JP3592876B2 - マルチキャスト通信制御方法及びノード装置 - Google Patents
マルチキャスト通信制御方法及びノード装置 Download PDFInfo
- Publication number
- JP3592876B2 JP3592876B2 JP02246897A JP2246897A JP3592876B2 JP 3592876 B2 JP3592876 B2 JP 3592876B2 JP 02246897 A JP02246897 A JP 02246897A JP 2246897 A JP2246897 A JP 2246897A JP 3592876 B2 JP3592876 B2 JP 3592876B2
- Authority
- JP
- Japan
- Prior art keywords
- link
- resource amount
- output
- communication
- service attribute
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能なコネクション型（例えば非同期転送モード型（ＡＴＭ：Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ））通信網におけるマルチキャスト通信制御方法及びノード装置に関する。
【０００２】
【従来の技術】
非同期転送モード型通信網（以下、ＡＴＭ通信網と呼ぶ）において複数の受信者へ同一の情報を分配するマルチキャスト通信を行なう場合、送信者からすべての受信者へのポイント−マルチポイントＡＴＭコネクションを設定することで、送信者は受信者数分の情報のコピーを自らすることなく、そのポイント−マルチポイントコネクションに向けて情報を送信するだけで、すべての受信者にそれを届けることが可能となる。ここで送信者、受信者とは実際の情報送信元ホスト、受信先ホストであっても構わないし、ルータ装置のようなコネクションレス型パケット中継ノードであっても構わない。
【０００３】
このポイント−マルチポイントコネクションの提供する帯域や通信品質（ＱｏＳ）などのサービス属性は、従来すべての受信者に対して同一のものが提供される。この制約は以下のような問題点を生じる可能性がある。
【０００４】
例えば、受信者によって要求するサービス属性が異なる（例えば、ある受信者は多少通信コストがかかっても一定帯域の確実な保証を要求するが、ある受信者は通信品質の保証をまったく要求せずむしろ低コストの通信を要求する）ような場合には、最も厳しい受信者の要求を満たすようなサービス属性をすべての受信者に提供するようなポイント−マルチポイントコネクションによりサービスを実現する方法が考えられる。
【０００５】
しかしながらその場合、通信品質保証の要求をしていない受信者に対しても所定の通信リソースをエンドエンドに確保していることになり、網リソースの効率的な運用を低コストな通信の提供といった観点からは望ましい方法とは言えない。
【０００６】
受信者により要求サービス属性が異なる場合のＡＴＭマルチキャスト通信の他の実現方法として、要求サービス属性の等しい（または類似した）受信者群に対してはひとつのポイント−マルチポイントコネクションによりサービスを提供し、要求サービス属性の異なる（または大きく異なる）受信者群には別の属性のポイント−マルチポイントコネクションによりサービス提供する方法も考えられる。極端な場合、受信者数分のポイント−ポイントコネクションを送信者から設定することになる。
【０００７】
この場合は、送信者が属性に応じて設定したコネクション数分だけのコピーを作成して各々のコネクションに送信する必要があること、通信網の送信者に近い部分（例えば送信者側ユーザ網インタフェース）の通信帯域を浪費している事などの問題がある。
【０００８】
すべての受信者に同一のサービス属性のポイント−マルチポイントコネクションを提供することの他の問題点として、一部の受信者への通信帯域が網内で確保できなかった場合がある。あるサービス属性を持つポイント−マルチポイントコネクションの受信者（枝；リーフ）を新たに追加しようとしても、その受信者への経路上でサービス属性を満たすだけの通信帯域が確保できないとその枝の追加は拒絶され、その受信者は情報をまったく受信できないことになる。
【０００９】
この場合にも別の通信属性（例えば通信品質の保証のまったくないサービス）のコネクションを送信者から受信者へ別に設定すれば情報の受信は可能になるが、送信者の情報コピーの負荷や通信網の送信者に近い部分の通信帯域の浪費の問題は残る。
【００１０】
【発明が解決しようとする課題】
このように従来ＡＴＭ通信網上でマルチキャスト通信を行なう際に、ひとつのポイント−マルチポイントコネクションにより情報転送すると、すべての受信者に同一のサービス属性を提供することになる。よって受信者毎のサービス属性要求の違いに柔軟に対処できないとか、一部の受信者への通信帯域が確保できない場合にはその受信者は情報をまったく受信できないなどの問題点がある。
【００１１】
また、これを解決するには、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じた複数のコネクションを設定してひとつのマルチキャスト通信を実現する方法も考えられるが、送信者での情報のコピーや通信網の送信者側での帯域の圧迫などの問題が残る。
【００１２】
本発明はこのような問題を解決するためになされるもので、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じたひとつのポイント−マルチポイントコネクションの形成を可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
本発明の第１の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣ（ＶｉｒｔｕａｌＣｈａｎｎｅｌ）リンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、この受信した設定要求に示されるもしくは対応して示される要求サービス属性が、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前段のノード装置から前記ノード装置へ向かう入力ＶＣリンクに提供されているサービス属性とは異なる場合に、前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とする。
【００１４】
この第１の発明は、新たな出力ＶＣリンクに割り当てられる通信リソース量を、前記入力ＶＣリンクに割り当てられている通信リソース量（提供されているサービス属性に対応するもの）とは異なるものにするものであり、この発明によれば、既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加することができ、ひとつのポイント−マルチポイントコネクションで受信者に応じて異なるサービス属性を提供することが可能になる。すなわち、既に存在するＶＣリンクに提供されているサービス属性と異なるサービス属性を要求する受信者を、ひとつのＶＣコネクションで新たに収容可能となる。
【００１５】
なお、前記要求サービス属性には、所定の通信品質を要求しない場合に相当するサービス属性を含み、この場合は、新たな出力ＶＣリンクに割り当てられる通信リソース量は０になる（リソースの割り当てを行わずにＶＣリンクを設定する）。
【００１６】
また、送信者が提供するサービス属性より大きいものを受信者が受けることはできないため、一般には、前記要求サービス属性は前記入力ＶＣリンクに提供されているサービス属性以下となる。但し、送信者が提供するサービス属性より小さなサービス属性を提供するＶＣリンクに、新たなＶＣリンクを追加する場合には、後述する入力ＶＣリンクの通信リソース量変更との順序関係により、前記要求サービス属性は前記入力ＶＣリンクに提供されていたサービス属性より大きくなることがある。
【００１７】
また、後述するように通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することを行う場合には、前記要求サービス属性は前記入力ＶＣリンクに提供されていたサービス属性より大きくなることがある。そのため、前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを設定させるのは、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置よりも送信者側のＶＣリンクの中に、該新たな出力ＶＣリンクに対応した要求サービス属性を満たさない通信リソース量が割り当てられているＶＣリンクが存在しない場合とすることが、リソースの効率的な利用という点では、好ましい。但し、このような場合でも要求サービス属性を満たす通信リソース量を割り当てておく方が好ましいこともある。
【００１８】
上記第１の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべき要求サービス属性が前記入力ＶＣリンクに提供されているサービス属性とは異なるならば、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、この設定される出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とする。
【００１９】
ここで、送信者が提供するサービス属性より小さなサービス属性を提供するＶＣリンクに、新たなＶＣリンクを追加する必要が生じたような場合は、次のようにすることが好ましい。すなわち、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つが入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性よりも、前記入力ＶＣリンクに提供されているサービス属性の方が、そのサービス属性に対応する通信リソース量が小さいならば、前記入力ＶＣリンクに割り当てられる通信リソース量を前記要求サービス属性に対応する量に変更する。
【００２０】
本発明の第２の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを構成するＶＣリンクのうち、前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクに割り当てている通信リソース量を記憶する記憶手段と、前記次段のノード装置を経由して既に通信情報を受信可能な各受信者に対して提供されているサービス属性及び新たに前記マルチキャスト通信サービスへ参加を要求した受信者に与えられるべき要求サービス属性のうち、もしくは、前記各受信者から既に提供されているサービス属性の変更を要求した受信者を除した受信者に対して提供されているサービス属性及び該変更を要求した受信者に与えられるべき要求サービス属性のうち、もしくは、前記各受信者から前記マルチキャスト通信サービスからの離脱を要求した受信者を除いた受信者に対して提供されているサービス属性のうち、そのサービス属性に対応する通信リソース量が最も大きいものを検出する検出手段と、この検出手段の検出結果の示す通信リソース量が前記記憶手段により記憶された通信リソース量と異なる場合に、前記出力ＶＣリンクに割り当てている通信リソース量を変更する手段とを備えたことを特徴とする。
【００２１】
この第２の発明によれば、新たに参加する受信者のために既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加する場合に、既に存在するＶＣリンクのリソース量を必要に応じて変更することで、受信者に応じて異なるサービス属性を提供するひとつのポイント−マルチポイントコネクションを効率良く形成することができる。また、受信者に応じて異なるサービス属性をひとつのポイント−マルチポイントコネクションで提供するにあたり、既に参加している受信者に対する通信品質の変更がサービス提供中に要求された場合や、既に参加している受信者が離脱して対応するＶＣリンクが削除される場合に、存在する各ＶＣリンクにおいて必要最小限の通信リソース量を確保することができる。
【００２２】
なお、前記サービス属性には、所定の通信品質を要求しない場合に相当するサービス属性を含み、これに対応する通信リソース量は０になる（リソースの割り当てを行わずにＶＣリンクを設定することに相当）。
【００２３】
ここで、前記検出手段は、例えば、前記次段のノード装置を経由して既に通信情報を受信可能な各受信者に対して提供されているサービス属性を示す情報を記憶する手段の記憶内容を参照して検出を行うことができる。
【００２４】
この記憶する手段は、各受信者に対して提供されているサービス属性を示す情報として、新たに前記マルチキャスト通信サービスへ参加を要求した受信者に与えられるべき要求サービス属性、もしくは、既に提供されているサービス属性の変更を要求した受信者に与えられるべき要求サービス属性を各受信者毎に記憶するものであってもよいし、後述するように通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することを行う場合には、各受信者に対して提供されているサービス属性（もしくはこれに対応する通信リソース量）に加えて、上記の要求サービス属性を記憶するものであってもよい。
【００２５】
上記第２の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを、該マルチキャスト通信サービスに対し新たに参加を要求した受信者もしくは既に受けている該サービスのサービス属性の変更を要求した受信者のために、もしくは該サービスからの離脱を要求した受信者に起因して、変更するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクの通信リソース量が、新たに参加を要求した受信者への通信がこのＶＣリンクを用いる場合に該受信者に与えられるべき要求サービス属性を満たすか否か、もしくは、該ＶＣリンクを用いて既に通信情報を受信可能な各受信者からサービス属性の変更を要求した受信者を除いた受信者に対して提供されているサービス属性及び該変更を要求した受信者に与えられるべき要求サービス属性のうちそのサービス属性に対応する通信リソース量が最も大きいものに対応するか否か、もしくは、前記各受信者から離脱を要求した受信者を除いた受信者に対して提供されているサービス属性のうちそのサービス属性に対応する通信リソース量が最も大きいものより大きいか否かを判断し、この判断結果に基づいて前記ＶＣリンクに割り当てている通信リソース量を変更することを特徴とする。
【００２６】
本発明の第３の発明は、通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することに関する。
【００２７】
第３の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、この受信した設定要求に示されるもしくは対応して示される要求サービス属性に対応する第１の通信リソース量を割り当てた新たな出力ＶＣリンクが設定できない場合に、新たな出力ＶＣリンクが設定可能な第２の通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とする。
【００２８】
この第３の発明によれば、既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加することができ、ひとつのポイント−マルチポイントコネクションで受信者に応じて異なるサービス属性を提供することが可能になる。すなわち、新たな受信者の参加のためにノードが受信した設定要求の要求サービス属性をリソース量不足により満たせなかった場合に、要求属性は満足しないが収容できる範囲内のリソース量でサービスを行なうことで、最低限コネクティビティだけでも提供することが可能となる。
【００２９】
なお、ＶＣリンクに割り当てられる第２の通信リソース量を０（リソースの割り当てを行わずにＶＣリンクを設定する）としても、収容できる範囲内のリソース量を求めてその値としてもよいが、前者の方が処理が簡単である。
【００３０】
上記第３の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべきサービス属性に対応する第１の通信リソース量を割り当てたＶＣリンクが設定不可能ならば、前記第１の通信リソース量より小さいかあるいは０である第２の通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、この設定された出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とする。
【００３１】
この場合に、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記入力ＶＣリンクに対する出力ＶＣリンクに割り当てられている通信リソース量のうち、前記第２の通信リソース量より大きなものが存在するか否かを調べ、存在しない場合には、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更することが、リソースの効率的な利用の点では、好ましい。
【００３２】
さらに、リソース量不足が解消したときには本来の要求サービス属性を提供するために、次の手段を採ってもよい。すなわち、前記第１の通信リソース量を割り当てたＶＣリンクが設定できないために前記第２の通信リソース量が割り当てられていることが記憶されている場合に、前記第１の通信リソース量の割り当てが可能になったか否かを調べ、可能になっていれば前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更するのである。
【００３３】
このことは、第３の発明のマルチキャスト通信制御方法で、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更し、この通信リソース量の変更された出力ＶＣリンクを入力ＶＣリンクとし、前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶＣリンクが出力ＶＣリンクとなる場合に、割り当てが可能であれば前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶＣリンクがなるべき出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更することを意味する。
【００３４】
また、あるノードでリソース量不足して要求サービス属性を満たさないリソース量が割り当てられたときにそのノードの上流でもリソースの効率的な利用のためにリソース量の変更を行うのであれば、リソース量不足が解消したときには本来の要求サービス属性を提供するためには、以下のようにするとよい。前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更する。それとともに、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更したならば、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更するときに、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第１の通信リソース量に変更するのである。
【００３５】
また、本発明（請求項１７）は、入力ＶＣリンクと複数の出力ＶＣリンクを用い、送信者から複数の受信者に通信データを送信するマルチキャスト通信サービスを提供可能なノード装置において、マルチキャスト通信サービスに用いられるポイント−マルチポイントコネクションを維持する維持手段と、このマルチキャスト通信サービスのための新たな出力ＶＣリンクの設定要求、及び、この新たなＶＣリンクに対する要求サービス属性を受信する受信手段と、この設定要求に応え、前記要求サービス属性を調べ、入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを前記ポイント−マルチポイントコネクションに加える設定手段とを具備することを特徴とする。
【００３６】
本発明（請求項１８）は、請求項１７記載のノード装置において、前記設定手段は、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００３７】
本発明（請求項１９）は、請求項１７記載のノード装置において、前記設定手段は、前記要求サービス属性を満たす通信リソース量が確保できない場合に、前記入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００３８】
本発明（請求項２０）は、入力ＶＣリンクと出力ＶＣリンクを用い、送信者から複数の受信者に通信データを送信するマルチキャスト通信サービスを提供可能なノード装置において、マルチキャスト通信サービスに用いられるポイント−マルチポイントコネクションを維持する維持手段と、出力ＶＣリンクに割り当てられた通信リソース量を示す情報を記憶する記憶手段と、この出力リンクの通信リソース量を変更する必要があるか否かを、前記マルチキャスト通信サービスに対する新たな受信者の参加要求、もしくは既に受信可能となっている受信者のサービス属性変更要求、もしくは受信者の離脱要求に応えて、決定する決定手段と、必要があると決定された場合に、出力ＶＣリンクに割り当てられている通信リソース量を変更する手段とを具備することを特徴とする。
【００３９】
本発明（請求項２１）は、請求項１７記載のノード装置において、前記受信手段は、前記要求サービス属性を含む前記設定要求を受信するものであり、前記設定手段は、この設定要求をデータリンク層で処理し、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００４０】
本発明（請求項２２）は、請求項１７記載のノード装置において、前記受信手段は、前記要求サービス属性を含むメッセージを受信するものであり、前記設定手段は、このメッセージをネットワーク層で処理し、この処理結果に基づいて前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００４１】
本発明（請求項２３）は、請求項２０記載のノード装置において、出力ＶＣリンクの先の次段ノードから、この出力ＶＣリンクを通して前記マルチキャスト通信サービスを受信可能となる受信者に対して提供されているサービス属性のうち最大のものを示すメッセージを受信する手段を更に具備し、前記決定手段は、このメッセージを参照して決定を行なうものであることを特徴とする。
【００４２】
本発明（請求項２４）は、請求項２３記載のノード装置において、入力ＶＣリンクの先の前段ノードへ、この入力ＶＣリンクを通して前記マルチキャスト通信サービスを受信可能となる受信者に対して提供されているサービス属性のうち最大のものを示すメッセージを送信する手段を更に具備することを特徴とする。
【００４３】
【発明の実施の形態】
以下、本発明の実施の一形態について説明する。
【００４４】
図１は本発明に関わるＡＴＭノードに具備されるコネクション制御部の機能構成例を示したものである。コネクション制御部１０は、シグナリングメッセージ処理部１１、コネクション状態管理部１２、経路制御部１３、アドミッション制御部１４、リンク状態管理テーブル１５、コネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７を含んでいる。
【００４５】
シグナリングメッセージ処理部１１は、端末もしくは隣接ＡＴＭノードとの間でコネクション制御に関わる各種メッセージをやりとりし、その結果生じるイベントをコネクション状態管理部１２に通知する。コネクション状態管理部１２は、通知されたイベントに基づき経路制御部１３やアドミッション制御部１４や各種テーブルからの情報を利用しつつ必要な処理を行ない、その結果をテーブルに書き込むとともにシグナリングメッセージ処理部１１へも通知する。
【００４６】
経路制御部１３は、制御するコネクションの次段ＡＴＭノードを自身の持つ経路情報をもとに決定するか、あるいはメッセージに含まれた経路指定情報をもとに決定するなどの機能をもつ。アドミッション制御部１４は、制御メッセージ内のサービス属性情報などをもとに必要リソース量の算出等を行なうとともに、新たなコネクションの収容可否やコネクション属性変更の可否などの判断を行なう。
【００４７】
リンク状態管理テーブル１５は、前記アドミッション制御部１４が判断を行なうために必要な情報（出力リンクの容量、使用率など）を管理している。
【００４８】
コネクション別割り当てリソース管理テーブル１６は、各ＡＴＭノードにおいて各ＶＣリンクに割り当てているリソース量を管理しているとともに、後述するように、そのＡＴＭノードにおいて前段ＡＴＭノードが割り当てているリソース量（正確にはそのＶＣリンクに与えるべきサービス属性を満たすもの）と同等のリソース量を割り当てることができたか否かを示す情報を持つことができる。
【００４９】
受信者別サービス属性管理テーブル１７は、各ＡＴＭノードにおいて関与する各ＶＣリンクの各々の受信者に与えるべき要求サービス属性をすべての受信者について管理しているとともに、後述するように、その要求サービス属性がそのＡＴＭノードを通過する時点において満たされているか否かを示す情報を持つことができる。
【００５０】
本発明に関わるＡＴＭノードは、ＡＴＭスイッチには限定されない。例えば、各ノードをセルスイッチルータ（以下、“ＣＳＲ”と言う）として構成してもよい。ＣＳＲとは、ネットワーク層（例えばＩＰ）処理手段とＡＴＭスイッチとを備え、ホストもしくは隣接ルータ（ＣＳＲ）とネットワーク層で処理されるメッセージを交換する。ＣＳＲは、このメッセージに基づき、ＣＳＲ内のＡＴＭスイッチを通るカットスルーコネクション（異なる論理ネットワーク間をデータリンク層で接続するコネクション）を形成し、ＩＰフォワーディングをバイパスしてデータを転送する。
【００５１】
（具体例１）
まず本発明の第１の具体例として、マルチキャスト通信の受信者により要求するサービス属性が異なる場合のポイント−マルチポイントコネクション（以下、ｐ−ｍｐ ＶＣと表す）の設定、受信者の追加（参加）、受信者の要求属性変更、受信者の削除（離脱）時の手順について説明する。
【００５２】
ＡＴＭ通信網の構成例と、各場合におけるｐ−ｍｐ ＶＣの構成の時間的変化の様子の例を図２、図３に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の時間的変化の様子を図４、図５に示す。
【００５３】
従来の方法との大きな違いはすでに存在するＶＣに提供されているサービス属性と異なるサービス属性を要求する受信者を新たに収容可能とし、しかもそれを効率良く行なうために、各ＶＣリンク（エンドエンドのＶＣコネクションのうちの隣接ＡＴＭノード間の部分）において必要最小限のリソースを確保することにある。
【００５４】
まず図２（ａ）において、送信者１０１から受信者２０１へのポイント−ポイントコネクション（以下、ｐ−ｐ ＶＣと表す）が設定されている（呼識別子を１０とする）。呼識別子は、各ＡＴＭノードが、自分の管理するＶＣリンクがどのｐ−ｍｐ ＶＣに属するものであるかを識別するためのものである。また、上記ｐ−ｐ ＶＣは、以降のｐ−ｍｐ ＶＣへの拡張を考慮して、受信者２０１から送信者１０１へのリソースは０にしておくことが好ましい。なお、既に設定されているのがｐ−ｍｐ ＶＣであっても以降の手順は同様である。
【００５５】
この際、受信者から送信者へ、アプリケーションレベルの通信品質（以下、ＱｏＳと表す）の要求が、例えばネットワーク層（例えばＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ））レベルの帯域予約プロトコル（例えばＲＳＶＰ（Ｒｅｓｏｕｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ））などで行なわれており、このＱｏＳ要求を受け取った送信者は、そのＱｏＳ要求を満たすに十分なＡＴＭレベルのサービス属性（サービスクラス、トラヒックディスクリプタ、セルレベルのＱｏＳなど）を設定して、ＶＣ設定要求を行なっている。
【００５６】
このＶＣ設定要求は、送信者から受信者へ向けて順次途中のＡＴＭノードへ転送される。そして、このＶＣ設定要求に含まれるあるいは対応して別送される、ＡＴＭレベルの要求サービス属性情報を含むメッセージが、上記制御メッセージに相当する。なお、この制御メッセージは、上記のように送信者が発し、受信者へ向けて順次転送してもよいし、アプリケーションレベルのＱｏＳ要求の生じた受信者が発し、送信者へ向けて順次転送するようにしてもよい。
【００５７】
また、受信者にて生じたアプリケーションレベルのＱｏＳ要求を受けずに、送信者にて受信者に与えられるべき要求サービス属性を適当に決定し、上記制御メッセージを含むＶＣ設定要求を受信者へ向けて順次転送するのでもよい。
【００５８】
ＡＴＭノード３０１，３０２は、このＶＣ設定要求（あるいは他の制御メッセージ）を受け、上記要求サービス属性を満足するように出力リンク（物理的なリンクあるいは物理リンクを論理的に分割したＶＰ（バーチャルパス））におけるＶＣのリソースを確保し、それを記憶する。この時のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７の内容は、それぞれ図４の（ａ）の４０１，４０２に示すようになる。ここでは割り当てリソース量として簡単のために通信帯域のみを示したが、バッファ量など他のパラメータが含まれても構わない。
【００５９】
次にこのｐ−ｐ ＶＣ（呼識別子１０）に新たな受信者２０２が加わる場合について説明する。受信者が存在中のＶＣに加わる方法は、ＡＴＭのシグナリングに規定されているリーフ主導型のコネクション参加要求を受信者が送信者に対して送出する方法でも良いし、インタネットプロトコル（ＩＰ）が上位層にいる場合（すなわち送信者、受信者がＩＰホストかルータの場合）にはＩＰのマルチキャストグループ参加要求メッセージやマルチキャスト用ルーティング情報交換メッセージを受信者が送信者または何らかのサーバに送信し、送信者がそれを知るとＡＴＭシグナリングのパーティ追加要求で受信者の追加を要求する方法でも良い。なお、上記コネクション参加要求やパーティ追加要求は、対応するＡＴＭノード装置にとって新たな出力ＶＣリンクの設定要求となるものの一例である。
【００６０】
この新たな受信者２０２は、特定のＱｏＳの要求はせずベストエフォット型の通信を希望するものとする。新たな受信者がＱｏＳの要求をしているか否か、している場合はそのＱｏＳの内容を示す情報は、上記リーフ主導型のコネクション参加要求を用いる場合には、ＡＴＭレベルの要求サービス属性としてコネクション参加要求に含まれていてもよいし、ＡＴＭレベルの要求サービス属性情報を含む制御メッセージを、新たな受信者あるいはＲＳＶＰ等を用いて受信者のＱｏＳ要求を知った送信者が、コネクション参加要求に対応して別送するのでもよい。このようなコネクション参加要求や他の制御メッセージが転送されることにより、各ＡＴＭノードは新たな受信者の要求サービス属性を知ることができる。
【００６１】
また、上記ＩＰのマルチキャストグループ参加要求メッセージ等を用いる場合には、このＩＰの参加要求メッセージに新たな受信者のＱｏＳ要求が含まれているか、受信者のＱｏＳ要求を示すＲＳＶＰメッセージを受け取るかすることにより、新たな受信者のＱｏＳ要求を知った送信者が、パーティ追加要求にＡＴＭレベルの要求サービス属性を含ませて送出してもよいし、ＡＴＭレベルの要求サービス属性情報を含む制御メッセージを、新たな受信者もしくは上記送信者が、パーティ追加要求に対応して別送するのでもよい。このようなパーティ追加要求や他の制御メッセージが転送されることにより、各ＡＴＭノードは新たな受信者の要求サービス属性を知ることができる。
【００６２】
なお、上記パーティ追加要求は、送信者から既にリーフが存在する区間はパーティ追加要求として転送され、新たなリーフを設定することになる分岐点より先の新たな受信者までの区間はコネクション設定要求（ＶＣ設定要求）として転送される。
【００６３】
各ノードとしてＣＳＲを採用する場合には、ＩＰレベルの要求サービス属性情報を含むメッセージが、新たな受信者（例えばＲＳＶＰを用いる場合）もしくは送信者により送信され、各ノードは、このメッセージをＩＰ処理することにより、対応する出力ＶＣリンクに対するＡＴＭレベルの要求サービス属性を求めることができる。
【００６４】
以下では、ＡＴＭシグナリングのパーティ追加要求を用い、この中に要求サービス属性情報を含ませる場合を例に取り説明を進める。この場合、送信者１０１は呼識別子１０で識別される受信者２０１宛のｐ−ｐ ＶＣへの新たな受信者２０２の追加を、パーティ追加要求を用いて要求する。この際、このパーティ追加要求に含ませる要求サービス属性として、ＵＢＲ（Ｕｎｓｐｅｃｉｆｉｅｄ Ｂｉｔ Ｒａｔｅ）サービスを指定する。パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報やその要求サービス属性情報をもとにその経路を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向へ新たなＶＣのリーフ（ＶＣリンク）を作成するためにＶＰＩ／ＶＣＩ値の確保（ここでは８０／４０）を行なう。
【００６５】
ここで、ＵＢＲサービスを受信者２０２へ提供する場合を考えているので、コネクション別割り当てリソース管理テーブル４０１における新たなリーフへの割り当てリソース量はゼロとなる。受信者別サービス属性管理テーブル４０２にも新たな出力リンク２の上のＶＰＩ／ＶＣＩ−８０／４０に対応する受信者２０２のサービス属性情報を追加する。そしてＡＴＭノード３０１は次段ＡＴＭノード３０３へコネクション設定要求を送出する。
【００６６】
この時点での各管理テーブルへの情報の追加は仮のものであり、後の下流からＶＣ設定確認が来た時点でそれらの追加が確定するか、あるいは設定に失敗し解放要求が下流から戻ってくれば、管理テーブルへの仮の追加状態を解除する。この段階で追加が確定すると、各テーブル１６，１７は、図４の（ｂ）に示すようになる。
【００６７】
ＡＴＭノード３０３，３０４では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量ゼロ）と受信者別サービス属性管理テーブル（サービス属性はＵＢＲ）に新たな追加が行なわれる。このようにして受信者２０２までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１が分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【００６８】
ここで、図２（ｂ）に示すように、送信者−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、３０２−受信者２０１間の割り当て帯域は１０Ｍｂｐｓとなるが、新しく追加したＡＴＭノード３０１−３０３間、３０３−３０４間、３０４−受信者２０２の割り当て帯域はゼロとなる。
【００６９】
次にこのｐ−ｍｐ ＶＣ（呼識別子１０）にさらに新たな受信者２０３が加わる場合について説明する。この受信者２０３は、２０１と同様に所定のＱｏＳを要求しているものとする。送信者１０１は、呼識別子１０で識別されるｐ−ｍｐＶＣへの新たな受信者２０３の追加を、ＡＴＭシグナリングのパーティ追加要求を用いて要求する。この際、受信者のために要求するサービス属性として、ＣＢＲサービス、セル廃棄率１０−８などと言ったものを指定する。
【００７０】
パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報や要求サービス属性情報をもとに、あるいはあらかじめパーティ追加要求内に明示的に示された経路情報をもとに、次段ＡＴＭノード３０３（出力リンク２）を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向への呼識別子１０に相当するＶＣのリーフ（ＶＣリンク）の存在の有無をコネクション別割り当てリソース管理テーブル（図４（ｂ））により調べ、すでに存在する（ＶＰＩ／ＶＣＩ＝８０／４０）事を確認する。
【００７１】
ただし、コネクション別割り当てリソース管理テーブル内の割り当てリソース量がゼロになっているため、このＶＣリンクは受信者２０３の要求サービス属性を満たすことはできない。ＡＴＭノード３０１では要求サービス属性を満たすために必要な割り当てリソース量を算出し、割り当てが可能であると確認すると、コネクション別割り当てリソース管理テーブルの割り当てリソース量の内容をゼロから例えば１０Ｍｂｐｓに書き換える（図４（ｃ））。
【００７２】
それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）を、割り当てたリソース量に合うように変更する。受信者別サービス属性管理テーブルには新たに受信者２０３のサービス属性情報（呼識別子１０、出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０、サービス属性＝｛ＣＢＲ，１０Ｍｂｐｓ、ＣＬＲ１０−８｝など）を加える。そして次段ＡＴＭノード３０３にパーティ追加要求を送出する。
【００７３】
ＡＴＭノード３０３はパーティ追加要求を受信すると次段ＡＴＭノード３０５へのＶＰＩ／ＶＣＩの捕捉、通信リソースの確保（ここでは１０Ｍｂｐｓ）を行なうとともにＡＴＭノード内のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容を更新し、さらに次段ＡＴＭノード３０５へコネクション設定要求を送出する。
【００７４】
ＡＴＭノード３０５，３０６では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量１０Ｍｂｐｓ）と受信者別サービス属性管理テーブル（ＣＢＲ）に新たな追加が行なわれる。このようにして受信者２０３までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１，３０３で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【００７５】
ここで、図２（ｃ）に示すように、ＡＴＭノード３０３−３０４間、ＡＴＭノード３０４−受信者２０２間のＶＣリンクの割り当て帯域はゼロとなるか、残りのすべてのＶＣリンクには１０Ｍｂｐｓの帯域を割り当てられている。
【００７６】
なお、上記で説明した一つの受信者は、一つのＡＴＭグループアドレスに属する複数の受信者であってもよい。この場合は、一つのＡＴＭグループアドレスに属する複数の受信者には同じＱｏＳが提供されることになる。
【００７７】
以上述べた本実施形態における受信者の追加時のＡＴＭノードの処理アルゴリズムを、図６を用いて整理する。
【００７８】
まず、ＡＴＭノードは前段ＡＴＭノードまたは送信者から、既存のＶＣへのパーティ追加要求を図１のシグナリングメッセージ処理部１１において受信する（Ｓ６０１）。次にそれをコネクション状態管理部１２へ渡し、コネクション状態管理部１２が、受信したパーティ追加要求内の宛先（受信者）アドレスや要求サービス属性あるいは経路指定情報などをもとに、経路制御部１３に次段ＡＴＭノードを問い合わせ、経路制御部１３が、次段ＡＴＭノードを決定する（Ｓ６０２）。
【００７９】
コネクション状態管理部１２は、その次段ＡＴＭノードへの出力リンクにパーティ追加要求に対応するＶＣのリーフが既に存在するかを調べ（Ｓ６０３）、存在しないならば、アドミッション制御部１４に、要求サービス属性から算出された割り当てリソース量の収容が可能かどうか問い合わせる。アドミッション制御部１４はリンク状態管理テーブル１５の情報をもとに収容可否を判断し、コネクション状態管理部１２へ通知する。コネクション状態管理部１２はリーフの追加が可能であるとわかると、割り当てリソース管理テーブル１６に、要求サービス属性から算出された割り当てリソース量とともに、新たなリーフを仮追加し（Ｓ６０９）、サービス属性管理テーブル１７に新規受信者についての情報を仮追加し（Ｓ６１０）、次段ノードへＶＣ設定要求を送信する（Ｓ６１１）。
【００８０】
リーフが既に存在する場合には、既存のリーフの割り当てリソース量より新規要求サービス属性に必要なリソース量の方が大きいかを調べ（Ｓ６０４）、大きくない場合はそのままとし（Ｓ６０６）、大きい場合は、新規追加の場合と同様に、アドミッション制御部１４にリソース変更の可否を問い合わせ、可能であるとわかると、そのリーフの割り当てリソース管理テーブル１６の内容を、新規要求サービス属性を満たすリソース量に仮変更する（Ｓ６０５）。Ｓ６０５では、リソース量の仮変更を行うリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）も変更する。
【００８１】
Ｓ６０４では、既存のリーフの割り当てリソース量が、次段ノードを経由して既にサービスを受けている受信者に対し提供されているサービス属性のうち最も大きいものに対応していることから、結果的に、次段ノードを経由して既にサービスを受けている受信者に対し提供されているサービス属性及び新規参加者に与えられるべきサービス属性のうち対応するリソース量が最も大きいものを検出し、これと既存のリーフの割り当てリソース量とを比較していることになる。そして、この比較結果にかかわらず、サービス属性管理テーブル１７への新規受信者についての情報の仮追加（Ｓ６０７）と、次段ノードへのパーティ追加要求の送信（Ｓ６０８）が行われる。
【００８２】
最後に、ＶＣ設定、パーティ追加が実際に行われたか拒絶されたかを下流からの通知により知り（Ｓ６１２）、仮変更や仮追加の内容を確認する（Ｓ６１３）か、取り消す（Ｓ６１４）。
【００８３】
上述したように、ｐ−ｐ ＶＣあるいはｐ−ｍｐ ＶＣに新たな受信者を追加する際には、出力リンク上にそのＶＣのリーフが存在しない場合には、追加する受信者に与えるべきサービス属性を満たすために必要な通信リソース量を割り当てて新たなリーフを追加し、リンク上にすでにそのＶＣのリーフが存在する場合には、そのリーフに割り当てられている通信リソース量と追加する受信者に与えるべきサービス属性を満たすために必要な通信リソース量のうち大きな方をそのリーフの新たな割り当てリソース量とする。
【００８４】
これを、上述の例では、ＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）サービスに対応するリソースを割り当てたｐ−ｍｐ ＶＣの途中のリーフからＵＢＲサービスに対応する属性（リソース割り当てなし）に変わる場合について示しているが、ＶＢＲ（Ｖａｒｉａｂｌｅ Ｂｉｔ Ｒａｔｅ）サービスに対応するｐ−ｍｐ ＶＣが途中のリーフからＵＢＲサービスに対応する属性（リソース割り当てなし）に変わる場合等でも同様に行なえる。
【００８５】
但し、例えばＣＢＲサービスに対応するｐ−ｍｐ ＶＣが途中のリーフからＶＢＲサービスに対応する帯域割り当てに変わるような場合には、その分岐するＡＭＴノードにおいて、ＶＢＲとして規定されたトラヒックパラメータに従うようにトラヒックのシェイピングを行なう必要がある。
【００８６】
次にこのｐ−ｍｐ ＶＣ（呼識別子１０）の受信者２０３のサービス属性を通信中に変更する場合について説明する。受信者２０３は要求サービス属性をＱｏＳ有りからＱｏＳなし（ＵＢＲ）に変更するものとする。送信者１０１は自身の独自の判断か、あるいは受信者からの要求サービス属性変更の意思（ＲＳＶＰレベルのメッセージなど）を認識することにより、呼識別子１０で示されるｐ−ｍｐ ＶＣの受信者２０３に与えるＡＴＭレベルのサービス属性の変更を、ＡＴＭシグナリングの属性変更要求（呼識別子、受信者のアドレス、変更したい属性値などを含む）を用いて要求する。あるいは、受信者２０３が、自身の意思を反映したＡＴＭレベルの要求サービス属性情報を含む制御メッセージを属性変更要求として送出するのでもよい。
【００８７】
属性変更要求を受信したＡＴＭノード３０１は、受信した情報をもとに変更に関わる次段ノードへのリーフに必要な割り当てリソース量を受信者別サービス属性管理テーブル１７により再評価する。
【００８８】
この再評価は、次のように行われる。すなわち、次段のノード３０３を経由して既にサービスを受けている受信者（２０２，２０３）からＱｏＳの変更を要求した受信者（２０３）を除いた受信者（２０２：この場合は一つだが複数の場合もある）に提供されているサービス属性のうち対応するリソース量が最も大きいものと、ＱｏＳの変更を要求した受信者（２０３）に与えられるべき（変更後の）要求サービス属性に対応するリソース量とのうち、最も大きなものを求める。そして、その求めた結果が現在の割り当てリソース量と異なる場合は、割り当てリソース量の変更が必要と判断する。
【００８９】
再評価の結果、割り当てリソース量の変更が必要な場合には、リソース量の変更が可能である事を確認した後、コネクション別割り当てリソース管理テーブル１６の割り当てリソース量の内容を書き換える（図５（ｄ）では１０Ｍｂｐｓから０Ｍｂｐｓに書き換える）。それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）も変更する。
【００９０】
受信者別サービス属性管理テーブル１７の呼識別子１０に属する受信者２０３のサービス属性の内容もＵＢＲに変更する。そして次段ＡＴＭノード３０３に属性変更要求を送出する。
【００９１】
ＡＴＭノード３０３は属性変更要求を受信すると、ＡＴＭノード３０１と同様の手順で変更に関わるリーフに必要な割り当てリソース量を受信者別サービス属性管理テーブル管１７により再評価する。ＡＴＭノード３０３では変更に関わるリーフの受信者が２０３のみであるので、受信者２０３のサービス属性に必要なリソースがそのリーフに必要なリソースになる。リソース量の変更が可能であれば、コネクション別割り当てリソース管理テーブル１６と受信者別サービス属性管理テーブル１７の内容を更新し、さらに次段ＡＴＭノード３０５へ属性変更要求を送出する。
【００９２】
ＡＴＭノード３０５，３０６ではｐ−ｐ ＶＣの属性変更とまったく同様の方法で属性変更手順が実施される。このようにして、送信者１０１から受信者２０３までのＶＣの属性変更が実施されることになる。
【００９３】
ここで、図３（ｄ）に示すように、送信者１０１−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、ＡＴＭノード３０２−受信者２０１間のＶＣリンクの割り当て帯域は１０Ｍｂｐｓとなるが、残りのすべてのＶＣリンクの割り当て帯域はゼロとなる。
【００９４】
なお、ここではＱｏＳを減らす方向の要求がなされた場合を説明したが、増やす方向の要求がなされた場合も同様である。
【００９５】
以上述べた本実施形態における受信者のサービス属性変更時のＡＴＭノードでの処理アルゴリズムを、図７を用いて整理する。
【００９６】
属性変更要求を受信した（Ｓ７０１）ＡＴＭノード３０１のコネクション状態管理部１２は、受信した情報をもとに、受信者別サービス属性管理テーブルの対応する部分のサービス属性値を変更した場合の、変更に関わる次段ノードへのリーフに必要な割り当てリソース量を再評価する（Ｓ７０２，７０３）。この再評価はそのリーフの先の受信者の中で最も大きなリソースを必要とするものを認識することを意味する。
【００９７】
再評価の結果、割り当てリソース量の変更が必要な場合には、アドミッション制御部１４に対して変更したい割り当てリソース量の収容が可能かどうか問い合わせる。アドミッション制御部１４はリンク状態管理テーブル１５の情報をもとに収容可否を判断し、コネクション状態管理部１２へ通知する。コネクション状態管理部１２は属性変更に伴う割り当てリソースの変更が可能であるとわかると、そのリーフの割り当てリソース管理テーブル１６の内容を、変更後の割り当てリソース量に仮変更する（Ｓ７０４）。そして、再評価の結果にかかわらず、サービス属性管理テーブル１７中の変更対象受信者についての情報を仮変更し（Ｓ７０５）、次段ノードへ属性変更要求を送信する（Ｓ７０６）。
【００９８】
最後に、属性変更が実際に行われたか拒絶されたかを下流からの通知により知り（Ｓ７０７）、仮変更や仮追加の内容を確定する（Ｓ７０８）か、取り消す （Ｓ７０９）。
【００９９】
さらに、受信者をｐ−ｍｐ ＶＣから外す場合（図３（ｅ））には、各ＡＴＭノードにおいて受信者別サービス属性管理テーブル１７の内容の削除を行ない、その結果をもとに各出力リンクにおけるＶＣのリーフへの割り当てリソース量を決定する。
【０１００】
すなわち、次段のノード（３０１）を経由してサービスを受けていた受信者 （２０１，２０２，２０３）から離脱を要求した受信者（２０１）を除した受信者（２０２，２０３）に提供されているサービス属性のうち対応するリソース量が最も大きいものを求め、求めた結果が現在の割り当てリソース量と異なる場合は、割り当てリソース量の変更が必要と判断する。必要なら割り当てリソース管理テーブル１６の更新を行なう（図５（ｅ））。この例では残った受信者には割り当て帯域ゼロのサービス属性しか提供されていないため、送信者１０１−ＡＴＭノード３０１間のリーフをＵＢＲに変更する。
【０１０１】
次に本発明の他の具体例として、マルチキャスト通信の受信者により要求するサービス属性が異なる場合のｐ−ｍｐ ＶＣの設定、受信者の追加、受信者の要求属性変更、受信者削除時の他の手順について説明する。
【０１０２】
ＡＴＭ通信網の構成と、各場合におけるｐ−ｍｐ ＶＣの構成の時間的変化の様子は具体例１の図２、図３と同様である。本具体例において、図２におけるｐ−ｐ ＶＣの設定（ａ）、ｎｏｎ−ＱｏＳ受信者の追加（ｂ）の手順までは第１の具体例と同じ手順であるが、受信者別サービス属性管理テーブル４０２を必要としない点が具体例１と異なる。
【０１０３】
ＱｏＳを要求する受信者２０１、要求しない受信者２０２に対して設定されたｐ−ｍｐ ＶＣにさらに新たな受信者２０３が加わる場合について説明する。この受信者２０３は、２０１と同様に所定のＱｏＳを要求しているものとする。送信者１０１は、呼識別子１０で識別されるｐ−ｍｐ ＶＣへの新たな受信者２０３の追加を、ＡＴＭシグナリングのパーティ追加要求を用いて要求する。この際、受信者のために要求するサービス属性として、ＣＢＲサービス、セル廃棄率１０−８などと言ったものを指定する。
【０１０４】
パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報や要求サービス属性情報をもとに、あるいはあらかじめパーティ追加要求内に明示的に示された経路情報をもとに、次段ＡＴＭノード３０３（出力リンク２）を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向への呼識別子１０に相当するＶＣのリーフ（ＶＣリンク）の存在の有無をコネクション別割り当てリソース管理テーブル（図４（ｂ））により調べ、すでに存在する（ＶＰＩ／ＶＣＩ＝８０／４０）事を確認する。
【０１０５】
ただし、コネクション別割り当てリソース管理テーブル内の割り当てリソース量がゼロになっているため、このＶＣリンクは受信者２０３の要求サービス属性を満たすことはできない。ＡＴＭノード３０１では要求サービス属性を満たすために必要な割り当てリソース量を算出し、割り当てが可能であると確認すると、コネクション別割り当てリソース管理テーブルの割り当てリソース量の内容をゼロから例えば１０Ｍｂｐｓに書き換える（図４（ｃ））。
【０１０６】
それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）を、割り当てたリソース量に合うように変更する。そして次段ＡＴＭノード３０３にパーティ追加要求を送出する。具体例１と異なり、本具体例では受信者別サービス属性管理テーブルは保持する必要はない。ＡＴＭノード３０３はパーティ追加要求を受信すると次段ＡＴＭノード３０５へのＶＰＩ／ＶＣＩの捕捉、通信リソースの確保（ここでは１０Ｍｂｐｓ）を行なうとともにＡＴＭノード内のコネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ＡＴＭノード３０５へコネクション設定要求を送出する。
【０１０７】
ＡＴＭノード３０５，３０６では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量 １０Ｍｂｐｓ）に新たな追加（仮追加）が行なわれる。
【０１０８】
このようにして受信者２０３までコネクション設定メッセージが転送され、受信者２０３はコネクション設定を受け付ける場合には、コネクション設定確認メッセージを送信者１０１に向けて送信する。コネクション設定確認メッセージはＡＴＭノード３０６，３０５，３０３，３０１を経由して送信者１０１まで転送される（３０３から上流へはパーティ追加確認メッセージというメッセージ名に変わる。）
この確認メッセージを下流から受信したＡＴＭノードのうち、その受信したインタフェース以外にもそのｐ−ｍｐ ＶＣの下流のリーフが存在しているノードでは以下の処理を行なった後に、その他のノードではそのまま、上流に対して確認メッセージを転送する必要がある。
【０１０９】
まず、図２（ｃ）におけるＡＴＭノード３０３の場合、ＡＴＭノード３０５から受信したコネクション設定確認メッセージ内に、実際に確保された（要求サービス属性に対応する）リソース量に相当する情報が記入されており、そのリソース量に関する（３０３−３０５間のリンクの確保リソースに関する情報）と、そのｐ−ｍｐ ＶＣに関する他のリーフである３０３−３０４間のリンクの確保リソースに関する情報（コネクション別割り当てリソース管理テーブルを参照）のうち最大値を決定し、上流ノード３０１へ送出するパーティ追加確認メッセージ内にその値を確保リソース量に関する情報として記入する。
【０１１０】
具体的には、ＡＴＭノード３０５から受信したコネクション設定確認メッセージ内に記載された確保リソース量の情報は１０Ｍｂｐｓ、ＡＴＭノード３０４との間のリンクに確保されているリソース量は０Ｍｂｐｓとなっており、よって１０Ｍｂｐｓを確保リソース量として上流ノード３０１へのパーティ追加確認メッセージに記入する。
【０１１１】
ＡＴＭノード３０１においても同様の処理が行なわれる。すなわち、ＡＴＭノード３０３から受信したパーティ追加確認メッセージ内に記入された確保リソース情報（１０Ｍｂｐｓ）と、コネクション別割り当てリソース管理テーブルに記憶されているＡＴＭノード３０２との間のリーフの割り当てリソース情報（１０Ｍｂｐｓ）とをもとに、送信ノード１０１へのパーティ追加確認メッセージに記入する確保リソース情報（１０Ｍｐｂｓ）を決定する。
【０１１２】
このようにして送信者１０１までパーティ追加確認メッセージが到着した時点でＡＴＭノード３０１，３０３で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【０１１３】
本具体例によれば、各ノードは、各々ｐ−ｍｐ ＶＣについて自ノードの下流に存在する全受信者の要求サービス属性を記憶せずとも、各出力リーフの先に存在する受信者（新たに加わった受信者、サービス属性変更要求をした受信者を含み、離脱した受信者を除く）の中で最大の通信リソース量を要するサービス属性を知ることができる。
【０１１４】
そして、これ以降また新たに受信者が加わる場合には、上記のように知らされた最大のサービス属性と、新たに加わる受信者用の要求サービス属性とを比較すれば、出力リーフに提供すべき最大サービス属性を求めることができる。
【０１１５】
また、上記確認メッセージにより、ある受信者がサービス属性変更要求をする場合に、その受信者を除いた受信者に対して提供すべきサービス属性とその受信者に対して変更後に提供すべきサービス属性とのうち、最大のものを知ることができ、出力リーフの割り当てリソースをこの求めた最大のサービス属性に対応するものに変更することができる。
【０１１６】
ある受信者が離脱する場合に、その受信者を除いた受信者に対して提供すべきサービス属性のうち最大のものも、同様に知って、出力リーフのリソース変更ができる。
【０１１７】
なお、上記確認メッセージの代わりに、ソフトステートで定期的に、各ノードの全出力リーフの先に存在する受信者の中で最大の通信リソース量を要するサービス属性を示すメッセージを上流ノードへ送るようにしても、同等のことが実現できる。
【０１１８】
ノードにＣＳＲを用いる場合には、このメッセージとしてＲＳＶＰを利用することもできる。
【０１１９】
（具体例２）
次に、本発明の他の例として、ｐ−ｍｐ ＶＣの設定時に要求するサービス属性を満たすためのリソース量が網内で確保できなかった場合の、ＡＴＭノードでの手順について説明する。帯域不足発生の箇所とその際のＡＴＭノードの動作の違いにより、３通りの場合について以下で説明する。なお、ここでは本例において特徴的な事項を説明するが、具体例１に述べた実施形態上の種々の変形は、本例においても適宜適用することができる。
【０１２０】
まず帯域不足の第１の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図８に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図９に示す。
【０１２１】
従来の方法との大きな違いは、コネクション設定、パーティ追加などの要求をＡＴＭノードが受信し、そのサービス属性要求を帯域不足により満たせなかった場合に、各要求を単に拒絶するのではなく、要求属性は満足しないが収容できる範囲内の帯域（あるいは帯域なし）でサービスを行なうことで、最低限コネクティビティだけでも提供することを可能にすることにある。
【０１２２】
まず図８（ａ）において、送信者１０１から受信者２０１へのｐ−ｐ ＶＣが設定されている（呼識別子を１０とする）。この際、受信者から送信者へアプリケーションレベルのＱｏＳの要求が、例えばネットワーク層（例えばＩＰ）の帯域予約プロトコル（例えばＲＳＶＰ）などで行なわれており、そのＱｏＳ要求を受けとった送信者はそのＱｏＳ要求を満たすに十分なＡＴＭレベルのサービス属性（サービスクラス、ピークセルレート、セルレベルのＱｏＳなど）を設定してＶＣ設定要求を行なっている。
【０１２３】
ＡＴＭノード３０１，３０２は要求されたサービス属性を満足するように出力リンク（物理的なリンクあるいは物理リンクを論理的に分割したＶＰ）におけるＶＣのリソースを確保し、それを記憶している。この時のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７の内容は、それぞれ図９の（ａ）の４０１，４０２に示すようになる。ここでは割り当てリソース量として簡単のために帯域のみを示したが、バッファ量など他のパラメータが含まれていても構わない。
【０１２４】
次にこのｐ−ｐ ＶＣ（呼識別子１０）に新たな受信者２０２が加わる場合について説明する。受信者が存在中のＶＣに加わる方法は、ＡＴＭのシグナリングに規定されているリーフ主導型のコネクション参加要求を受信者が送信者に対して送出する方法でも良いし、インタネットプロトコル（ＩＰ）が上位にいる場合（すなわち送信者、受信者がＩＰホストかルータの場合）にはＩＰのマルチキャストグループ参加要求メッセージやマルチキャスト用ルーティング情報交換メッセージを受信者が送信者または何らかのサーバに送信し、送信者がそれを知るとＡＴＭシグナリングのパーティ追加要求で受信者の追加を要求する方法でも良い。
【０１２５】
この新たな受信者２０２は、すでに接続されている受信者２０１と同様に特定のＱｏＳを要求しているものとする。この場合、送信者１０１は呼識別子１０で識別される受信者２０１宛のｐ−ｐ ＶＣへの新たな受信者２０２の追加をＡＴＭシグナリングのパーティ追加要求を用いて要求する。
【０１２６】
この際、要求するサービス属性として例えばピーク速度１０ＭｂｐｓのＣＢＲサービスを指定する。パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報やサービス属性情報をもとにその経路を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向へ新たなＶＣの分岐を作成するためにＶＰＩ／ＶＣＩ値の確保（ここでは８０／４０）を行なう。さらに通信リソースの確保を試みるが、ここで帯域不足によりそれが行なえないとする。
【０１２７】
従来はこの時点でパーティ追加拒絶通知を上流へ戻すが、ここでは出力リンクの空き状況が許容する範囲まで割り当てリソース量を下げて（あるいは割り当てリソースをなしにして）確保する。
【０１２８】
図８の（ｂ）の例では割り当てリソースをゼロ（ＵＢＲ）にした場合を示している。そして図９（ｂ）の受信者別サービス属性管理テーブル４０２に出力リンク２上のＶＰＩ／ＶＣＩ＝８０／４０に対応する受信者２０２の要求サービス属性情報（ＣＢＲ）を加えるとともに、このＡＴＭノードにおいて要求サービス属性を満足する帯域が受信者に与えられているか否かを示すフィールド（図９（ｂ）の成否）に帯域が与えられていない旨（否）を示しておく。
【０１２９】
また、図９（ｂ）のコネクション別割り当てリソース管理テーブル４０１のＶＰＩ／ＶＣＩ＝８０／４０のエントリに、相当するＶＣリンクの帯域は０Ｍｂｐｓであり、このＡＴＭノード３０１において帯域不足による割り当てリソースの変更を行なった旨を帯域変更タグＯＮで示しておく。これにより後に帯域の再割り当て要求を自身の判断で行なうことも可能にする。
【０１３０】
ここで、サービス属性管理テーブル１７の「成否」は、単にこのノードの時点で満足な帯域が与えられているか否かを示す。すなわち、このノードでは帯域不足ではないが上流のノードで帯域不足による変更が起こったためにこのノードでも要求サービス属性を満たすリソース量が割り当てられていないという場合にも、「成否」のフィールドには否（Ｘ）と記載されるし、自身より下流のノードで帯域不足が起こって上流まで遡って帯域取消をする場合にも、「成否」はＸになる。
【０１３１】
一方、「帯域変更タグ」はこのノードで初めて帯域不足による変更を余儀なくされたどうかを示す。つまり、自身より上流または下流で起こった帯域不足の場合には、自身の「帯域変更タグ」はＯＦＦのままである。
【０１３２】
次にＡＴＭノード３０１は次段ＡＴＭノード３０３へコネクション設定要求を送出する。その際は要求サービス属性（ＣＢＲ）とともに、すでに自ノードで割り当てリソースを変更した旨および変更した割り当てリソース量をいっしょに通知する。
【０１３３】
ＡＴＭノード３０３，３０４では通常の新たなコネクション設定と同様の手順でＶＣのリーフの追加が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量ゼロ、帯域変更タグはＯＦＦ）と受信者別サービス属性管理テーブル（サービス属性はＣＢＲ、成否フィールドは否）に新たな追加が行なわれる。
【０１３４】
すなわち、ＡＴＭノード３０３，３０４では、要求サービス属性に対応するリソース量を割り当てるのではなく、上流のノード３０１で変更された割り当てリソース量を越えない範囲でＶＣリンクの帯域を割り当てる。このようにして受信者２０２までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【０１３５】
ここで、送信者−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、３０２−受信者２０１間の割り当て帯域は１０Ｍｂｐｓとなるが、新しく追加したＡＴＭノード３０１−３０３間、３０３−３０４間、３０４−受信者２０２間のリーフの割り当て帯域はゼロとなっている。
【０１３６】
受信者２０２はＵＢＲに割り当てリソース量が変更されたＶＣ設定要求を受信すると、それを受け付けるか受け付けないかを決定できるので、ＱｏＳが満足できなくて受け付けても意味がないと考えれば拒絶すれば良い。
【０１３７】
また送信者１０１はパーティ追加要求あるいはＶＣ設定要求を送出する際に、途中で帯域不足が生じた場合には割り当て帯域を落してでも（あるいは割り当て帯域ゼロにしてでも）相手に接続したいか、十分な帯域が割り当てられない場合には接続をしないで欲しいかの希望を示すフィールドをメッセージに付加しても良い。
【０１３８】
ＡＴＭノード３０１−３０３間のリンクの帯域不足が解消し、図８（ｃ）に示すようにＡＴＭノード３０１から受信者２０２まで要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成するが成功すれば、ＡＴＭノード３０１のコネクション割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は、図９（ｃ）のように変更される。このリーフの再構成の具体的手順については後述する。
【０１３９】
以上述べた本実施形態における帯域不足に対処可能なＡＴＭノードでの処理アルゴリズムを、図１０に示す。
【０１４０】
（具体例２−２）
帯域不足の第２の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図１１に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図１２に示す。
【０１４１】
第２の場合とは、既存のＶＣへの受信者追加の際にｐ−ｍｐ ＶＣが分岐したあとのＡＴＭノード３０３で出力リンクの帯域が不足した場合である。この場合も図８（ｂ）のＡＴＭノード３０１で帯域不足が生じた時と同様に、そのＡＴＭノードから先のＶＣの割り当て帯域を変更（この例ではゼロ）してＶＣ設定を先まで進める方法がまず考えられる（図１１（ｂ））。このとき、ＡＴＭノード３０３では、帯域変更タグをＯＮに、成否フィールドを否とし、ＡＴＭノード３０４では、帯域変更タグをＯＦＦに、成否フィールドを否とする。
【０１４２】
但しこの場合には、すでにＣＢＲとして確保したＡＴＭノード３０１−３０３間の帯域はあまり意味のないものになる。
【０１４３】
図１２に、この場合のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル４０１、受信者別サービス属性管理テーブル４０２の変化の様子を示している。ＡＴＭノード３０１は自身では帯域不足を生じなかったため、図１２（ｂ）の帯域変更タグはＯＦＦであり、成否フラグは「成（Ｏ）」になる。下流ノードである３０３で帯域不足が生じたため、最終的にはＶＣの要求サービス属性は満たせていないが、この例では、帯域不足が生じたＡＴＭノードから先の受信者までのリーフにのみ要求サービス属性を満たさないリソース量を割り当てるので、ＡＴＭノード３０１は下流ノードで帯域不足が生じたことを必ずしも知る必要はない。
【０１４４】
このようにして帯域不足によりＡＴＭノード３０３−受信者２０２間の帯域は要求サービス属性を満足しないものになっているが、ＡＴＭノード３０３−３０４間の帯域不足が解消し、図１１（ｃ）に示すようにＡＴＭノード３０３から受信者２０２までの要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成することが成功すれば、ＡＴＭノード３０１のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は図１２（ｂ）に同じであるが、ＡＴＭノード３０３，３０４の各テーブルの内容は変更される。このリーフの再構成の具体的手順については後述する。
【０１４５】
なお、本例におけるＡＴＭノードでの処理アルゴリズムは、図１０と同様である。
【０１４６】
（具体例２−３）
帯域不足の第３の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図１３に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図１４に示す。
【０１４７】
第３の場合は第２の場合と同様に、既存のＶＣへの受信者追加の際にｐ−ｍｐＶＣが分岐したあとのＡＴＭノード３０３で出力リンクの帯域が不足した場合である。この例では第２の場合とは異なり、図１３（ｂ０）（ｂ１）に示すように帯域不足のＡＴＭノード３０３から先の割り当て帯域を変更するとともに、すでに確保した上流のリンクの帯域をノード３０３以降で割り当てた帯域と同じものに、分岐点（ＡＴＭノード３０１）までさかのぼって変更する。
【０１４８】
これにより、実際の帯域不足はＡＴＭノード３０３−３０４間のリンクで発生したが、それより上流のＡＴＭノード３０１から割り当て帯域が変更（この例ではゼロ（ＵＢＲ））されている。この方法は手順は第２の場合より複雑になるが、ムダな帯域を確保することを防ぐ効果がある。
【０１４９】
図１４に、この場合のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル４０１、受信者別サービス属性管理テーブル４０２の変化の様子を示している。ＡＴＭノードにおいて帯域が無事確保できた際に図１４（ｂ０）においていったん登録したテーブル情報を、下流にて帯域不足が発生したことを知ることで図１４（ｂ１）において変更している。
【０１５０】
下流ノードで帯域不足が生じたことは、送信者も含めたすべての上流ノードにおいて以下のような方法で知ることができる。
【０１５１】
一つの方法では、ＡＴＭノード３０３において帯域不足により割り当てリソースが変更された形で受信者２０２にＶＣ設定要求が到達し、受信者２０２がその設定要求を受け付けてＶＣ設定確認を送信者１０１へ戻す際に、提供されたＶＣのリソースは要求属性を満たさないものになっている旨をＶＣ設定確認の中の情報として示す方法である。
【０１５２】
あるいは、帯域不足の発生したＡＴＭノードで、下流にＶＣ設定を転送すると同時に上流に帯域不足のあった旨を別の制御メッセージで通知する方法もある。
いずれにしても、図１４（ｂ１）において、下流で与えた割り当てリソース（この例ではゼロ）と同じレベルまで、ＡＴＭノード３０１での対応するＶＣリンクの割り当てリソースも変更する。
【０１５３】
なお、ＡＴＭノード３０１は、ＡＴＭノード３０３を経由して既にサービスを受けている受信者の中に、帯域不足の発生したＡＴＭノードで割り当てた帯域よりも大きな帯域の必要な要求サービス属性を持つものが存在しないことを確認し（図１３，１４の例では存在しない）、上記割り当てリソースの変更を行う。
【０１５４】
このようにして帯域不足によりＡＴＭノード３０１−受信者２０２間の帯域は要求サービス属性を満足しないものになっているが、ＡＴＭノード３０３−３０４間の帯域不足が解消し、図１３（ｃ）に示すようにＡＴＭノード３０３から受信者２０２までの要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成することが成功すれば、ＡＴＭノード３０１のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は、図１４（ｃ）のように変更される。このリーフの再構成の具体的手順については後述する。
【０１５５】
（具体例２−４）
以上述べたように、所望のサービス属性を満たすだけの帯域の確保が途中のＡＴＭノードで行なえない場合には、途中のＡＴＭノードから所望のサービス属性を満たさないリソース量のコネクション設定を行なうことが可能である。しかしながらその後、帯域不足の出力リンクの帯域不足が解消された場合には、可能ならば所望のサービス属性を満たすようにコネクションの割り当て帯域を変更しても構わない。以下ではその実現方法の具体例を説明する。
【０１５６】
例えば、所望のサービス属性を満たさないコネクションが張られていることを知っている送信者あるいは受信者が、適当な時間の後にコネクション帯域の変更要求を送信する。この変更要求を受け、自ノードの成否フラグが「否（Ｘ）」になっているＡＴＭノード（例えば図８（ｂ）のノード３０１、図１１（ｂ）のノード３０３、図１３（ｂ１）のノード３０１）は、対応するリンクの帯域が現在は所望の属性を満たすように確保できるようになっているか否かを調べ、もし確保できるならば確保し、コネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ＡＴＭノードへ帯域変更要求を転送する。これを受信者２０２まで行なうことで、所望のサービス属性を満たすようなコネクションの帯域変更が成功する。
【０１５７】
あるいは、帯域不足により所望のサービス属性を満たさない割り当て帯域でＶＣリンクを設定した（自ノードの帯域変更タグがＯＮになっている）ＡＴＭノード（例えば図８（ｂ）の３０１、図１１（ｂ）の３０３）は、他のＡＴＭノードと定期的に交換している各リンク間のリソース使用状況に関する情報をチェックし、空き帯域ができたと判断した場合にはそのＡＴＭノードが所望の属性を満たすように割り当て帯域を設定し、コネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ノードへ帯域変更要求を転送する。これを受信者まで行なうことで、所望のサービス属性を満たすようなコネクションの帯域変更が成功する。
【０１５８】
図１３（ｂ１）のように、帯域不足のリンク（ＡＴＭノード３０３−３０４間）とＶＣリンクへの割り当て帯域を途中で変更したＡＴＭノード（３０１）とが直接つながっていない場合は、定期的に交換する各リンクのリソース使用状況に関する情報がわかるようなプロトコルが動作している場合には、上述した方法と同様にＡＴＭノード３０３−３０４間のリンクの空き帯域ができたことをＡＴＭノード３０１が認識した時点で帯域変更要求を送出すればよい。そうしたリンク使用状況がわからないような場合には、図１３のＡＴＭノード３０１が定期的に帯域変更要求を送出して、もし空き帯域ができていれば帯域変更が行なわれる。
このように、図１３（ｂ１）のノード３０１が、上記プロトコルにより離れたリンク（３０３−３０４間）のリソース状況を知って、もしくは、定期的に、帯域変更要求を送出するためには、ノード３０１は自ノードが不十分な帯域が割り当てられている区間の先頭であることを認識する必要がある。そのためには、上記帯域変更タグとは別に、「先頭タグ」を設けておくのが望ましい。つまり、各ノードは、ｐ−ｍｐ ＶＣのリーフの設定の際に、自ノードより下流のノードで帯域不足が起こったために自ノードで一旦行なった帯域の確保を取り消し、且つ、自ノードの上流へは帯域の確保の取り消しを示唆するＶＣ設定確認もしくは制御メッセージを送っていない場合に、先頭タグをＯＮにする。
【０１５９】
なお、更に別の方法として、図１３（ｂ１）のノード３０３（帯域変更タグＯＮ）が、帯域不足が解消したときに出力ＶＣリンク（３０３−３０４間）の割り当て帯域を変更するとともに、上流ノード３０１に入力ＶＣリンク（３０１−３０３間）の割り当て帯域を十分なものに引き上げるよう通知することも可能である。
【０１６０】
【発明の効果】
本発明によれば、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じたひとつのポイント−マルチポイントコネクションの形成が可能になる。
【図面の簡単な説明】
【図１】本実施形態に係るノード装置のコネクション制御を行う部分の機能構成を示す図
【図２】新たな受信者のためのＶＣリンクを追加する場合を説明するための図
【図３】受信者のＱｏＳ変更及び離脱が要求された場合を説明するための図
【図４】図２の場合の各テーブルの内容例を示す図
【図５】図３の場合の各テーブルの内容例を示す図
【図６】図２の場合のノードの動作を示すフローチャート
【図７】図３の場合のノードの動作を示すフローチャート
【図８】リソース量が不足した場合のＶＣリンクの追加の第１の例を説明するための図
【図９】図８の場合の各テーブルの内容例を示す図
【図１０】図８の場合のノードの動作を示すフローチャート
【図１１】リソース量が不足した場合のＶＣリンクの追加の第２の例を説明するための図
【図１２】図１１の場合の各テーブルの内容例を示す図
【図１３】リソース量が不足した場合のＶＣリンクの追加の第３の例を説明するための図
【図１４】図１３の場合の各テーブルの内容例を示す図
【符号の説明】
１１…シグナリングメッセージ処理部
１２…コネクション状態管理部
１３…経路制御部
１４…アドミッション制御部
１５…リンク状態管理テーブル
１６…コネクション別割り当てリソース管理テーブル
１７…受信者別サービス属性管理テーブル
【発明の属する技術分野】
本発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能なコネクション型（例えば非同期転送モード型（ＡＴＭ：Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ））通信網におけるマルチキャスト通信制御方法及びノード装置に関する。
【０００２】
【従来の技術】
非同期転送モード型通信網（以下、ＡＴＭ通信網と呼ぶ）において複数の受信者へ同一の情報を分配するマルチキャスト通信を行なう場合、送信者からすべての受信者へのポイント−マルチポイントＡＴＭコネクションを設定することで、送信者は受信者数分の情報のコピーを自らすることなく、そのポイント−マルチポイントコネクションに向けて情報を送信するだけで、すべての受信者にそれを届けることが可能となる。ここで送信者、受信者とは実際の情報送信元ホスト、受信先ホストであっても構わないし、ルータ装置のようなコネクションレス型パケット中継ノードであっても構わない。
【０００３】
このポイント−マルチポイントコネクションの提供する帯域や通信品質（ＱｏＳ）などのサービス属性は、従来すべての受信者に対して同一のものが提供される。この制約は以下のような問題点を生じる可能性がある。
【０００４】
例えば、受信者によって要求するサービス属性が異なる（例えば、ある受信者は多少通信コストがかかっても一定帯域の確実な保証を要求するが、ある受信者は通信品質の保証をまったく要求せずむしろ低コストの通信を要求する）ような場合には、最も厳しい受信者の要求を満たすようなサービス属性をすべての受信者に提供するようなポイント−マルチポイントコネクションによりサービスを実現する方法が考えられる。
【０００５】
しかしながらその場合、通信品質保証の要求をしていない受信者に対しても所定の通信リソースをエンドエンドに確保していることになり、網リソースの効率的な運用を低コストな通信の提供といった観点からは望ましい方法とは言えない。
【０００６】
受信者により要求サービス属性が異なる場合のＡＴＭマルチキャスト通信の他の実現方法として、要求サービス属性の等しい（または類似した）受信者群に対してはひとつのポイント−マルチポイントコネクションによりサービスを提供し、要求サービス属性の異なる（または大きく異なる）受信者群には別の属性のポイント−マルチポイントコネクションによりサービス提供する方法も考えられる。極端な場合、受信者数分のポイント−ポイントコネクションを送信者から設定することになる。
【０００７】
この場合は、送信者が属性に応じて設定したコネクション数分だけのコピーを作成して各々のコネクションに送信する必要があること、通信網の送信者に近い部分（例えば送信者側ユーザ網インタフェース）の通信帯域を浪費している事などの問題がある。
【０００８】
すべての受信者に同一のサービス属性のポイント−マルチポイントコネクションを提供することの他の問題点として、一部の受信者への通信帯域が網内で確保できなかった場合がある。あるサービス属性を持つポイント−マルチポイントコネクションの受信者（枝；リーフ）を新たに追加しようとしても、その受信者への経路上でサービス属性を満たすだけの通信帯域が確保できないとその枝の追加は拒絶され、その受信者は情報をまったく受信できないことになる。
【０００９】
この場合にも別の通信属性（例えば通信品質の保証のまったくないサービス）のコネクションを送信者から受信者へ別に設定すれば情報の受信は可能になるが、送信者の情報コピーの負荷や通信網の送信者に近い部分の通信帯域の浪費の問題は残る。
【００１０】
【発明が解決しようとする課題】
このように従来ＡＴＭ通信網上でマルチキャスト通信を行なう際に、ひとつのポイント−マルチポイントコネクションにより情報転送すると、すべての受信者に同一のサービス属性を提供することになる。よって受信者毎のサービス属性要求の違いに柔軟に対処できないとか、一部の受信者への通信帯域が確保できない場合にはその受信者は情報をまったく受信できないなどの問題点がある。
【００１１】
また、これを解決するには、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じた複数のコネクションを設定してひとつのマルチキャスト通信を実現する方法も考えられるが、送信者での情報のコピーや通信網の送信者側での帯域の圧迫などの問題が残る。
【００１２】
本発明はこのような問題を解決するためになされるもので、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じたひとつのポイント−マルチポイントコネクションの形成を可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
本発明の第１の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣ（ＶｉｒｔｕａｌＣｈａｎｎｅｌ）リンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、この受信した設定要求に示されるもしくは対応して示される要求サービス属性が、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前段のノード装置から前記ノード装置へ向かう入力ＶＣリンクに提供されているサービス属性とは異なる場合に、前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とする。
【００１４】
この第１の発明は、新たな出力ＶＣリンクに割り当てられる通信リソース量を、前記入力ＶＣリンクに割り当てられている通信リソース量（提供されているサービス属性に対応するもの）とは異なるものにするものであり、この発明によれば、既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加することができ、ひとつのポイント−マルチポイントコネクションで受信者に応じて異なるサービス属性を提供することが可能になる。すなわち、既に存在するＶＣリンクに提供されているサービス属性と異なるサービス属性を要求する受信者を、ひとつのＶＣコネクションで新たに収容可能となる。
【００１５】
なお、前記要求サービス属性には、所定の通信品質を要求しない場合に相当するサービス属性を含み、この場合は、新たな出力ＶＣリンクに割り当てられる通信リソース量は０になる（リソースの割り当てを行わずにＶＣリンクを設定する）。
【００１６】
また、送信者が提供するサービス属性より大きいものを受信者が受けることはできないため、一般には、前記要求サービス属性は前記入力ＶＣリンクに提供されているサービス属性以下となる。但し、送信者が提供するサービス属性より小さなサービス属性を提供するＶＣリンクに、新たなＶＣリンクを追加する場合には、後述する入力ＶＣリンクの通信リソース量変更との順序関係により、前記要求サービス属性は前記入力ＶＣリンクに提供されていたサービス属性より大きくなることがある。
【００１７】
また、後述するように通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することを行う場合には、前記要求サービス属性は前記入力ＶＣリンクに提供されていたサービス属性より大きくなることがある。そのため、前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを設定させるのは、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置よりも送信者側のＶＣリンクの中に、該新たな出力ＶＣリンクに対応した要求サービス属性を満たさない通信リソース量が割り当てられているＶＣリンクが存在しない場合とすることが、リソースの効率的な利用という点では、好ましい。但し、このような場合でも要求サービス属性を満たす通信リソース量を割り当てておく方が好ましいこともある。
【００１８】
上記第１の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべき要求サービス属性が前記入力ＶＣリンクに提供されているサービス属性とは異なるならば、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、この設定される出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とする。
【００１９】
ここで、送信者が提供するサービス属性より小さなサービス属性を提供するＶＣリンクに、新たなＶＣリンクを追加する必要が生じたような場合は、次のようにすることが好ましい。すなわち、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つが入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性よりも、前記入力ＶＣリンクに提供されているサービス属性の方が、そのサービス属性に対応する通信リソース量が小さいならば、前記入力ＶＣリンクに割り当てられる通信リソース量を前記要求サービス属性に対応する量に変更する。
【００２０】
本発明の第２の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを構成するＶＣリンクのうち、前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクに割り当てている通信リソース量を記憶する記憶手段と、前記次段のノード装置を経由して既に通信情報を受信可能な各受信者に対して提供されているサービス属性及び新たに前記マルチキャスト通信サービスへ参加を要求した受信者に与えられるべき要求サービス属性のうち、もしくは、前記各受信者から既に提供されているサービス属性の変更を要求した受信者を除した受信者に対して提供されているサービス属性及び該変更を要求した受信者に与えられるべき要求サービス属性のうち、もしくは、前記各受信者から前記マルチキャスト通信サービスからの離脱を要求した受信者を除いた受信者に対して提供されているサービス属性のうち、そのサービス属性に対応する通信リソース量が最も大きいものを検出する検出手段と、この検出手段の検出結果の示す通信リソース量が前記記憶手段により記憶された通信リソース量と異なる場合に、前記出力ＶＣリンクに割り当てている通信リソース量を変更する手段とを備えたことを特徴とする。
【００２１】
この第２の発明によれば、新たに参加する受信者のために既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加する場合に、既に存在するＶＣリンクのリソース量を必要に応じて変更することで、受信者に応じて異なるサービス属性を提供するひとつのポイント−マルチポイントコネクションを効率良く形成することができる。また、受信者に応じて異なるサービス属性をひとつのポイント−マルチポイントコネクションで提供するにあたり、既に参加している受信者に対する通信品質の変更がサービス提供中に要求された場合や、既に参加している受信者が離脱して対応するＶＣリンクが削除される場合に、存在する各ＶＣリンクにおいて必要最小限の通信リソース量を確保することができる。
【００２２】
なお、前記サービス属性には、所定の通信品質を要求しない場合に相当するサービス属性を含み、これに対応する通信リソース量は０になる（リソースの割り当てを行わずにＶＣリンクを設定することに相当）。
【００２３】
ここで、前記検出手段は、例えば、前記次段のノード装置を経由して既に通信情報を受信可能な各受信者に対して提供されているサービス属性を示す情報を記憶する手段の記憶内容を参照して検出を行うことができる。
【００２４】
この記憶する手段は、各受信者に対して提供されているサービス属性を示す情報として、新たに前記マルチキャスト通信サービスへ参加を要求した受信者に与えられるべき要求サービス属性、もしくは、既に提供されているサービス属性の変更を要求した受信者に与えられるべき要求サービス属性を各受信者毎に記憶するものであってもよいし、後述するように通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することを行う場合には、各受信者に対して提供されているサービス属性（もしくはこれに対応する通信リソース量）に加えて、上記の要求サービス属性を記憶するものであってもよい。
【００２５】
上記第２の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを、該マルチキャスト通信サービスに対し新たに参加を要求した受信者もしくは既に受けている該サービスのサービス属性の変更を要求した受信者のために、もしくは該サービスからの離脱を要求した受信者に起因して、変更するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクの通信リソース量が、新たに参加を要求した受信者への通信がこのＶＣリンクを用いる場合に該受信者に与えられるべき要求サービス属性を満たすか否か、もしくは、該ＶＣリンクを用いて既に通信情報を受信可能な各受信者からサービス属性の変更を要求した受信者を除いた受信者に対して提供されているサービス属性及び該変更を要求した受信者に与えられるべき要求サービス属性のうちそのサービス属性に対応する通信リソース量が最も大きいものに対応するか否か、もしくは、前記各受信者から離脱を要求した受信者を除いた受信者に対して提供されているサービス属性のうちそのサービス属性に対応する通信リソース量が最も大きいものより大きいか否かを判断し、この判断結果に基づいて前記ＶＣリンクに割り当てている通信リソース量を変更することを特徴とする。
【００２６】
本発明の第３の発明は、通信リソース量が確保できないときに要求サービス属性を満たさない通信リソース量で新たなＶＣリンクを追加することに関する。
【００２７】
第３の発明は、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、この受信した設定要求に示されるもしくは対応して示される要求サービス属性に対応する第１の通信リソース量を割り当てた新たな出力ＶＣリンクが設定できない場合に、新たな出力ＶＣリンクが設定可能な第２の通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とする。
【００２８】
この第３の発明によれば、既に存在するＶＣリンクとは異なるサービス属性を提供する新たなＶＣリンクを追加することができ、ひとつのポイント−マルチポイントコネクションで受信者に応じて異なるサービス属性を提供することが可能になる。すなわち、新たな受信者の参加のためにノードが受信した設定要求の要求サービス属性をリソース量不足により満たせなかった場合に、要求属性は満足しないが収容できる範囲内のリソース量でサービスを行なうことで、最低限コネクティビティだけでも提供することが可能となる。
【００２９】
なお、ＶＣリンクに割り当てられる第２の通信リソース量を０（リソースの割り当てを行わずにＶＣリンクを設定する）としても、収容できる範囲内のリソース量を求めてその値としてもよいが、前者の方が処理が簡単である。
【００３０】
上記第３の発明は、また、非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべきサービス属性に対応する第１の通信リソース量を割り当てたＶＣリンクが設定不可能ならば、前記第１の通信リソース量より小さいかあるいは０である第２の通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、この設定された出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とする。
【００３１】
この場合に、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記入力ＶＣリンクに対する出力ＶＣリンクに割り当てられている通信リソース量のうち、前記第２の通信リソース量より大きなものが存在するか否かを調べ、存在しない場合には、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更することが、リソースの効率的な利用の点では、好ましい。
【００３２】
さらに、リソース量不足が解消したときには本来の要求サービス属性を提供するために、次の手段を採ってもよい。すなわち、前記第１の通信リソース量を割り当てたＶＣリンクが設定できないために前記第２の通信リソース量が割り当てられていることが記憶されている場合に、前記第１の通信リソース量の割り当てが可能になったか否かを調べ、可能になっていれば前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更するのである。
【００３３】
このことは、第３の発明のマルチキャスト通信制御方法で、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更し、この通信リソース量の変更された出力ＶＣリンクを入力ＶＣリンクとし、前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶＣリンクが出力ＶＣリンクとなる場合に、割り当てが可能であれば前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶＣリンクがなるべき出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更することを意味する。
【００３４】
また、あるノードでリソース量不足して要求サービス属性を満たさないリソース量が割り当てられたときにそのノードの上流でもリソースの効率的な利用のためにリソース量の変更を行うのであれば、リソース量不足が解消したときには本来の要求サービス属性を提供するためには、以下のようにするとよい。前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更する。それとともに、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更したならば、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更するときに、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第１の通信リソース量に変更するのである。
【００３５】
また、本発明（請求項１７）は、入力ＶＣリンクと複数の出力ＶＣリンクを用い、送信者から複数の受信者に通信データを送信するマルチキャスト通信サービスを提供可能なノード装置において、マルチキャスト通信サービスに用いられるポイント−マルチポイントコネクションを維持する維持手段と、このマルチキャスト通信サービスのための新たな出力ＶＣリンクの設定要求、及び、この新たなＶＣリンクに対する要求サービス属性を受信する受信手段と、この設定要求に応え、前記要求サービス属性を調べ、入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを前記ポイント−マルチポイントコネクションに加える設定手段とを具備することを特徴とする。
【００３６】
本発明（請求項１８）は、請求項１７記載のノード装置において、前記設定手段は、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００３７】
本発明（請求項１９）は、請求項１７記載のノード装置において、前記設定手段は、前記要求サービス属性を満たす通信リソース量が確保できない場合に、前記入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００３８】
本発明（請求項２０）は、入力ＶＣリンクと出力ＶＣリンクを用い、送信者から複数の受信者に通信データを送信するマルチキャスト通信サービスを提供可能なノード装置において、マルチキャスト通信サービスに用いられるポイント−マルチポイントコネクションを維持する維持手段と、出力ＶＣリンクに割り当てられた通信リソース量を示す情報を記憶する記憶手段と、この出力リンクの通信リソース量を変更する必要があるか否かを、前記マルチキャスト通信サービスに対する新たな受信者の参加要求、もしくは既に受信可能となっている受信者のサービス属性変更要求、もしくは受信者の離脱要求に応えて、決定する決定手段と、必要があると決定された場合に、出力ＶＣリンクに割り当てられている通信リソース量を変更する手段とを具備することを特徴とする。
【００３９】
本発明（請求項２１）は、請求項１７記載のノード装置において、前記受信手段は、前記要求サービス属性を含む前記設定要求を受信するものであり、前記設定手段は、この設定要求をデータリンク層で処理し、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００４０】
本発明（請求項２２）は、請求項１７記載のノード装置において、前記受信手段は、前記要求サービス属性を含むメッセージを受信するものであり、前記設定手段は、このメッセージをネットワーク層で処理し、この処理結果に基づいて前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする。
【００４１】
本発明（請求項２３）は、請求項２０記載のノード装置において、出力ＶＣリンクの先の次段ノードから、この出力ＶＣリンクを通して前記マルチキャスト通信サービスを受信可能となる受信者に対して提供されているサービス属性のうち最大のものを示すメッセージを受信する手段を更に具備し、前記決定手段は、このメッセージを参照して決定を行なうものであることを特徴とする。
【００４２】
本発明（請求項２４）は、請求項２３記載のノード装置において、入力ＶＣリンクの先の前段ノードへ、この入力ＶＣリンクを通して前記マルチキャスト通信サービスを受信可能となる受信者に対して提供されているサービス属性のうち最大のものを示すメッセージを送信する手段を更に具備することを特徴とする。
【００４３】
【発明の実施の形態】
以下、本発明の実施の一形態について説明する。
【００４４】
図１は本発明に関わるＡＴＭノードに具備されるコネクション制御部の機能構成例を示したものである。コネクション制御部１０は、シグナリングメッセージ処理部１１、コネクション状態管理部１２、経路制御部１３、アドミッション制御部１４、リンク状態管理テーブル１５、コネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７を含んでいる。
【００４５】
シグナリングメッセージ処理部１１は、端末もしくは隣接ＡＴＭノードとの間でコネクション制御に関わる各種メッセージをやりとりし、その結果生じるイベントをコネクション状態管理部１２に通知する。コネクション状態管理部１２は、通知されたイベントに基づき経路制御部１３やアドミッション制御部１４や各種テーブルからの情報を利用しつつ必要な処理を行ない、その結果をテーブルに書き込むとともにシグナリングメッセージ処理部１１へも通知する。
【００４６】
経路制御部１３は、制御するコネクションの次段ＡＴＭノードを自身の持つ経路情報をもとに決定するか、あるいはメッセージに含まれた経路指定情報をもとに決定するなどの機能をもつ。アドミッション制御部１４は、制御メッセージ内のサービス属性情報などをもとに必要リソース量の算出等を行なうとともに、新たなコネクションの収容可否やコネクション属性変更の可否などの判断を行なう。
【００４７】
リンク状態管理テーブル１５は、前記アドミッション制御部１４が判断を行なうために必要な情報（出力リンクの容量、使用率など）を管理している。
【００４８】
コネクション別割り当てリソース管理テーブル１６は、各ＡＴＭノードにおいて各ＶＣリンクに割り当てているリソース量を管理しているとともに、後述するように、そのＡＴＭノードにおいて前段ＡＴＭノードが割り当てているリソース量（正確にはそのＶＣリンクに与えるべきサービス属性を満たすもの）と同等のリソース量を割り当てることができたか否かを示す情報を持つことができる。
【００４９】
受信者別サービス属性管理テーブル１７は、各ＡＴＭノードにおいて関与する各ＶＣリンクの各々の受信者に与えるべき要求サービス属性をすべての受信者について管理しているとともに、後述するように、その要求サービス属性がそのＡＴＭノードを通過する時点において満たされているか否かを示す情報を持つことができる。
【００５０】
本発明に関わるＡＴＭノードは、ＡＴＭスイッチには限定されない。例えば、各ノードをセルスイッチルータ（以下、“ＣＳＲ”と言う）として構成してもよい。ＣＳＲとは、ネットワーク層（例えばＩＰ）処理手段とＡＴＭスイッチとを備え、ホストもしくは隣接ルータ（ＣＳＲ）とネットワーク層で処理されるメッセージを交換する。ＣＳＲは、このメッセージに基づき、ＣＳＲ内のＡＴＭスイッチを通るカットスルーコネクション（異なる論理ネットワーク間をデータリンク層で接続するコネクション）を形成し、ＩＰフォワーディングをバイパスしてデータを転送する。
【００５１】
（具体例１）
まず本発明の第１の具体例として、マルチキャスト通信の受信者により要求するサービス属性が異なる場合のポイント−マルチポイントコネクション（以下、ｐ−ｍｐ ＶＣと表す）の設定、受信者の追加（参加）、受信者の要求属性変更、受信者の削除（離脱）時の手順について説明する。
【００５２】
ＡＴＭ通信網の構成例と、各場合におけるｐ−ｍｐ ＶＣの構成の時間的変化の様子の例を図２、図３に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の時間的変化の様子を図４、図５に示す。
【００５３】
従来の方法との大きな違いはすでに存在するＶＣに提供されているサービス属性と異なるサービス属性を要求する受信者を新たに収容可能とし、しかもそれを効率良く行なうために、各ＶＣリンク（エンドエンドのＶＣコネクションのうちの隣接ＡＴＭノード間の部分）において必要最小限のリソースを確保することにある。
【００５４】
まず図２（ａ）において、送信者１０１から受信者２０１へのポイント−ポイントコネクション（以下、ｐ−ｐ ＶＣと表す）が設定されている（呼識別子を１０とする）。呼識別子は、各ＡＴＭノードが、自分の管理するＶＣリンクがどのｐ−ｍｐ ＶＣに属するものであるかを識別するためのものである。また、上記ｐ−ｐ ＶＣは、以降のｐ−ｍｐ ＶＣへの拡張を考慮して、受信者２０１から送信者１０１へのリソースは０にしておくことが好ましい。なお、既に設定されているのがｐ−ｍｐ ＶＣであっても以降の手順は同様である。
【００５５】
この際、受信者から送信者へ、アプリケーションレベルの通信品質（以下、ＱｏＳと表す）の要求が、例えばネットワーク層（例えばＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ））レベルの帯域予約プロトコル（例えばＲＳＶＰ（Ｒｅｓｏｕｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ））などで行なわれており、このＱｏＳ要求を受け取った送信者は、そのＱｏＳ要求を満たすに十分なＡＴＭレベルのサービス属性（サービスクラス、トラヒックディスクリプタ、セルレベルのＱｏＳなど）を設定して、ＶＣ設定要求を行なっている。
【００５６】
このＶＣ設定要求は、送信者から受信者へ向けて順次途中のＡＴＭノードへ転送される。そして、このＶＣ設定要求に含まれるあるいは対応して別送される、ＡＴＭレベルの要求サービス属性情報を含むメッセージが、上記制御メッセージに相当する。なお、この制御メッセージは、上記のように送信者が発し、受信者へ向けて順次転送してもよいし、アプリケーションレベルのＱｏＳ要求の生じた受信者が発し、送信者へ向けて順次転送するようにしてもよい。
【００５７】
また、受信者にて生じたアプリケーションレベルのＱｏＳ要求を受けずに、送信者にて受信者に与えられるべき要求サービス属性を適当に決定し、上記制御メッセージを含むＶＣ設定要求を受信者へ向けて順次転送するのでもよい。
【００５８】
ＡＴＭノード３０１，３０２は、このＶＣ設定要求（あるいは他の制御メッセージ）を受け、上記要求サービス属性を満足するように出力リンク（物理的なリンクあるいは物理リンクを論理的に分割したＶＰ（バーチャルパス））におけるＶＣのリソースを確保し、それを記憶する。この時のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７の内容は、それぞれ図４の（ａ）の４０１，４０２に示すようになる。ここでは割り当てリソース量として簡単のために通信帯域のみを示したが、バッファ量など他のパラメータが含まれても構わない。
【００５９】
次にこのｐ−ｐ ＶＣ（呼識別子１０）に新たな受信者２０２が加わる場合について説明する。受信者が存在中のＶＣに加わる方法は、ＡＴＭのシグナリングに規定されているリーフ主導型のコネクション参加要求を受信者が送信者に対して送出する方法でも良いし、インタネットプロトコル（ＩＰ）が上位層にいる場合（すなわち送信者、受信者がＩＰホストかルータの場合）にはＩＰのマルチキャストグループ参加要求メッセージやマルチキャスト用ルーティング情報交換メッセージを受信者が送信者または何らかのサーバに送信し、送信者がそれを知るとＡＴＭシグナリングのパーティ追加要求で受信者の追加を要求する方法でも良い。なお、上記コネクション参加要求やパーティ追加要求は、対応するＡＴＭノード装置にとって新たな出力ＶＣリンクの設定要求となるものの一例である。
【００６０】
この新たな受信者２０２は、特定のＱｏＳの要求はせずベストエフォット型の通信を希望するものとする。新たな受信者がＱｏＳの要求をしているか否か、している場合はそのＱｏＳの内容を示す情報は、上記リーフ主導型のコネクション参加要求を用いる場合には、ＡＴＭレベルの要求サービス属性としてコネクション参加要求に含まれていてもよいし、ＡＴＭレベルの要求サービス属性情報を含む制御メッセージを、新たな受信者あるいはＲＳＶＰ等を用いて受信者のＱｏＳ要求を知った送信者が、コネクション参加要求に対応して別送するのでもよい。このようなコネクション参加要求や他の制御メッセージが転送されることにより、各ＡＴＭノードは新たな受信者の要求サービス属性を知ることができる。
【００６１】
また、上記ＩＰのマルチキャストグループ参加要求メッセージ等を用いる場合には、このＩＰの参加要求メッセージに新たな受信者のＱｏＳ要求が含まれているか、受信者のＱｏＳ要求を示すＲＳＶＰメッセージを受け取るかすることにより、新たな受信者のＱｏＳ要求を知った送信者が、パーティ追加要求にＡＴＭレベルの要求サービス属性を含ませて送出してもよいし、ＡＴＭレベルの要求サービス属性情報を含む制御メッセージを、新たな受信者もしくは上記送信者が、パーティ追加要求に対応して別送するのでもよい。このようなパーティ追加要求や他の制御メッセージが転送されることにより、各ＡＴＭノードは新たな受信者の要求サービス属性を知ることができる。
【００６２】
なお、上記パーティ追加要求は、送信者から既にリーフが存在する区間はパーティ追加要求として転送され、新たなリーフを設定することになる分岐点より先の新たな受信者までの区間はコネクション設定要求（ＶＣ設定要求）として転送される。
【００６３】
各ノードとしてＣＳＲを採用する場合には、ＩＰレベルの要求サービス属性情報を含むメッセージが、新たな受信者（例えばＲＳＶＰを用いる場合）もしくは送信者により送信され、各ノードは、このメッセージをＩＰ処理することにより、対応する出力ＶＣリンクに対するＡＴＭレベルの要求サービス属性を求めることができる。
【００６４】
以下では、ＡＴＭシグナリングのパーティ追加要求を用い、この中に要求サービス属性情報を含ませる場合を例に取り説明を進める。この場合、送信者１０１は呼識別子１０で識別される受信者２０１宛のｐ−ｐ ＶＣへの新たな受信者２０２の追加を、パーティ追加要求を用いて要求する。この際、このパーティ追加要求に含ませる要求サービス属性として、ＵＢＲ（Ｕｎｓｐｅｃｉｆｉｅｄ Ｂｉｔ Ｒａｔｅ）サービスを指定する。パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報やその要求サービス属性情報をもとにその経路を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向へ新たなＶＣのリーフ（ＶＣリンク）を作成するためにＶＰＩ／ＶＣＩ値の確保（ここでは８０／４０）を行なう。
【００６５】
ここで、ＵＢＲサービスを受信者２０２へ提供する場合を考えているので、コネクション別割り当てリソース管理テーブル４０１における新たなリーフへの割り当てリソース量はゼロとなる。受信者別サービス属性管理テーブル４０２にも新たな出力リンク２の上のＶＰＩ／ＶＣＩ−８０／４０に対応する受信者２０２のサービス属性情報を追加する。そしてＡＴＭノード３０１は次段ＡＴＭノード３０３へコネクション設定要求を送出する。
【００６６】
この時点での各管理テーブルへの情報の追加は仮のものであり、後の下流からＶＣ設定確認が来た時点でそれらの追加が確定するか、あるいは設定に失敗し解放要求が下流から戻ってくれば、管理テーブルへの仮の追加状態を解除する。この段階で追加が確定すると、各テーブル１６，１７は、図４の（ｂ）に示すようになる。
【００６７】
ＡＴＭノード３０３，３０４では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量ゼロ）と受信者別サービス属性管理テーブル（サービス属性はＵＢＲ）に新たな追加が行なわれる。このようにして受信者２０２までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１が分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【００６８】
ここで、図２（ｂ）に示すように、送信者−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、３０２−受信者２０１間の割り当て帯域は１０Ｍｂｐｓとなるが、新しく追加したＡＴＭノード３０１−３０３間、３０３−３０４間、３０４−受信者２０２の割り当て帯域はゼロとなる。
【００６９】
次にこのｐ−ｍｐ ＶＣ（呼識別子１０）にさらに新たな受信者２０３が加わる場合について説明する。この受信者２０３は、２０１と同様に所定のＱｏＳを要求しているものとする。送信者１０１は、呼識別子１０で識別されるｐ−ｍｐＶＣへの新たな受信者２０３の追加を、ＡＴＭシグナリングのパーティ追加要求を用いて要求する。この際、受信者のために要求するサービス属性として、ＣＢＲサービス、セル廃棄率１０−８などと言ったものを指定する。
【００７０】
パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報や要求サービス属性情報をもとに、あるいはあらかじめパーティ追加要求内に明示的に示された経路情報をもとに、次段ＡＴＭノード３０３（出力リンク２）を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向への呼識別子１０に相当するＶＣのリーフ（ＶＣリンク）の存在の有無をコネクション別割り当てリソース管理テーブル（図４（ｂ））により調べ、すでに存在する（ＶＰＩ／ＶＣＩ＝８０／４０）事を確認する。
【００７１】
ただし、コネクション別割り当てリソース管理テーブル内の割り当てリソース量がゼロになっているため、このＶＣリンクは受信者２０３の要求サービス属性を満たすことはできない。ＡＴＭノード３０１では要求サービス属性を満たすために必要な割り当てリソース量を算出し、割り当てが可能であると確認すると、コネクション別割り当てリソース管理テーブルの割り当てリソース量の内容をゼロから例えば１０Ｍｂｐｓに書き換える（図４（ｃ））。
【００７２】
それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）を、割り当てたリソース量に合うように変更する。受信者別サービス属性管理テーブルには新たに受信者２０３のサービス属性情報（呼識別子１０、出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０、サービス属性＝｛ＣＢＲ，１０Ｍｂｐｓ、ＣＬＲ１０−８｝など）を加える。そして次段ＡＴＭノード３０３にパーティ追加要求を送出する。
【００７３】
ＡＴＭノード３０３はパーティ追加要求を受信すると次段ＡＴＭノード３０５へのＶＰＩ／ＶＣＩの捕捉、通信リソースの確保（ここでは１０Ｍｂｐｓ）を行なうとともにＡＴＭノード内のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容を更新し、さらに次段ＡＴＭノード３０５へコネクション設定要求を送出する。
【００７４】
ＡＴＭノード３０５，３０６では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量１０Ｍｂｐｓ）と受信者別サービス属性管理テーブル（ＣＢＲ）に新たな追加が行なわれる。このようにして受信者２０３までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１，３０３で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【００７５】
ここで、図２（ｃ）に示すように、ＡＴＭノード３０３−３０４間、ＡＴＭノード３０４−受信者２０２間のＶＣリンクの割り当て帯域はゼロとなるか、残りのすべてのＶＣリンクには１０Ｍｂｐｓの帯域を割り当てられている。
【００７６】
なお、上記で説明した一つの受信者は、一つのＡＴＭグループアドレスに属する複数の受信者であってもよい。この場合は、一つのＡＴＭグループアドレスに属する複数の受信者には同じＱｏＳが提供されることになる。
【００７７】
以上述べた本実施形態における受信者の追加時のＡＴＭノードの処理アルゴリズムを、図６を用いて整理する。
【００７８】
まず、ＡＴＭノードは前段ＡＴＭノードまたは送信者から、既存のＶＣへのパーティ追加要求を図１のシグナリングメッセージ処理部１１において受信する（Ｓ６０１）。次にそれをコネクション状態管理部１２へ渡し、コネクション状態管理部１２が、受信したパーティ追加要求内の宛先（受信者）アドレスや要求サービス属性あるいは経路指定情報などをもとに、経路制御部１３に次段ＡＴＭノードを問い合わせ、経路制御部１３が、次段ＡＴＭノードを決定する（Ｓ６０２）。
【００７９】
コネクション状態管理部１２は、その次段ＡＴＭノードへの出力リンクにパーティ追加要求に対応するＶＣのリーフが既に存在するかを調べ（Ｓ６０３）、存在しないならば、アドミッション制御部１４に、要求サービス属性から算出された割り当てリソース量の収容が可能かどうか問い合わせる。アドミッション制御部１４はリンク状態管理テーブル１５の情報をもとに収容可否を判断し、コネクション状態管理部１２へ通知する。コネクション状態管理部１２はリーフの追加が可能であるとわかると、割り当てリソース管理テーブル１６に、要求サービス属性から算出された割り当てリソース量とともに、新たなリーフを仮追加し（Ｓ６０９）、サービス属性管理テーブル１７に新規受信者についての情報を仮追加し（Ｓ６１０）、次段ノードへＶＣ設定要求を送信する（Ｓ６１１）。
【００８０】
リーフが既に存在する場合には、既存のリーフの割り当てリソース量より新規要求サービス属性に必要なリソース量の方が大きいかを調べ（Ｓ６０４）、大きくない場合はそのままとし（Ｓ６０６）、大きい場合は、新規追加の場合と同様に、アドミッション制御部１４にリソース変更の可否を問い合わせ、可能であるとわかると、そのリーフの割り当てリソース管理テーブル１６の内容を、新規要求サービス属性を満たすリソース量に仮変更する（Ｓ６０５）。Ｓ６０５では、リソース量の仮変更を行うリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）も変更する。
【００８１】
Ｓ６０４では、既存のリーフの割り当てリソース量が、次段ノードを経由して既にサービスを受けている受信者に対し提供されているサービス属性のうち最も大きいものに対応していることから、結果的に、次段ノードを経由して既にサービスを受けている受信者に対し提供されているサービス属性及び新規参加者に与えられるべきサービス属性のうち対応するリソース量が最も大きいものを検出し、これと既存のリーフの割り当てリソース量とを比較していることになる。そして、この比較結果にかかわらず、サービス属性管理テーブル１７への新規受信者についての情報の仮追加（Ｓ６０７）と、次段ノードへのパーティ追加要求の送信（Ｓ６０８）が行われる。
【００８２】
最後に、ＶＣ設定、パーティ追加が実際に行われたか拒絶されたかを下流からの通知により知り（Ｓ６１２）、仮変更や仮追加の内容を確認する（Ｓ６１３）か、取り消す（Ｓ６１４）。
【００８３】
上述したように、ｐ−ｐ ＶＣあるいはｐ−ｍｐ ＶＣに新たな受信者を追加する際には、出力リンク上にそのＶＣのリーフが存在しない場合には、追加する受信者に与えるべきサービス属性を満たすために必要な通信リソース量を割り当てて新たなリーフを追加し、リンク上にすでにそのＶＣのリーフが存在する場合には、そのリーフに割り当てられている通信リソース量と追加する受信者に与えるべきサービス属性を満たすために必要な通信リソース量のうち大きな方をそのリーフの新たな割り当てリソース量とする。
【００８４】
これを、上述の例では、ＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）サービスに対応するリソースを割り当てたｐ−ｍｐ ＶＣの途中のリーフからＵＢＲサービスに対応する属性（リソース割り当てなし）に変わる場合について示しているが、ＶＢＲ（Ｖａｒｉａｂｌｅ Ｂｉｔ Ｒａｔｅ）サービスに対応するｐ−ｍｐ ＶＣが途中のリーフからＵＢＲサービスに対応する属性（リソース割り当てなし）に変わる場合等でも同様に行なえる。
【００８５】
但し、例えばＣＢＲサービスに対応するｐ−ｍｐ ＶＣが途中のリーフからＶＢＲサービスに対応する帯域割り当てに変わるような場合には、その分岐するＡＭＴノードにおいて、ＶＢＲとして規定されたトラヒックパラメータに従うようにトラヒックのシェイピングを行なう必要がある。
【００８６】
次にこのｐ−ｍｐ ＶＣ（呼識別子１０）の受信者２０３のサービス属性を通信中に変更する場合について説明する。受信者２０３は要求サービス属性をＱｏＳ有りからＱｏＳなし（ＵＢＲ）に変更するものとする。送信者１０１は自身の独自の判断か、あるいは受信者からの要求サービス属性変更の意思（ＲＳＶＰレベルのメッセージなど）を認識することにより、呼識別子１０で示されるｐ−ｍｐ ＶＣの受信者２０３に与えるＡＴＭレベルのサービス属性の変更を、ＡＴＭシグナリングの属性変更要求（呼識別子、受信者のアドレス、変更したい属性値などを含む）を用いて要求する。あるいは、受信者２０３が、自身の意思を反映したＡＴＭレベルの要求サービス属性情報を含む制御メッセージを属性変更要求として送出するのでもよい。
【００８７】
属性変更要求を受信したＡＴＭノード３０１は、受信した情報をもとに変更に関わる次段ノードへのリーフに必要な割り当てリソース量を受信者別サービス属性管理テーブル１７により再評価する。
【００８８】
この再評価は、次のように行われる。すなわち、次段のノード３０３を経由して既にサービスを受けている受信者（２０２，２０３）からＱｏＳの変更を要求した受信者（２０３）を除いた受信者（２０２：この場合は一つだが複数の場合もある）に提供されているサービス属性のうち対応するリソース量が最も大きいものと、ＱｏＳの変更を要求した受信者（２０３）に与えられるべき（変更後の）要求サービス属性に対応するリソース量とのうち、最も大きなものを求める。そして、その求めた結果が現在の割り当てリソース量と異なる場合は、割り当てリソース量の変更が必要と判断する。
【００８９】
再評価の結果、割り当てリソース量の変更が必要な場合には、リソース量の変更が可能である事を確認した後、コネクション別割り当てリソース管理テーブル１６の割り当てリソース量の内容を書き換える（図５（ｄ）では１０Ｍｂｐｓから０Ｍｂｐｓに書き換える）。それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）も変更する。
【００９０】
受信者別サービス属性管理テーブル１７の呼識別子１０に属する受信者２０３のサービス属性の内容もＵＢＲに変更する。そして次段ＡＴＭノード３０３に属性変更要求を送出する。
【００９１】
ＡＴＭノード３０３は属性変更要求を受信すると、ＡＴＭノード３０１と同様の手順で変更に関わるリーフに必要な割り当てリソース量を受信者別サービス属性管理テーブル管１７により再評価する。ＡＴＭノード３０３では変更に関わるリーフの受信者が２０３のみであるので、受信者２０３のサービス属性に必要なリソースがそのリーフに必要なリソースになる。リソース量の変更が可能であれば、コネクション別割り当てリソース管理テーブル１６と受信者別サービス属性管理テーブル１７の内容を更新し、さらに次段ＡＴＭノード３０５へ属性変更要求を送出する。
【００９２】
ＡＴＭノード３０５，３０６ではｐ−ｐ ＶＣの属性変更とまったく同様の方法で属性変更手順が実施される。このようにして、送信者１０１から受信者２０３までのＶＣの属性変更が実施されることになる。
【００９３】
ここで、図３（ｄ）に示すように、送信者１０１−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、ＡＴＭノード３０２−受信者２０１間のＶＣリンクの割り当て帯域は１０Ｍｂｐｓとなるが、残りのすべてのＶＣリンクの割り当て帯域はゼロとなる。
【００９４】
なお、ここではＱｏＳを減らす方向の要求がなされた場合を説明したが、増やす方向の要求がなされた場合も同様である。
【００９５】
以上述べた本実施形態における受信者のサービス属性変更時のＡＴＭノードでの処理アルゴリズムを、図７を用いて整理する。
【００９６】
属性変更要求を受信した（Ｓ７０１）ＡＴＭノード３０１のコネクション状態管理部１２は、受信した情報をもとに、受信者別サービス属性管理テーブルの対応する部分のサービス属性値を変更した場合の、変更に関わる次段ノードへのリーフに必要な割り当てリソース量を再評価する（Ｓ７０２，７０３）。この再評価はそのリーフの先の受信者の中で最も大きなリソースを必要とするものを認識することを意味する。
【００９７】
再評価の結果、割り当てリソース量の変更が必要な場合には、アドミッション制御部１４に対して変更したい割り当てリソース量の収容が可能かどうか問い合わせる。アドミッション制御部１４はリンク状態管理テーブル１５の情報をもとに収容可否を判断し、コネクション状態管理部１２へ通知する。コネクション状態管理部１２は属性変更に伴う割り当てリソースの変更が可能であるとわかると、そのリーフの割り当てリソース管理テーブル１６の内容を、変更後の割り当てリソース量に仮変更する（Ｓ７０４）。そして、再評価の結果にかかわらず、サービス属性管理テーブル１７中の変更対象受信者についての情報を仮変更し（Ｓ７０５）、次段ノードへ属性変更要求を送信する（Ｓ７０６）。
【００９８】
最後に、属性変更が実際に行われたか拒絶されたかを下流からの通知により知り（Ｓ７０７）、仮変更や仮追加の内容を確定する（Ｓ７０８）か、取り消す （Ｓ７０９）。
【００９９】
さらに、受信者をｐ−ｍｐ ＶＣから外す場合（図３（ｅ））には、各ＡＴＭノードにおいて受信者別サービス属性管理テーブル１７の内容の削除を行ない、その結果をもとに各出力リンクにおけるＶＣのリーフへの割り当てリソース量を決定する。
【０１００】
すなわち、次段のノード（３０１）を経由してサービスを受けていた受信者 （２０１，２０２，２０３）から離脱を要求した受信者（２０１）を除した受信者（２０２，２０３）に提供されているサービス属性のうち対応するリソース量が最も大きいものを求め、求めた結果が現在の割り当てリソース量と異なる場合は、割り当てリソース量の変更が必要と判断する。必要なら割り当てリソース管理テーブル１６の更新を行なう（図５（ｅ））。この例では残った受信者には割り当て帯域ゼロのサービス属性しか提供されていないため、送信者１０１−ＡＴＭノード３０１間のリーフをＵＢＲに変更する。
【０１０１】
次に本発明の他の具体例として、マルチキャスト通信の受信者により要求するサービス属性が異なる場合のｐ−ｍｐ ＶＣの設定、受信者の追加、受信者の要求属性変更、受信者削除時の他の手順について説明する。
【０１０２】
ＡＴＭ通信網の構成と、各場合におけるｐ−ｍｐ ＶＣの構成の時間的変化の様子は具体例１の図２、図３と同様である。本具体例において、図２におけるｐ−ｐ ＶＣの設定（ａ）、ｎｏｎ−ＱｏＳ受信者の追加（ｂ）の手順までは第１の具体例と同じ手順であるが、受信者別サービス属性管理テーブル４０２を必要としない点が具体例１と異なる。
【０１０３】
ＱｏＳを要求する受信者２０１、要求しない受信者２０２に対して設定されたｐ−ｍｐ ＶＣにさらに新たな受信者２０３が加わる場合について説明する。この受信者２０３は、２０１と同様に所定のＱｏＳを要求しているものとする。送信者１０１は、呼識別子１０で識別されるｐ−ｍｐ ＶＣへの新たな受信者２０３の追加を、ＡＴＭシグナリングのパーティ追加要求を用いて要求する。この際、受信者のために要求するサービス属性として、ＣＢＲサービス、セル廃棄率１０−８などと言ったものを指定する。
【０１０４】
パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報や要求サービス属性情報をもとに、あるいはあらかじめパーティ追加要求内に明示的に示された経路情報をもとに、次段ＡＴＭノード３０３（出力リンク２）を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向への呼識別子１０に相当するＶＣのリーフ（ＶＣリンク）の存在の有無をコネクション別割り当てリソース管理テーブル（図４（ｂ））により調べ、すでに存在する（ＶＰＩ／ＶＣＩ＝８０／４０）事を確認する。
【０１０５】
ただし、コネクション別割り当てリソース管理テーブル内の割り当てリソース量がゼロになっているため、このＶＣリンクは受信者２０３の要求サービス属性を満たすことはできない。ＡＴＭノード３０１では要求サービス属性を満たすために必要な割り当てリソース量を算出し、割り当てが可能であると確認すると、コネクション別割り当てリソース管理テーブルの割り当てリソース量の内容をゼロから例えば１０Ｍｂｐｓに書き換える（図４（ｃ））。
【０１０６】
それと同時に、ＡＴＭノード３０１における出力リンク２、ＶＰＩ／ＶＣＩ＝８０／４０のリーフに属するセルの転送制御用のパラメータ（優先クラスやスケジューラのパラメータなど）を、割り当てたリソース量に合うように変更する。そして次段ＡＴＭノード３０３にパーティ追加要求を送出する。具体例１と異なり、本具体例では受信者別サービス属性管理テーブルは保持する必要はない。ＡＴＭノード３０３はパーティ追加要求を受信すると次段ＡＴＭノード３０５へのＶＰＩ／ＶＣＩの捕捉、通信リソースの確保（ここでは１０Ｍｂｐｓ）を行なうとともにＡＴＭノード内のコネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ＡＴＭノード３０５へコネクション設定要求を送出する。
【０１０７】
ＡＴＭノード３０５，３０６では通常の新たなコネクション設定とまったく同じ手順でＶＣのリーフの拡張が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量 １０Ｍｂｐｓ）に新たな追加（仮追加）が行なわれる。
【０１０８】
このようにして受信者２０３までコネクション設定メッセージが転送され、受信者２０３はコネクション設定を受け付ける場合には、コネクション設定確認メッセージを送信者１０１に向けて送信する。コネクション設定確認メッセージはＡＴＭノード３０６，３０５，３０３，３０１を経由して送信者１０１まで転送される（３０３から上流へはパーティ追加確認メッセージというメッセージ名に変わる。）
この確認メッセージを下流から受信したＡＴＭノードのうち、その受信したインタフェース以外にもそのｐ−ｍｐ ＶＣの下流のリーフが存在しているノードでは以下の処理を行なった後に、その他のノードではそのまま、上流に対して確認メッセージを転送する必要がある。
【０１０９】
まず、図２（ｃ）におけるＡＴＭノード３０３の場合、ＡＴＭノード３０５から受信したコネクション設定確認メッセージ内に、実際に確保された（要求サービス属性に対応する）リソース量に相当する情報が記入されており、そのリソース量に関する（３０３−３０５間のリンクの確保リソースに関する情報）と、そのｐ−ｍｐ ＶＣに関する他のリーフである３０３−３０４間のリンクの確保リソースに関する情報（コネクション別割り当てリソース管理テーブルを参照）のうち最大値を決定し、上流ノード３０１へ送出するパーティ追加確認メッセージ内にその値を確保リソース量に関する情報として記入する。
【０１１０】
具体的には、ＡＴＭノード３０５から受信したコネクション設定確認メッセージ内に記載された確保リソース量の情報は１０Ｍｂｐｓ、ＡＴＭノード３０４との間のリンクに確保されているリソース量は０Ｍｂｐｓとなっており、よって１０Ｍｂｐｓを確保リソース量として上流ノード３０１へのパーティ追加確認メッセージに記入する。
【０１１１】
ＡＴＭノード３０１においても同様の処理が行なわれる。すなわち、ＡＴＭノード３０３から受信したパーティ追加確認メッセージ内に記入された確保リソース情報（１０Ｍｂｐｓ）と、コネクション別割り当てリソース管理テーブルに記憶されているＡＴＭノード３０２との間のリーフの割り当てリソース情報（１０Ｍｂｐｓ）とをもとに、送信ノード１０１へのパーティ追加確認メッセージに記入する確保リソース情報（１０Ｍｐｂｓ）を決定する。
【０１１２】
このようにして送信者１０１までパーティ追加確認メッセージが到着した時点でＡＴＭノード３０１，３０３で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【０１１３】
本具体例によれば、各ノードは、各々ｐ−ｍｐ ＶＣについて自ノードの下流に存在する全受信者の要求サービス属性を記憶せずとも、各出力リーフの先に存在する受信者（新たに加わった受信者、サービス属性変更要求をした受信者を含み、離脱した受信者を除く）の中で最大の通信リソース量を要するサービス属性を知ることができる。
【０１１４】
そして、これ以降また新たに受信者が加わる場合には、上記のように知らされた最大のサービス属性と、新たに加わる受信者用の要求サービス属性とを比較すれば、出力リーフに提供すべき最大サービス属性を求めることができる。
【０１１５】
また、上記確認メッセージにより、ある受信者がサービス属性変更要求をする場合に、その受信者を除いた受信者に対して提供すべきサービス属性とその受信者に対して変更後に提供すべきサービス属性とのうち、最大のものを知ることができ、出力リーフの割り当てリソースをこの求めた最大のサービス属性に対応するものに変更することができる。
【０１１６】
ある受信者が離脱する場合に、その受信者を除いた受信者に対して提供すべきサービス属性のうち最大のものも、同様に知って、出力リーフのリソース変更ができる。
【０１１７】
なお、上記確認メッセージの代わりに、ソフトステートで定期的に、各ノードの全出力リーフの先に存在する受信者の中で最大の通信リソース量を要するサービス属性を示すメッセージを上流ノードへ送るようにしても、同等のことが実現できる。
【０１１８】
ノードにＣＳＲを用いる場合には、このメッセージとしてＲＳＶＰを利用することもできる。
【０１１９】
（具体例２）
次に、本発明の他の例として、ｐ−ｍｐ ＶＣの設定時に要求するサービス属性を満たすためのリソース量が網内で確保できなかった場合の、ＡＴＭノードでの手順について説明する。帯域不足発生の箇所とその際のＡＴＭノードの動作の違いにより、３通りの場合について以下で説明する。なお、ここでは本例において特徴的な事項を説明するが、具体例１に述べた実施形態上の種々の変形は、本例においても適宜適用することができる。
【０１２０】
まず帯域不足の第１の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図８に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図９に示す。
【０１２１】
従来の方法との大きな違いは、コネクション設定、パーティ追加などの要求をＡＴＭノードが受信し、そのサービス属性要求を帯域不足により満たせなかった場合に、各要求を単に拒絶するのではなく、要求属性は満足しないが収容できる範囲内の帯域（あるいは帯域なし）でサービスを行なうことで、最低限コネクティビティだけでも提供することを可能にすることにある。
【０１２２】
まず図８（ａ）において、送信者１０１から受信者２０１へのｐ−ｐ ＶＣが設定されている（呼識別子を１０とする）。この際、受信者から送信者へアプリケーションレベルのＱｏＳの要求が、例えばネットワーク層（例えばＩＰ）の帯域予約プロトコル（例えばＲＳＶＰ）などで行なわれており、そのＱｏＳ要求を受けとった送信者はそのＱｏＳ要求を満たすに十分なＡＴＭレベルのサービス属性（サービスクラス、ピークセルレート、セルレベルのＱｏＳなど）を設定してＶＣ設定要求を行なっている。
【０１２３】
ＡＴＭノード３０１，３０２は要求されたサービス属性を満足するように出力リンク（物理的なリンクあるいは物理リンクを論理的に分割したＶＰ）におけるＶＣのリソースを確保し、それを記憶している。この時のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル１６、受信者別サービス属性管理テーブル１７の内容は、それぞれ図９の（ａ）の４０１，４０２に示すようになる。ここでは割り当てリソース量として簡単のために帯域のみを示したが、バッファ量など他のパラメータが含まれていても構わない。
【０１２４】
次にこのｐ−ｐ ＶＣ（呼識別子１０）に新たな受信者２０２が加わる場合について説明する。受信者が存在中のＶＣに加わる方法は、ＡＴＭのシグナリングに規定されているリーフ主導型のコネクション参加要求を受信者が送信者に対して送出する方法でも良いし、インタネットプロトコル（ＩＰ）が上位にいる場合（すなわち送信者、受信者がＩＰホストかルータの場合）にはＩＰのマルチキャストグループ参加要求メッセージやマルチキャスト用ルーティング情報交換メッセージを受信者が送信者または何らかのサーバに送信し、送信者がそれを知るとＡＴＭシグナリングのパーティ追加要求で受信者の追加を要求する方法でも良い。
【０１２５】
この新たな受信者２０２は、すでに接続されている受信者２０１と同様に特定のＱｏＳを要求しているものとする。この場合、送信者１０１は呼識別子１０で識別される受信者２０１宛のｐ−ｐ ＶＣへの新たな受信者２０２の追加をＡＴＭシグナリングのパーティ追加要求を用いて要求する。
【０１２６】
この際、要求するサービス属性として例えばピーク速度１０ＭｂｐｓのＣＢＲサービスを指定する。パーティ追加要求を受信したＡＴＭノード３０１は、追加すべき受信者のアドレス情報やサービス属性情報をもとにその経路を決定するとともに、出力リンク２から次段ＡＴＭノード３０３方向へ新たなＶＣの分岐を作成するためにＶＰＩ／ＶＣＩ値の確保（ここでは８０／４０）を行なう。さらに通信リソースの確保を試みるが、ここで帯域不足によりそれが行なえないとする。
【０１２７】
従来はこの時点でパーティ追加拒絶通知を上流へ戻すが、ここでは出力リンクの空き状況が許容する範囲まで割り当てリソース量を下げて（あるいは割り当てリソースをなしにして）確保する。
【０１２８】
図８の（ｂ）の例では割り当てリソースをゼロ（ＵＢＲ）にした場合を示している。そして図９（ｂ）の受信者別サービス属性管理テーブル４０２に出力リンク２上のＶＰＩ／ＶＣＩ＝８０／４０に対応する受信者２０２の要求サービス属性情報（ＣＢＲ）を加えるとともに、このＡＴＭノードにおいて要求サービス属性を満足する帯域が受信者に与えられているか否かを示すフィールド（図９（ｂ）の成否）に帯域が与えられていない旨（否）を示しておく。
【０１２９】
また、図９（ｂ）のコネクション別割り当てリソース管理テーブル４０１のＶＰＩ／ＶＣＩ＝８０／４０のエントリに、相当するＶＣリンクの帯域は０Ｍｂｐｓであり、このＡＴＭノード３０１において帯域不足による割り当てリソースの変更を行なった旨を帯域変更タグＯＮで示しておく。これにより後に帯域の再割り当て要求を自身の判断で行なうことも可能にする。
【０１３０】
ここで、サービス属性管理テーブル１７の「成否」は、単にこのノードの時点で満足な帯域が与えられているか否かを示す。すなわち、このノードでは帯域不足ではないが上流のノードで帯域不足による変更が起こったためにこのノードでも要求サービス属性を満たすリソース量が割り当てられていないという場合にも、「成否」のフィールドには否（Ｘ）と記載されるし、自身より下流のノードで帯域不足が起こって上流まで遡って帯域取消をする場合にも、「成否」はＸになる。
【０１３１】
一方、「帯域変更タグ」はこのノードで初めて帯域不足による変更を余儀なくされたどうかを示す。つまり、自身より上流または下流で起こった帯域不足の場合には、自身の「帯域変更タグ」はＯＦＦのままである。
【０１３２】
次にＡＴＭノード３０１は次段ＡＴＭノード３０３へコネクション設定要求を送出する。その際は要求サービス属性（ＣＢＲ）とともに、すでに自ノードで割り当てリソースを変更した旨および変更した割り当てリソース量をいっしょに通知する。
【０１３３】
ＡＴＭノード３０３，３０４では通常の新たなコネクション設定と同様の手順でＶＣのリーフの追加が行なわれるとともに、各々のノード内のコネクション別割り当てリソース管理テーブル（割り当てリソース量ゼロ、帯域変更タグはＯＦＦ）と受信者別サービス属性管理テーブル（サービス属性はＣＢＲ、成否フィールドは否）に新たな追加が行なわれる。
【０１３４】
すなわち、ＡＴＭノード３０３，３０４では、要求サービス属性に対応するリソース量を割り当てるのではなく、上流のノード３０１で変更された割り当てリソース量を越えない範囲でＶＣリンクの帯域を割り当てる。このようにして受信者２０２までのＶＣのリーフの追加が終了した時点で、ＡＴＭノード３０１で分岐するｐ−ｍｐ ＶＣが形成されたことになる。
【０１３５】
ここで、送信者−ＡＴＭノード３０１間、ＡＴＭノード３０１−３０２間、３０２−受信者２０１間の割り当て帯域は１０Ｍｂｐｓとなるが、新しく追加したＡＴＭノード３０１−３０３間、３０３−３０４間、３０４−受信者２０２間のリーフの割り当て帯域はゼロとなっている。
【０１３６】
受信者２０２はＵＢＲに割り当てリソース量が変更されたＶＣ設定要求を受信すると、それを受け付けるか受け付けないかを決定できるので、ＱｏＳが満足できなくて受け付けても意味がないと考えれば拒絶すれば良い。
【０１３７】
また送信者１０１はパーティ追加要求あるいはＶＣ設定要求を送出する際に、途中で帯域不足が生じた場合には割り当て帯域を落してでも（あるいは割り当て帯域ゼロにしてでも）相手に接続したいか、十分な帯域が割り当てられない場合には接続をしないで欲しいかの希望を示すフィールドをメッセージに付加しても良い。
【０１３８】
ＡＴＭノード３０１−３０３間のリンクの帯域不足が解消し、図８（ｃ）に示すようにＡＴＭノード３０１から受信者２０２まで要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成するが成功すれば、ＡＴＭノード３０１のコネクション割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は、図９（ｃ）のように変更される。このリーフの再構成の具体的手順については後述する。
【０１３９】
以上述べた本実施形態における帯域不足に対処可能なＡＴＭノードでの処理アルゴリズムを、図１０に示す。
【０１４０】
（具体例２−２）
帯域不足の第２の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図１１に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図１２に示す。
【０１４１】
第２の場合とは、既存のＶＣへの受信者追加の際にｐ−ｍｐ ＶＣが分岐したあとのＡＴＭノード３０３で出力リンクの帯域が不足した場合である。この場合も図８（ｂ）のＡＴＭノード３０１で帯域不足が生じた時と同様に、そのＡＴＭノードから先のＶＣの割り当て帯域を変更（この例ではゼロ）してＶＣ設定を先まで進める方法がまず考えられる（図１１（ｂ））。このとき、ＡＴＭノード３０３では、帯域変更タグをＯＮに、成否フィールドを否とし、ＡＴＭノード３０４では、帯域変更タグをＯＦＦに、成否フィールドを否とする。
【０１４２】
但しこの場合には、すでにＣＢＲとして確保したＡＴＭノード３０１−３０３間の帯域はあまり意味のないものになる。
【０１４３】
図１２に、この場合のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル４０１、受信者別サービス属性管理テーブル４０２の変化の様子を示している。ＡＴＭノード３０１は自身では帯域不足を生じなかったため、図１２（ｂ）の帯域変更タグはＯＦＦであり、成否フラグは「成（Ｏ）」になる。下流ノードである３０３で帯域不足が生じたため、最終的にはＶＣの要求サービス属性は満たせていないが、この例では、帯域不足が生じたＡＴＭノードから先の受信者までのリーフにのみ要求サービス属性を満たさないリソース量を割り当てるので、ＡＴＭノード３０１は下流ノードで帯域不足が生じたことを必ずしも知る必要はない。
【０１４４】
このようにして帯域不足によりＡＴＭノード３０３−受信者２０２間の帯域は要求サービス属性を満足しないものになっているが、ＡＴＭノード３０３−３０４間の帯域不足が解消し、図１１（ｃ）に示すようにＡＴＭノード３０３から受信者２０２までの要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成することが成功すれば、ＡＴＭノード３０１のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は図１２（ｂ）に同じであるが、ＡＴＭノード３０３，３０４の各テーブルの内容は変更される。このリーフの再構成の具体的手順については後述する。
【０１４５】
なお、本例におけるＡＴＭノードでの処理アルゴリズムは、図１０と同様である。
【０１４６】
（具体例２−３）
帯域不足の第３の場合について、ＡＴＭ通信網の構成例と、受信者の追加によるｐ−ｍｐ ＶＣの構成の時間的変化の様子を図１３に、その場合のＡＴＭノード３０１の持つ網リソース管理に関わる情報の変化の様子を図１４に示す。
【０１４７】
第３の場合は第２の場合と同様に、既存のＶＣへの受信者追加の際にｐ−ｍｐＶＣが分岐したあとのＡＴＭノード３０３で出力リンクの帯域が不足した場合である。この例では第２の場合とは異なり、図１３（ｂ０）（ｂ１）に示すように帯域不足のＡＴＭノード３０３から先の割り当て帯域を変更するとともに、すでに確保した上流のリンクの帯域をノード３０３以降で割り当てた帯域と同じものに、分岐点（ＡＴＭノード３０１）までさかのぼって変更する。
【０１４８】
これにより、実際の帯域不足はＡＴＭノード３０３−３０４間のリンクで発生したが、それより上流のＡＴＭノード３０１から割り当て帯域が変更（この例ではゼロ（ＵＢＲ））されている。この方法は手順は第２の場合より複雑になるが、ムダな帯域を確保することを防ぐ効果がある。
【０１４９】
図１４に、この場合のＡＴＭノード３０１の持つコネクション別割り当てリソース管理テーブル４０１、受信者別サービス属性管理テーブル４０２の変化の様子を示している。ＡＴＭノードにおいて帯域が無事確保できた際に図１４（ｂ０）においていったん登録したテーブル情報を、下流にて帯域不足が発生したことを知ることで図１４（ｂ１）において変更している。
【０１５０】
下流ノードで帯域不足が生じたことは、送信者も含めたすべての上流ノードにおいて以下のような方法で知ることができる。
【０１５１】
一つの方法では、ＡＴＭノード３０３において帯域不足により割り当てリソースが変更された形で受信者２０２にＶＣ設定要求が到達し、受信者２０２がその設定要求を受け付けてＶＣ設定確認を送信者１０１へ戻す際に、提供されたＶＣのリソースは要求属性を満たさないものになっている旨をＶＣ設定確認の中の情報として示す方法である。
【０１５２】
あるいは、帯域不足の発生したＡＴＭノードで、下流にＶＣ設定を転送すると同時に上流に帯域不足のあった旨を別の制御メッセージで通知する方法もある。
いずれにしても、図１４（ｂ１）において、下流で与えた割り当てリソース（この例ではゼロ）と同じレベルまで、ＡＴＭノード３０１での対応するＶＣリンクの割り当てリソースも変更する。
【０１５３】
なお、ＡＴＭノード３０１は、ＡＴＭノード３０３を経由して既にサービスを受けている受信者の中に、帯域不足の発生したＡＴＭノードで割り当てた帯域よりも大きな帯域の必要な要求サービス属性を持つものが存在しないことを確認し（図１３，１４の例では存在しない）、上記割り当てリソースの変更を行う。
【０１５４】
このようにして帯域不足によりＡＴＭノード３０１−受信者２０２間の帯域は要求サービス属性を満足しないものになっているが、ＡＴＭノード３０３−３０４間の帯域不足が解消し、図１３（ｃ）に示すようにＡＴＭノード３０３から受信者２０２までの要求サービス属性を満足するｐ−ｍｐ ＶＣのリーフを再構成することが成功すれば、ＡＴＭノード３０１のコネクション別割り当てリソース管理テーブルと受信者別サービス属性管理テーブルの内容は、図１４（ｃ）のように変更される。このリーフの再構成の具体的手順については後述する。
【０１５５】
（具体例２−４）
以上述べたように、所望のサービス属性を満たすだけの帯域の確保が途中のＡＴＭノードで行なえない場合には、途中のＡＴＭノードから所望のサービス属性を満たさないリソース量のコネクション設定を行なうことが可能である。しかしながらその後、帯域不足の出力リンクの帯域不足が解消された場合には、可能ならば所望のサービス属性を満たすようにコネクションの割り当て帯域を変更しても構わない。以下ではその実現方法の具体例を説明する。
【０１５６】
例えば、所望のサービス属性を満たさないコネクションが張られていることを知っている送信者あるいは受信者が、適当な時間の後にコネクション帯域の変更要求を送信する。この変更要求を受け、自ノードの成否フラグが「否（Ｘ）」になっているＡＴＭノード（例えば図８（ｂ）のノード３０１、図１１（ｂ）のノード３０３、図１３（ｂ１）のノード３０１）は、対応するリンクの帯域が現在は所望の属性を満たすように確保できるようになっているか否かを調べ、もし確保できるならば確保し、コネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ＡＴＭノードへ帯域変更要求を転送する。これを受信者２０２まで行なうことで、所望のサービス属性を満たすようなコネクションの帯域変更が成功する。
【０１５７】
あるいは、帯域不足により所望のサービス属性を満たさない割り当て帯域でＶＣリンクを設定した（自ノードの帯域変更タグがＯＮになっている）ＡＴＭノード（例えば図８（ｂ）の３０１、図１１（ｂ）の３０３）は、他のＡＴＭノードと定期的に交換している各リンク間のリソース使用状況に関する情報をチェックし、空き帯域ができたと判断した場合にはそのＡＴＭノードが所望の属性を満たすように割り当て帯域を設定し、コネクション別割り当てリソース管理テーブルの内容を更新し、さらに次段ノードへ帯域変更要求を転送する。これを受信者まで行なうことで、所望のサービス属性を満たすようなコネクションの帯域変更が成功する。
【０１５８】
図１３（ｂ１）のように、帯域不足のリンク（ＡＴＭノード３０３−３０４間）とＶＣリンクへの割り当て帯域を途中で変更したＡＴＭノード（３０１）とが直接つながっていない場合は、定期的に交換する各リンクのリソース使用状況に関する情報がわかるようなプロトコルが動作している場合には、上述した方法と同様にＡＴＭノード３０３−３０４間のリンクの空き帯域ができたことをＡＴＭノード３０１が認識した時点で帯域変更要求を送出すればよい。そうしたリンク使用状況がわからないような場合には、図１３のＡＴＭノード３０１が定期的に帯域変更要求を送出して、もし空き帯域ができていれば帯域変更が行なわれる。
このように、図１３（ｂ１）のノード３０１が、上記プロトコルにより離れたリンク（３０３−３０４間）のリソース状況を知って、もしくは、定期的に、帯域変更要求を送出するためには、ノード３０１は自ノードが不十分な帯域が割り当てられている区間の先頭であることを認識する必要がある。そのためには、上記帯域変更タグとは別に、「先頭タグ」を設けておくのが望ましい。つまり、各ノードは、ｐ−ｍｐ ＶＣのリーフの設定の際に、自ノードより下流のノードで帯域不足が起こったために自ノードで一旦行なった帯域の確保を取り消し、且つ、自ノードの上流へは帯域の確保の取り消しを示唆するＶＣ設定確認もしくは制御メッセージを送っていない場合に、先頭タグをＯＮにする。
【０１５９】
なお、更に別の方法として、図１３（ｂ１）のノード３０３（帯域変更タグＯＮ）が、帯域不足が解消したときに出力ＶＣリンク（３０３−３０４間）の割り当て帯域を変更するとともに、上流ノード３０１に入力ＶＣリンク（３０１−３０３間）の割り当て帯域を十分なものに引き上げるよう通知することも可能である。
【０１６０】
【発明の効果】
本発明によれば、受信者の要求サービス属性の違いや利用可能な通信帯域の違いに応じたひとつのポイント−マルチポイントコネクションの形成が可能になる。
【図面の簡単な説明】
【図１】本実施形態に係るノード装置のコネクション制御を行う部分の機能構成を示す図
【図２】新たな受信者のためのＶＣリンクを追加する場合を説明するための図
【図３】受信者のＱｏＳ変更及び離脱が要求された場合を説明するための図
【図４】図２の場合の各テーブルの内容例を示す図
【図５】図３の場合の各テーブルの内容例を示す図
【図６】図２の場合のノードの動作を示すフローチャート
【図７】図３の場合のノードの動作を示すフローチャート
【図８】リソース量が不足した場合のＶＣリンクの追加の第１の例を説明するための図
【図９】図８の場合の各テーブルの内容例を示す図
【図１０】図８の場合のノードの動作を示すフローチャート
【図１１】リソース量が不足した場合のＶＣリンクの追加の第２の例を説明するための図
【図１２】図１１の場合の各テーブルの内容例を示す図
【図１３】リソース量が不足した場合のＶＣリンクの追加の第３の例を説明するための図
【図１４】図１３の場合の各テーブルの内容例を示す図
【符号の説明】
１１…シグナリングメッセージ処理部
１２…コネクション状態管理部
１３…経路制御部
１４…アドミッション制御部
１５…リンク状態管理テーブル
１６…コネクション別割り当てリソース管理テーブル
１７…受信者別サービス属性管理テーブル
Claims (16)
- 送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、
前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ）リンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、
この受信した設定要求に示されるもしくは対応して示される要求サービス属性が、前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前段のノード装置から前記ノード装置へ向かう入力ＶＣリンクに提供されているサービス属性とは異なる場合に、前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とするノード装置。 - 前記設定させる手段は、前記要求サービス属性の方が前記入力ＶＣリンクに提供されているサービス属性より、そのサービス属性に対応する通信リソース量が小さい場合に、前記要求サービス属性に対応する通信リソース量を割り当てた新たなＶＣリンクを設定させるものであることを特徴とする請求項１記載のノード装置。
- 前記設定させる手段が前記要求サービス属性に対応する通信リソース量を割り当てた新たな出力ＶＣリンクを設定させるのは、前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置よりも送信者側のＶＣリンクの中に、該新たな出力ＶＣリンクに対応した要求サービス属性を満たさない通信リソース量が割り当てられているＶＣリンクが存在しない場合であることを特徴とする請求項１記載のノード装置。
- 非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、
前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべき要求サービス属性が前記入力ＶＣリンクに提供されているサービス属性とは異なるならば、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、
この設定される出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性に対応する通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とするマルチキャスト通信制御方法。 - 前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記要求サービス属性よりも、前記入力ＶＣリンクに提供されているサービス属性の方が、そのサービス属性に対応する通信リソース量が小さいならば、前記入力ＶＣリンクに割り当てられる通信リソース量を前記要求サービス属性に対応する量に変更することを特徴とする請求項４記載のマルチキャスト通信制御方法。
- 送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスを提供可能な非同期転送モード型通信網を構成するノード装置において、
前記マルチキャスト通信サービスに供されるポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうち前記ノード装置から次段のノード装置へ向かう出力ＶＣリンクとは異なる新たな出力ＶＣリンクの設定要求を受信する手段と、
この受信した設定要求に示されるもしくは対応して示される要求サービス属性に対応する第１の通信リソース量を割り当てた新たな出力ＶＣリンクが設定できない場合に、新たな出力ＶＣリンクが設定可能な第２の通信リソース量を割り当てた新たな出力ＶＣリンクを、前記ポイント−マルチポイントコネクションを構成するＶＣリンクとして、設定させる手段とを備えたことを特徴とするノード装置。 - 非同期転送モード型通信網において、送信者から送出された通信情報が１つ以上の受信者に受信されるマルチキャスト通信サービスに供されるポイント−マルチポイントコネクションに、該マルチキャスト通信サービスに対し新たに参加を要求した受信者のために新たなＶＣリンクを追加するマルチキャスト通信制御方法であって、
前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、新たに参加を要求した前記受信者に与えられるべきサービス属性に対応する第１の通信リソース量を割り当てたＶＣリンクが設定不可能ならば、前記第１の通信リソース量より小さいかあるいは０である第２の通信リソース量を割り当てたＶＣリンクを、前記出力ＶＣリンクとして設定し、
この設定された出力ＶＣリンクを入力ＶＣリンクとし、さらに追加すべき新たなＶＣリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てたＶＣリンクを、該さらに追加すべき新たなＶＣリンクがなるべき出力ＶＣリンクとして設定することを特徴とするマルチキャスト通信制御方法。 - 前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記入力ＶＣリンクに対する出力ＶＣリンクに割り当てられている通信リソース量のうち、前記第２の通信リソース量より大きなものが存在するか否かを調べ、
存在しない場合には、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更することを特徴とする請求項７記載のマルチキャスト通信制御方法。 - 前記設定させる手段により前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したことを記憶する手段をさらに備え、
前記設定させる手段は、この記憶する手段により前記第１の通信リソース量を割り当てたＶＣリンクが設定できないために前記第２の通信リソース量が割り当てられていることが示される場合に、前記第１の通信リソース量の割り当てが可能になったか否かを調べ、可能になっていれば前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更する手段を含むことを特徴とする請求項６記載のノード装置。 - 前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更し、
この通信リソース量の変更された出力ＶＣリンクを入力ＶＣリンクとし、前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶＣリンクが出力ＶＣリンクとなる場合に、割り当てが可能であれば前記受信者に与えられるべきサービス属性に対応しない前記第２の通信リソース量が割り当てられているＶ Ｃリンクがなるべき出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更することを特徴とする請求項７記載のマルチキャスト通信制御方法。 - 前記ポイント−マルチポイントコネクションを既に構成しているＶＣリンクのうちの一つを入力ＶＣリンクとし、追加すべき新たなリンクが出力ＶＣリンクとなる場合に、前記第２の通信リソース量を割り当てて前記出力ＶＣリンクを設定したならば、前記第１の通信リソース量の割り当てが可能になったときに、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更し、
前記入力ＶＣリンクに割り当てられる通信リソース量を前記第２の通信リソース量に変更したならば、前記出力ＶＣリンクの通信リソース量を前記第１の通信リソース量に変更するときに、前記入力ＶＣリンクに割り当てられる通信リソース量を前記第１の通信リソース量に変更することを特徴とする請求項８記載のマルチキャスト通信制御方法。 - 入力ＶＣリンクと複数の出力ＶＣリンクを用い、送信者から複数の受信者に通信データを送信するマルチキャスト通信サービスを提供可能なノード装置において、
マルチキャスト通信サービスに用いられるポイント−マルチポイントコネクションを維持する維持手段と、
このマルチキャスト通信サービスのための新たな出力ＶＣリンクの設定要求、及び、この新たなＶＣリンクに対する要求サービス属性を受信する受信手段と、この設定要求に応え、前記要求サービス属性を調べ、入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを前記ポイント−マルチポイントコネクションに加える設定手段とを具備することを特徴とするノード装置。 - 前記設定手段は、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする請求項１２記載のノード装置。
- 前記設定手段は、前記要求サービス属性を満たす通信リソース量が確保できない場合に、前記入力ＶＣリンクのサービス属性とは異なるサービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする請求項１２記載のノード装置。
- 前記受信手段は、前記要求サービス属性を含む前記設定要求を受信するものであり、
前記設定手段は、この設定要求をデータリンク層で処理し、前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする請求項１２に記載のノード装置。 - 前記受信手段は、前記要求サービス属性を含むメッセージを受信するものであり、
前記設定手段は、このメッセージをネットワーク層で処理し、この処理結果に基づいて前記要求サービス属性を持つ新たな出力ＶＣリンクを加えるものであることを特徴とする請求項１２記載のノード装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02246897A JP3592876B2 (ja) | 1996-02-05 | 1997-02-05 | マルチキャスト通信制御方法及びノード装置 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1899096 | 1996-02-05 | ||
| JP8-18990 | 1996-02-05 | ||
| JP02246897A JP3592876B2 (ja) | 1996-02-05 | 1997-02-05 | マルチキャスト通信制御方法及びノード装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09275408A JPH09275408A (ja) | 1997-10-21 |
| JP3592876B2 true JP3592876B2 (ja) | 2004-11-24 |
Family
ID=26355778
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02246897A Expired - Fee Related JP3592876B2 (ja) | 1996-02-05 | 1997-02-05 | マルチキャスト通信制御方法及びノード装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3592876B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001024662A (ja) * | 1999-07-09 | 2001-01-26 | Nec Commun Syst Ltd | 通信制御方式 |
-
1997
- 1997-02-05 JP JP02246897A patent/JP3592876B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09275408A (ja) | 1997-10-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6144661A (en) | Network node apparatus and virtual connection control method for providing various service attributes in multicast communication | |
| US6167051A (en) | Network node and method of packet transfer | |
| JP2977029B2 (ja) | 高速ａｔｍセル伝送を使用したインターネットプロトコルスイッチング方法及びそのためのネットワーク | |
| JP3480801B2 (ja) | パケット転送方法及びノード装置 | |
| EP0941010B1 (en) | Method and apparatus for provisioned and dynamic quality of service in a communications network | |
| US6671276B1 (en) | Switch based network architecture for IP multicast and integrated services | |
| US5835710A (en) | Network interconnection apparatus, network node apparatus, and packet transfer method for high speed, large capacity inter-network communication | |
| US20020071390A1 (en) | System and method for estabilishing a commucication path associated with an MPLS implementation on an ATM platform | |
| EP1213879B1 (en) | An MPLS implementation on an ATM platform | |
| JPH09247190A (ja) | 通信ネットワークのオペレーティング方法 | |
| US6385200B1 (en) | Broadcast control system, network element, and switching node apparatus with broadcast cell routing capabilities in asynchronous transmission mode network | |
| US6826184B1 (en) | Method and system for multi-service cut-through switching through a connection-oriented network | |
| US6515999B1 (en) | Router apparatus and method of using a virtual connection to transfer a packet | |
| JP3592876B2 (ja) | マルチキャスト通信制御方法及びノード装置 | |
| KR20010016690A (ko) | 멀티캐스트 통신 서비스 제공 시스템 및 멀티캐스트 서비스제어방법 | |
| WO1998037730A1 (en) | Resource reservation in atm networks | |
| JP3696166B2 (ja) | ノード装置及びパケット転送方法 | |
| US6845101B1 (en) | Method and a network for ATM switching | |
| US8396052B1 (en) | Apparatus and method for synchronous and asynchronous switching of internet protocol traffic | |
| JP3383295B2 (ja) | ノード装置及びパケット転送方法 | |
| JPH0795214A (ja) | Ａｔｍ通信システムの網立ち上げ方法、バーチャルパス使用方法、データグラム配送方法、及び帯域割り当て方法 | |
| JPH10247916A (ja) | 通信ネットワークおよびエッジデバイスおよびコネクション設定方法 | |
| Bastos et al. | Optimising bandwidth reservation in IP/ATM internetworks using the guaranteed delay service | |
| Zavialov | Distributed Failure Restoration for Asynchronous Transfer Mode (ATM) Tactical Communication Networks | |
| Zurich | Provisioning of RSVP-based Services over a Large ATM Network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040525 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040601 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040802 |
|
| 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: 20040824 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040826 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070903 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |