JP2003298560A

JP2003298560A - 送信機および送信方法、受信機および受信方法並びに光無線通信装置および光無線通信方法

Info

Publication number: JP2003298560A
Application number: JP2002102548A
Authority: JP
Inventors: Makoto Akiba; 誠秋葉; Kazuhiko Wakamori; 和彦若森; Masaaki Hanashima; 正昭花嶋
Original assignee: Hamamatsu Photonics KK; Communications Research Laboratory
Current assignee: Hamamatsu Photonics KK; Communications Research Laboratory
Priority date: 2002-04-04
Filing date: 2002-04-04
Publication date: 2003-10-17

Abstract

(57)【要約】【課題】プロトコルに応じてエラー訂正符号化を行う
か否かを切り換えることによって、スループットの低下
を防止し、降雨によるエラーの影響を少なくする。【解決手段】符号化判断部２１がデータに対してエラ
ー訂正符号化するか否かを決定する。ＴＣＰは、確認応
答型通信を使用した再送によるエラー訂正を行うもの
で、エラー訂正符号化回路の演算等による遅延が存在す
ると、スループットが低下する問題が生じるので、エラ
ー訂正符号化を行わない。ＵＤＰの場合では、降雨等に
よるエラー訂正の影響を低減するために、ＲＳ符号化部
２２によりエラー訂正符号化を行う。ＵＤＰであって
も、エラーの影響を受けにくいものは、符号化されな
い。マルチプレクサプロセス部２４は、パケットスケジ
ューラによるタイムスタンプを利用してスケジューリン
グを行い、データを光無線送信部２５に送り、空間伝送
路に対してデータが送出される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、光無線を用いた
ネットワークシステムに適用される送信機および送信方
法、受信機および受信方法並びに光無線通信装置および
光無線通信方法に関する。

【０００２】

【従来の技術】光無線例えば赤外線空間通信を用いたネ
ットワークシステム（以下、光無線ＬＡＮ(Local Area
Network) システムと適宜称する）においては、伝搬路
である空間の状況（例えば降雨や霧など）に応じて伝送
エラーが発生することは避け難い。但し、そうした伝送
中のエラー発生メカニズムやエラー発生のパターンに関
しては明確な解析がなされていない。本願発明者は、屋
外自由空間を伝搬する光の伝搬特性を評価するための実
験を行うことによって、降雨時におけるエラー発生の顕
著な特徴を見出した。

【０００３】最初に、本願発明者が見出した知見に関し
て説明する。屋外の光無線通信においては、伝送路であ
る空間の状態により伝搬される光パワーが減衰し、個々
の装置の所定最低受光量より光パワーが小さくなるとエ
ラーが生じる。霧や豪雨により非常に大きな減衰を生じ
た場合には、完全に通信断となり、この場合は別の通信
回線を利用するか通信断をもたらす事象が回復するのを
待つ以外に方法はない。

【０００４】しかしながら、本願発明者の行ってきた実
験では、回線断に至るほどの光波減衰ではない降雨時に
比較的高い確率でエラー発生が生じていることが確認さ
れた。この事象を詳細に調査したところ、受信強度の平
均値というより揺らぎ量との関係が深く、エラー発生時
には受光レベルが急激に低下する減少を見出した。この
急激な受光強度の揺らぎ（以下ディップと呼ぶ）は、変
動強度（ディップの深さ）によらずほとんど１ms程度の
時間幅であることが分かった。この現象は、波長（我々
の実験では、０．７８μｍ、１．５５μｍ、２．０μｍ
の３波長帯）や伝送レートとの相関もなく生じていた。
本現象のメカニズムに関しては未だ不明ではあるが、降
雨時という天候に強く依存している現象である。

【０００５】図１は、降雨時における１．５５μｍ帯受
信強度変動の一例を示す。図１の受信強度は、６２２Ｍ
bpsのレートを有するパルス信号を平均化したものであ
る。図１は、ある５秒間の測定で最も深いディップを示
すが、ほとんどのディップは同様のプロファイルを持っ
ている。晴天時には、このようなディップが全く発生し
ていない。したがって、ディップが実験装置に起因して
いるのではないと思われる。

【０００６】このディップが実際に通信のエラーを引き
起こしているかどうかを明らかにするために、ビットエ
ラーテスタ（ＢＥＲＴ）からのエラーパルスをトリガと
して、受信パルス信号をそのまま高速デジタルオシロス
コープで取り込む実験も同時に行った。使用した高速デ
ジタルオシロスコープの周波数帯域は４ＧHzであり、５
Ｇサンプル／秒でサンプルした。図２は、図１に比して
時間軸が拡大されたものであり、図２の上の図は、１．
５５μｍ帯の実際のパルス信号であり、下部はＢＥＲＴ
からのエラーパルスである。但し、膨大なデータ量を取
り扱うことを避けるため、何れの図においても、１００
nsecの時間幅でスムージングをし、データ量を減らして
ある。

【０００７】エラーパルスは本来、振幅−１Ｖ、幅１０
nsecの一定出力であるが、スムージングの結果、パルス
が発生する頻度の違いによってそのパルス振幅も幅も違
っている。図２において、振幅が大きいパルスはエラー
がその部分で多いことを示している。エラーの発生や密
度が受信パルス信号強度の低下とよく対応しているのが
分かる。高速デジタルオシロスコープで取得したほとん
どの全ての場合で、この対応が存在している。この結果
ディップがエラーの主因であることが分かった。

【０００８】次にディップの性質を明らかにするため、
その深さと幅の分布を調べた。ディップの深さと幅は、
以下の様にして得た。まず、測定時間（個々の測定につ
いて５秒間）の平均値を連続して下回っている一連のデ
ータに対して最小値を見つけ、その最小値と平均値の差
を深さとする。更に、深さが１／２となる時間間隔を幅
（半値幅）とした。深さの分布を図３に示し、半値幅の
分布を図４にす。但し、深さは平均値で規格化してあ
る。

【０００９】この方法では、特に深さの浅いデータには
電気的ノイズや大気揺らぎなどのディップではない変動
成分が含まれている可能性が高い。従って、図３および
図４では、その分布から判断して、最も深いディップの
深さの１／３を超えたものだけを使用している。図３か
ら分かるように、深さの頻度分布がほぼ指数関数に従っ
ている。また、図４から分かるように、ディップの半値
幅の平均値がほぼ１ｍsecであり、この平均値は、ディ
ップの深さや降雨量、風速などの気象条件にはあまりよ
らない。一方、ディップの深さ分布は降雨量と比例する
傾向にあるが、不定性は大きい。

【００１０】今回に実験により得られた知見にもとづ
き、１ｍsec程度のバースト時間に対する光無線伝送路
上でのエラー訂正符号化およびエラー訂正復号化装置を
構成すれば、光無線回線の品質劣化をもたらす降雨時の
伝送特性向上、すなわち伝搬路上で生じる擾乱の大きな
部分を占める降雨に対する対策として非常に効果的であ
ることが判明した。

【００１１】このような点から図５に示す光無線ＬＡＮ
システムの構築が考えられる。例えばビル間のように、
空間を隔てた二つのネットワークまたはＬＡＮ間で双方
向通信が行われる。また、ＦＴＴＨ(Fiber To The Hom
e)のラストワンマイルソリューションとして光無線を使
用する場合もある。一方のネットワークから他方のネッ
トワークへ送信すべきパケットがリードソロモン符号(R
eed-Solomon code) （以下、適宜ＲＳと称する）の符号
化部４１に入力される。ＲＳ符号化部４１において、リ
ードソロモン符号のエラー訂正符号化がなされる。ＲＳ
符号化部４１の出力データが光無線送信部４２に入力さ
れる。光無線送信部４２には、発光部としてのレーザダ
イオードが含まれ、符号化データパケットに応じて光強
度が変調された送信光が送信される。

【００１２】送信光が空間伝送路を通って受信側の光無
線受信部５３にて受信される。光無線受信部５３には、
送信光を受光し、電気信号に変換する受光部例えばアバ
ランシュダイオードが含まれている。光無線受信部５３
からの受信信号がＲＳ復号化部５４に供給され、リード
ソロモン符号によるエラー検出および訂正がなされる。
ＲＳ復号化部５４から受信データパケットが得られる。

【００１３】他方のネットワークから一方のネットワー
クにデータを伝送する場合には、他方のネットワークの
ＲＳ符号化部５１で符号化されたデータパケットが光無
線送信部５２に供給され、一方のネットワークへ送信さ
れる。光無線受信部４３で受信光が電気信号へ変換さ
れ、ＲＳ復号化部４４に受信信号が入力される。ＲＳ復
号化部４４では、リードソロモン符号を使用したエラー
検出および訂正がなされる。

【００１４】

【発明が解決しようとする課題】しかしながら、上述し
た構成例のように、常にエラー訂正符号化を行うこと
は、降雨によるディップに対するエラーの対策として有
効であるが、プロトコルによっては、問題を生じる。Ｔ
ＣＰ／ＩＰのトランスポートプロトコルには、伝送制御
プロトコルＴＣＰ(Transmission Control Protocol)
と、ユーザ・データグラム・プロトコルＵＤＰ(User Da
tagram Protocol)とがある。

【００１５】ＴＣＰは、メール、ファイル転送、ＷＥＢ
転送等で使用され、スロースタートによる輻輳制御機構
と再送によるエラー訂正を組み合わせた通信プロトコル
で、バイト・ストリーム転送を実現するプロトコルであ
る。ＴＣＰは、受信応答（アクノリッジ）を用いたパケ
ット再送方式をエラー訂正として使用している。アクノ
リッジが返らなかったデータパケットの位置から再び送
信する方式（Ｇｏ−Ｂａｃｋ−Ｎ方式）を採用し、エラ
ーが多い回線では、再送の効率が非常に悪くなる問題が
ある。

【００１６】ＴＣＰでは、データの送り出し側での再送
判断において、実際にパケットが抜けてアクノリッジが
返らなかったのか、或いは遅延によるタイムアウトによ
りアクノリッジが返らなかったのかの判断ができない。
したがって、衛星通信など遅延の大きい遠距離の通信に
おいてＴＣＰを使用する場合、設定によりタイムアウト
値を大きく取り、データパケット１個ずつでアクノリッ
ジが返ってくるのを確認するわけではなく、予めタイム
アウト値までの時間のデータを送ってしまうアルゴリズ
ムを使用している。

【００１７】この予めデータを送ってしまう先送り量の
ことをウィンドウサイズと呼ぶ。ウインドウサイズの設
定をエンドツーエンドでアプリケーション毎に変更し、
最適化する必要がある。しかしながら、通常のアプリケ
ーションでは、初期設定のままとされている。一般に
は、初期値として定義されているウィンドウサイズの値
は、近くのＬＡＮでの場合が定義されているだけであ
り、エンドツーエンドの通信において、経路途中に高遅
延の回線があった場合は、アクノリッジのタイムアウト
によって、未到着と判断されてしまい、エラーがないの
にもかかわらず再送を行うことになり、所定のスループ
ットが出なくなる問題が起こる。スループットが出ない
と、ユーザがアプリケーション自体を遅く感じるような
障害が発生する。

【００１８】リードソロモン等のアルゴリズムを使用し
たエラー訂正のための符号化装置を用いた場合、上述し
た降雨の影響で発生する、１ｍsec分のバーストエラー
を訂正するためにバッファ量を多く取ると、遅延の大き
な衛星回線より多くの遅延時間が発生し、スループット
に影響が出る。実際に、ＴＣＰでのスループット計測で
は、Fast Ethernet（登録商標）(100Ｍbps)回線でも、
４Ｍbitのメモリ容量で４０ｍsecの遅延が生じる。この
場合にスループットは、１００Ｍbps回線であれば、９
０Ｍbps程度の実効転送レートが得られなければならな
いが、実際には数Ｋbpsとなってしまう。なお、スルー
プットは、実際にある時間内に送信できるデータ量を意
味する。

【００１９】一方、ＵＤＰは、信頼性の低いデータグラ
ム・プロトコルである。但し、アプリケーションやネッ
トワーク環境によっては、仮想回線を確立する必要がな
く、データ転送のパスが固定化されないため、柔軟で効
率の良いデータ転送を行うことが可能である。主にＶｏ
ＩＰ(Voice over IP)などのリアルタイム通信で使われ
るＲＴＰ(Real-time Trnsport Protocol)は、ＵＤＰの
一つである。ＵＤＰでは、エラー制御は、ソフトウェア
実装者が行う仕様になっている。

【００２０】一般に、光ファイバー等有線での接続の場
合、エラーが無い状態であり特にエラー訂正を考えなく
ても使えてしまう場合があり、エラー訂正を行わないで
アプリケーションを作成する場合がある。テレビジョン
会議システムや、音声通信等の双方向でのリアルタイム
性の高い通信の場合には、エラー訂正のための再送を行
っている時間がなく、再送なしで通信が行われる。有線
の場合では、エラーが無い状態と考えることができ、特
に問題なくアプリケーションが動くことができる。ま
た、双方向テレビジョン電話の場合は、遅延時間は問題
になるが、ＵＤＰの場合、ＴＣＰのように再送方式のエ
ラー訂正を行わないので、回線の遅延時間が問題となら
ない。これは、アクノリッジを待たないでパケットを送
信するからである。

【００２１】しかしながら、上述した赤外線空間通信
（光無線ＬＡＮ）を使った場合には、エラーが起こりう
る回線のために、エラー訂正を行わないと、従来のアプ
リケーションをそのまま用いたのでは、不具合が出る場
合がある。実際、ＵＤＰ通信でＭＰＥＧ２(Moving Pict
ure Experts Group Phase 2)の映像音声ストリームを流
すアプリケーションの実験を行うと、実験室では有線ケ
ーブルを使って実験した場合には、映像音声ストリーム
を問題なく送ることができ、一方、エラーが発生しうる
光無線ＬＡＮ回線を用いた場合、エラーに応じてシステ
ムリセットやブロックノイズが発生する。すなわち、降
雨により１ｍsecバーストエラーが発生した場合にはデ
ータが全く届いてない状態になり、ＵＤＰでは、エラー
訂正が無いので音声にノイズが混じったりする原因にな
り、また、映像ストリームでエラーに極端に弱いＭＰＥ
Ｇ２などの場合、ブロックノイズ程度ならいいがシステ
ムがリセットするような障害が発生する。

【００２２】以上述べた点から回線エラー訂正のための
エラー訂正符号化装置を導入した場合、遅延時間に関し
てＴＣＰのスループットが出なくなる影響に比べて、Ｕ
ＤＰの通信の方が遅延時間の影響が少ないことが分か
る。

【００２３】したがって、この発明の目的は、伝送プロ
トコルに適応して、エラー訂正符号化を選択的に行うこ
とによって、降雨の影響を軽減すると共に、スループッ
トが低下する問題を解決することができ、それによって
光無線回線の伝送品質を維持することが可能とされた送
信機および送信方法、受信機および受信方法並びに光無
線通信装置および光無線通信方法を提供することにあ
る。

【００２４】

【課題を解決するための手段】上述した課題を解決する
ために、請求項１の発明は、空間を介してデータを通信
する光無線における送信機において、所定のプロトコル
に基づいたデータが入力され、プロトコルがエラー訂正
符号化で生じる遅延が問題とならないものである場合に
は、エラー訂正符号化を行うように制御され、プロトコ
ルがエラー訂正符号化で生じる遅延が問題となるもので
ある場合には、エラー訂正符号化を行わないように制御
されるエラー訂正符号化手段と、エラー訂正符号化手段
によってエラー訂正符号化されたデータおよびエラー訂
正符号化されていないデータの一方を空間伝送路に送出
する光無線送信手段とを備えた送信機である。請求項７
の発明は、プロトコルがエラー訂正符号化で生じる遅延
が問題とならないものである場合には、エラー訂正符号
化を行うように制御され、プロトコルがエラー訂正符号
化で生じる遅延が問題となるものである場合には、エラ
ー訂正符号化を行わないようにする送信方法である。

【００２５】請求項８の発明は、空間を介してデータを
通信する光無線における受信機において、空間伝送路を
介して送信されたデータを受信する光無線受信手段と、
受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、受信デー
タがエラー訂正符号化されたものでない場合には、エラ
ー訂正符号化を行わないように制御されるエラー訂正復
号化手段とを備えた受信機である。請求項１２の発明
は、受信データがエラー訂正符号化されたものてある場
合には、エラー訂正復号化を行うように制御され、受信
データがエラー訂正符号化されたものでない場合には、
エラー訂正符号化を行わないように制御されるエラー訂
正復号化ステップとからなる受信方法である。

【００２６】請求項１３の発明は、空間を介してデータ
を通信する光無線通信装置において、所定のプロトコル
に基づいたデータが入力され、プロトコルがエラー訂正
符号化で生じる遅延が問題とならないものである場合に
は、エラー訂正符号化を行うように制御され、プロトコ
ルがエラー訂正符号化で生じる遅延が問題となるもので
ある場合には、エラー訂正符号化を行わないように制御
されるエラー訂正符号化手段と、エラー訂正符号化手段
によってエラー訂正符号化されたデータおよびエラー訂
正符号化されていないデータの一方を空間伝送路に送出
する光無線送信手段とを備えた送信機と、空間伝送路を
介して送信されたデータを受信する光無線受信手段と、
受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、受信デー
タがエラー訂正符号化されたものでない場合には、エラ
ー訂正符号化を行わないように制御されるエラー訂正復
号化手段とを備えた受信機とからなる光無線通信装置で
ある。請求項１４の発明は、所定のプロトコルに基づい
たデータが入力され、プロトコルがエラー訂正符号化で
生じる遅延が問題とならないものである場合には、エラ
ー訂正符号化を行うように制御され、プロトコルがエラ
ー訂正符号化で生じる遅延が問題となるものである場合
には、エラー訂正符号化を行わないように制御され、受
信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、受信デー
タがエラー訂正符号化されたものでない場合には、エラ
ー訂正符号化を行わないように制御されるエラー訂正復
号化ステップとからなる光無線通信方法である。

【００２７】この発明では、光無線通信システムにおい
て、エラー訂正符号化を導入するとによって、降雨時の
エラーの影響を少なくできる。また、プロトコルがＴＣ
Ｐのように、エラー訂正符号化の遅延が問題となる場合
には、エラー訂正符号化を行わないので、スループット
が低下することを防止できる。

【００２８】

【発明の実施の形態】以下、この発明の一実施形態につ
いて図面を参照して説明する。図６は、この一実施形態
の通信システムの基本的構成を示すものである。一例と
して、二つのネットワークまたはＬＡＮ同士が図６に示
す光無線（赤外線空間通信）によって双方向通信可能に
結合されている。ビル同士の通信のように、光無線は、
屋外の空間を介して行われ、前述したように、降雨によ
って光が散乱し、受信光強度が減衰し、エラーが発生す
る。

【００２９】一方のネットワークから送信データがエラ
ー訂正符号化部１に供給される。エラー訂正符号化部１
は、後述するように、送信データのプロトコルに基づい
て符号化を行うか否かを判断する。エラー訂正符号化部
１の出力（エラー訂正符号化されたデータまたはエラー
訂正符号化されていないデータ）が光無線送信部２に供
給される。光無線送信部２では、発光部例えばレーザダ
イオードによって、電気信号が光に変換され、空間デー
タ通信路にデータに応じて強度が変調された光信号が送
出される。

【００３０】送信された光信号が光無線受信部１３にて
受信される。光無線受信部１３には、受光素子として例
えばアバランシュダイオードが設けられている。光無線
受信部１３からの受信信号がエラー訂正復号化部１４に
供給される。エラー訂正復号化部１４は、送信側でエラ
ー訂正符号化されたデータに対して復号処理を行う。エ
ラー訂正復号化部１４からの受信データが他方のネット
ワークに対して供給される。

【００３１】他方のネットワークから一方のネットワー
クにデータを伝送する場合には、他方のネットワークの
エラー訂正符号化部１１で符号化されたデータパケット
が光無線送信部１２に供給され、一方のネットワークへ
送信される。光無線受信部３で受信光が電気信号へ変換
され、エラー訂正復号化部４に受信信号が入力される。
エラー訂正復号化部４では、送信側でエラー訂正符号化
されたデータに対してエラー検出および訂正がなされ
る。エラー訂正符号化部１および１１は、同一の構成
（機能）を有するものであり、エラー訂正復号化部４お
１４は、同一の構成（機能）を有するものである。光無
線送信部２および１２、並びに光無線受信部３および１
３は、それぞれ同一の構成（機能）を有するものであ
る。

【００３２】エラー訂正符号化部１または１１の一例を
図７に示す。参照符号２１は、ネットワーク上のデータ
（インターネットプロトコルのデータ）を受け取って、
データパケットに対してエラー訂正符号化するか否かを
決定する符号化判断部である。符号化判断部２１によっ
て符号化すると決定されたデータは、リードソロモン符
号(Reed-Solomon code) （以下、適宜ＲＳと称する）符
号化部２２により符号化され、タイムスタンプおよび符
号化スタンプが付けられる。符号化判断部２１によって
符号化なしと決定された場合には、タイムスタンプ付加
部２３にてそのままタイムスタンプが付加される。ＲＳ
符号化は、前述した降雨によるバーストエラーを訂正で
きる程度の能力を持つものである。例えばＲＳ符号化と
インターリーブとが組み合わされることによって、バー
ストエラーを訂正可能としている。

【００３３】符号化判断部２１によって、２経路に分け
られたものがマルチプレクサプロセス部２４によって一
つの経路に戻される。マルチプレクサプロセス部２４
は、パケットスケジューラによるタイムスタンプを利用
してスケジューリングを行い、データを光無線送信部２
５に送る。光無線送信部２５によって、空間伝送路（光
無線伝送路）に対して、符号化データパケットが送出さ
れる。

【００３４】さらに、この発明の一実施形態について詳
述する。符号化判断部２１は、入力されるネットワーク
データパケットを分析することによって、エラー訂正符
号化を行うか否かを決定する。エラー訂正符号化のため
に生じる遅延の影響を受けるプロトコルの場合では、エ
ラー訂正符号化を行わない。一方、エラー訂正符号化の
ために生じる遅延の影響を受けないプロトコルの場合で
は、エラー訂正符号化を行う。

【００３５】一実施形態では、ネットワークがインター
ネットプロトコルＴＣＰ／ＩＰの場合である。ＴＣＰ／
ＩＰの場合では、ＴＣＰとＵＤＰのように、トランスポ
ートプロトコルが別に規定されている。ＴＣＰは、確認
応答型通信（アクノリッジ）を使用した再送によるエラ
ー訂正を行うもので、エラー訂正符号化回路の演算等に
よる遅延が存在すると、スループットが低下する問題が
生じる。したがって、ＴＣＰの場合では、エラー訂正符
号化を行わない。

【００３６】一方、ＲＴＰ、ＶｏＩＰ等のＵＤＰの場合
では、システム遅延が２００ｍsec程度が許容されてお
り、エラー訂正符号化回路の遅延の影響を受けない。こ
のようなプロトコルの場合では、降雨等によるエラー訂
正の影響を低減するために、エラー訂正符号化する。但
し、ＵＤＰであっても、エラーの影響を受けにくいもの
は、符号化されない。例えば、データによっては、ある
程度のバーストエラー（パケットロス）を計算にいれた
アプリケーション（ＤＶ(Digital Video)伝送やＭＰＥ
Ｇ４バージョン２）があり、この場合には符号化装置を
通さなくてもいい。ＵＤＰであってもエラーの影響を受
けにくいデータを符号化しないことによって、スループ
ットを高くすることができる。

【００３７】符号化判断部２１は、アプリケーション毎
に異なるポート番号や実際のデータの内容に関してパケ
ットの内容判断を行う。サーバソフトウェア側でＴＣＰ
とＵＤＰに関するフラグに加えて、アプリケーションご
とに使用するポート番号を変更し、これを符号化判断部
２１により検知することによって、プロトコルに基づい
て、符号化するか否かを判断することができる。さら
に、データの内容によって符号化するか否かを判断する
ことができる。例えば下記は、ＵＤＰの中のリアルタイ
ム転送プロトコルＲＴＰの例である。

【００３８】ｒｔｐ：／／ｗｗｗ．ｘｘｘｘ．ｃｏｍ／
ｄａｔａ．ｍｐ４（ＭＰＥＧ−４であるためエラーに強いので符号化装置
を通さない）ｒｔｐ：／／ｗｗｗ．ｘｘｘｘ．ｃｏｍ／ｄａｔａ．ｍ
ｐ２（ＭＰＥＧ−２であるためエラーに影響されるので符号
化装置を通す）なお、データ転送開始時に符号化を行うか否かの判断を
行い、その結果に基づいて設定することも可能である。

【００３９】マルチプレクサプロセス部２４は、データ
スケジューラとしての機能を有する。マルチプレクサプ
ロセス部２４は、もともと一つの伝送路上に流れてきた
データをエラー訂正のための符号化装置を通すか通さな
いかで２経路に分けるので、１経路に戻す機能を有す
る。符号化データと非符号化データをひとつの光無線伝
送路上を用いて通信するためにマルチプレクスする機能
で、伝送路上で符号化判断部２１が受信時刻によってタ
イムスタンプ（受信番号）を付けてタイムスタンプ順に
戻す処理を行う。または、マルチプレクサプロセス部２
４が以下のようなデータごとの優先順序にしたがってス
ケジューリングを行い、データを出力するようにしても
良い。

【００４０】一例として、アプリケーションにより優先
順序が付加される。すなわち、１）符号化による遅延時間有りの場合ＴＶ電話等リアルタイムアプリケーション優先度高い蓄積型ビデオなどのリアルタイムでないアプリケーション優先度低い２）符号化による遅延時間無しの場合再送型プロトコル（ＴＣＰ／ＩＰなど）優先度高いとされる。

【００４１】このときＴＣＰ／ＩＰは、バースト性が高
く帯域保証（ＱＯＳ）を行わないと、テレビジョン電話
等のリアルタイムアプリケーションとの組み合わせで不
具合が生じるので、帯域保証機構を併用するとが好まし
い。例えばＣＢＱ（クラスベースキューイング）などを
利用したスケジューリング機構を使用することができ
る。

【００４２】符号化判断部２１と、ＲＳ符号化部２２ま
たはタイムスタンプ付加部２３とは、上述したように、
符号化するか否かの判断を行い、必要なフラグを付加し
たデータを出力する。優先順位を付ける場合では、優先
順位のフラグも付加される。符号化しない場合では、フ
ラグとして、マルチプレクサプロセス部２４のための受
信番号フラグ（タイムスタンプ）と、分類番号フラグ
（優先分類）とが非符号化パケットデータに対して付加
される。光無線伝送路上では、非符号化データパケット
が伝送される。

【００４３】符号化を行うと判断され、ＲＳ符号化部２
２を通過したデータの場合では、フラグとして、マルチ
プレクサプロセス部２４のための受信番号フラグ（タイ
ムスタンプ）と、分類番号フラグ（優先分類）とが符号
化データパケットに対して付加される。光無線伝送路上
では、符号化後のデータパケットが伝送される。

【００４４】マルチプレクサプロセス部２４は、上述し
たように、受信番号フラグおよび優先分類フラグを用い
て時間的優先およびアプリケーションによる優先順位に
より、再スケジューリングを行い、データパケットを光
無線送信部２５を介して光無線伝送路上に出力する。

【００４５】図８は、送信側をソフトウェアによって実
現する場合のフローチャートである。送信側の構成は、
全てハードウエアで実現可能であるが、一部または全部
の機能をソフトウェアによって実現することもできる。
ネットワークからのデータパケットがパケット受信プロ
セス（ステップＳ１）により受信され、符号化判断プロ
セス（ステップＳ２）により符号化するか否かが判断さ
れる。上述したように、ネットワークからのデータのプ
ロトコルに基づいて符号化するか否かが決定される。す
なわち、ステップＳ２では、ＴＣＰのような符号化の遅
延の影響を受けるプロトコルの場合では符号化せず、Ｕ
ＤＰであって、符号化の遅延の影響を受けないプロトコ
ルの場合では符号化を行い、ＵＤＰであても、エラーの
影響を受けにくいものは、符号化をしないと判断され
る。

【００４６】ステップＳ２において符号化すると決定さ
れると、ステップＳ３の符号化プロセスでデータがエラ
ー訂正符号化され、ステップＳ４で符号化データがマル
チプレクス処理を受ける。符号化しない場合では、ステ
ップＳ３がスキップされ、ステップＳ４でマルチプレク
ス処理を受ける。マルチプレクス処理がなされると、光
無線送信プロセスのステップＳ５に処理が移行する。マ
ルチプレクス処理では、上述した受信番号フラグおよび
優先分類フラグを使用してスケジューリングの処理がな
される。図８では省略されているが、送信すべきデータ
が残っているか否かの判断がなされ、送信すべきデータ
がなくなったら送信処理が終了する。

【００４７】図９は、受信部のデータの内容により符号
化の判断を行うようにされた復号化部１４の構成例を示
す。符号化データパケットが光無線受信部１３により受
信され、デマルチプレクサプロセス部３１に送られ、復
号化判断部３２により符号化されているか否かが判断さ
れる。符号化されているデータの場合は、ＲＳ復号化部
３３に送られ、エラー訂正処理がなされる。符号化され
ていないデータの場合は、タイムスタンプを除かれ、元
のデータに戻され、それぞれマルチプレクサプロセス部
３４に送られてネットワークに送られる。

【００４８】復号化判断部３２は、送られてきたデータ
のフォーマットを判断することによって、復号化するか
否かを判断する。受信したデータが符号化されていない
データの場合には、ＩＰ（インターネットプロトコル）
のパケットフォーマットを使用している。したがって、
ＩＰのパケットフォーマットであるか否かを調べること
によって、符号化されているか否かの判断を簡単になし
うる。すなわち、符号化されているデータの場合は、Ｉ
Ｐパケットになっていない。また、フォーマットに基づ
く判断に限らず、符号化されていればデータ長も長くな
っているので、データ長を調べることによって符号化さ
れているか否かを判断できる。

【００４９】図１０は、受信側をソフトウェアによって
実現する場合のフローチャートである。受信側の構成
は、全てハードウエアで実現可能であるが、一部または
全部の機能をソフトウェアによって実現することもでき
る。ステップＳ１１において、光無線伝送路を介して送
信されてきたデータが受信される。受信データがステッ
プＳ１２において、デマルチプレクスプロセスの処理を
受け、ステップＳ１３において、符号化されているか否
かが判断される。

【００５０】ステップＳ１３において、上述したよう
に、データのフォーマットまたはデータの長さに基づい
て符号化されているか否かが判断される。符号化されて
いると決定された場合では、ステップＳ１４の復号化処
理を受け、リードソロモン符号の復号化がなされる。使
用されているリードソロモン符号のエラー訂正能力の範
囲内のエラーが訂正される。エラー訂正能力を超えるほ
ど長いバーストエラーが発生すると、訂正不能となる。
受信データに対しては、所定長例えばパケット毎にエラ
ーフラグが付加され、エラーが無いかまたはエラーが訂
正された場合と、エラーが訂正できなかった場合とがエ
ラーフラグで示される。復号化処理されたデータがステ
ップＳ１５においてパケット送信プロセスの処理を受け
る。

【００５１】ステップＳ１３において、符号化されてい
ないと決定された場合では、ステップＳ１４（復号化プ
ロセス）がスキップされ、ステップＳ１５において、パ
ケット送信プロセスの処理を受ける。パケット送信プロ
セスでは、２つの異なったタイミングで入ってきたデー
タをマルチプレクスしてネットワークパケットとしてネ
ットワークに送信する。

【００５２】この発明は、上述したこの発明の一実施形
態等に限定されるものでは無く、この発明の要旨を逸脱
しない範囲内で様々な変形や応用が可能である。例えば
エラー訂正符号の例としてリードソロモン符号を使用し
たが、バーストエラーに比較的強い方式であれば、リー
ドソロモン符号に以外のエラー訂正符号化を使用でき
る。また、複数のエラー訂正符号化を組み合わせた方式
のエラー訂正符号化を使用しても良い。

【００５３】

【発明の効果】この発明においては、屋外の空間を伝送
路とする光無線において、ＵＤＰのようなエラー訂正符
号化による遅延が問題とならないプロトコルに基づいた
リアルタイムアプリケーションの場合では、数ｍsecの
バーストエラーを訂正できるようにエラー訂正符号化し
ているので、降雨等によるエラーの影響を軽減でき、伝
送データの品質を向上することができる。また、この発
明では、ＴＣＰのようなエラー訂正符号化による遅延が
問題となるプロトコルに基づいたリアルタイムアプリケ
ーションの場合では、エラー訂正符号化をしないので、
スループットが低下することを防止できる。

【００５４】光無線は、今後、ＦＴＴＨのラストワンマ
イルソリューション等の応用分野がさらに広がると考え
られる。ラストワンマイルソリューションでは、ＴＣＰ
による非リアルタイム性データばかりでなく、音声や映
像などのリアルタイム性の高いストリームデータも多く
発生すると予想される。そのため、リアルタイム性が高
く再送機能のないＵＤＰ／ＩＰプロトコルに対して、こ
の発明のようなエラー訂正符号化およびエラー訂正復号
化を導入することはネットワークの信頼性を大きく向上
させることができる。

【図面の簡単な説明】

【図１】降雨時の受信強度変動の一例を示す略線図であ
る。

【図２】誤りパルスと図１の一部を拡大して示す略線図
である。

【図３】受信強度中に生じるディップの深さの分布を示
す略線図である。

【図４】受信強度中に生じるディップの幅の分布を示す
略線図である。

【図５】従来考えられる光無線システムの一例の構成を
示すブロック図である。

【図６】この発明が適用された光無線システムの全体的
な構成を示すブロック図である。

【図７】この発明が適用されたエラー訂正符号化部の一
例の構成を示すブロック図である。

【図８】この発明が適用された光無線システムの送信側
の処理の流れを示すフローチャートである。

【図９】この発明が適用されたエラー訂正復号化部の一
例の構成を示すブロック図である。

【図１０】この発明が適用された光無線システムの受信
側の処理の流れを示すフローチャートである。

【符号の説明】１，１１・・・エラー訂正符号化部、２，１２・・・光
無線送信部、３，１３・・・光無線受信部、４，１４・
・・エラー訂正復号化部、２１・・・符号化判断部、２
２・・・ＲＳ符号化部、３２・・・復号化判断部、３３
・・・ＲＳ復号化部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｂ 10/14 10/22 Ｈ０４Ｌ 29/06 (72)発明者若森和彦静岡県浜松市市野町1126番地の１浜松ホトニクス株式会社内 (72)発明者花嶋正昭静岡県浜松市市野町1126番地の１浜松ホトニクス株式会社内Ｆターム(参考） 5K014 AA01 BA08 FA11 5K034 DD01 EE01 EE03 HH01 HH09 HH63 MM01 5K102 AA21 AA69 AB09 AH22 AL11 AL21 KA12 KA39 MH03 MH32

Claims

【特許請求の範囲】

【請求項１】空間を介してデータを通信する光無線に
おける送信機において、所定のプロトコルに基づいたデータが入力され、上記プ
ロトコルがエラー訂正符号化で生じる遅延が問題となら
ないものである場合には、エラー訂正符号化を行うよう
に制御され、上記プロトコルが上記エラー訂正符号化で
生じる遅延が問題となるものである場合には、エラー訂
正符号化を行わないように制御されるエラー訂正符号化
手段と、上記エラー訂正符号化手段によってエラー訂正符号化さ
れたデータおよびエラー訂正符号化されていないデータ
の一方を空間伝送路に送出する光無線送信手段とを備え
た送信機。
【請求項２】請求項１において、入力データがネットワークから供給される送信機。
【請求項３】請求項１において、上記エラー訂正符号化は、降雨による受信強度の減衰で
発生するバーストエラーを訂正可能である送信機。
【請求項４】請求項１において、上記プロトコルがインターネットプロトコルであって、
ＴＣＰの場合にエラー訂正符号化を行わない送信機。
【請求項５】請求項１において、上記プロトコルがインターネットプロトコルであって、
ＵＤＰの場合にエラー訂正符号化を行う送信機。
【請求項６】請求項５において、上記プロトコルがＵＤＰの場合で、且つエラーの影響を
受けにくいものである場合に、エラー訂正符号化を行わ
ない送信機。
【請求項７】空間を介してデータを通信する光無線に
おける送信方法において、所定のプロトコルに基づいたデータが入力され、上記プ
ロトコルがエラー訂正符号化で生じる遅延が問題となら
ないものである場合には、エラー訂正符号化を行うよう
に制御され、上記プロトコルが上記エラー訂正符号化で
生じる遅延が問題となるものである場合には、エラー訂
正符号化を行わないように制御されるエラー訂正符号化
ステップと、上記エラー訂正符号化されたデータおよびエラー訂正符
号化されていないデータの一方を空間伝送路に送出する
光無線送信ステップとからなる送信方法。
【請求項８】空間を介してデータを通信する光無線に
おける受信機において、空間伝送路を介して送信されたデータを受信する光無線
受信手段と、受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、上記受信
データがエラー訂正符号化されたものでない場合には、
エラー訂正符号化を行わないように制御されるエラー訂
正復号化手段とを備えた受信機。
【請求項９】請求項８において、上記エラー訂正復号化手段の出力データがネットワーク
に供給される送信機。
【請求項１０】請求項８において、上記エラー訂正符号化がされたものか否かを上記受信デ
ータのフォーマットに基づいて判断する受信機。
【請求項１１】請求項８において、上記エラー訂正符号化がされたものか否かを上記受信デ
ータのデータ長に基づいて判断する受信機。
【請求項１２】空間を介してデータを通信する光無線
における受信方法において、空間伝送路を介して送信されたデータを受信する光無線
受信ステップと、受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、上記受信
データがエラー訂正符号化されたものでない場合には、
エラー訂正符号化を行わないように制御されるエラー訂
正復号化ステップとからなる受信方法。
【請求項１３】空間を介してデータを通信する光無線
通信装置において、所定のプロトコルに基づいたデータ
が入力され、上記プロトコルがエラー訂正符号化で生じ
る遅延が問題とならないものである場合には、エラー訂
正符号化を行うように制御され、上記プロトコルが上記
エラー訂正符号化で生じる遅延が問題となるものである
場合には、エラー訂正符号化を行わないように制御され
るエラー訂正符号化手段と、上記エラー訂正符号化手段によってエラー訂正符号化さ
れたデータおよびエラー訂正符号化されていないデータ
の一方を空間伝送路に送出する光無線送信手段とを備え
た送信機と、上記空間伝送路を介して送信されたデータを受信する光
無線受信手段と、受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、上記受信
データがエラー訂正符号化されたものでない場合には、
エラー訂正符号化を行わないように制御されるエラー訂
正復号化手段とを備えた受信機とからなる光無線通信装
置。
【請求項１４】空間を介してデータを通信する光無線
通信方法において、所定のプロトコルに基づいたデータが入力され、上記プ
ロトコルがエラー訂正符号化で生じる遅延が問題となら
ないものである場合には、エラー訂正符号化を行うよう
に制御され、上記プロトコルが上記エラー訂正符号化で
生じる遅延が問題となるものである場合には、エラー訂
正符号化を行わないように制御されるエラー訂正符号化
ステップと、上記エラー訂正符号化されたデータおよびエラー訂正符
号化されていないデータの一方を空間伝送路に送出する
ステップと、上記空間伝送路を介して送信されたデータを受信する光
無線受信ステップと、受信データがエラー訂正符号化されたものてある場合に
は、エラー訂正復号化を行うように制御され、上記受信
データがエラー訂正符号化されたものでない場合には、
エラー訂正符号化を行わないように制御されるエラー訂
正復号化ステップとからなる光無線通信方法。