ワイヤレスネットワークにおけるサービスディスカバリ方法
本発明の実施形態は、無線ネットワークにおいて提供されるサービスのディスカバリ方法であって、無線インタフェースを備えるデバイスに、前記デバイスが提供するサービスをアドバタイズさせ、近くにいる他のデバイスが提供するサービスを、前記他のデバイスとネットワーク接続を確立せずにディスカバリさせる段階を有する方法を提供するものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレスネットワークにおけるサービスディスカバリ方法に関する。
【背景技術】
【０００２】
今日、ネットワークデバイスが、印刷、プロジェクション、表示、ファイル共有などのサービスを提供する（そのため、「サーバ」と呼ばれる）が、オンライン状態でなければサービスを必要とするクライアントデバイス（「クライアント」）からの要求に答えられない。しかし、省電力も非常に重要である。また、多くのデバイスが今日ではモバイルになっており、ワイヤレスネットワークの干渉やバッテリパワーの制約が生じる。これらのデバイスは、電源を急速に消耗しないで、効率的にサーチ（search）を行い、または自分のサービスをアドバタイズ（advertise）できなければならない。ネットワークを介したサービスアドバタイズ（service advertisement）やディスカバリ（discovery）は、一般的には、ネットワークモデルにおけるレイヤ３以上のレイヤで動作するプロトコルを用いて行われる。こうしたプロトコルでは、クライアントデバイスは、サービスをディスカバーして利用しようとする場合、まずネットワークと接続を確立してからでないと、利用可能なサービスのディスカバリができない。ワイヤレスネットワークでは、クライアントは、複数のネットワークがある環境にいると、必要なサービスを提供するネットワークを識別するまでに、複数のネットワークとの接続と切断をしなければならない。このアプローチは時間とパワー消費の点から効率的とは言えない。
【０００３】
このように、ワイヤレスネットワークにおいて提供されるサービスのディスカバリ方法を改善する必要性が大いにある。
【発明の概要】
【課題を解決するための手段】
【０００４】
一態様による、無線ネットワークにおいて提供されるサービスのディスカバリ方法は、無線インタフェースを備えるデバイスに、前記デバイスが提供するサービスをアドバタイズさせ、近くにいる他のデバイスが提供するサービスを、前記他のデバイスとネットワーク接続を確立せずにディスカバリさせる段階を有する。
【０００５】
また、他の一態様による装置は、提供するサービスをアドバタイズし、近くにいる他の装置が提供するサービスを、前記他の装置とネットワーク接続を確立せずにディスカバリする無線インタフェースを備えた送受信器を有する。
【図面の簡単な説明】
【０００６】
本発明であると考える主題は特許請求の範囲に記載した。しかし、添付した図面を参照して以下の詳細な説明を読めば、本発明を、構成及び動作方法に関して、本発明の目的、特徴、利点とともに、最もよく理解できるであろう。
【図１】本発明の一実施形態による、モバイルインターネットデバイス（ＭＩＤ）を有するユーザが自分のＭＩＤから文書を印刷するプリンタを探す一例を示す図である。 言うまでもなく、図示を簡単かつ明確にするため、図中の要素はかならずしもそのスケール通りに描いてはいない。例えば、明確にするため、一部の要素の大きさは他の要素の大きさより誇張してある。さらに、適当であれば、対応または類似する要素を示すため、複数の図面で同じ参照番号を用いた。
【発明を実施するための形態】
【０００７】
以下の詳細な説明では、本発明をよく理解してもらうために、具体的な詳細事項を多数記載する。しかし、当業者には言うまでもなく、本発明はこれらの詳細がなくても実施することができる。他の場合には、実施形態を分かりにくくしないように、周知の方法、手順、コンポーネント、回路は詳細には説明していない。
【０００８】
本発明の実施形態は様々なアプリケーションで用いることができる。本発明の一部の実施形態は、送信器、受信器、送受信器、送信・受信器、無線通信局、無線通信デバイス、無線アクセスポイント（ＡＰ）、モデム、ワイヤレスモデム、パーソナルコンピュータ（ＰＣ）、デスクトップコンピュータ、モバイルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、ハンドヘルドデバイス、パーソナルデジタルアシスタント（ＰＤＡ）デバイス、ハンドヘルドＰＤＡデバイスなどの様々なデバイスやシステムとともに用いることができる。
【０００９】
本発明の実施形態はこの点で限定されるものではないが、「処理」、「コンピューティング」、「計算」、「決定」、「確立（establishing）」、「分析」、「チェック」などの用語は、コンピュータのレジスタやメモリ内の物理量（例えば電子的量）として表されるデータを操作する、及び／または同様に動作やプロセスを実行する命令を記憶できる、そのコンピュータのレジスタやメモリその他の情報記憶媒体内の物理量として表される他のデータに変換する、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、その他の電子的コンピューティングデバイスの動作及び／またはプロセスを言う。
【００１０】
本発明の実施形態はこの点では限定されないが、ここで「複数（plurality）」とは、例えば「複数（multiple）」または「２以上」の場合を含む。本明細書では、「複数（plurality）」との用語を用い、２以上のコンポーネント、デバイス、要素、ユニット、パラメータなどを示す。例えば、「複数のステーション」は２以上のステーションを含むものとする。
【００１１】
ネットワークを介したサービスアドバタイズ（service advertisement）やディスカバリ（discovery）は、一般的には、ネットワークモデルにおけるレイヤ３以上のレイヤで動作するプロトコルを用いて行われる。かかるプロトコルの例としては、ＵＰｎＰ／ＳＳＤＰ［３］やＺｅｒｏＣｏｎｆ／ＤＮＳ−ＳＤ［２］がある。こうしたプロトコルでは、クライアントデバイスは、サービスをディスカバーして利用しようとする場合、まずネットワークと接続を確立してからでないと、利用可能なサービスのディスカバリができない。本発明の実施形態では、「ネットワークとの接続を確立する」とは、７レイヤネットワークモデルのレイヤ３または場合によってはそれ以上のレイヤを開始することを意味する。クライアントは、複数のネットワークがある環境にいると、必要なサービスを提供するネットワークを識別するまでに、複数のネットワークとの接続と切断をしなければならない。このアプローチは時間とパワー消費の点から効率的とは言えない。本発明の一実施形態により、ＷｉＦｉ、ＵＷＢ、ブルートゥースなどの無線インタフェースを備えたデバイスであって、自機が提供するサービスをアドバタイズし、また近くにいる他のデバイスが提供するサービスをディスカバリするが、それらのデバイスとネットワーク接続を確立する必要がないデバイスを提供する。
【００１２】
１つ以上のサービスを提供（offer）するデバイスをサーバと呼ぶ。サーバが提供する１つ以上のサービスを利用するデバイスをクライアントと呼ぶ。本発明の一実施形態では、接続前に、サーバとクライアントの間で２種類のメッセージ、すなわち（１）クエリと（２）レスポンスを交換する。ただし、本発明はこの点で限定されるものではない。
【００１３】
クエリ（Query）：クエリメッセージは、近くにいるデバイスが提供するサービスについて知りたいクライアントが送信するものである。このメッセージは特定のデバイス宛てであってもよいし、すべてのデバイスにブロードキャストしてもよい。
【００１４】
レスポンス（Response）：レスポンスメッセージは、提供するサービスをアドバタイズするために、サーバにより送信される。このメッセージは、クエリメッセージに応答して特定のクライアント宛て（ユニキャスト）であってもよいし、ブロードキャストしてもよい。レスポンスメッセージは利用可能なサービスインスタンス（service instances）に関する「ヒント」を含み、クライアントがそのサービスに関心があるか決める役に立つ。
【００１５】
シナリオによっては、サーバの代わりに別のデバイスがレスポンスメッセージを送信してもよい。このようなデバイスはプロキシと呼ばれる。例えば、有線ネットワークへの無線接続を提供するＡＰは、その有線ネットワークにおけるサーバの代わりに動作する。図１は、ネットワーク例１００を示し、クライアント１２５、サーバ１０５、１１０、及びプロキシ１２０、１３０の各デバイスを有している。このネットワーク例では、ゲストプリンタ１４０は自分でクエリメッセージに応答し、ＡＰ１２０とジョーのコンピュータ１３０はそれぞれプリンタ１０５、１１０とプリンタｘｙｚ１３５のプロキシとして動作する。
【００１６】
クエリメッセージとレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコル（例えば、ＺｅｒｏＣｏｎｆやＵＰｎＰ）により提供されるサービス情報から求められる。メッセージ中のフィールドは、クライアントとサーバの両方が上位レイヤディスカバリプロトコルに対応する属性（attributes）を指定できるように、規定される。このアプローチにより、異なるサービスディスカバリレイヤ間の機能の統一と調整が容易になる。クライアントがサーバのネットワークに接続する前にＬ２ＳＤクエリメッセージ及びレスポンスメッセージを送信する必要があるので、そのメッセージを担うにはある種のフレーム（必ずではないが、一般的には管理フレーム）のみを用いることができる。８０２．１１ネットワークでは、可能性としては、情報エレメント（Information Element、ＩＥ）を用いて、クエリメッセージをプローブリクエスト（Probe Request）で送信し、レスポンスメッセージをプローブレスポンス（Probe Response）で送信できる。また、サーバはレスポンスメッセージをビーコン（Beacons）で周期的に送信できる。この場合、クライアントは受動的にビーコンを聞き、利用可能なサービスに関する情報を集めることができる。その他ＵＷＢやブルートゥースなどの無線インタフェースでも同様のメカニズムを用いることができる。ユーザが、接続するネットワークと１つ以上のサービスインスタンスとを選択すると、そのネットワークに接続するクライアントネットワーキングスタックがトリガー（triggered）される。ネットワーク接続が確立すると、接続するユーザがすでに指定している適当なサービスインスタンス情報により、上位レイヤのディスカバリメカニズムがトリガーされる。複数の異なるサービスディスカバリレイヤによる情報交換を調整することにより、実施が簡単になり、ユーザ体験が改善され得る（例えば、ユーザに、接続したいサービスやデバイスを選択するのに２回以上入力を促す必要がなくなる）。
【００１７】
さらに図１を参照して、モバイルインターネットデバイス（ＭＩＤ）１２５を有するユーザが、そのＭＩＤ１２５から文書を印刷するプリンタを探している例を考える。ＭＩＤ１２５は上位レイヤサービスディスカバリメカニズムとしてＺｅｒｏＣｏｎｆを用いており、８０２．１１無線インタフェースを備えているものとする。図１に示したように、ＭＩＤ１２５からプローブリクエストにてクエリメッセージを送信し、ＩＥを用いてプローブレスポンスでレスポンスメッセージを送信できる。ただし、本発明はこれに限定されるものではない。ＭＩＤ１２５は、サポートするプロトコルと、関心のあるサービスとを示すクエリメッセージを、プローブリクエストで送信する。この例では、プロトコルはＺｅｒｏＣｏｎｆであり、サービスタイプは「_ipp._tcp」であり、これは「インターネットプロトコルプリンタ」を表すＺｅｒｏＣｏｎｆサービスタイプである。言い換えると、ＭＩＤ１２５はＩＰＰプロトコルをサポートするどのプリンタデバイス（サービス）１０５、１１０、１３５、または１４０にも関心をもっている。コンパチブルなサービスを提供するサーバ（またはそのプロキシ）がレスポンスメッセージを返す。レスポンスメッセージは、サービスインスタンスに関する十分な「ヒント」を提供し、どのプリンタを選択するかＭＩＤ１２５ユーザが決定するのを助ける。この例では、クエリメッセージのフォーマットは、
＜上位レイヤディスカバリプロトコル，サービスタイプリスト，・・・＞
であるが、本発明はこれに限定されるものではない。レスポンスメッセージのフォーマットは、
＜上位レイヤディスカバリプロトコル，ネットワーク識別子，＜サービスタイプ，＜サービスインスタンス名，ＩＰアドレス等の付加的属性＞＞＞
である。本発明は、クエリメッセージやレスポンスメッセージの具体的なフォーマットやレイアウトを特定するものではなく、上記は単なる一例である。メッセージは、ネットワークへの接続前に、レイヤ２を用いてサービスをディスカバリする目的を達成するものであれば、どんなフォーマットで画成してもよい。プリンタのディスカバリに関係するステップを以下に挙げる。
【００１８】
１．ＭＩＤがブロードキャストクエリメッセージ
＜ＺｅｒｏＣｏｎｆ，＿ｉｐｐ．＿ｔｃｐ＞
を送信する。このメッセージは近くにあるすべてのサーバが受信する。
【００１９】
２．印刷サービスを提供し、ＺｅｒｏＣｏｎｆプロトコルをサポートするすべてのサーバが、このクエリに対してレスポンスメッセージで答える。
ａ．ＡＰからのResponse-1：<ZeroConf, JF3-Network, <_ipp._tcp, <<JF3-2-H5, JF3-2-J10>>>
ｂ．ジョーのラップトップからのResponse-2：<ZeroConf, Joe's-Laptop, <_ipp._tcp, <Printer-xyz, Location:JF3-2-K9, IP address: 139.145.23.90 >>>
ｃ．ゲストプリンタからのResponse-3：<ZeroConf, Guest-Printer, <_ipp._tcp, <Guest, Location:JF3-2-C4, IP address: 139.145.23.85 >>>
３．ＭＩＤはユーザフレンドリなフォーマットでユーザにレスポンスを表示し、ユーザは接続するネットワークとプリンタインスタンスとを選択する。
４．ＭＩＤは、選択されたネットワークに接続し、上位レイヤのディスカバリメカニズム（この場合、ＺｅｒｏＣｏｎｆ）を用いて、選択されたプリンタに関する付加的情報を取得して、そのプリンタに接続して使用できるようにする。
【００２０】
８０２．１１等の今日の無線インタフェースでは、「ネットワーク」をディスカバリすることはできるが、そのネットワークに接続されたデバイスが提供するサービスをディスカバリすることはできない。ユーザはネットワークに接続して、始めて、ＺｅｒｏＣｏｎｆやＵＰｎＰなどの上位レイヤサービスディスカバリプロトコルを用いてそのネットワークが提供するサービスをディスカバリすることができる。近くに複数のネットワークがあり、探しているサービスをどのネットワークが提供しているか知らなければ、ユーザは各ネットワークに接続して、上位レイヤのサービスディスカバリプロトコルを用いて利用可能なサービスを判断しなければならない。これは、かかる時間とエネルギーの点で効率的ではない。本発明の実施形態は、ネットワークに接続する前に、そのネットワークが提供するデバイスとサービスに関する情報をクライアントが判断でき、具体的なサービスについて問い合わせることができる方法を提供する。本発明の別の利点は、接続するまえに、ＩＰアドレスなどの情報をアドレッシングする上位レイヤサーバをクライアントがディスカバリできることである。これにより、接続後に実行する上位レイヤのディスカバリ動作の効率と信頼性がより高くなる。信頼性が高くないブロードキャストやマルチキャストのメッセージではなく、ユニキャストの上位レイヤディスカバリメッセージを送信できるからである。ＵＰｎＰやＺｅｒｏＣｏｎｆなどの上位レイヤサービスディスカバリフレームワークは、非管理ネットワークにおけるデバイスやサービスのディスカバリ用のマルチキャストメッセージに依存している。しかし、無線ネットワークでは、無線干渉や障害や信号フェージングの問題があるので、マルチキャストメッセージやブロードキャストメッセージの配信に依存しないことが特に重要である。
【００２１】
本発明の特徴をここに例示し説明したが、当業者は多数の修正、置換、変更及び等価物を考えることができるであろう。それゆえ、言うまでもなく、添付した特許請求の範囲は、かかる修正や変更も本発明の真の精神に含まれるものとしてすべてカバーするものである。
【技術分野】
【０００１】
本発明は、ワイヤレスネットワークにおけるサービスディスカバリ方法に関する。
【背景技術】
【０００２】
今日、ネットワークデバイスが、印刷、プロジェクション、表示、ファイル共有などのサービスを提供する（そのため、「サーバ」と呼ばれる）が、オンライン状態でなければサービスを必要とするクライアントデバイス（「クライアント」）からの要求に答えられない。しかし、省電力も非常に重要である。また、多くのデバイスが今日ではモバイルになっており、ワイヤレスネットワークの干渉やバッテリパワーの制約が生じる。これらのデバイスは、電源を急速に消耗しないで、効率的にサーチ（search）を行い、または自分のサービスをアドバタイズ（advertise）できなければならない。ネットワークを介したサービスアドバタイズ（service advertisement）やディスカバリ（discovery）は、一般的には、ネットワークモデルにおけるレイヤ３以上のレイヤで動作するプロトコルを用いて行われる。こうしたプロトコルでは、クライアントデバイスは、サービスをディスカバーして利用しようとする場合、まずネットワークと接続を確立してからでないと、利用可能なサービスのディスカバリができない。ワイヤレスネットワークでは、クライアントは、複数のネットワークがある環境にいると、必要なサービスを提供するネットワークを識別するまでに、複数のネットワークとの接続と切断をしなければならない。このアプローチは時間とパワー消費の点から効率的とは言えない。
【０００３】
このように、ワイヤレスネットワークにおいて提供されるサービスのディスカバリ方法を改善する必要性が大いにある。
【発明の概要】
【課題を解決するための手段】
【０００４】
一態様による、無線ネットワークにおいて提供されるサービスのディスカバリ方法は、無線インタフェースを備えるデバイスに、前記デバイスが提供するサービスをアドバタイズさせ、近くにいる他のデバイスが提供するサービスを、前記他のデバイスとネットワーク接続を確立せずにディスカバリさせる段階を有する。
【０００５】
また、他の一態様による装置は、提供するサービスをアドバタイズし、近くにいる他の装置が提供するサービスを、前記他の装置とネットワーク接続を確立せずにディスカバリする無線インタフェースを備えた送受信器を有する。
【図面の簡単な説明】
【０００６】
本発明であると考える主題は特許請求の範囲に記載した。しかし、添付した図面を参照して以下の詳細な説明を読めば、本発明を、構成及び動作方法に関して、本発明の目的、特徴、利点とともに、最もよく理解できるであろう。
【図１】本発明の一実施形態による、モバイルインターネットデバイス（ＭＩＤ）を有するユーザが自分のＭＩＤから文書を印刷するプリンタを探す一例を示す図である。 言うまでもなく、図示を簡単かつ明確にするため、図中の要素はかならずしもそのスケール通りに描いてはいない。例えば、明確にするため、一部の要素の大きさは他の要素の大きさより誇張してある。さらに、適当であれば、対応または類似する要素を示すため、複数の図面で同じ参照番号を用いた。
【発明を実施するための形態】
【０００７】
以下の詳細な説明では、本発明をよく理解してもらうために、具体的な詳細事項を多数記載する。しかし、当業者には言うまでもなく、本発明はこれらの詳細がなくても実施することができる。他の場合には、実施形態を分かりにくくしないように、周知の方法、手順、コンポーネント、回路は詳細には説明していない。
【０００８】
本発明の実施形態は様々なアプリケーションで用いることができる。本発明の一部の実施形態は、送信器、受信器、送受信器、送信・受信器、無線通信局、無線通信デバイス、無線アクセスポイント（ＡＰ）、モデム、ワイヤレスモデム、パーソナルコンピュータ（ＰＣ）、デスクトップコンピュータ、モバイルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、ハンドヘルドデバイス、パーソナルデジタルアシスタント（ＰＤＡ）デバイス、ハンドヘルドＰＤＡデバイスなどの様々なデバイスやシステムとともに用いることができる。
【０００９】
本発明の実施形態はこの点で限定されるものではないが、「処理」、「コンピューティング」、「計算」、「決定」、「確立（establishing）」、「分析」、「チェック」などの用語は、コンピュータのレジスタやメモリ内の物理量（例えば電子的量）として表されるデータを操作する、及び／または同様に動作やプロセスを実行する命令を記憶できる、そのコンピュータのレジスタやメモリその他の情報記憶媒体内の物理量として表される他のデータに変換する、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、その他の電子的コンピューティングデバイスの動作及び／またはプロセスを言う。
【００１０】
本発明の実施形態はこの点では限定されないが、ここで「複数（plurality）」とは、例えば「複数（multiple）」または「２以上」の場合を含む。本明細書では、「複数（plurality）」との用語を用い、２以上のコンポーネント、デバイス、要素、ユニット、パラメータなどを示す。例えば、「複数のステーション」は２以上のステーションを含むものとする。
【００１１】
ネットワークを介したサービスアドバタイズ（service advertisement）やディスカバリ（discovery）は、一般的には、ネットワークモデルにおけるレイヤ３以上のレイヤで動作するプロトコルを用いて行われる。かかるプロトコルの例としては、ＵＰｎＰ／ＳＳＤＰ［３］やＺｅｒｏＣｏｎｆ／ＤＮＳ−ＳＤ［２］がある。こうしたプロトコルでは、クライアントデバイスは、サービスをディスカバーして利用しようとする場合、まずネットワークと接続を確立してからでないと、利用可能なサービスのディスカバリができない。本発明の実施形態では、「ネットワークとの接続を確立する」とは、７レイヤネットワークモデルのレイヤ３または場合によってはそれ以上のレイヤを開始することを意味する。クライアントは、複数のネットワークがある環境にいると、必要なサービスを提供するネットワークを識別するまでに、複数のネットワークとの接続と切断をしなければならない。このアプローチは時間とパワー消費の点から効率的とは言えない。本発明の一実施形態により、ＷｉＦｉ、ＵＷＢ、ブルートゥースなどの無線インタフェースを備えたデバイスであって、自機が提供するサービスをアドバタイズし、また近くにいる他のデバイスが提供するサービスをディスカバリするが、それらのデバイスとネットワーク接続を確立する必要がないデバイスを提供する。
【００１２】
１つ以上のサービスを提供（offer）するデバイスをサーバと呼ぶ。サーバが提供する１つ以上のサービスを利用するデバイスをクライアントと呼ぶ。本発明の一実施形態では、接続前に、サーバとクライアントの間で２種類のメッセージ、すなわち（１）クエリと（２）レスポンスを交換する。ただし、本発明はこの点で限定されるものではない。
【００１３】
クエリ（Query）：クエリメッセージは、近くにいるデバイスが提供するサービスについて知りたいクライアントが送信するものである。このメッセージは特定のデバイス宛てであってもよいし、すべてのデバイスにブロードキャストしてもよい。
【００１４】
レスポンス（Response）：レスポンスメッセージは、提供するサービスをアドバタイズするために、サーバにより送信される。このメッセージは、クエリメッセージに応答して特定のクライアント宛て（ユニキャスト）であってもよいし、ブロードキャストしてもよい。レスポンスメッセージは利用可能なサービスインスタンス（service instances）に関する「ヒント」を含み、クライアントがそのサービスに関心があるか決める役に立つ。
【００１５】
シナリオによっては、サーバの代わりに別のデバイスがレスポンスメッセージを送信してもよい。このようなデバイスはプロキシと呼ばれる。例えば、有線ネットワークへの無線接続を提供するＡＰは、その有線ネットワークにおけるサーバの代わりに動作する。図１は、ネットワーク例１００を示し、クライアント１２５、サーバ１０５、１１０、及びプロキシ１２０、１３０の各デバイスを有している。このネットワーク例では、ゲストプリンタ１４０は自分でクエリメッセージに応答し、ＡＰ１２０とジョーのコンピュータ１３０はそれぞれプリンタ１０５、１１０とプリンタｘｙｚ１３５のプロキシとして動作する。
【００１６】
クエリメッセージとレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコル（例えば、ＺｅｒｏＣｏｎｆやＵＰｎＰ）により提供されるサービス情報から求められる。メッセージ中のフィールドは、クライアントとサーバの両方が上位レイヤディスカバリプロトコルに対応する属性（attributes）を指定できるように、規定される。このアプローチにより、異なるサービスディスカバリレイヤ間の機能の統一と調整が容易になる。クライアントがサーバのネットワークに接続する前にＬ２ＳＤクエリメッセージ及びレスポンスメッセージを送信する必要があるので、そのメッセージを担うにはある種のフレーム（必ずではないが、一般的には管理フレーム）のみを用いることができる。８０２．１１ネットワークでは、可能性としては、情報エレメント（Information Element、ＩＥ）を用いて、クエリメッセージをプローブリクエスト（Probe Request）で送信し、レスポンスメッセージをプローブレスポンス（Probe Response）で送信できる。また、サーバはレスポンスメッセージをビーコン（Beacons）で周期的に送信できる。この場合、クライアントは受動的にビーコンを聞き、利用可能なサービスに関する情報を集めることができる。その他ＵＷＢやブルートゥースなどの無線インタフェースでも同様のメカニズムを用いることができる。ユーザが、接続するネットワークと１つ以上のサービスインスタンスとを選択すると、そのネットワークに接続するクライアントネットワーキングスタックがトリガー（triggered）される。ネットワーク接続が確立すると、接続するユーザがすでに指定している適当なサービスインスタンス情報により、上位レイヤのディスカバリメカニズムがトリガーされる。複数の異なるサービスディスカバリレイヤによる情報交換を調整することにより、実施が簡単になり、ユーザ体験が改善され得る（例えば、ユーザに、接続したいサービスやデバイスを選択するのに２回以上入力を促す必要がなくなる）。
【００１７】
さらに図１を参照して、モバイルインターネットデバイス（ＭＩＤ）１２５を有するユーザが、そのＭＩＤ１２５から文書を印刷するプリンタを探している例を考える。ＭＩＤ１２５は上位レイヤサービスディスカバリメカニズムとしてＺｅｒｏＣｏｎｆを用いており、８０２．１１無線インタフェースを備えているものとする。図１に示したように、ＭＩＤ１２５からプローブリクエストにてクエリメッセージを送信し、ＩＥを用いてプローブレスポンスでレスポンスメッセージを送信できる。ただし、本発明はこれに限定されるものではない。ＭＩＤ１２５は、サポートするプロトコルと、関心のあるサービスとを示すクエリメッセージを、プローブリクエストで送信する。この例では、プロトコルはＺｅｒｏＣｏｎｆであり、サービスタイプは「_ipp._tcp」であり、これは「インターネットプロトコルプリンタ」を表すＺｅｒｏＣｏｎｆサービスタイプである。言い換えると、ＭＩＤ１２５はＩＰＰプロトコルをサポートするどのプリンタデバイス（サービス）１０５、１１０、１３５、または１４０にも関心をもっている。コンパチブルなサービスを提供するサーバ（またはそのプロキシ）がレスポンスメッセージを返す。レスポンスメッセージは、サービスインスタンスに関する十分な「ヒント」を提供し、どのプリンタを選択するかＭＩＤ１２５ユーザが決定するのを助ける。この例では、クエリメッセージのフォーマットは、
＜上位レイヤディスカバリプロトコル，サービスタイプリスト，・・・＞
であるが、本発明はこれに限定されるものではない。レスポンスメッセージのフォーマットは、
＜上位レイヤディスカバリプロトコル，ネットワーク識別子，＜サービスタイプ，＜サービスインスタンス名，ＩＰアドレス等の付加的属性＞＞＞
である。本発明は、クエリメッセージやレスポンスメッセージの具体的なフォーマットやレイアウトを特定するものではなく、上記は単なる一例である。メッセージは、ネットワークへの接続前に、レイヤ２を用いてサービスをディスカバリする目的を達成するものであれば、どんなフォーマットで画成してもよい。プリンタのディスカバリに関係するステップを以下に挙げる。
【００１８】
１．ＭＩＤがブロードキャストクエリメッセージ
＜ＺｅｒｏＣｏｎｆ，＿ｉｐｐ．＿ｔｃｐ＞
を送信する。このメッセージは近くにあるすべてのサーバが受信する。
【００１９】
２．印刷サービスを提供し、ＺｅｒｏＣｏｎｆプロトコルをサポートするすべてのサーバが、このクエリに対してレスポンスメッセージで答える。
ａ．ＡＰからのResponse-1：<ZeroConf, JF3-Network, <_ipp._tcp, <<JF3-2-H5, JF3-2-J10>>>
ｂ．ジョーのラップトップからのResponse-2：<ZeroConf, Joe's-Laptop, <_ipp._tcp, <Printer-xyz, Location:JF3-2-K9, IP address: 139.145.23.90 >>>
ｃ．ゲストプリンタからのResponse-3：<ZeroConf, Guest-Printer, <_ipp._tcp, <Guest, Location:JF3-2-C4, IP address: 139.145.23.85 >>>
３．ＭＩＤはユーザフレンドリなフォーマットでユーザにレスポンスを表示し、ユーザは接続するネットワークとプリンタインスタンスとを選択する。
４．ＭＩＤは、選択されたネットワークに接続し、上位レイヤのディスカバリメカニズム（この場合、ＺｅｒｏＣｏｎｆ）を用いて、選択されたプリンタに関する付加的情報を取得して、そのプリンタに接続して使用できるようにする。
【００２０】
８０２．１１等の今日の無線インタフェースでは、「ネットワーク」をディスカバリすることはできるが、そのネットワークに接続されたデバイスが提供するサービスをディスカバリすることはできない。ユーザはネットワークに接続して、始めて、ＺｅｒｏＣｏｎｆやＵＰｎＰなどの上位レイヤサービスディスカバリプロトコルを用いてそのネットワークが提供するサービスをディスカバリすることができる。近くに複数のネットワークがあり、探しているサービスをどのネットワークが提供しているか知らなければ、ユーザは各ネットワークに接続して、上位レイヤのサービスディスカバリプロトコルを用いて利用可能なサービスを判断しなければならない。これは、かかる時間とエネルギーの点で効率的ではない。本発明の実施形態は、ネットワークに接続する前に、そのネットワークが提供するデバイスとサービスに関する情報をクライアントが判断でき、具体的なサービスについて問い合わせることができる方法を提供する。本発明の別の利点は、接続するまえに、ＩＰアドレスなどの情報をアドレッシングする上位レイヤサーバをクライアントがディスカバリできることである。これにより、接続後に実行する上位レイヤのディスカバリ動作の効率と信頼性がより高くなる。信頼性が高くないブロードキャストやマルチキャストのメッセージではなく、ユニキャストの上位レイヤディスカバリメッセージを送信できるからである。ＵＰｎＰやＺｅｒｏＣｏｎｆなどの上位レイヤサービスディスカバリフレームワークは、非管理ネットワークにおけるデバイスやサービスのディスカバリ用のマルチキャストメッセージに依存している。しかし、無線ネットワークでは、無線干渉や障害や信号フェージングの問題があるので、マルチキャストメッセージやブロードキャストメッセージの配信に依存しないことが特に重要である。
【００２１】
本発明の特徴をここに例示し説明したが、当業者は多数の修正、置換、変更及び等価物を考えることができるであろう。それゆえ、言うまでもなく、添付した特許請求の範囲は、かかる修正や変更も本発明の真の精神に含まれるものとしてすべてカバーするものである。
【特許請求の範囲】
【請求項１】
無線ネットワークにおいて提供されるサービスのディスカバリ方法であって、
無線インタフェースを備えるデバイスに、前記デバイスが提供するサービスをアドバタイズさせ、近くにいる他のデバイスが提供するサービスを、前記他のデバイスとネットワーク接続を確立せずにディスカバリさせる段階を有する方法。
【請求項２】
前記無線インタフェースはＷｉ−Ｆｉ、ＵＷＢ、ブルートゥースよりなる群から選択される、請求項１に記載の方法。
【請求項３】
クエリ及びレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコルにより提供されるサービス情報から求められる、請求項１に記載の方法。
【請求項４】
前記クエリ及びレスポンスメッセージのフィールドは、クライアントとサーバの両方が、複数の異なるサービスディスカバリレイヤの機能の統合と調整を容易にする、上位レイヤのディスカバリプロトコルに対応する属性を指定するように画成される、請求項３に記載の方法。
【請求項５】
前記クライアントが前記サーバネットワークに接続する前に前記クエリ及びレスポンスメッセージを送信する必要があるので、所定タイプのフレームのみを用いて前記クエリ及びレスポンスメッセージを担わせる、請求項３に記載の方法。
【請求項６】
前記所定タイプのフレームは管理フレームである、請求項５に記載の方法。
【請求項７】
前記クエリメッセージをプローブリクエストで送信し、前記レスポンスメッセージを情報エレメントを用いてプローブレスポンスで送信する、請求項４に記載の方法。
【請求項８】
前記サーバは前記レスポンスメッセージをビーコンで周期的に送信し、前記クライアントは前記ビーコンを受動的に受信し利用可能なサービスに関する情報を集めるように構成された、請求項４に記載の方法。
【請求項９】
ユーザが接続するネットワークと１つ以上のサービスインスタンスを選択すると、クライアントネットワーキングスタックをトリガーして、そのネットワークに接続し、ネットワーク接続を確立すると、接続する前記ユーザが指定している適当なサービスインスタンス情報により上位レイヤディスカバリメカニズムをトリガーする、請求項４に記載の方法。
【請求項１０】
提供するサービスをアドバタイズし、近くにいる他の装置が提供するサービスを、前記他の装置とネットワーク接続を確立せずにディスカバリする無線インタフェースを備えた送受信器を有する、装置。
【請求項１１】
前記無線インタフェースはＷｉ−Ｆｉ、ＵＷＢ、ブルートゥースよりなる群から選択される、請求項１０に記載の装置。
【請求項１２】
クエリ及びレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコルにより提供されるサービス情報から求められる、請求項１０に記載の装置。
【請求項１３】
前記クエリ及びレスポンスメッセージのフィールドは、クライアントとサーバの両方が、複数の異なるサービスディスカバリレイヤの機能の統合と調整を容易にする、上位レイヤのディスカバリプロトコルに対応する属性を指定するように画成される、請求項１２に記載の装置。
【請求項１４】
前記クライアントが前記サーバネットワークに接続する前に前記クエリ及びレスポンスメッセージを送信する必要があるので、所定タイプのフレームのみを用いて前記クエリ及びレスポンスメッセージを担わせる、請求項１３に記載の装置。
【請求項１５】
前記所定タイプのフレームは管理フレームである、請求項１４に記載の装置。
【請求項１６】
前記クエリメッセージをプローブリクエストで送信し、前記レスポンスメッセージを、情報エレメントを用いるプローブレスポンスで送信する、請求項１３に記載の装置。
【請求項１７】
前記サーバは前記レスポンスメッセージをビーコンで周期的に送信し、前記クライアントは前記ビーコンを受動的に受信し利用可能なサービスに関する情報を集めるように構成された、請求項１３に記載の装置。
【請求項１８】
ユーザが接続するネットワークと１つ以上のサービスインスタンスを選択すると、クライアントネットワーキングスタックをトリガーして、そのネットワークに接続し、ネットワーク接続を確立すると、接続する前記ユーザが指定している適当なサービスインスタンス情報により上位レイヤディスカバリメカニズムをトリガーする、請求項１３に記載の装置。
【請求項１９】
前記装置は前記近くにいる他の装置の代わりにレスポンスメッセージを送信する、請求項１０に記載の装置。
【請求項１】
無線ネットワークにおいて提供されるサービスのディスカバリ方法であって、
無線インタフェースを備えるデバイスに、前記デバイスが提供するサービスをアドバタイズさせ、近くにいる他のデバイスが提供するサービスを、前記他のデバイスとネットワーク接続を確立せずにディスカバリさせる段階を有する方法。
【請求項２】
前記無線インタフェースはＷｉ−Ｆｉ、ＵＷＢ、ブルートゥースよりなる群から選択される、請求項１に記載の方法。
【請求項３】
クエリ及びレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコルにより提供されるサービス情報から求められる、請求項１に記載の方法。
【請求項４】
前記クエリ及びレスポンスメッセージのフィールドは、クライアントとサーバの両方が、複数の異なるサービスディスカバリレイヤの機能の統合と調整を容易にする、上位レイヤのディスカバリプロトコルに対応する属性を指定するように画成される、請求項３に記載の方法。
【請求項５】
前記クライアントが前記サーバネットワークに接続する前に前記クエリ及びレスポンスメッセージを送信する必要があるので、所定タイプのフレームのみを用いて前記クエリ及びレスポンスメッセージを担わせる、請求項３に記載の方法。
【請求項６】
前記所定タイプのフレームは管理フレームである、請求項５に記載の方法。
【請求項７】
前記クエリメッセージをプローブリクエストで送信し、前記レスポンスメッセージを情報エレメントを用いてプローブレスポンスで送信する、請求項４に記載の方法。
【請求項８】
前記サーバは前記レスポンスメッセージをビーコンで周期的に送信し、前記クライアントは前記ビーコンを受動的に受信し利用可能なサービスに関する情報を集めるように構成された、請求項４に記載の方法。
【請求項９】
ユーザが接続するネットワークと１つ以上のサービスインスタンスを選択すると、クライアントネットワーキングスタックをトリガーして、そのネットワークに接続し、ネットワーク接続を確立すると、接続する前記ユーザが指定している適当なサービスインスタンス情報により上位レイヤディスカバリメカニズムをトリガーする、請求項４に記載の方法。
【請求項１０】
提供するサービスをアドバタイズし、近くにいる他の装置が提供するサービスを、前記他の装置とネットワーク接続を確立せずにディスカバリする無線インタフェースを備えた送受信器を有する、装置。
【請求項１１】
前記無線インタフェースはＷｉ−Ｆｉ、ＵＷＢ、ブルートゥースよりなる群から選択される、請求項１０に記載の装置。
【請求項１２】
クエリ及びレスポンスメッセージで交換される情報は、上位レイヤのサービスディスカバリプロトコルにより提供されるサービス情報から求められる、請求項１０に記載の装置。
【請求項１３】
前記クエリ及びレスポンスメッセージのフィールドは、クライアントとサーバの両方が、複数の異なるサービスディスカバリレイヤの機能の統合と調整を容易にする、上位レイヤのディスカバリプロトコルに対応する属性を指定するように画成される、請求項１２に記載の装置。
【請求項１４】
前記クライアントが前記サーバネットワークに接続する前に前記クエリ及びレスポンスメッセージを送信する必要があるので、所定タイプのフレームのみを用いて前記クエリ及びレスポンスメッセージを担わせる、請求項１３に記載の装置。
【請求項１５】
前記所定タイプのフレームは管理フレームである、請求項１４に記載の装置。
【請求項１６】
前記クエリメッセージをプローブリクエストで送信し、前記レスポンスメッセージを、情報エレメントを用いるプローブレスポンスで送信する、請求項１３に記載の装置。
【請求項１７】
前記サーバは前記レスポンスメッセージをビーコンで周期的に送信し、前記クライアントは前記ビーコンを受動的に受信し利用可能なサービスに関する情報を集めるように構成された、請求項１３に記載の装置。
【請求項１８】
ユーザが接続するネットワークと１つ以上のサービスインスタンスを選択すると、クライアントネットワーキングスタックをトリガーして、そのネットワークに接続し、ネットワーク接続を確立すると、接続する前記ユーザが指定している適当なサービスインスタンス情報により上位レイヤディスカバリメカニズムをトリガーする、請求項１３に記載の装置。
【請求項１９】
前記装置は前記近くにいる他の装置の代わりにレスポンスメッセージを送信する、請求項１０に記載の装置。
【図１】
【公表番号】特表２０１１−５１７８８４（Ｐ２０１１−５１７８８４Ａ）
【公表日】平成２３年６月１６日（２０１１．６．１６）
【国際特許分類】
【出願番号】特願２０１０−５５０９２６（Ｐ２０１０−５５０９２６）
【出願日】平成２１年３月１９日（２００９．３．１９）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３７６７５
【国際公開番号】ＷＯ２００９／１２０５７６
【国際公開日】平成２１年１０月１日（２００９．１０．１）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公表日】平成２３年６月１６日（２０１１．６．１６）
【国際特許分類】
【出願日】平成２１年３月１９日（２００９．３．１９）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３７６７５
【国際公開番号】ＷＯ２００９／１２０５７６
【国際公開日】平成２１年１０月１日（２００９．１０．１）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]