(57)【要約】  無線ネットワーク中のＮＡＴの後側のＭＴＣデバイスのＩＰｖ４アドレス指定のためのアドレス決定技術のフレームワークを実行するための技術、システムおよび装置が記載してある。一態様において、方法は、無線通信ネットワーク中のネットワークアドレス変換器（ＮＡＴ）の後側のマシンタイプ通信（ＭＴＣ）デバイスのアドレスを決定するステップを含む。前記決定ステップは、前記無線通信ネットワークへ取り付けられたＭＴＣデバイスへ私的アドレスを割り当てるステップと、マッピングされた公的なトランスポートアドレスを決定するステップとを含む。【選択図】図8
2014515235.tif 000002
【特許請求の範囲】
【請求項１】
無線通信ネットワーク内のネットワーク側において実行することが可能な方法であって、
マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信し、
前記外部ＩＤを含むデバイス情報リクエストを送信し、
前記デバイス情報リクエストに応答して前記ＭＴＣデバイスの第１のインターネットプロトコル（ＩＰ）アドレスを受信し、前記第１のＩＰアドレスは、前記無線ネットワークの私的アドレス空間内にあり、
前記第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手し、前記第２のＩＰアドレスは、前記トリガリクエストの送信元である第２のネットワーク中の前記第１のＩＰアドレスの変換に対応する
ことを特徴とする方法。
【請求項２】
前記第２のＩＰアドレスを入手する工程では、
前記第１のＩＰアドレスを含むアドレス変換リクエストを送信し、
アドレス変換応答メッセージ中の前記第２のＩＰアドレスを受信する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のＩＰアドレスを含むトリガ応答メッセージを提供することにより、さらに前記トリガリクエストに応答する
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記第１のＩＰアドレスおよび前記第２のＩＰアドレスは、ＩＰバージョン４（ＩＰｖ４）アドレスを含む、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＭＴＣデバイスが任意の割り当てられたＩＰアドレスを有さない場合、前記トリガリクエストが受信される、
ことを特徴とする請求項１に記載の方法。
【請求項６】
無線通信ネットワーク内のネットワーク側において動作可能な装置であって、
マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信するトリガリクエスト受信器と、
前記外部ＩＤを含むデバイス情報リクエストを送信するリクエスト送信器と、
前記ＭＴＣデバイスの第１のＩＰアドレスを前記デバイス情報に応答して受信するインターネットプロトコル（ＩＰ）アドレス受信器とを備え、前記第１のＩＰアドレスは、前記無線ネットワークの私的アドレス空間中にあり、
前記第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手するＩＰアドレス入手器を備え、前記第２のＩＰアドレスは、前記トリガリクエストの送信元である第２のネットワーク中の前記第１のＩＰアドレスの変換に対応する
ことを特徴とする装置。
【請求項７】
前記ＩＰアドレス入手器は、
前記第１のＩＰアドレスを含むアドレス変換リクエストを送信する変換リクエスト送信器と、
アドレス変換応答メッセージ中の前記第２のＩＰアドレスを受信する別のＩＰアドレス受信器とを備える、
ことを特徴とする請求項６に記載の装置。
【請求項８】
前記トリガリクエスト応答器は、前記第２のＩＰアドレスを含むトリガ応答メッセージを提供することにより前記トリガリクエストに応答するトリガリクエスト応答器を更に備える
ことを特徴とする請求項６に記載の装置。
【請求項９】
前記第１のＩＰアドレスおよび前記第２のＩＰアドレスは、ＩＰバージョン４（ＩＰｖ４）アドレスを含む、
ことを特徴とする請求項６に記載の装置。
【請求項１０】
前記ＭＴＣデバイスが任意の割り当てられたＩＰアドレスを有さない場合、前記トリガリクエストが受信される、
ことを特徴とする請求項６に記載の装置。
【請求項１１】
不揮発性のコンピュータで読み出し可能な媒体を含み、前記不揮発性のコンピュータで読み出し可能な媒体上にはコードが保存され、前記コードは、プロセッサ上において実行されると、前記プロセッサに方法を実行させるコンピュータプログラム製品であって、前記方法は、
マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信し、
前記外部ＩＤを含むデバイス情報リクエストを送信し、
前記デバイス情報リクエストに応答して、前記ＭＴＣデバイスのための第１のインターネットプロトコル（ＩＰ）アドレスを受信し、前記第１のＩＰアドレスは、前記無線ネットワークの私的アドレス空間内にあり、
前記第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手し、前記第２のＩＰアドレスは、前記トリガリクエストの送信元である第２のネットワーク中の前記第１のＩＰアドレスの変換に対応する
ことを特徴とするコンピュータプログラム製品。
【請求項１２】
前記第２のＩＰアドレスを入手する工程では、
前記第１のＩＰアドレスを含むアドレス変換リクエストを送信し、
アドレス変換応答メッセージ中の前記第２のＩＰアドレスを受信することを特徴とする請求項１１に記載のコンピュータプログラム製品。
【請求項１３】
前記方法は、
前記第２のＩＰアドレスを含むトリガ応答メッセージを提供することにより前記トリガリクエストに応答する
ことを特徴とする請求項１１に記載のコンピュータプログラム製品。
【請求項１４】
前記第１のＩＰアドレスおよび前記第２のＩＰアドレスは、ＩＰバージョン４（ＩＰｖ４）アドレスを含む
ことを特徴とする請求項１１に記載のコンピュータプログラム製品。
【請求項１５】
前記ＭＴＣデバイスが任意の割り当てられたＩＰアドレスを有さない場合、前記トリガリクエストが受信される
ことを特徴とする請求項１１に記載のコンピュータプログラム製品。
【請求項１６】
無線通信ネットワークにおいてネットワーク側において動作可能な装置であって、
マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信する手段と、
前記外部ＩＤを含むデバイス情報リクエストを送信する手段と、
前記デバイス情報リクエストに応答して、前記ＭＴＣデバイスのための第１のインターネットプロトコル（ＩＰ）アドレスを受信する手段とを備え、前記第１のＩＰアドレスは、前記無線ネットワークの私的アドレス空間中にあり、
前記第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手する手段を備え、前記第２のＩＰアドレスは、前記トリガリクエストの送信元である第２のネットワーク中の前記第１のＩＰアドレスの変換に対応する
ことを特徴とする装置。
【請求項１７】
前記第２のＩＰアドレスを入手する手段は、
前記第１のＩＰアドレスを含むアドレス変換リクエストを送信する手段と、
アドレス変換応答メッセージ中の前記第２のＩＰアドレスを受信する手段とを備える
ことを特徴とする請求項１６に記載の装置。
【請求項１８】
前記第２のＩＰアドレスを含むトリガ応答メッセージを提供することにより前記トリガリクエストに応答する手段を更に備える
ことを特徴とする請求項１６に記載の装置。
【請求項１９】
前記第１のＩＰアドレスおよび前記第２のＩＰアドレスは、ＩＰバージョン４（ＩＰｖ４）アドレスを含む
ことを特徴とする請求項１６に記載の装置。
【請求項２０】
前記ＭＴＣデバイスが任意の割り当てられたＩＰアドレスを持たない場合、前記トリガリクエストが受信される
ことを特徴とする請求項１６に記載の装置。
【請求項２１】
無線通信ネットワーク内のゲートウェイデバイスにおいて実行可能な方法であって、
前記無線通信システムに対し私的である第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行うためのリクエストを受信し、
前記ＭＴＣデバイスのための第２のＩＰアドレスを入手し、前記第２のＩＰアドレスは、前記第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間中にあって、
前記第２のＩＰアドレスを含むことにより、前記リクエストへ応答を送り、
前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへのユーザデータプレーン通信および前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティからのユーザデータプレーン通信を促進する
ことを特徴とする方法。
【請求項２２】
前記第２のＩＰアドレスを入手する動作では、
ネットワークアドレス変換（ＳＴＵＮ）サーバのためにセッショントラバースユーティリティとメッセージを交換する  ことを特徴とする請求項２１に記載の方法。
【請求項２３】
前記メッセージの交換では、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信し、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信する
ことを特徴とする請求項２２に記載の方法。
【請求項２４】
前記第２のＩＰアドレスを入手する動作では、
リレーネットワークアドレス変換（ＴＵＲＮ）サーバを用いてトラバースとメッセージを交換する
ことを特徴とする請求項２１に記載の方法。
【請求項２５】
前記メッセージの交換では、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信し、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信する
ことを特徴とする請求項２４に記載の方法。
【請求項２６】
無線通信ネットワーク内のゲートウェイデバイスにおいて動作可能な装置であって、
前記無線通信システムに対し私的である第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行うためのリクエストを受信するリクエスト受信器と、
前記ＭＴＣデバイスのための第２のＩＰアドレスを入手するＩＰアドレス入手器とを備え、前記第２のＩＰアドレスは、前記第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間中にあり、
前記第２のＩＰアドレスを含むことにより前記リクエストへ応答を送る応答送信器と、
前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへのユーザデータプレーン通信および前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティからのユーザデータプレーン通信を促進するゲートウェイとを備える
ことを特徴とする装置。
【請求項２７】
前記ＩＰアドレス入手器は、
ネットワークアドレス変換（ＳＴＵＮ）サーバのためのセッショントラバースユーティリティとメッセージを交換するメッセージ交換器を備える
ことを特徴とする請求項２６に記載の装置。
【請求項２８】
前記メッセージ交換器は、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信するバインディングリクエスト送信器と、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信するバインディング応答受信器とを備える
ことを特徴とする請求項２７に記載の方法。
【請求項２９】
前記ＩＰアドレス入手器は、
リレーネットワークアドレス変換（ＴＵＲＮ）サーバを用いてトラバースとメッセージを交換するメッセージ交換器を備える
ことを特徴とする請求項２６に記載の方法。
【請求項３０】
前記メッセージの交換に対し、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信するバインディングリクエスト送信器と、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信するバインディング応答受信器とを備える
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
不揮発性のコンピュータで読み出し可能な媒体を含み、前記不揮発性のコンピュータで読み出し可能な媒体上にはコードが保存され、前記コードは、プロセッサ上において実行されると、前記プロセッサに方法を実行させるコンピュータプログラム製品であって、前記方法は、
前記無線通信システムに対し私的である第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行うためのリクエストを受信し、
前記ＭＴＣデバイスのための第２のＩＰアドレスを入手し、前記第２のＩＰアドレスは、前記第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間中にあり、
前記第２のＩＰアドレスを含むことにより、前記リクエストへの応答を送信し、
前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへのユーザデータプレーン通信ならびに前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへからのユーザデータプレーン通信を促進する
ことを特徴とするコンピュータプログラム製品。
【請求項３２】
前記第２のＩＰアドレスを入手する動作では、
ネットワークアドレス変換（ＳＴＵＮ）サーバのためにセッショントラバースユーティリティとメッセージを交換する
ことを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３３】
前記メッセージの交換では、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信し、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信するこ
ことを特徴とする請求項３２に記載のコンピュータプログラム製品。
【請求項３４】
前記第２のＩＰアドレスを入手する動作では、
リレーネットワークアドレス変換（ＴＵＲＮ）サーバを用いてトラバースとのメッセージを交換する
ことを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３５】
前記メッセージの交換では、
前記第１のＩＰアドレスを含むアドレスバインディングリクエストを送信し、
バインディング応答メッセージ中の前記第２のＩＰアドレスを受信する
ことを特徴とする請求項３４に記載のコンピュータプログラム製品。
【請求項３６】
無線通信ネットワーク内のゲートウェイにおいて動作可能な装置であって、
前記無線通信システムに対し私的である第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行うためのリクエストを受信する手段と、
前記ＭＴＣデバイスのための第２のＩＰアドレスを入手する手段とを備え、前記第２のＩＰアドレスは、前記第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間中にあり、
前記第２のＩＰアドレスを含むことにより前記リクエストへ応答を送る手段と、
前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへのユーザデータプレーン通信および前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティからのユーザデータプレーン通信を促進する手段とを備える
ことを特徴とする装置。
【請求項３７】
前記第２のＩＰアドレスを入手する手段は、
ネットワークアドレス変換（ＳＴＵＮ）サーバのためにセッショントラバースユーティリティとメッセージを交換する手段を含む
ことを特徴とする請求項３６に記載の装置。
【請求項３８】
無線通信システムであって、
マシンタイプ通信相互作用機能（ＭＴＣ−ＩＷＦ）を備え、
該マシンタイプ通信相互作用機能は、
マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信し、
前記外部ＩＤを含むデバイス情報リクエストを送信し、
前記デバイス情報リクエストに応答して、前記ＭＴＣデバイスのための第１のインターネットプロトコル（ＩＰ）アドレスを受信し、前記第１のＩＰアドレスは、前記無線ネットワークの私的アドレス空間中にあり、
前記第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手し、前記第２のＩＰアドレスは、前記トリガリクエストの送信元である第２のネットワーク中の前記第１のＩＰアドレスの変換に対応しており、
パケットデータゲートウェイ（Ｐ−ＧＷ）を備え、
該パケットデータゲートウェイは、
前記第１のＩＰアドレスの変換を行うためのリクエストを受信し、
前記ＭＴＣデバイスのための前記第２のＩＰアドレスを生成するためのメッセージを交換し、
前記第２のＩＰアドレスを前記ＭＴＣ−ＩＷＦへ提供し、
前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへのユーザデータプレーン通信および前記第２のＩＰアドレス空間中の前記ＭＴＣデバイスおよび別の通信エンティティへからのユーザデータプレーン通信を促進する
ことを特徴とする無線通信システム。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願への相互参照
本特許明細書は、米国仮特許出願第６１／４７５，６４７号（出願日：２０１１年４月１４日）、米国仮特許出願第６１／５３５，３４３号（出願日：２０１１年９月１５日）および国際特許出願第ＰＣＴ／ＣＮ２０１１／０７３８９６（出願日：２０１１年５月１０日）の優先権の恩恵を主張する。これらの特許出願全体は、参照を用いて本明細書に組み込まれる。
【技術分野】
【０００２】
この特許明細書は、通信（例えば、マシンタイプ通信（ＭＴＣ）およびマシン間（Ｍ２Ｍ）通信）に関する。
【０００３】
多くの用途において、無線ネットワークにおいて動作する無線デバイスは、無線ネットワーク内において動作していないが通信可能である他のデバイスおよびサーバと通信する。無線デバイスに対してこのような接続性を提供するために、多様な規格が利用可能である。例えば、インターネットプロトコル（ＩＰ）はこのようなフレームワークの１つであり、無線デバイスに割り当てられたＩＰアドレスに基づいて無線デバイスが他のデバイスへ通信的に接続されることを可能にする。
【０００４】
ある種の動作状況では（例えば、マシンタイプ通信（ＭＴＣ）およびマシン間（Ｍ２Ｍ）通信無線デバイスを含むシステムの場合）、ＩＰ接続性のためのフレームワークが存在しない場合がある。
【発明の概要】
【０００５】
ＭＴＣデバイスのＩＰアドレス指定に用いるアドレス決定技術のためのフレームワークを実現するための技術、システムおよび装置について記載する。いくつかの実現様態では、ＩＰｖ４アドレスが使用されることにより、サーバがＭＴＣデバイスとの通信を除くＩＰｖ４アドレス空間よりもＮＡＴの後側にある異なるＩＰｖ４アドレス空間中でＭＴＣデバイスが動作するようになる。
【０００６】
一態様において、開示の方法は、無線通信ネットワーク内のゲートウェイデバイスにおいて実施可能であり、以下の構成を含む。つまり、無線通信システムに対して私的である第１のＩＰアドレス空間内にあるマシンタイプ通信（ＭＴＣ）の第１のインターネットプロトコル（ＩＰ）アドレスの変換実施リクエストを受信するステップ、第１のＩＰアドレス空間とは異なる第２のＩＰアドレス空間内にあり、ＭＴＣデバイスのために用いる第２のＩＰアドレスを入手するステップ、第２のＩＰアドレスを含むことによってリクエストへ応答を送信するステップ、及び第２のＩＰアドレス空間中のＭＴＣデバイスおよび別の通信エンティティの間でユーザによるデータプレーン通信を容易にするステップを含む。
【０００７】
他の態様において、開示の方法は、無線通信ネットワーク内のネットワーク側において実施可能であり、以下の構成を含む。つまり、トリガリクエストを受信することであって、受信は、マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガーリクエストを受信するステップ、外部ＩＤを含むデバイス情報リクエストを送信するステップ、無線ネットワークの私的アドレス空間にあり、ＭＴＣデバイスのために用いる第１のインターネットプロトコル（ＩＰ）アドレスを、デバイス情報リクエストに応答して受信するステップ、、及び、受信したトリガーリクエストが送信されてきた第２のネットワークにおける第１のＩＰアドレスの変換に対応する第２のＩＰアドレスを、第１のＩＰアドレスに基づいて入手するステップを含む。
【０００８】
上記および他の特徴について、以下により詳細に説明する。
【図面の簡単な説明】
【０００９】
【図１】無線通信ネットワークを示すブロック図である。
【図２】無線通信ネットワーク内において動作可能な無線デバイスのブロック図である。
【図３】ネットワークアドレス変換システムを示すブロック図である。
【図４】私的ＩＰｖ４アドレス割り当ての促進のために交換される信号を示す。
【図５】セッション確立処理手順のための信号交換図である。
【図６】ＵＥ開始通信を示す信号交換図である。
【図７】、デバイスを動作開始させるためＩＰｖ４アドレス変換の際に交換されたメッセーシを示すブロック図である。
【図８】ＭＴＣサーバの動作が開始した通信において交換されたメッセージを示す信号交換図である。
【図９】ＳＴＵＮバインディングを維持する動作の継続中に交換されるメッセージを示す。
【図１０】ＮＡＴバインディングを解放する動作時の継続中に交換されるメッセージを示す。
【図１１】ＭＴＣデバイスの開始通信に用いるトランスポートアドレス変換（選択肢１）を示すブロック図である。
【図１２】ＭＴＣデバイスの開始通信に用いるトランスポートアドレス変換（選択肢２）を示すブロック図である。
【図１３】ＳＴＵＮサーバを用いた状況におけるアドレスマッピングとデータトランスポートとを例示する。
【図１４】ＴＵＲＮリレーを用いた状況におけるアドレスマッピングとデータトランスポートとを例示する。
【図１５】無線通信ネットワーク内のネットワーク側において実行することが可能な処理を示すフローチャートである。
【図１６】無線通信を促進するのための装置を示すブロック図である。
【図１７】無線通信システム内のゲートウェイデバイスにおいて実行することが可能な処理を示すフローチャートである。
【図１８】無線通信ネットワーク内において動作可能なゲートウェイデバイスの一部を示すブロック図である。
【発明を実施するための形態】
【００１０】
この特許明細書において開示される技術、デバイスおよびシステムをいくつかの実施形態において用いて、無線通信ネットワーク内のマシンタイプ通信（ＭＴＣ）デバイスのアドレスを決定することができる。いくつかの構成において、この開示の技術を用いることで、無線通信ネットワーク内のネットワーク側にあるハードウェアプラットフォームにおいて実行可能な既存の相互作用機能の機能を向上させることができる。いくつかの構成において、開示の技術を用いることで、無線通信ネットワーク内にあるゲートウェイデバイス（例えば、パケットゲートウェイデバイスＰ−ＧＷ）の機能を向上させることができる。
【００１１】
図１は、無線通信システムの一例を示す。無線通信システムは、１つ以上のベースステーション（ＢＳ）１０５ａおよび１０５ｂと、１つ以上の無線デバイス１１０と、アクセスネットワーク１２５とを含み得る。ベースステーション１０５ａおよび１０５ｂは、１つ以上の無線セクター内の無線デバイス１１０へ無線サービスを提供することができる。いくつかの実施形態において、ベースステーション（例えば、１０５ａまたは１０５ｂ）は、指向性アンテナを含む。これらの指向性アンテナは、２つ以上の指向性ビームを生成して、異なるセクター内を無線でカバーする。
【００１２】
アクセスネットワーク１２５は、１つ以上のベースステーション１０５ａおよび１０５ｂと通信することができる。いくつかの実施形態において、アクセスネットワーク１２５は、１つ以上のベースステーション１０５ａおよび１０５ｂを含む。いくつかの実施形態において、アクセスネットワーク１２５は、コアネットワーク（図１中図示せず）と通信する。このコアネットワークは、他の無線通信システムおよび有線通信システムとの接続性を提供できる。コアネットワークは、加入無線デバイス１１０に関する情報を保存するため、１つ以上のサービス加入データベースを含み得る。第１のベースステーション１０５ａは、第１の無線アクセス技術に基づいて無線サービスを提供することができ、第２のベースステーション１０５ａは、第２の無線アクセス技術に基づいて無線サービスを提供することができる。ベースステーション１０５ａは共に配置してもよいし、あるいは、展開シナリオに従ってフィールド内に別個に取り付けてもよい。アクセスネットワーク１２５は、複数の異なる無線アクセス技術をサポートできる。
【００１３】
本技術およびシステムを実行することが可能な無線通信システムおよびアクセスネットワークの多様な例を挙げると、例えば、符号分割多元接続（ＣＤＭＡ）（例えば、ＣＤＭＡ２０００１ｘ、高レートパケットデータ（ＨＲＰＤ）、高度ＨＲＰＤ（ｅＨＲＰＤ）、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）、高度ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）、ロングタームエボリューション（ＬＴＥ））に基づいた無線通信システムが含まれる。いくつかの実施形態において、無線通信システムには、異なる無線技術を用いた複数のネットワークが含まれる。デュアルモードまたはマルチモード無線デバイスは、異なる無線ネットワークへの接続に利用することが可能な２つ以上の無線技術を含む。いくつかの実施形態において、無線デバイスは、同時音声データ動作（ＳＶ−ＤＯ）をサポートすることができる。ＣＤＭＡ２００システムの場合、コアネットワーク１２５は、例えば、モバイルスイッチングセンター（ＭＳＣ）、パケットデータサービングノード（ＰＤＳＮ）などを含み得る。
【００１４】
図２は、無線ステーション２０５の一部を示すブロック図である。無線ステーション２０５（例えば、ベースステーションまたは無線デバイス）は、プロセッサ電子機器２１０（例えば、マイクロプロセッサ）を含み得る。プロセッサ電子機器２１０は、本明細書中に提示される無線通信技術のうち１つ以上を実現する。無線ステーション２０５は、トランシーバー電子機器２１５を含み、１つ以上の通信インターフェース（例えば、アンテナ２２０）を介して無線信号を受信および／または送信する。無線ステーション２０５は、データの送信および受信のための他の通信インターフェースを含み得る。無線ステーション２０５は、情報（例えば、データおよび／または命令）を保存するように構成された１つ以上のメモリを含み得る。いくつかの実施形態において、プロセッサ電子機器２１０は、トランシーバー電子機器２１５のうち少なくとも一部を含み得る。
【００１５】
いくつかの実施形態において、無線ステーション２０５は、ＣＤＭＡエアインターフェースに基づいて相互に通信し得る。いくつかの実施形態において、無線ステーション２０５は、直交周波数分割多重方式（ＯＦＤＭ）エアインターフェースに基づいて相互に通信し得る。直交周波数分割多重方式（ＯＦＤＭ）エアインターフェースは、直交周波数分割複数アクセス（ＯＦＤＭＡ）エアインターフェースを含み得る。いくつかの実施形態において、無線ステーション２０５は、１つ以上の無線技術（例えば、ＣＤＭＡ（例えば、ＣＤＭＡ２０００１ｘ）、ＨＲＰＤ、ＷｉＭＡＸ、ＬＴＥ、およびユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ））を用いて通信し得る。
【００１６】
本明細書中に記載される技術、デバイスおよびシステムを用いて、例えば、無線ネットワーク内のＮＡＴの後側にあるＭＴＣデバイスのＩＰｖ４アドレス指定のために用いるユニラテラルセルフアドレス固定（ＵＮＳＡＦ）のフレームワークを提供できる。加えて、本明細書中に記載される技術、デバイスおよびシステムを用いることにより、例えば、ＭＴＣデバイスおよび／またはＭＴＣサーバは、１つ以上のネットワークアドレス変換器（ＮＡＴ）の後側において展開されたＭＴＣデバイスの公的なルートを指定可能なアドレスを決定できる。
【００１７】
以下の記載において、セクション表題は、ひとえに開示の発明の理解を促進する目的のために用いたものであり、特許請求の範囲に記載の発明をいかようにも限定しない。
【００１８】
無線ネットワーク内ＮＡＴの後側にあるＭＴＣデバイスのＩＰｖ４アドレス指定のためのＵＮＳＡＦフレームワーク
１つ以上のＮＡＴによって分離される通信エンドポイントは一般的に、それらのピアのアドレス指定体系において有効なアドレスを用いて自身を参照する方法知らない。多数の目的のため、これらのエンドポイントは、それらのピアへに対する通知に用いられるアドレス（および／またはポート）を知る必要がある。
【００１９】
この問題は、ユニラテラルセルフアドレス固定（ＵＮＳＡＦ）として知られていることがある。ＲＦＣ３４２４に記載してあるように、ＵＮＳＡＦは、ＮＡＴの後側のエンティティが（ＮＡＴの外部の）「公的な」ドメイン内への通知へ用いられるアドレス（およびポート）を決定または固定することを試行するプロセスである。その後、この「公的な」アドレスは、ＮＡＴの後側のエンティティのアドレス指定のためのプロトコル交換において使用される。または、ＮＡＴの後側のエンティティが通信を受信できる「公的な」アドレスとして公示され得る。
【００２０】
ＵＮＳＡＦの場合、２つの場合を検討する必要がある。第１の場合、ＮＡＴの後側のエンティティが通信を開始する。第２の場合、ＮＡＴの外側のエンティティが通信を開始する必要がある。
【００２１】
２．無線ネットワークのためのＵＮＳＡＦ
公的なＩＰｖ４アドレスの利用可能性は制限されているため、ＭＴＣデバイス（単数または複数）は、ＮＡＴ（単数または複数）の後側において展開され、私的のルート指定不可能なＩＰｖ４アドレスが割り当てられる（そのため、ＭＴＣサーバ（単数または複数）が到達することができない）。ＭＴＣアプリケーションの本質に応じて、ＭＴＣデバイスまたはＭＴＣサーバが通信開始に必要である。いくつかの適用例において、ＮＡＴの後側のＭＴＣデバイスは、ピア―エンティティ間通信を開始する前に、公的にルート指定可能なトランスポートアドレスを知る必要がある。無線ネットワーク外部からの通信（例えば、デバイスの動作開始のためにＭＴＣサーバからの通信）を開始するためには、外部エンティティがＭＴＣデバイスの公的にルート指定可能なトランスポートアドレスを知る必要がある。
【００２２】
明細書において用いられる「トランスポートアドレス」という用語は、ＩＰアドレスおよびポート番号（例えば、ＵＤＰまたはＴＣＰポート番号）の組み合わせであり、ＩＰアドレスおよび関連付けられたポート番号双方に対する解明がアドレス解明に必要となり得る。
【００２３】
ＭＴＣ通信についてのこのような要求により、無線ネットワークのためのＮＡＴ後側にあるＭＴＣデバイスのＩＰｖ４アドレス指定に用いるアドレス決定技術が有用となる。このようなアドレス決定技術は、以下の２つのシナリオをサポートし得る：
１．ＭＴＣデバイスがＮＡＴの後側にあり、ＭＴＣデバイスまたはクライアントが通信を開始する。
２．ＮＡＴの外部にあるＭＴＣサーバおよびサーバが（例えば、デバイスの動作を開始するために）通信を開始する必要がある。
【００２４】
本明細書において記載されるアドレス決定技術の例示的フレームワークは、３ＧＰＰネットワーク内にあるＮＡＴの後側のＭＴＣデバイスに対するＩＰｖ４アドレス指定に用いるものである。ＮＡＴの本質に応じて、エンドポイント独立型マッピング（ＥＩＭ）およびエンドポイント依存型マッピング（非ＥＩＭ）ＮＡＴの２つの解決策が開示してある。ＥＩＭ挙動を行うＮＡＴでは、ＮＡＴのためのセッショントラバースユーティリティ（ＳＴＵＮ）プロトコル（ＩＥＴＦＲＦＣ５３８９）に基づいたアドレス決定技術が提案されている。非ＥＩＭ挙動を行うＮＡＴの場合、ＮＡＴ周囲トラバース利用リレー（ＴＵＲＮ）プロトコル（ＩＥＴＦＲＦＣ５７６６）に基づいたアドレス決定技術を用いることが可能である。
【００２５】
適切なアーキテクチャ
３ＧＰＰネットワークのＭＴＣサービスのための非管理ＮＡＴを用いたＮＡＴトラバースのための例示的な基準アーキテクチャが、図３に示されている。ＧＧＳＮ／Ｐ−ＧＷエンティティをその他の無線ネットワークに対して適切なネットワークエンティティと交換することにより、類似の基準モデルを他の無線ネットワークのために適用することが可能である。例えば、３ＧＰＰ２ネットワークの場合、ＧＧＳＮ／Ｐ−ＧＷエンティティを、図示の基準モデルにおけるＰＤＳＮと交換する。
【００２６】
図示のアドレス変換システム３００において、ＮＡＴ３１０内におけるＩＰアドレス変換およびアドレスバインディングは、無線ネットワークによって制御されない。このようなＩＰアドレス変換およびアドレスバインディングは、マシンタイプ通信に用いられる（ＵＥ３０２に配置された）ＭＴＣデバイスとの通信開始をＭＴＣサーバ３１４が望む場合、セッション特有の信号送信を利用することによって生成される。マシンタイプ通信相互作用機能（ＭＴＣ−ＩＷＦ）３０８は、ＭＴＣサーバ３１４とＧＧＳＮ／Ｐ−ＧＷ３０４とを接続する。
【００２７】
３ＧＰＰネットワークに対するこの例示的基準モデルにおいて、ＮＡＴデバイス３０６は、オペレータドメイン内でＧＧＳＮ／Ｐ−ＧＷ３０４の後側であり、ユーザプレーントラフィックのみがＮＡＴを横断する。ＧＧＳＮは、ゲートウェイ汎用パケット無線サービスサポートノードを意味する。ＮＡＴデバイス３０６は、単体で機能を発揮するエンティティであってもよいし、あるいはＧＧＳＮ／Ｐ−ＧＷ３０４と一体化して機能を発揮するエンティティであってもよい。ＮＡＴにおけるアドレス決定機能は、ＮＡＴの種類に応じたＲＦＣ５３８９（ＳＴＵＮ）またはＲＦＣ５７６６（ＴＵＲＮ）で規定されたプロトコルに適合する。ＮＡＴがＥＩＭ型である場合、ユーザプレーントラフィック３１０は、ＧＧＳＮ／Ｐ−ＧＷ３０４とＮＡＴとの間を通過する。ＮＡＴが非ＥＩＭ型である場合、ユーザプレーントラフィックは、ＧＧＳＮ／Ｐ−ＧＷ３０４とＴＵＲＮリレー機能３１２との間に流れる。ＲＦＣ５１２８は、ＥＩＭおよび非ＥＩＭ型ＮＡＴを記述する。ＧＧＳＮ／Ｐ−ＧＷ３０４におけるＳＴＵＮ機能は、ＳＴＵＮ／ＴＵＲＮクライアント機能に限定され得る。
【００２８】
３．  無線ネットワーク内におけるＮＡＴの後側にあるＭＴＣデバイスのＩＰｖ４アドレスを指定するためのアドレス決定技術
３．１  フレームワーク
本明細書中に記載されるアドレス決定技術は、以下の２つのステップを含む：
・ＭＴＣデバイスが無線ネットワークへ取り付けられ、私的ＩＰｖ４アドレスがデバイスへ割り当てられる。
・マッピングされた公的なトランスポートアドレスの決定
【００２９】
図４は、３ＧＰＰネットワークのための私的ＩＰｖ４アドレス割り当て処理手順およびアドレス登録の処理手順を実行するアーキテクチャ４００を例示的に示す。ＮＡＴ４１６の後側にあるＭＴＣデバイス４１２は、（メッセージ４０１を）３ＧＰＰネットワーク（ドメイン）へ与え、パケットデータプロトコル（ＰＤＰ）コンテクスト／パケットデータネットワーク（ＰＤＮ）接続およびＩＰアドレス割り当ての確立をリクエストする。３ＧＰＰ２ネットワークの場合、例示的な目的において、ＮＡＴ４１６の後側にあるＭＴＣデバイス４１２は、３ＧＰＰ２ネットワークに与え、ＰＤＳＮと接続したリンク層（ＰＰＰ）の確立およびＩＰアドレスの割り当ての確立をリクエストする。他の無線ネットワークにおける類似のステップも可能である。
【００３０】
ＭＴＣデバイス４１２は、ＡＡＡ４２６によって認証および認可される（メッセージ４０２）。ＰＤＰコンテクスト／ＰＤＮ接続が確立され、私的ＩＰｖ４アドレスがＭＴＣデバイスへと割り当てられる（メッセージ４０６）。オペレータ方針に応じて、ＩＰアドレスがＡＡＡ４２６によってまたはＧＧＳＮ／Ｐ−ＧＷ４１４によって割り当てられる。ＡＡＡ認証および認可処理手順およびＩＰアドレス割り当て処理手順の詳細は、適切な無線技術における呼び出し設定処理手順と同様である。この例示において、ＧＧＳＮ／Ｐ−ＧＷ４１４は、ＨＳＳ／ＡＡＡ４１８，４２６と共に、ＭＴＣデバイス４１２の特有情報（例えば、ＧＧＳＮ／Ｐ−ＧＷアドレス、ＭＴＣデバイスＩＤ、割り当てられた私的ＩＰｖ４アドレス情報等）を登録する。あるいは、ＧＧＳＮ／Ｐ−ＧＷは、このようなＭＴＣデバイスの特集情報全体またはその一部をＭＴＣゲートウェイ／プロキシと共に登録し得る（このような代替処理手順は図４中図示しない）。
【００３１】
マッピングされた公的トランスポートアドレスの決定について、以下の２つのシナリオを検討する必要がある。
１．ＮＡＴの後側のＭＴＣデバイス（クライアント）が通信を開始する場合、および
２．ＮＡＴの外部のＭＴＣサーバ（サーバ）が（例えば、デバイスの動作開始のために）通信を開始する必要がある場合。
【００３２】
先ずシナリオ２を考慮し、図７に示す。ＭＴＣサーバ４２２がＭＴＣデバイス４１２との通信を開始することを所望する場合、ＭＴＣサーバ４２２がＭＴＣデバイス４１２についての（公的な）トランスポートアドレス情報を既に持っていない場合、ＭＴＣサーバ４２２は、ＭＴＣデバイスのトランスポートアドレスについて問い合わせる。この問い合わせは、クエリメッセージ７０１をＭＴＣゲートウェイ／プロキシ４２０へ送ることにより、行われる。クエリメッセージ７０１は、ＭＴＣデバイスＩＤを含む。ＭＴＣゲートウェイ／プロキシ４２０は、ＧＧＳＮ／Ｐ−ＧＷ４１４情報に対するＨＳＳ／ＨＬＲ４１８とＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスとを問い合わせ、または、可能であればこのような情報をローカルキャッシュから入手する。ＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスを受信すると、ＭＴＣゲートウェイ／プロキシは、割り当てられた私的ＩＰｖ４アドレスおよび疑似ポート情報をＧＧＳＮ／ＰＧＷ４１４へと送ることにより、アドレス変換リクエスト／返信処理手順（７０４、７０５）を開始する。その後、ＭＴＣゲートウェイ／プロキシ４２０は、このような処理手順をアドレス決定サーバ４２４と共に行う。アドレス変換リクエスト７０４処理手順のために選択された「ポート」は、４８ｋ〜６４ｋの範囲のダイナミック／私的（一時ポート）であってもよいし、あるいは、他のいくつかのポートであってもよい。あるいは、疑似ポートを選択するＭＴＣゲートウェイ／プロキシ４２０の代わりに、ＧＧＳＮ／Ｐ−ＧＷ４１４がこのようなポートを選択してもよい。アドレス決定サーバ４２４は、アドレス変換を行い、マッピングされた公的なトランスポートアドレス（公的なＩＰアドレス＋ポート）情報７０５をＧＧＳＮ／Ｐ−ＧＷ４１４へと返送する。その後、このような情報がＭＴＣゲートウェイ／プロキシおよびＭＴＣサーバ（７０６）へと送られる。ここで、ＭＴＣサーバ４２０は、このような公的なトランスポートアドレスを用いて、ＭＴＣデバイス４１２との通信を開始することができる。ＭＴＣデバイス４１２（これは、無線ネットワーク４１０における私的空間内のＩＰアドレスが割り当てられ得る）は、オンライまたはオフラインとなり、ＭＴＣサーバ４２０からのこのような通信を受信する。
【００３３】
シナリオ１（ＮＡＴの後側にあるＭＴＣデバイスが通信を開始する）に関して、図１１および図１２中に２つの処理手順がそれぞれ示されている。いくつかの適用例において、ＮＡＴの後側にあるＭＴＣデバイスは、ピア―エンティティ間の通信を開始する前に、ルート指定可能なトランスポートアドレスを知る必要がある。ＭＴＣデバイス４１２は、デバイスＩＤおよび割り当てられた私的ＩＰｖ４アドレス情報を３ＧＰＰネットワーク内のエンティティ（例えば、ＧＧＳＮ／Ｐ−ＧＷ４１４、ＭＴＣゲートウェイ／プロキシ４２０）へと送ることにより、公的なトランスポートアドレスリクエスト／返信（１１０１、１１０４）処理手順を開始する。このような公的トランスポートアドレス決定処理手順は、エンティティ（例えば、ＧＧＳＮ／Ｐ−ＧＷ（選択肢１）またはＭＴＣゲートウェイ／プロキシ（選択肢２））の支援により、行うことができる。
【００３４】
選択肢１の場合、公的なトランスポートアドレスリクエスト／返信処理手順（１１０１、１１０４）は、エンティティ（例えば、ＧＧＳＮ／ＰＧＷ４１４）の支援を受けて行われる。ＭＴＣデバイス４１２がピアエンティティとの通信を開始したい場合において、ＭＴＣデバイス４１２が（公的な）トランスポートアドレス情報を既に持っていない場合、ＭＴＣデバイス４１２の適用状況に応じて、ＭＴＣデバイス４１２は、ピアエンティティとの通信開始に用いるべき「ポート」を選択する。その後、ＭＴＣデバイス４１２は、ＧＧＳＮ／Ｐ−ＧＷ４１４へ向けてリクエストメッセージ１１０１を送信することにより、公的なトランスポートアドレスリクエスト／返信処理手順（１１０１、１１０４）を開始する。リクエストメッセージ１１０１は、情報（例えば、デバイスＩＤ、（ＭＴＣデバイスへ割り当てられた）私的ＩＰｖ４アドレスおよび（ＭＴＣデバイスによって選択された）「ポート」情報）を含む。あるいは、ＩＰｖ４アドレスがリクエストメッセージ１１０１に含まれていない場合、このような情報は、デバイスＩＤに基づいてＨＳＳ／ＨＬＲ４１８に問い合わせることによりＧＧＳＮ／Ｐ−ＧＷ４１４によって入手され得、または、もし可能であれば、ＧＧＳＮ／Ｐ−ＧＷ４１４におけるローカルキャッシュから入手され得る。その後、ＧＧＳＮ／Ｐ−ＧＷ４１４は、割り当てられた私的トランスポートアドレス（ＩＰｖ４アドレスおよびポート）情報をアドレス決定サーバ４２４へと送ることにより、アドレス変換リクエスト／返信処理手順（１１０２、１１０３）を開始する。アドレス決定サーバ４２４は、アドレス変換を行い、マッピングされた公的トランスポートアドレス（ＩＰアドレス＋ポート）情報をＧＧＳＮ／Ｐ−ＧＷ４１４へと返送する（１１０３）。その後、その情報は、公的なトランスポートアドレス返信処理手順を介してＭＴＣデバイスへと返送される。ＭＴＣデバイスは、ここで、このような公的トランスポートアドレス情報を用いて、ピアエンティティとの通信を開始することができる。
【００３５】
選択肢２の場合、公的トランスポートアドレスリクエスト／返信処理手順（１２０１、１２０６）は、ＭＴＣゲートウェイ／プロキシ４２０の支援を受けて行われる。ＭＴＣデバイス４１２がピアエンティティとの通信開始を所望する場合において、ＭＴＣデバイス４１２が既に（公的な）トランスポートアドレス情報を持っていない場合、ＭＴＣデバイス４１２の適用状況に応じて、ＭＴＣデバイス４１２は、ピアエンティティとの通信開始に用いるべき「ポート」を選択する。その後、ＭＴＣデバイス４１２は、ＭＴＣゲートウェイ／プロキシへ向けたリクエストメッセージを送信することにより、公的なトランスポートアドレスリクエスト／返信処理手順（１２０１、１２０６）を開始する。リクエストメッセージ１２０１は、情報（例えば、デバイスＩＤ、（ＭＴＣデバイスへ割り当てられた）私的ＩＰｖ４アドレス、および（ＭＴＣデバイス４１２によって選択された）「ポート」情報）を含む。ＭＴＣゲートウェイ／プロキシ４２０は、ＧＧＳＮ／Ｐ−ＧＷ４１４についての情報を有することが想定され、およびＭＴＣデバイス４１２のアドレスを指定する私的ＩＰｖ４の情報を有することも想定され得る。ＭＴＣデバイス４１２へ割り当てられた私的ＩＰｖ４アドレスをリクエストメッセージ１２０１中に含めないようにすることが可能である。あるいは、このような情報（もしリクエストメッセージに含まれない場合には、ＧＧＳＮ／Ｐ−ＧＷおよびＩＰｖ４アドレス）は、デバイスＩＤに基づいたＨＳＳ／ＨＬＲ４１８に問い合わせ（１２０２）を行い（応答を受信する１２０３）ことにより、ＭＴＣゲートウェイ／プロキシ４２０によって入手され得る。その後、ＭＴＣゲートウェイ／プロキシ４２０は、割り当てられた私的トランスポートアドレス（ＩＰｖ４アドレスおよびポート）情報をＧＧＳＮ／Ｐ−ＧＷ４１４へと送ることにより、アドレス変換リクエスト／返信プロシージャ（１２０４、１２０５）を開始する。その後、ＧＧＳＮ／Ｐ−ＧＷ４１４は、このような処理手順をアドレス決定サーバ４２４と共に行う。アドレス決定サーバ４２４は、アドレス変換を行い、マッピングされた公的トランスポートアドレス（ＩＰアドレス＋ポート）情報をＧＧＳＮ／Ｐ−ＧＷ４１４（１２０５）へと返送する。その後、このような情報はＭＴＣゲートウェイ／プロキシへと送られ、公的トランスポートアドレス返信処理手順（１２０６）を介してＭＴＣデバイスへと返送される。ここで、ＭＴＣデバイスは、このような公的なトランスポートアドレス情報を用いて、ピアエンティティとの通信を開始することができる。
【００３６】
４．３  ＧＰＰネットワークにおける例示的な実施形態
以下の記述において、ＭＴＣデバイス５０２、ＧＧＳＮ５０６、ＮＡＴサーバ５０８、ＨＳＳ／ＨＬＲ５１０およびＭＴＣサーバ５１４は、既述したＭＴＣデバイス４１２、ＧＧＳＮ４１４、ＮＡＴサーバ４２４、ＨＳＳ／ＨＬＲ４１８およびＭＴＣサーバ４２２とそれぞれ実質的に類似する。また、さらなるネットワーク要素（モビリティ管理エンティティ（５０４）、ＭＴＣ−ＩＷＦ５１２）について以下に説明する。
【００３７】
一般的に、ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＵＥに対してさらなる要求をする必要は無い。同様に、ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＭＴＣサーバに対してさらなる要求をする必要は無い。
【００３８】
ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＭＴＣ相互作用機能（ＭＴＣ−ＩＷＦ）は、以下の機能のうち１つ以上を含み得る：
【００３９】
ＭＴＣ−ＩＷＦは、ＭＴＣのために用いられるＵＥがＮＡＴデバイスの後側にあることを認識することができる。
【００４０】
ＭＴＣに用いられるＵＥへ割り当てられたＩＰｖ４アドレスに基づいて、ＮＡＴの後側に配置されたＧＧＳＮ／Ｐ−ＧＷによりＵＥが機能するということを認識する能力。
【００４１】
処理手順を開始し、ＧＧＳＮ／Ｐ−ＧＷへの問い合わせによって、ＭＴＣに用いられるＵＥのために公的トランスポートアドレス（ＩＰアドレス＋ポート）を入手するする能力。
【００４２】
ＭＴＣ用のＵＥのための公的トランスポートアドレスをＭＴＣサーバへ通信する能力。
【００４３】
ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＧＧＳＮ／Ｐ−ＧＷは、ＮＡＴを用いて、私的から公的なトランスポートアドレスへの変換のためにＳＴＵＮ／ＴＵＲＮプロトコル機構を呼び出し得る。ＧＧＳＮ／Ｐ−ＧＷは、以下の機能を行い得る：
【００４４】
ＲＦＣ５２３９およびＲＣ５７６６に記載のようなＳＴＵＮ／ＴＵＲＮサポート機能。
【００４５】
ＳＴＵＮ／ＴＵＲＮサポートサーバの検出。いくつかの実施形態において、ＳＴＵＮ／ＴＵＲＮサーバアドレスをＧＧＳＮ／Ｐ−ＧＷ中に提供するために所定の構成機構を用いることができる。
【００４６】
ＭＴＣ−ＩＷＦによってリクエストされると、処理手順を開始し、ＳＴＵＮ／ＴＵＲＮアドレス決定処理手順をＮＡＴと共に実行することにより、ＭＴＣのために用いられるＵＥの公的トランスポートアドレスを取得する。
【００４７】
ＭＴＣのためのＵＥへ割り当てられた変換トランスポートアドレスをＭＴＣ−ＩＷＦへと通信する。
【００４８】
ＳＴＵＮキープアライブ機構の利用により、ＮＡＴバインディングを維持する。
【００４９】
ＳＴＵＮサーバおよび関連する信号送信要求については、ＲＦＣ５３８９中に記載してある。ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＳＴＵＮサーバに対するさらなる要求は無い。いくつかの実施形態において、ネットワーク内にＳＴＵＮサーバを展開しなくてよい。いくつかの実施形態においては、ＳＴＵＮサーバを展開し、主要なＮＡＴ種類のＵＥ用のＮＡＴにおいて、ＡＰＮ対面トランスポートアドレスを検索し易くしても良い。このような構成により、一態様において、ＮＡＴを介してユーザ計画トラフィックと直接通信することを可能にして、ＴＵＲＮリソースの必要性を最小化することが可能となる。
【００５０】
ＴＵＲＮリレーおよび関連する信号送信要求については、ＲＦＣ５７６６中に記載してある。ＮＡＴの後側に常駐するＵＥのためにＭＴＣをサポートする場合、ＴＵＲＮリレーサーバにおいてさらなる要求をする必要は無い。いくつかの実施形態においては、ネットワーク内においてＴＵＲＮを展開しなくてよい。いくつかの実施形態においては、ＴＵＲＮを展開することにより、全種類のＮＡＴの存在に対しユーザプレーントラフィックの交換を促進できるようにしてもよい。
【００５１】
ＭＴＣｙｙ基準点はＧＧＳＮ／Ｐ−ＧＷとＳＴＵＮ／ＴＵＲＮアドレス決定機能との間にある。このインターフェースは、ＮＡＴデバイスがＧＧＳＮ／Ｐ−ＧＷおよびＳＴＵＮ／ＴＵＲＮアドレス決定サーバ内で処理手順を起動するために必要な情報を搬送する。
【００５２】
５．  アドレス決定を行うための処理手順
本節において記載する処理手順は、非管理ＮＡＴの利用において特有のものであり、マシンタイプ通信のサポートのための他の処理手順に加えて適用される。
【００５３】
５．１  ＭＴＣ−ＩＷＦにおけるＮＡＴ検出
ＭＴＣに用いられるＵＥに割り当てられたＩＰｖ４アドレスまたはローカル構成に基づいて、ＰＬＭＮが非管理ＮＡＴをサポートする場合、ＭＴＣ−ＩＷＦは、ＮＡＴがＧＧＳＮ／Ｐ−ＧＷとＡＰＮとの間に展開されているかを検出し、アドレス変換機能がＧＧＳＮ／Ｐ−ＧＷと共に呼び出されるべきかを決定する。
【００５４】
５．２  セッション確立処理手順
図５を参照すればわかるように、ＭＴＣに用いられるＵＥがネットワークを用いて登録を行い、ＰＤＰコンテクスト／ＰＤＮ接続（５０１）が確立されると、セッション確立プロシージャ５００が適用される。このような処理手順は、ＵＥがプロシージャを自立的に開始することによって、またはネットワークによりメッセージが送信された結果、呼び出され得る。
【００５５】
ＭＴＣデバイスは、自立的にまたはネットワークによってメッセージが送信された結果、取り付け処理手順をネットワークと共に行う。取り付け処理手順の一部としてＭＴＣデバイスに、ここでは「Ｄ」と呼ばれるＩＰｖ４アドレス（メッセージ５０３）が割り当てられる。ＭＴＣデバイスがＮＡＴの後側において展開されているため、割り当てられたＩＰｖ４アドレスは、ＧＧＳＮ／Ｐ−ＧＷの私的アドレスドメイン内にある。セッション生成応答メッセージ（図示せず）を用いて、アドレス「Ｄ」をＧＧＳＮ／Ｐ−ＧＷからＳＧＳＮ／ＭＭＥへと搬送する。ＭＴＣ−ＩＷＦは、ＭＴＣデバイスへも割り当てられる。
【００５６】
上記工程の一部として、または取り付け処理手順の終了時において、ＳＧＳＮ／ＭＭＥは、ＭＴＣデバイスへ割り当てられたアドレス「Ｄ」をＨＳＳ／ＨＬＲへ通知する。インターフェースがＧＧＳＮ／Ｐ−ＧＷとＭＴＣ−ＩＷＦとの間に配置されると、ＧＧＳＮ／Ｐ−ＧＷは状態更新リクエスト／応答メッセージ５０５を用い、ＭＴＣデバイスへ割り当てられたアドレス「Ｄ」をＭＴＣ−ＩＷＦへ通知することができる。
【００５７】
５．３  ＵＥ開始通信
図６を参照すればわかるように、ＭＴＣに用いられるＵＥがネットワークを用いて登録を行い、上記したように確立されたＰＤＮコンテクスト／ＰＤＰ接続および割り当てられたＩＰｖ４アドレスを有する場合、処理手順６００が適用される。ＭＴＣに用いられるＵＥはＮＡＴの後側にあるため、私的ＩＰｖ４アドレス「Ｄ」がＵＥへと割り当てられる。
【００５８】
ＭＴＣデバイス５０２は、確立されたＰＤＮコンテクスト／ＰＤＰ接続（６０１）を介し、ピア―エンティティに対してアドレス指定されたユーザプレーンパケットを送る。パケットのソースＩＰアドレスは、ＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレス「Ｄ」に設定される。
【００５９】
バインディングが存在しないユーザプレーンパケットを受信すると、ＮＡＴデバイスは、このユーザプレーンパケットを新規セッションのためのパケットフローとして認識する。ＮＡＴデバイスは、アドレスおよび／またはポート変換を私的アドレス／ポート（Ｄ、Ｐ）に対して行い、変換されたトランスポートアドレス（Ｄｔ、Ｐｔ）（メッセージ６０３中に図示）とユーザプレーンパケットのソーストランスポートアドレスとを交換する。
【００６０】
ＭＴＣデバイスとピアエンティティとの間のエンドツーエンドＩＰ通信６０５が継続する。ピアエンティティは、ＭＴＣデバイスへ送られるユーザプレーンパケット中の宛先アドレスとして、トランスポートアドレス（Ｄｔ、Ｐｔ）を用いる。以下の点に留意されたい：ＮＡＴバインディングは、ユーザプレーントラフィックのフローにによってバインディング状態が保持される。ＮＡＴをリブートしかつ／または旧バインディングが存在しない場合、ＵＥからユーザプレーンパケットが受信されると、新規バインディングが生成される。
【００６１】
５．４  ＭＴＣサーバの動作が開始された通信
ＭＴＣサーバがＭＴＣに用いられるＵＥとの通信開始を所望する場合、図８に示す処理手順８００が適用される。ＭＴＣサーバは、ＭＴＣ−ＩＷＦを決定する。このＭＴＣ−ＩＷＦは、ＵＥの外部ＩＤを有するＤＮＳクエリを行うことにより、ＭＴＣに用いられるＵＥを提供する。ＭＴＣのために用いられる特定のＵＥに割り当てられるＭＴＣ−ＩＷＦはほとんど変わらないため、ＭＴＣサーバは、割り当てられたＭＴＣ−ＩＷＦアドレスを決定するためにＤＮＳクエリを行う必要はほとんど無い。そのためこのアドレスは、ＵＥとのユーザプレーン通信開始に用いるため、ルート指定可能なＩＰアドレスをＭＴＣ−ＩＷＦにリクエストすべく使用される。ＭＴＣ−ＩＷＦアドレスを解明するために用いるＤＮＳ更新およびＤＮＳクエリ処理手順については、以下の例示事項中で示していない。
【００６２】
以下の例示において、ＳＴＵＮサーバ要素は、ＳＴＵＮサーバおよびＴＵＲＮリレー双方を単一の論理要素として表している。この例示内容は、これらの機能が別個の論理要素として表される場合と均等である。これらの処理手順は、これらの機能をグループ化しても影響を受けない。さらに、このコールフローは、ＳＴＵＮサーバのＮＡＴトラバース処理手順を例示することを目的として、単純化した図を示しているにすぎない。
【００６３】
ＭＴＣサーバは、ＭＴＣデバイスとの通信開始を所望し、ＭＴＣデバイスのＩＰアドレス情報を持っていない場合またはＩＰ接続性の回復が必要であると特定した場合（例えば、ＭＴＣデバイスが全く応答していない場合）、ＭＴＣサーバは、トリガリクエストメッセージ８０１を送ることにより、ＩＰアドレスについてＭＴＣ−ＩＷＦに問い合わせる。トリガリクエストメッセージ８０１は、ＭＴＣデバイス外部識別子と、ＭＴＣサーバがＭＴＣデバイスとの開始を所望するアプリケーションのアプリケーション識別子とを含む。
【００６４】
アプリケーション識別子情報は、サービスプロバイダおよびＰＬＭＮエンティティによって共通に理解される「アプリケーションＩＤ」の形態にすることができる。あるいは、アプリケーション識別子情報は、名称割り当てに関する国際機関（ＩＡＮＡ）またはいくつかのこのような他の認証機関によってアプリケーションへと割り当てられた「ポート番号」の形態であってもよい。
【００６５】
いくつかの実施形態において、ＭＴＣサーバは、ＵＥの外部ＩＤを用いてＤＮＳクエリを行うことにより、ＭＴＣに用いられるＵＥを提供するＭＴＣ−ＩＷＦを決定し得る。
【００６６】
ＭＴＣデバイスへ割り当てられたＩＰアドレスのような情報がローカルキャッシュ中において利用できない場合、ＭＴＣ−ＩＷＦは、トリガリクエストを認証し、をＨＳＳ／ＨＬＲに通信して（メッセージ８０２）、ＭＴＣデバイスへ割り当てられたＩＰアドレスを入手する。ＭＴＣデバイスに対して確立中のＰＤＰコンテクスト／ＰＤＮ接続がある場合、ＨＳＳ／ＨＬＲは私的ＩＰｖ４アドレスと、ＭＴＣデバイスへと割り当てられたＧＧＳＮ／Ｐ−ＧＷとを返送する。その後、処理手順が次に続く。あるいは、ＰＤＰコンテクスト／ＰＤＮ接続が（８０３中のように）確立されていない場合またはＩＰ接続性の回復が必要な場合、ＨＳＳ／ＨＬＲは、内部デバイスＩＤ（ＩＭＳＩ）およびステップ８０４のようなＭＴＣデバイスの動作開始に必要な任意のさらなる情報を返送する。
【００６７】
ＭＴＣ−ＩＷＦは、デバイストリガ送達機構を選択し、ＭＴＣデバイスへのトリガ送達に用いられる次のノードへとトリガリクエストを転送する。ＭＴＣデバイスの動作が開始することにより、ＰＤＰコンテクスト／ＰＤＮ接続が確立され（８０３）、本明細書中の処理手順毎にＩＰｖ４アドレスがＭＴＣデバイスへと割り当てられる。この段階において、ＭＴＣデバイスへ割り当てられたＩＰアドレス「Ｄ」はＨＳＳ／ＨＬＲおよび／またはＭＴＣ−ＩＷＦにおいて利用可能となり、割り当てられたＧＧＳＮ／Ｐ−ＧＷ情報を伴ってＭＴＣ−ＩＷＦに対して利用可能となる。ＭＴＣデバイスはＮＡＴの後側に配置されているため、ＭＴＣ−ＩＷＦは、（私的）ＩＰｖ４アドレス「Ｄ」およびアプリケーションＩＤ／ポート「Ｐ」情報を含むアドレス変換リクエストメッセージ８０４を、割り当てられたＧＧＳＮ／Ｐ−ＧＷへと送ることにより、アドレス変換プロシージャを開始する。
【００６８】
ＧＧＳＮ／Ｐ−ＧＷは、ＲＦＣ５３８９およびＲＦＣ５７６６においてそれぞれ記載されているようなＳＴＵＮ／ＴＵＲＮクライアント機能を実行する。ＧＧＳＮ／Ｐ−ＧＷは、ＳＴＵＮバインディングリクエストメッセージ８０５をＳＴＵＮ／ＴＵＲＮサーバへと送って、ＭＴＣデバイスの公的トランスポートアドレスを入手する。
【００６９】
ＳＴＵＮ／ＴＵＲＮサーバは、アドレス変換を行い、マッピングされた公的トランスポートアドレス情報をＳＴＵＮバインディング応答メッセージ８−６中に含めて、ＧＧＳＮ／Ｐ−ＧＷへと返送する。ＳＴＵＮ／ＴＵＲＮサーバは、ＲＦＣ５３８９中の処理手順毎に、バインディング「寿命」の間、変換アドレスのためにバインディングを維持する。
【００７０】
ＧＧＳＮ／Ｐ−ＧＷは、ＳＴＵＮバインディング応答メッセージを間で受取り、変換されたトランスポートアドレス情報をアドレス変換応答メッセージ８０７を介してＭＴＣ−ＩＷＦへと返送する。
【００７１】
ＭＴＣ−ＩＷＦは、ＭＴＣデバイスへ割り当てられた公的トランスポートアドレスを、トリガ応答メッセージ８０８を介してＭＴＣサーバへと返送する。
【００７２】
この段階において、ＭＴＣサーバは、ＭＴＣデバイスとの通信を開始する準備が整っている。ＭＴＣサーバは、標的アドレスセットを用いてＭＴＣデバイスに対するアドレス指定がなされたユーザプレーンパケット８０９を、ＭＴＣデバイスへ割り当てられた公的トランスポートアドレス（Ｄｔ、Ｐｔ）に送る。
【００７３】
ユーザプレーンパケットを受信すると、ＮＡＴは、公的トランスポートアドレス（Ｄｔ、Ｐｔ）に対するバインディングを認識し、宛先トランスポートアドレス情報と、ＭＴＣデバイス８１０へ割り当てられた私的アドレス（Ｄ、Ｐ）とを交換する。
【００７４】
ＭＴＣサーバとＭＴＣデバイスとの間のエンドツーエンドＩＰ通信８１１が継続する。ＭＴＣデバイスは、ユーザプレーンパケットのソースアドレスとして、私的アドレス／ポート情報（Ｄ、Ｐ）を用いる。私的アドレス／ポート情報（Ｄ、Ｐ）は、ＮＡＴデバイスによって公的トランスポートアドレス（Ｄｔ、Ｐｔ）へマッピングされる。
【００７５】
５．５  ＳＴＵＮバインディングの維持
図９を参照すればわかるように、処理手順９００は、ＮＡＴデバイスにおけるＳＴＵＮバインディングの維持のために適用される。ユーザプレーントラフィックのフローにより、ＮＡＴバインディングはバインディング状態が維持される。さらに、ＧＧＳＮ／Ｐ−ＧＷにおけるＳＴＵＮクライアント機能は、ＳＴＵＮキープアライブ信号送信を利用することにより、そのバインディング状態を維持する。
【００７６】
ユーザプレーントラフィックのフローにより、ＮＡＴバインディングのバインディング状態が維持される。さらに、ＧＧＳＮ／Ｐ−ＧＷ中のＳＴＵＮクライアント機能が、周期的キープアライブＳＴＵＮバインディングリクエストメッセージ９０１をＳＴＵＮサーバへ送ることにより、そのバインディングのバインディング状態が維持される。
【００７７】
ＳＴＵＮサーバは、バインディングの寿命を更新し、ＳＴＵＮバインディング応答メッセージ９０２をＧＧＳＮ／Ｐ−ＧＷへ返送する。バインディング応答メッセージは、マッピングされたトランスポートアドレス（Ｄｔ、Ｐｔ）も含む。このような情報を含むことにより、ＧＧＳＮ／Ｐ−ＧＷは、ＮＡＴがリブートし、ＭＴＣデバイスに対して新規バインディング（Ｄｔ’、Ｐｔ’）を割り当てたかを決定することができる。
【００７８】
ＮＡＴが新規バインディングを割り当てた場合、ＧＧＳＮ／Ｐ−ＧＷは、当該情報をアドレス変換応答（Ｄｔ’、Ｐｔ’）メッセージ９０３を介してＭＴＣ−ＩＷＦへ転送する。
【００７９】
ＭＴＣ−ＩＷＦは、新規トランスポートアドレス情報をＭＴＣサーバへ転送する。ＭＴＣサーバは、新規トランスポートアドレス（Ｄｔ’、Ｐｔ’）をＭＴＣデバイス９０４とのさらなる通信に用いる。
【００８０】
５．６  ＮＡＴバインディングの解放
図１０を参照すればわかるように、処理手順１０００は、ＮＡＴデバイスにおけるＳＴＵＮバインディングの解放に適用される。ＭＴＣのためにＵＥに割り当てられた私的ＩＰｖ４アドレス「Ｄ」の解放についてＭＴＣ−ＩＷＦが知ると、ＭＴＣ−ＩＷＦは、アドレス変換リクエスト（解放）メッセージ１００１をＧＧＳＮ／Ｐ−ＧＷへと送ることにより、ＮＡＴバインディング解放処理手順を開始する。ＭＴＣに用いられるＵＥのためのＰＤＰコンテクスト／ＰＤＮ接続が解放された場合またはいくつかの他の手段によって、ＭＴＣ−ＩＷＦは、ＩＰアドレスの解放について知る。
【００８１】
ＭＴＣ−ＩＷＦは、ＭＴＣデバイスへ割り当てられたＩＰアドレス「Ｄ」の解放について知る。ＭＴＣ−ＩＷＦは、アドレス変換リクエスト（解放）メッセージ１１０１をＧＧＳＮ／Ｐ−ＧＷへ送ることにより、ＮＡＴバインディング解放処理手段を開始する。
【００８２】
ＧＧＳＮ／Ｐ−ＧＷは、ＳＴＵＮバインディングリクエスト（Ｄ、Ｐ）メッセージをＳＴＵＮサーバへ送り、バインディング寿命を「０」に設定する（１００２）。
【００８３】
ＳＴＵＮサーバは、ＭＴＣデバイスに対するバインディングを解放し、寿命が「０」に設定されたＳＴＵＮバインディング応答メッセージに応答する（１００３）。
【００８４】
ＧＧＳＮ／Ｐ−ＧＷは、アドレス変換応答（解放確認）メッセージをＭＴＣ−ＩＷＦ１００４へ返送することにより、ＮＡＴバインディングの解放を確認する。
【００８５】
図１３は、ＳＴＵＮサーバ１３０２を用いたアドレスマッピングおよびデータトランスポートの例示的なプロセス１３００を示す。いくつかのＮＡＴ装置は、「エンドポイント独立型マッピングおよびフィルタリング（ＥＩＭ）」として振る舞う。それらのＮＡＴ装置は、ＭＴＣサーバの宛先ＩＰトランスポートアドレスに関係無く、（ＮＡＴの後側の）ＭＴＣデバイスが有する同一（ソース）ＩＰアドレスおよびポートから送られてきた全パケットに対し、同一の公的なポートマッピングを用いる。さらに、このようなＮＡＴは、先発パケット中の宛先と異なるソーストランスポートアドレスを有する受信パケットをフィルタリングしない。この場合、アドレスサーバ（ＳＴＵＮサーバ１３０２）をアドレス決定処理手順のために配置し、ＭＴＣデバイスに対するマッピングされた公的トランスポートアドレスを入手することができる。
【００８６】
ＭＴＣサーバ４２２がＭＴＣデバイス４１４との通信を開始したい場合において、ＭＴＣデバイスのための（公的な）トランスポートアドレス情報を既に持っていない場合、ＭＴＣサーバは、クエリメッセージ１３１０をＭＴＣゲートウェイ／プロキシ４２０へ送ることにより、ＭＴＣデバイストランスポートアドレスを問い合わせる。クエリメッセージ１３１０は、ＭＴＣデバイスＩＤを含む。ＭＴＣゲートウェイ／プロキシは、ＧＧＳＮ／Ｐ−ＧＷ位置情報およびＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスをＨＳＳ／ＨＬＲに問い合わせるか、または、このような情報をそのローカルキャッシュ（ただし、利用可能な場合）から入手する。ＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスを受信すると、ＭＴＣゲートウェイ／プロキシは、割り当てられた私的ＩＰｖ４アドレスおよび疑似ポート情報をＧＧＳＮ／ＰＧＷへ送ることにより、アドレス変換リクエスト／返信処理手順をＧＧＳＮ／ＰＧＷと共に開始する。アドレス変換リクエスト処理手順のために選択された「ポート」は、４８ｋ〜６４ｋの範囲のダイナミック／私的（一時ポート）であるか、またはＦＦＳであるいくつかの他のポートである。あるいは、疑似ポートを選択するＭＴＣゲートウェイ／プロキシの代わりに、このようなポートをＧＧＳＮ／Ｐ−ＧＷによって選択してもよい。ＧＧＳＮ／Ｐ−ＧＷは、ＳＴＵＮバインディングリクエスト／応答（１３０８）処理手順（ＲＦＣ５３８９―ＮＡＴに対するセッショントラバースユーティリティ）をＳＴＵＮサーバ（アドレス決定サーバ）と共に実行する。そして、アドレス変換を行い、マッピングされた公的トランスポートアドレス（公的なＩＰアドレス＋ポート）情報をＸＯＲマッピングアドレス属性中のＧＧＳＮ／Ｐ−ＧＷへ返送する。その後、このような情報は、ＭＴＣゲートウェイ／プロキシおよびＭＴＣサーバへと送られる（１３１２）。ここで、ＭＴＣサーバは、ＭＴＣデバイスのこのような公的なトランスポートアドレスを用いて通信を開始することができる。ＭＴＣデバイスは、オンラインまたはオフラインとなり、ＭＴＣサーバからこのような通信を受信する。
【００８７】
ＧＧＳＮ／Ｐ−ＧＷは、ＤＮＳ検索処理手順を用いてＳＴＵＮサーバを決定することができ、あるいは、ＳＴＵＮサーバアドレス情報がＧＧＳＮ／Ｐ−ＧＷにおいて構成され得る。ＧＧＳＮ／Ｐ−ＧＷ（ＳＴＵＮクライアント）とＳＴＵＮサーバとの間のＳＴＵＮメッセージ交換は、ＳＴＵＮプロトコル（ＲＦＣ５３８９）で記載された認証およびメッセージ完全性機構によって保護することができる。ＳＴＵＮバインディング通知をキープアライブ処理手順のために用いて、ＮＡＴエンティティにおけるアドレス変換を維持することができる。ＮＡＴにおけるアドレス変換のための寿命情報のデフォルト設定およびキープアライブ処理手順のデフォルト設定は、ＦＦＳである。その後、ＭＴＣサーバ４２２は、ＮＡＴ（データパケット１３０６としての変換アドレス）を介してデータパケット通信１３０４を行うことができる。
【００８８】
シナリオ２：
図１０は、ＴＵＲＮリレー１４０２によるアドレスマッピングおよびデータトランスポートのための例示的なプロセスを示す。ＮＡＴの挙動が「エンドポイント依存型」ＮＡＴ（「非ＥＩＭ」）である場合、ＮＡＴは、アドレス依存型またはアドレスおよびポート依存型のＮＡＴとして振る舞うことができる。このようなＮＡＴの場合、ＭＴＣサーバのアドレスとアドレスが異なり得るＳＴＵＮサーバを用いたアドレス解析は、有効な解決策とならない。このようなＮＡＴ（非ＥＩＭ）は、アドレスマッピング目的のために用いられたＳＴＵＮサーバのトランスポートアドレスと同一のトランスポートアドレスから送られていないダウンリンクパケットをフィルタリングし得る。この場合、リレーサーバ（ＴＵＲＮリレー）を配置して、ＭＴＣデバイスのためのリレートランスポートアドレスを得ることができる。
【００８９】
ＭＴＣサーバがＭＴＣデバイスと通信を開始することを所望する場合であって、ＭＴＣサーバがＭＴＣデバイスのための（公的な）トランスポートアドレス情報を既に持っていない場合、ＭＴＣサーバは、クエリメッセージ１４１０をＭＴＣゲートウェイ／プロキシへ送ることにより、ＭＴＣデバイスのトランスポートアドレスを問い合わせる。クエリメッセージは、ＭＴＣデバイスＩＤを含む。ＭＴＣゲートウェイ／プロキシは、サービング側ＧＧＳＮ／Ｐ−ＧＷ位置情報とＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスとをＭＴＣデバイスへ送信するようにＨＳＳ／ＨＬＲに問い合わせるか、またはこのような情報をそのローカルキャッシュ（ただし、利用可能な場合）から入手する。ＭＴＣデバイスへ割り当てられた私的ＩＰｖ４アドレスを受信すると、ＭＴＣゲートウェイ／プロキシは、割り当てられた私的ＩＰｖ４アドレスおよび疑似ポート情報をＧＧＳＮ／ＰＧＷへ送ることにより、アドレス変換リクエスト／返信処理手順をＧＧＳＮ／ＰＧＷと共に開始する。アドレス変換リクエスト処理手順のために選択された「ポート」は、４８ｋ〜６４ｋの範囲のダイナミック／私的ポート（一時ポート）であるか、またはＦＦＳであるいくつかの他のポートであり得る。あるいは、疑似ポートを選択するＭＴＣゲートウェイ／プロキシの代わりに、ＧＧＳＮ／Ｐ−ＧＷがそのようなポートを選択してもよい。ＮＡＴが非ＥＩＭＮＡＴとして挙動することが分かった場合、ＧＧＳＮ／Ｐ−ＧＷは、ＴＵＲＮ割り当てリクエスト／応答処理手順１４０８（ＲＦＣ５７６６−ＮＡＴ周囲のリレーを用いたトラバース）をＴＵＲＮリレー（アドレス決定サーバ）と共に実行し、リレートランスポートアドレス（公的なＩＰアドレス＋ポート）をＸＯＲリレーアドレス属性中に含めて、ＧＧＳＮ／Ｐ−ＧＷへと返送する。その後、このような情報はＭＴＣゲートウェイ／プロキシおよびＭＴＣサーバ（１４１２）へと送られる。ＧＧＳＮ／Ｐ−ＧＷ（ＴＵＲＮクライアント）は、ＣｒｅａｔｅＰｅｒｍｉｓｓｉｏｎおよび／またはＣｈａｎｎｅｌＢｉｎｄ処理手順（単数または複数）をＴＵＲＮリレーと共に行って、ＭＴＣサーバとの通信を可能にする。ここで、ＭＴＣサーバは、このようなＴＵＲＮリレートランスポートアドレスを用いてＭＴＣデバイスとの通信を開始することができる。ＭＴＣデバイスは、オンラインまたはオフラインで、このような通信をＭＴＣサーバから受信する。
【００９０】
ＧＧＳＮ／Ｐ−ＧＷは、ＤＮＳ検索処理手順を用いてサービング側ＴＵＲＮリレーを決定することもできるし、あるいは、ＴＵＲＮリレーアドレス情報をＧＧＳＮ／Ｐ−ＧＷにおいて構成してもよい。ＧＧＳＮ／Ｐ−ＧＷ（ＴＵＲＮクライアント）とＴＵＲＮリレーとの間のＴＵＲＮメッセージ交換は、ＴＵＲＮプロトコル（ＲＦＣ５７６６）に記載された認証およびメッセージ完全性機構によって保護され得る。キープアライブ処理手順にバインディング通知を用いることにより、ＮＡＴエンティティにおけるアドレス変換を維持することができる。ＮＡＴにおけるアドレス変換についての寿命情報のデフォルト設定、ＴＵＲＮリレーアドレスマッピング寿命、およびキープアライブ処理手順は、ＦＦＳである。ＣｒｅａｔｅＰｅｒｍｉｓｓｉｏｎおよびＣｈａｎｎｅｌＢｉｎｄ方法の詳細内容もＦＦＳである。
【００９１】
その後、ＭＴＣサーバ４２２は、ＮＡＴ（データパケット１４０６としての変換アドレス）を介してデータパケット通信１４０４を行い得る。
【００９２】
図１５は、無線通信ネットワーク内のネットワーク側において実行することが可能なプロセス１５００のフローチャートである。プロセス１５００は、例えば既述したＭＴＣ−ＩＷＦを実現するためのプラットフォーム上において実行することが可能である。１５０２において、マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストが受信される。１５０４において、外部ＩＤを含むデバイス情報リクエストが送信される。１５０６において、デバイス情報リクエストに応答して、第１のＩＰアドレスがＭＴＣデバイスのために受信される。無線ネットワークの私的アドレス空間中に、第１のＩＰアドレスがあり得る。１５０８において、第１のＩＰアドレスに基づいて、第２のＩＰアドレスが入手される。第２のＩＰアドレスは、トリガリクエストの送信元である第２のネットワーク中にある第１のＩＰアドレスの変換に対応する。いくつかの実施形態において、第１のＩＰアドレスを含むアドレス変換リクエストを送り、これに応答して第２のＩＰアドレスを受信することにより、第２のＩＰアドレスを得ることができる。いくつかの実施形態において、第２のＩＰアドレスを含む応答メッセージを提供することにより、トリガリクエストに対して応答する。いくつかの実施形態において、第２のＩＰアドレスは、公的な空間に対応し得る。プロセス１５００は、ＩＰｖ４アドレスへ適用され得る。
【００９３】
図１６は、無線通信を促進するための装置１６００のブロック図である。モジュール１６０２（例えば、トリガリクエスト受信器）は、マシンタイプ通信（ＭＴＣ）デバイスの外部識別情報（ＩＤ）を含むトリガリクエストを受信するためのものである。モジュール１６０４（例えば、リクエスト送信器）は、外部ＩＤを含むデバイス情報リクエストを送信するためのものである。モジュール１６０６（例えば、ＩＰアドレス受信器）は、デバイス情報リクエストに応答して、無線ネットワークの私的アドレス空間中にありＭＴＣデバイス用の第１のＩＰアドレスを受信するためのものである。モジュール１６０８（例えば、ＩＰアドレス入手器）は、第１のＩＰアドレスに基づいて第２のＩＰアドレスを入手するためのものであり、第２のＩＰアドレスは、トリガリクエストの送信元である第２のネットワークの中の第１のＩＰアドレスの変換に対応する。装置１６００と、モジュール１６０２、１６０４、１６０６および１６０８とは、本明細書中に開示される１つ以上の技術を更に実行するように構成され得る。
【００９４】
図１７は、無線通信システム中のゲートウェイデバイスにおいて実行することが可能なプロセス１７００のフローチャートである。１７０２において、リクエストが受信され、無線通信システムに対し私的な第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行う。１７０４において、第２のＩＰアドレスがＭＴＣデバイスのために入手される。第２のＩＰアドレスは、第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間内にある。１７０６において、第２のＩＰアドレスを含むことにより、リクエストに対する応答が送信される。１７０８において、第２のＩＰアドレス空間中にあるＭＴＣデバイスおよび別の通信エンティティ間でのユーザデータプレーン通信が促進される。
【００９５】
図１８は、無線通信ネットワーク内において動作可能なゲートウェイデバイス１８００の一部を示すブロック図である。モジュール１８０２（例えば、リクエスト受信器）は、無線通信システムに対し私的な第１のＩＰアドレス空間内にある第１のインターネットプロトコル（ＩＰ）アドレスの変換を行うためにリクエストを受信するためのものである。モジュール１８０４（例えば、ＩＰアドレス入手器）は、ＭＴＣデバイスのための第２のＩＰアドレスを入手するためのものである。第２のＩＰアドレスは、第１のＩＰアドレス空間と異なる第２のＩＰアドレス空間中にある。モジュール１８０６（例えば、応答送信器）は、第２のＩＰアドレスを含むことによって、リクエストに対し応答を送るためのものである。モジュール１８０８（例えば、ゲートウェイサーバ）は、第２のＩＰアドレス空間中にあるＭＴＣデバイスおよび別の通信エンティティ間のユーザデータプレーン通信を促進するためのものである。装置１８００と、モジュール１８０２、１８０４、１８０６および１８０８とは、本明細書中に開示される１つ以上の技術を実行するようにさらに構成してもよい。
【００９６】
ＮＡＴの後側に配置されたマシンタイプ通信（ＭＴＣ）デバイスのＩＰアドレスを特定するための技術が開示されることが理解される。ＭＴＣデバイスは、無線ネットワーク内に配置されることが多く、私的ＩＰｖ４アドレスがＭＴＣデバイスへ割り当てられることが多い。ＩＰｖ４プロトコルを用いて利用可能なアドレスには制限があるため、私的アドレスは、ＭＴＣサーバのＩＰアドレスの範囲と異なるアドレス範囲内にあり得る。そのため、ＭＴＣサーバは、ＭＴＣデバイスと直接通信できず、アドレス変換サービスを必要とする場合がある。しかし、ＭＴＣデバイスは一般的にロングスリープモードに入って動作することが多いため、ＭＴＣサーバがＭＴＣデバイスとの通信を望む場合、ＭＴＣデバイスの私的ＩＰｖ４アドレスがＭＴＣサーバにとって利用できない可能性がある。
【００９７】
開示された信号交換技術により、一態様において、ＭＴＣデバイスが自身の固有の公的ＩＰアドレス（すなわち、ＭＴＣデバイスをＭＴＣサーバに知らせるためのＩＰアドレス）を検索することが可能になることが理解される。一態様において、この知識により、ＭＴＣデバイスにセキュアな通信を確立させ、またはＭＴＣデバイスの公的なＩＰアドレスについての情報を含むデジタル証明をリクエスト及び受信できるため、有用であり得る。
【００９８】
一態様において、開示のプロセス、装置およびシステムを用いれば、ＭＴＣデバイスが既に割り当てられたＩＰアドレスを有し活性状態にあるかに関係無く、ＭＴＣデバイスのＲＦがオフになっているが割り当てられたＩＰアドレスを未だ有しているモードまたはＭＴＣデバイスのＲＦがオフになっているかに関係なく、又はＭＴＣデバイスのＲＦがオフになっており現在ＭＴＣデバイスへ割り当てられたＩＰアドレスが無いモード（活性、休止および非活性状態にある）にあるかに関係無く、外部デバイス（例えば、ＭＴＣサーバ）とＭＴＣデバイスとの間の高速通信が促進されることがさらに理解される。本明細書中に開示された信号交換を用いれば、ＭＴＣデバイスとの通信確立のためのトリガリクエストが受信されたときのＭＴＣデバイスの動作モードに関係無く、実際のシステムが（数ミリ秒（例えば、２〜１０ミリ秒）ミリ秒のオーダーで）ＭＴＣデバイスとの通信を短時間内に確立することが可能となる。
【００９９】
本明細書中に記載される開示の実施形態および他の実施形態ならびに機能的動作は、デジタル電子回路内またはコンピュータソフトウェア、ファームウェアまたはハードウェア（例えば、本明細書中に開示の構造およびその構造的均等物、またはこれらのうち１つ以上の組み合わせ）において実行することが可能である。開示の実施形態および他の実施形態は、１つ以上のコンピュータプログラム製品として実行することができる（すなわち、データ処理装置による実行またはデータ処理装置の動作の制御のためのコンピュータで読み出し可能な媒体上において符号化されたコンピュータプログラム命令の１つ以上のモジュール）。コンピュータで読み出し可能な媒体は、機械で読み出し可能な記憶デバイス、機械で読み出し可能な記憶基板、メモリデバイス、機械で読み出し可能な伝搬信号、これらのうち１つ以上の組み合わせを実行する複合物であり得る。「データ処理装置」という用語は、データ処理のための全ての装置、デバイスおよびマシンを包含する（例えば、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサまたはコンピュータ）。この装置は、ハードウェアに加えて、コンピュータプログラムの実行環境を生成するコードを含み得る（例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらのうち１つ以上の組み合わせを構成するコード）。伝搬信号は、人工的に生成された信号（例えば、マシンによって生成された電気信号、光信号または電磁信号）であり、適切な受信器装置への送信されるべき情報を符号化するために用いられる。
【０１００】
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、コードとして知られる）は、任意の形態のプログラミング言語で書くことができる（例えば、コンパイルまたは解釈された言語）。また、このようなコンピュータプログラムは、任意の形態での展開が可能である（例えば、スタンドアロンプログラムまたはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境における使用に適した他のユニットとしての展開）。コンピュータプログラムは、ファイルシステム中のファイルに必ずしも対応しなくてもよい。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語文書中に保存された１つ以上のスクリプト）を保持するファイルの一部中に保存してもよいし、当該プログラム専用に用いられる単一のファイル中に保存してもよいし、あるいは、複数の協調されたファイル（例えば、１つ以上のモジュール、サブプログラム、またはコードの一部を保存するファイル）中に保存してもよい。コンピュータプログラムを展開して、１つのコンピュータまたは複数のコンピュータ上において実行することができる。これら複数のコンピュータは、一箇所に配置されるか、または、複数の位置に分散配置され、通信ネットワークによって相互接続される。
【０１０１】
本明細書中に記載されるプロセスおよび論理フローは、１つ以上のプログラマブルプロセッサによって行われ得る。これら１つ以上のプログラマブルプロセッサは、１つ以上のコンピュータプログラム上において実行して、入力データ上において動作することおよび出力を生成することにより、機能を行う。プロセスおよび論理流れは、によって行ってもよいし、あるいは、装置を特殊目的用論理回路（例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）として実行してもよい。
【０１０２】
コンピュータプログラムの実行に適したプロセッサを例示的に挙げると、汎用マイクロプロセッサおよび特殊目的用マイクロプロセッサ双方があり、また、任意の種類のデジタルコンピュータの任意の１つ以上のプロセッサがある。一般的に、プロセッサは、リードオンリーメモリまたはランダムアクセスメモリまたはこれら双方から命令およびデータを受信し得る。コンピュータの本質的要素として、命令を実行するプロセッサと、命令およびデータを保存する１つ以上のメモリデバイスとがある。一般的に、コンピュータは、１つ以上の大量記憶デバイスをさらに含むか、または、データ保存のための１つ以上の大量記憶デバイスからのデータ受信または１つ以上の大量記憶デバイスへのデータ転送のために動作可能に接続される（例えば、磁気ディスク、光磁気ディスクまたは光ディスク）。しかし、コンピュータは、このようなデバイスを持たなくてもよい。コンピュータプログラム命令およびデータの保存に適したコンピュータで読み出し可能な媒体は、全ての形態の不揮発性メモリ、媒体およびメモリデバイスを含む（例えば、半導体メモリデバイス（例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイス）、磁気ディスク（例えば、内部ハードディスクまたはリムーバブルディスク）、光磁気ディスク、およびＣＤＲＯＭおよびＤＶＤ−ＲＯＭディスク）。プロセッサおよびメモリは、特殊目的用論理回路によって補完されるかまたは特殊目的用論理回路中に用いられ得る。
【０１０３】
本文書において、多数の特定の情報について述べてきたが、これらは特許請求の範囲に記載のまたは請求され得る本発明の範囲の制限として解釈されるべきではなく、特定の実施形態に特有の特徴の記述として解釈されるべきである。別個の実施形態の文脈において本明細書に記載される特定の特徴は、単一の実施形態中と組み合わせて実行することも可能である。あるいは、単一の実施形態の文脈中に記載される多様な特徴を複数の実施形態において別個にまたは任意の適切なさらなる組み合わせとして実行することも可能である。さらに、上記において特徴を特定の組み合わせおよびさらには特許請求の範囲において機能するものとして説明したが、請求される組み合わせからの１つ以上の特徴を組み合わせから実行することもでき、請求される組み合わせをさらなる組み合わせまたは別のさらなる組み合わせへ向けることができる。同様に、図面中に動作を特定の順序で記載しているが、このような動作を図示の特定の順序でまたは順次行う必要があると理解すべきではなく、あるいは、所望の結果を得るために図示の動作全てを行う必要があると理解すべきでもない。
【０１０４】
例および実施形態を数個のみ開示している。記載の例および実施形態において、変更例、改変例および向上例が可能であり、開示内容に基づいて、他の実施形態が可能である。
【図１】
2014515235.tif 000003
【図２】
2014515235.tif 000004
【図３】
2014515235.tif 000005
【図４】
2014515235.tif 000006
【図５】
2014515235.tif 000007
【図６】
2014515235.tif 000008
【図７】
2014515235.tif 000009
【図８】
2014515235.tif 000010
【図９】
2014515235.tif 000011
【図１０】
2014515235.tif 000012
【図１１】
2014515235.tif 000013
【図１２】
2014515235.tif 000014
【図１３】
2014515235.tif 000015
【図１４】
2014515235.tif 000016
【図１５】
2014515235.tif 000017
【図１６】
2014515235.tif 000018
【図１７】
2014515235.tif 000019
【図１８】
2014515235.tif 000020
【国際調査報告】
2014515235.tif 000021
2014515235.tif 000022