(57)【要約】  端末から受信したリソース取得要求に応じて、放送信号の受信または送信のために使用される複数の通信リソースの中に空き通信リソースがあるか否かがチェックされる。それらの通信リソースが使用中であり、空き通信リソースがない場合、リソース取得要求は一時的に保留され、使用中の通信リソースの解放が待ち合せられる。使用されなくなった通信リソースが解放されると、保留されているリソース取得要求に対して、解放された通信リソースが割り当てられる。
2008152677.tif 000002
【特許請求の範囲】
【請求項１】
放送信号を受信して複数の端末に送信する通信装置であって、
前記放送信号の受信または送信のために使用される複数の通信リソースと、
前記複数の通信リソースのうち、使用されなくなった通信リソースを解放するリソース解放手段と、
前記複数の端末の１つからリソース取得要求を受信する受信手段と、
前記リソース取得要求に応じて空き通信リソースがあるか否かをチェックし、該リソース取得要求に対して空き通信リソースを割り当てるリソース割り当て手段と、
前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留し、使用中の通信リソースの解放を待ち合せる空き待ち手段と
を備えることを特徴とする通信装置。
【請求項２】
前記空き通信リソースがない場合に、通信リソースを使用中の端末に対してリソース継続使用確認を送信する送信手段をさらに備え、前記リソース解放手段は、該リソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項１記載の通信装置。
【請求項３】
前記リソース解放手段は、前記通信リソースを使用中の端末に対して定期的に送信される別のリソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項２記載の通信装置。
【請求項４】
前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信される別のリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項２記載の通信装置。
【請求項５】
前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信されるリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項１記載の通信装置。
【請求項６】
前記複数の通信リソースは、放送型ネットワークから前記放送信号を受信する複数の無線受信手段であり、前記受信手段は、マルチキャスト対応のネットワーク経由で前記複数の端末の１つから前記リソース取得要求を受信することを特徴とする請求項１乃至５のいずれかに記載の通信装置。
【請求項７】
放送信号を受信して複数の端末に送信する通信装置における通信リソース管理方法であって、
前記複数の端末の１つからリソース取得要求を受信し、
前記リソース取得要求に応じて、前記放送信号の受信または送信のために使用される複数の通信リソースの中に空き通信リソースがあるか否かをチェックし、
前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留して、使用中の通信リソースの解放を待ち合せ、
前記複数の通信リソースのうち、使用されなくなった通信リソースを解放し、
保留されているリソース取得要求に対して、解放された通信リソースを割り当てる
ことを特徴とする通信リソース管理方法。
【請求項８】
前記空き通信リソースがない場合に、通信リソースを使用中の端末に対してリソース継続使用確認を送信し、該リソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項７記載の通信リソース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号を受信して、ＩＰＴＶ（Internet Protocol Television）対応の複数の端末に送信するためのゲートウェイとして動作する通信装置と、その通信装置における通信リソース管理方法に関する。
【背景技術】
【０００２】
地上波を使用した放送サービスとして地上アナログ放送に加え、地上デジタル放送が開始された。衛星を使用した放送サービスとしては、ＢＳ（Broadcasting Satellite）デジタル放送およびＣＳ（Communications Satellite）デジタル放送があり、視聴者宅内でこれらの放送サービスを視聴するには、それぞれ別々の受信機あるいは受信機能を有したテレビ端末を準備する必要がある。【０００３】
一方、ＦＴＴＨ（Fiber to the Home ）に代表されるブロードバンドサービスの普及も本格化し、地上デジタル放送の電波の届かない地域での地上アナログ放送からの移行形態として、このＦＴＴＨを使用したＩＰマルチキャストによる地上デジタル放送のＩＰ再送信が検討されており、テレビ端末にもこの受信機能の搭載が検討され始めた。また、ブロードバンドサービスを利用して、専用の受信機により、最新のハリウッド映画等をＶＯＤ（Video on Demand ）として視聴できるサービスも整いつつある。【０００４】
地上デジタル放送、ＢＳ／ＣＳデジタル放送、ＩＰ放送（ＩＰＴＶ）、ＶＯＤ等のように多様化したサービスでは、それぞれの配信形態や配信媒体が異なる。このため、複数のサービスを利用するには、視聴者宅内に設置されるテレビ端末の配線が煩雑になり、かつ、操作も複雑になる。そこで、視聴者としては、その配線の統一や視聴方法の一元化が望まれる。【０００５】
図１は、従来の地上デジタル放送におけるＩＰ再送信の構成を示している。ＩＰＴＶ配信局１０１には、複数のＩＰ再送信装置１１１が設けられる。ＩＰ再送信装置１１１のＲＦ（Radio Frequency ）受信部１１３は、ＩＰ再送信の対象として、アンテナ１１２から入力される地上デジタル放送の放送波を受信する。【０００６】
この放送波は、図２に示すように、ＭＰＥＧ２−ＴＳ（Moving Picture Experts Group phase 2-Transport Stream ）のフォーマットのデジタル情報を含む。ＭＰＥＧ２−ＴＳは、ＩＳＯ（International Organization for Standardization）／ＩＥＣ（International Electrotechnical Commission ）１３８１８−１および
1181540389771_0
（International Telecommunication Union Telecommunication Standardization Sector）勧告Ｈ．２２２．０にて規定されたフォーマットである。【０００７】
ＲＦ受信部１１３は、受信したＭＰＥＧ２−ＴＳの画像コンテンツ部および付加情報部を、ＣＡＳ（Conditional Access System ）解除部１１４およびＮＩＴ（Network Information Table ）変換部１１７にそれぞれ出力する。【０００８】
ＣＡＳ解除部１１４は、限定受信を提供するために画像コンテンツ部に付加されたＣＡＳを解除し、符号化変換部１１５は、符号化方法をＭＰＥＧ２からＨ．２６４／ＡＶＣ（Advanced Video Coding ）に変換（トランスコード）する。そして、ＣＡＳ付加部１１６は、画像コンテンツ部に、再度、ＩＰ再送信用のＣＡＳを付加する。ＮＩＴ変換部１１７は、付加情報部内のＮＩＴを、ＩＰ再送信用に変換する。これにより、ＮＩＴ内の周波数情報がＩＰアドレス情報に変換される。【０００９】
こうして、図３に示すように、受信したＭＰＥＧ２−ＴＳ１４１から、変換後の画像コンテンツ部と付加情報部を含むＭＰＥＧ２−ＴＳ１４２が生成される。ＩＰパケット化部１１８は、生成されたＭＰＥＧ２−ＴＳを、図４に示すような、マルチキャスト形式のＩＰパケットにパケット化し、ＩＰ網１０２に送出する。【００１０】
ＩＰ網１０２では、ＩＰ再送信されるすべてのチャンネルのマルチキャストパケットが、視聴者を収容する光ファイバ１２３直近のレイヤ２スイッチ（Ｌ２ＳＷ）１２２まで中継される。【００１１】
ＩＰ網１０２内に設置されたマルチキャストルータ１２１は、視聴者宅１０３のＩＰ再送信対応の端末１３２との間で、チャンネル選択の制御として、マルチキャスト対応のグループ管理プロトコルであるＩＧＭＰ（Internet Group Management Protocol）メッセージＭ１およびＭ２のやり取りを行う。端末１３２は、ＩＰ再送信対応のテレビ受信機やレコーダであり、ＩＧＭＰとしては、ＩＧＭＰｖ１（ＲＦＣ（Request For Comment ）１１１２）またはＩＧＭＰｖ２（ＲＦＣ２２３６）が用いられる（例えば、下記の非特許文献１を参照）。【００１２】
レイヤ２スイッチ１２２は、ＩＧＭＰスヌーピング機能によりＩＧＭＰメッセージＭ１をモニタし、視聴者が選択したマルチキャストグループ宛のパケットのみを、その視聴者を収容する光ファイバ１２３に送出する。【００１３】
視聴者宅１０３では、光ファイバ１２３に接続されたＯＮＵ（Optical Network Unit）１３１からマルチキャストパケットが端末１３２に転送され、視聴者は、希望のＩＰ再送信を視聴することが可能になる。【００１４】
図５は、下記の特許文献１に開示されたＩＰマルチキャスト中継システムを示している。ＩＰＴＶ配信局１５１のマルチキャストサーバ１６１からは、図６に示すようなマルチキャストパケットが送出され、センタ送出装置１６２は、特定の複数のマルチキャストパケットを中継する。これにより、図７に示すようなフォーマットで、特定の複数のマルチキャストパケットが、それぞれ異なる周波数を使用してＣＡＴＶ（Community Antenna Television）伝送路１５２により、バイパス中継される。【００１５】
視聴者宅１５４の通信装置１７１は、周波数とマルチキャストグループのアドレスの対応関係を登録したテーブル１７６を備える。マルチキャスト対応の端末１７３から、視聴者がＩＧＭＰメッセージＭ３にてマルチキャストグループを選択すると、ＩＧＭＰ受信部１７８は、そのメッセージを受信し、制御部１７７に転送する。【００１６】
制御部１７７は、選択されたマルチキャストグループのアドレスに対応する周波数を、テーブル１７６から検索し、ＲＦ受信部１７４に通知する。ＲＦ受信部１７４は、その周波数を選択してマルチキャストパケットを受信し、ＬＡＮ（Local Area Network）送出制御部１７５は、図８に示すようなマルチキャストパケットを、ＬＡＮ経由で端末１７３に転送する。こうして、特定のマルチキャストグループ宛のパケットのみが、端末１７３に中継される。【００１７】
視聴者宅１５４のＮＵ（Network Unit）１７２は、ＩＰ網１５３を介してＩＰＴＶ配信局１５１に接続される。
次に、ＩＧＭＰメッセージによるＩＥＥＥ（Institute of Electrical and Electronic Engineers）１３９４バス上での通信資源（帯域リソース）管理について説明する。【００１８】
ＩＧＭＰｖ２には、“Ｍｅｍｂｅｒｓｈｉｐ  Ｒｅｐｏｒｔ”、“Ｌｅａｖｅ  Ｇｒｏｕｐ”、“Ｇｅｎｅｒａｌ  Ｑｕｅｒｙ”、“Ｇｒｏｕｐ−Ｓｐｅｃｉｆｉｃ  Ｑｕｅｒｙ”の４種類のＩＧＭＰメッセージが定義されている。【００１９】
このうち、“Ｍｅｍｂｅｒｓｈｉｐ  Ｒｅｐｏｒｔ”は、端末から送出される、マルチキャストグループへの加入を要求する加入メッセージであり、“Ｌｅａｖｅ  Ｇｒｏｕｐ”は、端末から送出される、マルチキャストグループからの離脱を要求する離脱メッセージである。【００２０】
“Ｇｒｏｕｐ−Ｓｐｅｃｉｆｉｃ  Ｑｕｅｒｙ”は、“Ｌｅａｖｅ  Ｇｒｏｕｐ”を受信した照会ルータ（Querier ）が、そのマルチキャストグループに参加している他の端末の有無を確認するために送出する第１の照会メッセージであり、“Ｇｅｎｅｒａｌ  Ｑｕｅｒｙ”は、照会ルータから定期的に送出される、すべてのマルチキャストグループへの参加の有無を照会する第２の照会メッセージである。【００２１】
図９は、下記の特許文献２に開示された、マルチキャストグループ加入時の処理のフローチャートである。ＩＧＭＰルータは、端末からマルチキャストグループへの加入メッセージを受信すると（ステップ１８１）、対応するＩＰマルチキャストアドレスについてのサービスを開始しているか否かをチェックする（ステップ１８２）。サービスを開始していなければ、そのＩＰマルチキャストアドレスへの加入手続き処理を行い（ステップ１８３）、処理が成功したか否かをチェックする（ステップ１８４）。処理が失敗した場合は、その旨を端末に通知する（ステップ１８９）。【００２２】
加入手続き処理が成功すると、次に、同期チャネル番号を確保し（ステップ１８５）、自らのレイヤ３フローレジスタに、このＩＰマルチキャストフローについての情報を書き込む（ステップ１８６）。このとき、レイヤ３フローレジスタ内のコネクションカウンタに、カウンタ値“１”が入力される。そして、端末のレイヤ３フローレジスタに対して、同様の情報を書き込む（ステップ１８７）。【００２３】
ステップ１８２において、要求されたＩＰマルチキャストアドレスについてのサービスを開始している場合は、自らのレイヤ３フローレジスタのコネクションカウンタをインクリメントする（ステップ１８８）。【００２４】
このように、端末からの加入メッセージを受信したとき、新規なマルチキャストグループへの加入の場合は、同期チャネル番号が確保され、既に処理中のマルチキャストグループへの加入の場合は、コネクションカクンタがインクリメントされる。【００２５】
図１０は、特許文献２に開示された、マルチキャストグループ脱退時の処理のフローチャートである。ＩＧＭＰルータは、ＩＰマルチキャストアドレス“ＩＰｍ”に対する離脱メッセージを端末から受信すると（ステップ１９１）、自らのレイヤ３フローレジスタのコネクションカウンタをデクリメントする（ステップ１９３）。【００２６】
また、ＩＰマルチキャストアドレス“ＩＰｍ”を受信し続けている旨のＩＧＭＰメッセージを、一定時間以上受信しなかった場合も（ステップ１９２）、コネクションカウンタをデクリメントする（ステップ１９３）。これは、第２の照会メッセージに対して、どの端末からも一定時間内に加入メッセージの応答がなかった場合に相当する。【００２７】
次に、ＩＧＭＰルータは、コネクションカウンタのカウンタ値が“０”になったか否かをチェックし（ステップ１９４）、その値が“０”になれば、そのＩＰマルチキャストグループから脱退する処理を行う（ステップ１９５）。【００２８】
下記の特許文献３には、ネットワークからデジタル放送情報を受信するためのデジタル放送受信装置が開示されている。このデジタル放送受信装置は、受信したデジタル放送情報中より、端末からの受信要求に応じたデジタル放送情報を抽出するための手段と、抽出したデジタル放送情報を、ネットワークを通じて端末に転送可能な情報形式に変換するための手段とを備え、変換後のデジタル放送情報を端末に転送する。【００２９】
しかしながら、上述した従来のデジタル放送におけるＩＰ再送信方法には、次のような問題がある。
視聴者宅内で多様なサービスを利用するために、図１に示したＩＰ再送信装置１１１を視聴者宅１０３内に設置することが考えられるが、放送チャンネル（周波数）の数だけの回路または機器が必要になる。例えば、東京では、地上デジタル放送が９チャンネル、ＢＳデジタル放送が４チャンネル、１１０度ＣＳデジタル放送が１２チャンネルあり、計２５個のＲＦ受信部が必要である。特に、戸建住宅の場合には、設置面積（回路規模）やコスト的に負担が大きい。【００３０】
次に、図５に示した通信装置１７１の仕組みを、ＩＰ放送のチャンネル選択に使用することも考えられる。しかし、ＲＦ受信部が１つしかないため、レコーダでの裏録画、ピクチャインピクチャ（ＰｉｎＰ）、複数の端末による同時視聴・録画等を目的として、異なる複数のチャンネルを同時に使用することができず、利便性が悪い。【００３１】
また、図１０に示したマルチキャストグループ脱退時の処理では、端末から離脱メッセージを受信すると、コネクションカウンタがデクリメントされる。しかし、ＩＧＭＰｖ２では、メッセージの輻輳回避のため、第１の照会メッセージまたは第２の照会メッセージに対する応答として、すべての参加したい端末に対して加入メッセージによる応答を義務付けていない。つまり、同じマルチキャストグループの他の端末は、隣接する端末の送信メッセージを聴取し、同じグループに属していれば、加入メッセージの送信を停止することができる。【００３２】
このため、離脱メッセージの受信により直ちに通信リソースを解放することはできず、第１の照会メッセージに対して加入メッセージによる応答がないことで、初めて通信リソースの解放が可能になる。【００３３】
さらに、特許文献２および３の構成では、以下に述べるように、有限の通信リソースに関する問題を解決することはできない。
図１１は、ＩＧＭＰｖ２において、空きリソースがない状態でチャンネル切り替えを行う場合の動作シーケンスを示している。通信装置に空きリソースがない状態で（手順２０１）、通信装置のリソースＲ１を使用している端末ａがチャンネル切り替えを行うとき（手順２０２）、通信装置は、前述したように、端末ａからの前チャンネルの離脱メッセージを受信しても（手順２０３）、直ちに前チャンネルで使用していたリソースＲ１を解放することはできない。【００３４】
そこで、通信装置は、前チャンネルに対応するマルチキャストグループの第１の照会メッセージを送出し（手順２０４）、その応答時間（１秒）内にどの端末からもそのマルチキャストグループへの加入メッセージがない場合に、初めてリソースＲ１を解放する（手順２０７）。【００３５】
リソースの解放前に、他のマルチキャストグループ（例えば、新チャンネル）の加入メッセージを受信すると（手順２０５）、空きリソースがないため、その要求をブロックする（手順２０６）。リソースの解放後に、新チャンネルの加入メッセージを受信すると（手順２０８）、新チャンネルのマルチキャストグループに対して、解放されたリソースＲ１を割り当てる（手順２０９）。【００３６】
この場合、端末ａでは、前チャンネルの離脱メッセージ送出と新チャンネルの加入メッセージ送出の間に、最低１秒以上間隔を空ける必要がある。
また、ＩＧＭＰｖ１では、離脱メッセージおよび第１の照会メッセージをサポートしていないため、第２の照会メッセージに対する加入メッセージによる応答の有無により、リソースを解放する必要がある。【００３７】
図１２は、ＩＧＭＰｖ１において、空きリソースがない状態でチャンネル切り替えを行う場合の動作シーケンスを示している。端末ａがリソースＲ１、端末ｂがリソースＲ２、端末ｃがリソースＲ３を使用中であり、通信装置に空きリソースがない状態で（手順２１１）、通信装置は、リソースＲ１〜Ｒ３の更新として、１２５秒間隔で定期的に第２の照会メッセージを送出する（手順２１２）。【００３８】
これに対して、端末ａ〜ｃは、視聴中のチャンネル（前チャンネル、チャンネルＣＨｎ、チャンネルＣＨｍ）の加入メッセージを送出する（手順２１３〜２１５）。通信装置は、第２の照会メッセージの応答時間（１０秒）内にすべての端末から加入メッセージを受信したため、いずれのリソースも解放しない（手順２１９）。【００３９】
端末ａは、前チャンネルの加入メッセージを送出した直後に、チャンネル切り替えを行い（手順２１６）、前チャンネルの視聴を終了する。しかし、新チャンネルの加入メッセージを送出しても（手順２１７）、空きリソースがないため、その要求はブロックされる（手順２１８）。【００４０】
通信装置は、次の周期の第２の照会メッセージを送出し（手順２２０）、端末ｂおよびｃから、チャンネルＣＨｎおよびＣＨｍの加入メッセージを受信する（手順２２１〜２２２）。ところが、端末ａからは前チャンネルの加入メッセージを受信しないため、前チャンネルで使用していたリソースＲ１を解放する（手順２２３）。その後、端末ａから新チャンネルの加入メッセージを受信すると（手順２２４）、新チャンネルのマルチキャストグループに対して、解放されたリソースＲ１を割り当てる（手順２２５）。【００４１】
このように、次の周期の第２の照会メッセージに対して、どの端末からもリソースＲ１に対応するマルチキャストグループへの加入メッセージが来ない場合に、初めてリソース１を解放することができる。つまり、端末ａでは、前チャンネルの加入メッセージ送出と新チャンネルの加入メッセージ送出の間に、最低１３５秒（第２の照会メッセージの送出間隔（１２５秒）＋応答時間（１０秒））以上間隔を空ける必要がある。【００４２】
以上説明したように、チャンネル切り替え時のような有限リソースの再取得においては、メッセージを送出するタイミングに大きな制約がある。
【特許文献１】特開２００３−２０４３５５号公報
【特許文献２】特開平１０−３０８７５９号公報
【特許文献３】特開２００１−０９４５１９号公報
【非特許文献１】“Internet Group Management Protocol, Version 2 ”、［ｏｎｌｉｎｅ］、［平成１９年４月９日検索］、インターネット＜ＵＲＬ：http://www.geocities.jp/kotekoteland/rfc/rfc2236j.txt ＞
【発明の開示】
【００４３】
本発明の課題は、放送型のネットワークにおける有限な通信リソースに空きがない状態でも、リソース取得要求がブロックされる可能性を低減し、ユーザの利便性向上とリソースの有効利用を図ることである。
【００４４】
図１３は、本発明の通信装置の原理図である。図１３の通信装置は、ｋ個の通信リソース３０１−１〜３０１−ｋ、リソース解放手段３０２、受信手段３０３、リソース割り当て手段３０４、および空き待ち手段３０５を備え、放送信号を受信して複数の端末に送信する。
【００４５】
通信リソース３０１−１〜３０１−ｋは、放送信号の受信または送信のために使用される。リソース解放手段３０２は、通信リソース３０１−１〜３０１−ｋのうち、使用されなくなった通信リソースを解放する。受信手段３０３は、複数の端末の１つからリソース取得要求を受信する。リソース割り当て手段３０４は、リソース取得要求に応じて空き通信リソースがあるか否かをチェックし、そのリソース取得要求に対して空き通信リソースを割り当てる。空き待ち手段３０５は、通信リソース３０１−１〜３０１−ｋが使用中であり、空き通信リソースがない場合に、リソース取得要求を一時的に保留し、使用中の通信リソースの解放を待ち合せる。
【００４６】
このような通信装置によれば、リソース解放手段３０２によりいずれかの通信リソースが解放されたとき、リソース割り当て手段３０４が、保留されているリソース取得要求に対して、解放された通信リソースを割り当てることができる。
【００４７】
さらに、空き通信リソースがない場合に、通信リソースを使用中の端末に対してリソース継続使用確認を送信し、そのリソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放するようにしてもよい。
【００４８】
通信リソース３０１−１〜３０１−ｋは、例えば、後述する図１５のＲＦ受信部３８４または変換部３８５に対応し、リソース解放手段３０２、リソース割り当て手段３０４、および空き待ち手段３０５は、例えば、制御部３８９に対応する。受信手段３０３は、例えば、ＩＧＭＰ送受信部３９０に対応する。
【００４９】
本発明によれば、通信リソースに空きがない状態において、リソース取得要求がブロックされる可能性が低減され、利便性が向上するとともにリソースの有効利用が促進される。
【００５０】
具体的には、マルチキャストを使用したＩＰ放送受信用の端末がチャンネル切り替えを行う際のプロトコルにおいて、前チャンネルのリソース解放用のメッセージと新チャンネルのリソース捕捉用のメッセージの送出タイミングにおける制約が解除され、それらのメッセージの連続送出が可能になる。これにより、リソース切り替え時間を短縮することができる。
【００５１】
また、空きリソースがない場合にリソース継続使用確認のメッセージを送出するようにすれば、使用されなくなった通信リソースの解放を迅速に行うことができる。したがって、前チャンネルのリソース解放用のメッセージをサポートしていない端末においても、チャンネル切り替えの待ち合せ時間を約１３５秒から人間が操作で許容できる約１秒に短縮でき、利便性が著しく向上する。
【００５２】
さらに、複数の異なるチャンネルの同時視聴が可能な通信装置の場合、放送チャンネルの数だけ必要であったＲＦ受信部を大幅に削減することが可能になる。例えば、東京で３つのチャンネルを同時視聴する場合、地上デジタル放送用とＢＳ／ＣＳデジタル放送用に２個ずつＲＦ受信部を設けたとしても、計６個のＲＦ受信部があればよく、コスト削減の効果が大きい。
【図面の簡単な説明】
【００５３】
【図１】地上デジタル放送のＩＰ再送信を示す図である。
【図２】ＭＰＥＧ２−ＴＳを示す図である。
【図３】ＭＰＥＧ２−ＴＳの変換を示す図である。
【図４】第１のマルチキャストパケットを示す図である。
【図５】ＩＰマルチキャスト中継システムを示す図である。
【図６】第２のマルチキャストパケットを示す図である。
【図７】第３のマルチキャストパケットを示す図である。
【図８】第４のマルチキャストパケットを示す図である。
【図９】従来のマルチキャストグループ加入時の処理のフローチャートである。
【図１０】従来のマルチキャストグループ脱退時の処理のフローチャートである。
【図１１】チャンネル切替時の第１の動作シーケンスを示す図である。
【図１２】チャンネル切替時の第２の動作シーケンスを示す図である。
【図１３】本発明の通信装置の原理図である。
【図１４】通信リソース管理処理の原理フローチャートである。
【図１５】通信システムの構成図である。
【図１６】周波数とアドレスの対応テーブルを示す図である。
【図１７】第１の通信リソース管理処理のフローチャートである。
【図１８】通信システムの第１の動作シーケンスを示す図である。
【図１９】通信システムの第２の動作シーケンスを示す図である。
【図２０】通信システムの第３の動作シーケンスを示す図である。
【図２１】第２の通信リソース管理処理のフローチャートである。
【図２２】通信システムの第４の動作シーケンスを示す図である。
【図２３】通信システムの第５の動作シーケンスを示す図である。
【図２４】第３の通信リソース管理処理のフローチャートである。
【図２５】通信システムの第６の動作シーケンスを示す図である。
【図２６】通信システムの第７の動作シーケンスを示す図である。
【図２７】第４の通信リソース管理処理のフローチャートである。
【図２８】通信システムの第８の動作シーケンスを示す図である。
【発明を実施するための最良の形態】
【００５４】
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図１４は、通信装置による通信リソース管理処理の原理フローチャートである。この通信リソース管理処理は、次の５つの処理から構成される。
（ａ）リソース捕捉処理（ステップ３５１〜３５３および３５６）
（ｂ）第１のリソース解放処理（ステップ３６０〜３６３）
（ｃ）第２のリソース解放処理（ステップ３６４〜３６６）
（ｄ）空き待ち処理（ステップ３５４〜３５５）
（ｅ）第３のリソース解放処理（ステップ３５７〜３５９）
リソース捕捉処理（ａ）において、通信装置は、端末からリソース取得要求を受信すると（ステップ３５１）、空きリソースがあるか否かをチェックする（ステップ３５２）。そして、空きリソースがあれば、そのリソースを端末に割り当てる（ステップ３５３）。リソース取得要求は、例えば、新リソース確保のための加入メッセージに対応する。【００５５】
空きリソースがなければ、空き待ち処理（ｄ）を行って、そのリソース取得要求を一時的に保留し、リソースの空きを待ち合せる。この空き待ち処理では、定期的に空きリソースがあるか否かをチェックし（ステップ３５４）、空きリソースがあれば、ステップ３５３の処理を行う。空きリソースがなければ、次に、保留期間が経過したか否かをチェックし（ステップ３５５）、保留期間が経過していなければ、ステップ３５４以降の処理を繰り返す。そして、保留期間が経過すると、そのリソース取得要求をブロックする（ステップ３５６）。【００５６】
通信装置は、第１、第２、または第３のリソース解放処理のいずれかを行うことで、リソースを解放する。
第１のリソース解放処理（ｂ）において、通信装置は、端末からリソース解放要求を受信すると（ステップ３６０）、そのリソースを使用中の端末に対して第１のリソース継続使用確認を送信し（ステップ３６１）、使用中の端末の有無をチェックする（ステップ３６２）。使用中の端末がなければ、そのリソースを解放し（ステップ３６３）、使用中の端末があれば、そのリソースを解放しない。リソース解放要求は、例えば、前リソース解放のための離脱メッセージに対応し、第１のリソース継続使用確認は、例えば、離脱メッセージを受信したときに送出される第１の照会メッセージに対応する。【００５７】
（ａ）、（ｄ）、および（ｂ）の処理を組み合わせることで、端末によるリソース切り替えやリソースの再取得において、離脱メッセージと加入メッセージの連続送出が可能になる。これにより、利便性が向上するとともにリソースの有効利用が促進される。【００５８】
第２のリソース解放処理（ｃ）において、通信装置は、定期的に第２のリソース継続使用確認を送信し（ステップ３６４）、各リソースを使用中の端末の有無をチェックする（ステップ３６５）。あるリソースについて使用中の端末がなければ、そのリソースを解放し（ステップ３６６）、すべてのリソースについて使用中の端末があれば、いずれのリソースも解放しない。第２のリソース継続使用確認は、例えば、定期的に送出される第２の照会メッセージに対応する。【００５９】
第３のリソース解放処理（ｅ）は、ステップ３５２において空きリソースがない場合に行われる。この場合、通信装置は、第１または第２のリソース継続使用確認を送信し（ステップ３５７）、リソースを使用中の端末の有無をチェックする（ステップ３５８）。使用中の端末がなければ、そのリソースを解放し（ステップ３５９）、使用中の端末があれば、そのリソースを解放しない。【００６０】
（ａ）、（ｄ）、（ｃ）、および（ｅ）の処理を組み合わせることで、端末によるリソース切り替えやリソースの再取得において、いつでも加入メッセージを送出できるようになる。これにより、利便性が向上するとともにリソースの有効利用が促進される。【００６１】
また、（ａ）、（ｄ）、（ｂ）、および（ｅ）の処理を組み合わせることで、電源断等によりリソースを解放する離脱メッセージが送出されず、捕捉されたままの状態になっているリソースを、新規なリソース取得要求に対して割り当てることが可能になる。これにより、利便性が向上するとともにリソースの有効利用が促進される。【００６２】
図１５は、このような通信リソース管理処理が実装され、地上デジタル放送、ＢＳ／ＣＳデジタル放送、ＩＰ放送等の多様なサービスを視聴することが可能な通信システムの構成例を示している。【００６３】
この通信システムにおいて、視聴者宅３７３に設けられた通信装置３８１は、ＩＧＭＰにおけるマルチキャストルータとして動作し、マルチキャスト対応のＬＡＮ経由で、ＩＰ放送対応の端末ａ〜ｄに接続される。【００６４】
また、ＬＡＮに接続されたＯＮＵ３９２は、光ファイバ３９１およびＩＰ網３７２経由で、ＩＰＴＶ配信局３７１のマルチキャストサーバ３７４に接続される。マルチキャストサーバ３７４は、ＩＰ放送のコンテンツを蓄積して、ＩＰ網３７２に送出し、ＩＰ網３７２内のマルチキャストルータ３７５は、そのコンテンツを光ファイバ３９１経由で視聴者宅３７３に中継する。【００６５】
通信装置３８１は、地上デジタル放送用のアンテナ３８２、ＢＳ／ＣＳデジタル放送用のアンテナ３８３、複数のＲＦ受信部３８４、変換部３８５、ＩＰパケット化部３８６、ＬＡＮ送出制御部３８７、テーブル３８８、制御部３８９、およびＩＧＭＰ送受信部３９０を備える。【００６６】
ＲＦ受信部３８４は、管理対象の通信リソースに相当し、アンテナ３８２または３８３から入力される地上デジタル放送またはＢＳ／ＣＳデジタル放送の放送波を受信する。変換部３８５は、図１のＣＡＳ解除部１１４、符号化変換部１１５、ＣＡＳ付加部１１６、およびＮＩＴ変換部１１７に対応し、受信した放送波に含まれる画像コンテンツ部の符号化方法と、付加情報部内の周波数情報等をＩＰ再送信用に変換する。【００６７】
ＩＰパケット化部３８６は、変換後の画像コンテンツ部と付加情報部を含むＭＰＥＧ２−ＴＳを、マルチキャスト形式のＩＰパケットに変換し、ＬＡＮ送出制御部３８７は、制御部３８９から指示されたＩＰパケットのみをＬＡＮに送出する。【００６８】
テーブル３８８は、図１６に示すように、受信周波数とマルチキャストグループのアドレスの対応関係を保持し、ＩＧＭＰ送受信部３９０は、制御部３８９と端末ａ〜ｄが受信チャンネル選択の制御に使用するＩＧＭＰメッセージを、ＬＡＮとの間で送受信する。【００６９】
制御部３８９は、放送波の受信とＩＰ再送信の全体制御を行うとともに、図１４に示したような通信リソース管理処理を行う。
ＩＧＭＰメッセージとしては、上述した通り、ＩＧＭＰｖ１またはＩＧＭＰｖ２のＩＧＭＰメッセージが用いられる。【００７０】
ＩＧＭＰｖ２には、加入メッセージ（Ｍｅｍｂｅｒｓｈｉｐ  Ｒｅｐｏｒｔ）、離脱メッセージ（Ｌｅａｖｅ  Ｇｒｏｕｐ）、第１の照会メッセージ（Ｇｒｏｕｐ−Ｓｐｅｃｉｆｉｃ  Ｑｕｅｒｙ）、および第２の照会メッセージ（Ｇｅｎｅｒａｌ  Ｑｕｅｒｙ）が定義されている。このうち、加入メッセージおよび離脱メッセージは、ＩＧＭＰメッセージＭ１１として端末ａ〜ｄから制御部３８９に送信され、第１および第２の照会メッセージは、ＩＧＭＰメッセージＭ１２として制御部３８９から端末ａ〜ｄに送信される。【００７１】
また、ＩＧＭＰメッセージＭ１１は、端末ａ〜ｄからマルチキャストルータ３７５にも送信され、ＩＧＭＰメッセージＭ１２は、マルチキャストルータ３７５から端末ａ〜ｄにも送信される。【００７２】
なお、ＩＧＭＰｖ１では、４種類のメッセージのうち、離脱メッセージおよび第１の照会メッセージがサポートされていない。
ＩＧＭＰでは、１つの物理ネットワーク内で照会を行う照会ルータは１つに限定される。図１５の通信システムにおける照会ルータの候補は、マルチキャストルータ３７５と通信装置３８１であり、照会ルータは、既知の手順にて選出される。【００７３】
次に、図１７から図２０までを参照しながら、図２の（ａ）、（ｄ）、および（ｂ）の処理を組み合わせた通信リソース管理処理について説明する。
図１７は、この通信リソース管理処理のフローチャートである。制御部３８９は、端末から加入メッセージを受信すると（ステップ５０１）、その加入メッセージ内のマルチキャストグループのアドレスを分析して、受信処理中のマルチキャストグループのアドレスであるか否かをチェックする（ステップ５０２）。それが受信処理中のマルチキャストグループのアドレスであれば、既に放送受信している他の端末と同一のチャンネルを受信することを示しているため、その加入メッセージに対する処理を終了する。【００７４】
加入メッセージ内のマルチキャストグループのアドレスが、受信処理中のマルチキャストグループのアドレスでなければ、空きのＲＦ受信部３８４（空きリスース）があるか否かを確認し（ステップ５０３）、空きリソースがあればそのリソースを捕捉する（ステップ５０４）。【００７５】
リソースの捕捉においては、空きのＲＦ受信部３８４をそのマルチキャストグループに割り当て、テーブル３８８からそのマルチキャストグループのアドレスに対応する受信周波数を検索する。そして、その受信周波数をＲＦ受信部３８４に設定するとともに、そのマルチキャストグループ宛のパケットの送出を、ＬＡＮ送出制御部３８７に対して許可する。【００７６】
ステップ５０３において空きリソースがなければ、所定の待ち合せ時間（保留期間）だけＲＦ受信部３８４の空きを待ち合せる。この空き待ち処理では、定期的に空きリソースがあるか否かをチェックし（ステップ５０５）、空きリソースがあれば、ステップ５０４の処理を行う。空きリソースがなければ、次に、待ち合せ期間が経過したか否かをチェックし（ステップ５０６）、待ち合せ時間が経過していなければ、ステップ５０５以降の処理を繰り返す。そして、待ち合せ時間が経過すると、その加入メッセージをブロックする（ステップ５０７）。【００７７】
したがって、待ち合せ時間内または待ち合せ時間経過時にリソース解放により空きができた場合は、そのリソースが捕捉される。また、待ち合せ時間を経過しても空きができなかった場合に、初めてその加入メッセージに対してブロック処理が行われる。この待ち合せ時間としては、例えば、第１の照会メッセージの応答待ち時間である１秒に余裕を持たせた一定時間（１秒＋α）が用いられる。待ち合せ時間の代わりに、空きリソースの確認する回数等を決めておき、その回数だけステップ５０５の処理を行うようにしてもよい。【００７８】
ステップ５０１〜５０７の処理と並行して、制御部３８９は、端末から離脱メッセージを受信すると（ステップ５０８）、通信装置３８１が照会ルータであるか否かをチェックする（ステップ５０９）。通信装置３８１が照会ルータであれば、その離脱メッセージに指定されたマルチキャストグループを宛先とし、応答待ち時間を設定した第１の照会メッセージを、ＬＡＮ送出制御部３８７経由でＬＡＮに送出する（ステップ５１０）。この応答待ち時間としては、一般的には１秒が設定される。【００７９】
通信装置３８１が照会ルータでなければ、照会ルータである他の装置（例えば、マルチキャストルータ３７５）が第１の照会メッセージを送出する（ステップ５１１）。
次に、制御部３８９は、通信装置３８１が照会ルータであるか否かに拘わらず、端末からの応答を監視し（ステップ５１２）、応答待ち時間内に応答がなければ、そのマルチキャストグループに割り当てられたリソースを解放する（ステップ５１３）。【００８０】
リソースの解放においては、ＬＡＮ送出制御部３８７に対して、そのマルチキャストグループ宛のパケットの送出を停止させるとともに、そのマルチキャトグループに割り当てられたＲＦ受信部３８４を解放する。【００８１】
応答待ち時間内に応答があれば、そのマルチキャストグループに対する処理を終了する。したがって、そのマルチキャストグループ宛のパケットの送出は継続され、リソースの解放は行われない。【００８２】
図１８は、最も基本的な動作である、端末における視聴の開始および終了の動作シーケンスを示している。この例では、通信装置３８１に、３個のＲＦ受信部３８４（リソースＲ１〜Ｒ３）が設けられ、通信装置３８１が照会ルータであるものとする。【００８３】
まず、すべてのリソースが空きの状態で（手順６０１）、端末ａにおいてチャンネルＣＨ１の視聴開始要求が発生すると（手順６０２）、端末ａは、チャンネルＣＨ１に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順６０３）。【００８４】
その加入メッセージを受信した通信装置３８１は、処理中のマルチキャストグループがなく（手順６０４）、かつ、空きリソースがあるため（手順６０５）、そのマルチキャストグループ用にリソースＲ１を捕捉する（手順６０６）。【００８５】
これにより、リソースＲ１であるＲＦ受信部３８４は、チャンネルＣＨ１の受信を開始し、ＬＡＮには、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットが送出される。そして、端末ａは、チャンネルＣＨ１の視聴を開始する。【００８６】
次に、端末ａにおいてチャンネルＣＨ１の視聴が終了すると（手順６０７）、端末ａは、チャンネルＣＨ１に対応するマルチキャストグループのアドレスを設定した離脱メッセージを、すべてのマルチキャストルータ宛（アドレス：２２４．０．０．２）に送出する（手順６０８）。【００８７】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータであるため、離脱メッセージに指定されたマルチキャストグループのアドレスおよび応答待ち時間（１秒）を設定した第１の照会メッセージを、そのマルチキャストグループ宛に送出する（手順６０９）。そして、設定した応答待ち時間の間、端末からの応答を監視する。【００８８】
通信装置３８１は、応答待ち時間内にそのマルチキャストグループの端末からの応答がないため、そのマルチキャストグループに対応するリソースＲ１を解放する（手順６１０）。【００８９】
これにより、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ１は空きリソースとなる。
図１９は、２台の端末が同じチャンネルを視聴する場合の動作シーケンスを示している。この例では、図１８の例とは異なり、マルチキャストルータ３７５が照会ルータであるものとする。【００９０】
端末ａがチャンネルＣＨ１の視聴を開始するための手順７０１〜７０６のシーケンスは、図１８の手順６０１〜６０６と同様である。ただし、端末ａが送出するメッセージは、マルチキャストルータ３７５と通信装置３８１の両方で受信される。【００９１】
なお、加入メッセージを受信した照会ルータであるマルチキャストルータ３７５は、そのマルチキャストグループに対する転送処理を開始しても、そのマルチキャストグループ宛のパケットを送出するマルチキャストサーバが存在しないため、転送するパケットを取得できない。あるいは、ＩＰフィルタ等の設定により、そのマルチキャストグループに対する転送処理を行わない。したがって、マルチキャストルータ３７５からは、そのマルチキャストグループ宛のパケットは送出されない。【００９２】
次に、端末ｂにおいてチャンネルＣＨ１の視聴開始要求が発生すると（手順７０７）、端末ｂは、チャンネルＣＨ１に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順７０８）。【００９３】
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループの処理中であるため（手順７０９）、加入メッセージに対する処理を終了する。しかし、ＬＡＮ上には既にチャンネルＣＨ１に対応するマルチキャストグループ宛のパケットが送出されているため、端末ｂは、チャンネルＣＨ１の視聴を開始できる。【００９４】
次に、端末ａにおいてチャンネルＣＨ１の視聴が終了すると（手順７１０）、端末ａは、チャンネルＣＨ１の離脱メッセージをすべてのマルチキャストルータ宛に送出する（手順７１１）。【００９５】
その離脱メッセージを受信したマルチキャストルータ３７５は、自身が照会ルータであるため、第１の照会メッセージをそのマルチキャストグループ宛に送出する（手順７１２）。【００９６】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータではないため、離脱メッセージに対する処理を終了する。また、第１の照会メッセージを受信した通信装置３８１は、その第１の照会メッセージ内に設定された応答待ち時間（１秒）の間、端末からの応答を監視する。【００９７】
第１の照会メッセージを受信した端末ｂは、チャンネルＣＨ１を継続視聴するため、チャンネルＣＨ１に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順７１３）。【００９８】
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループの処理中であるため（手順７１４）、加入メッセージに対する処理を終了する。
応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨ１に対応するマルチキャストグループの端末ｂから応答を受信しているため、リソースＲ１を解放しない（手順７１５）。したがって、そのマルチキャストグループ宛のパケットの送出が継続され、そのマルチキャトグループのために捕捉されているリソースＲ１は解放されない。【００９９】
次に、端末ｂにおいてチャンネルＣＨ１の視聴が終了すると（手順７１６）、端末ｂは、チャンネルＣＨ１の離脱メッセージをすべてのマルチキャストルータ宛に送出する（手順７１７）。【０１００】
その離脱メッセージを受信したマルチキャストルータ３７５は、自身が照会ルータであるため、再び、第１の照会メッセージをそのマルチキャストグループ宛に送出する（手順７１８）。【０１０１】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータではないため、離脱メッセージに対する処理を終了する。また、第１の照会メッセージを受信した通信装置３８１は、その第１の照会メッセージ内に設定された応答待ち時間（１秒）の間、端末からの応答を監視する。【０１０２】
応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨ１に対応するマルチキャストグループの端末から応答を受信していないため、そのマルチキャストグループに対応するリソースＲ１を解放する（手順７１９）。【０１０３】
これにより、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ１は空きリソースとなる。
図２０は、空きリソースがない状態でのチャンネル切り替えおよび新規視聴開始要求のブロックの動作シーケンスを示している。この例では、通信装置３８１が照会ルータであり、端末ａがチャンネルＣＨ１の視聴にリソースＲ１を使用し、端末ｂがチャンネルＣＨｎの視聴にリソースＲ２を使用し、端末ｃがチャンネルＣＨｍの視聴にリソースＲ３を使用しているものとする。【０１０４】
まず、空きリソースがない状態で（手順８０１）、端末ａにおいてチャンネルＣＨ１からチャンネルＣＨ２への切り替え要求が発生すると（手順８０２）、端末ａは、視聴を終了するチャンネルＣＨ１に対応するマルチキャストグループのアドレスを設定した離脱メッセージを、すべてのマルチキャストルータ宛に送出する（手順８０３）。【０１０５】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータであるため、第１の照会メッセージをそのマルチキャストグループ宛に送出し（手順８０４）、第１の照会メッセージに設定した応答待ち時間（１秒）の間、端末からの応答を監視する。【０１０６】
次に、端末ａは、視聴を開始するチャンネルＣＨ２に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順８０５）。
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが処理中ではなく、かつ、空きリソースがないため（手順８０６）、一定時間（１秒＋α）の空きリソース待ちを開始する（手順８０７）。【０１０７】
通信装置３８１は、第１の照会メッセージの応答待ち時間内にそのマルチキャストグループの端末からの応答がないため、そのマルチキャストグループに対応するリソースＲ１を解放する（手順８０８）。【０１０８】
これにより、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ１は空きリソースとなる。
次に、チャンネルＣＨ２のための空きリソース待ちをしていた通信装置３８１は、リソースＲ１が空きリソースとなったため、そのリソースをチャンネルＣＨ２に対応するマルチキャストグループ用に捕捉する（手順８０９）。【０１０９】
これにより、リソースＲ１であるＲＦ受信部３８４は、チャンネルＣＨ２の受信を開始し、ＬＡＮには、チャンネルＣＨ２に対応するマルチキャストグループ宛のパケットが送出される。そして、端末ａは、チャンネルＣＨ２の視聴を開始する。その結果、再び、空きリソースがない状態になる。【０１１０】
次に、端末ｄにおいて新規にチャンネルＣＨ３の視聴開始要求が発生すると（手順８１０）、端末ｄは、チャンネルＣＨ３に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順８１１）。【０１１１】
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが処理中ではなく、かつ、空きリソースがないため（手順８１２）、一定時間（１秒＋α）の空きリソース待ちを開始する（手順８１３）。しかし、一定時間内にリソースが解放されないため、端末ｄからの要求をブロックし（手順８１４）、その加入メッセージに対する処理を終了する。【０１１２】
この動作シーケンスによれば、空きリソースがなくても、直ちに加入メッセージがブロックされることがないため、端末から前リソース解放のための離脱メッセージと新リソース確保のための加入メッセージを連続して送出することが可能になる。【０１１３】
次に、図２１から図２３までを参照しながら、図１４の（ａ）、（ｄ）、（ｃ）、および（ｅ）の処理を組み合わせた通信リソース管理処理について説明する。
図２１は、この通信リソース管理処理のフローチャートである。このうち、ステップ９０１〜９０７の処理は、図１７のステップ５０１〜５０７と同様である。ただし、ステップ９０２において、制御部３８９は、加入メッセージ内のマルチキャストグループのアドレスが、受信処理中または空き待ち状態のマルチキャストグループのアドレスであるか否かをチェックする。そして、それが受信処理中または空き待ち状態のマルチキャストグループのアドレスであれば、その加入メッセージに対する処理を終了する。【０１１４】
ステップ９０１〜９０７の処理と並行して、制御部３８９は、通信装置３８１が照会ルータであるか否かをチェックする（ステップ９１１）。通信装置３８１が照会ルータであれば、すべてのマルチキャストグループ（アドレス：２２４．０．０．１）を宛先とし、応答待ち時間を設定した第２の照会メッセージを、定期的にＬＡＮに送出する（ステップ９１２）。この応答待ち時間としては、一般的には１０秒が設定され、第２の照会メッセージは、一般的には１２５秒間隔で送出される。【０１１５】
通信装置３８１が照会ルータでなければ、照会ルータである他の装置（例えば、マルチキャストルータ３７５）が定期的に第２の照会メッセージを送出する（ステップ９１３）。【０１１６】
次に、制御部３８９は、通信装置３８１が照会ルータであるか否かに拘わらず、端末からの応答を監視し（ステップ９１４）、応答待ち時間内に応答がなければ、応答がないマルチキャストグループに割り当てられたリソースを解放する（ステップ９１５）。【０１１７】
応答待ち時間内に応答があれば、その応答を送信した端末のマルチキャストグループに対する処理を終了する。したがって、そのマルチキャストグループ宛のパケットの送出は継続され、対応するリソースの解放は行われない。【０１１８】
ステップ９０３において空きリソースがなければ、ステップ９０５および９０６の処理と並行して、制御部３８９は、通信装置３８１が照会ルータであるか否かに拘わらず、すべてのマルチキャストグループを宛先とし、応答待ち時間を設定した第２の照会メッセージを、ＬＡＮ送出制御部３８７経由でＬＡＮに送出する（ステップ９０８）。この応答待ち時間としては、一般的な１０秒ではなく、応答時間を考慮して１秒が設定される。【０１１９】
次に、端末からの応答を監視し（ステップ９０９）、応答待ち時間内に応答がなければ、応答がないマルチキャストグループに割り当てられたリソースを解放する（ステップ９１０）。【０１２０】
応答待ち時間内に応答があれば、その応答を送信した端末のマルチキャストグループに対する処理を終了する。したがって、そのマルチキャストグループ宛のパケットの送出は継続され、対応するリソースの解放は行われない。【０１２１】
なお、（ａ）、（ｄ）、（ｃ）、および（ｅ）の処理を組み合わせる代わりに、（ａ）、（ｄ）、および（ｅ）の処理を組み合わせて、通信リソース管理を行うことも可能である。【０１２２】
図２２は、空きリソースがない状態でのチャンネル切り替えの動作シーケンスを示している。この例では、図２０と同様に、通信装置３８１が照会ルータであり、端末ａがチャンネルＣＨ１の視聴にリソースＲ１を使用し、端末ｂがチャンネルＣＨｎの視聴にリソースＲ２を使用し、端末ｃがチャンネルＣＨｍの視聴にリソースＲ３を使用しているものとする。【０１２３】
まず、空きリソースがない状態で（手順１００１）、通信装置３８１は、定期的に（１２５秒間隔で）すべてのマルチキャストグループを宛先とし、応答待ち時間（１０秒）を設定した第２の照会メッセージを送出し（手順１００２、１０２４）、応答待ち時間の間、端末からの応答を監視する。【０１２４】
第２の照会メッセージを受信した端末ａ、ｂ、およびｃは、それぞれ、チャンネルＣＨ１、ＣＨｎ、およびＣＨｍを継続視聴するため、それぞれのチャンネルに対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順１００３、１００５、１００７）。【０１２５】
それぞれの加入メッセージを受信した通信装置３８１は、すべてのマルチキャストグループが処理中であるため（手順１００４、１００６、１００８）、それらの加入メッセージに対する処理を終了する。【０１２６】
第２の照会メッセージに対する応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨ１、ＣＨｎ、およびＣＨｍのそれぞれに対応するマルチキャストグループの端末から応答を受信しているため、それぞれのリソースを解放しない（手順１０１４）。したがって、それらのマルチキャストグループ宛のパケットの送出が継続され、それらのマルチキャトグループのために捕捉されているリソースＲ１〜Ｒ３は解放されない。【０１２７】
チャンネルＣＨ１の加入メッセージを送出した後、端末ａにおいてチャンネルＣＨ１からチャンネルＣＨ２への切り替え要求が発生すると（手順１００９）、端末ａは、視聴を開始するチャンネルＣＨ２に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順１０１０）。【０１２８】
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが処理中ではなく、かつ、空きリソースがないため（手順１０１１）、一定時間（１秒＋α）の空きリソース待ちを開始する（手順１０１２）。【０１２９】
また、これと並行して、すべてのマルチキャストグループを宛先とし、応答待ち時間（１秒）を設定した第２の照会メッセージを送出し（手順１０１３）、応答待ち時間の間、端末からの応答を監視する。【０１３０】
第２の照会メッセージを受信した端末ａ、ｂ、およびｃは、それぞれ、チャンネルＣＨ２、ＣＨｎ、およびＣＨｍを継続視聴するため、それぞれのチャンネルの加入メッセージを送出する（手順１０１５、１０１７、１０１９）。【０１３１】
チャンネルＣＨｎおよびＣＨｍの加入メッセージを受信した通信装置３８１は、それらのマルチキャストグループが処理中であるため（手順１０１６、１０１８）、それらの加入メッセージに対する処理を終了する。【０１３２】
チャンネルＣＨ２の加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが空き待ち状態であるため（手順１０２１）、その加入メッセージに対する処理を終了する。【０１３３】
第２の照会メッセージに対する応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨｎおよびＣＨｍのそれぞれに対応するマルチキャストグループの端末から応答を受信しているため、それらのマルチキャストグループ宛のパケットの送出を継続し、それらのマルチキャトグループに割り当てられたリソースＲ２およびＲ３を解放しない。【０１３４】
しかし、チャンネルＣＨ１に対応するマルチキャストグループの端末からの応答がないため、そのマルチキャストグループに対応するリソースＲ１を解放する（手順１０２２）。【０１３５】
これにより、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ１は空きリソースとなる。
次に、チャンネルＣＨ２のための空きリソース待ちをしていた通信装置３８１は、リソースＲ１が空きリソースとなったため、そのリソースをチャンネルＣＨ２に対応するマルチキャストグループ用に捕捉する（手順１０２３）。【０１３６】
これにより、リソースＲ１であるＲＦ受信部３８４は、チャンネルＣＨ２の受信を開始し、ＬＡＮには、チャンネルＣＨ２に対応するマルチキャストグループ宛のパケットが送出される。そして、端末ａは、チャンネルＣＨ２の視聴を開始する。その結果、再び、空きリソースがない状態になる。【０１３７】
この動作シーケンスによれば、空きリソースがなくても、直ちに加入メッセージがブロックされることがないため、チャンネル切り替え時において、端末から新リソース確保のための加入メッセージをいつでも送出することが可能になる。また、チャンネル切り替えの待ち合せ時間は、最大１３５秒から約１秒に短縮される。【０１３８】
図２３は、マルチキャストルータ３７５が照会ルータである場合のチャンネル切り替えの動作シーケンスを示している。この動作シーケンスは、定期的に送出される第２の照会メッセージの送信元がマルチキャストルータ３７５である点を除いて、図２２と同様である。手順１１０１〜１１２４は、図２２の手順１００１〜１０２４にそれぞれ対応している。【０１３９】
次に、図２４から図２６までを参照しながら、図１４の（ａ）、（ｄ）、（ｂ）、および（ｅ）の処理を組み合わせた通信リソース管理処理について説明する。
図２４は、この通信リソース管理処理のフローチャートである。このうち、ステップ１２０１〜１２１０の処理は、図２１のステップ９０１〜９１０と同様であり、ステップ１２１１〜１２１６の処理は、図１７のステップ５０８〜５１３と同様である。【０１４０】
ただし、ステップ１２０８において、制御部３８９は、ステップ９０８と同様の第２の照会メッセージ、または複数個の第１の照会メッセージを送出する。これらの第１の照会メッセージには、リソースを使用中であるそれぞれのマルチキャストグループが宛先として設定され、応答待ち時間も設定される。この応答待ち時間としては、一般的には１秒が設定される。第１の照会メッセージの応答待ち時間内に応答がなければ、そのマルチキャストグループに割り当てられたリソースが解放される。【０１４１】
なお、（ａ）、（ｄ）、（ｂ）、および（ｅ）の処理を組み合わせる代わりに、（ａ）、（ｄ）、および（ｅ）の処理を組み合わせて、通信リソース管理を行うことも可能である。【０１４２】
図２５は、空きリソースがない状態で端末が電源断により離脱メッセージを送出せずに受信を終了し、直後に別の端末が新規に視聴開始を要求した場合の動作シーケンスを示している。この例では、通信装置３８１が照会ルータであり、端末ａがチャンネルＣＨ１の視聴にリソースＲ１を使用し、端末ｂがチャンネルＣＨｎの視聴にリソースＲ２を使用し、端末ｃがチャンネルＣＨｍの視聴にリソースＲ３を使用しているものとする。【０１４３】
まず、空きリソースがない状態で（手順１３０１）、端末ｂの電源が断になり（手順１３０２）、端末ｂは、チャンネルＣＨｎの離脱メッセージを送出せずに、受信を終了する（手順１３０３）。【０１４４】
次に、端末ｄにおいて新規にチャンネルＣＨ３の視聴開始要求が発生すると（手順１３０４）、端末ｄは、チャンネルＣＨ３に対応するマルチキャストグループのアドレスを設定した加入メッセージを送出する（手順１３０５）。【０１４５】
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが処理中ではなく、かつ、空きリソースがないため（手順１３０６）、一定時間（１秒＋α）の空きリソース待ちを開始する（手順１３０７）。【０１４６】
また、これと並行して、リソース使用中のチャンネルＣＨ１、ＣＨｎ、およびＣＨｍにそれぞれ対応する３個のマルチキャストグループを宛先とし、応答待ち時間（１秒）を設定した３個の第１の照会メッセージを送出し（手順１３０８、１３０９、１３１０）、応答待ち時間の間、端末からの応答を監視する。【０１４７】
第１の照会メッセージを受信した端末ａおよびｃは、それぞれ、チャンネルＣＨ１およびＣＨｍを継続視聴するため、それぞれのチャンネルの加入メッセージを送出する（手順１３１１、１３１３）。【０１４８】
それらの加入メッセージを受信した通信装置３８１は、それらのマルチキャストグループが処理中であるため（手順１３１２、１３１４）、それらの加入メッセージに対する処理を終了する。【０１４９】
チャンネルＣＨ１に対応するマルチキャストグループ宛の第１の照会メッセージに対する応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨ１に対応するマルチキャストグループの端末ａから応答を受信しているため、リソースＲ１を解放しない（手順１３１５）。したがって、そのマルチキャストグループ宛のパケットの送出が継続され、そのマルチキャトグループのために捕捉されているリソースＲ１は解放されない。【０１５０】
チャンネルＣＨｍに対応するマルチキャストグループ宛の第１の照会メッセージに対する応答待ち時間が経過すると、通信装置３８１は、この時間内にチャンネルＣＨｍに対応するマルチキャストグループの端末ｃから応答を受信しているため、リソースＲ３を解放しない（手順１３１８）。したがって、そのマルチキャストグループ宛のパケットの送出が継続され、そのマルチキャトグループのために捕捉されているリソースＲ３は解放されない。【０１５１】
チャンネルＣＨｎに対応するマルチキャストグループ宛の第１の照会メッセージに対する応答待ち時間が経過すると、通信装置３８１は、この時間内にそのマルチキャストグループの端末からの応答がないため、そのマルチキャストグループに対応するリソースＲ２を解放する（手順１３１６）。【０１５２】
これにより、チャンネルＣＨｎに対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ２は空きリソースとなる。
次に、チャンネルＣＨ３のための空きリソース待ちをしていた通信装置３８１は、リソースＲ２が空きリソースとなったため、そのリソースをチャンネルＣＨ３に対応するマルチキャストグループ用に捕捉する（手順１３１７）。【０１５３】
これにより、リソースＲ２であるＲＦ受信部３８４は、チャンネルＣＨ３の受信を開始し、ＬＡＮには、チャンネルＣＨ３に対応するマルチキャストグループ宛のパケットが送出される。そして、端末ｄは、チャンネルＣＨ３の視聴を開始する。その結果、再び、空きリソースがない状態になる。【０１５４】
なお、通信装置３８１は、それぞれの第１の照会メッセージに対して応答待ちを行う代わりに、最後に送出した第１の照会メッセージのみに対して応答待ちを行ってもかまわない。この場合、最後の第１の照会メッセージに対する応答待ち時間内に応答がなければ、応答がないマルチキャストグループに割り当てられたリソースを解放する。【０１５５】
この動作シーケンスによれば、電源断等により離脱メッセージが送出されず、捕捉されたままの状態になっているリソースの解放を促進し、そのリソースを新規なリソース取得要求に対して割り当てることが可能になる。【０１５６】
図２６は、図２５の動作シーケンスにおいて、第１の照会メッセージの代わりに第２の照会メッセージを使用する場合の動作シーケンスを示している。ただし、この例では、マルチキャストルータ３７５が照会ルータであるものとする。手順１４０１〜１４０７、１４０９〜１４１２、１４１６、および１４１７は、図２５の手順１３０１〜１３０７、１３１１〜１３１４、１３１６、および１３１７にそれぞれ対応している。【０１５７】
通信装置３８１は、手順１４０７の空きリソース待ちと並行して、第２の照会メッセージを送出する（手順１４０８）。第２の照会メッセージは１つであり、その応答待ち時間も１つであり、すべてのマルチキャストグループが照会対象になる。【０１５８】
したがって、端末ａおよびｃに加えて、端末ｄも、チャンネルＣＨ３を継続視聴するため、チャンネルＣＨ３の加入メッセージを送出する（手順１４１３）。
その加入メッセージを受信した通信装置３８１は、そのマルチキャストグループが空き待ち状態であるため（手順１４１５）、その加入メッセージに対する処理を終了する。【０１５９】
ところで、図１６のテーブルでは、放送波の周波数とマルチキャストグループアドレス（チャンネル）が１対１の対応関係にあるが、１つの周波数を用いて複数のチャンネルの放送を行うことも可能である。この場合、テーブル３８８には、各周波数に対応する複数のマルチキャストグループアドレスが登録される。【０１６０】
図２７は、このような通信システムにおける通信リソース管理処理のフローチャートである。このうち、ステップ１５０１、１５０２、１５０５〜１５１１、および１５１３〜１５１７の処理は、図２４のステップ１２０１〜１２０９および１２１１〜１２１５と同様であり、ステップ１５１９〜１５２２の処理は、図２１のステップ９１１〜９１４と同様である。ただし、図２７のリソース捕捉処理（ａ）のステップ１５０２とステップ１５０５の間には、リソース多重割り付け処理（ｆ）が挿入される。【０１６１】
ステップ１５０２において、加入メッセージ内のマルチキャストグループアドレスが、受信処理中または空き待ち状態のマルチキャストグループのアドレスではない場合に、リソース多重割り付け処理（ｆ）が行われる。【０１６２】
この場合、制御部３８９は、加入メッセージ内のマルチキャストグループアドレスに対応する受信周波数をテーブル３８８から検索し、その受信周波数が受信処理中の周波数と同一か否かを確認する（ステップ１５０３）。得られた周波数が受信処理中の周波数であれば、リソース多重割り付けを行う（ステップ１５０４）。この処理では、ＬＡＮ送出制御部３８７に対して、そのマルチキャストグループ宛のパケットの送出が許可される。得られた周波数が受信処理中の周波数でなければ、ステップ１５０５以降の処理を行う。【０１６３】
ステップ１５０６においては、まず、空きのＲＦ受信部３８４をそのマルチキャストグループに割り当る（ステップ１５３１）。次に、テーブル３８８からそのマルチキャストグループのアドレスに対応する受信周波数を検索して、ＲＦ受信部３８４に設定する（ステップ１５３２）。そして、そのマルチキャストグループ宛のパケットの送出を、ＬＡＮ送出制御部３８７に対して許可する（ステップ１５３３）。【０１６４】
ステップ１５１２においては、まず、応答がないマルチキャストグループ宛のパケットの送出を停止するように、ＬＡＮ送出制御部３８７に対して指示する（ステップ１５４１）。次に、テーブル３８８を参照して、そのマルチキャストグループと同じ受信周波数を使用しているすべてのマルチキャストグループのアドレスを取得し、ＬＡＮ送出制御部３８７において、それらのすべてのマルチキャストグループ宛のパケットの送出が停止されているか否かをチェックする（ステップ１５４２）。【０１６５】
そして、すべてのマルチキャストグループ宛のパケットの送出が停止されていれば、それらのマルチキャストグループのために捕捉されたＲＦ受信部３８４を解放する（ステップ１５４３）。それらのマルチキャストグループのいずれか１つでも、パケットの送出が停止されていない場合は、そのＲＦ受信部３８４を解放せずに、処理を終了する。【０１６６】
ステップ１５１８内のステップ１５５１〜１５５３の処理、および、ステップ１５２３内のステップ１５６１〜１５６３の処理についても、ステップ１５４１〜１５４３と同様である。【０１６７】
図２８は、同一周波数に複数のチャンネルが収容されており、２台の端末がそれぞれのチャンネルを視聴する場合の動作シーケンスを示している。この例では、通信装置３８１が照会ルータであり、１つの周波数にチャンネルＣＨ１およびＣＨ２が収容されているものとする。【０１６８】
まず、すべてのリソースが空きの状態で（手順１６０１）、端末ａにおいてチャンネルＣＨ１の視聴開始要求が発生すると（手順１６０２）、端末ａは、チャンネルＣＨ１の加入メッセージを送出する（手順１６０３）。【０１６９】
その加入メッセージを受信した通信装置３８１は、チャンネルＣＨ１のマルチキャストグループおよび周波数が処理中ではなく、かつ、空きリソースがあるため（手順１６０４）、そのマルチキャストグループ用にリソースＲ１を捕捉する（手順１６０５）。【０１７０】
チャンネルＣＨ１の周波数には、チャンネルＣＨ１およびＣＨ２が収容されているため、リソースＲ１であるＲＦ受信部３８４は、これらのチャンネルの受信を開始する。しかし、ＬＡＮには、チャンネルＣＨ１に対応するマルチキャストグループ宛のパケットのみが送出される（手順１６０６）。これにより、端末ａは、チャンネルＣＨ１の視聴を開始する。【０１７１】
次に、端末ｂにおいてチャンネルＣＨ２の視聴開始要求が発生すると（手順１６０７）、端末ｂは、チャンネルＣＨ２の加入メッセージを送出する（手順１６０８）。
その加入メッセージを受信した通信装置３８１は、チャンネルＣＨ２のマルチキャストグループが処理中ではなく、かつ、チャンネルＣＨ２の周波数が処理中であるため（手順１６０９）、そのマルチキャストグループ宛のパケットの送出を開始する（手順１６１０）。【０１７２】
これにより、ＬＡＮには、チャンネルＣＨ１とともにチャンネルＣＨ２のパケットが送出され、端末ｂは、チャンネルＣＨ２の視聴を開始する。
次に、端末ａにおいてチャンネルＣＨ１の視聴が終了すると（手順１６１１）、端末ａは、チャンネルＣＨ１の離脱メッセージを、すべてのマルチキャストルータ宛に送出する（手順１６１２）。【０１７３】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータであるため、第１の照会メッセージをそのマルチキャストグループ宛に送出し（手順１６１３）、第１の照会メッセージに設定した応答待ち時間（１秒）の間、端末からの応答を監視する。【０１７４】
通信装置３８１は、応答待ち時間内にそのマルチキャストグループの端末からの応答がないため、そのマルチキャストグループ宛のパケットの送出を停止する（手順１６１４）。しかし、同一周波数を使用するチャンネルＣＨ２のパケットが送出中であり（手順１６１５）、チャンネルＣＨ１のために捕捉されたリソースＲ１がチャンネルＣＨ２のために使用中であるため、リソースＲ１を解放しない（手順１６１６）。【０１７５】
次に、端末ｂにおいてチャンネルＣＨ２の視聴が終了すると（手順１６１７）、端末ｂは、チャンネルＣＨ２の離脱メッセージを、すべてのマルチキャストルータ宛に送出する（手順１６１８）。【０１７６】
その離脱メッセージを受信した通信装置３８１は、自身が照会ルータであるため、第１の照会メッセージをそのマルチキャストグループ宛に送出し（手順１６１９）、第１の照会メッセージに設定した応答待ち時間（１秒）の間、端末からの応答を監視する。【０１７７】
通信装置３８１は、応答待ち時間内にそのマルチキャストグループの端末からの応答がないため、そのマルチキャストグループ宛のパケットの送出を停止する（手順１６２０）。また、同一周波数を使用するすべてのチャンネルのパケット送出が停止されており（手順１６２１）、リソースＲ１が他で使用されていないため、リソースＲ１を解放する（手順１６２２）。【０１７８】
これにより、チャンネルＣＨ２に対応するマルチキャストグループ宛のパケットのＬＡＮへの送出が停止され、リソースＲ１は空きリソースとなる。
この動作シーケンスによれば、同一周波数に複数のチャンネルが収容されている場合に、同一のＲＦ受信部３８４を複数のチャンネルのために同時に使用することが可能になる。【０１７９】
以上の実施形態では、通信装置３８１のＲＦ受信部３８４を通信リソースとして管理しているが、管理対象はこれに限定されるものではない。例えば、ＬＡＮにおけるＱｏＳ（Quality of Service）による帯域確保のためにブロックが生ずるような通信リソース（帯域リソース）や、通信装置３８１の変換部３８５等の有限なリソースに対しても、同様の通信リソース管理が適用される。【０１８０】
また、通信装置と端末の間で送受信されるメッセージは、上述した実施形態においてチャンネル選択に使用されるＩＰｖ４（Internet Protocol Version 4 ）のＩＧＭＰメッセージに限定されるものではない。ＩＧＭＰの代わりに、例えば、ＩＰｖ６（Internet Protocol Version 6 ）のＭＬＤ（Multicast Listener Discovery：ＲＦＣ２７１０）やＲＳＶＰ（Resource Reservation Protocol：ＲＦＣ２２０５）を用いてもよい。ＲＳＶＰを用いた場合、図１４のリソース取得要求、リソース解放要求、およびリソース継続使用確認は、それぞれ、Ｒｅｓｖメッセージ、ＲｅｓｖＴｅａｒメッセージ、およびＰＡＴＨメッセージに対応する。
【図１】
2008152677.tif 000003
【図２】
2008152677.tif 000004
【図３】
2008152677.tif 000005
【図４】
2008152677.tif 000006
【図５】
2008152677.tif 000007
【図６】
2008152677.tif 000008
【図７】
2008152677.tif 000009
【図８】
2008152677.tif 000010
【図９】
2008152677.tif 000011
【図１０】
2008152677.tif 000012
【図１１】
2008152677.tif 000013
【図１２】
2008152677.tif 000014
【図１３】
2008152677.tif 000015
【図１４】
2008152677.tif 000016
【図１５】
2008152677.tif 000017
【図１６】
2008152677.tif 000018
【図１７】
2008152677.tif 000019
【図１８】
2008152677.tif 000020
【図１９】
2008152677.tif 000021
【図２０】
2008152677.tif 000022
【図２１】
2008152677.tif 000023
【図２２】
2008152677.tif 000024
【図２３】
2008152677.tif 000025
【図２４】
2008152677.tif 000026
【図２５】
2008152677.tif 000027
【図２６】
2008152677.tif 000028
【図２７】
2008152677.tif 000029
【図２８】
2008152677.tif 000030
【手続補正書】
【提出日】平成21年7月27日(2009.7.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
放送信号を受信して複数の端末に送信する通信装置であって、
前記放送信号の受信または送信のために使用される複数の通信リソースと、
前記複数の通信リソースのうち、使用されなくなった通信リソースを解放するリソース解放手段と、
前記複数の端末の１つからリソース取得要求を受信する受信手段と、
前記リソース取得要求に応じて空き通信リソースがあるか否かをチェックし、該リソース取得要求に対して空き通信リソースを割り当てるリソース割り当て手段と、
前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留し、使用中の通信リソースの解放を待ち合せる空き待ち手段と
を備えることを特徴とする通信装置。
【請求項２】
前記空き通信リソースがない場合に、通信リソースを使用中の端末に対してリソース継続使用確認を送信する送信手段をさらに備え、前記リソース解放手段は、該リソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項１記載の通信装置。
【請求項３】
前記リソース解放手段は、前記通信リソースを使用中の端末に対して定期的に送信される別のリソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項２記載の通信装置。
【請求項４】
前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信される別のリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項２記載の通信装置。
【請求項５】
前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信されるリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項１記載の通信装置。
【請求項６】
放送信号を受信して複数の端末に送信する通信装置における通信リソース管理方法であって、
前記複数の端末の１つからリソース取得要求を受信し、
前記リソース取得要求に応じて、前記放送信号の受信または送信のために使用される複数の通信リソースの中に空き通信リソースがあるか否かをチェックし、
前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留して、使用中の通信リソースの解放を待ち合せ、
前記複数の通信リソースのうち、使用されなくなった通信リソースを解放し、
保留されているリソース取得要求に対して、解放された通信リソースを割り当てる
ことを特徴とする通信リソース管理方法。
【国際調査報告】
2008152677.tif 000031
2008152677.tif 000032
2008152677.tif 000033