JP2014160319A - 通信装置、通信装置の制御方法、プログラム - Google Patents

通信装置、通信装置の制御方法、プログラム Download PDF

Info

Publication number
JP2014160319A
JP2014160319A JP2013029950A JP2013029950A JP2014160319A JP 2014160319 A JP2014160319 A JP 2014160319A JP 2013029950 A JP2013029950 A JP 2013029950A JP 2013029950 A JP2013029950 A JP 2013029950A JP 2014160319 A JP2014160319 A JP 2014160319A
Authority
JP
Japan
Prior art keywords
communication
service
sta
address
search
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2013029950A
Other languages
English (en)
Other versions
JP2014160319A5 (ja
Inventor
Fumihide Goto
史英 後藤
Original Assignee
Canon Inc
キヤノン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc, キヤノン株式会社 filed Critical Canon Inc
Priority to JP2013029950A priority Critical patent/JP2014160319A/ja
Publication of JP2014160319A publication Critical patent/JP2014160319A/ja
Publication of JP2014160319A5 publication Critical patent/JP2014160319A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/14Direct-mode setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/10Mapping of addresses of different types; Address resolution
    • H04L61/103Mapping of addresses of different types; Address resolution across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/16Service discovery or service management, e.g. service location protocol [SLP] or Web services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/20Address allocation
    • H04L61/2007Address allocation internet protocol [IP] addresses
    • H04L61/2015Address allocation internet protocol [IP] addresses using the dynamic host configuration protocol [DHCP] or variants
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks

Abstract

【課題】 サービスをより効率的に利用することができる通信装置を提供する。
【解決手段】 通信装置は、特定のサービスを提供する装置を検索し、検索された他の通信装置と無線によって接続する。そして、接続された他の通信装置のアドレスを、前記他の通信装置から取得し、取得したアドレスに基づいて前記他の通信装置が提供するサービスを利用する。
【選択図】 図4

Description

本発明は、通信装置、通信装置の制御方法、プログラムに関する。
近年、デジタルカメラやプリンタなどの電子機器に無線LANステーション機能を搭載し、電子機器を通信装置として、無線LANに接続して使用するケースが増えてきている。例えば特許文献1には、デジタルカメラに無線LAN機能を搭載し、画像共有を容易にする方法が開示されている。
また、Wi−Fi AllianceによりWi−Fi Direct(登録商標)という規格が制定された。Wi−Fi Directでは、各電子機器が無線LANアクセスポイントまたは無線LANステーションのいずれとして動作するかを決定するプロトコルが規定されている。前記プロトコルを実行することにより、電子機器のどちらが無線LANアクセスポイントになり、どちらが無線LANステーションになるかを自動的に決定できる。このWi−Fi Directを使用することで、アクセスポイントを別途用意する必要がなくなり、電子機器同士で直接通信して各種のサービス(画像共有、印刷など)を実行することができるので、ユーザの利便性が向上する。
また、アプリケーションレイヤにおいて他装置が提供しているサービスの内容を検索する機能(サービスディスカバリ機能)が、Wi−Fi Directのオプション機能として規定されている。本サービスディスカバリ機能によれば、接続処理実行前に、接続相手となる電子機器が提供しているサービスの情報を知ることができ、ユーザの利便性が向上する。
特開2011−35768号公報
上記サービスディスカバリ機能を用いれば、無線LANレイヤの通信によって、相手装置が提供しているサービスの情報を知ることができるが、この時点では相手装置のIPアドレスは決定していない。一方、アプリケーションレイヤにおいて実行されるサービスは、TCP/IPのプロトコル上で実行されるため、サービスを利用するために相手装置のIPアドレスを知らなければならない。そのため、無線LANレイヤの接続後に改めてTCP/IP上でのサービス情報の検索が必要となり、処理の負荷がかかってしまう。
そこで本発明は、サービスをより効率的に利用することができる通信装置を提供することを目的とする。
上記目的を達成するために、本発明の通信装置は、特定のサービスを提供する装置を検索する検索手段と、前記検索手段によって検索された他の通信装置と無線によって接続する接続手段と、前記接続手段によって接続された他の通信装置のアドレスを、前記他の通信装置から取得する取得手段とを有し、前記取得したアドレスに基づいて前記他の通信装置が提供するサービスを利用することを特徴とする。
本発明によれば、サービスをより効率的に利用することができるようになる。
装置を構成するブロック図 装置内のソフトウェア機能ブロック図 本発明が適用されるネットワーク構成の一例を示す図 実施例1における通信装置間のシーケンスの一例を示す図 実施例1における通信装置のフローチャートの一例を示す図 実施例2における通信装置間のシーケンスの一例を示す図 実施例2における通信装置のフローチャートの一例を示す図 実施例3における通信装置間のシーケンスの一例を示す図 実施例3における通信装置のフローチャートの一例を示す図
[実施例1]
以下、本実施形態に係る通信装置について、図面を参照しながら詳細に説明する。以下では、IEEE802.11シリーズに準拠した無線LANシステムを用いた例について説明するが、通信形態は必ずしもIEEE802.11準拠の無線LANには限らない。
本実施形態に好適な事例におけるハードウェア構成について説明する。
図1は本発明を適用できる実施形態に係る、後述の各装置の構成の一例を表すブロック図である。101は装置全体を示す。102は、記憶部103に記憶される制御プログラムを実行することにより装置全体を制御する制御部である。制御部102は、1つ又は複数のCPUやMPU等のプロセッサを含む。制御部102は、他の装置との間で通信パラメータの設定制御も行う。103は制御部102が実行する制御プログラムと、通信パラメータ等の各種情報を記憶する記憶部である。また、記憶部103には、通信装置で生成された、又は、外部装置から受信した、画像データやファイル等を記憶してもよい。記憶部103は、ROM,RAM,HDD,フラッシュメモリ等の各種メモリによって構成される。尚、後述する各種動作は、記憶部103に記憶された制御プログラムを制御部102が実行することにより行われる。
104はIEEE802.11シリーズに準拠した無線LAN通信を行うための無線部である。105は各種表示を行う表示部でありLCDやLEDのように視覚で認知可能な情報の出力、あるいはスピーカなどの音出力が可能な機能を有する。表示部105は視覚情報および音情報の少なくともどちらか一方を出力する機能を備えるものである。
107はアンテナ制御部、そして108はアンテナである。アンテナ制御部107はアンテナ108を制御して無線通信による信号を送受信する。109は、ユーザが各種入力等を行い、通信装置を操作するための操作部である。操作部109は、各種ボタンやタッチパネル等によって構成される。
サービス提供部110は、アプリケーションレイヤにおいて提供されるサービスを実行する機能を備えている。例えば、本通信機器がプリンタである場合は、印刷機能を提供し、デジタルカメラである場合は撮像機能を提供する。
尚、図1は一例であり、通信装置101は図1に示すハードウェア構成以外のハードウェア構成を備えていてもよい。例えば通信装置101がプリンタであれば印刷部を備え、通信装置101がデジタルカメラであれば撮像部を備える。
図2は、後述の通信制御機能を実行するソフトウェア機能ブロックの構成の一例を表すブロック図である。201はソフトウェア機能ブロック全体を示す。202はDiscovery制御部であり、通信相手となる通信装置を検索する検索処理を動作させる。
203はGO Negotiation制御部である。Wi−Fi Directプロトコル仕様に基づいた制御を行い、通信装置間でどちらが無線LANアクセスポイントになり、どちらが無線LANステーションになるかといった無線レイヤにおける役割を決定する。Wi−Fi Directにおいては、無線LANアクセスポイント機能を実施する通信装置をP2Pグループオーナー(以下、GO)、無線LANステーション機能を実施する通信装置をP2Pクライアント(以下、CL)と称する。GOまたは無線LANアクセスポイントとなる場合は、後述の無線LANアクセスポイント機能制御部211が起動され、CLまたは無線LANステーションとなる場合は、後述の無線LANステーション機能制御部210が起動される。このGO NegotiationのプロトコルはWi−Fi Direct仕様で決定されている。本発明のポイントではないため、説明は割愛する。Wi−Fi DirectではGOが構築したネットワークをP2Pグループと称する。本明細書でもネットワークのことをP2Pグループと記載する場合がある。本実施例においては、これらは同一の意味で記載されている。
なお、本明細書では、P2Pグループオーナー(GO)、P2Pクライアント(CL)および役割が未決定の通信装置群をまとめて、P2Pデバイスと称す。
204はDHCPクライアント制御部であり、GO Negotiation制御部203において自通信装置の役割が無線LANステーションとなったときに起動される。205はDHCPサーバ制御部であり、GO Negotiation制御部203において自通信装置の役割が無線LANアクセスポイントとなった時に起動される。
206はWPSエンローリ制御部であり、無線LANの通信のために必要な通信パラメ―タを、他のWPSレジストラ装置より受信する。DHCPクライアント制御部204と同様に、自通信装置の役割が無線LANステーションの時に動作する。207はWPSレジストラ制御部であり、無線LANの通信のために必要な通信パラメータを、他のWPSエンローリ装置に提供する。DHCPサーバ制御部205と同様に、自通信装置の役割が無線LANアクセスポイントの時に動作する。尚、WPSレジストラによって提供される通信パラメータは、ネットワーク識別子としてのSSID、暗号鍵、暗号方式、認証鍵、認証方式等のパラメータである。
208は無線LANパケット受信部、209は無線LANパケット送信部であり、上位レイヤの通信プロトコルを含むあらゆるパケットの送受信をつかさどる。210は無線LANステーション機能制御部である。自通信装置が無線LANステーションとして動作するときの認証・暗号処理等を実施し、無線LANアクセスポイントとして動作する装置が構築した無線ネットワークに参加する。211は無線LANアクセスポイント機能制御部であり、自通信装置が無線LANアクセスポイント機能として動作するときに無線ネットワークを構築し、認証・暗号処理および通信相手装置の管理等を実施する。無線LANステーション機能制御部210および無線LANアクセスポイント機能制御部211は、どちらか一方の機能もしくは同時に動作することが可能である。
212はパケットルーティング制御部であり、無線LANアクセスポイント機能制御部211が動作しているときに、通信パケットをブリッジおよびルーティングする。213はデータ記憶部であり、ソフトウェアそのものおよび、無線LANパラメータや、前述のDHCPアドレステーブルおよびARPテーブル等の各種テーブルを記憶保持している。
214はサービスディスカバリ制御部であり、Wi−Fi Direct特有のサービスディスカバリ機能をつかさどる。サービスディスカバリ機能は、IEEE802.11uで定められたアクションフレームを送受信することにより、相手通信装置の保有しているサービス情報をやりとりする。具体的にはSD Queryを送信し、SD Responseを返答として受信する。もしくは、相手装置からのSD Queryを受信し、応答としてSD Responseを送信する。本実施例において、サービス情報とは、通信装置が提供するアプリケーションレイヤのサービスを示す情報である。アプリケーションレイヤのサービスは、印刷サービス、動画像ストリーミングサービス、ファイル転送サービス等である。また、サービス情報には、通信装置が提供するサービスにアクセスするためのURL等の識別情報が含まれることがある。
215はRARPプロトコル制御部であり、RFC903によって定められたReverse address resolution protocolを実行する。具体的には、MACアドレスをキーとして、対応するIPアドレスを取得するためのプロトコル機能を実行する。
216はアプリケーションレイヤのサービスを提供するサービス提供部である。ここでのアプリケーションレイヤとは、OSI参照モデルにおける第5層以上の上位レイヤにおけるサービス提供層のことをさす。すなわち、サービス提供部216は、例えば、印刷機能(印刷サービス)や画像ストリーミング機能(動画像ストリーミングサービス)や、ファイル転送機能(ファイル転送サービス)などを提供する。
217はアプリケーションレイヤにおけるサービス利用部である。対向となる装置のアプリケーションレイヤのサービス提供部によって提供されるサービスを利用する。すなわち、印刷サービス提供装置へ印刷物を送信する機能や、デジタルディスプレイに動画像を送信する機能などを司る。
なお、図2に示す全ての機能ブロックはソフトウェアによって提供されるものに限らず、少なくとも一部がハードウェアによって提供されるようにしてもよい。そして、図2に示す各機能ブロックは、相互関係を有するものである。また、図2に示す各機能ブロックは一例であり、複数の機能ブロックが1つの機能ブロックを構成するようにしてもよいし、何れかの機能ブロックが更に複数の機能を行うブロックに分かれてもよい。
また、本実施例において、アプケリーションレイヤにおけるサービスは、そのサービスを提供する装置と、そのサービスを利用する装置とによって実現される。アプリケーションレイヤにおけるサービスの一例として印刷サービスを例にすると、サービス提供装置はプリンタであり、PC等から送られる印刷データを受信して印刷を行う。一方、サービス利用装置はPC等の装置であり、印刷データを生成してサービス提供装置としてのプリンタに送信する。また、サービスの一例として画像ストリーミングサービスを例にすると、サービス提供装置は表示装置であり、PC等から送られる画像データを受信して表示する。一方、サービス利用装置はPC等の装置であり、画像データを生成してサービス提供装置としての表示装置に送信する。
図3は、通信装置A32(以下、STA−A)、通信装置B33(以下、STA−B)、および、STA−AとSTA−Bとから構成されるネットワークA31(以下、ネットワークA)を示した図である。これら全ての装置は、先に説明した図1、図2の構成を有している。STA−AとSTA−Bとは、それぞれWiFi−Directに対応しており、後述するシーケンス、フローチャートに示す処理を実行する。STA−AとSTA−BのうちGOとして動作する装置は、ネットワークAを構築し、CLとして動作する装置は、構築されたネットワークAに参加する。尚、本実施例において、STA−Aはサービス提供装置として動作し、STA−Bはサービス利用装置として動作するものとする。
図4は、STA−AとSTA−Bとの間の通信を示すシーケンス図である。本シーケンスでは、無線LANの接続前に、Wi−Fi Direct規格に定められたサービスディスカバリによるサービス検索を実施している。そして、所望のサービスを提供する通信装置が存在する場合に無線LANの接続処理を行い、その後、当該サービスを実行している。
サービス提供装置であるSTA−Aは、ユーザの指示により、サービスの提供を開始する(F401)。一方、サービス利用装置であるSTA−Bは、ユーザの指示により、サービス提供装置を探すために、サービス検索処理を開始する(F402)。
なお、本実施例における、アプリケーションレイヤにおけるサービス利用装置、サービス提供装置とは、例えば、以下のとおりである。
アプリケーションレイヤにおけるサービスが印刷サービスであれば、利用装置は、印刷すべき画像やデータを有し、提供装置に印刷データを送信する装置であり、提供装置は印刷機能を有し、利用装置から送られた印刷データを印刷する装置である。具体的には、前者はPCやデジタルカメラやスマートフォン等であり、後者はプリンタや複合機等である。
アプリケーションレイヤにおけるサービスが映像ストリーミングサービスであれば、利用装置は、デジタルカメラやカムコーダなどの映像記録装置であり、提供装置は、デジタルTVやプロジェクタなどの画像表示装置である。
アプリケーションレイヤにおけるサービスをDLNA(登録商標)とすると、例えば、利用装置はDMS(デジタルメディアサーバ)であり、提供装置はDMR(デジタルメディアレンダラ―)である。DLNA規格においては様々なデバイスクラスが存在するため本記述は一例である。詳細はDLNA規格を参照されたい。
アプリケーションレイヤにおけるサービスがWi−Fi miracast(登録商標)であれば、Sinkと呼ばれる映像表示装置が提供装置であり、Sourceと呼ばれる映像蓄積装置が利用装置である。
UPnPプロトコル対応デバイスであれば、提供装置はUPnPデバイスであり、利用装置はコントロールポイントである。尚、ここで例示したサービスとサービス上の役割は単なる例示であり、アプリケーションレイヤにおけるサービスと役割をこれらだけに限定する意図はない。
F402においてユーザからサービス検索処理の指示を受けたSTA−Bは、サービス検索に先立ち、通信相手となる相手装置を検索するために、Probe Request信号をブロードキャスト送信する(F403)。
STA−Aは前記Probe Request信号を受信すると、Probe Response信号をSTA―Bへ返信する(F404)。STA−Bは、前記Probe Response信号を受信することで、通信相手となる候補の装置として、STA−Aが存在することを認識できる。したがって、STA−Bは、ユーザ所望のサービスをSTA−Aが提供可能かを調べるために、SD Query信号を送信する(F405)。SD Query信号とは、前述の通り、送信先の通信装置が所望のサービスを提供しているか否かを問い合わせるための問い合わせ信号である。SD Query信号は全サービスを検索するためのワイルドカードを指定しても良いし、特定のサービスを指定してもよい。そして本SD Query信号による問い合わせは、通信装置間が無線LANによる接続を実施する前(pre−association状態)に実施可能である。
SD Query信号を受信したSTA−Aは、その応答としてSD Response信号を送信する(F406)。SD Query信号がワイルドカードを指定したものであった場合、SD Response信号には、STA−Aが提供するサービスを示す情報が含まれている。また、SD Query信号が特定のサービスを指定したものであった場合、SD Response信号には、STA−Aが当該特定のサービスを提供可能であるか否かを示す情報が含まれている。STA−Aは、SD Response信号を送信する時に、SD Query信号を送信したSTA−BのMACアドレス等の識別情報を自身の記憶部に保持する。
STA−Bは、SD Response信号の内容を参照し、ユーザの判断もしくは通信装置の自律的な判断により所望のサービスがSTA−Aで提供可能であることが確認された場合、STA−AのMACアドレス等の識別情報を記憶部へ保持する。そして、ユーザの指示に応じて、所望のサービスのサービス開始指示を行う(F407)。
なお、ここではProbe Request信号により通信装置の検索を行った後に、SD Query信号により提供サービスの問い合わせを行う例について説明した。しかし、Probe Request信号に、アプリケーションレイヤのサービスに関連する追加情報要素を付与し、Probe Request信号のみで相手装置のサービスも含めて検索しても良い。この場合は、SD Query信号およびSD Response信号のやり取りは行わなくても良い。ただし、お互いのMACアドレス等の識別情報の保持は同様に実施する。
図4の説明に戻る。STA−Bは、サービス開始指示F407に応じて、無線LANの接続処理を実施する。本実施例においては、Wi−Fi Direct規格に基づいた無線LAN接続処理を実施するため、Group Formation処理を実施する(F408)。本処理は、前述のGO Negotiation制御部203により制御される。Group Formation処理とは、前述の通り、2台の通信装置のどちらがGOになり、どちらがCLになるかを決定する役割決定の処理である。この役割決定処理の結果、STA−AがGOとして動作を開始し(F409)、STA−BがCLとして動作を開始するとする(F410)。
したがって、STA−AをWPSレジストラとしSTA−BをWPSエンローリとしてWPSパラメータ交換処理が実行される(F411)。
引き続き、STA−AをDHCPサーバとして、STA―BをDHCPクライアントとしてIPアドレスの設定処理を実行する(F412)。
F405、F406におけるサービスディスカバリ処理によって、STA−Aのサービス情報はSTA−Bに通知されている。そこで、アプリケーションレイヤによるサービス処理を実施するのに必要なSTA−AのIPアドレスを取得するために、RARPプロトコルを実施する。RARPプロトコルを使う理由は、STA−AのMACアドレスは既に取得済みだからである。
すなわち、STA−BがRARPリクエストをSTA−Aに送信する(F413)。それに応答して、STA−AはRARPレスポンスをSTA−Bに送信する(F414)。
ここで、IPアドレスの取得処理を行う理由は、DLNAやBonjourなどのアプリケーションレイヤのプロトコルはTCP/IP上で動作しており、アプリケーションレイヤでのサービス実施のためにはIPアドレスが必要不可欠だからである。
F413,F414に示したRARPプロトコル処理により、STA−Bはサービス処理に必要なSTA−AのIPアドレスを確認できる。そのため、TCP/IP上における機器検索機能(例えばUPnPやBonjourなど)を再度実施することなく、アプリケーションレイヤにおけるサービスを実施することが可能となる(F415)。
なお、本シーケンス図では各種信号においてサービス利用装置が要求信号を送信して、その応答をサービス提供装置から受領する例を記載した。しかし、サービス提供装置から要求信号を送信して、その応答をサービス利用装置から受領しても良いし、信号の種類によってそれぞれの要求信号の送信装置を変えても良い。
図5は、本実施例の通信装置の動作を示すフローチャートである。本フローチャートの各ステップは、記憶部103に記憶されたプログラムを制御部102が実行することによって処理される。
通信装置は、ユーザの指示により処理が開始されると、自装置のサービス処理での役割を判定する(S501)。自装置がサービス利用装置である場合は、サービス提供装置を探すため、サービス検索を実施する(S502)。該サービス検索処理は、Wi−Fi Direct規格に定められたサービスディスカバリ処理を用いる。なお、サービスディスカバリ処理とは、図4で説明したように、Probe Request信号によるデバイスディスカバリ処理を行い、前記デバイスディスカバリ処理で検出された通信装置に向けて、サービス問い合わせを行うものである。
通信装置は、前記サービス検索処理において、所望のサービスを提供しているサービス提供装置が検出できたか否かを判定する(S503)。
S503における判定処理において、相手装置が存在しない場合、もしくは、相手装置となる通信装置は検出できたものの、所望のサービスを提供していない場合は、通信装置は、エラー処理を実施して処理を中止する(S510)。
一方、ステップS503において、相手装置を検出でき、なおかつ所望のサービスを提供していることが判明した場合は、通信装置は、サービス処理の準備処理を開始する(S504)。本ステップにおいて、通信装置は、通信相手となる相手装置のMACアドレスを、識別情報として記憶部103に記憶しておく。
続いて、アプリケーションレイヤにおけるサービス処理を実行するために、先ず無線LANレイヤでの接続処理を実施する。具体的には、Wi−Fi Direct規格に基づいた接続処理のため、通信装置は、Group Formationと言われる役割決定処理を実施する(S505)。ここで決定する役割とは、前述したGOかCLかの役割である。
前記役割が決定した後、通信装置は、無線LANパラメータおよびIPアドレスを設定するパラメータ設定処理を実施する(S506)。尚、本フローチャートではS506を一つのステップとして記載したが、具体的には、図2の説明で述べた通り、WPSプロトコルによる無線パラメータ設定処理および、DHCPプロトコルによるIPアドレス割り当て処理が行われる。即ち、GOとなった装置がWPSレジストラとなり、CLとなった装置がWPSエンローリとなり、GOの保有する無線LAN接続に必要なパラメータを転送する。引き続きGOがDHCPサーバとなり、CLがDHCPクライアントとなりIPアドレスの割り当て処理を実施する。
ここで、自装置および相手装置にIPアドレスが割り当てられたため、サービス検索処理で入手したMACアドレスについて、IPアドレスと対応付ける必要がある。DLNA、Bonjour,IPPなどのアプリケーションレイヤのプロトコルは、TCP/IP上で動作しているため、アプリケーションレイヤのサービスを実行するためにはIPアドレスが必要不可欠だからである。
そこで、通信装置は、RFC903によって定められたRARPプロトコルに基づいた、MACアドレスからのIPアドレス取得処理を実施する(S507)。S507における取得処理の完了後、通信装置は、ステップS504において記憶した識別情報をMACアドレスからIPアドレスに変更する付け替え処理を実施する(S508)。この付け替え処理により、サービス実施に必要な情報が確定したため、通信装置はサービス処理を行うことが可能となる(S509)。
一方、S501において、自装置がサービス提供装置であると判定された場合は、通信装置は速やかにサービスを開始する(S511)。具体的には自装置が提供している、もしくは提供予定のアプリケーションレイヤでのサービス情報についてUPnPやBonjourなどで報知する。また、Wi−Fi Direct規格で定められたサービスディスカバリ処理で検索された場合に応答するための情報設定を行う。
通信装置は、サービスを開始した後、サービス利用装置に検出されることを待ちうける(S512)。サービス利用装置としての相手装置から検出された場合は、先に説明したサービス利用装置と同様に、ステップS505からステップS509までの処理を実施する。
なお、サービス利用装置から検出されない場合は、されるまで待ちうける。ここでは所定の時間でタイムアウトとして処理をエラー終了しても良い。
なお、本フローチャート図では各種信号においてサービス利用装置が要求信号を送信して、その応答をサービス提供装置から受領する例を記載したが。しかし、サービス提供装置から要求信号を送信して、その応答をサービス利用装置から受領しても良いし、信号の種類によってそれぞれの要求信号の送信装置を変えても良い。
以上のように、本実施例によれば、無線LAN接続完了後に改めてUPnPもしくはBonjour等のプロトコルによる再検索をすることがなくなり、処理の負荷が減る。そして、無線LAN接続前に実施するサービス検索処理によって通信相手を決定することができ、サービス実施までの時間を短縮することが可能となり、サービスをより効率的に利用することができる。
[実施例2]
実施例1では、無線LANレイヤにおけるディスカバリ処理において取得したMACアドレスを記憶しておき、RARPを用いて、そのMACアドレスから対応するIPアドレスを取得する方法を説明した。本実施においては、RARPプロトコルを用いずに、IPアドレスが確定した時点で通信パケットによる通知を実施する場合について説明する。なお、各装置の構成は実施例1と同様に図1および図2に示した通りであり、システム構成は図3の通りであるため、これらの説明は省略する。
図6は、実施例2におけるSTA−AとSTA−Bとの間の通信を示すシーケンス図である。本シーケンスは、実施例1の図4に示したシーケンス処理と一部が異なる。図4と同一の処理については同一の番号を付与している。
サービス提供装置であるSTA−Aは、ユーザの指示により、サービスの提供を開始する(F401)。一方、サービス利用装置であるSTA−Bは、ユーザの指示により、サービス提供装置を探すために、サービス検索処理を開始する(F402)。
F402においてユーザからサービス検索処理の指示を受けたSTA−Bは、サービス検索に先立ち、通信相手となる相手装置を検索するために、Probe Request信号をブロードキャスト送信する(F403)。
STA−Aは前記Probe Request信号を受信すると、Probe Response信号をSTA―Bへ返信する(F404)。STA−Bは、前記Probe Response信号を受信することで、通信相手となる候補の装置として、STA−Aが存在することを認識できる。したがって、STA−Bは、ユーザ所望のサービスをSTA−Aが提供可能かを調べるために、SD Query信号を送信する(F405)。SD Query信号とは、前述の通り、送信先の通信装置が所望のサービスを提供しているか否かを問い合わせるための問い合わせ信号である。SD Query信号は全サービスを検索するためのワイルドカードを指定しても良いし、特定のサービスを指定してもよい。そして本SD Query信号による問い合わせは、通信装置間が無線LANによる接続を実施する前(pre−association状態)に実施可能である。
SD Query信号を受信したSTA−Aは、その応答としてSD Response信号を送信する(F406)。SD Query信号がワイルドカードを指定したものであった場合、SD Response信号には、STA−Aが提供するサービスを示す情報が含まれている。また、SD Query信号が特定のサービスを指定したものであった場合、SD Response信号には、STA−Aが当該特定のサービスを提供可能であるか否かを示す情報が含まれている。STA−Aは、SD Response信号を送信する時に、SD Query信号を送信したSTA−BのMACアドレス等の識別情報を自身の記憶部に保持する。
STA−Bは、SD Response信号の内容を参照し、ユーザの判断もしくは通信装置の自律的な判断により所望のサービスがSTA−Aで提供可能であることが確認された場合、STA−AのMACアドレス等の識別情報を記憶部へ保持する。そして、ユーザの指示に応じて、所望のサービスのサービス開始指示を行う(F407)。
なお、ここではProbe Request信号により通信装置の検索を行った後に、SD Query信号により提供サービスの問い合わせを行う例について説明した。しかし、Probe Request信号に、アプリケーションレイヤのサービスに関連する追加情報要素を付与し、Probe Request信号のみで相手装置のサービスも含めて検索しても良い。この場合は、SD Query信号およびSD Response信号のやり取りは行わなくても良い。ただし、お互いのMACアドレス等の識別情報の保持は同様に実施する。
STA−Bは、サービス開始指示F407に応じて、無線LANの接続処理を実施する。本実施例においては、Wi−Fi Direct規格に基づいた無線LAN接続処理を実施するため、Group Formation処理を実施する(F408)。本処理は、前述のGO Negotiation制御部203により制御される。Group Formation処理とは、前述の通り、2台の通信装置のどちらがGOになり、どちらがCLになるかを決定する役割決定の処理である。この役割決定処理の結果、STA−AがGOとして動作を開始し(F409)、STA−BがCLとして動作を開始するとする(F410)。
したがって、STA−AをWPSレジストラとしSTA−BをWPSエンローリとしてWPSパラメータ交換処理が実行される(F411)。
引き続き、STA−AをDHCPサーバとして、STA―BをDHCPクライアントとしてIPアドレスの設定処理を実行する(F412)。
F405、F406におけるサービスディスカバリ処理によって、STA−Aのサービス情報はSTA−Bに通知されている。そこで、アプリケーションレイヤによるサービス処理を実施するのに必要なSTA−AのIPアドレスを、STA−AはSTA−Bへ通知する。ここでは、SD Query信号およびSD Response信号のやり取りによって、STA−AはIPアドレスをSTA−Bへ通知する。
すなわち、STA−BがSD Query信号をSTA−Aに送信する(F601)。それに応答して、STA−AはSD Response信号をSTA−Bに送信する(F602)。尚、F601において送信されるSD Query信号は、F405において送信されるSD Query信号と内容が異なる。F405において送信されるSD Query信号は、STA−Aが提供するサービスを問い合わせるものであったのに対して、F601のSD Query信号は、STA−AのIPアドレスを問い合わせるものとなっている。即ち、601において送信されるSD Query信号とF405において送信されるSD Query信号とでは、問い合わせる情報の内容が異なっている。
ここで、IPアドレスの通知処理を行う理由は、DLNAやBonjourなどのアプリケーションレイヤのプロトコルがTCP/IP上で動作しており、アプリケーションレイヤでのサービス実施のためにはIPアドレスが必要不可欠だからである。
F601,F601のIPアドレス通知処理により、STA−Bはサービス処理に必要なSTA−AのIPアドレスを確認できる。そのため、TCP/IP上における機器検索機能(例えばUPnPやBonjourなど)を再度実施することなく、アプリケーションレイヤにおけるサービスを実施することが可能となる(F415)。
本実施例2においてはIPアドレスの通知にSD Query信号とSD Response信号とを用いたが、それ以外の信号(IEEE802.11規格で定められたアクションフレームなど)を用いてもよい。STA−AからSTA−BへIPアドレスを通知できるものであればよい。図6のシーケンス図は信号種別を限定する意図はない。
なお、本シーケンス図では各種信号においてサービス利用装置が要求信号を送信して、その応答をサービス提供装置から受領する例を記載した。しかし、サービス提供装置から要求信号を送信して、その応答をサービス利用装置から受領しても良いし、信号の種類によってそれぞれの要求信号の送信装置を変えても良い。
図7は、本実施例の通信装置の動作を示すフローチャートである。本フローチャートの各ステップは、記憶部103に記憶されたプログラムを制御部102が実行することによって処理される。図7のフローチャートにおいて、実施例1の図5で説明したフローチャートと同一の処理については同一の番号を付与してある。
通信装置は、ユーザの指示により処理が開始されると、自装置のサービス処理での役割を判定する(S501)。自装置がサービス利用装置である場合は、サービス提供装置を探すため、サービス検索を実施する(S502)。該サービス検索処理は、Wi−Fi Direct規格に定められたサービスディスカバリ処理を用いる。なお、サービスディスカバリ処理とは、図4で説明したように、Probe Request信号によるデバイスディスカバリ処理を行い、前記デバイスディスカバリ処理で検出された通信装置に向けて、サービス問い合わせを行うものである。
通信装置は、前記サービス検索処理において、所望のサービスを提供しているサービス提供装置が検出できたか否かを判定する(S503)。
S503における判定処理において、相手装置が存在しない場合もしくは、相手装置となる通信装置は検出できたものの、所望のサービスを提供していない場合は、通信装置は、エラー処理を実施して処理を中止する(S510)。
一方、ステップS503において、相手装置を検出でき、なおかつ所望のサービスを提供していることが判明した場合は、通信装置は、サービス処理の準備処理を開始する(S504)。本ステップにおいて、通信装置は通信相手となる相手装置のMACアドレスを識別情報として記憶部103に記憶しておく。
続いて、アプリケーションレイヤにおけるサービス処理を実行するために、先ず無線LANレイヤでの接続処理を実施する。具体的には、Wi−Fi Direct規格に基づいた接続処理のため、通信装置は、Group Formationと言われる役割決定処理を実施する(S505)。ここで決定する役割とは、前述したGOかCLかの役割である。
前記役割が決定した後、通信装置は、無線LANパラメータおよびIPアドレスを設定するパラメータ設定処理を実施する(S506)。尚、本フローチャートではS506を一つのステップとして記載したが、具体的には、図2の説明で述べた通り、WPSプロトコルによる無線パラメータ設定処理および、DHCPプロトコルによるIPアドレス割り当て処理が行われる。即ち、GOとなった装置がWPSレジストラとなり、CLとなった装置がWPSエンローリとなり、GOの保有する無線LAN接続に必要なパラメータを転送する。引き続きGOがDHCPサーバとなり、CLがDHCPクライアントとなりIPアドレスの割り当て処理を実施する。
ここで、自装置および相手装置にIPアドレスが割り当てられたため、サービス検索処理で入手したMACアドレスについて、IPアドレスと対応付ける必要がある。DLNA、Bonjour,IPPなどのアプリケーションレイヤのプロトコルは、TCP/IP上で動作しているため、アプリケーションレイヤのサービスを実行するためにはIPアドレスが必要不可欠だからである。
したがって、IEEE802.11に定められたアクションフレーム等を用いて、サービス提供装置とサービス利用装置の間でお互いの装置のIPアドレスの通知処理を実施する(S701)。具体的には、S502で実施したのと同様のSD Query信号とSD Response信号のやり取りによってIPアドレスを通知しあう。本説明ではアクションフレームを例として挙げたが、それ以外のパケットを用いる方法でもかまわない。
S701における通知処理の完了後、通信装置は、ステップS504において記憶した識別情報をMACアドレスからIPアドレスに変更する付け替え処理を実施する(S508)。この付け替え処理により、サービス実施に必要な情報が確定したため、通信装置はサービス処理を行うことが可能となる(S509)。
一方、S501において、自装置がサービス提供装置であると判定された場合は、通信装置は速やかにサービスを開始する(S511)。具体的には自装置が提供している、もしくは提供予定のアプリケーションレイヤでのサービス情報についてUPnPやBonjourなどで報知する。また、Wi−Fi Direct規格で定められたサービスディスカバリ処理で検索された場合に応答するための情報設定を行う。
通信装置は、サービスを開始した後、サービス利用装置に検出されることを待ちうける(S512)。サービス利用装置としての相手装置から検出された場合は、先に説明したサービス利用装置と同様に、ステップS505からステップS509までの処理を実施する。
なお、サービス利用装置から検出されない場合は、されるまで待ちうける。ここでは所定の時間でタイムアウトとして処理をエラー終了しても良い。
なお、本フローチャート図では各種信号においてサービス利用装置が要求信号を送信して、その応答をサービス提供装置から受領する例を記載したが。しかし、サービス提供装置から要求信号を送信して、その応答をサービス利用装置から受領しても良いし、信号の種類によってそれぞれの要求信号の送信装置を変えても良い。
以上のように、本実施例によれば、無線LAN接続完了後に改めてUPnPもしくはBonjour等のプロトコルによる再検索をすることがなくなり、処理の負荷が減る。そして無線LAN接続前に実施するサービス検索処理によって通信相手を決定することができ、サービス実施までの時間を短縮することが可能となり、サービスをより効率的に利用することができる。さらに、IPアドレスの通知を一般的なSD Query/SD Response信号などの交換で実施することで、特別なプロトコルの実装が不要となるため、装置の処理負荷の増加を防ぎ、サービスを更に効率的に実行することが可能となる。
[実施例3]
実施例1および実施例2においては、無線LANレイヤでの接続を実施する前に、F405やF406の処理によりサービスディスカバリを実施する例について説明した。本実施例3では、既に無線LANレイヤにおいて接続済みの場合について説明する。なお、各装置の構成は実施例1および2と同様に図1および図2に示した通りであり、システム構成は図3の通りであるため、これらの説明は省略する。
図8は、実施例3におけるSTA−AとSTA−Bとの間の通信を示すシーケンス図である。図8は、無線LANの接続が完了した後に、Wi−Fi Direct規格に定められたサービスディスカバリによるサービス検索を実施し、所望の通信装置が存在する場合に、サービス処理を行う場合の通信装置間の処理を示している。
まず、STA−AとSTA−Bにおいて、無線LAN接続をユーザの指示により開始する(F801、F802)。
STA−Bは、通信相手となる機器を検索するために、Probe Request信号をブロードキャスト送信する(F803)。
STA−Aは前記Probe Request信号を受信すると、Probe Response信号をSTA―Bへ返信する(F804)。STA−Bは、前記Probe Response信号を受信することで、通信相手となる候補の装置として、STA−Aが存在することを認識できる。
したがって、STA−AとSTA−Bとの間で無線LAN接続処理を実施する。本実施例においては、Wi−Fi Direct規格に基づいた無線LAN接続処理を実施するため、STA−AとSTA−Bは、Group Formation処理を実施する(F805)。本処理は、前述のGO Negotiation制御部203により制御される。Group Formation処理とは、前述の通り、2台の通信装置のどちらがGOになり、どちらがCLになるかを決定する役割決定の処理である。
前記役割決定処理の結果、STA−AがGOとして動作を開始し(F806)、STA−BがCLとして動作を開始する(F807)。
したがって、STA−AをWPSレジストラとしSTA−BをWPSエンローリとしてWPSパラメータ交換処理が実行される(F808)。
引き続き、STA−AをDHCPサーバとして、STA―BをDHCPクライアントとしてアドレス設定処理を実行する(F809)。
無線LAN接続が完了した後、サービス提供装置であるSTA−Aは、ユーザの指示により、サービス提供を開始する(F810)。一方、サービス利用装置であるSTA−Bは、ユーザの指示により、サービス提供装置を探すために、サービス検索処理を開始する(F811)。
前記サービス検索処理の指示を受けたSTA−Bは、ユーザが所望とするサービスをSTA−Aが提供できるかを調べるために、SD Query信号を送信する(F812)。SD Query信号とは、前述の通り、送信先の通信装置が所望のサービスを提供しているか否かを問い合わせるための問い合わせ信号である。SD Query信号は全サービスを検索するためのワイルドカードを指定しても良いし、特定のサービスを指定してもよい。
SD Query信号を受信したSTA−Aは、その応答としてSD Response信号を送信する(F813)。SD Query信号がワイルドカードを指定したものであった場合、SD Response信号には、STA−Aが提供するサービスを示す情報が含まれている。また、SD Query信号が特定のサービスを指定したものであった場合、SD Response信号には、STA−Aが当該特定のサービスを提供可能であるか否かを示す情報が含まれている。STA−Bは、SD Response信号の内容を参照し、ユーザの判断もしくは通信装置の自律的な判断により所望のサービスがSTA−Aで提供可能であることが確認された場合、ユーザの指示に応じて、サービス開始指示を行う(F814)。
F812、F813におけるサービスディスカバリ処理によってお互いのデバイスのサービス情報は交換されているため、実際のアプリケーションレイヤによるサービス処理を実施することが可能となる(F815)。 なお、本シーケンス図では各種信号においてサービス利用装置が要求信号を送信して、その応答をサービス提供装置から受領する例を記載した。しかし、サービス提供装置から要求信号を送信して、その応答をサービス利用装置から受領しても良いし、信号の種類によってそれぞれの要求信号の送信装置を変えても良い。
本実施例3においては既にサービスディスカバリ処理時点で無線LANによる接続処理も完了しており、IPアドレスが判明しているため、実施例1および実施例2とは処理が異なる。
本実施例3の説明においては、無線LAN接続のみを単独で実施した後に、アプリケーションレイヤのサービス検索、処理実行を行う例について説明した。しかし、あらかじめ実施例1または実施例2に示したアプリケーションレイヤでのサービス実行を実施した後に、無線LAN接続を保持したまま、別のサービス検索、実行を行う場合にも適用可能である。例えば、STA−BからSTA−Aにメタデータファイルを送信した後に引き続き、動画像ストリーミング処理を行う場合などが挙げられる。
図9は、本実施例の通信装置の動作を示すフローチャートである。本フローチャートの各ステップは、記憶部103に記憶されたプログラムを制御部102が実行することによって処理される。
まず通信装置は無線LAN接続を開始するために、相手装置を検出したか否かを判定する(S901)。ある所定の時間内で検出されない場合は、エラー終了をする(S911)。
ステップS901において、相手装置を検出した場合は、先ず無線LAN接続を実施する。ここではWi−Fi Direct仕様に基づいたGroup Formationと呼ばれる役割決定の処理を実施する(S902)。
ステップS902により通信装置の役割が決定した後、無線LANパラメータおよびIPアドレスを設定するパラメータ設定処理を実施する(S903)。本フローチャートでは一つのステップとして記載したが、具体的には、図2の説明で述べた通り、WPSプロトコルによる無線パラメータ設定処理および、DHCPプロトコルによるIPアドレス割り当て処理が実行される。具体的には、GOとなった装置がWPSレジストラとなり、CLとなった装置がWPSエンローリとなり、GOの保有する無線LAN接続に必要なパラメータを転送する。引き続き、GOがDHCPサーバとなり、CLがDHCPクライアントとなりIPアドレスの割り当て処理を実施する。以上で無線LANレイヤでの接続処理が完了する。
引き続きサービス処理を実施する。まずはユーザからの指示によりサービス開始要求がされたかどうかを判定する(S904)。サービス開始要求がない場合は、前記要求がされるまで待ちうける。もしくは、所定の時間待ちうけても要求がない場合は、タイムアウトエラーとして処理を中止しても良い。
さて、ステップS904にてサービス開始要求がなされた場合は、自装置のサービス役割を判定する(S905)。ここでのサービス役割とは、アプリケーションレイヤにおける各種サービスの提供装置になるのか利用装置になるのかの役割である。
ステップS905のサービス役割判定において、自装置がサービス提供装置であると判定された場合について説明する。自装置がサービス提供装置である場合は、サービス利用装置となる相手装置からのSD Query信号を待ちうける(S906)。相手装置からのSD Queryが所定の時間内に到着しない場合はエラー終了とする。なお、時間制限を設けずに、ユーザの指示による明示的なキャンセルがない限り待ち続けるようにしてもよい。
S906においてSD Queryを受信した場合、対応したSD Response信号を送信する(S907)。
S907においてサービスディスカバリ処理の応答としてSD Response信号を送信した後は、相手装置のIPアドレスを判定する(S908)。ここでのIPアドレスの判定処理とは、自装置がGOの場合は、自ら決定した自装置のIPアドレスと、自装置がDHCPサーバとして割り当てた相手装置のIPアドレスを記憶することである。また、自装置がCLの場合は、相手装置から受領した自装置のIPアドレスと、その相手装置のIPアドレスとを記憶する。
一方S905において自装置がサービス利用装置である場合について説明する。サービス利用装置となった自装置は、サービス提供元となる相手装置を検索するため、SD Query信号を送信する(S912)。前記SD Query信号を送信後、相手装置からSD Responseを受信する(S913)。なお、S913においてSD Responseを受信しない場合は、再度SD Queryを送信するところからやり直す。なお所定の時間たってもレスポンスを受信しないか、サービスが対応していない場合は、エラー終了としてもよい。
本実施例3の説明においては、無線LAN接続のみを単独で実施した後に、アプリケーションレイヤのサービス検索、処理実行を行う例について説明した。しかし、あらかじめ実施例1または実施例2に示したアプリケーションレイヤでのサービス実行を実施した後に、無線LAN接続を保持したまま、別のサービス検索、実行を行う場合にも適用可能である。例えば、STA−BからSTA−Aにメタデータファイルを送信した後に引き続き、動画像ストリーミング処理を行う場合などが挙げられる。
以上のように、本実施例3によれば、既に無線LANレイヤにおいて接続済みの場合に、Wi−FI Direct規格のサービスディスカバリ処理を実施することによって、アプリケーションレイヤのサービスを利用することができる。つまり、複雑な独自プロトコルを用いることなく、アプリケーションレイヤのサービスを利用することができるので、サービスをより効率的に利用することができるようになる。
[その他の実施形態]
上記の各実施例は、本発明を実施するための一例を示すものであり、本発明の趣旨を逸脱しない限り種々の変更が可能である。また、上記実施例1〜3は組み合わせることができる。また、各通信装置が、実施例1〜3のどれに従って動作するかをユーザが任意に選択できるようにしてもよい。
上記実施例では、DHCPによってIPアドレスが割り当てられた後、アプリケーションレイヤのサービスを利用するために必要な情報として、IPアドレスを問い合わせたり通知する構成について説明した。しかし、アプリケーションレイヤのサービスを利用するために必要な情報としては、IPアドレスに限らず、その他の情報であってもよい。例えば、サービスにアクセスするための宛先となるURLや、TCP/IPのポート番号などの情報であってもよい。
尚、上記実施例の通信装置は、デジタルカメラやプリンタ等に限らない。PCやタブレット端末であってもよく、携帯電話やスマートフォン等のモバイル端末であってもよい。また、複写機やスキャナ、FAX、複合機等の画像処理装置、テレビやレコーダー等のデジタル家電であってもよい。
また、上記実施形態はIEEE802.11準拠の無線LANを例に説明した。しかしながら、本発明は、ワイヤレスUSB、MBOA、Bluetooth(登録商標)、UWB、ZigBee(登録商標)等の他の無線通信において実施してもよい。また、有線LAN等の有線通信媒体において実施してもよい。ここで、MBOAは、Multi Band OFDM Allianceの略である。また、UWBは、ワイヤレスUSB、ワイヤレス1394、WINETなどが含まれる。
更に、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム又は装置のコンピュータ(又はCPUやMPU等)がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
102 制御部
103 記憶部
104 無線部
105 表示部

Claims (9)

  1. 通信装置であって、
    特定のサービスを提供する装置を検索する検索手段と、
    前記検索手段によって検索された他の通信装置と無線によって接続する接続手段と、
    前記接続手段によって接続された他の通信装置のアドレスを、前記他の通信装置から取得する取得手段と、
    を有し、
    前記取得したアドレスに基づいて前記他の通信装置が提供するサービスを利用することを特徴とする通信装置。
  2. 前記取得手段は、他の通信装置のMACアドレスを元に、当該他の通信装置のIPアドレスを取得することを特徴とする請求項1記載の通信装置。
  3. 前記取得手段は、RARPを用いて前記他の通信装置のアドレスを取得することを特徴とする請求項1又は2に記載の通信装置。
  4. 前記検索手段によって検索された他の通信装置との間で、無線通信の際の役割を決定する決定手段と、
    前記接続手段は、前記決定手段によって決定された役割に従って、無線ネットワークを構築又は無線ネットワークに参加し、他の通信装置と接続することを特徴とする請求項1乃至3の何れか一項に記載の通信装置。
  5. 前記決定手段によって、無線ネットワークを構築する装置としての役割に決定した場合、他の通信装置にアドレスを割り当てる割り当て手段と、
    前記決定手段によって、構築された無線ネットワークに参加する装置としての役割に決定した場合、他の通信装置からアドレスの割り当てを受ける受信手段と、
    を有することを特徴とする請求項1乃至4の何れか一項に記載の通信装置。
  6. 前記サービスは、印刷サービス、動画像ストリーミングサービス、ファイル転送サービスの何れかを含むことを特徴とする請求項1乃至5の何れか一項に記載の通信装置。
  7. 前記通信装置は、前記他の通信装置と、IEEE802.11に準拠した無線LANを用いて通信することを特徴とする請求項1乃至6の何れか一項に記載の通信装置。
  8. 通信装置の制御方法であって、
    特定のサービスを提供する装置を検索する検索工程と、
    前記検索工程によって検索された他の通信装置と無線によって接続する接続工程と、
    前記接続工程によって接続された他の通信装置のアドレスを、前記他の通信装置から取得する取得工程と、
    を有し、
    前記取得したアドレスに基づいて前記他の通信装置が提供するサービスを利用することを特徴とする通信装置の制御方法。
  9. 請求項1乃至7の何れか一項に記載の通信装置として、コンピュータを動作させるためのプログラム。
JP2013029950A 2013-02-19 2013-02-19 通信装置、通信装置の制御方法、プログラム Pending JP2014160319A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013029950A JP2014160319A (ja) 2013-02-19 2013-02-19 通信装置、通信装置の制御方法、プログラム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2013029950A JP2014160319A (ja) 2013-02-19 2013-02-19 通信装置、通信装置の制御方法、プログラム
US14/768,430 US9924554B2 (en) 2013-02-19 2014-02-14 Communication apparatus, control method for the communication apparatus, and non-transitory computer-readable storage medium
PCT/JP2014/000763 WO2014129153A1 (en) 2013-02-19 2014-02-14 Communication apparatus, control method for the communication apparatus, and program

Publications (2)

Publication Number Publication Date
JP2014160319A true JP2014160319A (ja) 2014-09-04
JP2014160319A5 JP2014160319A5 (ja) 2016-04-07

Family

ID=51390953

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013029950A Pending JP2014160319A (ja) 2013-02-19 2013-02-19 通信装置、通信装置の制御方法、プログラム

Country Status (3)

Country Link
US (1) US9924554B2 (ja)
JP (1) JP2014160319A (ja)
WO (1) WO2014129153A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6324188B2 (ja) * 2014-04-23 2018-05-16 キヤノン株式会社 通信装置
JP6385205B2 (ja) * 2014-09-01 2018-09-05 キヤノン株式会社 通信装置、通信装置の制御方法およびプログラム
US10993110B2 (en) * 2018-07-13 2021-04-27 Nvidia Corp. Connectionless fast method for configuring Wi-Fi on displayless Wi-Fi IoT device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050286075A1 (en) * 2004-06-25 2005-12-29 Samsung Electronics Co., Ltd. Wireless printing system and method based on IEEE 802.11
US20090010184A1 (en) * 2007-07-05 2009-01-08 Vesa Luiro Device and method for bidirectional communication
WO2009120576A2 (en) * 2008-03-24 2009-10-01 Intel Corporation Techniques for discovering services provided in a wireless network
US20110149806A1 (en) * 2009-12-22 2011-06-23 Samsung Electronics Co., Ltd. Method and apparatus for service discovery in wi-fi direct network
JP2012186643A (ja) * 2011-03-04 2012-09-27 Ricoh Co Ltd 無線通信装置、電子装置、及び簡易アクセスポイントの決定方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4443989B2 (ja) * 2003-09-10 2010-03-31 パナソニック株式会社 サービス要求端末装置
KR100590866B1 (ko) * 2003-12-04 2006-06-19 삼성전자주식회사 무선 네트워크를 통한 액세스 포인트의 무선 단말 등록방법 및 그 장치
JP2006101293A (ja) * 2004-09-30 2006-04-13 Sanyo Electric Co Ltd 通信装置、通信プログラム及び通信方法
EP1849259B1 (en) * 2004-11-05 2014-12-17 Kabushiki Kaisha Toshiba Network discovery mechanisms
US8576846B2 (en) * 2005-10-05 2013-11-05 Qualcomm Incorporated Peer-to-peer communication in ad hoc wireless network
JP4642652B2 (ja) 2005-12-26 2011-03-02 パナソニック株式会社 無線制御端末、無線通信システムおよび無線通信方法
US8243623B2 (en) 2009-03-31 2012-08-14 Intel Corporation Combined device and service discovery technique in stations supporting tunneled direct link setup (TDLS)
JP5369974B2 (ja) 2009-08-04 2013-12-18 株式会社リコー 撮像装置及び画像共有システム
JP2011228883A (ja) 2010-04-19 2011-11-10 Nec Corp ネットワーク監視装置、ネットワーク監視方法およびプログラム
JP5736987B2 (ja) 2011-06-14 2015-06-17 ブラザー工業株式会社 無線通信装置
KR102005771B1 (ko) * 2012-02-24 2019-10-01 삼성전자주식회사 무선 통신 네트워크에서 ip 주소 할당 방법 및 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050286075A1 (en) * 2004-06-25 2005-12-29 Samsung Electronics Co., Ltd. Wireless printing system and method based on IEEE 802.11
US20090010184A1 (en) * 2007-07-05 2009-01-08 Vesa Luiro Device and method for bidirectional communication
WO2009120576A2 (en) * 2008-03-24 2009-10-01 Intel Corporation Techniques for discovering services provided in a wireless network
US20110149806A1 (en) * 2009-12-22 2011-06-23 Samsung Electronics Co., Ltd. Method and apparatus for service discovery in wi-fi direct network
JP2012186643A (ja) * 2011-03-04 2012-09-27 Ricoh Co Ltd 無線通信装置、電子装置、及び簡易アクセスポイントの決定方法

Also Published As

Publication number Publication date
US20160007396A1 (en) 2016-01-07
WO2014129153A1 (en) 2014-08-28
US9924554B2 (en) 2018-03-20

Similar Documents

Publication Publication Date Title
JP6141006B2 (ja) 通信装置、制御方法、及びプログラム
JP6173011B2 (ja) 通信装置、通信装置の制御方法、プログラム
JP2015023440A (ja) 通信装置、通信方法およびプログラム
JP6214159B2 (ja) 通信装置、通信装置の制御方法、プログラム
US10021004B2 (en) Communication device, control method for communication device, and program
US20180241826A1 (en) Communication apparatus, control method therefor, and storage medium
JP2014160319A (ja) 通信装置、通信装置の制御方法、プログラム
JP6271843B2 (ja) 通信装置、その制御方法、プログラム
US9900829B2 (en) Communication device, method for controlling the communication device, and program
JP6207215B2 (ja) 通信装置、通信装置の制御方法、プログラム
JP6271838B2 (ja) 通信装置、通信装置の制御方法、プログラム
JP2014203201A (ja) 通信装置およびその制御方法、プログラム
JP6308719B2 (ja) 通信装置、その制御方法、プログラム
JP6570356B2 (ja) 通信装置、通信方法及びプログラム
JP2014165603A (ja) 通信装置、その制御方法、プログラム
JP2014110603A (ja) 通信装置、通信装置の制御方法、及びプログラム

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160215

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160913

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161111

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170124

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170905