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

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

Info

Publication number
JP2010103968A
JP2010103968A JP2009126097A JP2009126097A JP2010103968A JP 2010103968 A JP2010103968 A JP 2010103968A JP 2009126097 A JP2009126097 A JP 2009126097A JP 2009126097 A JP2009126097 A JP 2009126097A JP 2010103968 A JP2010103968 A JP 2010103968A
Authority
JP
Japan
Prior art keywords
network
bandwidth
processing unit
information
transfer processing
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.)
Granted
Application number
JP2009126097A
Other languages
English (en)
Other versions
JP4802261B2 (ja
Inventor
Takashi Utahara
崇 歌原
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2009126097A priority Critical patent/JP4802261B2/ja
Publication of JP2010103968A publication Critical patent/JP2010103968A/ja
Application granted granted Critical
Publication of JP4802261B2 publication Critical patent/JP4802261B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】インターネットと比較してより一定の品質を保証し、より高い情報セキュリティを担保し、従来の電機通信網回線レベルに近い高信頼性のIP回線を提供するためには、SIP信号の通信路とリソース管理部を実現する。
【解決手段】呼処理サーバは、呼処理を行う呼処理部と、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してSIPネゴシエーションの結果得られる要求帯域を、メディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって経路帯域を判定して経路選択を行い、1以上の転送処理部の中から自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する。
【選択図】図1

Description

本発明は、通信ネットワークを構成するルータとは独立したリソース管理部(リソース管理サーバ)を用いて、ルータやパケット転送装置間のリンクの利用可能な帯域(リソース)を管理するリソース管理システムおよびリソース管理方法に関する。
従来、リソース管理部(リソース管理サーバ)を用いて、ルータやパケット転送装置間のリンクの利用可能な帯域をリソース量として、その利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適切な容量のリソースを払い出す方式が採用されている。また、ユーザ端末間で必要なトラヒックに対するリソース量はSIP(Session Initiation Protocol)を用いてネゴシエーションして決定され、ユーザ端末間やユーザ端末とサーバ間でSIPを用いてネゴシエーションが行われる際に、リソース管理部に対して帯域の予約と確保要求、通信ネットワークへのポリシング設定が行われる。ここで、ポリシング設定とは、IPアドレス、ポート番号を対象としたクラシファイ、カラーリング、マーキング、シェイピング、ドロッピング、ディスカードなどである。すなわち、通信ネットワークへのポリシング設定により、トラヒックが制御されて適切なQoSがリソース管理部により提供される。
ところで、従来のリソース管理部はアクセス系のネットワークに限られ、アクセス系のネットワークのSIP信号はユーザ端末の発呼ごとになり、アクセス区間のリソースを使用するメディア通信のトラヒックに比べて少ないので特段の考慮がなされていない。
また、中継網、特に他網との接続に対してその境界ゲートウェイに対して、同じようなリソース管理と転送網へのポリシング設定を行う場合、SIP信号は同じ束として扱うことが可能となる。このため、無視できない値であるが、従来技術では考慮されていなかった。
NTT技術ジャーナル2007年4月、「NGNが提供する新しいコミュニケーションとそれを支える技術」
呼処理サーバのリソース管理部(RACS:Resource and Admission Control Subsystem)と複数の転送処理部(I−BGF:Interconnection Border Gateway Function )を含む次世代の通信ネットワーク(NGN:Next Generation Network )では、インターネットと比較してより一定の品質を保証し、より高い情報セキュリティを担保し、従来の電機通信網回線レベルに近い高信頼性のIP回線を提供するためには、SIP信号の通信路(SIP信号路)とリソース管理部を実現することが課題となる。
ところで、バックボーンネットワークや中継網において、物理リンクの冗長構成は一般的である。物理的なネットワークでは、その方路への経路中のいずれかの物理リンクの上限がボトルネックになり、最後に加わったユーザのトラヒックにより上限に達する場合、このユーザの影響が他のユーザの通信にも影響を及ぼすことがある。1ホップ程度の物理リンクの冗長であれば、装置からのロードバランスというアプローチ手段も考えられている。
また、アクセスラインでは、ユーザ毎の契約帯域とその上限帯域以内でのサービス利用を許可するために、ユーザがサービスを利用する毎に使用帯域を申告させ、ユーザの申告帯域の積み上げが、ユーザの契約帯域の上限に収まるかどうかを判定している。そして、契約帯域の上限に収まる場合には、通信を許可する受付制御と、受付許可した利用種別毎に実際のトラヒックの通過を許可するピンホール制御を行うことが研究されてきた。ユーザの契約帯域を仮想的なリソースとして仮想パスとして管理するリソース管理サーバによるリソース管理方式がこれにあたる。
しかし、バックボーンや中継網では十分なリソースが用意され、ユーザの契約帯域毎にリソースの受付を判断する必要はない。ただし、中継網では、接続事業者毎に接続を許可する帯域が守られているかどうかを、ユーザ毎に判断する必要がある。仮に自網では、アクセスライン毎およびユーザの契約帯域毎に受付を許可していたとしても、図12に示すように他網1向けのユーザに偏っていた場合に、接続事業者毎の帯域を超えている場合が考えられる。この場合に、自網のユーザや、他網1と共用している区間でトラヒックが重なって信号遅延やパケットロスなど通信障害が発生する可能性がある。
さらに、他網1への中継網がI−BGF1とI−BGF2で冗長構成をとっている場合に、それぞれの性能緒元や接続可能な物理リンクのボトルネックを加味して振り分けをしないと、やはりトラヒックが偏ってしまう可能性がある。
特に、図13に示すように、複数の接続事業者でI−BGF2をとりあいになっている場合には、前者と後者のバランスを考えないと、ある接続事業者へのトラヒックが他の接続事業者へのトラヒックに影響を与えてしまう可能性がある。
本発明は、呼処理サーバと転送処理部(I−BGF)を含む自網と、呼処理部を含む他網が接続される網構成において、呼処理サーバのリソース管理部(RACS)がユーザとの契約に基づくサービス品質を満足させるためのトラヒックの規定と受付制御を実施することができるリソース管理システムおよびリソース管理方法を提供することを目的とする。
第1の発明は、呼処理サーバと1以上の転送処理部を含む自網と、少なくとも1つの呼処理部を含む他網が接続される網構成のリソース管理システムにおいて、呼処理サーバは、ユーザ端末間のSIPネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行う呼処理部と、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してSIPネゴシエーションの結果得られる要求帯域を、SIPネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって転送処理部を含む経路帯域を判定して経路選択を行う手段と、1以上の転送処理部から他網と接続するための転送処理部を選択する際に、自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する手段とを備える。
ここで、ネットワークリソース情報は、転送処理部区間仮想パス構成情報と、網間仮想パス構成情報と、RACS受付優先度情報と、QoSクラス設定情報とを含む。データフロー情報は、ピークレート情報と、QoSクラス識別情報と、受付優先度と、受付優先クラス識別情報とを含む。セッション状態情報は、ユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報を含む。
また、第1の発明のリソース管理システムにおいて、呼処理サーバは、ユーザが通信時に送受信するメディアトラヒックの帯域確保要求時に転送処理部に対して自網側のポリシング設定を識別する識別子と他網側のポリシング設定を識別する識別子を転送処理部内で一意に識別可能な識別子の払い出しを要求するメッセージを送信し、同時に自網側の識別子と他網側の識別子のペアを識別管理するための転送処理部でユニークな識別子も転送処理部に払い出しを要求し、自網側の識別子と他網側の識別子とこのペアを識別する識別子を転送処理部ごとに記憶する手段を備える。
第2の発明は、呼処理サーバと1以上の転送処理部を含む自網と、少なくとも1つの呼処理部を含む他網が接続される網構成のリソース管理方法において、呼処理サーバの呼処理部は、ユーザ端末間のSIPネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行い、呼処理サーバのリソース管理部は、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してSIPネゴシエーションの結果得られる要求帯域を、SIPネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理し、さらに、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって転送処理部を含む経路帯域を判定して経路選択を行い、1以上の転送処理部から他網と接続するための転送処理部を選択する際に、自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する。
第2の発明のリソース管理方法において、リソース管理部が加入端末からの呼(SIP)に対応したサービスセッション制御信号を受信する第1のステップと、呼に対応したセッション状態情報を読み出す第2のステップと、呼に対応した使用可能な候補経路についてネットワークリソース情報を読み出す第3のステップと、ストリーム数および帯域使用率による転送処理部の選択が可能か否かを判定する第4のステップと、第4のステップで転送処理部の選択が可能なときに、呼に対応したデータフロー情報を読み出し、メディアの追加または削除の条件判定を行う第5のステップと、第5のステップの条件を満たさないときに、「ストリーム数が少ない>帯域使用率が低い」の優先順位に基づいて次優先の転送処理部を選択して第4のステップに戻る第6のステップと、第5のステップの条件を満たすときに、候補経路につき呼に対応したセッション状態情報から仮想パス選択論理を適用した転送処理部を決定する第7のステップと、第7のステップで決定した転送処理部の経路で対応したSIPセッション制御処理を行う第8のステップと、第4のステップまたは第6のステップで転送処理部の選択が不可のときに、呼の帯域確保要求に対してエラー返却を行う第9のステップとを有する。
本発明は、RACSがユーザとの契約に基づくサービス品質を満足させるためのトラヒックの規定と受付制御を実施することにより、広く普及しているインターネットと比較して一定の品質を保証するとともに、高い情報セキュリティを提供し、従来の電気通信網回線レベルに近い信頼性のIP回線を確保することができる。
本発明のリソース管理システムの構成例を示す図である。 SIP信号通信パターンを示す図である。 RACSが対応するメディア通信路の経路パターンを示す図である。 帯域管理範囲を説明する図である。 データフロー情報を示す図である。 ネットワークリソース情報を示す図である。 QoSクラス規定を示す図である。 メディアの追加削除時の実施条件を示す図である。 RACSの基本機能フローを示すフローチャートである。 自網発メディア通信シーケンスを示す図である。 他網発メディア通信シーケンスを示す図である。 従来のリソース管理システムの問題点を説明する図である。 従来のリソース管理システムの問題点を説明する図である。
図1は、本発明のリソース管理システムの構成例を示す。
図において、通信ネットワーク(NGN)1は、リソース管理部(RACS)121と呼処理制御部(CSCF:Call State Control Function )122を含む中継呼処理サーバ12と、対向呼処理サーバ13と、転送網11の転送処理部(I−BGF)111,112を含む。NGN1はI−BGF111経由で他網2と接続し、I−BGF111およびI−BGF112経由で他網3と接続している。物理的な接続は、一般的に専有、非専有の中継装置14を介して接続する。
CSCF122から呼の要求を受信したRACS121は、ネットワークリソース情報とデータフロー情報に基づく帯域管理により、リソースとI−BGFを含む経路帯域が十分か否かを判定して経路選択を行い、中継呼処理サーバ12はSIP信号のセッション状態情報、すなわちユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報の管理により呼処理の決定と実施を行う。RACS121が対象とする転送網11は、コアルータ(CR)およびI−BGFを含み他網までの網によって構成される。RACS121のQoS提供区間は、転送網の帯域をリソースとして論理仮想化したものであり、I−BGFごとのI−BGF区間、I−BGFと他網との網間に大別できる。呼処理サーバ間の呼制御信号はSIP信号を用いて行われる。
図2は、SIP信号の通信パターンを示す。
図において、SIP信号(invite,update 等) は、物理的にはユーザ通信のメディアトラヒックが流れるルートとは別のルートを通る。RACS121が対応するSIP信号は、CSCF122がRACS121と連携し、図中両端のCSCF(またはSIPサーバまたはパケット転送装置)16,17を経由して加入者網から他網へ、他網から加入者網へ転送する。このSIP信号によるユーザ端末間のネゴシエーション結果に伴いユーザ端末間のエンドツーエンドでメディアセッションが確立されメディア通信が開始される。このメディア通信は、I−BGF111またはI−BGF112を経由して転送網11で行われる。
図3は、RACSが対応するメディア通信路の経路パターンを示す。
図において、ネットワークリファレンスモデルにおいて、RACS121が対象とする経路は、I−BGF111と他網2との間の網間、I−BGF112と他網3との間の網間、I−BGF113と他網4との間の網間である。
RACS121では、帯域管理を行うにあたってネットワークの論理抽象化を行う。すなわち、物理ネットワーク構成および物理帯域を他網ごとの仮想パス(網間仮想パス)、およびI−BGFごとにI−BGFの転送能力を論理抽象化した仮想パス(I−BGF区間仮想パス)から構成される仮想パスネットワークとして論理抽象化することにより管理する。これにより、他網までの物理リンク速度や経路の考え方を集約して単純化でき、かつ各ネットワーク上のI−BGFを直接制御することなく入り口での集中制御が可能になる。また、I−BGFのボトルネックを加味した管理や経路の故障管理が可能となり、他網ごとの仮想パスと合せて網間での共用部分を管理することができる。
また、RACS121は、I−BGFごとのセッション数上限値および抽象化した論理帯域の上限値を記憶し、メモリなど一時領域にて使用中セッション数と論理帯域の積み上げ、積み下げの管理を行う。また、RACS121は、使用中セッション(I−BGFを使用するメディアストリーム数)の少ないI−BGFを選択し、同じ場合は帯域使用率すなわち使用帯域の少ないI−BGFを選択する。
RACSの帯域管理範囲と帯域管理区分については次の通りである。
RACSの帯域管理範囲は、図4に示すように、I−BGF区間仮想パスと網間仮想パスの2つに分けて帯域を管理する。網間仮想パスは、1または複数の物理インタフェースで構成される帯域上限を仮想パス上限帯域として管理する。I−BGF区間仮想パスは、I−BGF単位で帯域の積み上げ、積み下げを管理する。
帯域管理区分は、上限帯域をQoSクラスの粒度に分けて帯域を管理する。QoSクラスとは、図7に示すように、ITU−T Y.1540 のクラス0からクラス5をNGNのQoSクラスとして4つ(aからd)に分類しなおしたものである。パケットの転送は、IETFのdiffservの規定クラス(EFからBE)とマッピングして転送処理装置を制御する。パケットは、転送網ではdiffservクラスの振る舞いをする。網間仮想パスおよびI−BGF区間仮想パスそれぞれにおいて、QoSクラス粒度でそれぞれ帯域を管理する。同一の帯域確保要求中に複数の優先度のメディアフロー用の帯域を確保する要求が含まれていた場合に、優先度の高いQoSを指定したメディアフローを優先的に仮想パスに割り付けて記憶する。
RACSが行う帯域管理の方法では、データフロー情報やネットワークリソース情報が使われる。データフロー情報には、図5に示すように、発IP/着IP/プロトコル/着ポート/発ポートを含むデータフロー識別情報と、ピークレートの値と、QoSクラス識別情報と、RACSの受付優先度情報と、受付優先クラス識別情報とがある。ここで、データフロー情報の中のTGN番号は方路を表す通番であり、0や1などである。SIPルートは、SIP信号を通す経路を表す番号であり、0や1などである。
ネットワークリソース情報には、図6に示すように、I−BGF区間仮想パス構成情報としてI−BGF区間仮想パス上限帯域およびQoSクラス上限帯域(I−BGF区間仮想パス上限帯域に対する割合)と、網間仮想パス構成情報として網間仮想パス構成情報として網間仮想パス上限帯域およびQoSクラス上限帯域(網間仮想パス上限帯域に対する割合)と、RACS受付優先度情報(上限帯域に対する割合)と、QoSクラス設定情報としてバッファ時間/バースト比例情報/遅延ゆらぎ係数/帯域補正係数とがある。バッファ時間は、RACSが制御するパケット転送処理装置が吸収できるパケット転送のゆらぎ、遅延時間の合計である。時間が大きいほど、多くのパケットを受信して蓄積することができ、パケット転送のゆらぎや遅延時間を吸収することができる。制御補正係数は、RACSがパケット転送処理装置を制御するときの補正係数であり、制御時に設定した値でパケット転送処理装置が振る舞うことができないときに補正するための値である。例えば、パケット転送処理装置の能力を考慮して帯域補正係数を所望の値の 1.2倍に設定することにより、パケット転送処理装置が所望の値に対応する振る舞いが可能となる。帯域補正係数は、パケット転送処理装置が設定値に対して、レイヤ2の設定値として扱うか、レイヤ3の設定値として扱うかを補正する係数となっている。
RACSの帯域制御論理に関して、以下の考慮に基づいた処理を行う。まず、最低限1パケット分が通過できるように、バースト許容値の最低値を規定する。次に、トラヒックの擾乱を考慮した係数(帯域補正係数)bk はトークンレート、バースト許容値ともにそれぞれ乗算する。転送処理装置への設定値と実際の転送網でのパケットの振る舞いとの差分を補完するための係数(制御補正係数)gnはトークンレート、バースト許容値ともにそれぞれ乗算する。
(1) 確保帯域(積み上げ帯域)として、ri'=max[(ak+dk)/Dk*ri , ri] とする。CSCFは、RTCP分を含まない帯域をMax requested bandwidth として帯域確保要求メッセージで指定する。CSCFはRTCPの有無を指定し、RTCP分帯域はRACSで計算をする。すなわち、RACSでメディアが存在する方向のトラヒックは指定帯域の1.05倍、メディアが存在しない方向についてもCSCFはRTCPの有無を指定し、RTCP有の場合はメディアが存在する方向の0.05倍をメディアが存在しない方向の帯域量として帯域制御を行う。特定音声コーデックの場合は、RACSで1.05となることを考慮した値をRACSに通知する。
(2) トークンレートとして sdr=max[gn*bk*ri/8,rmin]とする。
(3) バースト許容値として mbs=min{smax,max[gn*bk*ri*(ak+dk)/8/1000,smin]}とする。ここで、rminは最少トークンレート、sminは最小バースト許容値、smaxは最大バースト許容値である。
また、CSCFからRACSに対して片方向通信として指定された場合で、RTP/AVP の場合は、反対方向のトラヒックも考慮する。RTSPの双方向分はCSCFが独立したメディアとしてRACSに要求する。rmin、smin、smaxはクラス毎に設定可能とする。保守者が投入するrminの値は、当初は0を推奨する。各設定値が「0」時は、計算を行わないこととする。
すなわち、転送処理装置のバッファ可能時間と流入トラヒックのクラス毎の遅延ゆらぎ量の他に、最小トークンレートと最小バースト許容サイズと最大許容バーストサイズを記憶する。転送処理装置に流入を許可するトラヒックのトークンレートとバースト許容値とを設定する際に、ユーザ間のSIPネゴシエーションで決定した要求帯域から、それぞれトラヒックの擾乱を考慮した係数と転送処理装置への設定粒度を考慮した係数を乗算して一次的なトークンレートと一次的なバースト許容値を算出した後、それぞれ記憶している最少値と比較して大きい方の値、記憶している最大値と比較して小さい方の値を算出結果として転送処理装置に設定し、トラヒックの流入制限を行う。
図8は、メディアの追加削除時の実施条件を示す。
ここで、Aは既存メディアの合計であり、Mは上限帯域であり、Xは追加メディア分合計であり、Yは削除メディアであるとき、メディアの追加削除時の実施条件として
A+X−Y≦M
を満たす場合に一時的に許容する。すなわち、SIP信号上は複数のメディアフローが要求されている場合に、CSCFからRACSへの帯域確保要求の予約時、確保時に、その帯域確保要求中にはメディアの削除と追加の要求が含まれている場合がある。もちろん変更なしのメディアが含まれている場合もある。これらは帯域確保要求ごとに、過不足を計算した上でリソースから積み上げ、積み下げを実施する。例えば、一回の帯域確保要求の中に、追加メディアと削除メディアが含まれる場合に、追加メディアの帯域に対して削除しようとするメディアの帯域の方が大きい場合には、必ず帯域の確保が可能となる。
RACSがI−BGFを選択する際の論理と方法について説明する。
まず、RACSは、各I−BGFを使用するメディアフロー数により選択を行い、次に帯域による選択を行う。メディアフロー数による選択は、メディアフロー数が少ないI−BGFを選択する。音声呼のみの場合には、メディアフロー数による選択により複数のI−BGFを順番に使用することになる。NGNでは、音声のみの呼だけでなく、ビデオ呼も使用される。この場合、メディアフロー数以外に使用帯域を考慮しなければ、帯域を使い切る前にメディアフロー数による頭打ちとなる場合もある。使用帯域によるI−BGF選択は、I−BGF区間仮想パスの帯域使用率を参照し、その中で最も帯域使用率の低いI−BGFを選択する。帯域の使用率は上り方向/下り方向で異なるため、帯域使用率の最も低いI−BGFを選択する際には、上り方向/下り方向の使用率の加算結果を元に比較する。その理由は、上り方向/下り方向の使用率をそれぞれ判別することにすると、ユーザからの要求が同一メディアに対して異なるI−BGFを設定する危険性があるためである。帯域使用率が同値のI−BGF区間仮想パスが複数存在していた場合、どのI−BGFを選択するかについては規定しない。サービス提供状況により、音声呼が支配呼となるか、ビデオ呼が支配呼になるかによって、フロー数による選択と帯域使用率による選択の優先順位を入れ替える機能を提供する。例えば、テレビ電話などの動画通信が増えると、コーデック種別などにより必要帯域が偏るため、帯域による振り分けを優先するようにしてもよい。
SIP信号の通信路を確立するまでのI−BGF選択は、まず保守者が特定のI−BGFに対して、あらかじめ確立可否を設定する。2つのI−BGFに対して、それぞれ事業者ごとに冗長用経路の0または1の確立可否を設定する。RACSは、CSCFからSIP信号の通信路確立の契機を与えられて、指定された0または1のSIP信号の通信路を設定許可されたI−BGFのストリーム数の上限チェックを実施し、当該I−BGFに対してSIP信号の通信路の設定とI−BGFへの制御を行う。
メディアフローのI−BGF選択論理について説明する。
RACSは、各I−BGFの基本情報を記憶する。制御用のIPアドレス、最大ストリーム数、I−BGFのパケット転送処理性能をリンクの物理帯域量を表すbps に見立ててI−BGF仮想パス最大帯域として記憶する。なお、bps への換算計算は、パケット転送処理能力であるpps をパケットサイズを元にbps に換算する。上り下りの帯域計算として1/2 する。
I−BGFを通過する物理リンクにボトルネックがある場合を想定して、以下のように算出する。「RACSとI−BGF間のリンク帯域(転送処理装置内のボトルネックとなりうるリンクを含む)」と、「pps をbps に換算した帯域/2」の小さい方の値を取得する。RACSとI−BGF間にリンクがない場合、I−BGFの処理能力以外にボトルネックがないため、上り下りを区別せず、上り下り合計帯域とする。
また、RACSに登録したI−BGFごと、対向する他網ごとにユーザ通信用に使用するI−BGFを設定する。例えば、他網1向けにはI−BGF#1とI−BGF#2、他網2向けにはI−BGF#2とI−BGF#3を通過することを設定する。これらをメディアルートと呼ぶ。
I−BGF選択は、I−BGF数≠メディアルート数の場合、その他網向けに使用できるメディアルートが設定されたI−BGFの選択となる。
当該他網向けに使用可能な複数のI−BGFに対してストリーム数による選択方法について説明する。ストリーム数上限やI−BGF故障によってI−BGFが選択できなかった場合は、帯域確保要求に対してエラーを返却する。ストリーム数による選択の結果、I−BGFが複数選択された場合は、帯域による選択を行う。帯域による選択の結果、I−BGFが複数選択された場合は、選択されたI−BGFの中から任意のI−BGFを選択する。選択されたI−BGFに対して溢れ判定を行い、溢れ判定がOKである場合にそのI−BGFを選択する。溢れ判定がNGの場合は、「ストリーム数が少ない>帯域使用率が低い」の優先順位に基づき、次優先のI−BGFの選択を行い、溢れ判定を繰り返す。ここで、「>」は優先順位の高低を表す。最終的に溢れ判定がOKとなるI−BGFが選択できなかった場合は、帯域確保要求に対してエラーを返却する。
図9は、RACS121の基本機能フローを示す。
ステップS1では、RACS121は加入端末からSIP呼に対応したサービスセッション制御信号を受信し、ステップS2へ進む。
ステップS2では、このSIP呼に対応したセッション状態情報を読み出し、ステップS3へ進む。
ステップS3では、このSIP呼に対応した使用可能な候補経路についてネットワークリソース情報を読み出し、ステップS4へ進む。
ステップS4では、ストリーム数/帯域使用率によるI−BGFの選択ができたか否かを判定し、I−BGFの選択ができた場合にステップS5へ進み、I−BGFの選択ができない場合にステップS9へ進む。
ステップS9では、このSIP呼の帯域確保要求に対してエラーを返却する。
ステップS5では、溢れ判定を行う。すなわち、このSIP呼に対応したデータフロー情報を読み出し、メディア追加・削除の実施条件(上記のA+X−Y≦M)を満たすか否かを判定し、実施条件を満たす場合に一時的に許容してステップS7へ進み、実施条件を満たさない場合にステップS6へ進む。
ステップS6では、「ストリーム数が少ない>帯域使用率が低い」の優先順位に基づいて次優先のI−BGFの選択ができたか否かを判定し、I−BGFの選択ができた場合にステップS5へ戻り、I−BGFの選択ができない場合にステップS9のエラー返却へ進む。
ステップS7では、候補経路について、このSIP呼に対応したセッション状態情報から仮想パス選択論理を適用したI−BGFを決定し、ステップS8に進む。
ステップS8では、このSIP呼にI−BGF経由で対応したSIPセッション制御処理を行う。このSIPセッション制御処理は、以下に示すように、選択したI−BGFのI−BGF区間仮想パスでのリソース確保と、選択したI−BGFに対するポリシー制御などである。
メディアフロー通信を開始する際には、呼処理制御部(CSCF)において、SIP−INVITEメッセージのSDPから必要パラメータを取り出し、呼処理サーバのRACSに対して制御要求情報を送信する。RACSは、制御要求パラメータの事業者IDより、I−BGFおよび収容物理ポートを抽出し、さらに物理リンクまたはVLAN−IDが抽出できる場合は抽出し、事業者毎のSIP信号路に結びついたメディアルートに沿った仮想パス毎に帯域判定を行う。ただし、INVITE受信時の制御では、着側のIPアドレスおよびポート番号は特定できないことから、I−BGFでのポリシー制御の有効化は行われない。SIPメッセージの応答である183W/SDPまたは200W/SDPメッセージから、CSCFが着側のIPアドレスおよびポート番号を抽出し、RACSが2回目の制御要求パラメータを受信し、その情報に従ってI−BGFを制御した際にポリシーが有効化される。すなわち、I−BGFでは、発着IPアドレス、発着ポート番号などの全ての制御のための情報が揃ったときにポリシーを有効化する。
RACSがI−BGFをポリシー制御する際には、発IPアドレス、発ポート番号、着IPアドレス、着ポート番号、プロトコル種別(IP/TCP/UDP)、ピークレート、ピークパケットサイズ、DSCP値などのパラメータが使われる。RACSでは、発IPアドレス、発ポート番号、着IPアドレス、着ポート番号、プロトコル種別までのパラメータをクラシファイ・パラメータとして、I−BGFに対してポリシー制御を行う。また、SIPシグナリングポート開通時、およびMEGACOによるメディアフロー制御時それぞれにおいて、ピークレートとピークパケットサイズを制御パラメータとして用いる。ピークレートとピークパケットサイズの制御パラメータは、他網側のターミネーション(Termination )に対して設定され、これらのパラメータを元にI−BGFでの流入制御を行う。DSCP値を用いたパケットの優先制御は、他網側および自網側のターミネーションに対して設定され、本パラメータを元にI−BGFでの優先制御を行う。
RACSは、MEGACOプロトコルを用いてI−BGFの自網側ターミネーションと他網側ターミネーションに、NAPT制御が動作するようにそれぞれのローカルアドレスとグローバルアドレス、ポート番号、DSCP値を設定することでポリシー制御を行う。
図10は、本発明における自網発メディア通信シーケンスを示す。
図において、中継呼処理サーバ12は、呼処理制御部(CSCF)122とリソース管理部(RACS)121からなる。中継呼処理サーバ12は、対向呼処理サーバ13Aまたはパケット転送処理装置から送信元情報(8) を格納したSIPinvite 信号を受信し、送信元装置に対して100trying 信号を返却し、受信したSIPinvite 信号を記憶する。
CSCF122は、RACS121に対して帯域確保要求メッセージにより送信元情報(8) を通知し、帯域確保要求を行う。この帯域確保要求には、複数のメディアフローごとにそれぞれ必要な上り下りの要求帯域が含まれる。また、メディアフローごとにパケットの振る舞いであるDSCPに相当するクラスが指定される。また、対向サーバを特定する方路情報が含まれる。この方路情報には、対向者識別子と対向者識別子内のコントロール信号路の通番が含まれる。
RACS121は、I−BGFごとに仮想化した上り下りそれぞれのクラスごとの上限帯域から要求されたメディアフローごとの帯域を取得可能か否か残帯域と比較する。帯域取得が不可能な場合は、即座に帯域確保要求にNG応答する。全てのメディアフローに対して帯域取得可能な場合は、RACS121はI−BGFに対して、送信元情報(8) を指定したターミネーションの作成指示を行う。ターミネーションのステータスは、OUSで作成する。
RACS121は、I−BGFに対してコントロール信号路を特定する情報と信号の方向性まで設定する。I−BGFは、その中でターミネーションをユニークに決定する識別子の付与を行ってRACS121に返信し、RACS121はこれをI−BGFごとに記憶する。すなわち、RACS121は、I−BGFに対してポリシング設定する際、同時に自網側と他網側のターミネーション作成を同一メッセージ上で試みる。この際、リソース管理サーバは、ターミネーションの組み合わせをcontext として識別し保存する。ただし、contecxtの識別子も、一回目の設定時はワイルドカードで指定したメッセージをI−BGFに送信して、I−BGFで払いだす。一方、I−BGFでターミネーションIDはユニークであり、識別子、IP/group/interface/id の/id 以下は、自網側と他網側で異なった識別子が払いだされるため、ターミネーションのセットを決定できる概念がcontext となる。メディアのターミネーションが格納されたcontext の中にはメディアのターミネーションの自網、他網のペアが格納される。他のペアは格納しない。モニタ設定をして、トラヒックのコピーをI−BGFから外部へ転送する場合にのみ、もうひとつのターミネーションが格納される。
これにより、ターミネーション情報をI−BGFごとにユニークに保持する。以後、ターミネーション識別子として、RACS121とI−BGFとのユニークな識別子として制御に用いる。
I−BGFは、RACS121に対してSIP信号の送信元情報(8) に対応するSIP信号の送信先に通知するべき送信元情報(3) を応答する。RACS121は、帯域確保要求メッセージの応答にSIP信号の送信先に通知するべき送信元情報(3) を応答する。
CSCF122は、保存していたSIPinvite 信号について送信元情報(8) を送信元情報(3) として、対向呼処理サーバ13Cまたはパケット転送処理装置に送信する。また、CSCF122は、対向呼処理サーバ13Cからの180ringing信号を対向呼処理サーバ13Aに転送し、対向呼処理サーバ13AからPRACK信号があった場合は対向呼処理サーバ13Cに転送する。さらに、CSCF122は、対向呼処理サーバ13Cから送信元情報(6) を格納した 200OK信号を受信して記憶する。
CSCF122は、RACS121に対して帯域確保要求メッセージにより送信元情報(6) を通知し、帯域確保要求を行う。この帯域確保要求には、複数メディアフロー分それぞれに必要な上り下りの要求帯域が含まれる。また、対向サーバを特定する方路情報が含まれる。この方路情報には、対向者識別子と対向者識別子内のコントロール信号路の通番が含まれる。
RACS121は、I−BGFに対してメディアフローごとにユニークなターミネーション識別子を用いて送信元情報(6) を指定したターミネーションの変更指示を行う。ステータスをINSにする。同時に、メディアフローごとに要求帯域にパケット転送処理装置ごとに記憶するパケット転送処理装置で所望の要求帯域を得られるようにするための制御補正係数を乗じた帯域量と、各クラスごとに到着パケットのバースト性を考慮したパケットが遅延してまとまった時間分のバースト比例係数を乗じたバースト量を設定する。
I−BGFは、RACS121に対してSIP信号の送信元情報(6) に対応するSIP信号の送信先に通知するべき送信元情報(4) を応答する。RACS121は、帯域確保要求メッセージの応答にSIP信号の送信先に通知するべき送信元情報(4) を応答する。CSCF122は、保存していたSIPinvite 信号について送信元情報(6) を送信元情報(4) として、対向呼処理サーバ13Aまたはパケット転送処理装置に送信する。
図11は、他網発メディア通信シーケンスを示す。
図において、他網発の要求呼の処理については、I−BGFを経由して中継呼処理サーバ12がSIPinvite 信号を受信して始まる。中継呼処理サーバ12は、対向呼処理サーバ13Dまたはパケット転送処理装置から送信元情報(6) を格納したSIPinvite 信号を受信し、送信元装置に対して100trying 信号を返却し、受信したSIPinvite 信号を記憶する。
CSCF122は、RACS121に対して帯域確保要求メッセージにより送信元情報(6) を通知し、帯域確保要求を行う。この帯域確保要求には、複数のメディアフローごとにそれぞれ必要な上り下りの要求帯域が含まれる。
RACS121は、I−BGFごとに仮想化した上り下りそれぞれのクラスごとの上限帯域から要求されたメディアフローごとの帯域を取得可能か否か残帯域と比較する。帯域取得が不可能な場合は、即座に帯域確保要求にNG応答する。全てのメディアフローに対して帯域取得可能な場合は、RACS121はI−BGFに対して、送信元情報(6) を指定したターミネーションの作成指示を行う。RACS121は、I−BGFに対してコントロール信号路を特定する情報と信号の方向性まで設定する。
I−BGFは、その中でターミネーションをユニークに決定する識別子の付与を行ってRACS121に返信し、RACS121はこれをI−BGFごとに記憶する。これにより、ターミネーション情報をI−BGFごとにユニークに保持する。以後、ターミネーション識別子として、RACS121とI−BGFとのユニークな識別子として制御に用いる。
I−BGFは、RACS121に対してSIP信号の送信元情報(6) に対応するSIP信号の送信先に通知するべき送信元情報(4) を応答する。RACS121は、帯域確保要求メッセージの応答にSIP信号の送信先に通知するべき送信元情報(4) を応答する。
CSCF122は、保存していたSIPinvite 信号について送信元情報(6) を送信元情報(4) として、対向呼処理サーバ13Eまたはパケット転送処理装置に送信する。また、CSCF122は、対向呼処理サーバ13Eからの180ringing信号を対向呼処理サーバ13Dに転送し、対向呼処理サーバ13DからPRACK信号があった場合は対向呼処理サーバ13Eに転送する。さらに、CSCF122は、対向呼処理サーバ13Eから送信元情報(8) を格納した 200OK信号を受信して記憶する。
CSCF122は、RACS121に対して帯域確保要求メッセージにより送信元情報(8) を通知し、帯域確保要求を行う。RACS121は、I−BGFに対してメディアフローごとにユニークなターミネーション識別子を用いて送信元情報(8) を指定したターミネーションの変更指示を行う。
I−BGFは、RACS121に対してSIP信号の送信元情報(8) に対応するSIP信号の送信先に通知するべき送信元情報(3) を応答する。RACS121は、帯域確保要求メッセージの応答にSIP信号の送信先に通知するべき送信元情報(3) を応答する。CSCF122は、保存していたSIPinvite 信号について送信元情報(8) を送信元情報(3) として、対向呼処理サーバ13Dまたはパケット転送処理装置に送信する。
また、Uプレーンのセッションのリフレッシュタイミングについて、RACSは次のように動作する。RACSを含めて中継呼処理サーバでは固定的なタイミングをもたず、Re-INVITE/UPDATE受信時にセッションのリフレッシュを行う。RACSにおけるリフレッシュ受信の監視は、SIPセッションのExpire値/2+30秒となる。リフレッシュのタイマが満了した場合にRACSからCSCFに通知を行う。さらに、SIPセッションのExpire値/2秒間リフレッシュを受けなかった場合、RACSはセッションを開放し、CSCFにセッションの開放通知を行う。
1 通信ネットワーク(NGN)
2,3 他網
11 転送網
12 中継呼処理サーバ
13 対向呼処理サーバ
14 中継装置
111〜113 転送処理部(I−BGF)
121 リソース管理部(RACS)
122 呼処理制御部(CSCF)

Claims (7)

  1. 呼処理サーバと1以上の転送処理部を含む自網と、少なくとも1つの呼処理部を含む他網が接続される網構成のリソース管理システムにおいて、
    前記呼処理サーバは、
    ユーザ端末間のSIPネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行う呼処理部と、
    前記自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してSIPネゴシエーションの結果得られる要求帯域を、SIPネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、
    前記リソース管理部は、
    前記自網と前記他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって前記転送処理部を含む経路帯域を判定して経路選択を行う手段と、
    前記1以上の転送処理部から前記他網と接続するための転送処理部を選択する際に、前記自網に張られたストリーム数が少ない転送処理部を選択し、前記ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する手段と
    を備えたことを特徴とするリソース管理システム。
  2. 請求項1に記載のリソース管理システムにおいて、
    前記ネットワークリソース情報は、転送処理部区間仮想パス構成情報と、網間仮想パス構成情報と、RACS受付優先度情報と、QoSクラス設定情報とを含むことを特徴とするリソース管理システム。
  3. 請求項1に記載のリソース管理システムにおいて、
    前記データフロー情報は、ピークレート情報と、QoSクラス識別情報と、受付優先度と、受付優先クラス識別情報とを含むことを特徴とするリソース管理システム。
  4. 請求項1に記載のリソース管理システムにおいて、
    前記セッション状態情報は、ユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報を含むことを特徴とするリソース管理システム。
  5. 請求項1に記載のリソース管理システムにおいて、
    前記呼処理サーバは、ユーザが通信時に送受信するメディアトラヒックの帯域確保要求時に転送処理部に対して自網側のポリシング設定を識別する識別子と他網側のポリシング設定を識別する識別子を転送処理部内で一意に識別可能な識別子の払い出しを要求するメッセージを送信し、同時に自網側の識別子と他網側の識別子のペアを識別管理するための転送処理部でユニークな識別子も転送処理部に払い出しを要求し、自網側の識別子と他網側の識別子とこのペアを識別する識別子を転送処理部ごとに記憶する手段を備えた
    ことを特徴とするリソース管理システム。
  6. 呼処理サーバと1以上の転送処理部を含む自網と、少なくとも1つの呼処理部を含む他網が接続される網構成のリソース管理方法において、
    前記呼処理サーバの呼処理部は、ユーザ端末間のSIPネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行い、前記呼処理サーバのリソース管理部は、前記自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してSIPネゴシエーションの結果得られる要求帯域を、SIPネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理し、
    さらに、前記リソース管理部は、
    前記自網と前記他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって前記転送処理部を含む経路帯域を判定して経路選択を行い、
    前記1以上の転送処理部から前記他網と接続するための転送処理部を選択する際に、前記自網に張られたストリーム数が少ない転送処理部を選択し、前記ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する
    ことを特徴とするリソース管理方法。
  7. 請求項6に記載のリソース管理方法において、
    前記リソース管理部が加入端末からの呼(SIP)に対応したサービスセッション制御信号を受信する第1のステップと、
    前記呼に対応した前記セッション状態情報を読み出す第2のステップと、
    前記呼に対応した使用可能な候補経路について前記ネットワークリソース情報を読み出す第3のステップと、
    前記ストリーム数および帯域使用率による前記転送処理部の選択が可能か否かを判定する第4のステップと、
    前記第4のステップで前記転送処理部の選択が可能なときに、前記呼に対応した前記データフロー情報を読み出し、メディアの追加または削除の条件判定を行う第5のステップと、
    前記第5のステップの条件を満たさないときに、「ストリーム数が少ない>帯域使用率が低い」の優先順位に基づいて次優先の転送処理部を選択して前記第4のステップに戻る第6のステップと、
    前記第5のステップの条件を満たすときに、候補経路につき前記呼に対応したセッション状態情報から仮想パス選択論理を適用した転送処理部を決定する第7のステップと、
    前記第7のステップで決定した転送処理部の経路で対応したSIPセッション制御処理を行う第8のステップと、
    前記第4のステップまたは前記第6のステップで前記転送処理部の選択が不可のときに、前記呼の帯域確保要求に対してエラー返却を行う第9のステップと
    を有することを特徴とするリソース管理方法。
JP2009126097A 2008-09-26 2009-05-26 リソース管理装置およびリソース管理方法 Active JP4802261B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009126097A JP4802261B2 (ja) 2008-09-26 2009-05-26 リソース管理装置およびリソース管理方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2008248251 2008-09-26
JP2008248251 2008-09-26
JP2009126097A JP4802261B2 (ja) 2008-09-26 2009-05-26 リソース管理装置およびリソース管理方法

Publications (2)

Publication Number Publication Date
JP2010103968A true JP2010103968A (ja) 2010-05-06
JP4802261B2 JP4802261B2 (ja) 2011-10-26

Family

ID=42294151

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009126097A Active JP4802261B2 (ja) 2008-09-26 2009-05-26 リソース管理装置およびリソース管理方法

Country Status (1)

Country Link
JP (1) JP4802261B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011035698A (ja) * 2009-08-03 2011-02-17 Nippon Telegr & Teleph Corp <Ntt> アドレス状態整合システム、アドレス状態整合方法、エッジルータ及びセッション制御サーバ
JP2012005045A (ja) * 2010-06-21 2012-01-05 Nippon Telegr & Teleph Corp <Ntt> 呼処理方法及び呼処理サーバ
WO2014041840A1 (ja) * 2012-09-13 2014-03-20 沖電気工業株式会社 通信装置及びプログラム、並びに通信システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000209278A (ja) * 1999-01-12 2000-07-28 Fujitsu Ltd ル―タ及びル―タを用いたパケット中継システム
JP2002118648A (ja) * 2000-10-05 2002-04-19 Oki Electric Ind Co Ltd ネットワーク間接続制御装置
JP2008113260A (ja) * 2006-10-31 2008-05-15 Hitachi Communication Technologies Ltd ゲートウェイ負荷分散機能を備えたパケット転送装置
JP2008225644A (ja) * 2007-03-09 2008-09-25 Nec Corp ゲートウェイ装置、ゲートウェイ装置の負荷分散方法及びゲートウェイ装置の負荷分散プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000209278A (ja) * 1999-01-12 2000-07-28 Fujitsu Ltd ル―タ及びル―タを用いたパケット中継システム
JP2002118648A (ja) * 2000-10-05 2002-04-19 Oki Electric Ind Co Ltd ネットワーク間接続制御装置
JP2008113260A (ja) * 2006-10-31 2008-05-15 Hitachi Communication Technologies Ltd ゲートウェイ負荷分散機能を備えたパケット転送装置
JP2008225644A (ja) * 2007-03-09 2008-09-25 Nec Corp ゲートウェイ装置、ゲートウェイ装置の負荷分散方法及びゲートウェイ装置の負荷分散プログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011035698A (ja) * 2009-08-03 2011-02-17 Nippon Telegr & Teleph Corp <Ntt> アドレス状態整合システム、アドレス状態整合方法、エッジルータ及びセッション制御サーバ
JP2012005045A (ja) * 2010-06-21 2012-01-05 Nippon Telegr & Teleph Corp <Ntt> 呼処理方法及び呼処理サーバ
WO2014041840A1 (ja) * 2012-09-13 2014-03-20 沖電気工業株式会社 通信装置及びプログラム、並びに通信システム
JP2014057253A (ja) * 2012-09-13 2014-03-27 Oki Electric Ind Co Ltd 通信装置及びプログラム、並びに通信システム
CN103814553A (zh) * 2012-09-13 2014-05-21 冲电气工业株式会社 通信装置、程序以及通信系统

Also Published As

Publication number Publication date
JP4802261B2 (ja) 2011-10-26

Similar Documents

Publication Publication Date Title
US8249236B2 (en) Network call back to add conference participants and/or media capabilities
US6944166B1 (en) Method for controlling service levels over packet based networks
US8165021B2 (en) Policy-based resource management
US8542592B2 (en) Managing a network flow using application classification information and active signaling relay
JP4796157B2 (ja) ネットワーク通信における資源配分を実施するためのシステム及び方法
US7420962B2 (en) Method for management of voice-over IP communications of various relative priority levels
US7639612B2 (en) System and method of providing bandwidth on demand
CN100505639C (zh) 多业务流资源申请的处理方法
US9763140B2 (en) Resource reservation on networks comprising wireless and wired segments
US20070147243A1 (en) Method and system for guaranteeing end-to-end quality of service
AU2002339309B2 (en) Traffic restriction by means of reliability check for a packet-oriented connectionless network with QoS transmission
KR20090037820A (ko) 아웃오브밴드 시그널링을 이용한 자원 제어 방법
JP4802261B2 (ja) リソース管理装置およびリソース管理方法
US20090204698A1 (en) Method, system and apparatus for reserving bearer resources
JP2007325224A (ja) トラヒック制御方法とシステムおよびプログラム
CN100544357C (zh) 一种端到端服务质量的域间协商的方法及其系统
Cisco Quality of Service for Voice over IP
US9094256B1 (en) Media capability selection
JP2011166237A (ja) リソース管理装置及びリソース管理方法
JP5061222B2 (ja) リソース管理方法およびリソース管理制御装置
Chen QoS and Over-subscription for IP/MPLS Networks
KR101220644B1 (ko) 인터넷에서의 네트워크 제어 기능 제공 시스템 및 그 방법
JP5075950B2 (ja) リソース管理制御装置およびその動作方法
Tanida et al. A modeling method of access network for resource reservation and admission control of NGN
JP2008016921A (ja) ルータ、優先パケット通過制御システム、優先処理量計算方法及び優先パケット通過制御方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110222

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110421

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

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110808

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

Free format text: PAYMENT UNTIL: 20140812

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4802261

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350