JP2020120392A - データ伝送のための制御プレーンおよびユーザプレーンの選択 - Google Patents

Abstract

【課題】ＲＡＮおよびＣＮにおけるシグナリング負荷及びスイッチング遅延を最小限に抑えることにより制御プレーンデータ伝送とユーザプレーンデータ伝送との動的切り替えのための解決策を提供する。【解決手段】方法は、制御プレーンＣＩｏＴ（Ｃｅｌｌｕｌａｒ Ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）最適化を用いた第1のデータの送信が行われている場合に、デタッチおよび連続する再アタッチの手順またはＴＡＵ（トラッキングエリア更新）手順を回避する、制御プレーンデータ伝送とユーザプレーンデータ伝送との間での動的切り替えを行う。異なる伝送方式間での切り替えの決定は、データパケットのサイズのような様々な基準またはデータの総量に基づく。【選択図】図９

Description

本発明は、制御プレーンデータ伝送およびユーザプレーンデータ伝送の（再）選択の方法に関する。

下記の略語および用語（違ったように述べられるとき）は、本発明において使用される。

以下の用語は、本発明において使用される。

用語「サービングノード」、「ＭＭＥ／ＳＧＳＮ」、「ＭＳＣ／ＳＧＳＮ／ＭＭＥ」、またはＣ−ＳＧＮ（ＣＩｏＴサービングゲートウェイノード）は、一般に、本発明の様々な実施形態を通じて使用され、コアネットワークと端末との間の制御プレーンシグナリング（ＮＡＳシグナリングとして知られる）の終端であるモバイルネットワークにおいて、ＭＳＣなどの機能エンティティ、ＳＧＳＮまたはＭＭＥ、あるいはＣ−ＳＧＮその他の可能な制御プレーン機能エンティティを表す。サービングノード（ＭＭＥ／ＳＧＳＮ）は、モビリティおよびセッション管理を担う次世代ネットワークでの機能エンティティでもあり得る。

用語「ＨＳＳ／ＨＬＲ」は、ＵＥの加入者データが格納されるリポジトリを意味し、ＨＳＳ、ＨＬＲ、またはコンバインド(combined)エンティティのいずれかであり得る。

用語「端末」、「デバイス」、あるいは「ユーザ端末」または「ＵＥ」（ユーザ機器）または「ＭＴ」（移動体端末）は、これらの用語のすべてがネットワーク、モバイルネットワーク、または無線アクセスネットワークとデータおよびシグナリングを送受信するために使用される機器を同様に表すような相互交換可能な方法で使用される。

近年、モノのインターネット（ＩｏＴ）技術およびマシンツーマシン（Ｍ２Ｍ）技術の普及により、第３世代パートナーシッププロジェクト（３ＧＰＰ）のような標準化団体は、リリース１０から、マシンタイプ通信（ＭＴＣ）として知られる改善に取り組み始めた。エンドデバイスの価格や、そのようなデバイスを提供するための事業者のネットワークにおける価格をより一層下げるために、３ＧＰＰはセルラＩｏＴ（ＣＩｏＴ）と呼ばれる研究を行った。この研究では、超低複雑度で、電力が制約され、低データ転送速度であるＩｏＴデバイスをサポートするための、アーキテクチャ拡張が検討され評価された。この研究を文書化したものは、３ＧＰＰ ＴＲ２３．７２０という文書に取り込まれている。結論は、１）必須の制御プレーン（ＣＰ）解決策（ＴＲのセクション２に記載）を指定し、２）ユーザプレーン（ＵＰ）解決策（ＴＲのセクション１８に記載）を任意で指定することである。したがって、ＣＰ解決策は「ソリューション２」とも呼ばれ、ＵＰ解決策は「ソリューション１８」とも呼ばれる。

ＣＩｏＴ向けに最適化されたＥＰＳは、通常のＵＥとは異なるトラフィックパターンをサポートし、既存のＥＰＳと比べると一部のかつ必要な機能だけをサポートするだろう。単一の論理エンティティＣ−ＳＧＮ（ＣＩｏＴ Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ Ｎｏｄｅ）に機能の一部を実装することにより、ＣＩｏＴ向けに最適化されたＥＰＳを有効にすることができる。モビリティ手順およびアタッチ手順は、対応するエンティティＭＭＥ、Ｓ−ＧＷ、およびＰ−ＧＷ用の他の節に記載されるように実行される。単一ノード非ローミングＣＩｏＴアーキテクチャの例を図１に示す。レファレンスポイント（インタフェース）の詳細な説明は、仕様３ＧＰＰ ＴＳ２３．４０１および３ＧＰＰ ＴＳ２３．６８２にある。

ＣＰ解決策かＵＰ解決策かの選択は、アタッチ手順中またはＴＡＵ手順中に行われる。ＵＥは、下記を含む「優先ネットワーク動作」を指示する。
制御プレーンＣＩｏＴ ＥＰＳ最適化がサポートされているか
ユーザプレーンＣＩｏＴ ＥＰＳ最適化がサポートされているか
制御プレーンＣＩｏＴ ＥＰＳ最適化が望ましいか、それともユーザプレーンＣＩｏＴ ＥＰＳ最適化が望ましいか
Ｓ１−Ｕデータ転送がサポートされているか
コンバインドアタッチ(Combined Attach)無しのＳＭＳ転送が要求されているか
ＰＤＮ接続無しのアタッチがサポートされているか
サービングノードは、アタッチまたはＴＡＵ受諾メッセージにて「サポートされたネットワーク動作」情報を送信する。

ＣＩｏＴ ＥＰＳ最適化において、ＵＥは「ＰＤＮ接続無しの受諾」をサポートすることができる。このことは、ＰＤＮ接続が無いためにＥＰＳベアラがアタッチ手順中に確立されないことを意味する。ＵＥは、ＮＡＳ （Ｅ）ＳＭシグナリングを使用して、後の時点でＰＤＮ接続（ＩＰまたは非ＩＰ）を要求することができる。

サービングノードが、ＣＰ ＣＩｏＴ ＥＰＳ最適化を使えるよう構成している場合、データは、ＵＥとサービングノードとの間において、それらが関係するＰＤＮ接続のＥＰＳベアラアイデンティティを含むＮＡＳ ＰＤＵで転送される。ＩＰデータタイプと非ＩＰデータタイプの両方がサポートされる。これは、ＲＲＣプロトコルおよびＳ１−ＡＰプロトコルのＮＡＳトランスポート機能、ならびに、ＭＭＥとＳ−ＧＷ間およびＳ−ＧＷとＰ−ＧＷ間のＧＴＰ−ｕトンネルのデータ転送を使用することによって達成される。非ＩＰ接続がＳＣＥＦとともにＭＭＥを介して提供される場合、データ転送はＴＳ２３．６８２に示されるように行われる。

図２は、制御プレーンＣＩｏＴ ＥＰＳ最適化（すなわち、ＣＰ解決策）のためのモバイル発信（ＭＯ）データ伝送のシグナリングフローを示す。この図は、ＴＳ２３．４０１に従う。ユーザデータ転送にＣＰ解決策を使用する場合、ＭＭＥ（上り（ＵＬ）用）およびＵＥ（下り（ＤＬ）用）は、ＮＡＳ ＰＤＵ内に含まれるＥＰＳベアラアイデンティティ（ＥＢＩ）を使用して、関連するＥＰＳベアラを識別する。

ＭＭＥがモバイル着信（ＭＴ）サービスにＣＰ解決策を使用することを望む場合、ＴＳ２３．４０１からの図３に手順例が示される。

ＵＥとＳ／ＰＧＷとの間の通信に関わる異なるプロトコルを表現するために、様々なインタフェースを介したプロトコルスタックを図４に示す。この図がＣＰ ＣＩｏＴ最適化のためのプロトコルスタックを示すことに留意されたい。ＣＩｏＴ ＥＰＳ最適化によって導入される１つの主な変更は、Ｓ１１インタフェースを介した、すなわちＭＭＥとＳＧＷとの間のＧＴＰ−Ｕインタフェースのサポートである。

必須として同意されたＣＰデータ伝送に加えて、ＵＰデータ伝送を使用することも任意選択で可能である。ここで、主な特徴は、ＵＥのＡＳコンテキストをｅＮＢに格納するためのＲＲＣ中止手順にある。この手順を図５に示す。これはＴＳ２３．４０１セクション５．３．４Ａのとおりである。さらに、ＴＳ２３．４０１セクション５．３．５Ａでは、接続再開手順が説明されている。

ＣＩｏＴ ＥＰＳ最適化は、ＬＴＥ（ＥＵＴＲＡＮ）システムにも適用できる。特に、１つの目的は、低コスト特性を有する広帯域（ＷＢ）ＥＵＴＲＡＮ ＵＥ（例えば、ｃａｔ−Ｍ）をカバーすることである。しかし、ＮＢ−ＩｏＴの可能なＷＢ ＥＵＴＲＡＮ ＵＥがＮＢ−ＩｏＴ解決策（ＣＰまたはＵＰ解決策）を使用する場合、ＲＡＴを変更する際にいくつかの制約がある。例えば、ＵＥが非ＩＰ接続をアクティベートした場合、ＵＥは２Ｇ／３Ｇアクセスを再選択せず、非ＩＰ接続の使用を続ける。

ＳＣＥＦによる非ＩＰデータ配信（ＮＩＤＤ）は、現在３ＧＰＰ Ｔｄｏｃ Ｓ２−１６０８３２（ＴＳ２３．６８２にて実現される必要がある）が手順を示しているが、３ＧＰＰ ＴＳ２３．６８２に保存されるだろう。ＮＩＤＤは、ＵＥとのモバイル発信（ＭＯ）およびモバイル着信（ＭＴ）の通信を処理するために使用され、通信に使用されるパケットはインターネットプロトコル（ＩＰ）に基づかない。非ＩＰデータの配信のためのＳＣＥＦの構成は、図６の説明に示されており、詳細な説明は、３ＧＰＰＴｄｏｃ Ｓ２−１６０８３２にある。

例として、図７は、ＳＣＳ／ＡＳが外部識別子またはＭＳＩＳＤＮを用いて識別されるような所与のユーザに非ＩＰデータを送信するための手順を示す。この手順では、非ＩＰデータ用のＥＰＳベアラの確立手順とＳＣＥＦ構成手順（図６参照）が完了していることを前提とする。

３ＧＰＰ ＴＳ２３．４０１ ｖ１４４．０、進化型ユニバーサル地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）アクセスのための汎用パケット無線サービス（ＧＰＲＳ）の強化；ステージ２、ｖ１３．５．０、２０１５−１２ ３ＧＰＰ ＴＲ２３．７２０、ＣＩｏＴのためのアーキテクチャ強化、ｖ１．２．９、２０１５−１１ ３ＧＰＰ ＴＳ２３．２０３、ポリシーおよび課金制御アーキテクチャ、ｖ１３．５．１、２０１５−０９.

問題の説明
上述の背景によれば、ＣＰ解決策およびＵＰ解決策の選択は、アタッチ手順またはＴＡＵ手順中に起こり得る。ここでは、伝送方式の選択について説明するが、どのようにして再選択が達成されるかについては説明しない。伝送メカニズムの再選択は、例えば、ＣＰ伝送による大量のデータが非効率的であるためにデータサイズを変更する場合に起こり得る。

データのＣＰ伝送とＵＰ伝送とを動的に切り替えることは、現在は不可能である。 ＣＩｏＴ ＥＰＳ最適化をサポートするスマートフォンの場合に、さらにＣＰ ＮＢ−ＩｏＴデータ伝送とＷＢ−ＥＵＴＲＡＮ伝送との間の動的選択が提供される必要がある。

ＣＰデータ伝送かＵＰデータ伝送かの再選択がアタッチ手順を用いて行われると想定すると、問題となるのは、アタッチ手順が明示的なシグナリングと認証とを必要とするということである。これにより、（１）ＲＡＮとＣＮにおけるシグナリング負荷と（２）ＣＰとＵＰを切り替えるための遅延とが増大し得る。このことはユーザーエクスペリエンスに影響を与える可能性がある。

本発明の目的は、（１）ＲＡＮおよびＣＮにおけるシグナリング負荷および（２）スイッチング遅延を最小限に抑えることによりＣＰ伝送とＵＰ伝送との動的切り替えのための解決策を提供することである。加えて、本発明では、動的切り替えが失敗する場合についても説明する。

スマートフォン（ＷＢ−ＥＵＴＲＡＮおよびＣＩｏＴ最適化が可能）が、現在ＷＢ−ＥＵＴＲＡＮ解決策で設定されている場合、ケースによっては、ＣＰを用いるデータ伝送を使用することが望ましいことがある（例えば、ＭＴ−ＳＭＳまたはＭＴ−ＮＩＤＤ配信の場合）。どのようにして効率的にそれを達成するかは、現在明確ではない。いくつかの（無線の）制限のために、ＭＭＥやＵＥは、ＮＢ−ＩｏＴ解決策のみを適用することを決定できる。

１つの態様において、本発明は、制御プレーンＣＩｏＴ（Ｃｅｌｌｕｌａｒ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ） ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）最適化を用いてデータを送信する手段と、データのデータサイズに基づいて、データがユーザプレーンで送信されるかどうかを決定する手段と、ユーザ装置コンテキストセットアップリクエストメッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を無線アクセスネットワークノードへ送信する手段と、前記無線アクセスネットワークノードが無線ベアラを移動体端末に設定する際に、ユーザ装置コンテキストセットアップ完了メッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）を前記無線アクセスネットワークノードから受信する手段と、前記移動体端末とパケットデータネットワーク（ＰＤＮ）ゲートウェイ（Ｐ−ＧＷ）との間のＰＤＮコネクション用の、サービングゲートウェイ（Ｓ−ＧＷ）への認容されたベアラのためのトンネルエンドポイント識別子（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＴＥＩＤ））を含むリソース変更要求メッセージ（ｍｏｄｉｆｙ ｒｅｓｏｕｒｃｅｓ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を送信する手段と、を備えるコアネットワークノードを提供する。

１つの態様において、本発明は、制御プレーンＣＩｏＴ（Ｃｅｌｌｕｌａｒ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ） ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）最適化を用いてデータを送信し、データのデータサイズに基づいて、データがユーザプレーンで送信されるかどうかを決定し、ユーザ装置コンテキストセットアップリクエストメッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を無線アクセスネットワークノードへ送信し、前記無線アクセスネットワークノードが無線ベアラを移動体端末に設定する際に、ユーザ装置コンテキストセットアップ完了メッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）を前記無線アクセスネットワークノードから受信し、前記移動体端末とパケットデータネットワーク（ＰＤＮ）ゲートウェイ（Ｐ−ＧＷ）との間のＰＤＮコネクション用の、サービングゲートウェイ（Ｓ−ＧＷ）への認容されたベアラのためのトンネルエンドポイント識別子（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＴＥＩＤ））を含むリソース変更要求メッセージ（ｍｏｄｉｆｙ ｒｅｓｏｕｒｃｅｓ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を送信する、通信制御方法を提供する。

１つの態様において、本発明は、ユーザプレーンＣＩｏＴ（Ｃｅｌｌｕｌａｒ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ） ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）最適化がサポートされているか否かを示すユーザプレーンＣＩｏＴ指示子（ｉｎｄｉｃａｔｉｏｎ）を含むユーザ装置コンテキストセットアップリクエストメッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）をコアネットワークノードから受信する手段と、移動体端末に無線ベアラを設定する手段と、前記コアネットワークノードにユーザ端末コンテキストセットアップ完了メッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）を送信する手段と、を備える無線アクセスネットワークノードを提供する。

１つの態様において、本発明は、ユーザプレーンＣＩｏＴ（Ｃｅｌｌｕｌａｒ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ） ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）最適化がサポートされているか否かを示すユーザプレーンＣＩｏＴ指示子（ｉｎｄｉｃａｔｉｏｎ）を含むユーザ装置コンテキストセットアップリクエストメッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）をコアネットワークノードから受信し、移動体端末に無線ベアラを設定し、前記コアネットワークノードにユーザ端末コンテキストセットアップ完了メッセージ（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｃｏｍｐｌｅｔｅ ｍｅｓｓａｇｅ）を送信する、通信方法を提供する。

（１）過大なＰＤＵサイズがＥＰＣに届くことによる誤った処理を回避または低減することができる（例えば、解決策１および解決策２）。
（２）制限されたＮＢ−ＩｏＴ制御プレーン帯域幅（例えば、ＲＡＮノード内）における過負荷を、ＣＰ伝送からＵＰ伝送への切り替えによって克服または緩和することができる。

図１は、シングルノード非ローミングＣＩｏＴアーキテクチャの例を示す。 図２は、制御プレーンＣＩｏＴ ＥＰＳ最適化（すなわち、ＣＰ解決策）用のモバイル発信（ＭＯ）データ伝送のシグナリングフローを示す。 図３は、ＮＡＳ ＰＤＵでのＭＴデータ転送用のシグナリングフローを示す。 図４は、ＵＥとＰＧＷとの間のプロトコルスタックを示す。 図５は、ｅＮｏｄｅＢが開始した接続停止手順を示す。 図６は、ＮＩＤＤ手順用のＳＣＥＦの場合の構成を示す。 図７は、ＳＣＳ／ＡＳが非ＩＰデータを外部識別子またはＭＳＩＳＤＮを用いて識別されるような所定のユーザに送信する際の手順を示す。 図８は、静的に設定されたデータサイズのシグナリングフローの例を示す。 図９は、大量のＤＬデータが届く、ＵＥがアイドルモードにあり制御プレーンＣＩｏＴデータ転送のためにアタッチされる場合の、ＣＰ ＣＩｏＴからＵＰ（ＣＩｏＴまたはフルＬＴＥ）への切り替えを示す。 図１０は、大量のＤＬ非ＩＰデータが届き、ＵＥがＳＣＥＦを介して制御プレーンＣＩｏＴデータ転送のためにアタッチされる場合の、制御プレーンＣＩｏＴからユーザプレーン（ＣＩｏＴまたはフルＬＴＥ）への切り替えを示す。 図１１は、ＭＴ通信のシグナリングフローを示す。 図１２は、ＵＥのブロック図を示す。 図１３は、ＲＡＮノードのブロック図を示す。 図１４は、サービングノードのブロック図を示す。

上述の問題を解決するために、様々な解決策が本明細書の様々な実施形態で説明される。

本発明における１つの解決策の考え方は、効率的な伝送方式に関する決定、すなわちＣＰを用いるかＵＰを用いるかの決定を、ＭＭＥが実行できるようにすることである。ＭＭＥにおける決定は、（１）伝送データのサイズ（または以下に列挙される他のデータ制限基準）に基づいて、あるいは（２）ＵＥが経験した無線条件に基づくことができる。

本発明における１つの解決策（解決策１）では、ＭＭＥがＰＧＷ／ＳＣＥＦおよびＡＳに、ＥＰＣまたはＲＡＮが処理できる最大パケットサイズを通知する。これは、静的に設定された最大データサイズに基づく。Ｃプレーン解決策が選択されると、ＭＭＥはそれをＰＧＷ／ＳＣＥＦおよびＡＳに通知する。

図８は解決策１の場合のシグナリングフローを示す。

新しいパラメータ：
ＨＳＳは、サブスクリプションデータ「処理指示子」を有する。このパラメータは、Ｃプレーン解決策が対応できるＰＤＵの最大サイズを超える大きなサイズのＤＬパケットがＥＰＣに届いた時のＮＷ動作を指示する。パラメータは、下記の値を持たなければならない。
破棄、または
できるだけ多くのデータを転送
‐ＭＭＥは、ＧＴＰ−Ｃメッセージによって「ＰＤＵの最大サイズ」という新しいパラメータを送信する。このパラメータは、ＮＡＳが処理可能なＰＤＵがどれだけ大量のデータであるかというＮＡＳ機能に基づいて設定される。例えば、複数のＲＲＣ処理がサポートされていない場合、この値は約１５００バイトでなければならない。「ＰＤＵの最大サイズ」という情報は、ＰＤＵ自体の最大サイズまたは「ＰＤＵの最大サイズ」を示すいくつかのビットとして表されうる。いくつかのビットが「ＰＤＵの最大サイズ」を示すために、ＭＭＥ／ＳＧＷ／ＳＣＥＦは、０：１０００バイト、１：１５００バイトなどを示す共通テーブルを有する。
‐ＰＧＷは、新しいパラメータ「処理指示子確認応答」を送信する。このパラメータは、「ＰＤＵの最大サイズ」と「処理指示子」の両方がＰＧＷによって理解され、示された実施が可能か否かを示す。

ＰＧＷは、ＭＭＥからの命令に基づいてＤＬ ＰＤＵパケットを処理する。
条件が合致する場合、すなわち、ＤＬパケットサイズがＣプレーン解決策の対応可能なＰＤＵの最大サイズを超える場合、処理指示子に基づいて実施する。例えば、単にＤＬパケットを破棄してＯ＆Ｍシステムに報告する。
解決策１の利点は、このアプローチでは、不要なユーザートラフィックがＥＰＣに届くことである。

同様に、非ＩＰ接続が確立されている場合、ＭＭＥはＳＣＥＦおよび/またはＡＳに通知することができる。ＳＣＥＦは新しいパラメータ「ＰＤＵの最大サイズ」をＡＳに送信する。ＡＳは、新しいパラメータ「処理指示子」を送信する。このパラメータは、大きなサイズのＤＬパケットまたはＵＬパケットがＥＰＣに届いた時のＮＷの動作を指示する。
ＡＳの動作：ＡＳは、「ＰＤＵの最大サイズ」に基づいて、示されたサイズよりも大きいＰＤＵを送信しない。

解決策１は下記の利点をもたらす。すなわち、過大なＰＤＵサイズがＥＰＣに届くことによる誤った処理を回避することができる。

要するに、Ｃプレーン解決策が選択されると、ＭＭＥはＰＧＷ／ＳＣＥＦおよびＡＳにその旨を通知する。

代替案：
「ＰＤＵの最大サイズ」を下記の情報の少なくとも１つと交換することができる。
ａ）ＵＥが受信する総データ量
ｂ）最大スループットまたはデータレート（特定の期間（例えば、秒／時間／日／週）あたり）
ｃ）最大伝送回数（特定の期間（例えば、秒／時間／日／週）あたり）
ｄ）ＵＥが受信する総データ量が閾値を上回る／下回るかを示すフラグ
また、代替情報として、ａ）〜ｄ）の中から２つ以上のパラメータとともに交換することができる。

装置が黙示的な「処理指示子」を有する場合、または「処理指示子」が他のメッセージにおいて交換される場合、セッション開始要求／応答は必ずしも「処理指示子」を含まなくてもよい。

上述の問題に対する他の解決策（解決策２と呼ぶ）は、（１）ＮＢ−ＩｏＴ ＣＰまたはＵＰ解決策、あるいは（２）ＮＢ−ＩｏＴ解決策およびＷＢ−ＥＵＴＲＡＮ解決策を、ネットワーク内、好ましくはサービングノード内で異なる基準に基づいて動的に再選択することである。例えば、１つの基準は、大きなパケットサイズまたは大量のデータ（例えば、複数のデータセグメント／パケットに分散されている）に起因しうる。

ＵＥがＣプレーンを用いてＣＩｏＴのためにアタッチされている際、あるいはＵＥがＣプレーン解決策をアクティベートさせた際に、大きなサイズのパケット（ＩＰおよび非ＩＰ）を処理する必要がある場合、ＵＥ／ＭＭＥは、ネットワーク設定をユーザプレーン（ＵＰ）解決策に変換する。

ＣＰまたはＵＰの選択の決定は、ＵＬにおいて送信される大量のデータに関するＵＥからの指示にも基づく。ＵＥからネットワークへの指示は、例えば、以下のとおりである。
ＭＯの場合、ＵＥは、サービス要求手順や他のＮＡＳまたはＲＲＣシグナリングメッセージなどにてＭＭＥに示すことができる。
ＵＥが既に接続済み状態またはアクティブ状態にある場合、ＵＥはそれを決定する。
ＭＴの場合、ＭＭＥは、アイドル−＞接続済み遷移中にＤＲＢ確立のためにＡＳコンテキストをｅＮＢに送信する。
例えば、ＵＥは、上記のケースにおいてＵプレーン解決策（またはＷＢ−ＥＵＴＲＡＮ）の要求を示すことができる。

ＭＯ通信において、大量データの送信が予想されることをＵＥが分かっている場合、ＵＥは以下の解決策のうちの１つを実行することができる。
‐ＵＥはデタッチ手順を開始し、再度アタッチする。アタッチ要求メッセージにおいて、ＵＥは、予想される大量データに基づいて異なるＣＰ優先およびＵＰ優先を指示する。例えば、ＵＥは、大量データを伝送するために、ＵＰ解決策優先を示すことができる。
‐デタッチ手順およびアタッチ手順中のシグナリングの増加を回避するために、代替解決策では、ＵＥはＰＤＮ接続の解放と再確立を開始することができる。ＰＤＮ接続再確立の間、ＵＥは、サービングノードに対して、ａ）大量データが予想される、またはｂ）ＵＰ解決策優先を示すことができる。
‐複数のＰＤＮ接続を有する場合、ＵＥは、ＵＥが要求したＣＩｏＴ接続のためのＰＤＮ切断手順を開始し、次にＵＥは、ＵＥが要求したＵプレーン解決策を用いたＰＤＮ接続手順を開始する。

解決策２の別の態様は、通常少量のデータしか送信しないアプリケーションもあれば、通常大量のデータを送信するアプリケーションもあるので、ＭＭＥがアプリケーション識別子（Ａｐｐ ＩＤ）に基づいてＵＰ解決策を起動するかどうかを決定できるというものである。アプリケーションは、例えば、ＴＤＦやＰＧＷ／ＳＣＥＦといったネットワーク入口点(Network ingress point)でのディープパケットインスペクション（ＤＰＩ）によって検出可能である。その後、ＰＧＷは、ＳＧＷおよびＭＭＥへのシグナリングにＡｐｐ ＩＤを含めるので、ＭＭＥは、その後のデータに対してＣＰ伝送またはＵＰ伝送を適用するかを決定できる。

一般に、解決策２は、ＵＥがネットワークにアタッチされ、ＣＩｏＴ最適化のための制御プレーン解決策（すなわち、制御プレーンを介したデータ転送）が設定されているときに、大きなサイズのデータを処理する必要がある（例えば下りにて）というユースケースに対処する。制御プレーンを介したデータ転送が効率的でない、もしくは全く不可能であるため、制御プレーンＣＩｏＴ最適化（すなわち、制御プレーンＣＰを介した伝送）からユーザプレーンＣＩｏＴ最適化（すなわち、ユーザプレーンＵＰを介した伝送）に、あるいは、ＵＥがＬＴＥ（ＷＢ−ＵＴＲＡＮ）機能を有する場合はフルＬＴＥユーザプレーンに動的に切り替えることが提案される。

解決策２．１
ＵＥがアタッチされ制御プレーン伝送によるＣＩｏＴが設定されている間における、大量の非ＩＰまたはＩＰデータ配信のための、制御プレーンＣＩｏＴからユーザプレーン（ＣＩｏＴまたはフルＬＴＥ）への切り替え。大量の非ＩＰまたはＩＰデータが、Ｐ−ＧＷで終端されたＰＤＮ接続を介して伝送されると仮定する。

図９は、大量のＤＬデータが届き、ＵＥがアイドルモードであって制御プレーンＣＩｏＴデータ転送のためにアタッチされた時の、ＣＰ ＣＩｏＴからＵＰ（ＣＩｏＴまたはフルＬＴＥ）への切り替えを示す。

図９に示すステップを以下のように詳細に説明する。
１．ＣＩｏＴ可能なＵＥ（ＣＩｏＴ機能を有するＬＴＥ ＵＥ、またはＣＩｏＴ専用ＵＥ）はアタッチされ、制御プレーンＣＩｏＴ最適化がデータ伝送のために設定されている。
２．下りデータが、Ｐ−ＧＷ機能エンティティに届く。あるいは、ＴＤＦが配備されている場合、ＤＬデータはＴＤＦ、つまりこの機能エンティティで処理することができる。
３．Ｐ−ＧＷ（またはＴＤＦ）は、ＤＰＩ（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）を実行し、データの発信元（例えば、「Ａｐｐ ＩＤ」によって識別される発信元アプリケーション）を識別することができる。Ｐ−ＧＷは、ＤＬパケットをＳ−ＧＷに転送する。「Ａｐｐ ＩＤ」は、ＤＬパケットのＧＴＰ−Ｕヘッダに含めることができるし、あるいは、ＰＧＷとＳＧＷとの間のＧＴＰ−Ｃプロトコル交換に含めることができる。
４．Ｓ−ＧＷはＤＬパケットをバッファに格納し、可能な場合は、受信データサイズおよび送信者Ａｐｐ ＩＤを含めて、ＭＭＥに下りデータ通知を送信する。
５．ＭＭＥは、ＣＰ伝送またはＵＰ伝送が適用可能であるかを判断するために受信したＤＤＮ要求を精査する。この目的のために、ＭＭＥはデータサイズをチェックして、制御プレーンを介したＤＬデータ配信を継続するか、あるいは、受信した下りデータが大量でありユーザプレーンを介して送信するほうが効率的である場合に利用可能なユーザプレーン（最適化されたＣＩｏＴユーザプレーンまたはＬＴＥユーザプレーン）のうちの１つに切り替えるか、を評価する。また、ＭＭＥは、どの配信オプションを使用すべきか、すなわちＣＰとＵＰのどちらを使用すべきかを決定する際に、利用可能であれば、ＤＬデータの起点（例えば、Ａｐｐ ＩＤ）を考慮してもよい。
６．ＭＭＥは、Ｓ−ＧＷに対してＤＤＮ確認応答でＵＥの呼び出しを確認応答する。
７．ＵＥがアイドルモードである場合、ＭＭＥはＵＥを呼び出して、ＵＥにサービス要求手順を実行させる。
８．ＭＭＥが（ステップ５におけるＤＬデータ評価に基づいて）ＵＰデータ伝送を適用すると決定した場合、ＭＭＥは、Ｓ１−ＡＰ初期コンテキストセットアップ要求メッセージをＲＡＮノードに送信する。このステップは、データ無線ベアラ（ＤＲＢ）をアクティベートする。ＭＭＥは、（ＮＢ−ＩｏＴ ＲＡＴの場合）ＵＰ ＣＩｏＴ使用のセットアップを明示的に指示するために、ＲＡＮノードへの初期コンテキストセットアップ要求メッセージに「ユーザプレーンＣＩｏＴ」指示を含めることができる。
９．ＲＡＮノード（例えば、ｅＮＢ）は、ＲＲＣ接続再構成手順によって無線ベアラ確立を実行する。ＲＡＮノードはまた、ＲＲＣ接続再構成要求メッセージにおいて最適化されたＣＩｏＴユーザプレーンに対する優先をＵＥに示してもよい。
１０．データ無線ベアラがセットアップされると、ＲＡＮノードは、Ｓ１−ＡＰメッセージ初期コンテキストセットアップ完了をＭＭＥに送信する。
注：初期コンテキストセットアップ手順が失敗した場合、あるいは、ＵＥがステップ７で呼び出し手順の呼び出しに応答しない場合、ＭＭＥは下りデータ通知失敗指示メッセージをＳＧＷに送信する。下りデータ通知失敗指示メッセージは、失敗の理由を示す新しい原因値を含むものとする。例えば、データサイズが制限値を超えている、制御プレーンからユーザプレーンへの切り替えが失敗する、など。
１１．ＭＭＥは、受諾されたＥＰＳベアラのＴＥＩＤを含むベアラ変更要求メッセージをＳ−ＧＷに送信し、Ｐ−ＧＷは、ベアラ変更応答で確認する。
１２．こうして、ユーザプレーン（最適化されたＣＩｏＴまたはフルＬＴＥ）が確立され、ＤＬデータを確立されたユーザプレーンを介してＵＥに配信することが可能になる。

解決策２．２
ＵＥがアイドルモードであって制御プレーンを用いたＣＩｏＴ最適化が設定されている間の大量の非ＩＰデータ配信のための制御プレーンＣＩｏＴからユーザプレーンＣＩｏＴへの切り替え

図１０は、大量のＤＬ非ＩＰデータが届いてＵＥがＳＣＥＦを介して制御プレーンＣＩｏＴデータ転送のためにアタッチされた時の、制御プレーンＣＩｏＴからユーザプレーン（ＣＩｏＴまたはフルＬＴＥ）への切り替えを示す。

図１０に示すステップを以下のように詳細に説明する。
１．ＣＩｏＴ可能なＵＥ（ＣＩｏＴ機能を有するＬＴＥ ＵＥ、またはＣＩｏＴ専用ＵＥ）は、制御プレーンＣＩｏＴ最適化のためにアタッチされ、アイドルモードである。
２．非ＩＰデータ配信要求がＳＣＥＦで受信される。
３．非ＩＰデータ要求がＳＣＥＦによって承認される。ＳＣＥＦは、非ＩＰデータのサイズをチェックして、ＵＥへの配信のために非ＩＰデータサイズと非ＩＰデータ自体とをＭＭＥに提示する。
注：非ＩＰデータサイズをＳＣＳ／ＡＳからのＮＩＤＤ配信要求に含めることが可能である。
４．ＭＭＥは、非ＩＰデータサイズが制御プレーンを用いた少量データ伝送の制限内であるか否かを評価する。受信した下りデータが大量であり、ユーザプレーンを介してそのデータを送信する方が効率的である場合、ＵＥによってサポートされるならば、ＭＭＥはＣＩｏＴ最適化されたユーザプレーンまたはＬＴＥユーザプレーンを確立すると決定してもよい。
５．ＵＥがアイドルモードである場合、ＭＭＥはＵＥを呼び出し、ＵＥはサービス要求を返す。
６．ＭＭＥは、Ｓ１−ＡＰ初期コンテキストセットアップ要求メッセージをＲＡＮノード（例えば、ｅＮＢ）に送信する。ＭＭＥは、ｅＮＢとＭＭＥとの間でＳ１ユーザプレーンが確立されるように、ＭＭＥによって割り当てられるＳ１ユーザプレーンＴＥＩＤを含める。このステップにより、無線ベアラおよびＳ１ベアラはアクティベートされる。ＭＭＥが（ステップ５のＤＬデータ評価に基づいて）最適化されたＣＩｏＴユーザプレーンを介してＤＬデータを配信すると決定した場合、ＭＭＥは、ＣＩｏＴ最適化ユーザプレーンタイプ配信の優先（または要求）を示すために、「ユーザプレーンＣＩｏＴ」指示子を含める。
７．ＲＡＮノードは、ＲＲＣ接続再構成手順を用いて無線ベアラ確立を実行する。ＲＡＮノード（例えば、ｅＮＢ）は、ＲＲＣ接続再構成要求メッセージにおいて、最適化されたＣＩｏＴユーザプレーンを優先することをＵＥに示してもよい。
８．ユーザプレーン無線ベアラがセットアップされると、ＲＡＮノードは、ＭＭＥにＳ１−ＡＰメッセージ初期コンテキストセットアップ完了を送信する。ＭＭＥは、Ｓ１ユーザプレーンがＭＭＥとｅＮＢとの間に確立されると、ベアラ変更要求メッセージをＳ−ＧＷに送信しない。初期コンテキストセットアップ手順が失敗した場合、またはＵＥがステップ５で呼び出し手順に対する呼び出しに応答しない場合、ＭＭＥはＮＩＤＤ配信失敗指示メッセージをＳＣＥＦに送信する。ＮＩＤＤ配信失敗指示メッセージは、失敗の理由を示す新しい原因値を含むものとする。例えば、データサイズが限界を超えた、制御プレーンからユーザプレーンへの動的切り替えが失敗した、ＵＥを呼び出すことができない、コンテキストが見つからない、中断(Suspension)によりＵＥを呼び出すことができない、ＵＥが既に再アタッチされている、ハンドオーバ／ＴＡＵ／ＲＡＵ手順が進行中のため一時的に拒否されている、ＵＥが応答していない、サービスが拒否されている、ＵＥが既に再度アタッチされている、などである。ＳＣＥＦがＭＭＥからＮＩＤＤ配信失敗指示メッセージを受信した場合、ＳＣＥＦは、ＳＣＳ／ＡＳが配信失敗に対する適切な処置を取るために、ＮＩＤＤ配信失敗指示メッセージを新しい原因値をもってＳＣＳ／ＡＳに送信する。新しい原因値とは、例えば、データサイズを超えた場合、制御プレーンからユーザプレーンへの動的切り替えが失敗する、ＵＥを呼び出すことができない、コンテキストが見つからない、中断(Suspension)によりＵＥを呼び出すことができない、ＵＥが既に再接続されている、ハンドオーバ／ＴＡＵ／ＲＡＵ手順が進行中のため一時的に拒否されている、ＵＥが応答していない、サービスが拒否されている、ＵＥが既に再接続しているなど。
９．こうして、ユーザプレーン（最適化されたＣＩｏＴまたはフルＬＴＥ）が確立され、ＤＬデータをＵＥに配信することができる。

解決策２．１および２．２では、下記の代替情報のうちの少なくとも１つを、データサイズ（または非ＩＰデータサイズ）と交換できる。
ａ）最大スループットまたはデータレート（特定の期間（例えば、秒／時間／日／週）あたり）
ｂ）最大伝送回数（特定の期間（例えば、秒／時間／日／週）あたり）
ｃ）ＵＥが受信する総データ量が閾値を上回る／下回るかどうかを示すフラグ。
また、代替情報として、ａ）〜ｃ）のうちの２つ以上のパラメータと交換することができる。

上記の解決策２．１および２．２は、ＤＬデータがＭＭＥに届いた時にＵＥがアイドル状態にあると仮定する。さらに、他の解決策２．３を以下に説明する。この解決策では、ＤＬデータがＳＧＷまたはＭＭＥに届いた時にＵＥが接続モードにあると仮定する。具体的には、ＣＰ伝送が設定され適用されているものとする。この解決策は、ＵＥが接続モードにある間に無線インタフェース構成（すなわち、無線ベアラ）およびＳ１−Ｕベアラを変更することを提案する。

図１１に示すステップを以下のように詳細に説明する。
１．ＵＥが接続状態である間、ユーザプレーンノードの１つ（ＲＡＮノード、ＰＧＷ、ＳＧＷのうちのいずれか）が、データサイズまたはデータ量が閾値を超えて増加していること、あるいは新しいアプリケーションがデータ伝送を開始したことを検出することができる。そのような検出にしたがって、ＳＧＷ／ＰＧＷまたはＲＡＮノードは、ユーザプレーン上の変化した状況（増加したデータや、新しいアプリケーションなど）についてＭＭＥに通知する。ＭＭＥ自体が、ユーザプレーン機能エンティティからの明示的な指示子を受けとることなく、増加したデータや開始された新しいアプリケーションを検出することも可能である。
例えば、ステップ１．１において、（図示しないが、ＰＧＷによって既に通知された）ＳＧＷが、ＧＴＰ−Ｕヘッダ中にパケット長パラメータを示している、ＧＴＰ−Ｕヘッダ中の新しいデータ／ＰＤＵサイズについてＭＭＥに通知する。あるいは、ＳＧＷが、ＧＴＰ−Ｃメッセージを使用して、新しいデータ量や新しいアプリケーション（例えば、Ａｐｐ ＩＤ）について通知する。あるいは、ステップ１．２において、ＲＡＮノードは、（例えば、特定の閾値を超えるバッファサイズに基づいて）ＳＲＢ１／ＳＲＢ２または制御プレーン上の増加したデータ伝送時間を検出することもできる。これは、限定されないが、制限された制御プレーン伝送帯域幅に好適に適用可能である。例えば、多くのＩｏＴ ＵＥが同時にデータを受信し、ＲＡＮノードの伝送バッファが増大しうることがあり、伝送遅延につながる。データＰＤＵサイズが１．５キロバイト未満であり、ＳＧＷ／ＰＧＷでは大量データとして検出されなかったとしても、ｅＮＢは、このような状況をＭＭＥに示すことが可能である。そのような指示子の１つの例は、ＣＰ伝送チャネル／ベアラが、所与のセル内でサービスされる１つの特定のＵＥまたはすべてのＵＥのために、あるいは、所与のＲＡＮノードによって、過大な負荷をかけられることを意味する「ＣＰ負荷」である。このような検出にしたがって、ＲＡＮノードは、変更されたデータ条件についてＭＭＥに通知する。
２．ＭＭＥは、ユーザプレーン（ＲＡＮノードまたはＳＧＷ／ＰＧＷのいずれか）から更新された情報を受信するか、あるいは、変更された状況を自ら検出した後で、使用されているＣＰ伝送をＵＰ伝送に切り替えるべきかどうかを判断することができる。ＭＭＥは、このようなＣＰ伝送からＵＰ伝送への切り替えが必要であると判断した場合、ＲＡＮノード内のＵＥのコンテキストを変更する手順を、より具体的には、例えば、ＡＳセキュリティのセットアップと可能なＤＲＢの確立を変更する手順を開始する。例えば、Ｓ１−ＡＰベアラ変更手順を使用することができるが、ＲＡＮノードにＤＲＢおよびＡＳセキュリティのアクティベーションを示す新しいパラメータを含めることができる。
３．ＭＭＥからの要求を受信すると、ＲＡＮノード（例えば、ｅＮＢ）は、まだ存在しない場合には、ＡＳセットアップセキュリティセットアップを開始し、ＤＲＢ（ｓ）の確立を開始する。この目的のために、ｅＮＢはＲＲＣ接続再構成手順を使用することができる。
４．ＵＳはＲＲＣ接続再構成を確認する。
５．ＲＡＮノード（ｅＮＢ）は、正常な無線接続の変更についてＭＭＥに応答する。
６．ＭＭＥは、ＳＧＷの再構成を実行する。この目的のために：
ステップ６．１において、ＭＭＥは、例えば、ベアラ変更要求手順を使用して、ｅＮＢのＧＴＰ−Ｕ ＴＥＩＤでＳＧＷを更新することによって、ＳＧＷ ＧＴＰ−Ｕ転送を再構成する。
ステップ６．２において、ＭＭＥは、Ｓ１１インタフェースを介して既存のＧＴＰ−Ｕトンネル状態の解放を開始する。
オプションとして、コンバインドベアラ変更手順およびＧＴＰ−Ｕ解放手順を実行する新しいＳ１１手順を指定してもよい。

図１１のように実行される手順の結果、ＵＬデータおよびＤＬデータは、ユーザプレーン（ＮＢ−ＩｏＴ ＵＰ最適化またはＷＢ−ＥＵＴＲＡＮ ＵＰ伝送のいずれかを含む）を用いて伝送される。

この解決策２．３で、ＵＥが通常のように接続状態にい続けることが可能である一方、大量ＰＤＵ処理が可能である。これにより、例えば、デタッチおよび再アタッチ手順を実行することに比べてシグナリングが低減する。

さらなる実施形態では、接続モードのＵＥが、ＵＥによって経験される悪い無線状態についてＭＭＥに示すことが提案される。例えば、これは、ＵＥがセルエッジに存在する場合（すなわち悪い無線状態、例えばＵＥが地下にある場合）に起こり得る。そのような場合、バッテリ電力を節約して到達可能性を確保するために、ＵＥおよびネットワーク（ＭＭＳ／ＳＧＳＮ）が以前に使用したＵＰ伝送からＣＰ伝送の使用を再選択することが提案される。
この目的のために、ＵＥは、ＮＡＳを介してＭＭＥ／ＳＧＳＮに悪い無線状態のシグナリングを示すことができる。別の代替案では、ＲＡＮノードが悪い無線状態をＭＭＥ／ＳＧＳＮに示すことができる。ＭＭＥ／ＳＧＳＮは、ＵＰ伝送からＣＰ伝送に切り替えることによって無線接続の再構成を開始する。

解決策１の代替案は解決策２に適用可能である。

以下の説明は、本発明に記載された全ての解決策に当てはまる。
本発明の実施形態によれば、移動体端末（例えば、ＵＥ）３０は、ネットワークへの／からの（特に、ＲＡＮノードからの）シグナリングに対応できるように変更される。移動体端末３０は、図１２に示すようなブロック図を用いて概略的に説明することができる。

図１２に示すように、移動体端末（ＵＥ）３０は、トランシーバ回路３１と、ネットワーク（ＲＡＮノード）と信号を送受信するための無線インタフェース３２とを備える。移動体端末３０は、自身の動作を制御するためのコントローラ３３を備える。コントローラ３３は、メモリ３４に関連付けられている。

ソフトウェアは、例えば、メモリ３４に予めインストールされていてもよく、通信ネットワークを介して、または着脱可能なデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。コントローラ３３は、この例では、メモリ３４に格納されたプログラム命令またはソフトウェア命令によって移動体端末３０の全体的な動作を制御するように構成される。図示のように、ソフトウェア命令は、とりわけ、オペレーティングシステム３５および通信制御モジュール３６を含む。

通信制御モジュール３６は、移動体端末３０とネットワークとの間の通信を制御する。通信制御モジュール３６は、トランシーバ制御モジュール３７を含む。

本発明の実施形態によれば、ＲＡＮノード（例えば、ｅＮＢ）４０は、ネットワーク（ＭＭＥ／ＳＧＳＮ）への／からのシグナリングおよびＵＥ３０への／からのシグナリングに対応できるように変更される。ＲＡＮノード４０は、図１３に示すようなブロック図を用いて概略的に説明することができる。

図１３に示すように、ＲＡＮノード４０は、トランシーバ回路４１と、サービングノードと信号を送受信するためのネットワークインタフェース４２と、移動体端末３０と信号を送受信するための無線インタフェース４３とを備える。ＲＡＮノード４０は、自身の動作を制御するためのコントローラ４４を備える。コントローラ４４は、メモリ４５に関連付けられている。

ソフトウェアは、例えば、メモリ４５に予めインストールされていてもよく、通信ネットワークを介して、または着脱可能なデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。コントローラ４４は、この例では、メモリ４５に格納されたプログラム命令またはソフトウェア命令によってＲＡＮノード４０の全体的な動作を制御するように構成される。図示のように、ソフトウェア命令は、とりわけ、オペレーティングシステム４６および通信制御モジュール４７を含む。

通信制御モジュール４７は、ＲＡＮノード４０と移動体端末３０との間の通信、およびＲＡＮノード４０とサービングノードとの間の通信を制御する。通信制御モジュール４７は、トランシーバ制御モジュール４８を含む。

本発明の実施形態によれば、サービングノード（ＭＭＥ／ＳＧＳＮ／ＭＳＣ／Ｃ−ＳＧＮ）５０は、提案された解決策に従って動作することができるよう変更／拡張されるべきである。また、ＳＧＷ、ＰＧＷおよびＨＳＳへの変更が必要である。このために、サービングノード（ＭＭＥ／ＳＧＳＮ）５０、ＳＧＷ、ＰＧＷ、ＳＣＥＦまたはＨＳＳは、図１４のブロック図を用いて概略的に説明することができる。

図１４に示すように、サービングノード５０は、トランシーバ回路５１と、他のネットワークエンティティ（ＲＡＮノード４０）と信号を送受信するためのネットワークインタフェース５２とを備える。サービングノード５０は、自身の動作を制御するコントローラ５３を備える。コントローラ５３は、メモリ５４に関連付けられている。

ソフトウェアは、例えば、メモリ５４に予めインストールされていてもよく、通信ネットワークを介して、または着脱可能なデータ記憶装置（ＲＭＤ）からダウンロードされてもよい。コントローラ５３は、この例では、メモリ５４に格納されたプログラム命令またはソフトウェア命令によってサービングノード５０の全体的な動作を制御するように構成される。図示のように、ソフトウェア命令は、とりわけ、オペレーティングシステム５５および通信制御モジュール５６を含む。

通信制御モジュール５６は、サービングノード５０と他のネットワークエンティティ（ＲＡＮノード４０）との間の通信を制御する。通信制御モジュール５６は、トランシーバ制御モジュール５７を含む。

本発明をその実施形態を参照して具体的に示し説明したが、本発明はこれらの実施形態に限定されるものではない。特許請求の範囲によって規定される本発明の精神および範囲から逸脱することなく、形式および詳細の様々な変更を行うことが可能なことは、当業者には理解されよう。

本願は、２０１６年２月１７日に特許出願された欧州特許出願ＥＰ１６２７５０２７．７の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。

Claims (6)

1. 制御プレーンCIoT (Cellular Internet of things)最適化を用いた第1のデータの送信が行われている場合に、前記第1のデータの送信後に受信した第2のデータのデータサイズに基づいて、以降のデータがユーザプレーンで移動体端末に送信されるかどうかを決定する決定手段と、
   前記決定に基づいて、前記移動体端末のためのユーザプレーン無線リソースのセットアップのための要求を通信装置へ送信する第1の送信手段と、
   前記移動体端末のための前記ユーザプレーン無線リソースの前記セットアップの完了を通知するためのメッセージを前記通信装置から受信する受信手段と、
   前記ユーザプレーン無線リソースを用いたデータ通信用のトンネル情報を含む変更要求をユーザデータ通信のためのネットワークノードへ送信する第2の送信手段と、を備えるコアネットワークノード。
2. 前記決定手段は、下りデータ通信中に前記以降のデータがユーザプレーンで送信されるか否かを決定する、請求項１に記載のコアネットワークノード。
3. 前記要求はユーザプレーンCIoT最適化がサポートされているか否かを示すユーザプレーンCIoT指示子(indication)を含む、請求項１または２に記載のコアネットワークノード。
4. 制御プレーンCIoT (Cellular Internet of things)最適化を用いた第1のデータの送信が行われている場合に、前記第1のデータの送信後に受信した第2のデータのデータサイズに基づいて、以降のデータがユーザプレーンで移動体端末に送信されるかどうかを決定し、
   前記決定に基づいて、前記移動体端末のためのユーザプレーン無線リソースのセットアップのための要求を通信装置へ送信し、
   前記移動体端末のための前記ユーザプレーン無線リソースの前記セットアップの完了を通知するためのメッセージを前記通信装置から受信し、
   前記ユーザプレーン無線リソースを用いたデータ通信用のトンネル情報を含む変更要求をユーザデータ通信のためのネットワークノードへ送信する、通信方法。
5. 前記以降のデータがユーザプレーンで送信されるか否かを決定することは、下りデータ通信中に行われる、請求項４に記載の通信方法。
6. 前記要求はユーザプレーンCIoT最適化がサポートされているか否かを示すユーザプレーンCIoT指示子(indication)を含む、請求項４または５に記載の通信方法。
   
   

Images