JP7374849B2 - 通信システム、通信方法およびプログラム - Google Patents

通信システム、通信方法およびプログラム Download PDF

Info

Publication number
JP7374849B2
JP7374849B2 JP2020095718A JP2020095718A JP7374849B2 JP 7374849 B2 JP7374849 B2 JP 7374849B2 JP 2020095718 A JP2020095718 A JP 2020095718A JP 2020095718 A JP2020095718 A JP 2020095718A JP 7374849 B2 JP7374849 B2 JP 7374849B2
Authority
JP
Japan
Prior art keywords
abnormality
message
communication
size
information
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.)
Active
Application number
JP2020095718A
Other languages
English (en)
Other versions
JP2021190901A (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.)
Toshiba Corp
Original Assignee
Toshiba 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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2020095718A priority Critical patent/JP7374849B2/ja
Priority to US17/184,346 priority patent/US11882053B2/en
Publication of JP2021190901A publication Critical patent/JP2021190901A/ja
Application granted granted Critical
Publication of JP7374849B2 publication Critical patent/JP7374849B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6205—Arrangements for avoiding head of line blocking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/004—Error avoidance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Small-Scale Networks (AREA)

Description

本発明の実施形態は、通信システム、通信方法およびプログラムに関する。
ＴＳＮ（Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ）規格等に対応したネットワークを介してリアルタイム通信する通信装置が知られている。ＴＳＮでは、時間単位でキューの送信可否を記載したゲート制御リストにより、フレームの送信可否を判定することで、送信タイミングおよび送信量を制御することができる。
IEEE Std 802.1Q-2018
しかしながら、従来技術では、通信のリアルタイム性が損なわれる場合があった。
実施形態の通信システムは、算出部を備える。算出部は、複数のキューそれぞれに対応する複数のゲートを開くか否かを定める複数のエントリを含むゲート制御情報に基づいて、送信するメッセージのサイズがキューにより送信可能なサイズより大きいことにより生じる異常を判定するための判定情報を算出する。
第１の実施形態にかかる情報処理システムの構成図。 第１の実施形態にかかる通信装置のハードウェア構成図。 第１の実施形態にかかる通信装置の機能ブロック図。 ゲート制御リストの例を示す図。 継続オープン時間の例を示す図。 異常フレームサイズの算出処理のフローチャート。 フレーム送信処理のフローチャート。 異常通知処理のフローチャート。 異常通知処理のフローチャート。 第１の実施形態の変形例のフレーム送信処理のフローチャート。 第１の実施形態の変形例のフレーム送信処理のフローチャート。 第１の実施形態の変形例のフレーム送信処理のフローチャート。 第２の実施形態にかかる通信装置の機能ブロック図。 第２の実施形態の変形例にかかる通信装置の機能ブロック図。 第３の実施形態にかかる通信装置の機能ブロック図。 第３の実施形態の変形例にかかる通信装置の機能ブロック図。 第３の実施形態の変形例にかかる通信装置の機能ブロック図。 第３の実施形態の変形例におけるフレーム送信処理のフローチャート。
以下に添付図面を参照して、この発明にかかる通信システムの好適な実施形態を詳細に説明する。以下では、リアルタイム通信の規格としてＴＳＮを用いる例を主に説明するが、適用可能な規格はＴＳＮに限られるものではない。
ＴＳＮでは、複数のキューそれぞれに対応する複数のゲートを開くか否かを定めるエントリを複数含むゲート制御リスト（ゲート制御情報の一例）が用いられる。例えばＴＳＮでは、複数のキューそれぞれにおいて、ゲートの開放（オープン）状態が継続（連続）する場合には、ゲートが最終的に閉じられるまでの時間、複数のエントリにまたがってフレーム（メッセージの一例）送信をすることができる。規格上、ゲートの切替間隔（TimeInterval）は１ナノ秒の粒度で設定できる。このため、送信キューに挿入されたフレームが滞りなく送信されるためには、少なくともそのフレームの送信に要する時間以上の間、ゲートの開放状態が維持される必要がある。
このように定義されたＩＥＥＥ ８０２．１Ｑｂｖの動作を実装する場合に、規格を忠実に再現しようとすると、特定の条件下では一種のデッドロック問題が発生する可能性がある。具体的には、ゲートの開放状態のTimeIntervalが短い送信キューに対して、一定サイズ以上のフレームが挿入されると、そのフレームの送信がいつまでも許可されないため、そのキューがデッドロックのような状態に陥る。また、このようなケースでは、問題を引き起こしたフレームの後に同じキューに挿入されたすべてのフレームの送信も一時的にストップする。このため、処理にリアルタイム性（定められた時間内に処理を完了する）を持たせることができない。
ＩＥＥＥ ８０２．１Ｑの規格では、queueMaxSDUおよびmaximum Bridge transit delay と呼ばれるパラメータが定義されている。queueMaxSDUは、ゲート制御情報に基づく通信の規格（ＩＥＥＥ ８０２．１Ｑ）で定義されるメッセージのサイズの最大値に相当する。queueMaxSDUで指定されているサイズより大きなサイズのフレームが送信キューに挿入された場合に、直ちにそのフレームが破棄されることで、上記のようなデッドロックの状態が生じることが回避される。また、queueMaxSDU以下のフレームが送信キューに挿入された場合は、maximum Bridge transit delayで指定された時間でタイムアウトさせて問題を引き起こしているフレームが破棄される。
queueMaxSDUの設定により指定されたサイズより大きなフレームを破棄できる。しかし、規格では、queueMaxSDUの値を設定するときにゲートの開放状態のTimeIntervalは考慮されていない。このため、ゲートの開放期間に送信できるフレームサイズが、queueMaxSDUで指定されているサイズよりも小さい場合には上記の問題を解決できない。
また、規格では、maximum Bridge transit delayの推奨値および最大値として、それぞれ１秒および４秒の値が定められている。しかし、これらの値を用いた場合、デッドロック自体は解消されるものの、通信のリアルタイム性が損なわれる。リアルタイム性を維持するためにmaximum Bridge transit delayの値を単純に短く設定すると、例えば別の送信キューに記憶されている正常なフレームもタイムアウトにより破棄されるなど、望ましくない副作用を引き起こす可能性が生じる。従って、このような副作用を伴わずに上記の問題を解決することができない。
（第１の実施形態）
第１の実施形態にかかる通信システムは、デッドロック問題を引き起こす可能性のある異常フレームをリアルタイムに検知し、異常フレームを必要に応じて適切に処理する。これにより、通信のリアルタイム性が損なわれることを回避可能となる。例えば、異常フレームの後に同じ送信キューに挿入された正常フレームの通信のリアルタイム性を維持することが可能となる。
図１は、第１の実施形態にかかる情報処理システムの構成例を示す図である。図１に示すように、情報処理システムは、Ｍ個（Ｍは２以上の整数）の通信装置１００１～１００Ｍと、制御装置３００と、を備えている。複数の通信装置１００１～１００Ｍと、制御装置３００とは、ネットワークにより接続される。
通信装置１００１～１００Ｍは、例えばＴＳＮに従い通信可能な装置である。通信装置１００１～１００Ｍは同様の機能を備えるため、区別する必要がない場合は単に通信装置１００という。通信装置１００は、通信システムの一例である。
制御装置３００は、通信装置１００を含む、ネットワーク上の通信装置を管理するサーバ装置である。
図２は、第１の実施形態にかかる通信装置１００のハードウェア構成の例を示すブロック図である。図２に示すように、通信装置１００は、メモリ１と、ホストプロセッサ２と、ストレージ３と、Ｎ個（Ｎは１以上の整数）のネットワークインタフェースコントローラ４１～４Ｎと、を備えている。
メモリ１は、一次データを記憶する記憶媒体である。メモリ１は、ホストプロセッサ２のメモリコントローラを介してホストプロセッサ２に接続される。メモリ１は、例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等により実現される。
ホストプロセッサ２は、データを処理する要素である。ホストプロセッサ２は、例えば、ＰＣＩ Ｅｘｐｒｅｓｓ（登録商標）等のバスを用いて、ストレージ３およびネットワークインタフェースコントローラ４１～４Ｎと接続される。
ホストプロセッサ２は、ストレージ３に格納された実行プログラムのイメージをメモリ１に展開し、メモリ１上の命令およびデータを読みながら処理を実行する。処理は、ホストプロセッサ２に備えられた１つまたは複数のコアにより実行される。
ストレージ３は、二次データを記憶する。ストレージ３は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）およびＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等により実現される。
ネットワークインタフェースコントローラ４１～４Ｎは、それぞれホストプロセッサ２をネットワーク２００１～２００Ｎに接続する。ネットワークインタフェースコントローラ４１～４Ｎは同様の機能を備えるため、区別する必要がない場合は単にネットワークインタフェースコントローラ４という。同様に、ネットワーク２００１～２００Ｎは、区別する必要がない場合は単にネットワーク２００という。
ネットワーク２００は、例えばＥｔｈｅｒｎｅｔ（登録商標）である。具体的には、ネットワーク２００は、ＩＥＥＥ ８０２．１で定義された規格に対応したネットワークである。ＩＥＥＥ ８０２．１で定義された規格は、例えば、ＡＶＢ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｂｒｉｄｇｉｎｇ）規格、および、ＴＳＮ（Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ）規格等である。また、ネットワーク２００の種類は任意でよい。ネットワーク２００は、例えばオフィスネットワーク、データセンタ内部のネットワーク、車載ネットワーク、工場内ネットワーク、携帯基地局のネットワーク、および、コア設備のネットワーク等である。
ネットワークインタフェースコントローラ４は、例えばＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、または、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等により実現される。また、ネットワークインタフェースコントローラ４は、ＡＳＩＣ、ＦＰＧＡおよびプロセッサのうち２つまたは３つの組み合わせによって実現してもよい。また、ネットワークインタフェースコントローラ４は内部に上述のメモリ１とは異なるメモリを内蔵していてもよい。また、ネットワークインタフェースコントローラ４は、ホストプロセッサ２とは別のチップとして実装されてもよいし、ＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－Ｃｈｉｐ）として１つのチップとして実装されてもよい。
なお、メモリ１、ストレージ３、および、ネットワークインタフェースコントローラ４は、専用のデータパスでホストプロセッサ２に接続されてもよいし、共用のデータバスを介してホストプロセッサ２に接続されてもよい。
また、通信装置１００は、例えば、ネットワーク上でフレームの送受信を行う終端ノードであってもよいし、ネットワーク上でフレームを中継するスイッチ装置等であってもよい。
図３は、第１の実施形態にかかる通信装置１００の機能構成の一例を示すブロック図である。なお図３は、主に通信装置１００に含まれるホストプロセッサ２（情報処理装置の一例）およびネットワークインタフェースコントローラ４（通信制御装置の一例）の機能構成の例を示す。図３ではネットワークインタフェースコントローラ４を１つのみ記載しているが、図２に示すようにネットワークインタフェースコントローラ４は複数備えられてもよい。
図３に示すように、ホストプロセッサ２は、スケジューリング情報記憶部１２１と、インタフェース部１０１と、算出部１０２と、Ｌ個（Ｌは１以上の整数）のアプリケーション１１０１～１１０Ｌと、を備えている。
スケジューリング情報記憶部１２１は、送信制御で用いられるスケジューリング情報を記憶する。スケジューリング情報は、例えば、ＩＥＥＥ ８０２．１Ｑで定義されるEnhancements for scheduled trafficの制御を実行するために用いられるゲート制御リスト（Ｇａｔｅ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）、および、ゲート制御リスト以外の情報を含む。ゲート制御リスト以外の情報は、例えば、ゲート制御を開始する時刻である。スケジューリング情報記憶部１２１は、例えばホストプロセッサ２内部に備えられるメモリにより実現される。スケジューリング情報記憶部１２１は、メモリ１により実現されてもよい。
ゲート制御リストは、予めストレージ３などに記憶しておいたものを入力して用いてもよいし、例えばＩＥＥＥ ８０２．１Ｑｃｃで定義されるＣＮＣ（Ｃｅｎｔｒａｌｉｚｅｄ Ｎｅｔｗｏｒｋ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）によってネットワーク２００経由で入力して用いてもよい。
図４は、ゲート制御リストの例を示す図である。図４に示すゲート制御リストは、Ｔ００からＴ０５までの６つのエントリを含む。各エントリは、８つのトラヒッククラスそれぞれに対応するキューのゲート状態と、タイムインターバルとを含む。ＴＣ０～ＴＣ７はトラヒッククラスを意味する。例えばＴＣ７は、７番のトラヒッククラスを表す。各トラヒッククラスのゲート状態は“ｏ”および“Ｃ”で表される。“ｏ”は、ゲートが開放（オープン）されていることを意味する。“Ｃ”は、ゲートが閉じられていることを意味する。ゲート状態は、トラヒッククラスのキューにおける送信が許可されるか否かを示す。
タイムインターバルは、エントリが継続する時間を表す。例えば図４の例ではＴ００のエントリのタイムインターバルには、１２８μｓが設定されている。これは、Ｔ００のエントリが１２８μｓ継続することを示している。Ｔ００から順にタイムインターバルの分、設定されたゲート状態を維持し、Ｔ０１、Ｔ０２、・・・と時間が経過するとともに、各トラヒッククラスのゲートのゲート状態が切り替えられる。最後のエントリ（図４の例ではＴ０５）が終わるとＴ００に戻り、処理が繰り返される。
図３に戻り、インタフェース部１０１は、アプリケーション１１０１～１１０Ｌと、ネットワークインタフェースコントローラ４との間のインタフェースとして機能する。インタフェース部１０１は、汎用ＯＳ（オペレーティングシステム）などに組み込まれているネットワークインタフェースドライバとして機能してもよい。
算出部１０２は、ゲート制御リストを参照して、異常を判定するための判定情報を算出する。例えば算出部１０２は、送信するメッセージのサイズがキューにより送信可能なサイズより大きいことにより生じる異常を判定するための判定情報を算出する。判定情報の算出処理の詳細は後述する。
アプリケーション１１０１～１１０Ｌは、メッセージを送信する処理を含む各種情報処理を実行する。アプリケーション１１０１～１１０Ｌを区別する必要がない場合は単にアプリケーション１１０という。
上記各部（インタフェース部１０１、算出部１０２、および、アプリケーション１１０）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。
ネットワークインタフェースコントローラ４は、受付部２０１と、異常検知部２０２と、異常処理部２０３と、ゲート処理部２０４と、ゲート制御リスト記憶部２２１と、判定情報記憶部２２２と、フレーム記憶部２２３と、を備えている。
ゲート制御リスト記憶部２２１は、ホストプロセッサ２から受け付けられたゲート制御リストを記憶する。
判定情報記憶部２２２は、ホストプロセッサ２から受け付けられた異常フレームサイズを記憶する。異常フレームサイズは、判定情報の一例である。異常フレームサイズは、送信キューごとに算出される。従って、判定情報記憶部２２２は送信キューごとに異常フレームサイズを記憶する。
フレーム記憶部２２３は、ホストプロセッサ２から受け付けられた送信対象とするフレーム（送信フレーム）を記憶する。
受付部２０１は、ホストプロセッサ２から送信された各種情報の入力を受け付ける。例えば受付部２０１は、ゲート制御リストおよび判定情報（異常フレームサイズ）を受け付ける。
異常検知部２０２は、インタフェース部１０１から受け取ったフレームの異常を検知する。異常検知部２０２は、判定情報記憶部２２２に記憶された異常フレームサイズを用いて異常を検知する。
異常処理部２０３は、フレームの異常が検知された場合に、検知された異常に応じた異常処理を実行する。なお異常が検知されなかった場合、異常処理部２０３は、フレームを送信するために、受け取ったフレームをフレーム記憶部２２３に記憶する。
ゲート処理部２０４は、ゲート制御リストに従うフレームの送信処理を行う。ゲート処理部２０４は、ＩＥＥＥ ８０２．１Ｑｂｖで定められているタイムアウェアシェーパとして機能してもよい。例えば、ゲート処理部２０４は、ゲート制御リストの読み込み、各トランスミッションゲートの制御、ガードバンドの判定処理、トランスミッションセレクション、および、フレームを各送信キューから取り出して転送する処理などを実行する。
上記各部（受付部２０１、異常検知部２０２、異常処理部２０３、および、ゲート処理部２０４）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。
図３に示すように、ホストプロセッサ２の算出部１０２は、受付部２０１と接続されている。異常検知部２０２および異常処理部２０３は、インタフェース部１０１およびフレーム記憶部２２３の間のデータパス上に位置している。受付部２０１および異常検知部２０２は、判定情報記憶部２２２を介して接続されている。また、異常処理部２０３およびインタフェース部１０１は、異常に関する情報（異常フレームに関する情報）をフィードバックするために接続されている。
異常に関する情報は、例えば以下の情報を含む。
・フレーム送信を要求したアプリケーション１１０に関する情報
・フレーム送信の要求が発生したタイミングに関する情報
・フレームのヘッダに含まれる情報
・フレームの優先度に関する情報
・フレームのサイズに関する情報
・送信キューに関する情報（識別情報など）
・送信キューから送信が許可されるフレームサイズに関する情報
次に、判定情報の算出処理の詳細について説明する。以下では、判定情報として異常フレームサイズを算出する例を示す。
まず算出部１０２は、異常フレームサイズを送信キューごとに算出するための事前準備を行う。具体的には、算出部１０２は、スケジューリング情報記憶部１２１に記憶されているゲート制御リストのゲートステートおよびゲート制御リストのタイムインターバルを用いて、ゲートの継続オープン時間（continuousOpenDuration、COD）を送信キューごとに算出する。継続オープン時間は、ゲートのオープン状態が継続する時間を表す。継続オープン時間は、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間と言い換えることができる。
図５は、図４のゲート制御リストから算出される継続オープン時間の例を示す図である。例えば、トラヒッククラスＴＣ７のエントリＴ０２については、Ｔ０２からＴ０３まで“ｏ”が継続しており、Ｔ０４で“Ｃ”となっている。Ｔ０２およびＴ０３のタイムインターバルは、５１２μｓおよび１２８μｓであるため、Ｔ０２の先頭からは“ｏ”は５１２＋１２８＝６４０μｓ継続することになる。同様に、Ｔ０３の場合にはＴ０４で“Ｃ”になるので、“ｏ”は１２８μｓ継続することになる。なお、ゲート制御リストは最終エントリまで進むと最初に戻る。Ｔ０５の場合は、Ｔ０５からＴ００まで“ｏ”が継続しているため、“ｏ”は５１２＋１２８＝６４０μｓ継続することになる。トラヒッククラスＴＣ０のように常に“ｏ”の場合には、ゲート制御リストが変更にならない限り“ｏ”が続くため、継続オープン時間は無限大（∞）となる。
次に、図６を参照して異常フレームサイズの算出について説明する。図６は、異常フレームサイズ（判定情報）の算出処理の一例を示すフローチャートである。なお、以下では、送信キュー（トラヒッククラス）が８つであり、０～７の数値で表される識別情報（qid）により送信キューが識別される場合を例に説明する。送信キューの個数および識別方法はこれに限られるものではない。
算出部１０２は、継続オープン時間の最大値（maximumContinuousOpenDuration、maxCOD）を送信キューごとに算出する（ステップＳ１０１）。算出部１０２は、各送信キューのmaxCODおよびネットワークのリンク速度（通信速度）を用いて、各送信キューから正常に送信できるフレームサイズの最大値（maximumPermissibleFrameSize、maxPFS）を、送信キューごとに算出する（ステップＳ１０２）。例えば、ｉ番目（ｉは０～７の整数）の送信キューのmaxCODが１０２４ナノ秒、リンク速度が１Ｇｂｐｓの場合、ｉ番目の送信キューのmaxPFSの値を以下の（１）式のように算出することができる。
maxPFSi＝1024×10-9×109（bps）／8＝128（byte） ・・・（１）
このとき、算出部１０２は、メディア依存オーバーヘッドのビット数を考慮して各送信キューのmaxPFSの値を補正してもよい（ステップＳ１０３）。メディア依存オーバーヘッドは、例えば、通信媒体に応じて設定された終端のインターパケットギャップ、および、プリアンブルなどである。例えば、メディア依存オーバーヘッドのビット数の合計値を２０バイトと仮定すると、上記の例では補正後のmaxPFSの値は１２８－２０＝１０８バイトとなる。
次に、算出部１０２は、各送信キューのmaxPFSの値をもとに各送信キューの異常フレームサイズ（localAbnormalFrameSize、localAFS）を、以下の（２）式により算出する（ステップＳ１０４）。
localAFSi＝min（maxPFSi，queueMaxSDUi）＋1 ・・・（２）
localAFSiは、ｉ番目の送信キューのlocalAFSの値を示す。maxPFSiは、ｉ番目の送信キューのmaxPFSの値を示す。queueMaxSDUiは、ｉ番目の送信キューのqueueMaxSDUの値を示す。
（２）式の計算では、算出部１０２は、各送信キューのmaxPFSとqueueMaxSDUの値から、各送信キューのそれぞれのlocalAFSの値を算出する。具体的には、算出部１０２は、各送信キューのmaxPFSとqueueMaxSDUとを比較し、小さい値を選択する。
その後、算出部１０２は、この選択した値に、送信データサイズの最小単位（例：１バイト、１ビットなど）の値を加算してlocalAFSを算出する。（２）式は、最小単位を示す値が１の場合の例である。送信データサイズの最小単位を示す値が１以外の場合は、（２）式で加算する値を、送信データサイズの最小単位に合わせて調整してもよい。例えば最小単位を示す値が８（８バイト、８ビットなど）の場合、算出部１０２は、以下の（３）式を用いて異常フレームサイズを算出してもよい。
localAFSi＝min（maxPFSi，queueMaxSDUi）＋8 ・・・（３）
ｉ番目の送信キューのmaxPFSの補正後の値を１０８バイトと仮定し（maxPFSi＝108）、さらに、ｉ番目の送信キューのqueueMaxSDUの値を１５００バイトと仮定すると（queueMaxSDUi＝1500）、算出部１０２は、ｉ番目の送信キューのlocalAFSを以下の（４）式のように算出することができる。
localAFSi＝min（108，1500）＋1＝109（byte） ・・・（４）
maxPFSの補正を行わない場合は、算出部１０２は、localAFSを以下の（５）式のよう算出することができる。
localAFSi＝min（128，1500）＋1＝129（byte） ・・・（５）
このように、例えばＩＥＥＥ ８０２．１Ｑｂｖで定められているガードバンドを算出する際にメディア依存オーバーヘッドのビット数を考慮する場合は、補正後のmaxPFSに基づいて算出されたlocalAFSの値（109バイト）を採用してもよい。また、例えば、ガードバンドを算出する際にメディア依存オーバーヘッドのビット数を考慮しない場合は、補正前のmaxPFSに基づいて算出されたlocalAFSの値（129バイト）を採用してもよい。
算出部１０２は、このようにして算出した異常フレームサイズを、ネットワークインタフェースコントローラ４（受付部２０１）に出力する。
ネットワークインタフェースコントローラ４の受付部２０１は、異常フレームサイズの算出結果を受け取り、判定情報記憶部２２２に記憶する（ステップＳ１０５）。このとき、受付部２０１は、異常フレームのサイズに関する情報として各送信キューのmaxPFSの値を受け取ってもよい。
その後、算出部１０２は、ゲート制御リストまたはリンク速度が変更されたか否かを判定する（ステップＳ１０６）。変更された場合（ステップＳ１０６：Ｙｅｓ）、ステップＳ１０１に戻り、算出部１０２は、更新された新しい値を用いて異常フレームサイズの算出をやり直す。
変更されていない場合（ステップＳ１０６：Ｎｏ）、算出部１０２は、他の通信装置１００、または、制御装置３００から異常に関する情報を受け取ったか否かを判定する（ステップＳ１０７）。受け取った場合（ステップＳ１０７：Ｙｅｓ）、算出部１０２は、必要に応じてステップＳ１０１に戻り異常フレームサイズの値を更新する。
上記のように、異常に関する情報は、例えば、異常が検知された送信キューの識別情報、および、異常が検知された送信キューの異常フレームサイズremoteAFSなどを含む。
例えば算出部１０２は、以下の（６）式に基づいて異常フレームサイズの値を更新することができる。
localAFSNewi＝min（localAFSi，remoteAFSi） ・・・（６）
localAFSNewiは、ｉ番目の送信キューの新しいlocalAFSの値を示す。localAFSiは、ｉ番目の送信キューの現在のlocalAFSの値を示す。remoteAFSiは、外部の通信装置などから受け取ったｉ番目の送信キューのremoteAFSの値を示す。
算出部１０２は、（６）式により、現在のlocalAFSとremoteAFSの値を用いて、新しいlocalAFSの値を算出する。具体的には、算出部１０２は、localAFSiとremoteAFSiの値とを比較して、小さい値をlocalAFSNewiとして採用する。
算出部１０２は、queueMaxSDUの初期値、および、queueMaxSDUの変更後の値の少なくとも一方を、判定情報に基づいて決定してもよい。queueMaxSDUの変更後の値とは、例えばqueueMaxSDUの値が既に設定されている場合に、設定済みの値を変更するための新たな値を意味する。例えば、各送信キューのqueueMaxSDUの値を変更することが許される場合は、（２）式および（６）式によって算出されたlocalAFSを用いて、各送信キューのqueueMaxSDUを調整してもよい。例えば、算出部１０２は、（７）式に基づいて新しいqueueMaxSDUの値（queueMaxSDUNew）を決定することができる。
queueMaxSDUNewi＝min（localAFSi－1、queueMaxSDUi） ・・・（７）
queueMaxSDUNewiは、ｉ番目の送信キューの新しいqueueMaxSDUの値を示す。localAFSiは、ｉ番目の送信キューのlocalAFSの値を示す。queueMaxSDUiは、ｉ番目の送信キューの現在のqueueMaxSDUの値を示す。
算出部１０２は、（７）式により、localAFSとqueueMaxSDUの値を用いて、新しいqueueMaxSDUの値（queueMaxSDUNew）を算出する。具体的には、算出部１０２は、localAFSiから、送信データサイズの最小単位（例：１バイト、１ビットなど）の値を減算する。その後、算出部１０２は、減算後の値とqueueMaxSDUiの値とを比較して、小さい値をqueueMaxSDUNewiとして採用する。
送信データサイズの最小単位を示す値が１以外の場合は、（２）式の説明と同じような方法で、localAFSから減算する値を送信データサイズの最小単位に合わせて調整してもよい。例えば最小単位を示す値が８（８バイト、８ビットなど）の場合、算出部１０２は、以下の（８）式を用いて新しいqueueMaxSDUの値を算出してもよい。
queueMaxSDUNewi＝min（localAFSi－8、queueMaxSDUi） ・・・（８）
算出部１０２は、例えば、以下の（９）式を用いてqueueMaxSDUの初期値を算出することができる。
queueMaxSDUi＝maxPFSi ・・・（９）
初期値の算出方法はこれに限られるものではない。例えば算出部１０２は、制御装置３００から指定された値を初期値として設定してもよいし、ネットワークのＭＴＵ（Maximum Transmission Unit）に基づいて初期値を決定してもよい。
上記の算出方法に従いlocalAFSまたはqueueMaxSDUの値を決定することで、例えば終端ノード間の通信経路上の中継ノード（スイッチ等の通信装置）で異常フレームとして判定される可能性のあるフレーム（潜在的な異常フレーム）を早い段階で検知することが可能となる。すなわち、送信ノード、または、送信ノードに近い中継ノードなどで潜在的な異常フレームを特定し、それに対処することができるようになる。これにより、通信経路上の帯域と、中継ノードの計算リソースおよびバッファ領域などを効率的に利用することが可能となる。
また、本実施形態では、（７）～（９）式により、queueMaxSDUについて、送信キューごとに個別の値（同一の値でもよいし、異なる値でもよい）を決定することができる。このため、異常をより高精度に検知可能となる。
次に、異常フレームの検知および異常フレームを検知した場合の異常処理について説明する。図７は、異常処理等を含むフレーム送信処理の一例を示すフローチャートである。
ホストプロセッサ２上で動作するアプリケーション１１０が新しいフレームを送信しようとすると、インタフェース部１０１は、フレームの送信要求を発行する。また、例えば、他の通信装置１００からフレームを受け取って、別の通信装置１００に転送する際にもフレームの送信要求が発行される。
異常検知部２０２は、フレームの送信要求を受信したか否かを判定する（ステップＳ２０１）。受信していない場合（ステップＳ２０１：Ｎｏ）、受信するまで処理が繰り返される。受信した場合（ステップＳ２０１：Ｙｅｓ）、異常検知部２０２は、送信が要求されたフレームをインタフェース部１０１から受け取り、受け取ったフレームの送信キューを識別する（ステップＳ２０２）。
例えば、異常検知部２０２は、インタフェース部１０１から直接的に指定された送信キューの識別情報（qid）、または、フレームのヘッダ等を参照して、送信キューを識別する。異常検知部２０２は、例えば、フレームのＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）タグのＰＣＰ（Ｐｒｉｏｒｉｔｙ Ｃｏｄｅ Ｐｏｉｎｔ）の値から優先度を判別し、その優先度に関連付けられた送信キューを識別してもよい。
次に、異常検知部２０２は、受け取ったフレームのサイズと識別した送信キューのqueueMaxSDUの値とを比較して、フレームを破棄すべきか否か決定する。例えば異常検知部２０２は、フレームのサイズがqueueMaxSDUより大きいか否かを判定する（ステップＳ２０３）。フレームのサイズがqueueMaxSDUより大きい場合（ステップＳ２０３：Ｙｅｓ）、異常処理部２０３は、フレームを破棄し（ステップＳ２０４）、処理を終了する。
フレームのサイズがqueueMaxSDU以下の場合（ステップＳ２０３：Ｎｏ）、異常検知部２０２は、フレームのサイズと識別した送信キューのlocalAFSとを比較して、送信しようとしているフレームが一時的なデッドロック状態を引き起こす可能性のある異常フレームか否かを判断する。例えば異常検知部２０２は、フレームのサイズがlocalAFS以上であるか否かを判定する（ステップＳ２０５）。なお異常検知部２０２は、localAFSの代わりに、異常フレームのサイズに関する情報として受け取ったmaxPFSを用いて異常の検知を行ってもよい。
フレームのサイズがlocalAFS未満の場合（ステップＳ２０５：Ｎｏ）、異常検知部２０２は、フレームを異常処理部２０３に受け渡し、異常が発生していないことを通知する（ステップＳ２０６）。これにより受け取ったフレームは正常フレームとして送信処理が継続される。すなわち異常処理部２０３は、フレーム記憶部２２３の送信キューにフレームを挿入し、通常のフレームの送信処理を行い（ステップＳ２０７）、処理を終了する。
フレームのサイズがlocalAFS以上の場合（ステップＳ２０５：Ｙｅｓ）、異常検知部２０２は、フレームを異常処理部２０３に受け渡し、異常が発生したことを通知する（ステップＳ２０８）。また、異常処理部２０３は、異常に関する情報を他の通信装置１００、または、制御装置３００などにネットワーク経由で通知してもよい。異常に関する情報を通知する場合の処理の詳細は後述する。その後、異常処理部２０３は、異常フレームを破棄し（ステップＳ２０９）、処理を終了する。
次に、異常に関する情報を通知する場合の処理について説明する。図８は、異常通知処理の一例を示すフローチャートである。
異常処理部２０３は、異常に関する情報を制御装置３００に通知する（ステップＳ３０１）。通知を受信した制御装置３００は、通信経路上の他の通信装置１００に対して異常フレームサイズの更新を指示する（ステップＳ３０２）。例えば制御装置３００は、異常が検知された送信キューの識別情報、および、更新する異常フレームサイズを示す情報などを含む更新指示を他の通信装置１００に送信する。また制御装置３００は、異常フレームの送信元である通信装置１００に対しては、異常処理の実行を指示する（ステップＳ３０３）。
図８は、制御装置３００が異常処理等を管理する場合の異常通知処理の例である。制御装置３００を用いず、複数の通信装置１００の間で情報を送受信して異常処理を実行するように構成してもよい。なおこの場合、情報処理システムは制御装置３００を備えないように構成されてもよい。図９は、異常通知処理の他の例を示すフローチャートである。
ある通信装置１００の異常検知部２０２により異常が検知された場合、この通信装置１００の異常処理部２０３は、異常に関する情報を、隣接する他の通信装置１００に通知する（ステップＳ４０１）。通知を受信した通信装置１００の異常処理部２０３は、異常が検知されたフレームの送信元であるか否かを判定する（ステップＳ４０２）。例えば異常処理部２０３は、異常の関する情報に含まれる、アプリケーション１１０に関する情報、および、フレームのヘッダの情報などを参照して、フレームの送信元であるかを判定する。
フレームの送信元である場合（ステップＳ４０２：Ｙｅｓ）、異常処理部２０３は、送信したフレームに対する異常処理を実行する（ステップＳ４０５）。フレームの送信元でない場合（ステップＳ４０２：Ｎｏ）、異常処理部２０３は、異常フレームサイズを、例えば上記の（６）式に従い更新する（ステップＳ４０３）。また、異常処理部２０３は、異常に関する情報を、さらに隣接する他の通信装置１００に通知する（ステップＳ４０４）。
（変形例１）
各送信キューのqueueMaxSDUの値を変更することが許される場合は、例えば上記（７）式に従い算出されたqueueMaxSDUNewiの値を用いて異常を検知するように構成されてもよい。すなわち、localAFSを用いず、変更されたqueueMaxSDUNewiの値のみを用いて異常を検知するように構成されてもよい。
図１０は、このように構成される変形例１のフレーム送信処理の一例を示すフローチャートである。ステップＳ５０１～ステップＳ５０４までは図７のステップＳ２０１～ステップＳ２０４と同様であるため説明を省略する。
本変形例では、フレームのサイズがqueueMaxSDU以下の場合（ステップＳ２０３：Ｎｏ）、異常検知部２０２は、フレームを異常処理部２０３に受け渡し、異常が発生していないことを通知する（ステップＳ５０５）。これにより受け取ったフレームは正常フレームとして送信処理が継続される。すなわち異常処理部２０３は、フレーム記憶部２２３の送信キューにフレームを挿入し、通常のフレームの送信処理を行い（ステップＳ５０６）、処理を終了する。
本変形例では、ゲート制御リストおよびリンク速度などに応じて動的にqueueMaxSDUを変更することができる。すなわち、例えばゲートの開放状態のTimeIntervalを考慮してqueueMaxSDUの値を設定することができる。このため、フレームの破棄をより適切に判定し、デッドロックの状態が生じることを回避可能となる。
（変形例２）
変形例２では、異常処理部２０３は、異常フレームを破棄するとともに、異常フレームに関する情報をアプリケーション１１０に通知する。図１１は、変形例２のフレーム送信処理の一例を示すフローチャートである。ステップＳ６０１～ステップＳ６０８までは図７のステップＳ２０１～ステップＳ２０８と同様であるため説明を省略する。
本変形例では、異常処理部２０３は、異常フレームを破棄し、破棄したフレームに関する情報を上位のインタフェース、すなわちインタフェース部１０１に通知する（ステップＳ６０９）。インタフェース部１０１は、異常フレームの送信要求を発行したアプリケーション１１０に異常を通知する（ステップＳ６１０）。
これにより、異常フレームの送信元であるアプリケーション１１０に対して必要な対応を促すことができる。例えば、アプリケーション１１０は、異常フレームのサイズをlocalAFS未満になるように調整してからフレームを再送することができる。また、フレームのサイズがlocalAFS未満に収まらない場合は、アプリケーション１１０は、異常フレームを複数の正常フレームに分割して送信してもよい。このとき、アプリケーション１１０は、分割した各フレームのサイズがlocalAFS未満になるように調整する。
また、別の対処方法として、アプリケーション１１０は、異なる送信キューを使って異常フレームの再送を試みることもできる。このとき、アプリケーション１１０は、各送信キューのlocalAFSの値を確認して、再送を試みるフレームのサイズがlocalAFS未満になるような送信キューを選択する。
（変形例３）
変形例３では、異常処理部２０３は、異常フレームを破棄する代わりに、異常フレームを分割して送信する。図１２は、変形例３のフレーム送信処理の一例を示すフローチャートである。ステップＳ７０１～ステップＳ７０８までは図７のステップＳ２０１～ステップＳ２０８と同様であるため説明を省略する。
本変形例では、異常処理部２０３は、異常フレームを送信しようとしている送信キューのlocalAFSの値を用いて、異常フレームを複数の正常フレームに分割する（ステップＳ７０９）。このとき、異常処理部２０３は、分割した各フレームのサイズが、送信キューのlocalAFS未満になるように調整する。異常処理部２０３は、フレーム記憶部２２３の送信キューに分割したフレームを挿入し、通常のフレームの送信処理を行い（ステップＳ７１０）、処理を終了する。
また、別の対処方法として、異常処理部２０３は、ＩＥＥＥ ８０２．１Ｑｂｕのフレームプリエンプションの仕組みを利用してフレームを分割してもよい。この場合、異常処理部２０３は、異常フレームをプリエンプション可能なMAC （Preemptable MAC）に転送する。フレームの分割処理自体は、Preemptable MACの内部で行われる。Preemptable MACは、フレームを分割して送信する制御部に相当する。
このように、第１の実施形態にかかる通信装置１００は、各送信キューからフレームを送信する際にゲート制御リストの制約により一時的なデッドロック状態を引き起こす可能性のある異常フレームを検知し、デッドロック状態を回避するために異常フレームを処理する。これにより、ＩＥＥＥ ８０２．１Ｑｂｖに基づく送信制御による通信のリアルタイム性を維持することが可能となる。
（第２の実施形態）
ネットワークインタフェースコントローラが備える機能の一部は、ホストプロセッサ内に備えられてもよい。第２の実施形態では、ホストプロセッサが異常検知部、異常処理部、および、判定情報記憶部を備える例を説明する。図１３は、第２の実施形態にかかる通信装置に含まれるホストプロセッサ２－２およびネットワークインタフェースコントローラ４－２の機能構成の一例を示す図である。
図１３に示すように、ホストプロセッサ２－２は、スケジューリング情報記憶部１２１と、インタフェース部１０１と、算出部１０２－２と、Ｌ個のアプリケーション１１０１～１１０Ｌと、異常検知部２０２と、異常処理部２０３と、判定情報記憶部２２２－２と、を備えている。また、ネットワークインタフェースコントローラ４－２は、受付部２０１と、ゲート処理部２０４と、ゲート制御リスト記憶部２２１と、フレーム記憶部２２３と、を備えている。
算出部１０２－２は、算出した判定情報（異常フレームサイズ）をホストプロセッサ２－２内の判定情報記憶部２２２－２に記憶する点が、第１の実施形態の算出部１０２と異なっている。
判定情報記憶部２２２－２は、受付部２０１を介さずに、算出部１０２－２から出力された判定情報を受け取って記憶する点が、第１の実施形態の判定情報記憶部２２２と異なっている。
他の構成は、第１の実施形態の機能構成を示す図３と同様であるため同一の符号を付し、説明を省略する。また、各部による処理の流れは、第１の実施形態（図６～図１２）と同様であるため説明を省略する。
（変形例４）
図１４は、第２の実施形態の変形例にかかる通信装置に含まれるホストプロセッサ２－２ｂおよびネットワークインタフェースコントローラ４－２の機能構成の一例を示す図である。本変形例では、判定情報記憶部２２２－２、異常検知部２０２、および、異常処理部２０３が、インタフェース部１０１－２ｂの内部機能として実装される。
このとき、例えば、汎用ＯＳなどに組み込まれているネットワークインタフェースドライバがインタフェース部１０１として機能し、異常検知（異常検知部２０２）および異常処理（異常処理部２０３）を実行してもよい。
このように、第２の実施形態にかかる通信システムでは、第１の実施形態と各部の配置が異なるが、第１の実施形態と同様の機能を実現することができる。
（第３の実施形態）
ホストプロセッサが備える機能の一部は、ネットワークインタフェースコントローラ内に備えられてもよい。第３の実施形態では、ネットワークインタフェースコントローラが算出部を備える例を説明する。図１５は、第３の実施形態にかかる通信装置に含まれるホストプロセッサ２－３およびネットワークインタフェースコントローラ４－３の機能構成の一例を示す図である。
図１５に示すように、ホストプロセッサ２－３は、スケジューリング情報記憶部１２１と、インタフェース部１０１と、Ｌ個のアプリケーション１１０１～１１０Ｌと、を備えている。また、ネットワークインタフェースコントローラ４－２は、算出部１０２－３と、受付部２０１と、異常検知部２０２と、異常処理部２０３と、ゲート処理部２０４と、ゲート制御リスト記憶部２２１と、判定情報記憶部２２２－３と、フレーム記憶部２２３と、を備えている。
算出部１０２－３は、受付部２０１を介して入力されたゲート制御リストを参照して判定情報を算出し、判定情報記憶部２２２－３に記憶する点が、第１の実施形態の算出部１０２と異なっている。
判定情報記憶部２２２－３は、受付部２０１を介さずに、算出部１０２－３から出力された判定情報を受け取って記憶する点が、第１の実施形態の判定情報記憶部２２２と異なっている。
他の構成は、第１の実施形態の機能構成を示す図３と同様であるため同一の符号を付し、説明を省略する。また、各部による処理の流れは、第１の実施形態（図６～図１２）と同様であるため説明を省略する。
（変形例５）
図１６は、第３の実施形態の変形例にかかる通信装置に含まれるホストプロセッサ２－３およびネットワークインタフェースコントローラ４－３ｂの機能構成の一例を示す図である。本変形例では、判定情報記憶部２２２－３、異常検知部２０２、および、異常処理部２０３がゲート処理部２０４－３ｂの内部機能として実装される。またゲート処理部２０４－３ｂは、ゲート部２０５－３ｂをさらに備えている。ゲート部２０５－３ｂは、例えばゲート制御リストのゲート状態（“ｏ”および“Ｃ”）に従いフレームを出力する機能である。
また、本変形例では、異常検知部２０２および異常処理部２０３が、フレーム記憶部２２３－３ｂとゲート部２０５－３ｂの間に配置される。例えば、フレーム記憶部２２３－３ｂからフレームを読み出してゲート部２０５－３ｂに渡す間に異常検知（異常検知部２０２）と異常処理（異常処理部２０３）が実行される。
ゲート処理部２０４－３ｂ内のトランスミッションセレクションアルゴリズムの機能の中に異常検知部２０２および異常処理部２０３の処理が組み込まれてもよい。
（変形例６）
図１７は、第３の実施形態の他の変形例にかかる通信装置に含まれるホストプロセッサ２－３およびネットワークインタフェースコントローラ４－３ｃの機能構成の一例を示す図である。本変形例では、ゲート部２０５－３ｂとネットワークとの間に、Express MAC２１１－３ｃおよびPreemptable MAC２１２－３ｃがそれぞれ接続される。
異常処理部２０３は、正常フレームをゲート部２０５－３ｂ経由でExpress MAC２１１－３ｃに転送してもよい。異常処理部２０３は、異常フレームをゲート部２０５－３ｂ経由でPreemptable MAC２１２－３ｃに転送してもよい。
図１８は、第３の実施形態の変形例６におけるフレーム送信処理の一例を示すフローチャートである。ステップＳ８０１～ステップＳ８０２までは図７のステップＳ２０１～ステップＳ２０２と同様であるため説明を省略する。
本変形例では、ゲート処理部２０４－３ｂ内の異常検知部２０２が、フレーム記憶部２２３－３ｂの送信キューからフレームを受け取る（ステップＳ８０３）。
ステップＳ８０４～ステップＳ８０７までは図７のステップＳ２０３～ステップＳ２０６と同様であるため説明を省略する。また、ステップＳ８０９は、図７のステップＳ２０８と同様であるため説明を省略する。
本変形例では、異常が発生していない場合、異常処理部２０３は、正常フレームをゲート部２０５－３ｂ経由でExpress MAC２１１－３ｃに転送する（ステップＳ８０８）。また異常が発生した場合、異常処理部２０３は、異常フレームをゲート部２０５－３ｂ経由でPreemptable MAC２１２－３ｃに転送する（ステップＳ８１０）。
このように、本変形例では、２つのＭＡＣ（Express MAC２１１－３ｃ、Preemptable MAC２１２－３ｃ）を適切に使い分けることで、ＩＥＥＥ ８０２．１Ｑｂｕのフレームプリエンプションの仕組みを利用したフレームの分割および送信が可能となる。
以上説明したとおり、第１から第３の実施形態によれば、通信のリアルタイム性が損なわれることを回避可能となる。
（変形例７）
これまでは算出部が異常フレームサイズを判定情報として算出する例を説明した。例えば算出部は、上記（２）式により、異常フレームサイズlocalAFSを算出した。算出部は、異常フレームサイズlocalAFSを算出可能な情報を判定情報として算出してもよい。例えば算出部は、以下の情報を判定情報として算出してもよい。
・継続オープン時間の最大値（maxCOD）
・正常に送信できるフレームサイズの最大値（maxPFS）
これらの判定情報を用いる場合、例えば、判定情報を受け取ったネットワークインタフェースコントローラ（異常検知部など）が、受け取った判定情報から上記の各式を用いて異常フレームサイズlocalAFSを算出すればよい。
（変形例８）
上記実施形態は、１つの通信装置（通信システム）がホストプロセッサおよびネットワークインタフェースコントローラを備える例である。ホストプロセッサおよびネットワークインタフェースコントローラは、物理的に独立した複数の装置内の機能として実現されてもよい。例えば、本変形例の通信システムは、ホストプロセッサに相当する機能を備える情報処理装置と、ネットワークインタフェースコントローラに相当する機能を備える通信制御装置と、がネットワークで接続された構成とすることができる。
第１～第３の実施形態の各記憶部（スケジューリング情報記憶部、ゲート制御リスト記憶部、判定情報記憶部およびフレーム記憶部）は、通信装置に内蔵または外付けされたメモリまたはハードディスク、若しくは、ＣＤ－Ｒ、ＣＤ－ＲＷ、ＤＶＤ－ＲＡＭ、および、ＤＶＤ－Ｒなどの記憶媒体などを適宜利用して実現することができる。
第１～第３の実施形態にかかる通信システムで実行されるプログラムは、ＲＯＭ（Read Only Memory））等に予め組み込まれて提供される。
第１～第３の実施形態にかかる通信システムで実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
さらに、第１～第３の実施形態にかかる通信システムで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１～第３の実施形態にかかる通信システムで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
第１～第３の実施形態にかかる通信システムで実行されるプログラムは、コンピュータを上述した通信システムの各部として機能させうる。このコンピュータは、コンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
１ メモリ
２、２－２、２－２ｂ、２－３ ホストプロセッサ
３ ストレージ
４１～４Ｎ ネットワークインタフェースコントローラ
１００１～１００Ｍ 通信装置
１０１ インタフェース部
１０２、１０２－２、１０２－３ 算出部
１１０１～１１０Ｌ アプリケーション
１２１ スケジューリング情報記憶部
２００１～２００Ｎ ネットワーク
２０１ 受付部
２０２ 異常検知部
２０３ 異常処理部
２０４、２０４－３ｂ ゲート処理部
２０５－３ｂ ゲート部
２２１ ゲート制御リスト記憶部
２２２、２２２－２、２２２－３ 判定情報記憶部
２２３、２２３－３ｂ フレーム記憶部
３００ 制御装置

Claims (11)

  1. 複数のキューそれぞれに対応する複数のゲートを開くか否かを定める複数のエントリを含むゲート制御情報に基づいて、送信するメッセージのサイズが前記キューにより送信可能なサイズより大きいことにより生じる異常を判定するための判定情報を算出する算出部、を備え、
    前記異常は、前記メッセージの送信が許可されないことにより前記キューがデッドロックの状態となる異常であり、
    前記判定情報は、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、および、前記ゲート制御情報に基づく通信の規格で定義されるメッセージのサイズの最大値、のうち小さい値に基づく情報、
    複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値、および、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、のうち少なくとも１つである、
    通信システム。
  2. 前記判定情報を用いて前記異常を検知する異常検知部をさらに備える、
    請求項１に記載の通信システム。
  3. 検知された前記異常に応じた異常処理を実行する異常処理部をさらに備える、
    請求項２に記載の通信システム。
  4. 前記異常処理は、前記異常が生じないサイズとなるように前記メッセージを分割する処理、前記メッセージを分割して送信する制御部に対して前記メッセージを出力する処理、前記異常に関する情報を前記メッセージの送信元のアプリケーションに通知する処理、前記異常が生じた前記メッセージを破棄する処理、および、前記異常に関する情報をアプリケーションとのインタフェースであるインタフェース部に通知する処理の少なくとも１つである、
    請求項３に記載の通信システム。
  5. 前記算出部は、前記ゲート制御情報が変更された場合、通信速度が変更された場合、ネットワークにより接続される他の通信装置から異常に関する情報を受信した場合、および、ネットワークにより接続される他の通信装置を管理する制御装置から異常に関する情報を受信した場合、の少なくともいずれかの場合に、前記判定情報を算出する、
    請求項１に記載の通信システム。
  6. 前記異常が検知された場合に、ネットワークにより接続される他の通信装置、および、ネットワークにより接続される他の通信装置を管理する制御装置、の少なくとも一方に前記異常に関する情報を通知する異常処理部をさらに備える、
    請求項１に記載の通信システム。
  7. 前記算出部を備えるプロセッサと、
    前記判定情報を用いて前記異常を検知する異常検知部を備えるネットワークインタフェースコントローラと、を備える、
    請求項１に記載の通信システム。
  8. 情報処理装置と、前記情報処理装置とネットワークにより接続された通信制御装置と、を備え、
    前記情報処理装置は、前記算出部を備え、
    前記通信制御装置は、前記判定情報を用いて前記異常を検知する異常検知部を備える、
    請求項１に記載の通信システム。
  9. 前記算出部は、前記判定情報に基づいて、前記ゲート制御情報に基づく通信の規格で定義されるメッセージのサイズの最大値の初期値、および、変更後の値の少なくとも一方を決定する、
    請求項１に記載の通信システム。
  10. 通信システムが実行する通信方法であって、
    複数のキューそれぞれに対応する複数のゲートを開くか否かを定める複数のエントリを含むゲート制御情報に基づいて、送信するメッセージのサイズが前記キューにより送信可能なサイズより大きいことにより生じる異常を判定するための判定情報を算出する算出ステップ、を含み、
    前記異常は、前記メッセージの送信が許可されないことにより前記キューがデッドロックの状態となる異常であり、
    前記判定情報は、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、および、前記ゲート制御情報に基づく通信の規格で定義されるメッセージのサイズの最大値、のうち小さい値に基づく情報、
    複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値、および、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、のうち少なくとも１つである、
    通信方法。
  11. コンピュータに、
    複数のキューそれぞれに対応する複数のゲートを開くか否かを定める複数のエントリを含むゲート制御情報に基づいて、送信するメッセージのサイズが前記キューにより送信可能なサイズより大きいことにより生じる異常を判定するための判定情報を算出する算出ステップ、を実行させ、
    前記異常は、前記メッセージの送信が許可されないことにより前記キューがデッドロックの状態となる異常であり、
    前記判定情報は、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、および、前記ゲート制御情報に基づく通信の規格で定義されるメッセージのサイズの最大値、のうち小さい値に基づく情報、
    複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値、および、
    通信速度と、複数の前記キューそれぞれに対して算出される、１以上の継続するエントリに対応する期間でメッセージを送信可能な時間のうち最大値と、に基づいて算出される、送信可能なメッセージのサイズの最大値、のうち少なくとも１つである、
    プログラム。
JP2020095718A 2020-06-01 2020-06-01 通信システム、通信方法およびプログラム Active JP7374849B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020095718A JP7374849B2 (ja) 2020-06-01 2020-06-01 通信システム、通信方法およびプログラム
US17/184,346 US11882053B2 (en) 2020-06-01 2021-02-24 Communication system, communication method, and computer program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020095718A JP7374849B2 (ja) 2020-06-01 2020-06-01 通信システム、通信方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2021190901A JP2021190901A (ja) 2021-12-13
JP7374849B2 true JP7374849B2 (ja) 2023-11-07

Family

ID=78704672

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020095718A Active JP7374849B2 (ja) 2020-06-01 2020-06-01 通信システム、通信方法およびプログラム

Country Status (2)

Country Link
US (1) US11882053B2 (ja)
JP (1) JP7374849B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020039538A1 (ja) * 2018-08-23 2020-02-27 三菱電機株式会社 通信装置、通信方法及び通信プログラム
CN114500692A (zh) * 2022-02-11 2022-05-13 重庆邮电大学 一种时间敏感网络帧抢占优化方法
CN117640536A (zh) * 2022-08-19 2024-03-01 中兴通讯股份有限公司 控制方法、通信方法、控制器、节点设备、可读介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019096930A (ja) 2017-11-17 2019-06-20 株式会社東芝 情報処理装置、情報処理方法、およびプログラム
JP2019165380A (ja) 2018-03-20 2019-09-26 株式会社東芝 転送制御装置、転送制御方法及びプログラム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7400587B2 (en) * 2002-11-13 2008-07-15 Edgewater Computer Systems, Inc. Optimum frame fragmentation method for communication over error prone channels
JP2012133643A (ja) * 2010-12-22 2012-07-12 Sony Corp 情報処理装置、情報処理システム、情報処理方法、およびプログラム
JP5849786B2 (ja) * 2012-03-08 2016-02-03 富士通株式会社 データブロック出力装置、通信システム、データブロック出力方法、及び通信方法
US10153820B2 (en) * 2015-11-25 2018-12-11 Newracom, Inc. Receiver address field for multi-user transmissions in WLAN systems
US10681128B2 (en) * 2016-10-12 2020-06-09 Cisco Technology, Inc. Deterministic stream synchronization
US11509540B2 (en) * 2017-12-14 2022-11-22 Extreme Networks, Inc. Systems and methods for zero-footprint large-scale user-entity behavior modeling
JP7103788B2 (ja) * 2017-12-28 2022-07-20 トヨタ自動車株式会社 車載システム、ゲートウェイ、プログラム、情報処理方法、情報処理システム、及び車両
CN110891026B (zh) * 2018-09-07 2022-11-25 华为技术有限公司 一种流量调度方法、设备及系统
US11129179B2 (en) * 2019-07-25 2021-09-21 Landis+Gyr Innovations, Inc. Initiating or postponing radio transmissions in compliance with dwell time limitations
JP7337750B2 (ja) 2020-06-01 2023-09-04 株式会社東芝 通信制御装置、通信制御方法、情報処理装置、情報処理方法、および、プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019096930A (ja) 2017-11-17 2019-06-20 株式会社東芝 情報処理装置、情報処理方法、およびプログラム
JP2019165380A (ja) 2018-03-20 2019-09-26 株式会社東芝 転送制御装置、転送制御方法及びプログラム

Also Published As

Publication number Publication date
US11882053B2 (en) 2024-01-23
JP2021190901A (ja) 2021-12-13
US20210377181A1 (en) 2021-12-02

Similar Documents

Publication Publication Date Title
JP7374849B2 (ja) 通信システム、通信方法およびプログラム
JP7103788B2 (ja) 車載システム、ゲートウェイ、プログラム、情報処理方法、情報処理システム、及び車両
JP7337750B2 (ja) 通信制御装置、通信制御方法、情報処理装置、情報処理方法、および、プログラム
CN110546926A (zh) 减少时间敏感分组的分组延迟变化
CN111193635A (zh) 测量递送等待时间的方法、系统和计算机可读介质
US10892997B2 (en) Scheduling of data flow transmission in a data center
JP2009522867A (ja) ネットワークトラフィック監視用装置及び方法
EP3375151A1 (en) Packet processing technique for a communication network
WO2018072653A1 (en) Systems and methods for customizing layer-2 protocol
JP2008124967A (ja) イーサｏａｍスイッチ装置
EP1037432B1 (en) Method and device for controlling the synchronization between two serial communication buses of a network
US11632334B2 (en) Communication apparatus and communication method
US11916768B2 (en) Information sharing method and apparatus in redundancy network, and computer storage medium
JP6517554B2 (ja) 伝送システムおよび伝送局
CN117014384A (zh) 一种报文传输方法以及报文转发设备
CN115603843A (zh) 出站分组的准确加时间戳
KR102463075B1 (ko) 분산형 지연 오프셋 매칭을 이용한 트래픽 무손실 전달 방법 및 이를 수행하기 위한 장치들
JP2006295930A (ja) レジデンシャルイーサネットにおけるスーパーフレームの開始を保証するための非同期フレーム伝送方法
EP4191969A1 (en) Communication control device, information processing device, communication control method, and information processing method
EP4191968A1 (en) Communication control device, information processing device, communication control method, information processing method, and storage medium
JP7321395B1 (ja) 通信システム、通信装置および通信方法
US20170005939A1 (en) Control method and network device
WO2024218926A1 (ja) 通信システム、管理方法、管理装置、及びプログラム
WO2023012948A1 (ja) 通信装置、通信システム、及び通信方法
JP2009206733A (ja) エッジノードおよび帯域制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220825

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230620

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230725

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230906

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231025

R151 Written notification of patent or utility model registration

Ref document number: 7374849

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151