JP6593725B2 - 改良されたショート・メッセージ送信手順およびハンドオーバ手順 - Google Patents

Description

本発明の一態様は、移動ノードのハンドオーバを実行するための方法に関する。さらに、本発明の一態様は、移動ノードと、本発明の方法に関与するその他のエンティティとに関する。

［ロングタームエボリューション（ＬＴＥ）］
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化あるいは発展・進化させるうえでの最初のステップとして、高速下りリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンスト上りリンク（高速上りリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

しかしながら、より長期的には、さらに増加しつつあるユーザの需要に備え、新たな無線アクセス技術に対する競争力を備える必要がある。この課題に対応するべく、３ＧＰＰは、研究項目としてＥｖｏｌｖｅｄ ＵＴＲＡおよびＵＴＲＡＮに着手しており、これらの研究項目は、サービスのプロビジョニングおよびコスト削減の観点でさらに大きな前進を実現するための手段を研究することを目指している。この目標の基礎として、３ＧＰＰは、ロング・ターム・エボリューション（ＬＴＥ）と称される新たな移動通信システムの一連の目標および要件を決定した。ＬＴＥは、今後の１０年間にわたり、データおよびメディアの高速転送ならびに大容量の音声サポートに関する加入者およびネットワーク事業者のニーズを満足するように設計されている。

［ＬＴＥアーキテクチャ］
図１は、ＬＴＥの全体的なアーキテクチャを示しており、図２は、Ｅ−ＵＴＲＡＮのアーキテクチャをさらに詳しく示している。

Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成されており、ｅＮｏｄｅＢは、ユーザ機器（ＵＥ）に向かうＥ−ＵＴＲＡのユーザ・プレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端させる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理層（ＰＨＹ）、メディア・アクセス制御（ＭＡＣ）層、無線リンク制御（ＲＬＣ）層、およびパケット・データ制御プロトコル（ＰＤＣＰ）層（ユーザプレーンのヘッダ圧縮および暗号化の機能を含んでいる）をホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッション制御、スケジューリング、ネゴシエーションされた上りリンクのサービス品質（ＱｏＳ）の実施、セル情報のブロードキャスト、ユーザ・プレーンデータおよび制御プレーンデータの暗号化／復号、下りリンク／上りリンクのユーザ・プレーン・パケットヘッダの圧縮／復元など、多くの機能を実行する。ｅＮｏｄｅＢは、Ｘ２インターフェースによって互いに接続されている。

さらに、ｅＮｏｄｅＢは、Ｓ１インターフェースによってＥＰＣ（Evolved Packet Core）に接続されており、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：移動管理エンティティ）に接続されており、Ｓ１−Ｕによってサービング・ゲートウェイ（ＳＧＷ：Serving Gateway）に接続されている。Ｓ１インターフェースは、ＭＭＥ／サービング・ゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。

ＳＧＷは、ユーザデータパケットのルーティングおよび転送を行う一方で、ｅＮｏｄｅＢ間のハンドオーバ時にユーザ・プレーンのモビリティアンカ（mobility anchor）としての役割と、ＬＴＥとそれ以外の３ＧＰＰ技術との間のモビリティのためのアンカとしての役割も果たす（Ｓ４インターフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）。ＳＧＷは、アイドル状態のユーザ機器に対しては、そのユーザ機器への下りリンクデータが到着したとき下りリンクデータ経路を終端させ、ページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト（例えば、ＩＰベアラ・サービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法傍受（lawful interception）の場合にユーザ・トラフィックの複製を実行する。

ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドル・モードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラの有効化／無効化プロセスに関与し、さらには、最初のアタッチ時と、コア・ネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証を確認し、ユーザ機器のローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティ・キーの管理を行う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセス・ネットワークと２Ｇ／３Ｇのアクセス・ネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インターフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインターフェースを終端させる。

移動ノード（ＭＮ、またはユーザ機器（ＵＥ）とも称される）と無線アクセスとの間の制御シグナリングは、無線リソース制御（ＲＲＣ）メッセージによって行われる。ＲＲＣプロトコルは、レイヤ３に設けられており、ＵＥに固有のシグナリング、アイドル・モードのＵＥのページング、およびシステム情報のブロードキャストのための機能を提供する。さらに、ＲＲＣ層は、上位層（例えば、ＮＡＳ）の制御情報の正確な送信を保証するための再送信機能をサポートする。

図３は、例示的なＬＴＥシステムのＵＥとＭＭＥとの間の制御プレーンのプロトコル・スタックを示す。レイヤ２は、メディア・アクセス制御（ＭＡＣ）と、無線リンク制御（ＲＬＣ）と、パケット・データ・コンバージェンス・プロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）とに分けることができ、RLCサブレイヤおよびＰＤＣＰサブレイヤは、ネットワーク側のｅＮｏｄｅＢにおいて終端される。ＮＡＳ層は、ＵＥおよびＭＭＥにおいて終端される。ＲＬＣ層がＵＥとｅＮｏｄｅＢとの間の制御プレーンで提供するサービスは、シグナリング無線ベアラ（ＳＲＢ）と称される。ユーザ・プレーンにおいては、ＲＬＣ層によってＵＥとｅＮｏｄｅＢとの間で提供されるサービスは、無線ベアラ（ＲＢ）またはデータ無線ベアラ（ＤＲＢ）と称される。

とりわけ、上位層、すなわち非アクセス層（ＮＡＳ）のメッセージは、ユーザ機器とｅＮｏｄｅＢとの間のＲＲＣメッセージによって（例えば、ＲＲＣ直接情報転送（RRC Direct Information Transfer）メッセージを用いて）搬送される。非アクセス層は、ＵＥとコア・ネットワーク（ＣＮ）との間で実行される機能層であり、ＲＲＣの上位に位置する。さらに、ＮＡＳは、回線交換される音声およびデータに関する呼制御（ＣＣ）と、パケット交換されるデータに関するセッション管理（ＳＭ）と、移動管理（ＭＭ）と、パケット交換ドメインおよび回線交換ドメインのショート・メッセージ・サービス（ＳＭＳ）とを目的とするプロトコルの機能グループである。ＮＡＳ層が生成する制御メッセージは、ＮＡＳメッセージと称される。例えば、そのようなメッセージは、移動管理、セッション管理、ＳＭＳ転送、および呼管理を制御するために使用される。ＮＡＳメッセージは、ＮＡＳの転送をサポートするための機能およびプロトコルを含むアクセス層の層（レイヤ３−２−１、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ）を通じて透過的に転送される。

アクセス層は、アクセス技術に固有のプロトコルの機能グループ、この場合、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、およびＰＨＹである。アクセス層は、無線に関連する情報の転送をサポートするためのプロトコルと、ＵＥとアクセス・ネットワークとの間の無線リソースの使用を調整するためのプロトコルと、アクセス・ネットワークによって提供されるリソースに対するサービング・ネットワーク（serving network）からのアクセスをサポートするプロトコルとを含む。アクセス層は、サービス・アクセス・ポイント（ＳＡＰ）を通じて非アクセス層（ＣＮに関連するシグナリングおよびサービス）にサービスを提供し、すなわち、ＵＥとコア・ネットワークとの間のアクセス・リンクを提供し、このアクセス・リンクは、１つまたは複数の独立しており同時に存在できるＵＥ−コア・ネットワーク無線アクセス・ベアラ・サービスと、ＵＥおよびコア・ネットワークの上位層エンティティ間のただ１つのシグナリング接続とから構成される。

例えば、データを送信しなければならないときに、サービス要求手順によって、非アクセス層シグナリング接続がユーザ機器とＭＭＥとの間で確立された後、ユーザ機器およびＭＭＥは、ＣＯＮＮＥＣＴＥＤ状態となる。ＩＤＬＥ状態からＣＯＮＮＥＣＴＥＤ状態への遷移を開始する最初の上りリンクの非アクセス層メッセージとしては、アタッチ要求、トラッキング・エリア更新要求、サービス要求（もしくは拡張サービス要求）、またはデタッチ要求がある。最初の非アクセス層メッセージを送信するために、ユーザ機器は、まず初めに、無線インターフェース（Ｕｕインターフェース）を介してｅＮｏｄｅＢへの無線リソース制御（ＲＲＣ）接続を確立する。ＲＲＣ接続を確立する間に、ユーザ機器とｅＮｏｄｅＢとが同期され、非アクセス層メッセージを転送するために使用可能なシグナリング無線ベアラ（ＳＲＢ）が確立される。これについては、後ほど図５を参照しながらより詳細に説明する。

図４は、ＵＥと、ｅＮｏｄｅＢと、サービング・ゲートウェイと、ＰＤＮゲートウェイとの間のＥ−ＵＴＲＡＮのユーザ・プレーンのプロトコル・スタックを開示している。プロトコル・スタックは、ネットワーク側のｅＮｏｄｅＢにおいて終端されるＰＤＣＰ（パケット・データ・コンバージェンス・プロトコル）サブレイヤと、ＲＬＣ（無線リンク制御）サブレイヤと、ＭＡＣ（メディア・アクセス制御）サブレイヤとから構成されている。ＵＥに関するＩＰパケットは、ＥＰＣに固有のプロトコルでカプセル化され、ＰＤＮ−ＧＷと、ＵＥに送信するためのｅＮｏｄｅＢとの間でトンネリングされる。

［ＥＰＳ移動および接続管理状態］
移動端末（またはユーザ機器、ＵＥ）がネットワークにアタッチされるとき、ＵＥは、いわゆるＲＥＧＩＳＴＥＲＥＤ状態になり、すなわち、ネットワークおよびＵＥにおいて、ＥＰＳ移動管理（ＥＭＭ：EPS Mobility Management）コンテキストが確立されており、デフォルトのＥＰＳベアラ・コンテキストが有効化されている。ＵＥが移動通信ネットワークに対してＲＥＧＩＳＴＥＲＥＤ状態である（登録されている）とき、ＵＥは、２つの異なる接続管理状態、すなわち、ＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態になり得る。ＵＥがオフにされているか、またはＵＥが移動通信ネットワークにアタッチされていないとき、ＵＥは、ＤＥＲＥＧＩＳＴＥＲＥＤ状態である。ＤＥＲＥＧＩＳＴＥＲＥＤ状態においては、ＥＭＭコンテキストが存在せず、ＭＭＥがＵＥの位置を把握しておらず、したがって、ＭＭＥはＵＥに到達することができない。

送信するデータがなく、無線リソースが解放されているが、ＵＥが有効なＩＰ構成を引き続き保持しているとき、ＵＥはＩＤＬＥ状態にある。ＩＤＬＥ状態のＵＥは、ｅＮＢとの無線の関連付け（すなわち、無線リソース接続、ＲＲＣ）がなく、したがって、いかなるシグナリング無線ベアラもデータ無線ベアラも存在しない。さらに、ＵＥとネットワークとの間の（例えば、ＭＭＥへの）非アクセス層（ＮＡＳ）シグナリング接続が存在せず、ｅＮＢとＳＧＷとの間のＳ１−Ｕ接続も存在しない。

ＵＥがＣＯＮＮＥＣＴＥＤ状態にあり、ＵＥが、特定の期間、データを送信／受信していないことをネットワーク（通常はｅＮＢ）が検出したとき、ネットワーク（通常はｅＮＢ）は、無線リソースおよびＳ１接続を解放すると判断する。その結果、ＵＥは、ＣＯＮＮＥＣＴＥＤ状態からＩＤＬＥ状態に遷移する。さらに、ＭＭＥは、ＵＥについてのそのＭＭＥの内部状態をＩＤＬＥに変更し、ｅＮＢへのＳ１−Ｕ接続を解放するようにＳＧＷに通知する。

上りリンクまたは下りリンク・データまたはシグナリング（例えば、アクティブ・フラグ（active flag）を伴うＴＡＵ手順によるＮＡＳシグナリング）をＵＥとネットワークとの間で交換する必要があるとき、ＵＥおよびＭＭＥは、ＣＯＮＮＥＣＴＥＤ状態になることとなる。アクティブ・フラグを伴わないＴＡＵ手順の場合は、ＵＥが、ＣＯＮＮＥＣＴＥＤ状態にならずに単一のＮＡＳメッセージの送信と受信とをそれぞれ行うことがあり得る。ＣＯＮＮＥＣＴＥＤ状態に遷移するために、ＵＥ、まず初めに、Ｕｕインターフェースを介してｅＮＢへの無線リソース制御（ＲＲＣ）接続を確立する必要がある。ＲＲＣ接続を確立する間に、ＵＥとｅＮＢとが同期され、ＮＡＳメッセージならびに上りリンク・データおよび下りリンク・データを転送するために使用可能なシグナリング無線ベアラ（ＳＲＢ）およびデータ無線ベアラ（ＤＲＢ）が確立される。

上述のＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態は、ＮＡＳ層状態図に関連している。一方、ＡＳ層においても、ＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態が定義されている。ＡＳのＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態は、ＮＡＳのＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態と似ているものの、完全には一致しておらず、すなわち、ＲＲＣ接続が確立される場合、ＡＳの状態はＣＯＮＮＥＣＴＥＤになり、そうではなく、ＲＲＣ接続が解放される場合、ＡＳの状態はＩＤＬＥになる。ＡＳの状態がＣＯＮＮＥＣＴＥＤであるとき、ＮＡＳの状態も必ずＣＯＮＮＥＣＴＥＤであるとは限らない（例えば、アクティブ・フラグを伴わないＴＡＵ手順の場合）。ＲＲＣ接続の確立、ひいては、ＡＳ ＣＯＮＮＥＣＴＥＤ状態への遷移は、ＵＥのみが「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ」メッセージを送信することができるときに、ＵＥによって開始される。ＵＥは、上りリンク・データもしくは上りリンク・シグナリングが利用可能になるか、または下りリンク・データもしくは下りリンク・シグナリングを受信するためにネットワークからページングされるかのどちらかの理由でＲＲＣ接続の確立を開始する。以下に、これら２つの場合について詳細を示す。

− ＵＥは、送信すべき上りリンク・データまたは上りリンクＥＳＭ ＮＡＳシグナリングを有する場合、ＮＡＳサービス要求手順（技術規格ＴＳ２３．４０１に記載されており、この技術規格ＴＳ２３．４０１は参照により本明細書に援用される）を開始する。ＵＥは、サービス要求メッセージを生成し、対応するＲＲＣ接続を確立するようにＡＳをトリガする。「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ」メッセージでｅＮＢに送信されるＲＲＣ確立理由は、「ｍｏ−Ｄａｔａ」（移動体発信データ（mobile originated-data）（ＵＥが上りリンク・データを送信したいことを意味する））または「ｍｏ−Ｓｉｇｎａｌｉｎｇ」（移動体発信シグナリング（mobile originated-signalling）（ＵＥが上りリンク・シグナリングを送信したいことを意味する））に設定される。

− ネットワークは、ＵＥへの下りリンク・データまたは下りリンクＮＡＳシグナリングを有する場合、ページング手順（技術仕様ＴＳ３６．４１３およびＴＳ３６．３３１に記載されており、これらの技術規格ＴＳ３６．４１３およびＴＳ３６．３３１は参照により本明細書に援用される）を開始する。ＵＥは、ページングを受信するとき、ＭＭＥへのサービス要求メッセージを生成することによりＮＡＳサービス要求手順を開始する。サービス要求メッセージは、ｅＮＢとのＲＲＣ接続を確立するようにＡＳ層をトリガする。ＲＲＣ確立理由は、移動体終端（Mobile Terminated）アクセスを意味する「ｍｔ−Ａｃｃｅｓｓ」に設定され、すなわち、移動体終端通信が設定されることとなる。

ＬＴＥ／ＳＡＥのＮＡＳ移動管理（ＭＭ）およびセッション管理（ＳＭ）シグナリングは、通常、ＥＭＭ（ＥＰＳ ＭＭ）およびＥＳＭ（ＥＰＳ ＳＭ）シグナリングと称される。対照的に、ＵＴＲＡＮ／ＵＭＴＳでは、ＵＥとＳＧＳＮとの間のＮＡＳシグナリングは、ＧＰＲＳ移動管理（ＧＭＭ）およびＧＰＲＳセッション管理（ＧＳＭ（登録商標））シグナリングと称される。本発明の一部の態様では、ＳＡＥ／ＬＴＥシステムとＵＴＲＡＮ／ＵＭＴＳシステムとの間の違いに注意することが重要であるので、ＧＭＭ／ＧＳＭ（登録商標）に対するＥＭＭ／ＥＳＭの用語を導入する。ページング・メッセージ内の「ＰＳ」（パケット交換ドメイン）または「ＣＳ」（パケット交換ドメイン）の指示に応じて、ＵＥは、ＮＡＳ接続を確立するために、サービス要求メッセージか、または拡張サービス要求メッセージかのどちらかを送信し得る。以下に、技術仕様ＴＳ２４．３０１の８．２．１５章による拡張サービス要求メッセージのフォーマットおよび内容を示す。

［ＲＲＣ］
ＲＲＣプロトコルは、ＮＡＳ情報の転送をサポートする。加えて、ＲＲＣ＿ＩＤＬＥ状態のＵＥに関して、ＲＲＣは、呼の到着をネットワークから通知することをサポートする。ＲＲＣ接続制御は、ページング、最初のセキュリティの有効化、シグナリング無線ベアラの確立、およびユーザ・データを搬送する無線ベアラ（データ無線ベアラ）の確立を含む、ＲＲＣ接続の確立、修正、および解放に関するすべての手順を包含する。

個別ＲＲＣメッセージは、シグナリング無線ベアラを介して転送され、これらのシグナリング無線ベアラは、ＰＤＣＰ層およびＲＬＣ層を介して論理チャネル（共通制御チャネル（ＣＣＣＨ）（接続の確立中の場合）か、または個別制御チャネル（ＤＣＣＨ）（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の場合）かのどちらか）にマッピングされる。システム情報およびページング・メッセージは、論理チャネルであるブロードキャスト制御チャネル（ＢＣＣＨ）およびページング制御チャネル（ＰＣＣＨ）にそれぞれ直接マッピングされる。

ＳＲＢ１とＳＲＢ２との主な違いは、ｅＮＢにおける優先処理にあり、すなわち、ＳＲＢ２を介して送信されたＲＲＣメッセージの方が、ＳＲＢ１を介して送信されたＲＲＣメッセージよりも優先度が低い。通常、ＮＡＳトランスポート・メッセージはＳＲＢ２を介して（上りリンク／下りリンク情報転送メッセージとして）搬送されるが、最初のＮＡＳメッセージ、例えば、サービス要求については、ＳＲＢ１を介して搬送されるＲＲＣメッセージにピギーバックされ得る。ＳＲＢ１を介したＲＲＣメッセージがＲＲＣ層の制御情報を含む一方、ＳＲＢ２を介したＲＲＣメッセージはＮＡＳメッセージに関するトランスポート・メッセージのようなものであることに留意されたい。

ＳＲＢ０は、ＣＣＣＨを使用するＲＲＣメッセージのために使用され、ＳＲＢ１は、ＤＣＣＨを使用するＲＲＣメッセージ用であり、ＳＲＢ２は、ＮＡＳ個別情報（NAS dedicated information）のみを含む、ＤＣＣＨを使用する（優先度の低い）ＲＲＣメッセージ用である。ＳＲＢ２が確立される前は、ＳＲＢ１が、ＮＡＳ個別情報のみを含むＲＲＣメッセージのためにやはり使用される。加えて、ＳＲＢ１は、ＮＡＳ個別情報のみを含む優先度の高いＲＲＣメッセージのために使用される。

ＤＣＣＨを使用するすべてのＲＲＣメッセージは、（セキュリティが有効化された後は）ＰＤＣＰ層によって完全性を保護され、暗号化される。ＣＣＣＨを使用するＲＲＣメッセージは、完全性を保護されない。

図５は、最初のセキュリティの有効化も含めて、シグナリング無線ベアラＳＲＢ０、１、および２のＲＲＣ接続確立手順を示すシグナリング図である。ＲＲＣ接続の確立は、ＳＲＢ１を確立し、最初の上りリンクＮＡＳメッセージを転送することを含む。このＮＡＳメッセージが、Ｓ１接続の確立をトリガし、通常は、このＳ１接続の確立によって、Ｅ−ＵＴＲＡＮがＡＳセキュリティを有効化し、ＳＲＢ２と、（デフォルトの個別ＥＰＳベアラおよび任意の個別ＥＰＳベアラに対応する）１つまたは複数のＤＲＢとを確立する後続のステップを引き起こす。

特に、ＵＥの上位層（例えば、ＮＡＳ）が、（例えば、ページングに応答して）接続の確立をトリガする。ＵＥは、アクセスが禁じられているか否かを調べる。禁じられていない場合、ＵＥの下位層がランダム・アクセス手順を実行し、ＵＥがタイマ（Ｔ３００として知られている）を開始し、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを送信する。このメッセージは、初期ＩＤ（Ｓ−ＴＭＳＩまたは乱数）および確立理由を含む。

Ｅ−ＵＴＲＡＮは、接続を受け入れる場合、ＳＲＢ１を含む初期無線リソース構成を含むＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐメッセージを返す。それぞれの個々のパラメータをシグナリングする代わりに、Ｅ−ＵＴＲＡＮは、デフォルト構成、すなわち、パラメータ値がＲＲＣの仕様で規定されている構成を提供するようにＵＥに命じることができる。

ＵＥは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを返し、ＮＡＳメッセージと、（ネットワーク共有をサポートするために使用される）選択されたＰＬＭＮの識別子と、上位層が提供する場合には、登録されたＭＭＥの識別子とを含める。最後の２つのパラメータに基づいて、ｅＮｏｄｅＢは、そのｅＮｏｄｅＢがＳ１接続を確立すべきコア・ネットワーク・ノードを決定する。ＮＡＳサービス要求または拡張サービス要求メッセージが、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに含められる。

ｅＮｏｄｅＢとＭＭＥとの間の初期コンテキスト設定手順は、Ｅ−ＲＡＢコンテキスト、セキュリティ・キー、ハンドオーバ制限リスト、ＵＥ無線機能（UE Radio capability）、およびＵＥセキュリティ機能（UE Security Capabilities）などを含む必要とされる全体的な初期ＵＥコンテキストを確立することを目的としている。この手順は、ＵＥに関連するシグナリングを使用する。

Ｅ−ＵＴＲＡＮは、完全性の保護と暗号化とを有効化するためのＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージを送信する。このメッセージは、完全性を保護されているが、暗号化はされておらず、どのアルゴリズムが使用されることになるのかを示す。

ＵＥは、ＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージの完全性の保護を検証し、この検証が成功する場合、すべての後続のメッセージに完全性の保護と暗号化とを適用するように下位層を構成する（例外として、暗号化は、応答メッセージ、すなわち、ＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅ（または、ＳｅｃｕｒｉｔｙＭｏｄｅＦａｉｌｕｒｅ）メッセージには適用されない）。

Ｅ−ＵＴＲＡＮは、ＳＲＢ２および１つまたは複数のＤＲＢを確立するために使用される無線リソース構成を含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信する。さらに、このメッセージは、ピギーバックされるＮＡＳメッセージまたは測定の構成などの情報を含む可能性がある。Ｅ−ＵＴＲＡＮは、ＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅメッセージを受信する前にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信する可能性がある。この場合、Ｅ−ＵＴＲＡＮは、一方の（または両方の）手順が失敗するとき、接続を解放するべきである。

最後に、ＵＥは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを返す。

図５は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージおよびＳ１−ＡＰメッセージを使用する、ＭＭＥに送信されるＮＡＳサービス要求またはＮＡＳ拡張サービス要求メッセージの送信も開示する。ユーザ機器は、技術仕様ＴＳ２４．３０１の５．６．１節に記載のタイマＴ３４１７またはＴ３４１７ｅｘｔを開始する。ユーザ機器は、それに応じてアクセス層から指示が受信されるときに、これらのタイマＴ３４１７またはＴ３４１７ｅｘｔを停止する。例えば、ユーザ機器は、タイマＴ３４１７を停止するための、ユーザ・プレーンに関するベアラの確立の指示をアクセス層から受信することになる。タイマＴ３４１７ｅｘｔを停止するために、ユーザ機器は、アクセス層からシステム変更の指示を受信することになる。

［ページング］
Ｅ−ＵＴＲＡＮからページング・メッセージを受信するために、アイドル・モードのＵＥは、ページングを指示するために使用されるＲＮＴＩ（radio network temporary identity：無線ネットワーク一時ＩＤ）値、すなわち、Ｐ−ＲＮＴＩに関してＰＤＣＣＨチャネルを監視する。ＵＥは、特定のＵＥに固有の機会にのみＰＤＣＣＨチャネルを監視する必要がある。それ以外のときは、ＵＥは、ＤＲＸ（間欠受信）を適用することができ、つまり、ＵＥは、バッテリーの電力を節約するためにそのＵＥの受信機をオフにすることができる。

アイドル・モードのＵＥへの接続を再確立するために、ＭＭＥは、ＵＥが位置すると予想されるトラッキング・エリアに基づいて、関連するｅＮｏｄｅＢにページング要求を配信する。ページング要求メッセージを受信するとき、ｅＮｏｄｅＢは、そのメッセージで与えられたトラッキング・エリアのうちの１つに含まれるセルの無線インターフェースを介して呼び出しを送信する。通常、ＵＥは、そのＵＥのＳＡＷ−一時移動体加入者ＩＤ（Ｓ−ＴＭＳＩ：SAW-Temporary Mobile Subscriber Identity）を用いてページングされる。

ＭＭＥからｅＮｏｄｅＢに送信されるページング要求メッセージは、技術仕様ＴＳ３６．４１３の９．１．６章（これは参照により本明細書に援用される）において以下のように定義されている。

ｅＮｏｄｅＢからユーザ機器に送信されるページング・メッセージは、技術仕様３６．３３１（これは参照により本明細書に援用される）で定義されている。

［ショート・メッセージ・サービス（ＳＭＳ）］
ショート・メッセージ・サービス（ＳＭＳ）は、ＧＳＭ（登録商標）の標準化が開始された際は、ユーザ機器の構成と、（例えば、新しい価格または新しい料金プランを知らせる）情報サービスとのためにネットワーク事業者からＵＥにショート・メッセージを送信するためのメカニズムとなることを目的としていた。後に、ショート・メッセージ・サービスは、蓄積交換型のサービスであるので、ユーザ間のメッセージ（移動体間のテキスト・メッセージ）を搬送するように規定された。最大のＳＭＳのサイズは、当時存在していたシグナリング・フォーマットに合わせるために１４０バイトまで、または７ビット文字で１６０文字までと規定されている。より大きな内容は、連結されたＳＭＳで送信可能であり、連結されたＳＭＳにおいては、それぞれのＳＭＳが、セグメンテーション情報を含むユーザ・データ・ヘッダ（ＵＤＨ）で始まる。ＵＤＨはペイロードの一部であるため、セグメントごとに利用可能な文字数はより少なく、７ビット符号化に関して１５３文字である（１６０文字ではない）。

図１２Ａは、移動体通信ネットワークでＳＭＳを転送するためのアーキテクチャを示す。簡単にするために、ＳＭ−ＳＣ、ＳＭＳ−ＧＭＳＣ、およびＳＭＳ−ＩＷＭＳＣは同じ筐体に実装される可能性があり、ＳＭ−ＳＣと称される可能性がある。ＳＭサービスは、回線交換サービスであると考えられ、したがって、ＳＭＳは、ＳＭ−ＳＣから、回線交換ドメインの移動通信交換局（ＭＳＣ：Mobile Switching Center）に届けられる。

２種類のＳＭＳ、すなわち、移動体発信型（ＭＯ、ユーザからネットワークに上りリンクで送信される）と、移動体終端型（ＭＴ、ネットワークからユーザに下りリンクで送信される）とが規定されている。

ＳＭＳ通信のプロトコル階層モデルが、図１３に示されており、以降で説明される。この図で使用されている略語「ＳＭ」は、「ショート・メッセージ」を意味する。

図１３は、主に、ＭＭＥ／ＳＧＳＮにおいてＳＭＳをネイティブでサポートするためのプロトコル・スタックを開示していることに留意されたい。言い換えると、「ＳＭＳオーバーＳＧｓ（SMS over SGs）」を用いたＳＭＳ通信のプロトコル階層モデルは示されておらず、図１３のプロトコル階層モデルとは異なる。

図１３において、図示されたＳＭ−ＳＣノードは、図１２Ａおよび１２Ｂに既に示されたように、機能エンティティであるＳＭＳゲートウェイＭＳＣ（ＳＭＳ−ＧＭＳＣ）およびＳＭＳ網間接続ＭＳＣ（ＳＭＳ−ＩＷＭＳＣ：SMS Interworking MSC）を実装し得る。ＳＭＳ−ＧＭＳＣは、例えば、ＭＴ−ＳＭＳのためにサービングＭＳＣ／ＳＧＳＮに接続するために使用され、すなわち、ＳＭＳ−ＧＭＳＣが、ＭＳＣ／ＳＧＳＮへのＭＴ ＴＰＤＵを含むＭＡＰメッセージを送信する（そのようなＭＡＰメッセージは、ＴＰＤＵを搬送するＭＡＰ＿ＭＴ＿ＦＯＲＷＡＲＤ＿ＳＨＯＲＴ＿ＭＥＳＳＡＧＥ、または略して「ｍｔ−ＦｏｒｗａｒｄＳＭ（ＴＰＤＵ）」と称される）。ＳＭＳ−ＩＷＭＳＣは、例えば、ＭＯ−ＳＭＳのためにサービングＭＳＣ／ＳＧＳＮに接続するために使用され、すなわち、サービングＭＳＣ／ＳＧＳＮが、ＳＭＳ−ＩＷＭＳＣへのＭＯ ＴＰＤＵを含むＭＡＰメッセージ（ＴＰＤＵを搬送するＭＡＰ＿ＭＯ＿ＦＯＲＷＡＲＤ＿ＳＨＯＲＴ＿ＭＥＳＳＡＧＥ、または略して「ｍｏ−ＦｏｒｗａｒｄＳＭ（ＴＰＤＵ）」）を送信する。

図１３に示されたＳＭＳプロトコル・エンティティ（例えば、ＳＭＲエンティティおよびＳＭＣエンティティ）の実装は、例であることに留意されたい。３ＧＰＰ以外の将来の１つのシステムまたは複数のシステムにおいては、ＳＭＳの機能エンティティの実装は、図示されたＳＭＳの機能エンティティとは異なり、物理ノードで行われる可能性がある。

ＭＴ−ＳＭＳに関して言えば、ＳＭ−ＳＣは、ショート・メッセージ転送層（ＳＭ−ＴＬ）において送信のためのＭＴ−ＳＭＳを準備する。ＳＭ−ＴＬメッセージ（ＴＰＤＵ：Transfer Packet Data Unit、転送パケット・データ単位）が、ショート・メッセージ中継層（ＳＭ−ＲＬ）のショート・メッセージ中継（ＳＭＲ）エンティティで受信される。ＳＭ−ＲＬ層のパケット・データ単位（ＰＤＵ）は、ＲＰＤＵ（中継層ＰＤＵ）と称される。ＭＴ−ＳＭＳ自体は、ＲＰ−ＤＡＴＡ ＲＰＤＵにカプセル化され、対応するＡＣＫ（acknowledgement）またはエラー・メッセージは、ＲＰ−ＡＣＫまたはＲＰ−ＥＲＲＯＲと称される。結果として、３種類のＲＰＤＵが存在することとなる。

ＳＭ−ＴＰプロトコルおよびＳＭ−ＲＰプロトコルは、ネットワーク側のＳＭ−ＳＣおよびＭＳＣ／ＭＭＥとＵＥとで対応するように実装される。したがって、中継プロトコルを実装するＳＭＲエンティティは、ＭＳＣ／ＭＭＥおよびＵＥで実装され、それらの間でＲＰＤＵを交換する。

回線交換ドメインでのＳＭＳの典型的な送信の場合、ＳＭ−ＳＣは、通常、ＭＡＰ／ＳＳ７シグナリングによってＭＳＣに接続され、ＭＳＣはＳＧＳＮ／ＭＭＥに接続される。後で説明するように、将来は、さらに、または代替的に、ＵＥがパケット交換ドメインにのみアタッチされるときのＳＭＳの送信のために、ＳＭ−ＳＣとＳＧＳＮ／ＭＭＥとの間に直接的なインターフェースが設けられることになる。ＳＳ７シグナリングは、ＳＭ−ＳＣとＳＧＳＮ／ＭＭＥとの間でＴＰＤＵを搬送するために使用されるＭＡＰプロトコルの一部である。実際は、ＳＳ７シグナリングは、ＳＭ−ＳＣと移動通信交換局（ＭＳＣ）との間で使用される。ＳＭ−ＳＣとＳＧＳＮまたはＭＭＥとの間の直接的なインターフェースを介したシグナリングは、ＭＡＰ／ＳＳ７シグナリングか、またはＤＩＡＭＥＴＥＲのようなＩＰに固有のプロトコルかのどちらかに基づく可能性がある。

例えば、ＭＡＰプロトコルまたはＤＩＡＭＥＴＥＲプロトコルでカプセル化されたＴＰＤＵがサービングＭＳＣ／ＳＧＳＮ／ＭＭＥに到着するとき、ＴＰＤＵは、ＭＳＣ／ＳＧＳＮ／ＭＭＥの内部でＳＭＲエンティティに転送され、さらには、接続管理（ＣＭ）サブレイヤにおいてＵＥおよびＳＧＳＮ／ＭＭＥで終端されるショート・メッセージ制御プロトコル（ＳＭ−ＣＰ）の一部であるＳＭＣエンティティに転送される。このサブレイヤのプロトコル・エンティティは、ＳＭＣ（ショート・メッセージ制御）エンティティと称される。このサブレイヤで交換されるＰＤＵは、ＣＰＤＵと称され、ＣＰ−ＤＡＴＡ、ＣＰ−ＡＣＫ、およびＣＰ−ＥＲＲＯＲのうちの１つである可能性がある。ＣＰ−ＤＡＴＡ ＰＤＵは、ＳＭＲエンティティで生成されたＲＰＤＵを搬送する。ＣＭサブレイヤは、ＮＡＳ層の一部であると見なされ得る。ＣＭサブレイヤは、ＮＡＳ移動管理（ＭＭ）サブレイヤのサービスを使用する。３ＧＰＰ移動通信システムに応じて、ＭＭサブレイヤは、ＧＭＭ（ＧＰＲＳ ＭＭ）またはＥＭＭ（ＥＰＳ ＭＭ）と称される。図１４は、ＣＰＤＵおよびＲＰＤＵの交換に関する、ＵＥとＳＭ−ＳＣとの間の移動体発信（ＭＯ）ＳＭＳの例示的なシグナリング・フローを示している。ＵＥは、初め、ＩＤＬＥモードであるものとする。ＵＥのＳＭＲエンティティがＲＰ−ＤＡＴＡ ＲＰＤＵを生成するとき、ＳＭＲエンティティは、ＳＧＳＮ／ＭＭＥへのＣＭシグナリング（すなわち、ＮＡＳ）接続を確立するようにＳＭＣエンティティをトリガする。

ＵＥとＭＭＥとの間のＮＡＳ ＭＭ接続、およびＵＥとｅＮＢとの間のＲＲＣ接続を確立するために、ＵＥは、ＮＡＳサービス要求メッセージをＭＭＥに送信する。さらに、ＵＥのＮＡＳ層が、ＲＲＣ接続を確立するようにＲＲＣ層に要求する。ＲＲＣ接続が確立され、サービス要求が送信された後、通常、（１つまたは複数の）データ無線ベアラが確立され、ＲＲＣ層が、ＮＡＳ ＭＭ接続が確立されていることをＮＡＳ層に示す。その後、ＮＡＳ ＭＭ層が、確立されたＮＡＳ ＭＭ接続についてＳＭＣエンティティに通知し、ＳＭＣエンティティが、ＣＰＤＵを送受信することができる。

ＮＡＳシグナリング接続が確立された後、ＳＭＣエンティティは、ＲＰ−ＤＡＴＡを含むＣＰＤＵ ＣＰ−ＤＡＴＡをＳＧＳＮ／ＭＭＥのＳＭＣエンティティに送信する。ＳＭＣエンティティは、ＲＰ−ＤＡＴＡをＳＭＲエンティティに転送し、ＳＭＲエンティティは、そのＲＰ−ＤＡＴＡをＴＰＤＵにカプセル化する。内部転送の後、ＳＧＳＮ／ＭＭＥのＭＡＰエンティティが、ＴＰＤＵでカプセル化されたＲＰ−ＤＡＴＡをｍｏ−ＦｏｒｗａｒｄＳＭ（ＴＰＤＵ）としてＳＭ−ＳＣのＭＡＰエンティティに転送する。

ＳＧＳＮ／ＭＭＥのＳＭＣエンティティは、ＣＰ−ＡＣＫメッセージによってＣＰ−ＤＡＴＡの受信に肯定応答（acknowledge）する。ＳＧＳＮ／ＭＭＥのＳＭＣエンティティがＳＭＲエンティティからＲＰＤＵ（例えば、ＲＰ−ＡＣＫ）を受信するとき、ＳＭＣエンティティは、ＲＰＤＵを含むＣＰ−ＤＡＴＡ ＣＰＤＵを生成し、そのＣＰ−ＤＡＴＡ ＣＰＤＵをＵＥのＳＭＣエンティティに送信する。（ＵＥとＭＭＥとの両方の）ＳＭＲエンティティがもはや送信すべきＲＰＤＵを持たないとき、ＳＭＲエンティティは、解放要求（Ｒｅｌ Ｒｅｑ）を送信することによって、ＣＭシグナリング接続がもはや必要ないことをＳＭＣエンティティに通知する。言い換えると、ＣＭ接続の解放（結果としてＮＡＳ ＭＭ接続を解放し得る）は、ＳＭ−ＲＬによって制御される（ただし、エラー状態の場合は例外である）。

より詳細に言えば、ＭＭＥ／ＳＧＳＮのＳＭＣエンティティが、ＳＭＲエンティティからのＲｅｌ Ｒｅｑと、ＵＥからの最後のＣＰ−ＡＣＫとを両方とも受信するとき、ＳＭＣエンティティは、ＮＡＳ ＭＭ接続の解放を開始するようにＭＭエンティティをトリガする。そのために、ＭＭＥ／ＳＧＳＮのＭＭエンティティは、ｅＮＢにＵＥコンテキスト解放命令を送信する。その結果、ＭＭＥのＭＭエンティティが、そのＵＥに関してＩＤＬＥ状態に遷移する（ただし、そのＵＥに関するＥＭＭおよびＥＳＭコンテキストは維持する）。一方で、ｅＮＢは、ＵＥコンテキストを削除し、ＵＥに「ＲＲＣ接続解放」メッセージを送信する。このメッセージを受信した後、ＵＥのＲＲＣ層は、ＲＲＣ接続が解放されたことをＮＡＳ層に示し、ＮＡＳ層は、ＩＤＬＥ状態に遷移する。

図１５に示すように、同様のシグナリング手順が、移動体終端（ＭＴ）ＳＭＳに関して実行される。この場合、最初のＭＴ−ＳＭＳが、ＳＭ−ＳＣからＵＥに転送されるＴＰＤＵにカプセル化される。ＴＰＤＵを搬送するｍｔ−ＦＳＭがＳＧＳＮ／ＭＭＥに到着するとき、メッセージは、内部で処理され、ＳＭＲエンティティおよびＳＭＣエンティティに転送され、ＳＭＣエンティティが、ＮＡＳ ＭＭシグナリング接続の確立をトリガする。上記目的のために、ＳＧＳＮ／ＭＭＥが、ＵＥをページングし、ＵＥは、サービス要求メッセージによって応答してサービス要求手順を開始する。ＮＡＳ ＭＭ接続が確立されると、ＳＧＳＮ／ＭＭＥのＳＭＣエンティティが、ＳＭＲ層のＲＰ−ＤＡＴＡを含むＣＰ−ＤＡＴＡ ＣＰＤＵをＵＥに送信することができる。ＵＥのＳＭＣエンティティは、ＣＰ−ＤＡＴＡメッセージを処理し、ＲＰ−ＤＡＴＡをＳＭＲエンティティに転送する。そして、ＳＭＣエンティティが、対応するＣＰ−ＡＣＫメッセージをＳＧＳＮ／ＭＭＥに送信する。

ＵＥのＳＭＲエンティティが、ＲＰ−ＡＣＫメッセージを下層のＳＭＣエンティティに送信し、すると今度は、ＳＭＣエンティティが、ＲＰ−ＡＣＫをＣＰ−ＤＡＴＡ ＣＰＤＵに入れ、そのＣＰ−ＤＡＴＡ ＣＰＤＵをＳＧＳＮ／ＭＭＥのＳＭＣエンティティに送信する。ＵＥおよび／またはＭＭＥのＳＭＲエンティティは、送信すべきＲＰＤＵをもはや持たないとき、そのＳＭＲエンティティに対応するＳＭＣエンティティに解放要求メッセージを送信して、ＣＭ接続がもはや必要ないことをそのＳＭＣエンティティに知らせる。

図１６は、ＭＯ ＳＭＳおよびＭＴ ＳＭＳに関する図１４および図１５のシグナリング図をより包括的に示す。特に、上部に、ＭＯ ＳＭＳに関するシグナリング手順を示し、下部に、ＭＴ ＳＭＳに関するシグナリング手順を示す。

［パケット交換ドメインにおけるＳＭＳ送信］
ほとんどの場合、音声サービスおよびＩＰサービスを使用する現在のＵＥは、回線交換サービスとパケット交換サービスとの両方のために移動通信ネットワークにアタッチされる。移動通信ネットワーク（例えば、ＵＴＲＡＮ）は、回線交換サービスおよびパケット交換サービスを同時にサポートすることができ、したがって、移動ノードは、やはり、回線交換サービスとパケット交換サービスとのどちらかまたは両方のためにＵＴＲＡＮにアタッチする可能性がある。Ｅ−ＵＴＲＡＮは、特に、パケット交換サービスのみをサポートするように設計されており、したがって、Ｅ−ＵＴＲＡＮ内のＵＥは、回線交換サービスにアタッチすることができない。それにもかかわらず、ＬＴＥネットワーク内のＵＥについても、以下に説明するように、ＳＭＳの配信が可能である。

３ＧＰＰの用語では、ＵＥが「ＥＰＳ／ＩＭＳＩアタッチされる（EPS/IMSI attached）」（ＬＴＥ／ＳＡＥシステムの用語として使用される）、または「ＧＰＲＳ／ＩＭＳＩアタッチされる（GPRS/IMSI attached）」（ＧＳＭ（登録商標）／ＵＭＴＳシステムの用語として使用される）と言われる。用語ＩＭＳＩは、ＣＳサービスに関連し、用語ＥＰＳおよびＧＰＲＳは、ＰＳサービスに関連する。概して、ＣＳサービスのために使用されるネットワーク・ノードまたはエンティティと、それらに対応するインターフェースとは、ＣＳドメインに属すると言われ、それに応じて、ＰＳサービスのために使用されるネットワーク・ノードまたはエンティティと、それらに対応するインターフェースとは、ＰＳドメインに属すると言われる。

図１２Ｂは、例示的なシステム・アーキテクチャと、ＳＭＳ送信に関与するエンティティ間のインターフェースとを開示しており、図１２Ｂに示されたアーキテクチャの方が、図１２Ａのアーキテクチャよりも新しい。ＵＥがＬＴＥアクセスによってＭＭＥに接続されるとき、ＳＭ−ＳＣとＭＭＥとの間でＳＧｄインターフェース（ＳＭ−ＳＣとＳＧＳＮとの間の既存のインターフェースＧｄに倣ってＳＧｄと呼ばれる）を介してＳＭＳを直接転送することを可能にする機能である「ネイティブＳＭＳ−ｉｎ−ＭＭＥ（native SMS-in-MME）」が指定されることになる。ＳＭ−ＳＣとＭＭＥとの間のＳＧｄインターフェースを設定することは既に合意されているが、そのようなインターフェースは、現在、最終的に規格で定義されていない唯一のインターフェースであり、そのため、名称「ＳＧｄ」は、図１２Ｂにおいて引用符付きで示してあり、ＳＭＳ−ＳＣとＭＭＥとの間のインターフェースは、規格によって異なる名称が与えられる可能性がある。

ＳＭＳの送信は、ＵＥがＧＥＲＡＮ（２Ｇとも称される）またはＵＴＲＡＮ（３Ｇとも称される）を介してＳＧＳＮに登録されるとき、２つの異なる方法、通常は、ＰＳドメイン（すなわち、Ｇｄインターフェースを介したＳＭＳ）か、ＣＳドメイン（すなわち、ＤインターフェースおよびＭＳＣエンティティを介したＳＭＳ）かのどちらかで実行され得る。図２５〜２８は、ＣＳドメインおよび／またはＰＳドメインを含む、ＳＭＳ配信のためのあり得るさまざまな経路を大まかに示す。図２７および２８は、ＵＥがＧＥＲＡＮおよびＵＴＲＡＮを介してＳＧＳＮに登録される特定の場合を示す。

ＰＳドメインのＳＭＳ（ＳＭＳオーバーＧｄインターフェース（SMS over Gd interface）とも称される）：ＳＧＳＮが、Ｇｄインターフェースを介してＳＭＳ−ＳＣとＳＧＳＮとの間でネイティブのＳＭＳ送信が可能となるように、ＳＭ−ＲＰプロトコルおよびＳＭ−ＣＰプロトコルのＳＭＳプロトコル・スタックを実装する。この文脈においては、ネイティブのＳＭＳ送信とは、ＵＥがアタッチされているサービング・ノードが、ＲＰ−ＤＡＴＡ ＰＤＵおよびＣＰ−ＤＡＴＡ ＰＤＵを形成するためのＳＭＳプロトコルであるＳＭ−ＲＰおよびＳＭ−ＣＰをサポートすることを意味する。それに対応して、ＳＭＳ−ＳＣは、ＳＭ−ＴＰプロトコルを使用してＧｄインターフェースを介してＳＧＳＮにＳＭＳを送信し、すると今度は、ＳＧＳＮが、ＳＭ−ＣＰプロトコルおよびＳＭ−ＲＰプロトコルを用いてＧｂまたはＩｕｐｓインターフェースを介してそれぞれＧＥＲＡＮまたはＵＴＲＡＮアクセスのＵＥにＳＭＳを転送することができる。これが、図２７に示されており、「ネイティブＳＭＳ−ｉｎ−ＳＧＳＮ（native-SMS-in-SGSN）」配信と称される可能性がある。さらに、図２７は、ＳＭＳ−ＳＣからＭＴ ＳＭＳを受信したときに、ＵＥがＳＧＳＮによってどのようにページングされるかを破線で示している。

移動ノードがＬＴＥネットワーク内にあるとき、ＳＭＳは、「新たな」ＳＧｄインターフェースを介してＳＭＳ−ＳＣとＭＭＥとの間で送信され、ＳＭ−ＣＰプロトコルおよびＳＭ−ＲＰプロトコルを用いてＳ１インターフェースを介してＭＭＥからＵＥに送信され得る。これが、図２６に示されており、「ネイティブＳＭＳ−ｉｎ−ＭＭＥ」配信と称される可能性がある。さらに、図２６は、ＭＭＥでＳＭＳ−ＳＣからＭＴ ＳＭＳを受信したときに、ＵＥがＭＭＥによってどのようにページングされるかを破線で示している。

その結果、ＳＭＳは、図２６および２７においてはＰＳドメインのエンティティのみを使用してコア・ネットワーク内で配信されており、ＣＳドメインは使用されていない。そのような場合、ＵＥはＭＳＩＳＤＮ番号を持っている必要がないことに留意されたい。したがって、ＭＯ ＳＭＳおよびＭＴ ＳＭＳは、ＭＳＩＳＤＮ識別子が存在することなしにコア・ネットワーク内でルーティング（および場合によっては格納）可能であり、その代わりに、別のＵＥ識別子、例えばＩＭＳＩが使用され得る。

最近の３ＧＰＰの活動で、ＳＧＳＮが、ＮＡＳ ＧＭＭ受容メッセージで「ＳＭＳサポート（SMS supported）」フラグを送信することによって「ＰＳのみ（PS only）」のＳＭＳをサポートすることをＵＥに通知することが規定された。これは主にＭＯ ＳＭＳの送信に関して実行され、ＵＥは、ＭＯ ＳＭＳがＳＧＳＮサービング・ノードを介して送信され得る（すなわち、ＳＭＳ送信のためにＭＳＣに接続する必要がない）ことが分かっている。さらに、ＳＧＳＮからのこのＮＡＳ ＧＭＭの「ＳＭＳサポート」の指示は、ＭＴ ＳＭＳがＳＧＳＮからＵＥに直接送信され得ることをＵＥに示す。さらに、ＰＳドメインのサービスのみを受け、ＮＡＳをベースとするＳＭＳに対応したＵＥは、アタッチ／ＲＡＵ複合（combined Attach/RAU）手順の間に、ＳＧＳＮに「ＳＭＳのみ（SMS-only）」と通知することに留意されたい。

ＣＳドメインのＳＭＳ：概して、ＣＳドメインにおけるＳＭＳの転送は、ＭＳＣサーバを用いて実現可能であり、そのとき、ＭＳＣサーバは、それぞれＵＴＲＡＮまたはＧＥＲＡＮでＵＥにＳＭＳを送信することができる。これが、図２８に示されており、ＳＭＳは、ＣＳドメインのみで配信され、したがって、「ＳＭＳオーバーＣＳ（SMS-over-CS）」と称される可能性がある。ＳＭＳ−ＳＣは、ＭＴ ＳＭＳを受信するとき、そのＭＴ ＳＭＳを、Ｄインターフェースを介してＭＳＣサーバに転送する。ＵＥは、ページングを受信するとき、ＣＳドメインに切り替わることができる（すなわち、ＵＥは、ＭＳＣに登録する）。そのとき、ＭＳＣサーバは、ＳＭＳ ＣＰ／ＲＰプロトコルによってＳＭＳをＵＥに直接送信することができる（図２８参照）。さらに、図２８は、ＭＴ ＳＭＳがＭＳＣに到着し、ＵＥがＳＧＳＮに登録されているときのあり得るページング経路を示す。ページングは、したがって、ＭＳＣがページング・メッセージを生成し、ＵＴＲＡＮネットワーク内にブロードキャストされるようにそのページング・メッセージをＳＧＳＮに転送するように、Ｇｓインターフェースを介して行われ得る。代替的に、ＭＳＣが、ＧＥＲＡＮおよびＵＴＲＡＮで直接ページングを行う可能性がある。ＳＭＳの転送が、ＭＳＣからＳＧＳＮにＧｓインターフェースを介して行われることはあり得ないことに留意されたい。

ＰＳ＋ＣＳ複合ドメインのＳＭＳ：ＳＭＳが、ＭＳＣサーバを経由し、ＭＡＰプロトコルを使用してＳＧｓインターフェースを介してＭＭＥと交換される場合も、ＭＳＣサーバ（ひいては回線交換ドメイン）が関与する。この場合、ＬＴＥネットワーク内に位置するＵＥは、ＳＭＳを転送するＳＭ−ＣＰ ＰＤＵをカプセル化するＮＡＳプロトコルを使用してＳ１インターフェースを介してＭＭＥからＳＭＳを受信する。図２５は、このＳＭＳ配信を示しており、このＳＭＳ配信は「ＳＭＳオーバーＳＧｓ」と称される可能性がある。さらに、図２５は、破線によりページングを示しており、ＳＭＳ−ＳＣからＭＴ ＳＭＳを受信すると、ＭＳＣは、ＳＧｓインターフェースを介してＭＭＥにページングを送信する。すると今度は、ＭＭＥが、そのＭＭＥのネットワーク内でＵＥをページングする。

ＭＭＥに登録されたＵＥに関しては、ＳＧｓインターフェースを介したＳＭＳの交換（すなわち、規格のリリース９で規定された、ＭＳＣからの「ＳＭＳオーバーＳＧｓ」）と、（規格のリリース１１で規定された、ＳＭ−ＳＣから直接の）「ネイティブＳＭＳ−ｉｎ−ＭＭＥ」機能を使用することとの間に違いがないことに留意されたい。

ＭＭＥは、ＳＭＣ機能およびＳＭＲ機能を含むＳＭＳ手順と、「ＳＭＳのみ」の場合の通常のＥＰＳ／ＩＭＳＩ複合（combined EPS/IMSI）手順とをサポートすることになる。加えて、ＭＭＥは、
・ ブロードキャストされないＬＡＩ（ロケーション・エリアＩＤ）をＵＥに提供し（このＬＡＩは、正しくＣＳ＋ＰＳ複合アタッチされる（combined CS+PS attached）ためにＵＥで必要とされる）、
・ アタッチ／ＴＡＵ受容メッセージで、ＩＭＳＩアタッチが「ＳＭＳのみ」のためであることを示し、
・ ＭＭＥがＭＳＣとのＳＧｓ関連付けを確立することを必要とせずにＳＭＳを転送することができることをＨＳＳに通知する。

ＰＳのみでアタッチされたＵＥが２Ｇ／３Ｇ（すなわち、ＧＥＲＡＮ／ＵＴＲＡＮ）アクセスを介してＳＧＳＮに接続されているときは、ＳＭＳ送信に関して以下の規定がある。

・ ＳＧＳＮとＨＳＳ／ＨＬＲとの間のインターフェースに関し、
○ ＰＳドメインのＮＡＳを介したＳＭＳサービスのサポートは任意であり、ＨＳＳへの加入、ＳＧＳＮのサポート、およびＵＥの指示に依存する。

○ 加入者データがＣＳへの加入を含まない場合、ＨＳＳは、ＳＧＳＮに「ＰＳのみ強制実施（PS-only-enforced）」を指示し、ＳＧＳＮは、ＧＭＭ複合（combined GMM）手順を実行せず、Ｇｓ関連付けを確立しない。

○ ＨＳＳがＳＧＳＮに「ＰＳのみ有効（PS-only-enabled）」を指示し、ＳＧＳＮがＮＡＳをベースとするＳＭＳをサポートする場合、ＳＧＳＮは、Ｇｓ関連付けを確立しない。

・ ＳＧＳＮとＵＥとの間のインターフェースに関し、
○ ＰＳドメインのサービスのみを受けており、ＮＡＳをベースとするＳＭＳに対応しているＵＥは、アタッチ／ＲＡＵ複合手順の間にＳＧＳＮに「ＳＭＳのみ」と通知する。

○ ＳＧＳＮは、アタッチ／ＲＡＵ手順の間にＵＥに「ＳＭＳサポート」と通知する。ＰＳドメインのサービスのみを受けており、ＮＡＳをベースとするＳＭＳに対応しているＵＥは、「ＳＭＳサポート」を受信するとき、ＩＭＳＩアタッチ／ＬＡＵ手順を実行すべきでない。

要約すると、どのエンティティがネイティブのＳＭＳ交換機能をサポートするかに関して４つの異なるケースが特定可能であり、異なるノードに実装されたＳＭＳ機能と、実際に使用されるネットワーク構成とに依存して、ＳＭＳがネットワーク・アーキテクチャの中で送信され得る方法に影響を与える。

「ＳＭＳ ｉｎ ＳＧＳＮ」および「ＳＭＳ ｉｎ ＭＭＥ」という表現は、ＳＧＳＮおよびＭＭＥがＳＭ−ＲＰプロトコルおよびＳＭ−ＣＰプロトコルを実装すること、すなわち、ＳＭＳのネイティブの送信がサポートされることを意味する。

図２５〜２８は、どの場合にどのＳＭＳの交換経路を取り得るのかを示すために、異なるケースの印が付されている。例えば、図２５による交換経路は、実際にはすべてのケースであり得る。ＳＧＳＮおよびＭＭＥがＳＭ−ＣＰ／ＲＰプロトコルを実装するケースＡでは、図２５〜２８の経路のすべてがあり得る。実際にどの経路が使用されるかは、例えば、ネットワーク構成と、ＵＥの位置とに依存する。より詳細に言えば、ＨＳＳ／ＨＬＲが、ＳＭＳ配信のためにＵＥにサービスを提供することになるエンティティ、例えば、ＭＳＣ、ＭＭＥ、またはＳＧＳＮを格納する。それに対応して、ＳＭＳがＳＭＳ−ＳＣに到着するとき、ＳＭＳ−ＳＣは、ＨＳＳ／ＨＬＲと通信して、移動ノードのためのＳＭＳサービング・ノードを知る。したがって、ＵＥがＬＴＥネットワーク内にあると仮定して、ＭＭＥがネイティブのＳＭＳ交換に対応している（すなわち、対応するＳＭ−ＣＰ／ＲＰプロトコルを備える）可能性があっても、ネットワーク構成は、ＨＳＳがＳＭＳ−ＳＣにＭＳＣについて通知するようになっており、この場合、ＭＭＥのこのネイティブのＳＭＳ機能は活用されず、したがって、ＳＭＳは、ＳＧｄインターフェースを介してＭＭＥに直接送信されない。その代わりに、ＳＭＳ−ＳＣは、ＵＥに関連するＭＳＣのアドレスを知り、上述のように（図２５参照）、ＳＭＳを、さらに転送されるように、Ｄインターフェースを介してＭＳＣに送信する。

同様に、ＳＧＳＮがネイティブでＳＭＳを送信することができるにもかかわらず、ＳＭＳ−ＳＣは、ＵＥがＵＴＲＡＮ内にあるとき、やはり、代わりにＭＳＣサーバを使用するようにＨＳＳ／ＨＬＲによって命令される可能性がある（図２８参照）。

４つのケースとあり得るＳＭＳ配信経路とは、以下のようにまとめられる。

ケースＡ：（ＬＴＥまたは２Ｇ／３Ｇで）ＵＥがＳＧＳＮまたはＭＭＥに登録されているとき、ＰＳドメインで（ＭＳＣの関与なしに）ネイティブのＳＭＳ送信が可能である。このケースＡでは、ＵＥは、図２６および２７によれば、ＳＧＳＮまたはＭＭＥに登録されているとき、ＳＭＳをネイティブで送受信することができる。しかし、ネットワーク構成がＳＭＳ−ＳＣにＣＳドメインを関与させるように要求する場合は、図２５および図２８によるＳＭＳ配信の経路もあり得る。

以下の状況においては、問題または不確実性が生じる可能性がある。

１）ＧＥＲＡＮ／ＵＴＲＡＮとＬＴＥとの間のハンドオーバ中。ＳＭＳ ＰＤＵが転送される方法が規定されていない。

２）ＩＳＲが有効化されているときは、ＳＭ−ＳＣがＳＭＳのルーティングのための単一のエンティティを知る必要がある（ＳＭ−ＳＣがＨＬＲ／ＨＳＳにルーティング情報を問い合わせる）ときにＭＴ ＳＭＳのルーティングが明らかにされるべきである。

ケースＢ：ＭＭＥを介したネイティブのＳＭＳ送信が可能である。ＳＧＳＮがネイティブのＳＭＳ送信をサポートしないので、図２７による経路は取り得ない。その代わりに、ＵＥがＵＴＲＡＮネットワーク内にあるとき、ＳＭＳは、図２８の経路によって交換される必要がある。それに対応して、このケースＢでは、ＵＥがＵＴＲＡＮ内にあるときは、ＣＳドメインを介してのみ、ＳＭＳの転送ができる。

ネットワーク事業者がＣＳドメインのエンティティ、例えばＭＳＣを使用することを避けたい場合、問題または不確実性が生じる可能性がある。ＵＥがＧＥＲＡＮアクセスおよびＵＴＲＡＮアクセスを介して接続されているときに、ＳＭＳ ＰＤＵがＵＥに／ＵＥから配信される方法が明らかでない。ケースＣ：ＳＧＳＮを介したネイティブのＳＭＳ送信が可能である。ＭＭＥが、ネイティブのＳＭＳ送信をサポートせず、そのため、ケースＣに関しては、図２６による経路の交換が不可能である。その代わりに、ＬＴＥネットワーク内にあるとき、ＵＥは、ＭＳＣサーバが関与する図２５の経路によってＳＭＳを受信する必要がある。

ネットワーク事業者がＣＳドメインのエンティティ、例えばＭＳＣを使用することを避けたい場合、問題または不確実性が生じる可能性がある。ＵＥがＬＴＥアクセスを介して接続されているときに、ＳＭＳ ＰＤＵがＵＥに／ＵＥから配信される方法が明らかでない。

ケースＤ：ＳＧＳＮもＭＭＥもネイティブのＳＭＳ機能をサポートしないとき、図２６および２７による交換は不可能である。それに対応して、ＭＳＣサーバが、図２５および２８に示すように、ＵＥへのＳＭＳの転送に常に関与する。このケースＤは、ＰＳドメインにおいていかなるＳＭＳ送信もできないので、本出願にとってそれほど重要ではない。

ＳＭＳは、上で説明し、図２５および２８に図示したように、通常、移動通信交換局（ＭＳＣ）が関与する回線交換サービスであると考えられているにもかかわらず、最近、３ＧＰＰの標準化では、ＰＳサービスのみ（ＰＳのみ）に加入および／またはアタッチされているＵＥのためのＳＭＳの送信を実装することが決定された。

上に示されたように、ＭＳＣサーバは、図２５および２８によるＳＭＳ送信に関与する。ケースＢの場合、ＵＥがＵＴＲＡＮ内にあるとき、ＭＳＣサーバなしにＳＭＳを送信することはできない。それに対応して、ケースＣにおいて、ＵＥがＬＴＥ内にあるときに、ＭＳＣサーバなしにＳＭＳを送信することはやはり不可能である。しかし、このことは、ＭＳＣがもはや関与しない、ＵＥのためのＰＳのみのＳＭＳの交換を実現するという目標に反する。

［アイドル状態シグナリング削減（ＩＳＲ：Idle state signaling reduction）機能］
３ＧＰＰは、ＬＴＥアクセスとＵＴＲＡＮ／ＧＥＲＡＮアクセスとの間のＩＤＬＥモードでの移動、すなわち、ＵＥが、サービング・ノードであるＭＭＥとＳＧＳＮとの間を移動する場合の最適化を定義した。この最適化は、ＩＤＬＥモード・シグナリング削減（略してＩＳＲ）と称されており、ＵＥが異なる無線アクセス技術（ＲＡＴ）の間を切り替えるときにいかなるシグナリングも開始しなくて済むようにする。以下で、ＩＳＲ機能の概要を簡単に紹介するが、ＩＳＲのより詳細な検討については３ＧＰＰ ＴＳ２３．４０１ ｖ１１．１．０の付録Ｊを参照することができ、この文献は、３ＧＰＰのサーバからダウンロード可能であり、参照により本明細書に援用される。

ＩＳＲは、一緒に運用されているＥ−ＵＴＲＡＮ（ＬＴＥ）とＧＥＲＡＮ／ＵＴＲＡＮとの間でＵＥが再選択を行うことによって引き起こされるＴＡＵ手順およびＲＡＵ手順の頻度を少なくすることを目的としている。特に、ＵＥとネットワークとの間の更新シグナリングが削減されるが、ネットワーク内部のシグナリングも削減される。

ＩＳＲに固有のノードおよびインターフェース機能にかかるコストを代償として、２Ｇ／３ＧとＥＰＣとの間の依存性が最小化される。ＩＳＲ機能の裏にある考え方は、ＵＥが、Ｅ−ＵＴＲＡＮのＴＡまたはＴＡのリストに登録されているときに、同時に、ＵＴＲＡＮ／ＧＥＲＡＮのＲＡに登録され得ることである。ＵＥは、２つの登録を平行して維持し、両方の登録に関する周期タイマを独立して実行する。同様に、ネットワークは、２つの登録を平行して維持し、さらに、ＵＥが登録されているＲＡとＴＡとの両方でページングされ得ることを保証する。

ＩＳＲのサポートは、ＧＥＲＡＮおよび／またはＵＴＲＡＮをサポートするＥ−ＵＴＲＡＮのＵＥには必須であり、ネットワークには任意である。ＩＳＲは、ＵＥのためのＩＳＲを有効化するために、ＵＥとネットワーク（すなわち、ＳＧＳＮ、ＭＭＥ、サービングＧＷ、およびＨＳＳ）との両方に特別な機能を必要とする。ネットワークは、各ＵＥに関して個別にＩＳＲの有効化を決定することができる。Ｇｎ／Ｇｐ ＳＧＳＮは、ＩＳＲ機能をサポートしない。

ＩＳＲは、Ｓ−ＧＷがＩＳＲをサポートするものとして、ＬＴＥから２Ｇ／３Ｇへのハンドオーバ、または２Ｇ／３ＧからＬＴＥへのハンドオーバの際に有効化される。下りリンク・データがＳ−ＧＷに到着するとき、Ｓ−ＧＷは、サービング・ノードであるＳＧＳＮとＭＭＥとの両方に下りリンク・データ通知（ＤＤＮ：Downlink Data Notification）要求を送信する。

ＩＳＲが有効化されているとき、これは、ＵＥがＭＭＥとＳＧＳＮとの両方に登録されていることを意味する。ＳＧＳＮとＭＭＥとの両方が、サービングＧＷとの制御接続を有する。ＭＭＥとＳＧＳＮとの両方が、ＨＳＳに登録されている。ＵＥは、ＳＧＳＮからのＭＭパラメータ（例えば、Ｐ−ＴＭＳＩおよびＲＡ）と、ＭＭＥからのＭＭパラメータ（例えば、ＧＵＴＩおよび（１つまたは複数の）ＴＡ）とを格納し、Ｅ−ＵＴＲＡＮアクセスおよびＧＥＲＡＮ／ＵＴＲＡＮアクセスに共通であるセッション管理（ベアラ）コンテキストを格納する。アイドル状態で、ＵＥは、ネットワークとのＴＡＵ手順またはＲＡＵ手順を実行することをまったく必要とせずに、（登録されたＲＡおよびＴＡ内で）Ｅ−ＵＴＲＡＮとＧＥＲＡＮ／ＵＴＲＡＮとの間の再選択を行うことができる。ＩＳＲが有効化されているとき、ＳＧＳＮおよびＭＭＥは、互いのアドレスを格納する。

１つのＣＮノード（ＳＧＳＮか、またはＭＭＥかのどちらか）による暗黙的なデタッチによって、ネットワークのＩＳＲが無効化される。ＩＳＲは、ＵＥが周期的な更新を遅れずに実行することができないとき、ＵＥにおいて無効化される。

上で説明したように、最近確定した標準化目標は、ＰＳのみの場合の、すなわち、ＭＳＣサーバが関与しないＳＭＳ配信を可能にすることである。しかし、移動体がＩＤＬＥ状態であり、ＩＳＲを有効化するときのＳＭＳ配信は、今のところ正式に定義されていない。ＩＳＲが有効化されていると、ＵＥがＲＡＵおよびＴＡＵを行うことを避けるので、ＨＳＳは、ＵＥがＬＴＥ内にあるのか、またはＵＴＲＡＮ内にあるのかが分からない。結果として、ＳＭＳ−ＳＣは、ＨＳＳから２つのアドレス、すなわち、ＳＧＳＮおよびＭＭＥのアドレスを取得することとなる。そのとき、ＳＭＳ−ＳＣは、ＭＴ ＳＭＳをＳＧＳＮおよびＭＭＥにマルチキャストしなければならないが、これは、ＳＭＳ−ＳＣがＳＭＳを転送する１つの特定の送信先を必要とするため、現在は不可能である。

ＵＥがＩＤＬＥ状態にあり、ＩＳＲを有効化するときにＳＭＳを配信するための手順が必要とされている。

ＩＳＲがＵＥに関して有効化されていないときは、ＨＳＳは、ＵＥがどのネットワーク内にあるかを常に正確に知っており、したがって、ＭＭＥであろうがＳＧＳＮであろうが、対応するサービング・ノードについてＳＭＳ−ＳＣに知らせることができる。

［ＬＴＥからＵＴＲＡＮ無線アクセスへのハンドオーバ］
不必要なシグナリングを回避するためにＩＳＲを使用する、ＵＥがＩＤＬＥモードであるときのＵＥの移動と、それに起因する問題とを上で簡単に説明した。以降で、ＵＥがＣＯＮＮＥＣＴＥＤモードであるときのＵＥの移動について説明し、特に、ＬＴＥからＵＴＲＡＮへのＲＡＴ間ハンドオーバについて説明する。３ＧＰＰ ＴＳ２３．４０１ ｖ１１．１．０の５．５．２章は、ＲＡＴ間ハンドオーバについて極めて詳細に説明しており参照により本明細書に援用され、特に、５．５．２．１章および５．５．２．２章が、Ｅ−ＵＴＲＡＮ（ＬＴＥ）とＵＴＲＡＮとの間のＲＡＴ間ハンドオーバについて記載している。５．５．２．１章が、もっぱら本出願に関連があり、理解の助けとなる範囲で以下に概要を述べる。

図２６は、ＲＡＴ間ハンドオーバの準備フェーズでネットワークにおいて実行されるメッセージ交換を示しており、ＴＳ２３．４０１の図５．５．２．１．２−１に対応している。図２６のさまざまなステップは、ＴＳ２３．４０１の５．５．２．１．２章で極めて詳細に説明されており、それを以下に再掲する。

１．ハンドオーバ元ｅＮｏｄｅＢが、ハンドオーバ先アクセス・ネットワークであるＵＴＲＡＮ Ｉｕモード（UTRAN Iu mode）へのＲＡＴ間ハンドオーバを開始することを決定する。この時点で、上りリンク・ユーザ・データと下りリンク・ユーザ・データとの両方は、以下、すなわち、ＵＥとハンドオーバ元ｅＮｏｄｅＢとの間の（１つまたは複数の）ベアラ、ハンドオーバ元ｅＮｏｄｅＢと、サービングＧＷと、ＰＤＮ ＧＷとの間の（１つまたは複数の）ＧＴＰトンネルを介して送信される。

ＵＥが実行中の緊急ベアラ・サービスを有する場合、ハンドオーバ元ｅＮｏｄｅＢは、ＩＭＳ音声に対応していないＵＴＲＡＮセルへのＰＳハンドオーバを開始しない。

注１：ハンドオーバの決定に至るプロセスは、本明細書の範囲外である。

２．ハンドオーバ元ｅＮｏｄｅＢが、ハンドオーバ要請（Handover Required）（Ｓ１ＡＰ理由（S1AP Cause）、ハンドオーバ先ＲＮＣ識別子、ＣＳＧ ＩＤ、ＣＳＧアクセス・モード、ハンドオーバ元−ハンドオーバ先透過コンテナ（Source to Target Transparent Container））メッセージをハンドオーバ元ＭＭＥに送信して、ハンドオーバ先ＲＮＣ、ハンドオーバ先ＳＧＳＮ、およびサービングＧＷにおいてリソースを確立するようにＣＮに要求する。（もしあれば）データ転送の対象となるベアラが、後のステップで、ハンドオーバ先ＳＧＳＮによって特定される（下のステップ７参照）。ハンドオーバ先セルがＣＳＧセルまたはハイブリッド・セルであるとき、ハンドオーバ元ｅＮｏｄｅＢは、ハンドオーバ先セルのＣＳＧ ＩＤを含めることになる。ハンドオーバ先セルがハイブリッド・セルである場合、ＣＳＧアクセス・モードが指示されることになる。

３．ハンドオーバ元ＭＭＥが、「ハンドオーバ先ＲＮＣ識別子」ＩＥから、ハンドオーバの種類がＵＴＲＡＮ ＩｕモードへのＩＲＡＴハンドオーバであると判定する。ハンドオーバ元ＭＭＥは、フォワード再配置要求（Forward Relocation Request）（ＩＭＳＩ、ハンドオーバ先ＩＤ、ＣＳＧ ＩＤ、ＣＳＧメンバーシップ指示、ＭＭコンテキスト、ＰＤＮ接続、制御プレーンのためのＭＭＥトンネル・エンドポイント識別子、制御プレーンのためのＭＭＥアドレス、ハンドオーバ元−ハンドオーバ先透過コンテナ、ＲＡＮ理由（RAN Cause）、ＭＳ情報変更報告アクション（MS Info Change Reporting Action）（利用可能な場合）、ＣＳＧ情報報告アクション（CSG Information Reporting Action）（利用可能な場合）、ＵＥタイム・ゾーン、ＩＳＲサポート（ISR Supported）、サービング・ネットワーク）メッセージをハンドオーバ先ＳＧＳＮに送信することによってハンドオーバ・リソース割り当て手順を開始する。ＩＳＲサポートの情報は、ハンドオーバ元ＭＭＥおよび関連するサービングＧＷがＵＥのＩＳＲを有効化することができる場合に示される。ＩＳＲが有効化されているとき、このメッセージは、ハンドオーバ先ＩＤによって特定されるハンドオーバ先にサービスを提供しているときにＵＥのＩＳＲを維持するＳＧＳＮに送信されるべきである。このメッセージは、ハンドオーバ元システムでアクティブなすべてのＰＤＮ接続を含み、各ＰＤＮ接続に関して、関連するＡＰＮ、制御プレーンのためのサービングＧＷのアドレスおよび上りリンク・トンネル・エンドポイント・パラメータ、ならびにＥＰＳベアラ・コンテキストのリストを含む。ＲＡＮ理由は、ハンドオーバ元ｅＮｏｄｅＢから受信されるＳ１ＡＰ理由を示す。ハンドオーバ先ＭＭＥがサービング・ネットワークが変更されるか否かを決定するのを支援するために、古いサービング・ネットワークがハンドオーバ先ＭＭＥに送信される。

ハンドオーバ元ＭＭＥは、ハンドオーバ元ｅＮｏｄｅＢによってＣＳＧ ＩＤが与えられているとき、ＵＥのＣＳＧ加入について調べることによってアクセス制御を実行することになる。このＣＳＧ ＩＤの加入データが存在しないか、またはＣＳＧ加入が失効しており、ハンドオーバ先セルがＣＳＧセルである場合、ハンドオーバ元ＭＭＥは、ＵＥが緊急ベアラ・サービスをも持たない限り、適切な理由のハンドオーバを拒否することになる。

ハンドオーバ元ＭＭＥは、ハンドオーバ先セルがＣＳＧセルまたはハイブリッド・セルであるとき、フォワード再配置要求にＣＳＧ ＩＤを含める。ハンドオーバ先セルがハイブリッド・セルであるとき、または１つもしくは複数の緊急ベアラが存在し、ハンドオーバ先セルがＣＳＧセルである場合、ＵＥがＣＳＧのメンバーであるか否かを示すＣＳＧメンバーシップ指示が、フォワード再配置要求メッセージに含められることになる。

ハンドオーバ先ＳＧＳＮは、ＴＳ２３．４０１の付録Ｅで定義されているように、ＥＰＳベアラをＰＤＰコンテキストに１対１でマッピングし、ＥＰＳベアラのＥＰＳベアラＱｏＳパラメータ値をベアラ・コンテキストのリリース９９ ＱｏＳパラメータ値にマッピングする。

ＰＤＰコンテキストの優先順位付けが、ハンドオーバ先コア・ネットワーク・ノード、すなわち、ハンドオーバ先ＳＧＳＮによって実行される。

ＭＭコンテキストは、ＴＳ２９．２７４に記載されているように、セキュリティに関連する情報、例えば、サポートされる暗号化アルゴリズムを含む。セキュリティ・キーの処理については、ＴＳ３３．４０１に記載されている。

ハンドオーバ先ＳＧＳＮは、フォワード再配置要求内のそれぞれのベアラ・コンテキストのＡＰＮ制限（APN Restriction）に基づいて最大ＡＰＮ制限（Maximum APN restriction）を決定し、続いて、新しい最大ＡＰＮ制限値を格納することになる。

４．ハンドオーバ先ＳＧＳＮが、例えば、ＰＬＭＮの変更が原因でサービングＧＷが再配置されるべきか否かを判定する。サービングＧＷが再配置されるべきである場合、ハンドオーバ先ＳＧＳＮは、「サービングＧＷ選択機能」に関するＴＳ２３．４０１の４．３．８．２項に記載されているように、ハンドオーバ先サービングＧＷを選択し、ハンドオーバ先サービングＧＷにＰＤＮ接続ごとにセッション生成要求メッセージ（ＩＭＳＩ、制御プレーンのためのＳＧＳＮトンネル・エンドポイント識別子、制御プレーンのためのＳＧＳＮアドレス、ユーザ・プレーンのための（１つまたは複数の）ＰＤＮ ＧＷアドレス、ユーザ・プレーンのための（１つまたは複数の）ＰＤＮ ＧＷ ＵＬ ＴＥＩＤ、制御プレーンのための（１つまたは複数の）ＰＤＮ ＧＷアドレス、制御プレーンのための（１つまたは複数の）ＰＤＮ ＧＷ ＴＥＩＤ、Ｓ５／Ｓ８上のプロトコル・タイプ、サービング・ネットワーク）を送信する。Ｓ５／Ｓ８上のプロトコル・タイプが、サービングＧＷに与えられ、そのプロトコルが、Ｓ５／Ｓ８インターフェースで使用されなければならない。

ハンドオーバ先ＳＧＳＮは、指示された順序で（１つまたは複数の）ＥＰＳベアラ・コンテキストを確立する。ＳＧＳＮは、実行フェーズのステップ７で行われるように、確立することができないＥＰＳベアラ・コンテキストを無効化する。

４ａ．ハンドオーバ先サービングＧＷが、そのサービングＧＷのローカル・リソースを割り当て、セッション生成応答（ユーザ・プレーンのための（１つまたは複数の）サービングＧＷアドレス、ユーザ・プレーンのための（１つまたは複数の）サービングＧＷ ＵＬ ＴＥＩＤ、制御プレーンのためのサービングＧＷアドレス、制御プレーンのためのサービングＧＷ ＴＥＩＤ）メッセージをハンドオーバ先ＳＧＳＮに返す。

５．ハンドオーバ先ＳＧＳＮが、再配置要求メッセージ（ＵＥ識別子、理由、ＣＮドメイン・インジケータ、完全性保護情報（すなわち、ＩＫおよび許される完全性保護アルゴリズム）、暗号化情報（すなわち、ＣＫおよび許される暗号化アルゴリズム）、設定されるべきＲＡＢのリスト、ＣＳＧ ＩＤ、ＣＳＧメンバーシップ指示、ハンドオーバ元ＲＮＣ−ハンドオーバ先ＲＮＣ透過コンテナ（Source RNC to Target RNC Transparent Container）、サービス・ハンドオーバ関連情報）を送信することによって、無線ネットワーク・リソース（ＲＡＢ）を確立するようにハンドオーバ先ＲＮＣに要求する。アクセス制限がＭＭコンテキストに存在する場合、接続モードのＵＥがアクセス制限によって禁止されたＲＡＴにハンドオーバすることをＲＮＣが制限するために、サービス・ハンドオーバ関連情報が、ハンドオーバ先ＳＧＳＮによって再配置要求メッセージに含められることになる。

確立されることが要求されるそれぞれのＲＡＢについて、設定されるべきＲＡＢは、ＲＡＢ ＩＤ、ＲＡＢパラメータ、トランスポート層アドレス、およびＩｕトランスポート関連付け（Iu Transport Association）などの情報を含む。ＲＡＢ ＩＤ情報要素は、ＮＳＡＰＩ値を含み、ＲＡＢパラメータ情報要素は、ＱｏＳプロファイルを与える。トランスポート層アドレスは、ユーザ・プレーンのためのサービングＧＷアドレス（ダイレクト・トンネル（Direct Tunnel）が使用される場合）またはユーザ・プレーンのためのＳＧＳＮアドレス（ダイレクト・トンネルが使用されない場合）であり、Ｉｕトランスポート関連付けは、サービングＧＷまたはＳＧＳＮの上りリンク・トンネル・エンドポイント識別子データにそれぞれ対応する。

暗号化キーおよび完全性保護キーが、新たにＡＫＡ（Authentication and Key Agreement：認証および鍵合意）手順を行うことを必要とせずに新しいＲＡＴ／モードのハンドオーバ先セルでデータ転送が継続できるようにするために、ハンドオーバ先ＲＮＣに送信される。ハンドオーバ先ＲＮＣのＲＲＣからＵＥに（再配置命令メッセージでか、またはハンドオーバ完了メッセージの後でかのどちらかで）送信される必要がある情報が、透過コンテナによってハンドオーバ先ＲＮＣからＵＥに送信されるＲＲＣメッセージに含められることになる。さらなる詳細は、ＴＳ３３．４０１に記載されている。

ハンドオーバ先ＳＧＳＮは、ハンドオーバ元ＭＭＥによって与えられるとき、ＣＳＧ ＩＤおよびＣＳＧメンバーシップ指示をフォワード再配置要求メッセージに含めることになる。

ハンドオーバ先ＲＮＣにおいては、無線およびＩｕユーザ・プレーン・リソースが、受容されたＲＡＢのために予約される。理由は、ハンドオーバ元ＭＭＥから受信されたＲＡＮ理由を示す。ハンドオーバ元ＲＮＣ−ハンドオーバ先ＲＮＣ透過コンテナは、ハンドオーバ元ｅＮｏｄｅＢから受信されたハンドオーバ元−ハンドオーバ先透過コンテナからの値を含む。

ハンドオーバ先セルがＣＳＧセルである場合、ハンドオーバ先ＲＮＣは、ハンドオーバ先ＳＧＳＮによって与えられたＣＳＧ ＩＤを検証し、そのＣＳＧ ＩＤがハンドオーバ先セルのＣＳＧ ＩＤと合致しない場合、適切な理由のハンドオーバを拒否することになる。ハンドオーバ先セルがハイブリッド・モードである場合、ハンドオーバ先ＲＮＣは、ＣＳＧメンバーシップ指示を使用して、ＣＳＧメンバーと非ＣＳＧメンバーとに差別化された処理を実行することができる。ハンドオーバ先セルがＣＳＧセルであり、ＣＳＧメンバーシップ指示が「非メンバー」である場合、ハンドオーバ先ＲＮＣは、緊急ベアラのみを受け入れる。

５ａ．ハンドオーバ先ＲＮＣが、リソースを割り当て、再配置要求ＡＣＫメッセージ（ハンドオーバ先ＲＮＣ−ハンドオーバ元ＲＮＣ透過コンテナ（Target RNC to Source RNC Transparent Container）、ＲＡＢ設定リスト、ＲＡＢ設定失敗リスト）でハンドオーバ先ＳＧＳＮに適用可能なパラメータを返す。

再配置要求ＡＣＫメッセージを送信すると、ハンドオーバ先ＲＮＣは、サービングＧＷから、またはダイレクト・トンネルが使用されない場合はハンドオーバ先ＳＧＳＮから、受容されたＲＡＢの下りリンクＧＴＰ ＰＤＵを受信するように準備されることになる。

各ＲＡＢ設定リストは、ユーザ・データのためのハンドオーバ先ＲＮＣアドレスであるトランスポート層アドレスと、ユーザ・データのための下りリンク・トンネル・エンドポイント識別子に対応するＩｕトランスポート関連付けとによって定義される。

ＲＡＢが確立されなかったどのＥＰＳベアラ・コンテキストも、ハンドオーバ先ＳＧＳＮおよびＵＥで維持される。これらのＥＰＳベアラ・コンテキストは、ルーティング・エリア更新（ＲＡＵ）手順が完了すると、明示的なＳＭ手順を介してハンドオーバ先ＳＧＳＮによって無効化されることになる。

６．「間接転送（Indirect Forwarding）」およびサービングＧＷの再配置が適用され、ダイレクト・トンネルが使用される場合、ハンドオーバ先ＳＧＳＮが、間接データ転送トンネル生成要求メッセージ（ＤＬデータ転送のためのハンドオーバ先ＲＮＣアドレスおよび（１つまたは複数の）ＴＥＩＤ）をサービングＧＷに送信する。「間接転送」およびサービングＧＷの再配置が適用され、ダイレクト・トンネルが使用されない場合は、ハンドオーバ先ＳＧＳＮが、間接データ転送トンネル生成要求メッセージ（ＤＬデータ転送のためのＳＧＳＮアドレスおよび（１つまたは複数の）ＴＥＩＤ）をサービングＧＷに送信する。

間接転送は、ＵＥのためのアンカー・ポイントとして使用されるサービングＧＷとは異なるサービングＧＷによって実行され得る。

６ａ．サービングＧＷが、間接データ転送トンネル生成応答（理由、データ転送のための（１つまたは複数の）サービングＧＷアドレスおよび（１つまたは複数の）サービングＧＷ ＤＬ ＴＥＩＤ）メッセージをハンドオーバ先ＳＧＳＮに返す。

７．ハンドオーバ先ＳＧＳＮが、フォワード再配置応答（Forward Relocation Response）メッセージ（理由、制御プレーンのためのＳＧＳＮトンネル・エンドポイント識別子、制御プレーンのためのＳＧＳＮアドレス、ハンドオーバ先−ハンドオーバ元透過コンテナ（Target to Source Transparent Container）、理由、ＲＡＢ設定情報、追加ＲＡＢ設定情報、ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ、サービングＧＷ変更指示）をハンドオーバ元ＭＭＥに送信する。サービングＧＷ変更指示は、新しいサービングＧＷが選択されたことを示す。ハンドオーバ先−ハンドオーバ元透過コンテナは、ハンドオーバ先ＲＮＣから受信されたハンドオーバ先ＲＮＣ−ハンドオーバ元ＲＮＣ透過コンテナからの値を含む。

ＩＥである「ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ」は、ハンドオーバ先システム内のデータ転送のための送信先トンネリング・エンドポイント（destination tunneling endpoint）を定義し、以下のように設定される。

− 「直接転送」が適用される場合、または「間接転送」が適用され、サービングＧＷの再配置が適用されず、ダイレクト・トンネルが使用される場合、ＩＥである「ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ」は、ステップ５ａで受信されたハンドオーバ先ＲＮＣへのアドレスおよびＧＴＰ−Ｕトンネル・エンドポイント・パラメータを含む。

− 「間接転送」およびサービングＧＷの再配置が適用される場合、ＩＥである「ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ」は、ステップ６で受信されたサービングＧＷへのアドレスおよびＤＬ ＧＴＰ−Ｕトンネル・エンドポイント・パラメータを含む。これは、ダイレクト・トンネルを使用するか否かということと無関係である。

− 「間接転送」が適用され、ダイレクト・トンネルが使用されず、サービングＧＷの再配置が適用されない場合、ＩＥである「ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ」は、ハンドオーバ先ＳＧＳＮへのＤＬ ＧＴＰ−Ｕトンネル・エンドポイント・パラメータを含む。

８．「間接転送」が適用される場合、ハンドオーバ元ＭＭＥは、間接データ転送トンネル生成要求メッセージ（（ステップ７で受信された）データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ、（１つまたは複数の）ＥＰＳベアラＩＤ）を間接転送に使用されるサービングＧＷに送信する。

間接転送は、ＵＥのためのアンカー・ポイントとして使用されるサービングＧＷとは異なるサービングＧＷによって実行され得る。

８ａ．サービングＧＷが、間接データ転送トンネル生成応答メッセージ（理由、データ転送のための（１つまたは複数の）サービングＧＷアドレスおよび（１つまたは複数の）ＴＥＩＤ）を送信することによって転送パラメータを返す。サービングＧＷがデータ転送をサポートしない場合、適切な理由の値が返されることとなり、（１つまたは複数の）サービングＧＷアドレスおよび（１つまたは複数の）ＴＥＩＤはメッセージに含められない。

図２７は、ＴＳ２３．４０１で定義されたＥ−ＵＴＲＡＮからＵＴＲＡＮ ＩｕモードへのＲＡＴ間ハンドオーバの実行フェーズを示しており、ＴＳ２３．４０１の図５．５．２．１．３−１に対応する。図２７のさまざまなステップは、ＴＳ２３．４０１の５．５．２．１．３章で極めて詳細に説明されており、以下に再掲される。

ハンドオーバ元ｅＮｏｄｅＢは、下りリンクおよび上りリンクのユーザ・プレーンのＰＤＵを受信し続ける。

１．ハンドオーバ元ＭＭＥが、ハンドオーバ命令メッセージ（ハンドオーバ先−ハンドオーバ元透過コンテナ、解放すべきＥ−ＲＡＢリスト、データ転送対象ベアラ・リスト）を送信することによってハンドオーバ元ｅＮｏｄｅＢに対する準備フェーズを完了する。「データ転送対象ベアラ・リスト」ＩＥがメッセージに含められる可能性があり、このＩＥは、「直接転送」が適用されるときに準備フェース（準備フェーズのステップ７）でハンドオーバ先側から受信された「ユーザ・トラフィック・データ転送のための（１つまたは複数の）アドレスおよび（１つまたは複数の）ＴＥＩＤ」のリストであるか、または「間接転送」が適用されるときに準備フェーズのステップ８ａで受信されたパラメータのリストである。

ハンドオーバ元ｅＮｏｄｅＢは、「データ転送対象ベアラ・リスト」で指定されたベアラのデータ転送を開始する。データ転送は、ハンドオーバ先ＲＮＣに直接向けられるか、あるいは、準備フェーズでハンドオーバ元ＭＭＥおよび／またはハンドオーバ先ＳＧＳＮによってサービングＧＷを経由するように決定されている場合は、サービングＧＷを経由する可能性がある。

２．ハンドオーバ元ｅＮｏｄｅＢが、Ｅ−ＵＴＲＡＮからのＨＯ命令（HO from E-UTRAN Command）メッセージによって、ハンドオーバ先アクセス・ネットワークにハンドオーバするようにＵＥに命令を与える。このメッセージは、ハンドオーバ先ＲＮＣが準備フェーズで設定した無線アスペクト・パラメータ（radio aspect parameter）を含む透過コンテナを含む。このＥ−ＵＴＲＡＮに固有のシグナリングの詳細は、ＴＳ３６．３００に記載されている。

ハンドオーバ命令メッセージを含むＥ−ＵＴＲＡＮからのＨＯ命令メッセージを受信すると、ＵＥは、そのＵＥのベアラＩＤをＮＳＡＰＩとの関係に基づいてそれぞれのＲＡＢに関連付けることになり、ユーザ・プレーン・データの上りリンク送信を中断することになる。

３．なし。

４．ＵＥが、ハンドオーバ先ＵＴＲＡＮ Ｉｕ（３Ｇ）システムに移り、ステップ２で配信されたメッセージで与えられたパラメータにしたがってハンドオーバを実行する。この手順は、受信されたＲＡＢと、特定のＮＳＡＰＩに関連する既存のベアラＩＤとを関連付ける追加機能を用いた、ＴＳ４３．１２９ ５．２．２．２項のステップ６および８の手順と同じである。

ＵＥは、ハンドオーバ先ＲＮＣで無線リソースを割り当てられたＮＳＡＰＩについてのみユーザ・データの転送を再開することができる。

５．新しいハンドオーバ元ＲＮＣ−ＩＤ＋Ｓ−ＲＮＴＩがＵＥとの間で正常に交換されるとき、ハンドオーバ先ＲＮＣは、再配置完了メッセージをハンドオーバ先ＳＧＳＮに送信することになる。再配置完了手順の目的は、ハンドオーバ先ＲＮＣによって、ハンドオーバ元Ｅ−ＵＴＲＡＮからそのＲＮＣへの再配置の完了を示すことである。再配置完了メッセージを受信した後、ハンドオーバ先ＳＧＳＮは、ハンドオーバ先ＲＮＣからデータを受信するように準備されることになる。ハンドオーバ先ＳＧＳＮによって受信されたそれぞれの上りリンクＮ−ＰＤＵは、サービングＧＷに直接転送される。

６．そのとき、ハンドオーバ先ＳＧＳＮは、ＵＥがハンドオーバ先側に到達したことを知り、フォワード再配置完了通知（Forward Relocation Complete Notification）（ＩＳＲ有効化（ISR Activated）、サービングＧＷ変更）メッセージを送信することによって、ハンドオーバ元ＭＭＥに通知する。指示される場合、ＩＳＲ有効化は、ハンドオーバ元ＭＭＥに、そのハンドオーバ元ＭＭＥがＵＥのコンテキストを維持することになり、ＩＳＲを有効化することになることを示し、これは、ＳＧＷが変更されないときにのみ起こり得る。さらに、ハンドオーバ元ＭＭＥは、この情報に肯定応答する。ハンドオーバ元ｅＮｏｄｅＢおよびハンドオーバ元サービングＧＷ（サービングＧＷを再配置する場合）のリソースがいつ解放されることになるかを管理するために、ハンドオーバ元ＭＭＥのタイマが開始される。

タイマが切れ、ＩＳＲ有効化がハンドオーバ先ＳＧＳＮから指示されない場合、ハンドオーバ元ＭＭＥは、ＵＥのすべてのベアラ・リソースを解放する。サービングＧＷ変更が指示され、このタイマが切れる場合、ハンドオーバ元ＭＭＥは、セッション削除要求（理由、動作指示（Operation Indication））メッセージをハンドオーバ元サービングＧＷに送信することによってＥＰＳベアラ・リソースを削除する。動作指示フラグが設定されず、それにより、ハンドオーバ元サービングＧＷがＰＤＮ ＧＷに対する削除手順を開始しないことをハンドオーバ元サービングＧＷに示す。この手順の前にＩＳＲが有効化されていない場合、理由が、ハンドオーバ元ＳＧＷがその他の古いＣＮノードに（１つまたは複数の）ベアラ削除要求メッセージを送信することによってそのＣＮノードのベアラ・リソースを削除することになることをハンドオーバ元ＳＧＷに示す。

フォワード再配置完了ＡＣＫ（Forward Relocation Complete Acknowledge）メッセージを受信すると、ハンドオーバ先ＳＧＳＮは、そのハンドオーバ先ＳＧＳＮが間接転送のためにＳＧＷにリソースを割り当てた場合、タイマを開始する。

７．このとき、ハンドオーバ先ＳＧＳＮは、今やハンドオーバ先ＳＧＳＮがＵＥが確立したすべてのＥＰＳベアラ・コンテキストを担っていることをサービングＧＷ（サービングＧＷを再配置する場合、これはハンドオーバ先サービングＧＷである）に通知することによってハンドオーバ手順を完了する。これは、ＰＤＮ接続ごとにベアラ修正要求メッセージ（制御プレーンのためのＳＧＳＮトンネル・エンドポイント識別子、（１つまたは複数の）ＮＳＡＰＩ、制御プレーンのためのＳＧＳＮアドレス、受容されたＥＰＳベアラのユーザ・トラフィックのための（１つもしくは複数の）ＳＧＳＮアドレスおよび（１つもしくは複数の）ＴＥＩＤ（ダイレクト・トンネルが使用されない場合）、または受容されたＥＰＳベアラのユーザ・トラフィックのための（１つもしくは複数の）ＲＮＣアドレスおよび（１つもしくは複数の）ＴＥＩＤ（ダイレクト・トンネルが使用される場合）、ならびにＲＡＴの種類、ＩＳＲ有効化）で行われる。ＰＤＮ ＧＷがＵＥの位置および／またはユーザのＣＳＧ情報（ＵＥコンテキストから判定される）を要求した場合、ＳＧＳＮは、このメッセージにユーザ位置情報ＩＥおよび／またはユーザＣＳＧ情報ＩＥも含める。ＵＥタイム・ゾーンが変わった場合、ＳＧＳＮは、このメッセージにＵＥタイム・ゾーンＩＥを含める。サービングＧＷが再配置されないが、サービング・ネットワークが変わった場合、またはＳＧＳＮが古いＭＭＥから古いサービング・ネットワーク情報をまったく受信しなかった場合、ＳＧＳＮは、このメッセージに新しいサービング・ネットワークＩＥを含める。ネットワークを共有するシナリオにおいて、サービング・ネットワークとは、サービング・コア・ネットワークを表す。指示される場合、ＩＳＲ有効化の情報は、ＩＳＲが有効化されることを示し、これは、ＳＧＷが変更されないときにのみ起こり得る。ベアラ修正要求がＩＳＲ有効化を指示せず、ＳＧＷが変更されていないとき、ＳＧＷは、予約されたＳＧＷ上のベアラ・リソースを有するその他のＣＮノードにベアラ削除要求を送信することによってすべてのＩＳＲリソースを削除する。

ＳＧＳＮは、ベアラ・コンテキスト無効化手順をトリガすることによって、受容されなかったＥＰＳベアラ・コンテキストを解放する。サービングＧＷは、受容されなかったベアラのＤＬパケットを受信する場合、そのＤＬパケットを破棄し、下りリンク・データ通知をＳＧＳＮに送信しない。

８．サービングＧＷ（サービングＧＷを再配置する場合、これはハンドオーバ先サービングＧＷである）が、ＰＤＮ接続ごとにベアラ修正要求メッセージを送信することによって、例えば、サービングＧＷを再配置する場合、例えば、課金に使用できるＲＡＴの種類の変更を（１つまたは複数の）ＰＤＮ ＧＷに知らせることができる。さらに、ＳＧＷは、ユーザ位置情報ＩＥおよび／またはＵＥタイム・ゾーンＩＥおよび／またはユーザＣＳＧ情報ＩＥがステップ７で存在する場合、それらのＩＥを含める。サービング・ネットワークは、ＴＳ２３．４０１の５．５．２．１．２項のステップ７またはステップ４で受信される場合、含められるべきである。サービングＧＷを再配置する場合、サービングＧＷは、受容されなかったベアラに関してもＳ５／Ｓ８でＤＬ ＴＥＩＤを割り当てる。ＰＤＮ ＧＷは、ベアラ修正応答メッセージで要求に肯定応答しなければならない。サービングＧＷを再配置する場合、ＰＤＮ ＧＷは、そのＰＤＮ ＧＷのコンテキスト・フィールドを更新し、ベアラ修正応答（課金ＩＤ（Charging Id）、ＭＳＩＳＤＮなど）メッセージをサービングＧＷに返す。ＰＤＮ ＧＷがそのＰＤＮ ＧＷのＵＥコンテキストにＭＳＩＳＤＮを格納している場合、ＭＳＩＳＤＮが含められる。

ＰＣＣインフラストラクチャが使用されている場合、ＰＤＮ ＧＷは、例えば、ＲＡＴの種類の変更についてＰＣＲＦに通知する。

９．サービングＧＷ（サービングＧＷを再配置する場合、これはハンドオーバ先サービングＧＷである）が、ベアラ修正応答メッセージ（理由、制御プレーンのためのサービングＧＷトンネル・エンドポイント識別子、制御プレーンのためのサービングＧＷアドレス、プロトコル構成オプション（Protocol Configuration Options））によってハンドオーバ先ＳＧＳＮへのユーザ・プレーンの切り替えを承認する。この段階で、ユーザ・プレーンの経路が、ＵＥと、ハンドオーバ先ＲＮＣと、ダイレクト・トンネルが使用されない場合はハンドオーバ先ＳＧＳＮと、サービングＧＷ（サービングＧＷを再配置する場合、これはハンドオーバ先サービングＧＷである）と、ＰＤＮ ＧＷとの間ですべてのＥＰＳベアラ・コンテキストに関して確立される。

サービングＧＷが変わらない場合、サービングＧＷは、経路を切り替えた後直ちに、古い経路で１つまたは複数の「エンド・マーカー（end marker）」パケットを送信することになる。

１０．ＵＥがそのＵＥの現在のルーティング・エリアがネットワークに登録されていないと認識するとき、またはＵＥのＴＩＮが「ＧＵＴＩ」を示すとき、ハンドオーバ先ＳＧＳＮがＵＥにそのＵＥが新しいルーティング・エリア内にあることを知らせることによって、ＵＥがルーティング・エリア更新手順を開始する。ＰＭＭ−ＣＯＮＮＥＣＴＥＤ状態のＵＥにルーティング・エリア情報を提供するのは、ＲＡＮ機能である。

ハンドオーバ先ＳＧＳＮは、ハンドオーバ・メッセージによって（１つまたは複数の）ベアラ・コンテキストを受信しているので、このＵＥに関してＩＲＡＴハンドオーバが実行されたことを知っており、したがって、ＲＡＵ手順の一部のみを実行し、特に、ハンドオーバ元ＭＭＥとハンドオーバ先ＳＧＳＮとの間のコンテキスト転送手順を省く。

１１．ステップ６で開始されたタイマが切れるとき、ハンドオーバ元ＭＭＥが、リソース解放メッセージをハンドオーバ元ｅＮｏｄｅＢに送信する。ハンドオーバ元ｅＮｏｄｅＢは、そのハンドオーバ元ｅＮｏｄｅＢのＵＥに関連するリソースを解放する。

ステップ６で開始されたタイマが切れるとき、ハンドオーバ元ＭＭＥがフォワード再配置応答メッセージでサービングＧＷ変更指示を受信した場合、ハンドオーバ元ＭＭＥは、セッション削除要求（理由、動作指示）メッセージをハンドオーバ元サービングＧＷに送信することによってＥＰＳベアラ・リソースを削除する。動作指示フラグが設定されず、それにより、ハンドオーバ元サービングＧＷがＰＤＮ ＧＷに対する削除手順を開始しないことをハンドオーバ元サービングＧＷに示す。ハンドオーバ元サービングＧＷは、セッション削除応答（理由）メッセージによって肯定応答する。この手順の前にＩＳＲが有効化されていない場合、理由が、ハンドオーバ元ＳＧＷがその他の古いＣＮノードに（１つまたは複数の）ベアラ削除要求メッセージを送信することによってそのＣＮノードのベアラ・リソースを削除することになることをハンドオーバ元ＳＧＷに示す。

１２．間接転送が使用された場合、ステップ６で開始されたハンドオーバ元ＭＭＥのタイマが切れると、間接転送のために使用された一時リソースを解放するために間接データ転送トンネル削除要求メッセージをＳＧＷに送信するようにハンドオーバ元ＭＭＥがトリガされる。

１３．間接転送が使用され、サービングＧＷが再配置されている場合、ステップ６で開始されたハンドオーバ先ＳＧＳＮのタイマが切れると、間接転送のために使用された一時リソースを解放するために間接データ転送トンネル削除要求メッセージをハンドオーバ先ＳＧＷに送信するようにハンドオーバ先ＳＧＳＮがトリガされる。

以上、Ｅ−ＵＴＲＡＮ（ＬＴＥ）からＵＴＲＡＮへのＲＡＴ間ハンドオーバのためのハンドオーバ手順を説明した。ここで、ＵＥがＣＯＮＮＥＣＴＥＤモードであり、現在ＳＭＳを受信しているシナリオを考えると、ＵＥがＬＴＥからＵＴＲＡＮへのハンドオーバを実行するとき、ＳＭＳがハンドオーバ後にどのようにしてさらに交換されるかが明らかでない。

より詳細に言えば、図２６による経路が現在使用されていると考えると、ＳＧＳＮへのＵＥのハンドオーバ後、ＰＳのみの配信が保証される（図２８による経路が不可能である）とした場合、ＳＭＳがどのようにして交換され得るかが今のところ定義されていない。同様に、図２７による経路が現在使用されていると考えると、ＰＳのみの配信が保証される（図２５による経路が不可能である）とした場合、ＳＭＳがどのようにして交換され得るかが今のところ定義されていない。

さらに、ＬＴＥシステムでは、たとえそれが使用されず、ＳＭＳ送信だけがＭＭＥとＵＥとの間でＮＡＳシグナリング接続を介して行われるとしても、少なくともデフォルトのベアラが確立され、有効化される。ＵＴＲＡＮの場合はそうではなく、シグナリングはデータ接続（データ・ベアラ）とは独立して単独で確立可能であり、すなわち、データ接続はＵＴＲＡＮにおいては必須ではない。しかし、この場合、Ｅ−ＵＴＲＡＮからＵＴＲＡＮにハンドオーバするとき、Ｅ−ＵＴＲＡＮで有効化されたデフォルトのベアラは、必要とされておらず、必須ではないとしても、ＵＴＲＡＮの対応するＰＤＮ接続に自動的にマッピングされる。この問題はリリース１１にのみ存在するのではなく、３ＧＰＰ規格のリリース８および９でも既に存在し、特に、１）ＳＧｓインターフェースを介してＳＭＳ送信を行う場合、および２）ＳＧｓを介したＳＭＳ送信中にＣＳフォールバックする場合（ＴＳ２３．２７２、８．２．５ｄ節も参照）に存在することにも留意されたい。

本出願は、これらの問題に対する解決策を提供する。

［マシン・ツー・マシン］
現在の移動通信ネットワークは、ヒューマン・ツー・ヒューマン通信に最適化されて設計されており、３ＧＰＰによればＭＴＣ（マシン型通信）とも称されるＭ２Ｍ（Ｍａｃｈｉｎｅ−２−Ｍａｃｎｉｎｅ）用途にはそれほど最適化されていない。

Ｍ２Ｍ通信は、人間が対話することを必ずしも必要としないエンティティ間のデータ通信の形態と見なすことができる。Ｍ２Ｍ通信は、新しいまたは異なる市場シナリオと、少ないコストおよび労力と、潜在的に極めて多くなり得る通信端末と、おおかた非常に少ない端末ごとのトラフィックとを伴うので、現在の通信モデルとは異なる。

ＭＴＣの応用の一部として、例えば、以下のものが挙げられる。

・ セキュリティ（例えば、警報システム、固定回線（landline）のバックアップ、アクセス制御、車／運転者のセキュリティ）
・ 追跡および記録（Tracking & Tracing）（例えば、フリート管理、注文管理、走行距離に応じた課金（Pay as you drive）、道路通行料徴収（Road Tolling）、交通情報）
・ 支払い（販売時点情報管理、自動販売機、ロイヤルティ・コンセプト（Loyalty Concept）、ゲーム機）
・ 健康（生命徴候の監視、遠隔診断、ウェブ・アクセス遠隔医療ポイント（Web Access Telemedicine point））
・ 遠隔保守／制御（センサー、照明、ポンプ、バルブ、エレベーター制御）
・ 計測（例えば、電気、ガス、水道、暖房、グリッド制御）

Ｍ２Ｍ通信に関する研究項目（３ＧＰＰ ＴＲ２２．８６８）は、２００７年に終了した。リリース１０以降、３ＧＰＰは、この研究項目から得られたネットワークの改善の成果を仕様策定フェーズへと進めようとしており、ＭＴＣのシナリオおよび応用をサポートするためにアーキテクチャへの影響およびセキュリティの観点での対応を行っている。したがって、３ＧＰＰは、大規模なマシン型通信グループを処理することによる影響および負担を減らすこと、デバイスのバッテリー電力使用に与える影響を最小化するためにネットワークの動作を最適化すること、事業者がマシン型通信の要件に合わせて作られたサービスを提供することを可能にすることによって新たなマシン型通信の応用を促進すること、またはマシン型通信サービスを提供するときのネットワーク事業者の運用コストを引き下げることなどのさまざまな目標および目的のもと、マシン型通信のためのネットワークの改善（ＮＩＭＴＣ：Network Improvements for Machine-Type Communication）に関する作業項目を定義した。

ＭＴＣは、通常のヒューマン・ツー・ヒューマン通信とは異なるいくつかの特質がある。３ＧＰＰは、ネットワークの動作を最適化するためにこれらの特質を特定しようとしている。これらの特質は、「ＭＴＣ機能（MTC feature）」と称され、技術規格ＴＳ２２．３６８で説明されており、この技術規格ＴＳ２２．３６８は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、参照により本明細書に援用される。例えば、上述のＭＴＣ機能のうちの１つは、「小データ送信」である可能性があり、これは、ＭＴＣデバイスが少量のデータを送信または受信することを意味する。少量のデータとは、データが、データ接続を確立するために必要な交換されるシグナリングのサイズよりも小さいかまたはそれと同程度であることを意味する。「小データ」の厳密な定義は、３ＧＰＰによる標準化の第１段階の課題であり、ＵＥの加入の一部であるか、またはネットワーク事業者のポリシーによる可能性がある。さらに、ＭＴＣデバイスは、少量のデータを送信する前に、ネットワークにアタッチされるか、またはネットワークからデタッチされる可能性がある。

「小データ送信」のために加入または構成されるＵＥの要件は、ネットワークに与える影響（例えば、シグナリングのオーバーヘッド、ネットワーク・リソース、再割り当てのための遅延）を最小限にしながら少量のデータを送信することである。小データは、上りリンクおよび下りリンクで効率的に送信されることになる。

小データ送信を最適化するために可能ないくつかの解決策があり得る。

− 小データが、通常のショート・メッセージ・サービス（ＳＭＳ）にカプセル化される可能性がある。ＵＥがパケット交換（ＰＳ）ＥＰＳネットワークにアタッチされているとき、ＳＭＳを送信する３つの主要なメカニズムがある。

・ ＳＭＳオーバー回線交換フォールバック（ＣＳＦＢ）（SMS over Circuit Switched Fall-back （CSFB））メカニズム。ＣＳＦＢメカニズムは、３ＧＰＰ ＴＳ２３．２７２に説明されている。下りリンクのＳＭＳが存在するとき、ＵＥは、回線交換（ＣＳ）ドメインに、すなわち、ＧＥＲＡＮアクセス・システムか、またはＵＴＲＡＮアクセス・システムかのどちらかにアタッチするためにネットワークからページングされる。ＭＴＣデバイスは高価な移動体デバイスではないことが期待されるので、１つの無線アクセス技術のみを実装しており、したがって、ＣＳドメインとＰＳドメインとの切り替えができないものと予想される。さらに、多くのＭＴＣデバイスはＰＳのみに対応しており、したがってＣＳＦＢは可能な通常の解決策とはならないと予想される。

・ ＳＭＳオーバーＩＰマルチメディア・サブシステム（ＩＭＳ）（SMS over IP Multimedia Subsystem （IMS））メカニズム。主として、ＩＭＳシステムは、セッション開始プロトコル（ＳＩＰ）およびセッション記述プロトコル（ＳＤＰ）を使用してＩＰ上で音声およびその他のリアル・タイム・サービスを転送するために設計されている。上述のように、ＭＴＣデバイスは、低コストのデバイスであることが期待されており、ＩＭＳクライアントを実装することは高価過ぎる可能性がある。したがって、ＳＭＳオーバーＩＭＳによる解決策は、常に望ましい解決策ではない可能性がある。

・ ＳＭＳオーバーＳＧｓメカニズム。ＳＧｓは、移動通信交換局（ＭＳＣ）とＭＭＥとの間のインターフェースである。ＭＳＣは、無線システムと固定ネットワークとの間のインターフェースを構成する。ＭＳＣは、移動局へのおよび移動局からのＣＳサービスを処理するためのすべての必要な機能を実行する。これが図６に示されており、以下でより詳細に説明される。

− 小データが、ＳＭＳ−ｏ−ＳＧｓメカニズムと同様に、ＮＡＳトランスポート・メッセージでカプセル化される。ＳＭＳ−ｏ−ＳＧｓとの違いは、小データが、何らかの方法でＭＭＥにルーティングされる小さなＩＰパケットであり、そして、ＭＭＥがＩＰパケットをＮＡＳパケットでカプセル化することである。

図６は、ＳＭＳ−ｏ−ＳＧｓメカニズムを用いたＳＭＳの転送を示すシグナリング図である。ＵＥは、ＥＳＰサービス、および「ＳＭＳのみ」の機能のために構成されていると仮定する。「ＳＭＳのみ」とは、ＳＭＳ（回線交換サービスと見なされる）が、ＳＭＳ−ｏ−ＳＧｓメカニズムを用いてＬＴＥアクセス・システムを介して転送されることを意味する。この目的のために、ＵＥとネットワークとが、アタッチ手順の間に、ＳＭＳの転送にかかわるそれらＵＥとネットワークとの機能を交換する。ＵＥとネットワークとの両方がＳＭＳ−ｏ−ＳＧｓを実装しており、このメカニズムを使用することで合意する場合、ＭＭＥにおけるＵＥのステータスが、ＰＳサービスおよび「ＳＭＳのみ」のためのアタッチ状態となる。したがって、下りリンクＳＭＳがＭＭＥに到着すると、ＭＭＥは、上述のように「ＰＳ」識別子を用いてＵＥをページングする。

さらに、ＵＥがＩＤＬＥモードであり、したがって、データを受信または送信するために構成されたいかなる無線リソースも持たないと仮定する。

ステップ（１）において、小データのＳＭＳがＭＭＥに到着するとき、下りリンク・データが受信されるべきであることをＵＥに知らせるために、ＵＥにページング・メッセージが送信される。ページング・メッセージは、「ＰＳ」、すなわちパケット交換に設定されたコア・ネットワーク・ドメイン・インジケータを含む可能性があり、つまり、ユーザ機器は、ＬＴＥアクセス技術によってＥＰＳシステムへの接続を確立するようにトリガされる。

ステップ（２）において、ユーザ機器は、サービス要求メッセージで応答し、タイマＴ３４１７を開始し、データ無線ベアラ（ＤＲＢ）の確立を待つ。サービス要求メッセージは、ＥＰＳ移動管理メッセージの１つであり、サービス要求手順を開始する。サービス要求手順は、上りリンク・ユーザ・データまたはシグナリングが送信されるべきときに、ＥＭＭモードをＥＭＭ−ＩＤＬＥモードからＥＭＭ−ＣＯＮＮＥＣＴＥＤモードに遷移させ、無線ベアラおよびＳ１ベアラを確立することを目的とする。この手順の別の目的は、ＭＯ／ＭＴ（移動体終端）回線交換フォールバック手順を呼び出すことである。

この手順は、例えば、ネットワークが保留中の下りリンク・シグナリングを有するとき、ＵＥが保留中の上りリンク・シグナリングを有するとき、または−ＵＥもしくはネットワークが保留中のユーザ・データを有し、ＵＥがＥＭＭ−ＩＤＬＥモードであるときに使用される。サービス要求手順はＵＥによって開始されるが、ＥＭＭ−ＩＤＬＥモードにおけるシグナリングまたはユーザ・データの下りリンクの転送に関しては、ページング手順を用いてネットワークによってトリガが与えられる。

サービス要求メッセージに対して、ＵＥは特定のＡＣＫを受信しない。したがって、ＡＣＫは、無線ベアラの確立によってなされる。タイマＴ３４１７は、無線インターフェース上のデータ無線ベアラ（ＤＲＢ）が確立されているというアクセス層（ＡＳ）による指示をＵＥが得るときに終了される。タイマＴ３４１７のデフォルト値は、６ｓである。ＵＥが、タイマＴ３４１７が切れる前にＡＳから指示を受信しない場合、ユーザ機器は、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔメッセージをＭＭＥに再送信する。

ＭＭＥがＵＥからＳｅｒｖｉｃｅＲｅｑｕｅｓｔメッセージを受信した後、ステップ（３）において、ＭＭＥが、ＵＥとｅＮＢとの間のデータ無線ベアラを設定するようにｅＮＢをトリガする（ステップ３．２参照）。特に、ＭＭＥは、無線ベアラ（ＳＲＢおよびＤＲＢ）を設定し、無線インターフェース上のセキュリティ保護を確立し、Ｓ１−Ｕベアラの確立およびその他の機能のためにＵＥのコンテキストを構成するために、ｅＮＢに対するＳ１−ＡＰ「初期コンテキスト設定」手順をトリガする。さらに、１つまたは複数のデータ無線ベアラの構成情報を含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがｅＮＢからＵＥに送信される。ユーザ機器は、指示通りにデータ無線ベアラを構成した後、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージによって応答する。

しかし、ユーザ機器とｅＮｏｄｅＢとの間で確立された（１つまたは複数の）データ無線ベアラは、小データを送信するために使用されない。その代わりに、小データは、ＮＡＳプロトコル・メッセージを用いてＭＭＥからＵＥに送信される（ＮＡＳがＵＥおよびＭＭＥで終端されることを示す図３参照）。ステップ（４）において、ＳＭＳは、下りリンクＮＡＳトランスポート・メッセージでカプセル化される。ＮＡＳの交換全般と、特にＮＡＳの転送とは、ＵＥがＣＯＮＮＥＣＴＥＤモードであるときに実行され、したがって、ＳＲＢだけでなく対応する（１つまたは複数の）ＤＲＢも確立される。同様に、ｅＮＢとＳ−ＧＷとの間のＳ１−Ｕベアラも、確立される。

以上のことから分かるように、小データを送信する可能な解決策は、ＭＭＥとユーザ機器との間でＮＡＳプロトコル・メッセージを使用することである。しかしながら、この従来技術の解決策には問題が伴う。

１つの問題は、小データがＮＡＳメッセージを用いて送信されるにもかかわらず、ユーザ機器とｅＮｏｄｅＢとの間でデータ無線ベアラが確立されることである。その理由は、ステップ（２）で送信されるＮＡＳサービス要求メッセージが、ステップ３．１および３．２によるデータ無線ベアラの確立をトリガするからである。概して、ＥＰＳベアラを構築／維持するためのシグナリングのオーバーヘッドが小データの中身のサイズに対して大きいので、ＥＰＳベアラを用いて小データを送信することは効率的でないことに留意されたい。さらに、データ無線ベアラが小データの転送にすら使用されないときは、シグナリングが無駄になる。

ＥＰＳベアラ（すなわち、ＤＲＢおよびＳ１−Ｕベアラ）を確立することと、後でそれらのベアラを解放することとは、関与しているノード間のシグナリングの交換を費やし、さらにそれらのノード自体の中でのシグナリングの処理を費やすこととなる。したがって、ＵＥがＲＲＣ接続を確立し、ＩＤＬＥ状態からＣＯＮＮＥＣＴＥＤ状態に遷移するときに、ＥＰＳベアラの確立を避けることが望ましい。

ＵＭＴＳシステムでは、ユーザ機器がネットワークにアタッチされるとき、ＵＥおよびコア・ネットワーク（ＳＧＳＮ）で制御プレーンのためのコンテキストのみが確立されることに留意されたい。ＩＤＬＥ状態のＵＥがＣＯＮＮＥＣＴＥＤ状態に遷移するとき、初めに、制御プレーンの接続のみが確立され、ＵＥはデータ・ベアラの確立のためのＰＤＰコンテキストの有効化を後で開始する。反対に、ＥＰＳシステムでは、ＵＥがネットワークにアタッチするとき、少なくとも１つのデフォルトのＥＰＳデータ・ベアラが確立される。したがって、ユーザ機器がＩＤＬＥ状態からＣＯＮＮＥＣＴＥＤ状態に遷移するとき、（ユーザ・プレーンの）ＥＰＳベアラが、制御プレーンの接続と平行して確立される。したがって、本発明が対象とする具体的な問題は、ＥＰＳシステムにアタッチされたユーザ機器がＩＤＬＥ状態からＣＯＮＮＥＣＴＥＤ状態に遷移し、既にデフォルトのＥＰＳベアラ・コンテキストを有するが、制御上の小データだけが送信されるべきであるときに、ユーザ・プレーンのベアラの確立をどのようにして回避するのかということである。

小データを送信する別のあり得る方法は、図１４〜１６で説明したＳＭＳ手順を使用することである。それに対応して、ＳＭＳは、ＵＥに、またはＵＥから、ＲＰ−ＤＡＴＡ ＲＰＤＵとして送信される。小データが１４０バイトよりも大きい場合、小データは、複数のセグメント、すなわちＳＭＳで構成された連結されたＳＭＳで送信され得る。

図１４〜１６によるＳＭＳ転送のために確立された無線リソースの解放は、以下で説明するように、最も有利ではない可能性がある。

通常、データ送信に関して、ｅＮＢは、非アクティブ時間の後、すなわち、特定の時間の間、無線インターフェース上の非パケット送信が実行されたとき、ＵＥとｅＮＢとの間で確立されたＲＲＣ接続の解放を開始する。ｅＮＢは、Ｓ１−ＡＰシグナリングをＭＭＥに送信して無線リソースの解放を要求する。次に、ＭＭＥが、ＵＥに固有のコンテキストを削除するようにｅＮＢに命令し、その結果、ＲＲＣ接続が解放される。

ＵＥの下位層（すなわち、アクセス層）がＲＲＣ接続の解放を指示するとき、ＵＥは、ＮＡＳシグナリング接続も解放する。

上述のＲＲＣ接続の解放は、ＵＥとＭＭＥとの両方のＮＡＳ層におけるＣＯＮＮＥＣＴＥＤ状態からＩＤＬＥ状態への遷移も意味することに留意されたい。

ＵＥとＭＭＥとの間のＮＡＳ ＭＭシグナリング接続を解放するためのシグナリング手順が、ネットワーク、すなわちＭＭＥによって開始される。

ＳＭＳ送信に関して、現在の３ＧＰＰの仕様は、ＮＡＳ移動管理接続を解放するための手順を記載している。ＮＡＳ移動管理接続の解放の１つのそのような例が、移動体終端ＳＭＳを想定して以下に与えられる。ＭＴ ＳＭＳに関して、ＵＥのＳＭＣエンティティは、以下の状態、すなわち、ＭＴ−Ｉｄｌｅ、ＭＴ−ＣＯ−Ａｃｋ待ち（MT-Wait for CO-Ack）、およびＭＴ−ＭＭ−接続確立（MT-MM-connection established）を有する。ＵＥのＳＭＣエンティティは、以下の場合のいくつかにおいて、ＮＡＳ接続を解放するようにＮＡＳ移動管理層をトリガする。

− 「ＭＴ−ＭＭ−接続確立」状態のＳＭＣエンティティがＳＭ−ＲＬ層（ＳＭＲエンティティ）からＣＭ接続解放要求メッセージを受信するとき。例えば、ＳＭ−ＲＬ層からのＣＭ接続解放要求は、ＳＭＲエンティティがＭＴ ＳＭＳの受信に肯定応答するためにＲＰ−ＡＣＫを送信するときにＳＭＣエンティティに指示される可能性がある。

− ＳＭＣエンティティがＭＴ−Ｉｄｌｅ状態になるとき。

− 例えばＳＭ−ＲＬ層でエラーが発生するとき。例えば、これは、中継層がＭＴ ＳＭＳに関するＲＰ−ＡＣＫを送信する指示を転送層から受信しないときに起こり得る。

ＭＭＥのＳＭＣエンティティがＳＭ−ＳＣからＣＰ−Ａｃｋおよび解放要求指示を受信するとき、ＮＡＳ無線リソース解放手順が開始される。小データを正常に送信した後は、無線リソースを速やかに解放することが、無線アクセス・ネットワークの容量を節約するために有利である。

しかしながら、すぐに解放することが、常に有益であるとは限らない可能性がある。例えば、すぐに解放してしまうと、例えば、ＵＥがＳＭＳに応答してデータを送信しなければならないときに、無線接続を立て続けに再確立することにつながる可能性がある。例えば、ＭＴ ＳＭＳは、ＭＴＣアプリケーションが何らかの動作、特にデータ報告（１つもしくは複数のＭＯ ＳＭＳである可能性がある）の送信、またはＭＴＣサーバへのデータ接続（すなわち、ＥＰＳベアラ）の確立を行うためのトリガとして使用される可能性がある。こうした場合などに、上述のＮＡＳ ＭＭ接続の終了が適用される場合、ＵＥは、接続が解放された後すぐに、ＭＯ ＳＭＳを送信するために、またはデータ・ベアラを確立するために、ＲＲＣ接続を再び開始する必要がある。別の言い方をすれば、ＮＡＳ ＭＭ接続と、さらにＲＲＣ接続とは、早く解放され過ぎる可能性がある。

ＴＳ２３．４０１ ＴＳ３６．４１３ ＴＳ３６．３３１ ＴＳ２４．３０１ ８．２．１５章 ＴＳ２４．３０１ ５．６．１節 技術仕様３６．３３１ ＴＳ２９．２７４ ＴＳ３３．４０１ ＴＳ３６．３００ ＴＳ４３．１２９ ５．２．２．２項 ＴＳ２３．２７２ ８．２．５ｄ節 ＴＲ２２．８６８ ＴＳ２２．３６８

したがって、現状の技術の上述の問題に鑑みて、本発明の１つの目的は、小データのみを交換する移動ノードのための通信システムにおける改良されたハンドオーバ手順を提供することである。

本発明の１つの態様は、小データの配信がパケット交換ドメインのみを使用して実行されるとき、特に、小データの送信中にアクセス・システム間のハンドオーバが起こる場合に、Ｅ−ＵＴＲＡＮとＵＴＲＡＮとの間のハンドオーバをどのようにしてサポートすべきかという問題に関する。この問題は、背景技術の節の「ＬＴＥからＵＴＲＡＮ無線アクセスへのハンドオーバ」の章で説明している。

この態様によれば、最適化されたハンドオーバが、小データ（例えば、ＳＭＳ）の送信の実行中にＥ−ＵＴＲＡＮからＵＴＲＡＮへのＲＡＴ間で移動ノードに対して実行される。背景技術の節で説明したように、シグナリング接続のみがＥ−ＵＴＲＡＮで実際に使用されているとき、この種のハンドオーバで問題が起こり、Ｅ−ＵＴＲＡＮでデータ接続が使用されていないにもかかわらず、対応するデータ接続がハンドオーバ中にＵＴＲＡＮでやはり確立される。ＵＴＲＡＮでのこの不必要なデータ接続と、関連するリソースの無駄とを避けるために、本発明のこの態様は、ハンドオーバ元ネットワークのＥ−ＵＴＲＡＮにおいて、ハンドオーバ先ネットワークのＵＴＲＡＮでデータ接続が確立されるか否かを調べる。

概要を述べると、ＵＴＲＡＮでデータ接続が確立されると判定された場合にのみ、ＬＴＥネットワークのデータ接続に対応するデータ接続が、（ＬＴＥのシグナリング接続に対応するシグナリング接続に加えて）ハンドオーバ中にＵＴＲＡＮで確立される。そうではなく、ＵＴＲＡＮでデータ接続が確立されないと判定された場合、ＵＴＲＡＮでデータ接続は確立されず、ＬＴＥのシグナリング接続に対応するシグナリング接続のみがＵＴＲＡＮで確立される。

本発明のこの態様のさらなる詳細を、以下で説明する。

ＵＴＲＡＮでデータ接続を確立すべきか否かに関するチェックは、さまざまな方法で実行され得る。例えば、ハンドオーバ元Ｅ−ＵＴＲＡＮのデータ接続がデータ交換のために使用されているか否かが、調べられる可能性がある。これは、ＵＥ、サービング・ゲートウェイ、またはｅＮＢに格納されたデータ交換の統計に基づいて行われる可能性がある。例えば、データ統計は、例えば、ＳＭＳ送信の開始後にＳ１−Ｕベアラを介して交換されたユーザ・データの量に関連する可能性がある。

追加的または代替的に、その他のパラメータが、調べるために考慮される可能性がある。例えば、ＳＭＳの送信が始まる前にＵＥがＣＯＮＮＥＣＴＥＤ状態であったとき、そのことは、過去にデータ・ベアラを介してデータ交換が実行され、今、または将来再び実行されることを示していると考えられる。したがって、ＵＴＲＡＮでデータ接続が必要とされる可能性があり、したがって、ハンドオーバ中に確立される。

Ｅ−ＵＴＲＡＮの各データ・ベアラは、優先度の値を割り振られる。デフォルト・ベアラのこの優先度の値も、ＵＴＲＡＮでデータ接続を確立すべきか否かの判定で考慮される可能性があり、例えば、優先度の値が高い（すなわち、事前に定義された閾値を超えている）とき、ＵＴＲＡＮでデータ接続が確立されると判定される可能性がある。好ましくは、これは、データ接続がＥ−ＵＴＲＡＮで現在使用されているか否かとは無関係に判定され得る。

さらなるオプションによれば、ＵＥが現在受信しているＳＭＳに応答してデータ送信を開始するか否かが考慮される可能性がある。より詳細に言えば、ＭＴ ＳＭＳがデバイスをトリガするために使用される場合、その時点でＥ−ＵＴＲＡＮにおいてデータ・ベアラを介してデータ交換が実行されていないとしてもＵＴＲＡＮでデータ接続が確立される。

ＵＴＲＡＮでデータ接続を確立するか否かに関するこのチェックは、エンティティ、好ましくは、Ｅ−ＵＴＲＡＮで実行される小データの交換に関与しているエンティティによって実行される可能性がある。これは、以下、すなわち、ＭＭＥ、ｅＮｏｄｅＢ、およびＵＥのうちの１つ、またはこれらの組み合わせである可能性がある。

上で説明したように、判定は、さまざまなパラメータおよびデータに基づく可能性がある。判定に必要なデータおよび／またはパラメータは、そのデータおよび／またはパラメータを格納するエンティティから実際に判断を行うエンティティに交換される。例えば、ＭＭＥがＵＴＲＡＮでデータ接続を確立すべきか否かを判断しようとしていると仮定すると、ＭＭＥは、ＵＥか、サービング・ゲートウェイか、またはｅＮＢかのいずれかからのデータ統計を要求することができる。

いずれの場合も、Ｅ−ＵＴＲＡＮのデータ接続に対応するＵＴＲＡＮのデータ接続を確立すべきか否かに関する判断を行うエンティティは、上で説明した判定に必要な情報を与えられる。

データ接続が確立されると仮定すると、ハンドオーバは、ＵＥおよびＳＧＳＮでＰＤＰコンテキストを有効化することを含め、通常通りに実行される。

本出願にとってより興味深いのは、データ接続が確立されない場合である。この場合、ハンドオーバは、ハンドオーバ先ネットワークであるＵＴＲＡＮでシグナリング接続が確立されるが、対応するデータ接続は避けられるように実行される。これを実現するために、ＵＴＲＡＮのデータ接続に関連するＳＧＳＮおよびＵＥのベアラ・コンテキストが、「保存（preserved）」状態に設定される。用語「保存」は、ＰＤＰコンテキストがネットワークおよびＵＥに格納されるが、有効化されず、すなわち使用されないことを意味し、さらに、ＳＧＳＮは、サービング・ゲートウェイに連絡して、「保存」状態であってもＳ４関連付けを確立する可能性があるが、無線アクセス・ベアラはＵＴＲＡＮの無線アクセス・ネットワークで確立されない。それに対応して、ハンドオーバ中に、ハンドオーバ元ＭＭＥが、ＵＴＲＡＮのデータ接続を設定しないが、対応するＰＤＰコンテキストは保存状態で維持するようにＳＧＳＮおよびＵＥに命令する。例えば、ＭＭＥは、各データ接続とその接続の状態とについてＳＧＳＮおよびＵＥに知らせる可能性があり、この場合、ＭＭＥは、Ｅ−ＵＴＲＡＮのデフォルト・ベアラとそのデフォルト・ベアラの状態が「保存」であることとについてＳＧＳＮおよびＵＥに知らせる。

あるいは、ハンドオーバ中のＭＭＥからＵＥへの通信で、上で説明した状態情報は、ＵＥに明示的に送信される必要がない。ＵＥは、（ハンドオーバの前のステップで）ＳＧＳＮによって確立された対応するデータ・ベアラに関する情報を受信しない（すなわち、ＲＡＢ ＩＤを受信しない）場合、ＵＴＲＡＮでシグナリング接続のみが確立されるべきであると推測することができる。

本発明は、移動通信システムで第１のネットワークから第２のネットワークへの移動ノードのハンドオーバを実行する方法を提供する。移動ノードは、パケット交換サービスおよび小データを受信するために第１のネットワークにアタッチされている。第１のネットワークで確立されたシグナリング接続が、小データを交換するために移動ノードによって使用され、データ接続が、移動ノードのために第１のネットワークで確立されている。第１のネットワークから第２のネットワークへの移動ノードのハンドオーバは、移動ノードをパケット交換サービスおよび小データのために第２のネットワークにアタッチするために開始される。移動ノードと第１のネットワークとの間の小データの交換に関与するノードが、データ接続に対応する第２のデータ接続が第２のネットワークで確立されるべきであるか否かを判定する。第１のネットワークのシグナリング接続に対応する、第２のネットワークの第２のシグナリング接続が、確立される。判定するステップの結果に応じて、第１のネットワークのデータ接続に対応する、第２のネットワークの第２のデータ接続が、確立されるか、または確立されない。そして、第１のネットワークから第２のネットワークへの移動ノードの開始されたハンドオーバが、完了する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、対応する第２のデータ接続を確立しないと判定された場合、第２のネットワークの対応する第２のデータ接続は、ハンドオーバ中に確立されない。対応する第２のデータ接続を確立すると判定された場合、第２のネットワークの対応する第２のデータ接続が、ハンドオーバ中に確立される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、第１のネットワークは、Ｅ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）であり、前記第２のネットワークは、ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）またはＧＥＲＡＮ（GMS EDGE Radio Access Network）である。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、ハンドオーバを完了させた後に小データが交換される、第１のネットワークの移動管理エンティティと第２のネットワークのサービングＧＰＲＳサポート・ノードとの間の転送接続が、確立される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、判定が、第１のネットワークのデータ接続が移動ノードによってユーザ・データの交換のために使用されているか否かを判定する。データ接続が移動ノードによってユーザ・データの交換のために使用されていない場合、対応する第２のデータ接続が第２のネットワークで確立されない。データ接続が移動ノードによってユーザ・データの交換のために使用されている場合、対応する第２のデータ接続が第２のネットワークで確立される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、判定が、第１のネットワークのデータ接続で移動ノードによって交換されるユーザ・データについてのデータ統計に基づいて実行される。好ましくは、判定は、第１のネットワークの移動管理エンティティで実行され、データ統計は、第１のネットワークのコア・ネットワーク・ノードかまたは無線アクセス・ノードかのどちらかから移動管理エンティティによって取得される。好ましくは、判定するステップは、第１のネットワークの無線アクセス・ノードで実行される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、このステップは、
データ接続に割り振られた優先度の値に関する情報、
移動ノードに送信される小データが、データ接続を使用してユーザ・データを送信することによって応答するように移動ノードをトリガするか否かに関する情報、
移動管理エンティティが小データを小データ・プロトコル（small data protocol）を使用して送信しているか、それとも非小データ・プロトコル（non-small data protocol）を使用して送信しているかに関する情報、
移動ノードからの、データ接続が移動ノードによって必要とされているか否かの指示、
のうちの少なくとも１つを考慮する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、データ接続に関する状態情報が、判定の結果に基づいて生成される。好ましくは、第１の状態が、対応する第２のデータ接続が確立されないことを示し、第２の状態が、対応する第２のデータ接続が確立されることを示す。データ接続に関する生成された状態情報は、ハンドオーバ中に、第１のネットワークの移動管理エンティティから第２のネットワークのサービングＧＰＲＳサポート・ノードに送信される。第２のネットワークのサービングＧＰＲＳサポート・ノードは、第１のネットワークのデータ接続に関する受信された状態情報に応じて、第２のネットワークの対応する第２のデータ接続を確立するか、または確立しない。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、サービングＧＰＲＳサポート・ノードが、第１のネットワークの移動管理エンティティから、第１のネットワークのデータ接続に関するコンテキスト情報を受信する。サービングＧＰＲＳサポート・ノードは、移動管理エンティティからのデータ接続に関する受信されたコンテキスト情報に基づいて第２のコンテキスト情報を生成する。有利なことに、サービングＧＰＲＳサポート・ノードとコア・ネットワークのサービング・ゲートウェイとの間の関連付けが、第２のコンテキスト情報に基づいて確立される。第２のデータ接続が第２のネットワークで確立されない場合、サービングＧＰＲＳサポート・ノードは、第２のコンテキスト情報を格納するが、第２のネットワークの第２のデータ接続は確立しない。第２のデータ接続が第２のネットワークで確立されるべきである場合、サービングＧＰＲＳサポート・ノードは、第２のコンテキスト情報を格納し、生成された第２のコンテキスト情報に基づいて第２のネットワークの第２のデータ接続を確立する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、データ接続に関する生成された状態情報が、ハンドオーバ中に、第１のネットワークの移動管理エンティティから移動ノードに送信される。移動ノードは、第１のネットワークのデータ接続に関する受信された状態情報に応じて、第２のネットワークの対応する第２のデータ接続を確立するか、または確立しない。あるいは、移動ノードは、移動管理エンティティからハンドオーバ命令を受信し、受信されたハンドオーバ命令中で特定の情報が欠けているか否かに応じて、第２のネットワークの対応する第２のデータ接続を確立するか、もしくは確立しない。この特定の情報は、通常、ハンドオーバ先無線ネットワークでのデータ・ベアラの確立中にハンドオーバ先ＲＮＣによって生成された（１つまたは複数の）ＲＡＢ ＩＤである。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、移動ノードが、第１のネットワークのデータ接続に関するコンテキスト情報を格納する。移動ノードは、データ接続に関する格納されたコンテキスト情報に基づいて、第２のデータ接続に関する第２のコンテキスト情報を生成する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、ハンドオーバは、第２のデータ接続が第２のネットワークで確立されない場合であっても正常に完了する。

さらに、本発明は、移動管理エンティティによってサービスを提供される第１のネットワークから第２のネットワークへの移動ノードのハンドオーバ手順に関与する移動管理エンティティを提供する。移動ノードは、パケット交換サービスおよび小データを受信するために第１のネットワークにアタッチされている。第１のネットワークで確立されたシグナリング接続が、小データを交換するために移動ノードによって使用され、データ接続が、移動ノードのために第１のネットワークで確立されている。ハンドオーバは、移動ノードをパケット交換サービスおよび小データのために第２のネットワークにアタッチするために実行される。移動管理エンティティのプロセッサが、ハンドオーバが実行されるときに、データ接続に対応する第２のデータ接続が第２のネットワークで確立されるべきか否かを判定する。移動管理エンティティの送信機が、第１のネットワークのシグナリング接続に対応する、第２のネットワークの第２のシグナリング接続を確立するように第２のネットワークおよび移動ノードに命令する。さらに、送信機は、判定の結果に応じて、第１のネットワークのデータ接続に対応する、第２のネットワークの第２のデータ接続を確立するか、または確立しないように第２のネットワークおよび移動ノードに命令する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサ、送信機、および受信機が、移動管理エンティティと第２のネットワークのサービングＧＰＲＳサポート・ノードとの間の転送接続を確立する。送信機は、ハンドオーバが完了した後、小データをサービングＧＰＲＳサポート・ノードに転送する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、第１のネットワークのデータ接続が移動ノードによってユーザ・データの交換のために使用されているか否かを判定することによって判定を実行する。データ接続が移動ノードによってユーザ・データの交換のために使用されていない場合、送信機が、第２のネットワークの第２のデータ接続を確立しないように命令し、データ接続が移動ノードによってユーザ・データの交換のために使用されている場合、送信機が、第２のネットワークの対応する第２のデータ接続を確立するように命令する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、第１のネットワークのデータ接続で移動ノードによって交換されるユーザ・データについてのデータ統計に基づいて判定を実行し、受信機が、第１のネットワークのコア・ネットワーク・ノードかまたは無線アクセス・ノードかのどちらかからデータ統計を受信する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、
データ接続に割り振られた優先度の値に関する情報、
移動ノードに送信される小データが、データ接続を使用してユーザ・データを送信することによって応答するように移動ノードをトリガするか否かに関する情報、
移動管理エンティティが小データを小データ・プロトコルを使用して送信しているか、それとも非小データ・プロトコルを使用して送信しているかに関する情報、
移動ノードからの、データ接続が移動ノードによって必要とされているか否かの指示、
のうちの少なくとも１つに基づいて判定を実行する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、判定の結果に基づいて、データ接続に関する状態情報を生成する。好ましくは、第１の状態が、対応する第２のデータ接続が確立されないことを示し、第２の状態が、第２のデータ接続が確立されることを示す。送信機が、データ接続に関する生成された状態情報を第２のネットワークのサービングＧＰＲＳサポート・ノードにさらに送信する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、送信機が、データ接続に関する生成された状態情報をハンドオーバ中に移動ノードにさらに送信する。

改良されたハンドオーバの上述の態様にいくらか関連する１つのさらなる態様は、移動ノードが、ハンドオーバ先アクセスで第２のデータ接続を確立するか否かに関するハンドオーバ元ネットワークでの判定を支援することである。特に、移動ノードは、その移動ノードがユーザ・データの交換のためにデータ接続を使用するか否かを知っている。ＭＯ ＳＭＳデータのみが上りリンクで送信されるべきである場合、またはＭＴ ＳＭＳがデバイスをトリガするために使用されない（移動ノードがＭＴ ＳＭＳに応答して上りリンク・ユーザ・データを送信しない）場合、移動ノードは、この事実を示すためにＭＭＥまたはｅＮＢに指示を送信することができる。したがって、移動ノードからこの指示を受信するｅＮＢまたはＭＭＥは、その指示から、移動ノードの観点から見てシグナリング接続のみが必要であると推測することができる。この推測は、（上述の態様で説明した）Ｅ−ＵＴＲＡＮからＵＴＲＡＮへのハンドオーバが実行され、ｅＮＢまたはＭＭＥが、Ｅ−ＵＴＲＡＮのデータ接続に対応するハンドオーバ先ネットワーク（ＵＴＲＡＮ）のデータ接続を確立するか否かを判定する必要があるときに役立つ可能性がある。

ｅＮＢまたはＭＭＥへのこの指示は、例えば、移動ノードがＭＯ ＳＭＳの送信が原因でＩＤＬＥからＣＯＮＮＥＣＴＥＤに移行するときに送信される可能性があり、この場合、データ接続は必要なく、ＵＴＲＡＮへのハンドオーバが実行されるとき、ＵＴＲＡＮのデータ接続は確立されない。

あるいは、ｅＮＢまたはＭＭＥへの指示は、移動ノードが、ｅＮｏｄｅＢに定期的に送信する測定から、ハンドオーバがまもなく行われることを認識するときにも送信される可能性がある。特に、移動ノードは、ＲＡＴ間の測定から、別のＲＡＴからの信号がハンドオーバの状態を満たしていると推測することができる。したがって、ＵＥは、ｅＮｏｄｅＢがこのより良いＲＡＴへのＲＡＴ間ハンドオーバを開始する可能性があると予想することができる。特に、移動ノードが現在Ｅ−ＵＴＲＡＮにアタッチされており、他方のＲＡＴが（データ接続が必須ではない）ＵＴＲＡＮである場合、移動ノードは、測定情報に加えて、ＳＭＳ／シグナリングのみが移動ノードによって使用されていることを（ＭＭＥに）示すことができる。

本発明の１つのさらなる態様は、ＰＳのみの配信が保証され、移動ノードがＩＳＲを使用している、すなわち、ＳＧＳＮおよびＭＭＥに同時にアタッチされているが、移動ノードがどちらのネットワーク（ＳＧＳＮのＵＴＲＡＮかまたはＭＭＥのＥ−ＵＴＲＡＮかのどちらか）にいるかをネットワークが正確に知らない特定のネットワークのシナリオに関する。このシナリオと、結果として生じる問題とは、背景技術の節のＩＳＲを説明する章で検討した。

説明しやすくするために、以下では、小データがショート・メッセージ、ＳＭＳを用いてカプセル化される、すなわち転送されると仮定するが、これは、さらに説明するように、常にそうである訳ではないに違いない。この態様の以下の原理は、ＳＭＳのみに限定されると見なされず、小データの交換のその他の方法にも当てはまる可能性がある。

本発明のこの態様によれば、デフォルトＳＭＳサービング・ノードが、ＩＳＲが有効化される場合に移動ノードにＳＭＳを配信するために定義される。概して、デフォルトＳＭＳサービング・ノードは、ＭＭＥかまたはＳＧＳＮかのどちらかである可能性があり、デフォルトＳＭＳサービング・ノードに関する情報はネットワークに格納されており、したがって、ＳＭＳが到着したとき、さらなる配信のためにＳＭＳがどのサービング・ノードに送信されるべきかがすぐに分かる。デフォルトＳＭＳサービング・ノードがどれだけ厳密に定義されるかは、例えば、ネットワークの構成による。例えば、デフォルトＳＭＳサービング・ノードはＵＥに固有であり、すなわち、各ＵＥに対して異なるデフォルトＳＭＳサービング・ノードがＨＳＳで指定される可能性がある。代替的に、またはそれと組み合わせて、デフォルトＳＭＳサービング・ノードは、ＵＥに固有ではなく（ＵＥに固有であるのみでなく）、地理的地域にやはり依存する。さらに、ノード（ＳＧＳＮおよびＭＭＥ）のネイティブのＳＭＳ機能が、デフォルトＳＭＳサービング・ノードを指定するために考慮される。ネイティブのＳＭＳをサポートするサービング・ノードのみが、ＵＥおよび／または地域のためのデフォルトＳＭＳサービング・ノードとして指定され得る。

上で説明したＳＭＳ配信のためのＭＭＥとＳＧＳＮとの間のページングおよびＳＭＳ転送を可能にするために、ＭＭＥとＭＳＣサーバとの間のＳＧｓインターフェースに似た関連付けが確立されるべきである。これは、ＩＳＲモードの有効化の一部である可能性がある。特に、ＩＳＲモードの有効化中に、ＭＭＥおよびＳＧＳＮは、互いのことを知り、したがって、ＭＭコンテキストおよびＳＭコンテキストがＳＧＳＮとＭＭＥとの両方で確立されるＳ３関連付けを確立する。しかし、Ｓ３関連付けは、ＳＧｓに似たページングの交換およびＳＭＳデータの送信を可能にするように拡張される可能性がある。

上記の内容を考慮して、以下で説明する本発明のこの態様は、ＵＥがＩＤＬＥであり、ＩＳＲを有効化しているときに、パケット交換ドメインのみでＳＭＳを配信することを可能にする。概して、デフォルトＳＭＳサービング・ノードが、移動ノードに宛てたＳＭＳを受信し、そのデフォルトＳＭＳサービング・ノード自体のネットワークのページング・メカニズムを開始し、さらに、その他のネットワークにブロードキャストされるべきページング・メッセージを生成し、これは、ページング・メッセージをその他のノードに転送することを含む。ＵＥがどこにあるかに応じて、デフォルトＳＭＳサービング・ノードが、ＳＭＳをＵＥに直接転送することができるか、またはその他のノードが、初めに、デフォルトＳＭＳサービング・ノードからＳＭＳを取得し、次に、取得されたＳＭＳをその他のノードのネットワーク内のＵＥに転送するかのどちらかである。

ＭＭＥがこの特定の移動ノードに関する小データ配信のためのデフォルトＳＭＳサービング・ノードとして構成されると仮定すると、ネットワーク（すなわち、ＳＭＳ−ＳＣ）は、デフォルトＳＭＳサービング・ノードであるＭＭＥにＳＭＳを振り向ける。ＭＭＥは、ＳＧｄインターフェースを介してＳＭＳ−ＳＣからＳＭＳを受信し、そのＭＭＥ自体のＬＴＥネットワーク内でＵＥをページングする。さらに、ＭＭＥは、ＵＴＲＡＮでブロードキャストするためのページング・メッセージを生成し、このページング・メッセージをＳＧＳＮに転送し、すると今度は、ＳＧＳＮが、ページング・メッセージをＵＴＲＡＮ内でブロードキャストする。このページング・メッセージは、ＵＥがＰＳドメインでのＳＭＳ送信のためにページングされることを示すこともできる。

ＵＥは、ＵＥがどこにあるかに応じて、ＵＴＲＡＮかまたはＥ−ＵＴＲＡＮかのどちらかで受信されたページングに応答する。それに対応して、ＵＥはＣＯＮＮＥＣＴＥＤモードに遷移し、ＩＳＲが無効化される。ＵＥは、そのＵＥの位置に応じてＳＧＳＮかまたはＭＭＥかのどちらかにアタッチする。

ＵＥは、Ｅ−ＵＴＲＡＮ内にある場合、Ｅ−ＵＴＲＡＮでのＭＭＥのページングに応答する。次いで、ＭＭＥは、ＳＭ−ＣＰ／ＲＰプロトコルを用いてＵＥにＳＭＳを直接送信することができる。

ＵＥがＵＴＲＡＮ内にある場合、ＵＥがＳＧＳＮのページングに応答し、ＳＧＳＮが、ＵＥがＵＴＲＡＮ内にあり、ＳＧＳＮによってサービスを提供されていることをＭＭＥに知らせる。さらに、ページング・メッセージがＰＳドメインを介したＳＭＳ送信に関するページングについての指示を含むとき、シグナリング接続のみがＵＴＲＡＮで確立される可能性がある。それに応答して、ＭＭＥは、ＳＭＳをＳ３インターフェースを介してＳＧＳＮに転送し、すると今度は、ＳＧＳＮが、シグナリング接続を介してＮＡＳプロトコル（ＮＡＳコンテナ）を使用してＵＴＲＡＮ内のＵＥにＳＭＳを転送することができる。

反対に、ＳＧＳＮがデフォルトＳＭＳサービング・ノードとして定義される場合、ＳＧＳＮが、ＳＭＳ−ＳＣからのＭＴ ＳＭＳの受信に応答して、そのＳＧＳＮ自体のネットワーク内でＵＥをページングし、Ｅ−ＵＴＲＡＮでのページングのためのページング・メッセージを生成する。生成されたページング・メッセージは、Ｓ３インターフェースを介してＭＭＥに転送され、すると今度は、ＭＭＥが、そのＭＭＥのＥ−ＵＴＲＡＮネットワークでそのページング・メッセージをブロードキャストする。

ＵＥがＵＴＲＡＮ内にある場合、ＵＥがＳＧＳＮのページングに応答し、ＳＧＳＮが、ＳＧＳＮで終端されるＳＭ−ＣＰ／ＲＰプロトコルを使用してＵＥにＳＭＳを直接送信することができる。ＵＥがＥ−ＵＴＲＡＮにある場合、ＵＥがＭＭＥのページングに応答し、ＭＭＥが、ＵＥがＭＭＥのＥ−ＵＴＲＡＮ内にあることをＳＧＳＮにしかるべく通知する。ＳＧＳＮは、Ｓ３インターフェースを介してＭＭＥにＳＭＳを転送し、ＭＭＥは、透過ＮＡＳコンテナでＳＭＳをカプセル化することができ、次いで、カプセル化されたＮＡＳコンテナを、ＮＡＳプロトコルを用いてそのＭＭＥのネットワーク内のＵＥに送信する。

この態様の代替は、ＵＥが非デフォルトＳＭＳサービング・ノードのネットワークにアタッチせず（ＵＥが、現在、そのネットワーク内にいるとしても）、その代わりに、可能であれば、ＵＥが、デフォルトＳＭＳサービング・ノードのネットワークへのＲＡＴ間再選択を実行することである。特に、ＭＭＥが、ＳＭＳを受信し、そのＭＭＥ自体のネットワークと、非デフォルトＳＭＳサービング・ノードであるＳＧＳＮのネットワークとでページングを開始するデフォルトＳＭＳサービング・ノードであると仮定する。ＵＥは、ＵＴＲＡＮ内にあり、したがって、ＳＧＳＮからのページングを受信する場合、ＳＧＳＮにアタッチせず、ＭＭＥにアタッチすることができるようにＲＡＴ間再選択を実行する。したがって、ＵＥは、ＭＭＥからＳＭＳを直接受信することができる。それに対応して、ＳＧＳＮがデフォルトＳＭＳサービング・ノードであり、ＵＥがＭＭＥのＥ−ＵＴＲＡＮにある場合に同じことが適用される。

本発明のさらなる目的は、通信システムで無線リソースを解放する改良された方法を提供することである。

本発明の別の態様によれば、無線リソースの解放が、移動ノードによって制御され、無線リソースが確かにもはや必要ないときにのみ無線リソースが解放されることを保証するために延期される。これにより、無線リソースが早く解放され過ぎ、その結果、無線リソースがそれらが解放された後すぐに再確立される必要があるという問題を回避する。

本発明の主な原理を説明するために以下のシナリオを仮定する。移動ノードが、アイドル・モードであり、ショート・メッセージ、すなわちＳＭＳをまもなく受信または送信しようとしている。ＳＭＳは、移動ノード（ＭＴＣデバイス）のＭＴＣアプリケーションに宛てた小データ、または移動ノード（ＭＴＣデバイス）のＭＴＣアプリケーションから発信された小データを含む可能性がある。

本発明の第１の包括的な実施形態が、以下で与えられる。

より詳細に言えば、移動ノードが着信データ・トラフィックを監視する。移動ノードは、ＳＭＳ、または移動ノードがコア・ネットワークに前に送信したＳＭＳに対するＡＣＫを受信するとき、タイマを開始する。タイマの目的は、特定の時間、無線リソースの解放を延期することである。タイマは、移動ノードからの／移動ノードへのまもなく行われるさらなる上りリンク／下りリンクの送信などのさまざまなイベントによって中止される可能性がある。あるいは、受信されたＳＭＳがユーザ・データの送信のためのユーザ・プレーンのデータ・ベアラの確立をトリガする場合、タイマはやはり中止される。概して、初めにタイマを開始したデータ交換に引き続いて無線リソースが使用されることになることが明らかである場合、タイマは移動ノードによって中止されるか、または開始すらされないと言うことができる。

そのようなイベントが起こらない場合、すなわち、無線リソースが近い将来に使用されることが明らかでない場合、タイマがやがて切れ、コア・ネットワーク、特に、移動ノードを担当し、無線リソース解放手順を開始する役割を担う移動管理エンティティへの無線リソース解放指示の送信をトリガする。

無線リソース解放指示は、さまざまな方法で移動管理エンティティに送信され得る。例えば、無線リソース解放指示は、別個のメッセージで送信される可能性があり、または受信されたショート・メッセージのＡＣＫなどの、移動管理エンティティにかねてから送信されるべきであるメッセージに含められる可能性がある。この指示自体は、アイドル状態に変わるための指示、または移動ノードの上りリンク・バッファがゼロであることを示す指示などの任意の適切なフォーマットである可能性がある。

移動ノードの無線リソース解放タイマの具体的な時間は実装により、例えば、数百または数千ミリ秒の範囲内である可能性がある。

本発明は、通信システムで無線リソースの解放を制御するための方法であって、ユーザ機器が、無線リソースを用いてショート・メッセージ・サービスのショート・メッセージを受信および／または送信することができる、方法を提供する。ユーザ機器において、下りリンク・ショート・メッセージ、またはユーザ機器によって前に送信された上りリンク・ショート・メッセージに対するＡＣＫの受信を判定するために、着信データが監視される。下りリンク・ショート・メッセージ、または上りリンク・ショート・メッセージのＡＣＫの受信が判定されたとき、無線リソース解放タイマが開始される。上りリンク・データがユーザ機器からコア・ネットワークに送信されるべきである場合、無線リソース解放タイマが停止される。無線リソース解放タイマが切れるとき、コア・ネットワークが、ユーザ機器のための無線リソースを解放するように命令される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、下りリンク・ショート・メッセージ、もしくは上りリンク・ショート・メッセージのＡＣＫの受信に加えて、または下りリンク・ショート・メッセージ、もしくは上りリンク・ショート・メッセージのＡＣＫの受信の代わりに、ユーザ機器の上位層が無線リソースの解放を指示するときに無線リソース解放タイマが開始される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、さらなる上りリンク・ショート・メッセージがユーザ機器からコア・ネットワークに送信されるべきである場合、またはユーザ・プレーンの無線リソースが確立されるべきである場合、無線リソース解放タイマが停止される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、無線リソースを解放するようにコア・ネットワークに命令するステップが、
アイドル指示を含む解放メッセージを、ユーザ機器を担当する移動管理エンティティに送信するステップ、または
ユーザ機器の上りリンク転送バッファがゼロであることについての情報を含む解放メッセージを、ユーザ機器を担当する移動管理エンティティに送信するステップを含む。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、解放メッセージが、受信されたショート・メッセージのＡＣＫをさらに含む。あるいは、解放メッセージは、受信された下りリンク・ショート・メッセージのＡＣＫである。あるいは、解放メッセージが、受信された下りリンク・ショート・メッセージのＡＣＫを含まないとき、無線リソース解放タイマが切れる前に、受信された下りリンク・ショート・メッセージのＡＣＫが、別個のメッセージで移動管理エンティティに送信される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、ユーザ機器で受信された下りリンク・ショート・メッセージに対するＡＣＫがコア・ネットワークでユーザ機器から受信されることを期待する最大時間の前に無線リソース解放タイマが切れる。加えて、または代替として、無線リソース解放タイマは、ｅＮｏｄｅＢの非アクティブ・タイマの前に切れる。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、ユーザ機器を担当する移動管理エンティティが、上位層からの、無線リソースを解放する命令に応答して、ｅＮｏｄｅＢおよびユーザ機器との無線リソース解放手順を開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、移動管理エンティティが、ショート・メッセージの上位層エンティティからのリソース解放指示にだけ応答して無線リソース解放手順を開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、無線リソース解放タイマが、一連の連結された下りリンク・ショート・メッセージの一部ではない下りリンク・ショート・メッセージ、または一連の連結された下りリンク・ショート・メッセージのうちの最後の下りリンク・ショート・メッセージである下りリンク・ショート・メッセージに対してのみ開始される。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、ユーザ機器が、受信された下りリンク・ショート・メッセージのヘッダ情報を処理して、受信された下りリンク・ショート・メッセージが一連の連結された下りリンク・ショート・メッセージの一部であるか否か、または一連の連結された下りリンク・ショート・メッセージのうちの最後の下りリンク・ショート・メッセージであるか否かを判定する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、少なくとも１つの上位層アプリケーションが、コア・ネットワークとデータを交換する。この場合、無線リソースを解放するようにコア・ネットワークに命令するステップが、少なくとも１つの上位層アプリケーションがデータ交換の終了を示すときにも実行される。

本発明は、通信システムで無線リソースの解放を制御するためのユーザ機器であって、無線リソースを用いてショート・メッセージ・サービスのショート・メッセージを受信および／または送信することができる、ユーザ機器を提供する。ユーザ機器の受信機およびプロセッサが、下りリンク・ショート・メッセージ、またはユーザ機器によって前に送信された上りリンク・ショート・メッセージに対するＡＣＫの受信を判定するために着信データを監視する。プロセッサは、下りリンク・ショート・メッセージ、または上りリンク・ショート・メッセージのＡＣＫの受信を判定するとき、無線リソース解放タイマを開始する。プロセッサは、上りリンク・データがユーザ機器からコア・ネットワークに送信されるべきである場合、無線リソース解放タイマを停止する。プロセッサおよび送信機は、無線リソース解放タイマが切れるとき、ユーザ機器のための無線リソースを解放するようにコア・ネットワークに命令する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、下りリンク・ショート・メッセージ、もしくは上りリンク・ショート・メッセージのＡＣＫの受信に加えて、または下りリンク・ショート・メッセージ、もしくは上りリンク・ショート・メッセージのＡＣＫの受信の代わりに、プロセッサが、ユーザ機器の上位層が無線リソースの解放を指示するときに無線リソース解放タイマを開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、さらなる上りリンク・ショート・メッセージがユーザ機器からコア・ネットワークに送信されるべきである場合、またはユーザ・プレーンの無線リソースが確立されるべきである場合、無線リソース解放タイマを停止する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサおよび送信機が、アイドル指示を含む解放メッセージを、ユーザ機器を担当する移動管理エンティティに送信すること、受信された下りリンク・ショート・メッセージのＡＣＫとして解放メッセージを送信すること、または、ユーザ機器の上りリンク転送バッファがゼロであることについての情報を含む解放メッセージを、ユーザ機器を担当する移動管理エンティティに送信することによって、ユーザ機器のための無線リソースを解放するようにコア・ネットワークに命令する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、解放メッセージが受信された下りリンク・ショート・メッセージのＡＣＫを含まないとき、プロセッサおよび送信機が、無線リソース解放タイマが切れる前に、受信された下りリンク・ショート・メッセージのＡＣＫを別個のメッセージで移動管理エンティティに送信する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、ユーザ機器で受信されたショート・メッセージに対するＡＣＫがコア・ネットワークでユーザ機器から受信されることを期待する最大時間の前に切れるように無線リソース解放タイマを設定する。加えて、または代替として、プロセッサは、ｅＮｏｄｅＢの非アクティブ・タイマの前に切れるように無線リソース解放タイマを設定する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサ、受信機、および送信機が、コア・ネットワーク対する、ユーザ機器のための無線リソースを解放する命令に応答して移動管理エンティティによって開始される無線リソース解放手順に関与する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサが、好ましくは受信された下りリンク・ショート・メッセージのヘッダ情報を処理することによって、一連の連結された下りリンク・ショート・メッセージの一部ではないと判定されたショート・メッセージ、または一連の連結された下りリンク・ショート・メッセージのうちの最後の下りリンク・ショート・メッセージであると判定されたショート・メッセージに対してのみ無線リソース解放タイマを開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、少なくとも１つの上位層アプリケーションが、コア・ネットワークとデータを交換する。この場合、プロセッサが、少なくとも１つの上位層アプリケーションがデータ交換の終了を示すときに、無線リソースを解放するようにコア・ネットワークに命令する。

本発明は、通信システムで無線リソースの解放を制御するための移動管理エンティティであって、ユーザ機器が、無線リソースを用いてショート・メッセージ・サービスのショート・メッセージを受信および／または送信することができる、移動管理エンティティをさらに提供する。移動管理エンティティのプロセッサおよび送信機が、上位層からの、ユーザ機器のための無線リソースを解放する命令と、ユーザ機器からの指示とに応答して、ユーザ機器のための無線リソースを解放するための、ｅＮｏｄｅＢおよびユーザ機器との無線リソース解放手順を開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、プロセッサおよび送信機が、ショート・メッセージの上位層エンティティからのリソース解放指示と、ユーザ機器からのアイドル指示とにだけ応答して、無線リソース解放手順を開始する。

本発明は、通信システムで無線リソースの解放を制御するための移動管理エンティティであって、ユーザ機器が、無線リソースを用いてショート・メッセージ・サービスのショート・メッセージを受信および／または送信することができる、移動管理エンティティをさらに提供する。受信機がショート・メッセージ・サービス・センター（short message service center）からリソース解放指示を受信するときに、移動管理エンティティのプロセッサが無線リソース解放タイマを開始する。プロセッサは、ユーザ機器のために上りリンク・データまたは下りリンク・データが送信されるべきである場合、無線リソース解放タイマを停止する。プロセッサは、無線リソース解放タイマが切れるとき、ユーザ機器のための無線リソースを解放する内部命令を生成する。プロセッサおよび送信機は、生成された内部命令に応答して、ユーザ機器のための無線リソースを解放するための、ｅＮｏｄｅＢおよびユーザ機器との無線リソース解放手順を開始する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、受信機がユーザ・プレーンの無線リソースの確立に関連するユーザ機器からのメッセージを受信するとき、プロセッサが無線リソース解放タイマを停止する。

上記の内容に対して追加的または代替的に使用され得る本発明の有利な実施形態によれば、受信機が下りリンク・ショート・メッセージに肯定応答するためのユーザ機器からのＡＣＫメッセージを受信するときにのみ、プロセッサが無線リソース解放タイマを開始する。

本発明のさらなる目的は、小データをユーザ機器に送信する改良された方法を提供することである。

これは、小データがユーザ機器に関して保留されるべきであるときに、ユーザ・プレーンではなく、制御プレーンの接続のみを確立するようにユーザ機器をトリガすることによって解決される。

これらの原理は、ＩＤＬＥモードまたはＤＥＲＥＧＩＳＴＥＲＥＤモードであるユーザ機器に適用され得る。ユーザ機器がＩＤＬＥモードであるとき、ユーザ機器は、コア・ネットワークとのいかなる制御プレーンまたはユーザ・プレーンの接続性（connectivity）も持たないが、コア・ネットワークは、ユーザ機器の位置、ベアラなどに関する情報を含むＵＥコンテキストを格納している。ユーザ機器がＤＥＲＥＧＩＳＴＥＲＥＤモードであるとき、ユーザ機器は、コア・ネットワークとのいかなる制御プレーンまたはユーザ・プレーンの接続性も持たず、さらに、コア・ネットワークは、通常、ＩＤ、およびユーザ機器がいる可能性があるおおよその位置以外にユーザ機器からのいかなるコンテキストも格納していない。

ユーザ機器がＩＤＬＥモードまたはＤＥＲＥＧＩＳＴＥＲＥＤであると仮定する。コア・ネットワークが、ユーザ機器に宛てた小データを受信する。しかし、ユーザ機器がコア・ネットワークに接続されていないので、小データはユーザ機器に転送できない。それに対応して、ユーザ機器は、小データを受信するためにコア・ネットワークに接続するようにコア・ネットワークによってトリガされる必要がある。ユーザ機器に宛てたデータが小データのみであるので、小データは、制御プレーンのみを用いて、すなわち、ユーザ・プレーンを使用せずに送信されるべきである。

それに対応して、ユーザ機器に送信されるトリガ・メッセージが、ユーザ機器がコア・ネットワークとの制御プレーンの接続性のみを確立すべきであることをユーザ機器に知らせるための指示を含む。トリガ・メッセージと、含まれる制御プレーンのみの指示とにしたがって、ユーザ機器は、制御プレーンのベアラの確立を開始することができる。そして、確立された制御プレーンの接続性、すなわち、制御プレーンのベアラが、ユーザ機器に小データを与えるためにコア・ネットワークによって使用され得る。

ユーザ機器がＩＤＬＥモードである場合、上述のトリガ・メッセージはコア・ネットワークから送信されるページング・メッセージであり、このページング・メッセージは、ユーザ機器が制御プレーンのみの接続性を確立するべきであるか、または制御プレーンの接続とユーザ・プレーンの接続との両方を確立すべきであるかを判別するためのフラグなどの指示によって拡張される。

ユーザ機器が、例えば、下りリンクで受信された小データに応答して上りリンク・データを送信すべきである場合、上りリンク・データが十分に小さいならば、ユーザ機器は、制御プレーンのベアラを使用して、すなわち、この目的でユーザ・プレーンのユーザ・データ・ベアラを確立することを必要とせずに上りリンク・データをやはり送信することができる。

ユーザ機器がコア・ネットワークにアタッチされていない（ＤＥＲＥＧＩＳＴＥＲＥＤ）か、またはＩＤＬＥモードであるかのどちらかであるとき、通常、制御ネットワークの１つのエンティティがユーザ機器をトリガする役割を担う。以下で接続性関連ネットワーク・エンティティ（connectivity-related network entity）とも称されるこのエンティティは、通常、コア・ネットワークの移動管理エンティティ（ＭＭＥ）である。ＭＭＥは、（１つまたは複数の）ユーザ機器をページングするためにｅＮｏｄｅＢにページング要求メッセージを送信する。さらに、ＭＭＥは、ユーザ機器が基地局（ｅＮｏｄｅＢ）にアタッチするように、ユーザ機器がＤＥＲＥＧＩＳＴＥＲＥＤであるときにユーザ機器をトリガするためのエンティティである可能性がある。

小データは、接続性関連ネットワーク・エンティティで受信される可能性があり、そのとき、接続性関連ネットワーク・エンティティは、小データの宛先であるユーザ機器を特定する。次いで、接続性関連ネットワーク・エンティティは、小データを受信するためにＩＤＬＥ／ＤＥＲＥＧＩＳＴＥＲＥＤモードからＣＯＮＮＥＣＴＥＤモードに遷移するように対応するユーザ機器をトリガする（例えば、ページングする）。この場合、小データは、ＳＭＳによって回線交換ネットワークから受信されるか、またはＰＤＮゲートウェイおよびサービング・ゲートウェイからパケット交換回線を介して受信されるかのどちらかである可能性がある。

あるいは、接続性関連ネットワーク・エンティティは、小データ自体は受信せず、小データに関連する別のトリガ・メッセージまたは指示を受信する可能性がある。例えば、小データがパケット交換ネットワークを介して受信され、ＰＤＮゲートウェイからサービング・ゲートウェイに転送される場合、サービング・ゲートウェイが、小データを小データとして特定することができ、したがって、制御プレーンの接続性に関してのみユーザ機器をトリガ／ページングするように接続性関連ネットワーク・エンティティ（例えば、ＭＭＥ）をトリガすることができる。

第１の態様の手順によってもたらされる利点は、ネットワークから下りリンクの小データを受信するために制御プレーンの接続性のみが必要であることをユーザ機器がトリガ・メッセージから知るので、データ・ベアラ、すなわちユーザ・プレーンが確立されないことである。

さらなる態様によれば、小データの上で説明した送信は、ユーザ機器から送信されるべき上りリンク・データをさらに考慮するために変更される。例えば、ユーザ機器が受信する小データに応答して、または単純に、ユーザ機器がネットワークにアタッチする次の機会に送信されるべき上りリンク・データがユーザ機器で保留中であるために、ユーザ機器が上りリンク・データをコア・ネットワークに送信する必要があると想定され得る。

それに対応して、ユーザ機器は、下りリンクの小データを受信するためにネットワークに接続するようにコア・ネットワークからトリガ・メッセージを受信する場合、ネットワークに送信されるべき保留中の上りリンク・データが存在するか否かを判定する。さらに、ユーザ機器は、小データに応答して上りリンク・データがネットワーク送信されるべきか否かを判定する。特に、ユーザ機器は、小データを受信しない（しかし、指示を含むトリガ・メッセージだけ受信する）が、以前の統計から、またはアプリケーションの構成に応じて、上りリンク・データが送信されるべきか否かを推定することができ、送信されるべきである場合、どれぐらいの量の上りリンク・データが送信されるべきか、およびどれぐらい頻繁に上りリンク・データが送信されるべきか（周期）などの上りリンク・データのさらなる詳細をさらに決定することができる。

その決定された情報に基づいて、ユーザ機器は、コア・ネットワークへの上りリンク・データを送信するのにも制御プレーンの接続性で十分であるか否かを判断することができる。ユーザ機器は、制御プレーンのシグナリングが上りリンク・データの送信をサポートするのに十分であると判断する場合、制御プレーンの接続性の確立だけを開始し、制御プレーンの接続性を確立した後、制御プレーンのみを使用して、すなわち、ユーザ・プレーンの接続を使用せずに上りリンク・データを送信する。さらに、ユーザ機器は、制御プレーンを確立するためのメッセージのうちの１つで、制御プレーンのみの接続性で十分であるという指示を送信することができる。このようにして、接続性関連ネットワーク・エンティティは、ユーザ機器がユーザ・プレーンなしで制御プレーンのみを確立したいことをやはり知ることができる。

しかし、ユーザ機器が、制御プレーンが保留中のまたは推定された将来の上りリンク・データを送信するのに十分でないと判定する場合、制御プレーンの接続性およびユーザ・プレーンの接続性が確立されるべきである。したがって、ユーザ機器は、制御プレーンを確立するためのメッセージのうちの１つで、ユーザ・プレーンの接続性が望ましい／必要であるという指示を送信することができる。

ゆえに、接続性関連ネットワーク・エンティティは、制御プレーンのシグナリング・ベアラのみでなく、ユーザ・プレーンのデータ・ベアラも確立する。

あるいは、ユーザ・プレーンが必要か否かをユーザ機器で判定する代わりに、ユーザ機器は、制御プレーンを確立するためのメッセージのうちの１つに、保留中のまたは推定された将来の上りリンク・データに関する情報を含めることもできる。この場合、接続性関連ネットワーク・エンティティが、その情報を受信し、その接続性関連ネットワーク・エンティティ自体で、ユーザ機器からの上りリンク・データの送信を可能にするためにユーザ・プレーンの接続性も必要であるか否かを決定することができる。接続性関連ネットワーク・エンティティは、受信された情報に基づいてその接続性関連ネットワーク・エンティティの判断を行うことができ、さらに、任意で、上りリンク・データを処理するための接続性関連ネットワーク・エンティティにおけるあり得る制限などのさらなるパラメータを考慮する可能性もある。より詳細に言えば、上りリンク・データが制御プレーンのシグナリングを使用して送信されるとき、上りリンク・データは、基地局を介して接続性関連ネットワーク・エンティティに送信される。接続性関連ネットワーク・エンティティの負荷または構成（例えば、最大上りリンク・データなど）に応じて、接続性関連ネットワーク・エンティティは、制御プレーンを介した上りリンク・データの送信を行うかまたは行わないと決定する可能性がある。

何らかの方法で、制御プレーンの接続性およびユーザ・プレーンの接続性が、ユーザ機器とネットワークとの間で確立される。したがって、下りリンク・データおよび上りリンク・データは、確立されたユーザ・プレーンの接続を介して送信され得る。

さらなる態様によれば、ユーザ機器が、ユーザ・プレーンの接続を確立するか否かの決定を、そのような決定が行われていない場合にやはり行うことができるように、上で説明した手順が拡張される。特に、ユーザ機器が、トリガ・メッセージを受信したときに、ユーザ・プレーンを確立すると決定せず、接続性関連ネットワーク・エンティティも、ユーザ・プレーンを確立すると決定しなかったと仮定すると、ユーザ機器は、下りリンクの小データを受信したときに、上りリンク・データを送信するためにユーザ・プレーンの接続が必要か否かを再び判断する可能性がある。

これは、（受信される下りリンクの小データに応答する）あり得る将来の上りリンク・データに関する推定が不正確であり、より多くの上りリンク・データが送信される場合に特に有利である。制御プレーンは既に確立されており、下りリンクの小データが、接続性関連ネットワーク・エンティティからユーザ機器に送信される。小データを受信すると、ユーザ機器は、今、および近い将来、ネットワークに送信されるべき上りリンク・データを正確に判定することができる。したがって、ユーザ機器は、上りリンク・データに関する新しい情報に基づいて、ユーザ・プレーンの接続が必要か否かを再び判断することができる。

ユーザ機器による判定は、例えば、接続性関連ネットワーク・エンティティでの処理に関連するさらなる情報にも基づく可能性がある。特に、前に説明したように、制限パラメータまたは構成パラメータも、上りリンク・データが制御プレーンを介して送信され得るか、またはユーザ・プレーンを介して送信され得るかを判定するために考慮され得る。接続性関連ネットワーク・エンティティは、そのような制限情報を決定することができ、制御プレーン確立手順中にその情報をユーザ機器に送信することができる。

したがって、ユーザ機器は、接続性関連ネットワーク・エンティティが制御プレーンでその量の上りリンク・データを処理することができるか否かを判定するために、「正確な」上りリンク・データを、接続性関連ネットワーク・エンティティからの情報と照らし合わせることができる。

ユーザ・プレーンの接続が必要ない場合、ユーザ機器は、単に、制御プレーンのシグナリングを用いた上りリンク・データの送信に進む。一方、ユーザ機器は、上りリンク・データがユーザ・プレーンで送信されるべきであると判断する場合、ユーザ・プレーンの接続の確立をトリガする。ユーザ・プレーンの接続性を持った後、上りリンク・データおよびあり得るさらなる下りリンクの小データが、ユーザ・プレーンの接続を介して送信される。

要約すると、さまざまな態様によれば、下りリンクの小データの送信が、初め、制御プレーンのシグナリングによって計画される。しかし、制御プレーンを確立する途中と、さらに確立した後とに、（例えば、ユーザ機器から送信されるべき上りリンク・データを考慮して）ユーザ・プレーンも送信されるべきであるか否かを（接続性関連ネットワーク・エンティティか、またはユーザ機器かのどちらかで）決定することができる。この目的のために、さまざまな情報が、この決定を行うためにユーザ機器と接続性関連ネットワーク・エンティティとの間で交換される。

本発明をより深く理解するための例によれば、基地局を含む移動通信ネットワークに加入しているユーザ機器に下りリンクの小データ・パケットを送信するための方法が提供される。ユーザ機器は、制御プレーンのみを介した移動通信ネットワークとの接続性を確立するように、接続性関連ネットワーク・エンティティによってトリガされる。トリガするステップに応答して、ユーザ機器および接続性関連ネットワーク・エンティティは、ユーザ機器に関する制御プレーンの接続性を確立する。下りリンクの小データ・パケットは、確立された制御プレーンの接続性を使用してユーザ機器に送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器がＩＤＬＥ状態であるとき、トリガするステップが、制御プレーンのみの指示（control-plane-only indication）を含むページング・メッセージをユーザ機器に送信するステップを含む。この場合、接続性関連ネットワーク・エンティティは、ユーザ機器の移動管理エンティティである。あるいは、ユーザ機器がＤＥＲＥＧＩＳＴＥＲＥＤ状態であるとき、トリガするステップは、制御プレーンのみの指示を含むデバイス・トリガ・メッセージをユーザ機器に送信するステップを含む。この場合、接続性関連ネットワーク・エンティティは、移動管理エンティティである。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、下りリンクの小データ・パケットが、制御プレーンの非アクセス層メッセージを使用してユーザ機器に送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、下りリンクの小データ・パケットが、接続性関連ネットワーク・エンティティで受信され、シグナリング・メッセージを使用して接続性関連ネットワーク・エンティティから基地局に送信され、ＲＲＣ、無線リソース制御メッセージを使用して基地局からユーザ機器に送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、接続性関連ネットワーク・エンティティが、接続性を確立した時点、および／または接続性関連ネットワーク・エンティティがユーザ機器をトリガするためのトリガを受信するインターフェースに基づいて、制御プレーンの接続性に関してのみユーザ機器をトリガすることを決定する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器および接続性関連ネットワーク・エンティティが、ユーザ・プレーンの接続性および制御プレーンの接続性の確立に関連するコンテキスト情報を格納する。しかしながら、接続性関連ネットワーク・エンティティは、制御プレーンの接続性のみを確立することを決定する。さらに、接続性関連ネットワーク・エンティティは、制御プレーンのみが確立されることを保証する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、下りリンクの小データ・パケットが接続性関連ネットワーク・エンティティによって受信される場合、接続性関連ネットワーク・エンティティによってトリガするステップが、下りリンクの小データ・パケットを受信することによってトリガされる。下りリンクの小データ・パケットがゲートウェイによって受信される場合、接続性関連ネットワーク・エンティティによってトリガするステップが、ゲートウェイから接続開始メッセージを受信することによってトリガされ、接続開始メッセージが下りリンクの小データ・パケットに関する情報を含む。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、下りリンクの小データ・パケットがゲートウェイによって受信される場合、下りリンクの小データ・パケットが、制御プレーンのシグナリングを使用してゲートウェイから接続性関連ネットワーク・エンティティに送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、トリガするステップに応答して制御プレーンの接続性の確立を開始するときに、ユーザ機器が制御プレーン確立タイマを開始する。制御プレーン確立タイマは、移動通信ネットワークとの制御プレーンの接続性を確立したときに停止される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、トリガするステップに応答して、ユーザ機器が、下りリンクの小データ・パケットに応答して送信されるべき上りリンク・データの特徴を推定する。ユーザ機器は、上りリンク・データの推定された特徴を接続性関連ネットワーク・エンティティに送信する。接続性関連ネットワーク・エンティティは、上りリンク・データの受信された特徴に基づいて、データ・ベアラを確立すべきか否かについて決定する。接続性関連ネットワーク・エンティティがデータ・ベアラを確立すると決定した場合、下りリンクの小データ・パケットは、確立されたデータ・ベアラを使用してユーザ機器に送信される。上りリンク・データも、確立されたデータ・ベアラを使用してユーザ機器から送信される。接続性関連ネットワーク・エンティティがデータ・ベアラを確立しないと決定した場合、下りリンクの小データ・パケットは、確立された制御プレーンの接続性を使用してユーザ機器に送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、接続性関連ネットワーク・エンティティによる決定が、接続性関連ネットワーク・エンティティで受信される上りリンク・データの処理に関連する制限パラメータにさらに基づく。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、接続性関連ネットワーク・エンティティが、データ・ベアラを確立しないと決定した場合、接続性関連ネットワーク・エンティティで受信される上りリンク・データの処理に関連する制限パラメータを決定する。接続性関連ネットワーク・エンティティは、決定された制限パラメータをユーザ機器に送信する。ユーザ機器は、受信された下りリンクの小データ・パケットに基づいて、送信されるべき上りリンク・データを決定する。ユーザ機器は、受信された制限パラメータに応じて、かつ決定された送信されるべき上りリンク・データに基づいて、上りリンク・データを送信するためにデータ・ベアラを確立すべきか否かについて判定する。そのとき、ユーザ機器がデータ・ベアラを確立すると決定した場合、上りリンク・データが、確立されたデータ・ベアラを使用して送信され、下りリンクの小データ・パケットが、確立されたデータ・ベアラを使用して送信される。ユーザ機器がデータ・ベアラを確立しないと決定した場合、上りリンク・データが、確立された制御プレーンの接続性を使用して送信される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、上りリンク・データの特徴が、上りリンク・データの量および／もしくは周期性に関する情報、ならびに／または上りリンク・データが小さいのか、もしくは大きいのかについての指示を含む。

下りリンクの小データ・パケットを受信するためのユーザ機器であって、基地局を含む移動通信ネットワークに加入している、ユーザ機器が提供される。ユーザ機器の受信機が、制御プレーンのみを介した移動通信ネットワークとの接続性を確立するための、接続性関連ネットワーク・エンティティからのトリガ・メッセージを受信する。ユーザ機器のプロセッサ、ユーザ機器の送信機、および受信機が、トリガ・メッセージに応答して、接続性関連ネットワーク・エンティティとの制御プレーンの接続性を確立する。受信機は、確立された制御プレーンの接続性を用いて下りリンクの小データ・パケットを受信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器がＩＤＬＥ状態であるとき、受信機が、ページング・メッセージをトリガ・メッセージとして受信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、受信機が、ＲＲＣ、無線リソース制御メッセージを使用して基地局から下りリンクの小データ・パケットを受信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、プロセッサが、制御プレーンの接続性の確立を開始するときに、制御プレーン確立タイマを開始する。そして、プロセッサは、移動通信ネットワークとの制御プレーンの接続性を確立したときに制御プレーン確立タイマを停止する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器のプロセッサが、トリガ・メッセージの受信に応答して、下りリンクの小データ・パケットに応答して送信されるべき上りリンク・データの特徴を推定する。接続性関連ネットワーク・エンティティが上りリンク・データの送信された特徴に基づいてデータ・ベアラを確立すべきか否かについて決定するように、送信機が、上りリンク・データの推定された特徴を接続性関連ネットワーク・エンティティに送信する。接続性関連ネットワーク・エンティティがデータ・ベアラを確立すると決定した場合、受信機、送信機、およびプロセッサが、データ・ベアラを確立する。受信機は、確立されたデータ・ベアラを用いて下りリンクの小データ・パケットを受信する。送信機は、確立されたデータ・ベアラを使用して上りリンク・データを送信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、接続性関連ネットワーク・エンティティがデータ・ベアラを確立しないと決定した場合、受信機が、接続性関連ネットワーク・エンティティで受信される上りリンク・データの処理に関連する制限パラメータを接続性関連ネットワーク・エンティティから受信する。プロセッサが、受信された下りリンクの小データ・パケットに基づいて、送信されるべき上りリンク・データを決定する。プロセッサは、受信された制限パラメータに応じて、かつ決定された送信されるべき上りリンク・データに基づいて、上りリンク・データを送信するためにデータ・ベアラを確立すべきか否かを判断する。プロセッサがデータ・ベアラを確立すると決定した場合、送信機、受信機、プロセッサが、データ・ベアラを確立する。送信機は、確立されたデータ・ベアラを使用して上りリンク・データを送信し、受信機は、確立されたデータ・ベアラを使用して下りリンクの小データ・パケットを受信する。

基地局を含む移動通信ネットワークに加入しているユーザ機器に下りリンクの小データ・パケットを送信するための接続性関連ネットワーク・エンティティが、提供される。送信機が、制御プレーンのみを介した移動通信ネットワークとの接続性を確立するための、ユーザ機器へのトリガ・メッセージを送信する。プロセッサ、受信機、および送信機が、ユーザ機器に関する制御プレーンの接続性を確立する。送信機は、確立された制御プレーンの接続性を使用してユーザ機器に下りリンクの小データ・パケットを送信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器がＩＤＬＥ状態であるとき、送信機が、制御プレーンのみの指示を含むページング・メッセージをトリガ・メッセージとして送信する。この場合、接続性関連ネットワーク・エンティティは、ユーザ機器の移動管理エンティティである。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、送信機が、制御プレーンの非アクセス層メッセージを使用して下りリンクの小データ・パケットを送信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、ユーザ機器および接続性関連ネットワーク・エンティティが、ユーザ・プレーンの接続性および制御プレーンの接続性の確立に関連するコンテキスト情報を格納する。接続性関連ネットワーク・エンティティのプロセッサが、制御プレーンの接続性のみを確立すると判断し、後で、確立中に、制御プレーンのみが確立されることが保証される。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、プロセッサが、接続性を確立した時点、および／または受信機がユーザ機器をトリガするためのトリガを受信するインターフェースに基づいて、制御プレーンの接続性に関してのみユーザ機器をトリガすることを決定する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、下りリンクの小データ・パケットが接続性関連ネットワーク・エンティティによって受信される場合、トリガ・メッセージの送信が、受信機が下りリンクの小データ・パケットを受信することによってトリガされる。あるいは、下りリンクの小データ・パケットが移動通信ネットワークのゲートウェイによって受信される場合、トリガ・メッセージの送信が、受信機がゲートウェイから接続開始メッセージを受信することによってトリガされ、接続開始メッセージが下りリンクの小データ・パケットに関する情報を含む。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、受信機が、下りリンクの小データ・パケットに応答してユーザ機器によって送信されるべき上りリンク・データの特徴をユーザ機器から受信する。プロセッサが、上りリンク・データの受信された特徴に基づいて、データ・ベアラを確立すべきか否かについて決定する。プロセッサがデータ・ベアラを確立すると決定した場合、受信機、プロセッサ、および送信機が、データ・ベアラを確立する。送信機は、確立されたデータ・ベアラを使用してユーザ機器に下りリンクの小データ・パケットを送信する。受信機は、確立されたデータ・ベアラを使用して上りリンク・データを受信する。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、決定が、接続性関連ネットワーク・エンティティで受信される上りリンク・データの処理に関連する制限パラメータにさらに基づく。

上記の内容に対して追加的または代替的に使用され得る有利な例によれば、プロセッサが、データ・ベアラを確立しないと決定した場合、接続性関連ネットワーク・エンティティで受信される上りリンク・データの処理に関連する制限パラメータを決定する。送信機が、ユーザ機器が上りリンク・データを送信するためにデータ・ベアラを確立すべきか否かについて決定するために、決定された制限パラメータをユーザ機器に送信する。ユーザ機器がデータ・ベアラを確立すると決定した場合、受信機が、確立されたデータ・ベアラを使用して上りリンク・データを受信し、送信機が、確立されたデータ・ベアラを使用して下りリンクの小データ・パケットをユーザ機器に送信する。

以下、本発明を、添付の図面を参照してさらに詳細に説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図 ３ＧＰＰ ＬＴＥのＥ−ＵＴＲＡＮアーキテクチャ全体の例示的な概略を示す図 アクセス層プロトコルおよび非アクセス層プロトコルを含む、ＬＴＥで使用されるＵＥとＭＭＥとの間の制御プレーンのプロトコル・スタックを示す図 ＵＥと、ｅＮｏｄｅＢと、Ｓ−ＧＷと、ＰＤＮ−ＧＷとの間のユーザ・プレーンのプロトコル・スタックを示す図 ＳＲＢ１およびＳＲＢ２を含む、ＲＲＣ接続の確立を開示するシグナリング図 回線交換ネットワークのＳＭＳメカニズムを使用する小データの送信を示すシグナリング図 小データ送信に関連する制御プレーンのみのページングを示すシグナリング図 小データ送信のための制御プレーンの確立を示すシグナリング図 接続性関連ネットワーク・エンティティおよびＵＥが必要に応じてユーザ・プレーンに関する決定も行うことができるようにすることによって拡張された制御プレーンのみのページングを示すシグナリング図 ＭＭＥが、ユーザ機器による上りリンク・データの推定に基づいて、ユーザ・プレーンのデータ・ベアラを確立するべきか否かを決定する機会を与えられるシグナリング図 ユーザ機器が、下りリンクの小データを受信した後に、厳密に上りリンク・データに基づいて、ユーザ・プレーンのデータ・ベアラを確立するべきか否かを決定する機会を与えられるシグナリング図 通信ネットワークでＳＭＳを転送するためのアーキテクチャを示す図 通信ネットワークでＳＭＳを転送するために使用されるより新しいバージョンの例示的なアーキテクチャを示す図 通信ネットワークでＳＭＳを送信するためのプロトコル・スタックを示す図 移動ノードからコア・ネットワーク、すなわち、ショート・メッセージ・サービス・センターＳＭ−ＳＣへのＳＭＳ（ＭＯ ＳＭＳ）の送信を示すシグナリング図 ＳＭ−ＳＣから移動ノードへのＳＭＳ（ＭＴ ＳＭＳ）の送信を示すシグナリング図 図１４および１５によるＭＴ ＳＭＳおよびＭＯ ＳＭＳに関するシグナリングの交換を示す単純化したシグナリング図 本発明のさまざまな実施形態による無線リソースの解放を含む、ＳＭ−ＳＣから移動ノードへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 本発明のさらなる実施形態による無線リソースの解放を含む、移動ノードからＳＭ−ＳＣへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 本発明のさまざまな実施形態による無線リソースの解放を含む、ＳＭ−ＳＣから移動ノードへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 本発明のさらなる実施形態による無線リソースの解放を含む、移動ノードからＳＭ−ＳＣへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 本発明のその他の実施形態による無線リソースの解放を含む、ＳＭ−ＳＣからＵＥへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 ＵＥ、ＭＭＥ、およびＳＭ−ＳＣのＳＭＳエンティティがより詳細に示された、本発明のその他の実施形態による無線リソースの解放を含む、ＳＭ−ＳＣからＵＥへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 ＵＥ、ＭＭＥ、およびＳＭ−ＳＣのＳＭＳエンティティがより詳細に示された、本発明のその他の実施形態による無線リソースの解放を含む、ＵＥからＳＭ−ＳＣへのＳＭＳの送信に関するシグナリングの交換を示すシグナリング図 本発明の包括的な実施形態で実行されるステップを示す流れ図 従来技術によるＳＭＳ配信のさまざまなあり得る経路を示す図 Ｅ−ＵＴＲＡＮからＵＴＲＡＮへのＲＡＴ間ハンドオーバの準備フェーズを示す図 Ｅ−ＵＴＲＡＮからＵＴＲＡＮへのＲＡＴ間ハンドオーバの実行フェーズを示す図 ＳＭＳのみの送信中に改良されたハンドオーバ手順が実行される本発明の一実施形態の例示的なメッセージ交換を示す図 図３１に関連して説明する本発明の一実施形態によるＳＭＳ配信経路を示す図 改良されたページングおよびアタッチ・メカニズムが示された、本発明の一実施形態によるメッセージ交換を示す図 図３３に関連して説明する本発明の一実施形態によるＳＭＳ配信経路を示す図 改良されたページングおよびアタッチ・メカニズムが示された、本発明の一実施形態によるメッセージ交換を示す図 図３５に関連して説明する本発明の一実施形態によるＳＭＳ配信経路を示す図

［定義］
以下で、本明細書で頻繁に使用されるいくつかの用語を定義する。

「移動ノード」は、通信ネットワーク内の物理的なエンティティである。１つのノードは、いくつかの機能エンティティを有する可能性がある。機能エンティティとは、所定の一式の機能を実装し、および／または所定の一式の機能をノードもしくはネットワークのその他の機能エンティティに提供するソフトウェア・モジュールまたはハードウェア・モジュールを指す。ノードは、ノードが通信することができる通信設備または媒体にノードをアタッチする１つまたは複数のインターフェースを有する可能性がある。同様に、ネットワーク・エンティティは、そのネットワーク・エンティティがその他の機能エンティティまたは通信相手のノードと通信することができる通信設備または媒体に機能エンティティをアタッチする論理インターフェースを有する可能性がある。

「ＭＴＣデバイス」は、移動ノードと一緒に配置される可能性があり、または移動ノードと一緒に配置されない可能性がある、通信ネットワーク内の機能エンティティと理解され得る。ＭＴＣデバイスは、マシン型通信の要件に合わせて適合または最適化される。

「小データ」は、小さなＩＰパケット（例えば、最大１０００バイトまで）、ＳＭＳ、または何らかのその他のアプリケーションに固有のデータである可能性があるデータの小さなチャンクと理解され得る。「小データ」という用語は現在の標準化で既に使用されているが、その正確な意味は決められていない。必ずではないがよくある解釈は、そのデータがＳＭＳに収まるほど十分に小さいことである。それに対応して、小データは、ＳＭＳのペイロードである１４０バイト未満である可能性がある。したがって、本発明においては、小データは、ＳＭＳであるとも理解され得る。しかし、上で説明したように、この点に関しては、標準化によって近い将来に決定されるであろう。そのとき、本発明と本発明の実施形態とは、決定された小データに対して適用され得る。

「加入した」という用語は、ユーザ機器がネットワーク・リソースの利用を申し込んでいるときに、ネットワークが、少なくとも、ユーザ機器がネットワークにアタッチするのをサポートするために十分な情報を知っていることであると理解され得る。特に、これは、ＩＭＳＩなどのユーザ機器のＩＤ、ユーザ機器がネットワーク内でどのリソースを利用することを許されているかの情報、ユーザの機能についての情報である可能性がある。さらに、ユーザ機器を効率的に「探索」することを可能にするために、ネットワークは、ユーザ機器のおおよその位置を知っている可能性がある。ユーザ機器がＩＤＬＥモードである場合、ネットワークは、ユーザ機器をページングすることができるように、ＩＭＳＩ、（１つまたは複数の）あり得るトラッキング・エリア、ベアラ・コンテキスト（ＥＰＳ、ＳＲＢ）を含むコンテキスト・データをコア・ネットワークに格納している。

一部の実施形態は、「データ・ベアラ（またはデータ接続）」と制御プレーンの接続性（すなわち、シグナリング接続／ベアラ）とを区別する。基本的に、データ・ベアラは、ユーザ・プレーンに関連付けられ、ユーザ・プレーンの一部をなし、ユーザ・データを転送するために確立され、概してユーザ機器とネットワークとの間で制御シグナリングを転送する制御プレーンおよび「シグナリング・ベアラ」とは対照的である。

実施形態の一部で使用される用語「アタッチ」または「アタッチされた」は、ユーザ機器がデータを送受信するためにネットワークに登録されることと理解され得る。「アタッチされた」状態では、ネットワークが、少なくともおおよそ、ユーザ機器の位置を知っており、したがって、着信データ（移動体終端データ）がユーザ機器に到達できる。

用語「ハンドオーバ」は、主としてＣＯＮＮＥＣＴＥＤモードでの移動に関連して使用され、上りリンク・データまたは下りリンク・データがハンドオーバ元のポイント（ＢＳ、ＮｏｄｅＢ、ｅＮｏｄｅＢ、またはアクセス・ネットワークそのもの）からハンドオーバ先のポイント（ＢＳ、ＮｏｄｅＢ、ｅＮｏｄｅＢ、またはアクセス・ネットワークそのもの）に転送またはリダイレクトされることも意味する。

以下で、いくつかの例を詳細に説明する。これらの説明は、本発明を限定するものと理解されるべきでなく、本発明をより深く理解するための本発明の実施形態の単なる例として理解されるべきである。当業者は、特許請求の範囲に記載された本発明の基本原理が、異なるシナリオに、本明細書において明確に説明されていない方法で適用され得ることが分かるに違いない。

一例によれば、従来技術の問題の一部が、小データがユーザ機器に関して保留されるべきであるときに、ユーザ・プレーンではなく、制御プレーンの接続のみを確立するようにユーザ機器をトリガすることによって解決される。図７および８を参照して詳細な説明を行う。

図７は、コア・ネットワーク、すなわちコア・ネットワーク・エンティティがユーザ機器宛ての小データを受信すると仮定した基本的な例を開示している。ユーザ機器は、ネットワークにアタッチされておらず、すなわち、登録解除状態またはアイドル状態であり、いずれにせよ、小データを受信するためのネットワークとの接続を持たない。下りリンク・データが保留中であるときにネットワークに接続するようにユーザ機器をトリガする役割を担うコア・ネットワーク・エンティティ（以降、接続性関連ネットワーク・エンティティと表記される）が、ユーザ機器がいる無線セルのｅＮｏｄｅＢを介してユーザ機器をトリガする。下りリンク・データが小さいので、接続性関連ネットワーク・エンティティは、制御プレーンに関してのみユーザ機器をトリガすることを決定する。それに対応して、トリガ・メッセージは、制御プレーンの接続性のみを確立し、予測するようにユーザ機器に命令するフラグなどの適切な指示を含む。ユーザ機器および接続性関連ネットワーク・エンティティは、下りリンクの小データが送信され得る、ユーザ機器と接続性関連ネットワーク・エンティティとの間の制御プレーンの接続を確立する。

制御プレーンのみを使用する利点は、とりわけ、シグナリング、遅延、およびトラフィック全体が削減でき、ネットワークのリソースが節約でき、ＵＥの処理能力を小さくできることである。小データによって消費されるバイト数は、通常、ユーザ・プレーンを確立するシグナリングによって消費されるバイト数よりもずっと少ないので、多数のＵＥが「小データ」向けに構成されている場合、ネットワークのトラフィック全体が大幅に削減でき、これは、特にマシン型デバイスの場合に当てはまりやすい。さらに、制御プレーンのシグナリングのみを使用するので、ＵＥは、ＣＯＮＮＥＣＴＥＤ状態に遷移する必要がなく、したがって、無線測定報告と、ｅＮｏｄｅＢレベルの移動と、結果としてＵＥの電力とが節約できる。

上で説明したように、接続性関連ネットワーク・エンティティは、小データを受信するときに、制御プレーンに関してのみユーザ機器をページングすることを決定する。換言すると、接続性関連ネットワーク・エンティティは、受信されたデータが「小データ」であるか否かを判定し、それに対応して、制御プレーンのみの指示をしながら、または制御プレーンのみの指示をせずにユーザ機器をページングする。その他の実施形態においては、制御プレーンのみに関してページングを行うという決定は、受信されたデータが小さいか否かだけに依存するのではなく、時間帯、データが受信されたインターフェースなどの観点にさらに依存する可能性があり、または小データに加えて特別な指示が受信される場合にだけ行われる可能性がある。それらの観点に基づいて、接続性関連ネットワーク・エンティティは、さらなるデータが送信されるか否か、または一部のネットワーク・エンティティに対する負荷が限界に達し、したがって、ユーザ・プレーンを使用することが好ましいか否か、を判定することができる可能性がある。

別の観点は、ユーザ機器がＩＤＬＥモードであるときに格納したコンテキストに関連する。特に、ユーザ機器がＣＯＮＮＥＣＴＥＤモードからＩＤＬＥモードに変わるとき、ネットワーク（例えば、ＭＭＥ）およびユーザ機器は、データ・ベアラおよびユーザ・プレーンに関連するコンテキストを含むユーザ機器コンテキストを格納する。従来技術においては、ユーザ機器がネットワークによってページングされるとき、コンテキストが利用できるすべてのベアラ、すなわち、制御プレーンの接続およびユーザ・プレーンの接続が確立される。

この例によれば、ユーザ機器が、制御プレーンに関してのみページングされる。したがって、ネットワークおよび／またはユーザ機器が利用可能なユーザ・プレーンのベアラ・コンテキストを持っていたとしても、制御プレーンの接続のみが確立される。コンテキストが利用できるユーザ・プレーンのそれらのデータ・ベアラは、確立されない。

図８は、図７の上で説明した例に基づいているが、ＬＴＥの特定のシステムでこれらの原理を実装する。

図８の例では、以下のことを仮定する。ユーザ機器がＩＤＬＥモードであり、小データが、背景技術の節で説明したＳＭＳ−ｏ−ＳＧｓメカニズムを用いてＭＭＥで受信される。ユーザ機器および／またはネットワークが、特別な機能である「小データ送信」、すなわち、小データ・パケットの特別な処理をするように構成されているとさらに仮定する。「小データ」機能は、背景技術の節で説明したＭＴＣデバイス用に定義されている。以下の説明では、ユーザ機器とだけ述べるが、ユーザ機器とはＭＴＣデバイスのことも指す可能性があると留意すべきである。

「小データ」機能により、ネットワークおよびユーザ機器は、（１つまたは複数の）ユーザ・プレーンの接続を確立することを避けるために、可能であれば、ユーザ・プレーンではなく制御プレーンを介して小データが転送されるべきであることを知る。例えば、ネットワークで、「小データ」機能が構成され、加入データベースに格納され得る。アタッチ手順の間に、ＭＭＥが、加入者データベースから構成された機能を取得する。「小データ」機能は、ＵＥにおいていくつかの方法で構成され得る。例えば、「小データ」機能は、ＵＳＩＭ（Universal Subscriber Identity Module：汎用加入者識別モジュール）カードに予め構成される可能性があり、またはＯＭＡ−ＤＭ（Open Mobile Alliance Device Management：オープン・モバイル・アライアンス・デバイス管理）もしくはＯＴＡ（Over the Air：オーバー・ザ・エア）デバイス管理プロトコルによって構成される可能性があり、またはアタッチ手順中にＭＭＥによって構成される可能性がある。アタッチ手順中のユーザ機器とＭＭＥとの間のいわゆる「機能交換（capabilities exchange）」は、３ＧＰＰをベースとする移動通信ネットワークでは当たり前のメカニズムである。

「小データ」の厳密な意味は、今のところ、標準化で厳密に定義されていない。よくある解釈は、データが、例えば、１つのＳＭＳに収まるほど小さいということである。これは、ＳＭＳのペイロードが１４０バイトであるので、およそ１４０バイトの情報を意味する。この目的では、小データの厳密なサイズは重要ではない。「小データ」という表記は、小さなＩＰパケット、ＳＭＳ、または何らかのその他のアプリケーションに固有のデータである可能性があるデータの小さなチャンクを意味する。したがって、「小データ」送信は、下りリンクおよび上りリンクで、ＭＭＥとＵＥとの間のＳＭＳ送信を行う場合を含む。

この手順に関与するコア・ネットワークのエンティティは、ＭＭＥおよびサービング・ゲートウェイであると想定される。さらに、小データは、回線交換ネットワークからＭＳＣを介して受信され得る。将来的に、その他のまたは追加のエンティティが、ＭＴＣ機能のために定義される可能性がある。その場合、この例が、それらのその他のエンティティにも適用できる。

ユーザ機器はＩＤＬＥモードであり、したがって、ユーザ機器はネットワークにアタッチされているが、制御プレーンの接続もユーザ・プレーンの接続も確立されていない。ＭＭＥは、ＵＥコンテキストを格納しており、格納されたトラッキング・エリアまたはルーティング・エリアに基づいて、ユーザ機器がどこにいるはずであるか、すなわち、どの（１つまたは複数の）ｅＭｏｄｅＢがユーザ機器に到達するためにページングされるべきであるかを判定することができる。さらに、ＭＭＥは、下りリンク・データが小データであると判定し、ユーザ機器が「小データ」機能に属することを知っている。したがって、制御プレーンの接続のみが、下りリンクの小データを送信するために使用されるべきである。

図８から分かるように、ＭＭＥは、制御プレーンに関してのみユーザ機器をページングする。あるいは、ＭＭＥは、小データに関して、すなわち、小データ機能により、ユーザ機器によって受信されるべきデータが小データであるという指示を含めてユーザ機器をページングし、ユーザ機器は、構成から、小データが制御プレーンのシグナリングを介して受信されるべきであることを知る。

シグナリング・メッセージでの追加的なオーバーヘッドが少ない指示の１つのあり得る実装は、単一のフラグである可能性がある。例えば、フラグが「０」に設定されているとき、ページングは通常通りである（すなわち、通常の制御プレーンおよびユーザ・プレーンの接続／ベアラが確立されることになる）。フラグが「１」に設定されているとき、ページングは、制御プレーンの接続のみに関するものであり、すなわち、ユーザ・プレーンの接続／ベアラは確立されない。ＭＭＥからｅＮｏｄｅＢに送信されるページング要求メッセージが、対応するビット・フィールドによって拡張される可能性がある。ｅＮｏｄｅＢは、ユーザ機器に関するページング機会を計算し、適切なタイム・スロットで無線インターフェースを介してユーザ機器にページング・メッセージを送信する。ｅＮｏｄｅＢからＵＥに送信されるページング・メッセージも、制御プレーンの確立のみ（または小データ）を指示するための対応するビット・フィールドを含む。

ユーザ機器は、ページング・メッセージを受信し、制御プレーンのみが確立されるべきであると判定する。したがって、ユーザ機器は、ＲＡＣＨ手順を開始してネットワークとの同期をとる。それ以降のシグナリングは、図５に関連して既に説明したシグナリングと同様である。シグナリング無線ベアラＳＲＢ０、１、および２が、連続的に確立される。

ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージで、ＭＭＥとのＮＡＳ接続の確立をトリガするために、ページングに応答してＮＡＳ ＳｅｒｖｉｃｅＲｅｑｕｅｓｔメッセージが送信される。ユーザ機器は、サービス要求メッセージ（ＳＲ）または拡張サービス要求メッセージ（ＥＳＲ）を送信するとき、通常、背景技術の節で説明したタイマＴ３４１７またはＴ３４１７ｅｘｔを開始する。しかし、ユーザ・プレーンをまったく確立せずに、制御プレーンの接続性のみが確立されるので、ユーザ機器のタイマの処理が、あらゆるエラーの場合を避けるために適合される可能性がある。ユーザ機器がタイマＴ３４１７を開始し、ユーザ・プレーンの接続が確立されない場合、タイマＴ３４１７が切れ、ユーザ機器がエラーを検出し、ＮＡＳサービス要求メッセージを再送信する。

有利な例によれば、新たなタイマが導入される可能性があり、または既存のタイマ、例えばＴ３４１７が適合される可能性がある。Ｔ３４ｓｄ（「ｓｄ」は小データ（small data）を意味する）と表記される新たなタイマが、ユーザ機器がＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージでＮＡＳサービス要求または拡張サービス要求メッセージを送信するときに開始される。タイマＴ３４ｓｄは、いくつかのオプションによって停止され得る。例えば、ユーザ機器は、ＮＡＳ下りリンク・トランスポート・メッセージ、またはそれに対応して下りリンクの「小データ」が受信されるときに、タイマＴ３４ｓｄを停止する（すなわち、クリアまたは終了する）可能性がある。別のオプションによれば、ユーザ機器は、ＳＲＢ２ベアラの確立が正常に完了するとき、すなわち、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを送信するときに、タイマＴ３４ｓｄを停止する可能性がある。さらに別のオプションは、下りリンクの有効な（すなわち、正しく完全性を保護され、および／または暗号化された）ＮＡＳメッセージが受信されるときに、タイマＴ３４ｓｄを終了することである。

初期コンテキスト設定手順が、制御プレーンの確立を進め、必要なＵＥコンテキストを確立するためにＭＭＥとｅＮｏｄｅＢとの間で実行される。ＭＭＥが、Ｓ１−ＡＰ「初期コンテキスト設定要求」メッセージを生成し、ｅＮｏｄｅＢに送信する。しかし、図５にしたがった通常の手順と異なり、ＭＭＥは、ユーザ・プレーンの確立を避けるために、Ｅ−ＲＡＢコンテキストを初期コンテキスト設定メッセージに含めない。したがって、ＭＭＥは、主に、セキュリティに関連するコンテキストを初期コンテキスト設定要求メッセージに含め、その結果、ｅＮｏｄｅＢが、ＳＲＢ１およびＳＲＢ２無線ベアラを確立することができる。

ＭＭＥおよびｅＮｏｄｅＢがＳ１−ＡＰ初期コンテキスト設定手順を実行した後、または実行している間に、ｅＮｏｄｅＢは、Ｕｕインターフェースを介してＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ手順を開始してＳＲＢ１を完了し、ＳＲＢ２無線ベアラを確立する。主として、ｅＮｏｄｅＢは、ＳＲＢ１およびＳＲＢ２を介して送信されるＲＲＣメッセージが完全性を保護され、暗号化されるので、この手順を完了するためにセキュリティ・コンテキストを必要とする。ＲＲＣ接続再構成手順は、ＲＲＣ接続を修正すること、すなわち、無線ベアラを確立／修正／解放することを目的とする。したがって、通常、ＲＲＣ接続再構成手順が、ＳＲＢ２と、さらにはユーザ・プレーンのデータ無線ベアラとを確立するために実行される。しかし、制御プレーンの接続のみ、すなわち、ｅＮｏｄｅＢとユーザ機器との間のシグナリング無線ベアラのみが確立されるべきであるので、ＲＲＣ接続再構成手順は、ＳＲＢ２を確立するためにのみ使用される。

したがって、シグナリング無線ベアラＳＲＢ０、１、および２が、確立される。ｅＮｏｄｅＢとＭＭＥとの間のＳ１−ＡＰ接続も、制御プレーンの一部である。ＭＭＥは、ユーザ機器へのＮＡＳトランスポート・メッセージの送信を開始することができる。ＭＭＥは、小データを含むＮＡＳ下りリンク・トランスポート・メッセージを生成し、そのＮＡＳ下りリンク・トランスポート・メッセージは、Ｓ１−ＡＰインターフェースおよびＲＲＣインターフェースを介してユーザ機器に転送される。ｅＮｏｄｅＢは、ＮＡＳ下りリンク・トランスポート・メッセージを受信するとき、そのメッセージをユーザ機器へのＲＲＣ下りリンク情報転送メッセージで透過的にカプセル化する。したがって、ユーザ機器は、制御プレーンのみを使用して下りリンクの小データを受信する。

制御プレーンを介して小データを搬送するための１つのあり得る手段は、上で説明したように、ＭＭＥとユーザ機器との間のＮＡＳプロトコルである。この点での１つの代替的な手段は、ＭＭＥとユーザ機器との間でホップ・バイ・ホップ送信を用いて小データを転送することである可能性がある。この目的で、小データは、ＭＭＥとｅＮｏｄｅＢとの間はＳ１−ＡＰプロトコルでカプセル化され、ＵＥとｅＮＢとの間はＲＲＣプロトコルでカプセル化される。最も適切なメッセージは、ＲＲＣ上りリンク／下りリンク情報転送メッセージである。

別の有利な例によれば、ＭＭＥが、シグナリング目的の（例えば、ＥＳＭおよびＥＭＭシグナリングの）ＮＡＳメッセージと、データ転送目的の（例えば、上りリンクおよび下りリンク・データ転送の）のＮＡＳメッセージとの優先度を区別するために、ＮＡＳトランスポート・メッセージの優先度を示す可能性がある。ＭＭＥは、ｅＮｏｄｅＢへのＳ１−ＡＰ「初期コンテキスト設定要求」メッセージか、またはＮＡＳメッセージ自体かのどちらかでそれらの異なる優先度を示すことができ、その結果、ｅＮｏｄｅＢが、異なる優先度を有する、小データを含むＮＡＳメッセージを処理することができる。ＮＡＳメッセージ自体に優先度を含めることの不利な点は、ｅＮｏｄｅＢが、そのＮＡＳメッセージを無線リンクを介してＲＲＣメッセージで送信する前にＮＡＳメッセージを調べるべきであるということである。

あるいは、ＭＭＥは、ＮＡＳメッセージ（すなわち、小データ）を搬送する各Ｓ１−ＡＰ ＮＡＳデータ・トランスポート・メッセージで比較的低い優先度を示すことができ、その結果、ｅＮｏｄｅＢが、ＮＡＳメッセージを詳細に調べることなく優先度を認識することができる。

図８では、ＭＭＥが、小データを受信するときに、制御プレーンのみの指示をしながらユーザ機器をページングすることを決定すると仮定した。しかし、制御プレーンのみの指示をしながらページングするか否かのＭＭＥでの決定は、さらに複雑になり得る。「小」データに関してユーザ機器をページングするべきか、または「通常」データに関してユーザ機器をページングするべきかのＭＭＥによる決定は、決定を行う時点、すなわち、時間帯も考慮するように拡張され得る。例えば、ある期間内、例えば、１：００〜２：００は、ユーザ機器とＭＴＣサーバとが「小データ」を交換することができるが、この時間以外は、通常データのみが交換可能である。あるいは、ある時間内は、制御プレーンが「小データ」のために使用できるが、その他の時間には、制御プレーンは「小データ」のために使用できない。複数の期間、例えば、１：００〜１：３０、１５：００〜１５：３０が存在し得る。

ＭＭＥがページング・メッセージで「小データ」の指示を使用すべきか否かを決定するためのその他の代替的方法は、ＭＭＥが下りリンク・データ自体を受信するか否か（例えば、ＳＭＳの場合）、またはＭＭＥが下りリンク・データ通知（ＤＤＮ）によってトリガされるか否かを考慮する。例えば、ＭＭＥがＵプレーンのデータ・パケットを受信する場合、ＭＭＥはＣプレーンの接続性のみを開始する。そうではなく、ＭＭＥが、例えばＳ−ＧＷからＤＤＮの指示を受信する場合、ＭＭＥは、通常データのための通常のページングを開始する。

代替的に、ＭＭＥは、ユーザ・プレーンのエンティティ（例えば、サービング・ゲートウェイ）による指示（もしくは小データ）、または別の特別なエンティティからの指示（もしくは小データ）を受信するか否かも決定で考慮する可能性がある。例えば、データ通知がサービング・ゲートウェイから受信される場合、「通常の」、すなわち、制御プレーンおよびユーザ・プレーンのページングが使用される。しかし、小データが特別なＭＴＣゲートウェイから到着する場合は、ＭＭＥは、小データ用の、すなわち、制御プレーンのみのページングを開始する。

以上、ＩＤＬＥモードのユーザ機器の場合について説明した。しかし、上記の原理は、ネットワークから登録解除されているユーザ機器にも拡張され得る。３ＧＰＰでは、これは、ユーザ機器がオフライン状態であり、オフライン状態はデタッチされた状態または登録解除された状態と等価であるので、オフライン小データ送信（offline small data transmission）として知られている。この場合、デタッチされたユーザ機器が、ネットワークにアタッチするようにトリガされる。したがって、対応するトリガ・メッセージが、ＭＭＥからｅＮｏｄｅＢを介してユーザ機器に送信される。送信は、さまざまな方法で実行され得る。

・ トリガ・メッセージのブロードキャスト：ＵＥおよびネットワークが、特定のブロードキャスト・リソースを使用するように構成され、トリガ・メッセージがブロードキャストされる。

・ トリガ・メッセージとしてのページング：ＵＥおよびネットワークが、ＩＤＬＥ状態のＵＥのために使用されるページング・メカニズムと同じページング・メカニズムか、またはデタッチされた／オフラインのＵＥのための拡張されたページング・メカニズムかのどちらかを適用する。ページング・メカニズムの１つの望ましい最適化方法は、ＤＲＸサイクル、すなわち、ページングが発生する時間間隔を伸ばすことである。現在、ページングＤＲＸサイクルは、最大で約５秒である可能性があるが、登録解除されたＵＥのページングのための最適化された値は、分単位または時間単位の値になる可能性がある。

いずれにせよ、トリガ・メッセージは、一意のＵＥ ＩＤを含み得る。上述の例のページング・メッセージと同様に、トリガ・メッセージは、ネットワークが制御プレーンの接続性のみを確立したいという、ユーザ機器への指示を含む。そのとき、アタッチ手順の間に、ユーザ機器は、デフォルトのＥＰＳデータ・ベアラが確立されないことを知り、例えば、タイマＴ３４１７またはＴ３４１７ｅｘｔではなくタイマＴ３４ｓｄを開始する。

アタッチ手順に関するいくつかの最適化も導入される可能性があり、例えば、ユーザ機器は、アクセス・ポイント名（ＡＰＮ）を送信しないか、またはＰＤＮゲートウェイとプロトコル構成オプション（ＰＣＯ）を交換しないか、またはＰＤＮタイプ（すなわち、ＩＰｖ４もしくはＩＰｖ６）を指示しない。しかし、ほとんどの最適化は、ネットワーク側で実現される。ＭＭＥは、ＥＰＳベアラ・コンテキストを有するとしてもＥＰＳベアラを確立する必要がない。したがって、ＭＭＥからＳＧＷ、さらにはＰＧＷへのシグナリング、ならびにＰＣＣエンティティへのシグナリングが、回避され得る。

ユーザ機器がＣプレーンの接続性のためにネットワークにアタッチする場合、小データが制御プレーン（ＮＡＳプロトコル）を介して送信された後、アタッチを終了することが望ましい可能性がある。その理由は、データ・ベアラがないためにユーザ機器が「通常の」上りリンク・データを送信することができず、ユーザ機器がＩＰ構成を持たず、したがって割り振られたＰＧＷが存在しないために「通常の」下りリンク・データが受信できないからである。

図８に関連して説明したように制御プレーンの接続性を確立し、下りリンクで小データを送信するための残りの手順は、同じままである。

上の説明では、小データがＭＭＥに到着し、したがって、ユーザ機器がネットワークにアタッチするようにページングまたはトリガをトリガすると仮定する。例えば、小データは、回線交換ネットワークから、特に、ＳＭＳオーバーＳＧｓが実装されているときにＭＳＣから受信される可能性がある。しかし、将来、小データは、ユーザ機器がアタッチされるＰＤＮ−ＧＷにおいてＩＰパケットとして受信される可能性もある。この場合、ＰＤＮゲートウェイが、下りリンクの小データをサービング・ゲートウェイに転送する。ユーザ機器がＩＤＬＥ状態であるか、または登録解除されているので、ユーザ機器のｅＮｏｄｅＢへのいかなるＳ１−Ｕベアラも存在せず、下りリンクの小データはさらに転送できない。したがって、サービング・ゲートウェイは、ユーザ機器をページング／トリガするようにＭＭＥをトリガする。

サービング・ゲートウェイは、下りリンク・データが「小データ」であると判定することができ、したがって、ＭＭＥへの下りデータ通知（Down Data Notification）メッセージに対応する指示を含める。追加的にまたは代替的に、サービング・ゲートウェイは、下りデータ通知メッセージで小データのサイズを示す可能性がある。次いで、ＭＭＥが、ネットワークにアタッチするようにユーザ機器をトリガ（ページング）し、例えば、ＧＴＰ−Ｃプロトコルを用いて制御プレーンでＳ１１インターフェースを介してＭＭＥにデータを転送するようにサービング・ゲートウェイに要求する必要がある。

代替的に、サービング・ゲートウェイは、下りリンク・データが小データであると判定することができ、例えば、下りデータ通知メッセージでＭＭＥに下りリンク・データを転送する。あるいは、小データを転送するために、サービング・ゲートウェイとＭＭＥとの間で別のメッセージが使用される可能性がある。それにより、ＭＭＥは、小データのサイズに基づいて、上述のように、制御プレーンのみの指示をしながらユーザ機器をページングすべきか、または制御プレーンのみの指示をせずにユーザ機器をページングすべきかを判定することができる。

［さらなる例］
上で説明した手順は、ユーザ機器およびＭＭＥのどちらか一方または両方が、下りリンクの小データによってトリガされる制御プレーンの接続の確立に加えて、ユーザ・プレーンの接続を確立することを決定することが可能であるように拡張され得る。

別の言い方をすれば、さらなる例は、データ送信（上りリンクおよび下りリンク）が制御プレーンのみで実行されるべきか、またはユーザ・プレーンで実行されるべきかをユーザ機器とＭＭＥとの間でネゴシエーションすることを可能にする。以下でより詳細に説明するように、この「ネゴシエーション」は、基本的に、決定にかかわる情報を交換することからなり、ＮＡＳプロトコルを介して実行され得る。

ネゴシエーションされる情報は、主として、制御プレーンで許可されるべき上りリンクおよび下りリンクのデータおよび／またはリソースの制限を表す。別の言い方をすれば、新しい情報要素が、制御プレーンのメッセージに含められ得るデータのデータ・サイズおよびデータの時間の制限（例えば、周期性または所与の期間内）を記述する。ユーザ機器は、「小データ」送信ＭＴＣ機能のために加入または構成される。したがって、下りリンクで送信されるデータは、ユーザ・プレーンが必要ないほど小さいと見なされる。ユーザ機器とＭＭＥとの間のネゴシエーションは、いつ小データが本当に「小さい」と見なされるのかについて柔軟な構成を可能にする。

ネゴシエーションは、制御プレーンの負荷および／またはＭＭＥの負荷に依存する可能性がある。例えば、ＭＭＥの負荷がかなり高い場合、制御プレーンを介して大量のデータを送信することは望ましくない可能性があり、データはユーザ・プレーンを介して送信されるべきであり、したがって、ＭＭＥを通過しない。それとは対照的に、ＭＭＥの負荷が少ない場合、ＭＭＥは、制御プレーンを介したより多くの量のデータの送信に関与することができる。

さらに、別のシナリオは、ＵＥ（ＭＴＣデバイス）がさまざまな移動通信ネットワークにアタッチすることができ、各ネットワークが「小データ」機能に関して異なる構成を持つことができることである可能性がある。１つのネットワークにおいて、小データは１００バイトまでに制限される可能性があり、別のネットワークでは、小データは５００または１０００バイトまでに制限される可能性がある。

したがって、ＭＭＥおよびユーザ機器のどちらか一方または両方がユーザ・プレーンの接続も確立して下りリンク・データおよび上りリンク・データを送信／受信する方がよいのか否かについて決定することを可能にすることに関連して、小データ送信にネゴシエーションを導入することが有利である。

図９は、ユーザ機器およびＭＭＥが手順の仮定でユーザ・プレーンの接続性について決定することができるそのような手順を開示する。図から明らかなように、ページングを受信すると、ＵＥは、保留中の上りリンク・データを判定し、および／またはそのＵＥがページングされた原因の下りリンク・データに応答して送信されるべき将来の上りリンク・データを推定する。ユーザ機器は、制御プレーンの確立を開始する。保留中の上りリンク・データに関する対応する情報が、接続性関連ネットワーク・エンティティに送信され、次いで、接続性関連ネットワーク・エンティティが、受信された保留中の上りリンク・データの情報を考慮してユーザ・プレーンの接続が必要か否かを決定することができる。ＭＭＥは、ＭＭＥで制御プレーンを介して受信された上りリンク・データを処理することに関する特定の制限も考慮する可能性がある。

ＭＭＥがユーザ・プレーンでデータ・ベアラを確立しようと決定した場合、下りリンク・データおよび上りリンク・データが、（１つまたは複数の）ユーザ・プレーンの接続を使用してユーザ機器とネットワークとの間で交換され得る。

ＭＭＥがユーザ・プレーンでデータ・ベアラを確立しないと決定した場合、制御プレーンの接続のみが確立され、下りリンクの小データは制御プレーンのシグナリングを使用してユーザ機器に送信される。有利なことに、ユーザの確立を決定するために接続性関連ネットワーク・エンティティによって使用される制限パラメータが、制御プレーンの接続を使用してユーザ機器にも送信され得る。ユーザ機器は、下りリンクの小データを受信するとき、上りリンク・データの正確な量および周期性を判定することができ、ユーザ・プレーンの接続性が上りリンク・データを送信するために必要となるか否かを判断することができる。さらに、ユーザ機器は、制限パラメータを与えられる場合、判定された上りリンク・データを、ＭＭＥによって決定された制限と比較することができ、したがって、上りリンク・データを送信するためにユーザ・プレーンを使用するか否かを決定することができる。

ユーザ機器は、ユーザ・プレーンの接続を確立すると決定した場合、ユーザ・プレーンの接続を開始し、完了する。その後、下りリンク・データおよび上りリンク・データが、確立されたユーザ・プレーンの接続性を使用してネットワークとユーザ機器との間で交換され得る。

図１０は、ＭＭＥがユーザ機器が送信する必要がある上りリンク・データを考慮してユーザ・プレーンの接続性を確立することを決定することができる１つの例を開示する。例示を目的として、図１０の例に関して、ここまでと同じ仮定がなされる。例えば、ユーザ機器はネットワークにアタッチされているが、ＩＤＬＥモードである。それに対応して、ＭＭＥおよびユーザ機器は、ＵＥコンテキストを格納しており、ＵＥコンテキストは、ユーザ・プレーンのデータ無線ベアラおよびＳ１−Ｕベアラに関する情報も含む。小データは、ＭＭＥによって、例えば、ＭＳＣからのＳＭＳ（ＳＭＳ−ｏ−ＳＧｓ）として受信される。

ＭＭＥでデータを受信すると、ＭＭＥは、ページングが「小データ」機能を対象としており、すなわち、ユーザ機器に小データを送信するのに制御プレーンだけで十分であるという指示を含めてユーザ機器をページングする。換言すれば、ＭＭＥは、ユーザ・プレーンのデータ無線ベアラおよびＳ１−Ｕベアラに関するコンテキスト情報を格納しているにもかかわらず、制御プレーンの接続だけを確立すると決定する。通常、従来技術では、ＭＭＥは、コンテキスト情報を有しているすべての接続、すなわち、ユーザ・プレーンの接続および制御プレーンの接続を確立する。

それに対応して、ページングに応答して、ユーザ機器は、図８に関して既に説明したのと同じ方法（ＲＡＣＨ、ＵＬ許可、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐ）で制御プレーンの接続の確立を開始する。

しかし、図１０による例では、ユーザ機器が、送信すべき保留中の上りリンク・データが存在するか否かをさらに判定する。より具体的には、ユーザ機器が、下りリンク・データを受信するときに確立されている接続を介して上りリンク・データを送信するように、ページングされるまで上りリンク・データ（周期的な測定結果など）を蓄積するように構成される可能性がある。

追加的にまたは代替的に、ユーザ機器は、ページングされた原因の下りリンクの小データに応答して上りリンク・データを送信することが必要となるか否かを推定する。より詳細には、以前の統計に基づいて、またはユーザ機器の小データ・アプリケーションの実装に基づいて、ユーザ機器は、あり得る将来の上りリンク・データの量を推定／判定することができる可能性がある。

例えば、ユーザ機器は、下りリンクで小データを受信するときに、通常、１０バイトのデータを送信するということを知っている。あるいは、ユーザ機器は、下りリンクの小データに応じて、あるときは１０バイトを送信し、またあるときは５００バイトを送信する。これは、小データがＭＴＣサーバからの要求であるときに当てはまる可能性がある。また、下りリンクの小データが、周期的な報告を送信するようにユーザ機器をトリガすることができる可能性がある。

それに対応して、そのような上りリンク・データの統計がユーザ機器で利用できる場合、ユーザ機器は、この情報のすべてまたは一部をＭＭＥに送信することになる。一例において、ユーザ機器は、この上りリンク・データの統計を、拡張サービス要求の特別な情報要素（ＵＬデータ情報と表記される）に含めることができる。背景技術の節で示されたように、ＮＡＳ ＥＳＲは、４バイトの任意のＥＰＳベアラ・コンテキスト・ステータス・フィールドを含む。各バイトが、データ量、周期性、上りリンク・データ・レート、ＱｏＳパラメータ、データ送信の総継続時間などの１つの情報を符号化するために使用され得る。さらに、新しい情報要素が、上りリンク・データの統計を送信する目的で導入される可能性がある。

ＮＡＳ ＥＳＲは、ｅＮｏｄｅＢとＭＭＥとの間でＳ１−ＡＰインターフェースを介して上りリンク・データ情報と一緒に送信される。ＭＭＥは、ユーザ機器からＮＡＳ拡張サービス要求を受信するとき、含まれる上りリンク・データの統計から、上りリンク・データを送信するためにユーザ・プレーンの接続が必要となるか否かを判定することができる。

データ送信のためにユーザ・プレーンの接続を確立するか否かに関するＭＭＥの決定は、ＭＭＥに関連する制限パラメータにさらに基づく可能性がある。より詳細に言えば、ＭＭＥは、上りリンクおよび下りリンクの制御プレーンを介したデータ転送に関する制限を判定することができる。例えば、制限は、上りリンクで送信される最大の絶対的なデータ・サイズ（例えば、５００バイト）、および／または最大の上りリンク・データ・レート（例えば、１００キロバイト／秒）、および／または最大のＮＡＳメッセージ・サイズ（例えば、１００バイト）、および／または最大のＮＡＳメッセージ・レート（例えば、１秒あたり５メッセージ）、および／またはＱｏＳパラメータ、および／または送信の継続時間、または何らかのその他の制限パラメータを含み得る。

この情報は、制御プレーンのシグナリングが上りリンク・データの送信を満足するか否か、または上りリンク・データを送信するためにユーザ・プレーンの接続性を確立することが有利であるか否かを判定するために、上りリンク・データの統計に関連して使用される可能性がある。

ＭＭＥがユーザ・プレーンの接続が不要であると決定した場合、図１０に示された後続の手順は、図８の手順と同じである。要するに、制御プレーンの接続のみが確立され、例えば、初期コンテキスト設定要求メッセージが、ユーザ・プレーンの確立を避けるためにＥ−ＲＡＢコンテキストを含まない。下りリンクの小データは、ＮＡＳシグナリング、またはＭＭＥとｅＮｏｄｅＢとの間のＳ１−ＡＰ、およびｅＮｏｄｅＢとユーザ機器との間のＲＲＣシグナリングなどの制御プレーンのシグナリングを使用してＭＭＥからＵＥに送信される。

ＭＭＥは、例えば、ＮＡＳ ＥＳＲメッセージでユーザ機器によって報告された上りリンク・データが制御プレーンを介したデータ転送の制限を超えているため、またはＭＭＥが現在過負荷状態である可能性があるために、ユーザ・プレーンの接続が確立されるべきであると決定する。したがって、ＭＭＥは、Ｓ１−ＡＰ初期コンテキスト設定手順を開始するが、図８とは対照的に、データ無線ベアラおよびユーザ・プレーンの確立のためにＥ−ＲＡＢコンテキストを含める。ｅＮｏｄｅＢは、ＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔメッセージを受信するとき、Ｅ−ＲＡＢコンテキストにしたがってＳＲＢ２およびＤＲＢベアラを確立するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ手順を開始する。

ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ手順の後、ユーザ機器は、ユーザ・プレーンが確立されていることと、ユーザ機器がＮＡＳ ＥＳＲメッセージが送信されたときに開始された新しいタイマＴ３４ｓｄを終了させる必要があることとを検出する。換言すれば、タイマＴ３４ｓｄを終了する原因は、データ無線ベアラが確立されるときであり、これは、事実上、Ｔ３４１７タイマの終了と同じ原因である。

データ無線ベアラを確立した（すなわち、ＰＤＣＰエンティティ、ＲＬＣエンティティのＤＴＣＨ論理チャネルを確立した）後、ユーザ機器は、対応するＥＰＳベアラを有効化し、つまり、上りリンク・データが、例えばＩＰパケットで準備され、ユーザ・プレーンを介して送信される。したがって、ユーザ・プレーンのベアラを確立することにより、図１０に示すように、下りリンクの小データと上りリンク・データとが転送できるようになる。上りリンク・データは、ユーザ機器からｅＮｏｄｅＢへのデータ無線ベアラと、ｅＮｏｄｅＢとサービング・ゲートウェイとの間のＳ１−Ｕベアラとを用いて送信される。上りリンクでは、サービング・ゲートウェイが、上りリンク・データを受信し、その上りリンク・データをＭＭＥ（またはＰＤＮ−ＧＷ）に転送する。そして、ＭＭＥ（またはＰＤＮ−ＧＷ）が、さらにＭＴＣサーバに向かうデータを、例えば、移動通信ネットワーク内に配置されたＭＴＣゲートウェイを介して転送する。

下りリンクの小データを送信することに関して、図１０の例示的なシナリオでは、下りリンクの小データがＭＭＥで（例えば、ＳＭＳ−ｏ−ＳＧｓを通じて）受信されると仮定していることに留意されたい。下りリンクの小データがＭＭＥで利用可能であり、ユーザ・プレーンを使用してユーザ機器に送信されるべきであるとき、少なくとも以下の２つの可能性がある。

図１０に示すように、ＭＭＥが、下りリンクの小データをサービング・ゲートウェイに転送し、したがって、サービング・ゲートウェイが、そのデータをＳ１−Ｕベアラを介してｅＮｏｄｅＢに送信することができる。この状況で、サービング・ゲートウェイとユーザ機器との間のデータ転送が、ユーザ・プレーンのベアラを介して実行される。

あるいは、上記を最適化する１つの方法は、ＭＭＥがＳ１−ＡＰプロトコルでｅＮｏｄｅＢにデータを転送することができるようにすることである。これは、Ｓ１−ＡＰプロトコルが制御プレーンのシグナリング用に定義されており、データ用に定義されていないので、標準的な挙動では現在利用できない。しかし、このオプションは、リソースと、サービング・ゲートウェイを介したシグナリングとを節約する機会を提供する。さらに、データが小さいので、そのデータをＳ１−ＡＰプロトコルで搬送することが許容可能である可能性がある。この目的で、Ｓ１−ＡＰを介したデータ転送のために導入された新しいメッセージが存在する可能性があり、一方、上りリンク／下りリンクＮＡＳトランスポート・メッセージのような既存のメッセージも使用され得る。この場合、ｅＮｏｄｅＢは、Ｓ１−ＡＰメッセージからデータを抽出し、そのデータをｅＮｏｄｅＢとユーザ機器との間でデータ無線ベアラにより転送するように修正される必要がある。

さらに、小データは、ＰＤＮ−ＧＷおよびサービング・ゲートウェイを介して受信される可能性があり、その場合、サービング・ゲートウェイがデータを既に有しており、そのデータをＭＭＥに転送する代わりに、小データが利用可能であることをＭＭＥに通知することができる。この場合、ＭＭＥがユーザ・プレーンの接続を確立することを決定したならば、サービング・ゲートウェイは、Ｓ１−Ｕデータ・ベアラを使用してｅＮｏｄｅＢに下りリンクの小データを送信するようにＭＭＥによってトリガされることのみを必要とする。

別の例によれば、ユーザ機器が、上りリンク・データを送信するためにユーザ・プレーンを確立すべきか否かについて決定することができるようにする。特に、下りリンクの小データに応答して転送されるべきであり得る将来の上りリンク・データに関して初めにユーザ機器によってなされた推定が誤っている場合、ＭＭＥの決定も誤りである可能性がある。下りリンクの小データは、ＭＴＣサーバに大量のデータを送信するようにユーザ機器（ＭＴＣデバイス）に命令する、ＭＴＣサーバからの要求であると想定され得る。ユーザ機器は、上りリンク・データがほんのわずかな量であると推定した可能性があり、上りリンク・データの実際の量は、大幅に多い。この場合、ＭＭＥの決定は（小さ過ぎる）推定された上りリンク・データに基づいているので、ＭＭＥは、ユーザ・プレーンを確立しないと決定する。しかし、ユーザ機器からＭＴＣサーバに送信されるべき実際の上りリンク・データを考慮すると、ユーザ・プレーンが確立されるべきである。したがって、ユーザ機器が、下りリンクで小データを受信した後、ユーザ・プレーンの接続を確立すべきか否かについて再度決定することができれば有利である。そのとき初めて、ユーザ機器は、上りリンクで送信されるべき上りリンク・データの正確な量を判定することができる。

図１１は、ユーザ機器と、ｅＮｏｄｅＢと、ＭＭＥと、サービング・ゲートウェイとの間で交換されるメッセージを示すシグナリング図である。図１１に示す例は、手順の初めに関しては図１０の例と同様である。特に、ユーザ機器が、小データがＭＭＥでＭＳＣから受信されるときにＭＭＥによってページングされる。ユーザ機器は、上りリンク・データ情報と一緒にＮＡＳ拡張サービス要求を送信することを含め、制御プレーンの確立を開始する。この例では、ＭＭＥが、報告された上りリンク・データを考慮して、および／またはこの点でのＭＭＥの制限を考慮して、ユーザ・プレーンが必要ないと判断するものと仮定する。それに対応して、ＭＭＥは、データ無線ベアラの確立を避けるためにＥ−ＲＡＢコンテキストを要求メッセージに含めずに初期コンテキスト設定手順を開始する。その初期コンテキスト設定手順にしたがって、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ手順が、ｅＮｏｄｅＢおよびユーザ機器によって実行される。

ＳＲＢ０、１、および２を確立した後、下りリンクの小データが、制御プレーン、すなわち、ＮＡＳシグナリングまたはＳ１−ＡＰおよびＲＲＣを用いてユーザ機器に送信される。ＭＭＥによって決定された制限パラメータも、例えば、下りリンクの小データと同じようにしてユーザ機器に送信される。ＭＭＥは、下りリンクＮＡＳトランスポート・メッセージを使用してユーザ機器に制限パラメータを送信することができる。代替的に、ＭＭＥは、別のＮＡＳメッセージに制限パラメータを含め、ユーザ機器に知らせることができる。ｅＮｏｄｅＢは、下りリンクＮＡＳトランスポート・メッセージを受信するとき、そのメッセージをユーザ機器へのＲＲＣ下りリンク情報転送メッセージで透過的にカプセル化する。

ユーザ機器は、ＭＭＥの制限パラメータと一緒に下りリンクの小データを受信する。ユーザ機器は、下りリンクの小データを処理して、ネットワークに送信されるべき厳密な上りリンク・データを判定する。そのとき、ユーザ機器は、その厳密な上りリンク・データに基づいて、ユーザ・プレーンの接続性を確立すべきか否かについて決定するさらなる機会を有する。例えば、上りリンク・データは、何らかの測定または結果の所与の期間内の定期的な報告である可能性がある。ＵＥは、特定の測定結果を１０秒ごとに報告し、その報告の継続時間は、例えば２０分である。そのとき、結果として生じる上りリンク・データ全体が、ＭＭＥの制限パラメータによって指示された制御プレーンを介したデータ転送の制限を超えている可能性がある。

それに対応して、ユーザ機器は、ユーザ・プレーンの接続を確立することを決定することができ、したがって、ＮＡＳセッション管理メッセージ（ＰＤＮ接続性要求）をＭＭＥに送信して、既存の休止状態のＥＰＳベアラを有効化するか、または新しいＥＰＳベアラを確立する。ＭＭＥでユーザ機器のＥＰＳベアラの要求を受信すると、ＭＭＥはコア・ネットワークでＥＰＳベアラを確立する（図１１のＳ１−Ｕベアラの確立を参照）ようにトリガされる。

さらに、ＭＭＥは、データ無線ベアラを確立するためにｅＮｏｄｅＢとユーザ機器との間の無線接続を再構成する必要がある。この目的で、ＭＭＥは、ｅＮｏｄｅＢとユーザ機器との間のＥ−ＲＡＢの有効化のためにｅＮｏｄｅＢのコンテキストを更新するＳ１−ＡＰ手順を実行する。ユーザ・プレーンでのＥＰＳベアラの確立が完了した後、ＭＭＥは、サービング・ゲートウェイへの下りリンク・データの転送を開始することができ、次いで、サービング・ゲートウェイから、下りリンクの小データがユーザ・プレーンを介してユーザ機器に送信される。

上りリンク・データも、ユーザ・プレーンのデータ無線ベアラおよびＳ１−Ｕベアラを使用してユーザ機器からサービング・ゲートウェイに送信され、それから、ＭＭＥに直接送信されるか、またはＭＭＥを通らずにＰＤＮ−ＧＷに送信される可能性がある。

ユーザ機器がユーザ・プレーンを確立しないと決定した場合、上りリンク・データおよび下りリンク・データは、上述の例に関して既に説明したように、制御プレーンの接続を使用して送信される。

上記の例を最適化する１つの方法は、ユーザ・プレーンでデータ無線ベアラが確立される前に上りリンク・データを送信することに関連する。特に、ユーザ機器がユーザ・プレーンを確立することを決定し、したがって、ユーザ・プレーンの確立を開始すると仮定する。ユーザ機器は、ユーザ・プレーンの接続が確立されるまで、制御プレーンを使用してｅＮｏｄｅＢおよびＭＭＥへの上りリンク・データの送信を開始することができる。これは、データ送信の遅延を短縮する。例えば、ユーザ機器は、制御プレーンの接続を用いて、第１の上りリンクの測定結果を送信することができる。次いで、第２の上りリンクの測定結果が、そうこうしているうちに確立されたユーザ・プレーンを使用して送信され得る。

基本的に、制御プレーンを使用して初めに送信される下りリンク・データに同じことが適用され得るが、ユーザ・プレーンの接続が確立されると、さらなる下りリンクの小データは、やはり、制御プレーンではなくユーザ・プレーンを介して交換され得る。

別の例によれば、ユーザ機器は、上で仮定したように上りリンク・データの統計を推定することができない可能性がある。その理由は、さまざまである可能性があり、例えば、ＭＴＣサーバとユーザ機器との間の要求／応答の交換が対話的であるために上りリンク・データが変わること、またはユーザ機器が上りリンク・データを推定する機能を実装しないことである可能性がある。

そのような場合、ユーザ機器とｅＮｏｄｅＢとの間のＲＲＣ接続（ひいてはＣＯＮＮＥＣＴＥＤ状態）が、ｅＮｏｄｅＢがＩＤＬＥモードへの遷移をトリガするまで存在し続ける。ユーザ機器はＩＤＬＥモードへの遷移をトリガできないことに留意されたい。ＩＤＬＥモードは、ｅＮｏｄｅＢによってのみトリガされる。さらに、上りリンク・データの終了後直ちにＲＲＣ接続が解放され、ユーザ機器がＩＤＬＥに遷移する場合、リソース（ユーザ機器、ｅＮｏｄｅＢ、およびＭＭＥにおける処理）が節約され得る。

そのような場合、ユーザ機器が上りリンク・データがいつ終わるのかを知っており、ＩＤＬＥモードへの遷移をトリガすることができるという別の仮定がなされ得る。あり得る解決策は、ユーザ機器がネットワーク（例えば、ＭＭＥ）に上りリンク・データが終わることを通知することができることである可能性がある。例えば、ユーザ機器が、ＮＡＳプロトコルでＭＭＥにある種の「上りリンク・データ終了」指示を明示的にシグナリングする可能性がある。そのとき、ＭＭＥは、技術仕様ＴＳ３６．４１３に記載されている「ＵＥコンテキスト解放」手順を開始する。

［さらなる代替的な例］
さらに、上記の例はすべて、小データ送信を受信し、ネットワークにアタッチするようにユーザ機器をトリガ／ページングすることによってＭＭＥが手順を開始する場合に関する。しかし、ユーザ機器が、上りリンクの小データを送信する必要があり、ＮＡＳシグナリング接続の確立を開始することもあり得る。その目的で、ユーザ機器は、ＲＲＣ接続の確立を開始する。ユーザ機器は、上りリンクで小データを送信するためにさまざまなオプションを使用することができる。

第１のオプションによれば、ユーザ機器は、ＮＡＳ拡張サービス要求メッセージで上りリンクの小データをカプセル化する。新しい情報要素が、これに関連して提供され得る。これは、無線リンクの暗号化が行われず、ＮＡＳ ＥＳＲメッセージが暗号化されない可能性があるので、セキュリティが重要でないデータに適用され得る。

第２のオプションによれば、ユーザ機器は、送信される小データに対する必要なセキュリティを保証するために、ＭＭＥへの上りリンクＮＡＳトランスポート・メッセージで上りリンクの小データをカプセル化することができる。ＮＡＳシグナリング接続の後の上りリンクＮＡＳトランスポート・メッセージが確立され、無線リンクを介して、ＲＲＣ上りリンク（下りリンク）情報転送メッセージが使用される。

第２のオプションが使用されるとき、ユーザ機器は、ＮＡＳシグナリング接続を確立するために、最初に、ＭＭＥにＮＡＳサービス要求を送信する。ユーザ機器が「小データ」送信ＭＴＣ機能用に構成されており（またはユーザ機器が未処理の上りリンク・データがその機能に属することを知っており）、小データが制御プレーンを介して送信されるべきであるので、ユーザ機器は、ＮＡＳを介した所望の転送をＭＭＥに指示することができる。その目的のために、ユーザ機器は、ＮＡＳメッセージ、例えば、特別なフラグを有するサービス要求か、または新しいフラグもしくは情報要素を有する拡張サービス要求かのどちらかを送信する。サービス要求は拡張の余地が限られているので、拡張サービス要求を送信することが好ましい。

ユーザ機器が上りリンクの小データに関する特別な指示を有するＮＡＳ （Ｅ）ＳＲを送信するとき、ユーザ機器は、従来技術のタイマＴ３４１７またはＴ３４１７ｅｘｔの代わりに特別なタイマＴ３４ｓｄを開始する。ＭＭＥは、対応するＳ１−ＡＰ手順を使用してシグナリング無線ベアラのみを確立するようにｅＮｏｄｅＢをトリガする。

さらに、有利な例によれば、ユーザ機器が、ＭＭＥに上りリンク・データ情報を示すことができ、これは、上りリンク・データのサイズが一定ではなく変化する場合に役立つ可能性がある。さらに、そのとき、ＭＭＥは、上りリンク・データ転送のために制御プレーンが好ましいか、またはユーザ・プレーンが好ましいかを判定する機会を持つ。

代替的な解決策によれば、１つのあり得る最適化の方法は、「非常に小さなデータ」を転送するためにページング手順（ユーザ機器がＩＤＬＥモードであるとき）またはいわゆる「デバイス・トリガ（Device Trigger）」手順（ユーザ機器がＤＥＲＥＧＩＳＴＥＲＥＤモードであるとき）を使用することである。

下りリンクの小データが非常に小さい（例えば、数ビットまたはバイト）と仮定すると、小データは、ページング・メッセージまたはデバイス・トリガ・メッセージでカプセル化され得る。この最適化でセキュリティの要件（完全性保護および任意で暗号化）を保証する１つのあり得る方法は、ＭＴＣアプリケーション・レベルのセキュリティを使用することである。

［無線リソース解放の制御］
本発明は、解放されるべき特定の無線リソースを使用してコア・ネットワークとＳＭＳ（例えば、ＭＴＣ小データを有する）を交換している移動ノードに関連する無線リソースの解放を制御するための改良された方法を提供する。

より詳細に言えば、小データを含むショート・メッセージを受信および／または送信するためには、初めに、無線リソースが確立される。そのとき、これらの確立された無線リソースが早く解放され過ぎることを避けるために、本発明は、コア・ネットワークの移動管理エンティティへの無線解放命令を移動ノードによって遅らせることを提案する。この目的のために、移動ノードにタイマが実装される。そのタイマが切れると、移動ノードが、リソース解放指示をコア・ネットワークのＭＭＥに送信して、移動ノードの観点から、無線リソースが解放され得ることを示す。移動ノードからのこの指示は、従来技術の指示として使用されるＣＰ−Ａｃｋメッセージとは異なる。

図１７および１８に関連して、本発明のさまざまな実施形態を、以降で、より詳細に説明する。これに関して、図１７は、ＭＭＥからＵＥに移動体終端ＳＭＳ（ＭＴ ＳＭＳ）を送信するための移動ノードと、ｅＮＢと、ＭＭＥとの間のメッセージ交換を示すシグナリング図である。例示のみを目的として、ＳＭＳを送信するためのＭＭＥとＳＭ−ＳＣとの間のリンク（すなわち、ｍｏ／ｍｔ−ＦＳＭ［ＴＰＤＵ］）は、これらの図から省略するが、図１４および１５にそれぞれ対応する。

ＵＥがＩＤＬＥモードであると改定されるので、ＭＭＥは、ＭＴ ＳＭＳの送信のための無線リソースを確立するために、最初にＵＥをページングする必要がある。それに対応して、ＵＥは、ページングに応答してＭＭＥにサービス要求メッセージを送り返す。それに応じて、ｅＮＢのＵＥコンテキストを含む無線リソースが確立される。通常、ＬＴＥにおいては、正常なサービス要求手順の後、ＳＲＢ１、ＳＲＢ２、および（１つまたは複数の）ＤＲＢが確立されている。しかし、上述のように、ＭＭＥがＳＭＳ（または小データ）転送のためにＵＥをページングするときにＳＲＢ１およびＳＲＢ２のみが設定される最適化されたメカニズムがあり得る。ＭＭＥがｅＮＢのセキュリティ・コンテキストを設定せず、したがって、ＳＲＢ１およびＳＲＢ２（デフォルトで暗号化される）が確立できないが、「安全でない」ＲＲＣ転送だけが利用可能であるさらに別の有利なメカニズムがあり得る。そのような場合、ＭＭＥからｅＮＢにプッシュされるＵＥに固有のコンテキストが存在せず、したがって、ＵＥとｅＮＢとの間のＲＲＣメッセージは暗号化されず、または別の言い方をすれば、ＵＥとｅＮＢとの間で明示的に確立された無線ベアラは存在しない。

必要な無線リソース（暗号化されるか、または上述のように暗号化されないかのどちらか）が確立されると、ＭＴ ＳＭＳが、ＭＭＥからＵＥにさらに送信される。ＵＥが、ＳＭＳを受信し、そのＳＭＳの内容を処理する。初めに、例示のみを目的として、ＳＭＳが、ＵＥのＭＴＣアプリケーションが上りリンクＳＭＳ（移動体発信）を用いて、またはＩＰプロトコルなどのその他のプロトコルを用いて上りリンクでデータを送信するためのトリガを含むと仮定する。

従来技術のシステムにおいて、無線リソースの解放は、ＭＯ ＳＭＳの送信の場合は、ＵＥからＣＰ−Ａｃｋメッセージを受信し、上位層ＳＭ−ＲＬのＳＭＲエンティティからＲｅｌ−Ｒｅｑメッセージを受信することによって、またはＭＴ ＳＭＳの送信の場合は、上位層ＳＭ−ＲＬのＳＭＲエンティティからＲｅｌ−Ｒｅｑメッセージを受信することによってＭＭＥでトリガされる。したがって、ＭＴＣトリガに応答してＵＥによってまもなく上りリンク送信が行われるにもかかわらず、無線リソースが解放され、結局、その後すぐに、上りリンク・データを送信するための別のサービス要求手順を通じて再確立されることになる。

それとは対照的に、本発明は、これらの状況を考慮に入れることを可能にする。説明する解決策においては、ＭＭＥが、ＵＥから無線リソース解放の明示的な要求か、または前に送信した下りリンク・データに対する通常のＡＣＫである可能性がある暗黙的な要求の指示かのどちらかを受信した後、無線リソースの解放を開始する。この目的のために、ＵＥが、着信データを監視し、ＭＴ ＳＭＳを検出したときに、無線リソースの解放を制御するためのタイマを開始する。タイマの長さは実装により、前もって設定されるか、ＵＥに固有であるか、事前に構成されるか、またはＮＡＳシグナリングによって構成されるかのいずれかである可能性がある。長さは、数百または数千ミリ秒の範囲内である可能性がある。

タイマは、既に確立されている無線リソースが使用されることになり、まだ解放されるべきでないことが明らかであるイベントが起こると中止されるように構成される。例えば、上りリンク・データがＵＥから送信されるべきであり、そのデータがＭＯ ＳＭＳであれ、ユーザ・データであれ、そのデータのためにデータ・ベアラが最初に確立されるべきであるとき。ＵＥの無線リソース解放タイマに関するさらなるあり得る中止イベントは、本発明のさらなる有利な実施形態に関連して後で説明される。

タイマが開始された後、ＵＥは、何らかのデータが上りリンクで送信されるべきであるか否かを定期的に調べる。ＳＭＳが（ＳＭＳかまたは異なる方法かのどちらかによる）上りリンク・データの送信のトリガを含むと仮定するとき、ＵＥは、タイマを中止し、したがって、無線リソースの解放に進まない（図１７に図示せず）。その代わりに、ＵＥは、無線リソースを再確立することを必要とせずに、例えばＭＯ ＳＭＳで上りリンク・データをＳＭ−ＳＣに送信する。

しかし、上りリンク・データが送信される予定がない場合、タイマは停止されず、ついには切れ、少なくとも移動ノードの観点から見て、無線リソースが近い将来使用されるか否か明らかでなく、確かに無線リソースが解放され得ることを示す。

ＵＥが無線リソースの解放についてＭＭＥにどのようにして知らせることができるかに関して、さまざまな代替的方法が存在する。図１７に示された代替的方法１は、以下の通りである。無線リソース解放タイマとは無関係に、おそらく無線リソース解放タイマが切れる前に、ＵＥが、ＭＴ ＳＭＳの受信に対して肯定応答する。これは、ＣＰ−Ａｃｋおよび（ＣＰ−Ｄａｔａ ＣＰＤＵ内の）ＲＰ−Ａｃｋの送信を含み得る。図１７から明らかなように、今度は、ＭＭＥが、ＣＰ−Ａｃｋによって、ＣＰ−Ｄａｔａ内にカプセル化されて送信されたＲＰ−Ａｃｋに対して肯定応答する。タイマが切れると、ＵＥの無線リソースを解放する意図を示す指示が、ＵＥからＭＭＥに別途送信される。

この指示は、その範囲を一切限定することなく、参照しやすくするために、図１７においては「アイドル指示」と称される。実際、この指示自体は、後で説明するように、さまざまな種類である可能性がある。

明らかなように、図１７の代替的方法１においては、アイドル指示は、別個のメッセージで送信される。したがって、ＵＥによって前に送信されるＣＰ−ＡｃｋもＲＰ−Ａｃｋも、遅らされない。これは、アイドル指示が、例えば、追加の情報要素としてＲＰ−Ａｃｋと一緒にＣＰ−Ｄａｔａ ＣＰＤＵに含められる代替的方法２においては異なる。その目的のために、ＣＰ−Ｄａｔａ ＣＰＤＵの送信が、アイドル指示をピギーバックするためにこのメッセージを再利用するために、無線リソース解放タイマが切れるまで遅らされる。ピギーバックすることの利点は、明示的なＮＡＳメッセージが生成されず、ＵＥからＭＭＥに送信されないことである。タイマが何らかの理由で停止される場合、遅らされたＲＰ−Ａｃｋメッセージが、アイドル指示を伴わずにＭＭＥに送信される。

図示されていないさらに別の代替的方法３は、アイドル指示を送信する代わりに、ＲＰ−Ａｃｋメッセージを搬送するＣＰ−Ｄａｔａメッセージの送信を遅らせることに関連する。最大の遅延は、１２秒未満、すなわち、ＲＰ−Ａｃｋの受信に関するＳＭＲエンティティの再送信タイマの最大時間未満である可能性がある。ＭＭＥのＳＭＲエンティティは、ＲＰ−Ａｃｋを受信しない間は、ＮＡＳ接続を解放するためのＲｅｌ−Ｒｅｑ指示をＭＭＥのＳＭＣエンティティに送信しない。そのような場合、ネットワークにおけるＮＡＳ接続の解放が遅らされ、明示的な「アイドル指示」を送信する場合と同じ結果となる。別の言い方をすれば、この代替的方法３は、いかなるプロトコルの変更も必要とせず、ＵＥの内部処理だけが、上りリンクのＲＰ−Ａｃｋメッセージを遅らせるように（ＭＴ ＳＭＳの場合）変更される。

これらの代替的方法のうち、最後のもの以外では（代替的方法１および２ − 明示的、一方、代替的方法３ − 暗黙的）、ＭＭＥは、アイドル指示を受信し、したがって、ＭＴ ＳＭＳを送信するために前に確立された無線リソースを解放するように移動ノードが指示していることを知ることになる。従来技術の手順および現在の標準的な手順と比較して、ＣＰ−Ａｃｋは、無線リソースの解放でもはや考慮されず（代替的方法１および２の場合）、その代わりに、本発明によるアイドル指示が、ＭＭＥによる無線リソースの解放をトリガする。

説明したように、ＭＭＥによって解放指示を検出し、処理すると、ＭＭＥは、図１４に関連して既に詳細に説明した通常の無線リソース解放手順を開始する。特に、ＭＭＥは、ｅＮＢにＳ１−ＡＰ ＵＥコンテキスト解放命令メッセージを送信し、そのメッセージに応答して、ｅＮＢが、ＵＥコンテキストを削除し、ＵＥにＲＲＣ解放要求メッセージを送信する。ＵＥは、ＲＲＣ接続が解放されたことをＮＡＳ層に通知し、ＮＡＳ層は、ＩＤＬＥ状態に遷移する。

ｅＮＢがＵＥに固有のコンテキストを持たず、すなわち、ＲＲＣメッセージの暗号化が無線リンクで行われない１つの特定の場合、ＭＭＥが、ＵＥの無線の状態および無線識別子（radio identifier）を解放するようにｅＮＢに要求する。この解放の結果、ｅＮＢからＵＥに「ＲＲＣ接続解放」メッセージが送信される可能性がある。

無線リソースの解放の上述の処理および制御によってもたらされる利点は、無線リソースの早期の解放が回避され得ることである。それに対応して、無線リソースの再確立が回避され得る。例えば、ＭＴ ＳＭＳが、ＭＴＣアプリケーションが上りリンク・データを送信するためのトリガの指示を含むとき、通常の無線リソース解放手順は、上りリンク・データがすぐ後に送信されるべきであるとしても、無線リソースを解放する（ＣＰ−ＡＣＫとＳＭＲエンティティからの解放要求とを受信したときにＭＭＥによって開始される）（またはＳＭＲエンティティからの解放要求だけを受信することによる）。それとは対照的に、本発明は、無線リソースの解放に関してこのイベントを考慮に入れ、無線リソースが近い将来、例えば、上りリンク・データの送信のために使用されることになることが明らかである場合はタイマを中止する。

上で説明した原理は、図１８を参照して詳細に説明するように、移動体発信ＳＭＳ（ＭＯ ＳＭＳ）が送信されるシナリオに同じように当てはまる。

ＵＥは、ＳＭＳ内で上りリンク・データ（例えば、小データ）を送信したい場合、ＭＭＥとのサービス要求手順を開始する。対応する無線リソースが確立されると、ＭＯ ＳＭＳがＭＭＥに送信される。この特定のシナリオにおいて、これは、ＲＰ−Ｄａｔａ ＲＰＤＵ内で行われ、ＲＰ−Ｄａｔａ ＲＰＤＵは、さらにＣＰ−Ｄａｔａ ＣＰＤＵ内にカプセル化される。ＲＰ−Ｄａｔａは、ＭＭＥによって、例えば、ｍｏ−ＦＳＭメッセージを用いてＭＡＣ／ＳＳ７シグナリングを通じてＳＭ−ＳＣに転送され、ＲＰ−Ｄａｔａを含むＣＰ−Ｄａｔａ ＣＰＤＵに対するＡＣＫがＵＥに送られる（ＣＰ−Ａｃｋを参照）。そして今度は、ＳＭＲエンティティが、ＲＰ−ＡｃｋをＳＭＣエンティティに送信することによって、ＳＭＳ（ＲＰ−Ｄａｔａ）の正常な受信に対して肯定応答する。ＭＭＥは、ＲＰ−ＡｃｋをＣＰ−Ｄａｔａ ＣＰＤＵ内にカプセル化する。

ＵＥは、ＭＯ ＳＭＳに対するＡＣＫが受信されるか否か、すなわち、ＲＰ−Ａｃｋメッセージが受信されるか否かを判定するために着信データを監視する。ＲＰ−Ａｃｋを受信すると、図１７の実施形態でＭＴ ＳＭＳを受信するのと同様に、ＵＥで無線リソース解放タイマが開始される。

ＵＥは、ＵＥでさらなるイベント、特に、何らかの上りリンク・データの送信がまもなく行われるか否か、例えば、連結されたＭＯ ＳＭＳの場合の第２のＭＯ ＳＭＳを監視する。そのような場合、タイマが中止され、換言すれば、タイマが、リソース解放指示を送信することなく停止される。しかし、タイマは、中止／停止されない場合、やがて切れ、リソース解放指示がＭＭＥに送信される。アイドル指示自体は、さまざまな形態をとる可能性があり、それらの形態の一部が、後でより詳細に説明される。

図１８は、ＭＭＥへのアイドル指示の送信をどのように実行すべきかに関して２つの代替的方法を示している。「アイドル指示」と称されるリソース解放指示は、ＭＭＥへの別個の（ＮＡＳ）メッセージで送信されるか、または別のメッセージの一部として、例えば、情報要素としてＣＰ−Ａｃｋとともに送信されるかのいずれかである。図１８の代替的方法２においては、タイマが停止されるとき、ＣＰ−Ａｃｋは、アイドル指示なしでＭＭＥに送信される。ＭＭＥは、ＭＭＥでの無線リソース解放手順をトリガするこのアイドル指示を受信し、処理する。それに対応して、ＭＭＥは、ＵＥコンテキスト解放命令をｅＮＢに送信し、そして今度は、ｅＮＢが、ＲＲＣ解放要求メッセージをＵＥに送信する。こうして、無線リソースが解放される。

図１８に示されていない１つのさらなる変形形態では、ＵＥが、無線リソースの解放を要求するためのアイドル指示によるＭＭＥに対する明示的な通知を行わず、その代わりに、ＭＭＥに上りリンクのＣＰ−Ａｃｋメッセージを送信するのを遅らせる。したがって、ＣＰ−Ａｃｋメッセージは、ＭＭＥへの暗黙的な遅延指示として働く。

これによってもたらされる利点は、いくつかの連結されていないＭＯ ＳＭＳが送信される場合に、タイマが間に合うように中止されるので、無線リソースが早く解放され過ぎないことである。従来技術では、ＳＭ−ＳＣが、さらなるＭＯ ＳＭＳを受信すると予想しないので、ＭＭＥに解放要求メッセージを送信し、したがって、最初のＭＯ ＳＭＳに関するＣＰ−Ａｃｋと相まって、ＭＭＥが、認識していないまもなく行われるさらなるＭＯ ＳＭＳの送信があるにもかかわらず、リソース解放手順を開始する。

［本発明の変形形態および有利な実施形態］
図１９は、図１７および１８を参照して示された実施形態と比較した、本発明の代替的なまたは追加的な実施形態を開示する。本発明の代替的な実施形態によれば、タイマの開始が、もはや、ＭＴ ＳＭＳ、またはＭＯ ＳＭＳに対するＡＣＫの受信のみによってトリガされない。その代わりに、上位層からの解放要求指示が、無線リソース解放タイマを開始するためのトリガ・イベントとして追加的または代替的に使用される。より詳細に言えば、ＵＥの上位層が、受信されたＳＭＳの内容を処理することができ、したがって、リソースがさらに使用されるべきか否かを判断することができる。例えば、上位層は、受信されたＭＴ ＳＭＳがＭＯ ＳＭＳの送信、または任意のその他の種類のＩＰ接続の確立もしくは上りリンクのＩＰの送信をトリガするか否かと、さらには送信が実行される時間とを知っている場合、ＵＥのＮＡＳ層に解放要求を示さない。そのような場合、ＵＥは、無線リソース解放タイマを開始する必要がない。一方、ＳＭＳアプリケーションは、その他の（おそらくはＭＴＣ）アプリケーションのトリガについて知らない場合、ＵＥのＮＡＳ層に解放要求を示す可能性があるが、ＵＥは、以下で説明するように、上位層からの解放要求に基づいて無線リソース解放タイマを開始する。ＵＥが上位層から解放要求を受信した後に無線リソース解放タイマを開始するか否かは、１）ＵＥの内部構成の問題、または２）ＵＥの内部の判断機能、または３）ＵＥとＭＭＥとの間、もしくはＵＥとその他のコア・ネットワーク・エンティティとの間のネゴシエーションに基づく可能性がある。

タイマの同様のトリガは、ＭＯ ＳＭＳのシナリオに適用可能であり、すなわち、さらにまたは代替的に、上位層の解放要求指示が、無線リソース解放タイマのトリガとして使用され得る。

図１４および１５に示された、ＵＥ内でＳＭＲエンティティからＳＭＣエンティティに送信される解放要求メッセージが、この目的のために使用され得る。ＭＯ ＳＭＳの場合、ＭＯ ＳＭＳの送信に対するＲＰ−Ａｃｋの受信が、解放要求メッセージを送信するように上位層をトリガするが、上位層からのさらなる上りリンクの送信が近い将来実行される予定がないことが前提となる（図１４参照）。ＭＴ ＳＭＳの場合、解放要求の送信は、上位層の上りリンクの送信が近いうちに行われない場合に限り、ＣＰ−Ｄａｔａ ＣＰＤＵでのＲＰ−Ａｃｋの送信に対するＣＰ−Ａｃｋを受信するときにＵＥ内でトリガされる（図１５参照）。

ＭＴ ＳＭＳの場合、ＵＥでの解放要求指示がＲＰ−Ａｃｋメッセージを送信した後にのみ生成されるので、タイマが開始した後の残りの手順が変わる。それに対応して、無線リソース解放タイマが切れた後に送信されるべき無線リソース解放指示（アイドル指示）は、別のメッセージで送信できず、例えば、ＮＡＳメッセージで別途送信される。図１９は、これを示している。ＭＭＥは、アイドル指示を受信し、したがって、上で説明した無線リソース解放手順を開始する。

図２０は、タイマのための解放要求トリガを用いたＭＯ ＳＭＳに関する本発明の実施形態を示している。この場合の手順は、図１８の手順と非常によく似ている。無線リソース解放タイマの開始イベントを変更すること以外、タイマが切れたときにアイドル指示を送信することは変わらない。特に、アイドル指示は、ＣＰ−Ａｃｋメッセージ内で、または別の、例えばＮＡＳメッセージで送信され得る。

タイマの開始イベントとして上位層の解放要求指示を使用することは、特定のシナリオで有利である可能性がある。ＭＴ ＳＭＳが、ＵＥ（すなわち、ＵＥのＭＴＣアプリケーション）が特定の時間遅延でＭＴＣサーバにステータス報告を送信するためのトリガ命令を含む場合、図１７による本発明の実施形態は最適でない。この場合、タイマは、（ＭＴ ＳＭＳが受信されるので）開始されるが、（上りリンク・データが送信されるべきでないので）中止されない。下位層は、時間遅延のある、上位層でまもなく行われるデータ送信を認識せず、上位層、すなわちＳＭＳの実際の中身を処理する層だけが、時間遅延を認識する。その結果、無線リソースが、上りリンク・データの送信がまもなく行われるとしても解放される。短い時間遅延の後、上りリンク・データが送信される必要があり、サービス要求手順が、無線リソースを再び確立するために実行される必要がある。

図１９による実施形態では、タイマ開始イベントとして解放要求指示を使用することにより、無線リソースのこの早期の解放が避けられる。解放要求指示は、タイマを開始するために下位層に送信されない。したがって、タイマは開始されず、切れてリソースの解放をトリガすることがない。

解放要求指示がタイマ開始イベントとして使用される別のシナリオは、連結されたＭＴ ＳＭＳに関する。連結されたＭＴ ＳＭＳの場合、ＳＭ−ＳＣが、ＵＥに複数のＳＭＳセグメントを送信する。基本的に、連結されたＳＭＳの第１のＳＭＳセグメントに対するＡＣＫがＳＭ−ＳＣに送られた後、ＳＭ−ＳＣは、第２のＳＭＳセグメントを送信する。図１７の実施形態によれば、それぞれの受信されるＳＭＳセグメントがタイマをトリガし、タイマの継続時間が新しいＳＭＳセグメントを受信するための時間よりも短い場合、無線リソースが毎回解放される。連結されたＳＭＳに関しては、無線リソースの解放が回避されるべきである。さらに、アイドル指示を送信するために代替的方法２が使用される場合、ＲＰ−Ａｃｋは、常に遅らされるが、連結されたＳＭＳの次のＳＭＳセグメントを送信するためにＳＭ−ＳＣによって必要とされるので、連結されたＳＭＳの送信手順に遅延がもたらされる。さらに別の不利な点は、ＭＴ ＳＭＳセグメントが受信されるたびに解放タイマが開始されるので、ＵＥの処理が増えることである可能性がある。

例えば、図１７の代替的方法１を使用することによって遅延が避けられる可能性があるが、解放タイマの値が短過ぎる場合、図１７に関連して説明したように、この実施形態に関しても、無線リソースの解放がやはり起こる。上位層（例えば、ＳＭＲエンティティまたは転送層）は連結されたＳＭＳについて認識しているため、上位層からの解放要求指示をタイマ開始イベントとして使用することによって、最後のＳＭＳセグメントが受信された後にのみＮＡＳ層に解放要求指示が送信されるので、無線リソースの不必要な解放が避けられる。さらに、解放タイマが各ＳＭＳセグメントが受信された後に開始されないので、ＵＥの処理が簡素化される。

上で説明したように、連結されたＭＴ ＳＭＳを使用すると、上述の実施形態の無線の解放の制御に問題が生じる可能性がある。この問題を軽減することを可能にする有利な実施形態を、以下に示す。ＵＥでＭＴ ＳＭＳが受信されるたびに無線リソース解放タイマを開始する代わりに、タイマは、ＳＭＳが連結されたＳＭＳの一部ではないとき、またはＳＭＳが連結されたＭＴ ＳＭＳの最後のＲＰＤＵセグメントであるときに限り開始される。この目的のために、ＵＥは、ＲＰ−Ｄａｔａ、すなわちＳＭＳを分析することになり、特に、そのＳＭＳに関するそのＳＭＳのユーザ・データのヘッダ部は、このＳＭＳが連結されたＳＭＳの一部であるという指示を含むはずであり、連結されたＳＭＳを構成するＳＭＳの総数と、連結されたＳＭＳのシーケンス中での、たった今受信されたＳＭＳの特定の番号とに関する情報をさらに含む。したがって、ＵＥは、必要な情報を知り、連結されていないＳＭＳと、一連の連結されたＳＭＳのうちの最後のＳＭＳセグメントである連結されたＳＭＳのセグメントとに対してのみタイマを開始することができる。

本発明の上述の実施形態のさらなる適合および／または代替的方法は、ＭＭＥでリソース解放手順を開始するときに、ネットワークのＳＭＲエンティティによって送信される解放要求指示を含めることに関する。図１７〜２０による実施形態において、ＳＭＲエンティティは、ＳＭＲエンティティがＲＰ−Ａｃｋ（ＭＴ ＳＭＳがＳＭ−ＳＣによって正常に送信されたことを意味する）を受信すると、またはＳＭ−ＳＣがｍｏ−ＦＳＭ ＡＣＫ（ＭＯ ＳＭＳがＳＭ−ＳＣで正常に受信されたことを意味する）を送信すると、ＳＭＣエンティティにＲｅｌ−Ｒｅｑ指示を送信する。これは、さらなる下りリンクのＭＴ ＳＭＳがＳＭ−ＳＣによって送信される予定がないと想定している。

本発明のこの有利な実施形態によれば、無線リソースの解放の開始が、ＵＥから受信されるリソース解放指示（「アイドル指示」）だけでなく、ＳＭＲエンティティからの解放要求指示にも依存する。言い換えると、両方のインジケータがＭＭＥで受信されるときにのみ、ＵＥコンテキスト解放命令をｅＮＢに送信することによってリソース解放手順が開始される。

これは、上で説明した実施形態に勝る特定の利点を有する可能性がある。例えば、さらなるＭＴ ＳＭＳがＳＭ−ＳＣによって送信されるべきである場合、これは、上述の実施形態のすべてで考慮されない。この実施形態では、ＭＭＥが、リソース解放手順を開始するためのＳＭＲエンティティからのＲｅｌ−Ｒｅｑ指示を待ち、さらなる下りリンク・データ、すなわちＭＴ ＳＭＳまたはＴＰＤＵがＵＥに送信される予定が確かにない場合にのみＲｅｌ−ＲｅｑがＳＭＲエンティティによって送信されるので、いくつかの連結された、または連結されていないＭＴ ＳＭＳが送信されるときに、早期の無線の解放が回避できる。通常、ショート・メッセージ転送層（ＳＭ ＴＬ）は、ＴＰＤＵで、送信すべきさらなるメッセージが存在するか否かの指示を提供し、この指示は、主に、連結されたＳＭＳの場合に使用されることに留意されたい。したがって、ＳＭＲエンティティは、この情報を解析し、送信を待っているさらなるＴＰＤＵが存在するか否かを知ることができる。

ＵＥからＭＭＥへの「アイドル指示」の送信は、上で説明した本発明のすべての実施形態の一部である。用語「アイドル指示」は、主として参照しやすくするために使用されており、この機能の範囲をそれが名付けられた通りに限定すると誤解するべきでない。アイドル指示が実際にどのように実装され得るかを、以下で詳細に説明する。概して、ＵＥからＭＭＥへのこの指示は、ＭＭＥに、ＵＥの観点から見て無線リソースがもはや必要なく、解放されることを知らせる。

アイドル指示は、例えば、ＩＤＬＥ状態に変わる明示的な指示、もしくはＮＡＳ接続を解放する明示的な指示である可能性があり、または上りリンクＮＡＳ転送バッファがゼロであることについての指示からなる可能性がある。したがって、アイドル指示は、０または１に設定されるフラグに過ぎない可能性があり、このフラグから、ＭＭＥは、リソースの解放がＵＥによって命じられているか否かを推測することができる。上で説明したように、ＭＭＥは、「アイドル指示」を命令として解釈し、無線リソースの解放を直ちに開始する可能性があり、または（ＳＭＳの上位層を代表する）ＳＭＲエンティティからの解放要求指示などの第２のイベントを待つ可能性がある。アイドル指示の今説明した実装のそれぞれは、本発明の上で説明した実施形態に適合性があることにさらに留意されたい。

上述の実施形態に関して、例えば、ＭＴ ＳＭＳ内のＭＴＣトリガに応答してＵＥから上りリンク・データが送信されるべきである場合に無線リソース解放タイマが中止／停止されることを上で説明した。本発明のさらなる実施形態によれば、タイマの中止イベントは以下の通りである。

１つの中止イベントは、ＭＴ ＳＭＳが受信された結果としてＭＯ ＳＭＳが送信されることである可能性がある。無線リソース解放タイマが動いている（例えば、無線リソース解放タイマが、ＭＴ ＳＭＳを正常に受信した後、開始された）場合、解放タイマは、上位層（例えば、ＳＭＲエンティティ）がＭＯ ＳＭＳが送信されるべきであることを示すときに停止／中止される。ＭＯ ＳＭＳは、上りリンクでのＲＰ−Ｄａｔａの送信を引き起こし、したがって、上りリンクのＲＰ−Ｄａｔａ ＲＰＤＵの送信が、無線リソース解放タイマの終了イベントとして使用され得る。

タイマのさらなる中止イベントは、ユーザ・プレーンのデータ・ベアラが確立されることである可能性がある。例えば、受信されたＭＴ ＳＭＳが、ＭＴＣサーバとＵＥとの間でユーザ・データを交換するためのデータ・ベアラを確立するためのＭＴＣトリガ指示を含む可能性がある。それに対応して、ＵＥは、これに関連してデータ・ベアラの確立を開始する。上りリンク・データの送信はすぐには起こらない可能性があるが、無線リソースを維持し、したがってそれらのリソースの解放を避けることがやはり有利である。この目的のために、タイマは、ＵＥがデータ・ベアラの確立を検出する場合にも中止されることになる。

無線リソース解放タイマの長さは実装により、概して、（例えば、通信履歴に基づいて）ＵＥで内部的に決定され得るか、またはネットワークによって事前に構成され得るかのどちらかである。無線リソース解放タイマの長さがネットワークによって事前に構成される場合、タイマの長さの構成は、ＵＥの加入データの一部であり、および／または５００ｍｓもしくは１ｓなどのハードコードされたデフォルト値である可能性がある。代替的に、タイマの値は、アタッチ手順中にＭＭＥからＵＥに告知される可能性がある。

さらに、無線リソース解放タイマの実際の値は、本発明にさらなる利点をもたらすいくつかの制約を有する可能性がある。「アイドル指示」が、例えば、ＲＰ−Ａｃｋ ＲＰＤＵを搬送するＣＰ−Ｄａｔａ ＣＰＤＵで送信され得る（ピギーバックされ得る）とき、タイマの値は、ＵＥとＳＭ−ＳＣとの間のＲＰプロトコル層の再送信タイマ未満となる。詳細に言えば、図１７の代替的方法２においては、ＲＰ−Ａｃｋが（アイドル指示を含めるために）無線リソース解放タイマが切れるまで延期されるので、ＭＭＥは、ＲＰ−Ｄａｔａ（すなわち、ＭＴ ＳＭＳ）が肯定応答されるのを待っているＳＭＲエンティティにＲＰ−Ａｃｋを間に合うように転送することができない。対応する再送信タイマが切れる前にＳＭＲエンティティでＲＰ−Ａｃｋを受信しないか、またはＳＭ−ＳＣでｍｔ−ＦＳＭ−Ａｃｋを受信しないと、ＳＭＲエンティティまたはＳＭ−ＳＣは、ＭＴ ＳＭＳを再送信する可能性がある。この状況は、無線リソース解放タイマをＳＭＲエンティティまたはＳＭ−ＳＣの再送信タイマよりも短く設定することによって回避され得る。ＳＭＳセグメントの送信の信頼性、すなわち再送信メカニズムはＳＭ−ＲＬ層で保証されると想定でき、したがって、ＳＭＲエンティティは、ＲＰ−Ａｃｋが時間通りに到着しない場合に再送信タイマを実施する。

さらに、本発明の別の有利な実施形態によれば、無線リソース解放タイマは、ＭＭＥにＲＲＣ接続の解放をトリガする役割を負うｅＮＢの非アクティブ・タイマよりも短くなる。より詳細に言えば、ｅＮＢは、ＵＥのために構成された非アクティブ・タイマを有し、ＵＥと相互にやりとりされるデータを監視する。特定の時間、データがＵＥによって送信または受信されず、すなわちＵＥが非アクティブであり、対応する非アクティブ・タイマが切れる場合、ｅＮＢは、ＭＭＥのリソース解放手順をトリガし、対応する要求をＭＭＥに送信する。これは、遅らされたＲＰ−Ａｃｋが送信される前にリソースの解放をトリガし、したがって、ただＲＰ−Ａｃｋを送信するために無線リソースを再確立することにつながる。この状況を避けるために、ＵＥの無線リソース解放タイマの値は、ｅＮＢの非アクティブ・タイマよりも小さく設定される可能性がある。

３ＧＰＰの標準化で現在検討されているのは、ＣＰ Ａｃｋを廃止する案についてである。言い換えると、ＲＰ層の肯定応答手順が十分に堅牢であると考えられるので、ＣＰ層のＣＰ−Ａｃｋを使用しないことが提案されている。ＭＭＥによって制御されるリソース解放のための現在のメカニズムは（ＳＭＲエンティティからの解放要求メッセージと一緒に）最後のＣＰ−Ａｃｋを受信することに基づくので、ＣＰ−Ａｃｋを廃するこの提案を採用すると、標準的なリソース解放手順と、特にその手順のトリガとを適合させることが必要となる。もしも実際にこれが規格で採用されたとしても、ＣＰ−Ａｃｋを使用しない上述の実施形態は引き続き使用可能であり、したがって、リソース解放手順がＣＰ−Ａｃｋを使用せずに機能し得る方法の１つのオプションとなり得る。例えば、アイドル指示がＣＰ−Ａｃｋメッセージとともに送信される本発明の上述の実施形態は、不可能になる（例えば、図１８、Ａｌｔ２参照）。しかし、残りの実施形態は、ＣＰ−Ａｃｋの使用が将来の規格で廃止されるとしても実現可能である。

本発明の別の有利な実施形態は、ＵＥからＭＭＥへのアイドル指示を使用する別の方法を提案する。本発明の上述の実施形態は、無線リソース解放タイマがＳＭＳの受信／送信イベントによって開始される一方、無線リソース解放タイマが切れたときにアイドル指示を送信することを提案している。しかし、ＵＥが、例えば、ＳＭＳの送信と平行してＥＰＳデータ・ベアラを介してＩＰパケットを交換するデータ・アプリケーションを有する場合、無線リソース解放指示は、ＳＭＳの送信のみに基づいて送信されない。タイマのトリガに加えて、またはタイマのトリガの代替として、アイドル指示は、特定のデータ・アプリケーションがＵＥのＮＡＳ層にデータ交換の終了について通知するときに、ＵＥによってＭＭＥにやはり送信され得る。したがって、ＮＡＳ ＭＭ層が、（１つまたは複数の）ＥＰＳデータ・ベアラ、すなわちＵプレーンの接続がもはや必要ないことを認識することができる。よって、ＵＥは、アイドル指示をＭＭＥに送信し、すると今度は、ＭＭＥが、それに応答して、ｅＮＢとの無線リソース解放手順を開始する。アイドル指示は、ＮＡＳメッセージ、例えば、上りリンクＮＡＳトランスポート・メッセージに含められ得る。デフォルトのＥＰＳデータ・ベアラが解放されず、ＣプレーンおよびＵプレーンの無線リソースだけが解放されることに留意されたい。

複数のアプリケーションがデータを交換する場合、ＵＥは、無線リソースを解放するためにＭＭＥに「アイドル指示」を送信することを決定する前に、すべてのアクティブなアプリケーションが上で説明したように「データ交換の終了」を示したことを確かめるべきである。

要約すると、アイドル指示は、無線リソース解放タイマが切れるときだけでなく、データ交換が終了することに関する特定の指示が上位層（例えば、アプリケーション層）から受信されるときにも生成され、ＵＥからＭＭＥに送信される。本発明のこの実施形態によってもたらされる利点は、アイドル指示が、無線リソース解放タイマを使用するときよりも早くトリガされ、したがって、無線リソースがより早く、ただし早過ぎず解放されることである。さらに、ｅＮＢの非アクティブ・タイマと比べても、無線リソースはより早く解放される。

上述の本発明のさまざまな実施形態を実装するためには、ＵＥとＭＭＥとの両方が、この点で、標準的な手順と比較して適合されるべきである。両方のエンティティは、ＮＡＳ層でアイドル指示を受信し、処理することができるべきである。アイドル指示は、ＣＭサブレイヤか、またはＮＡＳ ＭＭサブレイヤかのどちらかで処理され得ることにさらに留意されたい（図１３参照）。さらに、ＮＡＳ層プロトコルのうちの１つ、すなわち、ＳＭ−ＣＰ（ショート・メッセージ制御プロトコル）か、またはＮＡＳ ＭＭプロトコルかのどちらかに対する変更が必要である。下りリンクの小データがＭＴ ＳＭＳに含まれる場合、あり得るオプションは、接続管理（ＣＭ）サブレイヤでアイドル指示を実装することである。説明した解決策はＣＭサブレイヤが実装されないその他の小データ・アプリケーションに適用可能であるので、アイドル指示は、ＮＡＳ ＭＭプロトコルで送信され得る。

ＭＭＥは、ＮＡＳ ＭＭシグナリング接続がもはや必要ないことを示す（すなわち、ＵＥがＭＥにアイドル指示を送信する）ためのＵＥの機能について知っているべきである。一部のＵＥは本発明のこの機能を実装する可能性があり、その他のＵＥはこの機能を実装しない可能性がある。したがって、ＭＭＥは、無線リソースの解放がどのように制御されるべきか、つまり、標準的な従来技術の手順（ＭＯ ＳＭＳの場合はＣＰ−ＡｃｋおよびＲｅｌ−Ｒｅｑ、もしくはＭＴ ＳＭＳの場合はＲｅｌ−Ｒｅｑのみ）に基づくか、または本発明のさまざまな実施形態のうちの１つにしたがうかを知っている必要がある。この目的のために、ＵＥは、アタッチ手順中にＭＭＥに通知する。例えば、ＵＥは、ＭＭＥへの特定の指示（情報要素）をアタッチ要求メッセージに含め、ＭＭＥに、特定のＵＥが本発明による無線リソースの解放のための「アイドル指示」の送信をサポートすることを知らせることができる。

ＭＭＥが無線リソースの解放のためのＵＥの機能についてどのようにして知るかについての別の解決策は、加入データベースにＵＥの機能を格納することである。その場合、アタッチ手順の間に、ＭＭＥは、ＨＳＳ／ＨＬＲからＵＥの機能の情報（本発明によるアイドル指示のサポート）を取得する。

概して、ＵＥがアイドル指示をサポートすることをＭＭＥが通知される場合、ＭＭＥは、ＳＭＲエンティティからのＲｅｌ−Ｒｅｑおよび／またはＵＥからのＣＰ−Ａｃｋを受信してもＮＡＳ ＭＭおよびＲＲＣ接続の解放を開始しないが、本発明のさまざまな実施形態のうちの１つにしたがってＮＡＳ ＭＭおよびＲＲＣ接続の解放を実行する。

ここまでに説明した本発明のすべての実施形態においては、タイマがＵＥに実装される。本発明のこの無線リソース解放タイマは、以下で説明するように、既にＵＥに存在するタイマＴ３４４０とは異なることに留意されたい。Ｔ３４４０タイマは、ＵＥがアタッチ拒否、デタッチ要求、ＴＡＵ拒否（特別な拒否理由を伴う）、サービス拒否（特別な拒否理由を伴う）、および／またはＴＡＵ受容を取得するときに開始される。Ｔ３４４０タイマが切れるとき、ＵＥは、ＭＭシグナリング接続を暗黙的に解放し、ＩＤＬＥ状態になる（またはＩＤＬＥ状態のままとなる）。さらに、ＵＥのＭＭサブレイヤが、ＲＲＣ層に、ＲＲＣ接続が必要ないことを示す。いくつかの点で本発明のタイマと明らかに似ているが、さまざまな違いがある。例えば、本発明の無線リソース解放タイマは、ＳＭＳまたはＳＭＳ−Ａｃｋの受信により開始される。さらに、本発明の無線リソース解放タイマの継続時間は、ＳＭ−ＣＰプロトコルの手順によって制限され得る。タイマが切れるとき、異なる動作がやはり実行される。したがって、無線リソース解放タイマは異なっており、Ｔ３４４０タイマは、本発明のさまざまな実施形態のいずれを実装する目的にも再利用できない。

本発明の上述の実施形態の変更形態においては、アイドル指示をＣＰ−Ａｃｋとして実装することが提案される。換言すれば、従来技術においてリソース解放手順を開始するためのトリガ（のうちの１つ）として知られているＣＰ−Ａｃｋメッセージとは異なる明示的なアイドル指示を提供する代わりに、（好ましくはＳＭＲエンティティからの解放要求メッセージと一緒に）解放手順を開始するようにＭＭＥをトリガするために最後のＣＰ−Ａｃｋメッセージを維持することが提案される。しかし、本発明のこの実施形態は、本発明の上述の実施形態から既に分かっている無線リソース解放タイマによってＣＰ−Ａｃｋメッセージを遅らせることを提案する。

したがって、ＵＥは、タイマを開始し、ＣＰ−ＡＣＫ ＣＰＤＵをバッファリングし、遅らせ、上りリンク・データが送信されるべきか否か、および／またはデータ・ベアラが確立されるべきか否かを調べる。タイマが切れると、ＵＥは、ＣＰ−ＡｃｋをＭＭＥに転送し、次いで、ＭＭＥが、（好ましくはＳＭＲエンティティからの解放要求指示も受信した後）無線リソース解放手順をトリガすることができる。

本発明のさらに別の実施形態は、ＵＥの代わりにＭＭＥに無線リソース解放タイマを実装することに関する。図２１は、本発明のこの実施形態を開示しており、特に、ＭＴ ＳＭＳに関連して例示的な実施形態を示している。当然ながら、ＭＭＥにタイマを実装することは、ＭＯ ＳＭＳのさまざまなシナリオにも等しく適用可能である。

図２１の例示的な実施形態においては、タイマは、ＳＭＲエンティティから解放要求指示を受信するときに開始される。リソース解放手順を直ちに開始する代わりに、ＭＭＥは、リソース解放手順を開始する前に無線リソース解放タイマが切れるのを待つ。

タイマが開始され、ＭＭＥは、ＵＥへの／ＵＥからの上りリンクまたは下りリンク・データの送信がまもなく行われるか否かを継続的に調べる。さらに、ＵＥからのデータ・ベアラまたはＰＤＰコンテキストの確立が、無線リソース解放タイマを停止するためのイベントと見なされ得る。そうである場合、タイマが停止され、内部的な「アイドル指示」は生成されず、したがって、ＳＭＲエンティティが解放要求を示した可能性があっても、無線リソースの早期の解放が避けられる。一方、そのような下りリンク／上りリンク・データの送信またはベアラの確立が実行される予定がない場合、タイマがやがて切れ、アイドル指示がＭＭＥによって内部で生成される。これは、無線リソース解放手順（すなわち、ｅＮＢへのＵＥコンテキスト解放命令など）をトリガする。

本発明の上述の実施形態の変更形態において、ＭＭＥは、ＳＭ−ＳＣからの解放要求指示と、ＵＥからの最後のＣＰ−Ａｃｋメッセージとの両方が受信されるときにのみ無線リソース解放タイマを開始する。

代替的な実施形態は、ＭＭＥがＵＥに前に転送したＭＴ ＳＭＳに関連するＵＥからのＲＰ−Ａｃｋを受信するときにＭＭＥのタイマが開始されることを可能にし、この場合、ＳＭＲエンティティからの解放要求指示も受信するときにのみタイマを開始することが好ましい可能性がある。

代替的に、タイマは、上りリンクＳＭＳ（すなわち、ＭＯ ＳＭＳ）を受信するときに開始され得る。

ＵＥではなくＭＭＥにタイマを設けることにはいくつかの利点がある。これらの利点の１つは、ＵＥがＭＭＥに明示的な「アイドル指示」を送信する必要がなく、その代わりに、ＭＭＥ自体の内部の指示で十分であり、したがって、無線を介した無線リソースが節約されることである。

ＭＭＥにタイマを実装する別の利点は、ネットワークがＮＡＳ接続およびＲＲＣ接続の継続時間を制御しており、これは一部の事業者が求めていることであるという点である。

図２２は、ＵＥ、ＭＭＥ、およびＳＭ−ＳＣ内のＳＭＳのさまざまなエンティティが見えており、ＭＴ ＳＭＳ（例えば、小データを有する）がＳＭ−ＳＣからＵＥに送信される本発明の実施形態を開示している。図２２のこの特定の実施形態において、無線リソース解放タイマは、ＭＭ層がＵＥのＳＭＣエンティティからＣＰ−Ｄａｔａ ＣＰＤＵでＲＰ−Ａｃｋを受信するときに開始される。

代替的に、本発明の上述の実施形態の一部に対応するようにして、タイマは、ＳＭＳ、すなわち、ＭＴ ＳＭＳを含むＲＰ−Ｄａｔａ ＲＰＤＵを受信するとき、または上位のアプリケーション層がＭＭ層に指示を与えるときにやはり開始され得る。

本発明の上述の実施形態と同様に、ＵＥは、場合によってはタイマを中止し、それによって早期の無線リソースの解放を避けるために、まもなく行われる上りリンク・データの送信および／またはデータ・ベアラの確立を継続的に調べる。図２２の特定の実施形態において、アイドル指示は、ＲＰ−Ａｃｋを含むＣＰ−Ｄａｔａ ＣＰＤＵで送信される。したがって、タイマが開始された後、ＣＰ−Ｄａｔａ ＣＰＤＵは、タイマが中止されるかまたは切れるまで遅らされる。タイマが中止される場合、ＲＰ−Ａｃｋを含むＣＰ−Ｄａｔａ ＣＰＤＵがＭＭＥに送信される。タイマが切れる場合、ＲＰ−Ａｃｋを有するＣＰ−Ｄａｔａ ＣＰＤＵは、アイドル指示で（例えば、情報要素として）拡張され、それから、ＭＭＥに送信される。

タイマを中止する理由に応じて、ＵＥは、新しいデータ・ベアラの確立、または既存のデータ・ベアラのための無線リソースの有効化（後者は、本発明で上で説明したように、Ｃプレーンの無線ベアラだけが有効化されており、いかなるＤＲＢも有効化されていないと想定する）を要求するＮＡＳ ＥＳＭメッセージを送信することができる。

ＭＭＥは、ＲＰ−Ａｃｋを有するＣＰ−Ｄａｔａ ＣＰＤＵを受信し、ＲＰ−ＡｃｋをＳＭ−ＳＣに転送し、リソース解放指示を検出する。任意で、ＳＭＣエンティティは、リソース解放手順を開始するためにＳＭＲエンティティからのＲｅｌ−Ｒｅｑ指示を待つ。上で既に説明したように、無線リソースの解放を開始する前にＳＭＲエンティティからのＲｅｌ−Ｒｅｑを待つことは、いくつかのＭＴ ＳＭＳが連続して送信され、したがって、無線リソースのさまざまな再確立につながる状況を避けるために有利である。

ＭＭＥのＭＭ層は、内部的に解放要求指示を通知され、その解放要求指示が、ＭＭＥからｅＮＢへのＵＥコンテキスト解放命令（または無線リソースを解放するためのその他の可能な命令）の送信をトリガする。

図２２の実施形態は、さまざまなエンティティの内部構成と、上述の実施形態の機能がどのように実装され得るのかとについてより詳細により詳細な見解を与えているに過ぎないことに留意されたい。結果として、ＭＴ ＳＭＳのシナリオに関して上で説明した本発明のすべての変更形態および実施形態（図１７および１９参照）は、図２２に示すさまざまなエンティティにも実装可能である。

図２３は、ＵＥ、ＭＭＥ、およびＳＭ−ＳＣの特定のＳＭＳエンティティが詳細に示されているという点で図２２と似ている。しかし、図２３は、ＵＥからＳＭ−ＳＣへのＭＯ ＳＭＳの送信に関する。本発明のこの特定の実施形態においては、ＮＡＳ無線リソース解放タイマが、ＭＯ ＳＭＳの送信に応答してＵＥで受信されたＲＰ−Ａｃｋを検出することによって開始される。やはり、タイマのその他の開始イベントも可能であり、図１８および２０に関する説明をもう一度参照されたい。

無線リソース解放タイマが切れた後、アイドル指示が、ＭＭＥへのＮＡＳメッセージで別途送信されるか、またはＣＰ−Ａｃｋメッセージとともに送信される。アイドル指示は、（任意でＳＭＲエンティティからのＲｅｌ−Ｒｅｑメッセージと一緒に）無線リソース解放手順のトリガとして使用される。図２３の実施形態は、さまざまなエンティティの内部構成と、上述の実施形態の機能がどのように実装され得るのかとについてより詳細により詳細な見解を与えているに過ぎないことに留意されたい。結果として、ＭＯ ＳＭＳのシナリオに関して上で説明した本発明のすべての変更形態および実施形態（図１８および２０参照）は、図２３に示すエンティティにも実装可能である。

図２３および２４の実施形態においては、タイマと、さらに上りリンク・データを調べるための手順とが、ＵＥのＭＭエンティティで実装されるものとして説明され、示されている。しかし、本発明の代替的な実施形態においては、タイマ機能と、タイマを停止するための対応する監視メカニズムとは、ＳＭＣエンティティでも実装され得る。

図２４は、本発明の１つの特定の実施形態で実行されるべきさまざまなステップを示す流れ図である。

図２４の流れ図は、ＭＴ ＳＭＳの場合に関し、ＵＥがＣＰ−Ｄａｔａ ＣＰＤＵ内のＭＴ ＳＭＳ（ＲＰ−Ｄａｔａ ＲＰＤＵ）を受信することから始まる。この実施形態によれば、ＭＴ ＳＭＳの受信が、無線リソース解放タイマをトリガする。さらに、この特定の実施形態に関しては、アイドル指示が、ＭＴ ＳＭＳの正常な受信に対して肯定応答しているＲＰ−Ａｃｋメッセージと一緒に送信されると仮定する。この目的のために、ＲＰ−Ａｃｋを含む上りリンクのＣＰ−Ｄａｔａ ＣＰＤＵがバッファリングされ、無線リソース解放タイマが切れるまでＵＥのＮＡＳ層で遅らされる。

図２４ではＴ_{Ｄｅｌａｙ}と称される無線リソース解放タイマが、それがいつ切れるかを判定するために継続的に調べられる。明示的なアイドル指示は上述のように任意であるので、無線リソース解放タイマが切れる場合（分岐「はい」）、ＵＥは、ＲＰ−Ａｃｋおよびアイドル指示を有するＣＰ−Ｄａｔａ ＣＰＤＵをＭＭＥに送信する。それに応答して、ＭＭＥは、ｅＮＢにＮＡＳ／ＲＲＣの解放を命令する（例えば、ＵＥコンテキスト解放命令を送信する）ことによってｅＮＢとの無線リソース解放手順を開始する。

タイマが切れない間は（分岐「いいえ」）、ＵＥは、ＵＥのＮＡＳ層がＲＰ−Ｄａｔａ（ＲＰ−Ａｃｋではない）を含むＣＰ−Ｄａｔａ ＣＰＤＵを受信するか否かをさらに調べる。言い換えると、ＵＥは、上りリンク・データが送信されるべきか否かを調べる。そうである場合（分岐「はい」）、ＵＥは、タイマＴ_{Ｄｅｌａｙ}を停止し、ＲＰ−Ａｃｋと、タイマを中止させたＲＰ−Ｄａｔａとを有するＣＰ−Ｄａｔａ ＣＰＤＵをＭＭＥに送信する。

しかし、ＭＯ ＳＭＳのための上りリンク・データが検出されない（分岐「いいえ」）が、ＵＥが、ＵＥの上位層の非ＳＭＳアプリケーションから上りリンク・データ・ベアラの確立指示（ＤＲＢが設定されていない場合）またはデータ・ベアラの利用（ＤＲＢが設定されている場合）のトリガを受信する場合（分岐「はい」）、ＵＥは、やはりタイマを停止し、ＲＰ−Ａｃｋを有するＣＰ−Ｄａｔａ ＣＰＤＵを有するＮＡＳメッセージと、対応するＮＡＳ （Ｅ）ＳＭとをＭＭＥに送信する。

ＵＥとＭＭＥとの両方で無線リソース解放タイマを同時に実行することは、それによってＭＭ接続およびＲＲＣ接続の解放の遅延が大きくなり過ぎる可能性があるので望ましくないことに留意されたい。例えば、ＭＭＥが、ＣＰ−Ａｃｋ（ＭＯ ＳＭＳの場合）またはＲＰ−Ａｃｋを搬送するＣＰ−Ｄａｔａ（ＭＴ ＳＭＳの場合）（このＣＰ−Ｄａｔａは、実行中の無線リソース解放タイマによって既に遅らされている）を受信した後、無線リソース解放タイマを開始する場合、ＮＡＳ ＭＭ接続の解放の遅延が長くなり過ぎる。したがって、両方のエンティティで無線リソース解放タイマを同時に有効化することを避けるために、構成か、またはＵＥとＭＭＥとの間の何らかのネゴシエーションかのどちらかが可能であるべきである。

本発明のさらなる実施形態を、以下で説明する。

下りリンクの小データまたはＭＴ ＳＭＳが、ｅＮＢにおけるＲＲＣ接続の解放をトリガする（ただし、ＲＲＣの解放は条件付き（conditional）である可能性がある）ためにも使用される単一の下りリンクＮＡＳメッセージでＭＭＥからＵＥに搬送されるさらに別の実施形態を説明する。

例えば、図８に関連して明らかであるように、ＭＭＥがＵＥをページングした後、ＵＥは、サービス要求メッセージをＭＭＥに送信する。次いで、ＭＭＥが、ｅＮＢにおけるＵＥのコンテキストの確立を開始する。

この新しい実施形態は、ｅＮＢにおけるＵＥの確立が任意である可能性があること、すなわち、送信されるべきメッセージが１つ（またはほんのわずか）しかないためにＭＭＥがＵＥコンテキストの確立を省略する可能性があることに関してこの手順の最適化が行われると想定する。ｅＮＢにおけるＵＥコンテキストの確立を省略すると、無線インターフェースでＲＲＣメッセージの暗号化が行えなくなる。

この場合、ＵＥは、ＲＲＣ接続を解放するためにｅＮＢにＲＲＣ指示を送信する可能性がある。しかし、ＲＲＣ接続に加えて、ＵＥとＭＭＥとの間にしかるべきＮＡＳ接続が存在する可能性がある。ＮＡＳ暗号化が実施されるが、ＲＲＣ暗号化は適用されないときに、ＮＡＳ接続が確立されていると見なせるか否かは定義の問題であることが指摘され得る。ネットワークおよびＵＥが同期された状態であるために、ＮＡＳ接続の解放についてもＭＭＥに通知することが望ましい。ＵＥからＭＭＥへのその通知に関して困る事態は、ＭＭＥがｅＮＢに「条件付きの」解放を指示した結果、ＭＭＥが、無線リソースが維持されるのか、または解放されるのか分からないことであり、これは、言い方を変えれば、ＭＭＥが、さらなる下りリンクのＮＡＳメッセージが送信され得るか否か分からないことを意味する。

１つのあり得る解決策は、図１７〜２４の実施形態に関連して上で説明したようにＵＥからＭＭＥへの「ＩＤＬＥ」指示を適用することである。より詳細に言えば、ＭＭＥは、「ＩＤＬＥ」指示（およびＳＭＲエンティティからのＲｅｌ−ｒｅｑ）を受信するときに、無線リソースを解放するために、Ｓ１−ＡＰ「ＵＥコンテキスト解放」か、または何らかのその他の命令かのどちらかをｅＮＢに送信する。しかし、上述のシナリオでは、ｅＮＢにＵＥコンテキストが存在せず、したがって、ＵＥコンテキスト解放のためのＳ１−ＡＰメッセージは意味をなさない。したがって、単にＲＲＣ接続を解放するという新しい意味を実装するために、Ｓ１−ＡＰメッセージの意味を変更するか、または新しいＳ１−ＡＰメッセージを規定する必要がある可能性がある。一方、ＵＥは、ｅＮＢから「ＲＲＣ接続解放」要求を受信するときに、不正侵入を防止するためにＲＲＣメッセージを検証することができるべきである。

以下で、ＤＬ ＮＡＳメッセージを実現する可能性について説明する。１つの可能性は、ＤＬ小データまたはＭＴ ＳＭＳを修正されたＮＡＳサービス拒否メッセージでカプセル化することである。ＮＡＳサービス拒否メッセージは、またはＤＬデータがそのメッセージで搬送されており、ＮＡＳの拒否が処理エラー（もしくは輻輳）が原因で起こったのではないという新しい拒否理由、または追加のフラグもしくは指示を有する可能性がある。

別の可能性は、ＤＬ小データの転送に既存の「下りリンクＮＡＳトランスポート」メッセージを使用するが、ＲＲＣおよび／またはＮＡＳ「接続解放」の要求を含めることである。「接続解放」指示は、さまざまな方法で実装され得る。

・ 「接続解放」指示が、ＭＭＥからｅＮＢへのＳ１−ＡＰメッセージにのみ含められる。指示を受信した後、ｅＮＢがＲＲＣ接続を解放する。

・ 「接続解放」指示が、ＭＭＥからｅＮＢへのＳ１−ＡＰメッセージと、ＭＭＥからＵＥへの（小データを搬送する）ＤＬ ＮＡＳメッセージとに含められる。

概して、この実施形態で提案される最適化は、２つの機能、すなわち、ａ）ＤＬ小データを搬送する機能と、２）ＮＡＳ ＭＭ接続およびＲＲＣ接続の解放をトリガする機能とを果たすただ１つのＮＡＳメッセージがＭＭＥからＵＥに送信されることである。

上述の解決策の問題は、ＲＲＣ接続およびＮＡＳ ＭＭ接続が即座に解放されるために、ＵＥがＭＭＥにいかなる上りリンク・データまたはＡＣＫも送信することができないことである。したがって、本発明の別の実施形態は、条件付きのＲＲＣ接続の解放を実装することを提案する。

通常、ＤＬ ＮＡＳメッセージを搬送するＳ１−ＡＰメッセージは、ＵＥコンテキストの削除をｅＮＢに示す「ＵＥコンテキスト解放命令」をさらに含む。新しい解決策によれば、ＤＬ ＮＡＳメッセージ（例えば、サービス拒否メッセージ）を搬送するＳ１−ＡＰメッセージは、その代わりに、ｅＮＢへの「ＲＲＣ条件付き解放（RRC conditional release）」命令を含む。この条件付き解放命令は、ｅＮＢが、無条件にＵＥコンテキストを削除するのではなく、ＵＥがその後のＵＬ ＲＲＣメッセージで「ＲＲＣ維持（keep RRC）」を明示的に示さない場合にのみＵＥコンテキストを削除する（すなわち、ＲＲＣ接続を解放する）ことを意味する。さらに、ＭＭＥは、下りリンクのメッセージがＭＴ ＳＭＳの送信の一部としてのＲＰ−Ｄａｔａであることを知っている場合、少なくとも１つの上りリンクのＮＡＳ、すなわち、ＲＰ−Ａｃｋ ＲＰＤＵを搬送する上りリンクＮＡＳメッセージが予想されるべきであることが分かる。したがって、ＭＭＥは、単一の下りリンクＮＡＳメッセージの送信の後、直ちにＲＲＣを解放することを指示しない。１つの可能性は、ＭＭＥが、単一の下りリンクＮＡＳメッセージを搬送するＳ１−ＡＰメッセージで、ＲＰ−Ａｃｋ ＲＰＤＵを搬送するＵＥからの少なくとも１つの上りリンクＲＲＣメッセージを受信した後、ＲＲＣ接続が解放されることを示すことである。

指示「ＲＲＣ維持」の概念は象徴的であり、概して、ＵＥがＲＲＣ接続を維持したいことを意味する。「ＲＲＣ維持」の指示は、例えば、ＵＬ ＲＲＣメッセージでの明示的なＲＲＣ指示として、またはＭＭＥに連続するＮＡＳメッセージを送信することによって、またはＥ−ＲＡＢ確立手順中にＭＭＥによってトリガされるＤＲＢの確立によって実装され得る。

ｅＮＢは、指示「ＲＲＣ維持」を有するＵＬ ＲＲＣメッセージを待つための特定のタイマ（例えば、Ｔｃｏｎｄ＿ｒｅｌと称される）を有する可能性がある。ｅＮＢのこのタイマの値は、ＵＥごとにＭＭＥからシグナリングされ得るか、もしくはｅＮＢで静的に構成され得るかのどちらかであり、またはタイマの値は、さまざまな条件に基づいてｅＮＢで計算され得る。

ｅＮＢは、通常、各ＵＥのＩＤＬＥモードへの遷移をトリガするためのさらなるタイマを有し、ｅＮＢでネットワーク事業者によって構成されることを留意されたい。ＵＥがそのタイマの継続時間中にいかなるパケットも受信または送信しない場合、ｅＮＢは、Ｓ１−ＡＰ「ＵＥコンテキスト解放要求」メッセージをＭＭＥに送信する。そのとき、ＭＭＥは、「ＵＥコンテキスト解放命令」メッセージをｅＮＢに送信することによってＲＲＣ接続の解放を開始する。ＩＤＬＥモードへの遷移のためのｅＮＢで実行されているタイマは、ＵＥのＵＬまたはＤＬパケットが無線インターフェースを介して送信されるたびに再始動される。

「ＲＲＣ条件付き解放」手順を実装するためのｅＮＢのタイマ（Ｔｃｏｎｄ＿ｒｅｌ）は、ＩＤＬＥへの遷移のためのタイマとは異なる。１つの違いは、Ｔｃｏｎｄ＿ｒｅｌタイマがＭＭＥからのＲＲＣ接続解放指示（「ＵＥコンテキスト解放命令」メッセージ）によって開始されることである。さらに、Ｔｃｏｎｄ＿ｒｅｌタイマの継続時間は、ＩＤＬＥへの遷移のためのタイマの継続時間よりも大幅に短い。また、さらなる違いは、Ｔｃｏｎｄ＿ｒｅｌタイマがＵＥからの象徴的な「ＲＲＣ維持」の指示によって終了されることである。

「ＲＲＣ維持」の指示は、ＮＡＳ層で実装される可能性もあり（例えば、「ＮＡＳ維持（keep NAS）」）、例えば、ＵＥが、ＵＬ ＮＡＳメッセージで、ＮＡＳ ＭＭ接続が解放されるべきでないという指示をＭＭＥに送信する。

上述のこの実施形態においては、ＲＲＣ接続の確立に関して２つのオプションが可能であり、２つのオプションとは、すなわち、ａ）ＵＥのコンテキストがｅＮＢにプッシュされること、またはｂ）（小データもしくはＭＴ ＳＭＳを有する）ＤＬ ＮＡＳメッセージが暗号化されないＲＲＣ接続を介してＵＥに送信されることである。ＵＥがメッセージを復号可能であるので、ＤＬ ＮＡＳメッセージ自体が暗号化され得る。

１つの利点は、この最適化によって、規格に現在記載されているＩＤＬＥモードへの遷移の明示的なトリガのためのＳ１−ＡＰシグナリングおよびＲＲＣシグナリングが省かれることである。しかし、ｅＮＢに対する変更が必要である可能性がある。例えば、ｅＮＢは、暗号化されたＳＲＢ２ベアラではなく、暗号化されていないＳＲＢ１ベアラを介したＤＬ ＮＡＳメッセージをマッピングすることができるべきである。

ＤＬ小データが単一のメッセージである場合、いかなる予想されるＵＬデータもないので、小データを修正されたサービス拒否メッセージに含めることが有益である。しかし、通常、ＭＴ ＳＭＳが送信される必要があるとき、ＵＥは、少なくともＲＰ−ＡＣＫをネットワークに送信しなければならず、この場合、ＮＡＳ ＭＭ接続およびＲＲＣ接続は、ＭＴ ＳＭＳに肯定応答するためにＲＰ−Ａｃｋを送信することができるように、ＤＬ ＮＡＳメッセージを送信した後、直ちに解放されない。

一例においては、ＭＭＥがサービス拒否メッセージが正常に受信されたというＡＣＫを受信する必要がない新しい種類の「信頼できないＭＴ ＳＭＳ配信サービス」が規定される。それぞれ、ＳＭ−ＳＣも、ＲＰ−ＤＡＴＡ、すなわちＭＴ ＳＭＳの配信に対するＡＣＫを受信する必要がない。このサブオプションは、無線リンクに問題があり、ＮＡＳサービス拒否メッセージが誤りなくＵＥに配信され得ない場合、問題を起こす可能性がある。

別の例においては、ＭＴ ＳＭＳがデバイス・トリガ・メッセージである（それに応答してＵＬデータが送信されることになることを意味する）場合、その後のＵプレーンのベアラの確立、またはＭＯ ＳＭＳもしくはＵＬ小データが、デバイス・トリガ・メッセージ、すなわちＭＴ ＳＭＳを搬送するＤＬ ＮＡＳメッセージの配信に対するＡＣＫとして使用され得る。このサブオプションの不利な点は、ＵＥが、ＮＡＳサービス要求メッセージを受信した後にＲＲＣ接続およびＮＡＳ ＭＭ接続の確立を開始する必要があることである。

この実施形態で提案される解決策の全体的に不利な点は、ＵＥが、ＮＡＳ ＭＭ接続を維持したい場合に、ＭＭＥおよび／またはｅＮＢに明示的な指示（「ＲＲＣ維持」）を送信する必要があることである。これは、場合によっては、送信される必要があるさらなるＮＡＳメッセージを意味する。

以下の手順は、完全なシグナリング・フローを示している。

・ ＵＥがページングされる（おそらくは、本発明で既に説明したように、ＭＴ小データに関する特別な指示を伴う）。

・ ＵＥがＭＭＥにサービス要求を送信する（おそらくは、本発明で既に説明したように、「小データ」の指示を伴う）。

・ ＭＭＥが、ＭＴ小データを搬送し、ｅＮＢおよび／またはＵＥへの「解放」指示を含むＮＡＳ ＤＬメッセージ（修正されたサービス拒否または下りリンクＮＡＳトランスポート）をＵＥに送信する。ＭＭＥは、ＤＬ小データが単一の下りリンク・メッセージであり、すなわち、連結されたＳＭＳの一部ではないことを知っている場合にこのオプションを使用すると決定することができることに留意されたい。

・ ＤＬ ＮＡＳメッセージを受信し、メッセージの内容を処理した後、ＵＥがＵＬデータを送信する必要がある場合、ＵＥが、以下のようにして処理を進める可能性がある。

・ ＵＬデータがＵプレーンのＥＰＳデータ・ベアラを使用することになる場合、ＵＥが、第２のＮＡＳ ＭＭサービス要求またはＮＡＳ （Ｅ）ＳＭメッセージ（例えば、ＰＤＮ接続性要求）をＭＭＥに送信し、データ・ベアラが必要であることを示す。

・ ＵＬデータが（例えば、ＭＯ ＳＭＳのために）Ｃプレーンの接続の利用することになる場合、ＵＥが、ＵＬデータを搬送するＵＬ ＮＡＳメッセージを送信する。ＵＥは、ＭＭＥ（および場合によってはｅＮＢ）に、ＮＡＳ接続が解放されないことを示す。さらに、ＵＥは、本発明で既に開示されたメカニズムを適用する可能性があり、すなわち、無線リソース解放タイマおよび「アイドル指示」をＭＭＥに適用できる。

・ ｅＮＢは、ＲＲＣ接続を解放しない。

・ ＵＥかまたはＭＭＥかのどちらかが、送信すべきＵＬデータおよびＤＬデータの量に基づいてＮＡＳ ＭＭ接続およびＲＲＣ接続の終了を判断する（上の内容を参照されたい）。

本発明のさらなる実施形態を、以下で説明する。この発明のさらなる実施形態は、ＵＥが複数のＭＴＣアプリケーションを有し、それらのＭＴＣアプリケーションのうちの少なくとも１つが遅延に寛容であるシナリオを扱う。「遅延に寛容」とは、ＵＥが送信するためのデータを有する可能性があるが、データの送信の遅延が致命的でないことを意味する。送信を遅らせる理由は、無線リソースを節約し、電力消費を抑え、その他のアプリケーションまたはスケジューリングされたＴＡＵ手順によってネットワークへの接続がトリガされるときに遅延に寛容なデータを送信するためである。その後、ＵＥは、ＩＤＬＥ状態からＡＣＴＩＶＥ状態に遷移するときに、遅延に寛容なＭＴＣアプリケーションに関するＵＬデータを送信する可能性がある。

上述のように、ＵＥは、拡張サービス要求でＭＭＥにＵＬデータの統計を送信し、したがって、ＭＭＥが、ＥＰＳデータ・ベアラの確立が必要か否かを判断することができる。ＵＥは、送信すべき遅延に寛容なＭＴＣアプリケーションからの未処理のＵＬデータを有する場合、拡張サービス要求でこの未処理のデータを示すこともできる。この解決策の１つの問題は、ＵＥからの指示が不明確である可能性があり、ＭＭＥの判断が正しくない（例えば、Ｃプレーン／ＮＡＳを使用するが、ＵＥが異なるＰＤＮ接続にデータを送信する）可能性があることである。したがって、この問題に対処するための解決策が必要である。

本発明のこの実施形態の解決策は、ＭＴ小データまたはＭＴ ＳＭＳの結果生じたＵＬデータ（例えば、ＳＭＳ転送）とともに、拡張サービス要求内のＵＥからのどの特定のデータ・ベアラ（どのＰＤＮ接続）がさらに必要かの明示的な指示に基づく。結果的に、ＭＭＥは、遅延に寛容なＭＴＣアプリケーションのためのＤＲＢを確立し、ＮＡＳを介したＭＴ ＳＭＳ転送（およびその結果行われる可能性があるＭＯ ＳＭＳ）が平行して実行される。

任意で、ＵＥは、通常のサービス要求（ページングに対する応答としての拡張サービス要求ではない）を送信する可能性があり、後でＥＳＭ（ＥＰＳセッション管理）メッセージを使用することにより、遅延に寛容なＭＴＣアプリケーションのための特定のＥＰＳベアラを有効化することができる。例えば、サービス要求を送信し、いかなるＥＰＳベアラも確立されていないことを意味するＤＬ小データまたはＭＴ ＳＭＳ（例えば、下りリンクＮＡＳトランスポート・メッセージでカプセル化されている）を受信した後、ＵＥは、遅延に寛容なＭＴＣアプリケーションのための所与のＡＰＮへのＥＰＳベアラの確立を明示的に要求するために、ＥＳＭ ＰＤＮ接続性要求をＭＭＥに送信することができる。ＵＥが（拡張）サービス要求を送信した後にネットワークがＥＰＳデータ・ベアラを設定することを決定したが、遅延に寛容なＭＴＣアプリケーションが別のＥＰＳベアラを必要とする場合、以下のオプションがあり得る可能性がある。

・ 遅延に寛容なＭＴＣアプリケーションが異なるＡＰＮを必要とする場合、ＵＥが、ＰＤＮ接続性要求をＭＭＥに送信して、異なるＡＰＮへの新たなＰＤＮ接続を確立する。

・ 遅延に寛容なＭＴＣアプリケーションが個別ＥＰＳベアラを必要とする場合、ＵＥが、個別ＥＰＳベアラの確立をトリガする（ネットワークがそうすると決定した場合）ためにＥＰＳベアラ修正要求を送信する。

［ショート・メッセージ・ハンドオーバ手順］
以下で、移動ノードが無線リソースへの影響を抑えながら無線アクセス技術を変更することを可能にする改良されたハンドオーバ手順に関連する本発明のさまざまな実施形態を説明する。

より具体的には、図３１が、本発明のこの実施形態で使用される原理を実装するエンティティ間の高レベルの例示的なシグナリングの交換を示している。例示のみを目的として以下のシナリオが想定される。

移動ノードが、現在、ネットワーク、すなわちＳＭＳ−ＳＣとＳＭＳを交換していると仮定する。今のところ、ＵＥはＥ−ＵＴＲＡＮ内にあり、ＭＭＥを介し、ＳＧｄインターフェースでＳＭＳ−ＳＣと直接ＳＭＳを交換しているか、またはネイティブでＳＧｓインターフェースを介してＭＳＣサーバとＳＭＳを交換しているかのいずれかであると仮定されるべきである。

ＵＥは、ＵＥとｅＮＢとの間のシグナリング・ベアラ（例えば、ＳＲＢ０、ＳＲＢ１、ＳＲＢ２）と、ＬＴＥネットワーク内で確立された少なくとも１つのデフォルト・データ・ベアラ（ＤＲＢ、データ無線ベアラ）とを常に有しており、任意で、さらなる個別ＥＰＳベアラがユーザ・データを送信するために確立される。ｅＮＢは、それぞれのアクティブなＵＥに関して、ＭＭＥとの制御プレーンの接続と、ＳＧＷとのユーザ・プレーンの接続とを有する。デフォルト・データ・ベアラは、そのデフォルト・データ・ベアラがユーザ・データの送信のために実際に使用されるか否かに関係なく確立される。したがって、小データ（すなわち、シグナリング接続を介する）のみが制御プレーンを介してＬＴＥネットワーク内で移動ノードと交換される場合であっても、デフォルト・データ・ベアラは、移動ノードのためにＬＴＥネットワーク内でやはり確立されており、アクティブである。

ステップ１）
ｅＮＢが、ＳＭＳの交換が実行中である間に、すなわち、ＳＭＳの交換が完了する前に、ＵＥによって報告された測定に応じて移動ノードを（例えば、ＳＧＳＮによってサービスを提供される）別のハンドオーバ先アクセスにハンドオーバすることを望んでいる。それに対応して、ｅＮＢが、これをＭＭＥに示すことによってハンドオーバを開始する。したがって、ステップ１は、ＵＥによって実行され、ＵＥによってｅＮＢに報告される無線の測定も含むと見なされ得る。

ステップ２）
ここで、ＵＴＲＡＮ内の対応するデータ接続が確立されるべきか否かを判断する必要がある。図３１の例示的な実施形態においては、ハンドオーバ元ＭＭＥがこの判断を行うと仮定する。しかし、この判断は、ＭＭＥによってのみ実行されるのではなく、ＵＥおよび／またはｅＮＢによっても実行される可能性があり、概して、移動ノードの小データの交換に関与するＬＴＥネットワーク内のエンティティのうちの１つがこの判断を実行すると言うことができる。

さらに、この判断がどのように行われるかは、以降で説明するように、本発明の実施形態ごとにやはり異なる可能性がある。

一実施形態によれば、ＬＴＥネットワークのデフォルトのＥＰＳデータ・ベアラがデータ送信のために実際に今現在使用されているか否かが判定される可能性がある。Ｓ１−Ｕの有効化以降、上りリンクまたは下りリンクでいかなるデータも交換されなかった（または単に所与の時間内に交換されなかった）と判定された場合、データ接続はＵＴＲＡＮで不要であると決定され得る。この判定は、このデフォルト・データ・ベアラを介したユーザ・プレーンのデータ交換に関連するＵＥ、サービング・ゲートウェイ、またはｅＮＢからのデータの統計に基づく可能性がある。それに対応して、判断を実行するノード（例えば、ＭＭＥ）は、その他のノード（例えば、ＵＥ、サービング・ゲートウェイ、またはｅＮＢ）のうちの１つまたは複数から適切な情報を取得する。

特定の実施形態によれば、ＭＭＥは、ｅＮＢがＲＡＴ間ハンドオーバが必要であることをＭＭＥに知らせる（ステップ１）ときにＳ１−Ｕの統計をＭＭＥに報告するように、Ｓ１−Ｕベアラの確立中にｅＮＢを構成する可能性もある。それに対応して、ステップ１において、ＵＥは、無線の測定をｅＮＢに報告し、ｅＮＢは、ＲＡＴ間ハンドオーバが必要であると判断するとき、ＲＡＴ間ハンドオーバを準備するために、例えばＳ１−ＡＰメッセージによってＭＭＥに知らせる。好ましくは、「ハンドオーバ要請」メッセージ（標準的な準備フェーズの図２９のステップ２）が、ｅＮＢが、サービング・ゲートウェイへのＳ１−Ｕベアラを確立した後に上りリンクおよび下りリンクで交換されたデータの統計をＭＭＥに知らせることができるように拡張される可能性がある。

本発明の代替的な実施形態によれば、（ｅＮＢの代わりに）ＵＥが、データ交換についてＭＭＥに知らせる。ＭＭＥが、（例えば、ｅＮＢからＭＭＥで「ハンドオーバ要請」メッセージを受信したときに）データの統計に関してＵＥに直接問い合わせるか、またはＵＥが、シグナリング接続を介してＳＭＳを送信するためだけのＵプレーンのベアラを確立し、したがって、ネットワークがステップ２）の判定のためにそのような情報を必要とする可能性があることを知っている可能性があるので、明示的な要求なしにＭＭＥに通知する可能性があるかのどちらかである。データの統計の転送のための１つのオプションは、ＵＥからＭＭＥへの別個のＮＡＳシグナリング・メッセージを使用することである。別のオプションは、既存のＮＡＳメッセージ、例えば、ＮＡＳ ＥＭＭ情報メッセージで搬送される新しい情報要素を規定することである。

本発明のさらなる実施形態によれば、データの統計についての多くの情報を送信する代わりに、ＵＥが、ユーザ・プレーンのデータ・ベアラを介したデータ交換が行われたか、または行われているか、または近い将来に行われるかに関する指示を送信する可能性がある。やはり、この指示は、ＵＥからＭＭＥへの別個のＮＡＳシグナリング・メッセージで送信されるか、または代替的に、ＳＭＳの送信に使用されるＮＡＳメッセージに、例えばビット（「アクティブ・ビット（active bit）」）としてピギーバックされる可能性がある。ＵＥは、ＭＭＥとのそのような情報の交換を実行するために、この実施形態および上述の実施形態で修正される必要があることに留意されたい。

本発明のさらにその他の実施形態によれば、ＵＴＲＡＮでデータ接続を確立すべきか否かについての決定が、上述の実施形態で説明したデータの統計またはＵＥからの指示を必要とせずに行われ得る。特に、ＳＭＳの送信が始まる前、ＵＥがＣＯＮＮＥＣＴＥＤ状態であった場合、ＬＴＥネットワークのデータ・ベアラが確かに使用されており、したがって、ＵＴＲＡＮへのハンドオーバの後にやはり使用される可能性があると想定され得る。各ＥＰＳベアラは、例えば、実行中の緊急サービス、ＭＰＳ（Multimedia Priority Service：マルチメディア優先度サービス）サービス、またはＩＭＳサービスを有するＵＥに関連するＡＲＰ値（Access Retention and Priority：アクセス維持および優先度）を割り当てられる。Ｅ−ＵＴＲＡＮのデフォルト・データ・ベアラに関するこのＡＲＰ値が高い（すなわち、事前に定義された閾値よりも高い）場合、Ｅ−ＵＴＲＡＮでそのデータ・ベアラが現在使用されているか否かにかかわらず、対応するデータ接続がＵＴＲＡＮにおいて確立されることになる。また、ＵＥが受信したＳＭＳ（デバイスをトリガするために使用されるＳＭＳ）に応答してデータを送信するようにトリガされることが分かっているときは、ＳＭＳの送信が完了するとＵＥがデータ送信を開始すると推測され得る。この場合にも、Ｅ−ＵＴＲＡＮでデータ・ベアラが現在使用されているか否かにかかわらず、データ接続がＵＴＲＡＮにおいて確立されることになる。

以上、データ接続（Ｅ−ＵＴＲＡＮのデフォルト・データ・ベアラに対応する）が確立されるべきか否かを判定するさまざまな方法を説明した。さらに、（ＭＭＥであろうと、ＵＥであろうと、ｅＮＢであろうと）どのエンティティが実際に判断を行うかにかかわらず、ＭＭＥは、以下のステップ３）にしたがってハンドオーバ手順を継続することになるので、判断の結果を知る必要があり、すなわち、ハンドオーバ手順がやはりハンドオーバ先ネットワーク（ＵＴＲＡＮ）でデータ接続を確立するようなものであるか否かを知る必要がある。

さらなるハンドオーバ手順に関して、もっぱら、別途説明されない限り、ＵＴＲＡＮのデータ接続を確立しないと決定されたと仮定する。

ステップ３）
図３１ではハンドオーバ元ＭＭＥと称されるＭＭＥが、ハンドオーバ先ＳＧＳＮに、移動ノードがそのハンドオーバ先ＳＧＳＮへのハンドオーバを実行することを知らせ、ＬＴＥネットワークのＥＰＳベアラ・コンテキストをＳＧＳＮに送信する。ＥＰＳベアラ・コンテキストは、ハンドオーバを実行したいＵＥのためにＬＴＥネットワークで確立されており、アクティブであるデータ・ベアラに関連し、ＬＴＥではＳＲＢに関するＥＰＳベアラ・コンテキストは存在しない。

想定される例示的なシナリオにおいては、デフォルト・データ・ベアラのみがＬＴＥネットワークで確立されている（ＳＭＳデータ交換のみ）ので、このデフォルト・データ・ベアラに関するＥＰＳベアラ・コンテキストのみが、ＳＧＳＮに送信される。さらに、ＭＭＥ（または別のノード）がデータ接続が不要であり、ＵＴＲＡＮで確立されないと決定したため、ＭＭＥは、ＰＤＰコンテキスト（ＬＴＥのＥＰＳデフォルト・ベアラ・コンテキストに対応する）が「保存」状態に維持されることもＳＧＳＮに知らせる。「保存」とは、基本的に、ＳＧＳＮが、サービング・ゲートウェイ（ＳＧＷ）に連絡してこのＰＤＰコンテキストのためのＳ４関連付けまたはトンネルを確立する可能性がある（下のステップ４）参照）が、対応する無線アクセス・ベアラ（ＲＡＢ）を確立するようにハンドオーバ先アクセス・ネットワーク（すなわち、ＲＮＣ／ＢＳＳ）に要求せず、したがって、ＰＤＰコンテキストが有効化されない（３ＧＰＰの用語を用いて言えば、ＰＤＰコンテキストがＳＧＳＮおよびコア・ネットワークに「保存」される）ことを意味する。

本発明の一実施形態によれば、これは、ＥＰＳベアラがあるべき状態についてＳＧＳＮに知らせ、（デフォルト・データ・ベアラの）Ｅ−ＲＡＢ ＩＤを含め、デフォルト・データ・ベアラのこのＥ−ＲＡＢ ＩＤに関して状態「保存」を示すことによって、ＭＭＥにより開始される。これは、ＰＤＰコンテキスト（ＧＥＲＡＮ／ＵＴＲＡＮのＲＡＢ）の有効化が不要であることをＳＧＳＮに明示的に知らせる。それに対応して、ハンドオーバ元ＭＭＥからハンドオーバ先ＳＧＳＮに送信されるメッセージは、（１つまたは複数の）ＥＰＳベアラ・コンテキストだけでなく、各コンテキストの状態も含む。

さらに、ＭＭＥは、ＭＭＥとＵＥとの間で実行中のＳＭＳの送信があるので、ハンドオーバ処理の後またはハンドオーバ処理中にＳＭＳ ＰＤＵが転送されることをＳＧＳＮに知らせることができる。これは、ハンドオーバ先アクセス（ＵＴＲＡＮ／ＧＥＲＡＮ）の制御プレーンの接続がＳＭＳ送信のために使用されることになるというＳＧＳＮへの指示として使用され得る。

ステップ４）
このステップは、ＳＧＳＮおよびハンドオーバ先ネットワークによって実行される処理を含む。通常通り、ＥＰＳコンテキストが、ＳＧＳＮによってＰＤＰコンテキストにマッピングされ、格納される。さらに、ＳＧＳＮが（サービングＧＷへの接続が移動ノードに関して前に既に確立されたか否か、例えば、ＵＥがＳＧＳＮに前に既にアタッチされたか、またはＩＳＲがＵＥに関して有効化されたか否かによって）移動ノードに関するコンテキストを前に格納した場合、ＳＧＳＮは、ＰＤＰコンテキストのためのサービング・ゲートウェイとの接続、特にＳ４関連付けまたはトンネルを確立する必要がある可能性がある。

ＳＧＳＮは、受信されたＥＰＳベアラ・コンテキストから、マッピングされた各ＰＤＰコンテキストに関するＰＤＰコンテキストＩＤを生成する可能性もあり、ＰＤＰコンテキストＩＤは、以下から明らかなように、さらなるハンドオーバ手順で使用される。

それに対応して、ＳＧＳＮは、（（１つまたは複数の）受信されたＥＰＳベアラ・コンテキストからマッピングされた）ＰＤＰコンテキストを格納し、そこでコンテキストを確立し、したがってＵＴＲＡＮネットワークでデータ接続を確立するためにＲＮＣ／ＢＳＳに連絡しない。

しかし、ＳＧＳＮは、ハンドオーバ先ＲＮＣ／ＢＳＳに連絡して、未処理のハンドオーバについて知らせ、Ｅ−ＵＴＲＡＮのシグナリング無線ベアラに対応してハンドオーバ先アクセス・ネットワークのシグナリング無線ベアラを確立する。その目的のために、ＲＮＣがハンドオーバ先ＮＢに連絡し、ＢＳＳでは、ＢＳＣ（基地局コントローラ）がＢＴＳ（Base Transceiver Station：無線基地局）に連絡して、移動してくるＵＥに対する準備をする。さらに、ＲＮＣまたはＢＳＣとＳＧＳＮとの間のＩｕｐｓまたはＧｂ関連付けが、ＵＥのために確立される。ＢＳＳは、ＢＳＣ（ＢＳＣはＳＧＳＮに接続するためのＰＣＵ、パケット制御ユニットを含み得る）およびＢＴＳを含むことに留意されたい。

要約すると、ステップ４）において、Ｅ−ＵＴＲＡＮのＥＰＳデフォルト・データ・ベアラのＥＰＳベアラ・コンテキストに関する「保存」状態の情報を提供することによって、ＳＧＳＮが、無線リソースを無駄にする可能性があるＵＴＲＡＮまたはＧＥＲＡＮネットワークの対応するデータ・ベアラを確立することを避け、しかし、制御プレーンの接続のために無線アクセス・エンティティを準備することが実現される。

ステップ５）
このステップは、基本的に、ハンドオーバ先ＳＧＳＮが、ハンドオーバ情報と、さらにはＰＤＰコンテキストの保存状態についての指示とを正しく受信したことを確認することを明確にするために「ＨＯ要求確認（Confirm HO request）」と称される。さらに、ＳＧＳＮは、ＵＥによって使用されるべき無線に固有の情報を含めて、ＭＭＥに応答する。既に説明したように、ＳＧＳＮは、「保存」ＰＤＰコンテキストの確立を確認することができる。さまざまなＥＰＳベアラ・コンテキストがＭＭＥからＳＧＳＮに送信されたと仮定すると、ＰＤＰコンテキストの一部が（例えば、輻輳のために）ＳＧＳＮによって確立されない可能性があるので、要求されたＰＤＰコンテキストの確立／保存の結果についてＭＭＥに知らせることが有利である。結果は、例えば、「成功」および「不成功」である可能性がある。また、生成されたＰＤＰコンテキストＩＤがＭＭＥに送信され、通常は、ＲＡＢ ＩＤがＭＭＥに送信されるが、ステップ４）で説明したように、いかなるデータ接続（すなわち、ＲＡＢ）もＳＧＳＮで確立されないので、ＲＡＢ ＩＤは存在しない。

加えて、このステップにおいて、ＭＳＣとＭＭＥとの間のＳＧｓ関連付けのような関連付けがＳＧＳＮとＭＭＥとの間で確立される可能性があり、すなわち、ＭＭＥとＳＧＳＮとの間のＳＭ−ＣＰ ＰＤＵの転送（およびページング）を可能にする。

ステップ６、６ａ）
ＭＭＥが、ＵＥに搬送される情報を集め、その情報を、例えば、Ｓ１−ＡＰメッセージを用いてｅＮＢに送信し、さらにはＵＥに送信する。送信された情報により、ＵＥは、ハンドオーバ先ＵＴＲＡＮネットワーク（すなわち、ＳＧＳＮ）でどのベアラが有効化されたかを知ることができる。概して、ＵＥに送信されるハンドオーバ先ＲＡＮ情報は、ハンドオーバ先アクセス（すなわち、ＵＴＲＡＮ）に関連するパラメータに関する情報を含む。現在の標準化では、これは、ハンドオーバ先アクセスで確立されている（有効化されている）ＰＤＰコンテキストのＲＡＢ ＩＤを含むが、ベアラ・コンテキストの明示的な状態、すなわち、「保存」、「アクティブ」、または「削除」は送信されない。現時点で、ハンドオーバ先アクセスで確立されていないベアラ・コンテキストは、ＳＧＳＮ／ＭＭＥでは削除され、ＵＥに保存されている。

一実施形態によれば、したがって、ハンドオーバ先ＲＡＮ情報は、ＳＧＳＮで確立されたが、「保存」状態に保たれているＰＤＰコンテキストのＰＤＰコンテキストＩＤを含む可能性がある。任意で、ハンドオーバ先ＲＡＮ情報は、ステップ３と同様に、ハンドオーバ先アクセスのＥＰＳベアラ・コンテキストのＥＰＳベアラ・コンテキストＩＤおよび状態を含む可能性がある。

さらなる実施形態によれば、ステップ６、６ａ）のＨＯ命令メッセージがハンドオーバ先アクセスのＰＤＰコンテキストの（１つまたは複数の）ＲＡＢ ＩＤを含まない場合、ＵＥは、（１つまたは複数の）ＲＡＢ ＩＤを欠いたそのメッセージを、Ｅ−ＵＴＲＡＮのためにＵＥにＥＰＳコンテキストが格納されているにもかかわらず、そのＵＥがＵＴＲＡＮでシグナリング・ベアラ／接続のみを確立する必要があり、ＵＴＲＡＮのためのＥＰＳコンテキストが、対応するＰＤＰコンテキストにマッピングされ、「保存」状態に維持され、すなわち、ただＵＥに格納されるだけであり、さらに使用または有効化されることがないものと解釈することができる。別の言い方をすれば、このさらなる実施形態によれば、ベアラ・コンテキストの状態がＭＭＥからＵＥに報告されるのではなく、ハンドオーバ先アクセスの（１つまたは複数の）確立されたシグナリング・ベアラだけが報告され、その結果、ＵＥは、「示されていない」（欠けている）ＲＡＢ−ＩＤに関して、Ｅ−ＵＴＲＡＮアクセスからのＥＰＳベアラを保存状態のＰＤＰコンテキストに設定する。ハンドオーバ先アクセスでシグナリング接続のみが確立される本発明の特定のシナリオにおいては、ハンドオーバ命令メッセージが、ハンドオーバ先ＮＢまたはＢＴＳ（任意で、使用されるべきチャネルまたはタイム・スロット、割り振られた一時無線識別子（temporary radio identifier）、およびコア・ネットワーク識別子）についての情報を含むが、確立されたユーザ・プレーンのベアラについての情報は含まない（すなわち、ＲＡＢ ＩＤは含まない）。後のＲＡＵ／ＴＡＵ手順またはサービス要求手順の間に、ネットワークで維持されているＰＤＰベアラ・コンテキストおよびＵＥで維持されているＰＤＰベアラ・コンテキストが揃えられる可能性があり、すなわち、その場合、ネットワークで削除された（１つまたは複数の）ＰＤＰ／ベアラ・コンテキストがＵＥで削除される。

これに関連して、さらに、現在は、ハンドオーバ先アクセスでいかなるデータ・ベアラも確立できない場合、ＲＡＴ間ハンドオーバは失敗することが指摘され得る（例えば、ＴＳ２３．４０１、５．５．２．１．４節参照）。言うまでもなく、これは、この実施形態においてそれとは異なる処理をされ、ＲＡＴ間ハンドオーバは、ハンドオーバ先アクセスでいかなるデータ・ベアラも確立されなかったとしても正常に完了する。

ＭＭＥは、ＳＧＳＮで（１つまたは複数の）ＰＤＰコンテキストが確立された（１つまたは複数の）ＥＰＳベアラ・コンテキストを維持すべきである（すなわち、ＭＭＥは、そのＥＰＳベアラ・コンテキストと、サービングＧＷとの対応するＳ１１接続とを削除しない）。図２９では、ステップ５において対応するＲＡＢ ＩＤが存在しない場合、ＥＰＳベアラがＭＭＥで削除される（さらに、対応するＰＤＰコンテキストがＳＧＳＮに格納されない）ので、これは、図２９の従来技術とは異なる。

ステップ７）
上のステップ６、６ａ）に関する説明で既に示唆されたように、ＵＥは、ＭＭＥおよびｅＮＢから受信されたハンドオーバ命令を処理する必要がある。これは、ＵＥが、ＭＭＥからの明示的または暗黙的な指示（ステップ６、６ａ参照）にしたがって、保存状態のハンドオーバ先アクセスのためのＰＤＰコンテキストを設定することを含む。

本発明のさらなる実施形態によれば、ＰＤＰコンテキストの状態は、「削除」である可能性もあり、その場合、ＵＥは、ハンドオーバ命令メッセージに応答して、アクティブなＥＰＳベアラに関する対応するＥＰＳベアラ・コンテキストを削除する。

より具体的な実施形態によれば、ＵＥは、ＵＴＲＡＮでデータ接続を確立すべきか、または確立すべきでないかに関する（すなわち、データ接続の状態に関する）、ＨＯ命令メッセージで受信された命令を無視するか、または直ちに上書きする可能性もある。例えば、ＵＥは、ハンドオーバ命令メッセージに応答してベアラ・コンテキストを「保存」状態に設定するが、ハンドオーバ先アクセスでシグナリング接続を確立した後、コンテキストの有効化を直ちに開始すると決定する可能性がある。ＨＯ命令メッセージ内のＭＭＥの命令に反するこの処理は、ＭＴ ＳＭＳがデバイスのトリガのために使用され、すなわち、データ接続を使用して上りリンクでユーザ・データを送信するようにＵＥをトリガし、したがって、ハンドオーバ先アクセス（ＧＥＲＡＮ／ＵＴＲＡＮ）でデータ接続がやはり確立され、ＳＭＳの送信が完了した後に上りリンク・データを送信するために使用される場合に有利である可能性がある。同様に、状態がＥＰＳコンテキストに関して「削除」を示すときに、ＵＥは、ＥＰＳベアラ・コンテキストを削除せず、実際には、ハンドオーバ先アクセスでデータ・ベアラの確立を開始する。この目的のために、ＵＥは、例えば、ハンドオーバ先アクセスを介したＳＧＳＮへの個別ＰＤＰコンテキスト有効化シグナリングによってユーザ・プレーンのベアラの確立を要求する。

ステップ８）
このステップにおいては、ＵＥが、ハンドオーバ先ＲＮＣ／ＢＳＳとのＲＲＣ接続の確立を開始することによって、ＲＡＴ間ハンドオーバのための無線に固有の手順を実行する。これは、ステップ６、６ａ）のハンドオーバ先ＲＡＮ情報で示された情報にしたがって、ＲＮＣ／ＢＳＳとのシグナリング無線ベアラを確立することを含む。

ステップ８）の後、ＵＥは、基本的に、ＳＧＳＮとのシグナリング接続を有し（想定される例示的なシナリオを前提とすると、データ・ベアラ接続は持たない）、ＳＭ−ＣＰ ＰＤＵまたはその他のＮＡＳシグナリング・メッセージの交換を継続することができる。

ステップ９、９ａ）
ＳＭＳ ＰＤＵの交換が、Ｓ３インターフェースのＳＧｓに似た関連付けを介してハンドオーバ元ＭＭＥおよびハンドオーバ先ＳＧＳＮによって実行される（ステップ９ａ参照）。そのとき、ＳＭＳは、ＵＴＲＡＮでＵＥに配信され得る。図３２は、上述の実施形態によるハンドオーバが実行された後のＭＴ ＳＭＳに関するＳＭＳ配信経路を示している。

ハンドオーバ手順が正常に完了した後、ＭＭＥは、保存状態でＳＧＳＮにおいて確立された（１つまたは複数の）ＥＳＭベアラ・コンテキストを維持し続け、これは、後でＩＳＲを有効化することを可能にするためであることに留意されたい。ＭＭＥは、サービング・ゲートウェイからのページング・メッセージを受信することを可能にするため、または（ＵＥがＮＡＳ ＳｅｒｖｉｃｅＲｅｑｕｅｓｔメッセージを送信するときに）ＵＥを登録することを可能にするために、（１つまたは複数の）保存されたＰＤＰベアラ・コンテキストのためのサービング・ゲートウェイとの関連付けを維持する。このように、ＳＧＳＮは、ＮＡＳシグナリングでＵＥへのＩＳＲの指示を設定して、ＩＳＲが有効化されることをＵＥに示すことができる。しかし、ＩＳＲがサポートされない場合（これは、例えば、図３１のステップ３〜５においてＳＧＳＮとＭＭＥとの間でネゴシエーションされ得る）、ＭＭＥは、ＵＥに関するセッション管理（ＳＭまたはａｋａ ＥＳＭ）コンテキストを削除し、移動管理（ＭＭまたはａｋａ ＥＭＭ）コンテキストのみを維持する可能性がある。

上述の手順は、３ＧＰＰによって規定された既存の標準的な手順でも実装され得る。特に、本発明のより詳細な例示的実施形態に関して、上で説明したステップ１〜９）は、図２９および３０に関連して説明したＴＳ２３．４０１の準備フェーズおよび実行フェーズに実装される。以下で説明するように、本発明の実施形態は、規格で実行されるステップの一部を変更し、および／または規格でまだ定義されていない（例えば、ＭＭＥ、ＵＥ、およびＳＧＳＮにおける）さらなる処理を追加する。したがって、以下で言及されない図２９、３０の標準的な手順のステップは、基本的に変わらないと考えられる。

特に、図３１のステップ１）は、基本的に、図２９の準備フェーズのステップ１）および２）に対応する。図３１のステップ２）は、図２９の標準的な手順にしたがってＭＭＥにより実行されない新たなステップである。

図３１のステップ３）は、図２９の準備フェーズのステップ３）に対応し、特に、そのステップ３）で交換されるフォワード再配置要求メッセージに対応する。図３１のステップ４によるＳＧＳＮの処理は、規格のものとは大部分が異なっているが、図２９の準備フェーズのステップ４、４ａ、５、５ａ（および６、６ａ）に関連すると考えられる。

図３１のステップ５は、図２９のステップ７と比較でき、特に、フォワード再配置応答メッセージと比較され得るが、上で説明したように、さらなる変更を伴う。図３１のステップ６）のハンドオーバ命令メッセージは、図３０の実行フェーズのステップ１および２のハンドオーバ命令メッセージに対応する。

図３１のステップ７）の処理は、標準的なハンドオーバ手順中にＵＥで必ず実行される処理（規格の文書では正式に定義されていない）と重なるが、上で説明したように、変更をさらに含む。

図３１のステップ８）は、上で説明したように変更を伴うが、図３０の実行フェーズのステップ４、４ａに対応すると考えられる。

［さらなる変形形態］
Ｕプレーンのベアラがハンドオーバ先アクセスで必要か否かのＭＭＥによる上述の判断に対する代替的方法は、ｅＮＢがＵプレーンのベアラの必要性を検出し、判断することである。したがって、ＭＭＥは、ＩＤＬＥモードのＵＥに関するＳＭＳを受信するとき、ページング・メッセージでｅＮＢに、ページングがＳＭＳのみのためのものであることを知らせることができる。ｅＮＢは、この情報を格納し、ＵＥがＣＯＮＮＥＣＴＥＤモードに遷移するときにＵＰデータの交換の監視を開始することができる。そして、ＮＡＳ接続を介したＳＭＳの送信中に、ｅＮＢが、ＵＥからの測定に基づいて、ＵＥをＧＥＲＡＮ／ＵＴＲＡＮにハンドオーバすることを決定し、ＵＥがＣＯＮＮＥＣＴＥＤモードであるので（または代替的に所与の期間）ＵＬ／ＤＬデータ・トラフィックの交換が監視されなかったとき、ｅＮＢは、ハンドオーバ先ＲＡＴでデータ無線ベアラを確立しないと決定し、したがって、「ハンドオーバ要請」メッセージの「ハンドオーバ元−ハンドオーバ先透過コンテナ」にＳＭＳのみインジケータ（SMS-only indicator）を含める可能性がある。ＳＭＳのみインジケータに基づいて、ハンドオーバ先ＲＮＣは、一部またはすべての無線ベアラを確立せず、リソースを節約する命令にしたがう。ＲＮＣは、ＳＧＳＮにその決定について知らせ、ＳＧＳＮは、確立されなかったベアラを保存状態で維持する。

ｅＮＢによってハンドオーバがトリガされるときにＧＥＲＡＮ／ＵＴＲＡＮアクセスでのＵプレーンのベアラの確立を回避するための別の代替的方法は、ＭＭＥが、さらに上で言及されたメカニズムのうちの１つによって、Ｕプレーンが不要であることを認識している場合にハンドオーバを実行せず、ＧＥＲＡＮ／ＵＴＲＡＮへのリダイレクトの指示、およびこれがＳＭＳのみのためのものであるという任意の指示とともにＳ１−ＡＰシグナリング接続を解放することである。この場合、ｅＮＢは、ハンドオーバ先ＧＥＲＡＮ／ＵＴＲＡＮネットワークについてのさらなる情報とともにＵＥへのＲＲＣ接続を解放する。ＵＥは、ｅＮＢから与えられた情報を用いて新しいＧＥＲＡＮ／ＵＴＲＡＮセルに移動し、無線シグナリング接続のみを確立し（必要に応じて、ＲＲＣ確立理由として「シグナリング終端（Terminating Signalling）」または「高優先度シグナリング終端（Terminating High Priority Signalling）」を示し）、ルーティング・エリア更新メッセージをＳＧＳＮに送信する。ＭＭＥは、Ｓ１の解放をトリガするときには、移動手順を迅速にするために既にＳＧＳＮにＵＥコンテキスト情報を転送している可能性があり（さらに任意でＵＥのリダイレクトを示し）、すなわち、ＲＡＵがＳＧＳＮで受信されるとき、ＵＥコンテキスト情報は既に利用可能である。

上述の実施形態は、基本的に、ＭＯまたはＭＴ ＳＭＳの送信中のハンドオーバに適用可能であり、ＳＭＳ配信の対応する経路の方向の変化を考慮する。

さらに、上記の内容はもっぱらＳＭＳに関連して説明されたが、実施形態は、例えば、ＬＴＥのＮＡＳを介してシグナリング接続（Ｃプレーン）で転送される小さなＩＰデータにも適用可能であることを繰り返しておく。しかし、ＳＧＳＮが、ＵＴＲＡＮ／ＧＥＲＡＮでのＮＡＳ ＧＭＭシグナリングを介した小さなＩＰデータの転送をサポートする必要がある。したがって、概して、上述の実施形態は、Ｕプレーンのベアラが使用されないときの、任意の種類のＣプレーンの接続のためのＭＭＥからＳＧＳＮへのハンドオーバへの応用である。

１つの考慮すべき点は、ＵＥが本発明の実施形態のうちの１つによるＲＡＴ間ハンドオーバをサポートするか否かをネットワーク（すなわち、ＭＭＥ）が知っている必要があることである。したがって、ＭＭＥに対するアタッチ手順もしくはＴＡＵ手順の間、またはそれに対応して、ＳＧＳＮに対するアタッチ手順およびＲＡＵ手順の間に、ＵＥは、そのＵＥの機能で、この改良されたハンドオーバ手順のサポートを示すことができる。

以下の態様は、移動ノードと、移動ノードが本発明の上述の実施形態による改良されたハンドオーバ手順をどのように支援することができるかとに関連する。上で説明したように、データ接続がＵＴＲＡＮで確立されるべきか否かについて決定するエンティティであるＭＭＥは、さまざまな種類の情報を用いてこの決定を行う。とりわけ、ＭＭＥは、（ＵＥの観点から見て）データ接続が実際に必要か（必要となるか）否か、すなわち、ＲＡＴ間ハンドオーバ中にＵＴＲＡＮでＰＤＰコンテキストを有効化するか否かに関する移動ノードからの指示を使用することができる。ハンドオーバとは無関係に、ＵＥは、データ接続を使用する、または使用することになるか否かを知ることができる。結果として、ＵＥは、そのような指示を含むメッセージをＭＭＥに送信することができる。

例えば、ＵＥがＩＤＬＥモードであり、ＭＯ ＳＭＳが送信されるべきであるとき、ＵＥは、ＭＯ ＳＭＳがシグナリング無線ベアラのみを必要とし、データ接続は必要としないことを知っている。それに対応して、ＮＡＳサービス要求手順中に、移動ノードは、特別な「ＳＭＳ／シグナリング」指示を用いてこの事実についてＭＭＥに知らせることができる。この指示にもかかわらず、ＬＴＥにおいては、少なくともデフォルト・データ・ベアラがＥ−ＵＴＲＡＮで必須であるために、ＭＭＥがデータ・ベアラを設定する。

同様に、ＵＥは、ＭＴ ＳＭＳを受信しており、ＭＴ ＳＭＳがデバイスのトリガのためのものではなく、したがって、そのＭＴ ＳＭＳに応答して上りリンク・データ接続がユーザ・データの交換のために使用されないことを知っているとき、この事実をＭＭＥに示すことができる。上述のように、この指示は、ＭＭＥに送信される「ＳＭＳ／シグナリング」指示である可能性がある。この指示をＭＭＥに送信するための１つのあり得る方法は、ＵＥによって開始される既存のＮＡＳ ＥＭＭメッセージのうちの１つ、例えば、ＥＭＭ情報メッセージ、またはＵＥによって開始されるＥＳＭ情報手順（この手順は、ＥＳＭ情報手順が現在はネットワークによってのみ開始されるので、修正された手順である）を使用することである。

代替的に、ＵＥは、定期的に近隣のセルおよび／または技術の測定を行い、それらの測定（ＲＡＴ間の測定を含む）をネットワークに報告する。現在のＥ−ＵＴＲＡＮからの信号がハンドオーバを実行するための閾値未満であり、例えば、より強い信号強度がＧＥＲＡＮ／ＵＴＲＡＮなどの別のＲＡＴから得られると仮定すると、ＵＥは、ｅＮＢがおそらくＲＡＴ間ハンドオーバを決定する可能性があると推定することができる。したがって、ＵＥは、そのような場合、測定報告に加えて、ハンドオーバ先アクセスで「ＳＭＳ／シグナリング」のみが必要とされることに関する、ＭＭＥに宛てた対応する指示を送信する可能性がある。

本発明の上述の実施形態は、ＬＴＥからＵＴＲＡＮネットワークへの、すなわち、ＭＭＥからＳＧＳＮへのハンドオーバに関する。以下で、ＵＴＲＡＮからＬＴＥへのハンドオーバが、本発明のその他の実施形態で使用される原理を考慮してどのように改良され得るかを説明する。それに対応して、ＵＥがＰＤＰコンテキストを有効化せずに（ただし、（１つまたは複数の）これらのＰＤＰコンテキストは保存状態である可能性がある）ＵＴＲＡＮにアタッチされており、ＧＥＲＡＮおよびＵＴＲＡＮでは（ＬＴＥとは対照的に）そのような種類のアタッチが可能であると仮定する。

従来技術の現在の規格では、ＰＤＰコンテキストを有効化せずにアタッチされたＵＥに関するＧＥＲＡＮ／ＵＴＲＡＮからＬＴＥへのハンドオーバ中、ＬＴＥアクセスを介したＴＡＵ手順は拒否され、ＵＥはアタッチ手順を実行する必要がある。しかし、ＵＥがＳＧＳＮを用いた実行中のＳＭＳの送信を有する（さらに、ＰＤＰコンテキストは有効化されていない）場合、ＵＥがＧＥＲＡＮ／ＵＴＲＡＮからＥ−ＵＴＲＡＮへのハンドオーバを実行するとき、ＳＭＳの送信は失敗する。これは、ＭＴ ＳＭＳの送信が失敗すると、後で送信するためにＳＭ−ＳＣがそのＳＭＳを格納することが必要となり、ＳＭＳを格納していることを示し、ＨＳＳ／ＨＬＲの特別な「待機」フラグを有効化するためのＨＳＳ／ＨＬＲへのシグナリングを引き起こすので深刻な問題である。

この問題に対する１つの例示的な解決策が、以下で説明され、ＧＥＲＡＮ／ＵＴＲＡＮからＬＴＥへのハンドオーバ手順がシグナリング接続のためにのみ許されることに関連する。

ＭＭＥは、ＵＥのために構成されたＳＧＷおよびＰＧＷが存在しなくても、ＳＧＳＮからのハンドオーバ要求を受容することを許されるべきである。ＳＧＳＮは、（１つまたは複数の）保存状態のＰＤＰコンテキストを有する場合、（１つまたは複数の）それらのコンテキストについてＭＭＥに知らせることができ、したがって、ＭＭＥが、既に構成されているサービングＧＷおよびＰＧＷとのＳ１１接続を確立することができる。ＳＧＳＮは、ＵＥに関するＰＤＰコンテキストを持たない場合、（例えば、ＳＭＳまたは小さなＩＰデータの送信が原因の）シグナリング接続のハンドオーバと、ＳＧＳＮに格納されているＭＭ（ＧＭＭ）コンテキストとについてＭＭＥに知らせる。

したがって、ハンドオーバがシグナリング接続のためだけに完了することができ、その結果、ＳＭＳの送信が継続することができる。ＳＭＳの送信中、１）ＵＥは、デフォルトのＰＤＮ接続の確立を実行するようにネットワーク（例えば、ＭＭＥ）によって構成されるか、または２）命令されるかのどちらかである。別の言い方をすれば、ＵＥは、ハンドオーバ元のＵＴＲＡＮのＮｏｄｅＢまたはＧＥＲＡＮのＢＳＳからハンドオーバ命令を受信してＬＴＥアクセスへのハンドオーバを実行するとき、ＬＴＥアクセスである種の修正されたＴＡＵ手順を実行する。修正されたＴＡＵ手順とは、ＵＥが、一方で、ＭＭＥとのＮＡＳシグナリング接続を確立し、他方で、ＬＴＥのデフォルトのＰＤＮ接続を確立することを意味する。修正されたＴＡＵ手順を実行する一例は、ＵＥが、ＴＡＵ要求を送信した後直ちに（または短時間のうちに）「ＰＤＮ接続性要求」メッセージを送信することによってＰＤＮ接続性手順を実行することである。別のオプションは、ＴＡＵ要求メッセージに「ＰＤＮ接続性要求」メッセージを付け足すことであるが、ＴＡＵ要求メッセージが大きくなり過ぎるという問題が生じる可能性がある。ＴＡＵ要求メッセージは、迅速な送信を可能にするためにショート・メッセージとして規定されていることに留意されたい。したがって、メッセージを拡張すると、長過ぎると考えられる可能性があるほど送信時間が長くなる可能性がある。

任意で、ＭＭＥは、ハンドオーバの初めに開始されるタイマを有する可能性がある。ＵＥが、事前に定義された時間中にデフォルトのＰＤＮ接続の確立を実行しない場合、ＭＭＥは、デタッチ手順を開始する可能性がある。しかし、ＭＭＥは、ＳＭＳの送信が正常に完了するまで、デタッチ手順を待つことを考慮する可能性がある。

（シグナリング接続のハンドオーバが原因で、ＴＡＵ手順中に、またはＴＡＵ手順の後、短時間のうちにデフォルトのＰＤＮ接続を確立する）上述の実施形態は、ＵＥがＰＤＰコンテキストをまったく持たない、すなわち、ＵＥがＧＥＲＡＮ／ＵＴＲＡＮにアタッチされただけの場合に実行される可能性がある。しかし、ＵＥは、ハンドオーバ元ＧＥＲＡＮ／ＵＴＲＡＮアクセスに（有効化されていない）ＰＤＰコンテキストを有する（つまり、ＳＧＳＮも保存状態のＰＤＰコンテキストを有する）場合、（ＴＡＵ手順を実行するか、または実行しない）ハンドオーバを実行することができる。したがって、ＳＧＳＮが「フォワード再配置要求」手順中にＳＡＥシステムでデフォルトのＥＰＳベアラを確立するために必要な情報をＭＭＥに知らせるので、「ＰＤＮ接続性要求」手順を実行する必要がない。

別のあり得る解決策は、ハンドオーバ手順の間に、ＳＧＳＮからシグナリングされたデフォルトの加入ＡＰＮに基づいて、少なくともデフォルトのＰＤＮ接続がＭＭＥにより確立されることである。ＳＧＳＮは、アタッチ手順中にＨＬＲ／ＨＳＳから加入情報をダウンロードするときにデフォルトのＡＰＮを知ることができることに留意されたい。この場合、ＭＭＥが、ＳＧＳＮから「フォワード再配置要求」を受信し、ＰＤＰコンテキストは確立されていないが、デフォルトのＡＰＮはＳＧＳＮからシグナリングされるとき、ＭＭＥは、デフォルトのＡＰＮの加入コンテキストにしたがってＰＤＮ ＧＷを選択する。さらに、ＭＭＥは、サービング・ゲートウェイを選択し、それぞれのＥＰＳベアラを確立する。ｅＮＢへの「ハンドオーバ要求」と一緒に、またはｅＮＢへの「ハンドオーバ要求」の前に、ＭＭＥは、ｅＮＢでのＥＰＳベアラ・コンテキストの設定の確立をトリガする。ｅＮＢからＭＭＥへの「ハンドオーバ要求ＡＣＫ」で、ｅＮＢは、確立された無線接続についての情報をＵＥのための透過コンテナに含める。

この透過コンテナは、ｅＮＢからＭＭＥ、ＳＧＳＮ、ハンドオーバ先ＲＮＣ／ＢＳＣを介してＵＥに搬送されることに留意されたい。この解決策によれば、ＵＥは、透過コンテナによってデフォルトのＥＰＳベアラについての情報を知らされる。ＵＥがハンドオーバ先ＬＴＥアクセスに移るとき、デフォルトのＰＤＮ接続（デフォルトのＥＰＳベアラ）がｅＮＢで（すなわち、ｅＮＢとサービングＧＷとの間で）確立されている。

本発明の別の態様は、ＰＳドメインのみが使用される（すなわち、ＭＳＣサーバがＳＭＳの配信に関与しない）ことを保証しながら、ＵＥがＩＤＬＥモードであり、ＩＳＲを有効化する場合に小データをどのようにして送信すべきか、という問題に対処する。やはり、ＳＭＳによって現在実施されている小データ送信について考えるが、以下の実施形態はＳＭＳのみに限定されず、それらの実施形態の原理はその他の小データ送信（例えば、小さなＩＰパケット）に等しく適用可能である。

ＩＳＲが構成／有効化されていない（すなわち、ＵＥが、ＩＤＬＥモードである間にＲＡＴを変更するときにＳＧＳＮかまたはＭＭＥかのどちらかで常に登録を実行する）場合、ＨＳＳ／ＨＬＲは、いつでも、ＵＥがどこに登録されているかを知っており、要求されたときにＳＭＳ−ＳＣにしかるべく知らせることができるので、ＳＭＳのルーティングのためのデフォルトＳＭＳサービング・ノードを構成する必要がないことにも留意されたい。

本発明の以下の実施形態による、この問題を解決するための主たる考え方は、（コア・ネットワークの）デフォルトＳＭＳサービング・ノードが、それがＭＭＥであろうと、ＳＧＳＮであろうと、ＳＭＳの送信のために構成されるということである。デフォルトＳＭＳサービング・ノードは、（１つまたは複数の）ＭＴ ＳＭＳがＳＭＳ−ＳＣによって送信されるノードである。デフォルトＳＭＳサービング・ノードを実装することによって、ＳＭＳ−ＳＣは、ＩＳＲがＵＥに関してアクティブであるときに、ＬＴＥまたはＧＥＲＡＮ／ＵＴＲＡＮ内でＵＥが現在どこにいるかに関係なくＳＭＳを転送するべき１つの決まったノードをＨＳＳ／ＨＬＲから常に取得する。

デフォルトＳＭＳサービング・ノードは、ＭＭＥかまたはＳＧＳＮかのどちらかである。デフォルトＳＭＳサービング・ノードはＳＭＳ−ＳＣからＳＭ−ＣＰ ＰＤＵを直接受信することができなければならないので、（ＳＭ−ＣＰ／ＲＰプロトコルによる）ネイティブのＳＭＳをサポートするサービング・ノードだけがデフォルトＳＭＳサービング・ノードとして選択され得ることに留意されたい。それに対応して、（背景技術の節で定義された）ケースＡ（図２５〜２８および対応する説明も参照）では、ＭＭＥかまたはＳＧＳＮかのどちらかがデフォルトＳＭＳサービング・ノードとして選択される可能性があり、ケースＢでは、ＭＭＥだけがデフォルトＳＭＳサービング・ノードである可能性があり、ケースＣでは、ＳＧＳＮだけがデフォルトＳＭＳサービング・ノードである可能性がある。

ケースＡにおいて、ＭＭＥかまたはＳＧＳＮかのどちらかの選択は、ネットワーク事業者による決定に依存する可能性がある。デフォルトＳＭＳサービング・ノードを決定するとき、ネットワーク事業者は、ＮＡＳを介したＳＭＳ ＰＤＵの転送をサポートするサービングＣＮノードの機能を考慮に入れることができる。例えば、ＭＭＥとＳＧＳＮとの両方がネイティブのＳＭＳ送信をサポートする可能性があるが、ＭＭＥのみがＮＡＳを介したＳＭＳ ＰＤＵの転送をサポートする可能性がある。そのとき、ネットワーク事業者は、ＵＥがＬＴＥアクセス内にある場合にＳＭＳが送信され得るので、ＳＧＳＮをデフォルトＳＭＳサービング・ノードとして選択したい可能性がある。対照的に、この例においては、ＭＭＥがデフォルトＳＭＳサービング・ノードとして選択され、ＵＥがＵＴＲＡＮ／ＧＥＲＡＮアクセス内にあるとき、ＳＭＳは、ＳＧＳＮがＮＡＳを介したＳＭＳ ＰＤＵの転送をサポートしないのでＳＧＳＮを介して送信できない。

さらに、デフォルトＳＭＳサービング・ノードは、ＵＥに固有である可能性がある。例えば、一部のＵＥに関してはＳＧＳＮが、その他のＵＥに関してはＭＭＥが、コア・ネットワークのデフォルトＳＭＳサービング・ノードとして構成される。代替的に、デフォルトＳＭＳサービング・ノードの構成は、地理的地域に依存する可能性があり、例えば、ＭＭＥによってのみサービスを提供される地域内では、ＭＭＥがデフォルトＳＭＳサービング・ノードとして選択される。さらに、ＭＭＥがサービスを提供する地域とＳＧＳＮがサービスを提供する地域とが重なっている地理的地域では、ネットワーク事業者は、ＭＭＥまたはＳＧＳＮをＳＭＳ送信のためのデフォルト・サービング・ノードとして構成することを選択し得る。

そして、デフォルトＳＭＳサービング・ノードは、ネットワーク、好ましくはＨＳＳ／ＨＬＲに格納され、ＭＴ ＳＭＳが到着するときにＳＭＳ−ＳＣによって問い合わされる。

図３３は、ＳＧＳＮがデフォルトＳＭＳサービング・ノードとして定義されると想定される本発明の１つの例示的な実施形態を示す。ＵＥはＩＤＬＥ状態であると仮定する。

ステップ１）
ＩＳＲモードが有効化される。本発明の一実施形態において、ＩＳＲの有効化は、ＭＳＣサーバとＭＭＥとの間のＳＧｓ関連付けと同様のＭＭＥとＳＧＳＮとの間の関連付けを確立するために使用され得る。既に説明したように、ＩＳＲの有効化中に、ＳＧＳＮおよびＭＭＥは、互いのアドレスを知り、ＳＧＳＮとＭＭＥとの両方のＭＭコンテキストおよびＳＭコンテキストを含むＳ３関連付けを確立する。しかし、Ｓ３関連付けは、ＳＧｓに似たページングの交換およびＳＭＳ ＰＤＵの送信を可能にするように拡張される可能性がある。

特に、（１つまたは複数の）Ｓ３インターフェース・プロトコルは、ページング・メッセージを両方向に、すなわち、ＳＧＳＮからＭＭＥに（ＳＧＳＮがデフォルトＳＭＳサービング・ノードとして構成される場合）、およびＭＭＥからＳＧＳＮに（ＭＭＥがデフォルトＳＭＳサービング・ノードとして構成される場合）搬送することを可能にされるべきである。さらに、（１つまたは複数の）Ｓ３インターフェース・プロトコルは、ＳＭＳ ＰＤＵを搬送することを可能にされるべきである。非デフォルトＳＭＳサービング・ノードは、ＵＥへのＮＡＳ ＭＭシグナリング・メッセージでＳＭＳ ＰＤＵをカプセル化することができるべきである。任意で、ＳＭＳ ＰＤＵの送信に関する機能が、ＳＧＳＮとＭＭＥとの間で交換される可能性がある。例えば、非デフォルトＳＭＳサービングＣＮノードがＮＡＳ ＥＭＭ／ＧＭＭメッセージでのＳＭＳ ＰＤＵのカプセル化をサポートしない場合、ＵＥは、デフォルトＳＭＳサービング・ノードに変わるようにトリガされるべきであり、すなわち、ＵＥは、アクセス・システムを再選択し、デフォルトＳＭＳサービング・ノードにアタッチするようにトリガされる。

ステップ２）
ＳＭＳ−ＳＣが、ＭＴ−ＳＭＳを受信し、ＨＳＳ／ＨＬＲから特定のＵＥに関するＳＭＳサービング・ノードを要求する。デフォルトＳＭＳサービング・ノードとしてのＳＧＳＮを格納するＨＳＳ／ＨＬＲは、ＭＴ ＳＭＳがＨＳＳ／ＨＬＲによって特定されたＳＧＳＮに転送されるようにしかるべくＳＭＳ−ＳＣに情報を与える。

ステップ３、３ａ）
デフォルトＳＭＳサービング・ノードとしてのＳＧＳＮが、ＭＴ ＳＭＳの受信に応答してページングを開始する。特に、ステップ３、３ａにおいて、この例示的な実施形態は、もう一方の送信先アクセス、すなわち、ＭＭＥのアクセスにおけるＵＥに関するページングを開始する。したがって、ＳＧＳＮは、ページング・メッセージを生成しなければならず、そのページング・メッセージを、Ｓ３インターフェースを介し、前に設定されたＳＧｓに似た関連付けを用いてＭＭＥに送信する。そして今度は、ＭＭＥが、ＳＧＳＮから受信されたページング・メッセージを用いてそのＭＭＥのメットワークでページングを実行する。

ステップ４）
さらに、ＳＧＳＮが、登録されたルーティング・エリア（ＲＡ）においてそのＳＧＳＮ自体のＵＴＲＡＮネットワークでＵＥに関するページングを行う。

一方のステップ３、３ａと、他方のステップ４とは、交換可能であることに留意されたい。デフォルトＳＭＳサービング・ノードが、ＭＴ ＳＭＳを受信したとき、両方のネットワーク（Ｅ−ＵＴＲＡＮおよびＵＴＲＡＮ）に対してページングを開始することが有利である。

ステップ３、３ａ、および４のページングは、概して、ページングがＳＭＳに関連するという特別な指示を含むようなものである可能性がある。

図３３は、手順をさらに進める方法に関する３つの選択肢を水平な破線で区切って示している。ページング経路が、図３４の破線で示される。第１の選択肢に関しては、ＵＥがＥ−ＵＴＲＡＮ内、すなわち、ＭＭＥの下にいると想定される。したがって、ＵＥは、ＭＭＥによって送信されたページングを受信する。

ステップ５）
本発明の一実施形態によれば、ＵＥが、常に、ＵＥが現在いるＲＡＴのサービング・ノードに登録しようとする。この場合、ＵＥはＥ−ＵＴＲＡＮ内におり、したがって、ＭＭＥとのサービス要求手順を実行する。基本的に、これは、ＭＭＥにＮＡＳサービス要求メッセージを送信することを含む。

ステップ６）
ＮＡＳサービス要求メッセージを受信した後、ＭＭＥは、ＵＥが位置し、ＭＭＥにアタッチすることを、デフォルトＳＭＳサービング・ノードとしてのＳＧＳＮに知らせる。

ステップ７、７ａ）
次に、ＳＭＳ ＰＤＵが、Ｓ３インターフェースを介してＳＧＳＮからＭＭＥに転送される。そのとき、ＭＭＥは、透過ＮＡＳ ＥＭＭコンテナでカプセル化された（すなわち、ＮＡＳを介した）ＵＥへのＳＭＳ ＰＤＵを配信することができる。ネットワークのＳＭ−ＣＰ／ＲＰプロトコルはＳＧＳＮで終端され、ＭＭＥはこれらのＳＭＳ ＰＤＵをＮＡＳ ＥＭＭメッセージでカプセル化する。

図３４は、ＳＭＳが、ＭＭＥによってＵＥに配信される前にＳＧＳＮとＭＭＥとの間で交換される、この選択肢のＳＭＳの経路を例示している。

ＵＥが、現在どこにいるかに無関係にデフォルトＳＭＳサービング・ノードに登録するように強制されるような方法でページングされる代替的な実施形態を、ステップ５’および６’に関連して説明する。

ステップ５’）
したがって、ＵＥがＥ−ＵＴＲＡＮおよびＭＭＥ（デフォルトＳＭＳサービング・ノードではない）にある場合、ＭＴ ＳＭＳが配信されるべきであるという特別な指示とともにページングを受信した後、ＵＥは、ＲＡＴ間の再選択を実行し、次いで、デフォルトＳＭＳサービング・ノードとしてのＳＧＳＮに登録する。その目的のために、ＵＥは、初めに、ＳＧＳＮとのＲＡＵ／ＬＡＵ手順を実行する必要がある可能性がある。その手順の間に、ＳＧＳＮは、ＭＭＥからＵＥのコンテキスト（ＭＭコンテキストおよびＳＭコンテキスト）を取得または更新することができる。ＵＥがＬＴＥアクセスでＭＭＥに新たに登録されたので、ＭＭ／ＳＭコンテキストに対する変更が行われた可能性がある。ＳＧＳＮは、ＳＭＳの送信のみが行われるべきである場合、ＵＥに関する（１つまたは複数の）ＰＤＰコンテキストを必ずしも有効化しない。ＵＥがＭＭＥからのページングを受信するが、（サービス要求手順で）ＭＭＥに応答する代わりにＳＧＳＮとのＲＡＵ／ＬＡＵ手順を開始するケースは、従来技術とは異なることに留意されたい。

この実施形態の１つの異なる変形形態は、ＵＥが、ＳＧＳＮへの再選択を開始するために、ＭＭＥとの拡張サービス要求（ＥＳＲ）手順を開始することである。これは、ＵＥが、音声通話のためにＭＳＣにアタッチするためにＧＥＲＡＮ／ＵＴＲＡＮへの再選択を実行するようにＬＴＥアクセス内でページングされるＣＳフォールバック（ＣＳＦＢ）のシナリオに似ているが、まったく同一ではない。ここでは、ＵＥは、ＥＳＲ手順を開始して、ＳＭＳ送信のためにＳＧＳＮにアタッチするためにＧＥＲＡＮ／ＵＴＲＡＮへの再選択を行う。

ステップ６’）
次いで、ＳＭＳが、ネイティブでＳＧＳＮからＵＥに送信され得る。

本発明の代替的な実施形態が、図３３のステップ５’’および６’’によって示されている。ＵＥが、ＵＴＲＡＮ内でデフォルトＳＭＳサービング・ノードとしてのＳＧＳＮの下にあり、したがって、ＳＧＳＮからページング・メッセージを受信すると想定する（ステップ４参照）。

ステップ５’’）
ＵＥが、ページングに応答して、ＳＧＳＮとのサービス要求手順を実行し、このサービス要求手順は、ＮＡＳサービス要求メッセージを送信することを含む。

ステップ６’’）
次いで、ＳＧＳＮが、そのＳＧＳＮのネットワーク内のＵＥにＳＭＳをＳＭ−ＣＰ ＰＤＵとして直接送信することができる。ＳＧＳＮがＳＭ−ＣＰ ＰＤＵのネイティブの転送を実装し、ＳＭ−ＣＰ／ＲＰプロトコルを終端するので、ＳＧＳＮがＵＥにＭＴ ＳＭＳをＳＭ−ＣＰ ＰＤＵとして送信することが可能である。

図３５は基本的に図３３に対応しているが、ＭＭＥがデフォルトＳＭＳサービング・ノードとして構成されている。図３５のステップ１）は、図３３のステップ１）と同じである。図３５の残りのステップも、図３３に関する詳細な説明に鑑みて明白である。

ステップ２）において、ＭＴ ＳＭＳが、ＨＳＳ／ＨＬＲからデフォルトＳＭＳサービング・ノードであるＭＭＥに関する情報を得たＳＭＳ−ＳＣからＭＭＥによって受信される。それに対応して、ＭＴ ＳＭＳに応答して、ＭＭＥは、そのＭＭＥ自体のネットワークでページングを開始し（ステップ３参照）、さらにその他のネットワーク、すなわちＳＧＳＮのＵＴＲＡＮでページングを開始する（ステップ４、４ａ参照）。ＭＭＥからＳＧＳＮに送信されるページング・メッセージは、ＰＳドメインを介したＳＭＳの送信を指示する。したがって、ＳＧＳＮは、ＰＳドメイン・インジケータおよび「シグナリング終端」に設定されたページング理由とともにＧＥＲＡＮ／ＵＴＲＡＮでページング・メッセージを送信する。

ＵＥは、Ｅ−ＵＴＲＡＮ内でデフォルトＳＭＳサービング・ノードの下にある場合、ＮＡＳサービス要求メッセージをＭＭＥに送信し（ステップ５参照）、したがって、ＭＭＥが、最終的に、ＳＭ−ＣＰ ＰＤＵをＵＥに配信することができる。

ＵＥは、ＵＴＲＡＮ内にあるとき、ＮＡＳサービス要求メッセージをＳＧＳＮに送信し（ステップ５’参照）、そして今度は、ＳＧＳＮが、ＵＴＲＡＮにアタッチしているＵＥについてＭＭＥに知らせる（ステップ６’参照）。ＰＳドメインに関するページング内の指示と、場合によってはＳＭＳのみの指示（またはある種の「シグナリング接続」のみ）とによって、シグナリング接続のみがＧＥＲＡＮ／ＵＴＲＡＮで確立される。したがって、ＳＭＳはＳＭ−ＣＰ ＰＤＵとして、ＭＭＥからＳＧＳＮにシグナリング接続を介してＳ３インターフェースで転送され、ＳＧＳＮからＵＥに透過ＮＡＳ ＧＭＭコンテナでカプセル化されて転送される可能性がある（ステップ７’、７ａ’）。

代替的に、ＲＡＴ間の再選択が、図３３のステップ５’に関して既に説明したように実行され得る。

「ＳＭＳオーバーＳＧｓ」は、ＳＭＳ送信のための従来技術のメカニズムである（図２５参照）。ＵＥは、ＳＭＳオーバーＳＧｓを使用するように構成されている場合、ＧＥＲＡＮ／ＵＴＲＡＮアクセスからＳＧＳＮ／ＭＳＣへのＲＡＵ／ＬＡＵ要求メッセージに特別な指示「ＥＰＳ／ＩＭＳＩ複合アタッチ機能（combined EPS/IMSI attach capability）」を常に含める。ＵＥがＳＧＳＮとのＲＡＵ／ＬＡＵ複合（combined RAU/LAU）手順を実行する場合、ＳＧＳＮが、「ＥＰＳ／ＩＭＳＩ複合アタッチ機能」が設定されているか否かを調べる。「ＥＰＳ／ＩＭＳＩ複合アタッチ機能」が設定されている場合、ＳＧＳＮは、ＩＳＲを無効化するか（ＩＳＲが既に有効化されていた場合）、またはＲＡＵ受容メッセージでＩＳＲを示さないことによりＩＳＲを有効化しない。別の言い方をすれば、ＴＳ２３．２７２の５．５節の従来技術により、ＩＳＲは、ＵＥがＳＭＳの送信のためにＳＭＳオーバーＳＧｓを使用するように構成されている場合、有効化されない。

以下で、「ＳＭＳ ｉｎ ＭＭＥ」または「ＳＭＳオーバーＧｄインターフェース」の場合にＩＳＲが有効化され得るか否かと、どのように有効化され得るかとを検討する（図２６、図２７参照）。

「ＳＭＳオーバーＧｄインターフェース」がＳＭＳの送信のために使用されるとき、ＵＥは、ＰＳおよびＳＭＳのみでＳＧＳＮにアタッチされる。換言すれば、ＵＥは、ＣＳ／ＰＳ複合アタッチされる（combined CS/PS attached）が、ＣＳサービスはＳＭＳサービスのみである。ＩＳＲが有効化される場合、ＳＧＳＮは、ＭＭＥとの関連付けを確立するべきである。特に、ＭＴ ＳＭＳがＳＧＳＮに到着する場合、ＳＧＳＮは、ページング・メッセージをＭＭＥに転送するべきである。次いで、ＭＭＥは、「ＳＭＳオーバーＳＧｓ」メカニズムの場合と同じ方法でＵＥをページングするべきであり、ＵＥは、ＭＭＥとのサービス要求手順を実行する。ＳＧＳＮは、ＳＭＳ ＰＤＵをＭＭＥに転送し、ＭＭＥは、ＳＭＳ ＰＤＵを、ＮＡＳを介してＵＥに転送する。

したがって、ＩＳＲを有効化すべきか否かのネットワーク（ＳＧＳＮ、ＨＳＳ、ＭＭＥ）における判断は、ＭＭＥとのＥＭＭシグナリングで「ＳＭＳオーバーＮＡＳ（SMS over NAS）」をサポートするＵＥの機能に基づく。ゆえに、アタッチ／ＲＡＵ複合手順（ＧＭＭ手順）中のＳＧＳＮに対する「ＳＭＳのみ」の通常のＵＥの機能の指示に加えて、ＵＥは、ＮＡＳ ＧＭＭシグナリングでＳＧＳＮに、ＵＥがＥＭＭの「ＳＭＳオーバーＮＡＳ」に対応しているか否かも示す可能性がある。ＳＧＳＮに対するこの新しい指示は、ＩＳＲを有効化すべきか否かを判断するためにネットワークによって考慮され得る。ＳＧＳＮに対するＮＡＳ ＧＭＭの指示「ＳＭＳのみ」と、指示「ＳＭＳオーバーＮＡＳ」ＥＭＭ機能とは、独立した指示であることに留意されたい。

「ＳＭＳ ｉｎ ＭＭＥ」がＳＭＳの送信のために使用されるとき、ＵＥは、ＭＭＥにＰＳ／ＣＳ（ＥＰＳ／ＩＭＳＩとも称される）複合アタッチされる。ＩＳＲが有効化される場合、ＭＭＥは、ＳＧＳＮとの関連付けを確立するべきである。ＭＴ ＳＭＳがＭＭＥに到着する場合、ＭＭＥは、ページング・メッセージをＳＧＳＮに転送するべきである。そして、ＳＧＳＮが、ＵＴＲＡＮ／ＧＥＲＡＮアクセスでＵＥをページングするべきであり、この点で２つのオプションがあり得る。

１）ＳＭＳ ＰＤＵが、ＮＡＳ ＭＭシグナリング（例えば、透過ＮＡＳ ＧＭＭコンテナ）を介してＵＥとＳＧＳＮとの間で送信されるか、または

２）ＳＧＳＮとのサービス要求手順を実行した後、ＵＥが、「ＳＭＳ ｉｎ ＭＭＥ」メカニズムによってＳＭＳを受信するためにＭＭＥにハンドオーバするように命令される。

透過ＮＡＳ ＧＭＭコンテナでのＳＭＳ ＰＤＵの送信は、現在の規格では利用できない新しい機能であることに留意されたい。さらに、この場合にＩＳＲを有効化すべきか否かをネットワーク（主にＭＭＥ、ＨＳＳ、およびＳＧＳＮ）で判断するために、ネットワークは、ＵＥがＧＭＭシグナリングで「ＳＭＳオーバーＮＡＳ」をサポートするか否かを考慮に入れるべきである。この目的のために、ＵＥが、ＮＡＳ ＥＭＭシグナリングでＭＭＥに、ＮＡＳ ＧＭＭシグナリングが「ＳＭＳオーバーＮＡＳ」に対応していることを示すことが必要である可能性がある。アタッチ／ＴＡＵ手順中のＭＭＥに対するＮＡＳ ＥＭＭの指示「ＳＭＳのみ」と、指示「ＳＭＳオーバーＮＡＳ」ＧＭＭ機能とは、独立した指示であることに留意されたい。

要約すると、ＳＧＳＮを介したネイティブのＳＭＳ送信（ＳＭＳオーバーＧｄインターフェース）と、ＭＭＥを介したネイティブのＳＭＳ送信（ＳＭＳ ｉｎ ＭＭＥ）とが構成されているときにＩＳＲを有効化すべきか否かを判断するためには、それに対応して、ネットワークが、ＮＡＳシグナリングを介してＳＭＳ ＰＤＵを搬送するためのＧＭＭおよびＥＭＭシグナリングの機能を知っていることが重要である。ＳＧＳＮ／ＭＭＥに対するこれらのＵＥの指示は、例えば、ＵＥネットワーク機能ＩＥ（UE Network Capability IE）（主としてＬＴＥアクセスに関連するコア・ネットワーク・パラメータ用）およびＭＳネットワーク機能ＩＥ（MS Network Capability IE）（主としてＵＴＲＡＮ／ＧＥＲＡＮアクセスに関連するコア・ネットワーク・パラメータ用）で搬送される可能性がある。ＵＥネットワーク機能ＩＥおよびＭＳネットワーク機能ＩＥは、通常、アタッチ要求メッセージおよび非周期的なＴＡＵ／ＲＡＵ要求メッセージに挿入される。例えば、ＳＧＳＮへのＧＭＭシグナリングにおけるＥＭＭ機能（「ＳＭＳオーバーＮＡＳ」）の指示と、それに対応する、ＭＭＥへのＥＭＭシグナリングにおけるＧＭＭ機能（「ＳＭＳオーバーＮＡＳ」）の指示とは、ＵＥとＳＧＳＮ／ＭＭＥとの両方の新たな機能であると考えられ、すなわち、今のところ規格で定義されていない。これらの新しい指示は、異なるサービングＣＮノード（例えば、デフォルトＳＭＳサービング・ノードおよび現在登録されているサービス・ノード）の間でＳＭＳ（ＳＭＳ ＰＤＵ）を転送する方法を決定するときにも考慮され得る。したがって、これらの新たな機能は、１）ＩＳＲモードの有効化と、２）異なるサービングＣＮノードの間のＳＭＳの転送とについて判断を行うために必要とされる。

上の背景技術の節で与えられた説明は、本明細書に記載の特定の例示的な実施形態をより深く理解することを意図しており、本発明を、移動通信ネットワークのプロセスおよび機能の説明した特定の実装に限定するものと理解されるべきでない。しかしながら、本明細書で提案した改良は、背景技術の節で説明したアーキテクチャ／システムに容易に適用可能であり、本発明の一部の実施形態では、これらのアーキテクチャ／システムの規格および改良された手順を利用する可能性もある。幅広く説明した本発明の精神または範囲を逸脱することなく、特定の実施形態に示された本発明に対して多くの変更および／または修正がなされ得ることが当業者によって理解されるであろう。

本発明の別の実施形態は、ハードウェアおよびソフトウェアを用いた上述のさまざまな実施形態の実装に関する。本発明のさまざまな実施形態は、コンピューティング・デバイス（プロセッサ）を用いて実装または実行され得ることが認められる。コンピューティング・デバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブル・ロジック・デバイスなどである可能性がある。本発明のさまざまな実施形態は、これらのデバイスの組み合わせによって実行または具現化される可能性もある。

さらに、本発明のさまざまな実施形態は、プロセッサにより実行されるか、またはハードウェアで直接実行されるソフトウェア・モジュールによって実装される可能性もある。ソフトウェア・モジュールとハードウェアの実装との組み合わせも、あり得る可能性がある。ソフトウェア・モジュールは、任意の種類のコンピュータ可読ストレージ媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。

Claims (5)

1. ユーザ機器の動作を制御する集積回路であって、前記動作は、
   前記ユーザ機器が基地局を含む移動通信ネットワークに接続するように前記ユーザ機器をトリガするためのトリガ・メッセージであって、制御プレーンのみを介した前記移動通信ネットワークとの接続を確立するためのトリガ・メッセージを、移動管理エンティティから受信する処理と、
   前記トリガ・メッセージに応答して、前記移動管理エンティティとの制御プレーンの接続を確立する処理と、
   前記確立された制御プレーンの接続を用いて前記移動管理エンティティが受信した下りリンクの小データ・パケットを受信する処理と、
   前記トリガ・メッセージを受信した後に、送信部が前記制御プレーンのみを介した前記移動通信ネットワークとの接続を確立するための要求メッセージを送信した場合には、前記制御プレーンの接続の確立を開始するときに制御プレーン確立タイマを開始し、前記制御プレーンにおいて、完全性を保護され、および／または暗号化された非アクセス層（ＮＡＳ）メッセージを受信部が受信したときに前記制御プレーン確立タイマを停止する処理と、を含む、
   集積回路。
2. 前記ユーザ機器がＩＤＬＥ状態であるとき、前記動作は、前記ユーザ機器が前記移動通信ネットワークとの制御プレーンの接続のみを確立すべきであることを前記ユーザ機器に知らせるための指示を含むページング・メッセージを前記トリガ・メッセージとして受信する処理を含む、
   請求項１に記載の集積回路。
3. 前記動作は、ＲＲＣ（無線リソース制御）メッセージを使用して前記基地局から前記下りリンクの小データ・パケットを受信する処理を含む、
   請求項１または２に記載の集積回路。
4. 前記動作は、前記トリガ・メッセージの受信に応答して、前記下りリンクの小データ・パケットに応答して送信されるべき上りリンク・データの特徴を推定する処理と、
   前記移動管理エンティティが前記上りリンク・データの送信された特徴に基づいてデータ・ベアラを確立すべきか否かについて決定するように、前記上りリンク・データの推定された特徴を前記移動管理エンティティに送信する処理と、
   前記移動管理エンティティがデータ・ベアラを確立すると決定した場合に、データ・ベアラを確立する処理と、
   前記確立されたデータ・ベアラを用いて下りリンクの小データ・パケットを受信する処理と、
   前記確立されたデータ・ベアラを使用して前記上りリンク・データを送信する処理と、を含む、
   請求項１から３のいずれか一項に記載の集積回路。
5. 前記移動管理エンティティがデータ・ベアラを確立しないと決定した場合に、
   前記動作は、
   前記移動管理エンティティで受信される上りリンク・データの処理に関連する、前記移動管理エンティティからの制限パラメータを受信する処理と、
   受信された下りリンクの小データ・パケットに基づいて、送信されるべき上りリンク・データを決定する処理と、
   前記受信された制限パラメータに応じて、かつ前記決定された送信されるべき上りリンク・データに基づいて、前記上りリンク・データを送信するためにデータ・ベアラを確立すべきか否かを判断する処理と、
   データ・ベアラを確立すると決定した場合に、データ・ベアラを確立する処理と、前記確立されたデータ・ベアラを使用して前記上りリンク・データを送信する処理と、前記確立されたデータ・ベアラを使用して下りリンクの小データ・パケットを受信する処理と、を含む、
   請求項４に記載の集積回路。