JP2013513269A - 信頼性のあるパケットカットスルー - Google Patents
信頼性のあるパケットカットスルー Download PDFInfo
- Publication number
- JP2013513269A JP2013513269A JP2012541521A JP2012541521A JP2013513269A JP 2013513269 A JP2013513269 A JP 2013513269A JP 2012541521 A JP2012541521 A JP 2012541521A JP 2012541521 A JP2012541521 A JP 2012541521A JP 2013513269 A JP2013513269 A JP 2013513269A
- Authority
- JP
- Japan
- Prior art keywords
- frame
- data
- crc
- data packet
- corrupted
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
- H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
- H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
- H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
- H03M13/091—Parallel or block-wise CRC computation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- Probability & Statistics with Applications (AREA)
- Theoretical Computer Science (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
Abstract
カットスルーデータパケット機構が説明される。中間ノードにより、カットスルーデータパケットを転送することで、パケットにフレームCRCを行う前に、カットスルーデータパケットのパケット送信を開始することを可能にする。CRCは、代わりに、パケットの送信が発生している間に行われる。カットスルーデータパケットに、1つまたは複数のエラーが発見された場合には、そのようなエラーを示すパケットトレーラーが、カットスルーパケットを受信する終点ノードに向けて送信される。
Description
(関連する出願)
本出願は、2009年12月4日に出願された“信頼性のあるパケットカットスルーの方法およびシステム”と題された米国仮特許出願第61/266,747号に関連し、その優先権を主張するものであり、先の出願の開示の全ては、参考のために本明細書に組み込まれる。
本出願は、2009年12月4日に出願された“信頼性のあるパケットカットスルーの方法およびシステム”と題された米国仮特許出願第61/266,747号に関連し、その優先権を主張するものであり、先の出願の開示の全ては、参考のために本明細書に組み込まれる。
本発明は、概して、デジタル回路に関し、より具体的には、デジタル回路のエネルギー使用に関する。
モバイル産業プロセッサインターフェイスアライアンス[MIPI:Mobile Industry Processor Interface Alliance]において、いくつかの規格が定義されている。これら規格の1つは、UniPro(Unified Protocol)と呼ばれており、このUniProは、高速シリアルリンク[UniPro1]を用いたチップ間ネットワークを対象としている。UniProは、エラー処理、フロー制御、ルーティングまたは仲裁などの、一般的な相互接続の問題を解決する汎用プロトコルとして定義されている。UniProは、新しいデバイスを容易に作製するために、場合によっては異なるベンダーからの、異なる機能を有するチップを混合および整合することによって、電話製造業者の柔軟性を高めることを意図している。
UniProは、リンクレベルで信頼性のある通信を提供するために、かなり複雑なエラー処理手順を有する。UniProエラー処理は、CRCコードに基づくエラー検出、NACフレームを用いたエラー報告、およびエラーがあった場合のデータフレーム再送信に基づいている。シーケンス番号が、データフレームが順番に設定されていることを保証し、かつ、フレームの紛失や複製を防止する。ひとたびフレームが正しく受信されたことが報告されると、フレームを再送信バッファから取り除くことにより、トランスミッタ側で再送信バッファを管理することにおいても、シーケンス番号は重要である。
CRCベースのエラー検出に加えて、UniProは、また、タイマを用いて、エラーのまれなケース(corner case)に対処する。2つのタイマが用いられており、それぞれ、フレーム肯定応答および失われたフロー制御クレジットに対する保護に用いられる。
このエラー処理は、データフレームのCRCが確認された後でのみ、データフレームが処理されることを必要とする。このCRCの前処理は、パケットがレシーバアプリケーションにおいて配送された際に、必要条件となることがある一方で、介在ノードにおいて、例えば、UniProスイッチなどのUniProネットワークノードにおいては非効率的であり、そのようなノードでは、データフレーム配送と関連するレイテンシを増加させる。
現在の処理は十分ではあるが、本発明者は、このような通信システムにおいて、より少ないレイテンシを有する方法およびノードを有すること、および、より信頼性のあるパケットカットスルー機構を提供することが望ましいことを見出した。
カットスルーデータパケット機構が説明される。中間ノードにより、カットスルーデータパケットを転送することで、パケットにフレームCRCを行う前に、カットスルーデータパケットのパケット送信を開始することを可能にする。CRCは、代わりに、パケットの送信が発生している間に行われる。カットスルーデータパケットに、1つまたは複数のエラーが発見された場合には、そのようなエラーを示すパケットトレーラーが、カットスルーパケットを受信する終点ノードに向けて送信される。
1つの例示的な実施形態によると、終点ノードに向けてデータを送信する方法は、中間ノードにおいて、第1のデータフレームを受信するステップと、第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC:cyclic redundancy check)を行う前に、中間ノードによって、第2のデータフレームにおいて終点ノードに向けた第1のデータフレームに含まれるデータパケットの再送信を開始するステップであって、フレームCRCフィールドが、第1のデータフレームの少なくとも1つの非CRCフィールドに基づき計算されている、ステップと、中間ノードによって、かつ再送信を開始した後に、フレームCRCフィールドを用いて、第1のデータフレームに対して第1のCRCを行うステップと、第1のCRCの結果として、中間ノードによって、第1のデータフレームが、1つまたは複数のエラーを含み破損していることを決定するステップと、第2のデータフレームと関連するフレームトレーラーを、中間ノードによって、終点ノードに向けて送信するステップであって、フレームトレーラーは、第2のデータフレームに含まれるデータパケットが破損していることを示す、ステップと、を含む。
もう1つの例示的な実施形態によると、スイッチングデバイスは、第1のデータフレームを受信するように構成された第1のインターフェイスと、第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC)を行う前に、終点に向けた第2のデータフレームとしての第1のデータフレームに含まれるデータパケットの再送信を開始するものであって、フレームCRCフィールドは、第1のデータフレームの少なくとも1つの非CRCフィールドに基づき計算されている、ように構成された第2のインターフェイスと、第1および第2のインターフェイスを制御するように構成されたインターフェイスコントローラと、再送信を開始した後に、フレームCRCフィールドを用いて、第1のデータフレームに対して第1のCRCを行い、かつ、第1のデータフレームに対するCRCの結果として、第1のデータフレームが1つまたは複数のエラーを含み破損していることを決定するように構成されたプロセッサと、を含み、スイッチングデバイスは、第2のデータフレームに含まれたデータパケットが破損していることを示す第2のデータフレームと関連するフレームトレーラーを、第2のインターフェイスを介して送信するようにさらに構成されている。
もう1つの例示的な実施形態によると、レシーバは、カットスルーデータフレームを受信するように構成されたインターフェイスと、カットスルーデータフレームと関連する周期的冗長性検査(CRC)フィールド以外のデータフィールドを評価し、カットスルーデータフレームが1つまたは複数のエラーを含み破損しているか否かを決定するように構成されたプロセッサと、を含む。
さらにもう1つの例示的な実施形態によると、データパケットを含み、かつ第1のフレームトレーラーを有するデータフレームを、フレームデータレシーバにおいて受信する方法は、フレームデータレシーバの第1のインターフェイスにおいて、データフレームを受信するステップと、フレームデータレシーバによって、データフレーム内のフレームCRCフィールドを用いて、周期的冗長性検査(CRC)を行うステップであって、フレームCRCフィールドは、データフレームの少なくとも1つの非CRCフィールドに基づき計算されている、ステップと、第1のCRCの結果として、フレームデータレシーバによって、データフレームが破損していないことを決定するステップと、データパケットが破損していることを、フレームトレーラーから決定し、かつ関連する動作を行うステップと、を含む。
添付の図面は、特に、本発明の例示的な実施形態を示している。
(略語および頭字語の一覧)
ACK Acknowledge Message(肯定応答メッセージ)
AFC Acknowledgement and Flow Control(肯定応答およびフロー制御)
COF Continuation Of Frame(フレームの継続)
CRC Cyclic Redundancy Check(周期的冗長性検査)
CRCF Cyclic Redundancy Check Frame(周期的冗長性検査フレーム)
CRCH Cyclic Redundancy Check Header(周期的冗長性検査ヘッダ)
CTRL_ID Control Identifier(制御識別子)
DL_MTU Data Link Maximum Transmission Unit(データリンク最大送信単位、すなわちフレームの最大ペイロード)
EOF End Of Frame(フレーム終了)
EOF_ERR End Of Frame Error(フレーム終了エラー)
EOF_PAD End Of Frame(パディングバイトを有するフレーム終了)
EoM End of Message(メッセージ終了)
ESC_DL ESCape character for Data Link Layer(データリンク層用のエスケープキャラクタ)
FCT Flow Control token(フロー制御トークン)
L3s Layer 3 Short header(レイヤ3ショートヘッダ)
L4s Layer 4 Short header(レイヤ4ショートヘッダ)
MIPI Mobile Industry Processor Interface(モバイル産業プロセッサインターフェイス)
NAC Negative Acknowledgement Control(否定応答制御)
NACCrc Negative Acknowledgement Control Cyclic Redundancy Check(否定応答制御周期的冗長性検査)
NACGen Negative Acknowledgement Control Generation(否定応答制御生成)
PAerr (P)HY Adapter (err)or(PHYアダプタエラー)
PERR Packet ERRor(パケットエラー)
RRR Remote Reset Request(遠隔リセット要求、RReq(Reset (Req)est)とも呼ばれる)
Rx Receiver(レシーバ)
SDL Specification Description Language(仕様記述言語)
SOF Start Of Frame(フレーム開始)
TC Traffic Class(トラフィッククラス)
TC0_crc Traffic Class 0 CRC(トラフィッククラス0 CRC)
UniPro Unified Protocol(統一プロトコル)
ACK Acknowledge Message(肯定応答メッセージ)
AFC Acknowledgement and Flow Control(肯定応答およびフロー制御)
COF Continuation Of Frame(フレームの継続)
CRC Cyclic Redundancy Check(周期的冗長性検査)
CRCF Cyclic Redundancy Check Frame(周期的冗長性検査フレーム)
CRCH Cyclic Redundancy Check Header(周期的冗長性検査ヘッダ)
CTRL_ID Control Identifier(制御識別子)
DL_MTU Data Link Maximum Transmission Unit(データリンク最大送信単位、すなわちフレームの最大ペイロード)
EOF End Of Frame(フレーム終了)
EOF_ERR End Of Frame Error(フレーム終了エラー)
EOF_PAD End Of Frame(パディングバイトを有するフレーム終了)
EoM End of Message(メッセージ終了)
ESC_DL ESCape character for Data Link Layer(データリンク層用のエスケープキャラクタ)
FCT Flow Control token(フロー制御トークン)
L3s Layer 3 Short header(レイヤ3ショートヘッダ)
L4s Layer 4 Short header(レイヤ4ショートヘッダ)
MIPI Mobile Industry Processor Interface(モバイル産業プロセッサインターフェイス)
NAC Negative Acknowledgement Control(否定応答制御)
NACCrc Negative Acknowledgement Control Cyclic Redundancy Check(否定応答制御周期的冗長性検査)
NACGen Negative Acknowledgement Control Generation(否定応答制御生成)
PAerr (P)HY Adapter (err)or(PHYアダプタエラー)
PERR Packet ERRor(パケットエラー)
RRR Remote Reset Request(遠隔リセット要求、RReq(Reset (Req)est)とも呼ばれる)
Rx Receiver(レシーバ)
SDL Specification Description Language(仕様記述言語)
SOF Start Of Frame(フレーム開始)
TC Traffic Class(トラフィッククラス)
TC0_crc Traffic Class 0 CRC(トラフィッククラス0 CRC)
UniPro Unified Protocol(統一プロトコル)
以下の例示的な実施形態の詳細な説明は、添付の図面を参照する。異なる図面における同一の参照番号は、同一または類似の要素を識別する。また、以下の詳細な説明は、本発明を限定しない。代わりに、本発明の範囲は、添付の特許請求の範囲によって定義される。
例示的な実施形態によると、データフレームまたはパケットは、レイテンシを改善するために、“カットスルー”することができる。ここで、パケット“カットスルー”は、例えば、パケット送信者とパケット受信者との間の介在UniProノードにおいて、CRC検査が行われる前に、到来パケット(incoming packet)をさらに送信できることを意味する。本発明において、我々は、UniProネットワークにおいてパケットカットスルーを行う方法を提示する。中でも、例示的な実施形態は、パケットカットスルーをエラー処理と組み合わせることを提供し、これにより、カットスルーパケットの送信に関して検出されたエラーがネットワーク内で伝播され、エラーのあるパケットが止められることを保証する。例示的な実施形態は、エラーのあるパケットが配送されることを防止し、かつ、順番通りのデータ送信を保証する。例示的な実施形態の考察についてのいくつかの状況を提供するために、UniProプロトコルおよびこれらの例示的な実施形態を用いることができるシステムに関して、いくつかの情報が最初に提供される。しかし、本発明は、UniPro標準化システムでの使用に限定されないことを理解されたい。
UniProプロトコルは、そのリンクレベル通信のためのデータおよび制御フレームを定義する。データフレームは、アプリケーションからのデータをカプセル化し、一方で、制御フレームは、UniProのデータリンクレイヤプロトコルによって、その内部機構のために使用される。UniProプロトコル規格(1.00.00)は、図1に示すようなデータフレームを定義する。ここで、UniProデータフレームの1つ目のシンボルと最後の2つのシンボルは、それぞれフレームヘッダとトレーラーである。ヘッダは、制御シンボル(1の値を有する16番目のビットによって識別される)からなり、制御シンボルは、以下のフィールドを有する。
・エスケープバイト(ESC_DL):符号化されたPhyにおいて、エスケープシンボルに変換されるものであり、かつ、制御シンボルを示す。
・シンボル制御idフィールドCTRL_ID:データフレームヘッダの場合に、0の値を有し、図1ではSOF(Start Of Frame)で示される。
・トラフィッククラスTCx:UniPro1.0は、トラフィッククラスTCxに対して、値0および1を許可する。
・3つの予約ビット。
・エスケープバイト(ESC_DL):符号化されたPhyにおいて、エスケープシンボルに変換されるものであり、かつ、制御シンボルを示す。
・シンボル制御idフィールドCTRL_ID:データフレームヘッダの場合に、0の値を有し、図1ではSOF(Start Of Frame)で示される。
・トラフィッククラスTCx:UniPro1.0は、トラフィッククラスTCxに対して、値0および1を許可する。
・3つの予約ビット。
トレーラーは、2つのシンボル:EOF制御シンボル(16番目のビットが1)、およびエラー検出用のCRCデータシンボル(16番目のビットが0)、からなる。EOF制御シンボルは、以下のものからなる。
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、偶数のバイトを有するペイロードに対して、EOF(End Of Frame)によって示される1の値か、または、奇数のバイトを有するペイロードに対して、EOF_PAD(パディングバイトを有するEnd Of Frame)によって示される2の値かを有する。
・フレームシーケンス番号
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、偶数のバイトを有するペイロードに対して、EOF(End Of Frame)によって示される1の値か、または、奇数のバイトを有するペイロードに対して、EOF_PAD(パディングバイトを有するEnd Of Frame)によって示される2の値かを有する。
・フレームシーケンス番号
UniProバージョン1.5において、フレーム長(EOF/EOF_PAD制御シンボルの代わりに)フィールドを用いて、フレームの終わる箇所を識別するように、データフレームフォーマットが変わる可能性があり、この例が、図2に示されている。図1のEOFベースのデータフレームと比べて、データシンボルは、SOF制御シンボルの直後のフレームヘッダに挿入されている。この新しいデータシンボルは、フレーム長と、フレームシーケンス番号とを含む。EOF制御シンボルは、もはや存在しない。残りのデータフレーム構造に変更はない。
この新しいフレームフォーマットは、任意の16ビットヘッダCRCの導入を可能とするために導入され、このヘッダCRCは、リアルタイムトラフィッククラス(UniPro2.0仕様の一部であると予想されるもの)によって必要とされ、この例が、図3に示される。ヘッダCRCの存在は、1つ目のヘッダシンボル内のhCRCビットによって示される。ヘッダCRCは、また、L3ヘッダ(図3に3番目のワードのビット8:16として示される)と、L4ヘッダ(図3に3番目のワードのビット0:7として示される)とを保護する。ヘッダCRCの位置は、L3およびL4ヘッダにおけるビット(すなわち、L3s,L4sと、長いヘッダにのみ使用され、ここでは図示されない拡張子を示すビットと)を用いて、実行中に(動的に変化する状態で)(on the fly)計算される。フレーム内の2つのCRCを区別するために、“ヘッダCRC”を用いて、ヘッダを保護するCRCが示され、かつ、“フレームCRC”を用いて、フレーム全体を保護するCRCが示される。
UniPro1.00.00プロトコルは、2つの制御フレーム:図4に示されるAFC(Acknowledgement and Flow Control)制御フレーム、および、図5に示されるNAC(Negative Acknowledgement)制御フレーム、を有する。AFC制御フレームは、3つのシンボル:AFC制御シンボル(16番目のビットは1)、および、2つのデータシンボル、からなる。AFC制御シンボルは、以下のものからなる。
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、AFC(Acknowledgement and Flow Control)によって示される6の値か、UniPro1.0が値0および1を可能にする、トラフィッククラスTCxかを有する。
・トラフィッククラスTCx:UniPro1.0は、トラフィッククラスTCxに対して、値0および1を許可する。
・Reqビット:ピア側に、このトラフィッククラスでのAFC制御フレームを送ることを要求するために用いられる。
・2つの予約ビット。
図5に示されるNAC制御フレームは、2つのシンボル:NAC制御シンボル(16番目のビットは1)、および、1つのデータシンボル、エラー検出に用いられるCRC、からなる。NAC制御シンボルは、以下のものからなる。
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、NAC(Negative Acknowledgement)によって示される5の値のいずれかを有する。
・4つの予約ビット。
・RRRビット:ピア側に、リンクの再同期を要求するために用いられる。
NAC制御フレームにおける第2のデータシンボルは、エラー検出に用いられるCRCである。
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、AFC(Acknowledgement and Flow Control)によって示される6の値か、UniPro1.0が値0および1を可能にする、トラフィッククラスTCxかを有する。
・トラフィッククラスTCx:UniPro1.0は、トラフィッククラスTCxに対して、値0および1を許可する。
・Reqビット:ピア側に、このトラフィッククラスでのAFC制御フレームを送ることを要求するために用いられる。
・2つの予約ビット。
図5に示されるNAC制御フレームは、2つのシンボル:NAC制御シンボル(16番目のビットは1)、および、1つのデータシンボル、エラー検出に用いられるCRC、からなる。NAC制御シンボルは、以下のものからなる。
・エスケープバイト(ESC_DL):ヘッダ内のSOF制御シンボルに関する。
・シンボル制御idフィールド:データフレームトレーラーの場合に、NAC(Negative Acknowledgement)によって示される5の値のいずれかを有する。
・4つの予約ビット。
・RRRビット:ピア側に、リンクの再同期を要求するために用いられる。
NAC制御フレームにおける第2のデータシンボルは、エラー検出に用いられるCRCである。
UniProリンクレベルエラー処理スキームは、エラー検出およびデータフレーム再送信に基づいており、かつ、2つの安全策からなる。第1の安全策は、高速であり、かつ、典型的なエラーを処理する。第2の安全策は、より遅く、かつ、まれなケースを処理する。UniProシステムは、CRC(Cyclic Redundancy Check)エラー検出コードを、送信された各フレームに追加する。レシーバは、CRCを再計算し、かつ、再計算したCRCを、フレームの終わりに受信されたCRCに対して確認する。受信されたフレームが正しい場合には、レシーバは、このフレームを受信バッファに引き渡し、かつ、トランスミッタに対してフレームの肯定応答を行う(データフレームに関する)か、または、フレームを処理する(制御フレームに関する)。レシーバがエラーを検出した場合には、レシーバは、NACフレームを用いて、トランスミッタにエラーを報告する。
全ての送信されるデータフレームには、シーケンス番号が割り当てられており、この番号も、データフレームにおいて送信され、かつ、レシーバによって肯定応答に用いられる。UniProシーケンス番号は、5ビットを有する。リセット値は0であり、かつ、第1のデータフレーム送信に用いられる。シーケンス番号は、送受信されるフレームごとに増加され、かつ、31の周囲に配置される。UniProでは、最大で16フレームを、肯定応答を受信することなく送信することができる。フレーム肯定応答は、ACK制御フレームを用いて行われる。フレームを肯定応答する場合には、AFCフレーム内のシーケンス番号は、シーケンス番号によって識別されるデータフレームまで、このデータフレームも含めて全ての肯定応答されていないデータフレームを肯定応答する。
トランスミッタは、再送信バッファ内の全ての送信されたデータフレームを、肯定応答されるまで保存する。NAC制御フレームが受信された(エラーを報告している)場合には、再送信バッファ内の全てのデータフレームは、最も古い肯定応答されていないフレームから開始して、再送信される。
第2の安全策は、AFCまたはNACフレームの1つまたは複数が失われた場合に用いられる。そのような場合には、AFCフレーム内に含まれる肯定応答および/またはリンクレベルのフロー制御クレジットが失われているか、または、NACフレームに含まれているエラー指示(error indication)が失われている。このような(まれな)エラーから保護するために、各トラフィッククラスに対して、2つのタイマ:再生タイマと呼ばれるデータ用のタイマ、および、クレジットタイマと呼ばれるクレジット用のタイマ、が用いられる。再生タイマが切れると、このトラフィッククラスの全ての肯定応答されていないフレームが再送信される。クレジットタイマが切れると、Reqビットセットを有するAFCフレームが、このトラフィッククラスのために送信される。両方の場合で、UniPro1.00.00は、リンクの再同期を要求し、その後、RRRビットを有するNACフレームが送信され、到来するリンクの再同期を要求する。
CRCエラーに加えて、第1の安全策の一部として、レシーバは、以下の多くの他のエラーを検出する。
・レシーババッファオーバーフロー(例えば、TCxフィールドでのビット送信エラーによる)
・最大フレームサイズDL_MTUよりも大きい、到来するデータフレーム長(例えば、EOF制御シンボルを、有効なデータシンボルに変更する送信エラーによる)
・データフレーム内の誤ったシーケンス番号
・後に2つのデータシンボルが続かないAFCフレーム
・後に1つのデータシンボルが続かないNACフレーム
・後に1つのデータシンボルが続かないEOF/EOF_PAD
・データフレームが開始されていない場合の、COF、EOFまたはEOF_PAD制御シンボルの受信
・同じトラフィッククラスのデータフレームが、既に進行中であり、かつ、データフレームが、現在、先取されていない場合の、SOFシンボルの受信(AFCおよび/またはNACによる先取の間、SOF受信は、再送信の開始を示すことがあり、よって、エラーとみなされない)
・TC1データフレームが既に進行中の場合の、TC0に関するSOFシンボルの受信(TC0は、TC1を先取できない)
・同じトラフィッククラスのデータフレームの間の、このデータフレームが先取されていない場合の、COFシンボルの受信
・異なるTCのデータフレームを継続するCOFシンボルの受信
・データフレームが先取されておらず、かつ、先取しているフレームが終了した場合の、EOF、EOF_PADまたはデータシンボルの受信(先取されたフレーム、COFシンボルに関しては、EOFでないものが後に続くべきである)
・定義済みフィールドに関する無効な値、例えば未定義のCTRL_IDまたはTC、を有する制御シンボルの受信
・Phy Adapterからのエラー指示の受信
Phy Adapterは、以下の場合でのエラーを示す。
・悪いPhyシンボルが受信された場合
・正しい例外Phyシンボルが受信されたが、この例外Phyシンボルが、有効なUniProシンボルにマッピングされていない場合
・データPhyシンボルが予想される場合に、他の例外Phyシンボルの直後に、正しい例外Phyシンボルが受信された場合
・ESC_PAの後に、有効なデータPhyシンボルの誤った値が受信される場合
上記のエラーのいずれかが検出されると、NAC制御フレームが送信され、場合によっては、その前に、不要な再送信を避けるための一対のAFC制御フレームが先行する。
・レシーババッファオーバーフロー(例えば、TCxフィールドでのビット送信エラーによる)
・最大フレームサイズDL_MTUよりも大きい、到来するデータフレーム長(例えば、EOF制御シンボルを、有効なデータシンボルに変更する送信エラーによる)
・データフレーム内の誤ったシーケンス番号
・後に2つのデータシンボルが続かないAFCフレーム
・後に1つのデータシンボルが続かないNACフレーム
・後に1つのデータシンボルが続かないEOF/EOF_PAD
・データフレームが開始されていない場合の、COF、EOFまたはEOF_PAD制御シンボルの受信
・同じトラフィッククラスのデータフレームが、既に進行中であり、かつ、データフレームが、現在、先取されていない場合の、SOFシンボルの受信(AFCおよび/またはNACによる先取の間、SOF受信は、再送信の開始を示すことがあり、よって、エラーとみなされない)
・TC1データフレームが既に進行中の場合の、TC0に関するSOFシンボルの受信(TC0は、TC1を先取できない)
・同じトラフィッククラスのデータフレームの間の、このデータフレームが先取されていない場合の、COFシンボルの受信
・異なるTCのデータフレームを継続するCOFシンボルの受信
・データフレームが先取されておらず、かつ、先取しているフレームが終了した場合の、EOF、EOF_PADまたはデータシンボルの受信(先取されたフレーム、COFシンボルに関しては、EOFでないものが後に続くべきである)
・定義済みフィールドに関する無効な値、例えば未定義のCTRL_IDまたはTC、を有する制御シンボルの受信
・Phy Adapterからのエラー指示の受信
Phy Adapterは、以下の場合でのエラーを示す。
・悪いPhyシンボルが受信された場合
・正しい例外Phyシンボルが受信されたが、この例外Phyシンボルが、有効なUniProシンボルにマッピングされていない場合
・データPhyシンボルが予想される場合に、他の例外Phyシンボルの直後に、正しい例外Phyシンボルが受信された場合
・ESC_PAの後に、有効なデータPhyシンボルの誤った値が受信される場合
上記のエラーのいずれかが検出されると、NAC制御フレームが送信され、場合によっては、その前に、不要な再送信を避けるための一対のAFC制御フレームが先行する。
図6において、メッセージシーケンス図が示され、UniProエラー処理機構の第1および第2の安全策を例示している。簡略化のために、単一のトラフィッククラスが仮定されている。ここで、データフレーム#1および#2を正しく受信した後に、ノードBは、これらフレームの正しさを、最後に正しく受信されたフレームのシーケンス番号、この場合は#2、を保持するAFCフレームを、ノードAに送ることによって、報告する。ノードAは、AFCフレームを受信すると、フレーム#2までの全てのフレームを、再送信バッファから取り除く。ノードAは、フレーム#3および#4を送り続けるが、しかしフレーム#3のみが正しく受信され、フレーム#4の送信中にエラーが起こる。このエラーは、ノードBで検出されるものであり、ノードBは、最初にAFCをノードAに送り、フレーム#3の正しい受信を肯定応答し、その後にエラーを報告するNACフレームが続く。NACを受信する際に、ノードAは、最も古いフレーム、この例ではフレーム#4、から開始して、全ての肯定応答されていないフレームを再送信する(第1の安全策)。
ノードAは、再送信されたフレーム4の次に、フレーム5を続ける。フレーム#4は正しく受信されるが、ノードBによって、フレーム5にエラーが検出される。その結果、前の場合と同様に、AFCフレームを送って、フレーム4の正しい受信を報告し、かつ、NACフレームを送って、エラーを報告する。不都合なことに、NACフレームも、送信エラーに遭遇する。ノードAは、このエラーをNACにより報告するが、しかしフレーム#5を再送信すべきか否かが分からない。最終的に、ノードAの再生タイマが切れ、かつ、ノードAがフレーム#5を再送信する(第2の安全策)。
図7は、SDLフローチャートを用いて、UniProエラー検出機構の可能な部分的実施を例示している。ここで、レシーバに見出されるシンボルパーサーの最上位図が説明されている。シンボルパーサーは、3つの変数:TC0およびTC1のそれぞれで進行中のデータフレームがあるか否かを示す、tc0およびtc1、ならびに、NAC生成が有効化されている(真)か否(偽)かを示すNACGenOk、を維持する。最初は進行中のデータフレームはないので、tc0およびtc1は、両方とも偽(false)に設定されている。NACによりエラーが報告された後に、良いCRCを有するフレームが受信されるまで、NAC生成は一時的に無効化される。最初は検出されるエラーはないので、NACGenOkは、真(true)に設定される。
最初は、レシーバシンボルパーサーは、どのフレームも開始しておらず、NoFrame状態で待機する。フレーム開始のシンボル(NAC、AFC、0または1のTCを有するSOF)が受信されると、対応する手順が呼び出され、フレーム全体(それぞれ、NAC、AFC、TC1およびTC0)を受信する。他の何らかのシンボル(データ、COF、EOFまたはEOF_PAD、簡略化のために不図示)が受信された場合には、パラメータfalseによりError手順が呼び出される。どの状態でも、Phy Adapterからエラー指示が受信された場合には、パラメータfalseによりErrorが呼び出される。
図8には、Error手順が示されており、この手順は、RRRと呼ばれるパラメータを取る。NAC生成が有効化されている場合には、NACフレームがトリガされ、NAC生成が無効化される。このNACフレームは、手順パラメータとして受信されたRRR値に設定されたRRRビットを有する。エラーが検出された後は、パーサープロセスは、常に状態NoFrameに戻る。
図9には、NACフレームを受信する手順が示されている。NACシンボルを受信した後に、NAC手順が呼び出されるが、このNAC手順は、データシンボル(CRC)が受信されるまで、状態NACで待機する。もう1つのシンボルが受信された場合には、このシンボルは、Errorを呼び出す際に報告されるエラーである。データシンボルが受信された場合には、このデータシンボルは、NACフレームのCRCのはずであり、かつ、レシーバで計算されたCRCに対して確認される(簡略化のために、これらの図面ではCRC計算は図示せず)。CRCが正しくない場合には、Errorが呼び出される。CRCが正しい場合には、NACCrcOkによりNACフレームが引き渡されるが、ここで、NAC受信に続く動作が行われる。この後に、NACGenOkが真に設定される(良いフレームを受信した後に、NAC生成が有効化される)。tc1が真である場合には、TC1が先取されており、かつ、継続されるべきである。したがって、シンボルパーサープロセスは、状態TC1_CoFに移行する。そうではなく、tc0が真である場合には、パーサープロセスは、状態TC0_CoFに移行する。tc1とtc0のいずれも真でない場合には、パーサープロセスは、状態NoFrameに戻る。
図10には、AFCフレームを受信する手順が示されている。AFCシンボルを受信した後に、AFC手順が呼び出されるが、このAFC手順は、AFCフレームの第2のデータシンボルが受信されるまで、状態AFCで待機する。もう1つのシンボルが受信された場合には、このシンボルは、Errorを呼び出す際に報告されるエラーである。次いで、AFC手順は、第2のデータシンボル(CRC)が受信されるまで、AFC_crc状態で待機する。再び、他の何らかのシンボルが受信された場合には、このシンボルは、エラーであり、このエラーは、Errorにより報告される。第2のデータシンボルが受信された場合には、このデータシンボルは、AFCフレームのCRCのはずであり、このCRCは、レシーバで計算されたCRCに対して確認される(簡略化のために、これらの図面ではCRC計算は示さず)。CRCが正しくない場合には、Errorが呼び出される。CRCが正しい場合には、AFCCrcOkによりAFCフレームが引き渡され、ここで、AFC受信に続く動作が行われる。この後に、NACGenOkが真に設定される(良いフレームを受信した後に、NAC生成が有効化される)。tc1が真である場合には、TC1が先取されており、かつ、継続されるべきである。したがって、シンボルパーサープロセスは、状態TC1_CoFに移行する。そうではなく、tc0が真である場合には、パーサープロセスは、状態TC0_CoFに移行する。tc1とtc0のいずれも真でない場合には、パーサープロセスは、状態NoFrameに戻る。
図11には、TC1においてデータフレームを受信する手順が示されている。パーサーが、トラフィッククラスフィールドが1に設定されたSOFシンボルを受信した後に、TC1手順が呼び出されるが、このTC1手順は、tc1を真に設定してTC1フレームが開始したことを示し、次いで、データシンボルを受信している限り、状態TC1_dataで待機する。データが受信されている間に、2つのエラー:バッファオーバーフローおよびDL_MTUを超えたフレーム、が生じることがあるが、これらのエラーは、図面では示されていない。両方の場合において、エラーは、Errorによって報告される。状態TC1_dataから、フレームは、EOFシンボルまたはEOF_PADシンボル(簡略化のためにEOF_PADは図示せず)で終わることがある。EOF/EOF_PADシンボルの後は、データが予想される(CRC)。他の何らかのシンボルが受信された場合には、これは、Errorによって報告されるエラーである。CRCが受信された場合には、フレームは終了する(tc1が偽となる)。フレームは、そのCRCが正しい場合には、引き渡されるが、正しくない場合には、Errorが呼び出される。この後、NACGenOkが真に設定される(良いフレームを受信した後に、NAC生成が有効化される)。tc0を用いてTC0データフレーム先取がチェックされ、真である場合には、状態TC1_CoFで、TC0データフレーム受信が継続される。真でない場合には、パーサープロセスは状態NoFrameに戻る。
TC1_dataにおいて、先取が発生した場合(NACまたはAFCシンボルが受信される場合)には、このフレーム(それぞれ、NACまたはAFC)を受信するための手順が呼び出される。他の何らかのシンボルが、TC1_data状態で受信され(すなわち、SOFまたはCOF)、Errorによってエラーが報告される。TC1データフレームが先取され、先取されたフレームが終了した場合には、パーサーは、状態TC1_CoFに戻る。この状態で、(1)TCフィールドが1に設定されたCOFを受信する際に、TC1データフレームを継続することができ、その後、パーサーは、状態TC1_dataを継続する、または、(2)NAC、AFCによる他の先取が開始する場合がある、または(3)可能な再送信を示す、TCフィールドが1に設定されたSOFシンボルが受信される場合がある。その他のシンボルはエラーであり、Errorを用いて報告される。
図12には、TC0においてデータフレームを受信する手順が示されている。これは、TC1の場合と類似している。2つの違いがある。1つ目は、TC0フレームが、TC1フレームで先取される可能性があることであり、これは、TCフィールドが1に設定されたSOFシンボルが、ペイロード(TC0_data状態)の間または先取(TC0_CoF状態)の間に受信させることで示されている。2つ目は、TC0フレームが終了した際に、他に継続され得るフレームがないため、パーサーは常に状態NoFrameに戻ることである(TC1の場合では、TC0が先取されることがあるので、状態TC0_CoFでTC0を継続する必要があるか否かを決定するためのチェックが必要であり、または進行中のフレームがなく、この場合はパーサーが状態NoFrameに戻る)。
例示的な実施形態によると、例えば、CRCチェックが行われる前にパケットが送信される中間ノードにおいて、パケットカットスループロセスを行ってもよい。図13は、リンク1でパケットを送るノードAと、リンク1で送られたパケットを受信し、パケットをリンク2でカットスルーするノードBと、パケットを受信するノードCとを示している。よって、この例では、ノードBは、中間ノード、例えばスイッチングデバイスとみなすことができ、一方で、ノードCは、終点ノード、例えば、フレームデータレシーバとみなすことができる。パケットは、任意でヘッダCRC(crch)によって保護することができるヘッダと、ペイロードのいくつかのシンボルと、フレームCRC(crcf)を含むトレーラーと、を有して示されている。
フレームは、例示的な実施形態によると、L3 DeviceID(アドレス)が受信された直後にのみ、カットスルーすることができる。ヘッダがヘッダCRCによって保護されている場合には、例えばフレームヘッダ内の少なくとも1つの非CRCフィールド(および場合によっては、フレームヘッダ内の非CRCフィールドの全て)に基づいて、CRCを計算することにより、ヘッダCRCが確認された後でのみカットスルーを開始することがベターであり、これにより、L2〜L4ヘッダが正しいことを保証する。ヘッダCRCが破損している場合には、フレームは破棄され、かつ、エラーが報告される。図13の例では、第1のフレーム(リンク1のシーケンス番号#5を有する)は、ノードBでヘッダCRCが正しいことが証明されており、リンク1での正しい送信を示している。その結果、フレームは、リンク2でノードCにカットスルーされる(リンク2のシーケンス番号#9を有する)。ヘッダCRCがなかった場合には、フレームは、L3 DeviceIDが受信された際に、カットスルーされていた可能性がある。L3 DeviceID受信は、ノードBでトランスミッタポートを選択する必要がある。
この例では、フレーム#5は、そのリンク1でのペイロード送信の間に、エラーに遭遇する。しかし、エラーは、フレームCRCがチェックされる際にのみ検出されるが、これは、フレームがカットスルーされることを防ぐには遅すぎる。その結果、例えば、フレーム内の少なくとも1つの非CRCフィールドと、場合によってはフレーム内の全ての非CRCフィールドとに基づきCRCを計算することにより、フレームCRCがチェックされ、エラーが発見された後に、カットスルーフレーム(リンク2のフレーム#9)に、ペイロードにエラーが存在することを示すトレーラーが付加される。ペイロードエラーを示すことができる1つのやり方は、フレームトレーラーに特殊レイヤ2シンボルを追加することである(例えば、長さベースのフレームを示す図14AおよびEOFフレームを示す図14Bを参照されたい)。この文脈での「特殊」とは、レイヤ2シンボルが、適切に適合されたレシーバまたは中間ノードによって、ペイロードエラーがあるか否かを示していると解釈されるべきものである、ことを意味する。ペイロードエラーは、フレームトレーラーにフラグを設定することによって示すことができる。これは、中間ノードにおいて追加されたであろう新しいフレームトレーラー内か、または既存のフレームトレーラー、すなわち中間ノードに到着するフレームのフレームトレーラー内である可能性がある。当業者には、ペイロードエラーの有無の区別は、ペイロードエラーがある場合は設定されたフラグを有すること、およびペイロードエラーがない場合はクリアされたフラグを有すること、または逆に、ペイロードエラーがない場合は設定されたフラグを有すること、およびペイロードエラーがある場合はクリアされたフラグを有すること、のいずれかによって行えることが明らかである。ペイロードエラーが、特殊レイヤ2シンボルにより示されようと、フラグにより示されようと、トランスミッタによって正しいフレームCRCが付加される。両方の選択肢により、フレームのレシーバは、フレームを同じ様に処理する。フレームに信頼性がある場合には、フレームは破棄される。任意で、NACフレームを用いて、トランスミッタに対してエラーが示される。フレームがリアルタイムの場合には、フレームは破棄され、その再生フラグにより示されるように、リアルタイムフレームを再送信できる場合にのみ、エラー報告が返される。そうでない場合(再送信が許可されていない場合)には、リアルタイムフレームが受け付けられ、さらに送信されるが、しかし、エラーのあるペイロードを保持しているとマークされる。
ペイロードエラーを示す代わりのやり方は、トランスミッタで、フレームCRCを悪化させる(すなわち、エラーのあるCRCを挿入する)ことである。しかし、この場合には、現在のリンクで生じるエラーと前のリンクで生じるエラーとを、区別することができない。その結果、この方法を用いたプロトコルは、これらのエラーを処理する際に、方法が有する選択肢の選択が制限されるであろう。
NACフレームは、シーケンス番号を保持して示されている。これは、プロトコルでは原理的に可能であるが、UniProでは許可されていない。UniProでのシーケンス番号の欠如を補償するために、NACフレームにAFCフレームを先行させて、最後に正しく受信されたフレームのシーケンス番号を保持させることができる。フレームが、ヘッダCRCによって保護されている場合には、フレームトラフィッククラスは、正しいことが知られている。その結果、エラーを報告するNACフレームにフラグを立て、エラーが生じたトラフィッククラスを示してもよい。このやり方では、トランスミッタはより選択的とすることができ、影響されるトラフィッククラスに対してのみ、再送信動作を行う。
NACがリンク1で受信された後に、フレーム4(正しく受信されたことがNACにより報告されている)は、ノードAの再送信バッファから除去され、フレーム5が再送信される。リンク2において、NACフレームは、フレーム8が正しく受信されたことを報告しており、その結果、フレーム8は、フレームBの再送信バッファから除去されている。しかし、元のカットスルーは、再送信することができず、それは、破損しているとフラグが立てられ、かつ、ノードBの再送信バッファに保存されなかったからである(フレームCRCによって正しいと証明された場合にのみ、フレームは再送信バッファに引き渡される)。他のリンクから、他のフレームが利用可能な場合もあり、かつ、それらのフレームを送信することができる(例えば、図13の第2のフレーム#9)再送信フレーム(例えば、信頼性のあるフレーム)の場合には、結局は、元のカットスルーフレームが来て、フレーム10として再送信される。
図13では、フレーム9エラーの検出に応じて送られたNACフレームが、リアルタイムデータフレームのために必要である。EOF_ERRトレーラーにより、破損しているとラベル付けされた信頼性のあるデータフレーム(あるいはPERRトレーラーとも呼ばれる)の場合には、NACフレームの送信はスキップすることができる。代替の実施形態では、ノードBは、EOF_ERR表示を受信すると、再送信バッファからフレーム9を直接除去し、かつ、フレームシーケンス番号およびクレジットを自動的にロールバックすることができる。
図13ならびに図14Aおよび(b)の例示的な実施形態に係る上述のパケットカットスルー技術を実施するために、例えば、UniProノードに対するいくつかの変更を行うことができる。例えば、UniPro L2レシーバパーサーは、正しいフレームCRCを有するフレーム内の破損したペイロードを示す追加のシンボルを処理できることが必要である。図15では、EoFベースのフレームを用いたレシーバの例が示されている。このような場合には、Rxは、EOF L2シンボルの代わりに来るEOF_ERR L2シンボルも受信可能でなければならない。EOF_ERRシンボルが受信された場合には、EOF_ERR変数が真に設定されるので、状態TCO_crcにおいて、フレームCRCが正しいと証明された場合には、通常のエラー手順が行われる(有効化されていればNAC生成)が、これは、NACGenOkを真に設定せずに行われる。Rxの他の部分(例えばTC1、AFC等)またはフレームフォーマットの変更されたバージョン用のRxについては、変更点は同様である。
カットスルーパッケージを扱う必要がないUniPro L2レシーバは、フレームCRCが、フレームが正しいと証明するまで、Rxバッファに到来データを保存する。フレームは、フレームが正しいと証明された後にのみ、レイヤ3に対して利用可能となる。しかし、カットスルーの場合では、フレームは、CRCチェックの前に、レイヤ3に対して利用可能となる必要がある。自然時間が、レイヤ2ヘッダが受信された直後に、レイヤ3にフレームの供給を開始することとなるが、他の代替案も可能である。この例示的な実施形態に係るUniProレイヤ2も、フレームペイロードが破損している(そのようにラベル付けされているため、またはフレームCRCが誤っているためのいずれかで)ことを示すレイヤ3への表示を提供する。パケットがレイヤ3で経路指定されると、この表示は、トランスミッタポートで、レイヤ2に供給される。UniProレイヤ2トランスミッタは、外部に向かうデータフレームに、誤りのあるペイロードを有するとラベル付けする(例えば、EOF_ERRシンボルを付加することによって)。再送信することができる、信頼性のあるフレームおよびリアルタイムフレームに対して、ペイロードが破損している場合には、フレームは再送信バッファから除去される。この結果、再送信されたフレームのシーケンス番号が1ロールバックされる。信頼性のあるフレームでは、フロー制御クレジットを使用した利用可能なレイヤ2が、カットスルーフレームを送信する際に消費されたクレジットの分だけロールバックされる。再送信することができる、信頼性のあるフレームおよびリアルタイムのフレームでは、レシーバは、また、EOF_ERRとマークされたフレームを、そのRxバッファから除去する。この結果、予想されるシーケンス番号も進まない(正しいフレームの場合と同様)。
例示的な実施形態によると、方法、デバイスおよびシステムは、ネットワーク内で早く、すなわちフレームCRCが受信され、かつ、確認される前に、パケットの送信開始を可能にする。このようにして、パケットが最終送付先に供給される際に、CRCチェックにより導入される遅延ペナルティは、1度だけ受けられる。その結果、送信レイテンシは、著しく減少する。この利益を定量化するため、および純粋に例示として、パケットが3つのリンクを介して送られる場合には、各リンクで約1μsを要し(フレームCRCチェックのため)、合計のパケットレイテンシは3μsである。カットスルーする場合には、最初の2つのリンクでのパケット遅延は、約100nsまで減少することができ、1.2μsの合計パケット遅延時間をもたらす。
図13の実施形態と同様に、もう1つの例示的な実施形態が、TC0/TC1パケットカットスルーを示す図16として提供される。スイッチでは、DeviceIDが受信される際に、カットスルーを開始することができるのに対して、終点では、ペイロードは、CRCチェックが行なわれているはずなので、カットスルーは行われない。レシーバでエラーが検出された場合には、全ての進行中のカットスルーパケットは、EOF_ERRトレーラーによりエラーがあるとラベル付けされ、かつ、NACが生成される。カットスルーパケットは、Tx再生バッファに格納され、かつ、良いフレームCRCの場合には、引き渡され、または、ローカルRxから報告された(CRC)エラーもしくはEOF_ERRの場合には、削除される。TxがNACを受信した場合には、Txは、全ての肯定応答されていない引き渡されたフレームを再生し、かつ、無効なカットスルーフレームが受信された場合には、フレームに番号が付け直される。例示的な実施形態に係るこの機能に対応するために、EOF_ERR制御シンボルが付加されるが、このシンボルは、TC2でも、ペイロードエラーを示すために使用される。エラーの場合には、EOF_ERRにより既に送信されているフレームは、L2再送信によってスキップされ、かつ、L2再送信は、スキップされた無効フレームのために、番号を付け直してもよい。対応するトランスミッタ状態機械およびレシーバ状態機械が、図17A−17Bおよび図18として、それぞれ示されている。
これらの例示的な実施形態によれば、ヘッダCRCを有する長さベースのフレームは、ヘッダエラーが起こった場合には、より早いエラーリカバリを提供する。TCが正しいと証明された場合には、これは、誤ったTCにより生じたバッファオーバーフローを回避し、かつ、帯域幅予約(v2.0)の場合の、偶発的な帯域幅請求を回避する。DeviceIDが正しいと証明された場合には、これは、DeviceIDエラーによる他のリンクの偶発的なロードを防止する。
よって、1つの例示的な実施形態によれば、中間ノードから終点ノードに向けてデータを送信する方法は、図19のフローチャートに示されるステップを含む。ここで、ステップ1900において、中間ノード、例えば図13のノードBにおいて、第1のデータフレームが受信される。ステップ1902において、第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC)を行う前に、第2のデータフレームにおいて、終点ノード(例えば図13のノードC)に向けた第1のデータフレームに含まれるデータパケットの再送信を開始するが、このフレームCRCフィールドは、第1のデータフレームの少なくとも1つの非CRCフィールドに基づき計算されたものである。中間ノードは、データパケットの再送信を開始した後に、図1904に示されるように、フレームCRCフィールドを用いて、第1のデータフレームに対して第1のCRCを行う。次いで、中間ノードは、ステップ1906において、第1のデータフレームが破損している、すなわち1つまたは複数のエラーを含む、ことを決定する。その結果、ステップ1908において、中間ノードは、第2のデータフレームに含まれているデータパケットが破損していることを示す、第2のデータフレームと関連するフレームトレーラーを送信する。
図19に示される方法および上述の例示的な実施形態と関連する他の方法は、相互接続システムの一部として、様々なノード構造およびアーキテクチャを用いて実施することができることを、当業者は理解するであろう。上述のやり方でカットスルーパケットを処理する中間ノード(スイッチングデバイス)または終点ノード(例えば、フレームデータレシーバ)2000の概略的な例示が、図20として提供される。ここで、例えば中間ノードとして動作する場合に、ノード2000は、第1のデータフレームを受信するように構成された第1のインターフェイス2002と、第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC)を行う前に、終点ノードに向けた第2のデータフレームとしての第1のデータフレームに含まれるデータパケットの再送信を開始するように構成された第2のインターフェイス2004であって、フレームCRCフィールドは、第1のデータフレームの少なくとも1つの非CRCフィールドに基づき計算された、第2のインターフェイス2004と、を含むことができる。第1および第2のインターフェイスは、インターフェイスコントローラ2005によって制御することができる。ノード2000は、また、再送信を開始した後に、フレームCRCフィールドを用いて、第1のデータフレームに対して第1のCRCを行い、第1のデータフレームに対するCRCの結果として、第1のデータフレームが1つまたは複数のエラーを含み破損していることを決定するように構成された、プロセッサ2006を含むことができる。スイッチングデバイスは、第2のデータフレームに含まれたデータパケットを示す第2のデータフレームと関連するフレームトレーラーを、第2のインターフェイス2004を介して送信するように、例えばプロセッサ2006と併せて、さらに構成することができる。また、メモリデバイス2008を設けることができるが、このメモリデバイスは、特に、上述したような再送信バッファとして動作することができる。
ノード2000が、終点ノード(または任意のカットスルーフレームデータレシーバ)として動作する場合には、第1のインターフェイス2002は、カットスルーデータフレームを受信するように構成することができる。プロセッサ2006は、次いで、カットスルーデータフレームと関連する周期的冗長性検査(CRC)フィールド以外のデータフィールドを評価して、カットスルーデータパケットが破損しているか否か、すなわち1つまたは複数のエラーを含むか否か、を決定するように構成することができる。
よって、データパケットを含み、かつ、第1のフレームトレーラーを有するデータフレームを、フレームデータレシーバにおいて受信する、例示的な実施形態に係る方法が、図21のフローチャートに示されている。ステップ2100において、フレームデータレシーバの第1のインターフェイスにおいて、データフレームが受信される。ステップ2102において、フレームデータレシーバによって、前記データフレーム内のフレームCRCフィールドを用いて、周期的冗長性検査(CRC)が行われるが、フレームCRCフィールドは、データフレームの少なくとも1つの非CRCフィールドに基づき計算されている。第1のCRCの結果として、フレームデータレシーバによって、ステップ2104において、データフレームが破損していないことが決定される。しかし、ステップ2106において、データパケットが破損していることをフレームトレーラーから決定し、かつ、関連する動作、例えば上述した動作のいずれかが行われる。
上述の例示的な実施形態の様々な変形が考えられる。上述の例示的な実施形態は、全ての点で、本発明の限定ではなく例示であることを意図している。よって、本発明は、当業者によって、ここに含まれる説明から得ることができる詳細な実施において、様々な変形が可能である。このような変形および変更の全ては、添付の特許請求の範囲で定義されるように、本発明の範囲および要旨内にあるとみなされる。本発明の説明に用いられた要素、動作、または指示は、そのように明らかに説明されていない限り、本発明にとって重要または必須であると解釈されるべきではない。また、ここで用いられるように、冠詞a(1つの)は、1つまたは複数の項目を含むことを意図している。
Claims (25)
- 終点ノードに向けてデータを送信する方法であって、
中間ノードにおいて、データパケットを含む第1のデータフレームを受信するステップと、
前記第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC:cyclic redundancy check)を行う前に、前記中間ノードによって、第2のデータフレームにおいて前記終点ノードに向けた前記第1のデータフレームに含まれるデータパケットの再送信を開始するステップであって、前記フレームCRCフィールドは、前記第1のデータフレームの少なくとも1つの非CRCフィールドに基づいて計算されている、ステップと、
前記中間ノードによって、かつ、前記再送信を開始した後に、前記フレームCRCフィールドを用いて、前記第1のデータフレームに対して前記第1のCRCを行うステップと、
前記第1のCRCの結果として、前記中間ノードによって、前記第1のデータフレームが、1つまたは複数のエラーを含み破損していることを決定するステップと、
前記第2のデータフレームに含まれる前記データパケットが1つまたは複数のエラーを含み破損していることを示す、前記第2のデータフレームと関連するフレームトレーラーを、前記中間ノードによって前記終点ノードに向けて送信するステップと、を含むことを特徴とする方法。 - 前記フレームCRCフィールドは、前記第1のデータフレームの全ての非CRCフィールドに基づき計算される、ことを特徴とする請求項1に記載の方法。
- 前記第1のデータフレームは、ヘッダCRCフィールドをさらに含み、前記ヘッダCRCフィールドは、前記第1のフレームのヘッダの少なくとも1つの非CRCフィールドと、前記データパケットのヘッダと、前記データパケットのペイロードの少なくとも一部分とに基づき計算されており、前記方法は、
前記データパケットの再送信を開始する前に、前記中間ノードによって、前記ヘッダCRCフィールドを用いて第2のCRCを行うステップと、
前記少なくとも1つのヘッダフィールドが、前記第2のCRCに失敗した場合に、前記データパケットを再送信する代わりに、前記データパケットを破棄するステップと、をさらに含むことを特徴とする請求項1に記載の方法。 - 前記第1のデータフレームは、ヘッダCRCフィールドを含まず、
前記再送信ステップは、
前記データパケット内のレイヤ3(L3)送付先デバイス識別フィールドが、前記中間ノードによって受信された場合に、前記データパケットの再送信を開始するステップをさらに含む、ことを特徴とする請求項1に記載の方法。 - 前記中間ノードによって、前記フレームトレーラーを送信するステップは、
前記第2のデータフレーム内の前記フレームトレーラーとして、特殊レイヤ2シンボルを追加するステップであって、前記特殊レイヤ2シンボルは、前記第2のデータフレームが破損していることを示す、ステップをさらに含む、ことを特徴とする請求項1に記載の方法。 - 前記フレームトレーラーを送信する前記ステップは、
前記第2のデータフレーム内のフレームトレーラーにおいて、フラグを設定するステップであって、前記フラグは、前記第2のデータフレームが破損していることを示す、ステップをさらに含む、ことを特徴とする請求項1に記載の方法。 - 再送信されている前記第2のデータフレームのための第2のフレームCRCフィールドを計算し、前記第2のフレームCRCフィールドを、前記第2のデータフレームに付加し、かつ、前記第2のフレームCRCフィールドを、前記第2のデータフレームと共に送信するステップをさらに含む、ことを特徴とする請求項5に記載の方法。
- スイッチングデバイスであって、
第1のデータフレームを受信するように構成された第1のインターフェイスと、
前記第1のデータフレーム内のフレームCRCフィールドを用いて、第1の周期的冗長性検査(CRC)を行う前に、終点に向けた第2のデータフレームとしての前記第1のデータフレームに含まれる前記データパケットの再送信を開始するものであり、前記フレームCRCフィールドが、前記第1のデータフレームの少なくとも1つの非CRCフィールドに基づき計算されている、ように構成された第2のインターフェイスと、
前記第1のインターフェイスおよび前記第2のインターフェイスを制御するように構成されたインターフェイスコントローラと、
前記再送信を開始した後に、前記フレームCRCフィールドを用いて、前記第1のデータフレームに対して前記第1のCRCを行い、かつ、前記第1のデータフレームに対する前記CRCの結果として、前記第1のデータフレームが1つまたは複数のエラーを含み破損していることを決定するように構成されたプロセッサと、を備え、
前記スイッチングデバイスは、前記第2のインターフェイスを介して、前記第2のデータフレームに含まれた前記データパケットが破損していることを示す前記第2のデータフレームと関連するフレームトレーラーを送信するようにさらに構成される、ことを特徴とするスイッチングデバイス。 - 前記フレームCRCフィールドは、前記第1のデータフレームの全ての非CRCフィールドに基づき計算される、ことを特徴とする請求項8に記載のスイッチングデバイス。
- 前記第1のデータフレームは、ヘッダCRCフィールドをさらに含み、前記ヘッダCRCフィールドは、前記第1のフレームのヘッダの少なくとも1つの非CRCフィールドと、前記パケットのヘッダと、前記データパケットのペイロードの少なくとも一部分とに基づき計算されており、前記プロセッサは、前記第2のインターフェイスを介して、前記データパケットの再送信を開始する前に、前記少なくとも1つのヘッダフィールドに対して第2のCRCを行うようにさらに構成されており、
前記スイッチングデバイスは、前記第2のCRCが失敗した場合に、前記データパケットを再送信する代わりに、前記データパケットを破棄するようにさらに構成される、ことを特徴とする請求項8に記載のスイッチングデバイス。 - 前記第1のデータフレームは、ヘッダCRCフィールドを含まず、前記スイッチングデバイスは、前記データパケット内のレイヤ3(L3)送付先デバイス識別フィールドが、前記第1のインターフェイスにおいて受信された場合に、前記第2のインターフェイスを介して、前記データパケットの再送信を開始するようにさらに構成される、ことを特徴とする請求項8に記載のスイッチングデバイス。
- 前記フレームトレーラーは、前記フレームトレーラーに対する特殊レイヤ2シンボルとして追加され、前記特殊レイヤ2シンボルは、前記第2のデータパケットが破損していることを示す、ことを特徴とする請求項8に記載のスイッチングデバイス。
- 前記フレームトレーラーは、設定されている場合に、前記第2のデータフレームが破損していることを示すフラグをさらに含む、ことを特徴とする請求項8に記載のスイッチングデバイス。
- 前記プロセッサは、送信されている前記第2のデータフレームに対して、正しいフレームCRCフィールドを付加するようにさらに構成される、ことを特徴とする請求項12に記載のスイッチングデバイス。
- データパケットを含み、かつ、第1のフレームトレーラーを有する、データフレームを、フレームデータレシーバにおいて、受信する方法であって、
前記フレームデータレシーバの第1のインターフェイスにおいて、前記データフレームを受信するステップと、
前記フレームデータレシーバによって、前記データフレーム内のフレームCRCフィールドを用いて、周期的冗長性検査(CRC)を行うステップであって、前記フレームCRCフィールドは、前記データフレームの少なくとも1つの非CRCフィールドに基づき計算されている、ステップと、
前記CRCの結果として、前記フレームデータレシーバによって、前記データフレームが破損していないことを決定するステップと、
前記データパケットが1つまたは複数のエラーを含み破損していることを、前記フレームトレーラーから決定し、かつ、関連する動作を行うステップと、を含むことを特徴とする方法。 - 前記関連する動作は、前記データパケットを破棄することである、ことを特徴とする請求項15に記載の方法。
- 前記関連する動作は、前記データパケットを保持し、かつ、前記データパケットが破損していることを示す信号を送信することである、ことを特徴とする請求項15に記載の方法。
- 前記データパケットが破損していることを決定する前記ステップは、前記フレームトレーラーに特殊レイヤ2シンボルが存在することを検出するステップであって、前記特殊レイヤ2シンボルは、前記データパケットが破損していることを示す、ステップを含む、ことを特徴とする請求項15に記載の方法。
- 前記データパケットが破損していることを決定する前記ステップは、前記フレームトレーラーが、設定されている場合に、フラグを含むことを検出するステップであって、前記フラグは、前記データフレームが破損していることを示す、ステップを含む、ことを特徴とする請求項15に記載の方法。
- 前記関連する動作は、否定応答制御(NAC:negative acknowledgement control)フレームの送信をスキップすることをさらに含む、ことを特徴とする請求項15に記載の方法。
- 前記関連する動作は、再送信バッファから、前記データフレームを除去し、フレームシーケンス番号をロールバックすることをさらに含む、ことを特徴とする請求項15に記載の方法。
- フレームデータレシーバであって、
データパケットを含み、かつ、フレームトレーラーを有する、カットスルーデータフレームを受信するように構成されたインターフェイスと、
1または複数のプロセッサと、を備え、
前記1または複数のプロセッサは、
前記データフレーム内のフレームCRCフィールドを用いて、周期的冗長性検査(CRC)を行い、前記フレームCRCフィールドは、前記データフレームの少なくとも1つの非CRCフィールドに基づき計算されており、
前記CRCの結果として、前記データフレームが破損していないことを決定し、
前記データパケットが1つまたは複数のエラーを含み破損していることを、前記フレームトレーラーから決定し、関連する動作を開始するように構成される、ことを特徴とするフレームデータレシーバ。 - 前記データパケットが破損していることを決定することは、前記フレームトレーラーに特殊レイヤ2シンボルが存在することを検出することを含み、前記特殊レイヤ2シンボルは、前記データパケットが破損していることを示す、ことを特徴とする請求項22に記載のフレームデータレシーバ。
- 前記データパケットが破損していることを決定することは、前記フレームトレーラーがフラグを含むことを検出することを含み、前記フラグは、前記データフレームが破損していることを示す、ことを特徴とする請求項23に記載のフレームデータレシーバ。
- 前記カットスルーデータフレームが破損していないことを決定することは、前記データフレームに正しいフレームCRCフィールドが存在することを検出することを含む、ことを特徴とする請求項22に記載のフレームデータレシーバ。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US26674709P | 2009-12-04 | 2009-12-04 | |
US61/266,747 | 2009-12-04 | ||
US12/958,745 | 2010-12-02 | ||
US12/958,745 US8402343B2 (en) | 2009-12-04 | 2010-12-02 | Reliable packet cut-through |
PCT/EP2010/068842 WO2011067381A1 (en) | 2009-12-04 | 2010-12-03 | Reliable packet cut-through |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2013513269A true JP2013513269A (ja) | 2013-04-18 |
Family
ID=43447131
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012541521A Pending JP2013513269A (ja) | 2009-12-04 | 2010-12-03 | 信頼性のあるパケットカットスルー |
Country Status (4)
Country | Link |
---|---|
US (1) | US8402343B2 (ja) |
EP (1) | EP2507914A1 (ja) |
JP (1) | JP2013513269A (ja) |
WO (1) | WO2011067381A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017163316A (ja) * | 2016-03-09 | 2017-09-14 | 東芝メモリ株式会社 | 情報処理装置 |
US10592299B2 (en) | 2017-09-06 | 2020-03-17 | Fujitsu Limited | Computation node device, parallel computer system, and control method for computation node device |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101594059B1 (ko) * | 2011-12-08 | 2016-02-26 | 퀄컴 테크놀로지스, 인크. | 정상 데이터 송신과 재시도 데이터 송신 사이에서의 차동 포매팅 |
US9075736B2 (en) | 2013-01-07 | 2015-07-07 | Qualcomm Incorporated | Additional error protection for wireless transmission |
US9152494B2 (en) * | 2013-03-15 | 2015-10-06 | Cavium, Inc. | Method and apparatus for data packet integrity checking in a processor |
EP2814193B1 (de) * | 2013-06-14 | 2016-11-16 | Siemens Aktiengesellschaft | Verfahren und system zur erkennung von fehlern bei der übertragung von daten von einem sender zu zumindest einem empfänger |
US20150089047A1 (en) * | 2013-09-20 | 2015-03-26 | Broadcom Corporation | Cut-through packet management |
US10394751B2 (en) | 2013-11-06 | 2019-08-27 | Solarflare Communications, Inc. | Programmed input/output mode |
US10270705B1 (en) * | 2013-12-18 | 2019-04-23 | Violin Systems Llc | Transmission of stateful data over a stateless communications channel |
KR102498223B1 (ko) | 2015-10-13 | 2023-02-09 | 삼성전자주식회사 | Ufs 장치의 작동 방법, ufs 호스트의 작동 방법, 및 이들을 포함하는 시스템의 작동 방법 |
KR102563888B1 (ko) | 2016-09-30 | 2023-08-09 | 한국전기연구원 | 네트워크 환경에서 데이터 프레임 중복 제거 방법, 그 방법을 수행하는 장치 및 컴퓨터 프로그램 |
EP3767851B1 (en) | 2018-03-31 | 2023-08-30 | Huawei Technologies Co., Ltd. | Frame error indication |
US10958587B2 (en) * | 2018-07-24 | 2021-03-23 | Intel Corporation | Transmission latency reduction |
US10880234B2 (en) | 2019-05-21 | 2020-12-29 | Mellanox Technologies Tlv Ltd. | Cut-through switching system |
US11310098B2 (en) * | 2020-06-09 | 2022-04-19 | Cisco Technology, Inc. | Diagnosing intermediary network nodes |
TW202306365A (zh) | 2021-07-29 | 2023-02-01 | 韓商愛思開海力士有限公司 | 用於互連協定的訊框接收的資料處理的方法以及儲存裝置 |
TW202310594A (zh) * | 2021-08-19 | 2023-03-01 | 韓商愛思開海力士有限公司 | 用於互連協定的錯誤處理的方法、控制器以及儲存裝置 |
TW202311971A (zh) | 2021-09-09 | 2023-03-16 | 韓商愛思開海力士有限公司 | 用於互連協定的資料處理的方法、控制器以及儲存裝置 |
CN114416616B (zh) * | 2021-11-26 | 2024-06-18 | 兰州飞天网景信息产业有限公司 | 一种跨节点直连分片交换*** |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002199042A (ja) * | 2000-12-26 | 2002-07-12 | Nec Corp | Gfpフレーム転送装置およびgfpフレーム転送方法 |
WO2004066562A1 (ja) * | 2003-01-24 | 2004-08-05 | Fujitsu Limited | データ転送装置 |
WO2006020298A2 (en) * | 2004-07-19 | 2006-02-23 | Blumrich Matthias A | Collective network for computer structures |
WO2008152592A1 (en) * | 2007-06-13 | 2008-12-18 | Nxp B.V. | Electronic device and method of ensuring guaranteed services |
JP2009527976A (ja) * | 2006-02-23 | 2009-07-30 | サムスン エレクトロニクス カンパニー リミテッド | ネットワーク中継装置及びその方法 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6226299B1 (en) | 1999-01-20 | 2001-05-01 | Emulex Corporation | Sanitizing fibre channel frames |
US20020087716A1 (en) * | 2000-07-25 | 2002-07-04 | Shakeel Mustafa | System and method for transmitting customized multi priority services on a single or multiple links over data link layer frames |
US8626957B2 (en) * | 2003-08-22 | 2014-01-07 | International Business Machines Corporation | Collective network for computer structures |
KR101203471B1 (ko) * | 2006-06-29 | 2012-11-21 | 삼성전자주식회사 | 네트워크 브리지에서 이더넷 프레임을 전달하는 방법 및상기 브리지 장치 |
CN102047600A (zh) | 2008-01-18 | 2011-05-04 | 意法爱立信有限公司 | 发射机和接收机之间基于帧的尤其是具有帧中止或重发指示能力的通信方法以及通信节点 |
-
2010
- 2010-12-02 US US12/958,745 patent/US8402343B2/en active Active
- 2010-12-03 EP EP10784818A patent/EP2507914A1/en not_active Withdrawn
- 2010-12-03 WO PCT/EP2010/068842 patent/WO2011067381A1/en active Application Filing
- 2010-12-03 JP JP2012541521A patent/JP2013513269A/ja active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002199042A (ja) * | 2000-12-26 | 2002-07-12 | Nec Corp | Gfpフレーム転送装置およびgfpフレーム転送方法 |
WO2004066562A1 (ja) * | 2003-01-24 | 2004-08-05 | Fujitsu Limited | データ転送装置 |
WO2006020298A2 (en) * | 2004-07-19 | 2006-02-23 | Blumrich Matthias A | Collective network for computer structures |
JP2009527976A (ja) * | 2006-02-23 | 2009-07-30 | サムスン エレクトロニクス カンパニー リミテッド | ネットワーク中継装置及びその方法 |
WO2008152592A1 (en) * | 2007-06-13 | 2008-12-18 | Nxp B.V. | Electronic device and method of ensuring guaranteed services |
Non-Patent Citations (1)
Title |
---|
JPN6014046081; David Christoph Slogsnat: Tightly-Coupled and Fault-Tolerant Communication in Parallel Systems , 2008, p.165,166,172,177,178 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017163316A (ja) * | 2016-03-09 | 2017-09-14 | 東芝メモリ株式会社 | 情報処理装置 |
US10592299B2 (en) | 2017-09-06 | 2020-03-17 | Fujitsu Limited | Computation node device, parallel computer system, and control method for computation node device |
Also Published As
Publication number | Publication date |
---|---|
EP2507914A1 (en) | 2012-10-10 |
US20110161777A1 (en) | 2011-06-30 |
WO2011067381A1 (en) | 2011-06-09 |
US8402343B2 (en) | 2013-03-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2013513269A (ja) | 信頼性のあるパケットカットスルー | |
US7746786B2 (en) | Retransmission control method and device | |
JP4414442B2 (ja) | 広帯域無線接続通信システムにおける自動再伝送要求運用装置及び方法 | |
US20080195912A1 (en) | Method of communicatoin | |
US9577791B2 (en) | Notification by network element of packet drops | |
WO2014092779A1 (en) | Notification by network element of packet drops | |
US9007904B2 (en) | System to improve an ethernet network | |
JP2004537919A (ja) | パケットベースの通信システムのための前方エラー訂正システム及び方法 | |
US8335958B2 (en) | Method of communication, in particular with capability of frame abortion or retransmission indication, between a transmitter and a receiver based on frames and corresponding communication node | |
US7653060B2 (en) | System and method for implementing ASI over long distances | |
TWI526019B (zh) | 用於在無線區域網路系統中處理封包之方法及裝置 | |
KR20100104149A (ko) | 전송계층 성능 향상을 위한 전송계층 제어장치 및 전송속도와 신뢰성을 동시에 보장할 수 있는 패킷 송신 방법 | |
US9876727B2 (en) | Physical-layer signaling of flow control updates | |
CN109981385B (zh) | 一种实现丢包检测的方法、装置和*** | |
WO2015085875A1 (zh) | 流媒体报文的处理方法、WiFi芯片及移动终端 | |
WO2022042543A1 (zh) | 一种以太网错误帧的重传方法及相关装置 | |
JP4807828B2 (ja) | ブロードバンド・エンジンのためのエンベロープ・パケット・アーキテクチュア | |
US7623546B1 (en) | Latency improvement for file transfers over network connections | |
JP2004048474A (ja) | エレベータのデータ伝送装置 | |
CN108183767A (zh) | 一种适用于空间dtn网络的可靠传输方法 | |
KR101611663B1 (ko) | 비연결 지향형 프로토콜을 이용한 데이터 통신 | |
JPH10242946A (ja) | データフレーム伝送方法 | |
US7907613B1 (en) | Method and apparatus for measuring RTT in a cumulative acknowledgment transmission protocol | |
KR100780921B1 (ko) | 청크첵섬을 사용하는 무선 인터넷 에스씨티피 송수신시스템 및 방법 | |
JP2007201927A (ja) | エラーレート推定装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20131202 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20141024 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20141031 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20150403 |