JP3950907B2 - 通信システムおよび通信方法 - Google Patents

通信システムおよび通信方法 Download PDF

Info

Publication number
JP3950907B2
JP3950907B2 JP2006168257A JP2006168257A JP3950907B2 JP 3950907 B2 JP3950907 B2 JP 3950907B2 JP 2006168257 A JP2006168257 A JP 2006168257A JP 2006168257 A JP2006168257 A JP 2006168257A JP 3950907 B2 JP3950907 B2 JP 3950907B2
Authority
JP
Japan
Prior art keywords
data
priority
processing
transmission
protocol
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 - Lifetime
Application number
JP2006168257A
Other languages
English (en)
Other versions
JP2006304349A (ja
Inventor
民生 飯塚
恒一郎 桜庭
弘司 鴨志田
芳昭 足達
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Hitachi Information and Control Solutions Ltd
Original Assignee
Hitachi Ltd
Hitachi Information and Control Solutions 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 Ltd, Hitachi Information and Control Solutions Ltd filed Critical Hitachi Ltd
Priority to JP2006168257A priority Critical patent/JP3950907B2/ja
Publication of JP2006304349A publication Critical patent/JP2006304349A/ja
Application granted granted Critical
Publication of JP3950907B2 publication Critical patent/JP3950907B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、通信システム及び通信方法に関する。具体的には、特に音声,画像データなどのマルチメディア用データ及び緊急を要するプラント用データなどの遅延の許されない通信に好適なリアルタイム性が要求されるデータとその他の遅延がある程度許されるデータが混在する通信システム及び通信方法に関する。
DARPA(Defence Advanced Research Project Agency)プロトコルのTCP
(Transmission Control Protocal)/IP(Internet Protocol)やISO(InternationalStandards Organization) のOSI(Open Systems Interconnecttion) プロトコルのようなプロトコルを使用した通信システムにおいて、通信の遅延が許されるデータと遅延の許されないデータ(マルチメディア,プラントデータのようなリアルタイム性が要求されるデータ)を共存させてもリアルタイム性を保持した通信を実現できる通信システムの構築がエンドユーザから求められている。この種の方式として、例えば、特開平4−180425 号公報に記載のように、受信データ処理の順序を通信相手端末のネットワークアドレスと通信相手プロセスに対応付けた情報に従い優先制御する方式がある。また、例えば特開昭63−287231号公報に記載のように、網間中継装置において受信したデータのデータ長に注目し優先的に処理するデータか否かを判定する方式がある。
従来の通信システムの優先制御は、同じプロトコルを使用する各アプリケーションの通信プログラムごとに優先制御を行うこと、あるいは同じ通信プログラムであっても通信相手により優先制御を行うことに配慮されていない。
また、従来の通信システムの優先制御は、アプリケーションの通信プログラムで扱うデータごとにリアルタイム性に応じた優先処理レベルを設定する点に配慮されていない。
さらに、従来、システムを設計,構築する上で使い勝手が悪いという課題があった。
さらに従来、通信する端末の間に網間中継装置で接続され複数のネットワークから構成されるような通信システムにおける優先制御に配慮がなされていない。
さらに、従来の通信システムの優先制御は、優先データが連続した場合、非優先データの送信又は受信処理が中断されるため、データ送信端末で送信タイムアウトとなり再送が頻発することによる通信網の輻輳状態の防止、あるいは論理回線の切断等の防止に配慮がなされていない。
本発明の目的は、アプリケーションの通信プログラムが扱うデータごとに通信上の制限を設けることなく優先制御を実現しようとするものである。
また、本発明の目的は、網間中継装置を含む通信システムにおいて優先制御を実現しようとするものである。
また、本発明の目的は、高優先データの処理が連続して発生しても、低優先データに飢餓状態を発生させず、通信網の輻輳防止,論理回線の切断防止を実現しようとするものである。
上記目的を達成するための本発明の特徴は、通信システムにおいて、送信又は受信データ内の優先判定情報と予め登録された優先データ情報からデータの送信又は受信処理の順序をデータごとに決定することである。すなわち、具体的には、プロトコルにより規定された端末アドレスが割り当てられている複数の端末装置が通信網によって接続され、前記各端末装置間でプロトコル情報が格納されたデータを送信又は受信する通信システムにおいて、優先的に送信又は受信処理をするか否かを判定する優先判定情報を送信又は受信データ内のあるプロトコルヘッダ情報とする手段と、前記優先判定情報のうち優先的に送信又は受信するデータの優先判定情報を予め優先データ情報として登録する登録手段と、前記送信又は受信データから優先判定情報を取り出し、優先データ情報として登録されているデータか判定する判定手段と、優先データ情報として登録されているデータの場合、登録されていないデータよりも優先的にデータを送信又は受信処理する送信又は受信処理手段と、を設けたことである。
つまり、本発明は、マルチメディア,プラントデータのようなリアルタイム性が要求されるデータとある程度の遅延が許されるデータが混在した通信システムにおいて、送信又は受信データ内の優先判定情報と予め登録された優先データ情報からデータの送信又は受信処理の順序をデータごとに決定する。それによって、アプリケーションの通信プログラムが扱うデータごとに通信上の制限を設けることなく優先制御できる。
また、上記目的を達成するための本発明の特徴は、複数の通信網が接続されるような通信システムにおいて、送信又は受信されるデータを、送信先又は送信元の通信網の一方の通信網の伝送データサイズに分割して、データ分割識別子を付け、そのデータ分割識別子と優先度を対応付け、分割データの送信時又は受信時、そのデータの分割識別子に対応する優先度に基づいて優先制御することである。すなわち、具体的には、プロトコルにより規定された端末アドレスが割り当てられている複数の端末装置が通信網によって接続され
、前記各端末装置間でプロトコル情報が格納されたデータを送信又は受信する通信システムにおいて、送信データを分割する送信データ分割手段と、データを受信時、分割された前記送信データ内のプロトコルヘッダの優先判定情報から優先データか非優先データかを判定する優先判定手段と、受信データのヘッダ内のデータ分割識別子と優先か否かを対応付けた表を記憶する表記憶手段と、分割された前記送信データを受信時、そのデータ分割識別子が優先か否かを前記表から判定する表判定手段と、表判定手段における判定結果に従い、送信又は受信処理の優先制御を行う手段とを設けたことである。
つまり、本発明は、データの送信処理で決定した優先処理順序をデータ内のプロトコルヘッダの優先度情報に格納しその情報に従い送信・受信の優先制御を行う。また、分割したデータのデータ送信時又はデータ受信時データ内のプロトコルヘッダの優先判定情報から優先度を決定し、そのデータのデータ分割識別子と対応付けた表を持ち、分割されたデータの受信時そのデータの識別子に対応する優先度を表から求め優先制御する。それによって、データ内のプロトコルヘッダにサービス識別子を持たないデータに対しても優先制御でき、複数の通信網間を接続する網間中継装置,端末へ適用できる。
さらに、上記目的を達成するための本発明の特徴は、優先処理するデータがある回数連続して発生したとき、あるいは低優先のデータが発生してからある時間経過しても処理されない場合、高優先のデータ処理に影響を与えない程度により低優先のデータを処理することである。すなわち、具体的には、優先処理するデータを連続して送信・受信処理できる上限回数を登録する手段と、非優先処理するデータの送信・受信処理要求が発生してから優先処理するデータを連続して送信,受信処理した回数を積算する積算手段と、優先処理するデータの送信あるいは受信処理において、前記積算手段により積算された回数が上記登録された上限回数以上か否かを判定する手段と、上限回数以上の場合、非優先処理待ちデータを登録されたデータ数分優先的に送信又は受信処理手段とを設けたことである。又、上限回数の代わりに、送信又は受信処理するデータがシステム内に残留できる上限時間を用いてもよく、又、送信又は受信処理するデータがシステム内に残留できる上限時間を各優先処理レベルごとに登録するレベル別上限時間を用いてもよい。
つまり、本発明は、優先処理するデータがある回数連続して発生した場合、あるいは低優先のデータが発生してからある時間経過しても処理されない場合、高優先のデータ処理に影響を与えない程度に、より低優先のデータを処理する。それによって、高優先データが連続して発生した場合においても低優先データの送信又は受信処理が完全に中断しないようになるので、不必要な再送処理による通信網の輻輳状態,論理回線の切断を回避することができる。
上記した本発明の特徴および上記した以外の本発明の特徴は、以下の記載により、さらに明確とされる。
本発明によれば、アプリケーションの通信プログラムが扱うデータごとに通信上の制限を設けることなく優先制御を実現できる。
また、本発明によれば、網間中継装置を含む通信システムにおいて優先制御を実現できる。
また、本発明によれば、高優先データの処理が連続し発生しても、低優先データに飢餓状態を発生させず、通信網の輻輳防止,論理回線の切断防止を実現できる。
以下、本発明の一実施例を図を用いて詳細に説明する。
<システムの全体構成>
初めに、本発明が対象とする通信システムの全体構成を図2に示す。複数の端末200〜206が標準的なLAN,WAN等の通信網211〜214に接続され、各通信網211〜214が網間中継装置207〜210によって接続されている。そして、各端末,網間中継装置には、世界標準あるいは業界標準の通信プロトコルが実装され、プロトコルにより規定されたネットワークアドレスが割り当てられる。各端末には、通信プログラムが搭載され、各端末間でデータを送受信しながらシステム全体の業務処理を進める。通信プログラムからのデータ送信要求,通信網からのデータ受信は、端末に実装されている通信プロトコルを介しそれぞれ通信網へ送信,通信プログラムへ渡される。ある端末の通信プログラムから通信相手の端末へデータを送信すると、複数の通信網を網間中継装置により中継され通信相手の端末へ届く。
データをどの端末へ届けるかは、OSI参照モデルで対応付けるとネットワーク層プロトコルで規定されるネットワークアドレスで決定され、宛先端末上でどのプロセスへデータを届けるかは、OSI参照モデルで対応付けるとトランスポート層プロトコルで規定される宛先サービス識別子で決定される。
以下、実施例では、通信プロトコルとしてDARPAプロトコルのTCP,UDP,
IPを使用する通信システムを例に説明する。DARPAプロトコルのTCP/IPでは
、ネットワークアドレスがインターネットアドレス,サービス識別子がポート番号になる
。各端末の通信プログラムは、他端末の通信プログラムとデータ通信する場合、コネクション型かデータグラム型のいずれかの通信方法を用い、通信相手端末のインターネットアドレスと宛先ポート番号を明示し、通信相手の端末,通信プログラムと論理的に結合する
。相手通信プログラムは、送信元インターネットアドレスと送信元ポート番号により応答を返す先の端末,通信プログラムを識別する。通常、コネクション型の通信であればコネクション確立時に、送信元インターネットアドレス,宛先インターネットアドレス,送信元ポート番号,宛先ポート番号が決定される。データグラム型の通信時は、データ単位に決定する。
〔実施例1〕
<構成>
以下、第1の実施例について説明する。
本発明の通信システムの優先通信制御方式の構成を図1に示す。通信システム内の各端末140等、通信システム内の業務処理を行う通信プログラム処理部120,プロトコル送信処理部141,プロトコル受信処理部143,通信装置111を介し通信網へのデータ送信処理部126,通信網からのデータ受信処理部(データ受信手段とも称す)130
,送受信データの処理待ちキュー制御部142,144を有する。プロトコル送信処理部141は、TCP/IPプロトコル送信処理部121〜122から成り、プロトコル受信処理部143は、TCP/IPプロトコル受信処理部134〜135から成る。送受信データの処理待ちキュー制御部142,144は、データを優先的に処理するか否かを決定するデータの優先判定手段123,131と、送受信処理待ちキュー127,136へ接続する手段124,132と、送受信処理待ちキュー124,132からデータを取り出す手段125,133から成る。更に、補助記憶装置100に優先データ情報を記憶する優先データ情報登録ファイル101が設けられ、主記憶上に優先データ情報登録メモリ
102,送信・受信処理上限登録ファイル103を配置し優先的に送受信するデータの優先データ情報をデータの優先判定手段123,131に知らせる。
優先データ情報登録ファイル101に登録された優先データは、データ内に格納される通信プロトコル情報のプロトコル種別,TCPヘッダ内の宛先および送信元ポート番号,IPヘッダ内の宛先および送信元ネットワークアドレスから成り、送受信データを優先的に送受信処理するか否かの判定に使用する優先判定情報となる。優先データ情報登録ファイル101は、通信システムの構築時に設定され、システム立ち上げ時に主記憶上の優先データ情報登録メモリ102に記憶,管理される。補助記憶装置100の優先データ情報を全ての端末、および網間中継装置に格納する必要はなく、優先データ情報管理サーバ端末がシステム内に存在し、その他の端末,網間中継装置は、立ち上げ時通信要求を発行し自装置内の優先データ情報登録メモリ102に取り込んでもよい。また、この優先データ情報は、静的に割り付けても、動的に追加,変更,削除等の操作を行っても構わない。
網間中継装置は、端末の上記構成と比較すると通信プログラム処理部120やTCPプロトコル送受信処理部121,135を搭載していない装置もあるが通常上記端末140と同じような構成になる。ただし、網間中継装置は、二つ以上の通信網へ二つ以上の通信装置により接続され、それぞれの通信網から受信したデータを別の通信網へ送信し中継する機能を備えている。
通信システムへの外部からの入力は、通信ネットワーク(通信網とも称す)110上の所定の端末より行われ、通信装置111,データ受信手段130,受信データの優先判定手段131,受信データの接続手段132,136,受信データの取り出し手段133,IPプロトコルの受信処理部134,TCPプロトコルの受信処理部135,通信プログラム処理部120の順で伝達され処理が行われる。
処理結果の通信システムの外部への出力は、通信プログラム処理部120,TCPプロトコルの送信処理部121,IPプロトコルの送信処理部122,送信データの優先判定手段123,送信データの接続手段124,送信処理待ちキュー127,送信データの取り出し手段125,データ送信手段126,通信装置111の順で伝達され処理が行われ
、通信ネットワーク110上の所定の端末上へ出力される。
システム内のいずれかの端末の通信プログラムがデータ出力し、通信網を流れ宛先端末の上記入力時の処理手順で、受信側通信プログラムに、データが届けられる。ただし、網間中継装置が介在する場合は、通信ネットワーク110上の所定の端末より入力が行われ
、通信装置111,データ受信手段130,受信データの優先判定手段131,受信データの接続手段132,136,受信データの取り出し手段133,IPプロトコルの受信処理部134,IPプロトコルの送信処理部122,送信データの優先判定手段123,送信データの接続手段124,送信処理待ちキュー127,送信データの取り出し手段
125,データ送信手段126,通信装置111の順で伝達され処理が行われ、通信ネットワーク110上の所定の端末上へ出力される。
<送信処理>
図1を用いて、通信プログラムから通信網へデータ送信するまでの処理を示す。通信プログラム処理部120から送信されたデータは、プロトコル送信処理部141のTCPプロトコル処理部121でTCPヘッダを付加し、次にIPプロトコル送信処理部122でIPヘッダが付加される。そして、送信データの優先判定手段123にてデータ内のプロトコルヘッダ内の情報をチェックし優先送信するか非優先送信かを判定し、送信処理待ちキュー127の優先データ処理待ちキューか非優先データ処理待ちキューのいずれかに送信データの接続手段124にて接続する。送信データの接続手段124にて、送信処理待ちキュー127に一つもデータが接続されていない場合、かつデータ送信手段126にて通信装置111へデータの送信要求を発行していない場合は、送信処理待ちキュー127にデータを接続せずに直接データ送信手段126へデータを渡す。データ送信手段126で送信データにデータリンク層ヘッダ(LANへの送信時はMACヘッダ)を付加し、通信装置111を送信起動し通信網110へデータ送信する。
データ送信手段126にて通信装置111へデータを送信要求を発行し、かつ送信処理待ちキュー127に一つもデータが接続されていない場合、あるいはデータ送信手段126にて通信装置111へデータを送信要求を発行し、かつ送信処理待ちキュー127にデータが接続されている場合は、送信処理待ちキュー127にデータを接続する。このキューに接続されたデータは、データ送信手段126が現在通信装置111へ送信要求している処理が終了し、通信装置111から終了割り込みを受けた時点で送信処理待ちキュー127より次に送信すべきデータを送信データの取り出し手段125により取り出し通信装置
111へ送信要求する。送信データの取り出し手段125により取り出されるデータ数は
、次に通信装置111が受付可能なデータ数である。つまり、通信装置111がデータ送信手段126から要求されたデータを通信網110へ送信し終了するまでの間送信処理待ちキュー127に溜め込まれる。そして次に通信網へのデータ送信手段126が動作するときに送信データの取り出し手段125にて優先データから順にデータを取り出し送信処理を行う。
<受信処理>
図1により、通信網からデータを受信し通信プログラムへ渡すまでの処理を説明する。通信装置111が通信網110からデータを受信すると通信装置111からデータ受信手段130に割り込みで報告され、データ受信手段130が通信装置111からデータを取り込む。受信データの優先判定手段131にて受信データ内のプロトコルヘッダ内の情報をチェックし優先受信するか非優先受信かを判定し、受信処理待ちキュー136の優先データ処理待ちキューか非優先データ処理待ちキューのいずれかに受信データの接続手段
132にて接続する。受信処理待ちキュー136に一つもデータが接続されていない場合は、プロトコル受信処理部143を起動し、一連の割り込み報告による受信処理を終了する。データが接続されている場合は、受信処理を即終了する。プロトコル受信処理部143が起動されると受信データの取り出し手段133により受信処理待ちキュー136から次に処理すべき優先度の高いデータを一つ取り出し、IPプロトコル受信処理部134へデータを渡し、自端末宛てのデータであれば上位のTCPプロトコル受信処理部135経由で通信プログラム処理部120へデータを渡す。
IPプロトコル受信処理部134にて自端末宛てでないデータでかつ中継すべきデータと判断した場合は、受信データをプロトコル送信処理部141のIPプロトコル送信処理部122へ渡し、送信データの優先判定手段123,送信データの接続手段124,送信データの取り出し手段125,データ送信手段126を経由し送信する。
プロトコル受信処理部143は、受信処理待ちキュー136にデータが接続されている限り上記のプロトコル受信処理を繰り返す。プロトコル受信処理部143が動作中であっても通信網からのデータ受信手段130は、割り込み動作する。このため通信装置111から受信したデータは、受信処理待ちキュー136に接続され溜め込まれる。この溜め込まれたデータをプロトコル受信処理部143への受信データの取り出し手段133にてデータを取り出しプロトコルの受信処理を行う。
<優先判定情報>
受信,送信データが優先すべきデータか非優先データかを判定するために参照するプロトコルヘッダ内の優先判定情報について説明する。
図3に、通信網を流れるデータフレーム300の構成例を示す。データフレーム300は、データリンク層としてIEEE802.3 を用いた場合のTCP/IPのフレーム構成例である。この他、イーサネットフレームやIEEE802フレームがある。TCP/IPプロトコルを用いた場合の優先判定情報は、データのプロトコル種別,TCPヘッダ330内の宛先ポート番号332,送信元ポート番号331、およびIPヘッダ320内の宛先インターネットアドレス322,送信元インターネットアドレス(INA)321である。
プロトコル種別は、IEEE802.3のMACヘッダ,LLC(Logical Link Control)
,SNAP(Sub Network Access Point)から成る物理ヘッダ310内のSNAPヘッダ内のプロトコルタイプ311を用いる。プロトコルタイプ311は、DARPAプロトコルとしてリクエスト・フォー・コメンツ(RFC)内にタイプ番号とプロトコル名が記載されており16進数表記でIPプロトコルが800,ARPが806と決められている。更にプロトコル種別を限定するために、プロトコルタイプ311がIPのとき、IPヘッダ312内のプロトコル326(IPの上位プロトコル)を用いる。プロトコル326としては、TCP,UDP、およびICMPなどのプロトコルがRFCで定義されている。インターネットアドレスは、IPヘッダ320の送信元INA(インターネットアドレス)321,宛先INA322を用いる。ポート番号は、TCPあるいはUDPヘッダ330内の送信元ポート番号331,宛先ポート番号332を用いる。
図4に示す形式により、図1の優先データ情報登録メモリ102に、上記優先判定情報の内どの組み合わせを優先的に送受信するかが格納されている。すなわち、データの物理ヘッダ310内のプロトコルタイプ401,IPヘッダ内のプロトコルタイプ402,送信元のINA403,宛先のINA404,送信元ポート番号405,宛先ポート番号
406が、それぞれの対応する部分に格納されている。プロトコルには、直接、通信プログラム処理部120において通信プログラムの処理に使用するTCP,UDPプロトコルとARP,ICMPのようなシステム内のプロトコル処理から使用され通信プログラムからは直接使用されないプロトコルがある。全てのプロトコルを優先データ情報として登録すると優先データ情報登録メモリを検索するオーバーヘッドが大きくなり通信性能が遅延するため、ARP,ICMPのような直接通信プログラムから使用されないプロトコルは
、予め優先データとして処理しても良い。優先データ情報登録メモリを検索するオーバーヘッドを高速化するためのハッシュ化等の処理も組み込む。また、優先判定する情報全てを比較しなくても良いように優先データ情報登録メモリに格納される値が0の場合、その項目の比較を行わない。この値は0でも−1でも構わないが優先判定情報内で用いられない値である必要がある。
<優先判定>
図5に、送受信データの優先判定手段の一例のフローチャートを示す。この例では、処理500,505にて送受信するデータのプロトコル種別をチェックし、ARP,ICMPである場合無条件に優先データとし、ARP,ICMP,TCP,UDP以外のプロトコルである場合非優先データとして扱う。データがTCP,UDPプロトコルならば処理
510〜550にてデータと優先データ情報登録メモリ内全ての宛先,送信元ポート番号
、および宛先,送信元インターネットアドレスを比較する。優先データ情報が0の場合は比較せずに次の優先データ情報の比較を行う。登録されている場合、優先データとし、登録されていない場合には、非優先データとする。
処理500,505の代わりに、優先データ情報登録メモリ内の情報項目プロトコルタイプ401とデータヘッダ内のプロトコルタイプ311,プロトコル326とIP上位プロトコル402の比較処理を、処理510と505の間に入れることもできる。データヘッダ内のプロトコルタイプ311,プロトコル326と優先データ情報登録メモリ内の情報項目プロトコルタイプ401,IP上位プロトコル402の一致する項目が登録されている場合処理501以降の判定を行い、一致する項目が登録されていない場合、非優先データと判断する。
<処理待ちキュー構成>
上記のようにデータの優先判定を行った後、送受信データの接続手段により送受信データ処理待ちキューに接続する。送信・受信処理待ちキューへのデータ接続方法,取り出し方法を説明する前に送信・受信処理待ちキューの構成について説明する。
図6に、送信・受信データ処理待ちキューの構成図を示す。送信・受信データ処理待ちキューは、送信・受信データの処理待ちキュー制御に使用する情報から成るキューヘッダ610,優先データの処理待ちキュー620と非優先データの処理待ちキュー630から成る。優先データ処理待ちレベルキュー620,非優先データ処理待ちレベルキュー630の構造は同じ構造である。各処理待ちキューには、各キューごとに連続して取り出せるためのデータ数である連続取り出し可能最大データ数621,631と、現在の連続取り出し可能データ数622,632,各キューに現在いくつの処理待ちデータが接続されているかをカウントする処理待ちデータ数623,633,該当優先レベルキューに接続されているデータのFIFOの処理待ち状態のデータリストの先頭と最後のデータのデータヘッダアドレス624,635と625,635から成る。各キューに接続されるデータの内部処理構造640は、データの属性や優先情報等のデータ制御情報を格納するデータ管理ヘッダ641とデータ部642からなる。
上記処理待ちキューの初期情報の一例を次に示すと、図6のキューヘッダ610内のトータルデータ数611が0の場合である。
送信又は受信できる上限回数は、補助記憶装置100に送信又は受信処理上限登録ファイル103を配置し、優先と非優先のそれぞれの処理上限回数を登録する。この上限回数は、データの送信又は受信処理を開始するまでに、送信又は受信処理待ちキュー600の優先データ処理待ちキュー620内の連続取り出し上限回数621と非優先データ処理待ちキュー630内の連続取り出し上限回数631に格納する。現在の連続取り出し回数
622,632、その他の処理待ちデータ数、先頭処理待ちデータアドレス624,634
、および最終処理待ちデータアドレス625,635には0が格納される。取り出し上限回数621,631以外の情報は、処理待ちキューへのデータ接続処理,データ取り出し処理により値が変更される。
<接続方法>
図7に、送受信処理待ちキューへのデータの接続方法のフローチャートを示す。処理
710で接続するデータが優先か非優先かを判定する。処理720にて優先データならば優先データの処理待ちキューの最終処理待ちデータアドレス625で示されるデータの次に接続し、優先データ処理待ちキューの処理待ちデータ数623を1加算する。非優先データならば処理730にて非優先データの処理待ちキューの最終処理待ちデータアドレス625で示されるデータの次に接続し、非優先データ処理待ちキューの処理待ちデータ数623を1加算する。最後に処理740にてキューヘッダ内のトータルデータ数611を1加算する。
<取り出し方法>
次に、図8に、送信・受信データ処理待ちキューから送信処理するデータ、あるいは受信処理するデータを取り出す方法のフローチャートを示す。この処理には優先データが連続処理されることにより非優先データが送信又は受信処理待ちキューから取り出せず飢餓状態に陥ることを防止する処理も含めている。このフローに示す飢餓状態防止方法は、優先データ,非優先データの連続処理回数を用いた1例である。
処理810〜825は、優先データ処理待ちキューからのデータ取り出し処理である。処理850〜860が非優先データ処理待ちキューからのデータ取り出し処理である。処理830,840,845,865,870は、飢餓状態防止のための調整処理部である
。非優先データの飢餓状態を防止するため、各キューの連続取り出し上限回数と現在の連続取り出し回数を用い、優先データの連続取り出し数を現在の連続取り出し回数でカウントし、連続取り出し上限回数を越えた(又は上限回数と等しい)時、非優先データがあれば非優先データを取り出す。この時に非優先データをいくつ処理するかは、登録されている非優先データ処理待ちキューの取り出し上限回数で決まる。
通常優先データが存在する場合は、非優先データが存在しても処理810〜830により処理待ちキューから優先データが取り出され、優先データ処理待ちキュー620の処理待ちデータ数623と連続取り出し回数622が減算される。優先データ処理待ちキュー620の連続取り出し回数が、連続取り出し上限回数と等しくなる(処理815)と優先データの取り出しを中断し、非優先データが存在するかチェック(処理840)する。非優先データが存在する場合は、処理855〜860にて非優先データの取り出しを行う。この後、処理865にて、非優先データの連続取り出し回数632が連続取り出し上限回数631を越えた(又は上限回数631と等しい)場合、非優先データおよび優先データの処理待ちキューの連続取り出し回数632,622を0に設定する(処理870)。
この連続取り出し回数の初期化(処理845,870)は、送信・受信処理待ちキューにデータが一つも存在しなくなった時(処理810−850−870)、優先データは存
在するが優先データの連続取り出し回数が連続取り出し上限回数となり、非優先データの取り出しを行おうとしたが非優先データが存在していなかった時(処理840−845)
、優先データ,非優先データとも取り出し回数622,623が連続取り出し上限回数と等しくなった時(処理865−870)行われる。連続取り出し回数の初期化は、優先データの取り出しを中断する必要がなくなったタイミングで行う。
上記は、連続取り出し回数を積算する積算手段と、積算値が上限回数に達したか否か判定する積算値上限回数判定手段を用いた例である。
このほか、予め連続取り出し回数を上限回数で初期化し、データを取り出すごとに減算し、0になったか否か判定する方式でもよい。
上記の優先データ,非優先データの連続処理回数による飢餓状態防止策の他に次方式でも良い。補助記憶装置100にシステム内に残留できる上限時間を送信・受信処理上限登録ファイル103に登録し、データの送信又は受信までにそれぞれの処理待ちキューに格納する。そして、送信・受信処理待ちキューにデータを接続した後、一定周期にキューに接続されているデータのデータヘッダ内の待ち時間カウンタを加算し、残留上限時間を越えたデータ(又は残留上限時間と等しいデータ)を準優先データとし処理待ちキューから取り出す。この時本来の優先データの遅延を招かないよう取り出し個数を優先データ複数個に対し準優先データ一つというように調整し取り出す。また、回数による方式と接続されてからの待ち時間両方を組み込んだ取り出し方法でもよい。これらについての詳細な例は、実施例3にて示す。
本実施例によれば、プロトコル種別,IPヘッダ内のインターネットアドレス、およびTCPあるいはUDPヘッダ内のポート番号を用いて優先送信処理,優先受信処理したいデータを判別でき、通信プログラムで送受信するデータ単位にリアルタイム性が要求されるデータを優先処理できる効果がある。また、優先判定情報をポート番号だけにすることにより通信システム内のサービス種別単位に優先処理でき優先判定の処理オーバーヘッドを低減することもできる。
〔実施例2〕
以下、実施例2について説明する。
実施例1では、データ受信時もTCPあるいはUDPのポート番号とIPのインターネットアドレスを優先判定情報として用いた例を示した。しかし、TCPあるいはUDPからの送信データサイズが下位通信網の最大転送バイト数よりも大きい場合、送信データをセグメンティング(分割)し、受信データをリアセンブル(再組み立て)する。このセグメンティングされたデータには、TCPやUDPヘッダを含まないデータフレームも存在してしまう。つまり、セグメンティングされたデータを受信した時に実施例1で示した優先判定情報だけでは優先データか非優先データかを判定できない場合が生じる。これを回避する方法について、この実施例2で説明する。
上記セグメンティング,リアセンブル処理は、IPプロトコルとして規定されており周知である。この送信データのセグメンティングしたデータは、IPプロトコルではフラグメントと呼ばれている。このフラグメントの概略図を図9に示す。データ900をIPプロトコルが送信依頼された場合、IPヘッダ902からユーザデータ2の904までのデータサイズが送信先の通信網が扱える最大転送バイト数より大きい時、データ910とデータ920のようにデータを分割する。図9には、二つに分割した図を示している。一つ目のデータ910には、TCP/UDPヘッダ913が付加されるが、二つ目以降の分割されるデータにはTCP/UDPヘッダは付加されない。IPプロトコルでは、一つのデータを複数に分割し送信する場合、データを受信した側で再組み立てできるための情報を各分割データ内のIPヘッダ912,922に格納するようになっている。図3のデータ分割識別子327,フラグ324,FO325の情報が再組み立てに使用する情報である
実施例1では、送信データの判定手段を、図1のIPプロトコル送信処理部122の次に置き処理していたが、実施例2では、IPプロトコル送信処理部122でデータ分割処理を行う前に置く。そして優先判定した結果を元に分割するデータ全てのIPヘッダのタイプオブサービスフィールド(図9の950)内のデータグラムの優先度(図9の951)にデータの優先か否かの識別子を格納する。以後の優先送信処理は、この優先識別子により優先データか非優先データかを判断する以外、実施例1と同じである。格納するデータの優先識別子の値は、送信データの優先判定により優先データか非優先データかを識別した後で、それぞれに対応付けて登録されている優先識別子を用いる。
データ受信処理の構造は、実施例1の場合と略同じ。ただし、図1の受信データの優先判定手段131が、実施例1で示した方法と異なる。すなわち、異なる部分は、プロトコル種別がIPプロトコルであると認識した後の優先データか非優先データかの判定を、図9のIPヘッダ内タイプオブサービス情報中のデータグラムの優先度951を用いて行うところである。この優先度951は、上記データ送信処理で説明した通り、予め優先データと非優先データに対して優先識別子を対応付けて置き、その優先識別子の値に従い優先判定を行う。優先判定後の処理は、実施例1と同じ処理を行う。
本実施例によれば、最大転送バイト数の異なる下位通信網が複数存在する通信システムにおける網間中継装置で送受信データがセグメンティングされてもどのデータを優先的に処理するかを判別でき、本発明を適用できる通信機器に制限を付けずに優先制御を行える効果がある。
本実施例では、データ送信時、優先データと非優先データに対応するデータの優先度をデータ内のプロトコルヘッダの優先度情報951に格納し、データを受信時、データ内のプロトコルヘッダの優先度情報951に従いデータの受信処理を優先制御する例を示した
。この方法では、予め端末がデータ内のプロトコルヘッダの優先度情報951に優先するか否かを示す優先識別子を設定しなければいけない。このため、上記処理を行わない端末からデータを受信し中継する場合にIPプロトコルに準拠した端末,網間中継装置で、処理が正常動作しない場合又は優先判定ができない場合が発生する。これを回避するために
、データ送信時データ内のプロトコルヘッダの優先度情報951を格納せずに、実施例1の通り送信する。そして、図3に示すような、予め受信したデータのIPヘッダ内の
Identification(データ識別子)327,フラグメントオフセット325,フラグ324を監視し、分割されたデータの先頭データと判断した場合、そのデータが優先すべきデータかを優先判定情報より決定し、優先データであるとき、データ分割識別子ごとに記憶する。一つのデータ分割識別子に1ビット割り付け、データ分割識別子ごとに優先データか否かを管理できるようにする。初期値はオフとし、分割データの先頭データのヘッダ情報から優先すべきデータと判断したときに、対応するデータ分割識別子のフラグをオンする
。受信したデータのIPヘッダ内のフラグメントオフセット,フラグから分割された2個目以降のデータと判断した場合、IPヘッダ内のデータ分割識別子に対応するフラグがオンであれば、優先データ、オフであれば非優先データとして処理する。分割されたデータの最後のデータを受信した場合、優先判定を実施後、IPヘッダ内のデータ分割識別子に対応するフラグがオフする。この方法では、プロトコルヘッダの優先度情報に優先するか否かを示す値を設定する処理を採用しない端末からのデータも網間中継装置で中継するデータに対し優先制御でき、かつIPプロトコルで規定されるデータグラムの優先度951をサポートしている端末、網間中継装置でもプロトコル違反をすることなく優先制御できる効果がある。
〔実施例3〕
以下、実施例3について説明する。実施例1,2では、優先と非優先の2レベルの優先制御であるが、実施例3では、優先制御を2レベル以上の複数の優先処理レベルで実施する場合の実施例について説明する。
通信システム内の優先通信制御方式の構成は、実施例1で説明した図1の構成と略同じであるが、優先データ情報登録ファイル101と優先データ情報登録メモリ102の構成
,送信又は受信処理上限登録ファイル102,送信・受信処理待ちキュー127,136の構成,処理待ちキュー内の各種管理情報が異なる。更に、送信・受信データの優先判定手段123,131や送信・受信データの接続手段124,132、および送信・受信データの取り出し手段125,133でそれぞれ優先処理レベルを考慮した処理を行う。また、低い優先レベルの飢餓状態を防止するための手段として、本実施例では、定周期残留積算手段150を使用する。優先判定情報の構成,通信プログラムから通信網へデータ送信するまでの処理、および通信網からデータを受信し通信プログラムへ渡すまでの処理は
、実施例1と同じである。
優先データ情報は、実施例1で説明した図4の構成に優先レベルを追加した図10の構成を用いる。この優先データ情報に登録されている優先判定情報を持つデータの優先レベルは、図10の優先判定情報と一致した情報内の優先処理レベル1007値を用いて以後の送信・受信処理の優先制御を行う。データの優先判定情報が優先データ情報登録メモリ102に登録されていない場合は、最も低い優先処理レベルを割り当て、送信・受信処理する。
図11に、優先レベルを3とした場合の送信・受信処理待ちキューの構成を示す。送信
・受信処理待ちキュー1100は、キューヘッダ1110と使用する優先処理レベル数分の優先処理レベルごとの処理待ちキュー1110,1120,1130,1140から成る。キューヘッダ1110には、各優先処理レベルごとの処理待ちキューに接続されているトータルデータの数を格納するトータルデータ数1111,飛び越しデータリスト1112
、および優先処理レベル数1113,飛び越しデータ数1114から成る。飛び越しデータリスト1112は、低い優先レベルのデータが処理待ちキューに接続されてから定周期残留積算手段150にて飢餓状態と判断したデータを最優先で送信待ちするリストである
。優先処理レベル数1113は、通信システム内で使用する優先処理レベルの数を予め決定し登録しておく。各優先処理レベルごとの処理待ちキューの構成情報1121〜1123、およびキューに接続するデータ構造1140は、データヘッダに残留カウンタ1150を持つ以外は、実施例1で説明したものと同様のものである。
キューヘッダ情報1110の初期値は、トータルデータ数1111と飛び越しデータ数が0,優先データ情報登録ファイル101より入力し、優先処理レベル数に予め登録された値を格納する。各優先レベルごとの処理待ちキューの処理待ちデータ数1121が0,残留上限値1123は、送信・受信処理上限登録ファイル103より入力し、予め登録された値を初期値とする。キューヘッダ1110と優先レベル1120,1130,1140ごとの処理待ちキュー内のデータリストは、データが接続されていない状態にする。
<優先判定>
優先処理レベル化した優先制御で使用する送信・受信データの優先判定方法は、図5の処理555のように無条件に優先データとする処理の代わりに、データ内の優先判定情報と図10の優先データ情報登録メモリに登録されている優先データ情報の一致する情報内の優先処理レベル1007をデータの優先処理レベルとする処理方法である。また、ARPとIP以外のプロトコルタイプ,ICMP,TCP,UDP以外のIPプロトコル上位のプロトコル,優先データ情報登録メモリに登録されていない優先判定情報のデータの場合(処理500〜510)は、処理560の代わりに最も低い優先処理レベルのデータとして扱う。これらプロトコルも図10に示す優先データ情報登録ファイルに登録しておくことにより優先処理レベルを設定することも可能である。上記データの優先判定後、図11のデータヘッダ1141内に優先処理レベル1151を格納し、データの処理待ちキューへの接続処理へ渡す。以後データを通信網へ送信するか、あるいは受信データを通信プログラムに渡すまで各処理でデータヘッダ内の優先処理レベル1151を参照する。
又、データの送信要求時あるいはデータ受信時からシステム内に残留している時間を積算するための残留カウンタ1150をデータヘッド内に有する。残留カウンタ1150は
、データの送信要求時あるいはデータ受信時に0で初期化する。
<データの接続>
送信・受信データを送信・受信処理待ちキュー1100へ接続するのは、データの接続手段にて行い、接続フローを図12に示す。データは、処理1200にてデータの優先処理レベルに対応する処理待ちキューの一番最後に接続し、この優先レベルキューの処理待ちデータ数を1加算する。そして処理1210にてキューヘッダのトータルデータ数を1加算する。
<データの取り出し>
以下、優先処理レベルをレベルで、送信・受信処理待ちキューを処理待ちキューで、優先レベルごとの処理待ちキューをレベルキューで説明する。処理待ちキューからレベルを用いて一つのデータを取り出すフローチャートを図13に示す。実際の処理では図13の処理フローを取り出したいデータ数分ループし、データを取り出す。取り出し処理の説明を簡単にするため一つのデータを取り出す処理に限定している。
処理1300にて現在処理待ちキューにデータが接続されているかをキューヘッダのトータルデータ数で判定する。データが接続されていない場合は、データなしとして処理を終了する。一つ以上のデータが接続されている場合は、低い優先レベルのデータが飢餓状態に陥った時に接続されるキューヘッダ内の飛び越しデータリストにデータが接続されているかを処理1305でチェックする。飛び越しデータが存在する場合は、処理1335〜1340でキューヘッダからデータを外しトータルデータ数1111と飛び越しデータ数1114を1減算する。この飛び越しデータリストへデータを接続するのは、定周期残留積算手段にて行う。この手段については、後ほど説明する。通常は、処理1305〜
1330を繰り返し、最も高い優先レベルのキューから順に低いレベルのキューをサーチし取り出せるデータが存在するかサーチする。現在のサーチ対象レベルキューにデータがあるか処理1310で判定する。処理待ちデータがある場合、処理1315にてデータを一つ取り出し、処理1320で処理待ちキューのトータルデータ数、現在のサーチ対象レベルキューの処理待ちデータ数を1減算する。処理1310でサーチ中の対象レベルキューにデータがない場合は、処理1325にてサーチする優先レベルを変更する。その結果のサーチ優先レベルが最低レベルを越えたかを処理1330で判定し、越えていない場合は、処理1305から次の優先レベルキューのサーチを繰り返す。処理1330で、最低レベルを越えた場合は、取り出せるデータなしとして終了する。
<定周期残留積算手段>
次に、図14に、定周期で起動され処理待ちキュー内に接続されるデータの残留時間の積算手段についての処理手順を示し説明する。この処理は、予め登録された時間に従い、一定周期で起動され、図14のフローチャートに示す処理を実行する。処理1400で処理待ちキューに最優先レベルキューの処理待ちデータおよびキューヘッダ内の飛び越しデータ以外のデータがあるか判定し、ない場合は処理を終了する。最優先データと飛び越しデータ以外のデータがある場合は、最優先レベルより一つ下の優先レベルのキューから順に最低レベルのキューまで処理1405〜1420を繰り返し、全ての処理待ちデータのデータヘッダ内残留カウンタ1150を1加算する。加算した結果、そのデータのレベルキューの残留上限値1123を越えた(又は等しい)場合は、飢餓状態のデータと判断
(処理1420)し、処理1425〜1430でそのデータを接続されているレベルキューから外しキューヘッダの飛び越しリスト1112の一番後ろへ接続し、処理待ちデータ数1121を1減算する。
本実施例によれば、複数の優先処理レベルを用いるので、リアルタイム性が要求されるデータをさらに送信・受信処理する際に優先順序化することができる。また、定周期残留積算手段を用いるので、高優先データが連続して発生した場合においても低優先データの送信・受信処理が完全に中断しないようになるので、不必要な再送処理による通信網の輻輳状態,論理回線の切断を回避できる効果がある。
〔実施例4〕
以下、実施例4について説明する。実施例3の場合は、実施例2で説明したセグメンティングされるデータに対して優先判定情報を取り込めず優先判定ができない場合がある。そこで、本実施例では、実施例3の場合に、実施例2で説明したセグメンティング,リアセンブルされるデータに対しての優先制御方法を取り入れた複数の優先処理レベルによる通信方法を説明する。
送信データの判定手段を、実施例3では、図1のIPプロトコル送信処理部122の次に置き処理していたが、本実施例では、IPプロトコル送信処理部122でデータ分割処理を行う前に置く。そして、優先判定手段にて求めた優先処理レベルを分割するデータ全てのIPヘッダのタイプオブサービスフィールド(図9の950)内のデータグラムの優先度(図9の951)に格納する。以後の優先送信処理は、実施例3と同様である。優先度とする値は、優先処理レベル値を直接格納しても、優先レベルと優先度変換表により変換した値を格納しても良く、通信システム内で統一されていればよい。データ受信処理の構造は、実施例3と略同様である。ただし、図1の受信データの優先判定手段131が実施例3で示した方法と異なる。異なる点は、プロトコル種別がIPプロトコルであると認識した後の優先判定を、図9のIPヘッダ内タイプオブサービス情報中のデータグラムの優先度(図9の951)を用いて行う点である。上記データ送信処理で説明したとおり、予め優先処理レベルとIPヘッダ内の優先度を対応付けて置き、優先度951の登録値に従い優先判定を行う。優先判定後の処理は、実施例3と同様の処理を行う。
本実施例によれば、データのセグメンティングに対応しているので、実施例3の効果に加え、複数の異なる通信網からなる通信システムへも適用可能となる効果がある。
本実施例では、データ送信時、優先処理レベルをデータ内のプロトコルヘッダの優先度情報に格納し、データを受信時、データ内のプロトコルヘッダの優先度情報に従いデータの受信処理を優先制御する例を示した。この方法では、予め端末がデータ内のプロトコルヘッダの優先度情報に優先する処理レベルを設定しておく必要がある。このため、上記処理を行わない端末からのデータを受信し中継する場合に優先処理レベル判定できない問題が発生する。これを回避するために、データ送信時、データ内のプロトコルヘッダの優先度情報を格納せずに送信する。そして、予め受信したデータのIPヘッダ内のデータ分割識別子(Identification),フラグメントオフセット,フラグを監視し、分割されたデー
タの先頭データと判断した場合、そのデータが優先すべきデータかを優先判定情報より決定し、優先データである時、データ分割識別子ごとに記憶する。そして、受信したデータ分割識別子と優先処理レベルを対応付ける表を管理する。初期値は、0とし、分割データの先頭データのヘッダ情報から優先処理レベルを決定し、そのデータ分割識別子と優先処理レベルを記憶する。受信したデータのIPヘッダ内のフラグメントオフセット,フラグから、分割されたデータの2個目以降のデータであると判断した場合、IPヘッダ内のデータ分割識別子が前記表に記憶されていれば、その優先処理レベルに送信又は受信処理する。分割されたデータではあるが、対応するデータ分割識別子が前記表に記憶されていない場合は、先頭データがまだ到着していない、又は途中で破棄されたと見做し、予め登録されている優先処理レベルで送信又は受信処理する。その後、先頭データが到着した場合は、そのデータの分割識別子と優先処理レベルを上記表に記憶する。分割データの最後のデータを受信した場合、優先判定を実施した後、そのデータの分割識別子と優先処理レベルを上記表から削除する。高速検索できるためのハッシュ化による検索,登録、および削除などの方法により上記表の管理を行う。この方法によれば、異なる構成の端末からのデータを網間中継装置で中継するデータに対して優先処理レベルによる優先制御ができる。
以上説明したように、マルチメディア,プラントデータの様なリアルタイム性が要求されるデータとある程度の遅延が許されるデータが混在した通信システムにおいて、データの送受信処理の順序をデータごとに決定できるので、アプリケーションの通信プログラムが扱うデータごとに通信上の制限を設けることなく優先制御できる効果がある。また、アプリケーションの通信プログラムに、通信上の制限を設けることなく通信データ単位に優先処理レベルを設定できる。さらに、データ内のプロトコルヘッダにサービス識別子を持たないデータに対しても優先制御できるため、種別の異なる複数の通信網を中継する網間中継装置へも適用できる効果がある。高優先データが連続して発生した場合においても低優先データの送受信処理が完全に中断しないようになるので、不必要な再送処理による通信網の輻輳状態,論理回線の切断を回避できる効果がある。
通信システムの優先通信制御方式の構成図。 通信システム全体の図。 TCP/IPデータフレームの構成図。 実施例1の優先データ情報登録メモリの構成図。 実施例1のデータの優先判定手順を示す図。 実施例1の送受信データの処理待ちキューの構成図。 実施例1の送受信データを処理待ちキューへ接続する手順を示す図。 実施例1の処理待ちキューから送受信データを取り出す手順を示す図。 実施例2のIPプロトコルによるセグメンティング処理を示す図。 実施例3の優先データ情報登録メモリの構成図。 実施例3の送受信データの処理待ちキューの構成図。 実施例3の送受信データを処理待ちキューへ接続する手順を示す図。 実施例3の処理待ちキューから送受信データを取り出す手順を示す図。 実施例3の定周期残留積算手段の手順を示す図。
符号の説明
100…補助記憶装置、101…優先データ情報登録ファイル、102…優先データ情報登録メモリ、103…送信・受信処理上限登録ファイル、110…通信網、111…通信装置、120…通信プログラム処理部、121…TCPプロトコルの送信処理部、122…IPプロトコルの送信処理部、123…送信データの優先判定手段、124…送信データの接続手段、125…送信データの取り出し手段、126…データ送信手段、127…送信処理待ちキュー、130…データ受信手段、131…受信データの優先判定手段、
132…受信データの接続手段、133…受信データの取り出し手段、134…IPプロトコルの受信処理部、135…TCPプロトコルの受信処理部、140…中央処理装置,主記憶装置、141…プロトコル送信処理部、142…送信データの処理待ちキュー制御部、143…プロトコル受信処理部、144…受信データの処理待ちキュー制御部、150…定周期残留積算手段。

Claims (2)

  1. 複数の端末装置が接続され、前記端末装置で情報を送信又は受信する通信システムにおいて、前記端末間で授受される情報に規定領域及びデータ領域を含むものであって、前記規定領域のデータを取得する手段と、前記取得した規定領域のデータが所定のプロトコルに相当するものであると、受信について優先的な処理をおこなうことにより、前記取得した規定領域のデータに応じた記憶領域に前記データ領域のデータを格納する処理手段を設けたことを特徴とする通信システム。
  2. 端末装置で情報を送信又は受信する通信方法において、前記端末間で授受される情報に規定領域及びデータ領域を含むものであって、前記規定領域のデータを取得し、前記取得した規定領域のデータが所定のプロトコルに相当するものであると、受信について優先的な処理をおこなうことにより、前記取得した規定領域のデータに応じた記憶領域に前記データ領域のデータを格納する通信方法。
JP2006168257A 2006-06-19 2006-06-19 通信システムおよび通信方法 Expired - Lifetime JP3950907B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006168257A JP3950907B2 (ja) 2006-06-19 2006-06-19 通信システムおよび通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006168257A JP3950907B2 (ja) 2006-06-19 2006-06-19 通信システムおよび通信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2005341347A Division JP3944515B2 (ja) 2005-11-28 2005-11-28 通信システムおよび通信方法

Publications (2)

Publication Number Publication Date
JP2006304349A JP2006304349A (ja) 2006-11-02
JP3950907B2 true JP3950907B2 (ja) 2007-08-01

Family

ID=37472010

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006168257A Expired - Lifetime JP3950907B2 (ja) 2006-06-19 2006-06-19 通信システムおよび通信方法

Country Status (1)

Country Link
JP (1) JP3950907B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4758362B2 (ja) * 2007-01-30 2011-08-24 株式会社日立製作所 中継装置、プログラム及び中継方法
JP4599429B2 (ja) * 2008-05-13 2010-12-15 日本電信電話株式会社 通信システム及び通信方法
JP2016086335A (ja) * 2014-10-28 2016-05-19 日本電気株式会社 通信装置、通信方法及びプログラム
JP2019145909A (ja) * 2018-02-16 2019-08-29 日本電気株式会社 データ処理装置、データ処理方法、およびプログラム
JP7255183B2 (ja) * 2019-01-09 2023-04-11 日本電気株式会社 データ処理装置、データ処理方法、プログラム

Also Published As

Publication number Publication date
JP2006304349A (ja) 2006-11-02

Similar Documents

Publication Publication Date Title
JP3151103B2 (ja) 通信システムおよび通信方法
US7292530B2 (en) Method and apparatus to manage packet fragmentation
US6990106B2 (en) Classification and tagging rules for switching nodes
US8064344B2 (en) Flow-based queuing of network traffic
JP4685254B2 (ja) データ通信スイッチ用の優先順位リマッピング
US10432556B1 (en) Enhanced audio video bridging (AVB) methods and apparatus
EP1670187B1 (en) Tagging rules for hybrid ports
EP1578072B1 (en) Priority control apparatus and method for transmitting frames
AU2005326185A1 (en) Hardware filtering support for denial-of-service attacks
EP1417795B1 (en) Switching node with classification-dependent mac buffer control
JP3950907B2 (ja) 通信システムおよび通信方法
JP3950895B2 (ja) 通信システムおよび通信方法
US20200236057A1 (en) Packet Processing Method and Apparatus
JP7103883B2 (ja) 通信システム、通信制御方法、及び通信装置
JP3944515B2 (ja) 通信システムおよび通信方法
JP3689704B2 (ja) 通信システムおよび通信方法
US20090141712A1 (en) Router device
JP3457636B2 (ja) 通信システム
JP2004147164A (ja) パケット送信装置
KR100637933B1 (ko) 가입자 액세스망 접속 장비에서의 패킷 포워딩 방법 및장치
US7859997B2 (en) Packet handling on a network device
CN116032859B (zh) 一种融合式快速数据交换装置及方法
US7304946B2 (en) Packet multiplexing control method and a concentrator using the same
JP7251060B2 (ja) 情報処理装置、情報処理システム及び情報処理プログラム
CN114051008B (zh) 一种降低无线网络的游戏业务时延的系统

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061024

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061220

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070423

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20110427

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20120427

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20120427

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20130427

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20140427

Year of fee payment: 7

EXPY Cancellation because of completion of term