JP4764509B2 - 通信装置および通信リソース管理方法 - Google Patents

通信装置および通信リソース管理方法 Download PDF

Info

Publication number
JP4764509B2
JP4764509B2 JP2009519063A JP2009519063A JP4764509B2 JP 4764509 B2 JP4764509 B2 JP 4764509B2 JP 2009519063 A JP2009519063 A JP 2009519063A JP 2009519063 A JP2009519063 A JP 2009519063A JP 4764509 B2 JP4764509 B2 JP 4764509B2
Authority
JP
Japan
Prior art keywords
resource
communication
terminal
multicast group
message
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.)
Expired - Fee Related
Application number
JP2009519063A
Other languages
English (en)
Other versions
JPWO2008152677A1 (ja
Inventor
隆哉 山本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2008152677A1 publication Critical patent/JPWO2008152677A1/ja
Application granted granted Critical
Publication of JP4764509B2 publication Critical patent/JP4764509B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Transceivers (AREA)

Description

本発明は、放送信号を受信して、ＩＰＴＶ（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：ＲＦＣ２２０５）を用いてもよい。ＲＳＶＰを用いた場合、図１４のリソース取得要求、リソース解放要求、およびリソース継続使用確認は、それぞれ、Ｒｅｓｖメッセージ、ＲｅｓｖＴｅａｒメッセージ、およびＰＡＴＨメッセージに対応する。

Claims (6)

  1. 放送信号を受信して複数の端末に送信する通信装置であって、
    前記放送信号の受信または送信のために使用される複数の通信リソースと、
    前記複数の通信リソースのうち、使用されなくなった通信リソースを解放するリソース解放手段と、
    前記複数の端末の１つからリソース取得要求を受信する受信手段と、
    前記リソース取得要求により指定されるマルチキャストグループが、受信処理中又は通信リソースの空き待ち状態のマルチキャストグループではない場合に、空き通信リソースがあるか否かをチェックし、該リソース取得要求により指定されるマルチキャストグループに対して空き通信リソースを割り当てるリソース割り当て手段と、
    前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留し、使用中の通信リソースの解放を待ち合せる空き待ち手段と
    を備えることを特徴とする通信装置。
  2. 前記空き通信リソースがない場合に、通信リソースを使用中の端末に対してリソース継続使用確認を送信する送信手段をさらに備え、前記リソース解放手段は、該リソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項１記載の通信装置。
  3. 前記リソース解放手段は、前記通信リソースを使用中の端末に対して定期的に送信される別のリソース継続使用確認に対する応答がないとき、使用中の通信リソースを解放することを特徴とする請求項２記載の通信装置。
  4. 前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信される別のリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項２記載の通信装置。
  5. 前記受信手段は、前記複数の端末の１つからリソース解放要求を受信し、前記リソース解放手段は、該リソース解放要求により指定される通信リソースを使用中の端末に対して送信されるリソース継続使用確認に対する応答がないとき、該リソース解放要求により指定される通信リソースを解放することを特徴とする請求項１記載の通信装置。
  6. 放送信号を受信して複数の端末に送信する通信装置における通信リソース管理方法であって、
    前記複数の端末の１つからリソース取得要求を受信し、
    前記リソース取得要求により指定されるマルチキャストグループが、受信処理中又は通信リソースの空き待ち状態のマルチキャストグループではない場合に、前記放送信号の受信または送信のために使用される複数の通信リソースの中に空き通信リソースがあるか否かをチェックし、
    前記複数の通信リソースが使用中であり、前記空き通信リソースがない場合に、前記リソース取得要求を一時的に保留して、使用中の通信リソースの解放を待ち合せ、
    前記複数の通信リソースのうち、使用されなくなった通信リソースを解放し、
    保留されているリソース取得要求により指定されるマルチキャストグループに対して、解放された通信リソースを割り当てる
    ことを特徴とする通信リソース管理方法。
JP2009519063A 2007-06-12 2007-06-12 通信装置および通信リソース管理方法 Expired - Fee Related JP4764509B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2007/000620 WO2008152677A1 (ja) 2007-06-12 2007-06-12 通信装置および通信リソース管理方法

Publications (2)

Publication Number Publication Date
JPWO2008152677A1 JPWO2008152677A1 (ja) 2010-08-26
JP4764509B2 true JP4764509B2 (ja) 2011-09-07

Family

ID=40129295

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009519063A Expired - Fee Related JP4764509B2 (ja) 2007-06-12 2007-06-12 通信装置および通信リソース管理方法

Country Status (3)

Country Link
US (1) US8717886B2 (ja)
JP (1) JP4764509B2 (ja)
WO (1) WO2008152677A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4987834B2 (ja) * 2008-10-17 2012-07-25 日本電信電話株式会社 マルチキャスト制御ルータおよびマルチキャスト制御方法
KR101585010B1 (ko) * 2009-03-11 2016-01-14 삼성전자주식회사 무선 인터넷 프로토콜 텔레비전 시스템에서 채널 대역 할당방법 및 이를 위한 시스템
US8937858B2 (en) * 2010-09-27 2015-01-20 Telefonaktiebolaget L M Ericsson (Publ) Reducing access network congestion caused by oversubscription of multicast groups
US8811254B2 (en) * 2010-12-08 2014-08-19 Fujitsu Limited Dynamic connection admission control to enforce service level agreements in multicast networks
EP2533453B1 (en) * 2011-06-10 2015-08-19 Sony Corporation Apparatus and method for transmitting and receiving in a multi carrier transmission system
US9177022B2 (en) 2011-11-02 2015-11-03 Microsoft Technology Licensing, Llc User pipeline configuration for rule-based query transformation, generation and result display
US9189563B2 (en) 2011-11-02 2015-11-17 Microsoft Technology Licensing, Llc Inheritance of rules across hierarchical levels
US9558274B2 (en) * 2011-11-02 2017-01-31 Microsoft Technology Licensing, Llc Routing query results
US9843682B2 (en) * 2014-07-21 2017-12-12 Motorola Solutions, Inc. Method and apparatus for subgroup call to group members missing a group call
CN105847899B (zh) * 2016-05-19 2019-03-19 深圳创维数字技术有限公司 一种接收epg信息的方法及装置
CN112118331B (zh) * 2020-09-22 2023-01-10 贵州电网有限责任公司 网络资源释放采集方法、装置、系统和电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0950380A (ja) * 1995-08-04 1997-02-18 Toshiba Corp 通信システム
JP2002057721A (ja) * 2000-08-11 2002-02-22 Konica Corp 遠隔管理システム、管理ゲート装置及び管理装置
JP2002354450A (ja) * 2001-05-28 2002-12-06 Matsushita Electric Ind Co Ltd Ｓｔｂ遠隔操作システム
JP2003204355A (ja) * 2001-10-29 2003-07-18 Japan Cablenet Ltd Ｉｐマルチキャスト中継システム
WO2006101179A1 (ja) * 2005-03-23 2006-09-28 Pioneer Corporation 伝送システム、送信側伝送器、伝送方法、及びコンピュータプログラム
JP2007043310A (ja) * 2005-08-01 2007-02-15 Softbank Mobile Corp 移動通信システムにおける輻輳制御方法および輻輳制御装置

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5887136A (en) 1995-08-04 1999-03-23 Kabushiki Kaisha Toshiba Communication system and communication control method for the same
US6751221B1 (en) 1996-10-04 2004-06-15 Kabushiki Kaisha Toshiba Data transmitting node and network inter-connection node suitable for home network environment
US6523696B1 (en) 1996-10-15 2003-02-25 Kabushiki Kaisha Toshiba Communication control device for realizing uniform service providing environment
US7383341B1 (en) 1996-10-15 2008-06-03 Kabushiki Kaisha Toshiba Data transfer control device, relay device and control device suitable for home network environment
JP4003989B2 (ja) 1997-03-06 2007-11-07 株式会社東芝 通信装置および通信方法
JPH11225169A (ja) 1998-02-06 1999-08-17 Hitachi Ltd 通信網制御装置
JP2001094519A (ja) 1999-09-24 2001-04-06 Ntt Data Corp ディジタル放送受信方法及び装置
JP2002009824A (ja) 2000-06-26 2002-01-11 Matsushita Electric Ind Co Ltd 応答メッセージの帯域予約方法
JP2002237844A (ja) 2001-02-09 2002-08-23 Mcm Japan Kk 画像配信スイッチシステム及び画像配信スイッチ装置及び画像配信方法
US20020199200A1 (en) * 2001-05-25 2002-12-26 N2 Broadband, Inc. System and method for scheduling the distribution of assets from multiple asset providers to multiple receivers
TW578413B (en) * 2001-08-16 2004-03-01 Flarion Technologies Inc Methods and apparatus for controlling IP applications during resource shortages
US7155235B2 (en) * 2002-02-14 2006-12-26 Qualcomm, Incorporated Method and apparatus for conserving home agent resources in mobile IP deployment
KR100687707B1 (ko) 2004-02-12 2007-02-27 한국전자통신연구원 통신 방송 융합 액세스 시스템과 그 방법
JP2006166317A (ja) 2004-12-10 2006-06-22 Nippon Telegr & Teleph Corp <Ntt> 無線通信端末へのコンテンツ配信方法及びシステム
US20080155101A1 (en) * 2006-12-21 2008-06-26 Cisco Technology, Inc. Reserving resources for data streams in a communication network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0950380A (ja) * 1995-08-04 1997-02-18 Toshiba Corp 通信システム
JP2002057721A (ja) * 2000-08-11 2002-02-22 Konica Corp 遠隔管理システム、管理ゲート装置及び管理装置
JP2002354450A (ja) * 2001-05-28 2002-12-06 Matsushita Electric Ind Co Ltd Ｓｔｂ遠隔操作システム
JP2003204355A (ja) * 2001-10-29 2003-07-18 Japan Cablenet Ltd Ｉｐマルチキャスト中継システム
WO2006101179A1 (ja) * 2005-03-23 2006-09-28 Pioneer Corporation 伝送システム、送信側伝送器、伝送方法、及びコンピュータプログラム
JP2007043310A (ja) * 2005-08-01 2007-02-15 Softbank Mobile Corp 移動通信システムにおける輻輳制御方法および輻輳制御装置

Also Published As

Publication number Publication date
US8717886B2 (en) 2014-05-06
JPWO2008152677A1 (ja) 2010-08-26
WO2008152677A1 (ja) 2008-12-18
US20100085906A1 (en) 2010-04-08

Similar Documents

Publication Publication Date Title
JP4764509B2 (ja) 通信装置および通信リソース管理方法
KR100753026B1 (ko) 무선 네트워크에서의 방송 핸드오버
JP4653888B2 (ja) 情報送信ネットワークにおける論理型ノード識別
CA2680851C (en) Switched digital video client reverse channel traffic reduction
US8255555B2 (en) Reception apparatus and method for reducing time delay in channel switching
US7500261B1 (en) Multi-point multi-channel data distribution system
US20080155612A1 (en) Ip broadcasting system and a multicast group management apparatus for the same
JP4955699B2 (ja) デジタルテレビサービスの送信方法、対応するゲートウェイおよびネットワーク
US20070240192A1 (en) Delivery of subscription services to roaming users through head end equipment
JP2003179903A (ja) Ｉｐストリーミングシステム、ネットワーク中継装置、ｉｐストリーミング用セットトップボックス及びｉｐストリーミング配信方法
KR20070027803A (ko) Ｉｐ기반 방송의 채널변경시 지연시간의 개선 방법
US20130232231A1 (en) Management of the transmission of data streams over multiple networks
US20100017837A1 (en) Method of securing resources in a video and audio streaming delivery system
US20150304229A9 (en) Method and system for allocating receiving resources in a gateway server
KR20070097477A (ko) 게이트웨이 서버에서 수신 자원을 할당하기 위한 방법과시스템
KR101429032B1 (ko) 스트리밍 데이터 전달 방법
WO2010134145A1 (ja) データ通信装置、ホームネットワークシステム、データ通信方法、プログラム、及び集積回路
JP2001197472A (ja) ケーブルテレビネットワークを用いた伝送装置
JP3685637B2 (ja) ディジタル放送のコンテンツ制御方法
JP2021190865A (ja) ゲートウェイ装置、受信装置、データ通信システムおよびプログラム
EP3588847A1 (en) Multicast signal transmitting and receiving method and device
US20170180049A1 (en) Apparatus and method for broadcasting-communications convergence in hybrid fiber coax network
KR20110070440A (ko) Ｄｏｃｓｉｓ 서비스 정보 테이블을 이용한 아이피 기반 멀티캐스트 비디오 서비스의 채널 변경 방법
KR20110070439A (ko) 스위치드 브로드 캐스트의 채널 변경 방법
JP2009152830A (ja) Ｉｐネットワークにおける帯域制限方法及び装置

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110215

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110414

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110607

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110610

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140617

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees