JP2013526173A - Ｍｔｃデバイスの帯域幅削減 - Google Patents

Abstract

【課題】無線ネットワークにおけるマシン・タイプ・コミュニケーション・メッセージの処理を改善する。
【解決手段】無線ネットワーク内に配備するためのマシン・タイプ・デバイスは、アプリケーション層メッセージと、特定のプロトコル・スタックを使用できるものとしてマシン・タイプ・デバイスを識別する情報を含む要求を生成するように動作可能な処理回路を含む。マシン・タイプ・デバイスと基地局コントローラとの間で無線リソースがセットアップされた後、処理回路は、アプリケーション層メッセージ及びローカル無線ネットワーク別名を基地局コントローラに伝送するように更に動作可能であり、ローカル無線ネットワーク別名は、マシン・タイプ・デバイスが特定のプロトコル・スタックを使用できることを示す。
【選択図】図３

Description

本出願は、２０１０年４月２１日に出願された米国特許仮出願第６１／３２６４９５号による優先権を主張するものであり、前記出願の内容は参照により全体として本明細書に組み込まれる。

本出願は、マシン・タイプ・コミュニケーション・デバイス（machine type communication device）に関し、特に、無線ネットワークを横断するマシン・タイプ・コミュニケーション・メッセージの処理に関する。

マシンツーマシン（Machine-to-Machine）（Ｍ２Ｍ）は、人間の介入なしの通信又は人間の介入が限定されている通信を伴うものである。即ち、人は入力を提供しないが、任意選択で出力のみ提供する。「ＭＴＣ」という頭字語は、任意のタイプのマシンツーマシン通信に広く言及するために本明細書で使用する。ＭＴＣは、マシン同士が相互に直接通信できるようにし、典型的に、いくつかのタイプのコンポーネントを介して使用可能になるものである。例えば、ＭＴＣデバイスは、デバイス内に含まれるデータに関する要求に応答するか又はデバイス内に含まれるデータを自律的に伝送することができるデバイスである。通信ネットワークはＭＴＣデバイスとＭＴＣゲートウェイとの間の接続性を提供する。通信ネットワークは、例えば、ｘＤＳＬ（デジタル加入者回線）、ＬＴＥ（３ＧＰＰロング・ターム・エボリューション）、ＬＴＥ−Ａｄｖａｎｃｅｄ、ＷｉＭＡＸ（マイクロウェーブ・アクセスのための世界規模の相互運用性）、ＷＬＡＮ（無線ローカル・エリア・ネットワーク）などに基づくことができる。ＭＴＣゲートウェイは、通信ネットワークへの相互接続をＭＴＣデバイスに保証するＭＴＣ機能を使用する。ＭＴＣ通信ネットワークはＭＴＣゲートウェイとＭＴＣアプリケーションとの間の通信を提供する。ＭＴＣアプリケーションは、ＭＴＣサービスをサポートする１つ又は複数のアプリケーションによってデータが処理されるミドルウェア層を含む。ＭＴＣサービスに関するアプリケーション例は、スマート・パワー・グリッド、スマート・メータリング、消費者製品、健康管理などにおけるマシン・タイプ・コミュニケーションを含む。

ＭＴＣトラフィックは無線通信ネットワークに対して大容量を要求する。Ｒｅｌ−１０では、３ＧＰＰ（第３世代パートナーシップ・プロジェクト）は、ＭＴＣをサポートする３ＧＰＰネットワーク・システム改良に関する要件を確立している最中である。この研究の目的は、ネットワーク内の多数のＭＴＣデバイスをサポートするために必要な３ＧＰＰネットワーク機能強化を識別し、ＭＴＣ通信サービスに必要なネットワーク・イネーブラ（network enabler）を提供することである。具体的には、３ＧＰＰシステムによって提供されるようなＭＴＣ用のトランスポート・サービス及び関連の最適化、並びに、ＭＴＣデバイス、ＭＴＣサーバ、及びＭＴＣアプリケーションがネットワークの輻輳又はシステムの過負荷を引き起こさないことを保証するために必要な諸態様について検討している。しかし、現行のモバイル・ネットワークは、人間対人間の通信用に最適に設計されたままであり、従って、ＭＴＣアプリケーションにはあまり最適ではない。

例えば、ＭＴＣデバイスは、そのデバイスが接続状態になるサービス・エリア（例えば、経路指定エリア）の範囲内のＭＴＣデバイスとしてそのデバイスを明確に識別する３２ビットのＰ−ＴＭＳＩ（パケット一時移動加入者ＩＤ（packet temporary mobile subscriber identity））をサービングＳＧＳＮ（サービングＧＰＲＳサポート・ノード）がそれぞれのＭＴＣデバイスに割り当てるような、レガシーＧＰＲＳ（汎用パケット無線サービス）接続手順を条件とする。認証及びＩＭＥＩ（国際移動体装置識別番号（international mobile equipment identity））チェック手順は、レガシー手順通りに、ＧＰＲＳ接続中に必要に応じて実行される。このようなレガシー手順及びその他の手順はＭＴＣのために大量のシステム帯域幅を必要とし、それにより、人間対人間の通信に使用可能な帯域幅の量が削減される。今後数年で予想されるようにネットワークによってサービスされるＭＴＣデバイスの数が増加するにつれて、ＭＴＣ帯域幅の需要は大幅に増加する。

ＭＴＣメッセージが伝送を必要とする時に送信される制御プレーン及びユーザ・プレーン・ペイロードの総量を削減するために、ＭＴＣデバイスのために特定のプロトコル・スタック最適化が提供される。このような最適化は、典型的にレガシー・モバイル・デバイスに必要なＭＴＣデバイスとＳＧＳＮ ＮＡＳ（非アクセス階層（non-access stratum））との間の信号送出などのエンドツーエンド信号送出手順のうちのいくつかを削減するか又は除去することを含むことができる。また、プロトコル・スタックで必要なプロトコル層の数を削減することができ、従って、ＭＴＣアプリケーション層メッセージが無線インターフェースによりＭＴＣデバイスに／から伝送される時に必要な帯域幅も削減することができる。

また、ＭＴＣデバイスとＳＧＳＮとの間のパケット・データ・プロトコル（ＰＤＰ）コンテキスト活動化手順の使用も除去することができ、無線通信ネットワーク内での動作のためにＭＴＣデバイスを準備するために必要なオーバヘッドＮＡＳ信号の量が削減される。加えて、ＳＧＳＮとＭＴＣデバイスとの間のＵＤＰ／ＩＰ（ユーザ・データグラム・プロトコル／インターネット・プロトコル）データグラムのコンテキスト内でＭＴＣメッセージを搬送することを除去することができ、すべてのＭＴＣメッセージについて４６〜４８オクテットのオーバヘッドが節約される。このため、ＭＴＣデバイスは、ＵＤＰ／ＩＰを使用せずにＭＴＣメッセージの送信及び／又は受信を行うことができる。無線インターフェースにより送信される多くのＭＴＣメッセージは長さが約６０オクテット以下であり、その場合、４８オクテットのオーバヘッドの除去により大幅な帯域幅削減がもたらされる。

一実施形態により、第１のネットワーク・ノードから受信した無線リソース要求に応答して第１のネットワーク・ノードと基地局コントローラとの間の無線リソースをセットアップし、割り振られた無線リソースを使用して第１のネットワーク・ノードから基地局コントローラに非アクセス階層（ＮＡＳ）層要求を伝送し、第２のネットワーク・ノードにＮＡＳ層要求をリレーすることにより、無線ネットワーク内で非アクセス階層（ＮＡＳ）層メッセージが伝送される。特定のプロトコル・スタックを使用できるものとして第１のネットワーク・ノードを識別する情報と、第３のネットワーク・ノードのアクセス・ポイント名と、第１のネットワーク・ノード内のアプリケーションが第２のネットワーク・ノードで受信されるＮＡＳ層要求に応答して第２及び第３のネットワーク・ノードを介して通信する予定のサーバのアドレスとを使用して、特定のプロトコル・スタックに対応する動作パラメータが確立される。第２のネットワーク・ノードから第３のネットワーク・ノードにパケット・データ・プロトコル（ＰＤＰ）コンテキストベースの接続性が確立される。ＮＡＳ層要求によって提供される情報及び第３のネットワーク・ノードへのＰＤＰコンテキストベースの接続性に応答して第２のネットワーク・ノードで特定のプロトコル・スタックの使用が使用可能になる。特定のプロトコル・スタックに対応する動作パラメータが確立された後、第１のネットワーク・ノードから受信したその後の無線リソース要求に応答して第１のネットワーク・ノードと基地局コントローラとの間の無線リソースを使用して、特定のプロトコル・スタックにより、第１のネットワーク・ノードと第２のネットワーク・ノードとの間でアプリケーション層メッセージが転送される。

他の実施形態により、無線ネットワーク内で使用するための基地局コントローラは、メッセージに併せて送信されるローカル無線ネットワーク別名（local wireless network alias）に基づいて、第１のネットワーク・ノードから第２のネットワーク・ノードにアプリケーション層メッセージをリレーするように動作可能な処理回路を含む。ローカル無線ネットワーク別名は、第１のネットワーク・ノードが特定のプロトコル・スタックを使用することができ、特定の第２のネットワーク・ノードに関連付けられることを示す。

更に他の実施形態により、第１のネットワーク・ノードでＮＡＳ層メッセージを生成し、第１のネットワーク・ノードによって生成された無線リソース要求に応答して第１のネットワーク・ノードと基地局コントローラとの間の無線リソースをセットアップし、割り振られた無線リソースを使用して第１のネットワーク・ノードから第２のネットワーク・ノードに非アクセス階層（ＮＡＳ）層要求を伝達することにより、無線ネットワーク内で非アクセス階層（ＮＡＳ）層メッセージが伝送される。特定のプロトコル・スタックを使用できるものとして第１のネットワーク・ノードを識別する情報と、第１のネットワーク・ノード内のアプリケーションがＮＡＳ層要求に応答して第２のネットワーク・ノードを介して通信する予定のサーバのアドレスとを使用して、特定のプロトコル・スタックに対応する動作パラメータが確立される。特定のプロトコル・スタックに対応する動作パラメータが確立された後、アプリケーション層メッセージ及びローカル無線ネットワーク別名が基地局コントローラを介して第２のネットワーク・ノードに伝送され、ローカル無線ネットワーク別名は、第１のネットワーク・ノードが特定のプロトコル・スタックを使用できることを示す。

更に他の実施形態により、無線ネットワーク内に配備するためのマシン・タイプ・デバイス（machine type device）は、アプリケーション層メッセージと、特定のプロトコル・スタックを使用できるものとしてマシン・タイプ・デバイスを識別する情報を含む要求を生成し、マシン・タイプ・デバイスと基地局コントローラとの間で無線リソースがセットアップされた後、アプリケーション層メッセージ及びローカル無線ネットワーク別名をネットワーク・ノードに伝送するように動作可能な処理回路を含む。ローカル無線ネットワーク別名は、マシン・タイプ・デバイスが特定のプロトコル・スタックを使用できることを示す。

当業者であれば、以下の詳細な説明を読み、添付図面を見た時に、追加の特徴及び利点を認識するであろう。

図面の諸要素は必ずしも相互に対して一定の縮尺になっているわけではない。同様の参照番号は対応する同様の部分を指定する。例示された様々な実施形態の特徴は、相互に排除しない限り、組み合わせることができる。諸実施形態について図面に描写し、以下の説明で詳述する。

一実施形態によりＭＴＣデバイスにサービスする無線通信ネットワークの概略ブロック図である。 一実施形態により無線通信ネットワーク内で経路指定されたアプリケーション層メッセージに適用されるプロトコル・スタック最適化を示す図である。 一実施形態により単一無線ブロックを使用して無線通信ネットワーク内でアプリケーション層メッセージを経路指定する方法のフローチャートである。 一実施形態により無線通信ネットワーク内でアプリケーション層メッセージを経路指定する方法のフローチャートである。 他の実施形態により無線通信ネットワーク内でアプリケーション層メッセージを経路指定する方法のフローチャートである。

図１は、ユーザ装置（ＵＥ）１００及びＭＴＣデバイス１０２などの異なるタイプのデバイスにサービスするコア無線ネットワークの一実施形態を概略的に示している。特定のアプリケーションの場合、ＭＴＣデバイス１０２は、マシンツーマシン通信構成で動作するＵＥにすることができる。このため、図１内のＵＥは、現在、ＭＴＣモードで動作していないモバイル・デバイスを表すためのものである。回線交換の領域では、モバイル・サービス・センタ（ＭＳＣ）サーバ１０４が制御層の一部を形成する。ＭＳＣサーバは電話網１０６との音声通信を管理する。パケット交換の領域では、サービングＧＰＲＳサポート・ノード（ＳＧＳＮ）１０８及びゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）１１０が接続層の一部を形成し、制御機能とＩＰ接続を提供するための機能の両方を含む。ＧＧＳＮ１１０は、インターネット１１２、企業内ローカル・エリア・ネットワーク（ＬＡＮ）１１４などの１つ又は複数の外部ネットワークへのインターネットを提供する。また、コア無線ネットワークは、無線リソースを管理するための基地局コントローラ（ＢＳＣ）１１６も含む。ＢＳＣ１１６は無線ネットワークの基地局トランシーバ（ＢＳＴ）１１８を制御し、この基地局トランシーバはネットワークによってサービスされるデバイスに無線リソースを提供する。ＢＳＣ１１６は、ＧＰＲＳパケットを処理するためのパケット制御ユニット（ＰＣＵ）１２０を含む。ＰＣＵ１２０は、無線インターフェースにより無線リンク制御（ＲＬＣ）層及び媒体アクセス制御（ＭＡＣ）層を管理し、デバイスとＳＧＳＮ１０８との間のユーザ・データ・パケットの転送を管理する。

ＭＴＣデバイス１０２、ＢＳＣ１１６、ＳＧＳＮ１０８、及びＧＧＳＮ１１０は、それぞれ、本明細書に記載されている手順及びそれに対応するレガシー機能を実行するためにそれぞれの処理回路１２２、１２４、１２６、１２８を含む。それぞれの処理回路１２２、１２４、１２６、１２８は、これらの手順を実現するのに適した任意のタイプのハードウェア及び／又はソフトウェアを含むことができる。例えば、それぞれの処理回路１２２、１２４、１２６、１２８は、１つ又は複数のベースバンド・プロセッサ、マイクロプロセッサ、マイクロコンピュータ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）及びプログラム可能論理デバイスなどの特殊目的ハードウェア、コントローラ、メモリ、ファームウェア、ソフトウェア、及び／又はそれらの任意の組み合わせを含むことができる。

図２は、コア無線ネットワークの種々のコンポーネント及びネットワークによってサービスされるデバイスによって実現されるプロトコル・スタックの一実施形態を概略的に示している。ＭＴＣメッセージが伝送を必要とする時に必ず送信されるユーザ・プレーン・ペイロードの総量を削減しようとして、ＭＴＣデバイス１０２のために特定のプロトコル・スタック最適化が実現される。プロトコル・スタック最適化は、ＭＴＣアプリケーション層メッセージが無線インターフェースによりＭＴＣデバイス１０２に／から伝送される時にプロトコル・スタック内で必要な層の数の削減を含むことができる。これにより、次に、このようなＭＴＣメッセージを伝送するために必要な帯域幅が削減される。

アップリンクでは、ＭＴＣデバイス１０２は、無線ネットワーク内に位置するか又はネットワークの外部にあって、例えば、インターネット１１２、企業内ＬＡＮ１１４などに接続することができるＭＴＣサーバ１３０にアドレス指定されたメッセージを送信する。特定のＭＴＣアプリケーション層メッセージが単一無線ブロック内に十分収まる小ささである場合、複数無線ブロックを使用する代わりに、プロトコル・スタック最適化による単一ブロック・パケット・アクセス割り振りをＭＴＣメッセージ伝送に使用することができる。

図３は、ＭＴＣメッセージに関する単一ブロック・パケット・アクセスの一実施形態を示している。アプリケーション層メッセージは、ＭＴＣデバイス１０２が単一ブロック・パケット・アクセス要求をＢＳＣ１１６に送信し、ＢＳＣ１１６がＭＴＣデバイス１０２の特定のＩＤを把握せずに応答としてＭＴＣデバイス１０２に無線リソースを割り振ることにより、生成側のＭＴＣデバイス１０２からＳＧＳＮ１０８に送信される（ステップ３００）。例えば、ＢＳＣ１１６は、アプリケーション層メッセージの伝送のためにＭＴＣデバイス１０２にパケット・データ・チャネル（ＰＤＣＨ）を割り振ることができる。ＢＳＣ１１６は、単一ブロック・パケット・アクセス要求が承諾されたことを示すメッセージをＭＴＣデバイス１０２に送信する。応答として、ＭＴＣデバイス１０２は、割り振られた無線リソースを使用して、例えば、図２に示されているＵｍインターフェースにより、ＢＳＣ１１６で受信されたＭＴＣメッセージを含む単一無線ブロックを伝送する（ステップ３１０）。単一無線ブロックは、サブネットワーク依存収束プロトコル（SubNetwork Dependent Convergence Protocol））（ＳＮＤＣＰ）層と、パケット・フロー識別子（packet flow identifier）（ＰＦＩ）と、ＭＴＣデバイス１０２の特定のＩＤを示すローカル無線ネットワーク別名とに関連するＳＮ−ＰＤＵ（カプセル化ネットワーク・プロトコル・データ・ユニット（encapsulated network protocol data unit））内で搬送されるアプリケーション層メッセージを含む。一実施形態では、ローカル無線ネットワーク別名は、本明細書で後述するようにＭＴＣデバイス１０２に前に割り振られたＴＬＬＩ（一時論理リンクＩＤ（temporary logical link identity））である。次にＢＳＣ１１６は、例えば、図２に示されているＧｂインターフェースにより、ローカル無線ネットワーク別名に基づいて、ＰＦＩに関連するサービス品質（ＱｏＳ）で、ＭＴＣメッセージ、ローカル無線ネットワーク別名、及びＰＦＩをＳＧＳＮ１０８にリレーする（ステップ３２０）。

次にＳＧＳＮ１０８は、宛先ＭＴＣサーバ１３０に伝送するために、単一無線ブロックから抽出されたアプリケーション層メッセージ（ＭＴＣメッセージ）をＧＧＳＮ１１０に転送する。例えば、図２に示されているように、ＭＴＣ伝送のために最適化されたプロトコル・スタックをサポートするＭＴＣデバイスに関連するＰＦＩを認識することにより、ＳＧＳＮ１０８はＭＴＣメッセージをＧＧＳＮ１１０に転送する。一実施形態では、プロトコル・スタック最適化は、例えば、図２に示されているように、ＭＴＣデバイス１０２が無線インターフェースにより使用されるＭＴＣメッセージ・プロトコル・スタックからＵＤＰ／ＩＰヘッダを除去することを含む。これにより、ＭＴＣデバイス１０２は、約２０オクテットという比較的短いＭＴＣアプリケーション層メッセージについてＢＳＣ１１６による単一ブロック・パケット・アクセス割り振りの使用を最大限にすることができる。同じく図２に示されているように、無線インターフェースにより使用されるＭＴＣメッセージ・プロトコル・スタックからＵＤＰ／ＩＰヘッダを除去することにより、ＭＴＣデバイス１０２で実現されるプロトコル・スタックを更に最適化することができる。これらの最適化により、ＢＳＣ１１６を介してＭＴＣデバイス１０２からＳＧＳＮ１０８にアプリケーション層メッセージを送信するのに必要な帯域幅が少なくなる。

単一無線ブロックに含まれるＰＦＩがＭＴＣ伝送のために最適化されたプロトコル・スタックをサポートするＭＴＣデバイス１０２に関連付けられることを認識したことに応答して、ＭＴＣデバイス１０２に割り当てられたソースＰＤＰアドレス及びＭＴＣサーバ１３０に割り当てられた宛先ＰＤＰアドレスを使用して構築されたＵＤＰ／ＩＰデータグラム内でアプリケーション層メッセージが搬送されるように、ＳＧＳＮ１０８はＧＴＰ−Ｕプロトコル・データ・ユニット内にＭＴＣアプリケーション層メッセージをマッピングする。ＰＤＰアドレスは、例えば、ＩＰアドレスにすることができる。次にＳＧＳＮ１０８はＧＴＰ−Ｕプロトコル・データ・ユニットをＧＧＳＮ１１０に送信し、ＧＧＳＮ１１０は対応するＰＤＰアドレスに基づいて対応するＭＴＣサーバ１３０にＵＤＰ／ＩＰデータグラムを転送する。

ＭＴＣデバイスをサポートして単一ブロック・パケット・アクセス割り振りの使用を最大限にすることにより、大幅な帯域幅削減が実現される。例えば、４オクテットのヘッダを有する単一ＳＮ−ＰＤＵ／６オクテットのヘッダを有する単一ＬＬＣ（リンク層制御）ＰＤＵ内に収まるようにＭＴＣメッセージのペイロードが７オクテット以下である場合、ＭＴＣデバイス１０２は、単一ブロック・パケット・アクセスを要求するＣＨＡＮＮＥＬ ＲＥＱＵＥＳＴメッセージをＢＳＣ１１６に送信する。この場合、ネットワークは、ＭＴＣデバイス１０２がＬＬＣ ＰＤＵを搬送するＲＬＣ（無線リンク制御）データ・ブロックを送信する割り当て済みパケット・アップリンク・リソース上で単一無線ブロック期間のみ許可するので、アップリンクＴＢＦ（一時ブロック・フロー）は確立されない。アプリケーション層メッセージを搬送するＲＬＣデータ・ブロックについてＣＳ−１より大きいＧＰＲＳコード体系が許可される場合、ＭＴＣデバイス１０２は依然として、ＭＴＣメッセージ・ペイロードが７オクテットより大きい時でも単一ブロック・パケット・アクセスを要求するＣＨＡＮＮＥＬ ＲＥＱＵＥＳＴメッセージを送信することができる。例えば、ＣＳ−２コード体系が許可される場合、上記の単一ブロック・パケット・アクセス手順を使用して、長さが１７オクテットまでのＭＴＣメッセージを送信することができる。

単一ブロック・パケット・アクセスを使用できる場合には、ＭＴＣメッセージ配信をサポートして送信される信号送出ブロックの量において約６７％の節約を実現することができる。単一ブロック・パケット・アクセス信号送出により、いかなるＴＢＦ確立も行われない。このため、ＥＧＰＲＳパケット・チャネル要求（ＲＡＣＨ）＋即時割り当て（ＡＧＣＨ）＋ＭＴＣメッセージ（ＰＤＣＨ）という手順を実行することにより、ＭＴＣデバイス１０２から対応するＳＧＳＮ１０８に単一ブロック・パケット・アクセス要求が伝送される。この場合、ＭＴＣデバイスは単一ブロック・パケット・アクセスを要求し、割り当てられたＰＤＣＨを使用して、ＴＢＦ確立なしにＭＴＣメッセージを送信する。ＢＳＣ１１６は、ＭＴＣメッセージを含む無線ブロックの受信について肯定応答しない。アップリンクＭＴＣメッセージが失われる可能性があるので、この使用ケースは、例えば、ＭＴＣデバイスとＭＴＣサーバとの間の信号送出を使用してＭＴＣデバイス１０２を活動化することにより決定可能な「損失性の（lossy）」（即ち、損失耐性のある）ものであるとＭＴＣサーバ１３０によって見なされるＭＴＣの特徴に限定することができるであろう。この「損失性の」属性は、大量のＭＴＣデバイスが同じか又は同様のＭＴＣメッセージを送信することが予想される時に適切なものである可能性がある。

２フェーズ・アクセス・マルチブロック・パケット・アクセス信号方式の場合、ＥＧＰＲＳパケット・チャネル要求（ＲＡＣＨ）＋即時割り当て（ＡＧＣＨ）＋パケット・リソース要求（ＰＤＣＨ）＋パケット・アップリンク割り当て（ＰＡＣＣＨ）＋ＭＴＣメッセージ（ＰＤＣＨ）＋ＰＡＣＫＥＴ ＵＰＬＩＮＫ ＡＣＫ／ＮＡＣＫ（ＰＡＣＣＨ）＋ＰＡＣＫＥＴ ＣＯＮＴＲＯＬ ＡＣＫＮＯＷＬＥＤＧＥＭＥＮＴ（ＰＤＣＨ）という手順を実行することにより、ＭＴＣデバイス１０２から対応するＳＧＳＮ１０８にデータ・パケットが伝送される。１フェーズ・アクセス・マルチブロック・パケット・アクセス信号方式の場合、ＥＧＰＲＳパケット・チャネル要求（ＲＡＣＨ）＋即時割り当て（ＡＧＣＨ）＋ＭＴＣメッセージ（ＰＤＣＨ）＋ＰＡＣＫＥＴ ＵＰＬＩＮＫ ＡＣＫ／ＮＡＣＫ（ＰＡＣＣＨ）＋ＰＡＣＫＥＴ ＣＯＮＴＲＯＬ ＡＣＫＮＯＷＬＥＤＧＥＭＥＮＴ（ＰＤＣＨ）という手順を実行することにより、ＭＴＣデバイス１０２から対応するＳＧＳＮ１０８にデータ・パケットが伝送される。いずれの場合も、１つ又は複数の無線ブロックを使用してＭＴＣメッセージが送信された後に、アップリンクＴＢＦが確立され解放される。例えば、ＭＴＣメッセージがＭＴＣデバイス１０２から送信される場合の８０％で単一ブロック・パケット・アクセスが可能である場合、信号送出の節約は、２フェーズ・アクセスに比較して平均で約６７％＊８０％＝５４％になる。

単一ブロック・パケット・アクセス要求について上述したプロトコル最適化に加えて、ＭＴＣデバイス１０２と対応するＳＧＳＮ１０８との間のＰＤＰコンテキスト活動化を除去することにより、更に帯域幅削減を実現することができる。一般にＭＴＣデバイス１０２に関連する信号送出負荷の問題の場合、これらのタイプのデバイスに関連するパケット・データ伝送がＵＥ１００などの非ＭＴＣデバイスに提供される範囲のＱｏＳサポートを必要としないことを認識すると、これらのデバイスに関するＰＤＰコンテキスト活動化手順の除去を実現することができる。このようにするには、ＭＴＣデバイス１０２によって行われたアクセスをＢＳＣ１１６が識別することが必要であり、それにより、適用すべき対応するＱｏＳが決定され、ＧＧＳＮ１１０に関する解決策ではもはやＰＤＰアドレスをＭＴＣデバイス１０２に直接割り当てることができない。

図４は、送信側ＭＴＣデバイス１０２と対応するＳＧＳＮ１０８との間でＰＤＰコンテキストを確立せずに、無線ネットワーク内でアプリケーション層メッセージを伝送する一実施形態を示している。ＭＴＣデバイス１０２は、ＭＴＣアプリケーション層メッセージのために最適化された特定のプロトコル・スタックを使用できるものとしてデバイス１０２を識別する情報を含み、特定のプロトコル・スタックに対応する動作パラメータを確立するための要求を生成する。また、この要求は、ＧＧＳＮ１１０のアクセス・ポイント名（ＡＰＮ）と、ＭＴＣデバイス１０２内のアプリケーションがＳＧＳＮ１０８及びＧＧＳＮ１１０を介して通信する予定のＭＴＣサーバ１３０のアドレスも識別する。無線リソースに関する要求は、まず、要求を承諾すべきかどうかを判断するＢＳＣ１１６に送信される。要求が承諾される場合、ＢＳＣ１１６は、ＭＴＣデバイス１０２とＢＳＣ１１６との間の無線リソース（例えば、ＰＤＣＨ）をセットアップする（ステップ４００）。次にＭＴＣデバイス１０２は無線リソースを使用して、特定の最適化プロトコル・スタックに対応する動作パラメータを確立するための要求をＳＧＳＮ１０８に送信する（ステップ４１０）。応答として、ＳＧＳＮ１０８は、ＳＧＳＮ１０８とＧＧＳＮ１１０との間のＰＤＰコンテキストベースの接続性を確立する（ステップ４２０）。ＭＴＣデバイス１０２によって実現された特定のプロトコル・スタックの使用は、特定のプロトコル・スタックに対応する動作パラメータを確立するための要求によって提供された情報及びＧＧＳＮ１１０へのＰＤＰコンテキストベースの接続性に応答してＳＧＳＮ１０８で使用可能になる。このようにすると、ＭＴＣデバイス１０２とＳＧＳＮ１０８との間ではこの最適化プロトコル・スタックにより、また、ＳＧＳＮ１０８とＧＧＳＮ１１０との間ではＭＴＣデバイス１０２とＳＧＳＮ１０８との間でＰＤＰコンテキストを確立する必要なしに、ＭＴＣアプリケーション層メッセージを転送することができる（ステップ４３０）。

デバイス１０２をＭＴＣデバイスとして適切に識別することにより、ＭＴＣデバイス１０２とＳＧＳＮ１０８との間でＰＤＰコンテキスト活動化を除去することができる。ＭＴＣデバイス１０２がまず電源投入され、ＧＰＲＳ接続状態になろうと試みる場合、ＭＴＣデバイス１０２はいかなるＰ−ＴＭＳＩも持たず、従って、いかなるネットワーク・リソース識別子（ＮＲＩ）も持っていない。このため、以下の表１に強調表示されているように、アクセス中のデバイス１０２がＭＴＣデバイスであることを示すランダムＭＴＣ ＴＬＬＩを導入することができる。この初期ＮＡＳメッセージが特定のプロトコル・スタックに対応する動作パラメータの確立をトリガする働きをする場合、ＢＳＣ１１６は、ランダムＭＴＣ ＴＬＬＩに基づいて、ＭＴＣデバイス１０２に供応するためのデフォルトＳＧＳＮ１０８に初期ＮＡＳメッセージ（ＧＰＲＳ接続要求）を経路指定することができる。次に、ＭＴＣデバイス１０２に割り当てられたＰ−ＴＭＳＩを以下のように使用することができる。

ＭＴＣデバイス１０２がＧＰＲＳ接続状態になった後、以下の表１に強調表示されているように、対応する割り当て済みＰ−ＴＭＳＩを使用してローカルＭＴＣ ＴＬＬＩを構築することができる。ローカルＭＴＣ ＴＬＬＩの使用は、アクセス中のデバイスがＭＴＣデバイス１０２であることを示し、それにより、ＢＳＣ１１６はＭＴＣデバイス１０２に供応するためのデフォルトＳＧＳＮ１０８にその後のメッセージ（例えば、経路指定エリア更新要求）を経路指定することができる。ＭＴＣデバイス１０２及びレガシー・タイプ・デバイスが共通Ｐ−ＴＭＳＩ空間を共用できるようにするのではなく、ＭＴＣデバイス１０２に割り当て可能なＰ−ＴＭＳＩ空間を隔離することにより、デバイス管理を単純化することができる。これは、以下の表１に強調表示されているように、ローカルＭＴＣ ＴＬＬＩと同じ最上位４ビットを有するＰ−ＴＭＳＩをＭＴＣデバイス１０２に割り当てることにより、達成することができる。割り当てられたＰ−ＴＭＳＩの最下位２８ビットは、対応するＳＧＳＮ１０８によって制御された特定の地域（例えば、経路指定エリア）内で２５６百万台以下の固有のＭＴＣデバイス１０２をサポートできるようにするものである。例えば、潜在的に複数のＳＧＳＮ１０８がＭＴＣデバイス１０２に供応できるようにする必要がある場合、依然としてＭＴＣデバイス１０２に割り当てられたＰ−ＴＭＳＩのコンテキスト内でＮＲＩ概念を使用することができる。

ＭＴＣデバイス１０２に属すものとしてＰ−ＴＭＳＩをＮＲＩフィールドが識別できるようにすることも可能である。ランダムＭＴＣ ＴＬＬＩの使用により、ローカルＭＴＣ ＴＬＬＩの導入が達成され、その履歴目的のみによるＮＲＩの使用を可能にし、即ち、ＭＴＣデバイス１０２の識別にもＮＲＩを使用することはできない。現在のＰ−ＴＭＳＩが割り当てられた同じ経路指定エリア（ＲＡ）内にもはや入っていないとＭＴＣデバイス１０２が判断する場合には、デバイス１０２は、経路指定エリア更新メッセージを送信する時にランダムＭＴＣ ＴＬＬＩの使用に戻ることができる。前のデフォルトＳＧＳＮ１０８とは異なる場合に、ＭＴＣデバイス１０２に供応するための新しいデフォルトＳＧＳＮ１０８が古いＳＧＳＮ１０８を決定できるように、このメッセージは古いＰ−ＴＭＳＩを含んでいる。ランダムＭＴＣ ＴＬＬＩを使用すべき時期についてこの手法を使用すると、ＭＴＣデバイス１０２について表１内の外部ＭＴＣ ＴＬＬＩを導入することを回避することができる。

図５は、無線ネットワーク内でアプリケーション層メッセージを伝送するＭＴＣデバイス１０２の一実施形態を示している。ＭＴＣデバイス１０２はアプリケーション層メッセージを生成する（ステップ５００）。本明細書で前述したように、ＭＴＣ１０２によって生成された要求に応答してＭＴＣデバイス１０２とＢＳＣ１１６との間で無線リソースがセットアップされる（ステップ５１０）。この要求は、ＭＴＣアプリケーション層メッセージのために最適化された特定のプロトコル・スタックを使用できるものとしてＭＴＣデバイス１０２を識別する情報を含む。ＭＴＣデバイス１０２とＢＳＣ１１６との間で無線リソースがセットアップされた後、ＭＴＣデバイス１０２は、アプリケーション層メッセージと、ＭＴＣデバイス１０２に割り当てられたローカルＭＴＣ ＴＬＬＩと、ＭＴＣアプリケーション層メッセージに関連するＰＦＩを、ＢＳＣ１１６に伝送する（ステップ５２０）。ローカルＭＴＣ ＴＬＬＩは、ＭＴＣデバイス１０２がＭＴＣ伝送のために最適化されたプロトコル・スタックを使用できることをＢＳＣ１１６に対して示し、ＢＳＣ１１６はＭＴＣデバイス１０２を担当するＳＧＳＮ１０８にＭＴＣメッセージをリレーする。ＭＴＣメッセージは、ＢＳＣ１１６とＭＴＣデバイス１０２との間のＰＤＰコンテキスト確立なしに転送される。

ＭＴＣデバイス１０２がレガシーＰＤＰコンテキスト確立手順を使用しない場合、デバイス１０２はＰＤＰコンテキストの作成をトリガできない。しかし、ＭＴＣデバイス１０２からＳＧＳＮ１０８を介して特定のＭＴＣサーバ１３０に送信されるＭＴＣメッセージは適切なＡＰＮを使用して経路指定する必要があり、対応する発信元ＭＴＣデバイス１０２を示すので、ＰＤＰアドレス（例えば、ＩＰアドレス）をＭＴＣデバイス１０２に関連付け、ＧＧＳＮ１１０でＰＤＰアドレス／ＡＰＮの対を確立する必要性は依然として残っている。これは、正常なＧＰＲＳ接続後又はＭＴＣデバイス１０２に接続受諾メッセージを送信する直前のいずれかに、ＧＧＳＮ１１０に対するＰＤＰコンテキスト作成手順をＳＧＳＮ１０８がトリガすることによって達成することができる。このために、ＭＴＣデバイス１０２は、接続要求メッセージ内の新しい情報要素としてこの情報を含めることにより、ＧＰＲＳ接続手順中に好ましいＧＧＳＮ１１０（例えば、パケット・データ・ネットワーク・ゲートウェイ）のＡＰＮ及び対応するＭＴＣサーバ１３０のアドレスを（例えば、ＦＱＤＮ、即ち、完全修飾ドメイン名の形で）ＳＧＳＮ１０８に提供する。代わって、ＳＧＳＮ１０８は、接続手順中に（加入ベースの）ＨＬＲ（ホーム・ロケーション・レジスタ）１３２からこの情報を取り出すことができる。

これらの新しい情報要素を接続要求内に含めることは、例えば、接続手順中にランダムＭＴＣ ＴＬＬＩがＳＧＳＮ１０８に渡されない場合に、対応するデバイスが実際にＭＴＣデバイス１０２であることを示す働きをすることができる。次にＳＧＳＮ１０８は、ＡＰＮをＩＰアドレスに（例えば、ＤＮＳ照会を使用して）マッピングし、ＳＧＳＮとＧＧＳＮとの間のレガシー手順を使用して対応するＧＧＳＮ１１０に対してＰＤＰコンテキスト作成手順をトリガする。接続要求で提供されるか又はＨＬＲ１３２によって提供されるＭＴＣサーバ１３０のアドレスも、ＳＧＳＮ１０８によって（例えば、ＤＮＳ照会を使用して）ＩＰアドレスにマッピングすることができ、ＭＴＣメッセージがその後、ＳＧＳＮ１０８によって受信され、ＰＤＮゲートウェイ（例えば、ＧＧＳＮ１１０）を介してＭＴＣサーバ１３０に転送される時に使用することができる。

ＧＧＳＮ１１０にＰＤＰコンテキスト作成要求を送信する場合、ＳＧＳＮ１０８は、例えば、プロトコル構成オプションＩＥ（情報要素）を使用して、対応するデバイスがＭＴＣデバイス１０２であるという指示を含むことができ、それにより、ＧＧＳＮ１１０は、単一ＰＤＰコンテキストのみがそのデバイスに必要であることを認識し、それにＰＤＰアドレスを割り当てる時に（それにより、そのデバイスについてＰＤＰアドレス／ＡＰＮの対を確立する）、そのデバイスがＭＴＣデバイス１０２であることを考慮に入れることができる。ＰＤＰコンテキスト作成手順中にＧＧＳＮ１１０によって割り当てられたＰＤＰアドレスは、ＰＤＰコンテキスト作成応答として又はユーザ・ペイロード内のバンド内信号の一部としてＳＧＳＮ１０８に伝達して戻される。

ＧＧＳＮ１１０が対応するＰＤＰアドレス／ＡＰＮの対を確立した時にＭＴＣデバイス１０２のみがＭＴＣメッセージを送信することを保証するために、ＰＤＰコンテキスト作成手順の完了を条件として、ＧＰＲＳ接続手順の正常完了を行うことができるであろう。一実施形態では、ＳＧＳＮ１０８とＧＧＳＮ１１０との間でＰＤＰコンテキスト作成手順が正常に完了した時に、接続受諾メッセージがＭＴＣデバイス１０２に送信されるだけである。

接続手順及びＰＤＰコンテキスト作成手順の完了後、ＭＴＣデバイス１０２は、特定の最適化プロトコル・スタックを使用してＭＴＣメッセージを送受信することができる。ＭＴＣメッセージを送信するために、デバイス１０２は競合アクセスを実行し、本明細書で前述したように、伝送を必要とするＭＴＣメッセージのサイズ次第でＢＳＣ１１６によって単一ブロック又はマルチブロックのいずれかのパケット・アクセス割り振りが使用される。

接続手順中にＭＴＣデバイス１０２に割り当てられたＰ−ＴＭＳＩから導出されたローカルＭＴＣ ＴＬＬＩなどの下位層別名は、競合アクセスの結果としてＭＴＣメッセージとともにＭＴＣデバイス１０２からＢＳＣ１１６に伝達され、次にＭＴＣメッセージを搬送するＮ−ＰＤＵとともにＢＳＣ１１６からＳＧＳＮ１０８にリレーされる。これにより、ＳＧＳＮ１０８は、どのＭＴＣデバイス１０２がアプリケーション層メッセージを送信したかを明確に識別することができる。図２に示されているように、ＳＧＳＮ１０８は、ＵＤＰ／ＩＰプロトコル層に関するエンドポイントとして動作する。即ち、ＳＧＳＮ１０８は、接続手順中にそれが割り振ったＰ−ＴＭＳＩと、ＰＤＰコンテキスト作成手順中にＧＧＳＮ１１０によって割り当てられたＰＤＰアドレスとの間でマッピングを行うことができる。ＳＧＳＮ１０８がＢＳＣ１１６からＮ−ＰＤＵを受信すると、ＳＧＳＮ１０８は対応するＰ−ＴＭＳＩを調べ、Ｐ−ＴＭＳＩがＭＴＣデバイス１０２に関連付けられているかどうかを判断する。そうである場合、ＳＧＳＮ１０８はＰＤＰコンテキスト作成手順中にＧＧＳＮ１１０によって割り当てられた対応するソースＩＰアドレス（ＰＤＰアドレス）にＰ−ＴＭＳＩをマッピングし、対応するＭＴＣサーバ１３０のアドレス（同じくＰＤＰコンテキスト作成手順中に確立されたもの）を宛先ＩＰアドレスとして使用する。ＳＧＳＮ１０８は、ＭＴＣメッセージについて割り振られたＵＤＰポート番号及びＰＤＰコンテキスト作成手順中にＭＴＣデバイス１０２について確立されたＴＥＩＤ（トンネル・エンドポイント識別子）とともにこの情報を使用して、ＵＤＰ／ＩＰデータグラム内でＭＴＣメッセージを搬送するＧＴＰ−Ｕ ＰＤＵ（Ｎ−ＰＤＵ）を作成し、例えば、Ｇｎインターフェースにより対応するＧＧＳＮ１１０にＵＤＰ／ＩＰデータグラムを送信する。即ち、ＳＧＳＮ１０８によってＵＤＰ／ＩＰプロトコル層が挿入される。

同様に、ＳＧＳＮ１０８がＧＴＰ−Ｕ ＰＤＵを受信すると、ＳＧＳＮ１０８はＴＥＩＤ（ＧＴＰヘッダ）、宛先ＩＰアドレス（ＩＰヘッダ）、及びＵＤＰポート（ＵＤＰヘッダ）を使用して、ＧＴＰ−Ｕ ＰＤＵがＭＴＣデバイス１０２に対応するＭＴＣメッセージを搬送するかどうかを判断する。そうである場合、ＳＧＳＮ１０８はＧＴＰ−Ｕ ＰＤＵ内で搬送されたＭＴＣメッセージをＵＤＰ／ＩＰデータグラムから除去し、対応するＭＴＣデバイス１０２にそのＭＴＣメッセージをＮ−ＰＤＵとしてリレーする。即ち、ＳＧＳＮ１０８によってＵＤＰ／ＩＰプロトコル層が除去される。

デフォルトＵＤＰポートはＭＴＣメッセージの伝送に関連付けることができる。従って、ＳＧＳＮ１０８は、ＢＳＣ１１６から受信したＭＴＣメッセージ（例えば、Ｎ−ＰＤＵ）をＵＤＰ／ＩＰデータグラムにマッピングし、そのＵＤＰ／ＩＰデータグラムをＧＴＰ−Ｕ ＰＤＵ内で対応するＧＧＳＮ１１０に伝送するのに十分な情報を有する。次にＧＧＳＮ１１０は、図２に示されているように、ＧＴＰ−Ｕ ＰＤＵのペイロード（例えば、ＭＴＣメッセージ／ＵＤＰ／ＩＰデータグラム）をＭＴＣサーバ１３０にリレーする。この結果、ＭＴＣデバイス１０２とＳＧＳＮ１０８との間で送信されたすべてのＭＴＣメッセージについて、４６〜４８オクテットのオーバヘッド、即ち、ＩＰｖ６ヘッダの８オクテット（ソース・アドレス及び宛先アドレス以外のもの）、１６オクテット（ソースＩＰｖ６アドレス）、１６オクテット（宛先ＩＰｖ６アドレス）、及び６〜８オクテット（ＵＤＰヘッダ）が節約される。

ＢＳＣ１１６がこのタイプのデバイスについてアップリンク又はダウンリンクいずれかのＴＢＦを確立した時に、ＭＴＣデバイス１０２に割り振られたＰ−ＴＭＳＩによりそのデバイスをＭＴＣデバイス１０２として明確に識別できる場合、ＢＳＣ１１６は、ＭＴＣデバイス１０２について実現例固有のＯ＆Ｍ（運用及び整備）又はその他の構成済みＱｏＳ（サービス品質）管理方式を適用することができる。ＳＧＳＮ１０８は複数のＭＴＣデバイス１０２のグループについて使用可能になっている１つ又は複数のＭＴＣ特徴のセットによりＰ−ＴＭＳＩを割り当てることができるので、このようにすると潜在的にＢＳＣ１１６はＰ−ＴＭＳＩブロックベースでＱｏＳを適用することができる。換言すれば、ＢＳＣ１１６のＲＲＭ（無線リソース管理）スケジューラは、異なるＭＴＣデバイス・サブグループ（例えば、それぞれのＰ−ＴＭＳＩ値によってまとめてグループ化されたもの）がＱｏＳの観点から別個に管理されるように、ＭＴＣデバイス１０２を管理することができる。一実施形態では、Ｐ−ＴＭＳＩによって識別されたグループは、すべてのＭＴＣデバイス１０２について１つの無線優先順位（即ち、単一ＱｏＳ）を割り当てるＲＲＭスケジューラによって管理することができる。代わって、ＲＲＭスケジューラは、より細かい細分性で無線優先順位を割り当てることができ、それにより、異なる無線優先順位が異なるブロックのＰ−ＴＭＳＩ割り当てに対応することができ、例えば、Ｐ−ＴＭＳＩ割り振りにおいてＳＧＳＮ１０８によって有効に決定され、実現例固有の方法を使用してＢＳＣ１１６に伝達することができる。

ＴＢＦが確立されるアップリンクの場合、ＱｏＳ管理に関するこの手法は、それに関するリソース割り振りが必要な特定のＭＴＣデバイス１０２のＩＤをＲＲＭスケジューラが把握するように競合解決が完了することを要求する（即ち、ＴＢＦを使用してＭＴＣメッセージが送信される時に適切なＱｏＳが適用されることを保証することは、関連のＭＴＣデバイスの固有のＩＤをＲＲＭが把握していることを要求する）。例外は、本明細書で前述したように、ＭＴＣデバイス１０２が単一ブロック・パケット・アクセスを要求し（例えば、チャネル要求＝０１１１０ｘｘｘ）、割り当てられたＰＤＣＨを使用してＭＴＣメッセージを送信する（即ち、ＴＢＦは確立されていない）場合である。この場合、ＲＲＭスケジューラは要求側のＭＴＣデバイス１０２の特定のＩＤを把握せずに単一ＰＤＣＨを割り振るべきかどうかを判断しなければならないので、ＲＲＭスケジューラは単一ブロック・パケット・アクセスで構成されるアクセス要求を管理するために定義済みのＱｏＳを関連付けることができる。

「第１」、「第２」などの用語は様々な要素、領域、セクションなどを記述するために使用され、限定するためのものではない。同様の用語は説明全体を通して同様の要素を指している。

本明細書で使用する「ｈａｖｉｎｇ（有する）」、「ｃｏｎｔａｉｎｉｎｇ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含む）」、「ｃｏｍｐｒｉｓｉｎｇ（含む）」などは、所定の要素又は特徴の存在を示すが、追加の要素又は特徴を排除しない、拡張可能な用語である。「ａ」、「ａｎ」、及び「ｔｈｅ」という冠詞は、文脈が明確に他の指示をしない限り、複数形並びに単数形を含むものである。

特に他の注記がない限り、本明細書に記載された様々な実施形態の特徴は相互に組み合わせることができることを理解されたい。

特定の諸実施形態について例示し、本明細書で説明してきたが、当業者であれば、本発明の範囲を逸脱せずに、図示し説明した特定の諸実施形態の代わりに様々な代替及び／又は同等の実現例を使用できることを認識するであろう。本出願は、本明細書で考察した特定の諸実施形態のすべての適応例又は変形例を含むものである。従って、本発明は特許請求の範囲及びそれと同等のもののみによって制限されることが意図されている。

「3 ^rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications; (Release 10)」というタイトルの第３世代パートナーシップ・プロジェクト（３ＧＰＰ）テクニカル・レポート（ＴＲ）２３．８８８では、ネットワーク内の多数のＭＴＣデバイスをサポートし、ＭＴＣサービス要件を満たすためのアーキテクチャ上の強化策について研究し評価している。米国特許出願公報第ＵＳ２００２／００７５８５９号では、所与のモバイル端末に関するＱｏＳ定格を暗黙的に反映する方法で一時論理リンクＩＤ（ＴＬＬＩ）を割り当てることによりそのモバイル端末に供給するサービス品質（ＱｏＳ）について論じている。米国特許出願公報第ＵＳ２００５／０２８１２１６号では、供応される無線ネットワークのためにより多くの容量を達成するためにコア・ネットワーク（ＣＮ）エンティティのグループ化について論じている。さらに、米国特許出願公報第ＵＳ２００１／００３３５６３号では、基地局システム（ＢＳＳ）とサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）との間でより効率的かつ確実な通信を行うためにユーザ・データグラム・プロトコル（ＵＤＰ）及びインターネット・プロトコル（ＩＰ）によるデータ・パケットのカプセル化を提案している。米国特許出願公報第ＵＳ２００４／０２４６９６２号では、同じチャネル・セット上で異なるＱｏＳ遅延要件を有するいくつかのデータ・セッションを（異なるサービス・クラスについて）効率的に多重化できるように、既存のＧＰＲＳ低速アクセス手順に対する強化策が提案されている。これに対して、米国特許第６６３６４９１号では、どのようなセキュリティ問題もなく、ユーザの権利が加入によってすでに保証されているサービス要求をアクセス・ポイント（ＧＧＳＮ）が区別し受諾できるようにするために、少なくとも２つ又は３つの選択理由に基づくアクセス・ポイントの選択について論じている。
無線ネットワーク内の通信を改善しようとする上述の試みにもかかわらず、ＭＴＣトラフィックは無線通信ネットワークに対して大容量を要求する。Ｒｅｌ−１０では、３ＧＰＰ（第３世代パートナーシップ・プロジェクト）は、ＭＴＣをサポートする３ＧＰＰネットワーク・システム改良に関する要件を確立している最中である。この研究の目的は、ネットワーク内の多数のＭＴＣデバイスをサポートするために必要な３ＧＰＰネットワーク機能強化を識別し、ＭＴＣ通信サービスに必要なネットワーク・イネーブラ（network enabler）を提供することである。具体的には、３ＧＰＰシステムによって提供されるようなＭＴＣ用のトランスポート・サービス及び関連の最適化、並びに、ＭＴＣデバイス、ＭＴＣサーバ、及びＭＴＣアプリケーションがネットワークの輻輳又はシステムの過負荷を引き起こさないことを保証するために必要な諸態様について検討している。しかし、現行のモバイル・ネットワークは、人間対人間の通信用に最適に設計されたままであり、従って、ＭＴＣアプリケーションにはあまり最適ではない。

Claims (34)

1. 無線ネットワーク内でアプリケーション層メッセージを伝送する方法であって、
   第１のネットワーク・ノードから受信した無線リソース要求に応答して前記第１のネットワーク・ノードと基地局コントローラとの間の無線リソースをセットアップすることと、
   前記割り振られた無線リソースを使用して前記第１のネットワーク・ノードから前記基地局コントローラに非アクセス階層（ＮＡＳ）層要求を伝送し、第２のネットワーク・ノードに前記ＮＡＳ層要求をリレーすることと、
   特定のプロトコル・スタックを使用できるものとして前記第１のネットワーク・ノードを識別する情報と、第３のネットワーク・ノードのアクセス・ポイント名と、前記第１のネットワーク・ノード内のアプリケーションが前記第２のネットワーク・ノードで受信される前記ＮＡＳ層要求に応答して前記第２及び第３のネットワーク・ノードを介して通信する予定のサーバのアドレスとを使用して、前記特定のプロトコル・スタックに対応する動作パラメータを確立することと、
   前記第２のネットワーク・ノードから前記第３のネットワーク・ノードにパケット・データ・プロトコル（ＰＤＰ）コンテキストベースの接続性を確立することと、
   前記ＮＡＳ層要求によって提供される情報及び前記第３のネットワーク・ノードへの前記ＰＤＰコンテキストベースの接続性に応答して前記第２のネットワーク・ノードで前記特定のプロトコル・スタックの使用を使用可能にすることと、
   前記特定のプロトコル・スタックにより、前記第１のネットワーク・ノードと前記第２のネットワーク・ノードとの間でアプリケーション層メッセージを転送すること
   を含む、方法。
2. 前記無線リソース要求が、前記特定のプロトコル・スタックをサポートするものとして前記第１のネットワーク・ノードを識別するランダム・ローカル無線ネットワーク別名を含み、前記特定のプロトコル・スタックがユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外する、請求項１記載の方法。
3. 前記第２のネットワーク・ノードから前記第１のネットワーク・ノードに接続受諾メッセージを送信することを除き、前記第２のネットワーク・ノードと他のネットワーク・ノードとの間で接続関連信号送出が完了した後、前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間で前記ＰＤＰコンテキストベースの接続性が確立される、請求項１記載の方法。
4. 前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間で前記ＰＤＰコンテキストベースの接続性を確立することが、
   前記第２のネットワーク・ノードにより、前記第３のネットワーク・ノードの前記アクセス・ポイント名をＩＰアドレスにマッピングすることと、
   前記第３のネットワーク・ノードの前記アクセス・ポイント名を使用して、前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間でＰＤＰコンテキスト信号送出を実行することと、
   ＰＤＰコンテキスト信号送出中に前記第３のネットワーク・ノードによって提供されるインターネット・プロトコル（ＩＰ）ソース・アドレス情報並びに前記ＮＡＳ層要求内で前記第２のネットワーク・ノードに提供されるか又は接続関連信号送出中にホーム・ロケーション・レジスタ（ＨＬＲ）によって提供される前記サーバに対応するＩＰ宛先アドレス情報に基づいて、前記第２のネットワーク・ノードで前記特定のプロトコル・スタックの使用を使用可能にすること
   を含む、請求項１記載の方法。
5. 前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間で前記ＰＤＰコンテキストベースの接続性を確立することが、前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間でＰＤＰコンテキスト活動化手順を実現することを含み、
   前記特定のプロトコル・スタックをサポートする無線ネットワーク・ノードについてパケット・データ接続を確立する予定であることを示し、前記第２のネットワーク・ノードから前記第３のネットワーク・ノードに向けられたＰＤＰコンテキスト作成要求を送信することと、
   前記第３のネットワーク・ノードによって前記第１のネットワーク・ノードに割り当てられたＰＤＰアドレスを識別し、前記第３のネットワーク・ノードから前記第２のネットワーク・ノードでＰＤＰコンテキスト作成応答を受信すること
   を含む、請求項１記載の方法。
6. 前記第２のネットワーク・ノードと前記第３のネットワーク・ノードとの間で前記ＰＤＰコンテキスト活動化手順が完了した後、前記第２のネットワーク・ノードから前記第１のネットワーク・ノードに送信される接続関連信号送出の最終ステップが完了する、請求項５記載の方法。
7. 前記第１のネットワーク・ノードと前記第２のネットワーク・ノードとの間でアプリケーション層メッセージを転送することが、
   前記ユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外する前記特定のプロトコル・スタックの前記コンテキスト内で前記アプリケーション層メッセージを伝達することと、
   前記ＮＡＳ層要求が受信され、前記ＰＤＰコンテキストベースの接続性が確立された時に識別された前記サーバのＩＰアドレス及び前記第１のネットワーク・ノードのＩＰアドレスを使用することにより、前記第２のネットワーク・ノードで前記第１のネットワーク・ノードから受信した前記アプリケーション層メッセージを、前記ＵＤＰ層及びＩＰ層を含む異なるプロトコル・スタックにマッピングすることと、
   前記サーバの前記ＩＰアドレスに基づいて、前記第２のネットワーク・ノードで受信した前記アプリケーション層メッセージを前記第３のネットワーク・ノードを介して前記サーバに転送すること
   を含む、請求項１記載の方法。
8. 前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージを転送することが、
   前記第１のネットワーク・ノードに関するローカル無線ネットワーク別名と、前記第１のネットワーク・ノードによって生成されたアプリケーション層メッセージを搬送するネットワーク・プロトコル・データ・ユニットとを前記第２のネットワーク・ノードで受信することと、
   前記ローカル無線ネットワーク別名に基づいて前記特定のプロトコル・スタックをサポートするものとして前記第１のネットワーク・ノードを識別し、前記特定のプロトコル・スタックが前記ユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外することと、
   前記第３のネットワーク・ノードによって前記第１のネットワーク・ノードに割り当てられたソースＰＤＰアドレスと、前記サーバに関連する宛先ＰＤＰアドレスを使用して、前記ネットワーク・プロトコル・データ・ユニット内で搬送された前記アプリケーション層メッセージを、前記ＵＤＰ層及びＩＰ層が存在するＧＴＰ−Ｕプロトコル・データ・ユニットにマッピングすることと、
   前記第２のネットワーク・ノードから前記第３のネットワーク・ノードに前記ＧＴＰ−Ｕプロトコル・データ・ユニットを送信すること
   を含む、請求項１記載の方法。
9. 前記アプリケーション層メッセージを前記ＧＴＰ−Ｕプロトコル・データ・ユニットにマッピングすることが、
   前記第１のネットワーク・ノードについて前記第２のネットワーク・ノードによって前に決定されたパケット一時移動加入者ＩＤを前記ソースＰＤＰアドレスにマッピングすることと、
   前記ＮＡＳ層要求が受信された時並びに前記ＰＤＰコンテキストベースの接続性が確立された時に得られたサーバ情報に基づいて、前記パケット一時移動加入者ＩＤに対応する前記宛先ＰＤＰアドレスを識別することと、
   前記ＧＴＰ−Ｕプロトコル・データ・ユニットを生成することであって、前記アプリケーション層メッセージが前記ソース及び宛先ＰＤＰアドレスを使用して構築されたＵＤＰ／ＩＰデータグラム内で搬送されることと、
   前記ＧＴＰ−Ｕプロトコル・データ・ユニットを前記第３のネットワーク・ノードに送信すること
   を含む、請求項８記載の方法。
10. 前記第２のネットワーク・ノードから前記第１のネットワーク・ノードに前記アプリケーション層メッセージを転送することが、
    前記ＰＤＰコンテキストベースの接続性が確立された時に前記第３のネットワーク・ノードによって前記第１のネットワーク・ノードに割り当てられた前記ＧＴＰ−Ｕプロトコル・データ・ユニット内に含まれる宛先ＰＤＰアドレスに基づいて、前記第２のネットワーク・ノードで受信したＧＴＰ−Ｕプロトコル・データ・ユニットが前記第１のネットワーク・ノードに向けられたアプリケーション層メッセージを搬送すると判断することと、
    前記ＧＴＰ−Ｕプロトコル・データ・ユニット内で搬送されたＵＤＰ／ＩＰデータグラムからユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除去して、前記アプリケーション層メッセージを含むネットワーク・プロトコル・データ・ユニットを生成することと、
    前記ネットワーク・プロトコル・データ・ユニットを介して前記第１のネットワーク・ノードに前記アプリケーション層メッセージをリレーすること
    を含む、請求項１記載の方法。
11. 前記第１のネットワーク・ノードと前記第２のネットワーク・ノードとの間で前記アプリケーション層メッセージを転送することが、前記第１のネットワーク・ノードが共通のサービス品質要件を有する特定のグループの無線装置の一部であることを示す前記アプリケーション層メッセージに関連するローカル無線ネットワーク別名に基づいて前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージをリレーすることを含む、請求項１記載の方法。
12. 前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージをリレーすることが、
    接続手順中に前記第１のネットワーク・ノードに割り当てられたパケット一時移動加入者ＩＤに基づいて、前記第１のネットワーク・ノードがどのグループに関連付けられるかを識別することと、
    前記識別されたグループに割り当てられた前記サービス品質に基づいて、前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージをリレーすること
    を含む、請求項１１記載の方法。
13. 前記特定のプロトコル・スタックをサポートするすべての無線装置に同じサービス品質が割り当てられるか又はそれぞれの無線装置に明確に関連付けられたＩＤに基づいて前記特定のプロトコル・スタックをサポートする無線装置のサブセットに異なるサービス品質が割り当てられる、請求項１１記載の方法。
14. 前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージを転送することが、
    基地局コントローラが前記第１のネットワーク・ノードの前記特定のＩＤを把握せずに、前記基地局コントローラが前記第１のネットワーク・ノードから受信した単一ブロック・パケット・アクセス要求を受諾することに応答して、前記第１のネットワーク・ノードに無線リソースを割り振ることと、
    前記割り振られた無線リソースを使用して、前記第１のネットワーク・ノードによって伝送された単一無線ブロックを前記基地局コントローラで受信することであって、前記単一無線ブロックが、サブネットワーク依存収束プロトコル（ＳＮＤＣＰ）層と、パケット・フロー識別子と、前記第１のネットワーク・ノードの前記特定のＩＤを示すローカル無線ネットワーク別名とに関連するＳＮ−ＰＤＵ内で搬送される単一アプリケーション層メッセージを含むことと、
    前記ローカル無線ネットワーク別名に基づいて、前記パケット・フロー識別子に関連するサービス品質で、前記基地局コントローラから前記第２のネットワーク・ノードに前記単一アプリケーション層メッセージをリレーすること
    を含む、請求項１記載の方法。
15. 前記パケット・フロー識別子が前記特定のプロトコル・スタックをサポートする第１のネットワーク・ノードに関連付けられることを前記第２のネットワーク・ノードが認識することに応答して、前記第１のネットワーク・ノードに割り当てられたソースＰＤＰアドレスと前記サーバに割り当てられた宛先ＰＤＰアドレスを使用して構築されたＵＤＰ／ＩＰデータグラム内で前記単一アプリケーション層メッセージが搬送されるように、前記単一アプリケーション層メッセージをＧＴＰ−Ｕプロトコル・データ・ユニットにマッピングすることと、
    前記第２のネットワーク・ノードから前記第３のネットワーク・ノードに前記ＧＴＰ−Ｕプロトコル・データ・ユニットを送信すること
    により、前記第２のネットワーク・ノードが前記第３のネットワーク・ノードに前記単一アプリケーション層メッセージを転送する、請求項１４記載の方法。
16. 無線ネットワーク内で使用するためのネットワーク・ノードであって、前記ネットワーク・ノードが、
    第１のネットワーク・ノードから非アクセス階層（ＮＡＳ）層要求を受信し、前記第１のネットワーク・ノードによって基地局コントローラに送信された無線リソース要求に応答して割り振られた無線リソースを使用して前記ＮＡＳ層要求が前記第１のネットワーク・ノードから前記基地局コントローラに伝送され、前記基地局コントローラから前記ネットワーク・ノードに前記ＮＡＳ層要求を転送し、
    特定のプロトコル・スタックを使用できるものとして前記第１のネットワーク・ノードを識別する情報と、第３のネットワーク・ノードのアクセス・ポイント名と、前記第１のネットワーク・ノード内のアプリケーションが前記ＮＡＳ層要求を受信することに応答して前記ネットワーク・ノード及び前記第３のネットワーク・ノードを介して通信する予定のサーバのアドレスとを使用して、前記特定のプロトコル・スタックに対応する動作パラメータを確立し、
    前記ネットワーク・ノードから前記第３のネットワーク・ノードにパケット・データ・プロトコル（ＰＤＰ）コンテキストベースの接続性を確立し、
    前記ＮＡＳ層要求によって提供される情報及び前記第３のネットワーク・ノードへの前記ＰＤＰコンテキストベースの接続性に応答して前記ネットワーク・ノードで前記特定のプロトコル・スタックの使用を使用可能にし、
    前記第１のネットワーク・ノードによって前記基地局コントローラに送信されたその後の無線リソース要求に応答して割り振られた無線リソースを使用して、前記特定のプロトコル・スタックにより前記第１のネットワーク・ノードから受信したアプリケーション層メッセージを前記第３のネットワーク・ノードに転送する
    ように動作可能な処理回路を含む、ネットワーク・ノード。
17. 初期無線リソース要求が、前記特定のプロトコル・スタックをサポートするものとして前記第１のネットワーク・ノードを識別するランダム・ローカル無線ネットワーク別名を含み、前記特定のプロトコル・スタックがユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外する、請求項１６記載のネットワーク・ノード。
18. 前記ネットワーク・ノードから前記第２のネットワーク・ノードに接続受諾メッセージを送信することを除き、前記第２のネットワーク・ノードと前記ネットワーク・ノードとの間で接続関連信号送出が完了した後、前記ネットワーク・ノードと前記第３のネットワーク・ノードとの間で前記ＰＤＰコンテキストベースの接続性を確立するように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
19. 前記第３のネットワーク・ノードの前記アクセス・ポイント名をＩＰアドレスにマッピングし、前記第３のネットワーク・ノードの前記アクセス・ポイント名を使用して、前記ネットワーク・ノードと前記第３のネットワーク・ノードとの間でＰＤＰコンテキスト信号送出を実行し、ＰＤＰコンテキスト信号送出中に前記第３のネットワーク・ノードによって提供されるインターネット・プロトコル（ＩＰ）ソース・アドレス情報並びに前記ＮＡＳ層要求内で前記ネットワーク・ノードに提供されるか又は接続関連信号送出中にホーム・ロケーション・レジスタ（ＨＬＲ）によって提供される前記サーバに対応するＩＰ宛先アドレス情報に基づいて、前記ネットワーク・ノードで前記特定のプロトコル・スタックの使用を使用可能にするように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
20. 前記特定のプロトコル・スタックをサポートする無線ネットワーク・ノードについて前記動作パラメータを確立する予定であることを示し、前記ネットワーク・ノードから前記第３のネットワーク・ノードに向けられたＰＤＰコンテキスト作成要求を送信し、前記第３のネットワーク・ノードによって前記無線ネットワーク・ノードに割り当てられたＰＤＰアドレスを識別し、前記第３のネットワーク・ノードから前記ネットワーク・ノードでＰＤＰコンテキスト作成応答を受信するように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
21. 前記ユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外する前記特定のプロトコル・スタックの前記コンテキスト内で前記アプリケーション層メッセージを受信し、前記ＰＤＰコンテキストベースの接続性が確立された時に識別された前記サーバのＩＰアドレス及び前記第１のネットワーク・ノードのＩＰアドレスを使用することにより、前記ネットワーク・ノードで前記第１のネットワーク・ノードから受信した前記アプリケーション層メッセージを、前記ＵＤＰ層及びＩＰ層を含む異なるプロトコル・スタックにマッピングし、前記サーバの前記ＩＰアドレスに基づいて、前記ネットワーク・ノードで受信した前記アプリケーション層メッセージを前記第３のネットワーク・ノードを介して前記サーバに転送するように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
22. 前記第１のネットワーク・ノードに関するローカル無線ネットワーク別名と、前記第１のネットワーク・ノードによって生成されたアプリケーション層メッセージを搬送するネットワーク・プロトコル・データ・ユニットとを前記ネットワーク・ノードで受信し、前記ローカル無線ネットワーク別名に基づいて前記特定のプロトコル・スタックをサポートするものとして前記第１のネットワーク・ノードを識別し、前記特定のプロトコル・スタックが前記ユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除外し、前記第３のネットワーク・ノードによって前記第１のネットワーク・ノードに割り当てられたソースＰＤＰアドレスと、前記サーバに関連する宛先ＰＤＰアドレスを使用して、前記ネットワーク・プロトコル・データ・ユニット内で搬送された前記アプリケーション層メッセージを、前記ＵＤＰ層及びＩＰ層が存在するＧＴＰ−Ｕプロトコル・データ・ユニットにマッピングし、前記ネットワーク・ノードから前記第３のネットワーク・ノードに前記ＧＴＰ−Ｕプロトコル・データ・ユニットを送信するように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
23. 前記第１のネットワーク・ノードについて前記ネットワーク・ノードによって前に決定されたパケット一時移動加入者ＩＤ（Ｐ−ＴＭＳＩ）を前記ソースＰＤＰアドレスにマッピングし、前記ＮＡＳ層要求が受信された時に得られたか又は接続関連信号送出中にホーム・ロケーション・レジスタ（ＨＬＲ）によって提供されたサーバ情報に基づいて、前記Ｐ−ＴＭＳＩに対応する前記宛先ＰＤＰアドレスを識別し、前記ＧＴＰ−Ｕプロトコル・データ・ユニットを生成し、前記アプリケーション層メッセージが前記ソース及び宛先ＰＤＰアドレスを使用して構築されたＵＤＰ／ＩＰデータグラム内で搬送され、前記ＵＤＰ／ＩＰデータグラムを前記第３のネットワーク・ノードに送信するように前記処理回路が動作可能である、請求項２２記載のネットワーク・ノード。
24. 前記ＰＤＰコンテキストベースの接続性が確立された時に前記第３のネットワーク・ノードによって前記第１のネットワーク・ノードに割り当てられた前記ＧＴＰ−Ｕプロトコル・データ・ユニット内に含まれる宛先ＰＤＰアドレスに基づいて、前記ネットワーク・ノードで受信したＧＴＰ−Ｕプロトコル・データ・ユニットが前記第１のネットワーク・ノードに向けられたアプリケーション層メッセージを搬送すると判断し、前記ＧＴＰ−Ｕプロトコル・データ・ユニット内で搬送されたＵＤＰ／ＩＰデータグラムからユーザ・データグラム・プロトコル（ＵＤＰ）層及びインターネット・プロトコル（ＩＰ）層を除去して、前記アプリケーション層メッセージを含むネットワーク・プロトコル・データ・ユニットを生成し、前記ネットワーク・プロトコル・データ・ユニットを介して前記第１のネットワーク・ノードに前記アプリケーション層メッセージをリレーするように前記処理回路が動作可能である、請求項１６記載のネットワーク・ノード。
25. 無線ネットワーク内で使用するための基地局コントローラであって、前記基地局コントローラが、メッセージに併せて送信され、第１のネットワーク・ノードが特定のプロトコル・スタックを使用することができ、第２のネットワーク・ノードに関連付けられることを示すローカル無線ネットワーク別名に基づいて、前記第１のネットワーク・ノードから前記第２のネットワーク・ノードにアプリケーション層メッセージをリレーするように動作可能な処理回路を含む、基地局コントローラ。
26. 前記第１のネットワーク・ノードの特定のＩＤを把握せずに、前記第１のネットワーク・ノードから受信した単一ブロック・パケット・アクセス要求を受諾することに応答して、前記第１のネットワーク・ノードに無線リソースを割り振り、前記割り振られた無線リソースを使用して、前記第１のネットワーク・ノードによって伝送された単一無線ブロックを受信し、前記単一無線ブロックが、サブネットワーク依存収束プロトコル（ＳＮＤＣＰ）層と、パケット・フロー識別子と、前記第１のネットワーク・ノードの前記特定のＩＤを示す前記ローカル無線ネットワーク別名とに関連するＳＮ−ＰＤＵ内で搬送されるアプリケーション層メッセージを含み、前記ローカル無線ネットワーク別名に基づいて、前記パケット・フロー識別子に関連するサービス品質で、前記基地局コントローラから前記第２のネットワーク・ノードに前記単一アプリケーション層メッセージをリレーするように前記処理回路が動作可能である、請求項２５記載の基地局コントローラ。
27. 前記第１のネットワーク・ノードが共通のサービス品質要件を有する特定のグループの無線装置の一部であることを前記ローカル無線ネットワーク別名が示す、請求項２５記載の基地局コントローラ。
28. 接続手順中に前記第１のネットワーク・ノードに割り当てられたパケット一時移動加入者ＩＤに明確に対応するローカル無線ネットワーク別名に基づいて、前記第１のネットワーク・ノードがどのグループに関連付けられるかを識別し、前記識別されたグループに割り当てられた前記サービス品質に基づいて、前記第１のネットワーク・ノードから前記第２のネットワーク・ノードに前記アプリケーション層メッセージをリレーするように前記処理回路が動作可能である、請求項２７記載の基地局コントローラ。
29. 無線ネットワーク内でアプリケーション層メッセージを伝送する方法であって、
    第１のネットワーク・ノードでアプリケーション層メッセージを生成することと、
    前記第１のネットワーク・ノードによって生成された無線リソース要求に応答して前記第１のネットワーク・ノードと基地局コントローラとの間の無線リソースをセットアップすることと、
    前記割り振られた無線リソースを使用して前記第１のネットワーク・ノードから第２のネットワーク・ノードに非アクセス階層（ＮＡＳ）層要求を伝達することと、
    特定のプロトコル・スタックを使用できるものとして前記第１のネットワーク・ノードを識別する情報と、前記第１のネットワーク・ノード内のアプリケーションが前記ＮＡＳ層要求に応答して前記第２のネットワーク・ノードを介して通信する予定のサーバのアドレスとを使用して、前記特定のプロトコル・スタックに対応する動作パラメータを確立することと、
    前記特定のプロトコル・スタックに対応する動作パラメータを確立した後、前記第１のネットワーク・ノードによって前記基地局コントローラに送信されたその後の無線リソース要求に応答して割り振られた無線リソースを使用して、前記アプリケーション層メッセージ及びローカル無線ネットワーク別名を前記基地局コントローラを介して前記第２のネットワーク・ノードに伝送することであって、前記第１のネットワーク・ノードが前記特定のプロトコル・スタックを使用できることを前記ローカル無線ネットワーク別名が示すこと
    を含む、方法。
30. 前記アプリケーション層メッセージ及び前記ローカル無線ネットワーク別名を前記基地局コントローラに伝送することが、
    サブネットワーク依存収束プロトコル（ＳＮＤＣＰ）層と、パケット・フロー識別子と、前記第１のネットワーク・ノードの前記特定のＩＤを示す前記ローカル無線ネットワーク別名とに関連するＳＮ−ＰＤＵ内で搬送されるアプリケーション層メッセージを前記第１のネットワーク・ノードで生成することと、
    前記第１のネットワーク・ノードから前記基地局コントローラに単一ブロック・パケット・アクセス要求を送信することと、
    前記単一ブロック・パケット・アクセス要求が前記基地局コントローラによって承諾されることを示すメッセージを前記第１のネットワーク・ノードで受信することと、
    前記基地局コントローラにより一時ブロック・フローを確立せずに、前記単一ブロック・パケット・アクセスについて前記基地局コントローラによって割り振られた無線リソースを使用して、前記第１のネットワーク・ノードから前記基地局コントローラに前記アプリケーション層メッセージを伝送すること
    を含む、請求項２９記載の方法。
31. 前記アプリケーション層メッセージを生成することが、
    接続手順中に前記第１のネットワーク・ノードについて前記第２のネットワーク・ノードによって判断されたパケット一時移動加入者ＩＤに基づいて、前記ローカル無線ネットワーク別名を生成することと、
    前記アプリケーション層メッセージを搬送するネットワーク・プロトコル・データ・ユニットを生成すること
    を含む、請求項３０記載の方法。
32. 無線ネットワーク内に配備するためのマシン・タイプ・デバイスであって、前記マシン・タイプ・デバイスが、
    アプリケーション層メッセージと、特定のプロトコル・スタックを使用できるものとして前記マシン・タイプ・デバイスを識別する情報を含む要求を生成し、
    前記マシン・タイプ・デバイスと基地局コントローラとの間で無線リソースがセットアップされた後、前記アプリケーション層メッセージ及びローカル無線ネットワーク別名を前記基地局コントローラに伝送し、前記マシン・タイプ・デバイスが前記特定のプロトコル・スタックを使用できることを前記ローカル無線ネットワーク別名が示す
    ように動作可能な処理回路を含む、マシン・タイプ・デバイス。
33. サブネットワーク依存収束プロトコル（ＳＮＤＣＰ）層と、パケット・フロー識別子と、前記マシン・タイプ・デバイスの前記特定のＩＤを示す前記ローカル無線ネットワーク別名とに関連するＳＮ−ＰＤＵ内で搬送されるアプリケーション層メッセージを生成し、前記基地局コントローラに単一ブロック・パケット・アクセス要求を送信し、前記単一ブロック・パケット・アクセス要求が前記基地局コントローラによって承諾されることを示すメッセージを受信し、前記基地局コントローラにより一時ブロック・フローを確立せずに、前記単一ブロック・パケット・アクセスについて前記基地局コントローラによって割り振られた無線リソースを使用して、前記基地局コントローラに前記アプリケーション層メッセージを伝送するように前記処理回路が動作可能である、請求項３２記載のマシン・タイプ・デバイス。
34. 接続手順中に前記マシン・タイプ・デバイスについてネットワーク・ノードによって判断されたパケット一時移動加入者ＩＤに基づいて、前記ローカル無線ネットワーク別名を生成し、前記アプリケーション層メッセージを搬送するネットワーク・プロトコル・データ・ユニットを生成するように前記処理回路が動作可能である、請求項３３記載のマシン・タイプ・デバイス。