JP2006261897A - 端末アダプタ装置 - Google Patents

端末アダプタ装置 Download PDF

Info

Publication number
JP2006261897A
JP2006261897A JP2005074628A JP2005074628A JP2006261897A JP 2006261897 A JP2006261897 A JP 2006261897A JP 2005074628 A JP2005074628 A JP 2005074628A JP 2005074628 A JP2005074628 A JP 2005074628A JP 2006261897 A JP2006261897 A JP 2006261897A
Authority
JP
Japan
Prior art keywords
packet
priority
terminal
adapter device
terminal adapter
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
JP2005074628A
Other languages
English (en)
Other versions
JP4649242B2 (ja
Inventor
Hidenori Inai
秀則 井内
哲郎 ▲吉▼本
Tetsuo Yoshimoto
Hitomi Nakamura
仁美 中村
Junichi Fujiwara
淳一 藤原
Akira Matsukawa
公 松川
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.)
Hitachi Communication Technologies Ltd
Original Assignee
Hitachi Communication Technologies Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Communication Technologies Ltd filed Critical Hitachi Communication Technologies Ltd
Priority to JP2005074628A priority Critical patent/JP4649242B2/ja
Publication of JP2006261897A publication Critical patent/JP2006261897A/ja
Application granted granted Critical
Publication of JP4649242B2 publication Critical patent/JP4649242B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】優先度が高いデータフレームを優先的に転送して、インターネットにおけるQoS保証を行う。
【解決手段】ネットワークに接続され、フレームを送受信する送受信部と、各種処理を行う制御部と、前記制御部が使用するデータが格納された記憶部と、を備える端末アダプタ装置であって、前記記憶部には、受信したデータフレームが格納される受信キューが設けられ、前記制御部は、前記受信したデータフレームの優先度を判定し、前記判定された優先度の順に前記受信データフレームを受信キューに格納し、前記キューに格納されたデータフレームを、当該データフレームに付与された優先度順に取り出して転送する。
【選択図】図1

Description

本発明は、LANに接続された端末をインターネットを接続するための端末アダプタ装置に関し、特に、QoSの制御技術に関する。
近年、IP(Internet Protocol)ネットワークによるリアルタイムトラヒックのQoS制御に関する検討が活発化している。IETF(Internet Engineering Task Force)は、ECN(Explicit Congestion Notification)仕様の標準化をすすめている(例えば、非特許文献1参照)。
通信経路に存在する中継ルータにおいてパケットが輻輳すると、キューがオーバフローする。ECNによると、中継ルータは、受信パケットを廃棄する前に、ネットワークにおける輻輳の発生を、受信ノードに対して通知する。すなわち、中継ルータは、IPパケットのECNフィールド(IPv4の場合にはTOS(Type Of Service)フィールドの下位2ビット、IPv6の場合にはTC(Traffic Class)フィールドの下位2ビット)に設定し、輻輳の発生を通知する。
現在のインターネットでは、一部のファイヤウォール機器がECNフィールドが設定されているパケットを廃棄することがある。また、途中の中継ルータがECNフィールドを書き換えてしまことがある。
また、RFC3168では、中継ルータがECNフィールドを設定するタイミングは規定していない。バーストトラヒックの受信等によって、キューに滞留しているパケット数が一時的に多くなった場合にECNフィールドを設定することがある。実際には輻輳が発生していないにもかかわらず、受信ノードは輻輳が発生してパケットが廃棄されえていると認識して、例えばTCP/IPの輻輳制御アルゴリズムが働いてしまい、スループットが低下する問題も生じる。
また、公知のIP技術とQoS技術とを組み合わせることによって、インターネットサーバとLAN端末間のパケット又はLAN端末間のパケットの優先制御を実現できる。
IETF RFC3168、The Addition of Explicit Congestion Notification (ECN) to IP
家庭に設置する端末アダプタ装置が、複数種類のトラヒック(例えば、IPv6マルチキャストビデオストリーム、IPv4/IPv6 VoIPパケット、IPsecデータストリーム)を、インターネット側から受信してLAN側端末に配信する場合を考える。最も帯域の狭いVoIPストリームを優先的に転送するQoS制御を行う際に、VoIP以外のストリームの優先廃棄と、VoIPストリームの優先転送とをソフトウェアで実装する場合には、上りVoIPトラヒックと下りVoIPトラヒックが同一のキュー資源を共用するため、下りトラヒックの優先制御によって上りトラヒックの優先制御が期待どおりの働きをしないこと(又は、その逆)がある。
WAN側はVLAN技術を用いることにより、VLAN ID又はVLANの優先度(VLAN Priority)によって、下りトラヒックの優先度をL2レベルで設定することができる。しかし、家庭内のLANではVLAN機能が実装されてない場合が多く、LAN側I/FにはVLANを設定することができない。また、VoIPトラヒックは、お互い独立な双方向のRTPパケットで転送されるが、L2/L3レベルではこの双方向トラヒックを同一セッションに属するストリームとして認識していないので、実効性の高いQoS制御が困難であった。
本発明の第1の目的は、インターネットを利用したリアルタイム通信サービスにおいて、VoIPのような双方向のデータストリームを使用する通信サービスに対して、同時に使用する他の通信サービスとは異なるQoS制御を行うことにある。このため、ユーザ宅に設置された端末アダプタ装置と対向する端末アダプタ装置との間でQoSを保証した通信を行う端末アダプタ装置の構成を提供し、従来の電話サービスと同等のサービス品質を提供する場合に、端末アダプタにおけるQoSを保証する通信システムを実現することにある。
本発明の第2の目的は、上記QoSサービスを実現するためのQoS設定情報のパラメータの設定を簡単化又は自動化することによって、端末アダプタ装置及びゲートウェイ装置を使用する際の設定の利便性を高めることにある。
例えば、家庭に設置した端末アダプタ装置と複数の端末アダプタ装置との間でVoIPのRTPセッションを設定する場合に、対向地点毎にどのような通信品質を保証するかというQoS設定ポリシを自動的に設定できれば、ユーザの利便性は飛躍的に向上すると考えられる。通常、家庭内からネットワークへアクセスする場合には、ユーザの利便性を高めるために、複数の地点と同時に接続すること求められている。インターネット接続サービスを行うISP又は会社等のCUG(Closed User Group)へのVPN接続サービスを、従来のインターネット接続サービスと同等の使い勝手で実現することは、多地点のリアルタイム通信を実現する上で重要である。
本発明に係る端末アダプタ装置は、ネットワークに接続され、フレームを送受信する送受信部と、各種処理を行う制御部と、前記制御部が使用するデータが格納された記憶部と、を備え、前記記憶部には、受信したデータフレームが格納される受信キューが設けられ、前記制御部は、前記受信したデータフレームの優先度を判定し、前記判定された優先度の順に前記受信データフレームを受信キューに格納し、前記キューに格納されたデータフレームを、当該データフレームに付与された優先度順に取り出して転送する。
本発明によると、優先度が高いデータフレームを優先的に転送するので、QoSを保証することができる。
まず、本発明に係るQoS端末アダプタ装置の特徴を説明する。
(1)LANからWANへのVoIPトラヒックは、常に最優先のQoS制御を行うQoS制御手段を備える。この方法は、LAN内トラヒックに対して優先度を設定できない端末アダプタ装置における最も簡単な上りトラヒックのQoS制御方法である。しかし、上り方向にVoIPと同等のQoS制御を必要とするサービスが存在する場合(例えば、Winny等の大容量ファイル交換P2Pサービス)には十分な効果が得られない。
(2)L2レベルのclassification(CPUの前段に設けられたL2スイッチが、LANからWANへの優先トラヒックを識別等)を用いることによって、上りトラフックのQoSを制御する。この方法は、サービスが競合する場合の問題を解決することができるが、優先制御する端末を接続する物理ポートが限定されるので、QoS端末アダプタ装置の使い勝手が必ずしもよいとはいえない。
(3)端末アダプタ装置に対する下り優先トラヒックがある閾値以上滞留した場合には、tail drop(パケットを破棄)する。これと同時に、キューに滞留している下り(RTP/IP)パケットのIPヘッダの中にあるECNフォールドのCEビットを”1”に設定する。このCEビットの設定によって、端末アダプタ装置の受信キューが輻輳状態にあり、優先パケットが廃棄される可能性があることを、LAN端末に通知する。この方法は、端末アダプタ装置がECNマーキングを行うことにより、対向端末アダプタ装置に収容された上流側のLAN端末で品質を監視することができる。よって、ユーザ操作により優先トラヒックに対して干渉又は雑音と考えられるトラヒックを制限する判断が可能になる。
(4)端末アダプタ装置は、RTCPパケットを監視(snoop)する手段を備え、RTCPパケットに含まれるネットワークの品質特性(ジッタ、パケットロス等)の情報を把握する。よって、端末の助けを必要とせずに端末の品質特性を把握することができ、動的にQoSを制御することができる。この方法によると、端末の他に端末アダプタ装置が通信品質特性を把握することによって、非優先トラヒックが廃棄される閾値を下げる(廃棄されやすくする)ことができ、優先トラヒックの品質を高める動的QoS制御が可能になる。
なお、本明細書において、「パケット」と「フレーム」とは同じ意味を有するが、一般に、L2以下のレイヤでは「フレーム」と称し、L3以上のレイヤでは「パケット」と称するので、その呼び方に合わせて記載している。
次に、本発明の実施の形態について説明する。
図1は、本発明の実施の形態のネットワーク及びその周辺の構成を示すブロック図である。
本発明の実施の形態のネットワークは、インターネット1、ISP網2、アクセス網(IPv4網)3及びアクセス網(IPv6網)4によって構成されている。
ISP網2は、インターネット・サービス・プロバイダによって提供されるネットワークである。ISP網2は、IPv4プロトコルを用いてパケットを転送し、アクセス網3、4からのアクセスをインターネット1に中継する。
ISP網2は、インターネット・サービス・プロバイダによって提供されるネットワークであり、アクセス網3、4からのアクセスをインターネット1に中継する。
アクセス網3は、IPv4プロトコルを用いてパケットを転送するIPv4網で構成されており、ユーザ宅に設置された通信装置をISP網2に接続する。アクセス網4は、IPv6プロトコルを用いてパケットを転送するIPv6網で構成されており、ユーザ宅に設置された通信装置をISP網2に接続する。
IPv4網3は、LAC11及びLNS12を備える。LAC(L2TP Access Concentrator)11は、IPv4網3内に設けられたユーザ側のアクセスポイントである。LNS(L2TP Network Server)12は、IPv4網3内に設けられたISP網側のアクセスポイントである。
LAC11とLNS12との間は、VPN(Virtual Private Network)が設定されており、第2層トンネリングプロトコル(L2TP:Layer2 Tunneling Protocol)22によってフレームを転送する。
IPv4網3内では、L2TPによって、ユーザ宅からのPPP通信をトンネリングする。すなわち、ユーザ宅からの着信を受けたLACは、PPPのユーザー認証によって、代理的に正当なユーザであることを確認した後、LNS12との間でトンネルを生成する。LAC11とLNS12との間でトンネルが確立された後は、ISP網2の認証サーバ(例えば、RADIUSサーバ等)によって正式な認証がなされる。そして、ユーザ宅のPC18は、ISP網2内のサーバとPPPのネゴシエーションを行なった後に、インターネットに接続して通信をする。
ユーザ宅5内には端末アダプタ装置9が設置されている。端末アダプタ装置9は、コンピュータ18に接続されており、コンピュータ18からのインターネット1へのアクセスを中継する。なお、図示を省略するが、IPv4網3が光ネットワークである場合、ユーザ宅5には光終端装置(ONU:Optical Network Unit)が、端末アダプタ装置9とIPv4網3の間に設置される。
IPv4/v6網4は、SGW13、SIPサーバ14及びコンテンツ配信サーバ15を備える。
SGW(Security Gate Way)13は、ISP網2とIPv4/v6網4との間に設けられる、パケットにセキュリティを提供するルータである。また、ISP網とホームネットワークとの接点には、通信品質を保証するHGW(Home Gate Way)装置としてのQoS端末アダプタ装置(10A、10B)が設置されている。ユーザ宅内に設けられたPCは、QoS端末アダプタ装置(10A、10B)及びSGW13を経由して、インターネットに接続する。
SGW13とQoS端末アダプタ装置(10A、10B)は(網の接点では)IPv4パケットをIPv6にカプセル化して転送する。また、SGW13とQoS端末アダプタ装置(10A、10B)との間は、IPsec(Security Architecture for Internet Protocol)によって秘匿化した通信をし、ユーザ宅からの通信を転送する。
SIP(Session Initiation Protocol)サーバ14は、VoIP(Voice over Internet Protocol)技術を用いたIP電話の通話を制御するサーバである。この通話制御のため、SIP端末(IP電話機16、17)の位置情報を記憶するデータベースを有する。このデータベースには、URL、IPアドレス、待受ポート、SIP経路情報、ゲートウェイの場所及びプロキシの場所等が記憶される。VoIPサービスはPure−IPv4網、もしくはPure−IPv6網によって提供されるとする。
コンテンツ配信サーバ15は、ユーザ宅のSTB19、20に動画像データ等のストリーミングデータを供給する。ストリーミングデータを提供するIP放送サービスはPure−IPv6網によって提供されるとする。
この場合には、コンテンツ配信サーバ15から送信されるストリーミングデータはIPv6のマルチキャストによって送信される。
これらのインターネット接続、VoIP、IP放送の各サービスは同時に提供され、VoIPサービスを最優先としてネットワークシステムが協調して動作する必要がある。
ユーザ宅6内にはQoS端末アダプタ装置10Aが設置されている。QoS端末アダプタ装置10Aには、IP電話機16が接続されており、IP電話機16からのVoIPプロトコルによる通信を中継する。また、QoS端末アダプタ装置10Aには、STB(Set Top Box)19が接続されている。STB19は、テレビ等の映像表示装置が接続されており、コンテンツサーバ15から送信されるストリーミングデータを受信する。また、QoS端末アダプタ装置10Aは、コンピュータからのインターネット1へのアクセスを中継する。
なお、図示を省略するが、IPv4/v6網4が光ネットワークである場合、ユーザ宅6には光終端装置(ONU:Optical Network Unit)がQoS端末アダプタ装置10AとIPv4/6網4の間に設けられる。
同様に、ユーザ宅7内にはQoS端末アダプタ装置10Bが設置されている。QoS端末アダプタ装置10Bには、IP電話機17及びSTB20が接続されている。IPv4/v6網4が光ネットワークである場合、ユーザ宅7には光終端装置(ONU:Optical Network Unit)が設けられる。
IP電話機16、17から、VoIPプロトコルに従った接続要求(発呼)があると、SIPサーバ14は通信相手の位置情報をデータベースから取得する。そして、SIPサーバ14はIP電話機16、17と、通話開始のための信号手順を実行する(24)。着呼側IP電話機の呼び出しが完了すると、RTP(Real-time Transport Protocol)プロトコルにより、IP電話機16、17の間で直接パケットを転送する(25)。
図2は、本発明の実施の形態のQoS端末アダプタ装置10Aの構成を示すブロック図である。
QoS端末アダプタ装置10Aは、CPU26、L2スイッチ31、メモリ32及び表示装置33を備える。
CPU26は、演算処理を行うコアCPU27と、暗号化/復号化処理を行うCRYPRO ENGINE28と、LANに対するデータの転送を制御するLAN MAC29と、WANに対するデータの転送を制御するWAN MAC30とを備える。
CRYPRO ENGINE28は、暗号化演算及び復号化計算をハードウェアによって高速に実行する暗号化/復号化エンジンであり、ESP(Encapsulation Security Payload)等の計算負荷の重いIPsec処理に用いられる。
ここで、WANは、インターネットに対する接続回線であり、本実施の形態ではIPv4/v6網4である。また、LANは、ユーザ宅内に設けられるイーサネット(登録商標、以下同じ)等のネットワークである。
メモリ32は、CPU26の動作に必要なプログラム及びデータを記憶する。
L2スイッチ31は、LAN MAC29に接続されている。L2スイッチ31は、複数のポートが設けられており、各ポートには、コンピュータ18、セットトップボックス19及びIP電話機16が接続されており、LANに対して出力されるデータ又はLANから入力されるデータの経路を切り替える。なお、IP電話機16は、後述するQoS制御のために、予め定められたポートに接続される。
表示装置33は、CPU26に接続されている。表示装置33は、受信キューの状態や、転送されるデータの品質情報を報知する。
なお、QoS端末アダプタ装置10Bも、QoS端末アダプタ装置10Aと同じ構成を有し、同じ動作をする。
図3は、本発明の実施の形態のQoS端末アダプタ装置10Aの機能ブロック図である。なお、本図では、WAN側からLAN側へのデータの転送を示す。なお、同様に、LAN側からWAN側へもデータの転送することができる。
WAN MAC30は、WANからのフレームを受信し、受信したフレームをリングバッファ102にDMA転送する。
L(Layer)2のBH(Bottom Half)処理部101は、リングバッファ102、CXキュー111及び送信キュー114を備える。
リングバッファ102は、メモリ32に設けられており、WAN MAC30が受信したフレームを、受信キューに転送するまでの間、一時的に格納する。
受信キュー103は、メモリ32に設けられており、WAN(及び、LAN)から受信した全てのフレームが格納される。具体的には、受信キュー103に滞留しているフレームが予め定めた閾値(netdev_max_backlog)に満たなければ、ネットワークドライバがフレームをリングバッファ102から読み出して受信キュー103に格納する。
受信ソケットバッファ104は、受信キュー103に格納されたフレームのうち、自装置宛のパケットがコピーされる。
自宛処理部105は、受信ソケットバッファ104に格納されたパケットを順に取り出して、処理する。例えば、QoS端末アダプタ装置10Aが、SIP PROXY又はRTP PROXYとして機能する場合、受信したパケットに基づいて、新たなパケットを生成する。そして、生成されたパケットは、送信ソケットバッファ105に格納され、送信キュー114に格納される。
IPv4処理部(Pure-IPv4)107は、受信キュー103に格納されたフレームのうち、他装置宛のIPv4パケットが転送される。また、IPv4処理部107は、IPv4の処理(例えば、VoIPの音声データの転送処理)を実行し、処理が終了したパケットを送信キュー114に格納する。
IPv6前処理部108は、受信キュー103に格納されたフレームのうち、他装置宛のIPv6パケットが転送される。また、IPv6前処理部108は、転送されたIPv6パケットがIPsec処理すべきものかを判定する。
IPv6処理部(Pure-IPv6/Multicast)109は、IPsec処理が不要なIPv6パケットを処理し、処理が終了したパケットを送信キュー114に格納する。
ESP部110は、IPsec処理が必要なIPv6パケットを処理する。すなわち、WANから受信したパケットを復号化するためにCXキュー111に出力する。また、LAN側からWAN側へデータを転送する場合、LANから受信したパケットを暗号化するためにCXキュー111に出力する。
CXキュー111は、DMA転送によって、CRYPTO ENGINE28に送られるパケットを一時的に格納する。
CRYPTO ENGINE28は、WANから受信したIPsecパケットを復号化し、LANから受信したIPsecパケットを暗号化する。
タスクレットキュー112は、CRYPTO ENGINE28によって復号化されたパケットがDMA転送によって入力され、復号化されたパケットを一時的に格納する。
タスクレットキュー112に格納された復号化パケットは、IPsecトンネル転送のためにカプセル化されている。よって、IPsecトンネル処理部113は、このカプセル化されたパケットをデカプセル処理する。
また、LAN側からWAN側へデータを転送する場合、タスクレットキュー112に格納された暗号化パケットは、IPsecトンネル転送のためにカプセル化しなければならない。よって、IPsecトンネル処理部113は、この暗号化されたパケットをカプセル化する。
IPsecトンネル処理部113は、このカプセル化又はデカプセル化されたパケットを、送信キュー114に格納する。
送信キュー114は、QoS端末アダプタ装置10Aから送信される、フレームを一時的に格納する。
LAN MAC29は、送信キュー114に格納された送信待ちパケットをDMA転送によって読み出して、LANポート(又は、WANポート)へ出力する。
なお、図中、H/W、L2、L3、APLは処理のレイヤを示す。すなわち、H/Wは物理層、L2はデータリンク層、L3はネットワーク層、APLはアプリケーション層の処理であることを示す。
図4は、本発明の実施の形態のQoS端末アダプタ装置10AのWANからLANへパケットを転送する処理のフローチャートである。
まず、WAN MAC30が、WANから入力されたフレームを、リングバッファ102にDMA転送をする(S201)。
次に、受信キュー103に滞留しているパケット数と予め定めた閾値(netdev_max_backlog)とを比較する。その結果、受信キュー103の滞留パケット数が閾値以上であれば(閾値に等しければ)、受信キュー103にパケットを格納することができないので、パケットを破棄する(S204)。また、表示装置33に、受信キュー103の滞留パケット数が閾値以上であることを表示する。
一方、受信キュー103の滞留パケット数が閾値に満たなければ、L(Layer)2のBH(Bottom Half)処理部101のパケット処理プログラムであるネットワークデバイスドライバがリングバッファ102に格納されているパケットを受信キュー103に格納する(S203)。
その後、次に受信キュー103から取り出されるパケットの宛先が自装置か、他装置かを判定する(S205)。その結果、自装置宛のパケットであれば、自装置内で処理する必要があるので、受信キュー103からパケットを取り出して、パケットを受信ソケットバッファ104に格納する(S206)。
一方、他装置宛のパケットであれば、そのパケットはIPv4パケットであるか否かを判定する(S207)。
その結果、受信キュー103から取り出されるパケットがIPv4パケットであれば、パケットをIPv4処理部107に送り、IPv4の処理を実行する(S208)。その後、ステップS211に進み、LAN MAC29によってパケットをLANポートへ出力する。
一方、受信キュー103から取り出されるパケットがIPv4パケットでなければ、そのパケットをIPv6前処理部108に送る。
IPv6前処理部108では、入力されたパケットがIPsec処理すべきものか否かを判定する(S209)。
その結果、パケットがIPsec処理されるものでなければ、パケットをIPv6処理部109に送り、IPv6の処理を実行する(S210)。その後、ステップS211に進み、LAN MAC29によってパケットをLANポートへ出力する。
一方、パケットがIPsec処理されるものであれば、パケットを復号化するために、ESP部110へ送る。ESP部110は、復号化の対象となるパケットを、CXキュー111に出力する(S212)。
CXキュー111に格納されたパケットは、DMA転送によってCRYPTO ENGINE28に送られる。そして、CRYPTO ENGINE28で復号化された後、DMA転送によって、タスクレットキュー112に送られる(S214)。
タスクレットキュー112に格納された復号化されたパケットは、IPsecトンネル処理部113によって読み出される。IPsecトンネル処理部113では、カプセル化されたパケットをデカプセル処理する(S215)。
その後、ステップS211に進み、LAN MAC29によってパケットをLANポートへ出力する。すなわち、各種処理が終了したパケットを送信キュー114に格納する。LAN MAC29は送信キュー114に格納された送信パケットを順に読み出して、LANポートに出力する(S211)。
パケットをLANポートへ出力すると、ステップS201に戻り、次のパケットを処理する。
図5は、本発明の実施の形態のQoS端末アダプタ装置10AのLANからWANへパケットを転送する処理のフローチャートである。
まず、LAN MAC29が、LANから入力されたフレームを、リングバッファ102にDMA転送をする(S221)。
次に、受信キュー103に滞留しているパケット数と予め定めた閾値(netdev_max_backlog)とを比較する。その結果、受信キュー103の滞留パケット数が閾値以上であれば(閾値に等しければ)、受信キュー103にパケットを格納することができないので、パケットを破棄する(S204)。また、表示装置33に、受信キュー103の滞留パケット数が閾値以上であることを表示する。
一方、受信キュー103の滞留パケット数が閾値に満たなければ、L(Layer)2のBH(Bottom Half)処理部101のパケット処理プログラムであるネットワークデバイスドライバがリングバッファ102に格納されているパケットを受信キュー103に格納する(S223)。
その後、次に受信キュー103から取り出されるパケットの宛先が自装置か、他装置かを判定する(S225)。その結果、自装置宛のパケットであれば、自装置内で処理する必要があるので、受信キュー103からパケットを取り出して、パケットを受信ソケットバッファ104に格納する(S226)。
一方、他装置宛のパケットであれば、そのパケットはIPv4パケットであるか否かを判定する(S227)。
その結果、受信キュー103から取り出されるパケットがIPv4パケットであれば、パケットをIPv4処理部107に送り、IPv4の処理を実行する(S228)。その後、ステップS231に進み、WAN MAC30によってパケットをWANポートへ出力する。
一方、受信キュー103から取り出されるパケットがIPv4パケットでなければ、そのパケットをIPv6前処理部108に送る。
IPv6前処理部108では、入力されたパケットがIPsec処理すべきものか否かを判定する(S229)。
その結果、パケットがIPsec処理されるものでなければ、パケットをIPv6処理部109に送り、IPv6の処理を実行する(S230)。その後、ステップS231に進み、WAN MAC30によってパケットをWANポートへ出力する。
一方、パケットがIPsec処理されるものであれば、パケットを暗号化するために、ESP部110へ送る。ESP部110は、暗号化の対象となるパケットを、CXキュー111に出力する(S232)。
CXキュー111に格納されたパケットは、DMA転送によってCRYPTO ENGINE28に送られる。そして、CRYPTO ENGINE28で暗号化された後、DMA転送によって、タスクレットキュー112に送られる(S234)。
タスクレットキュー112に格納された暗号化されたパケットは、IPsecトンネル処理部113によって読み出される。IPsecトンネル処理部113では、パケットをカプセル化する処理を行う(S235)。
その後、ステップS231に進み、WAN MAC30によってパケットをWANポートへ出力する。すなわち、各種処理が終了したパケットを送信キュー114に格納する。WAN MAC30は送信キュー114に格納された送信パケットを順に読み出して、WANポートに出力する(S231)。
パケットをWANポートへ出力すると、ステップS221に戻り、次のパケットを処理する。
図6は、本発明の実施の形態の受信キュー103の説明図である。
受信キュー103には、受信したパケットが取り出される順に格納されている。
また、受信キュー103は、非優先パケット格納領域61と、優先パケット格納領域62とに区分されている。
また、受信キュー103に関して、以下のパラメータが設定されている。
優先対象しきい値(dl_qos)は、優先パケット格納領域62に格納されるパケットの優先度の最低値を規定する。すなわち、dl_qos以上の優先度が付されたパケットは、優先制御の対象となる。
非優先パケット廃棄閾値(dl_qos_low_threshold)は、非優先パケット格納領域61に格納できるパケットの最大値を規定する。なお、非優先パケット廃棄閾値を大きくすることによってスループットは向上するが、パケット転送の遅延時間が増加する。
優先パケットの廃棄閾値(dl_qos_high_threshold)は、優先パケット格納領域62に格納できるパケットの最大値を規定する。
キュー長閾値(netdev_max_backlog)は、受信キュー103に格納できるパケットの最大長を規定する。すなわち、この値を超える大きさのパケットは、受信キュー103に格納されず、破棄される。
次に、受信したパケットを受信キュー103に格納する処理を説明する。
本実施の形態では、8段階の優先度(0〜7)が設定されている。そして、優先パケットの下限値(dl_qos)は”4”に設定されている。すなわち、優先度0〜3のパケットは非優先パケット格納領域61に格納され、優先度4〜7のパケットは優先パケット格納領域62に格納される。
非優先パケット格納領域61及び優先パケット格納領域62は、各々別個に格納されるパケットの量が制限されている。すなわち、非優先パケット格納領域61には、所定の閾値(dl_qos_low_threshold)を超える量のパケットは格納できない。非優先パケット格納領域61に滞留しているパケット量がdl_qos_low_threshold以上であるとき、非優先パケット格納領域61に格納しようとしたパケットを破棄するtail drop動作をする。
同様に、優先パケット格納領域62には、所定の閾値(dl_qos_high_threshold)を超える量のパケットは格納できない。優先パケット格納領域62に滞留しているパケット量がdl_qos_high_threshold以上であるとき、優先パケット格納領域62に格納しようとしたパケットを破棄するtail drop動作をする。
また、受信キュー103全体としても格納されるパケットの量が制限されている。すなわち、受信キュー103には、所定の閾値(netdev_max_backlog)を超える量のパケットは格納できない。受信キュー103に滞留しているパケット量がnetdev_max_backlogであるとき、受信キュー103内の全てのパケットが処理されるまで、全ての受信したパケットを破棄するtail drop動作をする。
パケットを受信キュー103に格納する際は、格納しようとするパケットの優先度を判定する。そして、格納対象のパケットの優先度以上のパケットの最後の格納位置と、格納対象のパケットの優先度未満のパケットの最前の格納位置を特定する。
図6に示す状態では、優先度が”6”のパケット(63)を格納するので、格納対象のパケットの優先度以上のパケットの最後の格納位置として、優先度が”7”のパケットの末尾(66)が特定される。また、格納対象のパケットの優先度未満のパケットの最前の格納位置として、優先度が”5”のパケットの先頭(65)が特定される。
パケットの優先度は、VLANタグの優先度フィールドに設定された値(VLAN Priority)を用いるとよい。これによって、L2レベルで、WANを経由して転送されるVoIPパケットのVLANフレームの優先度を高く設定することによって、VoIPパケットのQoSを確保することができる。
また、VLAN IDによってパケットの優先度を定めてもよい。
また、QoSアダプタ装置10A内のパケットの優先度と、装置外のフレーム(パケット)の優先度とを異らせてもよい。例えば、QoSアダプタ装置10Aに優先度変換テーブルを設け、VLANタグに設定されている優先度を、装置内部で使用される内部優先度に変換した後に、内部優先度に従って、パケットを受信キュー103に格納する。
次に、上りパケットのQoS制御について説明する。
受信キュー103は、下りパケットと上りパケットの双方が格納されるリソースである。
下りパケットについては、WAN MAC30にて、IPsecトラヒック、IPv6マルチキャストトラヒック、IPv4/VoIPトラヒックを識別できる。また、前述したように、VLANタグの優先度フィールドに設定された値を用いることによって、フレームの優先度を判定できる。よって、WAN側からLAN側への転送に関しては、VoIPパケットを廃棄することなく転送することができる。しかし、VoIPは双方向のRTPパケットで転送されるので、下りVoIPパケットと同様に、上りVoIPパケットも優先的に転送する必要がある。しかし、L2/L3レベルでは、双方向のトラヒックを同一セッションに属するストリームとして認識していない。
ユーザ宅内のLANにはVLAN機能が実装されない場合が多いので、VLAN IDによる上りパケットの識別は困難である。よって、他の方法(例えば、MAC、IPヘッダ又は特殊イーサネットトレイラ等)で上りVoIPトラヒックを識別する必要がある。
すなわち、受信キュー103には、LAN側から受信したパケットが優先パケットとなるような優先度を設定し、該パケットが優先パケットとして取り扱われるようにする。
このため、L2スイッチ31は、パケットが入力されたポートを判定する。そして、特定のポートから入力されるパケットに対して情報を付加して、特定のポートから入力されたパケットに高い優先度を設定する。なお、ユーザはこの定められたポートには上りトラヒックを優先的に制御する端末(例えば、IP電話機)のみを接続しなければならない。
具体的には、L2スイッチは、特定の物理ポートから入力されるパケットに対して、特殊なイーサネットトレイラを付加する。そして、端末アダプタ装置がL2からL3にパケットを転送する際に、イーサネットドライバは、イーサネットトレイラが付加されているパケットを受信パケットに優先的に格納し、イーサネットトレイラが付加されていないパケットを優先的に廃棄する。
これによって、VoIPパケットのQoSを確保することができる。
図7は、本発明の実施の形態の端末アダプタ装置を経由する発信から切断までのシーケンス図である。
ユーザ宅A(userA@domain1)の端末(IP電話機16)が、ユーザ宅B(userB@domain2)の端末(IP電話機17)に対して接続要求をするとき、SIPサーバ14に対してセッション確立要求(INVITEメッセージ)301を送信する。INVITEメッセージ301には、リクエストの送信元(From)、リクエストの宛先(To)、リクエスト送信ホストのIPアドレス及びポート番号(Via)、呼ID(Call−ID)、シーケンス番号(Cseq)及びセッション記述フォーマット(SDP:Session Description Protocol)が含まれる。
発信側QoSアダプタ10Aは、INVITEメッセージ301を監視し、INVITEメッセージ301に含まれる情報を抽出する(301A)。
SIPサーバ14は、INVITEメッセージ301を受信すると、リクエストの宛先を特定し、該特定した宛先にINVITEメッセージ302を送信する。INVITEメッセージ302にも、リクエストの送信元(From)、リクエストの宛先(To)、リクエスト送信ホストのIPアドレス及びポート番号(Via)、呼ID(Call−ID)、シーケンス番号(Cseq)及びセッション記述フォーマット(SDP)が含まれる。
着信側QoSアダプタ10Bは、INVITEメッセージ302を監視し、INVITEメッセージ302に含まれる情報を抽出する(302A)。
また、SIPサーバ14は、INVITEメッセージ302を送信すると、発信側IP電話機16に暫定応答メッセージ(Trying)303を送信する。
着信側IP電話機17は、INVITEメッセージ302を受信すると、着信音を鳴動し、呼出中メッセージ(Ringing)304を送信する。SIPサーバ14は、Ringingメッセージ304を受信すると、発信側IP電話機16にRingingメッセージ305を送信する。
その後、着信側IP電話機17がオフフック(着信応答)すると、成功応答(OK)306を返信する。OKメッセージ306には、リクエストの送信元(From)、リクエストの宛先(To)、呼ID(Call−ID)、シーケンス番号(Cseq)及びリクエスト送信ホストのIPアドレス及びポート番号(Via)が含まれる。
SIPサーバ14は、OKメッセージ306を受信すると、発信側IP電話機16にOKメッセージ307を送信する。
発信側IP電話機16は、OKメッセージ307を受信すると、セッション確立確認通知(ACK)308を送信する。発信側IP電話機16は、ACK308を送信することによってセッション確立状態となる。
SIPサーバ14は、ACK308を受信すると、着信側IP電話機17にACK309を送信する。着信側IP電話機17は、ACK309を受信することによってセッション確立状態となる。
そして、発信側IP電話機16と着信側IP電話機17とは、RTPパケットによって音声データを伝送する。
QoSアダプタ10A、10BはINVITEメッセージ301、302において、リクエストの送信元及び宛先の情報を取得しているので、このセッションに関連するRTPパケットを識別することができる。また、リクエストの送信元及び/又は宛先に対応してRTPパケットの優先度を設定しておく。リクエストの送信元及び/又は宛先によって、RTPパケットの優先度を制御する。これによって、特定の者が関係するVoIPパケットのQoSを確保することができる。例えば、L3パケットのIPアドレスに基づいて同一セッションに属するRTPパケットを判定する。このようにすれば、上りVoIPトラフィックと下りVoIPトラフィックに同一のQoSポリシーを適用することができる。
発信側IP電話機16と着信側IP電話機17との間のRTPパケットの交換中に、発信側QoSアダプタ10Aは、受信キュー103の状態によって、発信側IP電話機16に送られるRTPパケット310のCEビットを設定し(310A)、着信側IP電話機16に送られるRTPパケット311のCEビットも同様に設定する(311A)。
同様に、着信側QoSアダプタ10Bは、受信キュー103の状態によって、着信側IP電話機17に送られるRTPパケット311のCEビットを設定し(311B)、発信側IP電話機17に送られるRTPパケット310のCEビットも同様に設定する(310B)。なお、具体的なCEビットのマーキングアルゴリズムについては後述する。 これによって、QoSアダプタ10A、10Bは、接続されているIP電話機に対し、受信キュー103の状態を通知することができる。
このRTPパケット310、311の交換中にRTCP(RTP Control Protocol)パケットが送信される。RTCPパケットには、RTCP−SR(RTCP Sender Report)と、RTCP−RR(RTCP Receiver Report)がある。RTCP−SRには、タイムスタンプと送信者からの統計情報(送信パケット数、送信バイト数)が含まれる。RTCP−RRには、受信者からの統計情報(パケット廃棄率、ジッタ等)が含まれる。
QoSアダプタ10A、10Bは、RTCP−RRを監視して、統計情報を取得する。具体的には、発信側QoSアダプタ10Aは、着信側IP電話機17から送信されたRTCP−RRパケット313から廃棄パケット数を取得する(313B)。また、着信側QoSアダプタ10Bは、発信側IP電話機16から送信されたRTCP−RRパケット315から廃棄パケット数を取得する(315B)。
通話が終了し、オンフックすると、発信側IP電話機16からセッション終了要求(BYE)316が送信される。なお、セッション終了要求は着信側IP電話機17から送信してもよい。
BYEメッセージ316には、リクエストの送信元(From)、リクエストの宛先(To)、シーケンス番号(Cseq)、呼ID(Call−ID)及びリクエスト送信ホストのIPアドレス及びポート番号(Via)が含まれる。
SIPサーバ14は、発信側IP電話機16からのBYEメッセージ316を受信すると、着信側IP電話機17にBYEメッセージ317を送信する。
着信側IP電話機17は、BYEメッセージ317を受信すると、SIPサーバ14に対してBYEメッセージ318を送信する。SIPサーバ14は、着信側IP電話機17からのBYEメッセージ317を受信すると、発信側IP電話機16にBYEメッセージ319を送信する。
発信側IP電話機16は、BYEメッセージ319を受信すると、成功応答(OK)320を返信する。SIPサーバ14は、発信側IP電話機16からのOKメッセージ320を受信すると、着信側IP電話機17にOKメッセージ321を送信する。
着信側IP電話機17は、OKメッセージ321を受信すると、SIPサーバ14に対してOKメッセージ322を送信する。SIPサーバ14は、着信側IP電話機17からのOKメッセージ322を受信すると、発信側IP電話機16にOKメッセージ323を送信する。
このOKメッセージの交換によって、通話が切断される。
次に、ECN(=CEビットマーキング)機能を利用したQoS制御について説明する。
受信キュー103に滞留している優先パケット数がdl_qos_high_threshold以上になった場合には、受信キュー103では、キューに滞留しているパケットの種類を判定し、キューに滞留している優先パケットであるRTPパケットに対して、当該パケットのECNフィールドのCEビットを”1”に設定する。これによって、端末アダプタ装置から見て下り方向の端末に対しては、自分を収容する端末アダプタ装置が輻輳状態になる可能性があること、上り方向の端末アダプタ装置又は端末に対しては、対向する端末アダプタ装置が輻輳状態になる可能性があることをリアルタイムで通知する。なお、RTP端末は、CEビットマーキングされたパケットに関しては実際に廃棄されたパケットではないために、通常は、RTCP−RR信号のペイロード部に記述する瞬時廃棄率及び累積廃棄パケット数には反映しない。
輻輳状態を示すCEビットマーキングを端末アダプタ装置が行なうことで、端末は途中経路の端末アダプタ装置で輻輳が発生する可能性があることを知ることができ、IP電話機から送信されるRTCP−RR信号を端末アダプタ装置が監視(snoop)することで実際に端末が受信したパケット数、実際に端末で廃棄したパケット数等のエンドツーエンドの下り品質情報を途中経路の端末アダプタ装置が把握できる。なお、CEビットマーキングされたパケット数等のRCTPプロトコルでは規定されていない情報はRTCPプロトコルでは交換されないが、端末及び端末アダプタ装置はこれらの情報を把握することが可能なので、ECN情報を交換するためにRTCPプロトコルを拡張する必要はない。 RTCPの規定によれば、RTPパケット送信端末は、RTPパケットの通信品質情報を通知するために、RTPパケットを受信する端末に対して送信側の通信品質情報を含むRTCP−SRパケットを送信する。RTCP−SRパケットを受信した端末は、その返答としてRTCP−RRパケットを送信する。
RTCPはエンドツーエンドの通信品質通知プロトコルであるため、下りトラヒック通信品質を下流側の端末及び端末アダプタ装置のみならず、上流側の端末アダプタ装置及び端末で監視することができる。すなわち、RTCPプロトコルの持つping-pongプロトコル規定によって、RTCP−SR信号を受信した端末は即座にRTCP−RR信号を送信する。またVoIPでは双方の端末がRTPパケットを送信するので、結果として端末は上り下り双方向の通信品質をモニタすることができる。さらに端末アダプタ装置が双方向のRTCP―SR、RTCP−RRパケットを監視(snoop)することで端末と同様な通信品質チェックが可能となる。
例えば、ユーザAを収容するQoSアダプタ装置が、RTCP−SRパケットを312Aで、RTCP−RRパケットを313Aで監視することによって、ユーザAからユーザBへのRTPパケットの通信品質をモニタすることができる。モニタ結果として通信品質の劣化が認められる場合には、非優先パケットの廃棄を促進するために非優先パケットに対する廃棄閾値を自律的に下げるなどの動的QoS制御を行うことができる。
さらに、もうひとつのQoS制御例について説明する。前述したような端末アダプタ装置による動的QoS制御ではなく、端末アダプタ装置にLED/LCD等の表示手段を設ける。端末アダプタ装置は、LED/LCD等に通信品質情報を色、又は文字で表示する。ユーザは、表示された品質情報に基づいて、自らが非優先パケットの送受信を控える(例えば、IPv6マルチキャストによるIP放送を一時中断する)。これによって優先パケットの送受信品質を向上させるといった、手動QoS制御を行うことが可能になる。
このように端末アダプタ装置側で通信品質情報を可視化するメリットは、ユーザ主導のQoS制御によって、より確実なQoS制御を行うことができる点にある。また、動的QoS制御、ユーザによる手動QoS制御を問わず、ユーザBを収容する端末アダプタ装置についても同様の制御を同時に行うことで、片方向のQoS制御のみならず、双方向のQoS制御が可能になる。よって、VoIPのような双方向メディアにとって発着双方の端末アダプタ装置でQoS制御を行うことが望ましい。
以上説明したように、本発明の実施の形態によると、優先廃棄・優先転送に基づく、インターネットにおけるQoS保証を行うことができる。これによって、QoS端末アダプタ装置が、WEBブラウジング、FTPダウンロード等のデータ通信を中継しながら、VoIP等の最優先トラヒックデータのパケットを損失することない。すなわち、VoIPパケットを、IP電話端末に優先的に転送することができる。よって、電話と同等の品質レベルを有するリアルタイム通信を提供することができる。
また、LANからWANへのVoIPトラヒックは、常に最優先のQoS制御を行うので、電話と同等の品質レベルを有するリアルタイム通信を提供することができる。
また、L2スイッチがLANからWANへの優先パケットを識別するので、上りトラフックのQoS制御も実現することができる。
また、優先パケットの最大滞留閾値と、非優先パケットの最大滞留閾値とを別に定め、優先パケット及び非優先パケットが各々の閾値以上滞留した場合には、パケットを破棄するので、優先パケットと非優先パケットとを別個にQoS制御することができる。
また、キューに滞留している下りRTP/IPパケットのIPヘッダの中にあるECNフォールドのCEビットを”1”に設定するので、端末アダプタ装置の受信キューが輻輳状態にあり、優先パケットが廃棄される可能性があることを、LAN端末に通知することができる。
また、端末アダプタ装置は、RTCPパケットを監視(snoop)するので、RTCPパケットに含まれるネットワークの品質特性の情報を把握することができる。
本発明は、リアルタイム通信と非リアルタイム通信が混在している場合にリアルタイム通信のQoSを制御するネットワーク機器に適用することができる。特に、ユーザ宅内に設置され、光ネットワークに接続され、VoIPデータを転送するルータに適用すると好適である。
本発明の実施の形態のネットワーク及びその周辺の構成を示すブロック図である。 本発明の実施の形態のQoS端末アダプタ装置のブロック図である。 本発明の実施の形態のQoS端末アダプタ装置の機能ブロック図である。 本発明の実施の形態のQoS端末アダプタ装置のWANからLANへパケットを転送する処理のフローチャートである。 本発明の実施の形態のQoS端末アダプタ装置のLANからWANへパケットを転送する処理のフローチャートである。。 本発明の実施の形態の受信キューの説明図である。 本発明の実施の形態の端末アダプタ装置を経由する発信から切断までのシーケンス図である。
符号の説明
1 インターネット
2 ISP網
3 IPv4網
4 IPv4/IPv6網
10A、10B QoS端末アダプタ
16、17 IP電話機
103 受信キュー

Claims (7)

  1. ネットワークに接続され、フレームを送受信する送受信部と、
    各種処理を行う制御部と、
    前記制御部が使用するデータが格納された記憶部と、を備え、
    前記記憶部には、受信したデータフレームが格納される受信キューが設けられ、
    前記制御部は、
    前記受信したデータフレームの優先度を判定し、前記判定された優先度の順に前記受信データフレームを受信キューに格納し、
    前記キューに格納されたデータフレームを、当該データフレームに付与された優先度順に取り出して転送する端末アダプタ装置。
  2. 前記端末アダプタ装置は、第1のネットワーク端子と第2のネットワーク端子とを備え、
    前記制御部は、
    前記第1のネットワーク端子から入力されるデータフレームに設定された優先度を判定し、
    前記第2のネットワーク端子から入力されるデータフレームは、あらかじめ定めた優先度であると判定し、
    前記判定された優先度の順に前記データフレームを前記受信キューに格納する請求項1記載の端末アダプタ装置。
  3. 前記端末アダプタ装置は、第1のネットワーク端子と複数の第2のネットワーク端子とを備え、
    前記制御部は、
    前記第1のネットワーク端子から入力されるデータフレームに設定された優先度を判定し、
    前記第2のネットワーク端子のうち特定の第2のネットワーク端子から入力されるデータフレームは、あらかじめ定めた優先度であると判定し、
    前記判定された優先度の順に前記データフレームを前記受信キューに格納する請求項1記載の端末アダプタ装置。
  4. 前記制御部は、
    入力されるデータフレームを前記受信キューに格納する際に、
    非優先データフレームが第1の閾値以上前記受信キューに滞留している場合、前記受信した前記非優先データフレームを廃棄し、
    優先データフレームが第2の閾値以上前記受信キューに滞留している場合、前記受信した優先データフレームを廃棄する請求項1記載の端末アダプタ装置。
  5. 前記制御部は、優先データフレームが第2の閾値以上前記受信キューに滞留している場合、前記受信キューに滞留している優先データフレームに、輻輳状態を示す情報を付加して、データフレームを転送する請求項1に記載の端末アダプタ装置。
  6. 前記制御部は、優先データフレームを送受信する端末から送信された制御信号に含まれる品質情報を取得し、
    前記取得した品質情報を表示する表示部を備える請求項1に記載の端末アダプタ装置。
  7. 前記制御部は、優先データフレームを送受信する端末から送信された制御信号に含まれる品質情報を取得し、前記取得した品質情報に基づいて非優先データフレームを優先的に廃棄する請求項4に記載の端末アダプタ装置。
JP2005074628A 2005-03-16 2005-03-16 端末アダプタ装置 Expired - Fee Related JP4649242B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005074628A JP4649242B2 (ja) 2005-03-16 2005-03-16 端末アダプタ装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005074628A JP4649242B2 (ja) 2005-03-16 2005-03-16 端末アダプタ装置

Publications (2)

Publication Number Publication Date
JP2006261897A true JP2006261897A (ja) 2006-09-28
JP4649242B2 JP4649242B2 (ja) 2011-03-09

Family

ID=37100666

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005074628A Expired - Fee Related JP4649242B2 (ja) 2005-03-16 2005-03-16 端末アダプタ装置

Country Status (1)

Country Link
JP (1) JP4649242B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2229023A1 (en) 2009-03-11 2010-09-15 Fujitsu Limited Communication apparatus
JPWO2009093473A1 (ja) * 2008-01-25 2011-05-26 パナソニック株式会社 中継装置、端末、優先通信制御方法、プログラム及び記録媒体

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61152151A (ja) * 1984-12-26 1986-07-10 Nec Corp 過負荷制御方式
JPH07325779A (ja) * 1994-06-01 1995-12-12 Fuji Xerox Co Ltd 入出力制御装置
JPH11239159A (ja) * 1994-07-21 1999-08-31 Fujitsu Ltd Atm交換機
JP2000183965A (ja) * 1998-12-15 2000-06-30 Toshiba Corp パケットスイッチ及びパケット交換方法
JP2001510302A (ja) * 1997-07-11 2001-07-31 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) Atmトラヒック用のデータ・シェーパ
JP2002190826A (ja) * 2000-12-22 2002-07-05 Nippon Telegr & Teleph Corp <Ntt> パケット転送方法及びネットワークシステム
JP2002354000A (ja) * 2001-05-25 2002-12-06 Mitsubishi Electric Corp ブリッジ装置
JP2002354046A (ja) * 2001-05-23 2002-12-06 Hitachi Ltd パケット中継装置バッファ管理方法
JP2003152752A (ja) * 2001-08-29 2003-05-23 Matsushita Electric Ind Co Ltd データ送受信方法
JP2003179636A (ja) * 2001-12-12 2003-06-27 Fujitsu Ltd VoIPネットワークの輻輳制御システム
JP2003324442A (ja) * 2002-04-26 2003-11-14 Matsushita Electric Ind Co Ltd 無線ネットワークで効率的なバッファ機構を用いることにより媒体アクセスを高速化する方法
JP2004023609A (ja) * 2002-06-19 2004-01-22 Nippon Telegr & Teleph Corp <Ntt> セルスケジューリング方法
WO2004066570A1 (ja) * 2003-01-17 2004-08-05 Fujitsu Limited ネットワークスイッチ装置およびネットワークスイッチ方法
JP2004236316A (ja) * 2003-01-27 2004-08-19 Microsoft Corp 帯域制御プログラム、方法およびエンド・システム

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61152151A (ja) * 1984-12-26 1986-07-10 Nec Corp 過負荷制御方式
JPH07325779A (ja) * 1994-06-01 1995-12-12 Fuji Xerox Co Ltd 入出力制御装置
JPH11239159A (ja) * 1994-07-21 1999-08-31 Fujitsu Ltd Atm交換機
JP2001510302A (ja) * 1997-07-11 2001-07-31 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) Atmトラヒック用のデータ・シェーパ
JP2000183965A (ja) * 1998-12-15 2000-06-30 Toshiba Corp パケットスイッチ及びパケット交換方法
JP2002190826A (ja) * 2000-12-22 2002-07-05 Nippon Telegr & Teleph Corp <Ntt> パケット転送方法及びネットワークシステム
JP2002354046A (ja) * 2001-05-23 2002-12-06 Hitachi Ltd パケット中継装置バッファ管理方法
JP2002354000A (ja) * 2001-05-25 2002-12-06 Mitsubishi Electric Corp ブリッジ装置
JP2003152752A (ja) * 2001-08-29 2003-05-23 Matsushita Electric Ind Co Ltd データ送受信方法
JP2003179636A (ja) * 2001-12-12 2003-06-27 Fujitsu Ltd VoIPネットワークの輻輳制御システム
JP2003324442A (ja) * 2002-04-26 2003-11-14 Matsushita Electric Ind Co Ltd 無線ネットワークで効率的なバッファ機構を用いることにより媒体アクセスを高速化する方法
JP2004023609A (ja) * 2002-06-19 2004-01-22 Nippon Telegr & Teleph Corp <Ntt> セルスケジューリング方法
WO2004066570A1 (ja) * 2003-01-17 2004-08-05 Fujitsu Limited ネットワークスイッチ装置およびネットワークスイッチ方法
JP2004236316A (ja) * 2003-01-27 2004-08-19 Microsoft Corp 帯域制御プログラム、方法およびエンド・システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2009093473A1 (ja) * 2008-01-25 2011-05-26 パナソニック株式会社 中継装置、端末、優先通信制御方法、プログラム及び記録媒体
EP2229023A1 (en) 2009-03-11 2010-09-15 Fujitsu Limited Communication apparatus
US8463278B2 (en) 2009-03-11 2013-06-11 Fujitsu Limited Communication apparatus and communication method

Also Published As

Publication number Publication date
JP4649242B2 (ja) 2011-03-09

Similar Documents

Publication Publication Date Title
CN109194660B (zh) 移动终端的入网方法和装置
JP4669536B2 (ja) 送信方法、トンネル終端装置、コンピュータプログラム
JP3737668B2 (ja) パケットサーバにおける呼設立方法
Black et al. Differentiated services (DiffServ) and real-time communication
US11159423B2 (en) Techniques for efficient multipath transmission
US10911413B2 (en) Encapsulating and tunneling WebRTC traffic
JP4216284B2 (ja) 802.11無線LANを通じたVoIPへのQoSを提供するための方法及び装置
US8284779B2 (en) Communication apparatus
JP2009544227A (ja) ケーブルアクセスで利用するQoSを備えたコンボフォン
AU2005239680A1 (en) VOIP (voice over internet protocol) call processing
JP4649242B2 (ja) 端末アダプタ装置
JP2005191763A (ja) 通信中継方法および中継装置
JP4201790B2 (ja) 効率的な帯域幅使用のための暗号化が適用されたパケット通信網での音声データ処理方法及びその装置
JP2008288763A (ja) エッジルータ装置およびセッション確立方法
JP6526084B2 (ja) 情報処理装置、情報処理方法、及びプログラム
JP5127729B2 (ja) パケット中継方法及びゲートウェイ装置
JP5025449B2 (ja) 中継通信システム
US20090052458A1 (en) Flow state attributes for producing media flow statistics at a network node
JP4275265B2 (ja) 呼制御サーバおよび音声データ通信方法
JP4722563B2 (ja) 通信端末装置、端末装置、通信システム及び通信方法並びにコンピュータプログラム
JP2005123985A (ja) 通信装置及び通信方法
JPH11331257A (ja) 異ネットワーク間接続方法およびルータ装置
JP4220802B2 (ja) IPv6通信におけるパケット送信方法およびIPv6通信のパケット分割を可能としたルータ
Le Faucheur et al. Resource reservation protocol (RSVP) proxy approaches
JP2008067149A (ja) ネットワークインターフェース装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071026

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20100119

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100223

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100302

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100428

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100713

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100819

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

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

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

Free format text: PAYMENT UNTIL: 20131217

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees