(57)【要約】  基地局が該基地局を介して通信コネクションを確立するための要求を通信デバイスから受信するシステムが開示されている。上記基地局は、以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得し、該取得された情報に基づいて、上記以前に確立された通信コネクションに関連するコンテキストを取得し、該取得されたコンテキストを用いて、上記以前に確立された通信コネクションを上記通信デバイスと再開する。【選択図】図５
2019506791.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでいる、トランシーバと、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得する、コントローラと、
を具備し、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開するように構成されている、
第１基地局。
【請求項２】
請求項１記載の第１基地局であって、
前記再開ＩＤは、前記ＲＲＣコネクションを中断しているタイミングで、前記第２基地局から前記ユーザ機器に対して供給されるＩＤである、
第１基地局。
【請求項３】
請求項１又は２に記載の第１基地局であって、
前記中断手順は、移動管理ノード（ＭＭＥ）とサービングゲートウェイ（Ｓ−ＧＷ）との間のインタラクションを必要とする、
第１基地局。
【請求項４】
請求項１から３のいずれか１項に記載の第１基地局であって、
前記コントローラは、前記ＲＲＣを中断することを決定する、
第１基地局。
【請求項５】
請求項１から４のいずれか１項に記載の第１基地局であって、
前記再開ＩＤは、前記第２基地局のＩＤに基づいて作成される、
第１基地局。
【請求項６】
請求項１から５のいずれか１項に記載の第１基地局であって、
前記トランシーバは、前記第２シグナリングメッセージを受信した後に、前記第２基地局における前記ＵＥコンテキストの開放についての要求を前記第２基地局へ送信する、
第１基地局。
【請求項７】
請求項１から６のいずれか１項に記載の第１基地局であって、
前記ＲＲＣコネクションは、物のインターネット（ＩｏＴ）デバイスのためのコネクションである、
第１基地局。
【請求項８】
第１基地局によって実行される方法であって、
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでおり、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得し、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開する、
方法。
【請求項９】
請求項８記載の方法であって、
前記再開ＩＤは、前記ＲＲＣコネクションを中断しているタイミングで、前記第２基地局から前記ユーザ機器に対して供給されるＩＤである、
方法。
【請求項１０】
請求項８又は９に記載の方法であって、
前記中断手順は、移動管理ノード（ＭＭＥ）とサービングゲートウェイ（Ｓ−ＧＷ）との間のインタラクションを必要とする、
方法。
【請求項１１】
請求項８−１０のいずれか１項に記載の方法であって、
さらに、前記ＲＲＣを中断することを決定する、
方法。
【請求項１２】
請求項８から１１のいずれか１項に記載の方法であって、
前記再開ＩＤは、前記第２基地局のＩＤに基づいて作成される、
方法。
【請求項１３】
請求項８から１２のいずれか１項に記載の方法であって、
さらに、前記第２シグナリングメッセージを受信した後に、前記第２基地局における前記ＵＥコンテキストの開放についての要求を前記第２基地局へ送信する、
方法。
【請求項１４】
請求項８から１３のいずれか１項に記載の方法であって、
前記ＲＲＣコネクションは、物のインターネット（ＩｏＴ）デバイスのためのコネクションである、
方法。
【請求項１５】
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでいる、受信手順と、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得する、取得手順と、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開する、再開手順と、
を、第１基地局に実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関する。本発明は、排他的ではないが、特に、第３世代パートナーシッププロジェクト（３ＧＰＰ）標準に基づいて動作する無線通信システム及びその装置、又は、それらの等価物若しくは派生物に関する。本発明は、排他的ではないが、特に、「物のインターネット（Internet of Things）」デバイス及び／又は（狭帯域の（narrowband））通信デバイスによる、データ送信に関する。
【背景技術】
【０００２】
３ＧＰＰ標準の最新の開発は、進化型パケットコア（ＥＰＣ：Evolved Packet Core）ネットワーク及び進化型ＬＭＴＳ地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）のロングタームエボリューション（Long Term Evolution）と呼ばれている。３ＧＰＰ標準の下では、ノードＢ（又はＬＴＥにおけるｅＮＢ）は、基地局であり、該基地局を介して、通信デバイスが、コアネットワークに接続し、そして、他の通信デバイス又はリモートサーバと通信する。簡単にするために、本出願は、そのような基地局を参照するために、基地局という用語を使用する。通信デバイスは、例えば、携帯電話（mobile telephones）、スマートフォン、ユーザ機器、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子ブックリーダなどのような、モバイル通信デバイスであってもよい。このようなモバイル（又は、通常静止している）デバイスは、典型的には、ユーザによって操作される。しかしながら、３ＧＰＰ規格は、所謂「物のインターネット（ＩｏＴ）」デバイス群（例えば、狭帯域ＩｏＴ（ＮＢ−ＩｏＴ）デバイス群）をネットワークに接続することを可能にする。そして、ＩｏＴデバイス群は、自動化装置（automated equipment）を含み、該自動化装置は、例えば、種々の測定機器、テレメトリ機器（telemetry equipment）、監視システム、追跡デバイス（tracking and tracing devices）、車載安全システム（in-vehicle safety systems）、道路センサ（road sensors）、デジタル広告板（digital billboards）、販売場所（point of sale）端末、リモート制御システム（remote control systems）のようなものである。ＩｏＴデバイス群は、非固定装置（例えば、車両）に備え付けられる又は監視／追跡の対象である動物若しくは人に取り付けられるＩｏＴデバイスもあるが、自動販売機、路側センサ（roadside sensors）、ＰＯＳ端末の様な、（通常）固定装置の一部として実装されてもよい。ＩｏＴデバイスは、マシンタイプ通信（ＭＴＣ）通信デバイス又はマシンツーマシン（Ｍ２Ｍ）通信デバイスと呼ばれることもあることが理解されよう。しかしながら、ＩｏＴデバイスは、厳密な狭帯域要件及び／又は省エネルギーニーズ（例えば、バッテリを数年間交換することができない）のために、ＭＴＣデバイスの特別なサブセットを形成する。
【０００３】
効果的には、ＩｏＴ（Internet of Things）は、適切な電子機器、ソフトウェア、センサ、ネットワーク接続などを備えた、複数のデバイス（又は、「複数の物」）のネットワークであり、これらによって、これら複数のデバイスは、互いにそして他の通信デバイスとデータを収集し交換することが可能になる。説明を簡単にするために、本出願は、明細書において、ＩｏＴデバイスを参照するが、説明された技術は、人による入力によって制御される通信デバイスであるか又はメモリに記憶されたソフトウェア命令によって制御される通信デバイスであるかに関わらず、データ送信／データ受信のために通信ネットワークに接続できる（移動する及び／又は通常固定の）如何なる通信デバイスに実装されてもよい。
【０００４】
ＩｏＴデバイスは、ネットワークに接続して、離れた「マシン」（例えば、サーバ）又はユーザとの間でデータを送受信する。ＩｏＴデバイスは、携帯電話又は類似のユーザ機器に最適化された通信プロトコル及び規格を使用する。しかしながら、ＩｏＴデバイスは、一度配置されると、典型的には、人間の監督又は指示を必要とせずに動作し、内部メモリに記憶されたソフトウェア命令に従う。ＩｏＴデバイスは、また、長期間にわたって、静止状態及び／又は非活動状態のままである可能性がある。ＩｏＴデバイスをサポートするための特定のネットワーク要件は、３ＧＰＰ技術報告書（ＴＲ）２３．７２０ Ｖ１．２．０で扱われており、その内容は、参照により本明細書に組み込まれる。ＩｏＴデバイス（及び他のＭＴＣデバイス全般）に関する更なるネットワーク要件は、３ＧＰＰ ＴＳ ２２．３６８標準Ｖ１３．１．０に開示されている。
【０００５】
ＩｏＴデバイスは、一般に、人間の監督なしでできるだけ長く動作できるように設計されている。例えば、ＩｏＴデバイスは、自発的に接続を設定してイベントを報告し、それから、スリープモードやスタンバイモードなどの低電力動作モードに戻るように、プログラムされ得る。
【０００６】
デバイスのバッテリ寿命を保証することは、ＮＢ−ＩｏＴワークの最大の考慮事項の１つである。ＩｏＴデバイスをよりシンプルにする一方で、データの保存や検索などのタスクを最小限に抑えることによって、バッテリの寿命を延ばすことができる。その結果として、迅速なデータ伝送及びそれに伴う電力節約を達成することができる。
【０００７】
３ＧＰＰは、ＮＢ−ＩｏＴデバイスのための軽いデータ送信を可能にするためのいくつかの解決策を検討した。３ＧＰＰによって選定された１つの解決策（「解決策２（Solution 2）」と呼ばれる）によれば、データは、非アクセス層（ＤＯＮＡＳ：non-access stratum）を介して、送信されてもよい。他の選定された解決策（「解決策１８」）は、必要なメッセージサイクルの数を短くすることによって、ユーザプレーン上での軽いデータ送信を容易にする。解決策１８の更なる詳細は、３ＧＰＰ Ｒ３−１５２６８６（「User plane based solution with AS information stored in RAN」と題される）及びＴＲ２３．７２０（「Architecture enhancements for Cellular Internet of Things」）に記載されており、その内容は、参照により本明細書に組み込まれる。
【０００８】
本発明は、エネルギーを節約するニーズがあり且つ狭帯域スペクトルで動作するように設計された（多数の、実際の展開では数百万デバイスのオーダーの）ＩｏＴデバイス群のための軽量化対策を提供するための要件を大きく損なうことなく、解決策１８に関する複数の問題を（少なくとも一部）に対処しようとしている。
【０００９】
解決策１８の１つの目標は、ＩｏＴ送信に関連するシグナリングオーバーヘッドを低減すること及びネットワークにおける関連する処理負荷を低減することである。この目的を達成するために、関連するネットワークノード（例えば、ＵＥ／ＩｏＴデバイス、基地局（ｅＮＢ）、移動管理エンティティ（ＭＭＥ：mobility management entity）、及びサービングゲートウェイ）のいくつかから、新しい挙動が予想される。具体的には、解決策１８は、以下のことを必要とする。
−（特定のＩｏＴデバイスのための）無線リソース制御（ＲＲＣ）接続を動作させるために必要なＡＳレベル情報（AS-level information）を格納（キャッシング）し、且つ、この情報をＥ−ＵＴＲＡＮ及びＩｏＴデバイス（ＵＥ）の両方に、ＩｏＴデバイスがＲＲＣアイドルモード（RRC_IDLE mode）にある間、保持すること。
−基地局（ｅＮＢ）ベースで機能をサポートすること。
−（特定のＩｏＴデバイスのための）Ｓ１−ＭＭＥ ＵＥ−関連シグナリング接続（S1-MME UE-associated signalling connection）が、ＩｏＴデバイスがＲＲＣアイドルモード（RRC_IDLE mode）にある間、基地局（ｅＮＢ）とＭＭＥとの間で維持されること。
−中断及び再開（suspend and resume）という２つの新しい手順が、ＲＲＣ及びＳ１ＡＰに主な影響を持って、導入されること。
−（特定のＩｏＴデバイスのための）ベアラコンテキストデータが、そのＩｏＴデバイスに関連する基地局（ｅＮＢ）及びＭＭＥに保持されること。
−中断及び再開という手順が、また、上記の関係するＩｏＴデバイスに関連する、ＭＭＥとサービングゲートウェイ（Ｓ−ＧＷ）との間のインタラクション（interaction）を必要とすること。
【００１０】
更に、また、ネットワーク主導の再開ケースに関して（for the network initiated resume case）、（特定のＩｏＴデバイスのための）ページングメッセージが（そのＩｏＴデバイスのための）既に確立されているＵＥ−関連シグナリング接続（UE-associated signalling connection）内で送信されることが許容される、ことが予測される。（ページングされたＩｏＴデバイスのための）中断されたＵＥコンテキストを保持している基地局のセル内でページングが成功すると、上記の再開手順（resume procedure）がトリガされる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
基地局がＩｏＴデバイス（ＵＥ）によって提供されたＡＳリファレンス（AS reference）によってアドレス指定されたＵＥコンテキストを見つけることができない場合、ＩｏＴデバイスは、レガシーサービス要求／ＲＲＣ接続セットアップ手順（legacy Service Request/RRC Connection Setup procedures）を実行する必要がある。更に、通常のＵＥコンテキスト解放手順（normal UE Context Release procedure）は、ＩｏＴデバイスに関連する「古い（旧）（old）」基地局（つまり、ＭＭＥに知られている最後の／前のサービス基地局）に向けて、ＭＭＥによって実行されてもよい。
【００１２】
（ほとんどのＩｏＴデバイスは動かない及び／又は頻繁には動かないが）シャドーイング、フェージング、及び／又は他の無線障害のために、ＩｏＴデバイス群がアタッチメントのセル／ｅＮＢポイントを１つのセル／基地局から他のセル／基地局へ切り替えてもよいことは、評価されるであろう。
【００１３】
セル/基地局を切り替える際に、関連するＵＥコンテキストが特定のＩｏＴデバイスのための新しい（新）基地局（new base station）で（そのＩｏＴデバイスによって提供される所謂「再開ＩＤ（Resume ID）」に基づいて）見つからない場合、ＩｏＴデバイスは、所謂レガシーアタッチ（Legacy Attach）手順に戻る必要がある。しかしながら、このレガシーアタッチ手順は、多くの場合、解決策１８の全体の目的を無効にする、エネルギー及びスペクトルの浪費を招く。更に、古いセル/基地局は、問題のＩｏＴデバイスが別の（例えば、隣接する）基地局に既にアタッチしていることを知ることなく、関連するＵＥコンテキストを保持し続ける。現在、正しい新しい基地局にＵＥコンテキストを渡して、古い基地局のＵＥコンテキストをタイムリーに解放することは、不可能である。また、提供された開放ＩＤが有効でないことを特定のＩｏＴデバイスに対して新しい基地局が通知するための適切なメカニズムも存在しない。
【００１４】
本発明者らは、ＩｏＴデバイス群（及び／又は同様のＵＥ群）を、新しく選択された基地局へＲＲＣ接続再開要求（RRC Connection Resume Request）をいつ送信すべきか及びレガシーＲＲＣ接続セットアップにいつ戻るべきかを決定するための複雑な手順を提供することなく、できるだけシンプルに保つことが自明でない、ことを認識した。また、通常のＵＥに適用可能な（例えば、アイドルモード（IDLE-mode）でセル／基地局を変更するＵＥのための）解決策を提供することも重要である。
【００１５】
従って、本発明の好ましい例示的な実施形態は、上記ニーズに対処する又は少なくとも部分的に対処する、方法及び装置を提供することを目的とする。
【００１６】
当業者の理解を容易にするために、本発明は、３ＧＰＰシステム（ＵＭＴＳ、ＬＴＥ）の文脈で詳細に説明されるが、本発明の原理は、通信デバイス又はユーザ機器（ＵＥ）が無線アクセス技術を用いてコアネットワークにアクセスする、他のシステムに適応可能である。
【課題を解決するための手段】
【００１７】
一態様において、本発明は、通信ネットワークのための基地局であって、前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信するトランシーバと、以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得して、前記取得された情報に基づいて、前記以前に確立された通信コネクションに関連するコンテキストを取得する、コントローラと、を具備し、前記基地局は、前記取得されたコンテキストを用いて、前記以前に確立された通信コネクションを前記通信デバイスと再開するように構成されている、基地局を提供する。
【００１８】
他の態様において、本発明は、基地局によって稼働される通信ネットワークのセルを介して通信する通信デバイスであって、以前に確立された通信コネクションに関連するコンテキストを保持するように構成されたメモリと、前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を前記基地局へ送信するように構成され、通信コネクションを確立するための前記要求は、前記通信デバイスが前記通信ネットワークとの間の以前に確立された通信コネクションを有していることを示す情報、及び、前記以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する情報を含む、トランシーバと、前記コンテキストを用いて、前記基地局との間で、前記以前に確立された通信コネクションを再開するように構成されたプロセッサと、を具備する基地局を提供する。
【００１９】
他の態様において、本発明は、通信ネットワークのための基地局であって、通信デバイスとの間で通信コネクションを確立して関連するコンテキストをセットアップし、前記通信コネクションが中断されているか否かを判定する、コントローラと、前記コントローラが前記通信コネクションを確立したとき及び前記通信コネクションが中断されていると前記コントローラによって判定されたときの少なくとも１つ、及び、リクエスト時に、前記コンテキストを他の通信ノードへ転送する、トランシーバと、を具備する基地局を提供する。
【００２０】
他の態様において、本発明は、通信ネットワークのための通信装置であって、基地局から、前記基地局及び通信デバイスを含む通信コネクションに関連するコンテキストを受信するトランシーバと、前記受信されたコンテキストを保持するメモリと、前記メモリから前記保持されたコンテキストを取得し、前記コンテキストの当初の受信元である前記基地局及び他の基地局のうちの１つに向けた前記トランシーバによる、前記取得されたコンテキストの転送を開始するコントローラと、を具備し、前記コントローラは、前記通信コネクションが再開されるべきでることを示し且つ前記保持されたコンテキストを識別する情報を受信したときに、前記保持されたコンテキストを取得し、前記転送を開始する、通信装置を提供する。
【００２１】
他の態様において、本発明は、通信ネットワークのための基地局であって、前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信するトランシーバと、以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得し、前記以前に確立された通信コネクションに関連するコンテキストを取得できないことを判定するコントローラと、を具備し、前記トランシーバは、前記以前に確立された通信コネクションに関連するコンテキストを取得できないという前記判定に応答して、前記以前に確立された通信コネクションを再開できないことを示すメッセージを、前記通信デバイスへ送信する、基地局を提供する。
【００２２】
本発明の複数の態様は、システムと、方法と、プログラム可能なプロセッサをプログラムして上記した又は特許請求の範囲に記載した態様及び可能性に記載した方法を実行するように機能する命令、及び／又は、適切に適合したコンピュータをプログラムしてクレームのいずれかに記載された装置を提供するように機能する命令を格納したコンピュータ可読記憶媒体などのコンピュータプログラムプロダクトとに及ぶ。
【００２３】
本明細書（特許請求の範囲を含む）及び／又は図面に示された各特徴は、他の開示された及び／又は図示された特徴とは独立して（又は組み合わせて）、本発明に組み込まれてもよい。限定されるものではないが特に、特定の独立請求項に従属する請求項のいずれかの特徴は、その独立請求項に任意の組合せで又は個別に導入されてもよい。
【００２４】
本発明の例示的な実施形態は、添付の図面を参照して、例として以下に説明される。
【図面の簡単な説明】
【００２５】
【図１】本発明の例示的な実施形態を適用可能な、セルラ通信システム（cellular telecommunication system）を概略的に示す図である。
【図２】図１に示すシステムの一部を形成するＩｏＴデバイスのブロック図である。
【図３】図１に示すシステムの一部を形成する基地局のブロック図である。
【図４】図１に示すシステムの一部を形成する移動管理エンティティのブロック図である。
【図５】本発明の例示的な実施形態が図１のシステムに実装され得る、例示的な方法を示すタイミング図である。
【図６】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図７】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図８】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図９】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図１０】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図１１】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【図１２】本発明の例示的な実施形態が図１のシステムに実装され得る、更なる例示的な方法を示すタイミング図である。
【発明を実施するための形態】
【００２６】
＜概要＞
図１は、ＩｏＴデバイス３、携帯電話（「ＵＥ」と示される）、及び他の通信デバイス（図示せず）が、Ｅ−ＵＴＲＡＮの無線アクセス技術（ＲＡＴ：radio access technology）を用いてＥ−ＵＴＲＡＮ基地局５及びコアネットワーク７を介して互いに通信することができる、電気通信ネットワーク１を概略的に示す。当業者には理解されるように、図１には、１つのＩｏＴデバイス３と、２つの携帯電話（mobile telephones）と２つの基地局５−１，５−２が、図示の目的のために示されているが、該システムは、実装される際には、典型的には、他の基地局及び他の通信デバイスを含んでいる。
【００２７】
各基地局５は、１つ又は複数の関連するセルを管理する。この例では、第１の基地局５−１は、「セル１」を管理し、第２の基地局５−２は、「セル２」を管理する。複数の通信デバイスは、セルを管理している適切な基地局と無線リソース制御（ＲＲＣ：radio resource control）接続を確立することによって、いずれかのセル（通信デバイスの位置、及び、他の要因、例えば、信号状態（signal conditions）、加入者データ（subscription data）、能力（capability）などに基づく、セル）に接続してもよい。図からわかるように、ＩｏＴデバイス３は、基地局５−１，５−２によって管理されている複数のセルが部分的にオーバラップしているエリアに位置している。このため、（データの送信／受信はない）ＲＲＣアイドルモード（RRC idle mode）で動作しているときには、ＩｏＴデバイス３は、最も信号品質が良いセルにキャンプオンし、ＲＲＣアクティブモード（RRC active mode）で動作しているときには、ＩｏＴデバイス３は、そのセルを介してデータを通信する。
【００２８】
複数の基地局５は、Ｓ１インタフェースを介してコアネットワーク７に接続され、Ｘ２インタフェース（図示せず）を介して互いに接続されている。コアネットワーク７は、インターネットなどの他のネットワーク及び／又はコアネットワーク７の外部にホストされたサーバに接続するための、ゲートウェイ８を含んでいる。
【００２９】
移動管理エンティティ（ＭＭＥ）９は、通信ネットワーク１内でアイドルモード（IDLE-MODE）にある移動通信デバイス（携帯電話及びＩｏＴデバイス３）の位置を追跡する役割を果たすネットワークノードである。特に、ＭＭＥ９は、複数の移動通信デバイスの最後の既知セル（又はトラッキングエリア）の識別子を格納しており、これにより、該複数の移動通信デバイスは、着信（音声又はデータ）呼があるときに通知され、通信パスが、その特定の移動通信デバイスに現在サービスしている基地局５を介して、セットアップされる。
【００３０】
ホーム加入者サーバ（ＨＳＳ：home subscriber server）１０は、各通信デバイス（例えば、ＩｏＴデバイス３及び携帯電話）について固有の加入関連情報（subscription related information）及び制御パラメータを格納する。ＨＳＳ１０は、また、複数の通信デバイスのうちのいずれがマシンタイプ通信デバイス（例えば、ＩｏＴ／ＭＴＣクライアントを実行しているときの、ＩｏＴデバイス３又は携帯電話）として構成（設定）されているかを識別する、情報を記憶しており、必要とされる場合に、この情報を他のネットワークエンティティへ提供する。
【００３１】
以下の例では、ＩｏＴデバイス３は、リモートサーバ（又は別の通信デバイス）にデータを送信するために、特定の間隔で（及び／又は、ＩｏＴデバイス３のアプリケーションの１つがネットワークと通信する必要があるときはいつでも）、ネットワークに接続する。この実施形態のＩｏＴデバイス３の動作は、自動化されており、本質的には自律的に動作することが可能である。しかしながら、ＩｏＴデバイス３が、ローカル又はリモートユーザから受信した入力（例えば、測定基準のリモート（再）構成、又は、スケジュール外の測定実行及び／又は報告）に基づいて、特定の活動を実行することができる、ことは理解されるであろう。さらに、ＩｏＴデバイス３は、携帯電話と同様に、ユーザによって操作されてもよい。
【００３２】
破線矢印で示すように、ＩｏＴデバイス３は、（セル１を介して）第１の基地局５−１に以前に接続されており、このため、第１の基地局５−１は、関連するＵＥコンテキストを保持している。しかしながら、ＩｏＴデバイス３は、連続線の矢印で示すように、現在、（セル２を介して）第２の基地局５−２への接続を試みている。
【００３３】
ターゲット基地局５−２が、ＩｏＴデバイス３（及び／又は他の任意のユーザ機器）に関連するＵＥコンテキストを取得して、これにより、ＩｏＴデバイス３（ＵＥ）についての既存の接続を再開できること、を確実にするために、次の複数のオプションが想定される。
【００３４】
第１のオプションによれば、ＩｏＴデバイス３（ユーザ機器）は、（ＲＲＣ接続再開要求などの）明示的な再開要求を送信し、この要求に、再開すべき接続を識別する情報を含める。例えば、ＩｏＴデバイス３は、所謂、再開ＩＤ（Resume ID）、及び／又は、ターゲット基地局５−２がＩｏＴデバイスの接続を再開するために必要なＵＥコンテキストを取得できる、以前のセル／基地局を識別する情報、を提供してもよい。例えば、再開ＩＤ、及び／又は、以前のセル／基地局を識別する情報は、再開要求内の１つ又は複数の適切な情報要素（ＩＥ：information elements）の形式で、明示的に提供されてもよい。また、ＩｏＴデバイス３が、ターゲット基地局５−２がＵＥコンテキストを取得できる古い基地局（old base station）を識別するのに適した情報を含むように、再開ＩＤを構築するように構成されてもよい、ことも理解されるであろう。
【００３５】
上記の以前のセル／基地局を識別する情報は、例えば、古い／以前のセルのＥ−ＵＴＲＡＮセルグローバルＩＤ（ＥＣＧＩ）及び／又は同様のものを含んでいてもよい。ターゲット基地局５−２が再開ＩＤによって参照されたＵＥコンテキストを有している場合、ターゲット基地局５−２は、（通常、基地局との接続を確立するときに実行される）拡張シグナリングを必要とすることなく、また、関連する遅延及び／又はバッテリの使用もなく、そのＵＥコンテキストの使用を続けて、ＩｏＴデバイス３（ＵＥ）のための接続を再開する。ターゲット基地局５−２が、供給された再開ＩＤに関連するＵＥコンテキストを有していない場合、ＩｏＴデバイス３のための接続を再開する前に、識別された基地局（例えば、ＥＣＧＩに対応する基地局）から、ＵＥコンテキストを取得することを行う。
【００３６】
第２のオプションによれば、ＩｏＴデバイス３（ユーザ機器）は、明示的な再開要求ではなく、通常の接続要求（例えば、ＲＲＣ接続要求、トラッキングエリア更新要求など）を送信する。しかしながら、この場合、ＩｏＴデバイス３（ＵＥ）は、この要求に、再開されるべき接続を識別する情報を含める。（１つ又は複数の専用ＩＥ（one or more dedicated IEs）を使用して）明示的に以前のセル／基地局を識別する情報を提供する代わりに（又はそれに加えて）、ターゲット基地局５−２がＵＥコンテキストを取得できる古い基地局（及び／又はＵＥコンテキストを有している他のノード）を識別するのに適した情報を再開ＩＤが含むように、ＩｏＴデバイス３が再開ＩＤを構成するように構成（設定）されてもよい、ことが理解されるであろう。例えば、（乱数と共に）Ｓ−ＴＭＳＩが、再開ＩＤとして（又は再開ＩＤの代わりに）用いられてもよい。この場合、Ｓ−ＴＭＳＩは、どこからＵＥコンテキストを取得すべきかを示せるように、構成されてもよい。例えば、Ｓ−ＴＭＳＩは、ＵＥコンテキスト（の位置）に関連する、ＥＣＧＩ、ＰＣＩ、ｅＮＢ−ＩＤ、ＭＭＥ−ＩＤ（及び／又は、ＵＥコンテキスト（の位置）に関連する類似のもの）のうちの少なくとも１つを含んでいてもよい。
【００３７】
有益なことに、ターゲット基地局５−２が通常の接続要求手順の間に（例えば、それ自身のメモリから、又は、別のノードから）ＵＥコンテキストを取得できる場合、ターゲット基地局５−２は、そのＩｏＴデバイスの既存の接続を、拡張シグナリングなしで且つ遅延なく再開するために、接続要求手順の少なくとも一部（例えば、ハンドシェイク動作）をスキップするように、構成（設定）されてもよい。これは、ＲＲＣ接続再開要求に関連する手順のいくつかについては実行する必要がないことを意味しており、ＵＥの実装がシンプルであり且つＵＥの動作が軽い状態を維持することに寄与することができる。
【００３８】
第３のオプションによれば、ＩｏＴデバイス３（ユーザ機器）は、明示的な再開要求ではなく、通常の接続要求（例えば、アタッチ要求、トラッキングエリア更新要求など）を送信する。しかしながら、この場合、ＩｏＴデバイス３は、再開ＩＤ、及び／又は、接続を再開するためのＵＥコンテキストに関する情報を含めない。有益なことに、このオプションでは、ネットワークノード（例えば、基地局、ＭＭＥ、ＨＳＳ）は、接続要求手順の一部として、新しい基地局にＵＥコンテキストを取得する場所を指示するように、構成（設定）されている。例えば、ＭＭＥ及び／又はＨＳＳは、各ＩｏＴデバイス／ＵＥについての再開ＩＤを（例えば、そのＩｏＴデバイス／ＵＥのための接続が中断されたときに）記憶し、そのＩｏＴデバイスがその後に新しい基地局を介してネットワークに接続することを試みるときに、この再開ＩＤを新しい基地局へ送信するように、構成（設定）されてもよい。このため、新しい基地局は、内部メモリ内で再開ＩＤを検索して、（見つかった場合）関連するＵＥコンテキストを元に戻すこと、及び／又は、接続要求手順の間にＭＭＥ／ＨＳＳから受け取った情報に基づいて、以前の基地局から（又は、妥当な場合、ＭＭＥのような他のノードから）、ＵＥコンテキストを取得すること、が可能である。
【００３９】
有益なことに、ＩｏＴデバイス／ＵＥ（又はＭＭＥ／ＨＳＳ）によって供給された特定の再開ＩＤについて関連するＵＥコンテキストが（新しい）基地局で見つからなかった場合、（エネルギー及び周波数スペクトルの無駄である）レガシーアタッチ手順に戻る必要がない。これは、新しい基地局が、ＩｏＴデバイスが新しい基地局を介した接続を再開／確立することを要求する際にＩｏＴデバイスによって提供された情報に基づいて、ＵＥコンテキストを取得することができる、ためである。
【００４０】
更に、ＩｏＴデバイスが隣接基地局／セルにひとたびアタッチすると、古い基地局／セルがそのＩｏＴデバイスについてのＵＥコンテキストを保持し続ける必要はない。従って、新しい基地局が、再開されたＲＲＣ接続について古い基地局に通知して、古い基地局にＵＥコンテキストを（新しい基地局にそれを転送した後に）破棄するように指示する、ように構成（設定）されてもよい、ことが理解されるであろう。
【００４１】
ＩｏＴデバイスと新しい基地局とは、また、（その新しい基地局を介して接続するときに）ＵＥコンテキストをセットアップすることをゼロから開始する必要がない。これは、既存のＵＥコンテキストが、古い基地局（又は、ＭＭＥ、ＨＳＳ、ＧＷなどの他の適切なアンカーポイント）から新しい基地局へ、再開手順の一部として送信される、ことが可能であるためである。
【００４２】
有益なことに、ＭＭＥは、問題のＩｏＴデバイスがアタッチポイント（attachment point）を（例えば、基地局５−１から基地局５−２へ）変更したか否かに関わらず、ＩｏＴデバイスをページングするための既に確立されたＵＥ−関連シグナリングを常に用いることができる。
【００４３】
＜ＩｏＴデバイス＞
図２は、図１に示すＩｏＴデバイス３（又はＩｏＴデバイス３として動作するように構成された携帯電話）の主要な構成要素を示すブロック図である。図示されているように、ＩｏＴデバイス３は、１つ又は複数のアンテナ３３を介して基地局５との間で信号を送受信するように動作可能な、通信回路（transceiver circuit）３１を有している。ＩｏＴデバイス３は、ＩｏＴデバイス３の動作を制御する、制御部（controller）３７を有している。制御部３７は、メモリ３９に関連付けられ、通信回路３１に接続されている。その動作に必ずしも必要ではないが、ＩｏＴデバイス３は、当然のことながら、従来の携帯電話３の通常の機能（例えば、ユーザインタフェース３５）のすべてを有していてもよく、これは、必要に応じて、ハードウェア、ソフトウェア、及びファームウェアのいずれか１つ又は任意の組み合わせによって、提供されてもよい。ソフトウェアは、メモリ３９に予めインストールされていてもよく、及び／又は、例えば、通信ネットワーク（telecommunications network）を介して又は取り外し可能なデータ記憶デバイス（ＲＭＤ：data storage device）から、ダウンロードされてもよい。
【００４４】
制御部３７は、この例では、メモリ３９に記憶された、プログラム命令又はソフトウェア命令によって、ＩｏＴデバイス３の全体の動作を制御するように、構成（設定）されている。
図示されているように、これらのソフトウェア命令は、とりわけ、オペレーティングシステム４１、通信制御モジュール４２、ＵＥコンテキストモジュール４５、及び、ＲＲＣモジュール４６を含んでいる。
【００４５】
通信制御モジュール４３は、ＩｏＴデバイス３と、そのサービング基地局５（及び、更なるＩｏＴデバイス、携帯電話、コアネットワークノードなどのような、サービング基地局５に接続された他の通信デバイス）との間の通信を制御するように、動作可能である。
【００４６】
ＵＥコンテキストモジュール４５は、サービング基地局５を介して通信する際に使用するために、ＩｏＴデバイス３に関連するＵＥコンテキストを処理する（例えば、取得する、生成する、変更する、記憶する、及び／又は、転送する）ことについて、担当する。
【００４７】
ＲＲＣモジュール４６は、ＲＲＣ標準（RRC standard）に従ってフォーマットされた、シグナリングメッセージを、生成するように、送信するように、且つ、受信するように動作可能である。例えば、そのようなメッセージは、ＩｏＴデバイス３とそのサービング基地局５との間で、交換される。ＲＲＣメッセージは、例えば、新しいサービング基地局５を介して以前のＲＲＣ接続を再開することに関する、メッセージを含んでいてもよい。
【００４８】
＜基地局＞
図３は、図１に示す基地局５の主要な構成要素を示すブロック図である。図示のように、基地局５は、１つ又は複数のアンテナ５３を介して（ＩｏＴデバイス３／携帯電話のような）通信デバイスとの間で信号を送受信するための通信回路５１と、コアネットワーク７との間で信号を送受信するためのコアネットワークインタフェース５５（例えば、Ｓ１インタフェース）と、隣接する基地局との間で信号を送受信するための基地局インタフェース５６（例えば、Ｘ２インタフェース）とを有している。基地局５は、基地局５の動作を制御する制御部５７を有する。制御部５７は、メモリ５９に関連付けられている。図３には必ずしも示されていないが、基地局５は、当然のことながら、セルラ電話ネットワーク基地局の通常の機能のすべてを有していてもよく、これは、必要に応じて、ハードウェア、ソフトウェア、及びファームウェアの任意の１つ又は任意の組み合わせによって、提供されてもよい。ソフトウェアは、メモリ５９に予めインストールされていてもよく、及び／又は、例えば、通信ネットワーク（telecommunications network）１を介して又は取り外し可能なデータ記憶デバイス（ＲＭＤ：data storage device）から、ダウンロードされてもよい。制御部５７は、この例では、メモリ５９に記憶された、プログラム命令又はソフトウェア命令によって、基地局５の全体的な動作を制御するように、構成（設定）されている。図示のように、これらのソフトウェア命令は、とりわけ、オペレーティングシステム６１、通信制御モジュール６３、ＵＥコンテキストモジュール６５、ＲＲＣモジュール６６、Ｘ２モジュール６７、Ｓ１ＡＰモジュール６８、及び、再開ＩＤ関連付けモジュール（Resume ID association module）６９を含んでいる。
【００４９】
通信制御モジュール６３は、基地局５と、基地局５に接続されている、ＩｏＴデバイス３、携帯電話、及び他のネットワークエンティティとの間の通信を制御するように動作可能である。通信制御モジュール６３は、また、ダウンリンクのユーザトラヒック、及び、例えばＩｏＴデバイス３及び／又は携帯電話の動作を管理するための制御データを含む、基地局５に関連する通信デバイスへ送信されるべき制御データの、独立した複数のフローを制御する。
【００５０】
ＵＥコンテキストモジュール６５は、基地局５に接続されたユーザ機器（例えば、ＩｏＴデバイス３）に関連するＵＥコンテキストを処理する（例えば、取得する、生成する、変更する、記憶する、及び／又は、転送する）ことについて、担当する。
【００５１】
ＲＲＣモジュール６６は、ＲＲＣ標準（RRC standard）に従ってフォーマットされた、シグナリングメッセージを、生成するように、送信するように、且つ、受信するように、動作可能である。例えば、そのようなメッセージは、基地局５とＩｏＴデバイス３（及び基地局５のセル内の他の通信デバイス）との間で交換される。ＲＲＣメッセージは、例えば、ＩｏＴデバイス３のための以前のＲＲＣ接続を、新しいサービング基地局としてのこの基地局５を介して再開することに関する、メッセージを含んでいてもよい。
【００５２】
Ｘ２モジュール６７は、Ｘ２ＡＰ標準（X2AP standard）に従ってフォーマットされた、シグナリングメッセージ（Ｘ２メッセージ）を、生成するように、送信するように、且つ、受信するように、動作可能である。Ｘ２メッセージは、例えば、隣接する複数の基地局の間でのＵＥコンテキストの転送に関する、メッセージを含んでいてもよい。
【００５３】
Ｓ１ＡＰモジュール６８は、Ｓ１ＡＰ標準（S1AP standard）に従ってフォーマットされた、シグナリングメッセージを、生成するように、送信するように、且つ、受信するように、動作可能である。例えば、そのようなメッセージは、基地局５と移動管理エンティティ９との間で交換される。Ｓ１ＡＰメッセージは、例えば、基地局５のセルにおけるＩｏＴデバイス／ユーザ機器の位置を登録することに関するメッセージ（例えば、初期ＵＥメッセージ（Initial UE message）及び／又は関連する応答）を、含んでいてもよい。
【００５４】
再開ＩＤ関連付けモジュール６９は、基地局５に接続されたユーザ機器（例えば、ＩｏＴデバイス３）の各項目（each item）に対応する、各再開ＩＤを処理して記憶する。
【００５５】
＜移動管理エンティティ（Mobility Management Entity）＞
図４は、図１に示す移動管理エンティティ９の主要な構成要素を示すブロック図である。
図示のように、移動管理エンティティ９は、基地局インタフェース７５（例えばＳ１インタフェース）を介して基地局５（及び／又は基地局５に接続されている通信デバイス）との間で信号を送受信するための、通信回路７１を有している。移動管理エンティティ９は、移動管理エンティティ９の動作を制御する制御部７７を有している。制御部７７は、メモリ７９に関連付けられている。図４には必ずしも示されていないが、移動管理エンティティ９は、当然のことながら、セルラ電話ネットワーク移動管理エンティティ（cellular telephone network mobility management entity）の通常の機能のすべてを有していてもよく、これは、必要に応じて、ハードウェア、ソフトウェア、及びファームウェアの任意の１つ又は任意の組み合わせによって、提供されてもよい。ソフトウェアは、メモリ７９に予めインストールされていてもよく、及び／又は、例えば、通信ネットワーク（telecommunications network）１を介して又は取り外し可能なデータ記憶デバイス（ＲＭＤ：data storage device）から、ダウンロードされてもよい。制御部７７は、この例では、メモリ７９に記憶された、プログラム命令又はソフトウェア命令によって、移動管理エンティティ９の全体的な動作を制御するように、構成（設定）されている。図示のように、これらのソフトウェア命令は、とりわけ、通信制御モジュール８３、ＵＥコンテキストモジュール８５、及び、Ｓ１ＡＰモジュール８８を含んでいる。
【００５６】
通信制御モジュール８３は、移動管理エンティティ９と、移動管理エンティティ９に接続されている、基地局５、ＩｏＴデバイス３、携帯電話、及び他のネットワークエンティティとの間の通信を制御するように動作可能である。
【００５７】
ＵＥコンテキストモジュール８５は、ＭＭＥ９に接続されたユーザ機器（例えば、ＩｏＴデバイス３）に関連するＵＥコンテキストを処理する（例えば、取得する、生成する、変更する、記憶する、及び／又は転送する）ことについて、担当する。
【００５８】
Ｓ１ＡＰモジュール８８は、Ｓ１ＡＰ標準に従ってフォーマットされた、シグナリングメッセージを、生成するように、送信するように、且つ、受信するように、動作可能である。例えば、そのようなメッセージは、移動管理エンティティ９と基地局５との間で交換される。Ｓ１ＡＰメッセージは、例えば、基地局５のセルにおけるＩｏＴデバイス／ユーザ機器の位置を登録することに関するメッセージ（例えば、初期ＵＥメッセージ（Initial UE message）及び／又は関連する応答）を、含んでいてもよい。
【００５９】
上記の説明では、ＩｏＴデバイス３、基地局５、及び移動管理エンティティ９は、理解を容易にするために、（通信制御モジュール、ＵＥコンテキスト／ＵＥコンテキストセットアップモジュールのような）複数の個別モジュールを有しているものとして説明された。これらのモジュールは、例えば既存のシステムが本発明を実施するように改変された特定のアプリケーションのために、このように提供されてもよい。一方で、他のアプリケーションでは、例えば、当初から本発明の特徴を考慮して設計されたシステムでは、全体的なオペレーティングシステムやコードに組み込まれていてもよく、このため、これらのモジュールは、個別のエンティティとして認識されない可能性がある。これらのモジュールは、また、ソフトウェア、ハードウェア、ファームウェア、又は、これらを組み合わせに、実装されてもよい。
【００６０】
ここで、ＩｏＴデバイス３が新しい基地局を介してネットワークとのデータ接続を再開する、上述のシナリオをより詳細に説明する（図５−１０を参照）。
【００６１】
＜動作−第１実施形態＞
図５は、（このＩｏＴデバイス３に関連するＵＥコンテキストを持たない）異なる基地局を介してＩｏＴデバイス３（又はＵＥ）のためのデータ接続の再開を実行するときに、システム１の複数の構成要素によって実行される、例示的なプロセスを示すフローチャートである。
【００６２】
最初に、ステップＳ５００に大まかに示されるように、ＩｏＴデバイス３及び古い基地局５−１は、ＩｏＴデバイス３に関連するＵＥコンテキスト及び再開ＩＤを記憶する。このＵＥコンテキストは、ＩｏＴデバイス３と古い基地局５−１との間の以前のＲＲＣ接続の間に（例えば、ＩｏＴデバイス３が基地局５−１のセル１を介して通信していた間に）、生成されたものである、ことが理解されるであろう。
【００６３】
ＩｏＴデバイス３が第２の基地局５−２を介して（例えば、セル２を介して）ＲＲＣ接続を再開しようとするとき、ＩｏＴデバイス３は、ステップＳ５０１において、第２の基地局５−２に対してＩｏＴデバイス３のためのＲＲＣ接続を再開することを要求するための適切にフォーマットされたシグナリングメッセージを、（ＲＲＣモジュール４６を用いて）生成して、送信する。そのＲＲＣシグナリングメッセージ（例えば、「ＲＲＣ接続再開要求」メッセージ）は、再開されるべきＲＲＣ接続に関連する再開ＩＤと、古いサービング基地局／セルを識別する情報（例えば、関連するＥＣＧＩ、基地局識別子（ｅＮＢ−ＩＤ：base station identifier）、及び／又は、物理セル識別子（ＰＣＩ：Physical Cell Identity））とを含む。ＲＲＣシグナリングメッセージは、また、認証トークン（authentication token）と、関連するベアラを識別する情報とを含んでいてもよい。
【００６４】
ステップＳ５０３において、受信した情報（例えば、再開ＩＤ、ＥＣＧＩ、ｅＮＢ−ＩＤ、ＰＣＩ）に基づいて、新しい基地局５−２は、このＩｏＴデバイス３に関連するＵＥコンテキストが（例えば、この特定の再開ＩＤが基地局５−２の再開ＩＤ関連付けモジュール６９によって認識されないために）、この基地局５−２で利用できない、ことを判断する。しかしながら、新しい基地局５−２は、また、（受信したＥＣＧＩ、ｅＮＢ−ＩＤ、及び／又はＰＣＩが、第１の基地局５−１に関連しているので）第１の基地局５−１によってＵＥコンテキストが保持されている、ことを判断する。
【００６５】
従って、新しい基地局５−２は、そのＩｏＴデバイス３に関連するＵＥコンテキストを取得するために、適切にフォーマットされたシグナリングメッセージを、（そのＸ２モジュール６７を用いて）生成して、ステップＳ５０５において、古い基地局５−１へ送信する。新しい基地局５−２は、このメッセージ（例えば、「ＵＥコンテキストフェッチ要求（UE Context Fetch Request）」メッセージ）に、ＩｏＴデバイス３に関連する再開ＩＤを含める。
【００６６】
この要求に応答して、古い基地局５−１は、そのメモリ５９（ＵＥコンテキストモジュール６５）から、関連するＵＥコンテキストを取り出し、そして、ステップＳ５０７において、ＵＥコンテキストを適切にフォーマットされたＸ２シグナリングメッセージ（例えば、「ＵＥコンテキストフェッチ応答（UE Context Fetch Response）」メッセージ）に含めることにより、ＵＥコンテキストを新しい基地局５−２に送信する。
【００６７】
表１は、再開しているＩｏＴデバイス３に関連するＵＥコンテキストを転送する際に、基地局間で交換されるメッセージに含まれ得る、例示的な複数の情報要素（ＩＥｓ：information elements）を示す。この例では、複数のＩＥは、古い基地局５−１から新しい基地局５−２へ転送されるべき、古い基地局５−１でＩｏＴデバイス３を識別する情報及び新しい基地局５−２でＩｏＴデバイス３を識別する情報（例えば、それぞれ、old/new eNB UE X2AP IDs）、関連する再開ＩＤ（及び／又はこれに類似するもの）、並びに、複数の拡張無線ベアラ（E-RABs：enhanced radio access bearers）を識別する情報（例えば、E-RAB IDsのリスト）を含む。
【００６８】
ＵＥコンテキストの受信に成功すると、新しい基地局５−２は、ステップＳ５０９において、古い基地局５−１に対してＩｏＴデバイス３に関連するＵＥコンテキストを開放することを指示する、適切にフォーマットされたシグナリングメッセージ（例えば、「ＵＥコンテキストリリース（UE Context Release）」メッセージ）を、生成して、古い基地局５−１へ送信する。ＵＥコンテキストリリース要求に応答して、古い基地局５−１は、ＩｏＴデバイス３に関連するＵＥコンテキストを、解放する（例えば、そのＵＥコンテキストモジュール６５から削除する）（ステップＳ５１０）。
【００６９】
【表１】
2019506791.tif 000003
【００７０】
有益なことに、ＩｏＴデバイス３は、（例えば、関連するＥＣＧＩ、ｅＮＢ−ＩＤ、及び／又はＰＣＩを使用して）以前に使用されたセル／基地局について新しい基地局５−２に知らせることによって、以前に使用された基地局と異なる基地局を介した再開処理（resume operation）に失敗することを避けることができる。このため、ＩｏＴデバイス３が、（古い基地局と新しい基地局との間でＵＥコンテキストの転送が成功したと仮定すると）複雑な新しいＲＲＣ接続セットアップ手順（RRC connection setup procedures）を実行すること、又は、再開要求（resume request）にＵＥコンテキストを含める（ステップＳ５０１）こと、の必要もない。これにより、ＩｏＴデバイス３の観点から、全体的な手順を軽い状態に保つことができる。
【００７１】
＜動作−第２実施形態＞
図６は、ＩｏＴデバイス３が前に使用した基地局を介してＩｏＴデバイス３のためのデータ接続の再開を実行するときに、システム１の複数の構成要素によって実行される、別の例示的なプロセスを示すフローチャートである。この場合、ＩｏＴデバイス３は、レガシーＲＲＣ接続要求手順を実行することによって、ＲＲＣ接続を再開することを試みる。
【００７２】
最初に、ステップＳ６００に大まかに示されるように、ＩｏＴデバイス３及び（ＩｏＴデバイス３に以前にサービスしていた）基地局５−２は、ＩｏＴデバイス３に関連するＵＥアクセス層（ＡＳ：access stratum）コンテキストを記憶する。このＵＥ ＡＳコンテキストは、ＩｏＴデバイス３とこの基地局５−２との間の以前のＲＲＣ接続の間に（例えば、図６において破線で示されているように、ＩｏＴデバイス３がセル２と通信していた間に）、生成されたものである、ことが理解されるであろう。図示のように、ＵＥ ＡＳコンテキストは、ＩｏＴデバイス３に関連する適切なＳ−テンポラリモバイル加入者識別子（S-TMSI：S-Temporary Mobile Subscriber Identity）及び／又はランダムＩＤ（例えば、０から２４０−１の範囲の予め決められた長さを有する疑似乱数（pseudo random number））で、インデックスされる。ＩｏＴデバイス３及び基地局５−２によって記憶されたＡＳコンテキストと同様に、任意の関連する非アクセス層（ＮＡＳ：non-access stratum）コンテキストもＩｏＴデバイス３及びＭＭＥ９によって記憶されてもよい、ことが理解されるであろう。
【００７３】
ＩｏＴデバイス３が基地局５−２を介してＲＲＣ接続を再開しようと試みるとき、ＩｏＴデバイス３は、その基地局５−２に対してＩｏＴデバイス３のためのＲＲＣ接続を確立することを要求する適切にフォーマットされたシグナリングメッセージを、（ＲＲＣモジュール４６を用いて）生成し、ステップＳ６０１において、送信する。このメッセージは、例えば、ランダムアクセス手順のメッセージ３として送信されてもよい、ことが理解されるであろう。ＲＲＣシグナリングメッセージ（例えば、「ＲＲＣ接続要求（RRC Connection Request）」メッセージ又は「トラッキングエリア更新」（ＴＡＵ：Tracking Area Update）メッセージ）は、ＩｏＴデバイス３に関連付けられたＳ−ＴＭＳＩ及び／又はランダムＩＤを含む（そして、これにより、再開すべき以前のＲＲＣ接続を識別する）。効果的には、Ｓ−ＴＭＳＩ及び／又はランダムＩＤは、再開されるべきＲＲＣ接続を一意的に識別する再開ＩＤとして機能する。
【００７４】
言い換えれば、ＩｏＴデバイス３がレガシー手順を使用して接続を試みるとき（そして、ＩｏＴデバイス３が以前にこの前の基地局に接続していた場合）、ＩｏＴデバイス３は、ＩｏＴデバイス３が基地局５−２へ（ランダムアクセス手順の第３のメッセージとして）送信するＲＲＣ接続要求の中に、再開ＩＤ（Ｓ−ＴＭＳＩ及びランダムＩＤのペア）を準備する。Ｓ−ＴＭＳＩは、４０ビット長であるため、この目的に適していることが理解されるであろう。ランダムＩＤは、特別なレベルの識別／検証（extra level of identification/verification）を追加して、ＩｏＴデバイス３に保持されているＵＥ ＡＳコンテキストと基地局５−２に保持されているＵＥ ＡＳコンテキストとが一致することを保証する。
【００７５】
基地局５−２は、再開ＩＤ関連付けモジュール６９を用いて、ＩｏＴデバイス３から受信した再開ＩＤ（Ｓ−ＴＭＳＩ及び／又はランダムＩＤ）を参照する。再開ＩＤ関連付けモジュール６９がこの特定の再開ＩＤを発見すると、つまり、基地局５−２がこのＩｏＴデバイス３についてのＵＥ ＡＳ（及び／又はＮＡＳ）コンテキストを有していることを確認すると、基地局５−２は、（ステップＳ６０３に大まかに示されるように）ＵＥ ＡＳコンテキストを、（そのＵＥコンテキストモジュール６５を使用して）取ってくる。（再開ＩＤとして用いられる）Ｓ−ＴＭＳＩ及び／又はランダムＩＤは、基地局５−２が、Ｓ−ＴＭＳＩ及び／又はランダムＩＤから、（そのＵＥコンテキストが基地局５−２に保持されていない場合でも）どの他のネットワークノード（例えば、基地局５−１又はＭＭＥ９）がそのコンテキストを持っているかを判断できるように、構成されてもよい、ことが理解されるであろう。
【００７６】
その後、基地局５−２は、ステップＳ６０１で受信した要求に対して応答する。しかしながら、従来の（新しい）ＲＲＣ接続確立手順を続ける代わりに、基地局５−２は、ＩｏＴデバイス３に対して（通常、ＲＲＣ接続セットアップで必要とされる）セキュリティコマンド及びＤＲＢセットアップをスキップするように指示する適切にフォーマットされたシグナリングメッセージを、（ＲＲＣモジュール６６を用いて）生成し、ステップＳ６１０において、送信する。この例では、基地局５−２は、「ＲＲＣ接続セットアップ」メッセージを送信し、このメッセージに、ＩｏＴデバイス３に対してＲＲＣ接続セットアップの（少なくとも）一部（例えば、セキュリティコマンド及びＤＲＢセットアップ）をスキップするように命令するのに適した適切な指示（例えば、適切にフォーマットされた情報要素、フラグ、及び／又はそれに類似したもの）を含める。
【００７７】
ステップＳ６１２において、ＩｏＴデバイス３は、ＩｏＴデバイス３がセキュリティコマンド及びＤＲＢセットアップ手順をスキップして以前のＲＲＣ接続を再開することを確認する適切にフォーマットされたシグナリングメッセージ（例えば、「ＲＲＣ接続セットアップ完了（RRC connection setup complete）」メッセージ）を、（ＲＲＣモジュール４６を用いて）生成して、ステップＳ６１２において、送信することにより、基地局５からのＲＲＣ接続セットアップメッセージに対して応答する。
【００７８】
従って、ＩｏＴデバイス３及び基地局５は、ＩｏＴデバイス３が（ＲＲＣ接続要求手順を用いて）既存のＲＲＣ接続を再開するとき、ハンドシェイクを実行する必要はない。このため、ＩｏＴデバイス３は、（Ｓ−ＴＭＳＩをキーとして用いて）ＡＳコンテキストを復元することができ、ＡＳコンテキストをゼロから生成する必要がない。これは、有利には、より迅速且つ簡単な実装に寄与し、これにより、ＩｏＴデバイスのバッテリ寿命を改善する。このため、ＩｏＴデバイス３及び基地局５−２は、以前にＩｏＴデバイス３によって用いられたＡＳセキュリティ及びＤＲＢセットアップを有益に使用し続けることができ、ＩｏＴデバイス３がネットワークに接続する度に／ＩｏＴデバイス３が接続を再開する度に、それらをセットアップする必要はない。
【００７９】
ステップＳ６１５に大まかに示されるように、ＩｏＴデバイス３及び基地局５−２は、既存の（現在再開された）ＲＲＣ接続を用いて、データを交換し続ける。基地局５−２とＭＭＥ９との間の関連する制御データ（例えば、トラッキングエリア更新（ＴＡＵ）に関連するシグナリング）の送受信は、図６において破線を用いて示されている。
【００８０】
この例では、ＡＳコンテキストを取り戻す際にＭＭＥ９を関与させる必要はなく、そして、明示的な「再開」手順及び／又は明示的な「再開ＩＤ」を用いる必要はない（Ｓ−ＴＭＳＩ及び／又はランダムＩＤのペアを代わりに使用することができる）。
【００８１】
＜動作−第３実施形態＞
図７は、基地局５を介してＩｏＴデバイス３のためのデータ接続の再開を行うときに、システム１の構成要素によって実行される、別の例示的なプロセスを示すフローチャートである。この場合、そのデータ接続を再開するときに、ＩｏＴデバイス３は、レガシーＲＲＣ接続要求手順に従い、（新しい）基地局５は、（この例では）ＭＭＥ９のような適切なアンカーポイントから、ＩｏＴデバイス３に関連するＵＥコンテキストを取得する。
【００８２】
最初に、ステップＳ７００に大まかに示すように、ＩｏＴデバイス３及びそれの古いサービング基地局５−１は、ＵＥコンテキスト及びＩｏＴデバイス３に関連する適切な再開ＩＤを記憶する。このＵＥコンテキストは、ＩｏＴデバイス３と基地局５−１との間の以前のＲＲＣ接続の間に（例えば、ＩｏＴデバイス３が基地局５−１のセル１を介して通信していた間に）、生成されたものである、ことが理解されるであろう。破線で示すように、この時点で、第２の基地局５−２は、（例えば、ＩｏＴデバイス３がまだこの基地局５−２に接続したことがない場合）ＩｏＴデバイス３に関連するＵＥコンテキストを保持しなくてもよい。
【００８３】
ステップＳ７０１に大まかに示されるように、古いサービング基地局５−１は、（例えば、Ｓ１ＡＰモジュール６８によって生成された適切にフォーマットされたＳ１ＡＰシグナリングメッセージを用いて）ＩｏＴデバイス３に関連する再開ＩＤを、ＭＭＥ９へ転送するように構成される。この例では、古いサービング基地局５−１は、基地局５−１がＩｏＴデバイス３からの初期ＵＥメッセージ（Initial UE Message）をＭＭＥ９へ転送するときに、関連する再開ＩＤを転送する。各サービング基地局は、ＩｏＴデバイス３が最初にその基地局にアタッチしたとき、及び／又は、ＩｏＴデバイス３がその基地局を介したそのＲＲＣ接続を中断したとき、関連する再開ＩＤをＭＭＥ９へ転送するように、構成されてもよい。
ステップＳ７０２において、ＭＭＥ９は、受信した再開ＩＤを（例えば、そのＵＥコンテキストモジュール８５を用いて）記憶する。
【００８４】
ＩｏＴデバイス３が第２の基地局５−２を介して（セル２を介して）ＲＲＣ接続を再開しようと試みるとき、ＩｏＴデバイス３は、第２の基地局５−２に接続することを要求する適切にフォーマットされたシグナリングメッセージを、（ＲＲＣモジュール４６を用いて）生成して、ステップＳ７０３において、第２の基地局５−２へ送信する。この場合、ＲＲＣシグナリングメッセージ（例えば、「トラッキングエリア更新（Tracking Area Update）」又は「アタッチリクエスト（Attach Request）」メッセージ）は、新しいＲＲＣ接続をセットアップするためにユーザ機器によって通常送信されるレギュラーＲＲＣメッセージ（例えば、ランダムアクセス手順のメッセージ３）を含む。ＩｏＴデバイス３のＴＡＵ／アタッチ要求が基地局５−２に受け入れられると（図７には示されていない応答）、ＩｏＴデバイス３は、ＲＲＣ接続が成功裏にセットアップされたことを基地局５−２に確認するメッセージ（例えば、「ＲＲＣ接続完了（RRC connection complete）」メッセージ）を、（ＲＲＣモジュール４６を用いて）生成して、ステップＳ７０４において、送信する。
【００８５】
新しいサービング基地局５−２は、ＩｏＴデバイス３からの初期ＵＥメッセージ（Initial UE Message）を、ＭＭＥ９へ転送する（ステップＳ７０５）。この例では、新しい基地局５−２は、（基地局５−２がまだこのＩｏＴデバイス３についてのＵＥコンテキストを持っていないため、及び／又は、ＩｏＴデバイス３が既存の接続の再開を明示的に要求していないため）ＭＭＥ９へのメッセージに再開ＩＤを含めない。
【００８６】
しかしながら、ＭＭＥ９は、このＩｏＴデバイス３についての再開ＩＤを有しているので、ＭＭＥ９が新しい基地局５−２のメッセージに応答するとき、ＭＭＥ９は、適切にフォーマットされたシグナリングメッセージに、その再開ＩＤを含める。具体的には、ＭＭＥ９は、基地局５−２に対してそのＩｏＴデバイス３についてのＵＥコンテキストを生成することを要求する適切にフォーマットされたシグナリングメッセージ（例えば、「Ｓ１ＡＰ初期コンテキストセットアップ要求（S1AP Initial Context Setup Request）」メッセージ）を、（Ｓ１ＡＰモジュール８８を用いて）生成して、ステップＳ７０７において、送信することによって、基地局５−２へ応答するように構成されてもよい。このメッセージは、また、ＩｏＴデバイス３に関連する再開ＩＤ、及び、古いサービング基地局５−１を識別する情報（例えば、関連するｅＮＢ−ＩＤ、eNB UE X2AP ID、及び／又はこれに類似するもの）を含む。効果的に、このメッセージは、新しいサービング基地局５−２に対して、識別されている古いサービング基地局５−１から既存のＵＥコンテキストを取ってきて、以前のサービング基地局５−１を介してＩｏＴデバイス３によって以前に用いられていたＲＲＣ接続を再開することを、指示する。
【００８７】
ステップＳ７０９に大まかに示されているように、提供された再開ＩＤが新しい基地局５−２に既に知られている（再開ＩＤ関連付けモジュール６９に保持されている）場合、基地局５−２は、ＵＥコンテキストモジュール６５から対応するＵＥコンテキストを取り出す。
【００８８】
しかしながら、供給された再開ＩＤが新しい基地局５−２に知られていない（再開ＩＤ関連付けモジュール６９において見つけられない）場合、基地局５−２は、（ステップＳ７０７でＭＭＥ９によって識別された）隣接する（古い）基地局５−１からＵＥコンテキストを取ってくるために、ステップＳ７１０からステップＳ７１２に示す手順を実行する。ステップＳ７１０からステップＳ７１２は、図５を参照して上述したステップＳ５０５からステップＳ５０９に本質的に対応するので、ここでは説明を簡単にするために省略する。
【００８９】
次に、基地局５−２は（ＲＲＣモジュール６６を用いて）適切にフォーマットされたシグナリングメッセージを生成して、ステップＳ７１３において、送信する。このシグナリングメッセージは、ＩｏＴデバイス３に対して、（通常、ＲＲＣ接続セットアップで必要とされる）セキュリティコマンド及びＤＲＢセットアップをスキップするように指示するものである。この例では、基地局５−２は、また、このメッセージに、再開されるべきＲＲＣ接続に関連する再開ＩＤを含める。
【００９０】
従って、ＩｏＴデバイス３及び基地局５は、ＩｏＴデバイス３が（既存のＲＲＣ接続要求手順を用いて）既存のＲＲＣ接続を再開する場合、ハンドシェイクを実行する必要はない。このため、ＩｏＴデバイス３は、そのＵＥコンテキストを復元することができ、新しいサービング基地局５−２は、ＵＥコンテキストをゼロから生成せずに、復元又は取ってくることもできる。これは、有利には、より迅速且つ簡単な実装に寄与し、これにより、ＩｏＴデバイスのバッテリ寿命を改善する。
【００９１】
ステップＳ７１５に大まかに示されるように、ＩｏＴデバイス３及び新しいサービング基地局５−２は、再開されたＲＲＣ接続を用いて、データを引き続き交換することができる。
【００９２】
要約すると、この例示的な実施形態では、ＩｏＴデバイスは、新しい基地局がこのＩｏＴデバイスについてのＵＥ ＡＳコンテキストを記憶しているか否かに関わらず、レガシーＲＲＣ接続要求手順に従う。必要な情報がアンカーポイント／ＭＭＥによって提供される（そして、必要に応じて、ＵＥコンテキストが古いサービング基地局から持ってこられる）ので、ＩｏＴデバイスが、基地局に対して、（例えば、明示的な再開ＩＤ又はＳ−ＴＭＳＩ／ランダムＩＤの形式の）再開ＩＤを提供する必要がない。
【００９３】
変形例及び代替例
以上、詳細な実施形態が説明された。当業者には理解されるように、上記実施例には多くの修正及び代替がなされ得るが、その中に具現化される本発明の恩恵を受ける。図示されているように、いくつかの代替及び変更を説明する。
【００９４】
再開ＩＤは、複数のセルに亘った一意性を保証して新しい基地局がＵＥコンテキストをどこから取ってくるべきか把握することを容易にするために、古い基地局に関連するＥＣＧＩ／グローバルｅＮＢ−ＩＤペアから作成された適切な識別子を含んでもよい、ことが理解されるであろう。この場合、ＩｏＴデバイスは、（例えば、ステップＳ５０１において）ＥＣＧＩ／ＰＣＩを個別に提供する必要はない。
【００９５】
（例えばステップＳ５０９に示すように）新しい基地局からの明示的なコンテキストリリース要求（context release request）を用いる代わりに、古い基地局がタイマーを用いて（例えば、ＵＥコンテキストを転送した後、所定時間長が経過した後に）ＵＥコンテキストを解放するように構成されてもよい、ことが理解されるであろう。この場合、古い基地局は、ステップＳ５０７でタイマーをスタートさせ、タイマー満了時にＵＥコンテキストを削除／解放するように、構成されてもよい。
【００９６】
また、適用できる場合、再開ＩＤは、ＩｏＴデバイスのＲＲＣ接続に関する情報（例えば、ＡＳセキュリティコンテキスト、ＲｏＨＣ状態及び／又はＬ１／Ｌ２パラメータなどの適切なベアラ関連情報）を含んでいてもよい。
【００９７】
ＩｏＴデバイスに関連するＡＳコンテキストは、アンカーポイントを識別するための適切なキーと一緒に、共通のアンカーポイント（例えば、ＭＭＥ及び／又はＳ−ＧＷ）に格納されてもよい、ことが理解されよう。従って、この場合、新しい基地局は、（キーを用いて）アンカーポイントからＡＳコンテキストを取得することができる。
【００９８】
再開ＩＤは、デバイスのＲＲＣ接続を一時中断するときに（そのサービング基地局によって）ＩｏＴデバイスに供給されてもよい、ことが理解されよう。これにより、IoTデバイスがそれに続いて再開を試みるときに、再開ＩＤがＲＲＣ接続の最新の状態を反映する、ことが保証される。
【００９９】
（図５のステップＳ５１０を参照して上述したように）古い基地局でのＵＥコンテキスト解放は、再開しているＩｏＴデバイスに関連する、Ｓ１−ＭＭＥ及び／又はＳ１−Ｕ接続を（古い基地局で）開放することを含んでいてもよい、ことが理解されるであろう。この場合、（例えば、既存の「経路スイッチ要求（Path Switch Request）」手順と同様に）新しい基地局とＳ−ＧＷとの間のＩｏＴデバイスのために、新しいＳ１−Ｕ接続が確立されてもよい。
【０１００】
ＩｏＴデバイス、（例えば、ステップＳ５０１を参照して上述したように）古いサービングセルに関連するＥＣＧＩを提供する代わりに、無線リンク障害又は誤ったハンドオーバの後にＲＲＣ接続再確立要求（RRC Connection Reestablishment request）に含められる情報と同様に、そのＲＲＣ接続再開要求（RRC connection resume request）の中に、セル無線ネットワーク一時識別子（C-RNTI ： cell radio network temporary identity）、ＰＣＩ、及び／又は、適切な、データ完全性のためのメッセージ認証コード（(MAC-I ： Message Authentication Code for data Integrity）を含めてもよい、ことが理解されよう。
【０１０１】
図６に示す例示的な手順の上記の説明では、基地局は、ＲＲＣ接続を再開しようと試みているＩｏＴデバイスのＵＥ ＡＳコンテキストを既に保持していると記述されている。しかしながら、Ｓ−ＴＭＳＩは、（例えば、ＥＣＧＩ、ＰＣＩ、ｅＮＢ−ＩＤ、ＭＭＥ−ＩＤに基づいて）どこからＵＥコンテキストを取得するかを示すことができるように構成されてもよい、ことが理解されよう。有益なことに、この場合、新しい基地局は、この情報を含むネットワークノードからＵＥコンテキストを取ってくることができる。例えば、基地局は、ステップＳ５０３からステップＳ５０９を参照して上述した手順に従って、ＵＥコンテキストを取ってきてもよい。
【０１０２】
図８及び図９は、図7を参照して上述した手順の例示的な変更例を示している。しかしながら、これらの例では、ＭＭＥが（ステップＳ７０２において）再開ＩＤを格納するためのアンカーポイントである代わりに、ＭＭＥは、ＨＳＳが（ステップＳ８０２において）記憶するための再開ＩＤを転送するように、構成されてもよい。代替的には、ＨＳＳは、ＩｏＴデバイスに関連する国際モバイル加入者識別子（IMSI ： International Mobile Subscriber Identity）から、再開ＩＤを導出することができる。このため、ＭＭＥが初期ＵＥメッセージ（Initial UE message）に応答する場合（ステップＳ８０７／Ｓ９０７）、ＭＭＥは、ＭＭＥのメッセージに、ＨＳＳによって提供される再開ＩＤを含める。図８及び図９に示される他のステップは、図７を参照して上述した同様の番号のステップに対応する。
【０１０３】
上述したように、既存のＵＥコンテキストは、再開動作の一部として、適切なアンカーポイントによって格納され、該適切なアンカーポイントから新しい基地局に渡されてもよい。ＭＭＥ、ＨＳＳ、及び／又はＳ−ＧＷは、このようなアンカーポイントとして機能するように構成されてもよい、ことが理解されよう。図１０及び図１１は、ＵＥコンテキストを格納するためのそのような共通のアンカーポイントを含む、２つの例示的なシナリオを示す。
【０１０４】
図１０のステップＳ１００１で分かるように、古い基地局は、ＩｏＴデバイスのための接続を最初に確立すると（ステップＳ１０００）、ＵＥコンテキストをアンカーポイントに転送するように、構成されてもよい。ステップＳ１００１は、（これはＩｏＴデバイスに関連するＵＥコンテキストも含むが）本質的にはステップＳ７０１に対応することが理解されよう。
【０１０５】
図１１に大まかに示される別のオプションによれば、古い基地局は、後のフェーズにて、例えば、ＩｏＴデバイスのための接続を中断しているときに、（ステップＳ１１１０において）ＵＥコンテキストをアンカーポイントに転送するように、構成されてもよい。
【０１０６】
さらに別のオプションによれば、古い基地局は、ＵＥコンテキストを、新しい基地局へ直接的に、例えば新しい基地局から適切な要求を受信したときに（例えば、図７から図９に示された「ＵＥコンテキストフェッチリクエスト」手順を参照して上述したように）、転送するように、構成されてもよい。
【０１０７】
図１２は、新しい基地局が、接続を再開しようとしているＩｏＴデバイスについてのＵＥコンテキストを見つける（又は、取得する）ことができない、シナリオを示す。ステップＳ１２０３は、上述したステップＳ５０１に対応する。しかしながら、ステップＳ１２０８に一般的に大まかに示されるように、基地局（再開ＩＤ関連付けモジュール６９）は、（ＩｏＴデバイス又はＭＭＥ／ＨＳＳから）供給された再開ＩＤを認識できない、及び／又は、古い基地局からＵＥコンテキストを取ってくることができない。有利なことに、この場合、基地局は、適切にフォーマットされたランダムアクセス応答（random access response）（及び／又はそれに似たもの）を、ステップＳ１２０９において（ＲＲＣモジュール６６を用いて）生成して送信することにより、適切なエラー表示（error indication）を、ＩｏＴデバイスへ提供することができる。この例では、上記の応答（例えば、ランダムアクセスメッセージ３）は、「ＲＲＣ接続再開失敗（RRC Connection Resume Failure）」メッセージを含み、影響を受ける再開ＩＤを含む。このメッセージは、有益には、適切なエラー要因（error cause）、例えば「Resume ID not found」、「UE context not available」、「resume operation not supported」及び／又はこれに類似のものを含んでいてもよい。この応答（及びもしあれば失敗要因）を受信すると、ＩｏＴデバイスは、レガシー接続セットアップ手順にフォールバックし、及び／又は、（この基地局を介して接続を再開しようとするのではなく）異なる基地局を介して接続を試みることができる。
【０１０８】
本発明の実施形態は、物のインターネット（Internet of Things）（又は、マシンタイプ）データ送信（例えば、測定イベント中に取得されたデータの送信など）を特に参照して説明されているが、送信されるデータは、通信デバイスが使用されているアプリケーションに基づくデータフォームを有していてもよい、ことが理解されるであろう。例えば、上記の実施形態は、ユーザデータ、バックアップデータ、同期データ、診断データ、監視データ、使用統計、エラーデータなどの他のデータを送信するために適用されてもよい。
【０１０９】
上記の例示的な実施形態では、ＩｏＴデバイスは、自動化されたデバイスである。上記の実施形態は、例えば、携帯電話（スマートフォン）、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子書籍リーダーなどの自動化された機器以外の他の機器を用いて実施されてもよい、ことが理解されるであろう。
【０１１０】
上記の例示的な実施形態では、３ＧＰＰ無線通信（無線アクセス）技術が使用される。しかしながら、上記の実施形態によるＩｏＴデバイスの送信を管理するために、他の無線通信技術（つまり、ＷＬＡＮ、Ｗｉ-Ｆｉ、ＷｉＭＡＸ、Ｂｌｕｅｔｏｏｔｈなど）が用いられてもよい。上記の実施形態は、「非モバイル」又は通常は固定のユーザ機器にも適用可能である。
【０１１１】
ＩｏＴアプリケーションの例
物のインターネット（Internet of Things）（又はＭＴＣ）アプリケーションのいくつかの例は、次の表（ソース：3GPP TS 22.368 V13.1.0、付録B）にリストされている。このリストは包括的ではなく、物のインターネット／マシンタイプ通信アプリケーションの範囲を示すことが意図されている。
【０１１２】
【表２】
2019506791.tif 000004
【０１１３】
上記の説明では、ＩｏＴデバイス及び基地局は、多数の別個の機能コンポーネント又はモジュールを有するものとして、理解を容易にするために記載されている。これらのモジュールは、例えば既存のシステムが本発明を実施するように改変された特定のアプリケーションのために、このように提供されてもよいが、他のアプリケーションにおいて、例えば、当初から本発明の特徴を考慮して設計されたシステムにおいて、これらのモジュールは、全体的なオペレーティングシステム又はコードに組み込まれていてもよく、そのため、これらのモジュールは、別々のエンティティとして認識されない可能性がある。
【０１１４】
上記の例示的な実施形態では、いくつかのソフトウェアモジュールが説明された。当業者には理解されるように、ソフトウェアモジュールは、コンパイルされたフォーム又はコンパイルされていないフォームで提供されてもよく、基地局、モビリティ管理エンティティ、ＩｏＴデバイス、又は他のユーザ機器（例えば、携帯電話）に対して、コンピュータネットワーク上の又は記録媒体上の信号として、提供されてもよい。更に、このソフトウェアの一部又は全部によって実行される機能は、１つ又は複数の専用ハードウェア回路を用いて実行されてもよい。しかしながら、ソフトウェアモジュールの使用は、基地局、移動管理エンティティ、又は、ＩｏＴデバイス（又は、ＩｏＴ機能、例えばＭＴＣアプリケーションを有する携帯電話）の機能性を更新するための更新を容易にするので、好ましい。
【０１１５】
以前に確立された通信接続に関連するコンテキストがどこから取り出されることができるかを示す情報は、以前に確立された通信接続に関連するコンテキストを基地局によって取り出すことができる、ノード（例えば、隣接基地局及び／又はモビリティ管理エンティティ）を特定する情報を有していてもよい。
【０１１６】
基地局のコントローラは、以前に確立された通信接続に関連するコンテキストがどこから取り出されることができるかを示す情報を、トランシーバによって受信された、情報を含むメッセージ（例えば、通信接続を確立するための要求、又は、Ｓ１−ＡＰ初期コンテキストセットアップ要求（S1-AP Initial Context Setup Request）のような他のメッセージ）から、取得するように、構成されてもよい。
【０１１７】
以前に確立された通信接続に関連するコンテキストが取り出され得る場所を示す情報は、通信ネットワークの通信ノードを識別する情報要素を含んでいてもよく、上記のコントローラは、情報要素によって識別される通信ノードから（例えば、隣接する基地局及び／又は移動管理エンティティから）コンテキストを取り出すように、構成される。
【０１１８】
基地局のトランシーバは、コンテキストを識別する情報（例えば、再開ＩＤ）を含む少なくとも１つのシグナリングメッセージ（例えば、「ＵＥコンテキストフェッチ要求（UE Context Fetch Request）」）を送信することにより、識別された通信ノードからコンテキストを取り出すように、構成されてもよい。
【０１１９】
基地局のトランシーバは、識別された通信ノードでコンテキストを開放するために、要求を（例えば、以前に確立された通信接続を再開するときに）識別された通信ノードへ送信するように構成されてもよく、該要求は、コンテキストを識別する情報（例えば、再開ＩＤ）を含んでいる。
【０１２０】
以前に確立された通信接続に関連するコンテキストがどこから取り出されることができるかを示す情報は、基地局のメモリ内で、以前に確立された通信接続に関連するコンテキストを取り出すことができる場所を識別する情報を含んでいてもよい。
【０１２１】
上記のコンテキストは、アクセス層（AS：access stratum）コンテキスト及び／又は非アクセス層（NAS：non-access stratum）コンテキストのような、ユーザ機器（ＵＥ）コンテキストを含んでいてもよい。
【０１２２】
通信接続を確立するための要求は、無線リソース制御（RRC：radio resource control）接続を確立するための要求及びＲＲＣ接続を再開するための要求のうちの１つを含んでいてもよい。以前に確立された通信接続は、中断された／アイドルのＲＲＣ接続を含んでいてもよい。
【０１２３】
以前に確立された通信接続に関連するコンテキストがどこから取り出されることができるかを示す情報は、再開ＩＤ、テンポラリモバイル加入者識別子（TMSI：temporary mobile subscriber identity）（例えば、S-TMSI）、ランダムＩＤ、基地局及び／又はセルを識別する情報（例えば、eNB-ID）、及び、基地局についての通信デバイスを識別する情報（例えば、eNB UE X2AP ID）のうちの少なくとも１つを含んでいてもよい。
【０１２４】
基地局のコントローラは、通信デバイスからの通信接続を確立するための要求、又は、他の通信ノード（例えば、移動管理エンティティ）からのメッセージに基づいて、通信デバイスが以前に確立された通信接続を有していたことを判断するように、構成されていてもよい。
【０１２５】
基地局のトランシーバは、通信デバイスに対して通信接続を確立するための手順の一部をスキップさせるように（例えば、ＲＲＣセキュリティモードセットアップ（RRC security mode setup）及び／又はデータ無線ベアラ（DRB：data radio bearer）をスキップすること）、メッセージを通信デバイスへ送信するように動作してもよい。この場合、通信デバイスのトランシーバは、通信デバイスが通信接続を確立するための手順の一部をスキップするように（RRC security mode setup）及び／又はデータ無線ベアラ（DRB：data radio bearer）セットアップをスキップすること）、基地局からメッセージを受信するように動作してもよい。
【０１２６】
基地局のトランシーバは、通信デバイスが別の基地局を介して通信接続を再開したという表示（indication）を受信するように構成されてもよく、その場合、コントローラは、トランシーバがその表示を受信すると、コンテキストを削除するように構成されてもよい。
【０１２７】
基地局のトランシーバは、通信デバイスとの通信接続を再開する際に、関連するコンテキストを取り出すように構成されてもよい。
【０１２８】
以前に確立された通信接続が再開できないことを示す（基地局から通信デバイスへの）メッセージは、適切な失敗要因を識別する情報を含んでいてもよい。
【０１２９】
通信デバイスは、３ＧＰＰ標準によるユーザ機器、「物のインターネット（IoT：internet of things）」デバイス、マシンタイプ通信（MTC）デバイス、マシンツーマシン（M2M）通信デバイス、及び、携帯電話（mobile telephone）のうちの少なくとも１つを含んでいてもよい。
【０１３０】
種々の他の変形は、当業者にとって明らかであり、ここでは、更に詳細には説明されない。
【０１３１】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１３２】
（付記１）
通信ネットワークのための基地局であって、
前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信するトランシーバと、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得して、前記取得された情報に基づいて、前記以前に確立された通信コネクションに関連するコンテキストを取得する、コントローラと、
を具備し、
前記基地局は、前記取得されたコンテキストを用いて、前記以前に確立された通信コネクションを前記通信デバイスと再開するように構成されている、
基地局。
【０１３３】
（付記２）
付記１記載の基地局であって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、前記以前に確立された通信コネクションに関連する前記コンテキストを取得できるノード（例えば、隣接する基地局及び／又は移動管理エンティティ）を識別する情報を含む、
基地局。
【０１３４】
（付記３）
付記１又は２に記載の基地局であって、
前記コントローラは、以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す前記情報を、前記トランシーバによって受信された前記情報を含むメッセージ（例えば、通信コネクションを確立するための前記要求、又は、Ｓ１−ＡＰ初期コンテキストセットアップ要求（S1-AP Initial Context Setup Request）のような他のメッセージ）から取得するように、構成されている、
基地局。
【０１３５】
（付記４）
付記３記載の基地局であって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、前記ネットワークの通信ノードを示す情報要素を含み、
前記コントローラは、前記情報要素によって示される前記通信ノードから（例えば、隣接する基地局及び／又は移動管理エンティティから）前記コンテキストを取得する、ように構成されている、
基地局。
【０１３６】
（付記５）
付記４記載の基地局であって、
前記トランシーバは、前記コンテキストを識別する情報（例えば、再開ＩＤ）を含む少なくとも１つのシグナリングメッセージ（例えば、「ＵＥコンテキストフェッチ要求（UE Context Fetch Request）」）を送信することにより、前記識別された通信ノードから前記コンテキストを取得するように、構成されている、
基地局。
【０１３７】
（付記６）
付記４又は５に記載の基地局であって、
前記トランシーバは、前記識別された通信ノードにおいて前記コンテキストを開放するために、前記コンテキストを識別する情報（例えば、再開ＩＤ）を含む要求を、前記識別された通信ノードへ（例えば、前記以前に確立された通信コネクションを再開するときに）送信するように、構成されている、
基地局
【０１３８】
（付記７）
付記１記載の基地局であって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、前記以前に確立された通信コネクションに関連するコンテキストを取得できる前記基地局のメモリ内の場所を識別する情報を含む、
基地局。
【０１３９】
（付記８）
付記１から７のいずれか１項に記載の基地局であって、
前記取得されたコンテキストは、アクセス層（AS：access stratum）コンテキスト及び／又は非アクセス層（NAS：non-access stratum）コンテキストのような、ユーザ機器（ＵＥ）コンテキストを含む、
基地局
【０１４０】
（付記９）
付記１から８のいずれか１項に記載の基地局であって、
通信コネクションを確立するための前記要求は、無線リソース制御（RRC：radio resource control）コネクションを確立するための要求及びＲＲＣコネクションを再開するための要求のうちの１つを含む、
基地局。
【０１４１】
（付記１０）
付記１から９のいずれか１項に記載の基地局であって、
前記以前に確立された通信コネクションは、縦断された／アイドルのＲＲＣコネクションを含む、
基地局。
【０１４２】
（付記１１）
付記１から付記１０のいずれか１項に記載の基地局であって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、再開ＩＤ、テンポラリモバイル加入者識別子（TMSI：temporary mobile subscriber identity）（例えば、S-TMSI）、ランダムＩＤ、基地局及び／又はセルを識別する情報（例えば、eNB-ID）、及び、基地局についての通信デバイスを識別する情報（例えば、eNB UE X2AP ID）のうちの少なくとも１つを含む、
基地局。
【０１４３】
（付記１２）
付記１から１１のいずれか１項に記載の基地局であって、
前記コントローラは、前記通信デバイスからの通信コネクションを確立するための要求、又は、他の通信ノード（例えば、移動管理エンティティ）からのメッセージに基づいて、前記通信デバイスが以前に確立された通信コネクションを有していたことを判定するように、構成されている、
基地局。
【０１４４】
（付記１３）
付記１から１２のいずれか１項に記載の基地局であって、
前記トランシーバは、通信コネクションを確立するための手順の一部を前記通信デバイスに対してスキップさせるように（例えば、ＲＲＣセキュリティモードセットアップ（RRC security mode setup）及び／又はデータ無線ベアラ（DRB：data radio bearer）セットアップをスキップすること）、メッセージを前記通信デバイスへ送信する、
基地局。
【０１４５】
（付記１４）
基地局によって稼働される通信ネットワークのセルを介して通信する通信デバイスであって、
以前に確立された通信コネクションに関連するコンテキストを保持するように構成されたメモリと、
前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を前記基地局へ送信するように構成され、通信コネクションを確立するための前記要求は、前記通信デバイスが前記通信ネットワークとの間の以前に確立された通信コネクションを有していることを示す情報、及び、前記以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する情報を含む、トランシーバと、
前記コンテキストを用いて、前記基地局との間で、前記以前に確立された通信コネクションを再開するように構成されたプロセッサと、
を具備する基地局。
【０１４６】
（付記１５）
付記１４記載の通信デバイスであって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、前記以前に確立された通信コネクションに関連する前記コンテキストを取得できるノード（例えば、基地局及び／又は移動管理エンティティ）を識別する情報、及び、前記以前に確立された通信コネクションに関連するコンテキストを取得できる前記基地局のメモリ内の場所を識別する情報のうちの少なくとも１つを含む、
通信デバイス。
【０１４７】
（付記１６）
付記１４又は１５に記載の通信デバイスであって、
前記コンテキストは、アクセス層（AS：access stratum）コンテキスト及び／又は非アクセス層（NAS：non-access stratum）コンテキストのような、ユーザ機器（ＵＥ）コンテキストを含む、
通信デバイス。
【０１４８】
（付記１７）
付記１４から１６のいずれか１項に記載の通信デバイスであって、
通信コネクションを確立するための前記要求は、無線リソース制御（RRC：radio resource control）コネクションを確立するための要求及びＲＲＣコネクションを再開するための要求のうちの１つを含む、
通信デバイス。
【０１４９】
（付記１８）
付記１４から１７のいずれか１項に記載の通信デバイスであって、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する前記情報は、再開ＩＤ、テンポラリモバイル加入者識別子（TMSI：temporary mobile subscriber identity）（例えば、S-TMSI）、ランダムＩＤ、基地局及び／又はセルを識別する情報（例えば、eNB-ID）、及び、基地局についての通信デバイスを識別する情報（例えば、eNB UE X2AP ID）のうちの少なくとも１つを含む、
通信デバイス。
【０１５０】
（付記１９）
付記１４から１８のいずれか１項に記載の通信デバイスであって、
前記トランシーバは、通信コネクションを確立するための手順の一部を前記通信デバイスに対してスキップさせるために（例えば、ＲＲＣセキュリティモードセットアップ（RRC security mode setup）及び／又はデータ無線ベアラ（DRB：data radio bearer）セットアップをスキップすること）、メッセージを前記基地局から受信する、
通信デバイス。
【０１５１】
（付記２０）
付記１４から１９のいずれか１項に記載の通信デバイスであって、
３ＧＰＰ標準によるユーザ機器、「物のインターネット（IoT：internet of things）」デバイス、マシンタイプ通信（MTC）デバイス、マシンツーマシン（M2M）通信デバイス、及び、携帯電話（mobile telephone）のうちの少なくとも１つを含む、
通信デバイス。
【０１５２】
（付記２１）
通信ネットワークのための基地局であって、
通信デバイスとの間で通信コネクションを確立して関連するコンテキストをセットアップし、前記通信コネクションが中断されているか否かを判定する、コントローラと、
前記コントローラが前記通信コネクションを確立したとき及び前記通信コネクションが中断されていると前記コントローラによって判定されたときの少なくとも１つ、及び、リクエスト時に、前記コンテキストを他の通信ノードへ転送する、トランシーバと、
を具備する基地局。
【０１５３】
（付記２２）
通信ネットワークのための通信装置であって、
基地局から、前記基地局及び通信デバイスを含む通信コネクションに関連するコンテキストを受信するトランシーバと、
前記受信されたコンテキストを保持するメモリと、
前記メモリから前記保持されたコンテキストを取得し、前記コンテキストの当初の受信元である前記基地局及び他の基地局のうちの１つに向けた前記トランシーバによる、前記取得されたコンテキストの転送を開始するコントローラと、
を具備し、
前記コントローラは、前記通信コネクションが再開されるべきでることを示し且つ前記保持されたコンテキストを識別する情報を受信したときに、前記保持されたコンテキストを取得し、前記転送を開始する、
通信装置。
【０１５４】
（付記２３）
通信ネットワークのための基地局であって、
前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信するトランシーバと、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得し、前記以前に確立された通信コネクションに関連するコンテキストを取得できないことを判定するコントローラと、
を具備し、
前記トランシーバは、前記以前に確立された通信コネクションに関連するコンテキストを取得できないという前記判定に応答して、前記以前に確立された通信コネクションを再開できないことを示すメッセージを、前記通信デバイスへ送信する、
基地局。
【０１５５】
（付記２４）
付記２３記載の基地局であって、
前記以前に確立された通信コネクションを再開できないことを示す前記メッセージは、適切な失敗要因を識別する情報を含む、
基地局。
【０１５６】
（付記２５）
付記１から１３、２１、２３、２４のいずれか１項に記載の前記基地局と、付記１４から２０のいずれか１項に記載の前記通信デバイスと、を具備するシステム。
【０１５７】
（付記２６）
通信ネットワークの基地局によって実行される方法であって、
前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信し、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得し、
前記取得された情報に基づいて、前記以前に確立された通信コネクションに関連するコンテキストを取得し、
前記取得されたコンテキストを用いて、前記以前に確立された通信コネクションを前記通信デバイスと再開する、
方法。
【０１５８】
（付記２７）
通信デバイスによって実行される方法であって、
以前に確立された通信コネクションに関連するコンテキストを保持し、
基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を前記基地局へ送信し、通信コネクションを確立するための前記要求は、前記通信デバイスが前記通信ネットワークとの間の以前に確立された通信コネクションを有していることを示す情報、及び、前記以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを識別する情報を含み、
前記コンテキストを用いて、前記基地局との間で、前記以前に確立された通信コネクションを再開する、
方法。
【０１５９】
（付記２８）
通信ネットワークのための基地局によって実行される方法であって、
通信デバイスとの間で通信コネクションを確立して関連するコンテキストをセットアップし、
前記通信コネクションが中断されているか否かを判定し、
前記通信コネクションが確立されたとき及び前記通信コネクションが中断されていると判定されたときの少なくとも１つ、及び、リクエスト時に、前記コンテキストを他の通信ノードへ転送する、
方法。
【０１６０】
（付記２９）
通信ネットワークのための通信装置によって実行される方法であって、
基地局から、前記基地局及び通信デバイスを含む通信コネクションに関連するコンテキストを受信し、
前記受信されたコンテキストを保持し、
前記通信コネクションが再開されるべきでることを示し且つ前記保持されたコンテキストを識別する情報を受信し、
前記情報を受信したときに、前記保持されたコンテキストを取得し、前記コンテキストの当初の受信元である前記基地局及び他の基地局のうちの１つに向けた、前記取得されたコンテキストの転送を開始する、
方法。
【０１６１】
（付記３０）
通信ネットワークのための基地局によって実行される方法であって、
前記基地局によって稼働される通信ネットワークのセルを介する通信コネクションを確立するための要求を、通信デバイスから受信し、
以前に確立された通信コネクションに関連するコンテキストをどこから取得できるかを示す情報を取得し、
前記以前に確立された通信コネクションに関連するコンテキストを取得できないことを判定し、
前記以前に確立された通信コネクションに関連するコンテキストを取得できないという前記判定に応答して、前記以前に確立された通信コネクションを再開できないことを示すメッセージを、前記通信デバイスへ送信する、
方法。
【０１６２】
（付記３１）
付記２６から３０のいずれか１項に記載の方法をプログラマブルコンピュータデバイスに実行させる、コンピュータに実装可能な命令群を含む、コンピュータプログラムプロダクト。
【０１６３】
この出願は、２０１６年１月１１日に出願された英国出願１６００４７４．９及び２０１６年１月１５日に出願された英国出願１６００７９１．６を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2019506791.tif 000005
【図２】
2019506791.tif 000006
【図３】
2019506791.tif 000007
【図４】
2019506791.tif 000008
【図５】
2019506791.tif 000009
【図６】
2019506791.tif 000010
【図７】
2019506791.tif 000011
【図８】
2019506791.tif 000012
【図９】
2019506791.tif 000013
【図１０】
2019506791.tif 000014
【図１１】
2019506791.tif 000015
【図１２】
2019506791.tif 000016
【手続補正書】
【提出日】平成30年7月2日(2018.7.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでいる、トランーバと、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得する、コントローラと、
を具備し、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開するように構成されている、
第１基地局。
【請求項２】
請求項１記載の第１基地局であって、
前記再開ＩＤは、前記ＲＲＣコネクションを中断しているタイミングで、前記第２基地局から前記ユーザ機器に対して供給されるＩＤである、
第１基地局。
【請求項３】
請求項１又は２に記載の第１基地局であって、
前記中断手順は、移動管理ノード（ＭＭＥ）とサービングゲートウェイ（Ｓ−ＧＷ）との間のインタラクションを必要とする、
第１基地局。
【請求項４】
請求項１から３のいずれか１項に記載の第１基地局であって、
前記コントローラは、前記ＲＲＣを中断することを決定する、
第１基地局。
【請求項５】
請求項１から４のいずれか１項に記載の第１基地局であって、
前記再開ＩＤは、前記第２基地局のＩＤに基づいて作成される、
第１基地局。
【請求項６】
請求項１から５のいずれか１項に記載の第１基地局であって、
前記トランシーバは、前記第２シグナリングメッセージを受信した後に、前記第２基地局における前記ＵＥコンテキストの開放についての要求を前記第２基地局へ送信する、
第１基地局。
【請求項７】
請求項１から６のいずれか１項に記載の第１基地局であって、
前記ＲＲＣコネクションは、物のインターネット（ＩｏＴ）デバイスのためのコネクションである、
第１基地局。
【請求項８】
第１基地局によって実行される方法であって、
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでおり、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得し、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開する、
方法。
【請求項９】
請求項８記載の方法であって、
前記再開ＩＤは、前記ＲＲＣコネクションを中断しているタイミングで、前記第２基地局から前記ユーザ機器に対して供給されるＩＤである、
方法。
【請求項１０】
ユーザ機器から、中断手順によって中断されているＲＲＣ接続を再開するための無線リソース制御（ＲＲＣ）コネクション再開要求メッセージを受信し、前記ＲＲＣコネクション再開要求メッセージは、前記ＲＲＣコネクションユーザ機器（ＵＥ）に関連するコンテキストを識別する再開ＩＤと前記ＵＥコンテキストを保持している第２基地局を識別するために適した情報とを含んでいる、受信手順と、
前記再開ＩＤを含む第１シグナリングメッセージを前記第２基地局へ送信し、且つ、前記ＵＥコンテキストを含む第２シグナリングメッセージを前記第２基地局から受信することにより、前記再開ＩＤに基づいて、前記ＵＥコンテキストを取得する、取得手順と、
前記ＵＥコンテキストを用いて、前記ユーザ機器との間で前記ＲＲＣコネクションを再開する、再開手順と、
を、第１基地局に実行させる、プログラム。
【国際調査報告】
2019506791.tif 000017
2019506791.tif 000018
2019506791.tif 000019