JP4298530B2

JP4298530B2 - 通信装置

Info

Publication number: JP4298530B2
Application number: JP2004024730A
Authority: JP
Inventors: 俊司藤田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-01-30
Filing date: 2004-01-30
Publication date: 2009-07-22
Anticipated expiration: 2024-01-30
Also published as: CN1649354B; CN1649354A; US20110161516A1; US7925772B2; US20050198344A1; US8396979B2; JP2005217975A

Description

本発明は、ＩＰアドレスを用いて通信を行う撮像装置等の通信装置に関する。

近年、ネットワーク上の所定のサービスを提供するデバイスを探索するためのネットワーク技術が開発されている。このような技術の一つに米国マイクロソフト社が提唱するＵＰｎＰ（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」と規定されている）は、それ以前のＤＨＣＰサーバから割り当てられたＩＰアドレスを使用していた際のネットワークアドレスと異なることになり、ＤＶＣＲからＤＴＶへのストリーミング転送が途切れてしまう。

本発明はかかる問題点に鑑みなされたものであり、ＤＨＣＰサーバが何らかの原因でＵＰｎＰネットワークから離脱した場合であっても、画像データの送信が中断されないようにすることを目的とする。

本発明に係る通信装置は、ＵＰｎＰ（Universal Plugand Play）ネットワークに接続されたＤＨＣＰサーバから第１のＩＰアドレスを取得する通信装置であって、前記第１のＩＰアドレスのリース期間中にＢＹＥＢＹＥメッセージが受信されたか否かを判定する判定手段と、前記第１のＩＰアドレスのリース期間中に前記ＢＹＥＢＹＥメッセージが受信されたと判定された場合に、前記第１のＩＰアドレスのリース期間の更新を要求する更新要求を前記ＤＨＣＰサーバに送信する更新要求送信手段と、第２のＩＰアドレスを生成するＩＰアドレス生成手段とを有し、前記更新要求が前記ＤＨＣＰサーバによって承認されなかったと判定された場合であり、かつ、画像データの送信が行われていないと判定された場合は、前記通信装置のＩＰアドレスを前記第１のＩＰアドレスから前記第２のＩＰアドレスに変更することを特徴とする。

本発明によれば、ＤＨＣＰサーバが何らかの原因でＵＰｎＰネットワークから離脱した場合であっても、画像データの送信が中断されないようにすることができる。

以下、添付図面に従って本発明に係る実施形態を詳細に説明する。

＜第１の実施形態＞
図１は、ＵＰｎＰネットワークの構成の一例を示す図である。デジタルビデオカムコーダ（以下、ＤＶＣＲ）２００は、Audio Video Working Committee（ＡＶＷＣ）によって定義されているMediaServerとして機能するデバイスである。デジタルテレビ（以下、ＤＴＶ）３００は同じくＡＶＷＣによって定義されているMediaRendererとして機能するデバイス、そしてＤＨＣＰサーバ１００はInternetGateway WCで定義されているInternetGatewayDeviceである。また、ＤＴＶ３００はＵＰｎＰのコントロールポイントとしての機能も持つ。全てのデバイスはＩＥＥＥ８０２．ｂ準拠の無線インターフェースにて接続されている。なお、本実施形態におけるＤＨＣＰサーバ１００は、ＩＥＥＥ８０２．ｂ準拠のアクセスポイントで実現しているものとする。また、ＤＶＣＲ２００、ＤＴＶ３００はＤＨＣＰクライアント機能、ＡｕｔｏＩＰ機能を合わせ持つことになる。

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

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

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

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

さて、ＤＶＣＲ２００が、上記のようにしてＤＨＣＰサーバ１００よりＩＰアドレスを取得してＵＰｎＰネットワークに参加してデータを送信中、何らかの原因でＤＨＣＰサーバ１００がネットワークから離脱した場合（ＤＨＣＰサーバ１００の通信可能エリアが、ＤＶＣＲ２００等の通信可エリア外になったり、その電源がＯＦＦになった場合等）の処理を図２のフローチャートに従って説明する。なお、図２に係る処理はデータ送信処理とは別タスクとして処理しているものである。

ＤＶＣＲ２００はＤＨＣＰサーバ１００より割り当てられたＩＰアドレスのリース期間が終了する前に、定期的にＤＨＣＰサーバ１００に対してリース更新要求（DHCP REQUEST）を行う（ステップＳ２０１、Ｓ２０２）。

リース更新要求（DHCP REQUEST）を発行した後、ステップＳ２０３にて、所定時間内にＤＨＣＰサーバ１００からの承認メッセージ（DHCPACK）を受信した場合は、リース期間を更新する。また、ステップＳ２０３にて所定時間内にＤＨＣＰサーバ１００からの承認メッセージ（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）をＤＨＣＰサーバ１００に対して行う。ＤＨＣＰサーバ１００はこのリース更新要求を受信し、リース期間を更新する（DHCPACK）。これを示すのが図示のタイミングＴ２である。

図示では、この後、タイミングＴ３にて、ＤＨＣＰサーバ１００がネットワークより離脱した場合を示している。

この後、ＤＶＣＲ２００はリース期間が終了直前となり、リース更新要求（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メッセージを受信していない場合でも、ＤＨＣＰサーバ１００より割り当てられたリース期間が終了直前であると判断した場合（ステップＳ４０４）には、ＤＨＣＰサーバ１００に対してリース更新要求（DHCPREQUEST）を行う（ステップＳ４０５）。

さて、処理がステップＳ４０５に進み、リース更新要求をＤＨＣＰサーバ１００に対して行って、ＤＨＣＰサーバ１００からのDHCP ACKを一定のタイムアウト時間内に受信した場合は、リース期間を更新する。ここでは上記タイムアウト時間を２秒とするが、この限りではない。また、ステップＳ４０５において、ＤＨＣＰサーバ１００からのDHCP ACKを一定のタイムアウト時間内に受信しなかった場合は、ＤＶＣＲ２００は現在データ転送中かどうかを調べ（ステップＳ４０７）、データ転送中であれば、データ転送が終了するまでＤＨＣＰサーバ１００から従前に割り当てられたＩＰアドレス設定を維持し、データ転送を継続する。そして、ステップＳ４０７にて、その転送が終了したと判断した場合には、ステップＳ４０８に進んでＡｕｔｏＩＰに移行し、ＩＰアドレス及びサブネットマスクを変更する（ステップＳ４０８）。

次に、上記の処理を行うＤＶＣＲ２００がデータ転送中にＤＨＣＰサーバ１００がＵＰｎネットワークから離脱した場合のシーケンスの一例を図５に従って説明する。

初期状態において、全てのデバイス（ＤＶＣＲ２００、ＤＴＶ３００）はＤＨＣＰサーバ１００より割り当てられたＩＰアドレスを設定しており、ＤＶＣＲ２００のＩＰアドレス／サブネットマスクは「192.168.0.2/24」、ＤＴＶ３００のそれは「192.168.0.3/24」、ＤＨＣＰサーバ１００は「192.168.0.1/24」（固定）である。また、本実施形態のＤＨＣＰサーバ１００によるＩＰアドレスのリース期間はどの機器に対しても３分間とし、各デバイスは２分間おきにＤＨＣＰサーバ１００に対してリース更新要求をするものとする。なお、この設定時間は一例であり、この限りではない。

このような初期状態において、ユーザはＤＴＶ３００上のコントロールポイントアプリケーションにおいて、操作部（操作ボタンが設けられたリモコン等）及びＤＴＶ３００の表示メニューに従い、ネットワーク内のＵＰｎＰ機器の中からＤＶＣＲ２００をデータ送信元として選択する。その後ユーザはＤＶＣＲ２００内の映像データを選択し、再生要求を示すボタンを押下する。これに伴いＤＴＶ３００はRTSP SETUPコマンドをＤＶＣＲ２００に送信し、ＤＴＶ３００−ＤＶＣＲ２００間にコネクションを張り、ＤＴＶ３００からＤＶＣＲ２００へRTSPPLAYコマンドを送信することで、ＤＶＣＲ２００からＤＴＶ３００へ向けて選択された映像データのRTP/RTSPストリーミング転送を開始する。すなわち、ＤＶＣＲ２００はRTSPPLAYコマンドを受信すると指定された映像データをRTPで送信開始する。ＤＴＶ３００はＤＶＣＲ２００より送信される動画データを受信し、リアルタイムに画面に表示を開始することになる（タイミングＴ１１）。なお、ここで、図５に示すシーケンスにおいてはＤＶＣＲ２００がストリーミング転送中に接続の確認を行うために送信するGETPARAMETERコマンドに対して、ＤＴＶ３００は常に確認レスポンスを返信しているものとする。

この後、ＤＴＶ３００はＤＨＣＰリース期間が終了直前（前回のリースされてから２分経過した場合に相当する）となったため、リース更新要求（DHCP REQUEST）をＤＨＣＰサーバ１００に対して行う。ＤＨＣＰサーバ１００はこの更新要求を受信し、新たなリース期間を設け、更新を承認する（DHCPACK）（タイミングＴ１２）。

この後、ＤＨＣＰサーバ１００がネットワークより離脱する。このとき、ＵＰｎＰの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メッセージの記述内容の一例を示す図である。ＵＰｎＰネットワークからＤＨＣＰサーバが離脱した際のこれまでのシーケンスを示す図である。実施形態におけるＤＶＣＲのブロック構成図である。

Claims

ＵＰｎＰ（Universal Plug and Play）ネットワークに接続されたＤＨＣＰサーバから第１のＩＰアドレスを取得する通信装置であって、
前記第１のＩＰアドレスのリース期間中にＢＹＥＢＹＥメッセージが受信されたか否かを判定する判定手段と、
前記第１のＩＰアドレスのリース期間中に前記ＢＹＥＢＹＥメッセージが受信されたと判定された場合に、前記第１のＩＰアドレスのリース期間の更新を要求する更新要求を前記ＤＨＣＰサーバに送信する更新要求送信手段と、
第２のＩＰアドレスを生成するＩＰアドレス生成手段と
を有し、
前記更新要求が前記ＤＨＣＰサーバによって承認されなかったと判定された場合であり、かつ、画像データの送信が行われていないと判定された場合は、前記通信装置のＩＰアドレスを前記第１のＩＰアドレスから前記第２のＩＰアドレスに変更する
ことを特徴とする通信装置。
前記更新要求が前記ＤＨＣＰサーバによって承認されなかったと判定された場合であり、かつ、画像データの送信が行われていると判定された場合は、前記通信装置のＩＰアドレスを前記第１のＩＰアドレスから前記第２のＩＰアドレスに変更しないようにすることを特徴とする請求項１に記載の通信装置。
前記ＩＰアドレス生成手段は、ＡｕｔｏＩＰを用いて前記第２のＩＰアドレスを生成することを特徴とする請求項１または２に記載の通信装置。
前記ＢＹＥＢＹＥメッセージは、前記ＤＨＣＰサーバからのＢＹＥＢＹＥメッセージであることを特徴とする請求項１から３のいずれか１項に記載の通信装置。
前記判定手段は、前記ＢＹＥＢＹＥメッセージが前記ＤＨＣＰサーバからのＢＹＥＢＹＥメッセージであるか否かを、前記ＢＹＥＢＹＥメッセージに含まれる情報を用いて判定することを特徴とする請求項４に記載の通信装置。