JPH0787099A

JPH0787099A - Ａｔｍ網における誤り制御方法

Info

Publication number: JPH0787099A
Application number: JP5229240A
Authority: JP
Inventors: Kumiko Kanai; 久美子金井; Takeshi Saito; 健斉藤; Keiji Tsunoda; 啓治角田
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1993-09-14
Filing date: 1993-09-14
Publication date: 1995-03-31

Abstract

(57)【要約】【目的】ＡＡＬタイプ５において高スループットかつ
低レイテンシの信頼性のあるデータ通信を可能とする誤
り制御方法を提供することを目的とする。【構成】本発明は、ＡＡＬタイプ５のＣＰＣＳレイヤ
ーよりも上位のレイヤにて行うＡＴＭ網における誤り制
御方法であって、送信しようとする一続きのデータ列を
一定の長さに順次区切り、それらの先頭を揃えて行方向
に並べるとともに、この区切られた一群のデータごとに
所定の誤り制御符号を付加する手順と、この手順によっ
てマトリックス状に並べられた全データを、前記行方向
とは垂直な列方向に、順次、所定のビット数のデータか
らなる単位データ列として取り出していく手順と、この
手順によって取り出された各単位データ列の送信順序を
受信側に示す符号を前記単位データ列ごとに付加した
後、前記単位データ列をＣＰＣＳレイヤーへ渡す手順と
を有してなることを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ＡＡＬのタイプ５およ
びユーザによって定義できるＡＡＬのタイプにおいて誤
り制御を行う方法に関する。

【０００２】

【従来の技術】多種多様な情報をＡＴＭに適応させるに
はＡＴＭ網と、上位レイヤとのインターワーキングが必
要であり、その機能を備えたＡＡＬがＡＴＭレイヤと上
位レイヤの間に存在する。

【０００３】現在、各種標準化機関によりＡＡＬには扱
う情報の種類に応じ現在４つのタイプが標準化されてい
る。すなわち、ＡＡＬタイプ１は固定ビットレートの音
声・映像などのリアルタイム通信、ＡＡＬタイプ２は可
変ビットレートのリアルタイム通信、ＡＡＬタイプ３／
４／５はデータ通信用（ただし、ＡＡＬタイプ３／５は
コネクションオリエンテッド通信用、ＡＡＬタイプ４は
コネクションレス用）となっている。この中で、ＡＡＬ
タイプ３／４、５はデータ通信用であることから、特に
正確さ（信頼性）が要求されるアプリケーションの存在
が考えられるが、現状ではプリミティブな部分の標準化
に留まっており、ＡＡＬにて誤り制御機能が十分に提供
されているとはいえない。

【０００４】このため、正確さが要求されるデータ通信
をＡＡＬタイプ３／４、あるいはＡＡＬタイプ５のユー
ザが求める場合は、ＡＡＬのＣＰＣＳレイヤよりも上位
のレイヤに、信頼性を保証させるプロトコルを実装する
必要がある。これまで知られている例としては、ＳＳＣ
Ｓ（Service Specific Convergence Sublayer;サービス
依存ＣＳ）に再送制御を基本としたプロトコルを実装す
る方法（例えば、ＩＴＵ−ＴＳ（旧ＣＣＩＴＴ）のＱ．
ＳＡＡＬプロトコル）や、ＳＳＣＳをヌルとし、その上
位にトランスポートレイヤプロトコル（例えば、ＴＣＰ
やＯＳＩ／ＴＰ４など）を実装する方法などがある。

【０００５】このような方法は、すべて再送により、そ
の信頼性を確保する方法である。

【０００６】また、別のアプローチとして、送信するデ
ータに対して誤り訂正符号を付与して、通信を行い、網
内にて多少の情報の廃棄、誤りが生じた場合でも、受信
側にて該失われた情報の再生を行うというものもある。

【０００７】その例として、ＡＡＬタイプ１（実時間Ｃ
ＢＲ通信用）のオプションとして用意されている誤り制
御符号を用いる方式がある。

【０００８】この方式は、送信側から受信側へ音声・映
像などのリアルタイム通信を行う際に、該データに誤り
制御符号を付与する方式である。この方式の送受信手順
を次に示す。

【０００９】まず、送信側の処理の手順は、以下のごと
くである。

【００１０】（１）上位レイヤから渡された送信データ
が図３０の様にＣＳレイヤに渡される。

【００１１】（２）ＣＳレイヤでは、上位レイヤから受
け取った送信データを以下の要領でインターリーブす
る。即ち、送信データを図３１（ａ）のように行方向に
並べ、次に（ｂ）のようにそれぞれの行に対して前方誤
り訂正符号（以下、ＦＥＣ（Forward Error Correctio
n）と略記する）を計算する。図を見てわかるように、
送信データ１２４オクテットごとに、ＦＥＣ４オクテッ
トを加えていく形となる。

【００１２】ここで、ＦＥＣとは、送信するデータに付
与する誤り訂正符号を意味する。ＡＡＬタイプ１では、
このＦＥＣとして、リード・ソロモン符号を指定してい
る。リードソロモン符号とは、単位長さのビットの塊を
１つの符号長（シンボルと呼ぶ）とし、これを単位とし
て、誤り検出・訂正演算を行う手法であり、「ビットの
塊」をその誤り制御の対象としていることから、バース
ト誤りに適した誤り制御符号として知られている。該Ａ
ＡＬタイプ１では、１オクテット（＝８ビット）を１シ
ンボル（符号長）としている。

【００１３】（３）ＳＡＲレイヤにてセルのペイロード
長に区切られる際、図３１（ｃ）の様に、インターリー
ブデータは、左上端から順に、列方向（縦方向）に順次
読み出されてＡＴＭセル化されていく。この列とは、上
記リードソロモン符号の１シンボル（＝１オクテット）
をその単位としている。即ち、１行目から１オクテット
読みだされた後、次の２行目の１オクテットが読みださ
れ、次に３行目・・・といった形となる。

【００１４】縦１列分は結局４７オクテットとなり、こ
れに対してＣＳから渡されたＳＮ（シーケンス番号、４
ビット）とＳＮＰ（Sequence Number Protect ；シーケ
ンス番号のための誤り制御符号、４ビット）がＳＡＲヘ
ッダ（計１オクテット）としてつけられ、これが図３２
のようにＡＴＭセルのペイロード（４８オクテット）に
格納される。

【００１５】（４）図３３のようにＡＴＭヘッダをつけ
ＡＴＭセルとし、網側に送出する。

【００１６】続けて、受信側の処理の手順を、以下に示
す。

【００１７】（１）ＡＴＭヘッダの値により、ＡＡＬタ
イプ１のインターリーブを行っているセルのみ（ただ
し、コネクション数も１）をフィルタリングして取り出
す。

【００１８】（２）ＡＴＭヘッダを取り去り、ＳＡＲヘ
ッダを検査する。この検査とは、到着するＳＮを調べて
いくことによるセルの抜けの検出を意味する。

【００１９】ＡＴＭ通信方式では、その原理上、網内で
のセルの廃棄（セルの紛失）が一定の確率で生じること
が避けられない。このセルの廃棄を、セルごとに付与さ
れるシーケンス番号により検出する。

【００２０】（３）セルの廃棄が検出された場合、廃棄
されたセルのＳＮをＣＳレイヤに知らせることによって
どのセルが廃棄されたのかを特定（廃棄位置の特定）
し、予め付加しておいたＦＥＣを用いて誤りを訂正す
る。

【００２１】なお、リードソロモン符号では、セル廃棄
のように（廃棄）位置の特定はされないが、到着したデ
ータにビット誤りが含まれていたとしてもＦＥＣで同時
に訂正できる。ただし、これは多くの処理過程、処理時
間を要する。

【００２２】このように、ＡＡＬタイプ１では、オプシ
ョンとして、ＦＥＣコードを付加することによってリア
ルタイムで（すなわち、再送を行うこと無しに）、信頼
性のある通信を保証することができる。

【００２３】一方、ＡＴＭ網でデータ転送を行う場合、
ＡＡＬとしては基本的にタイプ３／４、または５のいず
れかを用いることとなるが、タイプ５の方が処理が簡単
になっており高速性を追求したものとなっている。しか
し、タイプ３／４、５とも、そのＳＡＲレイヤやＣＰＣ
Ｓレイヤにおいては、特に信頼性保証のための誤り制御
を行っていないため、信頼性のあるデータ通信を欲する
ユーザは、何らかの手段で誤り制御を行わなければなら
ない。

【００２４】どのような誤り制御を行うのが適当かとい
う問題については、現在のところ、前述のようにＣＰＣ
Ｓの上位のレイヤ（ＳＳＣＳ、またはトランスポートレ
イヤ）に再送制御を基本としたプロトコルを実装する方
式が知られている。

【００２５】しかしながら、（１）次世代通信方式とし
て、ＡＴＭ方式が本命視される中、ＩＴＵ−ＴＳや、Ａ
ＴＭフォーラムなどの標準化機関により標準化が進めら
れているデータ通信用ＡＡＬタイプ（具体的にはＡＡＬ
タイプ５）が、今後の高速端末（マルチメディア端末を
含む）に実装されていく可能性が極めて高い、（２）Ａ
ＡＬタイプ５は高スループット、低レイテンシを目的と
している、（３）大容量トランザクションなど、大容量
で、実時間性が求められ（再送制御が基本的に許されな
い）、かつ信頼性も要求されるアプリケーションが今後
ますます増えていくと考えられる、（４）ＬＡＮ、ＭＡ
Ｎ、ＷＡＮなど、通信網の広域化がなされている。通信
網が広域であればあるほど、上記のレイテンシの確保
と、再送による誤り制御とは相いれないものとなってく
る（広域においては、情報の再送に莫大な時間がかかる
こととなる）、（５）一般に、再送による誤り制御を行
う方式においては、再送の単位は上位レイヤパケット群
（具体的には、たとえばＴＣＰパケットや、レイヤ４パ
ケットグループ）であり、セルの廃棄といった比較的小
さな単位のデータの消失に対し、大きなデータの再送を
求めるものとなっており、網資源の浪費につながる場合
がある、などの理由により、上述のような再送を基本と
する誤り制御方式をＡＴＭ端末上に実装するのみでは、
対処が難しいデータ通信領域がますます増大していくこ
とが考えられる。

【００２６】

【発明が解決しようとする課題】上述したように、従来
のＡＴＭ網でデータ転送を行う場合、特に、今後の高速
端末に実装されていく可能性が極めて高いＡＡＬタイプ
５にてデータ転送を行う場合、高スループット、低レイ
テンシといったサービス品質を確保することは、再送に
よる誤り制御では極めて困難であった。

【００２７】一方、前述したＡＡＬタイプ１における誤
り制御符号を用いる方法のような手法をＡＡＬタイプ５
に適用することは、それらのプロトコルの本質的な相違
から難しかった。

【００２８】本発明は、このようなことを鑑みなされた
ものであり、ＡＡＬタイプ５において高スループットか
つ低レイテンシの信頼性のあるデータ通信を可能とする
誤り制御方法を提供することを目的とするとともに、併
せて、ユーザ定義のＡＡＬにおいて高スループットかつ
低レイテンシの信頼性のあるデータ通信を可能とする誤
り制御方法を提供することを目的とする。

【００２９】

【課題を解決するための手段】上記課題を解決するため
に、本発明（請求項１）では、ＡＴＭアダプテーション
レイヤ・タイプ５のコモン・パート・コンバージェンス
・サブレイヤーよりも上位のレイヤにて行うＡＴＭ網に
おける誤り制御方法であって、送信しようとする一続き
のデータ列を一定の長さに順次区切り、それらの先頭を
揃えて行方向に並べるとともに、この区切られた一群の
データごとに所定の誤り制御符号を付加する第１の手順
と、前記第１の手順によってマトリックス状に並べられ
た全データを、前記行方向とは垂直な列方向に、順次、
所定のビット数のデータからなる単位データ列として取
り出していく第２の手順と、前記第２の手順によって取
り出された各単位データ列の送信順序を受信側に示す符
号を前記単位データ列ごとに付加した後、前記単位デー
タ列をコモン・パート・コンバージェンス・サブレイヤ
ーへ渡す第３の手順とを有してなることを特徴とする。

【００３０】また、本発明（請求項２）では、ＡＴＭア
ダプテーションレイヤ・タイプ５のコモン・パート・コ
ンバージェンス・サブレイヤーよりも上位のレイヤにて
行うＡＴＭ網における誤り制御方法であって、送信しよ
うとする一続きのデータ列を一定の長さに順次区切り、
それらの先頭を揃えて行方向に並べるとともに、この区
切られた一群のデータごとに所定の第１の誤り制御符号
を付加する第１の手順と、前記第１の手順によってマト
リックス状に並べられた全データを、前記行方向とは垂
直な列方向に、順次、所定のビット数のデータからなる
単位データ列として取り出していく第２の手順と、前記
第２の手順によって取り出された各単位データ列のＡＴ
Ｍセルのペイロード長よりも短い一定長のデータごと
に、この一定長のデータの送信側でのセル送出順を受信
側に示す符号と、この符号および前記一定長ごとのデー
タの双方のビット誤りを検出するための第２の誤り検出
符号とを挿入する第３の手順とを有してなることを特徴
とする。

【００３１】一方、本発明（請求項３）に係るＡＴＭ網
における誤り制御方法は、送信しようとする一続きのデ
ータ列をＡＴＭセル化する際、送信側でのセル単位のセ
ル送出順を受信側に示す符号と、この符号および前記Ａ
ＴＭセルのデータ部を保護するための誤り制御符号とを
セル単位に付加することを特徴とする。

【００３２】また、本発明に係るＡＴＭ網における誤り
制御方法は、送信しようとする一続きのデータ列を一定
の長さに順次区切り、それらの先頭を揃えて行方向に並
べるとともに、この区切られた一群のデータごとに所定
の第１の誤り制御符号を付加する第１の手順と、前記第
１の手順によってマトリックス状に並べられた全データ
を、前記行方向とは垂直な列方向に、順次、所定のビッ
ト数のデータからなる単位データ列として取り出してい
く第２の手順と、前記第２の手順によって取り出された
所定数の単位データ列と、送信側でのセル単位のセル送
出順を受信側に示す符号と、この符号および当該単位デ
ータ列を保護するための第２の誤り制御符号とをＡＴＭ
セルのデータ部として、ＡＴＭセル化を行う第３のステ
ップとを有してなることを特徴としても良い。

【００３３】ここで、上記２番目、３番目および４番目
に掲げた各方法において、前記セル送信順を受信側に示
す符号および前記誤り制御符号をセルの最後部に位置さ
せるようにすると好ましい。

【００３４】また、上記１番目に掲げた方法において、
ＡＴＭアダプテーションレイヤ・タイプ５のコモン・パ
ート・コンバージェンス・サブレイヤーで検査されるＣ
ＲＣ符号もしくは長さ表示により誤りが検出された場
合、または前記単位データ列の送信順序を受信側に示す
符号に誤りが検出された場合に、前記誤り制御符号の復
号装置に、当該誤り部分列の位置を通知するようにして
も良い。

【００３５】上記２番目に掲げた方法において、各ＡＴ
Ｍセルに少なくとも１つ以上付与された前記第１の誤り
制御符号により、誤りが検出された場合、または前記セ
ル送出順を受信側に示す符号に誤りが検出された場合
に、前記第１の誤り制御符号の復号装置に、該誤り位置
を通知するようにしても良い。

【００３６】上記４番目に掲げた方法において、前記セ
ル送出順を受信側に示す符号に誤りが検出された場合、
または前記第２の誤り制御符号により誤りが検出された
場合に、前記第１の誤り制御符号の復号装置に、該誤り
位置を通知するようにしても良い。

【００３７】さらに、上記のように、誤り制御符号の復
号装置に、該誤り位置を通知するようにした場合、それ
ぞれにおいて、前記ＣＲＣ符号もしくは長さ表示あるい
は前記第２の誤り制御符号に誤りが検出されるごとに、
および送出時の送出順を受信側に示す順序性のある符号
に一連でない部分が発見されるごとに、カウンタを増加
させ、このカウンタ値があらかじめ設定した値を越えた
場合に、所定の処理を実行するようにしても良い。

【００３８】

【作用】本発明（請求項１）に係るＡＴＭ網における誤
り制御方法によると、（１）ＡＡＬタイプ５のＣＰＣＳよりも上位のレイヤに
て、第１の手順と第２の手順にて構成されるデータ構造
を構成することができ、ＦＥＣを用いた誤り制御方式を
実現する枠組みを提供することができる。このことによ
り、再送制御を行うこと無しに、信頼性の要求されるデ
ータ通信を行う枠組みをＡＡＬタイプ５上に構築するこ
とができる。

【００３９】（２）ＡＴＭ網内にて発生したセル廃棄に
よる情報の欠落に対して、ＡＡＬタイプ５のトレイラ情
報（具体的には長さ表示またはＣＲＣ符号）を用いて、
これを検出することができるため、上記データ構造に不
完全なデータを送ることがない。

【００４０】（３）ＡＴＭ網内にて発生したランダムビ
ット誤りによる情報の誤りに対して、ＡＡＬタイプ５の
トレイラ情報（具体的にはＣＲＣ）を用いてこれを検出
することができるため、上記データ構造に不完全なデー
タを送ることがない。

【００４１】などの利点を享受することができる。

【００４２】これらは、ＡＡＬタイプ５のＣＰＣＳの上
位レイヤに、ただ単に行＊列のデータ構造を導入したの
みでは、リードソロモン符号による誤り制御方式を運用
することはできず、本発明のように、情報の抜け位置を
特定できる位置情報を導入することによりはじめてこれ
が可能となっている。

【００４３】なお、この方法において、ＡＴＭアダプテ
ーションレイヤ・タイプ５のコモン・パート・コンバー
ジェンス・サブレイヤーで検査されるＣＲＣ符号もしく
は長さ表示により誤りが検出された場合、または前記単
位データ列の送信順序を受信側に示す符号に誤りが検出
された場合に、前記誤り制御符号の復号装置に、当該誤
り部分列の位置を通知するようにした場合、（４）セル廃棄を原因とする列抜けと、伝送路符号誤り
を原因とするランダムビット誤りを上記の機構を用いて
同等のものとして扱い、処理を行うことから、前記誤り
制御符号（誤り訂正符号）に対して迅速な誤り位置の通
知を行うことができ、ひいては迅速な誤り訂正を行うこ
とができると共に、セル廃棄を原因としたデータ誤り
と、ランダムビット誤りを原因としたデータ誤りを、
（前記誤り制御符号にランダムビット誤り位置の特定能
力を持たせることなく）一括して処理することのできる
環境を提供することが可能となる、という利点をも享受
することができる。

【００４４】また、本発明（請求項２）に係るＡＴＭ網
における誤り制御方法によると、ＣＰＣＳレイヤの上位
レイヤにて付与する位置情報とデータに対してビット誤
りを検出するための前記第２の検出符号を付与すること
により、ＣＰＣＳにてＣＲＣ誤りが検出された場合で
も、ＣＰＣＳの上位レイヤにて、受信したデータの位置
情報が信頼できる値であるか否かを該上位レイヤ内にて
確認することができ、情報抜けの位置を特定することが
できると共に、位置情報のみならずデータに対しても誤
り検出符号が付与されているため、受信側装置のＣＰＣ
Ｓよりも上位のレイヤにおいて、任意位置のランダムビ
ット誤りをも検出することが可能となる。また、この方
法において、各ＡＴＭセルに少なくとも１つ以上付与さ
れた前記第１の誤り制御符号により、誤りが検出された
場合、または前記セル送出順を受信側に示す符号に誤り
が検出された場合に、前記第１の誤り制御符号の復号装
置に、該誤り位置を通知するようにした場合、前述した
請求項１に係るＡＴＭ網における誤り制御方法と同様の
理由により、ＦＥＣを用いた誤り制御方式に対し迅速な
対処が可能となる。

【００４５】また、この場合、ＡＴＭセル化されたデー
タの使用効率をより改善できる利点もある。

【００４６】一方、本発明（請求項３）に係るＡＴＭ網
における誤り制御方法によれば、セル単位に順序符号
（例えばシーケンス番号）と誤り制御符号を付与するこ
とにより、ＡＴＭ網におけるセルの廃棄およびＡＴＭ網
におけるランダムビット誤りの２つを同時にセル単位で
検証することができるので、ＡＴＭ網においてより信頼
性のある通信を実現することが可能となる。

【００４７】また、これらの符号は、ＷＡＮ領域など再
送による誤り制御が困難な場合のＦＥＣを用いた誤り制
御方式や、また、セル単位に順序符号と誤り制御符号を
付与するようにしたことによって、どのセルにランダム
ビット誤りがあるかを検出し、どのセルが抜けているか
を検出し、およびどのセルを再送してほしいかを要求・
返答することが可能となるので、セル単位の再送制御を
行って、無駄なデータ再送を行わない効率的な誤り制御
を行う場合の制御情報としてこれを用いることができ
る。

【００４８】また、この方法において、前記セル送出順
を受信側に示す符号に誤りが検出された場合、または前
記第２の誤り制御符号により誤りが検出された場合に、
前記第１の誤り制御符号の復号装置に、該誤り位置を通
知するようにした場合、前述した請求項１に係るＡＴＭ
網における誤り制御方法と同様の理由により、ＦＥＣを
用いた誤り制御方式に対し迅速な対処が可能となる。

【００４９】請求項２および３に係るＡＴＭ網における
誤り制御方法および前記４番目に掲げた方法において、
各セルの送信順序を示す符号と誤り制御のための符号を
セルの最後部に位置させるようにした場合、制御情報を
１カ所に集めることができるため処理装置の構成が簡単
になる利点を得ることができるとともに、データのアラ
インメントを行いやすくなる利点を得ることができる。

【００５０】さらに、上記のように、誤り制御符号の復
号装置に、該誤り位置を通知するようにした場合のそれ
ぞれにおいて、前記ＣＲＣ符号もしくは長さ表示あるい
は前記第２の誤り制御符号に誤りが検出されるごとに、
および送出時の送出順を受信側に示す順序性のある符号
に一連でない部分が発見されるごとに、カウンタを増加
させ、このカウンタ値があらかじめ設定した値を越えた
場合に、所定の処理を実行するようにした場合、誤り制
御能力の限界値をこえる誤り数に対応して、予め前記カ
ウンタに一定値を設定しておき、このカウンタのカウン
ト値が当該一定値を越えた場合に、カウンタから誤り制
御符号の復号装置にその旨を通知して、該当するデータ
の部分については誤り制御符号の復号処理を行わないよ
うにすると共に、上位のアプリケーションにも通知し、
そして、これを受けた当該上位のモジュールは、送信側
端末に該データの再送を要求するようにし、あるいは該
データを不要と判断した場合は該データに対応する部分
にダミーデータを与えるなどの体処法をいち早く行うこ
とができるので、より効率的な誤り制御を行うことが可
能となる。

【００５１】

【実施例】以下、図面を参照しながら実施例を説明す
る。

【００５２】本実施例では、いくつかの送信側端末と受
信側端末との間にてＡＴＭ網を介して通信を行う場合を
示す。この両端末間では、大容量トランザクション処理
が行われており、両端末間におけるデータのやり取り
は、低レイテンシ（再送制御が基本的に許されない）、
高スループット（大容量通信）、かつ信頼性のある（す
なわち、送信側端末にて送信したデータと同一のデータ
を受信側端末にて入手できる）通信が求められているも
のとする。なお、これら両端末間は、例えば公衆網を介
してＷＡＮ接続されている場合のように、互いに物理的
に離れた距離に位置するものとしても良い。

【００５３】本実施例では、これらの要求条件を満たす
ため、両端末間にてやり取りするデータにＦＥＣ（前方
誤り訂正符号）を付与して、受信側端末にてデータを格
納したＡＴＭセルのＡＴＭ網内での廃棄や、伝送路また
はスイッチノードにおけるビット誤りから、再送を行う
こと無しにデータを再生できる手法をいくつか示す。

【００５４】（第１の実施例）本実施例では、送信側端
末と受信側端末は、それぞれＡＴＭ端末であり、データ
のＡＴＭセル化／デセル化を行う場合、ＡＡＬタイプ５
を用いている。送信・受信両端末間にて信頼性のある通
信を行うために、すなわちデータを誤りなくやり取りす
るために、ＡＡＬタイプ５のＣＰＣＳレイヤの上位レイ
ヤであるＳＳＣＳレイヤとして、ＦＥＣを用いた誤り制
御方式を適用している。

【００５５】図１に、Ｕプレーン通信（アプリケーショ
ン間の通信）を行う場合の、両端末のプロトコルスタッ
クの図を示す。なお、図中、１はＡＴＭ網、３はＡＴＭ
交換機を示している。

【００５６】図１に示すように、送信側端末２_t、受信
側端末２_r共に大容量トランザクションのアプリケーシ
ョンが動作しており、送信側端末２_tから受信側端末２
_rに対して大容量・リアルタイムのデータが転送され
る。信頼性のある通信を確保するために、ＳＳＣＳに
て、後述するＦＥＣ処理が加えられる。両端末２_t，２
_rはＡＴＭ網１に直接接続され、更にエンド−エンドの
ＡＴＭコネクションにより両端末２_t，２_rは直接接続
されている。このエンド−エンドのＡＴＭコネクション
は、後述するように、本アプリケーション間の通信に先
立って確立されたものである。

【００５７】信頼性のある通信を実現するためのプロト
コルとしては、ＳＳＣＳにＦＥＣプロトコルを実装して
いるため、トランスポートプロトコルのレイヤ４はヌル
となっている。そのほか、すでに両端末２_t，２_r間に
エンド−エンドのＡＴＭコネクションが確立されている
ため、レイヤ２、レイヤ３もヌルとなっている。

【００５８】次に、送信側端末２_t、及び受信側端末２
_r内における、具体的な処理について説明する。

【００５９】図２に、送信側端末２_t、及び受信側端末
２_rの具体的な構成を示す。

【００６０】このように、送信側端末２_tは、アプリケ
ーション処理（広帯域トランザクション処理）を行い、
受信側端末２_rに対して送信したいデータ（アプリケー
ションデータと呼ぶ）をＳＳＣＳ処理モジュール６_tに
渡すアプリケーション処理モジュール４_t、アプリケー
ション処理モジュール４_tから受信したデータに、イン
タリーブ操作、及びＦＥＣを付与したのち、その各々の
インタリーブ列に対してシーケンス番号を付与し、これ
をＣＰＣＳ処理モジュール１４_tに渡すＳＳＣＳ処理モ
ジュール６_t、ＳＳＣＳ処理モジュール６_tから受け取
ったデータに対して、ＡＡＬタイプ５のＣＰＣＳ処理、
すなわち長さ表示（ＬＩ）、およびＣＲＣの各フィール
ドを、それぞれ演算して挿入する処理を行い、ＳＡＲ処
理モジュール２０_tに対してこれを渡すＣＰＣＳ処理モ
ジュール１４_t、ＡＡＬタイプ５のＳＡＲレイヤ処理の
うち、データのセグメンテーションをＣＰＣＳ処理モジ
ュール１４_tから渡されたデータに対して行うＳＡＲ処
理モジュール２０_t、該セグメンテーションされたデー
タにＡＴＭセルヘッダを付与し、さらに下位レイヤ（物
理レイヤ）の処理を行ってＡＴＭ網１に対してセルを投
入するＡＴＭヘッダ付与モジュール２２_tからなる。

【００６１】これに対し、受信側端末２_rは、ＡＴＭ網
１から入力されてきたセル流から、物理レイヤの処理、
及び自端末宛のセルを選択して取り出した後、該ＦＥＣ
を用いてデータ通信を行うセルのみを選択して、このＡ
ＴＭヘッダを削除した後にＳＡＲ処理モジュール２０_r
に渡すとともに、ＡＴＭセルヘッダのＰＴ（ペイロード
タイプ）のＵＵＩ（ユーザ・ユーザ情報）領域に、ＣＳ
−ＰＤＵの最後部を示すビットが表示されている場合
に、これをＳＡＲ処理モジュール２０_rに通知するＡＴ
Ｍヘッダ削除モジュール２２_r、ＡＴＭヘッダ削除モジ
ュール２２_rから受け取ったデータ（セルペイロードデ
ータ）を、ＣＳ−ＰＤＵの最後部についての情報を参照
しながらＡＡＬタイプ５のリアセンブリ処理を行い、Ｃ
Ｓ−ＰＤＵを再生するＳＡＲ処理モジュール２０_r、該
再生されたＣＳ−ＰＤＵについてＡＡＬタイプ５のＣＰ
ＣＳレイヤ処理、すなわちＣＲＣのチェックと長さ表示
のチェックを行い、ＣＳ−ＳＤＵを再生するＣＰＣＳ処
理モジュール１４_r、ＣＰＣＳ処理モジュール１４_rに
て再生されたＣＳ−ＳＤＵを各インタリーブ列とみな
し、これに付与されたシーケンス番号を確認し、更にデ
インターリーブ処理（アプリケーションデータの再生処
理）をＦＥＣ訂正モジュールを用いつつ行うＳＳＣＳ処
理モジュール６_r、ＳＳＣＳ処理モジュール６_rからア
プリケーションデータを受け取り、広帯域トランザクシ
ョン処理の受信側処理アプリケーションを稼働するアプ
リケーション処理モジュール４_rからなる。

【００６２】上記した個々のモジュールをハードウエア
処理にて行うかあるいはソフトウエア処理にて行うかの
選択についてはまったく自由であり、例えば、アプリケ
ーション処理モジュール４_t，４_rは、それぞれ端末２
_t，２_r内のＣＰＵによるソフトウエア処理にて、ＳＳ
ＣＳ処理モジュール６_t，６_r、ＣＰＣＳ処理モジュー
ル１４_t，１４_r、ＳＡＲ処理モジュール２０_t，２０
_r、およびＡＴＭヘッダ付与／削除モジュール２２_t，
２２_rは、それぞれ端末２_t，２_r内のハードウエア処
理にてその処理が行われるように構成する形態が一例と
して考えられるほか、他のいかなる形態を採用すること
も可能である。

【００６３】次に、送信側端末２_tにおける処理をレイ
ヤの順、すなわち各処理モジュールの動作する順に従っ
て説明する。

【００６４】（Ａ）アプリケーション処理モジュール４
_tによる処理まず、アプリケーション処理モジュール４_tにて生成さ
れたデータ（アプリケーションデータ）が生成されたと
する（図３０参照）。

【００６５】（Ｂ）インターリーブモジュール８_tおよ
びＦＥＣ付与モジュール１０_tによる処理次に、このアプリケーションデータに対して、図３に示
すようなインタリーブのためのデータの構造（以下、イ
ンターリーブ構造と呼ぶ）を作っていく。

【００６６】即ち、インターリーブモジュール８_tで
は、受け取ったアプリケーションデータを、図４のよう
に行方向（紙面の横方向）に並べていく。この際、本実
施例では、この行方向にデータを並べる、その１行あた
りの長さをＡＡＬタイプ１のオプションにあるインター
リーブ処理と同様に１２４オクテットとする。

【００６７】このアプリケーションデータの構造化を行
うと共に、データの揃った行については、ＦＥＣ付与モ
ジュール１０_tにより、該行についての誤り制御符号
（誤り訂正符号、長さは４オクテットとする）が演算さ
れ、図４の構造の右端部に付与される。この様子（イン
ターリーブモジュールにて構成される全体構造）を図５
に示す。なお、この誤り制御符号の詳細については、後
述する。

【００６８】この誤り制御符号の演算は、図４に示すよ
うな構造に、データがすべて出揃ってから、これを行っ
ても良いが、本実施例のＳＳＣＳ処理部６_tにおいて
は、この図４に示す構造の各行ごとにデータが揃ったな
らば、ＦＥＣ付与モジュール１０_tにより誤り制御符号
の演算、及びその演算結果の挿入を即座に行い、これと
並行してアプリケーションデータの図４のような整列が
行われ続けるといった処理を行う。これによって、並列
演算をすることを可能にし、演算効率を向上させてい
る。なお、その他の方法、例えば、各行ごとにデータが
整列されていく課程で、挿入されるべき誤り制御符号を
演算し、各行の最後のデータが図４の構造の各行に整列
した時点で、誤り制御符号の演算は終了しており、即座
にその符号の付与が行われるといった処理を行っても良
い。

【００６９】（Ｃ）シーケンス番号付与モジュール１２
_tによる処理シーケンス番号付与モジュール１２_tは、インターリー
ブモジュール８_tにて図５のように構成された全体構造
を図６の様に１オクテットづつの列に分け、これを図７
のように、１列目から順次、列ごとに読みだしていく。

【００７０】この読みだしの際に、各列ごとにシーケン
ス番号（ＳＮ）を各列単位につけていく。このシーケン
ス番号は全体で１オクテット（＝８ビット）の長さを有
しており、この中で最初の７ビットが実際のシーケンス
番号、最後の１ビットがパリティビットとなっている。

【００７１】なお、このシーケンス番号に費やすビット
数は、全体構造の列数に応じて増減してもかまわない
し、列数に対して少な目のビット数で、一つの全体構造
中で何回か値が循環してしまうような値でもまったくか
まわない。ただし、列数に対して少な目のビット数を用
いる場合は、全体構造の先頭の１列目を示すビットをシ
ーケンス番号のビット中に１ビット設けると、受信側端
末で全体構造を再構築していく場合の組立開始のトリガ
とすることができるので、効果的である。

【００７２】図７を見ればわかるように、シーケンス番
号は各列ごとに一つの割合で付与され、列が進むごとに
インクリメントされた値を持っている。このシーケンス
番号は各列の最前部に付与されても、最後部に付与され
てもかまわないが、本実施例では、図８のように最前部
に付与されているものとして以降の説明を続ける。

【００７３】このシーケンス番号が付与された各列のデ
ータが本実施例の送信側端末におけるＣＰＣＳ−ＳＤＵ
（サービスデータユニット）となる点に注意が必要であ
る。このＣＰＣＳ−ＳＤＵはＣＰＣＳ処理モジュール１
４_tに渡される。

【００７４】ここで、ＣＰＣＳ−ＳＤＵは４２オクテッ
ト（１オクテットのシーケンス番号＋４１オクテットの
アプリケーションデータ、または誤り制御符号）であ
り、ＣＰＣＳ処理モジュール１４_tにて６オクテットの
ＣＰＣＳトレイラが付与された場合に、丁度ＡＴＭセル
のペイロード長である４８オクテットになるため、ＣＰ
ＣＳ処理モジュール１４_tにてＰＡＤを挿入される必要
がなく、もって、網内資源を効率的に利用することがで
きる。

【００７５】（Ｄ）ＣＰＣＳ処理モジュール１４_tによ
る処理ＣＰＣＳ処理モジュール１４_tでは、ＳＳＣＳ処理モジ
ュール６_tから受け取ったＣＰＣＳ−ＳＤＵに、ＡＡＬ
タイプ５の処理である長さ表示（ＬＩ）とＣＲＣの演
算、付与を行い、ＣＰＣＳ−ＰＤＵを生成する。

【００７６】ここで、前述のように、ＰＡＤ挿入の必
要、あるいはＰＡＤ挿入のための長さの確認が不要であ
る。また、ＣＰＣＳ−ＳＤＵの長さは必ず４２オクテッ
トとなるため、長さ表示のためのＣＰＣＳ−ＳＤＵ長の
演算（検査）も原則的に不要である。

【００７７】（Ｅ）ＳＡＲ処理モジュール２０_tによる
処理ＳＡＲ処理モジュール２０_tでは、ＣＰＣＳ処理モジュ
ール１４_tから受け取ったデータ（ＣＰＣＳ−ＰＤＵ）
のセグメンテーション処理が行われるが、本実施例にお
いては、ＣＰＣＳ−ＰＤＵ長が４８オクテットであり、
本質的にセグメンテーション処理が不要である。

【００７８】セグメンテーション処理された４８オクテ
ットのデータ（ＳＡＲ−ＰＤＵ）は、ＡＴＭヘッダ付与
モジュール２２_tに渡される。

【００７９】なお、その際、ＡＴＭヘッダ付与モジュー
ル２２_tに渡されるＳＡＲ−ＰＤＵがＣＳ−ＰＤＵの最
後部に当たるデータである場合（よって、本実施例では
すべての場合）、この旨をＡＴＭヘッダ付与モジュール
２２_tに通知する。

【００８０】（Ｆ）ＡＴＭヘッダ付与モジュール２２_t
による処理ＡＴＭヘッダ付与モジュール２２_tでは、呼設定時に定
められたＡＴＭセルヘッダを付与した後、物理レイヤの
処理を介して、ＡＴＭセル化されたデータをＡＴＭ網１
に対して送出する。

【００８１】ＳＡＲ処理モジュール２０_tからデータ
（ＳＡＲ−ＰＤＵ）を受け取る際、これはＣＰＣＳ−Ｐ
ＤＵの最後部である旨の通知を受けている場合は、ＡＴ
ＭセルヘッダのペイロードタイプのＵＵＩフィールド
に、これを告げる旨のビットをたてておく。

【００８２】以上が、送信側端末２_tにおける処理の流
れである。

【００８３】次に、ＦＥＣ付与モジュール１０_tにて付
与される（あるいは、受信側端末２_rのＦＥＣ訂正モジ
ュール１０_rにて訂正処理される）誤り制御符号につい
て説明する。

【００８４】本ＦＥＣ付与モジュール１０_tにて付与さ
れる誤り制御符号は、リード・ソロモン符号と呼ばれる
ものである。この符号は、ＣＲＣなどに代表されるビッ
ト単位の誤り制御符号（ビット単位に誤り制御の対象と
し、誤り制御の対象となる符号のとりうる値は“０”か
“１”であり、この２つの値の正否を論ずる符号形式）
と異なり、数ビットの塊をその誤り制御の対象の１つの
単位とする誤り制御符号である。この数ビットの塊をシ
ンボルと呼ぶ。例えば、１シンボルが４ビットというよ
うに表現する。

【００８５】リード・ソロモン符号では、例えば、１シ
ンボルが４ビットの場合は、１つの符号の単位が４ビッ
トであり、誤り制御の対象となる符号のとりうる値は１
６進表示で“０”から“Ｆ”までの１６通り存在する。
送信側端末では、まず、送信したいビット列を、数ビッ
トずつ順次くるんでいくことにより、シンボルの列とみ
なす。このシンボルの列に対して、誤り制御符号化処理
を行い、同じくシンボル（すなわち、ビットの塊）の列
の形で誤り制御符号を生成する。受信側端末では、この
シンボルを単位に訂正演算を行っていく。例えば、２進
表示で“０００００００１”なるビット列が伝送路中
でビット誤りを生じ、“００００００１１”なるビッ
ト列に変わってしまった場合、通常のビット単位の誤り
処理では７ビット目の符号に誤りが生じたと考えるが、
４ビットを１シンボルとみなすリード・ソロモン符号で
は、１６進表示で“０１”が、伝送路誤りにより“０
３”となり、２シンボル目が“１”から“３”に変化
し、誤りが生じたと解釈する。

【００８６】このように、数ビットを１つの符号化の単
位として扱うリード・ソロモン符号は、その性質より、
バースト誤りに強い誤り制御方式としてしられている。
例えば、“０００００００１”なる符号が、バースト
伝送路誤りにより“００００１１１０”なる符号に変化
し、４ビット誤りが生じた場合でも、リード・ソロモン
符号では、“０１”が“０Ｅ”なる符号に変化した
と解釈すればよく、これは符号の立場からすると“０
１”が“０３”に変化した場合と比べ、事象的にはど
ちらも１シンボル誤りが生じたと解釈するのみで、誤り
訂正処理としては同一の処理を行うこととなる。よっ
て、バースト的な誤りに対して、耐性が強い符号とし
て、衛生通信などの分野で盛んに使われている符号方式
である。

【００８７】翻って、ＡＴＭ通信方式では、そのスイッ
チングの原理から、通信網中でのセル（パケット）の廃
棄が確率的に発生する事が避けられない。即ち、ＡＴＭ
通信方式は、ある送信側端末からセル流を送信した場合
でも、これが受信側端末に到達する間に一定の確率でセ
ルが廃棄されている事を前提としなくてはならない通信
方式である。従って、ＡＴＭ網を介して通信を行う端末
間では、やり取りする情報が信頼性を要求する情報、す
なわち送信側端末の上位レイヤから送出した情報と同一
の情報を確実に受信側端末の上位レイヤが受信する事を
要求する情報である場合は、何らかの信頼性を確保する
ためのプロトコルを両端末間で稼働させなくてはならな
い。

【００８８】これを実現するプロトコルとしては、従来
ＴＣＰやＯＳＩ／ＴＰ４などに代表されるトランスポー
トレイヤプロトコル（レイヤ４プロトコル、転送プロト
コル）が知られていたが、これらのプロトコルは、誤り
制御（誤りからの回復）の方法として、再送制御をベー
スにこれを行っており、本実施例の端末間のアプリケー
ションである広帯域トランザクションでは、その処理に
実時間性が求められるため、再送制御は認められない。
このため、信頼性確保のためのプロトコルとして、送信
するデータに誤り制御符号を付与して通信を行う方式を
適用しているのは前述の通りである。

【００８９】ここで、周知のように、ＡＴＭ通信網で
は、伝送路系（光ケーブルや同軸ケーブル、あるいはツ
イストペアなど）でのビット誤りは従来の通信方式と比
べて低い確率（例えば１０Ｅ−９）でしか起こらず、そ
のかわりセル廃棄という形でバースト的な情報の欠落が
確率的に（例えば１０Ｅ−９）生ずるという特徴があ
る。このセル廃棄に対して、信頼性の求められる通信を
求める送信・受信双方の端末は対処する必要があり、誤
り制御符号をその手段としているが、セル廃棄という事
象が、符号レベルでみるとバースト的な情報の欠落と見
る事ができる。それゆえ、バーストレベルの誤りに強い
耐性を持つリード・ソロモン符号をその符号化方式とし
て本ＦＥＣ付与モジュール１０_tは使用している。

【００９０】理想的には、図９のように、１シンボルを
４８オクテットとし、直接リード・ソロモン符号演算を
行い、ＡＴＭセル化を行えば、伝送途中でセル廃棄が発
生した場合でも、後述のようにセル廃棄箇所の特定がで
きさえすれば、リード・ソロモン符号は、１シンボル、
または数セル廃棄なら数シンボルの消失誤りと解釈し
て、受信側端末のＦＥＣ訂正モジュール１０_rにて訂正
演算を行えばダイレクトに復号処理が行えることがわか
る。

【００９１】しかしながら、リード・ソロモン符号の演
算は、１シンボル長あるいは符号長の増大により、その
演算量が急激に増大していく事が知られており、現状で
は“１シンボル＝４８オクテット”なる長大なシンボル
長を有する符号化器・復号化器を設計、実装する事が現
実的でない。

【００９２】そこで、（１）図４から図７に示すような
インターリーブ処理を行い、インターリーブの各列を１
つのＡＴＭセルに格納すること、および、（２）１シン
ボルを列ごとのデータ（本実施例では１オクテット）と
みなすことにより、伝送路中にてセル廃棄が生じた場合
に、インターリーブの各行からみると、１つのセルの廃
棄を１シンボルの消失とみなす事ができ、適当な演算量
にてその復号処理を行う事ができる。ただし、処理は全
ての行に渡って、本実施例ではインターリーブ構造の行
数である４１回行う。

【００９３】なお、本実施例の送信側端末２_tでは、イ
ンターリーブ構造の各列にそれぞれシーケンス番号をＳ
ＳＣＳ処理モジュール６_tにて付与しているが、この理
由については受信側端末２_rの処理の説明の際に詳述す
る。

【００９４】さて、上位レイヤ（アプリケーション処理
モジュール）から受け取ったデータは単発的に到着する
データであるか、それともバースト的に一定時間にわた
って到着する長大なデータであるかわからない場合があ
る。そこで、上位レイヤから渡されるデータが途切れ、
図４のインターリーブ構造がデータで一杯にならない場
合は、誤り制御符号の生成ができず、実時間性を求めら
れる通信であるにも関わらず、情報の送出がなかなかで
きないといった事態が生ずる事が考えられる。そこで、
本実施例では、図４のインターリーブ構造に余裕（空
き）が生じているならば、その時点からインターリーブ
モジュール８_t内に専用のタイマーを起動させ、一定時
間次のデータが到着しなかったらインターリーブ構造の
残りの領域にはダミーデータ(00...0 等) を補充して該
データを受信側端末２_rに向かって送出をしてしまうと
いった機構を採用している。この場合は、どこからがダ
ミーデータであるかの情報が受信側端末２_rに必要とな
るため、インターリーブ構造の最後の数ビット（数オク
テット）、あるいはシーケンス番号付与モジュールにて
付与するシーケンス番号内に、どこからがダミーデータ
であるかについての情報を入れて送出すれば良い。

【００９５】なお、このタイマーのタイムアウト（ダミ
ーデータ挿入開始）の判断の際には、端末に与えられた
ＶＰ／ＶＣのＵＰＣ（使用トラヒックパラメータ）での
制限値を越えないように、または有効利用するように判
断する事が必要となる。これは、例えば大きな帯域を与
えられていないのにもかかわらず、データ転送の高スル
ープット、低レイテンシを重視して、タイムアウトを小
さく設定すると、データの到着頻度が疎である場合には
ダミーデータが増え、転送効率が悪くなるばかりか、Ｕ
ＰＣで定められた帯域違反をしてしまう可能性もある。
それとは逆に、タイムアウトを大きく設定しすぎるとス
ループットが上がらなくなり、レイテンシも大きくなっ
てしまう場合がある。パラメータの取り方はいろいろ考
えられるが、指標を決めて、最適化を行うことが必要で
ある。

【００９６】また、データ送出契機についてブッシュ機
構のような方法を用いることもできる。ブッシュ機構と
はＴＰＣ（Transmission Control Protocol ）でインタ
ラクティブユーザに対応するために、バッファが一杯に
なるのを待たずに現在のストリーム中のデータの配線を
強制することのできるオペレーションである。

【００９７】例えば、本実施例において、アプリケーシ
ョンが瞬時的な情報の送出を要求している場合には、タ
イムアウトになるまで待っていたのでは要求されたサー
ビス品質（例えばレイテンシ）を保持できないかもしれ
ない。

【００９８】そこで、緊急を要するデータに関しては、
その旨をアプリケーション処理モジュールからＳＳＣＳ
処理モジュールに対して通知してもらえるようにしてお
く。そして、その指示があった場合には、インターリー
ブ構造にデータが溜まっていなくても、またはタイムア
ウトになっていなくても、ＳＳＣＳ処理モジュールは、
速やかにダミーデータを付け足しＦＥＣの計算に移り、
該データの送出を促すことも可能である。

【００９９】次に、受信側端末２_rにおける処理をレイ
ヤの順、すなわち各処理モジュールの動作する順に従っ
て説明する。

【０１００】（Ｇ）ＡＴＭヘッダ削除モジュール２２_r
による処理ＡＴＭヘッダ削除モジュール２２_rでは、ＡＴＭ網１か
ら受け取ったセル流について、物理レイヤ処理を行った
のち、呼設定時に定められたＡＴＭセルヘッダを有した
セルを受け取った場合、これをフィルタリングして受取
り、その他のセルは無視し、ＡＴＭセルヘッダを削除し
てＳＡＲ処理モジュール２０_rに渡す。

【０１０１】ここで、ＡＴＭセルヘッダのペイロードタ
イプのＵＵＩフィールドに、“これはＣＰＣＳ−ＰＤＵ
の最後部である“という旨を伝えるためのビットが立て
られている場合には、この旨をＳＡＲ処理モジュール２
０_rに対して通知する。

【０１０２】（Ｈ）ＳＡＲ処理モジュール２０_rによる
処理ＳＡＲ処理モジュール２０_rでは、ＡＴＭヘッダ削除モ
ジュールから渡されたデータ（ＳＡＲ−ＰＤＵ）に対
し、これもＡＴＭヘッダ削除モジュールから渡される
“これはＣＰＣＳ−ＰＤＵの最後部である”という旨の
情報を参照して、データ（ＣＰＣＳ−ＰＤＵ）のリアセ
ンブリ処理を行う。

【０１０３】データのリアセンブリが終了したならば、
ＣＰＣＳ処理モジュール１４_rに該データが渡される。

【０１０４】（Ｉ）ＣＰＣＳ処理モジュール１４_rによ
る処理ＣＰＣＳ処理モジュール１４_rでは、ＳＡＲ処理モジュ
ール２０_rから受け取ったＣＰＣＳ−ＰＤＵに対し、Ａ
ＡＬタイプ５の処理であるＣＲＣ演算処理、及び長さ表
示（ＬＩ）の確認作業をこの順番にて行う。

【０１０５】正常受信されたデータについては、このＣ
ＰＣＳトレイラを削除した上で、ＳＳＣＳ処理モジュー
ルにこのデータ（ＣＰＣＳ−ＳＤＵ）を転送する。

【０１０６】ここで、ＣＲＣ演算処理、及び長さ表示の
値の結果のどちらかに誤りが検出された場合は、この旨
をＳＳＣＳ処理モジュール６_rに通知する。この場合、
ＣＲＣ演算処理にて生じた誤りであるか、長さ表示の値
によって生じた誤りであるか、どちらであるかの情報を
ＳＳＣＳ処理モジュール６_rに通知する必要は、後述の
理由により、必ずしも必要なく、誤りが検出された旨の
み通知すればそれでよい。

【０１０７】（Ｊ）シーケンス番号確認モジュール１２
_rによる処理ＳＳＣＳ処理モジュール６_rには、基本的に正常受信さ
れたＣＰＣＳ−ＳＤＵ（ＳＳＣＳ−ＰＤＵ）、即ちイン
ターリーブ構造の各列が転送されてくる。

【０１０８】シーケンス番号確認モジュール１２_rで
は、これらＣＰＣＳ処理モジュール１４_rから受信した
ＳＳＣＳ−ＰＤＵのうち、シーケンス番号のフィールド
を参照して、インターリーブ構造のどの位置（どの列）
に該ＳＳＣＳ−ＰＤＵを配置すれば良いかを考え、配置
する。即ち、シーケンス番号に抜けのある場合は、その
位置（そのシーケンス番号を有したインターリーブ列が
入るであろう、インターリーブ構造の位置）について
は、何もデータを入れないでおき、正しいシーケンス番
号の位置に、受信したＳＳＣＳ−ＰＤＵを入れていく事
になる。

【０１０９】このようにしてインターリーブ構造の再生
を行っていくとともに、ＦＥＣ訂正モジュール１０_rに
対して、“インターリーブ構造のどの列が、ＳＮ誤りや
ＣＰＣＳのＣＲＣ誤りによって例外が発生したために、
正しいデータが再配置されていないか“という位置の情
報を通知する。

【０１１０】なお、このＦＥＣ訂正モジュール１０_rに
対して、インターリーブ構造の誤り発生位置を通知する
場合に、シーケンス番号の確認の際に、例えば伝送路中
でセル廃棄が生じて、セルの抜けが生じてしまうといっ
たようなことによって、シーケンス番号に誤りが生じ、
これを通知する場合のみならず、ＡＴＭ網におけるセル
の伝送中に生じたビット誤りを検出するＣＰＣＳ処理モ
ジュール１４_rのＣＲＣ確認において誤りが生じた場合
についても、同様の通知がＦＥＣ訂正モジュール１０_r
に対して行われる事になる。

【０１１１】詳細は後述するが、セル廃棄のみならず、
ビット誤りに対しても、同様の対処（インターリーブ構
造への再生を行わない）を行う事により、ＦＥＣ訂正モ
ジュール１０_rにおける訂正演算の量を大幅に低減する
ことができる。

【０１１２】（Ｋ）デインターリーブモジュール８_rお
よびＦＥＣ訂正モジュール１０_rによる処理シーケンス番号確認モジュール１２_rにて、（１）イン
ターリーブ構造の再生が可能な限り行われる、（２）イ
ンターリーブ構造のうち、セル廃棄やビット誤りなどの
理由により受信したＳＳＣＳ−ＰＤＵを配置できない列
番号に関しては、ＦＥＣ訂正モジュール１０_rにその列
番号の通知が行われている、という状況がなされてい
る。この状況の一例を図１０に示す。

【０１１３】ＦＥＣ訂正モジュール１０_rは、シーケン
ス番号確認モジュール１２_rから、正常なデータの入っ
ていない列番号をあらかじめ知らされた上で、誤り制御
符号の演算を開始する事になる。

【０１１４】ＦＥＣ訂正モジュール１０_rは、この正常
なデータの入っていない列番号を参照しながら、リード
・ソロモン符号の復号演算を実行し、正常なデータ（ア
プリケーションデータ）を再生する（デインターリーブ
動作）。当然ながら、再生されたアプリケーションデー
タは、図４にあったようなデータ構造となる。

【０１１５】しかるのち、データ再生が終了した事をア
プリケーション処理モジュール４_rに通知する。

【０１１６】（Ｌ）アプリケーション処理モジュール４
_r アプリケーション処理モジュール４_rが、アプリケーシ
ョンデータをＳＳＣＳ処理モジュール６_rから受け取
り、アプリケーション処理を行う。

【０１１７】以上が、受信側端末２_rにおける処理の流
れである。

【０１１８】この中で、ＦＥＣ訂正モジュール１０_rに
おける処理の詳細について、以降述べる。

【０１１９】ＦＥＣ訂正モジュール１０_rは、基本的
に、送信側端末２_t内のＦＥＣ付与モジュール１０_tに
おける演算の逆演算を行い、インターリーブ構造のデー
タの再生処理を行う。

【０１２０】ここで、リード・ソロモン符号の復号演算
方式としては、従来（例えば、ＩＴＵ−ＴＳにおけるＡ
ＡＬタイプ１のオプションや、米学会ＳＩＧＣＯＭＭ’
９０の"Reliable Broadband Communication Using a Bu
rst Erasure Correcting Code"にて発表された方式な
ど）では、図１１（ａ）に示すような方式がとられてい
た。その手順を、以下に示す。

【０１２１】ステップ１）インターリーブ構造の列単位
に、リード・ソロモン符号を用いて、誤りの有無をまず
検索する。なお、この処理に要する時間をＴ１とする。

【０１２２】ステップ２）インターリーブ構造の列のう
ち、ＡＴＭ網においてセル廃棄されたデータの位置を
（例えば列番号にて）復号化器に通知されている。即
ち、セル廃棄による誤りの位置は、復号化器はすでに知
っている。

【０１２３】ステップ３）伝送中に発生した、ランダム
ビット誤りの位置については復号化器は認知していな
い。よって、復号化器にて、ランダムビット誤りの位置
を検索するため、誤り位置検索（チェンサーチ）をおこ
なう。なお、この処理に要する時間をＴ３とする。

【０１２４】ステップ４）ランダム誤り位置を特定し、
その位置を復号化器が把握する。なお、この処理に要す
る時間をＴ４とする。

【０１２５】ステップ５）セル廃棄されたデータの位置
と、ランダムビット誤り位置の両方の位置を特定できた
復号化器は、この位置情報を元に、復号演算を開始す
る。なお、この処理に要する時間をＴ５とする。

【０１２６】ステップ６）復号完了ここに、全演算時間は、Ｔ１＋Ｔ３＋Ｔ４＋Ｔ５とな
る。

【０１２７】上記の処理のうち、ステップ３のチェンサ
ーチの処理は、演算が複雑であり、ソフトウエアで演算
する場合は、多くの演算時間が、ハードウエアで演算す
る場合は複雑な処理回路を要していた。

【０１２８】これに対し、本発明のＦＥＣ訂正モジュー
ル１０_rでは、前述のように伝送路中のランダムビット
誤りに対しても、ＡＡＬタイプ５のＣＰＣＳトレイラに
実装されたＣＲＣを用いて検出し、これを、インターリ
ーブ構造の列の誤りとして、列廃棄が生じた場合と同様
の対処を行っているため、ＦＥＣ訂正モジュール１０_r
における処理は、図１１（ｂ）に示すように簡略化され
ている。その手順を、以下に示す。

【０１２９】ステップ１１）リード・ソロモン符号を用
いて、誤りの有無をまず検索する。なお、この処理に要
する時間をＴ１とする。

【０１３０】ステップ１２）インターリーブ構造の列の
うち、ＡＴＭ網においてセル廃棄されたデータの位置、
及びランダムビット誤りが生じているデータの位置を
（列番号にて）復号化器に通知されている。即ち、セル
廃棄による誤りの位置も、ランダムビット誤りの位置
も、両方とも復号化器はすでに知っている。

【０１３１】ステップ１３）セル廃棄されたデータの位
置と、ランダムビット誤り位置の両方の位置を特定でき
た復号化器は、この位置情報を元に、復号演算を開始す
る。なお、この処理に要する時間をＴ５とする。

【０１３２】ステップ１４）復号完了ここに、全演算時間は、Ｔ１＋Ｔ５となる。

【０１３３】以上のように、明らかにチェンサーチの不
要な分、処理の大幅な簡略化がなされている。

【０１３４】前者の方法（従来の方法）では、インター
リーブ構造の行ごとに独立に演算を行っていたため、ラ
ンダムビット誤りが生じていない行についてはランダム
ビット誤り位置の通知（ステップ４）、ランダム誤りに
対しての訂正演算（ステップ５）の２つのステップは不
要であったのに対し、後者（本発明の方法）では、ラン
ダムビット誤りが検出された列については、すべて列廃
棄と同等に扱うことになるため、実際にランダムビット
誤りの起きていない行についても復号演算を行う必要性
はでてくるという欠点は有しているが、現状の伝送技術
を用いると、ランダムビット誤りの発生確率は、セル廃
棄確率よりも充分低いと考えられ、低確率でしか起こら
ないランダムビット誤りのための機構（従来の方法のス
テップ３、ステップ４）を必ず設けて、長い演算時間を
かけてインターリーブ構造行ごとに演算するのと比べ、
本発明の方法は、低演算時間を前提に考えられた手法で
あり、充分なメリットを享受することができる。

【０１３５】さて、ここまではインターリーブ構造の大
きさが横１２８オクテット＊縦４１オクテットとして説
明を続けてきたが、実際には、インターリーブ構造の縦
・横のサイズは可変である。

【０１３６】まず、横の長さ（アプリケーションデータ
を並べるデータのインターリーブ構造の横の長さ、及び
誤り制御符号の長さの両方を含む）は、ＡＴＭ網内の様
子（セル廃棄率や遅延時間など）や、送信しようとして
いるデータの大きさを勘案して適当に増減して良い。

【０１３７】また、縦の長さについても、適当に増減し
てかまわない。ＣＰＣＳ処理モジュールにて行う処理を
考慮すると、縦のサイズを４１、もしくは４１＋４８＊
Ｎ（Ｎは正数）としておくと、ＣＰＣＳ−ＰＤＵとして
ＰＡＤを挿入する必要がなくなるため、網資源使用効率
の点から都合がよいが、バリエーションとしてはインタ
ーリーブ構造の1 列が、必ずしも整数セルにきちんと収
まらなくても構わない。図１２には、縦の長さを８９列
とした場合のインターリーブ構造を（横幅は、アプリケ
ーションデータについては任意、誤り制御符号について
は４オクテットとした）、また、図１３には、これらの
シーケンス番号付与モジュール１２_tにて付与されるシ
ーケンス番号の様子を、図１４には、ＳＡＲレイヤ処理
部２０_tにおけるセグメンテーション処理を示す。

【０１３８】次に、上記に示したＦＥＣを用いた通信を
設定（または切断、あるいは変更）する際の手続き（呼
設定手順）について説明する。

【０１３９】送信側端末と、受信側端末は、（アプリケ
ーション間の）通信の開始に先立って、コネクションの
設定を行う。このコネクションの設定には、大きく２つ
の意味があり、以下の２つに分類される。（１）送信側・受信側両端末とＡＴＭ網間のＡＴＭコネ
クション設定ＡＴＭ網に対して、送信側端末と受信側端末間に、これ
らをエンド−エンドに接続するＡＴＭコネクションを設
定する。（２）送信側端末と受信側端末間の上位レイヤコネクシ
ョン設定送信側端末と、受信側端末間で、ＦＥＣとＡＡＬ５を用
いたデータ通信を行うことを同意し、例えばインターリ
ーブ構造の縦・横幅、ＦＥＣで用いるリード・ソロモン
符号の生成多項式の決定などの必要なパラメータの合意
を行い、上位レイヤ（アプリケーションレベル、ＳＳＣ
Ｓレイヤ、ＣＰＣＳレイヤ、ＳＡＲレイヤ）のコネクシ
ョンを設定する。

【０１４０】これらのコネクション設定の流れの例を図
１５に示す。図中では、コネクション設定のトリガは送
信側端末からかけているが、受信側端末からはじめにか
けるようになっていてもかまわない。

【０１４１】まず、送信側端末は、ＡＴＭ網に対して、
ＡＴＭコネクションの接続要求を行う。これを受けたＡ
ＴＭ網は、送信側端末との間で設定するＡＴＭコネクシ
ョンのＵＰＣ(Usage Parameter Control) の打ち合わせ
などを行いつつ、受信側端末との間で、上記のようなＡ
ＴＭコネクションの設定に合意するか否かをたずね、合
意するようであれば、受信側端末ともＵＰＣパラメータ
の打ち合わせなどを行う。これらの処理は、Ｃプレーン
の処理である。これらを介して、送信側端末と受信側端
末との間にベアラのＡＴＭコネクションが設定される。

【０１４２】このベアラのＡＴＭコネクションを介し
て、両端末間では、ＦＥＣを用いたＳＳＣＳと、ＡＡＬ
タイプ５を用いて、通信を行うのに際し、必要なパラメ
ータ（例えば、アプリケーション処理内容のお互いの確
認、各々の端末がＦＥＣ処理機能を持っているか、イン
ターリーブ構造のサイズなど）の打ち合わせを行い、合
意がとれた後に、実際のＦＥＣを用いたデータ通信が開
始される。

【０１４３】なお、本実施例では、ＡＴＭ網との打ち合
わせでは、ベアラのＡＴＭコネクションの設定に関する
事項のみを行い、両端末間の具体的な上位レイヤのいろ
いろなパラメータの打ち合わせなどは、両端末間に確立
されたＡＴＭコネクションを介して行う場合、即ち、Ａ
ＴＭ網側から見ると、ＵプレーンのＡＴＭコネクション
を介して上位レイヤ間のコネクションを確立する際に必
要な打ち合わせを行う場合について説明した。その代り
に、上位レイヤのパラメータの打ち合わせを、ベアラの
ＡＴＭコネクションの確立前に終了しておく方法、即
ち、図１５中にＳ１と記した打ち合わせ段階で、上位レ
イヤパラメータの打ち合わせをＡＴＭ網内のコネクショ
ン設定機能を介して行い、ＡＴＭコネクション開設の時
点で送信側端末、受信側端末双方の間で上位レイヤパラ
メータが合意されているような方法でも、勿論良い。

【０１４４】なお、図１５には、コネクション設定の流
れを示したが、ＦＥＣを用いたデータ通信の実行中にＦ
ＥＣのパラメータ（例えば、インターリーブ構造のサイ
ズ、前述のタイムアウト値の設定値、リード・ソロモン
符号の生成多項式など）の変更などを行っても良い。こ
のような、動的なパラメータの変更は、例えば、ＡＴＭ
網に輻輳が生じており、または反対に、強力な誤り訂正
符号を有していたところが、ＡＴＭ網の状態が非常に空
いており、セル廃棄がまったく起こらないような場合
に、誤り訂正符号の能力を弱めたり、インターリーブ構
造のサイズを増大させたりして、効率を向上させたりす
るような場合が例えば考えられる。なお、上記したＡＴ
Ｍ網に輻輳が生じていることは、端末側が受信データや
ＯＡＭ情報等から自立的に推測しても良いし、ＡＴＭ網
側から明示的に示される輻輳表示などを参考にして知る
形になっていても良い。一方、コネクション切断もほぼ
図１５と同様のフローにて行われる。

【０１４５】次に、本実施例では、ＳＳＣＳレイヤのＦ
ＥＣ処理のほかは、信頼性を確保するためのプロトコル
の実装は想定していなかった。しかしながら、実際には
誤り制御符号には、その能力に限界があるので、一定数
以上セルが廃棄され、もしくは一定数以上ランダムビッ
ト誤りが発生し、これ（即ち、誤りと認められるインタ
ーリーブ構造の列数）が誤り制御符号の能力を越えるも
のとなり、該誤り制御符号によるデータの再生はもはや
できないということが生ずる可能性もある。ちなみに、
一般に４シンボルのリード・ソロモン符号は４シンボル
までの位置の特定できる誤りの訂正か、２シンボルまで
の位置の特定できない誤りの訂正の能力を示す。

【０１４６】誤り訂正符号において訂正できないことが
生じた場合に、訂正できなかった元のデータを獲得する
ためには、再送制御を行うしか方法がないが、本実施例
では、ＳＳＣＳの上位に信頼性を確保するためのプロト
コルを実装せず、再送制御を行わないことを想定したも
のであるので、はじめから、ＡＴＭ網の状態をあらかじ
め予期し、充分な性能を有するパラメータを選択した上
で、ＦＥＣを用いた通信を開始するのが好ましい。ただ
し、可能な場合には、ＦＥＣを用いて再生できないデー
タについては、受信側端末は獲得をあきらめるようにす
れば、効率的である。

【０１４７】一方、ＳＳＣＳよりも更に上位のレイヤ
（例えばトランスポートレイヤ）に、再送制御を基本と
した誤り制御方式を有する転送プロトコルを実装する方
法を考えられる。このプロトコルを処理するモジュール
は、図２でいうと、アプリケーション処理モジュール４
_t（４_r）とＳＳＣＳ処理モジュール６_t（６_r）との
間におかれることとなる。この場合、ＡＴＭ網にて一定
以上の割合でセル廃棄が生じない限り使うことがないた
め、非常にライトウエイトな（ただし再送制御を有し
た）プロトコルを実装するのが好ましい。

【０１４８】このような、再送制御を有し、且つライト
ウエイトなプロトコル（以下、ライトウエイト転送プロ
トコルと呼ぶ）を本発明のＦＥＣを用いた誤り制御プロ
トコルの上位に実装した場合の例を以下に示す。この場
合のプロトコルスタックを図１６に示す。このように、
ライトウエイト転送プロトコルはＳＳＣＳ（インターリ
ーブ＋ＦＥＣ）とアプリケーションの間のレイヤ処理と
して位置づけられる。

【０１４９】本ライトウエイト転送プロトコルは、ブロ
ック選択再送アルゴリズムを適用している。即ち、送信
側端末３２_tは、送信データの管理をある大きさのブロ
ックを単位に行っており、受信側端末３２_rからデータ
の再送を求められた場合は、このブロックを単位に再送
を行う。逆に、受信側端末３２_rのライトウエイト転送
プロトコルは、再送要求（あるいは正常受信できたこと
の通知であるＡＣＫ通知）をこのブロックを単位に行
う。これは、例えばブロックごとにインクリメントされ
るシーケンス番号（ＳＮ）を用意することによりこれを
行うことができる。

【０１５０】この再送制御は、選択再送、即ち再送を要
求されたブロックについてのみ行う（選択再送）ものと
し、ＧＯ−ＢＡＣＫ−Ｎアルゴリズムのようなウインド
ウ内のデータをすべて再送するようなアルゴリズムは使
用しない。このようにすることにより、不必要なブロッ
クの再送を行うことをしなくて済むため、網内のトラヒ
ック量の不要な増加を未然に防ぐことができる共に、受
信側端末３２_rの受信バッファのオーバーランを防ぐこ
とができる。

【０１５１】本実施例では、このライトウエイト転送プ
ロトコルの１ブロックを、ＳＳＣＳレイヤのインターリ
ーブ構造（の内のＦＥＣでない部分、即ちＳＳＣＳ−Ｓ
ＤＵの部分）としている。このことにより、受信側端末
３２_rにてＳＳＣＳレイヤにてＦＥＣによる誤り検出が
行われ、誤りがない場合にはこの旨を上位レイヤである
ライトウエイト転送プロトコルに通知し、ライトウエイ
ト転送プロトコルにおいては誤り検出演算を行わなくて
も良いような構成をとっている。

【０１５２】また、再送制御を行う際には、送信側端末
３２_tはレート制御、即ち、送出するデータのスループ
ットを適当に増減する制御を行って、受信側端末３２_r
のオーバーフローを行うことが一般に行われるが、本実
施例においては、ライトウエイト転送プロトコルにてレ
ート制御を行うと下位レイヤのＦＥＣのインターリーブ
構造にデータが一杯になり、データ送出を行えるように
なるまでの時間が長くかかるようになり、レイテンシの
増大につながる場合がある。これに対応するため、本実
施例のライトウエイト転送プロトコルにおいては、イン
ターリーブ構造のデータがそろうまでのＳＳＣＳレイヤ
へのデータ送出（ライトウエイト転送プロトコルとＳＳ
ＣＳ間のデータの転送）はこれまでのデータ送出速度と
同一の速度で行うと共に、レイヤ４（ライトウエイト転
送プロトコル）が、ＡＴＭレイヤ（あるいはＡＡＬレイ
ヤ）にプリミティブの形でレート制御のための情報を送
出し、ＡＴＭレイヤにおけるＵＰＣ（ＡＴＭセル送出の
際のピークセルレート、平均セルレート等のトラヒック
制御）のパラメータを変更することによってレート制御
を行う方式をとっている。

【０１５３】次に、上記した誤り制御能力の限界値をこ
える誤りが発生した場合、そのことをいち早く感知し
て、早めに再送制御などの手を打つ手段について、説明
する。そのような手段の一例としては、受信側端末３２
_rのＳＰＣＳ処理を行うモジュール内に、誤り制御符号
誤りが検出されるごとに、または送出時の送出順を受信
側に示す順序性のある符号に一連でない部分が発見され
るごとに１づつ増加されるカウンタを設けることが考え
られる。

【０１５４】すなわち、誤り制御能力の限界値をこえる
誤り数に対応して、予め前記カウンタに一定値を設定し
ておき、このカウンタのカウント値が当該一定値を越え
た場合に、カウンタからＳＳＣＳ処理を行うモジュール
にその旨を通知して、該当するデータの部分については
ＦＥＣ訂正処理を行わないようにすると共に、上位のア
プリケーション処理を行うモジュールにも通知する。そ
して、これを受けた当該上位のモジュールは、送信側端
末３２_tに該データの再送を要求するようにする。これ
によって、無駄なＦＥＣ訂正処理を回避するとともに、
いち早く再送制御を行うことができ、より効率的な誤り
制御を行うことが可能となる。

【０１５５】なお、再送制御は、状況に応じて、誤り訂
正できない部分についてのみ行っても良いし、データ通
信自体を初めから行わせるようにしても良い。

【０１５６】また、上位のアプリケーションの方で当該
誤り訂正できない部分のデータは不要であると判断した
場合に、再送制御せずに、ＳＳＣＳ処理を行うモジュー
ルにおいて所定のダミーデータで代用しておき、アプリ
ケーションの方で対処を行うようにしても良い。

【０１５７】（第２の実施例）次に、本発明に係る第２
の実施例について説明する。本実施例は、概略的には、
上記第１の実施例における図１とほぼ同様の構成を有
し、送信側端末と受信側端末はＡＴＭ端末であり、ＡＡ
Ｌタイプ５を用いている。また、送信側・受信側端末で
稼働しているアプリケーション、プロトコルスタック、
具体的な内部構成も、基本的に第１の実施例とほぼ同様
のものである。

【０１５８】一方、本実施例の第１の実施例に対する主
な相違点は、第１の実施例では、インターリーブ構造の
各列に１つづつシーケンス番号（ＳＮ）を付与するよう
にした点に対して、本実施例では、インターリーブ構造
の縦（列）の長さに関わらず、送信される全ＡＴＭセル
に対して、必ずシーケンス番号および誤り検出符号を付
与するようにした点である。具体的には、送信側端末に
おけるＳＳＣＳ処理モジュール、受信側端末におけるＳ
ＳＣＳ処理モジュールおよびＣＰＣＳ処理モジュールが
異なっている。また、ＣＰＣＳ処理モジュールがＣＰＣ
Ｓ誤りを検出した場合でも、必ず該誤ったＣＰＣＳ−Ｓ
ＤＵを上位のＳＳＣＳ処理モジュールに渡す必要がある
ところも大きく異なる点である。

【０１５９】以下、本実施例について、第１の実施例と
の相違点を中心として、図２を参照しながら説明する。
なお、第１の実施例における各モジュールと本実施例に
おける各モジュールとを区別するために、本実施例で
は、第１の実施例において用いた参照番号に“´”の記
号を付したものを用いて（例えば送信側端末２_t´）、
説明する。

【０１６０】まず、送信側端末における処理について説
明する。

【０１６１】（Ａ）アプリケーション処理モジュール４
_t´による処理本実施例におけるアプリケーション処理モジュール４_t
´による処理は、第１の実施例において“（Ａ）アプリ
ケーション処理モジュール４_tによる処理”で説明した
ものと同様である。それゆえ、ここでの詳細な説明は省
略する。

【０１６２】（Ｂ）インターリーブモジュール８_t´お
よびＦＥＣ付与モジュール１０_t´による処理インターリーブモジュール８_t´では、アプリケーショ
ン処理モジュール４_t´から渡されるアプリケーション
データに対して、図１７（ａ）に示すような第１のイン
ターリーブ構造、図１７（ｂ）に示すような第２のイン
ターリーブ構造、または図１７（ｃ）に示すような第３
のインターリーブ構造を作っていく。ここでは、第１の
実施例と同様の理由により、インターリーブ構造の横幅
については特に問わない。また、縦方向（列方向）の長
さについては、（ａ）では４１オクテット、（ｂ）、
（ｃ）では４７オクテットとなっているが、実際の値
は、本例の値に限定するものではない。

【０１６３】このようなインターリーブモジュールを作
成する際の受け取ったアプリケーションデータの並べ方
は第１の実施例の場合と同様である。

【０１６４】これらのインターリーブ構造に並べられた
アプリケーションデータについて、ＦＥＣ付与モジュー
ル１０_t´により誤り制御符号（リード・ソロモン符
号）が演算され、図１７の各インターリーブ構造が完成
する。ここで、図１７（ｃ）のＰＡＤの領域について
は、アプリケーションデータは格納されないため、例え
ばオール０などのダミーデータを補充した上で、誤り制
御符号の演算が行えば良い。

【０１６５】（Ｃ）シーケンス番号付与モジュール１２
_t´による処理シーケンス番号付与モジュール１２_t´は、図１８、図
２０、および図２１の各々の様に、第１、第２、または
第３のインターリーブ構造のデータを読みだしていく。
図１８、図２０、および図２１では、第１の実施例と同
様に、各インターリーブ構造の横幅は１２８オクテッ
ト、シンボル長は１オクテットとしている。

【０１６６】図１８において、シーケンス番号付与モジ
ュール１２_t´は、第１のインターリーブ構造より読み
出したデータの列ごとに、６オクテットのダミーデータ
（例えばオール０のデータ列）と、１オクテットの“シ
ーケンス番号および誤り検出符号”を付与し、つづけて
次の列に移行するといった形で次々とデータを読んでい
き、これをＣＰＣＳ処理モジュール１４_t´に渡してい
く。

【０１６７】ここで、付与するシーケンス番号、及び誤
り検出符号について説明する。図１８のように、シーケ
ンス番号付与モジュール１２_t´にて付与するシーケン
ス番号・誤り検出符号は、合わせて１オクテットの長さ
を有している。本実施例では、シーケンス番号として４
ビット、誤り制御符号として４ビットの領域を各々有し
ている。シーケンス番号は、１０進数で０から１５まで
の数が循環して使われ、受信側で情報抜け（インターリ
ーブ構造の列抜け）の検出に使われる。図１９のように
シーケンス番号の最初の１ビットは、この第１のインタ
ーリーブ構造の最初の１列であることを示すビットがた
っているような構成でも良い。また、後半４ビットの誤
り制御符号は、図１８の“各列と、該列に付与されるシ
ーケンス番号“を検査対象として、付与される誤り検出
符号であり、例えばＣＲＣのような演算の簡単な誤り検
出符号であれば良い。ここで、この誤り検出符号は、シ
ーケンス番号のみを保護したり、アプリケーションデー
タのみを保護するようなものではなく、その双方を保護
するような構成になっている。

【０１６８】結局、ＣＰＣＳ処理モジュール１４_t´に
渡すＳＳＣＳ−ＰＤＵは、図２３（ａ）の様なものにな
る。

【０１６９】同様に、図２０では、シーケンス番号付与
モジュール１２_t´は、第２のインターリーブ構造より
読み出したデータの列ごとに、後述する１オクテットの
シーケンス番号と誤り検出符号を付与し、つづけて次の
列に移行するといった形で次々とデータを読んでいき、
これをＣＰＣＳ処理モジュール１４_t´に渡していく。
ここで、結局ＣＰＣＳ処理モジュール１４_t´に渡すＳ
ＳＣＳ−ＰＤＵは、図２３（ｂ）の様なものになる。

【０１７０】同様に、図２１では、シーケンス番号付与
モジュール１２_t´は、第３のインターリーブ構造より
読み出したデータの列ごとに、後述する１オクテットの
シーケンス番号と誤り検出符号を付与し、つづけて次の
列に移行するといった形で次々とデータを読んでいく。
ただし、ＰＡＤ（長さ６オクテット）の領域を含む列は
飛ばして、最後の列まで同様の処理を行い、最後にＰＡ
Ｄの含まれるデータ（アプリケーションデータの入った
最右の列）の列を読み出す。その際、ＰＡＤは読み出さ
ず、直接ＳＮ／ＣＲＣを挿入し、これを持ってＣＰＣＳ
−ＰＤＵとして、ＣＰＣＳ処理モジュール１４_t´にこ
れを渡す。ここで、結局ＣＰＣＳ処理モジュール１４_t
´に渡すＳＳＣＳ−ＰＤＵは、図２３（ｃ）の様なもの
になる。

【０１７１】また、図２２の第４のインターリーブ構造
として、図１９での第３のインターリーブ構造からの読
み出し順について、別の方法も説明しておく。先に説明
した方法ではｍ列目を抜かして読み出し、最後へ後回し
にしたが列の順序は崩さずにＰＡＤの部分だけ読み飛ば
す方法も考えられる。この方法をとった場合、インター
リーブ構造からの読み出し順を示す図は図２２のように
なる。ｍ列め以降のＳＮも、その後の１データ列長ごと
に（ｍ−１）列までに付与したＳＮの続き番号を付与し
ていけばよい。よって、ＣＰＣＳ−ＰＤＵとして、ＣＰ
ＣＳ処理モジュール１４_r´に渡すＳＳＣＳ−ＰＤＵは
図２３（ｄ）のようになる。この方法でセル廃棄が生じ
た場合、廃棄されたセルに含まれていたデータが複数列
に渡っているので、受信側は廃棄されたセルに付与され
ていたＳＮをＦＥＣ訂正モジュール１０_r´に伝えると
きどの列にセル廃棄の影響が及ぶのかを過不足なく通知
しなければならない。例のようにｍ列までがデータで、
それ以降と１２８列までがＦＥＣコードであった場合の
ＦＥＣ訂正モジュール１０_r´への通知箇所を示す。

【０１７２】ＳＮ誤りの箇所ｍ−１以前；ＳＮ＝列なので全ての行に通知ｍ；ｍ列目の１−４１行とｍ＋１列目
の１−６行ｍ＋１から１２７；ＳＮ列目の７−４７行とＳＮ＋１
列目の１−６行１２８；ＳＮ（＝１２８）列目の７−４７
行（Ｄ）ＣＰＣＳ処理モジュール１４_t´による処理ＣＰＣＳ処理モジュール１４_t´では、図２３にあるよ
うなデータ列をＣＰＣＳ−ＳＤＵとして、ＣＰＣＳ−Ｐ
ＤＵを作成していく。その際は、これらのデータのデー
タ長の関係から、図２４にあるような形でそれぞれＣＰ
ＣＳトレイラが付与されていくことになる。特に、図２
４（ｂ）の場合、ＣＰＣＳ−ＳＤＵ＋ＣＰＣＳトレイラ
が４８の倍数にならないため、４２オクテット長のＡＡ
Ｌタイプ５・ＣＰＣＳレイヤのＰＡＤが挿入される。

【０１７３】（Ｅ）ＳＡＲ処理モジュール２０_t´によ
る処理ＳＡＲ処理モジュール２０_t´では、４８オクテットご
とにＣＰＣＳ−ＰＤＵがセグメンテーションされるが、
これは結果的に図２３、図２４の太線の部分を境界線
（ＦＩ）として、セグメンテーションされることを意味
する。

【０１７４】ここで、セグメンテーション／ＡＴＭセル
化されたＣＰＣＳ−ＰＤＵの各部分部分には、必ずＳＮ
とＣＲＣが含まれ、更にそれらは、最後のセルを除い
て、ＡＴＭセルのペイロード（あるいはＳＡＲ−ＰＤ
Ｕ）の最後部に位置する。

【０１７５】（Ｆ）ＡＴＭヘッダ付与モジュール２２_t
´による処理第１の実施例と同様であり、ここでの詳細な説明は省略
する。

【０１７６】以上が、送信側端末２_t´における処理の
流れである。

【０１７７】次に、受信側端末２_r´における処理につ
いて説明する。

【０１７８】（Ｇ）ＡＴＭヘッダ削除モジュール２２_r
´による処理第１の実施例と同様であり、ここでの詳細な説明は省略
する。

【０１７９】（Ｈ）ＳＡＲ処理モジュール２０_r´によ
る処理第１の実施例と同様であり、ここでの詳細な説明は省略
する。

【０１８０】（Ｉ）ＣＰＣＳ処理モジュール１４_r´に
よる処理基本的に第１の実施例と同様であるが、ＣＲＣ演算処
理、及び長さ表示の値の結果のどちらかに誤りが検出さ
れた場合に、これをＳＳＣＳ処理モジュール１６_r´に
通知するとともに、該誤りデータをもＳＳＣＳ処理モジ
ュール１６_r´に渡す点が、第１の実施例と異なる点で
ある。

【０１８１】（Ｊ）シーケンス番号確認モジュール１２
_r´による処理第１の実施例と異なり、ＳＳＣＳ処理モジュール１６_r
´には、正常に受信されたＣＰＣＳ−ＳＤＵのみなら
ず、異常受信されたＣＰＣＳ−ＳＤＵをも受け取る。

【０１８２】正常に受信されたＣＰＣＳ−ＳＤＵについ
ては、ＡＴＭ網１における伝送途中や、ランダムビット
誤りは存在しないことがわかっているので（セル廃棄
や、ランダムビット誤りがある場合は、ＣＰＣＳ処理モ
ジュール１４_r´で誤りが検出されるはずである）、そ
のまま送信側端末にて付与したＳＮとダミーデータ（図
１８の場合のみ）を削除した上で、図１８、図２０、図
２１、および図２２のようにインターリーブ構造を再生
していく。

【０１８３】ＣＰＣＳ処理モジュール１４_r´にて誤り
が検出されたデータについては、シーケンス番号確認モ
ジュール１２_r´にてこれを受け取り、送信側端末のシ
ーケンス番号付与モジュール１２_t´にて付与したＳＮ
と、ＣＲＣを検査する。

【０１８４】ここで、ＣＰＣＳ処理モジュール１４_r´
により、必ずＡＴＭ網内にてセル廃棄なり、ランダムビ
ット誤りが起こっているなりしている旨がシーケンス番
号確認モジュール１２_r´に対して通知されているわけ
であるが、このＣＲＣの検査をすることにより、少なく
とも該当するインターリーブ構造列にランダムビット誤
りが生じているか否かを知ることができる。

【０１８５】ここで、ＣＲＣにて誤りが検出されない場
合は、（１）該当するインターリーブ構造の列にはランダムビ
ット誤りはない（２）付与されているＳＮは信頼に足るものである（Ｓ
Ｎにもビット誤りは生じていない）という２つのことを確認することができる。

【０１８６】即ち、ＡＴＭ網における信頼性のある通信
を阻害する要因としては、前述の通り、セルの廃棄とラ
ンダムビット誤りが考えられるわけであるが、この内の
ランダムビット誤りについて、この時点でその疑惑を溶
くことになっている点に注意が必要である。

【０１８７】反対に、ＣＲＣでビット誤りが検出された
場合は、該当するインターリーブ構造の列、あるいはシ
ーケンス番号のどちらかにランダムビット誤りが存在す
ることを意味しており、このデータ（インターリーブ構
造の列）はシーケンス番号確認モジュール１２_r´にて
廃棄される。しかしながら、後述のように、これに続く
列のＣＲＣ／ＳＮの検査を行うことにより、前述のシー
ケンス番号確認モジュールにて廃棄されたインターリー
ブモジュール構造の列の位置は特定できるため、問題と
はならない。

【０１８８】さて、ＡＴＭ網中でセル廃棄が生じた場合
は、１つのセルが１つのインターリーブ構造の列に対応
しているため、該当するインターリーブ構造の列が抜け
ているはずであるが、これを上記の（ビット誤りのない
と保証されている）ＳＮを検査することにより、どこの
インターリーブ構造の列がセル廃棄の形で紛失したかを
知ることができる。

【０１８９】セル廃棄によりインターリーブ構造の列ご
と紛失してしまった列の位置に関する情報や、ランダム
ビット誤り検出により、シーケンス番号確認モジュール
１２_r´にて廃棄された列の位置に関する情報など、こ
の紛失位置に関する情報（インターリーブ構造のどこの
列が紛失したか）について、シーケンス番号確認モジュ
ール１２_r´は上記のような理由により知ることができ
る。シーケンス番号確認モジュール１２_r´は、この紛
失位置（抜け位置）に関する情報をＦＥＣ訂正モジュー
ル１０_r´に対して通知する。

【０１９０】なお、このシーケンス番号確認モジュール
１２_r´にて、どの位置のセルが廃棄されたのかがわか
るので、送信側端末２_t´に対して、該ＳＮを示しつ
つ、該ＳＮを有するセルの再送を要求するといった手法
を適用することもできる。

【０１９１】（Ｋ）デインターリーブモジュール８_r´
およびＦＥＣ訂正モジュール１０_r´による処理第１の実施例と同様である。ただし、図２１あるいは図
２２の様なインターリーブ構造を用いている場合は、受
信側端末にも同一の位置にＰＡＤ領域をもうけ、送信側
端末２_t´と同一パターンのダミーデータを用いること
により、データの再生処理を行うことになる。

【０１９２】よって、この第２の実施例においてもＳＳ
ＣＳ処理モジュール６_r´にて、送信側端末２_t´のア
プリケーション処理モジュール４_t´が送信したデータ
と同一のデータを、受信側端末２_r´のアプリケーショ
ン処理モジュール４_r´が受け取ることができる。

【０１９３】（Ｌ）アプリケーション処理モジュール４
_r´ 第１の実施例と同様である。なお、ＳＳＣＳレイヤより
も上位のレイヤに信頼性を保証する再送制御を行うプロ
トコルを実装しても良いのは第１の実施例の場合と同様
である。

【０１９４】以上が、受信側端末２_r´における処理の
流れである。

【０１９５】ここで、本実施例においても、第１の実施
例で述べたようなライトウエイト転送プロトコルを本発
明のＦＥＣを用いた誤り制御プロトコルの上位に実装
し、必要な場合に再送制御を行うことによって、データ
転送の信頼性を向上させるようにしても良い。

【０１９６】その場合、さらに、第１の実施例で述べた
ようにして、誤り制御能力の限界値をこえる誤りが発生
した場合、そのことをいち早く感知して、早めに再送制
御などの手段を講じることができるように構成しても良
い。

【０１９７】（第３の実施例）次に、本発明に係る第３
の実施例について説明する。本実施例は、ＦＥＣを用い
た通信方式に適したユーザ定義のＡＡＬタイプ（ＡＡＬ
タイプＸ）を用いたものである。

【０１９８】ここに、これまでの第１の実施例および第
２の実施例では、ＩＴＵ−ＴＳによって規定されたＡＡ
Ｌタイプ５を用いていたため、本発明の実施のためには
不要な処理が含まれる場合がある。すなわち、ＡＡＬタ
イプ５では、ＣＰＣＳレイヤで長さ表示とＣＲＣからな
るＣＰＣＳトレイラを付与することが前提となっていた
が、この処理は第１および第２の実施例で示した発明を
実施する上で、必ずしも必要でない処理が含まれる場合
がある。例えば、インターリーブ構造の大きさが決まっ
ている場合は、長さ表示の値は一定値となるはずであ
り、情報としては冗長である。

【０１９９】本第３の実施例では、第１および第２の実
施例にて冗長と考えられた処理を省き、データ通信用Ａ
ＡＬ上に信頼性を持たせるためのＦＥＣを実装するのに
必要十分である処理のみを行うＡＡＬタイプを示す。

【０２００】基本的に、本ＡＡＬタイプでは、セル単位
にＳＮとＣＲＣ（ＳＮとデータの双方について誤りを検
出することのできる誤り検出符号）を付与する。このよ
うに、セル単位にＳＮとＣＲＣ処理を行う理由は、以下
の通りである。

【０２０１】（１）伝送路中で、どのセルが廃棄された
かを検出するために、ＳＮをセル単位に付与する。この
ＳＮを観察することにより、受信側端末がセルの抜け
（あるいは混入）を検出することができ、ひいては抜け
セルの再送を送信側端末に対して要求することができ
る。（２）ＳＮの正当性を保証することと、データ中のビッ
ト誤りを検出するために、ＳＮとデータを併せた全体に
対して誤り検出符号であるＣＲＣを用いる。

【０２０２】前述のように、ＡＴＭ網において情報の誤
りの原因となる事象はセル廃棄とビット誤りであった。
上記の理由（１）はセル廃棄に対して、理由（２）はビ
ット誤りに対してのセル単位の対処を示すものである。

【０２０３】ここで、ＡＴＭセル単位にセル廃棄、ある
いはビット誤りに対して対処を行う理由について述べて
おく。

【０２０４】前述のように、ＡＴＭ網ではセル廃棄とい
う事象が確率的に生じることが避けられないため、セル
単位にその廃棄の有無（混入の有無）を検証することの
できる機構を用意しておくことはきわめて効果的であ
る。また、本実施例にて説明するインターリーブ構造お
よびＦＥＣを用いたＡＴＭ網における誤り制御方式で
は、セル廃棄とビット誤りを等価なものとして扱う機構
を持っているため、セル単位にそのセル内のビット誤り
を検出できる機構を用意する必要がある。また、後述の
ように、セル単位の再送制御を行う場合、セル廃棄によ
り受信側端末まで配送されなかったセルについてと、受
信側端末にて訂正不可能なビット誤りが検出されたセル
については、双方とも送信側端末に対して該セルの再送
要求が行われることとなり、セル単位にシーケンス番号
と誤り検出符号を有することはこの機構を実現するため
にも非常に効果的である。

【０２０５】以下、本実施例について具体的に説明す
る。この第３の実施例においても、第１および第２の実
施例と同様に、送信側端末と受信側端末とがＡＴＭ網に
より接続されているが、この場合はアプリケーションと
して、広帯域データの放送を行っているものとする。

【０２０６】このＦＥＣを用いた信頼性のある通信が効
果を発揮する領域として、放送がある。周知のように、
放送型サービスは、１つの送信者から複数の受信者に対
して、同一のデータを送信するサービスのことである
が、複数の受信者にデータが届くまでの網内での振る舞
いは互いに異なることとなる。例えば、第１の受信側端
末と第２の受信側端末とでは、網内で廃棄されるセル
や、ランダムビット誤りの位置などが当然異なる。この
ような場合、再送制御により信頼性のある通信を保証し
ようとすると、送信側端末は、同時に複数の受信側端末
から要求される再送要求に独立に答えねばならず、内部
のデータの制御、受信側端末ごとに用意された状態変数
の制御が非常に複雑なものとなる。

【０２０７】これに対し、放送サービスのアプリケーシ
ョンにＦＥＣを用いた手法を用いると、基本的に信頼性
を獲得するための手段は各受信側端末にて演算する復号
演算となるため、当然この復号演算は各受信側端末が独
立に動作することができ、送信側端末は複雑なデータ管
理や、状態変数管理をまったく行う必要がない。以上の
ような理由から、ＦＥＣを用いた信頼性のある通信は、
放送に適した方式であるということが知られている。

【０２０８】ここに、本実施例では、プロトコルスタッ
クは図２５のようになる。また、送信側４２_tおよび受
信側両端末４２_rの構成は図２６のようになる。以下、
これらの図を参照しながら、第３の実施例のＦＥＣを用
いた通信方式の詳細について説明する。

【０２０９】まず、送信側端末４２_tにおける処理につ
いて説明する。

【０２１０】図２６に示すように、送信側端末４２_tお
よび受信側端末４２_rに広帯域データ転送のアプリケー
ションが動作しており、送信側端末４２_tから受信側端
末４２_rに対して広帯域なリアルタイムのデータが転送
される。信頼性のある通信を保証するために、ＣＳレイ
ヤにて、後で述べるようにＦＥＣ処理を加える。両端末
４２_t，４２_rはＡＴＭ網１に直接接続され、更にエン
ドーエンドのＡＴＭコネクションは、本アプリケーショ
ン間の通信に先立って確立されたものである。

【０２１１】信頼性のある通信を実現するためのプロト
コルとしては、前実施例と同じようにＣＳにＦＥＣプロ
トコルを実装しているため、トランスポートプロトコル
のレイヤはヌルとなっている。また、両端末４２_t，４
２_r間にエンド−エンドのＡＴＭコネクションが確立さ
れているため、レイヤ２、レイヤ３もヌルとなってい
る。

【０２１２】次に、送信側端末４２_t、及び受信側端末
４２_r内における、具体的な処理について説明する。

【０２１３】送信側端末４２_tは、アプリケーション処
理（広帯域データ転送処理）を行い、受信側端末４２_t
に対して送信したいデータ（アプリケーションデータと
呼ぶ）をＣＳ処理モジュールに渡すアプリケーション処
理モジュール４４_t、アプリケーション処理モジュール
４４_tから受信したデータに、インタリーブ操作、及び
ＦＥＣを付与するＣＳ処理モジュール５４_t、ＣＳ処理
モジュール５４_tから順次受け取ったデータに対して、
“ＡＴＭセルのペイロード長−（ＳＮ長＋ＣＲＣ長）”
間隔にＳＮとＣＲＣを演算し挿入しながら、これらを合
わせた長さがペイロード長ずつになるようにセグメント
化を行い、ＡＴＭヘッダ付与モジュール６２_tに該セグ
メントを渡すＳＡＲ処理モジュール６０_t、該セグメン
ト化されたデータに宛先に従ったＡＴＭセルヘッダを作
成し、物理レイヤの処理を行いＡＴＭ網１に対してセル
を投入するＡＴＭヘッダ付与モジュール６２_tからな
る。

【０２１４】これに対し、受信側端末４２_rは、ＡＴＭ
網１から入力されてきたセル流から、物理レイヤの処
理、及び自分宛のセルを選択して取り出した後、該ＦＥ
Ｃを用いてデータ通信を行うセルのみを選択して、この
ＡＴＭヘッダを削除した後に該セルのデータをＳＡＲ処
理モジュール６０_rに渡す機能を少なくとも有し、場合
によってはＡＴＭセルヘッダのＰＴ（ペイロードタイ
プ）のＵＵＩ（ユーザ・ユーザ情報）領域を予めユーザ
同志でインターリーブ構造単位にデインターリーブした
際に格納される最後のセルであることを示すものと合意
をとっておいて用い、それを検出し通知することも可能
であるＡＴＭヘッダ削除モジュール６２_r、ＡＴＭヘッ
ダ削除モジュール６２_rから受け取ったデータ（セルペ
イロードデータ）を、ＣＲＣとＳＮのチェックを行い、
もし誤りが検出されたならばＣＳ処理モジュール５４_r
のＦＥＣ訂正モジュール５０_rに、その誤り、抜け位置
の通知を行う機能を有するＳＡＲ処理モジュール６
０_r、ＳＡＲ処理モジュール６０_rからわたされたデー
タを、各インタリーブ構造に戻しつつ、誤り、抜け位置
の通知をＳＡＲ処理モジュール６０_rからうけている場
合にはそれを考慮し対処しつつ、デインターリーブ処理
（アプリケーションデータの再生処理）をＦＥＣ訂正モ
ジュール５０_rを用いつつ（詳細は後述）行う機能を有
するＣＳ処理モジュール５４_r、ＣＳ処理モジュール５
４_rからアプリケーションデータを受け取り、広帯域デ
ータ転送処理の受信側処理アプリケーションを稼働する
アプリケーション処理モジュール４４_rからなる。

【０２１５】これらのモジュールは第１の実施例でも示
したようにその各々のモジュールの処理がハード処理で
行なわれていてもソフト処理で行なわれていても、どち
らでも構わない。

【０２１６】次に、送信側端末４２_tにおける処理をレ
イヤの順（処理モジュールの順）に従って説明する。

【０２１７】（Ａ）アプリケーション処理モジュール４
４_tによる処理第１の実施例のアプリケーション処理モジュール４_tの
場合と同様である。

【０２１８】（Ｂ）インターリーブモジュール４８_tお
よびＦＥＣ付与モジュール５０_tによる処理ＣＳ処理モジュール５４_tは、インターリーブモジュー
ル４８_tとＦＥＣ付与モジュール５０_tからなり、アプ
リケーションデータに対して図２７（ａ）に示すような
インターリーブ構造を作っていく。ここでも、第１の実
施例と同様の理由により、インターリーブ構造の横幅に
ついては特に問わない。ただし、送信側端末４２_tと受
信側端末４２_r双方の間であらかじめ合意しておくもの
とする。また、縦方向のサイズについても任意で構わな
いが処理の容易性を考慮すれば“ＡＴＭセルのペイロー
ド長−（ＳＮ＋ＣＲＣのサイズ）”の倍数になっている
ことが望ましい。なお、ＳＮとＣＲＣはこの後で説明す
るＳＡＲ処理モジュール６０_tで付与されるトレイラで
ある。例えば、ＳＮとＣＲＣのサイズが併せて２オクテ
ットであれば、縦のサイズは４６シンボルもしくはその
倍数がよい。ＳＮとＣＲＣのサイズを併せて１オクテッ
トとすれば、インターリーブの縦のサイズは４７の倍数
が適当であり基本的には図２７（ａ）の様なインターリ
ーブを想定することができ、図２７（ｂ）の様な場合も
有り得る。ここでは、ＳＮとＣＲＣが併せて1 オクテッ
トであるような例を紹介するので縦の長さは４７オクテ
ットとして説明する。

【０２１９】前述のようにインターリーブ構造のサイズ
に関しては両端末で合意している必要があり、その設定
は動的にも静的にも行えるが、ここでは予め呼設定の段
階等で決定しているとする。また、ＣＳ処理モジュール
５４_t内のＦＥＣ付与モジュール５０_tで、バースト誤
り訂正符号（本実施例ではリードソロモン符号）を付与
する。

【０２２０】この場合にも、上位レイヤから受け取った
データは単発的に到着するデータであるか、それともバ
ースト的に一定時間にわたって到着するデータであるか
わからないので、上位から渡されるデータ量の変化を監
視し、第１の実施例と同様に必要に応じてタイマーを起
動させて調節をはかる。

【０２２１】（Ｃ）シーケンス番号付与モジュール５２
_tによる処理シーケンス番号付与モジュール５２_tでは上位に位置す
るインターリーブモジュール４８_tから順次列を読み出
してきて、ＳＮとＣＲＣを付与するとペイロードのサイ
ズになるように区切りながら、ＳＮを付与していく。Ｓ
Ｎは本実施例では４ビットとし、よって１６を法として
巡回する連続した番号となる。よって、セルがバースト
的に廃棄されないかぎりは、セル廃棄を検出することが
できる。実施例と同様に、ＳＮのビット数は３ビットに
して１ビットはインターリーブ列の１列目またはそれ以
外を表すようなビットとして用いることも可能である
が、その場合は８を法とした番号になる。ＳＮとＣＲＣ
（次のモジュールで付与する）のビット数は任意であ
り、図１９の様な構成にすることも可能である。

【０２２２】（Ｄ）ＳＡＲ処理モジュール６０_tによる
処理ＣＲＣ付与モジュール５８_tでは、４７オクテットのデ
ータとＳＮ両方に対して計算した誤り検出を行う符号を
付与する。ＣＲＣのサイズはＳＮと同様に４ビットとし
ている。第２の実施例と同じ理由でこれらのＳＮとＣＲ
Ｃは一緒にしてセルの最後になる部分に置くこととす
る。図２８のＣＲＣの能力としては、第２の実施例でも
述べたようにビット誤りの検出のみで十分である。

【０２２３】（Ｅ）ＡＴＭヘッダ付与モジュール６２_t
による処理第１の実施例のＡＴＭヘッダ付与モジュール１２_tの場
合と同様ある。

【０２２４】以上が、送信側端末４２_tにおける処理の
流れである。

【０２２５】次に、受信側端末４２_rにおける処理につ
いて説明する。

【０２２６】（Ｆ）ＡＴＭヘッダ削除モジュール６２_r
による処理第１の実施例のＡＴＭヘッダ削除モジュール２２_rの場
合と同様である。

【０２２７】（Ｇ）ＣＲＣ確認モジュール５８_rによる
処理ＣＲＣ確認モジュール５８_rでは、受け取った４８オク
テットごとのデータに含まれているＣＲＣの確認を行
う。予め送信側と受信側で決定しているＣＲＣの計算方
法に従って、受け取った４８オクテットのデータの先頭
から順次計算を効率的に行っていく。最後の４ビットを
残した時点で計算が完了し、最後の４ビットがＣＲＣに
相当しているので、これと比較することによって、一致
していれば正しいデータとＳＮであることが保証され、
シーケンス番号確認モジュールに最後の４ビットを取り
除いたデータ列をシーケンス番号確認モジュールに渡
す。誤りが検出されたならば、データとＳＮのいずれ
か、または両方にビット誤りが含まれていることが判明
するので、そのデータまたはシーケンス番号が誤りを含
んでいる旨をシーケンス番号確認モジュール５２_rとＦ
ＥＣ訂正モジュール５０_rに通知する。

【０２２８】（Ｈ）シーケンス番号確認モジュール５２
_rによる処理第１の実施例のシーケンス番号確認モジュール１２_rと
ほぼ同様であるが、本シーケンス番号確認モジュール５
２_rでは、ＣＲＣで誤りが検出されずに正しいと保証さ
れたデータに関して、シーケンス番号の部分（受け取っ
た時点では最後の４ビット）を検索していくことによっ
てセル廃棄を検出する。連続でない値が現れたらセル廃
棄があったことがわかる。もしも、セル廃棄が検出され
たならば前後のシーケンス番号を確認の上でＦＥＣ訂正
モジュールに誤り、抜け位置の通知を行うことによって
どのインターリーブ列が廃棄されたのかを知らせる。

【０２２９】（Ｉ）デインターリーブモジュール４８_r
およびＦＥＣ訂正モジュール５０_rによる処理デインターリーブモジュール４８_rについても、第１の
実施例のデインターリーブモジュール８_rの場合と同様
である。

【０２３０】ただし、インターリーブ構造の１列に複数
セルが含まれる様な場合について考えてみる。例えば、
図２９の様にインターリーブ列の１列が３セルに相当し
ている場合には、１セル廃棄されても残りの２セル分が
正しく到着していればその２セル分はインターリーブ構
造の正しい位置に書き込んでやって、１セル分だけダミ
ーデータを補充してやれば良い。この場合には全ての行
のＦＥＣを用いて訂正を行う必要はない。

【０２３１】（Ｊ）アプリケーション処理モジュール４
４_r 第１の実施例のアプリケーション処理モジュール４_rと
同様である。

【０２３２】以上が、受信側端末４２_rにおける処理の
流れである。

【０２３３】ここで、本実施例においても、第１の実施
例で述べたようなライトウエイト転送プロトコルを本発
明のＣＳレイヤよりも上位のレイヤに実装し、必要な場
合に再送制御を行うことによって、データ転送の信頼性
をさらに向上させるようにしても良い。

【０２３４】その場合、さらに、第１の実施例で述べた
ようにして、誤り制御能力の限界値をこえる誤りが発生
した場合、そのことをいち早く感知して、早めに再送制
御などの手段を講じることができるように構成しても良
い。

【０２３５】なお、本第１、第２、および第３の実施例
にて述べた誤り制御方式は、データ転送に限定したもの
ではない。例えば、ＡＡＬタイプ５機能のみがＡＡＬ機
能として実装された端末装置などにおいて、該端末装置
がマルチメディア／コンティニュアスメディア処理機能
（例えば音声や映像の処理機能）を有しており、この機
能を用いたマルチメディア通信機能を実現する場合に、
ＡＡＬタイプ５の処理機能を用いてこのマルチメディア
／コンティニュアスメディア通信を行ってもよい。この
場合に、本実施例にて述べたような誤り制御方式を併用
して用いることも可能である。また、同様に、本第３の
実施例にて述べたようなユーザ定義のＡＡＬタイプを用
いてデータ通信、あるいはマルチメディア／コンティニ
ュアスメディア通信を実現することも可能である点に注
意が必要である。これらの場合にも、低レイテンシにて
高信頼なマルチメディア／コンティニュアスメディア情
報の転送を実現可能になるのは言うまでもない。

【０２３６】また、本発明は上述した各実施例に限定さ
れるものではなく、その要旨を逸脱しない範囲で、種々
変形して実施することができる。

【０２３７】

【発明の効果】以上説明したように本発明によれば、Ａ
ＴＭ通信網で高速データ転送を行う場合にＡＡＬタイプ
５のＣＰＣＳよりも上位のレイヤにインターリーブ構造
とＦＥＣを用いた誤り制御方法を、またはセル単位にシ
ーケンス番号と誤り検出符号を付与したユーザ定義の新
しいＡＡＬタイプを用いることによって、信頼性のある
高スループット、低レイテンシなデータ通信を実現でき
る。

【図面の簡単な説明】

【図１】第１の実施例の処理プロトコルスタックを示す
図

【図２】第１の実施例の送信／受信側両端末の構成を示
す図

【図３】ＡＡＬタイプ５のインターリーブを説明するた
めの図

【図４】インターリーブ構造にて構成されるデータの構
造を示す図

【図５】インターリーブモジュールにて構成される全体
構造を示す図

【図６】インターリーブモジュールで構成される全体構
造を列方向からみた図

【図７】シーケンス番号付与モジュールによる全体構造
の読みだし順を説明するための図

【図８】ＡＡＬタイプ５におけるシーケンス番号の付与
を説明するための図

【図９】１シンボル＝４８オクテットとしたときの符号
化およびセル化方式を説明するための図

【図１０】受信側端末におけるインターリーブ構造再生
の様子の一例を示す図

【図１１】従来の復号処理と本発明の復号処理とを比較
するための図

【図１２】ＡＡＬタイプ５の他のインターリーブを説明
するための図

【図１３】ＡＡＬタイプ５における他のシーケンス番号
の付与を説明するための図

【図１４】ＣＰＣＳレイヤおよびＳＡＲレイヤ処理を説
明するための図

【図１５】コネクション設定の流れの一例を示す図

【図１６】ライトウェイト転送プロトコルを実装した場
合の処理プロトコルスタックを示す図

【図１７】第２の実施例におけるＡＡＬタイプ５のイン
ターリーブを示す図

【図１８】シーケンス番号付与モジュールの第１のイン
ターリーブ構造の読みだし順を説明するための図

【図１９】シーケンス番号付与モジュールにて付与する
シーケンス番号とＣＲＣのフォーマットを示す図

【図２０】シーケンス番号付与モジュールの第２のイン
ターリーブ構造の読みだし順を説明するための図

【図２１】シーケンス番号付与モジュールの第３のイン
ターリーブ構造の読みだし順を説明するための図

【図２２】シーケンス番号付与モジュールの第４のイン
ターリーブ構造の読みだし順を説明するための図

【図２３】ＡＡＬタイプ５のＳＳＣＳ処理を説明するた
めの図

【図２４】ＡＡＬタイプ５ＣＰＣＳ処理を説明するため
の図

【図２５】第３の実施例の処理プロトコルスタックを示
す図

【図２６】第３の実施例の送信／受信側両端末の構成を
示す図

【図２７】本発明に係るＡＡＬタイプＸにおけるインタ
ーリーブ構造への書き込みとＦＥＣ付与を説明するため
の図

【図２８】ＡＡＬタイプＸのＳＡＲヘッダ/ トレイラを
示す図

【図２９】ＡＡＬタイプＸにおけるＦＥＣ訂正を行わな
い部分を説明するための図

【図３０】ＡＡＬ−ＩＤＵとして上位から渡されるビッ
トのデータ列を示す図

【図３１】ＡＡＬタイプ１のオプションのインターリー
ブを説明するための図

【図３２】ＡＡＬタイプ１におけるＣＳレイヤの処理を
説明するための図

【図３３】ＡＴＭセルのＡＴＭヘッダとペイロードを示
す図

【符号の説明】

１ …ＡＴＭ網３ …ＡＴＭ交換機２_t…送信側端末４_t…アプリケーション処理モジュール６_t…ＳＳＣＳ処理モジュール８_t…インターリーブモジュール１０_t…ＦＥＣ付与モジュール１２_t…シーケンス番号付与モジュール１４_t…ＣＰＣＳ処理モジュール１６_t…ＬＩ付与モジュール１８_t…ＣＲＣ付与モジュール２０_t…ＳＡＲ処理モジュール２２_t…ＡＴＭヘッダ付与モジュール２_r…受信側端末４_r…アプリケーション処理モジュール６_r…ＳＳＣＳ処理モジュール８_r…デインターリーブモジュール１０_r…ＦＥＣ訂正モジュール１２_r…シーケンス番号確認モジュール１４_r…ＣＰＣＳ処理モジュール１６_r…ＬＩ確認モジュール１８_r…ＣＲＣ確認モジュール２０_r…ＳＡＲ処理モジュール２２_r…ＡＴＭヘッダ削除モジュール

Claims

【特許請求の範囲】

【請求項１】ＡＴＭアダプテーションレイヤ・タイプ５
のコモン・パート・コンバージェンス・サブレイヤーよ
りも上位のレイヤにて行うＡＴＭ網における誤り制御方
法であって、送信しようとする一続きのデータ列を一定の長さに順次
区切り、それらの先頭を揃えて行方向に並べるととも
に、この区切られた一群のデータごとに所定の誤り制御
符号を付加する第１の手順と、前記第１の手順によってマトリックス状に並べられた全
データを、前記行方向とは垂直な列方向に、順次、所定
のビット数のデータからなる単位データ列として取り出
していく第２の手順と、前記第２の手順によって取り出された各単位データ列の
送信順序を受信側に示す符号を前記単位データ列ごとに
付加した後、前記単位データ列をコモン・パート・コン
バージェンス・サブレイヤーへ渡す第３の手順とを有し
てなることを特徴としたＡＴＭ網における誤り制御方
法。
【請求項２】ＡＴＭアダプテーションレイヤ・タイプ５
のコモン・パート・コンバージェンス・サブレイヤーよ
りも上位のレイヤにて行うＡＴＭ網における誤り制御方
法であって、送信しようとする一続きのデータ列を一定の長さに順次
区切り、それらの先頭を揃えて行方向に並べるととも
に、この区切られた一群のデータごとに所定の第１の誤
り制御符号を付加する第１の手順と、前記第１の手順によってマトリックス状に並べられた全
データを、前記行方向とは垂直な列方向に、順次、所定
のビット数のデータからなる単位データ列として取り出
していく第２の手順と、前記第２の手順によって取り出された各単位データ列の
ＡＴＭセルのペイロード長よりも短い一定長のデータご
とに、この一定長のデータの送信側でのセル送出順を受
信側に示す符号と、この符号および前記一定長ごとのデ
ータの双方のビット誤りを検出するための第２の誤り検
出符号とを挿入する第３の手順とを有してなることを特
徴としたＡＴＭ網における誤り制御方法。
【請求項３】送信しようとする一続きのデータ列をＡＴ
Ｍセル化する際、送信側でのセル単位のセル送出順を受
信側に示す符号と、この符号および前記ＡＴＭセルのデ
ータ部を保護するための誤り制御符号とをセル単位に付
加することを特徴としたＡＴＭ網における誤り制御方
法。