JP2003338837A

JP2003338837A - パケット通信システムにおける通信品質保証方法及び転送遅延保証機能付きパケット通信装置

Info

Publication number: JP2003338837A
Application number: JP2002147484A
Authority: JP
Inventors: Shigeru Kotabe; 繁小田部; Takeshi Murata; 雄志村田; Katsumi Imamura; 勝巳今村; Takeshi Miyaura; 武士宮浦; Hideyo Fukunaga; 英世福永; Koshu Yoshida; 光州吉田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2002-05-22
Filing date: 2002-05-22
Publication date: 2003-11-28
Also published as: US20030219014A1

Abstract

(57)【要約】【課題】パケット通信システムにおいて、着信先のパ
ケット通信装置での受信パケットのバッファリング量を
最適化して必要な通信品質を安価に保証できるようにす
る。【解決手段】パケット通信装置を、タイマを用いて自
己が保証可能な遅延保証時間（Tdmax）内に必ず受信パ
ケットの送出を完了できるように構成し、上記遅延保証
時間（Tdmax）に関する情報を着信先のパケット通信装
置へ通知し、着信先のパケット通信装置が、通知された
情報に基づいて、発信元のパケット通信装置との間の通
信についての受信パケットのバッファリング量を決定す
るようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えば、インター
ネットプロトコル等を用いてデータの伝送を行なうパケ
ット通信装置に関し、特に、リアルタイム（実時間）性
の要求される通信サービス品質（ＱｏＳ：Quality of S
ervice）を保証するのに好適な、パケット通信システム
における通信品質保証方法及び転送遅延保証機能付きパ
ケット通信装置に関する。

【０００２】

【従来の技術】一般に、ＩＰ（Internet Protocol）ネ
ットワークにおいては、データ（パケットあるいはセ
ル）の伝送がいわゆるベストエフォートとなり、通信品
質（ＱｏＳ）の保証は行なわれていない。しかし、近
年、ＩＰネットワークに対してＱｏＳを必要とするサー
ビスに対する要求が大きくなり、これらのアプリケーシ
ョンの開発が盛んである。

【０００３】アプリケーションの一例としては、例え
ば、電話による音声通話，ビデオ（動画）配信等の実時
間通信や、ロボット遠隔操作，遠隔医療(手術)等のため
の実時間通信などがある。このようなアプリケーション
では、データが欠落、あるいは、想定した最大遅延時間
よりも遅れて受信側に到着した場合、１パケットであっ
ても、通話品質や再生品質に大きな影響を与え、品質劣
化が著しい。

【０００４】このため、端末等の受信側（着信先）で
は、データの転送遅延及びその揺らぎの最悪ケースを想
定し、データが最も遅れて到着した場合でも、アプリケ
ーション動作が破綻しないよう、到着したアプリケーシ
ョンデータを最大遅延量相当分バッファリングすること
により破綻を回避している。しかし、転送遅延が大きく
なると通信品質自体が悪化するため、いかにＱｏＳを保
証するかが課題となっている。そこで、これまでの品質
保証としては、伝送するデータの優先順位を「クラス」
と呼ばれる優先度の識別情報で判別し、優先度の高いク
ラスのデータから優先的に多重化して転送することが一
般に行なわれている。即ち、既存のＩＰルータ等の通信
装置（ノード）では，リアルタイム性の要求される通信
については、伝送データの「優先度」を高く設定し、優
先度の高いパケットから優先して送出するという手法を
採っている（図１２参照）。

【０００５】

【発明が解決しようとする課題】しかしながら、高優先
に設定できるパケットは限られており、サービス料金も
高価である。また、優先度を高く設定できない場合もあ
る。さらに、優先度の高いパケットが優先して送信され
てしまうため、優先度が低く設定されたパケットについ
ては、その遅延量がまったく計算（予測）できないこと
になる。

【０００６】したがって、これまでは、或る網内でリア
ルタイム通信を行なう場合、各ノードでのパケット送信
の優先度の設定により遅延を少なくする「ベストエフォ
ート」型の品質保証でしかなく、実際の転送遅延，揺ら
ぎについては実際には保証されていないという課題があ
る（図１３参照）。また、端末間での遅延量について
は、ネットワークが大きくなればなるほど算出が困難と
なり、スケーラビリティが得られない。

【０００７】一方で、各端末においては、前述したよう
に、実時間通信、例えば電話等の音声通信を行なう場
合、到着した音声パケットを或る一定量バッファリング
する必要がある。そのバッファリング量は、パケットの
到着時間に揺らぎが生じるため、一旦再生が始まった音
声が途切れてしまうことがないように、揺らぎ時間を十
分カバーするだけの量が必要である。

【０００８】また、一旦再生を始めた音声を早送りする
ことは不可能なため、最初のバッファリング量は変える
ことができない。しかし、バッファリング時間が大きく
なると、自らの音声が相手の受話器を通して帰ってくる
エコー（漏話）が音声品質を下げてしまい、また遅延に
よって通話しにくくもなる。このため、このバッファリ
ング量を、通話が途切れることのない範囲で可能な限り
少なくするよう最適化することが重要である。また、動
画伝送においても、いかにしてバッファリング量を最適
化するかが課題になる。

【０００９】ここで、一般的なルータで発生する転送遅
延について考える。図１４に一般的なルータの構成、図
１５にそのネットワークインタフェースの構成を示す。
図１４に示すように、ルータは、スイッチファブリック
１００と、このスイッチファブリック１００に接続さ
れ、入出力ポート数に応じた数のネットワークインタフ
ェース２００とをそなえており、各ネットワークインタ
フェース２００は、さらに、入力側インタフェース２０
１及び出力側インタフェース２０２をそなえて構成され
ている。

【００１０】そして、図１５に示すように、入力側イン
タフェース２０１には、受信パケットを一定量蓄積する
入力バッファ２０１ａと、当該受信パケットのルーティ
ングテーブルに基づく宛先解決を行なう宛先解決部２０
１ｂとがそなえられ、出力側インタフェース２０２に
は、受信パケットのクラスを識別してそのクラス毎に複
数のキュー（バッファ）２０２ｂに振り分けるエンキュ
ー制御部２０２ａと、各キュー２０２ｂからパケットを
読み出して出力するデキュー制御部２０２ｃとがそなえ
られている。

【００１１】かかるルータ構成において、受信パケット
が宛先解決部２０１ｂでの宛先解決のために入力バッフ
ァ２０１ａで待たされることと、出力側インタフェース
２０２でのバッファリング（エンキュー及びデキュー処
理）が、上述した転送遅延の発生する主な要因となる。
しかし、宛先解決時に発生する遅延については既存装置
では考慮されていない。

【００１２】また、出力側インタフェース２０２におい
て、デキュー制御部２０２ｃは、キュー２０２ｂや出力
回線毎に設定された優先度や帯域配分に応じて各キュー
２０２ｂからパケットを読み出して出力する。ここで、
デキュー制御部２０２ｃによるこれまでの帯域制御方式
には、主に、「固定帯域制御」や「ＷＦＱ（WeightedFa
ir Queuing）制御」などがある。

【００１３】そして、優先制御で代表的なものが上記の
「ＷＦＱ制御」である。この「ＷＦＱ制御」は、ＩＰパ
ケットの各種識別子を利用して、伝送待ちのパケットの
優先制御を行なうための技術である。原理的には、優先
度に応じてキュー２０２ｂに重みを付け、重みの大きい
キュー２０２ｂに格納されたパケットの送出頻度を高く
するというものである。

【００１４】このＷＦＱ技術をさらに発展させたもの
が、ＣＢＷＦＱ（Class Based Weighted Fair Queuin
g）である。このＣＢＷＦＱは、CQ（Custom Queuin
g）の拡張版，8/64/100のクラス分けが可能，クラ
ス間でのWFQ制御，クラス内でのRED（Random Early D
etection），クラス毎のPolicing/Shaping，クラス
毎のSLA（Service Level Agreement）といった特徴をも
つ。

【００１５】なお、このＣＢＷＦＱでは、受信パケット
の発信／宛先ＩＰアドレス，セッション（ポート，ソケ
ット），プロトコル等からクラス分けを行ない、そのク
ラスに応じてエンキューを行ない、各クラスの帯域配分
に応じて帯域を割り当てることが行なわれる。これらの
帯域制御方式を採用したノードでは、自ノードにパケッ
トが入力されてから出力されるまでの実際の遅延時間が
把握できなくなるため、端末間での総遅延時間が把握で
きず端末での受信バッファ量が決定できないことにな
る。また、ＳＬＡによる帯域割り当て保証の無いノード
が、経路上にいくつ存在するかが不明なため、大規模な
ネットワーク、特に、対外的な網に対しては事実上品質
保証されない（スケーラビリティが低い）ことになる。

【００１６】本発明は、以上のような課題に鑑み創案さ
れたもので、パケット転送経路上に位置するパケット通
信装置が保証可能なパケット伝送の遅延時間に関する情
報を着信先のパケット通信装置に通知することで、着信
先のパケット通信装置での受信パケットのバッファリン
グ量を最適化して必要な通信品質を保証できるようにす
るとともに、かかる保証を実現する転送遅延保証機能を
もったパケット通信装置を提供することを目的とする。

【００１７】

【課題を解決するための手段】上記の目的を達成するた
めに、本発明のパケット通信システムにおける通信品質
保証方法（請求項１）は、(1)或るパケット転送経路上
で通信を行なうにあたって、そのパケット転送経路上に
位置する１又は２以上のパケット通信装置が、或る受信
パケット量に対して自己が保証しうるパケット転送の遅
延時間情報を着信先のパケット通信装置へ通知し、(2)
着信先のパケット通信装置が、通知された遅延時間情報
に基づいて、発信元のパケット通信装置との間の該パケ
ット転送経路を用いた通信についての受信パケットのバ
ッファリング量を決定することを特徴としている。

【００１８】これにより、本発明では、或るパケット通
信装置間（端末間あるいはパケット通信網のエッジノー
ド間など）の通信を行なうにあたって、着信先のパケッ
ト通信装置が、送信元のパケット通信装置から送られて
くるパケットのパケット転送経路上のパケット通信装置
でのパケット転送遅延時間を事前に知ることができるの
で、上記パケット転送経路を用いた通信に必要な通信品
質を満足するだけの受信パケットのバッファリング量を
適応的に確保して最適化することができる。

【００１９】また、本発明の転送遅延保証機能付きパケ
ット通信装置（請求項２）は、以下の各部をそなえたこ
とを特徴としている。 (1)受信パケットをバッファリングする送信バッファ部 (2)受信パケットの到着時刻からその受信パケットの送
信処理を完了すべき遅延保証時刻までの残り時間を監視
する監視部 (3)この監視部による監視結果に基づいて、上記残り時
間の少ない受信パケットほど優先的に送信されるよう
に、上記送信バッファ部に対する該受信パケットのバッ
ファリングを制御するバッファリング制御部上述のごとく構成された本発明のパケット通信装置で
は、受信パケットの到着時刻からその受信パケットの送
信（転送）処理を完了すべき遅延保証時間までの残り時
間を優先度として受信パケットのバッファリング制御
（送信制御）を行なうので、上記の遅延保証時間を尊守
して、受信パケットの送信を行なうことができる。

【００２０】その結果、本パケット通信装置を用いるパ
ケット通信システムにおいては、或るパケット通信装置
間の通信に用いるパケット転送経路上のパケット転送の
遅延時間や揺らぎ等のパケット遅延量についての不確定
要素を削減して、当該パケット転送経路を用いた通信に
おいて保証可能な通信品質を特定することが可能とな
る。

【００２１】ここで、上記の監視部には、着信先のパケ
ット通信装置から事前に通知された、送信元のパケット
通信装置の送信パケット量に関する情報に基づいて上記
の遅延保証時間を算出する遅延保証時間算出部をそなえ
るのが好ましい。このようにすれば、送信元のパケット
通信装置が送信する実際のパケット量に対して自己が保
証可能な遅延保証時間を算出することが可能となる（請
求項３）。

【００２２】また、上記の送信バッファ部は、上記の監
視部で監視される残り時間が所定時間よりも少ない緊急
出力の必要な受信パケットを格納する緊急出力バッファ
をそなえ、上記のバッファリング制御部は、この緊急出
力バッファに受信パケットが存在する場合に、当該緊急
出力バッファの受信パケットを最優先に読み出す緊急出
力制御部をそなえて構成されていてもよい。このように
すれば、残り時間の非常に少ない受信パケットを最優先
に転送することができるので、上記の遅延保証時間を尊
守することが可能となる（請求項４）。

【００２３】さらに、本パケット通信装置には、上記の
遅延保証時間を、該着信先のパケット通信装置へ通知す
る遅延保証時間通知部をそなえるのが好ましい。これに
より、着信先のパケット通信装置は、上述したごとく、
事前に、パケット転送経路上のパケット転送遅延時間を
知ることができるので、上記パケット転送経路を用いた
通信に必要な通信品質を満足するだけの受信パケットの
バッファリング量を適応的に確保して最適化することが
できる（請求項５）。

【００２４】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を説明する。図１は本発明の一実施形態に係る
パケット通信システムの構成を示すブロック図で、この
図１に示すパケット通信システムは、複数のルータ（パ
ケット通信装置）１１から成るＩＰ網（パケット通信
網）１と、このＩＰ網１を介して相互に通信を行ないう
るパーソナルコンピュータ等の端末（パケット通信装
置）２，３をそなえて構成されている。なお、ルータ
（以下、ノードともいう）１１や端末２，３の台数は、
勿論、この図１に示す数に限定されるものではない。

【００２５】そして、本実施形態では、或るノード１１
において発生するパケット転送遅延量（時間）を最大遅
延量（時間）Tdmaxと定義し、或るノード１１がこの最
大遅延時間Tdmax以内にパケットを転送することを保証
できれば、ＩＰ網１全体を伝送するのにかかる遅延時間
を、端末２，３間の通信に用いるパケット転送経路上に
位置する１又は２以上のノード１１に問い合わせること
によって算出することが容易に可能となる。

【００２６】これを実現するために、本実施形態では、
ＩＰ網１を構成する各ルータ１１が、それぞれ、後述す
るように、タイマ機能を有し、受信パケットの到着から
その受信パケットについての送信（転送）処理を完了す
べき限度時間（最大遅延保証時間）内に、受信パケット
の転送を終えることができる転送遅延保証機能付きパケ
ット通信装置として設計されている。

【００２７】そして、例えば、端末２，３間の通信にお
いて、事前に、送信元の端末２又は３が、着信先（受信
側）の端末３又は２へのパケット転送経路上に位置する
１又は２以上のルータ１１に対して、着信先の端末３又
は２へ送信するパケット量に関する情報をクエリーパケ
ットと称するパケットにより通知することで、そのパケ
ット量に対して当該ルータ１１が保証可能な最大遅延保
証時間を問い合わせて収集することができるようになっ
ている。

【００２８】そして、送信元の端末２又は３が、収集し
た最大遅延保証時間（合計）を受信側の端末３又は２に
通知することで、受信端である端末２又は３は、送信元
の端末３又２からのパケットのパケット転送経路上に位
置するルータ１１での最大遅延保証時間を事前に知るこ
とができる。その結果、通知された最大遅延保証時間に
基づいて自己の受信パケットのバッファリング量を適応
的に決定して最適化することができ、大規模なＩＰ網１
内でも、端末２，３間の通信の遅延量や揺らぎによる通
信品質の劣化をカバーして、必要な通信品質（ＱｏＳ）
を確保することが可能になる。

【００２９】即ち、この図１の例では、５台のルータ１
１の最大遅延保証時間Tdmaxが、それぞれ、1ms，2ms，
0.5ms，1ms，1msであるから、パケットの受信端である
端末２又は３は、これらの最大遅延保証時間Tdmaxの合
計である5.5msの遅延時間を保証しうるバッファリング
量を最低限必要な受信バッファリング量として決定する
ことになる。

【００３０】以下、このような機能（転送遅延保証機
能）を実現するルータ１１の構成について詳述する。図
２は本発明の一実施形態としてのルータ１１の構成を示
すブロック図で、この図２に示すルータ１１は、スイッ
チ部（スイッチファブリック）１２，入出力ポート数に
応じた数のネットワークインタフェース１３−１〜１３
−Ｎ，１３−（Ｎ＋１）〜１３−Ｘ（Ｎ，Ｘはそれぞれ
Ｎ＜Ｘを満足する自然数），タイマ１４及びプロトコル
管理部１５をそなえて構成され、ネットワークインタフ
ェース１３−ｉ（ｉ＝１〜Ｘ）は、それぞれ、さらに入
力側インタフェース１３１−ｉ及び出力側インタフェー
ス１３２−ｉをそなえて構成されている。

【００３１】ここで、タイマ１４は、各インタフェース
１３−ｉ（１３１−ｉ，１３２−ｉ）に対して遅延なく
タイマ信号（同期信号）を送出して、自ノード１１内で
統一された時刻情報を計時する（時刻同期をとる）ため
のものであり、プロトコル管理部１５は、後述する自ノ
ード１１での受信パケット量に応じた最大遅延保証時間
の交渉（ネゴシエーション）を行なうための機能を有す
るものである。

【００３２】また、スイッチファブリック１２は、ネッ
トワークインタフェース１３−ｉ（入力側インタフェー
ス１３１−ｉ）から入力されるパケットの宛先ヘッダの
内容に従って当該入力パケットをスイッチングして所望
の出力ポートに対応するネットワークインタフェース１
３−ｉ（出力側インタフェース１３２−ｉ）へルーティ
ングするものである。

【００３３】なお、本スイッチファブリック１２は、受
信パケットを入力側インタフェース１３１−ｉでＡＴＭ
（Asynchronous Transfer Mode）セルに変換することに
より、受信パケットをＡＴＭセルベースでスイッチング
するＡＴＭスイッチとして構成されることもある。さら
に、ネットワークインタフェース１３−ｉの入力側イン
タフェース１３１−ｉは、主に、回線側からの受信パケ
ットについての受信処理（バッファリング及び所定のル
ーティングテーブルに基づく宛先解決等）を行なうもの
であり、ネットワークインタフェース１３−ｉの出力側
インタフェース１３２−ｉは、スイッチファブリック１
２から入力されるパケットについての送信処理（バッフ
ァリング等）を行なうものである。

【００３４】ただし、本実施形態の入力側インタフェー
ス１３１−ｉは、上記の基本機能に加えて、受信パケッ
トにその到着時刻及び宛先解決に要した時間（遅延時
間）に関する情報を付加することができるようになって
おり、このように受信パケットに付加された情報を基に
出力側インタフェース１３２−ｉにおいて、端末２又は
３との事前の交渉処理により求められている最大遅延補
償時間内に必ずパケットが送出されるようにバッファリ
ング（パケット書込及び読出処理）が制御されるように
なっている。

【００３５】このため、入力側インタフェース１３１−
ｉ及び出力側インタフェース１３２−ｉは、例えば図３
に示すように、入力バッファ２１，宛先解決部２２，計
測モジュール２３，時刻情報付加部２４及びプロトコル
処理部２５をそなえて構成され、出力側インタフェース
１３２は、残時間判定部３１，書込制御部３２，読出制
御部３６及びバッファ管理部３７及びプロトコル処理部
３８をそなえるとともに、複数の実時間バッファ３３−
１〜３３−ｎ（キュー＃１〜＃ｎ），緊急出力バッファ
（キュー）３４及び非実時間バッファ（キュー）３５か
ら成る送信バッファ部３３をそなえて構成されている。

【００３６】ここで、まず、入力側インタフェース１３
１−ｉにおいて、入力バッファ２１は、回線側からの受
信パケットを一時的に保持するためのものであり、宛先
解決部２２は、入力バッファ２１から出力される受信パ
ケットの宛先ヘッダ情報に基づいて所定の宛先解決処理
を行なうもので、その際、受信パケットが自己宛のクエ
リーパケット等の制御パケットであれば、プロトコル処
理部２５へ転送されるようになっている。

【００３７】また、計測モジュール２３は、タイマ１４
の計時時刻に基づいて、受信パケットの到着時刻（入力
バッファ２１への書込時刻），上記の宛先解決部２２で
の宛先解決に要する遅延時間（宛先解決時間），スイッ
チファブリック１２でのスイッチングによる遅延時間
（スイッチング時間）等を監視することができるもので
ある。ただし、宛先解決時間及びスイッチング時間につ
いては、それぞれ、ルータ１１固有の値として固定値と
考えてもよい。

【００３８】さらに、時刻情報付加部２４は、計測モジ
ュール２３で得られた上記の情報（少なくとも到着時刻
情報）を受信パケットに付加するためのものであり、プ
ロトコル処理部２５は、自己宛のクエリーパケット等の
制御パケットの内容をプロトコル管理部１５に通知する
もので、これにより、プロトコル管理部１５によって受
信制御パケットに応じたプロトコル処理が実施されるよ
うになっている。

【００３９】具体的に、本実施形態では、このプロトコ
ル処理部２５と、プロトコル管理部１５及びプロトコル
処理部３８とが協働して動作することにより、新規に品
質（遅延時間）保証が必要な実時間データトラフィック
の要求（クエリーパケット）が受信された場合、どの程
度の遅延量なら保証可能かを受信端である端末２又は３
との間で交渉（ネゴシエーション）する機能が実現され
ている。つまり、プロトコル管理部１５は、自ノード１
１での遅延保証時間を、着信先の端末２又は３へ通知す
る遅延保証時間通知部としての機能を果たすものであ
る。

【００４０】これに対して、出力側インタフェース１３
２−ｉにおいて、残時間判定部３１は、スイッチファブ
リック１２から入力されるパケットに付加されている到
着時刻情報に基づいて、そのパケットを送信しなければ
ならない最大遅延保証時間までの残り時間を判定するも
のであり、書込制御部３２は、この残時間判定部３１で
の判定結果及び入力パケットのサービスタイプ等に応じ
て、入力パケットを送信バッファ部３３の実時間バッフ
ァ３３−１〜３３−ｎ，緊急出力バッファ３４及び非実
時間バッファ３５のいずれかに書き込む（エンキューす
る）ものである。

【００４１】なお、実時間バッファ３３−１〜３３−ｎ
には、音声通信や動画伝送などのリアルタイム性の要求
されるアプリケーションについてのデータトラフィック
（パケット）が保持され、ここに保持されたパケット
（以下、実時間パケットということがある）は、最大遅
延時間以内に送出（転送）が完了されるように読出制御
部３６による読み出し（デキュー）が行なわれる。

【００４２】これに対し、緊急出力バッファ３４には、
実時間パケットの中でも、最大遅延保証時間までの残り
時間が非常に少なく緊急出力を要するパケットが保持さ
れ、ここにパケットが存在する場合には、そのパケット
が最優先に読出制御部３６によって読み出される。非実
時間バッファ（非優先制御バッファ）３５には、FTP（F
ile Transfer Protocol），HTTP（Hyper Text Transfer
Protocol），SMTP（Simple Mail Transfer Protocol）
等の、伝送データの遅延や揺らぎが比較的問題とならな
い（遅延時間について考慮する必要性の乏しい）データ
トラフィック（パケット）が保持され、ここに保持され
たパケット（以下、非実時間パケットということがあ
る）は、実時間バッファ３３−１〜３３−ｎにパケット
が存在する場合、その実時間パケットの転送が最大遅延
時間以内に転送できなくなってしまわない範囲で、順
次、読出制御部３６によって読み出される。

【００４３】そして、読出制御部３６は、上記のような
優先読出制御をバッファ管理部３７で管理されているス
ケジュールデータ（次にデキューすべきパケットのバッ
ファ３３−１〜３３−ｎ，３４，３５の格納位置等の情
報）に基づいて実行するもので、例えば、次のような各
部としての機能を有している。 (1)緊急出力バッファ３４に受信パケットが存在する場
合に、当該緊急出力バッファ３４の受信パケットを最優
先に読み出す緊急出力制御部３６１ (2)非実時間バッファ３５に格納された受信パケットの
パケットサイズ情報と実時間バッファ３３−１〜３３−
ｎに格納された受信パケットについての残り時間とに基
づいて、非実時間バッファ３５に格納された受信パケッ
トを読み出しても、実時間バッファ３３−１〜３３−ｎ
に格納された受信パケットを上記の残り時間満了前に読
み出すことができるか否かを判定するバッファ読出判定
部３６２ (3)バッファ読出判定部３６２において実時間バッファ
３３−１〜３３−ｎに格納された受信パケットを上記の
残り時間満了前に読み出すことができると判定された場
合に、非実時間バッファ３５に格納された受信パケット
を読み出し対象に決定する決定部３６３次に、バッファ管理部３７は、ＣＡＭ（Content Addres
sable Memory）によりバッファ３３−ｊ（ｊ＝１〜
ｎ），３４，３５を管理するバッファ管理回路およびバ
ッファ管理テーブルとしての機能を果たすもので、パケ
ットが存在するバッファ３３−ｊ，３４，３５の中から
読み出すべきパケットを選択し、そのパケットについて
のデキュー指示を読出制御部３６に与えるもので、パケ
ット読み出し毎に、次に読み出すパケットが存在するバ
ッファ３３−ｊ，３４，３５の検索およびバッファ管理
テーブルの内容更新が行なわれるようになっている。な
お、本バッファ管理部３７の詳細動作については、図８
〜図１０により後述する。

【００４４】プロトコル処理部３８は、プロトコル管理
部１５と協働して、上記のネゴシエーションを実行する
とともに、それにより得られる通信条件に関する情報
（伝送パケット量等）に基づいて当該通信条件に対して
自ノード１１が保証可能な遅延保証時間を求めることが
できるものである。つまり、本実施形態において、残時
間判定部３１，バッファ管理部３７及びプロトコル処理
部３８は、タイマ１４が計時する時刻情報に基づいて、
受信パケットの到着時刻からその受信パケットの送信処
理を完了すべき遅延保証時間までの残り時間を監視する
監視部としての機能を果たし、書込制御部３２及び読出
制御部３６は、この監視部による監視結果に基づいて、
上記残り時間の少ない受信パケットほど優先的に送信さ
れるように、バッファ３３−１〜３３−ｎ，３４，３５
に対する受信パケットのバッファリングを制御するバッ
ファリング制御部としての機能を果たすのである。

【００４５】以上の構成により、本実施形態のノード１
１は、或るネットワークインタフェース１３−ｉの入力
側インタフェース１３１−ｉに入力されたパケットが他
の（あるいは同じ）ネットワークインタフェース１３−
ｋ（ｋ＝１〜Ｘ）の出力側インタフェース１３２−ｋへ
スイッチファブリック１２を介して回線側へ出力される
までの時間を、最大遅延保証時間内に保証することが可
能となる。

【００４６】以下、上述のごとく構成された本実施形態
のパケット通信システム（ノード１１）の動作について
詳述する。（１）最大遅延保証時間の交渉（ネゴシエーション）処
理まず、ここでは、図１において、端末３から端末２にパ
ケットを送信する（つまり、端末３を送信元の端末、端
末２を受信側の端末とする）場合のネゴシエーション処
理について、図５を参照しながら説明する。なお、以下
のネゴシエーション処理は、プロトコル管理部５，プロ
トコル処理部２５及び３８が協働して実施する。

【００４７】まず、受信側（着信先）の端末２（以下、
受信端末２と表記することがある）は、例えば、動画配
信サービスを送信側（発信元）の端末３（以下、送信端
末３と表記することがある）から受ける場合、送信端末
３に対して送信端末３宛のサービス要求パケットを送信
する。このサービス要求パケットには、受信端末２のＩ
Ｐアドレスが発信元アドレスとしてヘッダに格納されて
おり、送信端末３は、このサービス要求パケットを受信
すると、その発信元アドレスを宛先アドレスとする動画
データを送信することになる。

【００４８】さて、この動画データ送信の前に、送信端
末３は、通信開始を表すトリガパケットを受信端末２に
対して送信し、受信端末２は、このトリガパケットを受
信すると、図４に示すように、送信端末３に対して、そ
の通信フローを識別するためのラベル（label），通信
条件〔伝送パケットサイズPsize（バイト）及びパケッ
ト頻度（パケット送信間隔）iTime（秒）〕等をパケッ
トにより通知する（ステップＳ１）。

【００４９】なお、この場合の「ラベル」は、ＩＰアド
レスの端末２，３の組及びプロトコル等の一般的なＣＢ
ＷＦＱ等で用いられる「クラス」定義での要素でもよい
し、ＭＰＬＳ（Multi-Protocol Label Switching）で用
いられるラベルでもよい。ただし、この場合は、ＬＤＰ
(Label Distribution Protocol)等によるＭＰＬＳのラ
ベル配布が既に行なわれていることが前提である。

【００５０】次に、送信端末３は、ルータ１１を通過す
る毎に１ずつ減算されるＴＴＬ（Time To Live）の異な
る、受信端末２を宛先とする複数のクエリーパケットＱ
ｘ（ｘ＝１，２，３，…）を送信する（ステップＳ２〜
Ｓ６）。これらのクエリーパケットＱｘには、受信端末
２から送られたラベル（label），パケットサイズ（Psi
ze）及びパケット送信間隔（iTime）等の情報が含まれ
る。

【００５１】これにより、各クエリーパケットＱｘは、
ＴＴＬ＝０となるまで各ルータ１１（図４ではルータ
Ａ，Ｂ，Ｃ，…，Ｘと表記している）を転送されてゆ
き、受信端末２に至るパケット転送経路上の異なる１又
は２以上のルータ１１にそれぞれ到達することになる
（各ルータ１１は、ＴＴＬ＝０のクエリーパケットＱｘ
を自己宛と判断する）。

【００５２】そして、各ルータ１１が本プロトコルをサ
ポートしている場合、当該ルータ１１は、その時点で自
己が保証しうる最大遅延時間（TdmaxA，TdmaxB，…）と
平均的な送出時間（出力目標時間：TdtypA，TdtypB，
…）とを返信パケットＲｘにより送信端末３に返信する
（ステップＳ７，Ｓ８，Ｓ１０）。なお、本プロトコル
をサポートしていないルータ１１については、かかる返
信はないことになる（ステップＳ９）。また、受信端末
２に到着したクエリーパケットＱn+1に対しては、その
受信端末２からクエリーパケット受信を示すパケットが
返信パケットＲn+1として送信端末３に返信される（ス
テップＳ１１）。

【００５３】そして、送信端末３は、受信端末２からの
返信パケットＲn+1を受信することにより、ネゴシエー
ション処理の終了を認識し、返信のあった各ルータ１１
の最大保証遅延時間を合算して、得られた合計保証遅延
時間を受信端末２に通知する（ステップＳ１２）。これ
により、受信端末２は、自己の受信バッファリングサイ
ズと読出閾値とを最適化することができる。なお、逆方
向（端末２→端末３）についても、上記と同様のシーケ
ンスを実施することによって、双方向の品質保証が可能
である。

【００５４】また、上述のようにパケット転送経路上に
プロトコル未サポートのルータ１１が存在することが予
想されるが、受信端末２は、自己のバッファリングサイ
ズ及び読出閾値を算出する際の不確定要素である未知の
遅延時間を削減することができるので、通信時の再生品
質を向上させることができる。次に、上記のネゴシエー
ション処理について、ルータ１１（例えば図４に示すル
ータＢ）内での処理に着目して説明する。

【００５５】まず、ルータ１１が、クエリーパケットＱ
２をネットワークインタフェース１３−１の入力側イン
タフェース１３１において受信したとする。このクエリ
ーパケットＱ２は、プロトコル処理部２５へ渡され、プ
ロトコル処理部２５は、そのクエリーパケットＱ２に設
定されている宛先アドレスを基に着信先である受信端末
３に対応する出力側インタフェース１３２−ｉを検索・
特定（例えば、出力側インタフェース１３２−Ｘ）し、
その情報をプロトコル管理部１５に通知する。

【００５６】プロトコル管理部１５は、自ルータ１１内
の全てのネットワークインタフェース１３−ｉ間のパケ
ット転送遅延時間を保証するフローのラベル（Labe
l），パケットサイズ，パケット頻度，バッファリング
時間（Tbuff），最大遅延保証時間（Tdmax），設定時刻
等の内容（エントリ）をもつ管理テーブルを有してお
り、この管理テーブルのエントリに基づいて、現在の出
力側インタフェース１３２−Ｘが保証可能な最大遅延保
証時間を算出し、クエリーパケットＱ２に対する最大遅
延保証時間のエントリを登録する。

【００５７】また、プロトコル管理部１５は、クエリー
パケットＱ２を受信したネットワークインタフェース１
３−１における出力側インタフェース１３２−１のプロ
トコル処理部３８へ、送信端末３への返信パケットＲ２
として返答すべき内容を通知し、ネットワークインタフ
ェース１３−Ｘの出力側インタフェース１３２−Ｘのプ
ロトコル処理部２５に対してはラベルおよび最大遅延保
証時間を通知する。

【００５８】これにより、出力側インタフェース１３２
−Ｘのプロトコル処理部２５によって、バッファ管理部
３７に対して、遅延時間保証対象のフローについてのラ
ベル及び最大遅延保証時間の設定（登録）が行なわれ、
以降、実際のフローに対して、設定された最大遅延保証
時間を保証したパケット転送処理が実行されることにな
る。

【００５９】なお、送信端末３からの送信処理が終了
し、入力側インタフェース１３１−１のプロトコル管理
処理部２５にて、通信終了通知が受信されると、当該通
知がプロトコル管理部１５経由で出力側インタフェース
１３２−Ｘのプロトコル処理部２５へ通知されて、バッ
ファ管理部３７における該当フローのエントリが削除さ
れて遅延保証処理が解除された後、プロトコル管理部１
５のもつ管理テーブルから該当エントリが削除される。

【００６０】（２）遅延保証時間の算出次に、上記のプロトコル管理部１５での遅延保証時間の
算出方法について説明する。ＩＰ網１内のリソースは限
られているため、品質保証するためには優先（遅延時間
保証）制御を行なうフローを制限する必要がある。遅延
保証時間は、その時点でどの程度の遅延保証トラフィッ
クが存在するかによって保証できる時間を変更する。こ
れはそもそも不可能な保証遅延時間を設定してしまうこ
とにより遅延保証機能が破綻しないようにするためであ
る。

【００６１】遅延保証時間の概略と算出方法の一例を図
６に示す。この図６に示すように、ノード１１にパケッ
トが到着（到着時刻T_０）してから出力されるまでの予
定時間（出力目標時間）をTdtypとし、現在ｍ個のフロ
ーの品質保証を行なうフローがある場合に、ｍ＋１番目
のフローの遅延保証時間を求めるとする。新規パケット
頻度をTfreq(1/s)、装置の１ビット出力当たりの時間を
Tout(s)とすると、出力目標時間Tdtypは、次のように表
される。 Tdtyp＝宛先解決時間＋スイッチング時間＋ΣTbuff(i)×Tout …（１）ただし、この式（１）において、ｉ＝１〜ｍ＋１であ
り、Σは１〜ｍ＋１の各フローについてのバッファリン
グ時間Tbuffの総和を表す。ここで、宛先解決時間及び
スイッチング時間を、ルータ１１固有の固定値と考えれ
ば、出力目標時間Tdtypは、ΣTbuff(i)×Toutのみに依
存することになる。そして、 Tbuff(i)＝〔パケットサイズ(i)×パケット頻度(/s)(i)〕／Tfreq …（２）と表すことができる。つまり、バッファリング時間Tbuf
fは、新規フローの出力間隔時間（パケット頻度の逆
数）当たりに出力される、既存フローのデータ量を出力
するのに必要な時間を表す。そして、最大遅延保証時間
Tdmaxは、例えば、品質保証するフローのパケットの２
倍とすると、 Tdmax＝Tdtyp＋２×ΣTbuff(i)×Tout …（３）と表すことができる。

【００６２】このように、本プロトコル処理部３８は、
着信先の端末２又は３から上述したネゴシエーションに
より事前に通知された、送信元の端末３又は２の送信パ
ケット量に関する情報に基づいて遅延保証時間を算出す
る遅延保証時間算出部３８１（図３参照）としての機能
も有している。そして、以上のようにして求められる出
力目標時間Tdtyp及び最大遅延保証時間Tdmaxが、出力側
インタフェース１３１−ｉのプロトコル処理部３８に通
知されることで、バッファ管理部３７において、パケッ
ト到着時刻（T_０）からの出力目標時刻Tt及び最大遅延
保証時刻Teが求められ、これらが後述するようにバッフ
ァ管理部３７のキュー毎の管理テーブルに登録されるの
である。

【００６３】これにより、ノード１１では、そのノード
１１が実際に受信するパケット量に見合った遅延保証時
間を求めることができ、遅延保証時間が単純に固定であ
る場合に比して、より確実な遅延保証を実現することが
可能となる。（３）キューの選択次に、受信パケットをバッファリングするキューの選択
処理について説明する。

【００６４】このキュー選択は、残時間判定部３１がバ
ッファ管理部３７と協働して動作することによって行な
われる。即ち、残時間判定部３１は、まず、新規受信パ
ケットが実時間パケットか非実時間パケット（FTP，HTT
P，SMTP等のパケット）か否かを判別し、非実時間パケ
ットであった場合、Tbuffの値を無限大として、非実時
間バッファ３５を新規受信パケットの格納先として選択
する。

【００６５】これに対し、新規受信パケットが実時間パ
ケットであった場合、残時間判定部３１は、新規受信パ
ケットの到着時刻T_０＋出力目標時間Tdtypにより出力目
標時刻Tt(new)を算出し、この出力目標時刻Tt(new)と各
キュー３３−ｉの最後尾パケットの出力目標時刻Tt(en
d)とを比較し、「Tt(new)＞Tt(end)(i)で、且つ、最後
尾パケットの出力目標時刻Tt(end)(i)が最大」（条件
）のキュー３３−ｉを格納先として選択する。

【００６６】一方、各キュー３３−ｉについて上記の比
較を繰り返しても、全てのキュー３３−ｉについて上記
の条件が満たせない場合、残時間判定部３１は、新規
受信パケットの到着時刻T_０＋最大遅延保証時間Tdmaxに
より最大遅延保証時刻Te(new)を算出し、この最大遅延
保証時刻Te(new)と各キュー３３−ｉの最後尾パケット
の出力目標時刻Tt(end)とを比較し、「Te(new)＞Tt(en
d)(i)で、且つ、最後尾パケットの出力目標時刻Tt(end)
(i)が最小」（条件）のキュー３３−ｉを格納先とし
て選択する。

【００６７】そして、上記の条件，をともに満たせ
ない場合、残時間判定部３１は、緊急出力バッファ３４
を新規受信パケットの格納先として選択する。以上の選
択結果が書込制御部３２に通知されることで、新規受信
パケットは、書込制御部３２によって該当バッファ３３
−ｉ，３４又は３５に書き込まれることになる。

【００６８】一例として図７に示すような状態を考えて
みる。この図７に示す場合は、まず、新規受信パケット
「Fx1」の出力目標時刻「Tt(1)」と、各キュー３３−ｉ
の最後尾パケットの出力目標時刻「TtA」，「TtB」，
「TtC」とがそれぞれ比較され、条件（最後尾パケッ
トの出力目標時刻「Tt」が、新規受信パケット「Fx1」
の出力目標時刻「Tt(1)」よりも小さく、且つ、最大）
を満足するキュー３３−ｉに新規受信パケット「Fx1」
が書込制御部３２によって書き込まれることになる。

【００６９】これに対し、条件を満足できなかった場
合は、新規パケットFx1の最大遅延保証時間「Te(1)」
と、各キュー３３−ｉの最後尾パケットの「TtA」，「T
tB」，「TtC」とが比較され、条件（最後尾パケット
の出力目標時刻「Tt」が、新規受信パケット「F x1」の
最大遅延保証時刻「Te(1)」よりも小さく、且つ、最
小）を満足するキュー３３−ｉに新規受信パケット「Fx
1」が書込制御部３２によって書き込まれることにな
る。

【００７０】そして、上記の条件，をともに満たせ
なかった場合、新規受信パケット「Fx1」は、書込制御
部３２によって緊急出力バッファ３５に書き込まれるこ
とになる。これにより、宛先解決に要する時間が大量に
発生した場合などに最大遅延保証時刻Teが守れなくなる
可能性がある場合であっても、緊急出力バッファ３５の
保持されたパケットは最優先で出力することが可能とな
る。

【００７１】（４）キュー管理方法次に、上記のキュー選択条件に基づくバッファ管理部３
７でのキュー管理方法の一例について、図８〜図１０を
用いて説明する。図８に示すように、バッファ管理部３
７は、例えば、各キュー＃１〜＃ｎについての管理テー
ブル３７１−１〜３７１−ｎを保持するメインＣＡＭ３
７１と、各キュー＃１〜＃ｎについての書込用キュー最
後尾パケット管理テーブル３７２−１〜３７２−ｎを保
持する書込用キュー最後尾管理レジスタ３７２と、各キ
ュー＃１〜＃ｎについての読出用キュー先頭管理テーブ
ル３７３−１〜３７３−ｎを保持する読出用キュー先頭
管理レジスタ３７３とをそなえて構成される。

【００７２】そして、管理テーブル３７１−１〜３７１
−ｎには、それぞれ、例えば図９に示すように、保持し
ているパケットについてのパケットサイズ，到着時刻，
出力目標時刻Tt，最大遅延保証時刻Te等の各情報が登録
される。また、書込用キュー最後尾パケット管理テーブ
ル３７２−１〜３７２−ｎには、例えば図１０（Ｂ）に
示すように、キュー＃ｊの最後尾に書き込まれたパケッ
トについてのラベル，パケットサイズ，到着時刻，出力
目標時刻Tt，最大遅延保証時刻Te，キュー番号等の各情
報が登録され、読出用キュー先頭パケット管理テーブル
３７３−１〜３７３−ｎには、図１０（Ａ）に示すよう
に、キュー＃ｊの先頭パケットについてのラベル，パケ
ットサイズ，到着時刻，出力目標時刻Tt，最大遅延保証
時刻Te，キュー番号等の各情報が登録される。

【００７３】これにより、各キュー＃ｊのパケット送出
（読出）をいつまでに完了しなければならないかが、こ
れらの管理テーブル３７１−ｊ，３７２−ｊ，３７３−
ｊによって、バッファ管理部３７にて一括管理されるこ
とになる。以下、本バッファ管理部３７の動作について
説明する。なお、出力側インタフェース１３２−ｉ（プ
ロトコル処理部３８）では、プロトコル管理部１５によ
る前述の交渉により得られた情報（ラベル，パケットサ
イズ，間隔等）を保持しているものとする。

【００７４】まず、新規パケットが出力側インタフェー
ス１３２−ｉへ到着すると、残時間判定部３１にて、そ
の新規パケットに入力側インタフェース１３１−ｉにて
付加された到着時刻T_０が抽出されるとともに、プロト
コル処理部３８及びプロトコル管理部１５によって、タ
イマ１４の現在時刻を基に出力目標時刻Tt及び最大遅延
保証時刻Teが算出される〔前記の式（２）及び式（３）
参照〕。

【００７５】そして、上記新規パケットが書込制御部３
２によって前記のバッファ選択処理に従って書き込まれ
ると、これらの値が該当キュー＃ｊの管理テーブル３７
１−ｊに登録されるとともに、この登録に伴って該当キ
ュー＃ｊの書込用最後尾パケット管理テーブル３７２−
ｊの内容が更新される。また、バッファ管理部３７は、
各キュー＃ｊからパケットが読み出される毎に、キュー
＃ｊの先頭及び最後尾のパケットのエントリを管理テー
ブル３７１−ｊから読み出し、対応するレジスタ３７
２，３７３（管理テーブル３７２−ｊ，３７３−ｊ）に
取り込み、キュー＃ｊ毎にキュー＃ｊの先頭と最後尾の
パケットの出力目標時刻Tt，最大遅延保証時刻Teをタイ
マ１４からの同期信号に従って単位時間毎に減算する。
これにより、出力目標時刻Ttが小さいパケットほどそれ
ぞれ出力目標時刻Ttまでの残り時間が少なく、最大遅延
保証時刻Teが小さいパケットほど最大遅延保証時刻Teま
での残り時間が少ないことになる。

【００７６】なお、キュー＃ｊにパケットが１つだけ保
持されている状態では、先頭パケット＝最後尾パケット
であり、当該パケットについての情報が読出用先頭パケ
ット管理テーブル３７３−ｊに登録されていることにな
る。さて、読み出し処理については、読出制御部３６
が、まず、緊急出力バッファ３４にパケット〔つまり、
最大遅延保証遅延時刻Teまでの残り時間が非常に少ない
（図６に示す「緊急出力時間」にあるパケット）〕が存
在するかをチェックし、緊急出力バッファ３４にパケッ
トが存在すれば、緊急出力制御部３６１（図３参照）と
しての機能により、当該緊急出力バッファ３４に保持さ
れているパケットを最優先に読み出す。

【００７７】緊急出力バッファ３４にパケットが存在し
ない場合は、読出制御部３６は、読出用先頭パケット管
理テーブル３７３−ｊを参照して、まず、各キュー（実
時間バッファ）＃ｊの先頭パケットの最大遅延保証時刻
Teをチェックし、当該最大遅延保証時刻Teが最小のもの
から優先的に読み出しを行ない、次いで、出力目標時刻
Ttをチェックし、当該出力目標時刻Ttが最小のものから
優先的に読み出しを行なう。このように、実時間パケッ
トについては、最大遅延保証時間Teを超えないよう優先
的に読み出しが行なわれる。

【００７８】なお、非実時間バッファ３５に或るパケッ
トサイズのパケットが存在する場合、読出制御部３６
は、その先頭パケットを送出したとしても、実時間バッ
ファ＃ｊ内で最大遅延保証時刻Te及び出力目標時刻Ttが
最小のパケットの送出を完了できるか否かをバッファ読
出判定部３６２としての機能により判定し、完了できれ
ば、決定部３６３としての機能により、その非実時間パ
ケットを読出対象パケットと決定して読み出しを行な
う。

【００７９】かかる読出制御により、残り時間に基づく
優先読出制御を行なうトラフィック（パケット）のクラ
スと、残り時間に依存しない（優先読出制御を行なわな
い）クラスとで、パケットサイズと残り時間とに基づい
て読み出しの優先度が変更され、遅延時間の均等化を図
ることができる。例えば、図１１（Ａ）に模式的に示す
ように、実時間バッファＡ，Ｂ，Ｃ，Ｄにそれぞれ，パ
ケットＡ１，Ａ２，Ａ３，パケットＢ１，パケットＣ
１，パケットＤ１が保持され、非実時間バッファ３５に
パケットＮＲ１が保持されているとすると、各パケット
Ａ１〜Ａ３，Ｂ１，Ｃ１，Ｄ１，ＮＲＺ１は、図１１
（Ｂ）に模式的に示すように、パケットＡ１→パケット
Ｂ１→パケットＣ１→パケットＡ２→パケットＮＲＺ１
→パケットＤ１→パケットＡ３の順序で読み出されて送
出されることになる。

【００８０】以上のように、本実施形態によれば、ＩＰ
網１を構成するノード１１において、到着時刻T_０から
最大遅延保証時刻Teまでの残り時間の少ない実時間パケ
ットほど優先的に転送されるので、ノード１１で発生す
るパケット転送遅延の最大値を保証することができる。
その結果、端末２，３は、受信パケットのバッファリン
グ量を適応的に決定して最適化することができ、大規模
なＩＰ網１内でも、端末２，３間の通信の遅延量や揺ら
ぎによる通信品質の劣化をカバーして、必要な通信品質
（ＱｏＳ）を確保することが可能になり、特に、リアル
タイム性の要求される通信品質を向上させることができ
る。

【００８１】・その他なお、本発明は上述した限定されず、本発明の趣旨を逸
脱しない範囲で種々変形して実施することができる。例
えば、上述した実施形態では、ネゴシエーションの際、
受信端末２又は３に対して、出力目標時刻及び最大遅延
保証時刻の双方を通知しているが、これらのいずれか一
方のみを通知するようにしてもよい。

【００８２】また、各ノード１１において、最大遅延保
証時刻Teを算出する際、宛先解決時間及びスイッチング
時間は固定値としているが、勿論、これらの時間をリア
ルタイムに計測するようにしてもよい。さらに、上述し
た実施形態では、パケット通信装置として端末２，３間
の通信に本発明を適用した場合について説明したが、Ｉ
Ｐ網１内の任意のノード１１間（例えば、エッジノード
間）の通信に適用することも可能である。

【００８３】・付記（付記１）複数のパケット通信装置をそなえて成るパ
ケット通信システムにおいて、或るパケット転送経路上
で通信を行なうにあたって、該パケット転送経路上に位
置する１又は２以上のパケット通信装置が、或る受信パ
ケット量に対して自己が保証しうるパケット転送の遅延
時間情報を着信先であるパケット通信装置へ通知し、該
着信先であるパケット通信装置が、通知された該遅延時
間情報に基づいて、送信元のパケット通信装置との間の
該パケット転送経路を用いた通信についての受信パケッ
トのバッファリング量を決定することを特徴とする、パ
ケット通信システムにおける通信品質保証方法。

【００８４】（付記２）パケット通信システムを構成
するパケット通信装置であって、時刻情報を計時するタ
イマと、該受信パケットをバッファリングする送信バッ
ファ部と、該タイマが計時する時刻情報に基づいて、該
受信パケットの到着時刻から当該受信パケットの送信処
理を完了すべき遅延保証時間までの残り時間を監視する
監視部と、該監視部による監視結果に基づいて、該残り
時間の少ない受信パケットほど優先的に送信されるよう
に、該送信バッファ部に対する該受信パケットのバッフ
ァリングを制御するバッファリング制御部とをそなえた
ことを特徴とする、転送遅延保証機能付きパケット通信
装置。

【００８５】（付記３）該監視部が、着信先のパケッ
ト通信装置から事前に通知された、送信元のパケット通
信装置の送信パケット量に関する情報に基づいて該遅延
保証時間を算出する遅延保証時間算出部をそなえたこと
を特徴とする、付記２記載の転送遅延保証機能付きパケ
ット通信装置。

【００８６】（付記４）該送信バッファ部が、該監視
部で監視される該残り時間に応じた優先送信制御を行な
う受信パケットを格納する優先制御バッファと、該監視
部で監視される該残り時間に依存しない送信制御を行な
う受信パケットを格納する非優先制御バッファとをそな
えるとともに、該バッファリング制御部が、該非優先制
御バッファに格納された受信パケットのパケットサイズ
情報と該優先制御バッファに格納された受信パケットに
ついての該残り時間とに基づいて、該非優先制御バッフ
ァに格納された受信パケットを読み出しても、該優先制
御バッファに格納された受信パケットを該残り時間満了
前に読み出すことができるか否かを判定するバッファ読
出判定部と、該バッファ読出判定部において該優先制御
バッファに格納された受信パケットを該残り時間満了前
に読み出すことができると判定された場合に、該非優先
制御バッファに格納された受信パケットを読み出し対象
に決定する決定部とをそなえて構成されたことを特徴と
する、付記２又は３に記載の転送遅延保証機能付きパケ
ット通信装置。

【００８７】（付記５）該送信バッファ部が、該監視
部で監視される該残り時間が所定時間よりも少ない緊急
出力の必要な受信パケットを格納する緊急出力バッファ
をそなえるとともに、該バッファリング制御部が、該緊
急出力バッファに受信パケットが存在する場合に、当該
緊急出力バッファの受信パケットを最優先に読み出す緊
急出力制御部をそなえて構成されたことを特徴とする、
付記２〜４のいずれか１項に記載の転送遅延保証機能付
きパケット通信装置。

【００８８】（付記６）該遅延保証時間を、該着信先
のパケット通信装置へ通知する遅延保証時間通知部をそ
なえたことを特徴とする、付記２〜５のいずれか１項に
記載の転送遅延保証機能付きパケット通信装置。

【００８９】

【発明の効果】以上詳述したように、本発明によれば、
次のような効果ないし利点が得られる。 (1)送信元の端末が、パケット通信装置に問い合わせて
収集した遅延保証時間を着信先に通知することで、着信
先は、パケット転送経路上で発生しうる遅延時間を事前
に知ることができるので、自己の受信パケットのバッフ
ァリング量を適応的に決定して最適化することができ、
大規模なネットワークにおいても、通信の遅延量や揺ら
ぎによる通信品質の劣化をカバーして、必要な通信品質
を確保することが可能になる。

【００９０】(2)パケット通信装置では、パケットの到
着時刻から最大遅延保証時刻までの残り時間の少ない実
時間パケットほど優先的に転送することができるので、
パケット通信装置で発生するパケット転送遅延の最大値
を保証することができる。その結果、大規模なネットワ
ークにおいても、パケット通信装置間で必要な通信品質
（ＱｏＳ）を容易に確保することが可能になり、安価に
実時間通信における通信品質を向上させることができ
る。

【００９１】(3)着信先のパケット通信装置から事前に
通知された、送信元のパケット通信装置の送信パケット
量に関する情報に基づいて上記の遅延保証時間を算出す
ることができるので、パケット通信装置が実際に受信す
るパケット量に見合った遅延保証時間を求めることがで
き、遅延保証時間が単純に固定である場合に比して、よ
り確実な遅延保証を実現することができる。

【００９２】(4)遅延保証時間の残り時間に基づく優先
読出制御を行なうトラフィック（パケット）のクラス
と、残り時間に依存しない（優先読出制御を行なわな
い）クラスとで、パケットサイズと残り時間とに基づい
て読み出しの優先度を変えることができるので、遅延時
間の均等化を図ることができる。 (5)遅延保証時間の残り時間が少ない受信パケットは緊
急出力バッファに保持させ、この緊急出力バッファに受
信パケットが存在する場合には、その受信パケットを最
優先に読み出すようにすることができるので、確実に、
遅延保証時間内にパケットの送信（転送）を完了するこ
とができる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るパケット通信システ
ムの構成を示すブロック図である。

【図２】図１に示すルータの構成を示すブロック図であ
る。

【図３】図２に示すルータのネットワークインタフェー
スの構成を示すブロック図である。

【図４】図１に示すパケット通信システムの動作（ネゴ
シエーション）を説明するためのシーケンス図である。

【図５】図２に示すルータにおけるネゴシエーション時
の動作を説明するための図である。

【図６】本実施形態に係るルータでの最大遅延保証時間
の概念を説明するための図である。

【図７】図２及び図３に示すルータでの書込動作を説明
するための図である。

【図８】図３に示すバッファ管理部の構成を示すブロッ
ク図である。

【図９】図８に示すメインＣＡＭに保持されるキュー毎
の管理テーブルの一例を示す図である。

【図１０】（Ａ）は図８に示す読出用キュー先頭管理レ
ジスタに保持される読出用キュー先頭管理テーブルの一
例を示す図、（Ｂ）は図８に示す書込用キュー最後尾管
理レジスタに保持される書込用キュー最後尾管理テーブ
ルの一例を示す図である。

【図１１】（Ａ）及び（Ｂ）はいずれも図３に示す読出
制御部による読出動作を説明するための図である。

【図１２】従来のパケット通信システムを示すブロック
図である。

【図１３】従来のパケット通信システムの課題を説明す
るための図である。

【図１４】図１２及び図１３に示すパケット通信システ
ムを構成するルータの構成を示すブロック図である。

【図１５】図１４に示すネットワークインタフェースの
構成を示すブロック図である。

【符号の説明】

１ＩＰ網（パケット通信網）２，３端末（パケット通信装置）１１ルータ（パケット通信装置）１２スイッチファブリック（スイッチ部）１３−１〜１３−Ｘネットワークインタフェース１３１−１〜１３１−Ｘ入力側インタフェース１３２−１〜１３２−Ｘ出力側インタフェース１４タイマ１５プロトコル管理部（遅延保証時間通知部）２１入力バッファ２２宛先解決部２３計測モジュール２４時刻情報付加部２５プロトコル処理部３１残時間判定部（監視部）３２書込制御部（バッファリング制御部）３３送信バッファ部３３−１〜３３−ｎ実時間バッファ３４緊急出力バッファ３５非実時間バッファ３６読出制御部（バッファリング制御部）３６１緊急出力制御部３６２バッファ読出判定部３６３決定部３７バッファ管理部（監視部）３７１メインＣＡＭ３７１−１〜３７１−ｎ管理テーブル３７２書込用キュー最後尾管理レジスタ３７２−１〜３７２−ｎ書込用キュー最後尾管理テー
ブル３７３読出用キュー先頭管理レジスタ３７３−１〜３７３−ｎ読出用キュー先頭管理テーブ
ル３８プロトコル処理部（監視部）３８１遅延保証時間算出部

───────────────────────────────────────────────────── フロントページの続き (72)発明者村田雄志福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者今村勝巳福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者宮浦武士福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者福永英世福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者吉田光州福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内Ｆターム(参考） 5K030 GA11 GA14 HA08 HB01 HB02 KA03 LC01 LC09 MA07 MA13 MB06 MC06

Claims

【特許請求の範囲】

【請求項１】複数のパケット通信装置をそなえて成る
パケット通信システムにおいて、或るパケット転送経路上で通信を行なうにあたって、該
パケット転送経路上に位置する１又は２以上のパケット
通信装置が、或る受信パケット量に対して自己が保証し
うるパケット転送の遅延時間情報を着信先であるパケッ
ト通信装置へ通知し、該着信先であるパケット通信装置が、通知された該遅延
時間情報に基づいて、送信元であるパケット通信装置と
の間の該パケット転送経路を用いた通信についての受信
パケットのバッファリング量を決定することを特徴とす
る、パケット通信システムにおける通信品質保証方法。
【請求項２】パケット通信システムを構成するパケッ
ト通信装置であって、時刻情報を計時するタイマと、該受信パケットをバッファリングする送信バッファ部
と、該タイマが計時する時刻情報に基づいて、該受信パケッ
トの到着時刻から当該受信パケットの送信処理を完了す
べき遅延保証時間までの残り時間を監視する監視部と、該監視部による監視結果に基づいて、該残り時間の少な
い受信パケットほど優先的に送信されるように、該送信
バッファ部に対する該受信パケットのバッファリングを
制御するバッファリング制御部とをそなえたことを特徴
とする、転送遅延保証機能付きパケット通信装置。
【請求項３】該監視部が、着信先のパケット通信装置から事前に通知された、送信
元のパケット通信装置の送信パケット量に関する情報に
基づいて該遅延保証時間を算出する遅延保証時間算出部
をそなえたことを特徴とする、請求項２記載の転送遅延
保証機能付きパケット通信装置。
【請求項４】該送信バッファ部が、該監視部で監視される該残り時間が所定時間よりも少な
い緊急出力の必要な受信パケットを格納する緊急出力バ
ッファをそなえるとともに、該バッファリング制御部が、該緊急出力バッファに受信パケットが存在する場合に、
当該緊急出力バッファの受信パケットを最優先に読み出
す緊急出力制御部をそなえて構成されたことを特徴とす
る、請求項２又は３に記載の転送遅延保証機能付きパケ
ット通信装置。
【請求項５】該遅延保証時間を、該着信先のパケット
通信装置へ通知する遅延保証時間通知部をそなえたこと
を特徴とする、請求項２〜４のいずれか１項に記載の転
送遅延保証機能付きパケット通信装置。