(57)【要約】【課題】  ＤＨＣＰサーバが何らかの原因でネットワークから離脱した場合であっても、データストリームの送信が中断してしまうことを防ぐ。【解決手段】  デジタルビデオカムコーダ（ＤＶＣＲ）２００及びデジタルテレビ（ＤＴＶ）３００はＤＨＣＰサーバ１００（アクセスポイント）機能に基づいて、それぞれＩＰアドレスを取得する。ＤＶＣＲ２００がＤＴＶ３００に対して撮像画像である映像ストリームを送信中に、ＤＶＣＲ２００がＩＰアドレスの更新要求をＤＨＣＰサーバ１００に要求したとき、既にＤＨＣＰサーバ１００がＵＰｎＰネットワークから離脱していた場合には、従前のＩＰアドレスを保持したままストリームの送信を継続する。そして、一連の送信が完了したとき、ＡｕｔｏＩＰ機能を利用して、自身でＩＰアドレスを生成する。【選択図】  図３
2005217975.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続手段を備え、該ネットワーク接続手段を介して他の装置との間でデータストリームの送信、或いは受信を行う通信装置であって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント手段と、
該ＤＨＣＰクライアント手段により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成手段と、
前記ＤＨＣＰクライアント手段により、ＤＨＣＰサーバに対する更新要求が失敗したとき、通信相手装置との間でデータストリームの通信中であるか否かを判断する判断手段と、
該判断手段でデータストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断手段でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成手段により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御手段と
を備えることを特徴とする通信装置。
【請求項２】
前記ネットワークは、ＵＰｎＰネットワークであることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記ネットワーク接続手段は、ＩＥＥＥ８０２.１１ｘ（ｘはａ，ｂ，ｄ）、UltraWideBand、或いは、Bluetoothのいずれかの無線ネットワークインターフェースであることを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
更に、前記通信相手装置と通信中に、当該通信相手装置に接続確認メッセージを送信して、その応答があるか否かで接続確認の判定を行う第１の判定手段と、
前記ネットワーク上に存在する他の装置から、ネットワーク離脱を宣言するメッセージを受信したか否かを判定する第２の判定手段と、
前記第１の判定手段で前記通信相手装置との接続の確認ができないと判定した場合、又は、前記第２の判定手段でネットワーク離脱を宣言するメッセージを受信したと判定した場合、前記ＤＨＣＰサーバにＩＰアドレスの更新要求を行うＩＰアドレス更新要求手段と、
該ＩＰアドレス更新手段による更新に失敗した場合には、データストリームの通信完了を待って前記ＩＰアドレス生成手段により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する第２の制御手段と
を備えることを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
ネットワーク接続手段を備え、該ネットワーク接続手段を介して他の装置との間でデータストリームの送信、或いは受信を行う通信装置の制御方法であって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント工程と、
該ＤＨＣＰクライアント工程により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成工程と、
前記ＤＨＣＰクライアント工程により、ＤＨＣＰサーバに対する更新要求が失敗したとき、通信相手装置との間でデータストリームの通信中であるか否かを判断する判断工程と、
該判断工程でデータストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断工程でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成工程により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御工程と
を備えることを特徴とする通信装置の制御方法。
【請求項６】
ネットワーク接続手段を備え、該ネットワーク接続手段を介して他の装置との間でデータストリームの送信、或いは受信を行う為の通信装置用のコンピュータプログラムであって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント手段と、
該ＤＨＣＰクライアント手段により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成手段と、
前記ＤＨＣＰクライアント手段により、ＤＨＣＰサーバに対する更新要求が失敗したとき、通信相手装置との間でデータストリームの通信中であるか否かを判断する判断手段と、
該判断手段でデータストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断手段でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成手段により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御手段
として機能することを特徴とするコンピュータプログラム。
【請求項７】
請求項６に記載のコンピュータプログラムを格納することを特徴とするコンピュータ可読記憶媒体。
【請求項８】
撮像手段と、撮像した映像情報を所定の記憶媒体に記憶する記憶手段と、ネットワーク接続手段と、該ネットワーク接続手段で接続されたネットワーク上の制御装置からの指示に従い、前記記憶手段に記憶された映像情報を映像ストリームとして、前記ネットワーク上の再生装置に送信するストリーム送信手段とを備える撮像装置であって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント手段と、
該ＤＨＣＰクライアント手段により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成手段と、
前記ＤＨＣＰクライアント手段により、ＤＨＣＰサーバに対する更新要求が失敗したとき、前記再生装置に映像ストリームの通信中であるか否かを判断する判断手段と、
該判断手段で映像ストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断手段でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成手段により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御手段と
を備えることを特徴とする撮像装置。
【請求項９】
撮像手段と、撮像した映像情報を所定の記憶媒体に記憶する記憶手段と、ネットワーク接続手段と、該ネットワーク接続手段で接続されたネットワーク上の制御装置からの指示に従い、前記記憶手段に記憶された映像情報を映像ストリームとして、前記ネットワーク上の再生装置に送信するストリーム送信手段とを備える撮像装置の制御方法であって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント工程と、
該ＤＨＣＰクライアント工程により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成工程と、
前記ＤＨＣＰクライアント手段により、ＤＨＣＰサーバに対する更新要求が失敗したとき、前記再生装置に映像ストリームの通信中であるか否かを判断する判断工程と、
該判断工程で映像ストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断工程でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成工程により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御工程と
を備えることを特徴とする撮像装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰアドレスを利用してネットワーク通信する撮像装置等の通信装置におけるＩＰアドレス取得、更新技術に関するものである。
【背景技術】
【０００２】
近年、ネットワーク上の所定のサービスを提供するデバイスを探索するためのネットワーク技術が開発されている。このような技術の一つに米国マイクロソフト社が提唱するＵＰｎＰ（Universal Plug and Play）がある（非特許文献１）。ＵＰｎＰでは、「サービス」、「デバイス」及び「コントロールポイント」を規定している。サービスは所定のサービスを提供する論理的な単位であり、デバイスは１つ以上のサービスを有する論理的な単位であり、コントロールポイントは１つ以上のサービスを制御する論理的な単位である。
【０００３】
ＵＰｎＰはＩＰ，ＴＣＰ，ＵＤＰ，ＨＴＴＰといったインターネット標準技術によって構成されており、ネットワークに接続し、機器同士がお互いを検出し相互認識し合うまでの自動ステップと、実際に機器を制御するステップおよびイベントを発行するステップを規程している（特許文献１）を参照することとし、以下に、本発明が係わるＵＰｎＰのアドレッシングおよびディスカバリのステップについての説明を行う。
【０００４】
アドレッシングは、ネットワークアドレス、すなわちＩＰアドレスを取得するステップであり、ネットワークに参加し他の機器と相互作用させる前に必ず行わなければならない前提となるステップである。ＵＰｎＰではＩＰアドレス設定のために二つの手段を定義している。
【０００５】
一つ目はＤＨＣＰ（Dynamic Host Configuration Protocol）サーバからのＩＰアドレスの取得である（非特許文献２）。以下、ＤＨＣＰについて簡単にその概要を説明する。
【０００６】
ＵＰｎＰデバイスは、必須項目としてＤＨＣＰクライアント機能を持っており、ネットワークに参加すると、先ずＤＨＣＰサーバが存在するか否かを調べる（DHCP DISCOVER）。そこで、ネットワーク内にＤＨＣＰサーバが存在していればＤＨＣＰサーバからの返答を受信し（DHCP OFFER）、ＩＰアドレスの要求申請を行い（DHCP REQUEST）、ＤＨＣＰサーバが任意に生成した同一ネットワーク内でのユニークなＩＰアドレスをある一定期間取得することができる（DHCP ACK）。この一定期間とは、リース期間であり、継続してＩＰアドレスを使用したい場合は、リース期間の期限が過ぎる前に更新要求（DHCP REQUEST）をＤＨＣＰサーバに対して申請し、更新許可を受ける必要がある。また、デバイスがネットワーク離脱する場合など、もはやＩＰアドレスを必要としなくなった場合は、そのＩＰアドレスをＤＨＣＰサーバに返却しなければならない。
【０００７】
二つ目の手段はＡｕｔｏＩＰ技術を用いたＩＰアドレス設定である（非特許文献３）。以下、このＡｕｔｏＩＰについて簡単にその概要を説明する。
【０００８】
ＡｕｔｏＩＰは、デバイス自身が任意にＩＰアドレスを生成し設定する機能のことである。使用できるＩＰアドレスの範囲は169.254.1.0乃至169.254.254.255までに制限されており、デバイスはネットワーク上にＤＨＣＰサーバが存在しないことを認識した場合、このアドレス範囲内で任意のIPアドレスを生成し、ＡＲＰ（Address Resolution Protocol）を使用して同一ネットワーク内で同じＩＰアドレスを使用しているデバイスがいないことを確認してから設定を行う。これにより、ＤＨＣＰサーバが存在しないネットワークでもアドレッシングを行うことができる。
【０００９】
ＵＰｎＰでは、ＡＲＰによるネットワークトラフィックの増大を防ぐ目的から、これら二つの手段のうち、ＤＨＣＰサーバ割り当ての方を優先している。それゆえ、ＡｕｏｔｏＩＰで設定しているＵＰｎＰデバイスは、定期的にＤＨＣＰサーバがネットワークに存在するかどうかチェック（DHCP DISCOVER）する必要がある。この周期はＵＰｎＰにおいては５分間隔が推奨されている。
【００１０】
ＵＰｎＰデバイスはアドレッシングステップによってＩＰアドレスを設定した後、ディスカバリを行う。ディスカバリは、ネットワーク上の他の全ての機器と自動的に相互認識しあうステップである。ディスカバリには大別して二つのメッセージが定義されており、一つはネットワークに参加したことを知らせるＡＬＩＶＥメッセージであり、もう一つはネットワークから離脱することを知らせるＢＹＥＢＹＥメッセージである。これらのメッセージをマルチキャスト送信することで、ネットワーク上の全ての機器に対して存在の有無を相互認識し合うことができる。また、この二つのメッセージはＧＥＮＡプロトコルで定義される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.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ＵＰｎＰデバイスは、上記アドレッシングステップにて述べたような手段でＩＰアドレスの設定を行うが、複数のＵＰｎＰデバイスのＩＰアドレスがＤＨＣＰサーバによって管理されているネットワークにおいて、ＤＨＣＰサーバがネットワークから離脱する場合を想定すると、以下に示すような問題点が発生する。
【００１２】
図７は、この問題となる例のシーケンスを示している。
【００１３】
図示は、デジタルビデオカムコーダ（以下、ＤＶＣＲ）、ＤＨＣＰサーバ、デジタルテレビ（以下、ＤＴＶ）にてＵＰｎＰネットワークが構成されており、全ての機器はＤＨＣＰサーバより割り当てられたＩＰアドレスを使用している。なお、ＤＨＣＰサーバは、無線ＬＡＮのアクセスポイントで構成するものとするが、ＰＣ等でも良いし、接続形態は有線ネットワーク（例えばイーサネット（登録商標））でも構わない。
【００１４】
図７における各デバイスのＩＰアドレスであるが、ＤＨＣＰサーバは「192.168.0.1」（固定）、ＤＨＣＰクライアントであるＤＶＣＲのＩＰアドレスは「192.168.0.2」、ＤＴＶのＩＰアドレスは「192.168.0.3」としている。なお、いずれもサブネットマスクは例えば「255.255.255.0」が一般的である。
【００１５】
ここで、ＤＶＣＲは記録されてある動画データをＤＴＶに対してストリーミング転送している最中に、突然ＤＨＣＰサーバがネットワークから離脱した場合（故障、電源がＯＦＦ、もしくは無線通信のエリア外に移動した等）について考察する。
【００１６】
ここで、ＤＨＣＰサーバがネットワーク離脱直後、ＤＶＣＲがＩＰアドレス更新要求を行うと、当然、ＤＨＣＰサーバが存在しないので、レスポンスが返ってこない。すなわち、ＤＶＣＲはＤＨＣＰサーバが存在していないことを検出することになり、ＡｕｔｏＩＰに移行し、任意のＩＰアドレス、例えば「169.254.1.1」を設定することになる。しかしながら、このとき、ＡｕｔｏＩＰにて設定したネットワークアドレス（サブネットマスクは１６ビットで「255.255.0.0」と規定されている）は、それ以前のＤＨＣＰサーバから割り当てられたＩＰアドレスを使用していた際のネットワークアドレスと異なることになり、ＤＶＣＲからＤＴＶへのストリーミング転送が途切れてしまう。
【００１７】
本発明はかかる問題点に鑑みなされたものであり、突然ＤＨＣＰサーバがＵＰｎＰネットワークから離脱した場合に生じる、他の機器間でのデータ転送の中断の阻止、あるいは各機器のアドレス設定変更タイミングの差によって生じる他の機器とのデータ転送できない時間を極力縮小する技術を提供しようとするものである。
【課題を解決するための手段】
【００１８】
上記問題を解決するため、例えば本発明の通信装置は以下の構成を備える。すなわち、
ネットワーク接続手段を備え、該ネットワーク接続手段を介して他の装置との間でデータストリームの送信、或いは受信を行う通信装置であって、
ＩＰアドレスを前記ネットワーク上のＤＨＣＰサーバよりＩＰアドレスを取得すると共に、取得したＩＰアドレスのリース期限前にＩＰアドレスの更新要求を行うＤＨＣＰクライアント手段と、
該ＤＨＣＰクライアント手段により前記ＤＨＣＰサーバよりＩＰアドレスの取得が失敗したとき、ＩＰアドレスを自身で生成するＩＰアドレス生成手段と、
前記ＤＨＣＰクライアント手段により、ＤＨＣＰサーバに対する更新要求が失敗したとき、通信相手装置との間でデータストリームの通信中であるか否かを判断する判断手段と、
該判断手段でデータストリームの通信中であると判断した場合には、当該データストリームの通信が完了するまでは従前に利用していたＩＰアドレスを維持し、前記判断手段でデータストリームの通信中ではない、又は、データストリームの通信が完了した場合、前記ＩＰアドレス生成手段により自身のＩＰアドレスを生成し、ネットワークへの接続を維持する制御手段とを備える。
【発明の効果】
【００１９】
本発明によれば、ＤＨＣＰサーバが何らかの原因でネットワークから離脱した場合であっても、データストリームの送信が中断してしまうことを防ぐことが可能になる。さらにまた、ＤＨＣＰサーバのネットワーク離脱においても、ネットワーク接続不能状態の期間を短縮させることも可能にする。
【発明を実施するための最良の形態】
【００２０】
以下、添付図面に従って本発明に係る実施形態を詳細に説明する。
【００２１】
＜第１の実施形態＞
図１は、ＵＰｎＰネットワークの構成の一例を示す図である。デジタルビデオカムコーダ（以下、ＤＶＣＲ）２００は、Audio Video Working Committee（ＡＶ ＷＣ）によって定義されているMediaServerとして機能するデバイスである。デジタルテレビ（以下、ＤＴＶ）３００は同じくＡＶ ＷＣによって定義されているMediaRendererとして機能するデバイス、そしてＤＨＣＰサーバ１００はInternetGateway WCで定義されているInternetGatewayDeviceである。また、ＤＴＶ３００はＵＰｎＰのコントロールポイントとしての機能も持つ。全てのデバイスはＩＥＥＥ８０２．ｂ準拠の無線インターフェースにて接続されている。なお、本実施形態におけるＤＨＣＰサーバ１００は、ＩＥＥＥ８０２．ｂ準拠のアクセスポイントで実現しているものとする。また、ＤＶＣＲ２００、ＤＴＶ３００はＤＨＣＰクライアント機能、ＡｕｔｏＩＰ機能を合わせ持つことになる。
【００２２】
本実施形態では、本発明をＤＶＣＲ２００に適用した場合を説明する。ただし、ＤＶＣＲ２００以外の装置（デジタルカメラ、携帯電話、モバイルコンピュータ等）でも実施することができる。
【００２３】
図８は、本実施形態におけるＤＶＣＲ２００の主要な構成要素を示すブロック図である。ＤＶＣＲ２００は、装置全体の制御を司るＣＰＵ１１１をはじめ、以下の構成を備える。
【００２４】
１１２は制御プログラム、ＤＶＣＲ４のＵＵＩＤ、デバイスディスクリプション、サービスディスクリプション等を記憶したＲＯＭ、１１３はワークエリアとして使用されるＲＡＭ、１１４は録画ボタンや各種スイッチやボタン、更にはＵＰｎＰネットワークへの参加又はＵＰｎＰネットワークから離脱を切り換えるボタン（ネットワーク参加ボタン）等を有する操作部である。１１５はＵＰｎＰネットワークに接続するためのネットワークインターフェース、１１６は光学レンズ、イメージセンサ（ＣＣＤセンサ等）で構成されるカメラ部、１１７は圧縮符号化／復号処理を行うコーデック部、１１８は記録媒体（ディスク媒体、磁気テープ等）への画像データの記録／再生を行う記録部、１１９は液晶表示器等を有する表示部である。
【００２５】
上記構成において、ＤＶＣＲ２００の電源をＯＮにし、ネットワーク参加ボタンをＯＮにすると、ＤＨＣＰサーバ１００に対してＩＰアドレスを要求し（DHCP REQUEST）、ＵＰｎＰネットワークへの参加が行われる。この後、ＵＰｎＰネットワーク上のコントロールポイント（本実施形態では、ＤＴＶ３００）からの指示に従い、記録媒体に記録された音声付き動画像ストリームを、ネットワーク上のMediaRenderer（本実施形態ではＤＴＶ３００が兼用）に送信され、そこで再生されることになる。
【００２６】
さて、ＤＶＣＲ２００が、上記のようにしてＤＨＣＰサーバ１００よりＩＰアドレスを取得してＵＰｎＰネットワークに参加してデータを送信中、何らかの原因でＤＨＣＰサーバ１００がネットワークから離脱した場合（ＤＨＣＰサーバ１００の通信可能エリアが、ＤＶＣＲ２００等の通信可エリア外になったり、その電源がＯＦＦになった場合等）の処理を図２のフローチャートに従って説明する。なお、図２に係る処理はデータ送信処理とは別タスクとして処理しているものである。
【００２７】
ＤＶＣＲ２００はＤＨＣＰサーバ１００より割り当てられたＩＰアドレスのリース期間が終了する前に、定期的にＤＨＣＰサーバ１００に対してリース更新要求（DHCP REQUEST）を行う（ステップＳ２０１、Ｓ２０２）。
【００２８】
リース更新要求（DHCP REQUEST）を発行した後、ステップＳ２０３にて、所定時間内にＤＨＣＰサーバ１００からの承認メッセージ（DHCP ACK）を受信した場合は、リース期間を更新する。また、ステップＳ２０３にて所定時間内にＤＨＣＰサーバ１００からの承認メッセージ（DHCP ACK）を受信しなかった場合は、ＤＶＣＲ２００は自身のコネクション状態を調べる（ステップＳ２０４）。ネットワーク内の他の機器に対してデータの送信あるいは受信を行っている場合は、ＤＨＣＰサーバ１００から割り当てられたＩＰアドレスを維持する。ネットワーク内の他のどの機器に対してもデータの送信あるいは受信を行っていない場合は、ＤＨＣＰサーバより割り当てられたＩＰアドレスから、ＡｕｔｏＩＰにより生成した任意のＩＰアドレスに変更する（ステップＳ２０５）。
【００２９】
すなわち、ＤＶＣＲ２００は、データ送受信を行っていてる最中（受信して記録する場合もある）に、ＩＰアドレスのリース期限になって、そのリース更新要求を送信しても、ＤＨＣＰサーバ１００から認証メッセージを受信できないときには、直ちにＡｕｔｏＩＰに移行せず、その一連の送受信が完了するのを待ってＡｕｔｏＵＰに移行する。
【００３０】
次に、上記の処理を行うＤＶＣＲ２００において、以下、ＤＶＣＲがデータ転送中にＤＨＣＰサーバ１００がネットワークから離脱した場合のシーケンスを図３を参照して説明する。
【００３１】
初期状態において、全てのデバイスはＤＨＣＰサーバ１００より割り当てられたＩＰアドレスを設定しており、それぞれのＩＰアドレスは、ＤＶＣＲ２００は「192.168.0.2/24」、ＤＴＶは「192.168.0.3/24」、ＤＨＣＰサーバは「192.168.0.1/24」である（「/24」は、サブネットマスクの先頭から２４ビットが「１」であること、すなわち、サブネットマスクが「255.255.255.0」であることを示す）。また、本実施形態のＤＨＣＰサーバにおけるＩＰアドレスのリース期間はどの機器に対しても３分間とし、各デバイスは２分間おきにＤＨＣＰサーバに対してリース更新要求をするものとする。ただし、これらの時間は一例であり、これによって本願発明が限定されるものではない。
【００３２】
このような初期状態において、ユーザはＤＴＶ３００上のコントロールポイントアプリケーションにおいて、ネットワーク内のＵＰｎＰデバイスの中（複数存在し得る）からＤＶＣＲ２００をデータ送信元として選択する。その後ユーザはＤＶＣＲ２００内の映像データを選択し再生ボタンを押下する。これに伴いＤＴＶ３００はRTSP SETUPコマンドをＤＶＣＲ２００に送信し、ＤＴＶ３００−ＤＶＣＲ２００間にコネクションを張り、RTSP PLAYコマンドにてRTP/RTSPストリーミング転送が開始される（タイミングＴ１）。ＤＶＣＲ２００はRTSP PLAYコマンドを受信すると指定された映像データをＲＴＰプロトコルで、指定されたデバイス（ここではＤＴＶ３００）へ送信開始する。ＤＴＶ３００はＤＶＣＲ２００より送信される動画データを受信し、リアルタイムに画面に表示する。
【００３３】
この後、ＤＴＶ３００はＤＨＣＰサーバによるＩＰアドレスのリース期間が終了直前となったため、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行う。ＤＨＣＰサーバ１００はこのリース更新要求を受信し、リース期間を更新する（DHCP ACK）。これを示すのが図示のタイミングＴ２である。
【００３４】
図示では、この後、タイミングＴ３にて、ＤＨＣＰサーバ１００がネットワークより離脱した場合を示している。
【００３５】
この後、ＤＶＣＲ２００はリース期間が終了直前となり、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行うが、既にＤＨＣＰサーバ１００はネットワークに存在しないため、ＤＶＣＲ２００はＤＨＣＰサーバ１００からの承認を受信できない（タイミングＴ４）。そのためＤＶＣＲ２００は、次の処理として、ＤＶＣＲ自身のコネクション状態を確認する。ＤＶＣＲ２００はＤＴＶ３００に対してコネクションを張り、動画データをストリーミング転送しているため、現状のＤＨＣＰサーバ１００から割り当てられたＩＰアドレス「192.168.0.2/24」の設定を保持（維持）し続ける。
【００３６】
この後、ユーザは映像データを鑑賞し終わる（ユーザがコントロールポイントアプリケーションにて停止ボタンを押下する）と、ＤＴＶ３００はRTSP TEARDOWNコマンドをＤＶＣＲ２００に対して送信する。ＤＶＣＲ２００は、これを受信すると、データ転送を終了しＤＴＶ間のコネクションを閉じる。コネクションを閉じると、ＤＶＣＲ２００はＡｕｔｏＩＰにて同一ネットワーク内にて一意で任意のＩＰアドレスを生成し、ＤＨＣＰサーバより割り当てられたＩＰアドレスにからＡｕｔｏＩＰに移行し、自身で生成したＩＰアドレス、例えば「169.254.1.1/16」に変更する（タイミングＴ５）。
【００３７】
この後、リース期間が終了直前になったＤＴＶ３００がリース更新要求（DHCP REQUEST）を行うが、ＤＨＣＰサーバからの承認が返ってこない。このとき、ＤＴＶ３００はデータ受信中ではないため、ＡｕｔｏＩＰに移行し、ネットワーク内で一意で任意のＩＰアドレス、例えば、「169.254.1.2」を設定する（タイミングＴ６）。ＤＶＣＲ２００がＡｕｔｏＩＰに移行し、ＤＴＶ３００がＡｕｔｏＩＰへ移行する直前までの間では、お互いに通信不可の状態になるが、互いにＡｕｔｏＩＰへ移行した後は、ネットワークアドレスが同じになるので、再び通信が行えるようになる。
【００３８】
以上は、ＤＶＣＲ２００がＤＴＶ３００よりも早くＤＨＣＰによるＩＰアドレスのリース期限が早くなる例であったが、逆の場合も同様である。すなわち、ＤＴＶ３００がストリームをＤＶＣＲ３００から受信中に、ＩＰアドレスのリース期間間際になり、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行ったものの、ＤＨＣＰ１００から認証が返ってこない場合には、一連の再生が終了するのを待ってから（リース期間を越えたとしても）、ＡｕｔｏＩＰへ移行する。
【００３９】
以上説明したように本実施形態によれば、ＵＰｎＰネットワークに接続可能なデバイスにおいて、ＩＰアドレスの更新要求をＤＨＣＰサーバに対して発行し、ＤＨＣＰサーバから何ら回答がないとき、その時点で他のデバイスとの通信が既に確立している場合には、従前のＤＨＣＰサーバから割り当てられたＩＰアドレスを継続して使い続けることで、通信確立しているデバイス間の通信が途絶えるという問題がなくなる。
【００４０】
＜第２の実施形態＞
第２の実施形態では、ＤＨＣＰサーバ１００がネットワークから離脱したかどうかを調べるタイミングを改善する例を説明する。説明を簡単なものとするため、第２の実施形態におけるネットワーク構成は図１と同じであり、ＤＶＣＲ２００に適用した場合を説明する。
【００４１】
第２の実施形態におけるＤＶＣＲ２００は、ＤＨＣＰサーバ１００よりＩＰアドレスを割り当てられた状態から、ＤＨＣＰサーバ１００がＵＰｎＰネットワーク離脱後にＡｕｔｏＩＰ設定に切り替えるまでにおいて、図４のフローチャートに従って処理する。
【００４２】
先ず、ＤＶＣＲ２００はネットワーク上の他の機器に対してデータ転送を行っているかどうかを判断する（ステップＳ４０１）。本実施形態においては、ＲＴＰ／ＲＴＳＰ転送を行っているかどうかを判断することになる。そして、転送中であると判断した場合には、ステップＳ４０２にて、接続相手（本実施形態ではＤＴＶ３００）に対してＲＴＳＰのGET PARAMETERコマンドを使用して定期的に接続の確認を行う（ステップＳ４０２）。このリクエストに対して接続相手からの確認レスポンスを受信できなかった場合は、接続相手がアドレッシングを行ったと推測し、ＤＨＣＰサーバに対してリース更新要求を行う（ステップＳ４０５）。
【００４３】
ＤＶＣＲ２００は、データ転送を行っていない場合、あるいはデータ転送中において接続相手からの接続確認レスポンスを受信している場合においても、ネットワーク上の他の機器からのBYEBYEメッセージ（ＵＰｎＰネットワーク離脱することを宣言するメッセージ）を受信したと判断した場合は（ステップＳ４０３）、ＤＨＣＰサーバ１００に対してリース更新要求を行う（ステップＳ４０５）。
【００４４】
また、ＤＶＣＲ２００はステップＳ４０３においてBYEBYEメッセージを受信していない場合でも、ＤＨＣＰサーバより割り当てられたリース期間が終了したと判断した場合（ステップＳ４０４）には、ＤＨＣＰサーバ１００に対してリース更新要求（DHCP REQUEST）を行う（ステップＳ４０５）。
【００４５】
さて、処理がステップＳ４０５に進み、リース更新要求をＤＨＣＰサーバ１００に対して行って、ＤＨＣＰサーバ１００からのDHCP ACKを一定のタイムアウト時間内に受信した場合は、リース期間を更新する。ここでは上記タイムアウト時間を２秒とするが、この限りではない。また、ステップＳ４０５において、ＤＨＣＰサーバ１００からのDHCP ACKを一定のタイムアウト時間内に受信しなかった場合は、ＤＶＣＲ２００は現在データ転送中かどうかを調べ（ステップＳ４０７）、データ転送中であれば、データ転送が終了するまでＤＨＣＰサーバ１００から従前に割り当てられたＩＰアドレス設定を維持し、データ転送を継続する。そして、ステップＳ４０７にて、その転送が終了したと判断した場合には、ステップＳ４０８に進んでＡｕｔｏＩＰに移行し、ＩＰアドレス及びサブネットマスクを変更する（ステップＳ４０８）。
【００４６】
次に、上記の処理を行うＤＶＣＲ２００がデータ転送中にＤＨＣＰサーバ１００がＵＰｎネットワークから離脱した場合のシーケンスの一例を図５に従って説明する。
【００４７】
初期状態において、全てのデバイス（ＤＶＣＲ２００、ＤＴＶ３００）はＤＨＣＰサーバ１００より割り当てられたＩＰアドレスを設定しており、ＤＶＣＲ２００のＩＰアドレス／サブネットマスクは「192.168.0.2/24」、ＤＴＶ３００のそれは「192.168.0.3/24」、ＤＨＣＰサーバ１００は「192.168.0.1/24」（固定）である。また、本実施形態のＤＨＣＰサーバ１００によるＩＰアドレスのリース期間はどの機器に対しても３分間とし、各デバイスは２分間おきにＤＨＣＰサーバ１００に対してリース更新要求をするものとする。なお、この設定時間は一例であり、この限りではない。
【００４８】
このような初期状態において、ユーザはＤＴＶ３００上のコントロールポイントアプリケーションにおいて、操作部（操作ボタンが設けられたリモコン等）及びＤＴＶ３００の表示メニューに従い、ネットワーク内のＵＰｎＰ機器の中からＤＶＣＲ２００をデータ送信元として選択する。その後ユーザはＤＶＣＲ２００内の映像データを選択し、再生要求を示すボタンを押下する。これに伴いＤＴＶ３００はRTSP SETUPコマンドをＤＶＣＲ２００に送信し、ＤＴＶ-ＤＶＣＲ間にコネクションを張り、ＤＴＶ３００からＤＶＣＲ２００へRTSP PLAYコマンドを送信することで、ＤＶＣＲ２００からＤＴＶ２００へ向けて選択された映像データのRTP/RTSPストリーミング転送を開始する。すなわち、ＤＶＣＲ２００はRTSP PLAYコマンドを受信すると指定された映像データをRTPで送信開始する。ＤＴＶ３００はＤＶＣＲより送信される動画データを受信し、リアルタイムに画面に表示を開始することになる（タイミングＴ１１）。なお、ここで、図５に示すシーケンスにおいてはＤＶＣＲ２００がストリーミング転送中に接続の確認を行うために送信するGET PARAMETERコマンドに対して、ＤＴＶ３００は常に確認レスポンスを返信しているものとする。
【００４９】
この後、ＤＴＶ３００はＤＨＣＰリース期間が終了直前（前回のリースされてから２分経過した場合に相当すう）となったため、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行う。ＤＨＣＰサーバ１００はこの更新要求を受信し、新たなリース期間を設け、更新を承認する（DHCP ACK）（タイミングＴ１２）。
【００５０】
この後、ＤＨＣＰサーバ１００がネットワークより離脱する。このとき、ＵＰｎＰのInternetGatewayDeviceであるＤＨＣＰサーバ１００はネットワークから離脱する直前にBYEBYEメッセージをマルチキャストする（タイミングＴ１３）。
【００５１】
先に説明したように、ＤＶＣＲ２００はこのBYEBYEメッセージを受信すると、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行う。このとき既にＤＨＣＰサーバ１００はＵＰｎＰネットワーク上には存在しないため、ＤＶＣＲ２００はＤＨＣＰサーバ１００からの承認を受信できない。そのためＤＶＣＲ２００は、自身のコネクション状態を確認する。ＤＶＣＲ２００はＤＴＶ３００に対してRTSPのSETUPコマンドにてコネクションを張り、動画データをストリーミング転送している途中であるため、ＤＨＣＰサーバ１００から従前に割り当てられたＩＰアドレス「192.168.0.2/24」の設定を保持する（タイミングＴ１４）。
【００５２】
この後、ユーザは映像データを鑑賞し終わった後、コントロールポイントアプリケーションにて停止ボタンを押下する。これに伴いＤＴＶ３００はRTSP TEARDOWNコマンドをＤＶＣＲ２００に対して送信する。ＤＶＣＲ２００がこれを受信するとデータ転送を終了し、ＤＶＣＲ−ＤＴＶ間のコネクションを閉じる。コネクションを閉じると、ＤＶＣＲはAutoIP機能にて同一ネットワーク内にて一意で任意のＩＰアドレスを生成し、ＤＨＣＰサーバより割り当てられたＩＰアドレスにからAutoIPで生成したＩＰアドレス「169.254.1.1/16」に変更する（タイミングＴ１５）。
【００５３】
この後、リース期間が終了直前になったＤＴＶ３００がリース更新要求（DHCP REQUEST）を行うが、ＤＨＣＰサーバ１００からの承認が返ってこない（タイミングＴ１６）。従って、ＤＴＶ３００はAutoIP機能により、ネットワーク内で一意で任意のＩＰアドレス、例えば「169.254.1.2/16」を設定する（タイミングＴ１７）。
【００５４】
以上の説明から理解できるように、タイミングＴ１５〜Ｔ１７までの間では、ＤＴＶＲ２００とＤＴＶ３００は再びコネクションを張ることはできない。しかしながら、ＤＴＶ３００が、ＤＶＣＲ２００と同様の機能を持つようにすると、タイミングＴ１５にてＤＴＶ３００もＡｕｔｏＩＰに移行することになるわけであるから、このようなコネクション不能期間は実質的に無くすことが可能になるのは明らかであろう。
【００５５】
＜第２の実施形態の変形例＞
ここでは、上記第２の実施形態におけるBYEBYEメッセージの受信について制限を付加した例について述べる。
【００５６】
ＵＰｎＰネットワーク上におけるデバイスが発信するBYEBYEメッセージの記述例を図６に示す。ＵＰｎＰデバイスはBYEBYEメッセージをマルチキャストする際、ＮＴ（Notification Type）ヘッダにおいて、告知の対象を設定することができる。
【００５７】
従って、このＮＴヘッダにおいて、デバイスタイプが「InternetGatewayDevice」と記述されている場合にはＤＨＣＰサーバ１００からのBYEBYEメッセージであることがわかるので、この場合にのみＤＨＣＰサーバに対してのリース更新要求を行えば良い。すなわち、図４のステップＳ４０３では、BYEBYEメッセージを受信した場合に、そのＮＴヘッダを調べ、それが「InternetGatewayDevice」であるかどうかを判断するようにすればよい。これ以外は、上記第２の実施形態と同様であるので、説明は省略する。
【００５８】
以上説明したように、第２の実施形態、並びに、その変形例によれば、第１の実施形態の作用効果に加えて、ＵＰｎＰネットワーク上のＤＨＣＰサーバが、そのＵＰｎＰネットワークから離脱した際のＵＰｎＰデバイス間の通信不能期間を短縮させることが可能となる。
【００５９】
なお、本実施形態では、ＵＰｎＰネットワーク上にＤＨＣＰサーバ１００、ＤＶＣＲ２００、ＤＴＶ３００の３つのデバイスが存在する例を説明したが、ＤＨＣＰサーバは１つであるものの、それ以外のデバイスの数は、取り得るＩＰアドレスの範囲内であれば制限はない。
【００６０】
また、本実施形態では、ＵＰｎＰネットワークをＩＥＥＥ８０２．１１ｂに準拠したネットワークを前提にして説明したが、ＩＥＥＥ８０２．１１ａ、ｇでも構わないし、UltraWideBand、或いは、Bluetoothでもって構築しても構わない。更に、無線に限らず、有線（例えば、イーサネット（登録商標）、ＵＳＢ、ＩＥＥＥ１３９４等）でも構わない。
【００６１】
また、本実施形態では、ＵＰｎＰネットワーク上におけるコントロールポイントとしてＤＴＶ３００を例にしたが、ある程度の表示手段（表示器）及び操作部を有するデバイスであればコントロールポイントとして機能できるので、ＰＣ等であっても構わない。特に、データ発信源としては、ＤＶＣＲ２００を例にしたが、ＰＣ等でも、それ専用のアプリケーションを実行すれば発信源として機能することができるので、本願発明は、コンピュータプログラムをもその範疇とするのは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ可読記憶媒体に格納されており、それをコンピュータにセットし、システムにコピー或いはインストールすることで実行可能となるわけであるから、当然、そのようなコンピュータ可読記憶媒体も本願発明の範疇に入る。
【図面の簡単な説明】
【００６２】
【図１】第１、第２の実施形態におけるＵＰｎＰネットワークの構成を示す図である。
【図２】第１の実施形態におけるアドレス変移時のＤＶＣＲの処理手順を示すフローチャートである。
【図３】第１の実施形態におけるＵＰｎＰデバイスのアドレス変移のシーケンスフローを示す図である。
【図４】第２の実施形態におけるアドレス変移時のＤＶＣＲの処理手順を示すフローチャートである。
【図５】第２の実施形態におけるＵＰｎＰデバイスのアドレス変移のシーケンスフローを示す図である。
【図６】ＵＰｎＰデバイスが発信するBYEBYEメッセージの記述内容の一例を示す図である。
【図７】ＵＰｎＰネットワークからＤＨＣＰサーバが離脱した際のこれまでのシーケンスを示す図である。
【図８】実施形態におけるＤＶＣＲのブロック構成図である。
【図１】
2005217975.tif 000003
【図２】
2005217975.tif 000004
【図３】
2005217975.tif 000005
【図４】
2005217975.tif 000006
【図５】
2005217975.tif 000007
【図６】
2005217975.tif 000008
【図７】
2005217975.tif 000009
【図８】
2005217975.tif 000010