JP5098886B2 - ネットワークグループ管理方式 - Google Patents

ネットワークグループ管理方式 Download PDF

Info

Publication number
JP5098886B2
JP5098886B2 JP2008209949A JP2008209949A JP5098886B2 JP 5098886 B2 JP5098886 B2 JP 5098886B2 JP 2008209949 A JP2008209949 A JP 2008209949A JP 2008209949 A JP2008209949 A JP 2008209949A JP 5098886 B2 JP5098886 B2 JP 5098886B2
Authority
JP
Japan
Prior art keywords
group
terminal
data
management
bandwidth
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
JP2008209949A
Other languages
English (en)
Other versions
JP2010044702A (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
Priority to JP2008209949A priority Critical patent/JP5098886B2/ja
Priority to US12/480,922 priority patent/US9083620B2/en
Publication of JP2010044702A publication Critical patent/JP2010044702A/ja
Application granted granted Critical
Publication of JP5098886B2 publication Critical patent/JP5098886B2/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
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、ピア・ツー・ピア（peer-to-peer：以下P2P）によって複数の端末装置を接続し、データのリレー転送によってリアルタイムデータ配信を行う、ストリーミング配信技術に関する。
従来のクライアント・サーバ型データ配信では、データ受信端末数が増加すると、それに比例した配信負荷が配信サーバに発生する。そのため、大規模システムにおいては、アクセスが集中する配信サーバやネットワークインフラの増強が必須であり、配信コストが課題となる。
このような背景もあり、近年では、P2P技術を応用した配信が注目されている。P2P型のストリーミング配信手法として、データを受信した端末が、受信データを他の端末へ中継し、次々にリレー配信することによって大規模な配信を実現する手法が知られており、端末増加に対する配信サーバの配信負荷増加が緩やか、若しくは影響が無い、という特徴を備えている。
P2P型配信は、物理的なネットワーク環境を意識しない、端末間の論理リンクで形成される論理ネットワーク（オーバーレイネットワーク）上でのデータ配信とみなすことができる。
一方、P2Pデータ配信において、P2Pネットワークを構成する端末の情報を把握し管理することは、セキュリティや商用サービスにおける課金等の様々な観点から重要である。
端末の管理には、専用のサーバ（端末管理サーバ）を配備し集中管理する方式が考えられるが、端末数の多い大規模システムでは、端末管理サーバの情報アクセスが集中し、これがボトルネックとなってスケーラビリティが損なわれる問題があった。
このような端末情報管理の負荷を軽減する方式としては、端末をグループ分けしてグループ毎に端末管理サーバを配備し、グループ単位で情報管理を行う方法が一般的に知られている。端末数の増加時には、グループ数を増やすことによってグループ内端末数の増加を避けられるため、各グループ内の端末管理サーバは、管理負荷の増加を抑える事が出来る。
なおこのとき、データのリレー転送は、できる限りグループ内の端末同士で解決できることが望ましい。これは、物理的なネットワーク構成を考慮して、ネットワーク的に近い端末を集めてグループを構成すれば、グループ内の端末同士でリレー転送するかぎり、端末間の通信トラフィックが物理的ネットワークへ与える影響を軽減できるためである。
以上述べたような、P2Pリレー配信において端末をグループ化し、グループ内で配信経路を構築する従来技術としては、下記特許文献１に記載の技術がある。
この従来技術は、データをリレー転送する端末をグループ化して、サーバ負荷を分散しつつ、サ―バを含む各端末の帯域利用効率を向上させる、データ中継型コンテンツ配信技術である。
グループ化では、データ転送帯域が近い端末が集められて１つのグループが形成され、帯域の太い端末を上流としてグループ内で１本の数珠つなぎの経路が生成され、データ配信が行われる。
数珠つなぎであるため、配信経路上の端末が故障等で中継配信から離脱した場合は、故障端末の上流にあたる端末がこれを検知し、離脱端末をスキップしてその下流端末へデータを転送するよう経路を修正することにより、配信を維持できる。
また、下記特許文献２に記載の別の従来技術のグループ化は、上記従来技術と同様のコンテンツ配信において、中継端末が転送帯域の太い順に並べられ、第１のグループから第Nのグループへ順に割り当てが行われ、次に第Nから第１のグループへ順に割り当てが行われ、これが繰り返されことにより、各グループにおけるメンバ端末の性能及び台数が均等化されるようグループが構成されることを特徴としている。
この方式も、グループ内の配信経路は数珠つなぎであり、故障時は故障端末のリレーをスキップするだけで良いので、経路修正は容易である。
特開２００４−３１８２７４１号公報 特開２００４−１９９５７８号公報
端末をグループ化して管理することにより、スケーラビリティを向上させる端末管理方式として、前記２つの従来技術（特許文献１、２）を挙げたが、これら従来技術におけるグループ化は、グループ内のリレー配信が数珠繋ぎの１本の中継経路で行われるダウンロード型配信において、ダウンロード時間の短縮の効果が得られるよう最適化されている。また、中継端末の停止時には停止端末をスキップすることにより配信の継続が可能である。
一方、ストリーミング配信においては配信データ速度が一定である場合が多く、配信の効率化においては、配信時間の短縮ではなく、同時配信端末数を増加させることが目的となる。
そのため、グループ内の配信経路は数珠つなぎの１本ではなく、ツリー状あるいはメッシュ状に設定され、転送帯域の太い端末は複数端末へ同時にデータをリレー転送する方法が一般的である。
図３６は、各端末がツリー状の配信経路で接続され、この経路に従ってデータが中継配信されていくP2P配信システムにおける一部分として、１グループ分の配信経路例を示した図である。このような配信経路のストリーミング配信で端末のグループ化が行われる場合、前述の従来技術をそのまま適用したグループ化では問題が生じてくる。
図３６では、各端末が円で表され、端末の状態として、円に添えた数字で、[使用帯域/保有帯域]が示されている。例えば、端末aは、保有帯域が、配信データ帯域Bの丁度２倍の2Bを保有しており、受信した配信データを内部でコピーして端末b,cに中継しているので2Bを使用している。よって[2B/2B]と表記されている。
この図では、すべての端末が保有帯域を既に使い切っていることが分かる。
前述した従来技術では、保有帯域が近いものでグループが構成されるか、あるいは、各グループの保有帯域が均一になるようグループが構成されるが、そのグループ内でツリー又はメッシュ状に経路が構築された場合には、図３６に示されるように、グループ内の転送帯域に余裕が無い状態を生じてしまうことが起きる。
この時、例えば２つ以上の端末に中継している端末（図３６の端末a）が何らかの理由
で動作停止した場合に、配信先を失って使用帯域が減った端末Mの直下に、端末b,cのいずれか一方は、接続して受信を継続できるが、他方はグループ内にデータの転送が可能な他の端末がいないため、配信元を失って、受信を継続できなくなる。
このような場合には、他のグループから配信元となれる端末を探して接続する、などの配信経路修正を迫られるが、経路切断（受信停止）状態を検知した後に他グループとの通信シーケンスを伴って手間と時間を要する接続経路の修正を行う事は、リアルタイムストリーミング配信においてビデオや音声の停止等を招き、好ましくないという問題点を有していた。
以上のように、グループ内で経路が修繕できない状態を生じ得ることが、従来のグループ化手法の課題である。
課題は、P2Pストリーミング配信において、端末がグループ化される場合に、経路修正不能な状態の発生を予め回避することを目的とする。
以下に示す態様は、端末装置をグループ化し、その端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式を前提とする。
そして、端末装置をグループ化して管理するためのグループ管理端末装置等が以下の構成を有する。
通信制御手段（１０２）は、自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する。
端末情報管理手段（１０３）は、収集した端末情報を保持する。
グループ帯域管理手段（１０４）は、収集した端末情報に基づいて、自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持する。
制御手段（１０１）は、端末情報管理手段が保持する端末情報及びグループ帯域管理手段が保持するデータ送信帯域の総和情報に基づいて、自グループ内でリアルタイム配信されるデータの配信データ帯域、自グループに対する流入データ帯域、及び自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、自グループ内の各端末装置の増減管理及び接続管理を行う。この比較判定処理は例えば、端末保有転送帯域の総和と他グループから自グループへの流入データ帯域の和と、自グループ内での配信データ帯域に自グループ内の端末装置の数を乗算して得た値と自グループからの流出データ帯域と所定の判定マージンの和とを比較する処理である。この制御手段は例えば、自グループへの追加を希望する端末装置に関する情報を加味して比較判定処理を実行し、その実行結果に基づいて自グループへの追加を希望する端末装置の自グループへの追加を許可するか否かを決定する。また、制御手段は例えば、比較判定処理の結果、自グループ内の各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへ端末移動要求を送出することにより、自グループと他グループとの間で、端末装置を移動させる制御処理を実行する。更に、制御手段は例えば、比較判定処理の結果、自グループ内の各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへデータ送出支援要求又はデータ送出削減通知を送出することにより、自グループに対するデータの流入量又は流出量を制御する処理を実行する。また、制御手段は例えば、他グループからの端末移動要求、データ送出支援要求、又はデータ送出削減通知を受信したときに、その要求又は通知に関する情報を加味して比較判定処理を実行し、その実行結果に基づいてその要求又は通知に応じるか否かを決定する。
グループ内の帯域総和を管理し、帯域変化に備えて事前にグループ間の端末移動や流出入量の調整を行うため、グループ内の帯域総和を安定状態に保ち、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
また、比較判定処理によって、端末数と流出入帯域を調整することにより、総需要を上回る配信性能を保持することが可能となり、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
更に、新規端末の追加判定時にも、総需要を上回る配信性能を保持することが可能となり、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
加えて、グループ内の端末の停止時等にも、総需要を上回る配信性能を維持し、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
そして、グループ間の端末移動や、流出入量の調整時にも、総需要を上回る配信性能を維持し、帯域変化時にグループ内で経路が修正できない状態の発生を防止することが可能となる。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
以下に説明する第１及び第２の実施形態は、端末をグループ化し、端末間でデータ転送を行うストリーミング配信システムを前提とする。
各実施形態の原理説明
まず初めに、グループ内で確実にデータ配信経路が配線（経路構築）できる条件を明らかにしておく。この条件を満たすようにグループ内状態を保ち続けることで、常にデータ配信経路がグループ内で配線可能となり、経路修正が容易となるため、配信の安定化が実現する。
例えば、ある端末から他のある端末へのストリーミング配信が成り立つ条件を考えると、この配信データ帯域Bは、この受信端末にとっての需要帯域であり、一方、ストリーミング送出する側の端末は、帯域B 以上を送出できる配信性能が必要となることは明らかである。つまり、この２端末間で、下記数１式が満たされることが、配信が可能となる条件、すなわち２端末間で配信経路が配線できる条件である。
Figure 0005098886
 この基本事項を発展させ、グループ化した端末間での配線可能条件を導出する。数１式をグループ単位に拡張すると、下記数２式に示されるように、グループ内の総配信性能が、グループ内の総需要を上回っていれば、基本的には配信経路の生成が可能、ということになる。
Figure 0005098886
 ただし、配信経路の配線方法は様々な方法があり、図３に示されるような単一ツリーの経路の場合、「総配信性能」を各端末の配信性能そのものの総和としても、経路配線が困難な状況が発生しうる。図３では、配信性能の総和Btotalは、端末Xの配信性能をB(X)と表
記し、他グループの配信性能を利用して流入する帯域Binも加味すれば、下記数３式のようになる。
Figure 0005098886
 一方、総需要は、グループ内端末が5台、他グループへの配信帯域BoutはBなので、合計6Bである。総配信性能がBだけ多いにもかかわらず、実際にはもう一台接続可能とは限らない。単一ツリーのような経路で配信する場合、0.5Bの帯域が二カ所の端末から配信可能であっても、これを合わせて一台への配信が実現できるとは限らないためである。
実際には、これを可能にする配信方法があるため、後述する第２の実施形態で取り上げることにするが、まずは、以下に説明する第１の実施形態では、単一ツリー型の配信経路を用い、このような帯域の端数は丸められるという前提で説明をする。この前提のもとでは、総配信性能が総需要よりも潤沢であれば、端末追加も可能であり、また配線も可能である。
第１の実施形態
以上の原理をベースにした、第１の実施形態について以下説明する。
グループ管理端末の基本構成図を図１、グループ内端末(以下、単に端末)の基本構成図を図２に示す。
グループ管理端末は、他の端末との通信を行う通信制御部１０２、グループ内端末のデータ転送帯域を含む端末情報を管理する端末情報管理部１０３、グループの帯域を管理するグループ帯域管理部１０４を備える。
まず、管理端末において、制御部１０１は、通信制御部１０２を介して他の端末のデータ転送性能の余剰分を取得し、端末情報管理部１０３に格納する。また、制御部１０１は、端末情報管理部１０３に格納されている各端末のデータ転送帯域の余剰分を合算し、これをグループ帯域として、グループ帯域管理部１０４へ格納する。一方、制御部１０１は、所定の条件判定式を適用して、グループとして転送能力に余力があるか否かを計算する。便宜上、余力のあるグループ状態を「安定」、余力のない状態を「不安定」と呼ぶことにする。
所定の条件判定式としては、例えば、
Figure 0005098886
 が適用される。数４式の導出手順について、以下に説明する。
本実施形態では、グループ内の帯域が不足し、配信経路が生成できなくなるような状態を回避するために、グループ内における「総配信性能」が「総需要」を上回ってなお余るように、グループ状態を維持するための基本判定として、
Figure 0005098886
 が用いられる。ここで、グループにおける「総配信性能」は、下記数６式で定義される。
Figure 0005098886
 「流入帯域」とは、図４に示されるように、他のグループから配信してもらえる分の帯域を指す。一方、グループにおける「総需要」は、下記数７式で定義される。
Figure 0005098886
 「流出帯域」とは、図４に示されるように、他のグループへ配信する分の帯域を指す。
上記数５式〜数７式により、数４式を導出することができる。第１の実施形態において、制御部１０１は、数４式を基本判定式として、グループの転送能力を判定する。
新規端末がグループに追加される際における判定時には、制御部１０１は、新規端末の保有するデータ転送帯域を取得し、数４式によって再判定を行い、数４式が成立する場合に、新規端末のグループへの追加を許可し、成立しない場合には、その追加を許可しない。
新規端末のグループへの追加又はグループ内の端末の停止などによって、グループ内の端末数が変化した場合、若しくはグループ内の端末が保有する転送帯域がネットワーク状況や端末上のプログラム使用状況等によって変化した場合に、制御部１０１は、数４式に基づいて判定を行い、判定式が不成立となった場合に、他のグループ管理端末へ端末移動要求を送出し、自グループ内の転送帯域の少ない端末を他グループへ移動するか、他グループの転送帯域の大きな端末を自グループへ移動させることにより、上記判定式が再び成立するように制御し、グループの安定状態を維持する。或いは、制御部１０１は、他グループへデータ送出の支援要求を送出することにより、グループへの流入量を増加させて、判定式が再び成立するよう制御し、グループの安定状態を維持する。又は、制御部１０１は、他グループへデータ送出の削減通知を送出し、これが受け入れられたらデータの流出量を抑制し、グループの安定状態を維持する。
制御部１０１は、端末移動要求として、自グループから他グループへの端末払出し依頼若しくは他グループから自グループへの端末受入れ依頼を受信した場合、又は、データの流入帯域増強依頼若しくは流出帯域削減通知を受信した場合に、数４式が成立しており、かつ、要求を受け入れても成立が維持できる場合に、その要求に応じる。
上記構成を有する第１の実施形態の動作について、グループ管理端末及びグループメンバ端末とで構成されるP2Pネットワークのグループを例に説明する。本発明は、P2Pによるストリーミング配信に適用可能な発明であるが、以下の第１の実施形態は、グループ管理に必要な端末内、端末間の制御に関する実施の例とし、ストリーミングデータそのものの送受信方法に関する詳細な説明は行わない。
P2Pによるストリーミング配信の例を図４に示す。グループ内の端末は、配信経路上の下流端末に受信データを転送し、全端末への配信が成立する。本実施形態では、グループメンバ端末の一つがグループ管理端末を兼ねている（端末M）。
グループ管理端末Mは、図１に示されるように、制御部１０１、通信制御部１０２、端末情報管理部１０３、グループ帯域管理部１０４を備える。一方、グループメンバ端末は、図２に示されるように、制御部２０１、通信制御部２０２、端末情報管理部２０３を備える。通信制御部１０２、２０２は、他の端末と通信を行う。
端末情報管理部１０３、２０３が管理する端末情報管理テーブルの例を図５に示す。空き帯域の管理方法はいくつか考えられるが、第１の実施形態では、ストリーミング配信されるコンテンツの帯域、すなわち配信経路の帯域幅を基準にし、これを基準単位の１と数える。よって、端末が保有する帯域及び端末が使用している帯域は、実帯域（単位はbps:bit per second<ビット／秒>）をコンテンツ帯域幅（単位は同じくbps）で割った商、ということになる（この整数値を、次数と呼ぶことにする）。以降、本実施形態では、「帯域」という表現はこの次数を指す。図５に示される端末情報管理テーブルには、端末の保有する配信に使用可能な帯域（使用可能保有帯域）と、既に配信に使用している帯域（使用帯域）、及び端末情報が格納される。
例えば、図５に示される端末情報管理テーブルの１行目のエントリの端末情報は、それに対応する端末が192.168.10.5というIP(インターネットプロトコル)アドレスを持ち、ポート番号10000を使用し、この端末が配信に使用できる帯域は配信コンテンツ帯域２本分であり、そのうち１本分は既にその端末が配信に使用していることを示している。また、この端末情報は、その端末の所属するグループIDは10であり、配信経路の上流（UPと表記）に位置する端末は「UP、192,xx〜」で示される、グループID=10に属する端末である。同様に、この端末の下流（LWと表記）には、「LW、192.xx〜」で示される端末が接続されており、これにデータが中継配信されていることを示している。更に、この端末情報は、その端末が、グループ管理端末ではない、一般端末であることを示している。
なお、端末情報を参照することにより、UPの接続端末が別グループIDであれば、流入帯域を受けている端末であると判別できるし、LWの接続端末が別グループIDであれば、流出帯域を出力している端末であると判別できる。
各端末情報は、端末がグループに組み入れられる際にその端末から取得されて上記端末情報管理テーブルに格納される。また、各端末は、情報に変化が生じた際には、自グループの管理端末へ更新情報を送信する。
一方、端末情報管理テーブルは、グループ管理端末の属するグループとは異なるグループに属している端末の情報も保持している。これは、グループ管理端末が把握している、他のグループ管理端末の情報である。これらの端末情報を保持することにより、グループ管理端末は、他のグループの管理端末のIPアドレスを知り、通信が可能となる。また、必要に応じて、UP若しくはLWの接続端末の所属グループIDと同じIDを持つ管理端末を検索すれば、流出入帯域に関連するグループの管理端末を特定できる。
続いて、グループ帯域管理部１０４が管理するグループ帯域管理テーブルの例を図６に示す。グループ内の各端末の使用可能保有帯域の合計が「帯域総量」に格納される。また、グループ外からグループ内への配信経路があれば、その経路の帯域が「流入帯域」に格納され、グループ内から別グループへの配信経路があれば、その経路の帯域が「流出帯域」に格納される。図５に示される端末情報管理テーブルに格納されている情報に変化が生じた際には、図６に示される「帯域総量」が再計算される。「流入帯域」、「流出帯域」が変化した場合には、その都度、再計算が行われる。
前述した数４式における判定マージンＭの最小値としては、下記数８式のように、グループ内の端末が保有する転送帯域のうちの最大値が選択される。
Figure 0005098886
これによって、最大の転送帯域を保有する端末を含む任意の端末１台が突然停止した場合にも、（総配信性能）が（総需要）を下回ることがなくなるので、判定マージンＭとして設定する値の目安にすることができる。
以上の管理情報と判定条件を元に、図１の制御部１０１は、グループ内端末の増減を管理する。基本動作として、数４式が成り立たない場合に、その判定式が成り立つよう、端末数及び流出入量が調整される。
端末の新規参加時には、グループ管理端末の制御部１０１は、参加を要求する新規端末が送信する接続要求パケットから、端末情報を取得する。
図１８は、接続要求パケットのデータフォーマット例を示す図である。接続要求パケットには、接続の要求を示すメッセージタイプ「JoinReq」、新規端末のIPアドレス「IPadrs」、ポート番号「port」、保有帯域「spec」が格納されている。
制御部１０１は、図７の動作フローチャートで示されるように、この端末情報を加味して数４式の条件判定を行い（ステップＳ７０１、Ｓ７０２）、条件が成り立てば、ステータス（グループ状態）は「安定」とし（Ｓ７０３）、新規端末のグループ内への参加を許可し（Ｓ７０４）、不成立時には、ステータスは「不安定」とし（Ｓ７０５）グループ内への参加を拒否する（Ｓ７０６）。なお、制御部１０１は、参加拒否時には、次に述べる他グループへの対応依頼を行った上で参加を許可するように制御することもできる。
新規端末への応答パケットのデータフォーマット例を図１９に示す。
次に、制御部１０１は、図８の動作フローチャートに示されるように、グループ内の端末が突然動作を停止する、或いは、グループ内端末が保有する帯域が変化する、などによって、帯域計算（Ｓ８０１）の後に数４式の条件判定（Ｓ８０２）が不成立となって、ステータス（グループ状態）が不安定となる場合（Ｓ８０３）、若しくは、新規参加で新たに接続する端末があり、図７の動作フローチャートに基づいて新規端末の端末情報を前述の加味して条件判定を行った場合に不安定となる場合（Ｓ７０５）には、他グループのグループ管理端末へ対応を依頼する（Ｓ８０４）。一方、帯域計算（Ｓ８０１）の後に数４式の条件判定（Ｓ８０２）が成立となる場合には、ステータス（グループ状態）が安定にされる（Ｓ８０３）。上記ステップＳ８０４の他グループの管理端末への対応依頼処理の動作フローチャートは、図９に示される。
この例では、不安定状態を一気に解消することを優先し、まず、制御部１０１は、保有帯域の多い端末を他グループから移動するための「端末払出し依頼」を、少なくとも１つ以上の他のグループ管理端末へ送信する（Ｓ９０１）。他のグループ管理端末は端末情報管理部１０３が保持する端末情報管理テーブルから知ることができる。端末払出し依頼のパケットフォーマットには、図２０に示されるように、メッセージタイプ「MoveReq」、送信元管理端末情報(Sender info2)、送信元グループID「GroupID」、要求する端末性能「ReqSpec」が付加される。
制御部１０１は、承諾を示す「OK」の回答を有する「端末払出し依頼応答」のパケット（図２１のパケットフォーマットを有する）を受信できれば、払い出された端末を既存経路に挿入し、ここから配信経路を分岐し、受信帯域の不足に陥っている端末や新規端末に経路を接続する（Ｓ９０２−＞Ｓ０３）。
新規端末参加の状態遷移の例を図１０に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１１に、それぞれ示す。
制御部１０１は、「OK」の回答を有する「端末払出し依頼応答」パケットを１通も受信できない場合は、流入帯域の増強を試みる。即ち、制御部１０１は、少なくとも１つ以上の他グループ管理端末へ、流入帯域の増強が可能か否か、即ち、経路接続が可能な、転送帯域に空きがある端末がいないか、「流入帯域増強依頼」（図２２のパケットフォーマットを有する）を送信する（Ｓ９０２−＞Ｓ９０４）。
制御部１０１は、上記依頼に対応して「OK」の回答を有する「流入帯域増強応答」のパケット（図２３のパケットフォーマットを有する）を受信できれば、「流入帯域増強応答」パケットに記載された端末情報（図２３のNode info = 転送帯域に空きがある端末の情報）から、帯域が不足している端末若しくは新規端末への配信経路を生成する（Ｓ９０５−＞Ｓ９０６）。
新規端末参加の状態遷移の例を図１２に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１３に、それぞれ示す。
制御部１０１は、「流入帯域増強依頼」に対して他グループ管理端末から「OK」の回答を有する「流入帯域増強応答」パケットを１通も受信できない場合は、次のメッセージである「流出帯域削減通知」（図２４のパケットフォーマットを有する）を送出する（Ｓ９０５−＞Ｓ９０７）。送出先は、現在、流出帯域の送り先である端末（図２４のNode1）の所属するグループ管理端末である。Node1の検索は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）から、LWに記載されていて自グループ以外である端末が選択されれば良い。
制御部１０１は、上記通知に対応して「OK」の回答を有する「流出帯域削減通知応答」のパケット（図２５のパケットフォーマットを有する）を受信できれば、その端末への配信経路を切断して、帯域が不足している端末若しくは受け入れる新規端末への経路を接続する（Ｓ９０８−＞Ｓ９０９）。
新規端末参加の状態遷移の例を図１４に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１５に、それぞれ示す。
制御部１０１は、「OK」の回答を有する「流出帯域削減応答」のパケットを１通も受信できない場合は、さらに次のメッセージである「端末受入れ依頼」（図２６のパケットフォーマットを有する）を他のグループ管理端末へ送信する（Ｓ９０８−＞Ｓ９１０）。端末受入れ依頼には、端末情報管理部１０３が保持する端末情報管理テーブル（図５）から、使用可能保有帯域が無い、若しくは少ない端末の端末情報が付加される。送付先としては、端末情報管理テーブル（図５）から上流若しくは下流のグループ管理端末が検索されればよい。
制御部１０１は、上記依頼に対応して「OK」の回答を有する「端末受入れ依頼応答」（図２７のパケットフォーマットを有する）を受信できれば、その端末への経路を切り離し、帯域が不足する端末若しくは新規端末を接続する（Ｓ９１１−＞Ｓ９１２）。「端末受け入れ依頼」では、帯域不足で正常受信できない端末若しくは新規端末自体を他グループに引き取り依頼することも可能であり、これが受け入れられれば、自グループでは特に変更は生じない。
新規端末参加の状態遷移の例を図１６に、その場合における接続情報管理テーブルの接続前から接続後への変化を図１７に、それぞれ示す。
制御部１０１は、上記依頼に対応して「OK」の回答を有する「端末受入れ依頼応答」を１通も受信できない場合は、新規端末の受け入れ等を拒絶する（Ｓ９１３）。
最後に、他のグループ管理端末から、図９のステップＳ９０１、Ｓ９０４、Ｓ９０７、及びＳ９１０の処理に基づく各依頼又は通知を受信したときの制御部１０１の動作を、以下に説明する。
図９のステップＳ９０１の処理により他のグループ管理端末から送信された「端末払出し依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図２８に示す。
制御部１０１は、通信制御部１０２を介して「端末払出し依頼」パケット（図２０）を受信すると（Ｓ２８０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ２８０２）。
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０２−＞Ｓ２８０８）、依頼元のグループ管理端末へ返送する（Ｓ２８０９）。
自グループのステータスが「安定」である場合には、制御部１０１は、下記数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ２８０２−＞Ｓ２８０３）。
Figure 0005098886
続いて、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が、マージンＭR 以内で、かつ配信データ帯域が２本分以上である端末を検索し（Ｓ２８０４−＞Ｓ２８０５−＞Ｓ２８０７−＞Ｓ２８０４の繰返し処理）、検索に成功した端末について、払出し可能な端末として、端末情報を付加した上で、依頼承諾を示す「OK」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０５−＞Ｓ２８０６）、依頼の送信元であるグループ管理端末へ返送する（Ｓ２８０９）。
テーブル内に払出し条件の成立する端末が無ければ、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２８０７−＞Ｓ２８０８）、依頼元のグループ管理端末へ返送する（Ｓ２８０９）。
図９のステップＳ９０4の処理により他のグループ管理端末から送信された「流入帯域増強依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図２９に示す。
制御部１０１は、通信制御部１０２を介して「流入帯域増強依頼」パケット（図２２）
を受信すると（Ｓ２９０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ２９０２）。
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「流入帯域増強依頼応答」パケット（図２３）を生成し（Ｓ２９０２−＞Ｓ２９０９）、依頼元のグループ管理端末へ返送する（Ｓ２９１０）。
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ２９０２−＞Ｓ２９０３）。
続いて、マージンＭR が配信データ帯域以上であれば、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索し（Ｓ２９０４−＞Ｓ２９０５−＞Ｓ２９０８−＞Ｓ２９０４の繰返し処理）、検索に成功した端末について、端末情報を付加した上で接続通知パケットを送付し（Ｓ２９０５−＞Ｓ２９０６）、当該端末を帯域増強の為に配信経路を出力できる端末として選択し、この端末情報を付加した上で、依頼承諾を示す「OK」を記載した「流入帯域増強依頼応答」パケット（図２３）を生成し（Ｓ２９０７）、依頼の送信元であるグループ管理端末へ返送する（Ｓ２９１０）。
テーブル内に検索条件に該当する端末が無ければ、依頼拒否を示す「NG」を記載した「端末払出し依頼応答」パケット（図２１）を生成し（Ｓ２９０８−＞Ｓ２９０９）、依頼元のグループ管理端末へ返送する（Ｓ２９１０）。
図９のステップＳ９０７の処理により他のグループ管理端末から送信された「流出帯域削減通知」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図３０に示す。
制御部１０１は、通信制御部１０２を介して「流出帯域削減通知」パケット（図２４）を受信すると（Ｓ３００１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ３００２）。
自グループのステータスが「安定」でない場合には、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００２−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ３００２−＞Ｓ３００３）。
続いて、制御部１０１は、上記マージンＭR が配信データ帯域よりも大きいか否かを判定する（Ｓ３００４）。
マージンＭR が配信データ帯域以下である場合には、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００４−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
マージンＭR が配信データ帯域よりも大きい場合には、経路修正できる可能性があるので、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、帯域削減対象として通知された端末（図２４のNode1）の下流に接続されている
全ての端末に対応する全ての端末情報エントリの「マーカー」領域（図５参照）にマークフラグを設定する。このマーク処理では、端末情報管理テーブル（図５）からまずNode1に記載されている端末アドレスに対応する端末情報エントリが検索され（Ｓ３００５）、この端末情報エントリにLWかつ自グループである下流端末が登録されていれば、各下流端末に対応する各端末情報エントリにマークフラグが設定され、更に各エントリからLWかつ自グループである下流端末に対応する各端末情報エントリが検索されてそこにマークフラグが設定され、以下同様の処理が繰り返される（Ｓ３００６）。
以上のマーク処理の後、制御部１０１は、端末情報管理テーブル（図５）において、「マーカー」領域にマークフラグが設定されていない端末情報エントリのうち、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索する（Ｓ３００７）。
このような端末が見つからなければ、制御部１０１は、「NG」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３００８−＞Ｓ３０１１）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
一方、このような端末が見つかれば、制御部１０１は、検索された端末から帯域削減対象として通知された端末（図２４のNode1）への経路を生成したのち（Ｓ３００８−＞Ｓ３００９）、「OK」を記載した「流出帯域削減通知応答」パケット（図２５）を生成し（Ｓ３０１０）、依頼元のグループ管理端末へ返送する（Ｓ３０１２）。
最後に、図９のステップＳ９１０の処理により他のグループ管理端末から送信された「端末受入れ依頼」を受信した側のグループ管理端末の制御部１０１が実行する処理の動作フローチャートを、図３１に示す。
制御部１０１は、通信制御部１０２を介して「端末受入れ依頼」パケット（図２６）を受信すると（Ｓ３１０１）、自グループのステータスが「安定」であるか否かを判定する（Ｓ３１０２）。
自グループのステータスが「安定」でない場合には、制御部１０１は、依頼拒否を示す「NG」を記載した「端末受入れ依頼応答」パケット（図２７）を生成し（Ｓ３１０２−＞Ｓ３１０８）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。
自グループのステータスが「安定」である場合には、制御部１０１は、前述の数９式に従って、安定状態としてどの程度の余裕があるか、マージンＭR を計算する（Ｓ３１０２−＞Ｓ３１０３）。
続いて、マージンＭR が配信データ帯域以上であれば、制御部１０１は、端末情報管理部１０３が保持する端末情報管理テーブル（図５）において、空き帯域、すなわち「使用可能保有帯域」から「使用帯域」を差し引いた帯域が配信データ帯域以上残っている端末を検索し（Ｓ３１０４−＞Ｓ３１０５−＞Ｓ３１０７−＞Ｓ３１０４の繰返し処理）、検索に成功した端末があれば、依頼に付加されていた端末情報の端末へ、検索された端末情報を接続先通知パケットによって通知するとともに、依頼承諾を示す「OK」を記載した「端末受入れ依頼応答」パケット（図２７）を生成し（Ｓ３１０６）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。なお、以上の手順で付加して送付する端末情報は、条件に該当する端末が複数存在する場合にはリストで返送しても良い。その場合、リストとして端末情報を複数受信した管理端末側で、任意の端末を選択して良い。
テーブル内に検索条件の成立する端末が無ければ、依頼拒否を示す「NG」を記載した「
端末払出し依頼応答」パケット（図２７）を生成し（Ｓ３１０７−＞Ｓ３１０８）、依頼元のグループ管理端末へ返送する（Ｓ３１０９）。
以上説明した第１の実施形態では、各依頼などの端末間メッセージとしては、所定のデータフォーマットのものが使用されているが、任意のフォーマットのIP（インターネットプロトコル）パケットなどによって実現されてもよい。
また、グループ管理端末が他のグループ管理端末に各種依頼や通知を送る際に、相手のグループ管理端末が複数ある場合には、それら複数に送付が行われてもよく、グループ管理端末が受信する応答が複数あれば、そのうち任意のものが選択されてもよい。
配信経路の配線方法については、さまざまな方法が知られているが、本実施形態では簡易な一例を示した。他の方法でももちろんよい。
第２の実施形態
上記第１の実施形態では、端末間の各経路における帯域が配信データ帯域と同一であり、管理される帯域の単位が配信データ帯域を基本単位にしたものであったが、第２の実施例では、これよりも細い帯域を基本単位にした管理が行われる。なお、基本的なグループ管理方法は、第１の実施形態に示しているものと同様である。
第２の実施形態の詳細説明の前に、第１の実施例で使用した簡易な配信経路の配線方法よりも効率的な経路生成方法を示しておく。
第１の実施例に使用された配線方法では、図３２の端末a,bのように、端末が配信データ帯域Bよりも少ない帯域（ここでは半分の0.5B）しか保有していない場合、データの中継配信ができない。保有帯域Bの端末Mは、帯域Bが必要な配信データを端末a又はbの片方にしか配信できないため、他方はデータを受信できないことになる。
これに対し、図３３のように、帯域Bを必要とする配信データがたとえば２等分され、0.5B ずつ２つの配信経路で同時に配信を行う方法が知られている。例えば、配信データが単位データに細分化され、時間軸の並びで交互に２つのグループに振り分けて２等分され、それぞれのグループがデータ１、データ２とされる。データ１及び２は、データ量がオリジナルの半分なので、配信帯域も半分(0.5B)となる。データ１の配信経路を経路１、データ２の配信経路を経路２とすると、端末a及びbは、経路１及び経路２という２種の別経路からそれぞれデータ１とデータ２を0.5B ずつ漏れなく受信すれば、結果的にすべてのデータを受信でき、時間軸順に交互に結合すれば、オリジナルを復元できることになる。このような複数経路を用いた配信経路構築手法に対して本発明が適用された第２の実施形態を、以下に示す。
ここでは、配信データ帯域Bが２等分されて２つの経路で配信されるケースについて説明する。
まず、グループ管理端末の基本構成図、及びグループ内端末(以下、単に端末)の基本構成図は、第１の実施形態における図１及び図２の構成と同じである。
各端末は、実際の保有帯域を0.5Bで割った商を、保有帯域として、グループ管理端末に通知する。管理テーブルへの登録情報も、同様に0.5Bで割った商で統一され、端末情報管理部１０３（図１）や端末情報管理部２０３（図２）等に保持される端末情報管理テーブルは、図３４に示されるようになる。UP1,UP2はそれぞれ経路１及び経路２における上流端末であり、同様に、LW1,LW2はそれぞれ経路１及び経路２における下流端末を示している。
経路が配線される場合には、図３５に示されるように、制御部１０１は、まず、自グル
ープのステータスが「安定」であるか否かを判定する（Ｓ３５０１）。
自グループのステータスが「安定」でない場合には、制御部１０１は、接続不可の結果を返す（Ｓ３５０１−＞Ｓ３５１１）。
自グループのステータスが「安定」である場合には、制御部１０１は、ステップＳ３５０２にて、経路番号を０にリセットし、ステップＳ３５０３にて、端末情報管理部１０３が保持する端末情報管理テーブルに端末Xの端末情報（接続端末以外）を登録した後、ステップＳ３５０４で経路番号を＋１しながら、ステップＳ３５０９にてｎが分割数（第２の実施形態では＝２）に達したと判定するまで、管理テーブルから空き次数を保有する端末を検索し（Ｓ３５０５）、端末Xの接続端末として該当端末を端末Xの端末情報エントリのUPnに登録し（Ｓ３５０６）、該当端末の端末情報エントリのLWnに端末Xを登録して使用可能保有帯域（図５参照）を減らし（Ｓ３５０７）、該当端末と端末Xに相互接続を指示する（Ｓ３５０８）、制御処理を繰り返し実行する。
本実施形態では、配信データ帯域が２等分した経路構築手法を取り上げているが、図３５の動作フローチャートのようにＮ等分でも同様の制御動作が適用可能である。
更に、複数の経路が等分でない手法にも応用でき、複数の経路のうち最も細い帯域を基準単位にして同様の制御動作が適用されればよい。なお、等分でない場合には、各経路の帯域は、最小帯域の整数倍であると、余剰が発生せず、効率が良い。
第１及び第２の実施形態におけるグループ管理端末の基本構成図である。 第１及び第２の実施形態における一般端末の基本構成図である。 ツリー型経路による配信経路例を示した図である。 流入帯域、流出帯域の各定義の説明図である。 端末情報管理部が保持する端末情報管理テーブルの構成例を示す図である。 グループ帯域管理部が保持するグループ帯域管理テーブルの構成例を示す図である。 端末追加の判定処理を示す動作フローチャートである。 帯域変化時の判定処理を示す動作フローチャートである。 帯域不足（不安定ステータス）時の対応依頼処理を示す動作フローチャートである。 端末払出し依頼に伴う経路構築例を示す説明図である。 図１０の端末払出し依頼に伴う端末情報管理テーブルの変化を示す説明図である。 流入帯域増強依頼に伴う経路構築例を示す説明図である。 図１２の流入帯域増強依頼に伴う端末情報管理テーブルの変化を示す説明図である。 流出帯域削減通知に伴う経路構築例を示す説明図である。 図１４の流出帯域削減通知に伴う端末情報管理テーブルの変化を示す説明図である。 端末受け入れ依頼に伴う経路構築例を示す説明図である。 図１６の端末受け入れ依頼に伴う端末情報管理テーブルの変化を示す説明図である。 接続要求パケットフォーマット例を示す図である。 接続応答パケットフォーマット例を示す図である。 端末払出し依頼パケットフォーマット例を示す図である。 端末払出し依頼応答パケットフォーマット例を示す図である。 流入帯域増強依頼パケットフォーマット例を示す図である。 流入帯域増強依頼応答パケットフォーマット例を示す図である。 流出帯域削減通知パケットフォーマット例を示す図である。 流出帯域削減通知応答パケットフォーマット例を示す図である。 端末受入れ依頼パケットフォーマット例を示す図である。 端末受入れ依頼応答パケットフォーマット例を示す図である。 端末払出し依頼受信時の処理を示す動作フローチャートである。 流入帯域増強依頼受信時の処理を示す動作フローチャートである。 流出帯域削減通知受信時の処理を示す動作フローチャートである。 端末受入れ依頼受信時の処理を示す動作フローチャートである。 単一ツリー型経路での配信限界の例を示す説明図である。 複数経路による配信経路構築手法の例を示す説明図である。 第２の実施形態における接続情報管理テーブルの構成例を示す図である。 第２の実施形態における配信経路生成処理を示す動作フローチャートである。 P2Pによるリレー配信システムの一部であるグループ内の配信経路例を示した図である。
符号の説明
１０１、１０２ 制御部
１０２、２０２ 通信制御部
１０３、２０３ 端末情報管理部
１０４ グループ帯域管理部

Claims (7)

  1. 端末装置をグループ化し、該端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式であって、
    端末装置をグループ化して管理するためのグループ管理端末装置が、
    自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する通信制御手段と、
    前記収集した端末情報を保持する端末情報管理手段と、
    前記収集した端末情報に基づいて、前記自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持するグループ帯域管理手段と、
    前記端末情報管理手段が保持する前記端末情報及び前記グループ帯域管理手段が保持する前記データ送信帯域の総和情報に基づいて、前記自グループ内でリアルタイム配信されるデータの配信データ帯域、前記自グループに対する流入データ帯域、及び前記自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、前記自グループ内の前記各端末装置の増減管理及び接続管理を行う制御手段と、
    を含むことを特徴とするネットワークグループ管理方式。
  2. 端末装置をグループ化し、該端末装置間でリアルタイムデータ転送を行うストリーミング配信システムにおけるネットワークグループ管理方式であって、
    自グループ内の各端末装置に関するデータ転送帯域を含む端末情報を各端末装置から収集する通信制御ステップと、
    前記収集した端末情報を保持する端末情報管理ステップと、
    前記収集した端末情報から、前記自グループ内の各端末装置の保有するデータ送信帯域の総和情報を保持するグループ帯域管理ステップと、
    前記端末情報管理ステップが保持する前記端末情報及び前記グループ帯域管理ステップが保持する前記データ送信帯域の総和情報に基づいて、前記自グループ内でリアルタイム配信されるデータの配信データ帯域、前記自グループに対する流入データ帯域、及び前記自グループからの流出データ帯域との関係を判定する比較判定処理を実行することによって、前記自グループ内の前記各端末装置の増減管理及び接続管理を行う制御ステップと、
    を含むことを特徴とするネットワークグループ管理方式。
  3. 前記比較判定処理は、端末保有転送帯域の総和と他グループから前記自グループへの前記流入データ帯域の和と、前記自グループ内での前記配信データ帯域に前記自グループ内の前記端末装置の数を乗算して得た値と前記自グループからの前記流出データ帯域と所定の判定マージンの和とを比較する処理である、
    ことを特徴とする請求項１又は２の何れか１項に記載のネットワークグループ管理方式。
  4. 前記制御手段又は前記制御ステップは、前記自グループへの追加を希望する端末装置に関する情報を加味して前記比較判定処理を実行し、その実行結果に基づいて前記自グループへの追加を希望する端末装置の前記自グループへの追加を許可するか否かを決定する、
    ことを特徴とする請求項１乃至３の何れか１項に記載のネットワークグループ管理方式。
  5. 前記制御手段又は前記制御ステップは、前記比較判定処理の結果、前記自グループ内の前記各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへ端末移動要求を送出することにより、前記自グループと前記他グループとの間で、前記端末装置を移動させる制御処理を実行する、
    ことを特徴とする請求項１乃至４の何れか１項に記載のネットワークグループ管理方式。
  6. 前記制御手段又は前記制御ステップは、前記比較判定処理の結果、前記自グループ内の前記各端末装置の増減又は接続を許可しないと判定した場合に、他のグループへデータ送出支援要求又はデータ送出削減通知を送出することにより、前記自グループに対するデータの流入量又は流出量を制御する処理を実行する、
    ことを特徴とする請求項１乃至５の何れか１項に記載のネットワークグループ管理方式。
  7. 前記制御手段又は前記制御ステップは、前記他グループからの前記端末移動要求、前記データ送出支援要求、又はデータ送出削減通知を受信したときに、該要求又は通知に関する情報を加味して前記比較判定処理を実行し、その実行結果に基づいて該要求又は通知に応じるか否かを決定する、
    ことを特徴とする請求項５又は６の何れか１項に記載のネットワークグループ管理方式。
JP2008209949A 2008-08-18 2008-08-18 ネットワークグループ管理方式 Expired - Fee Related JP5098886B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008209949A JP5098886B2 (ja) 2008-08-18 2008-08-18 ネットワークグループ管理方式
US12/480,922 US9083620B2 (en) 2008-08-18 2009-06-09 Network group management system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008209949A JP5098886B2 (ja) 2008-08-18 2008-08-18 ネットワークグループ管理方式

Publications (2)

Publication Number Publication Date
JP2010044702A JP2010044702A (ja) 2010-02-25
JP5098886B2 true JP5098886B2 (ja) 2012-12-12

Family

ID=41682038

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008209949A Expired - Fee Related JP5098886B2 (ja) 2008-08-18 2008-08-18 ネットワークグループ管理方式

Country Status (2)

Country Link
US (1) US9083620B2 (ja)
JP (1) JP5098886B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5429892B2 (ja) * 2011-09-20 2014-02-26 Ｎｅｃビッグローブ株式会社 通信システム、サーバ、帯域制御装置、帯域制御方法およびプログラム
EP2597815B1 (de) * 2011-11-23 2019-07-24 Siemens Schweiz AG Verfahren zur identifikation von in einem kommunikationsnetzwerk zusammengefassten geräten
JP7234726B2 (ja) * 2019-03-20 2023-03-08 富士フイルムビジネスイノベーション株式会社 通信装置、通信システム、及びプログラム
CN110290009B (zh) * 2019-07-02 2023-02-28 深圳市网心科技有限公司 一种数据调度方法、装置及计算机可读存储介质

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5121383A (en) * 1990-11-16 1992-06-09 Bell Communications Research, Inc. Duration limited statistical multiplexing in packet networks
US6330609B1 (en) * 1997-11-07 2001-12-11 Lucent Technologies, Inc. Admission control system and method for media-on-demand servers
JP3766223B2 (ja) * 1999-02-18 2006-04-12 富士通株式会社 境界装置及びそのコネクション設定方法
US7006530B2 (en) * 2000-12-22 2006-02-28 Wi-Lan, Inc. Method and system for adaptively obtaining bandwidth allocation requests
US6826612B1 (en) * 1999-12-21 2004-11-30 Alcatel Canada Inc. Method and apparatus for an improved internet group management protocol
US7774468B1 (en) * 2000-07-28 2010-08-10 Siddhartha Nag Network traffic admission control
JP4489925B2 (ja) * 2000-11-02 2010-06-23 富士通株式会社 ネットワーク共有帯域割当て方法及びこれを用いるネットワークシステム
US8060643B2 (en) * 2002-08-30 2011-11-15 Hewlett-Packard Development Company, L.P. Method and apparatus for dynamically managing bandwidth for clients in a storage area network
JP2004199578A (ja) * 2002-12-20 2004-07-15 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信方法及び装置並びにプログラム及び記録媒体
JP2004318274A (ja) * 2003-04-11 2004-11-11 Nippon Telegr & Teleph Corp <Ntt> 中継型コンテンツ配信方法及び装置並びにプログラム
US7336605B2 (en) * 2003-05-13 2008-02-26 Corrigent Systems, Inc. Bandwidth allocation for link aggregation
US7362776B2 (en) * 2004-11-01 2008-04-22 Cisco Technology, Inc. Method for multicast load balancing in wireless LANs
JP2006227763A (ja) 2005-02-15 2006-08-31 Nec Soft Ltd データ共有システム、データ共有方法及びプログラム
JP4604824B2 (ja) * 2005-05-10 2011-01-05 ブラザー工業株式会社 情報配信システム、処理プログラム、管理プログラム及び情報配信方法等
WO2006120946A1 (ja) * 2005-05-10 2006-11-16 Brother Kogyo Kabushiki Kaisha ツリー型ネットワークシステム、ノード装置、放送システム及び放送方法等
JP4760231B2 (ja) * 2005-08-31 2011-08-31 ブラザー工業株式会社 コンテンツデータ配信システム、同システムにおける端末装置、及び、端末装置の動作プログラム
JP5018036B2 (ja) * 2006-11-21 2012-09-05 日本電気株式会社 ＱｏＳ制御システム、ＱｏＳ制御方法、およびＱｏＳ制御プログラム
US8284654B2 (en) * 2007-12-03 2012-10-09 Verizon Patent And Licensing Inc. Bandwidth admission control on link aggregation groups
US8811254B2 (en) * 2010-12-08 2014-08-19 Fujitsu Limited Dynamic connection admission control to enforce service level agreements in multicast networks
US8619777B2 (en) * 2011-11-22 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Admission control for receiving traffic at hosts

Also Published As

Publication number Publication date
JP2010044702A (ja) 2010-02-25
US20100042713A1 (en) 2010-02-18
US9083620B2 (en) 2015-07-14

Similar Documents

Publication Publication Date Title
CN1957568B (zh) 用于配置跨域电信服务的开放式服务发现和路由选择机制
TWI222812B (en) Method and system for resource reservations in a multicasting network
US10027436B2 (en) Service and application layer optimization using variable rate optical transmission
CN101383769B (zh) 建立双向点到点连接的方法
JP5098886B2 (ja) ネットワークグループ管理方式
CN101513004A (zh) 对等体间动态带宽调整和交易的系统
CN101073226A (zh) 在标签交换的通信网络中创建隧道的方法和设备
CN101433031B (zh) 在传输网络中协调接纳控制的方法和系统
CN103477612A (zh) 经扩展以连接网络层级的云服务控制和管理架构
US8649375B2 (en) Method and devices for multicast distribution optimization
CN101136844A (zh) 实现多协议标签交换网络差分业务流量工程的方法和系统
WO2007132469A2 (en) Rpr representation in ospf-te
CN107615721A (zh) 传输软件定义网络(sdn)‑逻辑链路聚合(lag)成员信令
CN101488966A (zh) 一种视频服务系统
CN100571185C (zh) 一种跨不同管理域网络的边缘连接选路方法
CN1663193B (zh) 用于管理通信网络中的链路资源的方法
CN112583729A (zh) 一种路径的流量分配方法、网络设备及网络系统
CN102724064A (zh) 一种网络应用仿真系统构建方法
CN100496023C (zh) 一种传输链路状态信息的方法
CN102300260B (zh) 一种调整abis接口带宽资源的方法及系统
CN101345714B (zh) 标签交换路径的准入方法及系统
WO2022184129A1 (zh) 一种时隙分配处理方法、设备及存储介质
Oliveira et al. Improving peer neighborhood on P2P video distribution networks using Push/Pull protocol
CN113193988A (zh) 一种多pce的路径计算交互方法和系统
CN108023810A (zh) 连接能力的通告方法及装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110513

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: 20120828

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120829

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120910

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

Free format text: PAYMENT UNTIL: 20151005

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