JP3614907B2 - データ再送制御方法及びデータ再送制御システム - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は、ＦＥＣによる誤り訂正機能及び再送による誤り訂正機能を用いた通信におけるデータ再送制御方法及びデータ再送制御システムに関する。
【０００２】
【従来の技術】
多種多様な情報をＡＴＭセルを用いた通信形態に適応させるには、ＡＴＭ網と上位レイヤとのインタワークが必要であり、その機能を備えたＡＡＬがＡＴＭレイヤと上位レイヤの間に存在する。
【０００３】
図３１に、ＡＴＭアダプテーションレイヤの一例としてＡＡＬタイプ５の位置づけを示す。タイプ５の場合、ＡＡＬは大きく分けてＣＳレイヤ（Ｃｏｎｖｅｒｇｅｎｃｅ Ｓｕｂｌａｙｅｒ）とＳＡＲレイヤ（Ｓｅｇｍｅｎｔａｔｉｏｎ ａｎｄ Ｒｅａｓｓｅｍｂｌｅ）の２つのサブレイヤからなっている。ＣＳレイヤはさらに２つのサブレイヤからなっており、ＣＰＣＳレイヤ（Ｃｏｍｍｏｎ Ｐａｒｔ ＣＳ）はサービスの種類に係わらず必要となる処理を、また、ＳＳＣＳレイヤ（Ｓｅｒｖｉｃｅ Ｓｐｅｃｉｆｉｃ ＣＳ）はサービスに依存して行われる処理を受け持っている。従って、ＳＳＣＳレイヤがヌルの場合も有る。ＳＡＲレイヤは、主にデータの分解／組立を行っており、送信時にはＡＴＭレイヤでＡＴＭヘッダを付与することができるサイズ、つまりペイロードサイズである４８オクテットにデータを区切って下位レイヤに渡す処理を行う。それとは反対に、受信時には下位レイヤからペイロードサイズのデータを受け取り、ＣＳ−ＰＤＵに組み立ててＣＳレイヤに渡す。
【０００４】
現在までに、ＡＡＬは扱う情報の種類に応じて４つのタイプがＩＴＵ−Ｔなどにより標準化されている。具体的には、ＡＡＬ１は固定ビットレートの音声・画像などのリアルタイム通信、ＡＡＬ２は可変ビットレートのリアルタイム通信、ＡＡＬ３／４と５は可変データ通信用（但し、ＡＡＬ３と５はコネクションオリエンテッド（ＣＯ）通信用、ＡＡＬ４はコネクションレス（ＣＬ））となっている。
【０００５】
この中でも、特に、ＡＡＬ３／４と５はデータ通信用であることから、わずか１ビットのビット誤りでさえ許容されないようなデータの正確さ、換言すると受信したデータが送信したデータと完全に同一のものであるということを保証できるような信頼性が要求されるアプリケーションの存在が考えられる。また、ＡＡＬ１、２といったリアルタイムアプリケーションで高いＱＯＳが要求されるような場合にも、データ自体の信頼性が必要となってくることは言うまでもない。
【０００６】
しかし、現状ではＡＴＭ技術についてはプリミティブな部分の標準化に留まっており、ＡＡＬにて誤り制御機能が十分には提供されていない。このため、正確さが要求されるデータ通信をＡＡＬ３／４、あるいはＡＡＬ５のユーザが求める場合、例えばＡＡＬ５であれば、標準の決まっていないＣＰＣＳレイヤよりも上位のレイヤに、信頼性を保証させるプロトコルを実装する必要がある。ＡＡＬ５のＣＰＣＳレイヤ以下では仕様が固まっており、すでに標準化されているため、サービスに依存した新しい機能を付加する場合にはＣＰＣＳレイヤよりも上位のレイヤでなければならない。
【０００７】
これまで知られている例としては、ＳＳＣＳレイヤ（Ｓｅｒｖｉｃｅ Ｓｐｅｃｉｆｉｃ Ｃｏｎｖｅｒｇｅｎｃｅ Ｓｕｂｌａｙｅｒ；サービス依存ＣＳレイヤ）に再送制御を基本としたプロトコルを実装する方法（例えば、ＩＴＵ−ＴのＱ．ＳＡＡＬプロトコル）や、ＳＳＣＳレイヤをヌルとし、その上位にトランスポートレイヤプロトコル（例えば、ＴＣＰやＯＳＩ／ＴＰ４など）を実装する方法などがある。
【０００８】
上記のような方法は、全て再送によりその信頼性を確保する方法である。
【０００９】
しかしながら、（１）大容量トランザクションなど、大容量で実時間性が求められ（すなわち再送制御が基本的に許されない）、かつ信頼性も要求されるアプリケーションが今後ますます増えていくと考えられる。
【００１０】
また、（２）ＬＡＮ、ＭＡＮ、ＷＡＮなど、通信網の広域化がなされている。通信網が広域であればあるほど、上記のレイテンシイの確保と、再送による誤り制御とは相いれないものとなってくる（情報の再送には莫大な時間がかかる）。
【００１１】
また、（３）一般に、再送による誤り制御を行う方式においては、再送の単位は上位レイヤパケット群（具体的には、例えばＴＣＰパケットや、レイヤ４パケットグループ）であり、セルの廃棄といった比較的小さな単位のデータ消失に対し、大きなデータの再送を求めるものとなっており、網資源の浪費につながる場合がある。
【００１２】
このような理由により、上述した再送を基本とする誤り制御方法をＡＴＭ端末上に実装するのみでは対処が難しいデータ通信領域が、今後ますます増大していくことが考えられる。特に、リアルタイム性が重視される場合には、リアルタイム性の確保が必須であり、再送を基本とする誤り制御方法による対処では極めて難しい。
【００１３】
そこで、１９９４年電子情報通信学会春季大会にて本発明者らは、“Ｂ−７８６ ＡＴＭ網における誤り制御方式、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）ｏｎ ＡＡＬ Ｔｙｐｅ ５”と題してＦＥＣをＡＡＬ５に実装する方法を提案している。この方式は、送信するデータに対して誤り訂正符号を付与して通信を行い、網内にて多少の情報の廃棄や誤りが生じた場合でも受信側において消失情報の再生を行うという、信頼性のある通信を行うための別のアプローチを適用したものである。より具体的には、ＡＡＬ１のＣＳレイヤにおけるオプションとして用意されている誤り訂正符号と同様の符号をＡＡＬ５のＳＳＣＳレイヤ以上の部分に適用するものである。ＡＡＬ１では、送信側から受信側へ音声・映像などのリアルタイム通信を行うため、再送が現実的にできないことから、該データに誤り制御符号を付与して、伝送中のエラーに対する耐性を強くするといった工夫が行なわれている。この方法と同様のインタリーブ方式を用いて、ＦＥＣ冗長コードをＡＡＬ５のデータに対して付加することによって（再送を必要としない）リアルタイム通信や、信頼性のある通信を保証することができる。
【００１４】
ここでＡＡＬ３／４でなく、ＡＡＬ５を用いた理由としては、例えば以下の点があげられる。
【００１５】
（１）次世代通信方式としてＡＴＭ方式が本命視される中、ＩＴＵ−ＴやＡＴＭフォーラムなどの標準化機関により標準化が進められているデータ通信用ＡＡＬ（具体的にはＡＡＬ５）が、今後の高速端末（マルチメディア端末を含む）に実装されていく可能性が極めて高いこと。
【００１６】
（２）ＡＡＬ５は、高スループット、低レイテンシイを目的としていること。
【００１７】
ただし、上記方式をタイプ５以外のＡＡＬにも実装可能であることはもちろんのことである。
【００１８】
この実装にあたって、ＡＡＬ１で行われているようなＦＥＣを行うためには、送信側において、上位レイヤから渡されたデータを一度マトリクス状のインタリーバに書き込んで、冗長用の符号を付与した後に転送する必要がある。また、受信側では到着すべきであったが廃棄されてしまったり、到着が許容範囲以上に遅くなってしまったデータ（セル）が送信時にインタリーバのどの位置にあったかを特定する必要がある。ＡＡＬ１では、デフォルトの処理としてＳＡＲレイヤでセルにシーケンスナンバ（ＳＮ）を付与することになっているので、オプションとしてＦＥＣを行う場合にもこれを用いることができ、必然的に誤り位置の特定を行うことができた。一方、ＡＡＬ５には位置を特定するための処理は行われていない。そこで、ＦＥＣ冗長符号およびＳＮの付与を行う機能を、現状ではヌルであるＳＳＣＳレイヤに持たせることを提案した。
【００１９】
ところで、上記学会発表にて想定しているインタリーバはＡＡＬ１で用いられているものと同じであり、データを書き込めるサイズは固定であった。ＡＡＬ１では、転送するデータが音声等のＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ；固定ビットレート）であり、一定の割合で連続して上位レイヤから渡されることが予めわかっているので、大きめの固定サイズのインタリーバでも問題はなかった。しかしながら、データ転送においては、どのようなタイミングで、どのような大きさのデータが上位レイヤから渡されるかわからない。よって、大きさの固定されたインタリーバでは、インタリーバのサイズよりもかなり小さいデータを転送する場合には、残りの領域にダミーデータをパディングしてダミーセルを送出しなければならない。データのサイズをインタリーバのサイズで割ったときの剰りが小さい場合、ダミーデータが増えてしまうので、特に問題になる。
【００２０】
したがって、このような方法では、帯域を有効に使うことができず、余分なトラヒックを増やしてしまうことになりかねない。加えて、従来のＡＡＬ１と異なり、ダミーデータがインタリーバ毎に入るときには、どこからがダミーデータであるかを示すための表示部分がインタリーバ毎に必要であるので、この部分を受信側で的確に取り出せるための機構も必要となる。
【００２１】
また、既存のインタリーバは、上位レイヤから渡されたデータを一度メモリに書き込んでから読み出しを行っているので、書き込みと読み出しの方向が垂直になる場合には、レイテンシイが少なくとも１つのインタリーバに書き込むのに必要な時間だけかかった。例えば、ＩＴＵ−Ｔ勧告Ｉ．３６３においてＡＡＬ１のオプションとなっているインタリーバ１つあたりのサイズはデータ領域で４７×１２４＝５８２８オクテットあり、この領域に対して最初の列にデータを書き込み始めてから最終列の書き込みに入る所までの間、下位レイヤに対しての送出は全くできないことになる。
【００２２】
他のインタリーブ方式としては、最近、ＩＴＵ−Ｔ，ＳＧ ＸＩＩＩ，Ｗｏｒｋｉｎｇ Ｄｏｃｕｍｅｎｔ ＴＤ／２７（Ｒｅｖ．） （１３−２）−Ｅ，Ｍａｒｃｈ，１９９４ ａｔ Ｇｅｎｅｖａ，“Ｓｔａｔｕｓ Ｒｅｐｏｒｔ ｏｎ ＡＡＬ１／２ ｆｏｒ ｖｉｄｅｏ ｓｉｇｎａｌ ｔｒａｎｓｐｏｒｔ”にあるように、斜めインタリーブ（読み出しと書き込みの方向が斜めに交差する）という手法が提案されている。しかしながら、この方法を用いても、垂直に交差する場合と比べてレイテンシイは半分にしかならないという問題があった。
【００２３】
この遅延への対策として、松崎らにより示される文献（１９９４年春 電子情報通信学会 春季全国大会 Ｂ−８５３；「ＡＴＭセルとＭＰＥＧ−２システム規格との整合性を考慮した誤り訂正手法の検討」）において、データの読み出しと書き込みが同じ方向であるかのごときインタリーバが図示されており、そのように書き込みと読み出しを行えば上記のような遅延自体は改善される。当該図に対しては何ら説明が与えられていないが、一般的に該インタリーバへはデータを書き込み、その後読み出すという操作が必要であり、またその読み書きのためのメモリ領域もインタリーバの大きさが必要である。すなわち、この方法においても、なお、インタリーバの大きなメモリ領域の確保が必要であるとともに、該メモリへの読み書きのための遅延が回避できないという問題があった。
【００２４】
また、受信側で受信するデータにＦＥＣ冗長符号が付与されている場合、既存の方法（ＡＡＬ１等）では、従来送信時にＦＥＣ冗長符号を付与するのと同程度のあるいはそれ以上の遅延がすべてのデインタリーバ処理で生じてしまうという問題もあった。それは、受信時には到着したデータを、データ領域かＦＥＣ冗長領域かにかかわらず、全て順次デインタリーバ内に格納していくという処理が必要であったからである。ＡＡＬ１では、セル廃棄をＳＮで検出することは可能であるが、データ内のビット誤りを検出する機能がＦＥＣ冗長符号にしかないため、データが正しいことを確認するには、受信側は全てのデータに対してＦＥＣによる復号処理を行わなければならない。これらの処理に要する遅延は、ビットエラーがセル廃棄と比較して極めてまれであってほとんどのデータが正しいような場合には、特に無駄が大きくなってしまっていた。
【００２５】
【発明が解決しようとする課題】
以上述べたように、従来のＦＥＣによる誤り訂正は、本来ＣＢＲ伝送等に適切な方式であって、転送すべきデータが連続的に上位レイヤから到着することを前提としている。よって、特にＡＡＬ３／４、５のようなデータ転送を行うプロトコルに、従来のようなＦＥＣによる誤り訂正を実装するのは不向きであった。すなわち、ＡＡＬ１で採用されている固定サイズのインタリーバでは、送りたいデータがそのサイズと比べて小さい場合には、データでインタリーバのデータ領域を満たすことができないので、残りの領域にはダミーデータを入れてダミーセルを送出するしかなかった。このような方法では、帯域を有効に使うことができず、余分なトラヒックを増やしてしまい、輻輳を招くことになりかねない。加えて、どこからがダミーデータであるかをインタリーバ毎に明確にし、それを受信側にわかるように伝送する機能が必要となるが、従来のＡＡＬ１のインタリーバでは全く考えられていなかった。
【００２６】
また、既存の方法ではインタリーバに対して書き込みと読み出しの方向が異なるために、メモリに書き込んでいる間、メモリからの読み出しを待つことで遅延が存在する。この遅延はインタリーバの大きさにおよそ比例するものであり、比較的低遅延であると言われている斜めインタリーブの方法を用いても遅延の大きさを半分にすることしかできない。
【００２７】
さらに、これへの解決法と考えられるデータの読み書きが同じとなるような既存の方法においても、インタリーバのメモリ領域の確保が必要で、また該メモリへの読み書きのための遅延時間が必要であった。
【００２８】
また、ＡＡＬ１等で行われている既存の方法では、誤り検出や復号のために受信時にも従来送信時と同程度あるいはそれ以上の遅延が生じてしまうという問題もあった。というのは、受信時には、到着したデータをデータ領域のものだけでなくＦＥＣ冗長領域のものも含めて全て、順次デインタリーバ内に格納し、ＦＥＣにより誤り検出、さらには訂正を行なっていたからである。
【００２９】
本発明は、ＦＥＣによる誤り訂正機能及び再送による誤り訂正機能を用いた通信におけるデータ再送制御方法及びデータ再送制御システムを提供することを目的とする。
【００３０】
【課題を解決するための手段】
本発明は、ＦＥＣによる誤り訂正機能および再送による誤り訂正機能を用いた通信におけるデータ再送制御方法であって、送信端末において、受信端末から、該受信端末にてＦＥＣによる誤り訂正機能によっては訂正できない誤りを伴って受信された誤りのある通信データに対する再送を要求する再送要求を受信する第１の手順と、前記第１の手順にて受信された前記再送要求およびＦＥＣによる前記誤り訂正機能の誤り訂正能力に基づいて、前記誤りのある通信データを、前記ＦＥＣによる誤り訂正機能および前記再送による誤り訂正機能を用いることによってリカバーするのに必要な再送データの最小量を決定する第２の手順と、前記第２の手順にて決定された前記最小量の再送データを、前記送信端末から前記受信端末へ再送する第３の手順とを有することを特徴とする。
好ましくは、前記通信は、前記送信端末から複数の受信端末へのマルチキャスト通信であり、前記第１の手順では、送信端末において、少なくとも一つの受信端末から前記再送要求を受信し、前記第３の手順では、前記最小量の再送データを、前記送信端末から前記少なくとも一つの受信端末へ再送するようにしてもよい。
また、本発明は、ＦＥＣによる誤り訂正機能および再送による誤り訂正機能を用いた通信におけるデータ再送制御システムであって、送信端末において、受信端末から、該受信端末にてＦＥＣによる誤り訂正機能によっては訂正できない誤りを伴って受信された誤りのある通信データに対する再送を要求する再送要求を受信する第１の手段と、前記第１の手段にて受信された前記再送要求およびＦＥＣによる前記誤り訂正機能の誤り訂正能力に基づいて、前記誤りのある通信データを、前記ＦＥＣによる誤り訂正機能および前記再送による誤り訂正機能を用いることによってリカバーするのに必要な再送データの最小量を決定する第２の手段と、前記第２の手段にて決定された前記最小量の再送データを、前記送信端末から前記受信端末へ再送する第３の手段とを有することを特徴とする。
好ましくは、前記通信は、前記送信端末から複数の受信端末へのマルチキャスト通信であり、前記第１の手段では、送信端末において、少なくとも一つの受信端末から前記再送要求を受信し、前記第３の手段では、前記最小量の再送データを、前記送信端末から前記少なくとも一つの受信端末へ再送するようにしてもよい。
【００３４】
【作用】
本発明では、送信端末において、受信端末から、該受信端末にてＦＥＣによる誤り訂正機能によっては訂正できない誤りを伴って受信された誤りのある通信データに対する再送を要求する再送要求を受信し、受信された前記再送要求およびＦＥＣによる前記誤り訂正機能の誤り訂正能力に基づいて、前記誤りのある通信データを、前記ＦＥＣによる誤り訂正機能および前記再送による誤り訂正機能を用いることによってリカバーするのに必要な再送データの最小量を決定し、決定された前記最小量の再送データを、前記送信端末から前記受信端末へ再送する。これによって、信頼性の高いデータ通信を効果的に実現することができる。
【００４３】
（４）また、本発明によると、インタリーバのデータ部分と冗長部分を独立したものとすることが可能となる。これによって、ネットワーク上での誤り率が比較的小さい場合にはほとんどのインタリーバのデータ部分には誤りが無いと判断されるのでＦＥＣ処理が不要となり、よってＳＳＣＳレイヤでの処理時間を更に短縮することができる。
【００４８】
【実施例】
以下、図面を参照しながら本発明の実施例を説明する。
【００４９】
本実施例では、送信側端末と受信側端末との間にてＡＴＭ網を介してＡＡＬタイプ５を用いたデータ通信を行う場合を示すが、本発明は他のタイプの方式にも同様に適用できることは言うまでもない。
【００５０】
この送受信端末間では、例えば大容量トランザクション処理が行われており、両端末間におけるデータのやりとりは、低レイテンシ（再送制御が基本的に許されない）、高スループット、かつ信頼性のあるデータ通信が求められている場合を想定している。例えば、端末が公衆網を介してＷＡＮ接続されており、物理的に遠い距離にあるような場合も含まれる。
【００５１】
ここでは、両端末間にてやりとりするデータにＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）のための誤り訂正ビットを付与し、送信中の伝送路やＡＴＭスイッチ内でセル廃棄が生じた場合に、再送せずに正しいデータを再生できる手法を示す。
【００５２】
本実施例では、ＡＴＭの特徴であるセル廃棄のみを主に仮定して説明を進めているが、実際のデータ通信ではビット誤りも生じる可能性はある。このビット誤りに対する訂正方法としては、後述するようなＳＳＣＳヘッダ／トレイラにＣＲＣフィールドを設け、セルごとにビット誤り検出を行うことによって誤りの検出されたセルは廃棄し、セル廃棄されたものとみなす方法がある。また、誤り訂正を行う符号として、インタリーバ内のどの位置にビット誤りが生じているのかわからなくても訂正可能であるリードソロモン符号（ＲＳ符号）を用いる方法もある。ただし、この機能を適用するには、受信側で必ず誤り位置の特定のための復号演算を行う必要がある。
【００５３】
本実施例では、送信側端末と受信側端末は、それぞれＡＴＭ端末でありＡＡＬ５を用いている。エラーフリーなデータを高いスループットで、かつ低いレイテンシで送受信できるように、ＡＡＬ５のＣＰＣＳレイヤの上位レイヤであるＳＳＣＳレイヤにＦＥＣ機能を実装している。
【００５４】
（第１の実施例）
まず、第１の実施例を説明する。本実施例は、１対１の端末が通信を行なう場合の例である。
【００５５】
図１に、本実施例の送受信端末のプロトコルスタックの構造を示す。これは、Ｕプレーン通信（アプリケーション間の通信）を行なう場合のプロトコルスタックである。図中、１はＡＴＭ網、３はＡＴＭ交換機を表している。
【００５６】
送信側端末２ｔおよび受信側端末２ｒでは、ともに大容量トランザクション処理のアプリケーションが動作しており、送信側端末２ｔから受信側端末２ｒに対して大容量・リアルタイムのデータが転送される。両端末２ｔ，２ｒは、直接接続されているものとする。このエンドーエンドのＡＴＭコネクションは、アプリケーション間に予め確立される。従って、レイヤ２、３、４は通常ヌルとなっている。
【００５７】
もし、何らかの理由で送信側端末２ｔと受信側端末２ｒのコネクション間に１つでもルータが介されている場合には、そのルータはＳＳＣＳレイヤの処理として同様のＦＥＣ処理を行えることが必要である。
【００５８】
ＡＡＬレイヤではすでに標準化が決まっているＡＡＬ５を実装しており、標準のＡＡＬ５の上のＳＳＣＳレイヤに、本発明のインタリーバ処理とＦＥＣ処理を実装している。これにより、エンド−エンド間で信頼性のある通信を実現している。
【００５９】
ただし、より信頼性を増すために、上記でヌルであったトランスポートプロトコルのレイヤ４にもライトウェイトな再送制御プロトコルを実装していてもよい。ＦＥＣには冗長の程度に応じて訂正能力限界があり、通常はエラーは訂正能力の範囲内におさまるように設計されるべきであるが、万一その範囲を越える場合（すなわち訂正不可能な場合）も考えられる。再送制御プロトコルを実装すれば、ＦＥＣの能力を越えてしまうほど多量の廃棄が生じるようなことが仮にあった場合、遅延の増大は生じるとしても、データの信頼性だけは保つことができる。
【００６０】
図２に、送信側端末２ｔおよび受信側端末２ｒの内部構成を示す。
【００６１】
送信側端末２ｔは、アプリケーション処理（例えば広域トランザクション処理）を行い、受信側端末２ｒに対してアプリケーションデータを送信する。
【００６２】
アプリケーション処理モジュール４ｔは、アプリケーションデータをＳＳＣＳ処理モジュール６ｔに渡す処理を行う。
【００６３】
ＳＳＣＳ処理モジュール６ｔでは、渡されたデータに対してインタリーブ操作を行い、ＦＥＣ冗長コードを付与した後、そのインタリーバの列に対してＳＳＣＳヘッダ／トレイラを付与し、これをＣＰＣＳ処理モジュール１４ｔに渡す。
【００６４】
ＣＰＣＳ処理モジュール１４ｔでは、ＳＳＣＳ処理モジュール６ｔから受けとったデータに対して、ＡＡＬ５のＣＰＣＳ処理、すなわち長さ表示とＣＲＣの２つのフィールドを各々演算して付与する処理を含むトレイラ付与作業を行ない、ＳＡＲ処理モジュール２０ｔに渡す。
【００６５】
ＳＡＲ処理モジュール２０ｔでは、通常のＡＡＬ５のＳＡＲレイヤ処理としてＣＰＣＳ処理モジュール１４ｔから渡されたデータに対してセグメンテーションを行なう。
【００６６】
セグメンテーションされたデータはＡＴＭヘッダ付与モジュール２２ｔに渡され、ＡＴＭセルヘッダが付与され、さらに図示しない下位レイヤの処理が行なわれてＡＴＭ網１にセルとなって投入される。
【００６７】
一方、受信側端末２ｒは、ＡＴＭ網１から入力されてきたセル流に対して、図示しない物理レイヤおよびＡＴＭレイヤの処理を行い、自端末宛のセルを選択して取り出す。そして、ＡＴＭヘッダ削除モジュール２２ｒは、ＡＴＭヘッダを削除した後にＳＡＲ処理モジュール２０ｒに渡す。その際、ＡＴＭセルヘッダのＰＴ（ペイロードタイプ）のＵＵＩ（ユーザユーザ情報）領域に、ＣＳ−ＰＤＵの最後部を示すビットが表示されていたら、これをＳＡＲ処理モジュール２０ｒに通知する。
【００６８】
ＳＡＲ処理モジュール２０ｒは、受け取ったデータ（セルのペイロード）に対して、ＣＳ−ＰＤＵの最後部の情報を参照しながらＡＡＬ５のリアセンブリ処理を行なう。
【００６９】
ＣＰＣＳ処理モジュール１４ｒは、ＳＡＲ処理モジュール２０ｒから受け取ったＣＳ−ＰＤＵに対してＡＡＬ５のＣＰＣＳレイヤ処理、すなわちＣＲＣと長さ表示のチェック等を行ない、ＣＳ−ＳＤＵを再生する。
【００７０】
ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒは、ＣＳ−ＳＤＵに付与されたＳＳＣＳヘッダ／トレイラを確認しながら削除し、デインタリーバモジュール８ｒに渡していく。その際、ＣＰＣＳトレイラで誤りが検出されている場合には、その事実をＦＥＣ訂正モジュール１０ｒに通知する。
【００７１】
デインタリーバ８ｒで正しく再生されたデータは、ＳＳＣＳ処理モジュール６ｒからアプリケーションデータとしてアプリケーション処理モジュール４ｒへ渡されていく。
【００７２】
ところで、上記した個々のモジュールは、ハードウェア処理あるいはソフトウェア処理のいずれで行なっても構わない。例えば、アプリケーション処理モジュール４ｔ，４ｒおよびＳＳＣＳ処理モジュール６ｔ，６ｒは、各々の端末２ｔ，２ｒ内部に設けたＣＰＵによるソフトウェア処理で、また、それらより下層のＣＰＣＳ処理モジュール１４ｔ，１４ｒ、ＳＡＲ処理モジュール２０ｔ，２０ｒおよびＡＴＭヘッダ付与／削除モジュール２２ｔ，２２ｒは、各々端末２ｔ，２ｒ内にハードウェアとして実装する方法もある。
【００７３】
次に、送信側端末２ｔにおける処理をレイヤの順に従って説明する。
【００７４】
（Ａ）アプリケーション処理モジュール４ｔによる処理
まず、アプリケーション処理モジュール４で、例えば図３のようなアプリケーションデータが生成される。アプリケーションデータの長さは、アプリケーションに依って異なり、一般的には広いレンジを持つ可変長のデータである。アプリケーションデータの発生間隔もアプリケーションに依存し、連続する場合や断続的、断片的な場合など様々なケースが考えられる。
【００７５】
アプリケーション処理モジュール４ｔは、インタリーバモジュール８ｔに対してアプリケーションデータ（ＡＡＬ−ＩＤＵ）を渡していくが、１アプリケーションデータが終了した時点で、その旨をデリミタとしてインタリーバモジュール８ｔに通知する。
【００７６】
（Ｂ）インタリーバモジュール８ｔによる処理
インタリーバモジュール８ｔは、アプリケーション処理モジュール４ｔから渡されたアプリケーションデータであるＡＡＬ−ＩＤＵを、マトリクス状メモリであるインタリーバのデータ領域の部分に順次書き込んでいく。書き込み方は、例えば図４の様に左上端から垂直方向に１列ずつ行う。
【００７７】
インタリーバへの書き込みの方法として、ここでは図４に示した方向、順序に従う例を挙げるが、図５に示すような方法など、様々な書き込み順序、方向が可能である。
【００７８】
ＦＥＣ冗長領域内にはデータは書き込まず、書き込み終了後に各行のシンボルごとに対して予め決まった演算を行った結果を、対応するＦＥＣ冗長領域内の各行に書き込む。なお、演算を行った結果をメモリ内のインタリーバ領域に具体的に書き込まずに、論理的に別のメモリに格納し必要に応じて読み出し下位レイヤに渡すという方法も可能である。
【００７９】
インタリーバのサイズは様々なものが考えられるが、例えば、ＡＡＬ１では以下のようなサイズのインタリーバがオプションとしてＩＴＵ−Ｔ勧告Ｉ．３６３によって標準化されている。横（列）のサイズとしては、１シンボルが１オクテットであって、データ領域１２４シンボル、ＦＥＣ冗長領域４シンボルである。この場合の縦（行）のサイズは、セル長からＳＡＲヘッダ長を差し引いた長さ、４７オクテットである。また、ＡＡＬ１でのオプションの他の値として、同じシンボルサイズで縦のサイズが８シンボル、横のサイズがデータ８８シンボル、ＦＥＣ冗長領域６シンボルであるものも標準化されている。ただし、ここではこれらの値にこだわる必要はない。
【００８０】
本実施例において、いくつかのインタリーバサイズの値を提示しているが、これらはいずれも、インタリーバがデータ領域としてとることのできる最大値を示している。すなわち、アプリケーションデータのサイズによって、それよりも小さく変化させることが可能である。アプリケーションデータのサイズがインタリーバの横のサイズを最大値まで用いた場合でも、その領域に入らないときには、２枚目のインタリーバ、３枚目のインタリーバと言うように、ＡＡＬ１でのＣＢＲ転送と同じように複数枚のインタリーバを用いて転送することとなる。また、縦のサイズはセルのペイロードのサイズとの関係でいくつか実装に適当なサイズがある。
【００８１】
例えば、インタリーバの１列に対して１つのＳＳＣＳヘッダ／トレイラとＡＡＬ５のＣＰＣＳトレイラを付与する方法をとったものとする。この場合には、縦の長さはセルのペイロード長からＳＳＣＳヘッダ／トレイラ分（ヘッダ／トレイラ部分によるオーバーヘッドをなるべく小さくするように、１オクテット等が考えられる）とＣＰＣＳトレイラ分（８オクテット）を除いた長さ（４８−１−８＝）３９オクテット等が考えられる。また、１列を複数セル、例えば２セル分とすれば縦のサイズは（３９＋４８＝）８７オクテット等が適当であると考えられる。
【００８２】
縦のサイズが大きい場合と小さい場合を比べてみる。上述したものと同じ、インタリーバ１列をペイロードに持つＳＳＣＳ−ＰＤＵについて比較すると、ＳＳＣＳヘッダ／トレイラ長が同じならば、縦のサイズの大きい方が上位レイヤデータの転送効率（ｐａｃｋｉｎｇ ｅｆｆｉｃｅｎｃｙ）があがるという利点がある。一方、縦のサイズが長いと転送すべきデータが列の途中で終了してしまう可能性も高く、その場合にはその列の残りの部分をパディングで満たさなければならず、逆に転送効率が下がってしまうという問題点もある。縦のサイズとして適当な値を選ぶには、このようなトレードオフを加味すべきである。さらに、あまりに大き過ぎると、ランダムなビット誤りを含み易い問題あるいはＦＥＣ符号のオーバーヘッドが上がる問題などが生じる。
【００８３】
横のサイズに関しては、従来と同じ誤り訂正符号として１シンボルがｎビットのリード・ソロモン符号（以下ＲＳ符号と記す）を用いるとして、通常、最大長が（２＾ｎ）−１シンボルに限定される。拡張ＲＳ符号を利用すると、それよりも１あるいは２シンボル長いものも可能であるが、拡張ＲＳ符号は通常のものと比較して、受信後の復号処理、誤り訂正処理が複雑である。従って本実施例では、あえて拡張ＲＳ符号を用いないこととする。ｎの値としては、ソフトウェアによる処理の容易さも考慮して、８またはその倍数を用いることが一般的である。
【００８４】
図６に一例を示すように、上記の値を越えない範囲で、インタリーバのサイズとして、横のサイズを４オクテットの倍数にする方法がある。この方法では、例えばＲＳ符号で１シンボルをｎビットとしたときに、ｎと列シンボル数との積が３２の倍数になることを意味している。ＦＥＣ機能をソフト処理で実現する場合を想定すると、計算機で仮想的にインタリーバへのデータの書き込み、読み出しを行うことになるが、計算機のＣＰＵはメモリへのアクセスが４オクテット単位の方が扱いやすいので、有効なデータが足りない場合には４オクテット単位になるようにパディングをしてでもアライメントをとった方が良い場合もある。
【００８５】
後で詳しく述べるが、今度はＣＰＣＳトレイラをデータ領域とＦＥＣ冗長領域の各々に１つずつ付ける例を考える。この場合、インタリーバの縦の長さはＳＳＣＳヘッダ／トレイラ分のみを考慮すれば十分である。よって、ＳＳＣＳレイヤのオーバヘッドを例えば１オクテットとして、（４８−１＝）４７バイトが良いと考えられる。しかしこの方法では、ＣＰＣＳトレイラによって増加する８オクテットの増加分もセルのペイロードとして伝送しなければいけないことを考慮していないので、そのための８バイト分をインタリーバのデータ領域内に確保する方法か、あるいはＣＰＣＳレイヤのアライメントをとる機能に任せる方法のいずれかをとる必要が生じる。ＣＰＣＳレイヤのアライメントをとる機能に任せる場合には、ＣＰＣＳトレイラのみを１セルに格納することになるので４０バイトのパディングが必要となり、オーバーヘッドが大きくなってしまう問題点がある。従って、インタリーバのデータ領域にあらかじめＣＰＣＳレイヤ用に８オクテットのスペースを確保しておく方がパッキング効率は良い。
【００８６】
前述したように、データ転送の場合、ＡＡＬ−ＩＤＵのサイズは一定でなく、ＳＳＣＳモジュール６ｔではこのサイズを認識し、さらに受信側ＳＳＣＳモジュール６ｒにも知らせる必要がある。多くのプロトコルでは、ＳＳＣＳモジュール６ｔでＡＡＬ−ＩＤＵの終了（デリミタ）を検出することができ、ＳＳＣＳレイヤでは予めサイズを認識することが可能となっている。従って、送信側のＳＳＣＳレイヤにおいてインタリーバのどの位置までデータを書き込んだかを、何らかの手段で明記し受信側ＳＳＣＳレイヤにわかるようにしなければならない。
【００８７】
次に、これまで述べてきた種々の例に基づいて任意のサイズのＡＡＬ−ＩＤＵをインタリーバに格納していった最終的な様子をいくつかの例について説明する。これらの例では、あらかじめコネクション毎に用いるインタリーバの最大サイズ、ＦＥＣ領域の大きさ、ＳＳＣＳ−ＰＤＵの大きさやフォーマットなどが呼設定時にネゴシエーションされているものとする。
【００８８】
図７には、インタリーバの縦のサイズが３９オクテットである例を示した。このサイズは、１列ごとに対して１オクテットのＳＳＣＳヘッダ／トレイラ（図７（ｂ）のようにヘッダを付与している）とＣＰＣＳトレイラが１つずつ付いている例である。インタリーバの最大列数は１２８オクテットであり、各行に４オクテット分のＦＥＣ領域がある。
【００８９】
また、この例は比較的大きなサイズのアプリケーションデータが格納された様子を示しており、複数枚（＃１から＃Ｎまで）のインタリーバに渡っている。もちろん、小さなサイズのアプリケーションデータであっても、図７に示したインタリーバの状態と同じように格納できる。図７（ａ）の＃１は、データ領域がこの例で許容される最大値まで使用されているインタリーバであり、最後の１オクテットを用いてその列に含まれている有効なデータ量を長さ表示（ＬＩ）フィールドに表示する。また、図７（ａ）の＃Ｎはデータ領域に未使用部分が残っている（アプリケーションデータが途中で終了した）インタリーバであり、最終列はパディングを含む場合もある。このインタリーバでも同様に最終列の最後の１バイトを用いて、その列の有効データ量をＬＩフィールドに表示する。よって、最終列の有効データ長とＬＩフィールドの１オクテットの和が３９オクテットに満たない場合、その足りない分だけパッドを付加する。
【００９０】
次に、図８に、インタリーバの縦のサイズが４７バイトである例を示す。図９には、この場合のＳＳＣＳレイヤの処理の流れを説明するための図を示す。
【００９１】
ＡＡＬ−ＩＤＵが到着すると（ステップＳ１１）、インタリーバへの書き込みを行う（ステップＳ１３）。
【００９２】
インタリーバが満たされると（ステップＳ１４）、必要に応じてＰＡＤを挿入し、ＬＩを書き込む（ステップＳ１５）。そして、ＦＥＣ冗長コードの計算を行う（ステップＳ１６）。
【００９３】
インタリーバからは、順次、列ごとのデータが読みだされ、ＳＳＣＳヘッダが付与される（ステップＳ１７）。
【００９４】
そして、ＣＰＣＳ処理（ステップＳ１８）、ＳＡＲ処理（ステップＳ１９）が行われ、ＡＴＭヘッダが付与され（ステップＳ１８）、ＡＴＭセルとしてＡＴＭ網を転送される。
【００９５】
さて、図８は、インタリーバのデータ領域とＦＥＣ領域それぞれに対して１つずつＣＰＣＳトレイラが付与されている例である。図７の例と同じように、各列に対しては、１バイトのＳＳＣＳヘッダ／トレイラが付与される（図８（ｂ））。また、この例も比較的大きなサイズのアプリケーションデータが格納された様子を示しており、複数枚のインタリーバ（＃１〜＃Ｎ）に渡っている。もちろん、小さなサイズのアプリケーションデータであっても、図８に示したインタリーバの状態と同じように格納できる。
【００９６】
図８（ａ）の＃１は、データ領域が最大値まで使用されているインタリーバであり、最後の９バイトを用いてその列に含まれているパディングの量をＬＩフィールド（１オクテット）に表示し、残り（８オクテット）は未使用とする。この８オクテットＣＰＣＳトレイラが付与される際に余分なパディングを行わなくてすむように、予めトレイラのサイズ分を確保しておくための領域である。また、図８（ａ）の＃Ｎは、データ領域に未使用部分が残っている（アプリケーションデータが途中で終了した）インタリーバであり、最終列はパディングを含む場合もある。このインタリーバでも同様に最終列の最後の１バイトを用いてその列のパディングの量をＬＩフィールドに表示する。よってパッドは、最終列の有効データ長とＬＩフィールドの１オクテットの和が４７オクテットに満たない場合、その足りない分だけ付加される。
【００９７】
次に、図７と図８で用いられているＬＩ表示の方法について詳しく説明する。図１０には、その例を示した。（ａ）は図７に対応する場合で、データ領域内の途中の列の最下行でアプリケーションデータが終了した場合を表している。この場合最終列には有効なデータは含まれていないので、ＬＩフィールドは０となり、３８オクテット分のパディングをする。また、（ｂ）は図８に対応する場合で、アプリケーションデータを書き込んでいって終了した行が３８〜４７オクテット目であった場合の表示方法を示している。この時は、ＬＩフィールドにはパディングの量を示すようにする。この様な方法をとることで、送信側から受信側に正確にアプリケーションデータの量を伝えることが可能となる。
【００９８】
同じアプリケーションのデータであれば、複数のＡＡＬ−ＩＤＵを１つのインタリーバ内に格納することも可能である。よって、１つのＡＡＬ−ＩＤＵのデリミタ検出後に、タイマを起動させ、ある一定時間次のＡＡＬ−ＩＤＵが到着するまでそのインタリーバの送出を待つこともできる。
【００９９】
タイマーの設定は、アプリケーションがどれくらいのレイテンシを要求するかによっても様々な設定が可能である。例えば、遅延に対する要求条件の厳しくないファイル転送等では数秒待つことも可能であり、またそれとは逆で、動画像などの場合にはタイマーのしきい値を０に設定し帯域を最大限まで使用することもできる。
【０１００】
アプリケーションデータをデータ領域に書き込んだ後には、レイテンシイを小さく抑えるためにも、できるだけ速やかにＦＥＣ冗長領域を計算することが望ましい。
【０１０１】
図１１に一例を示すように、インタリーバからの読み出しは書き込んだ方向、順序と同じに、１シンボル書き込み終了後引き続いて１シンボル読み出しをすぐに行う。書き込みと読み出しを交代に、または並列に行うことによって、今まで書き込み終わるまで読み出しができなかったというボトルネックが解消され、ＳＳＣＳレイヤの上位レイヤから下位レイヤに渡すまでにかかる時間が大きく減少する。データ読み出し後は、順次ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔへ渡していく。
【０１０２】
以上のように行うと、インターリーブにより生じていた遅延がほとんど無視でき、ＳＳＣＳレイヤがヌルの場合とかなり近い速度が得られる。以前のインタリーブでは、書き込みは水平方向に、読み出しは垂直方向にと、１つのデータ領域内全てにデータが書き込まれてから（全てが埋まらない場合にはＰＡＤをしてから）読み出しを行っていた。これに対して本実施例の方法では、下位レイヤに渡すデータの読み出し方向を書き込み方向と同一にし、特にデータ領域に関しては書き込みと読み出しがほぼ同時に行われるので、データ領域全てを書き込むまでデータの送出を待たなくてもよくなり、遅延がかなり小さくなる。
【０１０３】
（Ｃ）ＦＥＣ付与モジュール１０ｔによる処理
ＦＥＣ付与モジュール１０ｔでは、図１２に例を示すように、データ領域の範囲内に書き込まれたデータの各行に対して、それぞれのＦＥＣ冗長領域を計算し対応する位置に書き込んでいく。ｎ行目に対するＦＥＣ冗長領域は、ｎ行１列、ｎ行２列、・・・、ｎ行ｍ列のｍ個のシンボルを用いて演算することによって得られた結果である。
【０１０４】
パディングがなされていないインタリーバの場合は図１２（ａ）のように、また、インタリーバの途中でデータが終了している場合は図１２（ｂ）のように未使用部分を除いて各行に対応するＦＥＣ冗長領域を計算していく。（ｂ）の場合に、ｎ行目に対するＦＥＣ冗長領域を計算するには、ｎ行１列からｎ行４列までのシンボルを用いて、未使用部分が無い場合と同じ演算方法でＦＥＣ冗長領域を計算することが可能である。
【０１０５】
図１３に、１列が１つのＣＰＣＳ−ＳＤＵとなる場合の例を示す。インタリーバは、ＡＡＬ−ＩＤＵであるデータが書き込み終わったら、図１３（ａ）のように、その列の残りの部分をＰＡＤ（例えばシンボル中のビットがａｌｌ“０”またはａｌｌ“１”）で埋めて、さらにその列の最後の１シンボルの部分に、その列に含まれる有効なデータの長さを書き込む。もし、ある列の最後までデータが埋まっていたら、図１３（ｂ）のように、次の列を使って長さ表示を行う。要するに、列の最後に長さ表示が含まれている列の前の列はデータで満たされることになる。
【０１０６】
データが全く書かれていない残りの列に対しては、ＰＡＤ等は行なわない。データ領域の最後は次のステップで付与されるＳＳＣＳヘッダ／トレイラで受信側が認識できるので、余分なＰＡＤをしてインタリーバの最大サイズに合わせる必要はない。また、データを書き込んでいない部分はセルとなって転送されることもない。この様な操作を行うと、ＣＢＲ転送に適していたインタリーバをデータ転送にも容易に適用することが可能となるのである。
【０１０７】
ＦＥＣ冗長領域を計算する際、データが書き込まれていずダミーの入っていないデータ領域の各列はＦＥＣ冗長コード演算のために代入するパラメータが存在しないので、演算数が少なくて済むことになる。しかしながら、ダミーとして０または１がパディングされていて、しかもそれをＦＥＣの計算のためのデータとして用いる従来の場合には、その値を用いてデータがある列と同様の計算を各シンボルに対して行わなければならないので、データ領域が有効なデータで満たされている場合と同じだけの計算時間が必要になってしまう。したがって、残ったデータ領域にＰＡＤを入れず、かつその領域をＦＥＣのための演算領域からはずす場合は、演算量が減少するため簡単に短時間でＦＥＣ冗長の計算が行えることになり、より高速にプロトコル処理できることになる。
【０１０８】
図１３は、データを書き込むという観点から、仮想的にインタリーブ行列をおいて、そこに左上から書き込む様子を示しているが、ＦＥＣのための冗長を演算するような立場からは、実際には図１４のように書かれていることと等価になる。すなわち、マトリクスの左側（すなわちＦＥＣのための情報部分の上位の方）はダミーのＰＡＤがつけられていて、データ領域の右端につめられて実データが置かれている構成である。実データ領域の中では、番号の若い（すなわち早く上位レイヤから来た）データほど左側にある。すなわち、ＦＥＣ演算をする符号語、という点からは、下位の実データ分の情報部分とＦＥＣ冗長部分とがあるように見える。この様子を、図１５（ａ）に示す。
【０１０９】
他には、例えば図１６の様にデータが全く入らない列にダミーデータを入れてＦＥＣ冗長領域を計算するが、それらを含むダミーセルは送出しない方法もある。網に送出されるデータ量は図１３の場合と同様に最低限に抑えることが可能である。
【０１１０】
それ以外にも、前述した図５（ａ）のようにシンボル毎にインタリーブのデータ領域中にランダムに配置したり、図５（ｂ）のように行の順序をデータ領域の中で自由に設定することも可能である。これらの場合、同様にデータの全く入らない列にいれたダミーデータ列は送出しないことにより、網の送出されるデータ量はやはり図１３や図１６と同じく最低限に抑えることが可能である。
【０１１１】
これらの例では、あらかじめ通信前に送受信双方でインタリーブ行列への挿入方法についてあらかじめネゴシエーションしておくことは言うまでもない。
【０１１２】
図１６および図５は、図１３とは異なり、ＦＥＣ演算の立場から見たインタリーブマトリクス構造はそれぞれの図と同一である。すなわち、各符号語は、図１６の場合は、図１５（ｂ）にあるように、上位に実データの情報、その下にダミーの（シンボル値０の）情報があるような情報部分とＦＥＣ冗長部分とから構成される。また、図５（ｂ）のようにランダムに実データ列を配する場合は、図１５（ｃ）のように実データとダミーデータがまだらに入ったような情報部分と、その右側の冗長部分から成る。
【０１１３】
図１３、図１６および図５共に、実データ部分はセルとして伝送されるが、ダミー部分は送出されない。受信側では、ダミー部分には０が送信されたものとみなして復号が行われる。
【０１１４】
図１３および図１６に関するＦＥＣ冗長領域の作成方法については、後でより詳細に説明する。以下のプロトコル処理の流れでは、代表例として図１３のインタリーブマトリクスへの書き込み方法であるものとして説明を行う。
【０１１５】
ＦＥＣ冗長領域を演算し始めた時には、データ領域に一度書き込まれたデータはＳＳＣＳヘッダ／トレイラを付与するためにＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔにほとんど渡されている（図１１）。図７および図８のように、ＦＥＣ冗長領域に書き込まれた計算結果も、演算終了次第、データ領域と同様に列方向に１列ずつ読み出され、ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔへと順次渡されていく。ＦＥＣ冗長領域の計算にかかる時間は、一般にデータを水平方向に書き込むのを待つ時間よりもはるかに小さいことがわかっている。
【０１１６】
（Ｄ）ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔによる処理
ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔでは、インタリーバモジュール８ｔから列単位で読み出されたデータに対して、ＳＳＣＳヘッダ／トレイラを付与しＣＰＣＳ処理モジュール１４ｔに渡していく。ＳＳＣＳヘッダ／トレイラを付与する単位は、図１７（ａ）のようにインタリーバの１列ごとでもよいし、図１７（ｂ）のように、一定の列数ごと、例えば２列ごとをひとまとめにしたものなども考えられる。すなわち、インタリーバの複数列にＳＳＣＳヘッダ／トレイラを付与したものがＳＳＣＳ−ＰＤＵとなる。複数のインタリーバ列をＳＳＣＳ−ＰＤＵとする場合には、ひとまとめとする列数が最低限ＦＥＣの訂正能力を越えないようにする。ＦＥＣ方式の誤り訂正では、付与している誤り訂正符号のオーバーヘッド（冗長部分）の量によって、訂正できるシンボル数（インタリーバの列数）に限界がある。例えば、前述の図８におけるインタリーバのＦＥＣ冗長領域の列サイズが４の場合には、データとＦＥＣ領域全体に対して、４列までの消失誤りを訂正することができる。
【０１１７】
ここで付与するＳＳＣＳヘッダ／トレイラには、それが付与されているデータ列がインタリーバのどの位置（何列目）にあったかを確実に特定するための情報が含まれていなければならない。
【０１１８】
代表的なＦＥＣを行う誤り訂正符号としては、Ｒｅｅｄ−Ｓｏｌｏｍｏｎ符号があるが、この誤り訂正符号を用いて容易に訂正するための前提として、「誤り位置が特定されていること」という条件がある。もし、誤り位置が特定されていない場合、その位置特定のための計算量を多く必要とし、また、訂正能力も位置特定時のおよそ半分のシンボルエラーしか訂正できない。誤り位置（ここでは誤りが生じているデータを含むセルのインタリーバ内の位置に相当する）を特定するには、何らかの形で送信時にセル毎の識別子を付けておく必要がある。その識別子として最も有効であろう方法は、例えばセル単位にＳＮを付与することである。また、ＳＮにもある程度の信頼性を持たせる必要がある。
【０１１９】
ＳＳＣＳヘッダ／トレイラとしては、例えば図１８のようなフィールドを持たせることができる。ここでは、１バイトの長さのヘッダの例を示している。
【０１２０】
インタリーバの横のサイズの一例として、ＣＰＵを用いてのソフト処理のためには、データ長を該ＣＰＵがアクセスする単位として４バイトにアライメントすることが望ましいことを前述したが、ここでも同様のことが言え、ヘッダ／トレイラ長を４バイトとすることも可能である。
【０１２１】
ここで、図１８のＳＳＣＳヘッダの一例について説明する。
【０１２２】
（ａ）は、同期ビットであり、インタリーバの先頭のＳＳＣＳヘッダ／トレイラであることを示す。例えば、先頭の時は“１”、それ以外は“０”と表示する。
【０１２３】
（ｂ）は、シーケンスナンバであり、インタリーバ中の順序を表示する。例えば、セル廃棄された時の抜けが検出できる。
【０１２４】
（ｃ）は、ＳＮＰ（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ Ｐｒｏｔｅｃｔｉｏｎ）ビット、すなわちシーケンスナンバに対するプロテクトのためのパリティビットであり、シーケンスナンバの誤りを検出する。
【０１２５】
（ｄ）は、Ｄ／Ｆ（Ｄａｔａ／Ｆｌａｇ）ビットであり、ペイロードの中身がデータであるかそれともＦＥＣ冗長コードであるかを示す。
【０１２６】
（ｅ）は、Ｂ／Ｅ（Ｂｅｇｉｎ／Ｅｎｄ）ビットであり、データとＦＥＣ冗長コード領域各々の最後であることを示す。例えばインタリーバ内で、データ領域およびＦＥＣ冗長領域の最後にあたるＳＳＣＳヘッダ／トレイラのこのフラグを“１”、それ以外を“０”に設定する。
【０１２７】
インタリーバからは、データ領域に引き続いてＦＥＣ冗長領域が読み出され、ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔに渡されてくる。ＳＳＣＳヘッダ／トレイラの付与は、これらのデータ列に対して、上述したようなヘッダ／トレイラを一定間隔に挿入していくことで実現される。ここでいう一定間隔は、インタリーバにおける１列分の長さであったり、もしくは複数列分の長さである。
【０１２８】
図１９には、インタリーバ１つ分に対するＳＳＣＳヘッダ／トレイラの例を示す。ここで示した値は、誤りの無い正しいＳＳＣＳヘッダ／トレイラの一例である。
【０１２９】
同期ビットは、インタリーバの先頭にあるＳＳＣＳ−ＰＤＵを示し、シーケンスナンバはこの場合４ビットで循環している。図１９の例では、シーケンスナンバはデータ領域に付与されている最初のＳＳＣＳヘッダ／トレイラを０としてスタートし、１６を法として増加しており、データ領域の最後のＳＳＣＳヘッダ／トレイラとＦＥＣ冗長領域の最初のＳＳＣＳヘッダ／トレイラは連続している。また、別の方法としてＦＥＣ冗長領域の最初のＳＳＣＳヘッダ／トレイラでシーケンスナンバをクリアし再度０からスタートさせた場合でも実現は可能である。ただし、シーケンスナンバを途中でクリアせずに図１９の例のように連続していた方が、データ領域とＦＥＣ冗長領域の境界でセル廃棄が生じた場合もセル廃棄の検出が容易に行えるという利点がある。また、１つのＡＡＬ−ＩＤＵのサイズがかなり大きく、複数のインタリーブに渡って格納される場合に対しては、連続したインタリーブ間に連続したシーケンスナンバを付与する方法と、データ領域の先頭のＳＳＣＳヘッダ／トレイラには必ず０を付与する方法との２通りが考えられる。データ領域の列数は固定長でないが、ＳＳＣＳヘッダ／トレイラの別のフィールド（Ｄ／ＦビットやＢ／Ｅ）の表示や、ＦＥＣ冗長領域のサイズが予めエンドエンド間でネゴシエーションされていることから、データ領域とＦＥＣ冗長領域が交代して転送されてくる境界を正しく識別することが可能である。
【０１３０】
シーケンスナンバプロテクトは４ビットのシーケンスナンバに対して偶パリティを計算するものとする。もちろん、その代わりに奇数パリティを用いても構わない。
【０１３１】
本実施例では、Ｄ／Ｆビットは１であればインタリーバ内のデータ領域であることを示し、０であればＦＥＣ冗長領域であることを示している。Ｂ／Ｅビットは、ＥＮＤを１として、データ領域のＳＳＣＳ−ＰＤＵの最後のＰＤＵとＦＥＣ領域のＳＳＣＳ−ＰＤＵの最後のＰＤＵにマークをしている。
【０１３２】
図１９で示したＳＳＣＳヘッダ／トレイラで、Ｂ／Ｅフィールド＝１，Ｄ／Ｆフィールド＝データ、の値を持つヘッダ／トレイラが、そのインタリーバのデータ領域の最終列に含まれる有効なデータ長を示すＬＩフィールドを含むＳＳＣＳ−ＳＤＵに付与される。
【０１３３】
（Ｅ）ＣＰＣＳ処理モジュール１４ｔの処理
順次ＣＰＣＳ処理モジュール１４ｔに渡されたデータには通常のＡＡＬ５処理が行われ、長さ表示とＣＰＣＳトレイラが付けられる。ＣＰＣＳ−ＳＤＵとなる単位の例として、図７と図８の２種類を挙げる。図７では、ＳＳＣＳヘッダ／トレイラとそのペイロードが１組となったものが、ＣＰＣＳ−ＳＤＵとなる単位である。図８では、インタリーバのデータ領域とインタリーバのＦＥＣ冗長領域のそれぞれ（合計２つ）が、ＣＰＣＳ−ＳＤＵとなる単位である。
【０１３４】
図７の場合は、インタリーバの１列ごとにＳＳＣＳヘッダ／トレイラを付与する方法をとり、それぞれに対してＡＡＬ５のＣＰＣＳトレイラが付与される。この方法ではＡＡＬ５のＣＲＣがインタリーバの一列に対して適用されるので、もし受信側でエラーが発見された場合には、該インタリーバの特定の一列にエラーのあることが認識される。また、もしセル廃棄が発生したとしても、ＳＳＣＳヘッダ／トレイラにおけるシーケンス番号の抜けから、どのインタリーブ列が受信側に到着しなかったかを把握できるようになっている。このようにして、セル廃棄やビット誤りの位置を正確に特定することが可能となる。
【０１３５】
図７の応用として、インタリーバの１列ではなく、複数列毎にＳＳＣＳヘッダ／トレイラを付与する方法もある。図７ではＳＳＣＳレイヤのオーバヘッドとインタリーバデータの一列とＣＰＣＳトレイラの和が例えば４８オクテットになるようにインタリーバを設計して、レイヤ毎に余分なパディングを防ぐような工夫をしている。これを応用した場合においても、インタリーバの縦の長さを工夫して、ＳＳＣＳ−ＰＤＵの長さとＣＰＣＳトレイラの長さの和が４８オクテットの倍数か、あるいはそれが通信を行う端末の操作上不可能な場合でも、なるべくＣＰＣＳレイヤでのパディングを少なくするような設計が、データ転送効率をあげる上で望ましい。
【０１３６】
図８の場合は、ＡＡＬ５トレイラも１つのインタリーバに対して２つだけ付与する方法をとる。２つとは、データ領域全体に対して１つのＣＰＣＳトレイラを付与し、ＦＥＣ冗長領域全体に対してもう１つのＣＰＣＳトレイラを付与することを意味している。前者については、パディングを最小限にするために、予めインタリーバモジュール８ｔでインタリーバのデータ領域の最後の８バイト分は未使用にしてあるので、ＳＳＣＳレイヤから渡されたデータにＣＰＣＳトレイラを付与すると、ちょうど４８バイトの倍数になり、ＳＡＲ処理を行うときにパディングの必要がなくなる。一方、ＦＥＣ冗長領域に対してＣＰＣＳトレイラを付与する場合には、予めインタリーバモジュール８ｔで未使用部分を確保しておくことができないので、図８のようにインタリーバの一列を４７オクテット長とした場合には、４０オクテットのパディングが必要になってしまう。しかし、例えば図７と比較して、ＡＡＬ５のトレイラ数が少ない分のオーバーヘッドを小さくすることができ、転送効率があがることになる。また、上記パディングを減らしたい場合には、例えば図８において、インタリーバの長さを変更し、ＦＥＣ冗長領域を含むＳＳＣＳ−ＰＤＵとＣＰＣＳトレイラの長さの和を４８オクテットで割った余りが０であるかあるいは、４８オクテットに十分近い値であるようにすることも可能である。詳しくは、受信側のＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒの説明において述べる。
【０１３７】
（Ｆ）ＳＡＲ処理モジュール２０ｔによる処理
ＳＡＲ処理モジュール２０ｔでは、ＣＰＣＳ処理モジュール１４ｔから受け取ったデータ（ＣＰＣＳ−ＰＤＵ）のセグメンテーション処理が行なわれる。ただし、インタリーバの縦のサイズ、ＳＳＣＳヘッダ／トレイラのサイズ、ＣＰＣＳトレイラのサイズの合計が４８オクテットになっていれば、セグメンテーションは行なわれない。一方、例えば、ＣＰＣＳ−ＰＤＵが図８のようになっていて、ＣＰＣＳトレイラがデータ領域、ＦＥＣ冗長領域のそれぞれに対して１つずつ付与されているような場合には、セグメンテーションが行われる。
【０１３８】
４８オクテットに区切られたＳＡＲ−ＰＤＵは、ＡＴＭヘッダ付与モジュール２２ｔに渡される。その際、ＡＴＭヘッダ付与モジュール２２ｔに渡されるＳＡＲ−ＰＤＵがＣＳ−ＰＤＵの最後部にあたるデータである場合、その旨をＡＴＭヘッダ付与モジュール２２ｔに通知する。
【０１３９】
（Ｇ）ＡＴＭヘッダ付与モジュール２２ｔによる処理
ＡＴＭヘッダ付与モジュール２２ｔでは、呼設定時に定められたＡＴＭセルヘッダを付与した後、物理レイヤの処理を介して、ＡＴＭセル化されたデータをＡＴＭ網１に対して送出する。ＳＡＲ処理モジュール２０ｔからデータ（ＳＡＲ−ＰＤＵ）を受け取る際、これはＣＰＣＳ−ＰＤＵの最後部である旨の通知を受けている場合は、ＡＴＭセルヘッダのペイロードのＵＵＩフィールドに、これを告げる旨のビットを立てておく。
【０１４０】
以上が、送信側端末２ｔにおける処理の流れである。
【０１４１】
次に、受信側端末２ｒにおける処理をレイヤの昇順、すなわち各処理モジュールの動作する順に従って説明する。
【０１４２】
（Ｈ）ＡＴＭヘッダ削除モジュール２２ｒによる処理
ＡＴＭヘッダ削除モジュール２２ｒでは、ＡＴＭ網１から受け取ったセル流について、物理レイヤ処理を行った後に呼設定時に定められたＡＴＭセルヘッダを有したセルを受け取った場合、これをフィルタリングして受け取り、その他のセルは無視し、ＡＴＭセルヘッダを削除してＳＡＲ処理モジュール２０ｒに渡す。ここで、ＡＴＭセルヘッダのペイロードタイプのＵＵＩフィールドに、ＣＰＣＳ−ＰＤＵの最後部であることを示すビットが立てられていたらその旨をＳＡＲ処理モジュール２０ｒに対して通知する。
【０１４３】
ＣＰＣＳ−ＰＤＵの最後部を構成するセルであることを示すビットを含むセルが廃棄された場合、図２０のように、次に到着するＣＰＣＳ−ＰＤＵと同一のＣＰＣＳ−ＰＤＵとして上位レイヤに渡されてしまう。しかしながら、ＣＰＣＳトレイラのチェックによりこの誤りは検出される。さらに、その誤りを含むＣＰＣＳ−ＰＤＵをＳＳＣＳ処理モジュール６ｔまで渡すことで、ＦＥＣを用いて訂正することが可能なのである。
【０１４４】
（Ｉ）ＳＡＲ処理モジュール２０ｒによる処理
ＳＡＲ処理モジュール２０ｒでは、ＡＴＭセルヘッダ削除モジュール２２ｒから渡されたデータ（ＳＡＲ−ＰＤＵ）に対し、ＣＰＣＳ−ＰＤＵの最後部であるという表示を参照してデータのアセンブリを行う。アセンブリ終了後、ＣＰＣＳ処理モジュール１４ｒに該データが渡される。
【０１４５】
（Ｊ）ＣＰＣＳ処理モジュール１４ｒによる処理
ＣＰＣＳ処理モジュール１４ｒでは、ＳＡＲ処理モジュール２０ｒから受け取ったＣＰＣＳ−ＰＤＵに対し、ＡＡＬ５の処理であるＣＲＣ演算処理、および長さ表示の確認を順次行う。
【０１４６】
ここで、ＣＲＣ演算処理、および長さ表示の値のいずれかに誤りが検出されたかどうか、結果をＳＳＣＳ処理モジュール６ｒに通知する。この場合、どちらの演算で誤りが生じたかを知らせる必要は必ずしもない。
【０１４７】
（Ｋ）ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒによる処理
ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒでは、主にＳＮに抜けがないか、さらに、ＣＰＣＳトレイラで誤りが検出されている場合にはその通知を受け取る等の確認しながら、ヘッダ／トレイラを取り除いていく。
【０１４８】
ＣＰＣＳトレイラで誤りが検出されていることを通知されている場合には、そのＣＰＣＳ−ＰＤＵに含まれるＳＳＣＳ−ＰＤＵのいずれかが廃棄されている可能性が高いので、ＳＮをチェックしセル廃棄の位置を特定しなければならない。
【０１４９】
ＳＳＣＳヘッダ／トレイラの誤り（ビット誤りも含む）としては様々な状況が考えられる。ここでは、図１８の例に示したフィールドを持ったヘッダ／トレイラの誤りの対処について説明する。
【０１５０】
（ａ）の同期ビットはインタリーバの先頭を示すビットである。そのＳＳＣＳ−ＰＤＵがインタリーバの先頭のデータを含んでいる場合にはそのビットをたてて１とし、その他の場合には０とするものである。もし、この同期ビットが反転してしまうような誤りが起きた場合には、そのＳＳＣＳ−ＰＤＵから新規のインタリーバであることがわからないかも知れない。しかし、その前のＳＳＣＳ−ＰＤＵの（ｄ）のＦＥＣ冗長コードである表示と（ｅ）Ｂ／Ｅビットが最後であることを示していることによって、同期ビットが反転していても新規のインタリーバの先頭を検出することが可能である。
【０１５１】
（ｂ）のシーケンスナンバでビット誤りが生じた場合には、その後の（ｃ）のシーケンスナンバプロテクション（例えば、偶数パリティ）を用いて誤り検出することができる。前後のシーケンスナンバが正しいことがわかれば、ヘッダ／トレイラを取り除いた後、ＳＳＣＳのペイロード部はインタリーバの相当する位置に書き込むことができる。また、その代わりに、疑わしいデータを廃棄してしまってセル廃棄と見なしてＦＥＣ冗長コードを用いて正しいデータを再生させることも可能である。
【０１５２】
（ｄ）のＤ／Ｆは、ペイロード部が含むビット列がデータであれば１、ＦＥＣ冗長コードであれば０というように、ペイロードのタイプを示す。また、（ｅ）のＢ／Ｅは、データを含む複数の連続したＳＳＣＳ−ＰＤＵの中でそのＳＳＣＳ−ＰＤＵが最後であることを示す。ＦＥＣ冗長部についても、同様に、連続したＳＳＣＳ−ＰＤＵの中で最後であることを示す。従って、Ｂ／Ｅビットが１の（要するにそのＳＳＣＳ−ＰＤＵが最後のデータである）場合に、この表示がビット誤りを起こしたとする。しかし、次のＳＳＣＳヘッダ／トレイラのＤ／Ｆビットが１から０になり、そのペイロードにはＦＥＣ冗長コードを含むことが知らされるので、ＳＳＣＳ確認モジュール１２ｒでは正しく認識することが可能である。
【０１５３】
上記では、伝送路においてビット誤り率が例えば１０＾（−１０）以下といった微小なネットワークであるような場合を想定していることから、該ＳＳＣＳヘッダ／トレイラおよびその前後のＳＳＣＳヘッダ／トレイラには同時に２ビット以上のビット誤りが存在しないことを前提として記述をしている（ただし、＾はべき乗を意味する）。しかしながら、実際には、極めて珍しいことではあるが、その範囲に２ビット以上の誤りが含まれることもあり、その場合には、例えば、インタリーバのＦＥＣ冗長領域の大きさが固定であることや、シーケンス番号が連続していること等、上記以外の条件を加味して正確なＳＳＣＳヘッダ／トレイラを再現することが可能である。さらには、該ＳＳＣＳヘッダ／トレイラ全体の長さを例えば２オクテット長にし、その一部または全体を誤り訂正符号化することによって、ほぼ完全にビット誤り対策が施されることになる。
【０１５４】
次に、以上のような対誤り性を考慮した上で、具体例として図７と図８で示した送信データを受信した場合の処理について説明する。また、各々の場合で、ＣＰＣＳ処理モジュール１４ｒからＣＰＣＳトレイラに誤りが検出された対処の方法について述べる。
【０１５５】
まず、図７の場合について説明する。
【０１５６】
この場合は、インタリーバ内の比較的小さな単位、例えば１列ごとに１つのＳＳＣＳデータについて、１つのＣＰＣＳトレイラが付与されている。それぞれの列に関してＣＲＣおよび長さ表示を用いたチェックを行うことができるので、それらが正しい場合にはそれぞれのペイロード部の信頼性が保証され、ペイロードに含まれているＳＳＣＳヘッダ／トレイラの信頼性も保証されることになる。もちろん、ＣＲＣチェックによって漏れがあるような誤りパターンが存在しない訳ではない。しかしながら、そのようなパターンの発生確率は、該データに４ビット以上の誤りが発生し、かつ、その誤りパターンが偶然ＣＲＣチェックにより検出できないという、極めて微小なケースであり、これはこのレイヤの誤り検出レベルとしては、十分無視できる程度のものである。
【０１５７】
また、このＣＰＣＳトレイラの付与の方法では、セル単位にＣＲＣが演算されることになり、セル内のビット誤りを検出することも可能となる。そこで、ビット誤りの検出されたセルを廃棄されたと見なすことによって、誤り位置不明のビット誤りを位置のわかった消失誤りの形で誤り訂正することができる。ＦＥＣ符号では、位置不明のランダム誤りを訂正するよりも、位置のわかった消失誤りに対しての方がおよそ２倍の訂正能力があるため、この手法はより少ないＦＥＣ冗長部で同じ訂正能力を有することができるという点で極めて有効である。
【０１５８】
図７の応用として、インタリーバの数列に対してＣＰＣＳトレイラを１つ付加する場合を上述した。そのような場合に、もし１つのＣＰＣＳ−ＰＤＵが１つのセルに入らない場合は、複数セルに対して、ＣＰＣＳトレイラによるチェックが行われる。そのケースで、ＣＲＣ等のチェックによってビットエラーが発見されたとすると、そのエラーがインタリーバの数列のどこにあるかがわからないため、該当するＣＰＣＳ−ＰＤＵに属するインタリーバの数列全部を廃棄されたものとみなす方法と、位置の特定できないランダム誤りが発生したとして訂正を行う方法がある。もちろん、これらいずれの場合においても、訂正できるだけの十分なＦＥＣ冗長領域を有していることが必要である。
【０１５９】
図７において、１つのインタリーバに含まれるデータ領域を含む全てのＣＰＣＳ−ＰＤＵに対してＣＰＣＳトレイラの誤りが全く通知されていない場合には、上述したように、該インタリーバのデータ領域には誤りがないと判断できる。この場合、ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒはそれらのデータに対して以下の手順で処理を行う。
【０１６０】
先頭ＳＳＣＳ−ＰＤＵから順にＳＳＣＳヘッダ／トレイラのＤ／ＦビットがＤであることを確認しながら、デインタリーバモジュール８ｒに渡していく。ＣＰＣＳトレイラで誤りが検出されていないので、デインタリーバモジュール８ｒのデータ領域に格納せずに、直接上位レイヤであるアプリケーションレイヤまで渡すように通知する。
【０１６１】
そして、データ領域に相当する部分を含む複数のＣＰＣＳ−ＳＤＵより以降に到着する、ＦＥＣ冗長符号を含むＣＰＣＳ−ＳＤＵは廃棄するように命令を出す。というのは、もはや誤り訂正をする必要がないので、次以降に到着するＦＥＣ冗長領域のデータを含むＣＰＣＳ−ＳＤＵは不要だからである。
【０１６２】
もちろん、ＳＮのチェックを行い、セル廃棄が無いことを確認しながら、ＳＳＣＳヘッダ／トレイラを取り除くことはいうまでもない。これらの処理は、ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒの基本動作である。よって、以下に説明するケースでも必ず行われる。
【０１６３】
次に、図７において、ＣＰＣＳ−ＰＤＵに誤りが検出された場合を考える。
【０１６４】
先頭のＳＳＣＳ−ＰＤＵから順にＳＳＣＳヘッダ／トレイラのＤ／ＦビットがＤであることを確認しながら、デインタリーバのデータ領域に格納するようにデインタリーバモジュール８ｒに渡していく。データ領域の最後の列を含むＳＳＣＳ−ＰＤＵに付与されたヘッダ／トレイラはエンドビットがマークされており、更に次のＳＳＣＳ−ＰＤＵはＦ／ＤビットがＤからＦに変わる。このＰＤＵからは、ＦＥＣを含むデータであることをデインタリーバモジュール８ｒに通知する。この通知に従って、デインタリーバモジュール８ｒは、データとＦＥＣ冗長符号をデインタリーバの正しい位置に格納していく。途中で生じているセル廃棄は、ＳＳＣＳヘッダ／トレイラ中のＳＮにより廃棄されたセルの位置の特定が可能である。
【０１６５】
上記のようにデインタリーバ上に置かれたデータに関する誤り訂正の詳細については、デインタリーバモジュール８ｒによる処理の説明のところで行う。
【０１６６】
次に、図８の場合について説明する。これは、インタリーバ内のデータ領域とＦＥＣ冗長領域に対してそれぞれ１つずつのＣＰＣＳトレイラが付与されている例である。図２１には、この場合の処理の流れを説明するための図を示す。
【０１６７】
ＡＴＭ網から転送されてきたＡＴＭセルのＡＴＭヘッダを削除し（ステップＳ３１）、ＳＡＲ処理（ステップＳ３２）、ＣＰＣＳＲ処理（ステップＳ３３）を行う。ＣＰＣＳ−ＰＤＵに対して行われたＣＲＣおよび長さ表示チェックの結果がＣＰＣＳ処理モジュール１４ｒからＳＳＣＳレイヤに対して通知される。
【０１６８】
図７の場合と同様に、誤りが検出されていなければ、その旨の通知をＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒがＣＰＣＳ処理モジュール１４ｒから受けている。この場合には、次にＦＥＣ冗長領域を含むＣＰＣＳ−ＰＤＵがＣＰＣＳレイヤから渡されたときには、誤りを含む含まないに係わらずそのＣＰＣＳ−ＳＤＵを廃棄してよい。よって、図２１で「ＦＥＣ冗長コードの廃棄命令を出す」というオペレーションが動作し（ステップＳ３５）、次に到着するＣＰＣＳ−ＳＤＵを廃棄する（ステップＳ３６）。このように処理を行えば、ＦＥＣを付与していない場合と比較してもＳＳＣＳヘッダ／トレイラを削除するだけのオーバーヘッドで実現が可能である。
【０１６９】
すなわち、ＦＥＣ冗長領域とデータ領域が別々のＣＰＣＳ−ＰＤＵに属していることにより、上述したように、データ領域のＣＰＣＳ−ＰＤＵにエラーのない場合に、ＦＥＣ領域のＳＳＣＳ処理を行う無駄がなくなり、結果として処理の軽減を図ることができるのである。これは、必ずしもデータ領域とＦＥＣ冗長領域に１つずつのＣＰＣＳ−ＰＤＵを割り当てる場合にとどまらず、図７の例などにもあるように、１つのＣＰＣＳ−ＰＤＵ内に、インタリーバのデータ領域とＦＥＣ冗長領域が混ざって存在しなければ、同様にあてはまることである。
【０１７０】
次に、データ領域を含むＣＰＣＳ−ＳＤＵにエラーが発見された場合について説明する。ＣＰＣＳトレイラで誤りが検出されたデータ列の先頭に位置するＳＳＣＳヘッダ／トレイラの中を見て（ステップＳ３４）、ペイロード内のデータ列がデータ領域を示している場合、すなわちＤ／ＦビットがＤである場合、誤り訂正を行わなければならない（ステップＳ３８，Ｓ４０）。ペイロードの中身がＦＥＣ冗長領域、すなわちＤ／ＦビットがＦである場合には、それとペアであるデータ領域を含むＣＰＣＳ−ＳＤＵで誤りが検出されていなければ上述の例にあてはまるので、ＦＥＣ冗長符号を含むＣＰＣＳ−ＳＤＵはもはや不要であり、訂正の必要はない（ステップＳ３９，Ｓ４０）。
【０１７１】
先頭のＳＳＣＳ−ＰＤＵから順にＳＳＣＳヘッダ／トレイラのＤ／ＦビットがＤであることを確認しながら、デインタリーバのデータ領域に格納するようにデインタリーバモジュール８ｒに渡していく。データ領域の最後の列を含むＳＳＣＳ−ＰＤＵに付与されたヘッダ／トレイラはエンドビットがマークされており、更に次のＳＳＣＳ−ＰＤＵはＦ／ＤビットがＤからＦに変わる。このＰＤＵからは、ＦＥＣを含むデータであることをデインタリーバモジュール８ｒに通知する。この通知に従って、デインタリーバモジュール８ｒは、データとＦＥＣ冗長符号をデインタリーバの正しい位置に格納していく。途中で生じているセル廃棄は、ＳＳＣＳヘッダ／トレイラ中のＳＮにより廃棄されたセルの位置の特定が可能である。
【０１７２】
しかしながら、図７の場合と異なり、通常のランダム誤りが含まれている場合、その誤り位置をインタリーブのどの一列あるいは数列であるかを特定することができない。従って、この場合は、位置のわからないランダム誤りが含まれることを前提とした誤り訂正処理を行わなければならない。
【０１７３】
このランダム誤り訂正は、一般に消失誤り訂正よりも処理量が多くなるため、それを防ぐための工夫を行うことができる。
【０１７４】
セル内に含まれるランダム誤り（位置のわからないビット誤り）を検出するためには、セル毎にセル全体に対するＣＲＣを設けることが必要である。このようなＣＲＣを設けるには、ＳＳＣＳヘッダ／トレイラに含めることが適切であると考えられ、その場合には、ＳＳＣＳヘッダ／トレイラは、図１８に示した例よりも大きなサイズになる可能性もある。ＳＳＣＳヘッダ／トレイラのＣＲＣにより、あるセル内に誤りが生じていることが発見された場合には、そのセルは消失したものとみなし、デインタリーバにはそのセルは廃棄されたと通知する手段をとる。このように、ランダム誤りを消失誤りにみたてて訂正を行うことにより、処理量が多くなるのを避けることができる。
【０１７５】
ところで、受信側のＣＰＣＳ処理とＳＳＣＳ処理を協調動作させたソフトウェアで実現する場合には、さらなる高速化を図ることができる。すなわち、データ領域に対するＣＰＣＳ処理時に行う通常の長さのカウントとＣＲＣ演算を同時に行うのと並行に、ＳＳＣＳ処理としてＳＳＣＳヘッダ／トレイラの削除を行うものである。
【０１７６】
このように行うと、ＣＰＣＳ処理で誤りが検出されなかった場合には、すでにメモリにはＳＳＣＳヘッダ／トレイラの取り除かれた状態で書き込まれているので、上位レイヤへの受け渡しがポインタ渡しで瞬時に行えるのである。もちろんこの後に渡されるＦＥＣ冗長領域を含むＣＰＣＳ−ＳＤＵは、すでに不必要であるので廃棄して構わない。
【０１７７】
データ領域を格納したＣＰＣＳ−ＰＤＵについてのチェックで誤りが検出されたならば、その旨をＳＳＣＳ処理モジュール６ｒに通知し、続いてＣＰＣＳ処理モジュール１４ｒで処理されるＦＥＣ冗長領域を含むＣＰＣＳ−ＰＤＵをチェックし、両ＣＰＣＳ−ＰＤＵをＳＳＣＳ処理モジュール６ｒに渡さなければならない。ＳＳＣＳ処理モジュール６ｒでも誤りの検出された通知を受け、それに従いシーケンスナンバ等ヘッダ／トレイラのを確認し、セルの抜けている位置をデインタリーバに通知し誤り訂正をさせることとなる。
【０１７８】
（Ｌ）デインタリーバモジュール８ｒによる処理
デインタリーバモジュール８ｒでは、ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒからの情報により、データ領域に誤りがなければデータ列をインタリーバに書き込みしなおすことなく、スルーな状態でアプリケーション処理モジュール４ｒに渡していく。例えば図５のように、インタリーブ上ではランダムな並びであるようなデータもあるが、これらデータの送受信の順序は上位アプリケーションから見て順序透過性がある。すなわち、ＣＰＣＳレイヤからのデータについて、ＳＳＣＳレイヤでのオーバヘッドを除けば、そのままスルーしてアプリケーション処理モジュール４ｒに渡すことが可能である。
【０１７９】
ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒからの情報により、データ領域に誤りが検出されていれば、誤りを含むデータをインタリーバの所定の位置に戻していき、該データ領域に対応して付随されているＦＥＣ冗長領域のビット列をＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒから受け取り、同じくインタリーバのＦＥＣ冗長領域に戻し、ＦＥＣ演算を行って誤り訂正を行う。
【０１８０】
この際、データ領域の最後のＳＳＣＳ−ＳＤＵは全てがデータではなく、一部がダミーデータである可能性が高い。１列のどこまでがデータであるかは、ＳＳＣＳヘッダ／トレイラによりデータを含む最後のＳＳＣＳ−ＳＤＵであることを認識した結果を、デインタリーバまで通知してもらうことにより検出する。
【０１８１】
図８の場合、デインタリーバではデータ領域の最後のＳＳＣＳ−ＳＤＵが到着したら、その列の最後から９シンボル目（ＬＩフィールド）を見る。そこに示された値は、ＬＩフィールドから逆方向に何オクテットのパディングが挿入されているかを示している。また、図７の場合には、データ領域の最終列の最後のシンボルがＬＩフィールドとなっており、そのＬＩフィールドから逆方向に何オクテットのパディングが挿入されているか、またはその最終列内の最上行から何オクテットの実データが含まれているかのいずれかの情報を表す。
【０１８２】
その後、データ領域に書き込まれている訂正されたデータをアプリケーション処理モジュール４ｒに渡していく。渡す順序は送信側端末２ｔでインタリーバモジュール８ｔに書き込んだ順序と同様に列方向に読み出しながら渡していく。デインタリーバ処理を行ってデータ長を正確に把握しているので、上位レイヤに渡す場合にもパッドのダミーデータを上位に渡してしまうことはない。データ領域のＳＳＣＳ−ＰＤＵに誤りが検出されていない場合にも、上位にパッド以外のデータのみを渡さなければならないので、データの正確な長さを把握する必要がある。この場合は、ＦＥＣ冗長コードの廃棄命令を出す際に、先に説明したデインタリーバを行った場合と同じようにデータ領域を含む最後のＳＳＣＳ−ＳＤＵをＳＳＣＳヘッダ／トレイラ確認時に通知してもらい、それによって長さを正確に知る。パッドであった部分は上位レイヤに渡す前に取り除く。
【０１８３】
（Ｍ）アプリケーション処理モジュール４ｒによる処理
最後に、アプリケーション処理モジュール４ｒが、アプリケーションデータをＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒから受け取り、アプリケーション処理を行う。
【０１８４】
以上が、受信側端末２ｒにおける処理の流れである。
【０１８５】
次に、より具体的な例として、ＦＥＣ付与モジュール１０ｔおよびＦＥＣ訂正モジュール１０ｒにおけるＦＥＣ手法の動作例をあげる。
【０１８６】
送信側において、ＦＥＣ付与モジュール１０ｔでは、インタリーバモジュール８ｔからのデータを見ながらインタリーバのＦＥＣ冗長領域に付加すべきデータを計算し、その結果をすぐにインタリーバモジュール８ｔに返す役割を担う。インタリーバモジュール８ｔでは、受け取ったＦＥＣ冗長領域用のデータを通常のデータに続けてＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔに渡す。ＳＳＣＳヘッダ／トレイラ付与モジュール１２ｔでは、それぞれの領域に従って、ヘッダ／トレイラを付与する。
【０１８７】
また、受信側において、ＦＥＣ訂正モジュール１０ｒは、そのインタリーバについて訂正する必要のある時のみ動作する。すなわち、下位のＣＰＣＳ処理モジュール１４ｒにおいてセル抜けやビット誤りによるエラーが検出された時、そのデータはＳＳＣＳ処理モジュール６ｒに渡されてデインタリーバモジュール８ｒに蓄えられる。そして、ＳＳＣＳヘッダ／トレイラ確認モジュール１２ｒにおいて、多くの場合、デインタリーバ内のどの位置にセル抜けあるいはビット誤りがあるのかが検出される。プロトコル仕様によっては、位置の正確に特定できないビット誤りが含まれることがあるが、その場合でも、訂正能力は誤り位置の特定された場合よりも限定されるものの、ＦＥＣ訂正モジュール１０ｒにおいては訂正可能な構成をとることができる。しかしながら、この実施例では簡単のため、上記ＳＳＣＳヘッダ／トレイラに付与された種々のビットが有する能力によって、ビット誤りが発生した場合においても、その誤りシンボル位置が特定できるものと仮定する。このようなエラーに対して、ＦＥＣ訂正モジュール１０ｒでは、デインタリーバモジュール８ｒのデータを参照しながら、データ抜け部分の復元、あるいはビット誤りの訂正を行う。そして、訂正情報をデインタリーバモジュール８ｔに戻す。
【０１８８】
ＦＥＣ付与モジュール１０ｔおよびＦＥＣ訂正モジュール１０ｒの構成は、これまでに述べてきたインタリーバモジュール自身のサイズや、それぞれのインタリーバについて、１つのＳＳＣＳヘッダ／トレイラを付与する列数や、またインタリーバへの書き込み位置等によって、少しずつ異なることになる。
【０１８９】
従って、これらのモジュールの例を挙げる際には、インタリーバモジュール８ｔおよびデインタリーバモジュール８ｒと関連させながら説明することとなる。はじめに、送信側におけるＦＥＣ冗長シンボル構成法の例をあげ、その後にそれぞれの方法に対する、受信側での誤り訂正方法の例を述べることとする。
【０１９０】
まず、図７および図８に示されるようなインタリーバの一列がすべて１セルのペイロードに収容され、また該１列のみでＳＳＣＳレイヤのペイロードとなる場合について説明する。このような場合は、インタリーバの縦の長さは３９オクテットまたは４７オクテット、横の最大長はＲＳ符号の１シンボルをｋビットとして２＾ｋ−１シンボル長以下になる。このようにシンボルの大きさを可変にすると、それに従ってインタリーバの大きさが変わるが、これらインタリーブ処理には、主としてソフトウェア上での操作を考慮する必要があるので、ソフトウェア処理に適したインタリーバ長にするため、１シンボルのビット数は２のｎ乗（ｎは整数）、すなわち４ビット、８ビット、１６ビット等が望ましい。また、この中で、ＡＡＬ１では１シンボルを８ビットとした仕様が決められている。従って以下では、１シンボルは全て８ビットの場合のみについて記すこととする。もちろん、他のビット数の場合も同様の操作で行われる。
【０１９１】
そのようにすると、図７のような例では、インタリーバの縦の長さが３９オクテット、横の長さが２５５オクテット長以下の任意のオクテット長となる。また図８では、横は同じで縦のみが４７オクテットとなる。どちらの図でも、データ領域に最大１２４オクテット、ＦＥＣ冗長領域に４オクテット分を割り当てている。実際にはこれらの合計が２５５オクテットを越えないように設計できることになるが、本実施例では、ＡＡＬ１におけるインタリーバの横の大きさに合わせた例として、図７および図８の場合について詳細に示すこととする。従って、生成多項式等もＡＡＬ１と同様のものとして論じることとする。
【０１９２】
具体的には、αを８次の原始多項式の根とし、生成多項式は、

とする。ただし、（１）式およびそれ以降の式はすべてＧＦ（２＾８）上での演算によるものとする。ここで、α＾ｂは、αのｂ乗を表すものとする。
【０１９３】
図７および図８における実際のＦＥＣ演算の方法としては、図１３および図１４による方法、図１６による方法、図５による方法等がある。
【０１９４】
以下、それぞれの方法を示す。
【０１９５】
（１）送信側ＦＥＣ処理方法１
ここでは、図１３や図１４の送信側におけるインタリーバへのデータ挿入方法に対するＦＥＣ冗長データの生成方法を示す。
【０１９６】
図１４にあるように、この方式の場合、インタリーバのなるべく右側につめてデータが挿入されていることが特徴である。従って、図７のインタリーバで具体的に説明すると、データがインタリーバのデータ領域に全部入っている場合には、３９×１２４シンボル分のデータが入るが、もしデータがｍ列分しかない場合、インタリーバの左から（１２４−ｍ）列は空（データがはいっていない）となる。そして、残りｍ列の先頭からデータが入るが、データ領域の最後の列は実データが全部入っている場合と、パディング用のデータの混じっている場合がある。
【０１９７】
データの入っていない先頭の（１２４−ｍ）列に関しては、この部分をセルに合成して送信することはないため、ＦＥＣ用の符号化をするに際しても、この部分は、符号化のための情報部に含めない。ただし、装置化するにあたって、送受信の少なくとも一方がインタリーバの大きさを可変長にすることが困難であるような場合があるかもしれない。そのときは、あらかじめ送受信間でネゴシエーションし、実際にはデータを送らないとしても、インタリーバの中で空きがでる部分にどのようなダミーデータをいれてＦＥＣの符号化および復号化を行うかについて決めておく方法もある。
【０１９８】
インタリーバについては、各行毎に符号化を行うこととする。この場合、ｍシンボル（オクテット）の情報部分と４シンボル（オクテット）の冗長部分からなる符号語が３９行分できることになる。各行は並列に符号化／復号化が行われ、それぞれの行で同じ動作が行われるため、以下では一行のみについて示すこととする。
【０１９９】
インタリーバの一行には情報シンボルはｍ個（１≦ｍ≦１２４）あるので、それをインタリーバの左側から表して、

と表記することにする。たまに情報シンボルの存在しない行が存在するが、その場合はＭ［＊］はない。
【０２００】
また、符号語のシンボルは（ｍ＋４）個あるので、それもインタリーバの左側から表すと、

となる。情報Ｍと符号語Ｃとは一対一であるので、必ずしも同じシンボル値を共有する必要はないが、今回のようにインタリーブすることによって遅延が増えないようにするためには、なるべくシンボル値を共有することが望ましい。
【０２０１】
従って、上記（２）式と（３）式において、情報シンボルはそのまま符号シンボルとして使用し、

とする。そして、Ｃ［３］、Ｃ［２］、Ｃ［１］、Ｃ［０］を冗長部分とする。
【０２０２】
このようにすると、送信時に、上位レイヤからのメッセージをそのまま下位に流すことができる。すなわち、一旦インタリーバに書き込むことなく、上位レイヤからのメッセージをスルーして流せるため、遅延が小さくて済むというメリットが生まれる。ただし、上位から下位へ流すデータは、冗長シンボル生成のための計算処理のためには使用される。
【０２０３】
一方、受信時にはデインタリーバのデータ領域の全体、あるいはその領域をいくつかに分割したそれぞれの部分に対して、下位レイヤにおいてＣＲＣによる誤り検査が行われる。この検査の結果そのデインタリーバのデータ領域に誤りがないと判定された場合には、データ領域のデータは、ＳＳＣＳレイヤにおいて、デインタリーバに改めて書き込むことなく、ＳＳＣＳヘッダ／トレイラ処理のみを行ってスルーして上位レイヤに送ることができる。また、冗長部分は不必要なので、これも特に処理を行わず即座に廃棄できる。このようにして、受信側処理全体のスループットを向上させるというメリットがある。ところが、もし同じ値を元の情報と符号語とで共有している式（４）のような構成になっていなければ、符号語全体を受信しないと元のメッセージが復元できないため、上述のメリットが生まれないことになる。
【０２０４】
以上は、主として図１４に関するインタリーバモジュール８ｔ中のデータについて述べた。式（４）のようにして、Ｃ［ｍ＋３］からＣ［４］までは簡単に生成することができる。
【０２０５】
次に、残りの冗長部分の生成方法を述べる。この冗長部分は、上述した構成のインタリーバモジュール８ｔからのデータ受けて、ＦＥＣ付与モジュール１０ｔにおいて生成される。
【０２０６】
ここでは、ＡＡＬ１と同じようなＲＳ符号を用いることとしているので、演算としては、まず情報Ｍを多項式表現したＭ（Ｘ）を、

と表して

となるような、ａ［ｍ］、ｂ［ｍ］、ｃ［ｍ］、ｄ［ｍ］の係数を求めることを行えばよい。
【０２０７】
ここで、Ｑ（Ｘ）は、Ｍ（Ｘ）・Ｘ＾４をＧ（Ｘ）で割った商にあたり、式（６）のＱ（Ｘ）・Ｇ（Ｘ）以外の右辺部分は、その余りに相当する。よって、Ｍ（Ｘ）が決まると、式（６）の左辺をＧ（Ｘ）でわり算すればよい。ａ［ｍ］、ｂ［ｍ］、ｃ［ｍ］、ｄ［ｍ］はそれぞれ、

に相当する。
【０２０８】
繰り返し述べているように、このインタリーバはある最大サイズまでは可変であり、しかもそれがどれ位の大きさになるかは、上位からのデータ量次第である。従ってデータが多い場合も少ない場合も同じような計算手法を使わないと、計算に無駄が生じることになる。式（６）をそのまま用いることは、Ｍ（Ｘ）が確定してからならばよいが、通常は上位レイヤからいきなりメッセージＭを全部一度に与えられることはない。上位レイヤからは、例えば数バイト長ずつのデータが流れてきている。それを全部受け取った後に、はじめて上位レイヤからのメッセージ長がどれだけの量であった、ということが判明するのである。従って、もしＭ（Ｘ）が確定するまでＦＥＣ演算処理の開始を待つとすると、それは従来のＡＡＬ１のような垂直方向のデータの読み書きをする場合と同じ程度の遅延を要することになってしまう。そのような訳で、上位レイヤからデータが流れ始めると、すぐにＦＥＣ冗長領域の計算が開始でき、しかもいつ上位レイヤからのデータが終わったとしても、常に式（６）の形になっているような計算方法を用いる必要がある。
【０２０９】
そこで、本実施例においては、ハードウェアにおいて符号化に用いられているシフトレジスタを用いた方式を（ソフトウェアで実現する場合においても）採用するのがよい。すなわち、まずＭ［ｍ−１］が上位レイヤより来るため、これに対してあたかもこれが最終列のシンボルであるかのように以下の計算を行う。
【０２１０】

ここで、式（１）のそれぞれの係数を利用すると、式（８）の値は、

により簡単に求められる。これは、実際に計算してもよいし、かけ算のテーブルをひく方法をとってもよい。
【０２１１】
もし、ｍ＝１であって、Ｍ［ｍ−１］が最後であったとすると、右辺の４つの係数の値がそれぞれ式（６）のａ，ｂ，ｃ，ｄに相当する。すなわち、Ｍ［０］はＣ［４］にそのまま変わり、

となる。このように１シンボル目では式（８）と式（６）とでは整合がとれている。
【０２１２】
次に、２シンボル目が到着した場合を考える。式（６）に合わせるように記述すると、

となる。この場合は、Ｘ＾５の項とＸ＾４の項に分けて、別々にＧ（Ｘ）で割った剰余を計算し、それを後で加える方法がある。しかし、そのような方法では、シンボル数が段々増えていくにつれて、その計算回数がシンボル数に比例して増えていく、という問題が生じる。当然テーブルを引く場合にも、テーブル参照回数が増えていってしまう。
【０２１３】
そこで、式（８）をうまく利用することを考える。
式（１１）は、式（８）を用いて、

と変形できる。
【０２１４】
式（１２）の左辺を展開して、

となる。
【０２１５】
従って、

により、メッセージが２シンボルの場合のＦＥＣ冗長領域のシンボル値が求められる。
【０２１６】
式（１４）は、帰納的に用いることができる。すなわち、２シンボル目以降は毎回その以前のシンボル値から容易に計算できる。よってｋシンボル目が到着した時には、

という計算を行えばよい。
【０２１７】
このようにして最後のシンボルが到着するまで、あるいはインタリーバに収容されるデータ領域の最大列数（本実施例では１２４）までのシンボルが計算されると、終了し、その次のタイミングで、他の行において計算されたものと一緒に、ＦＥＣ付与モジュール１０ｔからインタリーバモジュールにＦＥＣ冗長領域データとして送られる。送る順序は、ａ［ｍ］、ｂ［ｍ］、ｃ［ｍ］、ｄ［ｍ］の順である。
【０２１８】
図１０においては、最後の列にはパディングされた部分があるが、この部分については符号化のための情報に加える方法も加えない方法も実現可能である。しかし、少なくともＬＩ表示のシンボルはＦＥＣ符号化のためのデータに加えたいので、パディング部分も（たとえａｌｌ“０”のデータでも）一応、加えた方が装置化が楽になるであろう。もし、パディング部分を含まないようなＦＥＣ符号化を行うとすると、全くデータのない（つまり情報Ｍがヌルである）行が存在し得る。このような場合は、ＦＥＣ付与モジュールは、ａ［０］＝ｂ［０］＝ｃ［０］＝ｄ［０］＝０のデータをインタリーバモジュールに返す。
【０２１９】
（２）送信側ＦＥＣ処理方法２
ここでは、図１６にあるように、送信側にてデータをインタリーバの左上から正確に挿入するような場合のＦＥＣ冗長データの生成方法を示す。
【０２２０】
図１６にあるように、本方式の場合、今度はインタリーバのなるべく左側につめてデータが挿入されているという特徴を有している。従って、図７のインタリーバで具体的に説明すると、データがインタリーバのデータ領域に全部入っている場合には、前述した例と同様に、３９×１２４シンボル分のデータが入るが、もしデータがｍ列分しかない場合、インタリーバの右から（１２４−ｍ）列は空（データがはいっていない）となる。そして、ｍ列目は実データが全部入っている場合と、パディング用のデータの混ざっている場合がある。
【０２２１】
データ領域の残りの（１２４−ｍ）列に関しては、この部分をセルに合成して送信することはない。それはすなわちトラヒックの無駄を意味するからである。ＦＥＣ用の符号化をするに際しては、この部分は、あたかも全て“０”のデータが入っているかのように扱われる。
【０２２２】
別の手法として、あらかじめ送受信間でネゴシエーションし、実際にはデータを送らないとしても、インタリーバの中で空きがでる部分にどのようなダミーデータをいれてＦＥＣの符号化および復号化を行うかについて決めておく手法もある。この場合は必ずしも空き領域を全て“０”にするような必要はなく、お互いの決めたビットパターンを用いて符号化すればよい。しかし、一般にそのようなビットパターンを決めておくと、ＦＥＣのための符号化にはかえって演算時間を増加させることになってしまので、ここではａｌｌ“０”を仮定することとする。
【０２２３】
インタリーバにおいては、前述した例と同様に各行毎に符号化を行うこととする。すると、この場合はｍシンボル（オクテット）の情報部分と、（１２４−ｍ）シンボルの“０”のデータと、４シンボル（オクテット）の冗長部分からなる符号語が３９行分できることになる。各行は並列に符号化／復号化が行われ、それぞれの行で同じ動作が行われるため、そのうち一列について見ることとする。
【０２２４】
インタリーバの一行には情報シンボルはｍ個（１≦ｍ≦１２４）あるので、それをインタリーバの左側から表して、

と表記することにする。たまに情報シンボルの存在しない行が存在するが、その場合はＭ［＊］はない。
【０２２５】
また、符号語のシンボルは１２８個あるので、それもインタリーバの左側から表すと、

となる。情報Ｍと符号語Ｃとは一対一であるので、必ずしも同じシンボル値を共有する必要はないが、インタリーブすることによって遅延が増えないようにするためには、情報シンボル値を共有することが望ましい。
【０２２６】
従って、上記（１６）式と（１７）式において、情報シンボルはそのまま符号シンボルとして使用し、

とする。そして、Ｃ［３］、Ｃ［２］、Ｃ［１］、Ｃ［０］を冗長部分とする。ただし、式（１８）において、Ｃ［１２７−ｍ］からＣ［４］までは実際にはネットワークには送出しない。
【０２２７】
このようにすると、送信時には、上位レイヤからのメッセージをそのまま下位に流すことができる。すなわち、一旦インタリーバに書き込むことなく、上位レイヤからのメッセージをスルーして流せるため、遅延が小さくて済むというメリットが生まれる。ただし、上位から下位へ流すデータは、冗長部分生成のための計算処理のためには使用される。
【０２２８】
受信時には、下位レイヤのＣＲＣによる誤り検査の結果、そのデインタリーバのデータ領域に誤りがない場合、データはＳＳＣＳヘッダ／トレイラ処理のみでスルーして上位レイヤに渡せる。冗長部分は即座に廃棄でき、デインタリーバへ改めて誤り訂正のための書き込みを行う必要はない。このようにして、全体の処理遅延を減らすことができるという利点が得られる。もし、式（１８）のように同じ値を元情報と符号語とで共有しているような構成になっていなければ、符号語全体を受信しないと元のメッセージが復元できないため、上述の利点は得られない。
【０２２９】
以上は、主として図１６に関するインタリーバモジュール８ｔ中のデータについて述べた。式（１８）のようにして、Ｃ［１２７］からＣ［４］までは簡単に生成することができる。
【０２３０】
次に、残りの冗長部分の生成方法を述べる。この冗長部分は、上述した構成のインタリーバモジュール８ｔからのデータ受けて、ＦＥＣ付与モジュール１０ｔにおいて生成される。
【０２３１】
ここでは、ＡＡＬ１と同じようなＲＳ符号を用いることとしているので、演算としては、まず情報Ｍを多項式表現したＭ（Ｘ）を、

と表して、

となるような、ｅ［ｍ］、ｆ［ｍ］、ｇ［ｍ］、ｈ［ｍ］の係数を求めることを行えばよい。
【０２３２】
ここで、Ｑ（Ｘ）は、Ｍ（Ｘ）・Ｘ＾４をＧ（Ｘ）で割った商にあたり、式（２０）のＱ（Ｘ）・Ｇ（Ｘ）以外の右辺部分は、その余りに相当する。インタリーバのデータ領域中のダミー部分は、値が“０”であり、符号化の計算には関わらないため、式（２０）では既に省略されている。よって、Ｍ（Ｘ）が決まると、式（２０）の左辺ををＧ（Ｘ）でわり算すればよい。ｅ［ｍ］、ｆ［ｍ］、ｇ［ｍ］、ｈ［ｍ］はそれぞれ、

に相当する。
【０２３３】
前述した例とは異なり、Ｍ（Ｘ）を構成する個々の項において、Ｍ（Ｘ）におけるｍの値によらず項の係数と次数は変化しない。すなわち、インタリーバの１列目のデータＭ［ｍ−１］に対しては、必ずＸ＾１２３であり、これは２列目、３列目とデータが増えていっても変化しない。もちろん２列目以降についても同様である。すると、式（２０）において、

となるので、ｍの値にかかわらず、インタリーバの最初のデータから順にＸのべき乗をかけたもの、すなわち式（２２）における各項をを個別にＧ（Ｘ）で割ることが可能である。従って、このような形での冗長領域の計算方法としては、インタリーバのデータが１シンボル到着する度に、そのデータに対してＧ（Ｘ）によるわり算を実行し、その余りをそれまでに計算された余りに加える方法が考えられる。
【０２３４】
以下、この方法を具体的に示す。
【０２３５】
まず、インタリーバの最初のデータが到着すると、

となるｅ［１］、ｆ［１］、ｇ［１］、ｈ［１］を計算する。次に２番目のデータが到着すると、式（２３）と同様に

を計算し、その後、

のように排他的論理和を行って２シンボルのデータに対する冗長を計算する。以下も同様に行い、最終的にｅ［ｍ］、ｆ［ｍ］、ｇ［ｍ］、ｈ［ｍ］が得られる。このように１つずつ計算することによって、最終のシンボルが到着した時点でそのときの計算値が求められることになる。
【０２３６】
式（２３）および式（２４）のようなＧ（Ｘ）でのモジュロ計算は、毎回行うとかなり計算時間をとられることになる。従って、通常は、各Ｘのべき乗に対するＧ（Ｘ）のモジュロ値のテーブルを持つのがよい。
【０２３７】
テーブルには、

の計算結果である、Ｅ［ｋ］、Ｆ［ｋ］、Ｇ［ｋ］、Ｈ［ｋ］の値とそれに対応するＸのべき乗の数が書かれている。すなわち、例えば図２２に示す表ａのようになる。
【０２３８】
この表ａを用いると、任意の入力データＭ［ｍ−ｋ＋１］に対して、

となることから、

という計算によって、各シンボルに対する剰余の値が簡単に算出できる。ただし、ｅ［１］＝ｅ’［１］、ｆ［１］＝ｆ’［１］、ｇ［１］＝ｇ’［１］、ｈ［１］＝ｈ’［１］である。
【０２３９】
このようにして、最後のシンボルが到着するまで、あるいはインタリーバに収容されるデータ領域の最大列数（本実施例では１２４）までのシンボルが計算されると終了し、その次のタイミングで、計算結果を他の行において計算されたものと一緒に、ＦＥＣ付与モジュール１０ｔからインタリーバモジュールにＦＥＣ冗長領域データとして送る。送る順序は、ｅ［ｍ］、ｆ［ｍ］、ｇ［ｍ］、ｈ［ｍ］の順である。
【０２４０】
図１６においても、前述した例と同様に、最後の列にはパディングされた部分があるが、この部分については符号化のための情報に加える方法も加えない方法も実現可能である。しかし、少なくともＬＩ表示のシンボルはＦＥＣ符号化のためのデータに加えたいので、パディング部分も（たとえａｌｌ“０”のデータでも）データとして加えた方が、装置化が容易になる。もし、パディング部分を含まないようなＦＥＣ符号化を行うとすると、全くデータのない（つまり情報Ｍがヌルである）行が存在し得る。このような場合は、ＦＥＣ付与モジュールは、ｅ［０］＝ｆ［０］＝ｇ［０］＝ｈ［０］＝０のデータをインタリーバモジュールに返す。
【０２４１】
（３）送信側ＦＥＣ処理方法３
ここでは、図５の送信側におけるインタリーバへのデータ挿入方法に対するＦＥＣ冗長データの生成方法を示す。
【０２４２】
図５のようにランダムにインタリーバへの書き込みが行われる場合には、送信側ＦＥＣ処理方法１のような規則的な手法を用いることはできない。そこで、送信側ＦＥＣ処理方法２のようなテーブルを用いて、各シンボルに対する剰余を計算し、それを加えることによって、ＦＥＣ冗長領域の値を計算する手法が用いられる。
【０２４３】
以下に、図５のそれぞれについて簡単にＦＥＣ冗長領域の生成方法を述べる。
【０２４４】
送信側ＦＥＣ処理方法においては、インタリーバの左端から規則正しくデータが挿入されていたので、テーブルの内容についても、図２２の表ａのように規則正しく並んでいた。しかし、図５のそれぞれの実施例については、その規則性がないため、それぞれ送信側と受信側とであらかじめネゴシエーションした後に、はじめて上記のような表が書けることになる。
【０２４５】
図５（ｂ）の場合には、ランダムであるのは書き込む列の順序だけであり、縦方向の書き込み方は決められているので、前述した例と同様に、図２２の表ａだけを用いればよいが、図５（ａ）の方は、書き込む列の順序だけでなく、その一列の中でのシンボルの書き込み順序が異なるため、その順序情報についての表を追加して書かなければならない。
【０２４６】
まず、図５（ｂ）について説明する。ここでは、図に従いデータ領域が右端７行、ＦＥＣ冗長領域が４行あることとする。左端の行から、５番目、２番目、７番目（実際はヌルでデータなし）、４番目、１番目、３番目、６番目（実際はヌル）、といったデータとなる。
【０２４７】
すると、送信側ＦＥＣ処理方法２と同様にして、情報の多項式表現Ｍ（Ｘ）は、

となる。
【０２４８】
以下の処理は、送信側ＦＥＣ処理方法２における式（２０）〜式（２８）の経過と比較して、Ｍ［＊］、ｅ［＊］、ｆ［＊］、ｇ［＊］、ｈ［＊］の係数を除くとほとんど同じである。従って、図２２の表ａを用いて、まずＭ［４］に対するｅの係数を式（２８）の方法で、

で求め、それ以下のものは、順に、

の排他的論理和演算を行うことによって最終のｅ［１１８］を得ることができる。係数ｆ，ｇ，ｈについても全く同様の計算により得られる。こうして、ｅ［１１８］、ｆ［１１８］、ｇ［１１８］、ｈ［１１８］がそれぞれ求める冗長シンボルとなる。
【０２４９】
次に、図５（ａ）の場合を示す。この場合も図に従ってシンボル単位に書き込みが行われるとすると、図２２の表ａ１の他に、図２３の表ｂを用いることによって計算することができる。ここでも、図に示されているようなデータ領域が右端６行、ＦＥＣ冗長領域が４行ある具体例を用いて説明する。なお、行番号は左端および上端から昇べきの順につけるものとする。
【０２５０】
この図２３の表ｂに従うと、図で例えば上から４行目の情報の多項式表現Ｍ（Ｘ）は、各シンボルをＭ［＊］で表すと、

と表せる。ここからは、図５（ｂ）の例と同様にして図２２の表ａを用い、Ｘ＾３の係数ｅは、

の排他的論理和演算を順に行うことによって、得られる。他の係数ｆ，ｇ，ｈも同様である。
【０２５１】
こうして、ｅ［１１９］、ｆ［１１９］、ｇ［１１９］、ｈ［１１９］がそれぞれ上から４行目の冗長シンボルとなる。他の行については、式（３３）において情報Ｍのシンボル番号が異なるだけで、それ以外は同様の演算により得られる。
【０２５２】
以上のように、図５（ａ），（ｂ）の例でのＦＥＣ冗長領域の計算は、送信側ＦＥＣ処理方法２を多少変形した方法を用いることによって実行することができる。
【０２５３】
図７および図８のような構成以外の例として、インタリーバの一列が１セルよりも大きい場合、また、インタリーバの複数列に対してＳＳＣＳヘッダを付加する場合等が考えられるが、これらの場合においても、図１３、図１６、図５のそれぞれの例に合わせて、全く同様の演算でＦＥＣ冗長シンボルの計算が行える。
【０２５４】
これまでは３種類の例をあげて、送信側におけるＦＥＣ冗長領域の計算方法について説明してきたが、今度はそれぞれに関する受信側での復号方法および誤り訂正方法について説明する。
【０２５５】
送信側のインタリーバモジュール８ｔから出力されたデータはセルとして伝送され、受信側に到達し、セル分解の後、受信側のデインタリーバモジュール８ｒに入る。ある送信側インタリーバからの受信データは、データ領域の何列かをペイロードに含む１つ以上のＣＰＣＳ−ＰＤＵと、ＦＥＣ冗長領域の何列かをペイロードに含むやはり１つ以上のＣＰＣＳ−ＰＤＵから成っている。このうち、データ領域をペイロードに含む全ＣＰＣＳ−ＰＤＵが、ＣＰＣＳレイヤにおけるＣＲＣチェック等によって、全てエラーなしと判定された場合、ＳＳＣＳレイヤにおいては、ＳＳＣＳヘッダ／トレイラを除去するのみで残りのデータをそのまま上位のアプリケーションモジュール４ｒに渡す。そして、そのデインタリーバに関して、ＦＥＣ冗長領域をペイロードに含むＣＰＣＳ−ＰＤＵは全て、デインタリーバ用のメモリに書き込むことなく廃棄して構わない。
【０２５６】
ただし、データ領域側データをペイロードに含む複数のＣＰＣＳ−ＰＤＵにおいて、１つでもＣＲＣチェック等によるエラーがあるときには、そのデインタリーバに関連する全てのデータは、ＦＥＣ冗長領域のものを含めて、誤り訂正のために必要なものとなる。
【０２５７】
図７の場合は、デインタリーバの一列から１つのＣＰＣＳ−ＰＤＵを構成しており、しかもそれが１つのセルとなる。このため、受信したＣＰＣＳ−ＰＤＵにおいてＣＰＣＳトレイラのＣＲＣチェック等が異常であるという場合には、該ＣＰＣＳ−ＰＤＵ内にビット誤りが発生していることを意味している。この時、エラーの発見された列はデインタリーバモジュール８ｒ上で、伝送中にセル廃棄された場合と同じ扱いにしてしまう。すなわち、そこの一列にはセルが到着しなかったと同等にみなす。そしてその結果として生じたセル抜けの位置をＳＳＣＳヘッダのＳＮチェックにより確認する。
【０２５８】
一方、図８のような場合は、デインタイリーバの一列は１セルであるが、ＣＰＣＳ−ＰＤＵは複数列にまたがって構成される。従って、ＣＰＣＳトレイラによるチェックのみでは、ランダム誤りおよびセル抜けの状態が不明確である。仮にあるＣＰＣＳ−ＰＤＵにおいてセル抜けがあったとすると、ＣＰＣＳトレイラの機能だけでは、そのＣＰＣＳ−ＰＤＵに属する他のデインタリーバ列がエラーフリーである保証がなされない。
【０２５９】
そこで、まずセル抜けに対しては、ＳＳＣＳヘッダ／トレイラのＳＮを用いて確認する。ＳＮ自体に誤り検査ビットを加えておくと、抜けた位置を特定する際の確実性が増す。また、ランダムなビット誤りへの対策としては、ＳＳＣＳヘッダ／トレイラがデインタリーバの１列毎についているので、この部分にＳＳＣＳ−ＰＤＵ全体の誤り検出機能を付加する。そして、伝送中のセル廃棄によって、ＣＰＣＳトレイラの誤り検出機能が有効に働かなかった場合、あるいはビット誤りによってＣＰＣＳトレイラのＣＲＣチェックにエラーが発見された場合に限って、ＳＳＣＳレイヤにおけるデインタリーバ一列単位の該誤り検査を行い、各列のエラーの有無を検査するという方法が考えられる。これによって、ＣＰＣＳ−ＰＤＵのサイズによらず、実際にビット誤りおよびセル廃棄の発見されたインタリーバ列に属するシンボルのみを訂正すればよいことになる。
【０２６０】
また、別の場合として、デインタリーバの一列が複数セルで構成され、その一列をペイロードに含んでＳＳＣＳ−ＰＤＵおよびＣＰＣＳ−ＰＤＵを構成することも考えられる。ここでも、１つのセルが伝送路中に廃棄された場合には、その他の部分のシンボルエラーはＣＰＣＳトレイラを用いても検出不可能になる。この場合には、計算を簡単にするために、該当する一列全てが廃棄されたとみなして誤り訂正を試みる方法をとることができる。このような方法を用いることによって、例えば図７の例に比べて誤り訂正能力は若干落ちるが、処理遅延は増加させることなく小さく保持できる。廃棄されたとみなされるデインタリーバ一列の位置は、ＳＳＣＳヘッダ／トレイラによって特定される。
【０２６１】
ＳＳＣＳヘッダを除いたデータは、インタリーバと全く同様の順番でデインタリーバ領域に書き込む。この書き込み順は、あらかじめ送受信間でネゴシエーションされているものとする。その際、抜けのある部分については、そのことを別領域に明示するか、あるいはダミーのペイロードデータを書き込む。そして、そのデータをＦＥＣ訂正モジュール１０ｒに渡し、シンボル抜けの部分を再生する。その後に、情報データをデインタリーバモジュール８ｔから書き込んだ順に読み出して、受信側のアプリケーション処理モジュール４ｒに送る。
【０２６２】
以下では、上記ＦＥＣ演算の送信側ＦＥＣ処理方法１，２，３に従って、受信側のＦＥＣ訂正モジュール１０ｒにて行われる夫々の場合に対応する誤り訂正操作を、受信側ＦＥＣ処理方法１，２，３として説明する。このモジュールが動作するのは、デインタリーバの任意の一行において、訂正可能な範囲のシンボルエラーがあり、かつその位置が判明している場合であり、以下では、そのような場合を例にとって説明する。なお、図７にあるように、インタリーバの一列がすべて１セルのペイロードに収容され、また該１列のみでＳＳＣＳレイヤのペイロードを構成する場合について説明するが、それ以外のデインタリーバの構成にも適用可能である。
【０２６３】
（４）受信側ＦＥＣ処理方法１
ここでは、送信側ＦＥＣ処理方法１として述べたインタリーバに対するデインタリーバを用いた誤り訂正方法を記す。
【０２６４】
送信側ＦＥＣ処理方法１ではＦＥＣ冗長領域が４シンボル分である場合について記してあるので、この受信側ＦＥＣ処理方法１でもそれに従って記述する。ＦＥＣ冗長領域が４シンボルの場合、誤りシンボル位置が明確であれば、４シンボルまでの誤りを訂正することが可能である。
【０２６５】
いま、ｓ番目、ｔ番目、ｕ番目、ｖ番目のシンボルに誤りまたは抜けがあるとする。ただし、０＜ｓ＜ｔ＜ｕ＜ｖ＜（ｍ＋１）であるとする。
【０２６６】
図１４は、送信側ＦＥＣ処理方法１において説明したように、デインタリーバのできるだけ右側につめてシンボルを挿入する構成をしている。デインタリーバ上に埋まるデータ量は毎回可変なので、受信が開始された時点では、どの位のデータが到着するかの予測ができない。従って、送信側と同様に、可変シンボル長に柔軟に対応できるような復号処理を行う必要がある。
【０２６７】
受信シンボル列は、情報シンボルと冗長シンボルとの合計がｍシンボルあるとすると、（１７）式から、

のように表され、Ｅ［＊］の部分はエラーがある部分を意味する。それ以外のＣ［＊］で書かれる部分は、送信側のデータがそのまま正しく受信されていることを意味する。式（３４）では一般的な書き方をしたが、Ｅ［＊］は、先頭あるいは最後尾のシンボルにあっても構わないし、また連続していても構わない。
【０２６８】
さて、ＦＥＣ訂正モジュール１０ｒでの処理を行うまでに、既にシンボル単位にエラーの有無が明確になっている。もし１シンボルもエラーがない場合には、式（３４）は、

と表され、これを用いた多項式Ｃ（Ｘ）は、生成多項式Ｇ（Ｘ）で割り切れる。これは、すなわち、

となることを意味する。しかし、エラーシンボルの含まれる受信シンボル列Ｒを用いた多項式Ｒ（Ｘ）では、Ｇ（Ｘ）による余りは０とはならない。そこで、これらをシンドロームＳ［ｉ］（ｉ＝１，２，３，４）として次のように表すこととする。
【０２６９】

ここで、Ｅ［＊］の部分の係数を訂正を簡単にするために、Ｒ（Ｘ）においては、

とおいておくこととする。
【０２７０】
すると、シンドロームＳ［ｉ］（ｉ＝１，２，３，４）は、以下のようにして計算される。
【０２７１】
手順１：Ｓ［１］ ＝Ｓ［２］ ＝Ｓ［３］ ＝Ｓ［４］ ＝０とおく。
【０２７２】
手順２：シンボルが１ つ来る度に（すなわちデインタリーバの１ 列が到着する度に）、

のように代入していく。ここで＋は排他的論理和を表す。ただし、式（３８）によって、Ｅ［ｍ−ｋ］ ＝０である。
【０２７３】
手順３：手順２を最後のシンボルまで計算した時のＳ［ｉ］（ｉ＝１，２，３，４）の値が、求めるシンドローム値である。
【０２７４】
手順２を詳細に説明する。最終的には式（３７）の値を求めたいのであるが、受信を終了するまで、シンボル数がどれだけあるのかがわからない。よって、シンボルを受信する度に計算を行い、突然シンボル受信が終了したとしても、シンドロームＳ［ｉ］（ｉ＝１，２，３，４）の計算結果が最終的に求める値になっている必要がある。
【０２７５】
実際に、手順２では、以下の計算と同じことを行っている。まず、最初のシンボルＣ［ｍ−１］が到着すると、シンドローム値は、

となる。
【０２７６】
次に、シンボルＣ［ｍ−２］が到着すると、

となる。
【０２７７】
同様にしていくと、最終的に

となり、この式は（３７）式と同じである。
【０２７８】
このような方法をとることによって、ｋ個のシンボルが到着した時には、必ずシンドロームＳ［ｉ］（ｉ＝１，２，３，４）は、（ｋ−１）次の多項式にα＾（１１９＋ｉ） （ｉ＝１，２，３，４）を代入した形をとっているので、デインタリーバモジュール８ｒのシンボル到着がいつ終了しても、常にその時点の本実施例に基づくデインタリーバ構成での正しいシンドローム演算値を示していることになる。なお、式（４０）〜（４２）において、エラーのあるシンボルを受信した部分については、Ｃ［＊］からＥ［＊］に表記を書き換えるとよい。
【０２７９】
次に、このようにして得られるシンドローム値の意味を考える。誤りのあるシンボルがもし正しく受信されていたとすると、これらはそれぞれ、Ｃ［ｍ−ｋ］（ｋ＝ｓ，ｔ，ｕ，ｖ）と表される。すると、これらの記号を用いて式（３７）のシンドロームＳ［１］の値は、

となる。
【０２８０】
なお、本実施例では、α＾ｂｃは、αの（ｂ×ｃ）乗を表すものとする。例えば、上記のα＾１２０（ｍ−ｓ）は、αの（１２０×（ｍ−ｓ））乗を表す。
【０２８１】
他のシンドロームも同様に、

となる。ただし、ここでは２進信号（０，１）のみを仮定しているので、＋の演算と−の演算はどちらも同じ排他的論理和となる。すなわち式（４３）と（４４）は合わせて、

と表記できる。
【０２８２】
このことから、式（３９）の手順によってＳ［ｉ］（ｉ＝１，２，３，４）の値が求められると、式（４５）は、Ｃ［ｍ−ｓ］、Ｃ［ｍ−ｔ］、Ｃ［ｍ−ｕ］、Ｃ［ｍ−ｖ］に関する連立方程式となる。そしてこれを解くことによって、それぞれの正しいシンボル値が求められる。本実施例では、エラーシンボルの見落としがない（すなわち、ＳＳＣＳレイヤ以下によってエラーのあるシンボルが確実に検出され、それ以外には存在しない）ことを想定しているので、これらの連立方程式には、必ず一意な解が存在する。
【０２８３】
解は、それぞれ、

となる。
【０２８４】
式（４５）において、エラーシンボルがもし１つ（Ｅ［ｍ−ｓ］）のみであれば、上式は、

であり、これから、

となる。これはｉの値によらず同じなので、どれか１つを計算すればよい。とすると、式（３７）において、例えばＳ［１］のみ計算すればよく、他のシンドローム計算を行う必要がないので、その分の演算量を減らすことができる。
【０２８５】
また、もしエラーシンボルが２つ（Ｅ［ｍ−ｓ］とＥ［ｍ−ｔ］）であれば、式（４５）は、

となる。これも２つのシンドローム、例えばＳ［１］とＳ［２］のみを計算すればよく、他のシンボルに対してかかる演算の分を減らすことができる。
【０２８６】
そして、解は、

となる。
【０２８７】
また、エラーシンボルが３つ（Ｅ［ｍ−ｓ］とＥ［ｍ−ｔ］とＥ［ｍ−ｕ］）であるとき、式（４５）は、

となり、この場合は３つのシンドローム、例えばＳ［１］、Ｓ［２］、Ｓ［３］のみを計算すればよい。すなわち、Ｓ［４］に対してかかる演算の分を減らすことができる。
【０２８８】
解は、

となる。
【０２８９】
これらの演算には、αのべき乗の計算が多数必要となる。常に出てくる演算（例えばα＾１２０等）に関しては、表を作っておくと高速化を図ることができる。
【０２９０】
（５）受信側ＦＥＣ処理方法２
ここでは、送信側ＦＥＣ処理方法２で述べたインタリーバに対するデインタリーバを用いた誤り訂正方法を説明する。
【０２９１】
受信側ＦＥＣ処理方法１と同様に、ＦＥＣ冗長領域の大きさと同じ４シンボルまで訂正可能である。そこで、０＜ｓ＜ｔ＜ｕ＜ｖ＜（ｍ＋５）であるような、ｓ番目、ｔ番目、ｕ番目、ｖ番目にそれぞれシンボル誤り、またはシンボル抜けがあるとする。
【０２９２】
図１６の場合は、送信側ＦＥＣ処理方法２で説明したように、データ領域内のシンボルはデインタリーバのできるだけ左側に詰められており、一方ＦＥＣ冗長領域のシンボルは、デインタリーバの右端４列に入れられているような構成である。受信側ＦＥＣ処理方法１と同様に、データが終了するまで、デインタリーバのデータ領域のどこまでデータが入るかは毎回に異なり、全くわからない。従って、シンボル受信開始と同時に復号演算を開始し、シンボル受信がいつが終了したとしても、即座に誤り訂正処理に入れるような復号処理を行う必要がある。
【０２９３】
受信シンボルは、受信側ＦＥＣ処理方法１の場合とは異なり、データがｍシンボル（０＜ｍ＜１２５）、冗長部分が４シンボルあるとする。このとき、受信シンボル列Ｒは（１７）式から、

のように表され、Ｅ［＊］の部分はエラーがあるシンボルを意味する。それ以外のＣ［＊］で書かれる部分は、送信側のデータがそのまま正しく受信されていることを意味する。式（５３）は一般的な書き方であり、Ｅ［＊］はデータ領域の先頭や最後尾、あるいはＦＥＣ冗長領域にあっても構わないし、また連続していても構わない。Ｃ［１２８−ｍ］とＣ［３］の間は、デインタリーバのマトリクス上では、空のデータ領域（０データの部分）があるが、送受信はされないことを意味している。もちろん、ｍ＝１２４の場合は、この空データ領域は存在しない。
【０２９４】
ＦＥＣ訂正モジュール１０ｒでの処理を行うまでに、既にシンボル単位にエラーの有無が明確になっている。シンボルの訂正を簡単にするために、式（５３）において、Ｅ［１２８−ｓ］、Ｅ［１２８−ｔ］、Ｅ［１２８−ｕ］、Ｅ［１２８−ｖ］は全て値が０であるとおき、訂正後のシンボルをそれぞれＣ［１２８−ｓ］、Ｃ［１２８−ｔ］、Ｃ［１２８−ｕ］、Ｃ［１２８−Ｖ］とする。
【０２９５】
受信側ＦＥＣ処理方法１に従って、式（３７）のようにシンドロームＳ［ｉ］（ｉ＝１，２，３，４）を定義すると、これらは以下のように計算される。
【０２９６】
手順１：Ｓ［ｉ］＝０（ｉ＝１，２，３，４）とおく。
【０２９７】
手順２：シンボルが１つ到着する度に、

のように代入していく。
【０２９８】
手順３：手順２で最後のシンボルまで計算した時のＳ［ｉ］（ｉ＝１，２，３，４）の値が求めるシンドローム値である。
【０２９９】
上記手順においてＣ［１２７］が到着した時点で、仮に正しいデータ領域シンボルの到着が終わったとすると、

となる。これはまさしく、図１６にあるＣ［１２７］のシンボルがデインタリーバの左端にある場合のシンドローム計算の結果を示している。もし正しいデータがこの１シンボルのみであったとしても、その後にＦＥＣ冗長領域部分の値を加えると、本実施例に基づくデインタリーバ構成のシンドローム値となる。すなわち、シンボル到着がいつ終了しても常に正しいシンドローム値が求められるような計算方法となっている。
【０３００】
このようにして得られるシンドローム値は、もし受信シンボルに全く誤りがなければ全て０となる。実際は、受信側ＦＥＣ処理方法１の式（４５）にならって、

という値を持つことになる。式（５４）の手順で求められたシンボル値Ｓ［ｉ］（ｉ＝１，２，３，４）を使って、式（５６）の各シンボルＣ［１２８−ｋ］（ｋ＝ｓ，ｔ，ｕ，ｖ）を求めることが、ＦＥＣ訂正モジュール１０ｒでの誤り訂正処理となる。
【０３０１】
これらは４次の連立方程式となり、解は、

となる。
【０３０２】
式（５６）において、エラーシンボルがもし１つ（Ｅ［１２８−ｓ］）のみであれば、上式は、

であり、これから、

となる。これは、ｉの値によらず同じなので、どれか１つを計算すればよい。すると、式（５４）において、例えばＳ［１］のみ計算すればよく、他のシンドローム計算を行う必要がないので、その分の演算量を減らすことができる。
【０３０３】
また、もしエラーシンボルが２つ（Ｅ［１２８−ｓ］とＥ［１２８−ｔ］）であれば、式（４５）は、

となる。
【０３０４】
これも２つのシンドローム、例えばＳ［１］とＳ［２］のみを計算すればよく、他のシンドロームに対してかかる分の演算を減らすことができる。
【０３０５】
そして解は、

となる。
【０３０６】
また、エラーシンボルが３つ（Ｅ［１２８−ｓ］とＥ［１２８−ｔ］とＥ［１２８−ｕ］）であるとき、式（５６）は、

となり、この場合は３つのシンドローム、例えばＳ［１］、Ｓ［２］、Ｓ［３］のみを計算すればよいので、Ｓ［４］に対してかかる演算の分を減らすことができる。
【０３０７】
解は、

となる。
【０３０８】
これらの演算を行う場合には、α＾（１１９＋ｉ）（１２８−ｋ） （ｋ＝１〜１２８），（ｉ＝１，２，３，４）の演算に多少の時間がかかってしまうので、ｉおよびｋをパラメータとした表をあらかじめ作成しておくと、毎回αのべき乗を計算するよりもより高速に演算ができる。
【０３０９】
（６）受信側ＦＥＣ処理方法３
ここでは、送信側ＦＥＣ処理方法３で述べたインタリーバに対するデインタリーバを用いた誤り訂正方法を示す。
【０３１０】
受信側ＦＥＣ処理方法１、２と同様にエラーシンボルは最大４つまで訂正可能である。そこで、それらのエラーシンボル位置をそれぞれｓ番目、ｔ番目、ｕ番目、ｓ番目（０＜ｓ＜ｔ＜ｕ＜ｖ＜（ｍ＋５））とする。
【０３１１】
図５の場合は、到着したシンボル毎にデータ領域のシンボルはランダムに、またＦＥＣ冗長領域のシンボルは、受信側ＦＥＣ処理方法１、２と同様にデインタリーバの右端４列に位置する。この場合も、デインタリーバによっていつシンボル受信が終了するかわからない。よって、そのような可変シンボル長に柔軟に対応できるような復号処理を行う必要がある。
【０３１２】
一般的には、エラーがのった受信シンボルは式（３４）で、エラーフリーの場合の受信シンボルは式（３５）で夫々表されるが、以下では、図５にある具体例を用いて説明する。
【０３１３】
まず、図５（ｂ）についてみると、全てのシンボルが正しく受信できたときの受信系列Ｃは、

であり、そのうちＣ［３］、Ｃ［２］、Ｃ［１］、Ｃ［０］は冗長シンボルである。これを多項式表現すると、

となる。この例では９つのシンボルを受信するが、実際には最大１２８シンボルまで受信することがあり得る。これらのシンボルのそれぞれについて、何番目のシンボルがどこの列に属するか（すなわち式（６５）を作成するにあたって、各シンボルに対応するＸのべき乗の値は何であるか）といった一覧表を、送信側と同様に保持している必要がある。
【０３１４】
さて、式（６５）のシンボルのうち、最大４つのシンボルがエラーを起こしているとする。ただし、冗長シンボルのみのエラーである場合は、誤り訂正処理を行わないので、ここでは、少なくとも１つのエラーシンボルは、データ領域に属するシンボルであるとする。
【０３１５】
受信側ＦＥＣ処理方法１、２と同様にエラー数に応じて、シンドロームＳ［ｉ］の計算を行う。エラーシンボル数と同じだけのシンドロームの計算を行えば、誤り訂正が可能である。シンドロームの計算は、
手順１：Ｓ［ｉ］＝０ （ｉ＝１，２，３，４）とおく。
【０３１６】
手順２：受信シンボルに応じて、以下の計算を行う。
【０３１７】

手順３：最後のシンボルが終了すると、その時のＳ［ｉ］（ｉ＝１，２，３，４）が求めるシンドロームの値である。
【０３１８】
手順２において、ｆ（ｋ）はＣ［ｋ］と対になる、多項式上のべき乗数を示す。例えば図５（ｂ）において、Ｃ［８］に相当するべき乗数はｆ（８）＝６である。
【０３１９】
上記演算により得られるＳ［ｉ］（ｉ＝１，２，３，４）の別の表現は、式（４５）の変形で与えられる。誤りのあるシンボルの訂正後の値をＣ［ｍ−ｋ］（ｋ＝ｓ，ｔ，ｖ，ｕ）とすると、本実施例の具体例では、ｍ＝８なので、

となる。
【０３２０】
式（６６）と式（６７）から、４次の連立方程式ができ、これからＣ［８−ｋ］（ｋ＝ｓ，ｔ，ｕ，ｖ）の値を求めることができる。エラーシンボルが４つあるときの解は、それぞれ

となる。
【０３２１】
式（６７）において、エラーシンボルがもし１つ（ｓ番目）のみであれば、上式は、

であり、これから、

となる。これは、ｉの値によらず同じなので、どれか１つを計算すればよい。とすると、例えばＳ［１］ のみ計算すればよく、他のシンドロームに対する計算を行わずに済むことになる。
【０３２２】
また、もしエラーシンボルが２つ（ｓ番目とｔ番目）であれば、式（６７）は、

となる。これも２つのシンドローム、例えばＳ［１］とＳ［２］のみを計算すればよく、他のシンドロームに対する演算を行わずに済むことになる。
【０３２３】
そして、解は、

となる。
【０３２４】
また、エラーシンボルが３つ（ｓ番目とｔ番目とｕ番目）であるとき、式（６７）は、

となり、この場合は３つのシンドローム、例えばＳ［１］、Ｓ［２］、Ｓ［３］のみを計算すればよい。すなわちＳ［４］の演算を必要とせずに済む。
【０３２５】
このときの解は、

となる。
【０３２６】
これらの演算には、αのべき乗の計算が多数必要となる。常に出てくる演算（例えばα＾１２０等）に関しては、表を作っておくと高速化を図ることができる。
【０３２７】
次に、図５（ａ）の場合を説明する。これは基本的に図５（ｂ）と同じであるので、図に示した具体例のみを説明することとする。
【０３２８】
図５（ａ）の場合は、受信側でも送信側と同じ表２を持っていて、シンボル到着の度に、そのシンボルがデインタリーバのどの位置にくるのかを把握しておく必要がある。ここでも、送信側と同じく上から４行目を例にとり、この行がもし全くエラーがないとすると、受信シンボルを使った多項式は、式（３２）から

と表される。本来は、何番目のシンボルまで受信するかは、あらかじめ送信側から知らされることはなく、ＣＰＣＳ−ＰＤＵの終わりを検出することによって、初めて知ることになる。
【０３２９】
この場合も、最大４シンボルのエラーを想定する。シンドロームの計算方法は、式（６６）にある手順と全く同じである。ただし、ｋの値は式（７５）にあるＣ［ｋ］から取り出されているので、ランダムな値をとる。そして、ｆ（ｋ）は式（７５）において、そのｋの値に対するＣ［ｋ］を係数とするＸの次数を表す。例えば、ｋ＝１に対して、ｆ（１）＝７である。
【０３３０】
エラーがある場合のシンドロームの値は０にはならず、式（６７）にならって記述すると、

となる。ただし、０＜ｓ＜ｔ＜ｕ＜ｖであり、｛ｓ，ｔ，ｕ，ｖ∈ｋ｜ｋは４行目に属するシンボル番号｝であるとする。そして、ｓ，ｔ，ｕ，ｖ番目のシンボルにエラーが発生しているとする。また、Ｃ［ｋ］（ｋ＝ｓ，ｔ，ｕ，ｖ）は、それぞれのシンボルの訂正後の値を意味する。
【０３３１】
式（６６）と式（７６）を解くことによって、訂正後のシンボル値が計算できる。まず、４つのエラーがある場合は、

となる。
【０３３２】
式（６７）において、エラーシンボルがもし１つ（ｓ番目）のみであれば、上式は、

であり、これから、

となる。これはｉの値によらず同じなので、どれか１つを計算すればよい。とすると、例えばＳ［１］のみ計算すればよく、他のシンドローム計算を行う必要がないので、その分の演算量を減らすことができる。
【０３３３】
また、もしエラーシンボルが２つ（ｓ番目とｔ番目）であれば、式（６７）は

となる。これも２つのシンドローム、例えばＳ［１］とＳ［２］のみを計算すればよく、他のシンドロームに対する演算を行わなくて済む。
【０３３４】
そして、解は、

となる。
【０３３５】
また、エラーシンボルが３つ（ｓ番目とｔ番目とｕ番目）であるとき、式（６７）は、

となり、この場合は３つのシンドローム、例えばＳ［１］、Ｓ［２］、Ｓ［３］のみを計算すればよい。すなわちＳ［４］の演算を行わなくて済む。
【０３３６】
このときの解は、

となる。
【０３３７】
本実施例では、データの信頼性を保証するためのプロトコルとしてはＡＡＬタイプ５のＳＳＣＳレイヤのＦＥＣ処理以外を想定していない。しかしながら、実際にはＦＥＣの能力には限界があり、一定数以上セルが廃棄された場合にはもはやＦＥＣによる誤り訂正は不可能となってしまう。このような状況では再送による誤り訂正を行なうしかなく、そのためには予めＳＳＣＳレイヤのＦＥＣによる誤り訂正の他に上位レイヤにライトウェイトな再送制御を実装しなければならない。ＦＥＣで訂正できない場合、元のデータを得るには再送を行なうしかないので、本実施例では、ＳＳＣＳの上位にライトウェイトな再送制御のためのプロトコルは実装していると想定している。また、予めＡＴＭ網の状態をみて誤りの多く発生する状態であれば能力の高いＦＥＣ用符号を用いる、またほとんど誤りの発生しない状態であれば軽いＦＥＣ符号を用いるなど、パラメータを選択した上で通信を開始できる。
【０３３８】
なお、前述のように、本実施例ではＡＡＬタイプ５に関するものについて説明したが、本発明の誤り訂正方法はデータ転送に限定されるものではなく、同様の方法で他のタイプにも適用可能である。
【０３３９】
逆に、例えば、ＡＡＬ５機能のみが実装された端末装置において、該端末装置がマルチメディア／コンティニュアスメディア処理機能（音声、動画等）を持っていれば、この様なアプリケーションを実現する場合にＡＡＬ５の処理機能に本実施例の誤り制御方式を併用させることによって柔軟に対処し様々な状況で様々なデータの信頼性を保証することができるのである。
【０３４０】
（第２の実施例）
次に、第２の実施例を説明する。第１の実施例は、１対１の端末が通信を行なう場合の例であったが、第２の実施例では、１対多通信の場合について説明する。
【０３４１】
本実施例では、図２４に示すように、１台の送信側端末２ｔが、複数台の受信側端末２ｒ（２ｒ−１〜２ｒ−ｎ）に対して通信を行なっているものとする。なお、図中の受信側端末２ｒのいずれか複数個が受信側端末かつ送信側端末となり、同じようなコネクションを張り同じように１対多通信を行なうことによって多対多通信を実現することもできるが、このような場合にも、本発明を適用することが可能である。
【０３４２】
以下、ＦＥＣを付与しマルチキャストを行なう場合の例について説明する。
【０３４３】
図２５は、本実施例の送受信端末のプロトコルスタックの一例である。基本的な構成は、第１の実施例のプロトコルスタックとほぼ同様である。図１と異なる点は、本実施例では、いずれかのレイヤにマルチキャスト機能を提供する能力のあるプロトコルが必要になることである。
【０３４４】
一般的に広く知られたマルチキャスト機能を提供できるプロトコルとしては、マルチキャストＩＰアドレスを使ったＩＰ転送などがある。現状のシステムでは、ＩＰマルチキャストを行なう場合に、その上位レイヤプロトコルとしてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｃｏｌ）が用いられるのが通常である。ＵＤＰはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｃｏｌ）と異なり、エンド−エンドに信頼性の保証を行なわないプロトコルであるので、転送途中でパケットが廃棄されても、ビット誤り等が生じても、訂正は行なわない。しかしながら、ここで転送しようとしているアプリケーションデータはマルチメディアで放送形態をとるデジタルメディアを想定しているので、ＩＰ＋ＵＤＰのようなデータの信頼性を保証しないプロトコルでは不都合である。そこで、本実施例では、ＭＴＰ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）やＲＭＰ（Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ）をレイヤ４のプロトコルとした。しかし、本発明のＦＥＣを実装している場合には、信頼性の保証を上位レイヤによる再送で行なう必要性がかなり少なくなる。
【０３４５】
ＭＴＰは、ＩＰでマルチキャストを行なう場合、転送途中に生じた誤りを訂正する機能を持ったプロトコルである。現在はインターネットドラフトのＲＦＣ１３０１に実現の方法に関する詳細が記述されている。該ドラフトの誤り訂正の方法とは、受信者による再送要求により送信者がデータを再送するという方法である。ＲＭＰは、カリフォルニア大学バークレイ校のＢ．Ｗｅｔｔｅｎらにより提案されたものであり、ＭＴＰとほぼ同様の動作及び機能を持ったプロトコルである。しかし、両者ともＣＳＣＷなどをアプリケーションとすることを前提としているので、リアルタイム性の保証は行なっていない。
【０３４６】
しかしながら、例で挙げたようなアプリケーションを実現するにはリアルタイム性の保持を行なう必要がある。その場合には、受信者が誤りを検出してから送信者に対して再送要求を行なっていたのでは、遅延が許容範囲を越えてしまう可能性が高い。このような場合にも、前述した第１の実施例のように、転送するデータに予め誤り訂正を行なうための冗長な符号を付与しておくことによって、上記のような問題点を解消できるのである。
【０３４７】
さて、ＩＰのような上位レイヤで提供されるマルチキャストは、ＡＴＭレベルでは図２５のようにスイッチ３のコピー機能などを用いて実現される。また、コネクションの張り方としては、主に以下の２通りが考えられる。
【０３４８】
（１）送信側端末から全ての受信側端末に対してポイント−マルチポイントのＡＴＭコネクションを張る。
【０３４９】
（２）送信側端末から一部の受信側端末と一部の中継サーバに対してポイント−マルチポイントのＡＴＭコネクションを張る。中継サーバよりも（マルチキャストツリー内で）下流の受信側端末と中継サーバに関しては、該中継サーバが担当する。中継サーバとは、物理的または論理的にネットワークやサブネットを接続しているような装置を指し、ＡＡＬよりも上位のレイヤでコネクションを一度終端することもある。
【０３５０】
上記２の例を図２６に示す。Ｈは送信側端末（２ｔ）、Ｈ１〜Ｈ２５は受信側端末（２ｒ）、Ｓ１〜Ｓ５は中継サーバである。ネットワーク１−１〜１−７は、ＡＴＭ網である。図２６のように、送信側端末Ｈから受信側端末Ｈ１、Ｈ２、および中継サーバＳ１、Ｓ２、Ｓ３に対して、コネクションを設定し、中継サーバＳ１、Ｓ２、Ｓ３は、それぞれの下流に位置するＡＴＭ網１−２，１−３，１−４内のマルチキャストグループに属する受信側端末やさらに下流にメンバーが存在する中継サーバに対して同じようにコネクションを張る。
【０３５１】
上記１の方法は，受信側端末の総数が比較的少ない場合には適切な方法である。これに対して、上記２の方法は受信側端末の総数がかなり多い場合でも、階層的に下流の中継サーバにコネクションを一度終端させることで、広域に渡るマルチキャストが実現できる方法である。
【０３５２】
次に、送信側端末２ｔおよび受信側端末２ｒを説明する。図２７に、本実施例の送信側端末２ｔおよび受信側端末２ｒの内部構成を示す。本実施例の送信側端末２ｔおよび受信側端末２ｒの内部構成は、基本的には、第１の実施例とほぼ同様である。したがって、以下では、本実施例の送信側端末２ｔおよび受信側端末２ｒについて、第１の実施例との相違点を中心として説明する。なお、ここでも、ＡＡＬとしてタイプ５を例にあげる。
【０３５３】
まず、送信側端末２ｔのアプリケーション処理モジュール１０４ｔ、ＭＴＰ／ＲＭＰ処理を行うＭＴＰ／ＲＭＰ処理モジュール１３０ｔ、ＩＰ処理を行うＩＰ処理モジュール１３１ｔでは、マルチキャストしたい送信側端末２ｒに対して、それぞれのプロトコルに特有な処理が行なわれる。データの種類としては、動画、音声、テキストデータなどＡＴＭの特徴を活かして様々なメディアを転送するが、ここまでの処理は、本発明に限られた方法ではない。
【０３５４】
次に、ＳＳＣＳ処理モジュール１０６ｔ、ＣＰＣＳ処理モジュール１１４ｔ、ＳＡＲ処理モジュール１２０ｔでは、第１の実施例で説明したものと同様の処理が施される。
【０３５５】
ただし、ＦＥＣを行なうＳＳＣＳレイヤで、上位レイヤに対してエラーフリーな通信を提供する場合、そのためには、ＳＳＣＳレイヤ以下のレイヤでトランスペアレント（透過的）なデータの受渡しが可能であることが必要となる。というのは、送信側のＳＳＣＳレイヤのエンティティに対して、受信側のＳＳＣＳレイヤのエンティティから再送要求が送られた場合に、セル単位の再送を行なうためには、ＳＳＣＳレイヤで、個々のセルの識別ができることが必須になるからである。例えば、ＳＳＣＳレイヤでセル単位の再送を行なう場合、再送要求、あるいは再送に関係あるデータはＳＳＣＳレイヤよりも下のレイヤではトランスペアレントに受渡しされなければならない。これらは、受信側端末２ｒの処理の説明において詳しく述べる。ＳＳＣＳレイヤ以下に関しても、第１の実施例と同様の処理が行なわれる。
【０３５６】
次に、受信側端末２ｒについて説明する。
【０３５７】
マルチキャストを行なう場合には、多くの宛先に対してメッセージを送信するため、いずれかの受信側端末２ｒで正しくデータを受信できない可能性が高くなる。言い換えると、送信側にいずれかの送信側端末２ｔから再送要求が送られる確率が高くなる。しかし、本発明によれば、予めＦＥＣを付与するレイヤ（ＡＡＬ５の場合であればＳＳＣＳレイヤ）に、データの信頼性を保証する機能を持たせることで、その確率を激減させることができるのである。
【０３５８】
受信側端末２ｒでの誤り検出は、まず、ＣＰＣＳ処理モジュール１１４ｒで行なわれる。その際、誤りが検出されなければ、第１の実施例で示したように、ＳＳＣＳ処理モジュール１０６ｒを省略して上位レイヤにデータを渡す方法も可能である。その場合には、送信側で付与したＦＥＣ冗長符号のオーバーヘッド程度ですみ、スループット、レイテンシイは、ＡＡＬ５にかなり近い性能を得ることができる。
【０３５９】
前述したように、マルチキャストの場合、ＩＰレベルでマルチキャストグループに該当する複数のＩＰアドレスに対してデータグラムを送出するので、一般的なＩＰマルチキャストでは、送信側端末２ｔで再送要求を受けとる確率がポイント−ポイントの場合よりも大きい。マルチキャストグループに属する端末数が大きければ大きいほどその確率は大きくなる。例えば、受信側端末数が１０＾４、データリンクの誤り率が無線程度に大きい場合には、１に近い確率で送信側端末２ｔは再送要求を受けとる。
【０３６０】
誤りのレベルとしては、大きく２種類に分けられる。
（１）予め付与した誤り訂正符号（ＦＥＣコード）により訂正可能な程度である場合
（２）上記１のレベルを上回り、ＦＥＣコードによる訂正が不可能、よって、再送以外に訂正は無理である場合
もちろん、上記１の場合には、第１の実施例の１対１通信の場合と同様に誤り訂正を行なって、正しいデータを上位レイヤに渡すことができる。
【０３６１】
しかしながら、上記２のケースが発生した場合には再送により誤りを訂正しなければならず、その方法としては以下のような候補がある。
Ａ）ＡＡＬよりも上位レイヤで再送制御を行なう（例えば、図２５のレイヤ４に相当するＭＴＰ／ＲＭＰ等）。
Ｂ）ＡＡＬのいずれかのレイヤで再送制御を行なう。
【０３６２】
上記Ａのケースでは、それぞれの再送プロトコルの手順にしたがって誤り訂正が行なわれるので、第１の実施例で説明した手順をもちることができるが、上記Ｂの方法で再送制御を行なうには、第１の実施例で説明した手順に加え、いくつかの処理が必要になる。以下、上記２のようなレベルの誤りが生じ、それを上記Ｂのような方法で誤り回復をはかろうとした場合の手順について説明する。
【０３６３】
ＦＥＣの訂正能力を上回るような誤りが転送中に生じた場合に、ＳＳＣＳレイヤで信頼性保証のために再送制御を行なう方法について説明する。再送制御を行なうとすると、再送の単位は様々な方法が可能である。
１）ＡＴＭレイヤレベルのセル再送
２）ＣＰＣＳ−ＰＤＵを単位とする再送
３）ＳＳＣＳ−ＰＤＵ（インタリーバ）を単位とする再送
４）ＳＳＣＳ−ＰＤＵ（インタリーバ）内の列（任意の列数）を単位とする再送
５）レイヤ３以上のパケットを単位とする再送
ここでは、一例として、マルチキャストを行う場合で、かつ、上記３）のＳＳＣＳ−ＰＤＵ（インタリーバ）内の列（任意の列数）を単位として再送により誤り訂正を行なうケースについて述べる。
【０３６４】
第１の実施例で述べたように、送信側端末２ｔのＳＳＣＳ処理モジュール１０６ｔでは、セル単位にＳＮを含むＳＳＣＳヘッダが付与されている。受信側端末２ｒのＳＳＣＳ処理モジュール１０６ｒでは、このＳＳＣＳヘッダに従ってセル廃棄されたセルを特定するのである。これ以前で、何らかの誤りが生じているという事実は、ＣＰＣＳレイヤのＣＲＣにより検出済みである。検出した誤りが広範囲に及んでおり、送信時に付与されたＦＥＣの訂正能力を越えている場合には、送信側のＳＳＣＳレイヤに対して、再送要求を出す。再送要求のメッセージは、マルチキャストグループのメンバーである受信側端末のいずれかから送られることが予想され、その台数はわからない。１台だけかも知れないし、または数台から送られることもある。
【０３６５】
例えば、受信側端末２ｒ−１のみが訂正能力以上の誤りを検出した場合、送信側端末２ｔのＳＳＣＳ処理モジュール１０６ｔに対して、受信側端末２ｒ−１は少なくとも自分のアドレス、またはマルチキャストアドレス、再送して欲しいセルのＳＮを送ることによって誤り訂正を実現する（図２８参照）。
【０３６６】
受信側端末２ｒ−１が送信した再送要求は、送信側端末２ｔのＳＳＣＳ処理モジュール１０６ｔに届けられる。送信側端末２ｔでは再送要求メッセージの内容に応じて、それに対応するＳＮを持つセルを再送する。その際、マルチキャストコネクションとは別に設定されたポイント−ポイントコネクションを利用して、再送要求を送信した受信側端末にのみ再送データを送信しても構わないし、再度マルチキャストを行なっても構わない。
【０３６７】
廃棄されたセルをＳＳＣＳ−ＰＤＵ内のどの列に対応するかということをＳＮから特定できても、この例ではＡＡＬ５を前提としているので、通常、その廃棄されたセルのみを転送することはできない。ＡＡＬ５のトレイラが付与され、１セル分の実データでも２セル分のＡＡＬ−ＰＤＵとなってしまう。再送データを転送する方法としては、以下のようなものが可能である。
（１）実データを独立したインタリーバに格納し直して、新たにＦＥＣを付与し、独立したＡＡＬ−ＰＤＵとして送出する。この場合は、廃棄された時のＳＮも新たなＳＳＣＳヘッダ／トレイラに記す必要がある。
（２）ＡＡＬをヌルにして送出する。ＳＳＣＳヘッダ／トレイラは以前のものを付与する。
（３）再送要求を受けとった時点で、その時、またはその次に転送するインタリーバの最初または最後に含ませてしまう。他のデータと混ざらないように、再送データであることの表示が必要。
【０３６８】
また、上記の方法での、再送の宛先としては、以下のそれぞれがある。
Ａ）マルチキャストグループに属する全ての受信側端末（マルチキャストによって転送する）
Ｂ）再送要求を送ってきた受信側端末のみ（何らかの方法でポイント−ポイントのコネクションを設定する必要がある）
Ｃ）再送用のコネクションを個々の受信側端末に対して予め張っておいて、再送要求を送ってきた受信側端末に対してのみ再送する。ＳＳＣＳヘッダ／トレイラは以前のものを付与する。
Ｄ）マルチキャストグループ内の一部
上記１の場合には、廃棄されたセル数が小さいと、ＦＥＣコードの冗長性が高くなってしまう可能性がある。
【０３６９】
上記２の場合には、最小限のデータ量を網に送出することになりオーバーヘッドが小さい。
【０３７０】
上記Ａのように、マルチキャストで再送データを送出すると、特定の受信側端末だけにコネクションを張り直すという処理を送信側端末が行なわなくて済むという利点がある。
【０３７１】
マルチキャストデータに再送セルを含ませる場合、受信したデータが再送データであるという識別は、ＳＳＣＳヘッダ／トレイラに再送データであることを示すビットを立てるようにすれば良い。すでに正しく受信できている場合には受信側のＳＳＣＳ処理モジュール１０６ｒで廃棄してしまえば良いので実現は比較的簡単である。
【０３７２】
図１８のＳＳＣＳヘッダ／トレイラの例にはそのようなフィールドがなく、ＳＳＣＳレイヤでエラーフリーな通信を提供する場合には、図２９のように拡張したＳＳＣＳヘッダ／トレイラが通常の転送時から必要になる。
【０３７３】
（１）は、図１８では１バイトであったＳＳＣＳヘッダ／トレイラに、再送データであることを表示するフィールドを１ビット付加した。
【０３７４】
（２）は、バイト単位が望ましいという見地から、ＳＳＣＳヘッダ／トレイラのＳＮをより大きな値までとれるようにし、インタリーバ内のデータ領域と冗長コードの領域がより確実に識別できるようフィールドを増やした。
【０３７５】
（３）は、（２）とは逆に、ＳＮフィールドを小さくすることによって１バイトのＳＳＣＳヘッダ／トレイラ内に再送データ表示フィールドを１ビット設けた。
【０３７６】
再送セル数は、ＦＥＣの訂正能力に依存して減らすことが可能である。例えば、ＦＥＣの訂正能力が１２８セル中４セルだった場合、再送要求で８個のセルを再送するようにリクエストされたとする。このＦＥＣコードでは４セル以内の廃棄ならば訂正できるので、再送するセル数は少なくとも４セル送ってやれば済む。このように、最小限のセルを送ることによって、網の輻輳を引き起こさないように防止することができる。このような利点も、ＦＥＣを用いている場合の特徴の一つである。
【０３７７】
次に、送信側端末に複数の受信側端末から再送要求が送られてきた場合について説明する。ここでは、ＦＥＣの訂正能力としては、１インタリーバのサイズが１６セル、その内、１セルまでの訂正が可能なコードであるものとして説明する。
【０３７８】
廃棄されたセルを全て再送する方法の他に、次のようにして再送セルの数を削減できる方法がある。
【０３７９】
図３０のように、受信側端末２ｒ−１，２ｒ−３から各々次のようなセルの再送要求が送信側端末２ｔのＳＳＣＳ処理モジュール１０６ｔに到着したとする。
受信側端末２ｒ−１→セルのＳＮ…１，２，３
受信側端末２ｒ−３→セルのＳＮ…２，３，４
どの受信側端末で、どのセルが廃棄されたのかが、送信側端末で上記のように特定できた場合、その後の処理として以下のような方法がある。
（１）受信側端末が受信できなかったセルのＳＮを全て再送する。
（２）ＦＦＣの能力に応じて復号に必要な最小限のセルを再送する
ここでもそれぞれ、マルチキャストで送る方法と、ポイント−ポイントで送る方法がある。
【０３８０】
上記の廃棄されたセルのＳＮを比較すると、２と３が共通であることがわかる。上記２の方法に従えば、それぞれの受信側端末で３セルずつ廃棄が生じているので、それぞれ、あと２セルずつ正しく受信できれば、残りの１セルはＦＥＣ符号により回復することができる。よって、前で説明したように最小限のセルを再送する、というポリシーに基づいて、送信側端末２ｔは、受信側端末２ｒ−１，２ｒ−３に対して共通の廃棄セルであるＳＮ＝２，３を送信するという方法がとれる。もちろん、受信側端末２ｒ−１に対してＳＮ＝１，２，３のセル、受信側端末２ｒ−３に対してＳＮ＝２，３，４のセルと、個々に最小限のセルを送ることもできる。しかし、マルチキャストグループ内の特定の端末に対して再送を行なう場合には、先にも述べたが対応するポイント−ポイントのコネクションが必要になる。
【０３８１】
送信先は、前述した例と同様に、受信側端末２ｒ−１，２ｒ−３に限ることもできるし、再度マルチキャストによってこれらの２セルのみ、またはＳＮ＝１，２，３，４，の４個のセルを送ることもできる。
【０３８２】
マルチキャストによる場合、すでに正しく復号されている受信側端末ではデータが再送セルであることをＳＳＣＳレイヤで検出することができるのでそのセルは廃棄することができる。よって、重複して別のデータに混入してしまって、影響を及ぼす恐れはない。
【０３８３】
この時の再送セルもオーバーヘッドを最小限にするために、再送セルのみをＣＰＣＳ−ＳＤＵにせず、ＳＳＣＳレイヤのレベルで別のインタリーバに挿入してしまうことが可能である。
【０３８４】
マルチキャストグループ内の特定の受信側端末（ここでは受信側端末２ｒ−１，２ｒ−３）にだけデータを送るようにするには、送信側端末か、もしくは送信側端末と受信側端末の中継点で特定の受信側端末にだけコネクションを設定して必要最小限のセルのみを転送するという方法が考えられる。
【０３８５】
以上の例では、セル廃棄を検出した受信側が再送要求を出すという、Ｎｅｇａｔｉｖｅ ＡＣＫ（否定的な応答確認）を用いた方法であったが、Ｐｏｓｉｔｉｖｅ ＡＣＫ（肯定的な応答確認）を用いる方法もとることができる。
【０３８６】
このような場合には、送信側端末２ｔがマルチキャストデータを送信後、ＳＳＣＳ処理モジュール１０６ｔでタイマを起動して、マルチキャストグループの全ての受信側端末２ｒからＡＣＫが返ってくるのを待つ。ＡＣＫには、受信側端末２ｒのアドレス、受信できたデータの識別子などが記されている。
【０３８７】
タイマの上限値の設定は、ラウンドトリップタイムに応じて設定される。このタイマの上限値を越えてもＡＣＫが返ってこない場合には、その返事のない受信側端末に対してそれに応じたデータを再送する。この再送の方法は、今まで述べてきた方法と同様である。
【０３８８】
このデータ送出のメカニズムはＴＣＰのウィンドウ制御によく似ている方法であり、同じようにスライディングウィンドウを用いることもできる。ただし、マルチキャストという環境下でＰｏｓｉｔｉｖｅ ＡＣＫを用いているので、全ての受信側端末２ｒからＡＣＫが返ってこないとそれに対応するデータは再送用のメモリから排除できなくなってしまう。よって、ＡＣＫが経路の途中の輻輳を起こしているノード等で送れてしまっている時には、送信者は次のデータを送出できないという状況に陥ってしまい、スループットの低下が起こる可能性もある。
【０３８９】
受信側のＡＡＬより上位のレイヤには、ＳＳＣＳレイヤでのＦＥＣと再送による誤り制御の効果で、エラーフリーな正しいデータが渡されることになる。その後は、レイヤ３，４の通常の処理が行なわれ、アプリケーションレイヤにはもちろん正しいデータが届けられる。
【０３９０】
受信側の説明に含めて、再送時の送信側の説明を述べた。このように行なうことで、マルチキャストを行なっている時に、ＦＥＣの能力を越えてしまうほどの誤りが転送中に生じても、最小限のオーバーヘッドと遅延でサービスを提供できる。
【０３９１】
上記したように送受信側端末の処理を行なうことで、ＡＡＬレベルにエラーフリーな通信を提供することが可能である。マルチキャストを行なう場合は、受信側端末の数が大きければ大きいほど、いずれかの受信側端末から送信側端末に対して再送要求が生じる可能性が高い。しかし、ＡＡＬレベルにＦＥＣ機能を持たせ、さらに、再送による誤り訂正を提供することによって、信頼性が高く、リアルタイム性のより保証されたシステムを構築することができる。
【０３９２】
以上、各実施例にて説明したように、本発明によれば、ＡＴＭ通信網で高速通信を行う場合に、ＡＡＬのいずれかのレイヤにインタリーバとＦＥＣを用いた誤り制御方法を実装し、さらに、インタリーバのサイズを柔軟にアプリケーションデータのサイズに合わせることによってデータ転送の高効率化、高速化、省資源化を図ることができる。特に、ＡＡＬタイプ５で高速データ転送を行う場合には、ＣＰＣＳよりも上位のレイヤに本発明の誤り制御方法を適用することによって、本来ＦＥＣが持つオーバーヘッドを最小限に抑えつつ、ＡＡＬタイプ５の高速性を最大限に発揮することが可能となる。また、ＡＡＬ１、２、３／４に対しても、より高効率にＦＥＣを実装することが可能である。
【０３９３】
また、本発明は、上述した各実施例に限定されるものではなく、その要旨を逸脱しない範囲で、種々変形して実施することができる。
【０３９４】
【発明の効果】
本発明によれば、信頼性の高いデータ通信を効果的に実現することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施例の送受信端末のプロトコルスタックの構造を示す図
【図２】送信側端末２ｔおよび受信側端末２ｒの内部構成を示す図
【図３】ＡＡＬ−ＩＤＵとして上位から渡されるアプリケーションデータを示す図
【図４】インタリーバへのアプリケーションデータの書き込みの様子を示す図
【図５】インタリーバへの書き込み順序の例を示す図
【図６】４オクテット単位でデータ長のアライメントをとる場合の様子を示す図
【図７】インタリーバにデータを格納した様子を示す図
【図８】他のインタリーバにデータを格納した様子を示す図
【図９】図８の場合の処理の流れを説明するための図
【図１０】図７および図８の場合のＬＩフィールドの例を示す図
【図１１】インタリーバからのデータの読み出しの例を示す図
【図１２】ＦＥＣ冗長コードの付与の例を示す図
【図１３】データ領域内の最終列の長さ表示の例を示す図
【図１４】図１３のＦＥＣ演算の立場から見たマトリクスの状態を示す図
【図１５】マトリクスの１ラインの符号語構成の例を示す図
【図１６】データ領域にダミーを入れる場合のインタリーバの状態を示す図
【図１７】ＳＳＣＳヘッダ／トレイラを付与する単位を示す図
【図１８】ＳＳＣＳヘッダ／トレイラの一例の図
【図１９】インタリーバ１つに対するＳＳＣＳヘッダ／トレイラを示す図
【図２０】ＵＵＩ＝１を含むセルが廃棄された場合の受信側でのレイヤ処理を説明するための図
【図２１】図８の場合の処理の流れを説明するための図
【図２２】モジュロ値のテーブルを示す図
【図２３】冗長シンボルのテーブルを示す図
【図２４】本発明の第２の実施例における１対多通信の形態を示す図
【図２５】同実施例の送受信端末のプロトコルスタックの構造を示す図
【図２６】ＡＴＭコネクションの張り方を説明するための図
【図２７】送信側端末２ｔおよび受信側端末２ｒの内部構成を示す図
【図２８】受信端末２ｒ−１において再送要求が出された場合について説明するための図
【図２９】ＳＳＣＳヘッダ／トレイラの例を示す図
【図３０】複数の端末から再送要求が送られた場合について説明するための図
【図３１】ＡＴＭアダプテーションレイヤを説明するための図
【符号の説明】
１…ＡＴＭ網、３…ＡＴＭ交換機、２ｔ…送信側端末、２ｒ…受信側端末、４ｔ…アプリケーション処理モジュール、４ｒ…アプリケーション処理モジュール、６ｔ…ＳＳＣＳ処理モジュール、６ｒ…ＳＳＣＳ処理モジュール、８ｔ…インタリーバモジュール、８ｒ…デインタリーバモジュール、１０ｔ…ＦＥＣ付与モジュール、１０ｒ…ＦＥＣ訂正モジュール、１２ｔ…ＳＳＣＳヘッダ／トレイラ付与モジュール、１２ｒ…ＳＳＣＳヘッダ／トレイラ確認モジュール、１４ｔ…ＣＰＣＳ処理モジュール、１４ｒ…ＣＰＣＳ処理モジュール、１６ｔ…ＬＩ付与モジュール、１６ｒ…ＬＩ確認モジュール、１８ｔ…ＣＲＣ付与モジュール、１８ｒ…ＣＲＣ確認モジュール、２０ｔ…ＳＡＲ処理モジュール（セグメンテーション）、２０ｒ…ＳＡＲ処理モジュール（リアセンブリ）、２２ｔ…ＡＴＭヘッダ付与モジュール、２２ｒ…ＡＴＭヘッダ削除モジュール、１−１〜１−７…ＡＴＭ網、２ｒ−１〜２ｒ−５…受信側端末、３０…マルチキャストサーバ、１０４ｔ…アプリケーション処理モジュール、１０４ｒ…アプリケーション処理モジュール、１３０ｔ…ＭＴＰ／ＲＭＰ処理モジュール、１３０ｒ…ＭＴＰ／ＲＭＰ処理モジュール、１３１ｔ…ＩＰ処理モジュール、１３１ｒ…ＩＰ処理モジュール、１０６ｔ…ＳＳＣＳ処理モジュール、１０６ｒ…ＳＳＣＳ処理モジュール、１１４ｔ…ＣＰＣＳ処理モジュール、１１４ｒ…ＣＰＣＳ処理モジュール、１２０ｔ…ＳＡＲ処理モジュール、１２０ｒ…ＳＡＲ処理モジュール、１２２ｔ…ＡＴＭヘッダ処理モジュール、１２２ｒ…ＡＴＭヘッダ処理モジュール、Ｈ…送信側端末、Ｈ１〜Ｈ２５…受信側端末、Ｓ１〜Ｓ５…中継サーバ

Claims (4)

1. ＦＥＣによる誤り訂正機能および再送による誤り訂正機能を用いた通信におけるデータ再送制御方法であって、
   送信端末において、受信端末から、該受信端末にてＦＥＣによる誤り訂正機能によっては訂正できない誤りを伴って受信された誤りのある通信データに対する再送を要求する再送要求を受信する第１の手順と、
   前記第１の手順にて受信された前記再送要求およびＦＥＣによる前記誤り訂正機能の誤り訂正能力に基づいて、前記誤りのある通信データを、前記ＦＥＣによる誤り訂正機能および前記再送による誤り訂正機能を用いることによってリカバーするのに必要な再送データの最小量を決定する第２の手順と、
   前記第２の手順にて決定された前記最小量の再送データを、前記送信端末から前記受信端末へ再送する第３の手順とを有することを特徴とするデータ再送制御方法。
2. 前記通信は、前記送信端末から複数の受信端末へのマルチキャスト通信であり、
   前記第１の手順では、送信端末において、少なくとも一つの受信端末から前記再送要求を受信し、
   前記第３の手順では、前記最小量の再送データを、前記送信端末から前記少なくとも一つの受信端末へ再送することを特徴とする請求項１に記載のデータ再送制御方法。
3. ＦＥＣによる誤り訂正機能および再送による誤り訂正機能を用いた通信におけるデータ再送制御システムであって、
   送信端末において、受信端末から、該受信端末にてＦＥＣによる誤り訂正機能によっては訂正できない誤りを伴って受信された誤りのある通信データに対する再送を要求する再送要求を受信する第１の手段と、
   前記第１の手段にて受信された前記再送要求およびＦＥＣによる前記誤り訂正機能の誤り訂正能力に基づいて、前記誤りのある通信データを、前記ＦＥＣによる誤り訂正機能および前記再送による誤り訂正機能を用いることによってリカバーするのに必要な再送データの最小量を決定する第２の手段と、
   前記第２の手段にて決定された前記最小量の再送データを、前記送信端末から前記受信端末へ再送する第３の手段とを有することを特徴とするデータ再送制御システム。
4. 前記通信は、前記送信端末から複数の受信端末へのマルチキャスト通信であり、
   前記第１の手段では、送信端末において、少なくとも一つの受信端末から前記再送要求を受信し、
   前記第３の手段では、前記最小量の再送データを、前記送信端末から前記少なくとも一つの受信端末へ再送することを特徴とする請求項３に記載のデータ再送制御システム。

Images