FEC(前方誤り訂正,forward error correction:受信者が自分だけで受け取ったデータに符号誤りがあるかどうかを確認し,もし符号誤りがあればそれを自分だけで訂正することができる技術)がもしなかったら,データをセリアル(順序だてて)に送信することはできないでしょうか。なぜならば、受信側は、FECがなければ正しく受け取ったかどうかを自分では判定できないから。


逆に、セリアル送信が可能であるのは、FECの技術が確立したからと考えてよいでしょうか。

回答の条件
  • 1人2回まで
  • 登録:2010/01/04 14:33:47
  • 終了:2010/01/11 14:35:02

回答(3件)

id:jeanjean No.1

jeanjean回答回数64ベストアンサー獲得回数32010/01/04 16:31:38

ポイント30pt

FECが無くても、TCP/IPを使えばパケットに通し番号が付いているのでデータをシリアル(セリアル)に送信する事は可能です。例えば映像を送信する場合、TCP/IPでデータを送信すると全てのデータは確実に送信できる一方リアルタイムでデータを送るには不向きなので、UDPで送信する事になります。この場合FECなどで誤り訂正を付けることで一定のエラーから回復する事ができるようになっています。

通信路にパケットロスが無い場合は、FECは必用ないでしょう。また、データの到着順を正しく整える事はFECに寄らなくても、データのパケット内にシリアル番号として持てば良いので、FECがシリアル通信に必須とは思えません。

どんなデータで、どんな通信路を想定しているのかが分かると、もう少し具体的な話ができるかもしれません。

id:ShinRai

ありがとうございます。

ノン・リアルタイムであれば、TCP/IPで、パケットに通し番号がついた状態で送ることができるわけですね。パケット通信だからそういうことができるわけですね。


そして、リアルタイムで送りたければFECが役に立つ。

基本的に受け手が、自分で、パケットロス、あるいは符号誤りを判断する方法というのにはどういう技術があるのでしょうね。


想定しているのは、ヒトの言語、mRNAといった多値デジタル通信です。

2010/01/04 16:50:57
id:jeanjean No.2

jeanjean回答回数64ベストアンサー獲得回数32010/01/04 17:44:11

ポイント30pt

>想定しているのは、ヒトの言語、mRNAといった多値デジタル通信です。

おお、なんと学術系のデータ通信なんでしょうか、面白そうですね。


FECというと、汎用で低いレベル(パケットレベル)で誤り訂正を行うもので、CDやDVDの誤り訂正なんかも何らかの参考になるかもしれません。


  • 「受け手が、自分で、パケットロス、あるいは符号誤りを判断する」

送信者がFECなどを使って無くても、受け手が自力でパケットロスや符号誤りを判断させるとすると、人の言語であれば文字化けや変な言葉づかいで判断するしかなく、mRNAならきっと見た目で判断するのは難しいんでしょうね。


やはり送信側でFECや、Zipファイルでも使われているようなCRC値のチェックが必用で、受信側は送信側で決めた手続きに従って、検査を行ってデータを使う事になると思います。


ひょっとして、誤り訂正もできる RAR圧縮 でファイル送信させるのが簡単でよかったりして・・・・

id:ShinRai

ありがとうございます

言語もRNAもそれ自体がデジタル通信であるので、どうして一次元配列の順序だったデータを送っているのか、興味があるのです


「昔々あるところに」が開始コドンで、「めでたし、めでたし」が終止コドン、この二つのコドンの間はお話が詰まっている、てな感じかなあ

文法とプロトコルって似てますね

2010/01/04 18:00:36
id:rafile No.3

rafile回答回数662ベストアンサー獲得回数242010/01/06 15:46:49

ポイント20pt

FECは検出の技術ではないですよ。

検出し訂正する方法です。

誤りを検出した後に、再送を要求する方法もあります。

たとえば、

「今日はでんパできたよ」

まず、この日本語がおかしいことを検出して、

でんパ?ああ、電車で来たんかな?とか、ああ電話出来たんかなとか、口調とかも踏まえて理解するのがFEC。

「え、何?」と問い返すのが再送です。

言語はかなり冗長性があるので、訂正はたやすいかと思います。mRNAはよくわかりませんが、「え、何?」って聞けそうにはないですね

id:ShinRai

ありがとうございます。

たしかにFECは、受信側が検出して、自前で訂正できるのですね。

きわめてノイジーな環境であり、そもそも送信者に連絡が取れない一方通行の通信であるのに、再送要求しなくても大丈夫

なのですよね。

クリックのいうセントラル・ドグマの世界といえるでしょうか。(RNA)

言語の場合には、デジタル信号が多値(音節数112)であるから、雑音耐性のある符号語を作ることが容易である。

それは、構音・聴覚の離散性が高いとか、耳になじみやすいとかあるでしょうが、そもそも音表象(サウンドシンボリズム)

的なオノマトペとして言葉が生まれたということもあるのでしょう。

2010/01/07 10:28:43
  • id:jeanjean
    「文法とプロトコル」確かに似ていますね。 映像のリアルタイム転送ではパケットはUDPレベルのものを使っていましたがそこから上のレイヤーでは独自のプロトコルを使ってまして、最外郭にFEC、その次にシリアルナンバーなどのメタデータの層があり、さらに中に映像パケットがありました。FECで映像を復元できなかった場合でもシリアルナンバーによって映像の遅延が起こることを防いでいたりする仕組みがあったりしました。


    デジタルの場合ですと、TCP/IPだと割とOS任せやドライバ任せの通信でプロトコルをデザインすることは無いんですが、UDPで通信する技術を紐解くと、一次元配列の順序だったデータを送っている手法についても何か参考になるものが出てくるかも知れません。


    Webで検索すると、猿でも分かる簡単な説明しか出てきませんがオライリーの「詳説イーサネット」あたりが読み物としても面白かったと思います。
  • id:h_kondo
    >基本的に受け手が、自分で、パケットロス、あるいは符号誤りを判断する方法というのにはどういう技術があるのでしょうね。
    ish.com パソコン通信の時代にお世話になったツールです。
    http://www.vector.co.jp/soft/dos/util/se003701.html
    エラー訂正機能の無い通信環境でのバイナリーファイルの受け渡しによく使われました。
  • id:ShinRai
    jeanjeanさん、ありがとうございました。
    「詳説イーサネット」絶版なのですね。
    興味をもちました。地元の大学図書館にあったので一度読みたいと思います。

    FECはそもそも、深宇宙探査技術で、きわめて雑音の多い環境で、一度きりの送信ですませるために利用されたということをある方に伺いました。

    普通のデジタル通信は、そこまでノイズの多い環境では使わなかったのでしょう。

    しかし、適応符号化変調方式の時代に、マージンをすべて通信速度に置き換えるためにFECが使われるようになったのだと思います。


    シャノンは、符号化には時間がかかりすぎるから実用化できないといったのですが、60年以上前のことですからね
  • id:ShinRai
    h_kondoさん

    エラー訂正(および検出)機能のない通信環境では、
    ひたすら雑音が少ないことをお祈りして、
    全データが無事に伝送されることを神様にお願いする
    しかないのでしょうか

    誤り訂正符号は、そのような状況においては救世主になりますか
  • id:h_kondo
    ish.comを使った場合は多少の通信エラーならば許容できるようになります。
    ish.comのドキュメントより
     データの転送誤りの検出に CRC(巡回符号)を用いており、万一転送エラーが発
    生した場合にはほぼ完全にエラーを検出します。この場合、エラーの発生が少ない
    とき(62~72行に対して2行以内のエラーしか発生しない場合)には自動的にエラー
    訂正を行い完全に復元します。エラーが頻繁に発生したときには、エラー訂正がで
    きないので、エラーの発生箇所を表示し、復元できなかったファイルを自動的に消
    去します。したがって、受信したプログラムなどが正常に動作しない場合にデータ
    転送時のエラーが原因なのかプログラム自体のミス(バグ)によるものなのか悩む
    心配がありません。
  • id:nasi-goreng
    2値デジタルのエラー訂正手法をそのまま、多値デジタルのエラー通信に持ち込むのは無理がありませんか?

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません