JP2012147422A5

JP2012147422A5 -

Info

Publication number: JP2012147422A5
Application number: JP2011268595A
Authority: JP
Filing date: 2011-12-08
Publication date: 2014-08-21
Anticipated expiration: 2031-12-08

Description

短距離通信を介したネットワーク設定

本発明は、無線通信に関し、具体的には、無線ネットワークの形成に関する。

背景

無線対応型装置は、情報伝送の際ネットワークを利用することができる。例えば、情報が装置における伝送のために保留中である時、または他の装置における情報が要求される場合において、装置は別のデバイスとのネットワーク接続を開始することができる。無線ネットワークが形成される方式は、採用されている特定の無線通信媒体に依存し得る。装置は最初にネットワークで動作するため、無線通信およびネットワークメンバーシップを交渉する必要がある。例えば、ＩＥＥＥ８０２．１１の種々の項に従って基準が確立されている無線ローカルエリアネットワーキング（ＷＬＡＮ）の場合、ネットワーク内の個別装置がアクセスされてもよいように、インターネットプロトコル（ＩＰ）アドレスが要求されてもよい。

より具体的には、ＩＰアドレスによって、ネットワークに関与する装置が通信できるような明確に異なる識別性がもたらされる。同じＩＰアドレスを有する装置が通信の競合を引き起こすため、この状況が回避されることが重要となる。したがって、ＩＰアドレスが割り当てられるプロセスは、ネットワークに承認されている新しい装置への一意のアドレスの割当を確保するのに役立つ対策を含んでもよい。例示的なプロセスでは、ＩＰアドレスのランダム割当に続いて、例えば、割り当てられたＩＰアドレスがネットワークメンバーのそれぞれによって使用されているアドレスと競合するかどうかに関する問い合わせを通して、ＩＰアドレスがネットワークで未使用であるという検証も伴い得る。

これらのプロセスは、安定したネットワーク動作を確立するために不可欠であるが、既存のＩＰアドレス割当および検証動作が、比較的長時間にわたって（例えば、ネットワークのサイズに応じて数秒）実行されることもある。そのような動作によって生じる遅延は、装置によって実現されるサービスの質（ＱｏＳ）に悪影響を及ぼす場合がある。例えば、無線通信に依存するいくつかのアプリケーションは、例えば、高いデータ完全性要件、装置が情報源の通信範囲内に存在する限られた時間、ストリーミングデータ（例えば、オーディオおよび／またはビデオ）の必要な連続性等のために、数秒の遅延にさえも敏感となる可能性があり、結果として全体的なユーザ体験を損なう場合がある。

摘要

本発明の種々の実施形態例は、ＩＰアドレス割当を改善するための方法、装置、コンピュータプログラム、およびシステムを対象としている。別の装置との接続開始を要求する装置が、イニシエータ（例えば、近距離通信無線通信（Near Field Communications）またはＮＦＣの用語における「ハンドオーバリクエスタ」）と見なされる。装置がイニシエータと見なされる場合、イニシエータがすでにネットワークのメンバーであるかどうかに関する判断が行われてもよい。イニシエータがすでにネットワークのメンバーであると見なされない場合、イニシエータは、ＩＰアドレスをイニシエータに割り当てるために他の装置によって使用可能なＩＰアドレス構成情報を提供してもよい。そして、イニシエータにおいて設定されるＩＰアドレスは、以前に送信されたＩＰアドレス構成情報に応じて他の装置によってイニシエータに提供されるＩＰアドレスに基づいてもよい。

少なくとも１つの実施形態例では、イニシエータから他の装置に送信され得るＩＰアドレス構成情報は、装置においてサポートされる１つ以上のＩＰアドレス割当方法を含んでもよい。この情報は他の装置によって受信され、受信した装置は応答をイニシエータに送信してもよい。例えば、イニシエータによって受信する応答は、少なくとも、選択されたＩＰアドレス構成方法（例えば、イニシエータにおいてサポートされる１つ以上のＩＰ割当方法から選択される）と、他の装置と通信するためにイニシエータによって使用可能なＩＰアドレスとを含んでもよい。本発明の少なくとも１つの実施形態によれば、応答はさらに、他の装置のＩＰアドレス、サブネットマスク、および利用可能なサブマスクリストのうちの１つ以上を含んでもよい。この情報はさらに、他の装置との構成無線通信のためにイニシエータによって利用されてもよい。

ハンドオーバ要求メッセージを受信する装置は、（ハンドオーバ要求メッセージのコリジョンが、衝突解決プロセスをトリガーする装置の間で発生しない限り）セレクタの役割を担ってもよい。セレクタにおいてＩＰアドレスを設定しうる方式は、イニシエータにおける方式とは異なってもよい。例えば、セレクタおよびイニシエータが同じ既存のネットワークのメンバーである場合、セレクタはハンドオーバ要求メッセージにおいてイニシエータによって提供されるＩＰアドレスを無視してもよい。他方で、まだ何れのネットワークのメンバーでもないセレクタは、ハンドオーバ要求メッセージにおいて提供されるＩＰアドレスを採用してもよい。セレクタおよびイニシエータが両方とも、既存であるが関係のないネットワーク内にある場合、装置のうちの１つは、接続試行が失敗したならば、それらの既存のネットワークメンバーシップを放棄しなければならない。ＩＰアドレスが設定される実際の方式にかかわらず、装置は、次いで、無線通信を介して通信してもよい。

前述の概要は、限定的となることを目的としていない本発明の実施形態例を含む。上記の実施形態は、本発明の実装で利用され得る選択された側面またはステップを説明するために使用されるにすぎない。しかしながら、特定の実施形態例に関する１つ以上の側面またはステップを他の実施形態の１つ以上の側面またはステップと組み合わせても、依然として本発明の範囲内で新しい実施形態を作成できることは明白である。したがって、当業者であれば、本発明の種々の実施形態が他の実施形態からの側面を組み込んでもよく、または他の実施形態と組み合わせて実装されてもよいことを理解されたい。

本発明は、添付図面と共に、以下の種々の実施形態例の説明からより深く理解されるであろう。

本発明の種々の実施形態を実装する際に利用され得る装置、システム、構成等の例を示す。

本発明の種々の実施形態を実装する際に利用され得る装置構成例に関するさらなる詳細を示す。

本発明の少なくとも１つの実施形態による、従来のＩＰアドレス割当の実施例を示す。

本発明の少なくとも１つの実施形態による、デバイス動作の概観を示す。

本発明の少なくとも１つの実施形態による、装置連動シナリオの第１の実施例を示す。

本発明の少なくとも１つの実施形態による、装置連動シナリオの第２の実施例を示す。

本発明の少なくとも１つの実施形態による、装置連動シナリオの第３の実施例を示す。

本発明の少なくとも１つの実施形態による、装置連動シナリオの第４の実施例を示す。

本発明の少なくとも１つの実施形態による、通信プロセス例のフローチャートを示す。

実施形態の説明

本発明は、多数の実施形態例に関して以下で説明されているが、添付の請求項で説明されるように、本発明の精神および範囲から逸脱することなく、種々の変更をそれらに行うことができる。
〔Ｉ．本発明の実施形態が実装され得るシステムの例〕

本発明の種々の実施形態を実装するために使用可能であるシステムの例が、図１Ａに示されている。このシステムは、例えば、特定の用途の要件に応じて、全体構成に含まれてもよい要素や、全体構成から省略されてもよい要素を備えている。したがってこのシステムは、何れの方式でも本発明を限定することを目的としていない。

コンピュータデバイス１００は、例えば、ラップトップコンピュータであってもよい。コンピュータデバイス１００の中の機能的要素を備える、基本的構成要素例を表す要素が、１０２−１０８で示されている。プロセッサ１０２は、命令を実行するように構成される１つ以上のデバイスを含んでもよい。少なくとも１つのシナリオでは、プロセッサ１０２によるプログラムコード（例えば、メモリに記憶されたコンピュータ実行可能命令群）の実行は、コンピュータデバイス１００に、例えば、データ、イベント、または他の出力活動をもたらしてもよい方法ステップを含む、プロセスを行わせてもよい。プロセッサ１０２は、専用（例えば、モノリシック）マイクロプロセッサドライブであってもよく、またはＡＳＩＣ、ゲートアレイ、マルチチップモジュール（ＭＣＭ）等の複合デバイスの一部であってもよい。

プロセッサ１０２は、有線または無線バスを介して、コンピュータデバイス１００の中の他の機能的構成要素に電子的に接続されてもよい。例えば、プロセッサ１０２は、処理中に使用するための記憶された情報（例えば、プログラムコード、データ等）を取得するために、メモリ１０４にアクセスしてもよい。メモリ１０４は、概して、静的または動的モードで動作する、リムーバブルまたは組込型メモリを含んでもよい。さらに、メモリ１０４は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、およびＦｌａｓｈ、ＥＰＲＯＭ等の書換可能メモリを含んでもよい。コードは、コンピュータ実行可能命令を含む、インタープリタ型またはコンパイラ型コンピュータ言語を含んでもよい。コードおよび／またはデータは、オペレーティングシステム、通信ユーティリティ、ユーザインターフェース、より特殊化したプログラムモジュール等のソフトウェアモジュールを作成するために使用されてもよい。

１つ以上のインターフェース１０６はまた、コンピュータデバイス１００の中の種々の構成要素に接続されてもよい。これらのインターフェースは、装置間通信（例えば、ソフトウェアまたはプロトコルインターフェース）、装置と装置との通信（例えば、有線または無線通信インターフェース）、および装置とユーザとの通信（例えば、ユーザインターフェース）さえも可能にしてもよい。これらのインターフェースは、コンピュータデバイス１００内の構成要素、他の装置、およびユーザがコンピュータデバイス１００と連動することを可能にする。さらに、インターフェース１０６は、コンピュータ可読媒体上で具現化される電子、磁気、または光信号等の機械可読データを伝達してもよく、またはユーザの動作を、コンピュータデバイス１００によって理解されてもよい活動に翻訳してもよい（例えば、キーボードをタイプする、携帯電話機の受話器に話し掛ける、タッチスクリーンデバイス上のアイコンに触れる等）。インターフェース１０６はさらに、プロセッサ１０２および／またはメモリ１０４が他のモジュール１０８と連動することを可能にしてもよい。例えば、他のモジュール１０８は、コンピュータデバイス１００によって提供される、より特殊化した機能性をサポートする１つ以上の構成要素を備えてもよい。

コンピュータデバイス１００は、図１Ａでさらに示されるように、種々のネットワークを介して他の装置と通信してもよい。例えば、ハブ１１０は、有線および／または無線サポートをコンピュータ１１４およびサーバ１１６等のデバイスに提供してもよい。ハブ１１０はさらに、ローカルエリアネットワーク（ＬＡＮ）上のデバイスが広域ネットワーク（インターネット１２０等のＷＡＮ）上のデバイスと通信することを可能にする、ルータ１１２に接続されてもよい。そのようなシナリオでは、各ＬＡＮ上のデバイスが通信してもよいように、別のルータ１３０がルータ１１２に情報を伝送し、そこから情報を受信してもよい。さらに、この構成例で描写される構成要素の全てが、本発明の実装のために必要なわけではない。例えば、ルータ１３０によって使用可能にされるＬＡＮでは、この機能性がルータによってサポートされてもよいため、付加的なハブは必要とされない。

さらに、遠隔デバイスとの通信が、短距離および長距離無線通信１４０の種々のプロバイダによってサポートされてもよい。これらのプロバイダは、インターネット１２０への無線接続を提供するために、例えば、長距離地上ベースのセルラーシステムおよび衛星通信、および／または短距離無線アクセスポイントを使用してもよい。例えば、携帯情報端末（ＰＤＡ）１４２および携帯電話機１４４は、無線通信１４０のプロバイダによって提供されるインターネット接続を介して、コンピュータデバイス１００と通信してもよい。同様の機能性が、短距離および／長距離無線通信を可能にするように構成されるハードウェアおよび／またはソフトウェアの形態で、ラップトップコンピュータ１４６等のデバイスに含まれてもよい。さらに、開示された装置のうちの何れかまたは全ては、ラップトップ１４６と無線対応型装置１４８との間に示された短距離無線の連動等の直接連動を行ってもよい。無線対応型装置例１４８は、より複雑な独立型無線対応型デバイスから、ラップトップ１４６のような装置における機能性をサポートするための周辺デバイスに及んでもよい。

図１Ａのコンピュータデバイス１００に関して開示されるインターフェース構成要素１０６の例について、図１Ｂでさらに詳細に示す。前述のように、インターフェース１０６は、データを（例えば、１５０で識別されるような）コンピュータ装置１００に伝達するためのインターフェースと、例えば、ユーザインターフェース１７２を含む他の種類のインターフェース１７０との両方を含んでもよい。装置レベルのインターフェースの代表的なグループが１５０で示されている。例えば、マルチ無線コントローラ１５２は、長距離無線インターフェース１５４（例えば、セルラー音声およびデータネットワーク）、短距離無線インターフェース１５６（例えば、ＢｌｕｅｔｏｏｔｈおよびＷＬＡＮネットワーク）、（例えば、電子、磁気、電磁気、および光学情報スキャナが機械可読データを解釈する連動のための）近接近無線インターフェース１５８、有線インターフェース１６０（例えば、Ｅｔｈｅｒｎｅｔ）等の連動を管理してもよい。図１Ｂに示されたインターフェース例は、本明細書での説明のためのみに提示されており、したがって、本発明の種々の実施形態を任意の特定のインターフェースの利用に限定することを目的としていない。本発明の実施形態はまた、図１Ｂで具体的に識別されていないインターフェースを利用してもよい。

マルチ無線コントローラ１５２は、インターフェース１５４−１６０のうちのいくつかまたは全ての動作を管理してもよい。例えば、マルチ無線コントローラ１５２は、その間に各インターフェースが動作することが許可される特定の期間を割り振ることによって、相互に干渉し得るインターフェースが、同時に動作することを防止してもよい。さらに、マルチ無線コントローラ１５２はまた、動作環境内の感知された干渉等の環境情報を処理して、干渉に対してより高い回復力を持つインターフェースを選択することが可能であってもよい。これらのマルチ無線制御シナリオは、可能な制御機能性の包括的リストを包含するように意図されていないが、どのようにマルチ無線コントローラ１５２が図１Ｂのインターフェース１５４−１６０と連動してもよいかという実施例として挙げられるにすぎない。
〔ＩＩ．アドレス割当システムの例〕

本開示において、「Ｗｉ−Ｆｉ」は種々のＩＥＥＥ８０２．１１標準、およびこの種類の無線接続に関する種々の概念、パラメータ、変数等に基づく、無線ローカルエリアネットワーキング（ＷＬＡＮ）に関しても用いられている。しかしながら、この特定の形態の無線通信の使用は、本発明の種々の実施形態例を説明するためにすぎず、本発明の実装を開示された構成のみに限定するようには意図されていない。例えば、本発明の種々の実施形態例はまた、他の実質的に同様の無線媒体を用いて実装されてもよい。

Ｗｉ−Ｆｉ通信の例を利用した説明を続けると、インフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）（例えば、基本サービスセットまたはＢＳＳ）、アドホック（ＡｄＨｏｃ）（例えば、独立基本サービスセットまたはＩＢＳＳ）、およびＷｉ−Ｆｉダイレクト（Ｗｉ−ＦｉＤｉｒｅｃｔ）（アクセスポイントまたはＡＰを使用しないＰ２Ｐ）といった、３つの通信モードが現在存在している。インフラストラクチャおよびＷｉ−Ｆｉダイレクトアーキテクチャは、ネットワークに進入する装置にＩＰアドレスを割り振るために、動的ホスト構成プロトコル（ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ；ＤＨＣＰ）サーバが利用可能であることを要求する。アドホック連動の場合において、いくつかの実装は、参加装置のうちの１つの中に存在するＤＨＣＰサーバを含んでもよいが、そのような構成は典型的ではない。（例えば、ＤＨＣＰサーバが利用可能ではない時に）ＩＰアドレスを割り当てるための別の可能な解決法が、Ｃｈｅｓｉｒｅらによって２００５年５月に公開されたネットワークワーキンググループリクエストフォーコメンツ（ＮｅｔｗｏｒｋＷｏｒｋｉｎｇＧｒｏｕｐｒｅｑｕｅｓｔｆｏｒｃｏｍｍｅｎｔｓ；ＲＦＣ）番号３９２７によって提案されている、ＩＰｖ４リンクローカルアドレス戦略の動的構成、または「オートＩＰ（ＡｕｔｏＩＰ）」で存在してもよい。オートＩＰは、ネットワークホストが、同じ物理アドレスに接続された他のデバイスとの通信のために有効である１６９．２５４／１６プリフィックス内のＩＰｖ４アドレスを伴うインターフェースを自動的に構成することを可能にしてもよい。しかしながら、ＲＦＣ３９２７は、ＩＰｖ４アドレスを使用したリンクローカル通信が、同じ物理（または論理）リンクに接続された他のデバイスとの通信のみに好適であることを認識する。また、オートＩＰの起源は、Ｅｔｈｅｒｎｅｔのような固定ネットワーク内にある。それは、移動動作のために最適化されていない。

オートＩＰを用いてＩＰアドレスを割り当てることによって移動無線ネットワークを実装する上での有意な問題として、ＲＦＣ３９２７で定義されているデフォルト値を使用すると、ＩＰアドレス（リンクローカルアドレス）の割り当てに、最大で９秒かかる場合があるというものがある。「Ａ」および「Ｂ」として示された装置に関して図２で示されるように、ＩＰアドレスは、疑似ランダム関数（例えば、プリフィックス１６９．２５４／１６）を使用してローカルで割り振られ、次いで、アドレス獲得手順が行われる。
・ＰＲＯＢＥ＿ＷＡＩＴ＝１：ＡＲＰプローブを開始する前のランダム初期遅延（０−１秒）
・ＰＲＯＢＥ＿ＮＵＭ＝３，ＰＲＯＢＥ＿ＭＩＮ＝１，ＰＲＯＢＥ＿ＭＡＸ＝２：ランダムな（１−２秒）間隔を伴う３つのＡＲＰプローブパケット
・ＡＮＮＯＵＮＣＥ＿ＷＡＩＴ＝２：ＡＲＰプローブ段階後の２秒遅延
・ＩＰアドレスコリジョンが検出された場合、新しいＩＰアドレスが割り振られ、獲得プロセス全体が再び開始されるべきである（しかしながら、稀な状況である）。
・ＡＮＮＯＵＮＣＥ＿ＮＵＭ＝２，ＡＮＮＯＵＮＣＥ＿ＩＮＴＥＲＶＡＬ＝２：２秒の間隔を伴う２つのＡＲＰアナウンスパケット−＞リンクローカルアドレスがプローブ段階後にすでに使用可能であると仮定し、したがって、これは余分な追加遅延を生じさせない。

上記で説明されるアドレス獲得プロセスを実行するための典型的な時間は、約５−９秒である。理論上、ＲＦＣ３９２７デフォルト値を短縮することは、実際の実装で可能でありうるだろうが、相互運用性の問題が生じることも予測できる。

少なくとも１つの実装例では、近距離通信無線通信（Near Field Communication; NFC）が、アドホックＷｉ−Ｆｉネットワークを実装する時に要求される予備情報を交換するために利用されてもよい。例示的なケースであるが、「接触（touching）」を介して装置間でファイル（例えば、写真、マルチメディア等）を送信することを含んでもよい。装置に接触することは単純に、別の装置のＮＦＣ通信範囲内に（例えば、無線周波数（ＲＦ）伝送範囲内に）装置を持っていくことを含んでもよい。また接触は、例えば、Ｗｉ−Ｆｉ接続確立に先立ってＷｉ−Ｆｉ関連構成情報を交換することを含む、ＮＦＣ接続ハンドオーバをトリガーしてもよい。単一のファイルのみを送信するためにアドホック（ＩＢＳＳ）Ｗｉ−Ｆｉ接続が作成される場合、オートＩＰ実行によって生じる遅延が、不満足なユーザ体験をもたらす場合がある。実際、Ｗｉ−Ｆｉ通信によって提供される通常のスループットは非常に高く、写真のようなファイルを伝送するのに１秒未満の時間しかかからない程度であるため、ほとんどのユーザは、たった１つのファイルを送信するなら数秒を超えることがないだろうと期待する。

既存の接触／ハンドオーバシステムにおける少なくとも１つの問題として、接触されたデバイスが他の装置の識別情報を知る必要があるということがある。例えば、ゼロ・コンフィギュレーション（ＩＰｖ４およびＩＰｖ６アドレス自動構成）およびＵＰｎＰサービス発見機構の両方を、この目的で使用することができるが、幾らかの遅延がプロセス全体で生じる。依然としてＲＦＣ３９２７で開示されているプロセスに依存するため、および両方の機構がＮＦＣを介して交換される「デバイス名」を要求するため、遅延は両方の機構で生じ得る。代替として、媒体アクセス制御（ＭＡＣ）アドレスがＮＦＣ上で交換されてもよく、次いで、デバイスの実際のＩＰアドレスを取得するために逆または反対アドレス解決プロトコル（ＡＲＰ）を使用してもよいが、追加遅延も生じ得る。
〔ＩＩＩ．改善されたアドレス割当システムの例〕

本発明の少なくとも１つの実施形態によれば、無線ネットワーク内で使用するための、アドレス可能な装置識別情報（例えば、ＩＰアドレス）を割り当てることは、装置間の接続が確立されている時にすでに利用可能である、アドレス可能な装置識別情報を用いることによって、改善されうる。それによって、既存の割当方法に基づいて有効な（競合しない）装置識別情報を作成するために通常は要求される、余分な時間が排除される。装置はまた、（例えば、ＮＦＣを介した）接続確立中に交換される装置識別情報に基づいて、ネットワーク識別情報を知らされてもよい。それによって、Ｗｉ−Ｆｉを介して装置識別を取得する付加的なステップを回避でき（例えば、サービス名クエリの必要性を除去する等）、接続確立の時間を更に節約できる。

以下の開示は、アドホック（ＩＢＳＳ）モードで適用されている本発明の種々の実施形態を説明するが、同じ方法が、他の通信媒体／モードとともに使用可能でありうる。かかる他の通信媒体／モードは、既知のものでも決定されなければならないものでもよい。例えば、本発明の実施形態は、Ｗｉ−Ｆｉアドホックモード動作に関して説明されているが、Ｗｉ−ＦｉアライアンスがＩＰアドレス割振のためのＤＨＣＰ以外の方法を受け入れるならば、本明細書で説明されるプロセスはまた、個人対個人の（Ｗｉ−Ｆｉダイレクトモード等の「Ｐ２Ｐ」）動作にも有用でありうる。理想的な状況では、各装置は、その独自のＩＰアドレスを生成し、リンクが要求されるときにそのアドレスを別の装置と交換する。しかしながら、この基本動作は、ＩＰアドレスの一意性を保証しない（重複ＩＰアドレスが同じネットワーク接続内で回避される必要がある）。本発明の種々の実施形態は、２つだけの独立型デバイスが接触を通して通信しているか、または他の装置を含むより大きいＩＢＳＳネットワーク内にあるかどうかにかかわらず、ＩＰアドレスの一意性を確保するのに役立つ。

発明の動作を一般化した例が図３に示されている。ここでは、処理を開始するために、２つの装置が接触させられてもよい。次いで、改善されたＩＰアドレス構成が、（例えば、Ｗｉ−Ｆｉ通信を介した）ネットワーク相互作用によって開始させられてもよい。本発明の少なくとも１つの実施形態によれば、ＮＦＣ接続ハンドオーバメッセージが、通信の初期接触段階でＩＰアドレスを交換するために使用されてもよい。既存の接続ハンドオーバメッセージ構造は、特定のキャリア（例えば、Ｗｉ−Ｆｉ）に関する付加的な情報を運ぶために使用され得る補助データレコードを含む。Ｗｉ−Ｆｉに関して、ハンドオーバメッセージは、サービスセット識別子（ＳＳＩＤ）、パスワード等のような実際のＷｉ−Ｆｉ構成情報を含む構成レコードや、ＩＰアドレスまたは接続ハンドオーバに有用な任意の他のデータのような情報を含む補助データレコードといった、２種類のレコードを含む。

第１のシナリオ例が図４で示されている。ここでは、協働することを要求する装置は、既存のＩＢＳＳネットワークのメンバーではない。これらの装置は、本明細書での説明のために「イニシエータ」および「セレクタ」として区別されるが、これらの名前は限定的となることを目的としておらず、接続確立中の装置のそれぞれの動作を区別するために用いているにすぎない。例えば、図４に示された装置の協働の様子をみれば、イニシエータ装置は、装置が別の装置とのリンクを確立するように要求しているため、ＮＦＣ用語に従って「ハンドオーバリクエスタ」または単に「リクエスタ」と見なされてもよい。また、セレクタ装置が、当該セレクタを含む既存のネットワークや新しいネットワークへイニシエータを登録するための「レジストラ」として動作しうることから、上記イニシエータ装置は、「エンローリ（enrollee）」と見なされてもよい。

何れか一方（または両方の）装置は、情報（例えば、上記の例における写真ファイル等）を伝送または受信するために、別の装置へのリンクを確立することを要求してもよい。イニシエータの役割を果たすデバイスは、単に、ハンドオーバ要求メッセージを伝送する最初の装置であってもよい。このハンドオーバ要求メッセージは、別の装置によって、ハンドオーバ選択応答メッセージ（responding handover select message）によって、「受信した」と承認（acknowledged）される。また、両方の装置が実質的に同時にハンドオーバ要求メッセージを伝送することも可能であり、ハンドオーバ要求の「衝突（コリジョン）」をもたらす。そのような場合、ＮＦＣ接続ハンドオーバ方式は、乱数に基づいていずれかのハンドオーバ要求を無視する衝突解決機構を定めている。図４−７で示された実装例では、衝突を経験することなくイニシエータがハンドオーバ要求メッセージを伝送したことが仮定されており、また、衝突が発生していた場合であっても、イニシエータおよびセレクタ装置が図示される通りであるように、衝突がすでに解決されていることが仮定されている。

ステップ４００で、イニシエータは例えば、ハンドオーバ要求メッセージの補助データレコードによって、サポートされるＩＰアドレス構成方法をセレクタに伝送してもよい。この情報は、イニシエータ装置においてサポートされる、ＮＦＣＷＳＣＩＰｖ４アドレス割当方法のようなＩＰアドレス構成方法を示してもよい。場合によっては、ハンドオーバ要求メッセージはさらに、媒体アクセス制御（ＭＡＣ）アドレスを含んでもよい。

ステップ４１０で、セレクタは、イニシエータからハンドオーバ要求メッセージを受信してもよく、次にステップ４１２で、イニシエータによって提供されるサポートされたＩＰアドレス割当方法に基づいて、少なくとも、イニシエータによって使用されるためのＩＰアドレスを割り当ててもよい。例えば、イニシエータによってサポートされるＩＰアドレス割当方法のうち、ＮＦＣＬｉｎｋＬｏｃａｌＩＰｖ４アドレス割当方法がセレクタによって選択された場合、セレクタは、イニシエータおよびセレクタの両方に対する新しいＩＰアドレスを生成し、生成されたＩＰアドレスが同じではないことをチェックしてもよい。説明されているシナリオ例による、ＩＰアドレスの可変および固定部分に基づけば、アドレスが同じとなる確率は約１／６５，０００である。ステップ４１４においてアドレスが同じであると決定された場合、プロセスはステップ４１２に戻り、新しいアドレスを割り当ててもよい。代替として、ＮＦＣＷｉ−ＦｉＳｉｍｐｌｅＣｏｎｆｉｇＩＰｖ４（ＮＦＣＷＳＣＩＰｖ４）ＩＰアドレス割当方法が、イニシエータによってサポートされるＩＰアドレス割当方法から選択された場合、セレクタは、アドレスを少なくともイニシエータに割り当てるために、Ｗｉ−ＦｉアライアンスＩＢＳＳ仕様で定義される階層ＩＰアドレス割当方法を使用してもよい。

次に、処理はステップ４１６に進む。ここでは、（例えばハンドオーバ選択メッセージの補助データレコードによって、）応答がイニシエータに返送されてもよい。応答に含まれる情報は、選択されるＩＰアドレス割当方法の種類等の基準に依存してもよい。例えば、ＮＦＣＬｉｎｋＬｏｃａｌＩＰｖ４アドレス割当方法が選択された場合、応答には、イニシエータおよび／またはセレクタに割り当てられたＩＰアドレスとともに、選択されたＩＰアドレス割当方法（例えば、「ＮＦＣＬｉｎｋＬｏｃａｌＩＰｖ４」）を示す情報が含まれていてもよい。ＩＰアドレス割当方法は、ステップ４００でセレクタに伝送された、イニシエータによってサポートされるＩＰアドレス割当方法から選択される。代替例として、ＮＦＣＷＳＣＩＰｖ４アドレス割当方法が選択された場合、応答はさらに、サブネットマスクと、利用可能なサブマスクリストとを含んでもよい。これらの例の他にも、ＩＰアドレス割当方法の種類によっては、更に別の情報が応答に含まれることが必要とされてもよい。ステップ４０２で、応答はイニシエータによって受信されてもよく、イニシエータは、応答において受信する情報（例えば、セレクタによって割り当てられるＩＰアドレス）に基づいて、そのＩＰアドレスを設定してもよい。次に、プロセスはステップ４１８に進み、セレクタは、新しく割り当てられたＩＰアドレスを使用して、イニシエータと通信してもよい。同様に、イニシエータ側のプロセスは、ステップ４０４でイニシエータがセレクタと通信し、終了してもよい。

本発明の代替実施形態によれば、既存のアドホック（ＩＢＳＳ）ネットワークで現在動作しているイニシエータが、任意のネットワークのメンバーではないセレクタと関係することも可能である。そのようなデバイスを含む動作シナリオが図５で示されている。ステップ５００でイニシエータは、既存のアドホックネットワークのメンバーとして動作するためにすでに割り当てられたＩＰアドレスを利用しながら、セレクタによって使用するためのＩＰアドレスを割り当ててもよい。次にステップ５０２で、イニシエータは、それがセレクタに割り当てたＩＰアドレスと、既存のアドホックネットワークで使用中のＩＰアドレスのうちの何れかとの間に、競合がないことを検証してもよい。競合が発見されなかった場合、プロセスはステップ５０４に進み、（例えば、既存のネットワークからの）イニシエータＩＰアドレスおよびセレクタによって使用するために割り当てられるＩＰアドレスの両方がセレクタに伝送されてもよい。例えば、ＩＰアドレスは、ハンドオーバ要求メッセージの補助データレコードを使用して伝送されてもよい。

特にセキュリティが実装される場合、アドホックネットワークで動作する装置は、同じネットワークのメンバーである他の装置を認識してもよい。（例えば、他の装置についての識別情報を認識してもよい。）セキュリティを使用する時に、アドホックネットワーク内のデバイスのそれぞれの間に直接のセキュアなリンクがある。例えば、４つの装置を含む無線アドホックネットワークは、６つの明確に異なる直接リンクを含む。ネットワークについてのこの認識を考慮して、ランダムＩＰアドレスの割当およびＩＰアドレスの一意性の検証は、ネットワークメンバー装置のうちの何れかまたは全てにおいて、事前に完了されてもよい。そのような高度な準備は、実際の通信において、知覚される動作速度を速めるだろう。例えば、１つ以上のＩＰアドレスが、装置の接触および接続ハンドオーバ動作の前に準備されてもよく、一意性がＡＲＰを使用してチェックされてもよい。代替として、装置は、アドホックネットワーク内のトラフィックを監視することによって、使用されたＩＰアドレスのリストを良好な状態に維持（蓄積および更新）してもよく、単にランダムＩＰアドレスを割り当て、ランダムＩＰアドレスを既知の使用されたＩＰアドレスのリストと比較することによって、ＩＰアドレスがネットワーク内でまだ使用中ではないことをチェックしてもよい。ステップ５１０において、セレクタは、ハンドオーバ要求メッセージを受信してもよく、オプションとして例えば、ハンドオーバ選択メッセージにおいて確認を伝送することによって、イニシエータによって割り当てられたＩＰアドレスが使用可能であることを確認してもよい。ステップ５１２のオプション確認が送信されると、ステップ５０６でその確認がイニシエータによって受信されてもよい。ステップ５１４において、セレクタは、イニシエータと通信するために、イニシエータによって割り当てられるＩＰアドレスを使用してもよい。接続が開始された時点においてはセレクタはまだネットワークのメンバーではなかったため、セレクタ側の競合をチェックする必要はない。イニシエータ側では、ステップ５０８でイニシエータがセレクタと通信し、プロセスを完了してもよい。

本発明の少なくとも１つの実施形態による第３のシナリオ例が、図６で示されている。この例において、イニシエータはアドホックネットワークのメンバーではなく、セレクタは既存のネットワークのメンバーである。ステップ６００において、イニシエータは、（例えば、ハンドオーバ要求メッセージの補助データレコードによって）１つ以上のＩＰアドレス割当方法（例えばイニシエータによってサポートされるＩＰアドレス割当方法）を、セレクタに送信してもよい。

セレクタは、ステップ６１０でハンドオーバ要求メッセージを受信してもよく、ステップ６１２で、既存のアドホックネットワークでイニシエータによって使用されるためのＩＰアドレスを割り当ててもよい。ステップ６１２において、イニシエータによって使用されるためのランダムリンクローカルＩＰアドレスを割り当てることは、セレクタが、アドホックネットワーク内で自身のアドレスがすでに割り振られていると認識していることを暗示し、イニシエータに割り当てられるＩＰアドレスが、既存のアドホックネットワークでまだ使用されていないことをチェックすることを含んでもよい。この場合において、顕著な遅延が生じることなくＡＲＰクエリを行うためには十分な時間がない場合があるため、前述のように、セレクタは、事前に準備されるＩＰアドレスのリストを良好な状態に維持していてもよい。ステップ６１４で競合が存在しないことが決定された場合、ステップ６１６で、セレクタは、図１で説明された実施例と同様に、ハンドオーバ選択メッセージの補助データレコードを、応答としてイニシエータに送信してもよい。ステップ６０２で、イニシエータは応答を受信してもよく、次にステップ６０４で、応答において受信されたＩＰアドレスを使用してセレクタと通信してもよい。同様に、ステップ６１８で、セレクタはすでに割り当てられているネットワークアドレスを利用してイニシエータと通信してもよい。

イニシエータおよびセレクタが両方とも、既存のアドホックネットワークのメンバーであることも考えられる。図７の実施例は、本発明の少なくとも１つの実施形態による、このシナリオに対処する。イニシエータは、ステップ７００では、イニシエータがすでにアドホックネットワークのメンバーであるため、すでに割り振られている自身のＩＰアドレスに留意して、セレクタによって使用するためのＩＰアドレスを割り当ててもよく、ステップ７０２で、割り当てられたアドレスがイニシエータのアドホックネットワーク内でまだ使用中ではないことをチェックしてもよい。次いでステップ７０４で、イニシエータはセレクタに割り当てられるＩＰアドレスとともに、その自身のＩＰアドレスを、ハンドオーバ要求メッセージの補助データレコードによってセレクタに送信してもよい。

次いでステップ７１２で、当該ハンドオーバ要求メッセージがセレクタによって受信されてもよい。ステップ７１２で、イニシエータおよびセレクタが実は同じアドホックネットワークのメンバーであるとセレクタが決定した場合、ステップ７１４で、（両方の装置が同じネットワーク内で一意の識別子をすでに割り当てられているため、）セレクタは、ステップ７００でイニシエータによって割り当てられたＩＰアドレスを無視してもよく、ステップ７１６では、ハンドオーバ選択メッセージの補助データレコードによって、既に割り当てられている自身のＩＰアドレスを伝送してもよい。次にステップ７１８で、セレクタは、既に割り当てられている自身のＩＰアドレスを使用してイニシエータと通信してもよく、イニシエータは、ステップ７０６でセレクタからハンドオーバ要求メッセージを受信した後、ステップ７０８で、既に割り当てられている自身のＩＰアドレスを使用して、セレクタと通信してもよい。

ステップ７１２で、イニシエータおよびセレクタが同じアドホックネットワークのメンバーではないことが決定された場合、プロセスはステップ７２０に進み、ステップ７２２でのハンドオーバ選択メッセージの伝送を通して、セレクタがこの状況をイニシエータに示してもよい。次にステップ７２４で、プロセスは、これらの装置が通信するためには、これらの装置のうちの少なくとも１つが当該装置の現在のネットワークから退出しなければならないメンバーシップ解消段階に入ってもよい。両方の装置がそれらのネットワークから退出する場合、これらの装置は、図４で説明された方式で接続確立を再実行してもよい。これらの装置のうちの１つが、その現在のネットワークから退出した場合、これらの装置は、どの装置がそれぞれのネットワークから退出することを選択したかに応じて、図５または６で説明された方式で接続確立を再実行してもよい。イニシエータもセレクタも、その既存のネットワークメンバーシップを終了する意思がない（または終了できない）場合、接続確立は完全に失敗する。

本発明の少なくとも１つの実施形態によれば、単一の装置の視点からの通信プロセス例のフローチャートが図８で示されている。プロセスはステップ８００で開始し、通信を要求してもよい。例えばステップ８０２で、装置が別の装置へのリンク開始を要求するかどうかに関して決定が行われてもよい。図８ではハンドオーバ要求の衝突は発生していないことが仮定されている。そこで、ステップ８０２で装置がリンク開始を要求するという決定が行われた場合、当該装置はイニシエータの役割を果たす。また、リンク開始が要求されないことが決定された場合、装置はハンドオーバ要求メッセージの受信を待ってもよい（従って例えば当該装置はセレクタの役割を果たす）。ステップ８０２で、装置がイニシエータの役割を果たしていると決定された場合、ステップ８０４では、イニシエータがすでに既存のネットワークのメンバーであるかどうかに関して、さらなる決定が行われてもよい。ステップ８０４で、イニシエータがまだ既存のネットワークのメンバーではないという決定が行われた場合、プロセスはステップ８０６に進み、ＩＰアドレス構成情報が別の装置に送信されてもよい。例えば、ＩＰアドレス構成情報は、イニシエータによってサポートされる１つ以上のＩＰアドレス割当方法を含んでもよく、当該構成情報はハンドオーバ要求メッセージの補助データレコードによって送信されてもよい。応答メッセージ（例えば、ハンドオーバ選択メッセージ）が、ステップ８０８で受信されてもよい。応答メッセージは、この装置との通信で使用するためにセレクタによって割り当てられるＩＰアドレスとともに、応答装置（例えばセレクタ）のアドレスを含んでもよい。イニシエータは、後続の通信でセレクタによって提供されるアドレスを利用してもよい。ステップ８１０でプロセスが終了してもよく、ステップ８００で再開してもよい。

ステップ８０４に戻って、イニシエータがすでに既存のネットワークのメンバーであることが決定された場合、ステップ８１２では、イニシエータは、セレクタによって使用可能なリンクローカルＩＰアドレスを割り当ててもよい。しかしながら、この場合において、イニシエータは最初に、ステップ８１６で情報をセレクタに伝送する前に、ステップ８１４で既存のネットワーク内の他の装置とのＩＰアドレス競合をチェックしてもよい。検証は、イニシエータにすでに存在しているＩＰアドレス情報に基づいて、またはネットワーク内の他の装置に問い合わせることによって行われてもよい。情報がすでにイニシエータの中にある場合において、イニシエータは、ネットワークですでに使用中のＩＰアドレスのリストに対してＩＰアドレスをチェックしてもよく、イニシエータにおいて維持されるＩＰアドレスのリストから、すでに検証されたＩＰアドレスを選択してもよい。ＩＰアドレスがステップ８１４でどのようにチェックされるかにかかわらず、競合がステップ８１４で検出されなくなるまで、新しいＩＰアドレスがステップ８１２で割り当てられてもよい。次にステップ８１６で、少なくとも送信者（イニシエータ）アドレスおよび割り当てられたアドレスが、例えば、ハンドオーバ選択メッセージの補助データレコードを用いてセレクタに伝送されてもよい。ステップ８１８では、応答がセレクタから受信されてもよい。次にステップ８２０で、応答において受信する情報に基づいてイニシエータおよびセレクタが同じネットワークのメンバーであるかどうかに関するさらなる決定が行われてもよい。ステップ８２０でイニシエータおよびセレクタの両方が既存のネットワークのメンバーであることが決定された場合、ステップ８２２で、イニシエータは既存のネットワーク上で自身が通信するためにすでに使用しているＩＰアドレスを使用して、セレクタと通信してもよい。次にステップ８１０で、プロセスは終了してもよく、ステップ８００で再開してもよい。ステップ８２０でイニシエータおよびセレクタが異なるネットワークのメンバーであることが決定された場合、プロセスは以下で説明されるメンバーシップ解消段階のためのステップ８３８に進んでもよい。

ステップ８０２に戻って、装置がイニシエータではない（例えば、別の装置への接続を開始しようとしない装置である）ことが決定された場合、当該装置はセレクタと見なされてもよく、プロセスは、ハンドオーバ要求メッセージをイニシエータから受信するステップ８２４に進んでもよい。次にステップ８２６で、ハンドオーバ要求メッセージがＩＰアドレスを含むかどうかに関する決定が行われてもよい。ハンドオーバ要求メッセージがＩＰアドレスを含まないことが決定された場合、イニシエータは、まだネットワークで動作していない。そこでプロセスはステップ８２８に進み、セレクタは、イニシエータによって使用されるためのＩＰアドレスを割り当ててもよく、次いで、例えば、ハンドオーバ選択メッセージの補助データレコードを用いて、割り当てられたＩＰアドレスをイニシエータに伝送してもよい。次にステップ８３０で、イニシエータおよびセレクタは、セレクタによってイニシエータに提供されたＩＰアドレスを使用して通信してもよく、ステップ８３２でプロセスが完了してもよく、さらにステップ８００で再開してもよい。ステップ８２６において、ステップ８２４で受信したハンドオーバ要求メッセージがＩＰアドレスを含むことが決定された場合、ステップ８３４で、両方のデバイスが同じネットワークのメンバーであるかどうかに関してさらなる決定が行われてもよい。ステップ８３４で、両方のデバイスが同じネットワーク内にあることが決定された場合、ステップ８３６で、ハンドオーバ要求メッセージにおいてイニシエータによって提供されるＩＰアドレスは、セレクタによって無視されてもよい（両方の装置がすでに同じネットワーク内で一意の識別子を有するため）。ステップ８３０で、セレクタおよびイニシエータはそれらの既存のＩＰアドレスを使用して通信してもよく、ステップ８３２でプロセスが完了してもよく、さらに、ステップ８００で再開してもよい。ステップ８３４でイニシエータおよびセレクタが同じネットワークのメンバーではないことが決定された場合、プロセスはステップ８３８に進んでもよい。

メンバーシップ解消段階は、ステップ８２０またはステップ８３４における、イニシエータおよびセレクタが異なるネットワークのメンバーであるという決定の結果として、ステップ８３８で開始してもよい。起点にかかわらず、ステップ８３８では、イニシエータまたはセレクタに、要求される接続を確立するために、その既存のネットワークメンバーシップから離れる意思がある（または離れることができる）かどうかに関して決定が行われてもよい。ステップ８３８において、何れか一方（または両方）の装置に、その現在のネットワークから退出する意思がある場合、プロセスは、既存のネットワークメンバーシップが放棄された後に、図面上のジャンプ参照「Ａ」によって表されるようにステップ８０２に戻ってもよい。しかしながら、イニシエータもセレクタも、その既存のネットワークメンバーシップを終了する意思がない（または終了できない）場合、ステップ８４０で接続確立は完全に失敗する。ステップ８３２でプロセスが完了してもよく、ステップ８００で再開してもよい。

本発明の種々の実施形態は、上記で開示される実施例のみに限定されず、他の構成または実装を包含してもよい。

例えば、本発明の実施形態例は、装置が別の装置への接続開始を要求するかどうかを決定するための手段と、装置がイニシエータであると決定され、さらに、既存のネットワークのメンバーではないと決定される場合、装置がさらに、ＩＰアドレス構成情報を他の装置に伝送するための手段と、他の装置から受信する応答において提供される情報に基づいて、装置においてＩＰアドレスを設定するための手段とを備える、装置を包含してもよい。

本発明の少なくとも１つの他の実施形態例は、装置に、装置が別の装置への接続開始を要求するかどうかを決定させる電子信号を備えてもよく、装置がイニシエータであると決定され、さらに、既存のネットワークのメンバーではないと決定される場合、電子信号はさらに装置に、ＩＰアドレス構成情報を他の装置に伝送させ、他の装置から受信する応答において提供される情報に基づいて、装置においてＩＰアドレスを設定させる。

本発明の少なくとも１つの他の実施形態例は、非一時的コンピュータ可読記憶媒体上に記録される、コンピュータ可読プログラムコードを含む、コンピュータプログラム製品を備えてもよく、コンピュータ可読プログラムコードは、装置に、装置が別の装置への接続開始を要求するかどうかを決定させるように構成されるコードを備え、装置がイニシエータであると決定され、さらに、既存のネットワークのメンバーではないと決定される場合、コードはさらに、装置に、ＩＰアドレス構成情報を他の装置に伝送させ、他の装置から受信する応答において提供される情報に基づいて、装置においてＩＰアドレスを設定させるように構成される。

本発明の少なくとも１つの他の実施形態例は、少なくとも１つのプロセッサと、実行可能命令を含む、少なくとも１つのメモリとを備える、装置を備えてもよく、少なくとも１つのメモリおよび実行可能命令は、少なくとも１つのプロセッサと共働して、装置に、少なくとも、装置が別の装置への接続開始を要求するかどうかを決定させることを行わせるように構成され、装置がイニシエータであると決定され、さらに、既存のネットワークのメンバーではないと決定される場合、少なくとも１つのメモリおよび実行可能命令はさらに、少なくとも１つのプロセッサと共働して、装置に、ＩＰアドレス構成情報を他の装置に伝送させ、他の装置から受信する応答において提供される情報に基づいて、装置においてＩＰアドレスを設定させるように構成される。

したがって、本発明の精神および範囲から逸脱することなく、形態および詳細の種々の変更をそれらに行うことができることが、当業者に明白となるであろう。本発明の範囲は、上記の実施形態例のうちのいずれによっても限定されるべきではないが、以下の請求項およびそれらの同等物のみに従って定義されるべきである。