JP5970068B2 - Ｐｍｉｐプロトコル拡張 - Google Patents

Description

例としての実施形態は、ＰＭＩＰプロトコルの使用を改善することを対象とする。具体的には、例としての実施形態のいくつかは、ネットワークノードを提供することを対象とし、そのＰＭＩＰプロトコルの決定はネットワーク通信において使用されることになる。

無線通信ネットワークともいう典型的なセルラーシステムにおいて、移動局及び／又はユーザ機器ユニットとしても知られる無線端末は、１つ以上のコアネットワークへ無線アクセスネットワーク（ＲＡＮ）を介して通信する。無線端末は、“セルラー”フォンとしても知られるモバイルフォン、及び、例えば移動終端といった無線ケイパビリティを有するラップトップなどの、移動局又はユーザ機器ユニットであって、よって例えば、無線アクセスネットワークとの間で音声及び／又はデータを通信するポータブルな、ポケット型の、手持ち型の、コンピュータ内蔵型の、又は車載型の移動デバイスであり得る。

無線アクセスネットワークは、複数のセルエリアに分割される地理的なエリアをカバーし、各セルエリアは、基地局、例えば無線基地局（ＲＢＳ：Radio Base Station）によってサービスされる。無線基地局は、いくつかのネットワークにおいては、“ＮｏｄｅＢ”又は“Ｂノード”とも呼ばれ、本文書においては基地局とも呼ばれる。セルは、基地局サイトに据え付けられる無線基地局機器によって無線カバレッジを提供される地理的なエリアである。各セルは、ローカル無線エリア内のＩＤによって識別され、当該ＩＤは、当該セルにおいてブロードキャストされる。基地局は、当該基地局のレンジ内にあるユーザ機器ユニットと、無線周波数上で動作するエアインタフェース上で通信する。

無線アクセスネットワークのいくつかのバージョンにおいて、複数の基地局が、典型的には、例えば地上回線又はマイクロ波によって無線ネットワークコントローラ（ＲＮＣ）に接続される。基地局コントローラ（ＢＳＣ）と呼ばれることもある無線ネットワークコントローラは、そこに接続される複数の基地局の種々のアクティビティを、監督し及び協調させる。無線ネットワークコントローラは、典型的には、１つ以上のコアネットワークに接続される。

ＵＭＴＳ（Universal Mobile Telecommunications System）は、ＧＳＭ（Global System for Mobile Communications）から進化した第３世代の移動体通信システムであり、広帯域符号分割多重アクセス（ＷＣＤＭＡ：Wideband Code Division Multiple Access）というアクセス技術に基づいて、改善された移動体通信サービスを提供することが意図される。ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）は、本質的に、ユーザ機器ユニット（ＵＥ）について広帯域符号分割多重アクセスを用いる無線アクセスネットワークである。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＵＴＲＡＮ及びＧＳＭベースの無線アクセスネットワーク技術をさらに進化させることに取り組んでいる。ＬＴＥ（Long Term Evolution）は、ＥＰＣ（Evolved Packet Core）と共に、３ＧＰＰファミリーへの最新の追加版である。

プロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６）は、ＩＥＴＦにより標準化された、ネットワークベースのモビリティ管理プロトコルである。ＰＭＩＰｖ６は、ＷｉＭＡＸ、３ＧＰＰ、３ＧＰＰ２及びＷＬＡＮベースのアクセスアーキテクチャなどの多様なアクセス技術を収容する、共通的な及びモバイルコアネットワークに非依存のアクセス技術である。

ここで提示される例としての実施形態の少なくとも１つの例としての目的は、ＰＭＩＰｖ６通信を改善することである。ここで提示される例としての実施形態のコンセプトは、（ＰＭＩＰドラフト及びＰＭＩＰ ＲＦＣの両方をサポートし得る）ＳＧＷなどのＭＡＧノード又はＬＭＡが、ピアノード、即ちＬＭＡ／ＭＡＧと通信するためにどのＰＭＩＰプロトコルスタックが使用されるべきかを決定することを可能とする、ＰＭＩＰプロトコルスタック内の仕組みを提供することである。ここで提示される例としての実施形態のいくつかは、ＰＭＩＰ ＲＦＣ及びＰＭＩＰドラフトの間の下位非互換性の課題を解決することを対象とし得る。

例としての実施形態は、トランスポートネットワークがＩＰｖ４ネットワークであり、ノードがピアノードに向けて通信、例えば、プロキシバインディング更新メッセージの送信を開始するとき、サポートする双方のＰＭＩＰプロトコル（ＰＭＩＰ ＲＦＣ又はＰＭＩＰドラフト）スタックのノード、例えば、ＭＡＧ／ＬＭＡのための仕組みを含むことができる。当該仕組みは、ピアノードとの全く最初の通信、又は、どのＰＭＩＰプロトコルをピアノードがサポートしているかをピアノードが知らない場合において、メッセージを２つのフォーマット、１つは、ＰＭＩＰドラフト、即ちＰＭＩＰｖ６ ｍｅｓｓａｇｅ／ＩＰｖ６／ｗｉｔｈ ＩＰｖ４又はＩＰｖ４−ＵＤＰカプセル化を踏まえて、もう１つはＰＭＩＰ ＲＦＣ、即ちＰＭＩＰｖ６／ＵＤＰ／ＩＰｖ４に沿って送信することを含むことができる。したがって、ピアノードが１つのＰＭＩＰプロトコルスタックをサポートしている場合、ピアノードはメッセージのうち１つに答えることのみ可能であり、ピアノードが両方のＰＭＩＰプロトコルスタックをサポートしている場合、ノードはＲＦＣバージョンのメッセージにのみ応答してもよい。上記の仕組みによれば、ＰＭＩＰドラフト又はＰＭＩＰ ＲＦＣいずれかのプロトコルスタックが、その後の通信に対して選択されることができる。

結果として、例としての実施形態のいくつかは、第１のネットワークピアノードにおいて、第２のネットワークピアノードにより使用されるＰＭＩＰｖ６制御プレーンを判定するための方法を対象とすることができる。当該第１及び第２のネットワークピアノードは、インターネットプロトコルバージョン４（ＩＰｖ４）トランスポートネットワーク内にある。当該方法は、少なくとも１つの制御プレーンフォーマットで、少なくとも１つの通信メッセージを第２のネットワークピアノードへ送信することを含む。当該方法は、当該少なくとも１つの通信メッセージに関する少なくとも１つの通信レスポンスを受信することをさらに含む。当該方法はまた、当該少なくとも１つの通信レスポンスに基づいて、第２のネットワークピアノードにより利用されるＰＭＩＰｖ６制御プレーンのバージョンを判定することを含む。

例としての実施形態のいくつかは、第２のネットワークピアノードにより使用されるＰＭＩＰｖ６制御プレーンを判定するための第１のネットワークピアノードを対象とすることができる。当該第１及び第２のネットワークピアノードは、ＩＰｖ４トランスポートネットワーク内にある。当該第１のネットワークピアノードは、少なくとも１つの制御プレーンフォーマットで、少なくとも１つの通信メッセージを第２のネットワークピアノードへ送信するように構成される送信回路を含む。当該第１のネットワークピアノードは、当該少なくとも１つの通信メッセージに関する少なくとも１つの通信レスポンスを受信するように構成される受信回路をさらに含む。当該第１のネットワークピアノードはまた、当該少なくとも１つの通信レスポンスに基づいて、第２のネットワークピアノードにより利用されるＰＭＩＰｖ６制御プレーンのバージョンを判定するように構成される処理回路を含む。

上述した内容は、添付図面に描いたような例としての実施形態の以下のより具体的な説明から明らかとなるであろう。添付図面において、同類の参照符号は、様々な図を通じて同じ部分を指す。図面は必ずしも等尺ではなく、代わりに例としての実施形態を描くに際して強調がなされる。

移行パスの具体例である。 移行パスの具体例である。 移行パスの具体例である。 例としての実施形態のいくつかによる、ネットワークノードの概略図である。 図４のネットワークノードの例としての動作を示すフロー図である。

［定義］
３ＧＰＰ Third Generation Partnership Project
３ＧＰＰ２ Third Generation Partnership Project 2
ＢＮＧ Broadband Network Gateway
ＢＳＣ Base Station Controller
ＤＮＳ Domain Name System
ＥＰＣ Evolved Packet Core
ｅＰＤＧ Evolved Packet Data Gateway
ＧＰＲＳ General Packet Radio Service
ＧＳＭ Global System for Mobile Communications
ＧＴＰ GPRS Tunneling Protocol
ＧＷ Gateway
ＨＲＰＤ High Rate Packet Data
ＨＳ ＧＷ HRPD Serving Gateway
ＩＥ Information Element
ＩＥＴＦ Internet Engineering Task Force
ＩＰｖ４ Internet Protocol version 4
ＩＰｖ６ Internet Protocol version 6
ＬＭＡ Local Mobility Anchor
ＬＴＥ Long Term Evolution
ＭＡＧ Mobile Access Gateway
ＭＭＥ Mobility Management Entity
ＰＤＮ Packet Data Network
ＰＧＷ PDN Gateway
ＰＬＭＮ Public Land Mobile Network
ＰＭＩＰ Proxy Mobile Internet Protocol
ＰＭＩＰｖ６ Proxy Mobile Internet Protocol version 6
ＲＡＮ Radio Access Network
ＲＢＳ Radio Base Station
ＲＮＣ Radio Network Controller
Ｓ４−ＳＧＳＮ S4 Serving GPRS Support Node
ＳＧＷ Serving Gateway
ＵＥ User Equipment
ＵＤＰ User Datagram Protocol
ＵＭＴＳ Universal Mobile Telecommunications System
ＵＴＲＡＮ UMTS Terrestrial Radio Access Network
ＷＣＤＭＡ Wideband Code Division Multiple Access
ＷｉＭＡＸ Worldwide Interoperability for Microwave Access
ＷＬＡＮ Wireless Local Area Network

例示的な実施形態の完全な理解を提供するために、限定ではなく説明の目的で、以下の説明において、固有のコンポーネント、エレメント、技法などの特定の詳細が説明される。しかしながら、例としての実施形態は、それら特定の詳細から離れた他のやり方で実践されてもよい。他の例において、よく知られた方法及びエレメントの詳細な説明は、例としての実施形態の説明を曖昧にしないために省略される。

ここで提示される例としての実施形態を説明する手段として、問題が最初に識別され、議論されるであろう。３ＧＰＰ ＣＴ４は、Ｒｅｌ−９以降についてのＲＦＣを調整するために、ＴＳ２９．２７５のＰＭＩＰのＣプレーンプロトコルスタックを更新することに合意した。Ｒｅｌ−９のＩＥＴＦドキュメントへの参照は、既にＩＥＴＦドラフト“IPv4 Support for Proxy Mobile IPv6”、draft-ietf-netlmm-pmip6-ipv4-support-17からＲＦＣ５８４４に更新されている。しかしながら、Ｃ−プレーンプロトコルスタックのための変更は反映されていない。

同時に、ＩＰｖ４トランスポートネットワーク上でＰＭＩＰｖ６を使用しているとき、ＲＦＣがドラフトへの下位互換性がないことにＣＴ４は気付いた。ドラフトバージョンでは、パス上のＮＡＴが検出されたか否かによってＵＤＰカプセル化が任意である、ＮＡＴトラバーサルが推奨された。ＰＭＩＰ ＲＦＣでは、ＵＤＰカプセル化は必須となり、内側のＩＰｖ６ヘッダは除去される。したがって、ドラフトバージョンのＰＭＩＰノードは、ＲＦＣバージョンのＰＭＩＰノードと通信できない。さらに、ドラフトバージョンのＰＭＩＰプロトコルスタックは、ＩＥＴＦによってもはやサポートされていないため、ドラフトバージョンベースのＰＭＩＰオペレータは、ドラフトバージョンのＰＭＩＰノードを永久に保つことができない。しかしながら、インターワーキングの課題もまた、ＲＦＣベースのＰＭＩＰネットワークに移行するドラフトバージョンベースのＰＭＩＰネットワークにとって問題となっている。したがって、Ｒｅｌ−８からＲｅｌ−９以降へ仕様を更新するための、ある仕組み又は下位互換の方法が必要であった。

ＧＷ選択のためのＤＮＳプロシージャを拡張するために、３ＧＰＰ ＣＴ４寄書のＣ４−１１１２０５に含まれるＤＮＳベースのソリューションが、ＮＴＴドコモによって提案され、ドラフトスタイルのＰＭＩＰ制御プレーンケイパビリティを反映する既存の“Service Parameters”、“x-3gpp-sgw:x-s8-pmip”、“x-3gpp-sgw:x-s5-pmip”、“x-3gpp-pgw:x-s5-pmip”に続いて、新たなサービスパラメータ“x-3gpp-sgw:x-s5-pmip2”、“x-3gpp-sgw:x-s8-pmip2”、“x-3gpp-pgw:x-s5-pmip2”が、ＲＦＣスタイルのＰＭＩＰ制御プレーンケイパビリティを示すために導入された。上記の新たなサービスパラメータを導入することによって、ＭＭＥ／Ｓ４−ＳＧＳＮは、同じスタイルのＰＭＩＰプロトコルスタックを用いてＳＧＷ／ＰＧＷを選択することが可能である。

以下、改善されたＰＭＩＰ通信のための様々な方法が議論されるであろう。

［移行パス−非ローミングの場合］
これらのＰＭＩＰドラフトベースのノード、例えばＳＧＷ／ＰＧＷ／ｅＰＤＧを、ＰＭＩＰ ＲＦＣベースにアップグレードするための移行パスについて、ここで議論する。

選択肢１：全てのＰＭＩＰノードをＲＦＣベースのＰＭＩＰプロトコルスタックに一夜中にアップグレードする。
非常に短時間のうちに、全てのＰＭＩＰノード上でドラフトベースからＲＦＣベースへソフトウェアをアップグレードする。限られたシステムの中断時間で、ネットワークは新たなＰＭＩＰプロトコルスタックに同時に移行されることができる。
長所：
・ＰＭＩＰでないノードに影響がない
・迅速な移行パス（１ステップの移行）
短所：
・限られたシステムの中断時間
・全てのノードが一緒にアップグレードされなければならない
結論：
・別途の移行ソリューションが必要ない

選択肢２：２ステップの移行
この選択肢を用いると、オペレータは、ドラフトベースのＰＭＩＰノードをより長期間保つことができる。ネットワークに新たなＰＭＩＰノードを追加する時、新たなＰＭＩＰノード（ＬＭＡ及び／又はＭＡＧ）は、ＲＦＣベース及びドラフトベースの両方のＰＭＩＰプロトコルスタックを同時にサポートできなければならない。

図１に示すように、ＬＭＡ１及びＭＡＧ１は、ドラフトベースのＰＭＩＰノードである。移行パスのステップ１は、双方のスタックがサポートされているＬＭＡ２及びＭＡＧ２を追加することである。両方のＭＡＧは、２つのＬＭＡと問題なく通信することができる。

この選択肢を用いると、追加された新たなＰＭＩＰノードは、異なるＰＤＮ若しくはロードシェアリングの供給、又はシステム冗長化等の目的で、既存のＰＭＩＰネットワークの一部となることができる。ＭＡＧ１及びＭＡＧ２間のカバレージには、モビリティの課題はない。

しかしながら、全く最初の時における通信の問題を回避するため、特定のＬＭＡに全く最初のＰＭＩＰメッセージを送信する前に、新たなＭＡＧにおいて指標が必要であるかもしれない。この指標は、モビリティプロシージャにおいてターゲットのシステムに転送される必要もあるかもしれない。このステップで、指標は、ドラフトプロトコルスタックが適用されるべきか、又は何らかのプロトコルスタックが適用されるべきかのいずれかを、ＭＡＧ２に知らせることとなる。

図２に示された移行パスのステップ２は、ドラフトベースのＰＭＩＰノードが完全に除去（又はアップグレード）されたときに、ＲＦＣスタックがサポートされるＬＭＡ３及びＭＡＧ３を追加することである。これは、ＬＭＡ１／ＭＡＧ１及びＬＭＡ３／ＭＡＧ３の間のインターワーキング及びモビリティの問題を回避するためである。

ステップ１と同様、全く最初の時における通信の問題を回避するために、特定のＬＭＡに全く最初のＰＭＩＰメッセージを送信する前に、ＭＡＧにおいて指標が必要であるかもしれない。この指標は、モビリティプロシージャにおいてターゲットのシステムに転送される必要もあるかもしれない。このステップで、指標は、ＲＦＣプロトコルスタックが適用されるべきか、又は何らかのプロトコルスタックが適用されるべきかのいずれかをＭＡＧ２に知らせることとなる。

長所：
・全ての新たなＰＭＩＰノード及び古いＰＭＩＰノードが問題なく互いに通信することができる。
・ＰＭＩＰノードのアップグレードが１つずつ行われることができる。
・システムの中断時間がない。
短所：
・移行パスがより長い。
・２ステップの移行。
・ステップ１で、新たに開発されるＰＭＩＰノードが、ドラフトベース及びＲＦＣベースの両方のプロトコルスタックを同時にサポートしなければならない。

選択肢３：ＲＦＣスタックのみがサポートされる新たなＰＭＩＰノード（ＬＭＡ及び／又はＭＡＧ）を追加する。
この選択肢を用いると、オペレータは、ドラフトベースのＰＭＩＰノードをより長期間保つことができる。ネットワークに新たなＰＭＩＰノードを追加するとき、新たなＰＭＩＰノード（ＬＭＡ及び／又はＭＡＧ）は、ＲＦＣベースのＰＭＩＰプロトコルスタックのみをサポートする能力を有することができる。

図３に示すように、ＬＭＡ１及びＭＡＧ１は、ドラフトベースのＰＭＩＰノードである。ＬＭＡ２及びＭＡＧ２は、ＲＦＣベースのみの新たなＰＭＩＰノードである。サポートされるＰＭＩＰプロトコルスタックの非互換性の課題により、ＬＭＡ１とＭＡＧ２との間、又はＬＭＡ２とＭＡＧ１との間に通信はない。

この選択肢を用いると、追加された新たなＰＭＩＰノードは、既存のＰＭＩＰネットワークから分離されたＰＭＩＰネットワークとなる。ＰＭＩＰドラフトベースのノードが、ＲＦＣ及びドラフト両方をサポートするか、又はＲＦＣのみをサポートするかのいずれかにアップグレードするまで、２つのネットワーク間にインターワーキング及びモビリティはない。ＧＷ選択プロシージャにおいて別途の指標が追加されなければならない。この指標は、モビリティプロシージャにおいてターゲットのシステムに転送される必要もあるかもしれない。

指標は、ユーザ機器ごとを基準としなければならない。
長所：
・システムの中断時間がない。
・１ステップの移行。
・新たなＰＭＩＰノードは、３ＧＰＰから最終的には除去されることとなるＰＭＩＰドラフトをサポートする必要がない。
短所：
・メンテナンスすべき２つの分離されたネットワーク。
・２つのネットワーク間にロードシェアリング、インターワーキング及びモビリティがない。

［分析］
選択肢１は、簡単で迅速なソリューションである。それはまた、いかなる標準化作業も必要としない。選択肢３は、インターワーキング及びモビリティの課題、並びに２つのネットワークの同時の保守作業に起因して、あり得そうにない。

選択肢２は、スムースな移行パスを提供するため、非常に可能性がある。選択肢２が可能性のある移行パスであると仮定しうる場合、この新たな指標は、２、３の異なる方法で実装されうる。

ソリューション１：ＭＡＧ２におけるローカル構成
・移行ステップ１で、ＭＡＧ２は、ドラフトバージョンを有効にして構成されるものとする。
・移行ステップ２で、ＭＡＧ２は、ＲＦＣバージョンを有効にして再構成されるものとする。
長所：
・標準化の影響はない
・ＰＭＩＰでないいかなるノードにも影響はない
・コストが低い
短所：
・ＳＧＷにおける再構成のためのネットワーク管理コスト

ソリューション２：ＭＭＥにより送信される新たなＧＴＰ指標
・移行ステップ１の前に、ネットワーク内の全てのＭＭＥが、新たなＧＴＰ指標をサポートするためにアップグレードされなければならない。
・移行ステップ１で、クリエイトセッションリクエストメッセージにおいて、ＭＭＥは“ドラフトバージョンを使用するものとする”という新たな指標を一緒にＭＡＧ２に送信する。
・移行ステップ２で、クリエイトセッションリクエストメッセージにおいて、ＭＭＥは、“ＲＦＣバージョンを使用するものとする”という新たな指標を一緒にＭＡＧ２に送信する。
長所：
・ＭＡＧでの再構成がない
短所：
・ＧＴＰに標準化の影響がある
・全てのＭＭＥが、移行開始前に最初にアップグレードされなければならない。
・ＭＭＥにおける再構成のためのネットワーク管理コスト
・別途のコスト

ソリューション３：ＭＭＥにより送信される新たなＧＴＰ指標と新たなＤＮＳネームペアリング機能
・移行ステップ１の前に、ネットワーク内の全てのＭＭＥは、新たなＧＴＰ指標をサポートするためにアップグレードされなければならない。
・移行ステップ１で、“ドラフトバージョンＰＭＩＰ”のみが、ＭＭＥ ＤＮＳペアリングプロシージャで選択されるものとする。そして、クリエイトセッションリクエストメッセージにおいて、ＭＭＥは、“ドラフトバージョンを使用するものとする”という新たな指標を一緒にＭＡＧ２に送信する。
・移行ステップ２の前に、新たなＰＭＩＰ ＤＮＳネームのための新たなＤＮＳ構成
・移行ステップ２で、“ＲＦＣバージョンＰＭＩＰ”のみがＭＭＥ ＤＮＳペアリングプロシージャで選択されるものとする。そして、クリエイトセッションリクエストメッセージにおいて、ＭＭＥは、“ＲＦＣバージョンを使用するものとする”という新たな指標を一緒にＭＡＧ２に送信する。
長所：
・ＭＡＧでの再構成がない
短所：
・ＧＴＰに標準化の影響がある
・全てのＭＭＥが、移行開始前に最初にアップグレードされなければならない
・下位互換でない可能性がある、新たなＭＭＥ ＤＮＳペアリングプロシージャ
・ＭＭＥ及びＤＮＳでの再構成のためのネットワーク管理コスト
・別途のコスト

ソリューション４：ソリューション３と同じだが、移行ネットワークにおいて、２つの新たなＤＮＳネームを用いる。
・このソリューションを用いると、現在のＤＮＳネームは、標準では変化しない。２つの新たなＰＭＩＰ ＤＮＳネームが、Ｓ５インタフェース：s5-pmip-rfc及びs5-pmip-draftのために追加される。
・２つの新たなＰＭＩＰ ＤＮＳネームは、移行ネットワーク内でのみ使用される。これにより、既存のＲ８／Ｒ９／Ｒ１０のＭＭＥの実装に対するいかなる影響も回避することができる。

［例としての実施形態への導入］
選択肢２は、スムースな移行パスを提供するものとして、非常に可能性がある。しかしながら、移行ソリューションが必要となる可能性がある。これは、ＰＭＩＰメッセージをＬＭＡに送信する前に、どのＰＭＩＰを適用するものとされているのかをＭＡＧ２が知る必要があるからである。同じＰＭＩＰプロトコルスタックをサポートしているＳＧＷ／ＰＧＷノードのセットをＭＭＥが選択することを可能にするために新たなサービスパラメータが導入される、ＤＮＳベースのソリューションを使用することが可能であろう。しかしながら、ローミング及びＳＧＷ間のモビリティプロシージャ、３ＧＰＰと非３ＧＰＰとの間のプロシージャをサポートするために、完全なＤＮＳソリューションは、多くのプロトコル、例えば、ＤＮＳ／ＧＴＰ／Ｄｉａｍｅｔｅｒプロトコルを更新する必要があり、このことは、Ｓ１１／Ｓ４／Ｓ３／Ｓ１０／Ｓ１ Ｓ６ａ／Ｓ６ｄ／ＳＷｘなどの多くのインタフェースに影響を与える。より重要なこととしては、ＰＭＩＰベースのローミングをサポートするために、（１つのＰＭＩＰ ＲＦＣのみが配備されているサービングネットワークに位置している場合でさえ、それでも両方のＰＭＩＰスタックが配備されている問題のあるＨｏｍｅＰＬＭＮとローミング協定を有する）ＭＭＥは、新たなＰＭＩＰネーミングをサポートしなければならず、ＧＴＰｖ２における新たなＰＭＩＰプロトコルスタックＩＥをサポートしなければならないという事実であるが、これは適当ではない。他方、移行の間、中間ステップとして双方のスタックをサポートすることは回避することができず、したがって、ＰＭＩＰプロトコルスタック上の純粋なエンハンスメントである他の有益なソリューションが利用され得るであろう。

［ＭＡＧ関連のプロシージャ上の例としての更新］
例としての実施形態のいくつかは、ＭＡＧ関連のプロシージャに対する更新を含むことができる。上記で指定されたようにＭＡＧノードが両方のＰＭＩＰプロトコルスタックをサポートし、トランスポーテーションネットワークでＩＰｖ４が用いられているとき、ピアノードとの最初の通信において、又はピアノードがどのＰＭＩＰプロトコルをサポートしているかをＭＡＧノードが知らない場合に、異なるＰＭＩＰプロトコルスタックを用いて２つのフォーマットで、ＭＡＧノードはＰＭＩＰメッセージ、例えば、プロキシバインディング更新をＬＭＡに送信する。これは、どのＰＭＩＰプロトコルスタックがピアＬＭＡノードによりサポートされているかをＭＡＧが知らない場合に行われる。応答メッセージが２つのフォーマットで受信された場合、ＲＦＣベースのみが、考慮されてもよい。

［ＬＭＡ関連のプロシージャ上の例としての更新］
例としての実施形態のいくつかは、ＬＭＡ関連のプロシージャに対する更新を含むことができる。上記で指定されたようにＬＭＡノードが両方のＰＭＩＰプロトコルスタックをサポートし、トランスポーテーションネットワークでＩＰｖ４が用いられており、かつ、同一のＭＡＧから２つのフォーマットでＰＭＩＰメッセージを受信するとき、ＬＭＡノードは応答メッセージをＲＦＣフォーマットでのみ送信してもよい。

［ハートビートメカニズム上の例としての更新］
例としての実施形態のいくつかは、ハートビートメカニズム上の更新を含むことができる。ハートビートメカニズムもまた、どのＰＭＩＰプロトコルスタックが使用されるべきかをピアノードに知らせるのに用いられることができる。

上記で指定されたように、ＭＡＧ又はＬＭＡノードが両方のＰＭＩＰプロトコルスタックをサポートし、トランスポーテーションネットワークでＩＰｖ４が用いられているとき、ピアノードとの最初の通信（又は、ピアノードがどのＰＭＩＰプロトコルをサポートしているかをＭＡＧ若しくはＬＭＡノードが知らない場合）において、ＭＡＧ又はＬＭＡノードは、ＰＭＩＰドラフト及びＰＭＩＰ ＲＦＣに対応する２つのフォーマットで、ハートビートリクエストメッセージを送信することができる。

上記で指定されたように、ＭＡＧ又はＬＭＡノードが両方のＰＭＩＰプロトコルスタックをサポートし、トランスポーテーションネットワークでＩＰｖ４が用いられているとき、同一のピアノードからＰＭＩＰドラフト及びＰＭＩＰ ＲＦＣに対応する２つのフォーマットでハートビートリクエストメッセージが受信された場合、ピアノードは、ＲＦＣフォーマットでのみハートビートレスポンスを応答してもよい。応答メッセージが２つのフォーマットで受信された場合、ＲＦＣベースのみが考慮されてもよい。

［アップグレードメカニズムの例］
いくつかの例としての実施形態は、ＰＭＩＰトンネル管理プロシージャにおけるアップグレードメカニズムを対象とすることができる。上記で指定されたように、ＭＡＧ又はＬＭＡノードが両方のＰＭＩＰプロトコルスタックをサポートし、トランスポーテーションネットワークでＩＰｖ４が用いられているとき、ソフトウェアのアップグレード、例えば、ＲＦＣベースＰＭＩＰバージョンへのアップグレードの場合、ＭＡＧ又はＬＭＡノードは、リスタートカウンタを増加させることができる。リスタートカウンタは、どのＰＭＩＰバージョンをＭＡＧ又はＬＭＡノードがサポートしているかをハートビートメカニズムがピアノードに知らせるトリガとなる、

［例としてのノード構成］
図４は、ここで議論される例としての実施形態のいくつかを包含しうるネットワークノード（例えば、ＭＡＧ、ＬＭＡ、及び／又はピアノード）の一例を示す。ネットワークノード１４は、任意数の通信ポート又は回路、例えば、受信回路２０及び送信回路２４を含むことができる。通信ポート又は回路は、任意の形式の通信データ又は命令を受信及び送信するように構成されることができる。ネットワークノード１４は、単一のトランシーバポート又は回路を代替的に含むものであってもよいことが理解されるべきである。通信又はトランシーバポート又は回路は、当技術分野で既知の任意の入力／出力通信ポート又は回路の形式であってもよいことがさらに理解されるべきである。

ネットワークノード１４は、少なくとも１つのメモリユニット２６をさらに含むことができる。メモリユニット２６は、任意の種類及び／又は実行可能なプログラム命令の、受信され、送信され、及び／又は測定されたデータを格納するように構成されることができる。メモリユニット２６は、任意の適切なタイプのコンピュータ読み取り可能なメモリであってもよく、揮発性及び／又は不揮発性タイプのものであってもよい。

ネットワークノード１４は、また、ＳＳＬ１１で受信された情報に基づいて複数の光学的ルートを確立するように構成されることができる、処理回路２２を含むことができる。処理回路２２は、任意の適切なタイプの計算ユニット、例えば、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ＦＰＧＡ（field programmable gate array）、又はＡＳＩＣ（application specific integrated circuit）であってもよいことが理解されるべきである。また、処理回路２２は、単一のユニットとして含まれる必要はないことが理解されるべきである。処理回路２２は、任意数のユニット又は回路として含まれてもよい。

［例としてのネットワークノードの動作］
図５は、図４のネットワークノードのような第１のネットワークピアノードの、例としての動作を示すフロー図である。例としての動作フローは、第１のネットワークピアノードにおいて、第２のネットワークピアノードにより使用されるＰＭＩＰｖ６制御プレーンを判定するための方法を対象とする。第１及び第２のネットワークピアノードは、ＩＰｖ４トランスポーテーションネットワーク内にある。第１及び第２のネットワークピアノードは、図１〜３で説明したＭＡＧ／ＬＭＡノードのようなＭＡＧ／ＬＭＡノードであってもよい。例としての実施形態のいくつかによれば、ＬＭＡノードはＰＧＷであってもよいことが理解されるべきである。例としての実施形態のいくつかによれば、ＭＡＧノードはＳＧＷ、ｅＰＤＧ（Evolved Packet Data Gateway）、ＨＳＧＷ（HRPD Serving Gateway）、及び／又はＢＮＧ（Broadband Network Gateway）であってもよい。

［動作５０］
第１のネットワークピアノードは、少なくとも１つの制御プレーンフォーマットで、少なくとも１つの通信メッセージを第２のネットワークピアノードに送信する（５０）。送信回路２４は、少なくとも１つの制御プレーンフォーマットで、少なくとも１つの通信メッセージを第２のネットワークピアノードに送信するように構成される。制御プレーンフォーマットは、制御プレーンＡ又は制御プレーンＢフォーマットであってもよいことが理解されるべきである。

例としての実施形態のいくつかによれば、第１のネットワークピアノードは、ＭＡＧノードであり、第２のネットワークピアノードは、ＬＭＡノードである。そのような例としての実施形態では、少なくとも１つの通信が、ハートビートメッセージであってもよく、又はプロキシバインディンク更新リクエストであってもよい。

例としての実施形態のいくつかによれば、第１のネットワークピアノードは、ＬＭＡノードであり、第２のネットワークピアノードは、ＭＡＧノードである。そのような例としての実施形態では、少なくとも１つの通信が、ハートビートメッセージである。

［例としての動作５２］
例としての実施形態のいくつかによれば、少なくとも１つの通信メッセージは、第１及び第２の制御タイプ（例えば、制御プレーンフォーマットＡ及び制御プレーンフォーマットＣ）のそれぞれ第１及び第２の通信メッセージであってもよい。送信５０は、第２のネットワークピアノードに第１及び第２の通信メッセージを同時に送信すること（５２）をさらに含むものであってもよい。送信回路２４は、第１及び第２の通信メッセージを同時に送信するように構成されてもよい。

［例としての動作５４］
例としての実施形態のいくつかによれば、少なくとも１つの通信メッセージは、第１の制御タイプの第１の通信メッセージであってもよい。第２のネットワークピアノードからのレスポンスが時間ピリオドの間に受信されない場合、少なくとも１つの通信レスポンスが、第１の通信レスポンスである。第１の通信レスポンスは、第２の制御プレーンタイプの第２の通信メッセージが送信される必要があるという、第１の内部的な通知である。例えば、第２のネットワークピアノードからのレスポンスを受信しないことは、第１の通信メッセージが送信された第１の制御タイプを、第２のネットワークピアノードがサポートしていないことの結果である可能性がある。第１の内部的な通知の受信は、第１のネットワークピアノード内のユーザプログラム可能なルールに基づくものであってもよい。上記のシナリオは、例としての動作５４、５８、６２及び６４を説明するために使用されることができると理解されるべきである。

したがって、例としての実施形態のいくつかによれば、第１のネットワークピアノードは、第２の制御プレーンタイプの第２の通信メッセージを送信してもよい（５４）。送信回路２４は、第２の制御プレーンタイプの第２の通信メッセージを送信してもよい。

［動作５６］
第１のネットワークピアノードは、少なくとも１つの通信メッセージ（例えば、第１の通信メッセージ及び／又は第２の通信メッセージ）に関する少なくとも１つの通信レスポンス（例えば、第１の通信レスポンス及び／又は第２の通信レスポンス）をそれぞれ受信する（５６）ようにさらに構成される。受信回路２０は、少なくとも１つの通信メッセージに関する少なくとも１つの通信レスポンスを受信するように構成される。

［例としての動作５８］
複数の通信メッセージが送信される（例えば、例としての動作５２）、又は予め決定される時間ピリオドの後で第２の通信メッセージが送信される（例えば、例としての動作５４）例としての実施形態において、第１のネットワークピアノードは、第２の通信メッセージに関する第２の通信レスポンスを受信し得る（５８）。受信回路は、第２の通信メッセージに関する第２の通信レスポンスを受信するように構成されてもよい。

［動作６０］
第１のネットワークピアノードは、さらに、少なくとも１つの通信レスポンスに基づいて、第２のネットワークピアノードにより利用されるＰＭＩＰｖ６制御プレーンのバージョンを判定する（６０）。処理回路２２は、少なくとも１つの通信レスポンスに基づいて、第２のネットワークピアノードにより利用されるＰＭＩＰｖ６制御プレーンのバージョンを判定するように構成される。

［例としての動作６２］
例としての実施形態のいくつかによれば、第２のネットワークピアノードからのレスポンスが予め決定される時間ピリオド内に受信されない場合、第２の通信レスポンスは、第２のネットワークノードとの通信が可能でないことを示す第２の内部的な通知である。したがって、判定６０は、ＰＭＩＰｖ６制御プレーンがヌル値であると判定すること（６２）をさらに含むことができる。処理回路２２は、ＰＭＩＰｖ６制御プレーンがヌル値であると判定するように構成されてもよい。

このことは、第２のネットワークピアノードが現在利用可能でないことを意味する。したがって、例としての実施形態のいくつかによれば、一時的なパスの失敗を回避するために、第１のネットワークピアノードは、第２の及び／又は第１の通信メッセージの再送信を試みてもよい。

［例としての動作６４］
例としての実施形態のいくつかによれば、第２の通信レスポンスが第２のネットワークピアノードから受信された場合、判定６０は、第２の制御タイプ（例えば、第２の通信メッセージの制御タイプ）であるようにＰＭＩＰｖ６制御プレーン値を判定すること（６４）をさらに含むことができる。処理回路２２は、第２の制御タイプであるようにＰＭＩＰｖ６制御プレーン値を判定するように構成される。

［例としての動作６６］
例としての実施形態のいくつかによれば、少なくとも１つの通信レスポンスが第２のネットワークピアノードから受信される場合、判定６０は、少なくとも１つの通信メッセージの（又は、関連する）少なくとも１つの制御プレーンフォーマットであるようにＰＭＩＰｖ６制御プレーン値を判定すること（６６）をさらに含むことができる。処理回路２２は、少なくとも１つの通信メッセージの少なくとも１つの制御プレーンフォーマットであるようにＰＭＩＰｖ６制御プレーン値を判定するように構成されてもよい。

例としての実施形態のいくつかによれば、少なくとも１つの制御プレーン値は、制御プレーンＡであってもよい。例えば、例としての実施形態のいくつかによれば、システムリソースを節約するために、おそらく１つの通信メッセージだけが一度に送信されうる。したがって、送信は階層的方法で実行されてもよい。例としての実施形態のいくつかによれば、制御プレーンタイプＡの通信メッセージが最初に送信されてもよい。通信レスポンスが受信されない場合、第１のネットワークピアノードが、その後制御プレーンタイプＢの通信メッセージを送信してもよい。

［例としての動作６８］
例としての実施形態のいくつかによれば、（例えば、複数又は２つの通信メッセージが送信された後に）複数の通信レスポンスが第２のネットワークピアノードから受信された場合、判定６０は、デフォルトの制御プレーンフォーマットであるようにＰＭＩＰｖ６制御プレーン値を判定すること（６８）をさらに含むことができる。例としての実施形態のいくつかによれば、デフォルトの制御プレーンフォーマット値は、制御プレーンＡであってもよい。処理回路２２は、デフォルトの制御プレーンフォーマットであるようにＰＭＩＰｖ６制御プレーン値を判定するように構成されてもよい。

［結論］
このように、例としての実施形態は、ここで述べた様々な問題を解決する。例としての実施形態に関連する問題、課題、考慮事項、又は利点の非限定的な例は、以下の通りである。
ａ．最終的には、３ＧＰＰ ＰＭＩＰプロトコルは、ＩＥＴＦ ＲＦＣに沿ったものでなければならず、したがって、いかなるＰＭＩＰドラフトベースの３ＧＰＰノードも、ＰＭＩＰ ＲＦＣをサポートするようにアップグレードされなければならない。
ｂ．例としての実施形態は、全ての可能なシステムダウンタイムを最小限に抑えることができるはずである。
ｃ．例としての実施形態は、完全に異なるプロトコルスタックに基づく他のネットワークエレメント、例えばＭＭＥ／ＨＳＳへの影響を最小化するはずである。
ｄ．例としての実施形態は、ＰＭＩＰベースのノードが配備されていないかまたはＰＭＩＰ ＲＦＣノードのみが配備されている他のオペレータのネットワークに影響を及ぼしてはならない。
ｅ．例としての実施形態は、さらに、他のネットワークエレメント及び／又はプロトコルスタックへのいかなる影響もなく、ＰＭＩＰの下位非互換の課題を解決する。

例としての実施形態のいくつかは、ネットワークノードにおけるＰＭＩＰプロトコル拡張のための方法を含むことができ、当該ネットワークノードは、ＩＰｖ４ネットワーク内にあることができる。当該方法は、ピアノードに向けた通信を開始するステップ、及びピアノードに２つのフォーマットでＰＭＩＰメッセージを送信するステップを含むことができる。上述した例としての実施形態は、ＰＭＩＰメッセージをＰＭＩＰドラフト及びＰＭＩＰ ＲＦＣフォーマットで送信することをさらに含むことができる。

上述した例としての実施形態のうちいずれかは、２つのフォーマットでＰＭＩＰメッセージを受信するピアノードをさらに含むことができる。ピアノードが、送信された２つのフォーマットのうち１つしかサポートすることができない場合、ピアノードは、サポートされているフォーマットで応答することができる。ピアノードが、送信されたフォーマットの両方をサポートすることができる場合、ピアノードは、ＰＭＩＰ ＲＦＣフォーマットで応答することができる。

上述した例としての実施形態のうちいずれかは、ハートビートリクエストの形式で通信を開始することをさらに含むことができる。

上述した例としての実施形態のうちいずれかは、プロキシバインディング更新メッセージの形式で通信を開始することをさらに含むことができる。

上述した例としての実施形態のうちいずれかは、ソフトウェアアップグレードの間にリスタートカウンタを増加させること、及びそれによってピアノードがどのＰＭＩＰバージョンをサポートしているかをハートビートメカニズムがピアノードに知らせるトリガとなることをさらに含むことができる。

例としての実施形態のいくつかは、ＰＭＩＰ拡張のためのネットワークノードもまた、含むことができる。当該ネットワークノードは、ピアノードに向けた通信の開始においてメッセージを生成するための生成ユニット、及び２つのフォーマットでのＰＭＩＰメッセージを特徴とする前記メッセージをピアノードに送信するための送信ユニットを含むことができる。

例としての実施形態は、上述した例としての実施形態のうち任意の１つを実行するように構成されているネットワークノードをさらに含むことができる。

ここで提供された例としての実施形態の説明は例示の目的で提示された。説明は、網羅的であることや開示された厳密な形式に例としての実施形態を限定するものであることを意図しない。修正及び変形が、上の教示を踏まえて可能であり、提供された実施形態に対する多様な代替手段の実践から取得され得る。ここで議論された例は、多様な例としての実施形態の原理及び性質並びにその実践的な応用を説明して、特定の用途に適するように熟慮されて多様なやり方で多様な修正と共に当業者が例としての実施形態を利用できるようにするために、選択され説明された。ここで説明された実施形態の特徴は、方法、装置、モジュール、システム及びコンピュータプログラムプロダクトの全ての可能な組合せで組み合わされてよい。

留意されるべき点として、“comprising”（備える／含む）との語は、列挙されるものとは別のエレメント又はステップの存在を必ずしも排除せず、エレメントに先行する“a”又は“an”との語は当該エレメントの複数の存在を排除しない。さらに留意されるべき点として、いかなる参照符号も請求項の範囲を限定せず、例としての実施形態はハードウェア及びソフトウェアの両方の手段で少なくとも部分的に実装されてよく、複数の“手段”、“ユニット”又は“デバイス”がハードウェアの同じ品目によって表現されてよい。

ここで使用される用語としての“device”（装置）は、インターネット／イントラネットアクセス、ウェブブラウザ、オーガナイザ、カレンダー、カメラ（例えば、ビデオ及び／又は静止画カメラ）、サウンドレコーダ（例えば、マイクロフォン）、及び／又はＧＰＳ（global positioning system）受信機のための能力を有する無線電話機、データ処理とセルラー無線電話を組み合わせることができるＰＣＳ（personal communications system）端末、無線電話又は無線通信システムを含むことができるＰＤＡ（personal digital assistant）、ラップトップ、通信能力を有するカメラ（例えば、ビデオ及び／又は静止画カメラ）、及び、パーソナルコンピュータ、ホームエンタテイメントシステム、テレビ等のような、送受信することが可能な任意の他の計算または通信装置を含むように広義に解釈されるべきものである。

ここで説明された多様な例としての実施形態は、方法のステップ群又はプロセス群の一般的な文脈において説明されており、ある観点においてそれは、プログラムコードなどのコンピュータにより実行可能な命令を含むコンピュータ読取可能な媒体において具現化され、ネットワーク接続された環境内のコンピュータにより実行される、コンピュータプログラムプロダクトによって実装され得る。コンピュータ読取可能な媒体はリムーバブルな及び非リムーバブルな記憶デバイスを含んでよく、当該記憶デバイスは、限定ではないものの、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＤ（compact discs）、ＤＶＤ（digital versatile discs）などを含む。概して、プログラムモジュールは、特定のタスクを実行し又は特定の抽象的なデータタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み得る。コンピュータにより実行可能な命令、関連付けられるデータ構造及びプログラムモジュールは、ここで開示された方法のステップ群を実行するためのプログラムコードの例を表現する。そうした実行可能な命令の特定のシーケンス又は関連付けられるデータ構造は、当該ステップ群又はプロセス群において記述される機能を実装するための対応する動作の例を表現する。

Claims (6)

1. 第１のネットワークピアノードにおいて、第２のネットワークピアノードにより使用されるプロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６）制御プレーンを判定するための方法であって、前記第１及び第２のネットワークピアノードは、インターネットプロトコルバージョン４（ＩＰｖ４）トランスポートネットワーク内にあり、
   第１の制御プレーンフォーマットで第１の通信メッセージを及び第２の制御プレーンフォーマットで第２の通信メッセージを前記第２のネットワークピアノードへ送信すること（５０）と、
   前記第１の通信メッセージ及び前記第２の通信メッセージに対して、１つのみの通信レスポンスを受信すること（５６）と、
   前記第１の通信メッセージ及び前記第２の通信メッセージに対して受信された前記１つのみの通信レスポンスに基づいて、前記第２のネットワークピアノードにより利用される前記ＰＭＩＰｖ６制御プレーンのバージョンを、当該ＰＭＩＰｖ６制御プレーンのバージョンは受信された前記通信レスポンスに関連付けられる制御プレーンフォーマットであるというように判定すること（６０）と、
   を含む方法。
2. 前記第１のネットワークピアノードは、モバイルアクセスゲートウェイ（ＭＡＧ）ノードであり、前記第２のネットワークピアノードは、ローカルモビリティアンカー（ＬＭＡ）ノードであり、前記第１の通信メッセージ及び前記第２の通信メッセージは、ハートビートメッセージ又はプロキシバインディング更新リクエストメッセージである、請求項１の方法。
3. 前記第１のネットワークピアノードは、ローカルモビリティアンカー（ＬＭＡ）ノードであり、前記第２のネットワークピアノードは、モバイルアクセスゲートウェイ（ＭＡＧ）ノードであり、前記第１の通信メッセージ及び前記第２の通信メッセージは、ハートビートメッセージである、請求項１の方法。
4. 第２のネットワークピアノードにより使用されるプロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６）制御プレーンを判定するための第１のネットワークピアノードであって、前記第１及び第２のネットワークピアノードは、インターネットプロトコルバージョン４（ＩＰｖ４）トランスポートネットワーク内にあり、
   第１の制御プレーンフォーマットで第１の通信メッセージを及び第２の制御プレーンフォーマットで第２の通信メッセージを前記第２のネットワークピアノードへ送信するように構成される送信回路（２４）と、
   前記第１の通信メッセージ及び前記第２の通信メッセージに対して、１つのみの通信レスポンスを受信するように構成される受信回路（２０）と、
   前記第１の通信メッセージ及び前記第２の通信メッセージに対して受信された前記１つのみの通信レスポンスに基づいて、前記第２のネットワークピアノードにより利用される前記ＰＭＩＰｖ６制御プレーンのバージョンを、当該ＰＭＩＰｖ６制御プレーンのバージョンは受信された前記通信レスポンスに関連付けられる制御プレーンフォーマットであるというように判定するように構成される処理回路（２２）と、
   を含む、第１のネットワークピアノード。
5. 前記第１のネットワークピアノードは、モバイルアクセスゲートウェイ（ＭＡＧ）ノードであり、前記第２のネットワークピアノードは、ローカルモビリティアンカー（ＬＭＡ）ノードであり、前記第１の通信メッセージ及び前記第２の通信メッセージは、ハートビートメッセージ又はプロキシバインディング更新リクエストメッセージである、請求項４の第１のネットワークピアノード。
6. 前記第１のネットワークピアノードは、ローカルモビリティアンカー（ＬＭＡ）ノードであり、前記第２のネットワークピアノードは、モバイルアクセスゲートウェイ（ＭＡＧ）ノードであり、前記第１の通信メッセージ及び前記第２の通信メッセージは、ハートビートメッセージである、請求項４の第１のネットワークピアノード。

Images