JP2005217976A - 電子機器及びその制御方法 - Google Patents

Abstract

【課題】AutoIP等によってネットワークアドレスが設定されている状況において、ＤＨＣＰサーバ等のアドレスサーバが当該ネットワークに参加した際に生じていた、他の機器とのデータ転送の中断の可能性を低減する。
【解決手段】AutoIPにより当該電子機器自身で設定したネットワークアドレスでネットワークに接続している電子機器は、該ネットワーク上のアドレスサーバとしてのＤＨＣＰサーバの存在を検出する（Ｓ２０１〜Ｓ２０３）。アドレスサーバが検出された場合、当該電子機器が他の装置との間でデータ転送中であるか否かを判定し（Ｓ２０４）、データ転送中であると判定された場合は、当該データ転送の終了を待って、アドレスサーバから取得されるネットワークアドレスへの変更を実行する（Ｓ２０７〜Ｓ２０９）。
【選択図】 図２

Description

本発明は、ネットワークインターフェースを有する電子機器に関する。

近年、ネットワーク上の所定のサービスを提供するデバイスを探索するためのネットワーク技術が開発されている。このような技術の一つに米国マイクロソフト社が提唱するＵＰｎＰ（Universal Plug and Play）がある（非特許文献１）。ＵＰｎＰでは、「サービス」、「デバイス」及び「コントロールポイント」を規定している。サービスは所定のサービスを提供する論理的な単位であり、デバイスは１つ以上のサービスを有する論理的な単位であり、コントロールポイントは１つ以上のサービスを制御する論理的な単位である。

ＵＰｎＰはＩＰ，ＴＣＰ，ＵＤＰ，ＨＴＴＰといったインターネット標準技術によって構成されており、ネットワークに接続し、機器同士がお互いを検出し相互認識し合うまでの自動ステップと、実際に機器を制御するステップおよびイベントを発行するステップを規程している（特許文献１）を参照することとし、以下に、本発明が係わるＵＰｎＰのアドレッシングおよびディスカバリのステップについての説明を行う。

アドレッシングは、ネットワークアドレス、すなわちＩＰアドレスを取得するステップであり、ネットワークに参加し他の機器と相互作用させる前に必ず行わなければならない前提となるステップである。ＵＰｎＰではＩＰアドレス設定のために二つの手段を定義している。

一つ目はＤＨＣＰ（Dynamic Host Configuration Protocol）サーバからのＩＰアドレスの取得である（非特許文献２）。以下、ＤＨＣＰについて簡単にその概要を説明する。

ＵＰｎＰデバイスは、必須項目としてＤＨＣＰクライアント機能を持っており、ネットワークに参加すると、先ずＤＨＣＰサーバが存在するか否かを調べる（DHCP DISCOVER）。そこで、ネットワーク内にＤＨＣＰサーバが存在していればＤＨＣＰサーバからの返答を受信し（DHCP OFFER）、ＩＰアドレスの要求申請を行い（DHCP REQUEST）、ＤＨＣＰサーバが任意に生成した同一ネットワーク内でのユニークなＩＰアドレスをある一定期間取得することができる（DHCP ACK）。この一定期間とは、リース期間であり、継続してＩＰアドレスを使用したい場合は、リース期間の期限が過ぎる前に更新要求（DHCP REQUEST）をＤＨＣＰサーバに対して申請し、更新許可を受ける必要がある。また、デバイスがネットワーク離脱する場合など、もはやＩＰアドレスを必要としなくなった場合は、そのＩＰアドレスをＤＨＣＰサーバに返却しなければならない。

二つ目の手段はAutoIPを用いたＩＰアドレス設定である（非特許文献３）。以下、このAutoIPについて簡単にその概要を説明する。

AutoIPは、デバイス自身が任意にＩＰアドレスを生成し設定する機能のことである。使用できるＩＰアドレスの範囲は169.254.1.0乃至169.254.254.255までに制限されており、デバイスはネットワーク上にＤＨＣＰサーバが存在しないことを認識した場合、このアドレス範囲内で任意のIPアドレスを生成し、ＡＲＰ（Address Resolution Protocol）を使用して同一ネットワーク内で同じＩＰアドレスを使用しているデバイスがいないことを確認してから設定を行う。これにより、ＤＨＣＰサーバが存在しないネットワークでもアドレッシングを行うことができる。

ＵＰｎＰでは、ＡＲＰによるネットワークトラフィックの増大を防ぐ目的から、これら二つの手段のうち、ＤＨＣＰサーバ割り当ての方を優先している。それゆえ、AutoIPで設定しているＵＰｎＰデバイスは、定期的にＤＨＣＰサーバがネットワークに存在するかどうかチェック（DHCP DISCOVER）する必要がある。この周期はＵＰｎＰにおいては５分間隔が推奨されている。

ＵＰｎＰデバイスはアドレッシングステップによってＩＰアドレスを設定した後、ディスカバリを行う。ディスカバリは、ネットワーク上の他の全ての機器と自動的に相互認識しあうステップである。ディスカバリには大別して二つのメッセージが定義されており、一つはネットワークに参加したことを知らせるALIVEメッセージであり、もう一つはネットワークから離脱することを知らせるBYEBYEメッセージである。これらのメッセージをマルチキャスト送信することで、ネットワーク上の全ての機器に対して存在の有無を相互認識し合うことができる。また、この二つのメッセージはＧＥＮＡプロトコルで定義されるNotificationタイプを有しており、これによって告知の対象をルートデバイス、ＵＵＩＤ、デバイスタイプ、サービスタイプの４種類に設定することができる。
Universal Plug and Play Device Architecture Version 1.0, 08 Jun 2000 10:41 AM RFC 2131 Dynamic Host Configuration Protocol. IETF request for comments. Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network. IETF draft.

ＵＰｎＰデバイスは、上記アドレッシングステップにて述べたような方法でＩＰアドレスの設定を行うが、複数のＵＰｎＰデバイスがのAutoIPを使用しているネットワークにおいてＤＨＣＰサーバがネットワークに参加する場合を想定すると、以下に示すような問題点が発生する。図９に問題となる例のアドレッシングステップに関わるシーケンスを示し、これに従って説明する。

今、MediaServer、MediaRendererにてＵＰｎＰネットワークが構成されており、各デバイスはAutoIPによってＩＰアドレスを設定している状態にあるとする。なお、ＩＰアドレスはそれぞれMediaServerが169.254.1.1、MediaRendererが169.254.1.2とする。この初期状態においては、ＤＨＣＰサーバは存在していないものとする。

ステップ９０１にて、MediaServerは動画データをストリーミング送信し、ステップ９０２にてMediaRendererはこのストリーミングデータを受信している。ステップ９０３にて、MediaRendererは周期的なDHCP DISCOVERメッセージを送信し、ＤＨＣＰサーバをサーチする。ステップ９０３のタイミングでは、ＤＨＣＰサーバがネットワークに存在しないため、MediaRendrerはDHCP OFFERメッセージを受信しない（ステップ９０４）。次にステップ９０５にて、例えばユーザの手によってＤＨＣＰサーバがネットワークに参加する。このとき、ＤＨＣＰサーバはＩＰアドレス192.168.0.1を自身に割り当てているものとする。

次にステップ９０６にて、MediaServerは周期的なDHCP DISCOVERメッセージを送信し、ＤＨＣＰサーバをサーチする。このタイミングではＤＨＣＰサーバが存在する。ＤＨＣＰサーバは、このDHCP DISCOVERメッセージを受信し、ステップ９０７にて、提供できるＩＰアドレスを記したDHCP OFFERメッセージを送信する。ここで、提供できるＩＰアドレスを192.168.0.2とする。続いてステップ９０８にて、MediaServerはＤＨＣＰサーバがネットワーク内に存在することを認識し、ＩＰアドレス192.168.0.2の使用許可を要求するDHCP REQUESTメッセージを送信する。ステップ９０９にて、ＤＨＣＰサーバがDHCP ACKメッセージを送信することで、MediaServerに対してＩＰアドレス192.168.0.2の使用を許可する。これによりステップ９１０にて、MediaServerはAutoIPからＤＨＣＰサーバより割り当てられたＩＰアドレスに変更する。しかしながら、このとき、MediaServerとMediaRendererのネットワークアドレスは異なるものとなってしまい、ステップ９１１およびステップ９１２にて、MediaServerとMediaRendererの間のストリーミング転送が途切れてしまうといった問題が起こる。

本発明はこのような課題に鑑みてなされたものであり、AutoIP等によってネットワークアドレスが設定されている状況において、ＤＨＣＰサーバ等のアドレスサーバが当該ネットワークに参加した際に生じていた、他の機器とのデータ転送の中断の可能性を低減することを目的とする。

上記の目的を達成するための本発明による電子機器は以下の構成を備える。即ち、
ネットワークに接続可能な電子機器であって、
当該電子機器自身で設定したネットワークアドレスでネットワークに接続している状態において、該ネットワーク上のアドレスサーバを検出する検出手段と、
アドレスサーバが検出された場合に、当該電子機器が他の装置との間でデータ転送中であるか否かを判定する判定手段と、
前記判定手段によってデータ転送中であると判定された場合は、当該データ転送の終了を待って、前記アドレスサーバから取得されるネットワークアドレスへの変更を実行する変更手段とを備える。

また、上記目的を達成するための本発明の他の態様による電子機器の制御方法は、
ネットワークに接続可能な電子機器の制御方法であって、
当該電子機器自身で設定したネットワークアドレスでネットワークに接続している状態において、該ネットワーク上のアドレスサーバを検出する検出工程と、
アドレスサーバが検出された場合に、当該電子機器が他の装置との間でデータ転送中であるか否かを判定する判定工程と、
前記判定工程によってデータ転送中であると判定された場合は、当該データ転送の終了を待って、前記アドレスサーバから取得されるネットワークアドレスへの変更を実行する変更工程とを備える。

本発明によれば、AutoIP等によってネットワークアドレスが設定されている状況において、ＤＨＣＰサーバ等のアドレスサーバが当該ネットワークに参加した際に生じていた、他の機器とのデータ転送の中断の可能性が低減される。

以下、添付の図面を参照して本発明に好適な実施形態を説明する。

＜第１実施形態＞
図１はＵＰｎＰプロトコルによって構成されたネットワーク（ＵＰｎＰネットワーク）の構成を示す図である。本実施形態（他の実施形態も同様）では、このネットワークに接続可能な電子機器として、デジタルビデオカメラ（ＤＶＣＲ）及びデジタルテレビ（ＤＴＶ）を例にあげて説明するが、他の電子機器であってもかまわない。本実施形態のＤＶＣＲはＵＰｎＰのAudio Video Working Committee（以下、AV WC）によって標準化されているMediaServer、ＤＴＶは同じくAV WCによって標準化されているMediaRenderer、そしてアドレスサーバとしてのＤＨＣＰサーバはInternetGateway WCで標準化されているInternet Gateway Deviceであるとする。ＤＴＶはＵＰｎＰのコントロールポイント機能も持つ。本実施形態では、全てのデバイスはIEEE802.11b準拠の無線インターフェースにて接続しているものとする。しかしながら、IEEE802.11b以外の規格、例えばIEEE802.11a、IEEE802.11g、Ethernet（登録商標）、IEEE1394、UltraWideBandを用いてネットワークを構成する場合にも適用できることは言うまでもない。

なお、本実施形態では、本発明をＤＶＣＲに適用した場合を説明する。ただし、ＤＶＣＲ以外の装置（デジタルカメラ、携帯電話、モバイルコンピュータ等）でも実施することができる。

図１０は、本実施形態におけるＤＶＣＲの主要な構成要素を示すブロック図である。ＤＶＣＲは、装置全体の制御を司るＣＰＵ１１１をはじめ、以下の構成を備える。

１１２は制御プログラム、ＤＶＣＲ４のＵＵＩＤ、デバイスディスクリプション、サービスディスクリプション等を記憶したＲＯＭ、１１３はワークエリアとして使用されるＲＡＭ、１１４は録画ボタンや各種スイッチやボタン、更にはＵＰｎＰネットワークへの参加又はＵＰｎＰネットワークから離脱を切り換えるボタン（ネットワーク参加ボタン）等を有する操作部である。１１５はＵＰｎＰネットワークに接続するためのネットワークインターフェース、１１６は光学レンズ、イメージセンサ（ＣＣＤセンサ等）で構成されるカメラ部、１１７は圧縮符号化／復号処理を行うコーデック部、１１８は記録媒体（ディスク媒体、磁気テープ等）への画像データの記録／再生を行う記録部、１１９は液晶表示器等を有する表示部である。

上記構成において、ＤＶＣＲの電源をＯＮにし、ネットワーク参加ボタンをＯＮにすると、ＤＨＣＰサーバ１００に対してＩＰアドレスを要求し（DHCP REQUEST）、ＵＰｎＰネットワークへの参加が行われる。この後、ＵＰｎＰネットワーク上のコントロールポイント（本実施形態では、ＤＴＶ）からの指示に従い、記録媒体に記録された音声付き動画像ストリームが、ネットワーク上のMediaRenderer（本実施形態ではＤＴＶが兼用）に送信され、そこで再生されることになる。

次に、図２に従って、AutoIPを使用しているＤＶＣＲにおいて、ＤＨＣＰサーバがネットワークに参加した際に行われる処理について説明する。なお、各ＵＰｎＰデバイスは、AutoIP設定時は、DHCP DISCOVERを５分おきに送信し、周期的なサーチを行うものとする。

ステップＳ２０１にて、ＤＶＣＲは５分周期のサーチを行う時間になったら、ステップＳ２０２にてDHCP DISCOVERメッセージをブロードキャスト送信する。ステップＳ２０３において、ＤＨＣＰサーバからのDHCP OFFERメッセージを受信しなかった場合は、AutoIPの設定を持続し、再び５分が経過した時点でＤＨＣＰのサーチを行うという手順を繰り返す。

一方、ステップＳ２０３にて、DHCP OFFERメッセージを受信した場合は、ステップＳ２０４にて、ＤＶＣＲは自身のコネクション状態を調べる。ネットワーク内の他の機器に対してコネクションを張っていない、すなわち他の機器との間でデータの送信あるいは受信を行っていない場合は、ステップＳ２０５にて、DHCP OFFERメッセージに記述されているＩＰアドレスの使用許可申請を行うDHCP REQUESTメッセージを送信する。以降、通常のＤＨＣＰ準拠のアドレス割り当て処理が行われ、DHCP ACKの受信によりＤＨＣＰサーバから割り当てられたＩＰアドレスの設定が完了する（ステップＳ２０６）。

また、ステップＳ２０４にて、コネクション状態を調べた結果、ネットワーク内の他の機器に対してコネクションを張っている、すなわちデータの送信あるいは受信を行っていると判定された場合はステップＳ２０７へ進み、当該データの送信あるいは受信が終了するまで待つ。コネクションが閉じた、すなわちデータの送信あるいは受信が終了すると、処理はステップＳステップＳ２０７からステップＳ２０８に進み、再びDHCP DISCOVERメッセージを送信する。以降、ＤＨＣＰ準拠の処理、すなわちDHCP OFFERの受信、DHCP REQUESTの送信、DHCP ACKの受信を行ってＤＨＣＰサーバより割り当てられたＩＰアドレスの設定を行う（ステップＳ２０９）。

次に、AutoIPで構成されるネットワークにＤＨＣＰサーバが参加してきた場合において、図２の処理を行うＤＶＣＲを例にとり、その動作を図３に従って説明する。

初期状態において、ＤＶＣＲおよびＤＴＶはAutoIPによりＩＰアドレスを設定しており、それぞれＤＶＣＲは169.254.1.1、ＤＴＶは169.254.1.2である。また、本実施例において、AutoIP設定時にＤＨＣＰサーバをサーチするポーリング周期は５分とする。ただし、この設定時間は一例であり、この限りではない。このような初期状態において、図３の各ステップについて説明する。

ユーザはＤＴＶ上のコントロールポイントアプリケーションにおいて、ネットワーク内のＵＰｎＰ機器の中からＤＶＣＲをデータ送信元として選択する。続いてユーザはＤＶＣＲ内の映像データを選択し再生ボタンを押下する。これに伴いＤＴＶはRTSP SETUPコマンドをＤＶＣＲに送信し、ＤＴＶ−ＤＶＣＲ間にコネクションを張り、RTSP PLAYコマンドを送信してRTP/RTSPストリーミング転送を開始する。ＤＶＣＲはRTSP PLAYコマンドを受信すると指定された映像データをRTPで送信開始する。ＤＴＶはＤＶＣＲより送信される動画データを受信し、リアルタイムに画面に表示する（ステップ３０１、３０２）。

ステップ３０３にて、ＤＴＶはＤＨＣＰサーバをサーチする周期が訪れたため、DHCP DISCOVERをブロードキャスト送信する。ステップ３０４にて、ＤＨＣＰサーバがネットワーク内に存在していないため、ＤＴＶはDHCP OFFERを受信しない。これによりＤＴＶはAutoIPの設定を持続する。続いてステップ３０５にて、ＤＨＣＰサーバが例えばユーザ二よりマニュアルでネットワークに参加する。このときＤＨＣＰサーバはＩＰアドレス192.168.0.1を自身に割り当てているものとする。

ステップ３０６にて、ＤＶＣＲはＤＨＣＰサーバをサーチする周期が訪れたため、DHCP DISCOVERをブロードキャスト送信する。ステップ３０７にて、ＤＶＣＲはＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。このDHCP OFFERメッセージには提供できるＩＰアドレスが含まれており、本実施形態では192.168.0.2とする。ステップＳ３０８にて、ＤＶＣＲはＤＨＣＰサーバがネットワーク内に存在していることを確認したものの、現在ＤＴＶに対してデータ転送中であるため、DHCP REQUESTは行わず、AutoIPのＩＰアドレス設定を持続する。

この後、ユーザが映像データを鑑賞し終わると、コントロールポイントアプリケーションにて停止ボタンが押下されする。これに伴いＤＴＶはRTSP TEARDOWNコマンドをＤＶＣＲに対して送信し、それを受信したＤＶＣＲはデータ転送を終了しＤＴＶ間のコネクションを閉じる（ステップ３０９、３１０）。ステップ３１１にて、ＤＶＣＲはデータ送信を終了するとすぐにDHCP DISCOVERをブロードキャスト送信し、再びＤＨＣＰサーバをサーチする。ステップＳ３１２にて、ＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。ステップ３０７で述べたように、このDHCP OFFERメッセージには提供できるＩＰアドレスが含まれており、再び192.168.0.2とする。これは一例であり、しかも毎回同じとは限らない。ステップ３１３にて、ＤＶＣＲは、自身が他のどの機器ともコネクションを張っていないため、ＩＰアドレス192.168.0.2の使用許可を申請するDHCP REQUESTメッセージをＤＨＣＰサーバに送信する。ステップＳ３１４にて、ＤＨＣＰサーバからのDHCP ACKを受信し、ステップＳ３１５にて、AutoIPのＩＰアドレス（168.254.1.1）からＤＨＣＰサーバより割り当てられたＩＰアドレス（192.168.0.2）に変更する。

その後、ＤＴＶにもＤＨＣＰサーバをサーチする周期が訪れ、ステップ３１６にて、DHCP DISCOVERをブロードキャスト送信しＤＨＣＰサーバをサーチする。ステップ３１７にて、ＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。このDHCP OFFERメッセージに含まれる提供可能なＩＰアドレスを192.168.0.3とする。ステップ３１８にて、ＤＴＶはＩＰアドレス192.168.0.3の使用許可を申請するDHCP REQUESTメッセージをＤＨＣＰサーバに送信する。ステップ３１９にて、ＤＴＶはＤＨＣＰサーバからのDHCP ACKを受信し、ステップ３２０にて、AutoIPのＩＰアドレス（168.254.1.2）からＤＨＣＰサーバより割り当てられたＩＰアドレス（192.168.0.3）に変更する。なお、上記では、コネクションが張られた状態であるか否かを、RSTPのSETUPパケットの受信からRSTPのTEARDOWNパケットの受信までの間としたが、これは一例である。例えば、TCPのSYNメッセージの受信からTCPのFINメッセージの受信までをコネクションが張られた状態、即ちデータ転送状態とみなすようにしてもよい。

＜第２実施形態＞
第２実施形態では、ＤＨＣＰサーバがネットワークに参加したかどうかを調べる、すなわちDHCP DISCOVERをブロードキャスト送信するタイミングを第１実施形態におけるＤＶＣＲに新たに追加した場合の例について述べる。第２実施形態では、DHCP DISCOVERを行うタイミングとして、５分間の周期的なポーリングの他に、“データ転送中である場合であって転送が途中で途切れた時”、および“Internet Gateway Device（以下ＩＧＤ）からのALIVEメッセージを受信した時”を追加する。図４にＩＧＤからのALIVEメッセージを示す。ＵＰｎＰデバイスはALIVEメッセージをマルチキャストする際、NT（Notification Type）ヘッダにおいて、告知の対象を設定することができる。

図５に従って、AutoIPを使用しているＤＶＣＲが、ＤＨＣＰサーバがネットワークに参加したか否かの問い合わせと、ＤＨＣＰが参加したときに行う処理について説明する。第１実施形態で説明したように、各ＵＰｎＰデバイスは、AutoIP設定時は、DHCP DISCOVERを５分おきに送信して周期的なサーチを行う。ステップＳ５０１にて、ＤＶＣＲが他の機器とコネクションを張っている状態、すなわちデータ転送中の場合は、ステップＳ５０２に進む。ステップＳ５０２にて、データ転送が正常に行われているかどうかを判定するために、データ転送中に転送相手からの応答があるかどうかを確認する。本実施形態２においてはRTSP GetParameterコマンドを定期的に相手に送信し、その応答の有無によってデータ転送が正しく行われているかどうかの判断を行うことを例に取る。

ステップＳ５０２にて、RTSP GetParameterコマンドに対する応答が無い場合、すなわち転送が途切れ、コネクションが切れた場合は、ステップＳ５０５にてDHCP DISCOVERをブロードキャスト送信する。この動作は、ＤＨＣＰサーバの出現を転送相手が先に検出し、AutoIPからＤＨＣＰサーバによるＩＰアドレスに変更してしまったことによってコネクションが切れた場合を想定した処理である。なお、RTSP GetParameterコマンドに対する応答パケットの有無の判断は、コマンドを送信してから所定時間以内に応答パケットを受信したか否かにより行うが、この所定時間にＴＣＰの再送制御を含めてもよい。

ステップＳ５０１にて、ＤＶＣＲが他の機器とコネクションを張っていない状態、すなわちデータ転送中で無い場合と、ステップＳ５０２にてRTSP GetParameterコマンドに対する応答を受信した場合は、ステップＳ５０３に進む。ステップＳ５０３では、ＩＧＤからのALIVEメッセージを受信したかどうかによってDHCP DISCOVERをブロードキャスト送信する処理を行う。この動作は、ＤＨＣＰサーバ機能を持つＩＧＤがネットワークに参加し、最初のALIVEメッセージを送信してきたことを想定した処理である。ステップＳ５０３にてＩＧＤからのALIVEメッセージを受信しない場合でも、ステップＳ５０４にてＤＨＣＰサーバのサーチを行う５分周期のポーリング時間になったら、ステップＳ５０５にてDHCP DISCOVERをブロードキャスト送信する。以上のように、第２実施形態のＤＶＣＲでは、ステップＳ５０２、ステップＳ５０３、およびステップＳ５０４の３種類の条件によってＤＨＣＰサーバのサーチを実行する。

続いて、ステップＳ５０６において、ステップＳ５０５で発行したDHCP DISCOVERに対してＤＨＣＰサーバからDHCP OFFERを受信したか否かを判定する。DHCP OFFERを受信しなかった場合はそのままステップＳ５０１へ戻り、AutoIPの設定が持続されることになる。ステップＳ５０６にてＤＨＣＰサーバからのDHCP OFFERを受信した場合は、ステップＳ５０７に進み、ＤＶＣＲは自身のコネクション状態を調べる。ネットワーク内の他の機器に対してコネクションを張っていない、すなわちデータの送信あるいは受信を行っていない場合は、ステップＳ５０８にて、DHCP OFFERメッセージにより提案されたＩＰアドレスの使用許可申請を行うべくDHCP REQUESTメッセージを送信する。以降、通常のＤＨＣＰ準拠の処理を行い、DHCP ACKの受信によりＤＨＣＰサーバから割り当てられたＩＰアドレスの設定を行う（ステップＳ５０９）。

ステップＳ５０７において、ネットワーク内の他の機器に対してコネクションを張っている、すなわちデータの送信あるいは受信を行っていると判定された場合は、ステップＳ５１０に進み、データの送信あるいは受信が終了するのを待つ。ステップＳ５１０にて、コネクションが閉じた、すなわちデータの送信あるいは受信が終了したならば、ステップＳ５１１にて再びDHCP DISCOVERメッセージを送信する。以降、通常のＤＨＣＰ準拠の処理を行い、DHCP OFFERの受信、DHCP REQUESTの送信、DHCP ACKの受信を経てＤＨＣＰサーバより割り当てられたＩＰアドレスの設定を行う（ステップＳ５１２）。
次に、AutoIPで構成されるネットワークにＤＨＣＰサーバ機能をもつＩＧＤが参加してきた場合において、図５に示した処理を実行するＤＶＣＲを例にとり、その動作を図６に従って説明する。

初期状態において、ＤＶＣＲおよびＤＴＶはAutoIPによりＩＰアドレスを設定しており、それぞれＤＶＣＲは169.254.1.1、ＤＴＶは169.254.1.2である。また、本例において、AutoIP設定時にＤＨＣＰサーバをサーチするポーリング周期は５分とする。なお、この設定時間は一例であり、この限りではない。このような初期状態において、図６に示された各ステップに従い説明する。

ユーザはＤＴＶ上のコントロールポイントアプリケーションにおいて、ネットワーク内のＵＰｎＰ機器の中からＤＶＣＲをデータ送信元として選択する。続いてユーザはＤＶＣＲ内の映像データを選択し再生ボタンを押下する。これに伴いＤＴＶはRTSP SETUPコマンドをＤＶＣＲに送信し、ＤＴＶ−ＤＶＣＲ間にコネクションを張り、RTSP PLAYコマンドを送信してRTP/RTSPストリーミング転送を開始する。ＤＶＣＲはRTSP PLAYコマンドを受信すると指定された映像データをＲＴＰで送信開始する。ＤＴＶはＤＶＣＲより送信される動画データを受信し、リアルタイムに画面に表示する（ステップ６０１、６０２）。

ステップ６０３にて、ＤＴＶはＤＨＣＰサーバをサーチする周期が訪れたため、DHCP DISCOVERをブロードキャスト送信する。ステップ６０４にて、ＤＨＣＰサーバがネットワーク内に存在していないため、ＤＴＶはDHCP OFFERを受信しない。これによりＤＴＶはAutoIPの設定を持続することになる。続いてステップ６０５にて、ＤＨＣＰサーバ（ＩＧＤ）が例えばユーザによりネットワークに参加する。なお、このときＤＨＣＰサーバはＩＰアドレス192.168.0.1を自身に割り当てているものとする。

ステップ６０６にて、ＩＧＤはネットワークに参加するとすぐ、ALIVEメッセージをマルチキャスト送信する。このALIVEメッセージの中にはＮＴヘッダにＩＧＤであることを示す情報が含まれている。ステップ６０７にて、ＩＧＤからのALIVEメッセージを受信したＤＶＣＲはDHCP DISCOVERメッセージをブロードキャスト送信する（ステップＳ５０３、Ｓ５０５）。すると、ステップ６０８にて、ＤＶＣＲはＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。このDHCP OFFERメッセージには提供できるＩＰアドレスが含まれており、本例では192.168.0.2とする。ステップ６０９にて、ＤＶＣＲはＤＨＣＰサーバがネットワーク内に存在していることを確認したものの、現在ＤＴＶに対してデータ転送中であるため、DHCP REQUESTは行わず、AutoIPのＩＰアドレスを持続する（ステップＳ５０６、Ｓ５０７、Ｓ５１０）。

この後、ユーザによる映像データの鑑賞が終了し、コントロールポイントアプリケーションにて停止ボタンが押下されると、これに伴いＤＴＶはRTSP TEARDOWNコマンドをＤＶＣＲに対して送信し、それを受信したＤＶＣＲはデータ転送を終了しＤＴＶ間のコネクションを閉じる（ステップ６１０、６１１）。ステップ６１２にて、ＤＶＣＲはデータ送信を終了するとすぐにDHCP DISCOVERをブロードキャスト送信し、再びＤＨＣＰサーバをサーチする（ステップＳ５１１）。そして、ステップ６１３にて、ＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。ステップ６０８で述べたように、このDHCP OFFERメッセージには提供できるＩＰアドレスが含まれており、ここでは再び192.168.0.2が子弟さているとする。なお、これは一例であり、毎回同じとは限らない。ステップ６１４にて、ＤＶＣＲは、自身がどの機器ともコネクションを張っていないため、ＩＰアドレス192.168.0.2の使用許可を申請するDHCP REQUESTメッセージをＤＨＣＰサーバに送信する。ステップ６１５にて、ＤＨＣＰサーバからのDHCP ACKを受信し、ステップ６１６にて、AutoIPのＩＰアドレス（168.254.1.1）からＤＨＣＰサーバより割り当てられたＩＰアドレス（192.168.0.2）に変更する（ステップＳ５１１２）。

この後、ＤＴＶにもＤＨＣＰサーバをサーチする周期が訪れると、ステップ６１７にて、DHCP DISCOVERをブロードキャスト送信しＤＨＣＰサーバをサーチする。ステップ６１８にて、ＤＨＣＰサーバからのDHCP OFFERメッセージを受信する。このDHCP OFFERメッセージに含まれる提供可能なＩＰアドレスを192.168.0.3とする。ステップ６１９にて、ＤＴＶはＩＰアドレス192.168.0.3の使用許可を申請するDHCP REQUESTメッセージをＤＨＣＰサーバに送信する。ステップ６２０にて、ＤＴＶはＤＨＣＰサーバからのDHCP ACKを受信し、ステップ６２１にて、AutoIPのＩＰアドレス（168.254.1.2）からＤＨＣＰサーバより割り当てられたＩＰアドレス（192.168.0.3）に変更する。

＜第３実施形態＞
第３実施形態では、ＤＨＣＰサーバがネットワークに参加したかどうかを調べるタイミング、すなわちDHCP DISCOVERをブロードキャスト送信するタイミングを第１実施形態におけるＤＶＣＲに対して新たに追加した場合の、第２実施形態とは異なる例について述べる。第３実施形態では、DHCP DISCOVERを行うタイミングとして、５分毎の周期的なポーリングの他に、データ転送中である場合であって転送が途中で途切れた時、および BYEBYEメッセージを受信した時を追加する。BYEBYEメッセージは、本明細の背景技術において述べたものであり、図７にそのパケット例を示す。ＵＰｎＰデバイスはALIVEメッセージと同様、BYEBYEメッセージをマルチキャストする際にＮＴ（Notification Type）ヘッダにおいて、告知の対象を設定することができる。

図８のフローチャートを参照して、AutoIPを使用しているＤＶＣＲが、ＤＨＣＰサーバがネットワークに参加したか否かの問い合わせと、ＤＨＣＰが参加したときに行う処理について以下、説明する。

各ＵＰｎＰデバイスは、AutoIP設定時は、DHCP DISCOVERを５分おきに送信して周期的なサーチを行う。ステップＳ８０１にて、ＤＶＣＲが他の機器とコネクションを張っている状態、すなわちデータ転送中の場合は、ステップＳ８０２に進む。ステップＳ８０２にて、データ転送が正常に行われているかどうかを判定するために、データ転送中に転送相手からの応答があるかどうかを確認する。本例においては、RTSP GetParameterコマンドを定期的に相手に送信し、その応答の有無によってデータ転送が正しく行われているかどうかの判断を行う。

ステップＳ８０２にて、RTSP GetParameterコマンドに対する応答が無い場合、すなわち転送が途切れ、コネクションが切れた場合は、ステップＳ８０５に進み、DHCP DISCOVERをブロードキャスト送信する。この動作は、ＤＨＣＰサーバの出現を転送相手が先に検出し、AutoIPからＤＨＣＰサーバによる ＩＰアドレスに変更してしまったことによってコネクションが切れた場合を想定した処理である。

ステップＳ８０１にて、ＤＶＣＲが他の機器とコネクションを張っていない状態、すなわちデータ転送中で無い場合と、ステップＳ８０２にてRTSP GetParameterコマンドに対する応答を受信した場合は、ステップＳ８０３に進む。ステップＳ８０３では、ネットワーク内のデバイスからのBYEBYEメッセージを受信したかどうかによってDHCP DISCOVERをブロードキャスト送信する処理を行う。この動作は、自身以外のデバイスが先にＤＨＣＰサーバの出現を検出してＩＰアドレスを変更する際に、BYEBYEメッセージをマルチキャスト送信していることを想定した処理である。ステップＳ８０３にてBYEBYEメッセージを受信しない場合でも、ステップＳ８０４にてＤＨＣＰサーバのサーチを行う５分周期のポーリング時間になったら、ステップＳ８０５にてDHCP DISCOVERをブロードキャスト送信する。以上のように、ＤＶＣＲはステップＳ８０２、ステップＳ８０３、およびステップＳ８０４の３種類の条件によってＤＨＣＰサーバのサーチを行う。

続いて、ステップＳ５０６において、ステップＳ５０５で発行したDHCP DISCOVERに対してＤＨＣＰサーバからDHCP OFFERを受信したか否かを判定する。DHCP OFFERを受信しなかった場合はそのままステップＳ５０１へ戻り、AutoIPの設定が持続されることになる。一方、ステップＳ８０６にてＤＨＣＰサーバからのDHCP OFFERを受信した場合は、ステップＳ８０７に進み、ＤＶＣＲは自身のコネクション状態を調べる。ネットワーク内の他の機器に対してコネクションを張っていない、すなわちデータの送信あるいは受信を行っていない場合は、ステップＳ８０８にて、DHCP OFFERメッセージにより提案されたＩＰアドレスの使用許可申請を行うDHCP REQUESTメッセージを送信する。以降、通常のＤＨＣＰに準拠した処理を実行し、DHCP ACKの受信によりＤＨＣＰサーバから割り当てられたＩＰアドレスを自身に設定する（ステップＳ８０９）。

ステップＳ８０７にて、ネットワーク内の他の機器に対してコネクションを張っている、すなわちデータの送信あるいは受信を行っている場合は、ステップＳ８１０に進み、データの送信あるいは受信が終了するまで待つ。ステップＳ８１０にて、コネクションが閉じた、すなわちデータの送信あるいは受信が終了した場合は、ステップＳ８１１にて再びDHCP DISCOVERメッセージを送信する。以降、通常のＤＨＣＰに準拠した処理を行い、DHCP OFFERの受信、DHCP REQUESTの送信、DHCP ACKの受信を経て、ＤＨＣＰサーバより割り当てられたＩＰアドレスの設定を行う（ステップＳ８１２）。

＜変形例＞
なお、第１乃至第３実施形態では、ステップＳ２０７、ステップＳ５１０、ステップＳ８１０において、データ転送が終了するまでＩＰアドレスを変更しないとしたが、この限りではない。例えば、実際にデータが転送されていなくてもコネクションが張られている場合はAutoIPを持続させるようにしてもよい。あるいは所定のタイムアウト時間を設け、データ転送がされていてもこの所定のタイムアウト時間が経過した場合には当該コネクションを切ってDHCP DISCOVERを行うように構成してもよい。なお、この所定のタイムアウト時間としては、例えば３０秒、あるいはＤＨＣＰサーバのサーチのポーリングタイムアウト時間（本例では５分）、あるいはUPnP ALIVEメッセージを送信する周期と同じ時間（例えば３０分）といった所定のタイムアウトが過ぎた場合はコネクションを切ってDHCP DISCOVERを行うということも実施できる。なお、この場合、所定のタイムアウト時間を無限長とすれば、データ転送の完了を待ってDHCP DISVOVERを発行する上記各実施形態と同じ動作になる。また、ステップＳ２０７、ステップＳ５１０、ステップＳ８１０におけるデータ転送においても、第２、第３実施形態のステップＳ５０２、Ｓ８０２で説明したようなデータ転送中断の検出を行い、転送が中断された場合にアドレスサーバからのアドレスの取得を行うようにしてもよい（DHCP DISCOVERの発行）。

また、上記各実施形態では、データ転送の完了後にDHCP DISCOVERを発行して、ＤＨＣＰによるアドレスの取得をやり直している（ステップＳ２０８、Ｓ２０９、Ｓ５１１、Ｓ５１２、Ｓ８１１、Ｓ８１２）。しかしながら、一般にＤＨＣＰサーバには「DHCP OFFERからDHCP REQUESTを受信するまでの制限時間」が設定されており、その制限時間内であればDHCP OFFERに記述されたＩＰアドレスを利用するためのDHCP REQUESTを受け付けることができる。よって、DHCP OFFERを受信してからデータ転送の終了確認（Ｓ２０７、Ｓ５１０、Ｓ８１０）までの時間を計測し、その時間がＤＨＣＰサーバに設定されている上記制限時間の範囲内であった場合には、DHCP DISCOVERを発行せず、すでに受信されたDHCP OFFERに記述されたＩＰアドレスを利用すべくDHCP REQUESTを発行するようにしてもよい。もちろん、制限時間の範囲を超えた場合は、DHCP DISCOVERの発行を行う。

また、ＤＶＣＲ等に組み込まれたアプリケーションによっては、外部機器からのデータ転送の予約を保持する機能を設けたものがある。例えば、２台のＤＴＶがネットワーク上に存在し、一方のＤＴＶとの間でデータ転送を行っている間に他方のＤＴＶから発行されたデータ転送の依頼を予約として保持しておく。このような予約の機能を有する電子機器においては、ステップＳ２０７、Ｓ５１０、Ｓ８１０のデータ転送終了の判定において、現在実行中のデータ転送が終了しても、データ転送の予約が存在する場合には引き続き予約されたデータ転送を実行するようにしてもよい。すなわち、データ転送の予約があると判断された場合はデータ転送が継続するものとみなすようにしてもよい。

以上説明したように、各実施形態によれば、ネットワーク上のAutoIPによってＩＰが設定されたデバイスにおいて、当該ネットワークにＤＨＣＰサーバが参加したことを検出した際に、デバイス自身のコネクション状態を判定し、他の機器との間にコネクションが張られていればAutoIPのＩＰアドレスを保持し、当該コネクションが閉じるのを待ってＤＨＣＰサーバによるＩＰアドレスへ変更する。このため、ＤＨＣＰサーバの参加に連動して発生する可能性のあるデータ転送の中断を防ぐことができる。

また、第２実施形態によれば、定期的なＤＨＣＰサーバのサーチに加え、データ転送中であってデータ転送が途中で途切れた場合（第２実施形態ではRTSPのGetParameterパケットに対する応答パケットを受信できたか否かにより判断する）、およびＤＨＣＰサーバの加入の可能性を示すメッセージ（第２実施形態ではＩＧＤのALIVEメッセージ）を受信した場合に、ＤＨＣＰサーバに対してDHCP DISCOVERが行われる。また、第３実施形態では、ネットワーク上の他の電子機器のＩＰアドレスが変更された可能性（すなわちＤＨＣＰサーバが加入した可能性）を示すメッセージ（第３実施形態ではBYEBYEメッセージ）を受信した場合に、ＤＨＣＰサーバに対してDHCP DISCOVERが行われる。このような、第２、第３実施形態によれば、通常のＤＨＣＰサーバサーチのポーリング周期よりも早くＤＨＣＰサーバのネットワーク参加を検出することが可能であり、各機器におけるＤＨＣＰサーバ離脱検出の時間差によって生じる通信不能時間を縮小することが可能となる。

＜他の実施形態＞
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

実施形態によるＵＰｎＰネットワークを示す図である。 AutoIPを使用しているデバイスにおいて、ＤＨＣＰサーバのサーチ、及びＤＨＣＰサーバがネットワークに参加した際に行われる、第１実施形態による処理を説明するフローチャートである。 第１実施形態によるデジタルビデオカメラ（ＤＶＣＲ）のアドレス遷移を説明する遷移図である。 第２実施形態における、ＵＰｎＰのALIVEメッセージを示す図である。 AutoIPを使用しているデバイスにおいて、ＤＨＣＰサーバのサーチ、及びＤＨＣＰサーバがネットワークに参加した際に行われる、第２実施形態による処理を説明するフローチャートである。 第２実施形態によるデジタルビデオカメラ（ＤＶＣＲ）のアドレス遷移を説明する遷移図である。 第３実施形態における、ＵＰｎＰのBYEBYEメッセージを示す図である。 AutoIPを使用しているデバイスにおいて、ＤＨＣＰサーバのサーチ、及びＤＨＣＰサーバがネットワークに参加した際に行われる、第３実施形態による処理を説明するフローチャートである。 ＤＨＣＰサーバのネットワーク参入に伴う一般的なアドレスの遷移を説明する遷移図である。 実施形態におけるＤＶＣＲのブロック構成図である。

Claims (11)

1. ネットワークに接続可能な電子機器であって、
   当該電子機器自身で設定したネットワークアドレスでネットワークに接続している状態において、該ネットワーク上のアドレスサーバを検出する検出手段と、
   アドレスサーバが検出された場合に、当該電子機器が他の装置との間でデータ転送中であるか否かを判定する判定手段と、
   前記判定手段によってデータ転送中であると判定された場合は、当該データ転送の終了を待って、前記アドレスサーバから取得されるネットワークアドレスへの変更を実行する変更手段とを備えることを特徴とする電子機器。
2. 前記変更手段は、前記検出手段による前記アドレスサーバの検出から所定時間を経過した場合は、前記データ転送の完了を待たずに該アドレスサーバから取得されるネットワークアドレスへの変更を実行することを特徴とする請求項１に記載の電子機器。
3. 前記検出手段は、所定のコマンドをブロードキャストし、アドレスサーバよりの返答を受信することによりアドレスサーバを検出し、ここで、該返答にはネットワークアドレスの通知が含まれており、
   前記変更手段は、前記返答の受信から所定時間内に前記データ転送が完了した場合は該変動によって通知されたアドレスを用いてアドレスを変更し、該所定時間を超えて該データ転送が完了した場合は前記所定のコマンドのブロードキャストからやり直してアドレスを変更することを特徴とする請求項１に記載の電子機器。
4. 前記検出手段は、所定のコマンドを周期的にブロードキャストし、アドレスサーバよりの返答を受信することによりアドレスサーバを検出することを特徴とする請求項１に記載の電子機器。
5. 前記検出手段は、更に、アドレスサーバである可能性のある機器の加入を示すメッセージを受信した際に前記所定のコマンドをブロードキャストすることを特徴とする請求項４に記載の電子機器。
6. 前記検出手段は、更に、他の電子機器のアドレス変更の可能性を示すメッセージを受信した際に前記所定のコマンドをブロードキャストすることを特徴とする請求項４に記載の電子機器。
7. 前記検出手段は、更に、当該電子機器が実行していたデータの転送が途切れた際に、前記所定のコマンドをブロードキャストすることを特徴とする請求項４に記載の電子機器。
8. 他の機器との間のデータ転送の予約の有無を判断する判断手段を更に備え、
   前記変更手段は、前記判断手段によってデータ転送の予約があると判断された場合はデータ転送が継続するものとみなすことを特徴とする請求項１に記載の電子機器。
9. ネットワークに接続可能な電子機器の制御方法であって、
   当該電子機器自身で設定したネットワークアドレスでネットワークに接続している状態において、該ネットワーク上のアドレスサーバを検出する検出工程と、
   アドレスサーバが検出された場合に、当該電子機器が他の装置との間でデータ転送中であるか否かを判定する判定工程と、
   前記判定工程によってデータ転送中であると判定された場合は、当該データ転送の終了を待って、前記アドレスサーバから取得されるネットワークアドレスへの変更を実行する変更工程とを備えることを特徴とする電子機器の制御方法。
10. 請求項９に記載の電子機器の制御方法をコンピュータに実行させるための制御プログラムを格納した記憶媒体。
11. 請求項９に記載の電子機器の制御方法をコンピュータに実行させるための制御プログラム。

Images