JPWO2002089413A1 - 通信装置及びこの通信装置によって構成される通信システム - Google Patents
通信装置及びこの通信装置によって構成される通信システム Download PDFInfo
- Publication number
- JPWO2002089413A1 JPWO2002089413A1 JP2002586576A JP2002586576A JPWO2002089413A1 JP WO2002089413 A1 JPWO2002089413 A1 JP WO2002089413A1 JP 2002586576 A JP2002586576 A JP 2002586576A JP 2002586576 A JP2002586576 A JP 2002586576A JP WO2002089413 A1 JPWO2002089413 A1 JP WO2002089413A1
- Authority
- JP
- Japan
- Prior art keywords
- communication device
- unit
- time
- packet
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
ネットワークシステムで各局がメディアアクセスできる基本周期を予め決めてしまうことで、制御局において簡単なアルゴリズムで各局のメディアアクセス制御を実現でき、誤り訂正符号と誤り訂正符号化ブロック単位の再送及び暗号化を行うことにより、送信局及び受信局において最小の帯域で信頼性の高く且つプライバシを保護する通信を実現でき、帯域制御フレームによる時刻合わせによって、送信局と受信局との間で発生するＡＶソースパケットのジッタを最小に抑え、どの局でＡＶソースが再生されても違和感なく鑑賞が可能になる。
Description
技術分野
本発明は、リアルタイムＡＶデータの転送を行う無線通信方式および装置、特にＩＥＥＥ８０２．１１無線通信方式および装置に関わる。
背景技術
ＩＥＥＥ８０２．１１無線通信方式は、本来無線ＬＡＮのために規格化された標準である。
この方式では、一定周期で衝突が発生する可能性がある区間（Ｃｏｎｔｅｎｔｉｏｎ Ｐｅｒｉｏｄ：ＣＰ）と衝突が生じない区間（Ｃｏｎｔｅｎｔｉｏｎ Ｆｒｅｅ Ｐｅｒｉｏｄ：ＣＦＰ）が入れ替わることを特徴とし、衝突が発生する区間は主にＬＡＮの用途に、衝突が生じない区間は通信帯域の確保を必要とする通信のために使うことができる。
第３０図は、従来のＩＥＥＥ８０２．１１のＰＣＦ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という機能を使用したときにＣＦＰとＣＰの発生する区間を時間軸で示した図である。
ＣＦＰではＰＣ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｏｒ）と呼ばれる特定の端末が、ＣＦＰを利用する端末をポーリングすることにより、通信帯域の確保を行う。ＰＣは、各端末の時刻合わせなどを行うための情報（ＴＩＭと呼ばれる）をＢｅａｃｏｎと呼ばれるフレームに載せて一定間隔で送信する。送信されるＢｅａｃｏｎのうち数回に１回の割合で、スリープ状態の端末に対する通知情報（ＤＴＩＭと呼ばれる）を含むＢｅａｃｏｎが送られる。スリープしている端末はＤＴＩＭを含むＢｅａｃｏｎが送信される時刻のあたりになるとアクティブ状態になり、ＤＴＩＭを含むＢｅａｃｏｎを受信し必要な通信を行うと再びスリープ状態に入る。
ＣＦＰはＤＴＩＭを含むＢｅａｃｏｎに続いて発生し、次のＢｅａｃｏｎが送信されるまでには終了する。ＩＥＥＥ８０２．１１におけるＢｅａｃｏｎの送信周期は、例えば１００ｍｓ程度の値の場合がある。
しかしながら、ＣＦＰを使って、ＤＶＣまたはＭＰＥＧ２−ＴＳなどのリアルタイムＡＶデータを送信する場合、この周期が問題になる。ＤＶＣの標準画像は３０Ｍｂｐｓ、ＭＰＥＧ２−ＴＳは標準で６Ｍｂｐｓ、高画質モードで２４Ｍｂｐｓの転送レートで連続的または継続的に送信局に入力されつづける。しかし、送信の機会、即ち、従来のＩＥＥＥ８０２．１１においてＣＦＰが発生する間隔は数１００ｍｓに一回と非常に長く、その間に入力される膨大なソースパケットをバッファリングしなければならない。更に、数回のＢｅａｃｏｎ周期のうち１周期にしかＣＦＰが存在しないため、たとえ現在規格化が進められているＩＥＥＥ８０２．１１ａ ５ＧＨｚ物理層（物理転送速度最大５４Ｍｂｐｓ）を用いても、ＡＶデータの転送に必要な帯域を確保することが困難である。
又、有線メディアに比べ信頼性が劣る無線メディアでは、通信路上でエラーやパケット消失が発生しやすい。現在のＩＥＥＥ８０２．１１ＭＡＣ層は誤り訂正符号もパケット消失符号もないため、通信路上でエラーが発生した場合、パケットの再送が必要である。しかしながら、ＣＦＰは数１００ｍｓ周期に一回しか発生せず、且つ再送待機中にもリアルタイムＡＶデータは刻々と入力されつづける。従って、再送を行うには更に数１００ｍｓ分のデータを保持するバッファが必要になる。
更に、この周期は、ユーザーに対し、遅延という形で現れる。このため、ユーザーが流れてくるＡＶデータに対して、停止、巻き戻しなどのコマンドを発行しても、即座に反映できないという問題がある。
上記問題を解決するためにＢｅａｃｏｎの間隔を短くすることは、即ち、スリープしている端末に対してより多くのアクティブ状態を強いることになるため、難しい。
このため、リアルタイムＡＶデータ伝送のようなＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）通信をＩＥＥＥ８０２．１１において実現するための規格化を行っているＩＥＥＥ８０２．１１ｅでは、２００１年３月現在、ＨＣＦ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という手法が提案されている。ＰＣＦでは数回に１回のＢｅａｃｏｎ周期でしか衝突が生じない区間がなかったのに対し、ＨＣＦでは自由に衝突が生じない区間を設けることができる。この方式では、周期的なデータ送信を希望する送信局が制御局（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｏｒ：ＨＣ）に対し、メディアアクセス周期及びメディアアクセス時間の要求を行い、それを認めた制御局は、ＣＦＰ、ＣＰに関わらず、帯域確保フレームを定期的に送信局に送信（ポーリング）することで衝突が発生しない区間を生成する。
従来のＩＥＥＥ８０２．１１のＣＦＰにおいては、一般にＨＣがＰＣを兼ねるため、ＰＣＦを搭載した従来のＩＥＥＥ８０２．１１通信機器に通信を妨害されることはない。
従来のＩＥＥＥ８０２．１１のＣＰにおいては、従来のＩＥＥＥ８０２．１１通信装置はＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という機能を使って通信を行う。ＤＣＦでは、送信を開始する前にＤＩＦＳ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる３４μｓの待機時間とランダムバックオフで定められた時間だけキャリアセンスするＣＳＭＡ／ＣＡ方式が用いられる。
これに対し、ＨＣＦを備えた制御局（ＨＣ）はＣＦＰ、ＣＰに関わらずＰＩＦＳ（ＰＣＦ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる２５μｓの時間間隔だけキャリアセンスすればメディアアクセスが可能になる。又、制御局（ＨＣ）にポーリングされた被制御局はＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる１６μｓの時間間隔だけキャリアセンスするだけで送信を開始できる。このため、ＨＣＦ機能を搭載した機器が通信を開始すると、ＤＣＦで動作する従来の局はメディアアクセスができなくなり、ＨＣＦを備えた制御局（ＨＣ）、被制御局は従来の局に妨害されることなく通信できる。
しかしながら、ＰＣＦではＰＣが決めたＢｅａｃｏｎ間隔に基づき各送信局が動作していたのに対し、現在提案されているＨＣＦでは各送信局が、それぞれ、ＨＣに対しメディアアクセス周期（ポーリング周期）及びメディアアクセス周期内での通信を行うための時間を要求する。このため、ＨＣは、複雑な各送信局のメディアアクセススケジューリングをしなければならない。
又、無線メディア上で発生した誤りに対し再送を行う場合、再送用の帯域を別途確保しておく必要がある。この再送による負担を減らすために、現在誤り訂正符号（リードソロモン符号）を使用する提案も行われている。このリードソロモン符号が用いられる場合、パケットが複数のブロックに分割されて、各ブロック毎にリードソロモン符号化が成される。よって、送信されるデータのパケットは、複数のリードソロモン符号化ブロックによって構成される。しかし、現在の提案では、パケット内のほとんどのリードソロモン符号化ブロックでエラー訂正に成功した場合であっても、一つでもリードソロモン復号に失敗すればパケット全体を再送する必要がある。
更に、実際の通信においてはプライバシ保護のため暗号化が行われる。この暗号化が各ブロック毎に行われ、暗号化が行われた各ブロックにリードソロモン符号化による誤り訂正符号が付加される。そして、この誤り訂正符号が付加された複数のリードソロモン符号化ブロックによって成るデータ部全体に対し、誤り検出符号が付加される。
現在の提案ではＭＡＣヘッダと同じリードソロモン符号化ブロックに暗号鍵（公開鍵）が添付されているため、このリードソロモン符号化ブロックに対する誤り訂正が成功すれば、データ部の各リードソロモン符号化ブロックの暗号鍵による復号は可能となる。しかし、パケット自体の復号の成功を保証するには、データ部を構成する全てのリードソロモン符号化ブロックに対する誤り訂正が成功する必要がある。
上記にあげた２つの状況は、ともに誤り訂正に成功したリードソロモン符号化ブロックまでも再送せねばならず、そのために余計な通信帯域を確保せねばならない。即ち、再送するデータ量が、本来再送を必要とするデータ量に比べて大きくなり、データ転送の効率化を図るべき無線通信において、非効率的なデータ転送を行うこととなる。
上記とは別の問題として、システム全体の時刻合わせの問題がある。第３１図が、ネットワークシステムにおける各局のシステムタイマの精度と、受信局のソースパケット出力で発生するジッタを示す図である。
送信局はＡＶソースパケットに対し自局のタイマが示す入力時の時刻情報を添付し、受信局は添付された時刻情報と自局のタイマを使ってＡＶソースパケットのタイムシーケンスを再生する。しかし、各局のタイマは全く同じ精度ではないため、ある程度の時間が経過すると、各々の時刻がずれてくる。この送信局、受信局の間の時刻ずれが、受信局がＡＶソースパケットのタイムシーケンス再生をする際にジッタとして現れる。
即ち、第３１図のように、制御局のシステムタイマに比べて、送信局のシステムタイマが進むと、送信局で送信されるソースパケットのタイミングが早くなるとともに、ソースパケットに付加される時刻情報が制御局のシステムタイマの表す時刻より早いものとなる。逆に、第３１図のように、受信局のシステムタイマが遅れると、受信局で出力されるソースパケットのタイミングが遅れて、ソースパケットの出力間隔が本来の出力間隔と比べて長くなり、ジッタが生じる。更に、定期的に与えられるビーコンによって、各局のシステムタイマが一致させられるので、時間遅れが発生している受信局におけるソースパケットの出力間隔が本来の出力間隔と比べて短くなり、同じくジッタが生じる。
一方、個々のＡＶソースパケットは出力タイミングが厳しく決まっており、定められたジッタ範囲内で出力されなければならない。しかしながら、現在のＨＣＦではビーコンによる時刻合わせしか行われない。ＩＥＥＥ８０２．１１におけるタイマ精度は０．０１％であるが、仮に１００ｍｓに一回送信されるビーコンでしか時刻合わせを行わないとすると、送信局と受信局の間では最大２０μｓ程度の時刻ずれが発生する。
上述したパケット毎のデータ再転送によるデータ転送の非効率化や、許容範囲外となるジッタの発生によるデータの欠落及び出力異常などにより、ＩＥＥＥ８０２．１１などで設定される無線通信システムは、ＡＶデータの転送に十分な通信システムではない。
発明の開示
よって、本発明は、ＡＶデータ転送に適切となる効率的なデータ送信を行うことができる無線通信システムを提供することを目的とする。
本発明の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局によって送信局とされる通信装置が、時刻を管理するシステムタイマと、アプリケーションデータに対して前記システムタイマより得られた該アプリケーションの入力時刻に基づいて生成した時系列的管理用の時刻情報を付加するとともに、前記アプリケーションデータのうち保持期間が定められたアプリケーションデータに対して送信可能な期間を設定するデータ処理部と、該データ処理部で前記時刻情報が与えられた前記アプリケーションデータを一時的に保持するバッファと、該バッファから前記アプリケーションデータを読み出すともに該アプリケーションデータに誤り訂正符号を付加する誤り訂正符号付加部と、該誤り訂正符号付加部で誤り訂正符号が付加されたアプリケーションデータから送信パケットを作成する送信パケット生成部と、該送信パケット生成部で作成した前記送信パケットを送信する送信部と、前記バッファからアプリケーションデータを読み出すことを制御するとともに、前記送信パケット生成部で生成された前記送信パケットを通信帯域が確保された時間に前記送信部から送信することを制御する送信制御部と、前記送信部から送信した一つ又は複数の送信パケットの受信を示す応答信号を受信する受信部と、を備え、前記送信部から送信する際に、前記送信制御部において、前記システムタイマから得られる現在時刻と前記バッファ内に格納されたアプリケーションデータに対して設定された前記送信可能な期間とを比較し、該現在時刻が前記送信可能な期間を超過しているアプリケーションデータについては、前記誤り訂正符号付加部が前記バッファから読み出さず、又、前記送信部より前記送信パケットを送信した後、所定時間以上経過しても、前記送信パケットに対する前記応答信号を前記受信部で受信しなかったことが前記送信制御部において確認されるとき、該送信パケットが正しく受信されていないと判定することを特徴とする。
又、本発明の別の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局によって受信局とされる通信装置が、時刻を管理するシステムタイマと、時系列的管理用の時刻情報が付加されたアプリケーションデータから成る送信パケットを受信する受信部と、該受信部で受信された送信パケットに誤り訂正符号が付加されているか否かを判定する誤り訂正判定部と、前記受信部で受信された送信パケットのうち誤り訂正符号が付加された送信パケットに対して誤り訂正を施す誤り訂正処理部と、誤り訂正が成された送信パケットよりアプリケーションデータを生成する第１復号部と、前記受信部で受信された送信パケットのうち誤り訂正符号が付加されていない送信パケットより前記アプリケーションデータを生成する第２復号部と、前記第１及び第２復号部で生成された前記アプリケーションデータを一時的に格納する第１及び第２バッファと、前記システムタイマによる時刻が前記アプリケーションデータに付加された時刻情報による時刻と一致したことを確認すると、前記アプリケーションデータを前記第１又は第２バッファから読み出して出力するデータ出力部と、１つ又は複数の送信パケットの受信状態を示す応答信号を送信する送信部と、を備え、前記受信部で受信された送信パケットに対して、前記誤り訂正処理部及び前記第１復号部による第１演算処理と、前記第２復号部による第２演算処理とを同時に施すことを特徴とする。
本発明の別の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局となる通信装置が、時刻を管理するシステムタイマと、他の通信装置から送信される通信帯域の確保を要求する帯域確保要求信号を受信する受信部と、通信帯域が確保され衝突が生じない非衝突区間を時分割で管理する帯域管理部と、前記システムタイマより得られる現在時刻を他の通信装置に認識させるための時刻情報信号と、前記非衝突区間の開始を他の通信装置に認識させるための非衝突区間開始信号と、前記非衝突区間の終了を他の通信装置に認識させるための非衝突区間終了信号と、を送信する送信部と、を備え、前記非衝突区間を発生させる周期を基本周期とし、前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間の周期であるメディアアクセス周期が、前記基本周期の整数倍でないとき、該他の通信装置の帯域確保の要求を拒否することを特徴とする。
発明を実施するための最良の形態
以下に本発明の実施例を示す。本発明における通信ネットワークは有線、無線を特定しないが、以下の実施例ではＩＥＥＥ８０２．１１無線通信方式を用いた場合を例にして説明を行う。
第１図は、本発明を実施する無線ネットワーク構成例である。
第１図の１は衝突が発生しない区間において送信を行う局の無線メディアへのアクセスを制御する制御局である。本実施形態ではメディアアクセス制御機能としてＨＣＦを備えるものとする。この制御局１は、通常、ＨＣ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｏｒ）と呼ばれる。
第１図の２はリアルタイムＡＶデータの送信局、３はリアルタイムＡＶデータの受信局である。リアルタイムＡＶデータ送信局２及びリアルタイムＡＶデータ受信局３の衝突が発生しない区間（ＣＦＰ）におけるメディアアクセスは制御局１によって管理される。本実施形態では、このＣＦＰにおけるメディアアクセス管理を機能させるために、制御局１及び送信局２及び受信局３はそれぞれ、ＨＣＦを備えるものとする。
第１図の４は衝突が起きる可能性がある区間（ＣＰ）のみメディアアクセスできる従来の局である。本実施形態では、局４はＤＣＦのみを備えるものとする。
尚、第１図において、それぞれの局には送信、受信、制御、従来のメディアアクセスのようにひとつの機能しか実装されていないように記載しているが、これは説明を簡潔にするためであり、実際には一つの局に複数の機能を実装するものとしてもよい。
第２図は、送信局２の構成を示すブロック図である。
第２図の５はネットワークシステム全体の時刻情報を管理するシステムタイマである。システムタイマ５は制御局１が発行するＢｅａｃｏｎなどの時刻情報を格納したフレームに含まれる現在時刻情報に基づいて時刻合わせをすることで、常に制御局１内のシステムタイマとほぼ同じ時刻になるように動作するとともに、この現在時刻情報に基づいてメディアアクセス時間を管理する。
第２図の６は入力されたＡＶソースパケットを転送に適した形に変換するためのデータブロック生成回路である。又、このデータブロック生成回路６は、複数のデータブロックの集合体に対して、ＡＶソースパケットに対するデータブロックの生成情報（本実施形態ではこの情報をＭＡＰと呼ぶことにする）、及びＡＶソースパケットが入力されたときのシステムタイマ５で測定される時刻情報を添付する。
ＡＶソースパケットのデータブロック生成回路６への入力時刻を管理するタイマを別途用意する方法もあるが、本実施形態では説明を簡単にするために、システムタイマ５を使用している。このＭＡＰと時刻情報を付加されたデータブロックの集合を、本実施形態において、ＡＶデータパックと呼ぶことにする。
第２図の７はＡＶ伝送用バッファであり、データブロック生成回路６で生成されたＡＶデータパックを順次格納する。ＡＶ伝送用バッファ７は、ＡＶデータパック単位でバッファアドレス管理を行い、且つ、送信待機状態にあるバッファアドレスを示す識別子を備える。この識別子は、ＡＶデータパック単位毎のバッファアドレスに対応して与えられる１ビットのデータである。そして、ＡＶ伝送用バッファ７にＡＶデータパックが入力されると、入力されたＡＶデータパックのバッファアドレスに対応する識別子を１とし、又、ＡＶ伝送用バッファ７からＡＶデータパックが出力されると、出力されたＡＶデータパックのバッファアドレスに対応する識別子を０とする。ＡＶ伝送用バッファ７のバッファサイズは、後述するライフタイム分のＡＶデータパックを格納できるサイズとする。又、ＡＶ伝送用バッファ７には、後述する再送可能であることを示す再送可能識別子をも備える。
第２図の８は送信局２のメディアアクセスを制御するＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）部であり、第２図の９はＡＶ伝送用バッファ７から出力されるＡＶデータパック、またはＬＬＣ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層のデータをバッファリングするＬＬＣ−ＰＤＵ（ＬＬＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）用バッファ１０内のデータをＭＡＣパケットに格納するためのＭＡＣパケット生成回路である。
第２図の１１は、他局から送信されたパケットを受信するための受信部である。受信部１１が制御局１が送信したＢｅａｃｏｎを受信した場合、Ｂｅａｃｏｎ内部に格納されている時刻情報をシステムタイマ５に通知し、システムタイマ５はその時刻情報を使って自身の時刻情報を更新する。受信部１１が制御局１からのＡＶ伝送のための帯域確保フレームを受信した場合、ＭＡＣ部８にその旨を通知する。通知されたＭＡＣ部８は、ＡＶ伝送用バッファ７の状態を調べ、バッファに送信待機状態のＡＶデータパックが存在しているときは、ＭＡＣパケット生成回路９に対しＭＡＣパケットの生成を開始するよう要求する。受信部１１が受信局３からのＡＣＫを受信したときは、受信局３が再送を必要としているかどうかを判断し、再送が必要であれば、その旨をＭＡＣ部８に通知し、次回の送信時に必要なデータを送信できるようにする。
ＭＡＣパケット生成回路９は、入力データを選択するセレクタ１２と、入力されたデータに対し誤り検出符号を付加する誤り検出符号付加回路１３と、誤り検出符号を付加した状態のデータを暗号化する暗号化器１４と、ＭＡＣパケットヘッダを生成するＭＡＣパケットヘッダ生成回路１５と、ＭＡＣパケットヘッダと暗号化されたデータを選択するセレクタ１６と、セレクタ１６の出力に対し誤り訂正符号を付加する誤り訂正符号付加回路１７と、誤り訂正符号付加回路１７での誤り訂正符号をデータに付加するか否かを選択するセレクタ１８と、入力されたパケット全体に対し誤り検出符号を付加する誤り検出符号付加回路１９と、で構成される。本実施実施形態において、誤り訂正符号付加回路１７はリードソロモン符号（２２４，２０８）を扱うものとする。即ち、２０８バイトのデータに対し、１６バイトのリードソロモン符号を付加し、全体としては２２４バイトのデータを出力する。
第３図は、受信局３の構成を示すブロック図である。
第３図におけるＭＡＣパケット受信回路２０は、パケット全体の誤り検出を行う誤り検出回路２１と、パケットに付加された誤り訂正符号により誤り訂正を行う誤り訂正回路２２と、ＨＣＦに対応したＭＡＣパケットを解析するＭＡＣパケット解析回路２３と、データに施された暗号を復号する復号器２４と、復号されたデータの誤りを検出する誤り検出回路２５と、データの出力先をＬＬＣ−ＰＤＵ用バッファ３０及びＡＶ伝送用バッファ３２のいずれにするかを選択するセレクタ２９と、リードソロモン符号を付加されていないパケットを解析するＭＡＣパケット解析回路２６と、データに施された暗号を復号する復号器２７と、復号されたデータの誤りを検出する誤り検出回路２８で構成される。本実施形態では、誤り訂正回路２２はリードソロモン符号（２２４，２０８）を扱う。即ち２２４バイトのデータに対し、末尾１６バイトをリードソロモン符号として扱い、エラー訂正を行った２０８バイトのデータを出力する。
尚、第３図の受信局３は、ＭＡＣパケット解析回路、復号器、誤り検出符号をそれぞれ２つずつ備えているが、これはリードソロモン復号処理には時間がかかるため、リードソロモン復号中に従来のＭＡＣパケットを受信したような場合に、従来のＭＡＣパケットの処理ができなくなることを防ぐためである。従って、このような機能が必要ではない場合には、ＭＡＣパケット解析回路、復号器、誤り検出符号それぞれ１つのみを備えるものとしても構わない。又、ＬＬＣ−ＰＤＵ用バッファについても、同時に２系統からの書き込みが可能な制御回路をもつバッファであればＬＬＣ−ＰＤＵ用バッファを１つとしても構わない。
誤り検出回路２５から出力されるデータがＡＶデータパックであるならば、セレクタ２９を通じてＡＶ伝送用バッファ３２に与えられて、ＡＶ伝送用バッファ３２に格納される。ＡＶ伝送用バッファ３２は、ＡＶデータパック単位にアドレス管理を行い、バッファアドレスに対してＡＶデータパックの格納状態を示す識別子を備える。この識別子は、ＡＶデータパック単位毎のバッファアドレスに対応して与えられる１ビットのデータである。そして、ＡＶ伝送用バッファ３２に正常なＡＶデータパックが入力されると、入力されたデータパックのバッファアドレスに対応する識別子を１とし、ＡＶ伝送用バッファ３２からＡＶデータパックが出力されると、出力されたデータパックのバッファアドレスに対応する識別子を０とする。ＡＶ伝送用バッファ３２のバッファサイズは、後述するライフタイム分のＡＶデータパックを格納できるサイズとする。
第３図の３３はソースパケット出力回路である。このソースパケット出力回路３３は、ＡＶ伝送用バッファ３２に蓄えられているＡＶデータパックからソースパケットを再構築し、ソースパケットに添付されている時刻情報又はソースパケットから算出された時刻情報とシステムタイマ３４に従ってタイムシーケンスを再現し、ソースパケットを出力する。
ＭＡＣパケット受信回路２０がＢｅａｃｏｎなどの時刻情報を格納したフレームを受信すると、その時刻情報をシステムタイマ３４に通知し、システムタイマ３４は通知された時刻情報に従って自身の時刻情報を更新する。
第３図の３５は、受信装置のメディアアクセスを制御するＭＡＣ部である。このＭＡＣ部３５によって、システムタイマ３４の時刻情報や、メディアセンスによって自局がメディアアクセス可能であるかどうか、即ち、ＡＣＫ送信可能な時であるかを判断する。
第３図の３６はＡＣＫ生成部である。このＡＣＫ生成部３６は、ＭＡＣパケット受信部２０の状況やＡＶ伝送用バッファ３２の状態に応じて、送信局２に対しＡＣＫを生成する。
第４図は、制御局１の構成を示すブロック図である。
第４図で３７はシステムタイマであり、ＭＡＣ部３８はこのシステムタイマ３７の時刻情報をもとにメディアアクセス制御を行う。システムタイマ３７が規定の時刻を示すと、ＭＡＣ部３８はＢｅａｃｏｎや帯域確保フレームを送信するよう送信部３９に要求する。
第４図の４０は、他局から送信されたパケットを受信するための受信部であり、新規に帯域確保を要求したい送信局からの帯域確保要請フレームなどを受信する。受信部４０が帯域要請フレームを受信すると、その情報は帯域管理部４１に与えられる。帯域管理部４１は周期的に帯域を確保する必要がある局と、ＴＸＯＰと呼ばれるメディアアクセス時間を管理している。帯域管理部４１は、帯域に余裕があれば、この要求を許可し、内部に必要な情報を記憶する。ＭＡＣ部３８は帯域管理部４１から帯域情報が変わったことを通知されると、適当な時間からその局のための帯域確保フレームを送信するよう、送信部３９に要求する。
既存の局４については、ＩＥＥＥ８０２．１１のＰＣＦ／ＤＣＦを備えた従来の装置であるため、その構成の説明を省略する。
以下では送信局２に入力されたＡＶソースパケットが受信局３にて出力されるまでの処理の流れについて順次説明する。ここでは例として、ＡＶソースパケットがＭＰＥＧ２−ＴＳ又はＤＶＣ（スタンダード）である場合について説明する。
データブロック生成回路６は、入力されたＡＶソースパケットを、リードソロモン符号（２２４，２０８）で扱いやすい形式、すなわちデータが２０８バイト以内になるように構成しなおしたＡＶデータパックを生成し、ＡＶ伝送用バッファ７に格納する。
第５図はＭＰＥＧ２−ＴＳが送信局２のＡＶ伝送用バッファ７に格納されるまでの流れを示した図である。
一つのＭＰＥＧ２−ＴＳパケットの大きさは１８８バイトであり、通常の画質で平均６Ｍｂｐｓ程度、高画質のもので２４Ｍｂｐｓの速度で断続的に転送される。データブロック生成回路６では、入力されたＭＰＥＧ２−ＴＳパケットに対し、入力時のシステムタイマ５に基づく４バイトの時刻情報をソースパケットヘッダ（ＳＰＨ）として添付するとともにデータブロックの内容を示す８バイトのＭＡＰ情報を添付することで、２００バイトのＡＶデータパックを生成する。このようにして生成されたＡＶデータパックは順次ＡＶ伝送用バッファ７に与えられ、ＡＶ伝送用バッファ７において、ＡＶデータパックがデータブロック生成回路６より出力される順に後述するＴａｇが付加されて格納される。
即ち、ｎ番目（ソースパケットカウンタによって与えられたカウント値に相当する）に与えられたソースパケットがデータブロック生成回路６に与えられると、入力された時刻がシステムタイマ５で確認される。このシステムタイマ５で確認された時刻に基づく時刻情報によるＳＰＨ及びＭＡＰ情報を添付してＡＶデータパックを生成すると、このＡＶデータパックをＡＶ伝送用バッファ７においてｋ番目となる後述するＴａｇを付加して格納する。又、ｎ＋１番目のソースパケットにより生成されるＡＶデータパックが、ｋ＋１番目となる後述するＴａｇが付加されたＡＶ伝送用バッファ７に格納される。
第６図はＤＶＣパケットが送信局２のＡＶ伝送用バッファ７に格納されるまでの流れを示した図である。
一つのＤＶＣのパケットは４８０バイトであり、３０Ｍｂｐｓの転送速度で連続的に転送される。パケット先頭はフレームパルス入力の立ち上がりで判別される。データブロック生成回路６は入力されたＤＶＣパケットを５つのブロックに分割し、２つのブロック毎にデータブロックの内容を示す８バイトのＭＡＰ情報を添付して、ＡＶデータパックを生成する。このようにして生成されたＡＶデータパックは順次ＡＶ伝送用バッファ７に与えられ、ＡＶ伝送用バッファ７において、ＡＶデータパックがデータブロック生成回路６より出力される順に後述するＴａｇが付加されて格納される。又、ＤＶＣのＭＡＰ情報には、フレームパルス立ち上がり時のシステムタイマ５に基づく２バイトの時刻情報を格納している。
即ち、ｎ番目に与えられたソースパケットがデータブロック生成回路６に与えられると、入力された時刻がシステムタイマ５で確認される。そして、ソースパケットが９６バイトの５つのブロックＦ０ｎ〜Ｆ４ｎに分割されると、２つのブロックＦ０ｎ，Ｆ１ｎに、システムタイマ５で確認された時刻に基づく時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成する。このＡＶデータパックをＡＶ伝送用バッファ７においてｋ番目となる後述するＴａｇを付加して格納する。又、２つのブロックＦ２ｎ，Ｆ３ｎに、同一の時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成し、このＡＶデータパックをＡＶ伝送用バッファ７においてｋ＋１番目となる後述するＴａｇを付加して格納する。
又、ｎ＋１番目のソースパケットが与えられると、データブロック生成回路６で５つのブロックＦ０ｎ＋１〜Ｆ４ｎ＋１に分割される。そして、２つのブロックＦ４ｎ，Ｆ０ｎ＋１に、システムタイマ５で確認されたｎ＋１番目のソースパケットの入力された時刻に基づく時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成する。このＡＶデータパックをＡＶ伝送用バッファ７においてｋ＋２番目となる後述するＴａｇを付加して格納する。その後、ブロックＦ１ｎ＋１，Ｆ２ｎ＋１によるＡＶデータパック、ブロックＦ３ｎ＋１，Ｆ４ｎ＋１によるＡＶデータパックがそれぞれ、順に、後述するＴａｇが付加されてＡＶ伝送用バッファ７に格納される。
尚、システムタイマ５に基づく４バイト又は２バイトの時刻情報は、システムタイマ５によって確認されたソースパケットの入力時刻を表すものであっても構わないし、この入力時刻に送信局２での処理時間及び受信局３への送信時間を付加した時刻としても構わない。
第７図Ａ及び第７図Ｂは、ＭＰＥＧ２−ＴＳ及びＤＶＣそれぞれに対するＭＡＰ情報を格納するパケットヘッダフォーマットの一例である。又、表１は、ＭＡＰ情報における各フィールドのビット数を表した表であり、表２は、ＭＰＥＧ２−ＴＳ及びＤＶＣそれぞれに対する各フィールドの情報を示した表である。
第７図ＡのＭＰＥＧ２−ＴＳに対するＭＡＰ情報のフィールド構成と、第７図ＢのＤＶＣに対するＭＡＰ情報のフィールド構成とから明らかなように、ＭＰＥＧ２−ＴＳに対するＭＡＰ情報には、ＳＹＴフィールドが無く、ＦＤＦフィールドとされている。その他のフィールドについては、ＭＰＥＧ２−ＴＳ及びＤＶＣのいずれに対するＭＡＰ情報にも含まれる。
以下に、各フィールドの詳細について説明する。まず、ＤＢＳは８ビットのフィールドで、格納時の最小単位であるデータブロックのサイズをｑｕａｄｌｅｔ（＝４バイト）単位で示している。即ち、ＭＰＥＧ２−ＴＳの場合は、時間情報とソースパケットを合わせた１９２バイトが最小単位になるため、４８（＝｜００１１００００｜２）が、ＤＶＣの場合は、フラグメントされた９６バイトが最小単位になるため、２４（＝｜０００１１０００｜２）が入力される。
ＦＮは３ビットのフィールドで、ソースパケットをいくつのデータブロックに分割したかを整数で示す。１は分割をしていないことを示し、０は８個に分割したことを示す。ＭＰＥＧ２−ＴＳの場合は分割しないため１を、ＤＶＣの場合は５つに分割するため５が入力される。
ＤＢＩは３ビットのフィールドで、ＡＶデータパックの先頭に格納されたブロックが何番目のブロックであるを示す数値が入る。ＭＰＥＧ２−ＴＳの場合、分割しないため、ＤＢＩは常に０であるが、ＤＶＣの場合はソースパケットが分割されるため、ソースパケットが分割されて生成されるブロックの順番を示す０〜４までの整数が入る。
ＳＰＣは８ビットのフィールドで、ＡＶデータパック内に格納されているソースパケットが何番目のパケットであるかを示すソースパケットカウンタによるカウンタ値であり、分割された複数のブロックが格納されているときは、その先頭のブロックのカウンタ値とされる。
ＱＰＣは８ビットのフィールドで、格納したブロックの合計が２００バイトに満たない場合に施すパディングの量をバイト数で示す。ここではＭＰＥＧ２−ＴＳは、パディングを行わないため、常に０（＝｜００００００００｜２）である。しかし、ＤＶＣの場合は、パケットが連続的に入力されなかった場合、９６バイトのパディングが付加される可能性があり、このようなときは９６（＝｜０１１０００００｜２）となり、このような場合以外では０（＝｜００００００００｜２）となる。
ＲＳＶは１ビットのフィールドで、後に利用可能とするための予約フィールドである。ＳＰＨは１ビットのフィールドで、ＡＶデータパックを作成する際にソースパケットヘッダが付加していたか否かを示す。ＭＰＥＧ２−ＴＳの場合は時刻情報として４バイトのソースパケットヘッダを付加するため１が、ＤＶＣの場合は０が格納される。
ＦＭＴは６ビットのフィールドでソースパケットのフォーマットを示す。このＦＭＴは、上位１ビットが１のとき、ＳＹＴフィールドを有することを示す。即ち、ＭＰＥＧ２−ＴＳの場合は｜００００００｜２が、ＤＶＣの場合は時刻情報として２バイトのＳＹＴを備えるため｜１０００００｜２が格納される。
ＦＤＦは８ビット又は２４ビットのフィールドで、ＦＭＴで指定されたフォーマットよりも詳しい情報が入力される。このＦＤＦは、ＤＶＣの場合は２バイトのＳＹＴを備えるため８ビットのフィールドとなり、ＭＰＥＧ２−ＴＳの場合はＳＹＴがないので２４ビットのフィールドとなる。
ＳＹＴは１６ビットのフィールドで、ソースパケットが入力した時刻情報である。ＭＰＥＧ２−ＴＳの場合は、ソースパケットヘッダとして時刻情報をもっているため付加せず、ＤＶＣの場合は先に述べた２バイトの時刻情報をここに格納する。尚、このＳＹＴには、ソースパケットの先頭のブロックがＡＶデータブロックに含まれる場合は、そのブロックのソースパケットが入力された時刻情報が格納される。又、本実施形態では、ＦＭＴ、ＦＤＦ、ＳＹＴは、ＩＥＥＥ１３９４でリアルタイムＡＶデータを転送するための方式であるＩＥＣ６１８８３に従っている。
以上の操作により、ＭＰＥＧ２−ＴＳソースパケット、ＤＶＣソースパケットは、ともに２００バイトのＡＶデータパックに変換され、ＡＶ伝送用バッファ７、に格納される。
第８図は、ＡＶ伝送用バッファ７に格納されたＡＶデータパックからＭＡＣパケットを生成するまでの処理を示す図である。
ＡＶ伝送用バッファ７は、データブロック生成回路６で生成された２００バイトのＡＶデータパックに８ビットの識別子を含む４バイトの付加情報であるＴａｇを添付して出力する。この付加情報であるＴａｇ内の８ビットの識別子は、上述したようにＡＶ伝送用バッファ７に格納された順序を表す値に相当する。このＴａｇを付加された２０４バイトのＡＶデータパックがセレクタ１２で選択されて誤り検出符号付加回路１３に与えられると、誤り検出符号付加回路１３によって４バイトの誤り検出符号（ＦＣＳ）が付加される。
Ｔａｇにある８ビット識別子は、本実施形態において、リードソロモン符号化ブロック単位での再送を行う通信において、受信局３がＡＣＫを返信する際に、どの符号化ブロックを正常に受信したかを示すために使われる。よって、Ｔａｇにある８ビット識別子は、受信局３が判別できる形式、例えば連続的な番号でもよい。
本実施形態では、管理を容易にするとともにその管理に用いられる別のバッファを不要とするために、ＡＶ伝送用バッファ７のバッファアドレスを８ビット識別子として使用する。このことにより、回路が簡略化される。又、本実施形態では、送信するＡＶデータパックにＴａｇ情報を付加しているが、これは一例であり、Ｔａｇ情報を付加せずに上位フォーマットヘッダにより識別を行うなどの方法も可能である。
４バイトのＴａｇと４バイトの誤り検出符号が付加された２０８バイトのＡＶデータパックは、これを１単位として、暗号化器１４によって暗号化される。この暗号化器１４において用いられる方法として、現在、ＩＥＥＥ８０２．１１ｅにおいて提案されているｂａｓｉｃ ＷＥＰと呼ばれる公開鍵法による暗号化方法が用いられる。
この暗号化方法は、予め、送信局２と受信局３の間において秘密鍵を決めておく。そして、送信局２において、この秘密鍵と公開鍵とによって暗号化する。又、公開鍵は、送信パケット毎に変更され、パケットに付加して受信局３に通知される。受信局３では、通知された公開鍵と秘密鍵とによって復号化する。尚、公開鍵はＭＡＣパケットヘッダ生成回路１５で生成されると、暗号化器１４に与えられる。
暗号化されたデータに対し、ＭＡＣヘッダと公開鍵が付加され、更に、誤り訂正符号付加回路１７によって１６バイトのリードソロモン符号が付加される。ここで、誤り訂正符号付加回路１７において、ＭＡＣヘッダと公開鍵を一つのリードソロモン符号化ブロックとし、データに関しては２０８バイトのＡＶデータパックに相当する暗号化データ単位でリードソロモン符号化ブロックとする。
即ち、まず、ＭＡＣパケットヘッダ生成回路１５で生成されたＭＡＣヘッダと公開鍵とがヘッダ部としてセレクタ１６で選択されて誤り訂正符号付加回路１７に与えられ、１６バイトのリードソロモン符号が付加される。その後、暗号化器１４で暗号化された暗号化データ単位毎のＡＶデータパックがデータ部としてセレクタ１６で選択され、誤り訂正符号付加回路１７で１６バイトのリードソロモン符号が付加される。そして、誤り訂正符号付加回路１７で所定数のＡＶデータパックそれぞれに相当する各データ部にリードソロモン符号が付加されて出力されると、セレクタ１６によって、ＭＡＣパケットヘッダ生成回路１５の出力を誤り訂正符号付加回路１７に与えるように接続を切り換える。
又、３２バイトのＭＡＣヘッダと４バイトの公開鍵のデータ量は３６バイトしかなく、２０８バイトに満たない。このため、誤り訂正符号付加回路１７は、このＭＡＣヘッダと公開鍵とによるデータブロック（ヘッダ部）について、１〜１７２バイトに０又は１のパディングが格納されるとともに１７３〜２０８バイトにＭＡＣヘッダと公開鍵とが格納されているデータとして、処理を行う。このヘッダ部を処理する際、誤り訂正符号付加回路１７が、１７２バイト分の０又は１のパディングの処理後の内部状態となるように、初期化すればよい。
そして、セレクタ１８が誤り訂正符号付加回路１７の出力を選択して誤り検出符号付加回路１９に与えるため、リードソロモン符号化処理されたデータ全体に対し、誤り検出符号付加回路１９により４バイトのＦＣＳが付加される。即ち、リードソロモン符号化処理された１つのヘッダ部と所定数（ｎ）のデータ部による誤り訂正符号付データに対して、ＦＣＳが付加される。よって、所定数（ｎ＋１）のリードソロモン符号化ブロックによる誤り訂正符号付きデータに対して、誤り検出符号化が行われる。これは従来のＩＥＥＥ８０２．１１パケットとの互換性を保つための処理である。
上述のように、ＡＶ伝送用バッファ７において、ＡＶデータパックを２０８バイト以内に無駄なく収まるように構成しなおすことには、パディングによって発生する帯域の増加を抑制できるという利点と、後述するリードソロモン符号化ブロック単位で再送する際の処理が簡略化できるという利点がある。
又、ＭＡＣパケット生成回路９でのＭＡＣパケットの生成処理において、固定長のリードソロモン符号を使った例を挙げたが、他の方法として、ソースパケットの大きさにあわせてリードソロモン符号の符号長を可変させる方法もある。例えば、リードソロモン符号として（２５５、２３９）を利用する場合において、ＭＰＥＧ２−ＴＳソースパケットを処理するときは、先頭から２０８バイト目までを誤り訂正符号付加回路１７を通した後、２０９バイト目から２３９バイト目まで０又は１をパディングしたものとして計算を行い、１６バイトのリードソロモン符号を得る。そして、２０９バイト目から２３９バイト目までの０又は１のパディングは除去して、２０８バイト目までＡＶデータパックに１６バイトのリードソロモン符号を付加して誤り検出符号付加回路１９に送出する方法がある。
固定長のリードソロモン符号の場合は、ＡＶデータパックやソースパケットの大きさによってリードソロモン符号化ブロック内にパディングが発生する可能性があるが、この方法では誤り訂正符号付加回路１７においてパディングが除去されるので、メディア上を転送されるパケット内にはパディングが発生せず、帯域の使用効率が向上するという利点がある。
この場合、パディングする量が多くなればなるほど、リードソロモン符号化時のパディング箇所の処理の遅延が大きくなり、パディング分の遅延を補償するために、パディング分だけ先行した先読みを行って処理する必要がある。このため、より速い動作クロックと、先読みでリードソロモン符号化処理を施したデータを保存するために多くのバッファが必要となる。
又、ヘッダ部において、１〜３６バイトまでにＭＡＣヘッダと公開鍵を格納し、残りの３７〜２０８バイトを０又は１のパディングとする形で処理をしても構わないが、その場合は、符号化の際にパディング部で発生する遅延時間を考慮する必要がある。この場合、可変長のリードソロモン符号化処理と同様、先読みでリードソロモン符号化処理を施したデータを保存するためのバッファが必要となる。
又、セレクタ１２によって、ＬＬＣ−ＰＤＵ用バッファ１０からのデータブロックが選択されたとき、ブロック１３〜１９が上述と同様の動作を行うことによって、ＬＬＣ−ＰＤＵ用バッファ１０に格納されたインターネット用のデータなど処理されてＭＡＣパケットが生成される。
更に、セレクタ１８が、セレクタ１６からの出力を選択して誤り検出符号付加回路１９に与えるとき、誤り訂正符号付加回路１７におけるリードソロモン符号化処理が行われずに、ＭＡＣパケットヘッダ生成回路１５で生成されたヘッド部及び暗号化器１４でＡＶデータパックが暗号化されて得られたデータ部が、誤り検出符号付加回路１９に与えられる。よって、リードソロモン符号の付加されていないヘッド部及び所定数のデータ部よりなるデータに対して、ＦＣＳが付加される。
次に、受信局３がＭＡＣパケットを受信したときの処理について述べる。
まず、受信局３では、受信パケットが誤り訂正符号化処理をされているかを判別する必要がある。この判別方法において、ＭＡＣヘッダに設けた誤り訂正符号化処理の有無を示す識別フィールドより判別する方法があるが、無線メディア上で発生したエラーによって、誤り訂正符号化処理識別フィールドに誤りが発生する場合もある。そのため、単純にこの誤り訂正符号化処理の有無を示す識別フィールドのみによる判別だけでは、信頼性が低い。
よって、誤り訂正回路２２によって誤り訂正符号化処理を行うか否かが確認される。今、第９図に、誤り訂正回路２２と誤り検出回路２１とにおいて同一のデータ量のデータに対する処理速度が同じであるものとしたときの、誤り検出回路２１の出力と誤り訂正回路２２の出力の時間的な関係を示す。この第９図を参照して、以下に、誤り検出回路２１及び誤り訂正回路２２それぞれでの時間的な処理関係を説明する。
まず、誤り検出回路２１にＭＡＣパケットが入力されると、ＭＡＣヘッダと公開鍵とリードソロモン符号とによるデータブロック長分の処理時間が経過すると、誤り訂正回路２２にＭＡＣパケットのデータが出力される。そして、誤り訂正回路２２は、入力されたデータを一度バッファリングした後に、ユークリッド演算を開始する。その後、誤り訂正回路２２において、リードソロモン符号化ブロック長分の時間をかけてユークリッド演算が行われると、次に、チェンサーチが行われる。
このため、誤り訂正後のＭＡＣヘッダの出力が開始されるのは、ＭＡＣパケット受信回路２０内の誤り検出回路２１へのＭＡＣヘッダの入力開始から２７６バイト分（ＭＡＣヘッダを含むデータブロック５２バイト＋リードソロモン符号化ブロック２２４バイト）のデータ処理時間後であり、この後、更に５２バイト分のデータ処理時間を経過した後に、ＭＡＣヘッダに対する誤り訂正が成功したか否かが確認されるとともに、誤り訂正処理を行うか否かが確認される。この誤り訂正が正常に行われなかったとき、誤り検出回路２１へのＭＡＣヘッダの入力開始から３２８バイト分のデータ処理時間が経過したタイミングで、誤り訂正エラー信号が出力される。
これに対し、従来のＩＥＥＥ８０２．１１ａパケットにおいては、受信後、ＳＩＦＳ（１６μｓ）の間隔でＡＣＫを返さなければならない。しかしながら、上述のような誤り訂正処理を待った上で誤り訂正処理を行うか否かを判断した場合、ＭＡＣヘッダに対して施されるチェンサーチが終了するまでにかかる処理時間がＳＩＦＳより長くなるため、ＳＩＦＳの間隔でＡＣＫを返すことは難しい。
このため、受信局３は、誤り訂正処理されたＭＡＣパケットと通常の誤り訂正がないＭＡＣパケットをそれぞれ独立かつ並列に処理できるように、ＭＡＣパケット受信回路２０内に２系統のＭＡＣパケット処理用のブロックを備える。
第１０図に、ＭＡＣパケット受信回路２０において、ＭＡＣパケットが誤り訂正処理をされているか否かを判断した後に、ＭＡＣパケットに対して各種処理を施すためのフローチャート示し、以下でその動作を説明する。
最初に、誤り検出回路２１においてＭＡＣパケットの宛先アドレスをチェックする（ＳＴＥＰ１）。このとき、宛先アドレスが自局宛か、又は、宛先指定のないブロードキャストでない場合は（Ｎｏ）、ＭＡＣパケット解析回路２６後段での通常の処理は中止し、誤り訂正回路２２後段での誤り訂正の処理のみを行う（ＳＴＥＰ２）。即ち、宛先アドレスが間違っている場合は、誤り検出回路２１で誤り検出されるために、通常の処理では正常に受信できないので、このＭＡＣパケットに対するＡＣＫを返信する必要がない。又、このとき、宛先アドレスが正しく他局のアドレスを示している場合は、受信局３にとって無関係な通信である。
その後、誤り訂正処理部２２で誤り訂正をした後、誤り訂正されたＭＡＣパケットの宛先アドレスをＭＡＣパケット解析回路２３で再度チェックする（ＳＴＥＰ３）。このとき、ＭＡＣパケットの宛先アドレスが自局宛又はブロードキャストである場合（Ｙｅｓ）、復号器２４後段での処理が行われて、後述する遅延ＡＣＫがＡＣＫ生成回路３６より送信される（ＳＴＥＰ４）。又、逆に、ＭＡＣパケットの宛先アドレスが自局あて又はブロードキャストでない場合（Ｎｏ）、現在行っている誤り訂正処理を中止する（ＳＴＥＰ５）。
ＳＴＥＰ１において、誤り検出回路２１で確認されたＭＡＣパケットの宛先アドレスが自局宛又はブロードキャストである場合は（Ｙｅｓ）、誤り検出回路２１において、ＭＡＣヘッダ内の誤り訂正処理識別フィールドより、誤り訂正符号化されているか否かの判断を行う（ＳＴＥＰ６）。この識別フィールドで誤り訂正符号化されていることが示されていたら（Ｙｅｓ）、ＳＴＥＰ２に移行して、ＳＴＥＰ２〜ＳＴＥＰ５の誤り訂正処理のみを行う。このとき、誤り訂正処理をしていないにも関わらず誤り訂正処理識別フィールドが誤り訂正処理を示している場合、処理するＭＡＣパケットにエラーが発生していることを示し、このＭＡＣパケットは通常の処理ではＡＣＫを返信する必要がない。
又、ＳＴＥＰ６において、ＭＡＣヘッダ内の誤り訂正処理識別フィールドにおいて誤り訂正符号化されていることが示されていない場合は、誤り訂正回路２２後段での誤り訂正の処理と、ＭＡＣパケット解析回路２６後段での通常の処理とを平行して行う（ＳＴＥＰ７）。
ＳＴＥＰ７を経た後、誤り訂正回路２２で誤り訂正処理が行われると（ＳＴＥＰ８）、誤り訂正回路２２から出力される誤り訂正処理後のＭＡＣヘッダの誤り訂正処理識別フィールドがＭＡＣパケット解析回路２３で解析される（ＳＴＥＰ９）。ここで、誤り訂正処理識別フィールドが誤り訂正符号化されていることを示している場合（Ｙｅｓ）、誤り訂正エラー信号の状態を確認する（ＳＴＥＰ１０）。このとき、ＭＡＣヘッダが誤り訂正回路２２において正常に誤り訂正処理が成されたことが確認されると（Ｙｅｓ）、上述の通常の処理を中止するとともに、上述の誤り訂正処理が続けて行われる（ＳＴＥＰ１１）。この誤り訂正処理が行われるとき、遅延ＡＣＫをＡＣＫ生成回路３６で生成して送信する。
ＳＴＥＰ９において、誤り訂正処理識別フィールドが誤り訂正符号化されていることを示していない場合（Ｎｏ）、又は、ＳＴＥＰ１０において、ＭＡＣヘッダが誤り訂正回路２２における誤り訂正処理が正常に成されていない場合（Ｎｏ）、上述の誤り訂正処理を中止するとともに、上述の通常の処理のみを続けて行う（ＳＴＥＰ１４）。この通常の処理が行われるとき、ＡＣＫをＡＣＫ生成回路３６で生成して送信する。
ＳＴＥＰ７を経た後、上述の通常の処理が行われたとき（ＳＴＥＰ１２）、ＭＡＣパケット検出回路２１において、ＭＡＣパケットヘッダにおけるフォーマット的なエラーが確認される（ＳＴＥＰ１３）。このとき、ＭＡＣパケットヘッダにおけるエラーが検出されると（Ｙｅｓ）、上述の通常の処理が中止されるとともに、上述の誤り訂正処理を続けて行う（ＳＴＥＰ１１）。又、ＭＡＣパケットヘッダにおけるエラーが検出されない限り（Ｎｏ）、上述の誤り訂正処理を中止するとともに、上述の通常の処理を続けて行う（ＳＴＥＰ１４）。
ＳＴＥＰ７における通常の処理と誤り訂正処理の平行動作は、それぞれの判別までにかかる時間に差があるため、先に正常と判断された処理動作が優先されて、優先された処理動作に対して、以降のパケット処理を行う。尚、上述の両方の処理において、同時に正常と判断された場合は、以下の２通りの判断方法を用いることができる。一つの判断方法は、物理層から報告されるパケット長から判断する方法、残りの一つの判断方法は、確率的に正しいと考えられる処理動作を選択する方法である。
前者の判断方法では、受信したＭＡＣパケットのパケット長が誤り訂正符号処理をされた場合のパケット長（＝３２バイト（ＭＡＣヘッダ）＋４バイト（ＩＶ：公開鍵）＋１６バイト（ＲＳ符号）＋ｎ×２２４バイト（ｎは、ＭＡＣパケット内に含まれるＡＶデータパックの数に相当する）＋４バイト（ＦＣＳ））であることが誤り検出回路２１で確認されると、誤り訂正処理を優先する。しかしながら、可変長のリードソロモン符号を使用している場合は、この判断方法を使用することはできない。
後者の判断方法では、誤り訂正回路２２と誤り検出回路２１のそれぞれが誤動作する確率を比較し、確率的に誤動作をしにくい方を優先する。尚、リードソロモン符号で誤りを誤訂正をする確率は１／６００００であり、誤り検出符号が誤りを正常に検出できない確率はデータ長によって変化する。
上記判断方法以外に、誤り検出回路２１の出力を一度バッファリングし、誤りが検出されないときは、そのＭＡＣヘッダ内容に従って通常の処理を行い、誤りが検出されたときは、誤り訂正処理を行う方法もある。この場合、同時並行的に処理する必要がないので、第１０図のフローチャートと比べて、その判定アルゴリズムをより簡略化できる反面、バッファによる遅延が発生する。
以下に、誤り訂正符号化処理について説明する。第１１図は、誤り訂正符号化処理されたパケットとして正常に判断された後、パケット内のＡＶデータパックがＡＶ転送用バッファに格納されるまでの流れを示したものである。
誤り検出回路２１から誤り訂正回路２２にＭＡＣパケットが与えられると、まず、ヘッダ部について誤り訂正処理が行われる。このとき、誤り訂正回路２２で正常に訂正されて得られたヘッダ部がＭＡＣパケット解析回路２３に与えられ、ＭＡＣヘッダ及び公開鍵が取り出されると、公開鍵が復号器２４に与えられる。又、ＭＡＣパケット内に含まれるデータ部についても、誤り訂正回路２２で誤り訂正が成される際、訂正エラー信号が出力されたか否かが確認される。又、誤り訂正回路２２で誤り訂正が行われたデータ部は、ＭＡＣパケット解析回路２３を通じて復号器２４に与えられる。
復号器２４は、予め設定していた秘密鍵と、ＭＡＣパケット解析回路２３が得られた公開鍵を用いて、データ部の復号化を行い、その結果を誤り検出回路２５によって、データ部が正しく復号化されているかどうかをＦＣＳによって判別する。ここで、誤り検出回路２５はリードソロモン復号が行われて、正常に訂正できたか否かの判別も行われる。
誤り検出回路２５によってＦＣＳが除去されて得られたＡＶデータパックは、ＡＶ伝送用バッファ３２のＴａｇにある８ビット識別子が示すバッファアドレスに格納されていく。同時に誤り訂正回路２２から出力される誤り訂正エラー信号を観測し、この信号が正常に受信できたことを示す場合には、ＡＶ伝送用バッファ３２において、ＡＶデータパックを格納したバッファアドレスに対応する格納状況表示識別子に対し１を書き込み、誤り訂正エラー信号が訂正エラーを示した場合はその格納状況表示識別子に０を書き込む。
即ち、第１１図の場合、誤り訂正回路２２において、訂正エラー信号が出力されるデータ部＃１，＃３に対しては、ＡＶ伝送用バッファ３２の格納状況表示識別子が０となる。又、データ部＃２に対しては、ＡＶ伝送用バッファ３２の格納状況表示識別子が１となる。即ち、復号器２４及び誤り検出回路２５で復号化されたデータ部＃１，＃３より得られるＴａｇ内の８ビット識別子がｋ−１，ｋ＋１となるＡＶデータパックが格納されるＡＶ伝送用バッファ３２内のバッファアドレスに対応する格納状況表示識別子が０となる。又、同様に、Ｔａｇ内の８ビット識別子がＴａｇとなるＡＶデータパックが格納されるＡＶ伝送用バッファ３２内のバッファアドレスに対応する格納状況識別子が１となる。
ＡＶ伝送用バッファ３２での処理をより簡単にするために、誤り訂正回路２２の出力をリードソロモン符号化ブロック分の長さのバッファでバッファリングし、訂正エラーが発生しなかったことを確認した後、ＭＡＣパケット解析回路２３に出力させるようにしても構わない。この場合、ＭＡＣパケット解析回路２３による解析が遅延するとともに、より多くのバッファがいるが、ＡＶ伝送用バッファ３２の制御は簡略化できる。
又、本実施形態の場合、ＡＶ伝送用バッファ３２に、受信したＭＡＣパケットより得られたＡＶデータパックを書き込む際、誤り訂正が正常に行われて、対応するバッファアドレスの格納状況表示識別子が既に１である場合は、書き込みを中止するようにしてもよい。これは、既に正しく書き込まれていたバッファアドレスのデータ領域に、誤り誤訂正や誤り訂正失敗している可能性があるデータが書き込まれることを防ぐためである。
次に、ＡＶ伝送用バッファ３２内のＡＶデータパックがソースパケットとして再構成され出力されるまでの処理動作を説明する。
ソースパケット出力回路３３は、ＡＶ伝送用バッファ３２に有効なＡＶデータパックが格納されているとき、この有効なＡＶデータパック順次読み出して、ＡＶデータパックの中身を解析する。即ち、ＡＶ伝送用バッファ３２において、格納状況表示識別子が１となるバッファアドレスに格納されるＡＶデータパックが読み出されて、ソースパケット出力回路３３で解析される。
ソースパケット出力回路３３において、ＭＡＰのＦＭＴ、ＦＤＦフィールドによってＡＶデータパックに格納されているＡＶソースパケットの種類を確認する。又、ＭＡＰのＤＢＳによってデータブロックサイズを確認するとともに、この値とＱＰＣで確認されるパディングの値とからＡＶデータパックに格納されているデータブロックの個数が認識される。そして、各データブロックに対して、それぞれのＭＡＰにおけるＳＰＣ及びＤＢＩで指示されたデータブロック番号とＦＮで指示された分割数とに応じて、ＡＶソースパケットを再構築する。更に、ＭＡＰ内のＳＹＴ又はソースパケットヘッダで指示された時刻情報に基づいて、タイムシーケンスを再現しながら、再構築したＡＶソースパケットを出力する。
第１２図は、ＡＶデータパックがＭＰＥＧ２−ＴＳによるＡＶソースパケットのＡＶデータパックである場合のソースパケット出力回路３３の処理の流れを示している。
まず、ソースパケット出力回路３３は、上述のようにＭＡＰを解析する。このとき、ＭＰＥＧ２−ＴＳのＭＡＰが表２に示した値となるため、ソースパケット出力回路３３は、ＡＶ伝送用バッファ３２より読み出されるＡＶデータパックがＭＰＥＧ２−ＴＳによるものであり、ＡＶソースパケットがソースパケットヘッダが付加された状態で分割なしに格納されていることが確認される。
ソースパケット出力回路３３は、更に、ソースパケットヘッダとＡＶソースパケットとを分割して、ソースパケットヘッダ内の時刻情報に後述するオフセット時間を加算した時刻情報と自局のシステムタイマ３４が与える現在時刻情報とを照らし合わせ、両者が一致したときにＡＶソースパケットを出力する。
第１３図は、ＡＶデータパックがＤＶＣによるＡＶソースパケットのＡＶデータパックである場合のソースパケット出力回路３３の処理の流れを示している。
まず、ソースパケット出力回路３３は、上述のようにＭＡＰを解析する。ＤＶＣのＭＡＰが表２に示した値となるため、ソースパケット出力回路３３は、このＡＶデータパックがＤＶＣによるものであり、ＡＶソースパケットが５つに分割されていることが確認される。又、このＡＶデータパックには、何番目のソースパケットの何番目のデータブロックが格納されているかが確認される。
ソースパケット出力回路３３は、ＡＶデータブロックＦ０〜Ｆ４をＦ０，Ｆ１，Ｆ２，Ｆ３，Ｆ４の順の並びになるよう結合して、一つのＡＶソースパケットに再構成する。さらにインデックス０のＡＶデータブロックを格納していたＡＶデータパックのＭＡＰのＳＹＴから時刻情報を確認し、この時刻情報に後述するオフセット時間を加算した時刻情報を求める。オフセットされた時刻情報と自局のシステムタイマ３４が与える現在時刻情報とを照らし合わせ、両者が一致したときにＡＶソースパケットを出力する。
以下に、オフセット時間の計算方法について説明する。
送信局２及び受信局３の内部に構成される回路によって発生する遅延やメディアアクセスのタイミングによって発生する遅延のため、ＡＶソースパケットが送信局２のデータブロック生成回路６に入力された時刻をそのまま利用して、受信局３のソースパケット出力回路３３から出力することはできない。このため、送信局２、受信局３もしくはその両方において、ＡＶソースパケットの時刻情報をオフセットする必要がある。
本実施形態では、オフセット時間の計算は、受信局３のソースパケット出力回路３３が行っている。これは、仮に同じパケットを受信した局が複数台存在する場合、それぞれの局においてパケット出力の時間差ができるが、送信局２が受信局３の内部回路による遅延を考慮せずに送信を行えるという利点がある。各受信局３の間で遅延差が生じるのは、リードソロモン復号処理にかかる時間によるものであるが、すべての局が同じ速度で復号処理をすれば、このような時間差を抑制することができる。
又、逆に、送信局２のデータブロック生成回路６のみでオフセット時間を計算するものとしても構わない。このようにすることで、受信局３が複数台存在する場合でも、すべての受信局のＡＶソースパケット出力をほぼ同じ時間とすることができる。
いずれの方法を用いるとしても、ネットワーク内の送受信局の内部回路構成による遅延量は、システムが破綻しない範囲内であらかじめ決定しておく。又、本発明の装置を備えたネットワークシステムが何を要求しているかによって、いずれの方法がよいかは異なる。
以上のようにして送信局２に入力されたＡＶソースパケットは、受信局３から出力される。
次に無線通信路上でエラーが発生した場合の再送方法について述べる。
受信局３において、ＭＡＣパケット全体が消失したか、又は、ＭＡＣヘッダ部に誤りが発生してこのＭＡＣパケットを破棄した場合、受信局３から送信局２に対してＡＣＫは返信されない。このため、送信局２は次の送信機会において自発的に再送を行う。
次に、受信局３において、ＭＡＣパケット内のデータ部のリードソロモン符号化ブロックにおいて誤りが発生した場合はＡＣＫを使って受信局３から送信局２に対し再送を要求する。このとき、誤り訂正回路２２におけるリードソロモン符号の復号には時間がかかるため、通常のＡＣＫを返すことはできない。よって、復号後に複数のパケットに対し一括してＡＣＫを返すことができる遅延ＡＣＫを使用する。
第１４図に、現在ＩＥＥＥ８０２．１１ｅにおいて提案されている遅延ＡＣＫのフレームフォーマットを示す。
２バイトのＦｒａｍｅ Ｃｏｎｔｒｏｌフィールド及び２バイトのＤｕｒａｔｉｏｎフィールドによって、遅延ＡＣＫであることが宣言される。又、６バイトのＲＡフィールドによって受信側となる送信局２のアドレスが示されるとともに、６バイトのＴＡフィールドによって送信側となる受信局３のアドレスが示される。２バイトのＲｅｃｏｒｄ Ｃｏｕｎｔフィールド内の８ビットの識別子によって、４バイト単位毎のＡＣＫ Ｒｅｃｏｒｄフィールドの数が設定される。第１４図では、４バイトのＡＣＫ Ｒｅｃｏｒｄフィールドを１つとして構成している。又、誤り検出符号として、４バイトのＦＣＳが付加されている。
このＡＣＫ Ｒｅｃｏｒｄフィールド内のシーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｏ．ｆｏｒ ＴＣ−ｂｉｔｍａｐ ＃０ ｂｉｔ）は再送を要求するパケットを示している。即ち、ＴＣ−ｓｅｑ内の４ビットのＴＣＩＤによって、再送する映像ファイルの識別子が示されるとともに、シーケンス番号によって再送するＡＶソースパケットのパケットの番号が示される。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、シーケンス番号で示されるＡＶソースパケット以降のＡＶソースパケットとシーケンス番号で示されるパケットとの時間軸上の位置関係が１ビット毎に示される。ＴＣ−ｂｉｔｍａｐにおいて、再送要求されるＡＶソースパケットの位置を示すビットに１が与えられ、受信が成功したＡＶソースパケットの位置を示すビットに０が与えられる。
尚、現在提案中の遅延ＡＣＫはパケット単位での再送しか考慮されていない。このようなパケット単位での再送は、課題でも述べたが、パケット内に格納されているリードソロモン符号化ブロックのうち一つでも誤り訂正エラーが発生するとすべてを再送しなければならず、非常に効率が悪い。
それに対して、本実施形態では、パケット単位の再送のみならず、リードソロモン符号化ブロック単位（ＡＶデータパック単位）の再送も可能とするように、遅延ＡＣＫを構成する。本実施形態におけるＡＶデータパック格納方法は、パケット内の一部のリードソロモン符号化ブロックしか正常に受信できず、ＡＶ伝送用バッファにそのＡＶデータパックが格納されなかった場合でも、この正常に受信された部分における再生は可能である。又、各ＡＶデータパックはＴａｇにある８ビット識別子によって区別することが可能である。このため、パケット単位で再送をする必要性はなく、誤り訂正ができずに得られなかったＡＶデータパックのみ再送を行えばよい。
第１５図は、第１４図に示したＡＣＫフレームフォーマットのリードソロモン符号化ブロック単位再送拡張の一例であり、パケット単位の再送を行うか、ブロック単位の再送を行うかを識別するためのＢｉｔｍａｐ Ｏｂｊｅｃｔビットを２バイトのＲｅｃｏｒｄ Ｃｏｕｎｔフィールド内に設けている。このＢｉｔｍａｐ Ｏｂｊｅｃｔビットは、ＡＣＫ Ｒｅｃｏｒｄフィールドがパケットのシーケンスナンバーを示すのか、Ｔａｇにある８ビット識別子を示すのかを識別するためのものである。リードソロモン符号化ブロック単位再送を行う場合は、このＢｉｔｍａｐ Ｏｂｊｅｃｔビットを１にする。
Ｂｉｔｍａｐ Ｏｂｊｅｃｔビットが１のとき、ＡＣＫ Ｒｅｃｏｒｄフィールド内の情報は、ＡＶ伝送用バッファ３２内のバッファアドレスに相当するＴａｇにある８ビット識別子の値を示す。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、ＴＣ−Ｓｅｑで示されているＴａｇにある８ビット識別子から以降の受信状況を示すことができる。ＴＣ−ｂｉｔｍａｐにおいて、再送要求されるＡＶデータパックの位置を示すビットに１が与えられ、受信が成功したＡＶデータパックの位置を示すビットに０が与えられる。
即ち、ＴＣ−ｓｅｑ内の４ビットのＴＣＩＤによって、再送する映像ファイルの識別子が示されるとともに、シーケンス番号によって再送するＡＶデータパックの８ビット識別子が示される。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、シーケンス番号で示されるＡＶデータパック以降のＡＶデータパックとシーケンス番号で示されるＡＶデータパックとの時間軸上の位置関係が１ビット毎に示される。
第１１図では、前回の受信においてバッファアドレスＮ−２まではすべて正常な書き込みが行われものとするとともに、受信したＭＡＣパケット内の１番目と３番目のリードソロモン符号化ブロックにおいて誤り訂正エラーが発生しており、ＡＶデータパックが得られないものとする。よって、ＡＶ伝送用バッファ３２のＮ番目のバッファアドレスには正常にデータが書き込まれたが、ｋ−１、ｋ＋１番目のバッファアドレスはヌルになっている。
第１６図は、第１１図で示す受信結果に対し、ＡＣＫ生成回路３６が生成したＡＣＫフレームを示す。ＡＣＫ生成回路３６では、ＡＶ伝送用バッファ３２内の各バッファアドレスの格納状態が、ＡＶ伝送用バッファ３２から与えられる格納状況表示識別子によって確認される。又、ＭＡＣパケット受信部２０で受信されて処理が成されたＡＶデータパックのＴａｇ内の８ビット識別子がＭＡＣ部３５で認識され、ＡＣＫ生成回路３６に伝えられる。
そして、ＭＡＣ部３５よりＭＡＣパケット受信部２０で処理されたＡＶデータパックについての情報が与えられると、ＡＶ伝送用バッファ３２から与えられる格納状況表示識別子によって、再送要求するＡＶデータパックに付加されたＴａｇ内の８ビット識別子が認識され、この認識された８ビット識別子に基づいて、遅延ＡＣＫが生成される。尚、このとき、前回の受信で正常に受信されたＡＶデータパックのＴａｇ内の８ビット識別子はＡＣＫ生成回路３６内に記憶されている。
このとき、まず、ＡＣＫ Ｒｅｃｏｒｄフィールド内の情報がＴａｇにある８ビット識別子を示すために、Ｒｅｃｏｒｄ Ｃｏｕｎｔフィールド内のＢｉｔｍａｐ Ｏｂｊｅｃｔビットが１とされる。又、ＡＣＫ Ｒｅｃｏｒｄフィールドの数がこの場合１つだけとなるので、Ｒｅｃｏｒｄ Ｃｏｕｎｔフィールド内のＲｅｃｏｒｄ Ｃｏｕｎｔが１とされる。
又、ＡＣＫ ＲｅｃｏｒｄフィールドのＴＣ−ｓｅｑにおけるシーケンス番号が、前回正常に受信した最新のバッファアドレスに対応する８ビット識別子ｋ−２の次の８ビット識別子、即ち、今回受信されたＡＶソースパケットの先頭のデータ部に含まれるＡＶデータパックが格納されるバッファアドレスに対応する８ビット識別子ｋ−１となる。
このとき、ＭＡＣ部３５によって与えられる情報より、ＭＡＣパケット受信部２０で受信されて処理されたＡＶデータパックが確認されると、各ＡＶデータパックの受信状況をＡＶ伝送用バッファ３２より与えられる格納状況表示識別子より確認される。今、第１１図において、８ビット識別子ｋ−１，ｋ＋１に対応するバッファアドレスに格納されるべきＡＶデータパックが正常に誤り訂正処理が成されていない。よって、８ビット識別子ｋ−１，ｋ＋１に対応するバッファアドレスにおける格納状況表示識別子が０として与えられる。
よって、この格納状況表示識別子が０となるバッファアドレスに対する８ビット識別子ｋ−１，ｋ＋１が確認されるため、８ビット識別子ｋ−１，ｋ＋１にあたるビット位置が１となるように、ＴＣ−ｂｉｔｍａｐが生成される。即ち、１６ビットのＴＣ−ｂｉｔｍａｐが｜１０１０ ００００ ００００ ００００｜２となる。
尚、ＴＣ−Ｓｅｑに格納されるバッファアドレスは、本実施形態のように前回正常に受信した最新のバッファアドレスの次のアドレスである必要はなく、受信異常が発生したと思われるバッファアドレスとしても構わない。
又、同じ受信機会において受信したすべてのパケットに対する遅延ＡＣＫを生成する必要もない。即ち、受信局３が最後のパケットまでのＡＣＫが返せない場合は、途中までに受信したパケットの遅延ＡＣＫを生成し、送信局２に返すようにしてもよい。又、このとき遅延ＡＣＫを返せなかったパケットに対する遅延ＡＣＫは、ライフタイムを超過しない限りいつ返してもよい。
但し、この場合は、送信局２において、受信局３が何番目のパケットまでに対する遅延ＡＣＫを返信したのかを判別できるようにする必要がある。これは、例えば、遅延ＡＣＫが返されるまでの時間を、送信局２及び受信局３の間、もしくはシステム全体のパラメーターとして、予め設定しておき、その時間を過ぎても遅延ＡＣＫが返されないパケットやバッファアドレスについては再送をするという方法で対処できる。
このような遅延ＡＣＫについては、他の局の送信により遅延ＡＣＫ自体が送信不可能になるということを防ぐために、他の通信より優先させて送信する必要がある。このため、本実施形態では、制御局１から送信される後述するＣＦ−Ｅｎｄを受信した後、ＰＩＦＳ時間が経過したことをＭＡＣ部３５が確認すると、ＡＣＫ生成回路３６で生成した遅延ＡＣＫを送信する。
よって、他の局が送信可能となるまでの時間であるＤＩＦＳ時間＋バックオフ時間よりも短いＰＩＦＳ時間経過後に遅延ＡＣＫが送信されるため、他の局よりも先に受信局３がメディアにアクセスすることが可能となる。尚、ＰＩＦＳ時間よりも短いＳＩＦＳ時間経過後に遅延ＡＣＫの送信を行うようにしても構わないし、制御局１により遅延ＡＣＫ送信のタイミング制御を行うようにしても構わない。
又、上述したようにＭＡＣパケット解析回路２６後段の各回路が動作を行う通常処理が成されるとき、ＡＣＫがＡＣＫ生成回路３６で生成されて送信される。この通常処理が成されるときに送信されるＡＣＫは、誤り検出回路２８でＭＡＣパケットが正常に受信されたことを確認すると、ＭＡＣ部３５によってＡＣＫ生成回路３６にＡＣＫの送信を指示し、ＡＣＫ生成回路３６からＡＣＫが送信される。よって、このＡＣＫの送信は、ＭＡＣパケットの受信を完了してからＳＩＦＳ時間が経過するまでに行われる。
送信局２では、このような遅延ＡＣＫを受信部１１で受信すると、ＡＶ伝送用バッファ７における送信待機状態識別子及び再送可能識別子と、遅延ＡＣＫにおけるＡＣＫ Ｒｅｃｏｒｄフィールドとによって、ＭＡＣ部８がＭＡＣパケット生成回路９がＡＶ伝送用バッファ７より読み出すＡＶデータパックを設定して、ＭＡＣパケット生成回路９の動作を制御する。
又、本実施形態では、ＡＶソースパケットの送受信する際の寿命時間であるライフタイムを考慮した送信を行う。即ち、時間が経過しすぎたＡＶソースパケットを再生すると映像または音声に乱れが生じるため、予めシステム内遅延などを考慮したうえで、ライフタイムを設定しておき、このライフタイムを超えたＡＶソースパケットについては送信を禁止する。
ＡＶソースパケットの再送の場合も同様、受信局３から再送要求されてもライフタイムを経過したＡＶソースパケットは再送しても、受信局３から出力されたＡＶソースパケットが再生不可能となる。そのため、受信局３が送信局２に対して再送要求をするときや、送信局２が実際に再送を開始するときには、ＡＶソースパケットの時刻情報とライフタイムを比較し、ライフタイムを超えているものについては再送を禁止する。
このように、ライフタイムが設定されるときに、遅延ＡＣＫを受信した送信局２における動作を、以下に説明する。第１７図は、第１６図の遅延ＡＣＫを受信した送信局２のＡＶ伝送用バッファ７内において、各バッファアドレスに対する送信待機状態識別子を、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールド内の情報に応じて更新する動作を示す。
上述したように、ＡＶ伝送用バッファ７には、各バッファアドレスに対して、送信待機状態を示す送信待機状態識別子と再送可能である（即ち、バッファアドレスに格納されているＡＶデータパックがライフタイムを超えていない）ことを示す再送可能識別子とが備えられる。
まず、受信部１１で遅延ＡＣＫが受信されると、遅延ＡＣＫのＢｉｔｍａｐ Ｏｂｊｅｃｔビットが１であることが確認されると、ＡＣＫ ＲｅｃｏｒｄフィールドがＴａｇ内の８ビット識別子に関する情報であることをＭＡＣ部８に認識させる。そして、ＭＡＣ部８において、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールドにおけるシーケンス番号が確認されると、このシーケンス番号によって示されれる８ビット識別子が認識される。
そして、シーケンス番号より８ビット識別子がｋ−１であることが認識されるため、Ｔａｇ内の８ビット識別子ｋ−１以降の８ビット識別子に対するバッファアドレスに対する送信待機状態識別子がＡＶ伝送用バッファ７より確認される。今、８ビット識別子ｋ＋２〜ｋ＋４のそれぞれに対するバッファアドレスに格納されるＡＶデータパックが送信待機状態にあるものとすると、第１７図の２段目にあるビットマップように、ＡＶ伝送用バッファ７より｜０００１ １１００ ００００ ００００｜２となる１６ビット分の送信待機状態識別子がＭＡＣ部８に与えられる。
又、ＭＡＣ部８において、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールドにおける第１７図の１段目のような｜１０１０ ００００ ００００ ００００｜２となるＴＣ−ｂｉｔｍａｐが確認される。そして、ＭＡＣ部８において、確認されたＴＣ−ｂｉｔｍａｐとＡＶ伝送用バッファ７より得られた１６ビット分の送信待機状態識別子とのＯＲを取ることで、再送を含めた送信対象となる識別子ビットマップ｜１０１１ １１００ ００００ ００００｜２が得られる。
更に、ＭＡＣ部８において、８ビット識別子ｋ−１以降の８ビット識別子に対するバッファアドレスに対する再送可能識別子がＡＶ伝送用バッファ７より確認される。８ビット識別子ｋ−１〜ｋ＋４のそれぞれに対するバッファアドレスに格納されるＡＶデータパックの有する時刻情報がライフタイム以内にあるものとすると、第１７図の３段目にあるビットマップのように、ＡＶ伝送用バッファ７より｜１１１１ １１００ ００００ ００００｜２となる１６ビット分の再送可能識別子がＭＡＣ部８に与えられる。
そして、上記で得られた送信対象となる識別子ビットマップと、この再送可能識別子によるビットマップとのＡＮＤを取り、その結果を使って送信待機状態識別子のビットマップを｜１０１１ １１００ ００００ ００００｜２として更新する。この更新された１６ビット分の送信待機状態識別子のビットマップと、シーケンス番号より次回の送信時での送信が確認されたＡＶデータパックの８ビット識別子がＭＡＣパケット生成回路９に与えられる。即ち、第１７図の場合、８ビット識別子ｋ−１，ｋ＋１〜ｋ＋４が与えられる。
そして、ＭＡＣパケット生成回路９によって、次回の送信機会に、ＭＡＣ部８によって与えられた８ビット識別子に対応するバッファアドレスのＡＶデータパックがＡＶ伝送バッファ７より読み出されて、ＭＡＣパケットが生成される。よって、第１７図の場合、８ビット識別子ｋ−１，ｋ＋１〜ｋ＋４に対応するバッファアドレスのＡＶデータパックがＡＶ伝送バッファ７より読み出されて、ＭＡＣパケットが生成された後、このＭＡＣパケットが送信される。
又、上述の再送可能識別子は、本来すべてのＡＶデータパックに付加されている時刻情報を調べて、システムタイマ５による現在時刻情報及びライフタイムで認識される時刻情報と比較を行った上で更新される。即ち、システムタイマ５によって確認される現在時刻情報からライフタイムを減算した時刻情報と、ＡＶデータパックに付加されている時刻情報とを比較し、ＡＶデータパックに付加されている時刻情報の方が早い時刻を示す場合は、送信を禁止するために再送可能識別子を０とする。
又、制御局１によって指示されるメディアアクセス周期が決まっており、且つライフタイムがそのメディアアクセス周期の整数倍である場合、送信局２のＡＶ伝送用バッファ７における再送可能識別子とアドレスバッファとの関係が第１８図で示すような関係となるようにしても構わない。このとき、メディアアクセス周期がシステムタイマ５によってカウントされ、ＡＶデータパックがＡＶ伝送用バッファ７に入力されるとき、システムタイマ５によってカウントされたメディアアクセス周期の計数値が第１８図のようにサイクルフィールドに格納される。
又、このＡＶ伝送用バッファ７に入力されるＡＶデータパックのバッファアドレスに対する送信待機状態表示識別子及び再送可能識別子が１とされる。更に、システムタイマ５によってメディアアクセス周期がカウントされる度に、現在の周期回数となる計数値とライフタイムをメディアアクセス周期で割った数との差分を計算し、サイクルフィールドがその計算値より小さくなったとき、そのバッファアドレスに対する再送可能識別子を０にする。
例えば、第１８図のように、ライフタイムがメディアアクセス周期の３倍になっており、又、システムタイマ５によってカウントされるメディアアクセス周期の計数値が２３であるものとする。よって、このとき、ＡＶ伝送用バッファ７において、Ｔａｇ内の８ビット識別子ｋ＋４に対するバッファアドレスにＡＶデータパックが格納されるとき、このバッファアドレスに対するサイクルフィールドに計数値２３が格納される。
又、８ビット識別子ｋ＋４のバッファアドレスに対する送信待機状態表示識別子及び再送可能識別子が１とされる。そして、サイクルフィールドに格納された値が現在の周期回数となる計数値２３とライフリミットをメディアアクセス周期で割った数３との差分２３−３＝２０よりも小さくなるバッファアドレスに対する再送可能識別子が０とされる。
このようにすることで、再送の際に送信局２において、ＡＶ伝送用バッファ７内のすべてのバッファアドレスに格納されたＡＶデータパックの送信時間を調べる必要がなくなるため、上述したＡＶデータパックに付加されている時刻情報を比較する場合にくらべ回路を大幅に簡略化することができる。
次に、制御局１による帯域確保の方法について、基本周期内に衝突が発生する区間を備える場合と備えない場合それぞれに対して説明する。
１．基本周期内に衝突が発生する区間を備える場合
まず、メディアアクセスのための基本周期の決定方法について述べる。第１９図は、ＨＣＦを備えた制御局１と送信局２と受信局３の基本的なパケット交換を時間軸で示した一例である。この第１９図の例では、１つの基本周期に、衝突が発生しない区間ＣＦＰと衝突が発生する区間ＣＰとが含まれる。
第１９図のように、まず、制御局１から帯域確保フレームであるＣＦ−Ｐｏｌｌが送信部３９から送信される。このＣＦ−Ｐｏｌｌが送信されてから、制御局１からＣＦ−Ｅｎｄが送信されるまでの間は衝突が発生しない区間ＣＦＰとして確保される。ＣＦ−Ｐｏｌｌを受信した送信局２は、自局が送信局であることをＣＦ−Ｐｏｌｌより確認して、受信局３に対しＲＴＳを生成して送信する。
又、ＲＴＳを受信した受信局３は、自局が受信局であることをＲＴＳより確認して、送信局２に対し、ＣＴＳを生成して送信する。ＣＴＳを受信した送信局２は受信局３が受信可能な状態であることを確認し、受信局３に対し、ＭＡＣパケット生成回路９で生成したＭＡＣパケットを含むパケット＃１〜＃ｎの単一転送又はバースト転送を行う。
そして、制御局１が、後述する第２２図のアルゴリズムを利用して送信局２が無線メディアの帯域を解放したことを確認すると、ＣＦ−ＥｎｄをＭＡＣ部３８で生成して送信部３９より送信することで、衝突が発生しない区間ＣＦＰを終了させる。この区間ＣＦＰ内でのＣＦ−Ｐｏｌｌ、ＲＴＳ、ＣＴＳ、パケット＃１〜＃ｎ、ＣＦ−Ｅｎｄそれぞれの間隔はＳＩＦＳ（１６μｓ）である。
次に、衝突が起きる可能性のある区間ＣＰが開始する。第１９図の例においては遅延ＡＣＫをこの区間で返すものとしている。但し、遅延ＡＣＫが従来のＩＥＥＥ８０２．１１方式に従った動作を行う通信装置の妨害で返信されなくなることを避けるため、ＰＩＦＳ時間後に返信を行っている。尚、この遅延ＡＣＫの返信方法については、上述の通り制御局１による遅延ＡＣＫの送信時間を制御することによるものでも構わない。
そして、最初のＣＦ−Ｐｏｌｌが送信されてから基本周期分の時間が経過すると、ネットワークシステムを構成する局間で通信が行われていないときは、区間ＣＰを終了させるとともに次の基本周期が開始されるように、制御局１から、ＣＦ−Ｐｏｌｌが送信される。尚、基本周期内で区間ＣＰで送信されるＬＡＮパケットが送信終了する場合、現時点における基本周期が開始されたときに最初に送信されるＣＦ−Ｐｏｌｌが送信されてから基本周期に相当する時間が経過すると、次の基本周期を開始するためにＣＦ−Ｐｏｌｌが送信される。
第１９図の中段において、区間ＣＦＰにおいて送信局２から送信されるパケットの物理層にＩＥＥＥ８０２．１１ａ物理層（５ＧＨｚ）を使用した場合の物理層パケットの構成を示す。ＩＥＥＥ８０２．１１ａ物理層は最大通信速度が５４Ｍｂｐｓで、周波数帯域５ＧＨｚにおけるＯＦＤＭ方式を備えた物理層であり、先に述べたＤＶＣやＭＰＥＧ２−ＴＳ高画質モードの転送を行える可能性のある物理層である。
Ｐｒｅａｍｂｌｅ、Ｓｉｇｎａｌ、Ｓｅｒｖｉｃｅ、Ｔａｉｌ、ＰＡＤＳは、ＩＥＥＥ８０２．１１ａ物理層によってＭＡＣパケットであるＰＤＵに付加されるものであり、ＰｒｅａｍｂｌｅとＳｉｇｎａｌについては、それぞれの転送時間が１６μｓ、４μｓと決まっている。１６ビットのＳｅｒｖｉｃｅと６ビットのＴａｉｌとＰＡＤＳとＭＡＣパケットであるＰＤＵとは、最大通信速度が５４ＭｂｐｓとなるＯＦＤＭ方式で転送することができる。最大通信速度５４Ｍｂｐｓとなる時のＯＦＤＭ方式での１シンボル長は２１６ビットである。そして、ＰＡＤＳは、Ｔａｉｌを含む最後のシンボルのシンボル長が２１６ビットになるように付加される。
第１９図の下段において、上述のＩＥＥＥ８０２．１１ａ物理層におけるＰＤＵであるＭＡＣパケットの構成を示す。ＩＥＥＥ８０２．１１ＭＡＣ層では、３２バイトのＭＡＣヘッダ及び４バイトのＦＣＳを除いたプロトコルのフレームボディと呼ばれるフィールドの最大値が２３１２バイトに制限されている。従って、２２４バイトのリードソロモン符号化ブロックを１０個まで収めることが可能である。
よって、本実施形態で挙げたＡＶソースパケットのうち最も速い転送速度をもつＤＶＣの場合について考えると、上述の１パケットで９６（データブロックサイズ）×２（データブロック個数）×１０（リードソロモン符号化ブロック個数）＝１９２０バイトを転送することができる。
又、第１９図に示すように、各パケット＃１〜＃ｎに含まれる複数のリードソロモン符号化ブロックの内の１ブロックを再送要求されたＡＶデータパックによるリードソロモン符号化ブロックに対する帯域として確保している。実際にデータ送信を行う場合は、このブロックを必ず再送要求されたＡＶデータパックによるリードソロモン符号化ブロックとする必要はないが、演算処理を容易にするためにこのような構成としている。よって、正規の（再送ではない）ＤＶＣによるＡＶソースパケットを格納できるデータサイズは１７２８バイトとなる。
又、ＭＡＣパケット全体の大きさは、３２（ＭＡＣヘッダ）＋４（ＩＶ）＋１６（ＭＡＣヘッダ部のＲＳ符号）＋２２４×１０（リードソロモン符号化ブロック）＋４（ＦＣＳ）＝２２９６バイトである。これに、１６ビットのＳｅｒｖｉｃｅと６ビットのＴａｉｌとを加え、２１６ビット（ＯＦＤＭシンボル長）で割って小数点以下を切り上げた値（＝８６）がＰＡＤＳを含むＯＦＤＭシンボル数となる。
１つのＯＦＤＭシンボルの転送時間は４μｓであるので、４×８６（ＯＦＤＭシンボル数）＋１６（Ｐｒｅａｍｂｌｅ）＋４（Ｓｉｇｎａｌ）＝３６４μｓが一つの物理層パケットを転送するのに必要な時間である。
又、遅延ＡＣＫは、ＣＦ−Ｅｎｄが送信完了した後、ＰＩＦＳ（２５μｓ）経過した後に出力される。リードソロモン符号化処理は、第９図に示すようにリードソロモン符号化ブロック２個分の遅延が発生する。受信局３の内部回路の処理速度が物理転送路の速度と同じとすると、この遅延は６８μｓとなる。これに対し、第１９図における最後のパケット＃ｎ送信終了後からの遅延ＡＣＫを送信するまでの間隔は、１６μｓ（ＳＩＦＳ）＋２７μｓ（ＣＦ−Ｅｎｄ）＋２５μｓ（ＰＩＦＳ）＝６８μｓとなり、リードソロモン復号処理と同等の時間を確保できる。実際に遅延ＡＣＫを送信する際には物理層パケットの１６μｓのプリアンブル区間があるため、遅延ＡＣＫ内のデータ生成に更に時間的な余裕がある。
衝突が起きる可能性がある区間ＣＰで局４がメディアアクセスをするにはＤＩＦＳ時間（３４μｓ）＋ランダムバックオフ時間による期間だけ待機しなければならない。よって、ＣＦ−Ｅｎｄが送信されて、区間ＣＦＰが終了するとともに区間ＣＰが開始すると、ＤＩＦＳ時間よりも短いＰＩＦＳ時間経過後に遅延ＡＣＫが送信されるため、遅延ＡＣＫの送信を局４の送信動作によって妨害されることはない。
尚、遅延ＡＣＫを局４の送信動作によって妨害されないための方法としては、上記以外にも、制御局１が送信する帯域確保フレームＣＦ−Ｐｏｌｌに続いて遅延ＡＣＫを送信するようにしても構わない。この場合、遅延ＡＣＫを送信するまでに、帯域確保フレーム送信時間及び遅延ＡＣＫの送信までの待機時間が更に必要となるが、より確実に遅延ＡＣＫを送信することが可能になる。
又、第２０図は、上述した各制御パケットの転送時間などを考慮して、衝突しない区間ＣＦＰに含まれるパケット数を表すパケットバースト回数と、ＤＶＣソースパケットの実転送レート及び基本周期の長さとの関係を計算した結果をグラフで示したものである。
第２０図でＬＡＮなしと記述されているグラフは衝突が発生しない区間を最小にした場合であり、ＬＡＮ有りと記述されているグラフは転送速度２４Ｍｂｐｓ、フレームボディ長２３１２バイトのＬＡＮパケットと共存したときの値を示す。実転送レートは、再送用の帯域はパケットのデータ部を構成する１０個のリードソロモン符号化ブロックのうち一つを再送専用として割り当てたとして、残りのリードソロモン符号化ブロックで転送できる転送量を示したものである。
第１９図の例では、例えばＬＡＮと共存したときにＤＶＣの実転送速度が３０Ｍｂｐｓ以上となる最小の周期、約６．８ｍｓ（バースト回数１５回、実転送レート３０．２Ｍｂｐｓ）を基本周期とする。このようにすることで、基本周期をもっとも転送速度が速いＤＶＣ転送に適合するよう設計できるため、ＤＶＣよりも転送速度が低いＭＰＥＧ２−ＴＳの送信も可能である。
次に、上述のようにして各局間で通信が行われているときにおいて、制御局１がメディアアクセスを許可する送信局を決定する際の動作について、以下に説明する。第２１図は、制御局１が新規に周期的なメディアアクセスを要求する送信局２に対し、メディアアクセスを許可するか否かを判別するためのフローチャートである。
尚、本実施形態において、通信ネットワークに属する各局のメディアアクセス周期を基本周期の整数倍とする。又、基本周期内における周期的にポーリングされる各局のメディアアクセス時間の合計の上限は、この基本周期におけるＤＶＣ転送の場合にかかるメディアアクセス時間と同等とする。更に、制御局１は、周期的なメディアアクセスを許可した各局の基本周期内におけるメディアアクセス時間及びメディアアクセス周期を帯域管理部４１に記憶し、記憶したメディアアクセス時間を合計した時間をＤＶＣ転送時にかかるメディアアクセス時間から減算し、このようにして得られた時間を残り帯域として記憶する。
制御局１は、制御局１以外の局（以下、送信局とする）から送信される新規に周期的なメディアアクセスの許可を得るための帯域確保要請フレームを受信部４０で受信する（ＳＴＥＰ５１）。このとき、帯域確保要請フレームより、帯域情報として、送信局が必要とするメディアアクセス周期及びメディアアクセス時間が確認される。
そして、この帯域情報が帯域管理部４１に送出されると、帯域管理部４１において、この新規に周期的なメディアアクセスを要求する送信局が必要とするメディアアクセス周期が基本周期の整数倍であるか確認される（ＳＴＥＰ５２）。即ち、この送信局に対して送信する帯域確保フレームＣＦ−Ｐｏｌｌの送信周期が、基本周期の整数倍であるか、帯域管理部４１で確認される。
このとき、メディアアクセス周期が基本周期の整数倍であることが確認されると（Ｙｅｓ）、帯域管理部４１において、帯域確保要請フレームを送信した送信局が必要とするメディアアクセス時間と上述した残り帯域とを比較する（ＳＴＥＰ５３）。そして、メディアアクセス時間が残り帯域よりも短いことが確認されると（Ｙｅｓ）、帯域管理部４１において、このメディアアクセス時間と基本周期とを比較する（ＳＴＥＰ５４）。
この帯域管理部４１で、帯域情報から確認されたメディアアクセス時間が基本周期より短いことが確認されると（Ｙｅｓ）、送信局から要求されたメディアアクセス周期及びメディアアクセス時間が帯域管理部４１に格納されるとともに、このメディアアクセス時間を残り帯域から減算することで、残り帯域の時間を更新する（ＳＴＥＰ５５）。このＳＴＥＰ５５の動作を終了すると、再び、ＳＴＥＰ５１に移行して、帯域確保要請フレームの受信確認が行われる。
又、ＳＴＥＰ５２において、メディアアクセス周期が基本周期の整数倍でないとき（Ｎｏ）、又は、ＳＴＥＰ５３において、メディアアクセス時間が残り帯域より長いとき（Ｎｏ）、又は、ＳＴＥＰ５４において、メディアアクセス時間が基本周期より長いとき（Ｎｏ）、ＳＴＥＰ５１で受信された帯域確保要請フレームによる要求を拒否し、帯域管理部４１における確認されたメディアアクセス周期及びメディアアクセス時間が破棄される（ＳＴＥＰ５６）。そして、このＳＴＥＰ５６の動作を終了すると、ＳＴＥＰ５５の時と同様、再び、ＳＴＥＰ５１に移行して、帯域確保要請フレームの受信確認が行われる。
以上のようにメディアアクセス時間の設定を行うことによって、既存ＬＡＮのための帯域を保護しつつ、ＤＶＣまたはＤＶＣ以下の転送速度をもつリアルタイムＡＶデータの帯域を容易に確保することができる。
このように制御局１が送信局２のメディアアクセスの許可を行うとき、制御局１が送信局２の周期内での送信終了を検出し、送信局２が利用していた帯域を解放するために、第２２図に示すフローチャートに従って動作する。
まず、現在のＩＥＥＥ８０２．１１と同様、制御局１は、受信部４０で送信局２から送信されるパケット及び受信局から送信されるＡＣＫ又は遅延ＡＣＫが受信されると、受信された信号をＭＡＣ部３８で確認してメディアの監視を行う（ＳＴＥＰ１０１）。そして、ＭＡＣ部３８において、送信局２から送信されるパケット内のＭＡＣヘッダに含まれるＮＦ（Ｎｏｎ Ｆｉｎａｌ）ビットより送信局２の状態を監視し、ＮＦビットが０となったか否かを確認することで、送信終了を確認する（ＳＴＥＰ１０２）。即ち、第１９図の場合、パケット＃ｎ内のＭＡＣヘッダに含まれるＮＦビットが０であるとともに、パケット＃１〜＃ｎ−１内のＭＡＣヘッダに含まれるＮＦビットが１である。
このようにＭＡＣヘッダのＮＦビットにより送信終了を確認する処理はＰＣＦに適合したものである。このＰＣＦの通信では、送信局２と受信局３との間で通信を行うときには必ず制御局１を経由するので、このＮＦビットを監視することができる。又、制御局１がパケットを受信できず、送信局２へＡＣＫの返信できなかった場合には、送信局から即座にパケットが再送されていたため、ＳＴＥＰ１０２の処理による送信局２からのパケットの送信終了の確認が可能である。
ＳＴＥＰ１０２で、ＮＦビットが１である場合（Ｎｏ）、送信局２からのパケットの送信が終了してからＳＩＦＳ時間以上の時間が経過するまでに送信局２又は受信局３からの信号を受信部４０で受信したか否かが、ＭＡＣ部３８でシステムタイマ３７より与えられる時刻情報より確認される（ＳＴＥＰ１０３）。即ち、送信局２から送信されるパケットが最後のパケットであり、このパケットが送信されてからＳＩＦＳ時間以上経過したか否かが確認される。
このとき、送信局２からのパケットが送信終了してからＳＩＦＳ時間が経過するまでに、送信局２から送信される次のパケット又は受信局から送信されるＡＣＫを受信すると（Ｎｏ）、送信局２が送信可能とされるメディアアクセス時間であるＴＸＯＰ時間が経過したか否かが、ＭＡＣ部３８によってシステムタイマ３９による時刻情報を参照することで確認される（ＳＴＥＰ１０４）。そして、ＴＸＯＰ時間の経過が確認されなかったときは（Ｎｏ）、再度ＳＴＥＰ１０１以降の処理動作を行う。
このようなＳＴＥＰ１０３及びＳＴＥＰ１０４の処理動作が成されることで、送信局２及び受信局３の間で制御局１を経由しない通信を行うとともに遅延ＡＣＫの送信が可能となるＨＣＦにおいても、送信局２の帯域解放処理を行うことができる。即ち、ＮＦビットの確認を行わない場合でも、送信局２から送信される最後となるパケットを制御局１において確認することができる。
ＳＴＥＰ１０２においてＮＦビットが０であることが確認されたとき（Ｙｅｓ）、又、ＳＴＥＰ１０３において送信局２からのパケットの送信終了後ＳＩＦＳ時間以上経過したことが確認されたとき（Ｙｅｓ）、又、ＳＴＥＰ１０４においてＴＸＯＰ時間が経過したことが確認されたとき（Ｙｅｓ）、現在の衝突が発生しない区間ＣＦＰにおいて別の局へポーリングを行うポーリングスケジュールがあるかどうかが、ＭＡＣ部３８によって、帯域管理部４１より得られる帯域確保時間情報より確認される（ＳＴＥＰ１０５）。
そして、ＭＡＣ部３８によって、帯域確保時間情報よりポーリングスケジュールがあることが確認されると（Ｙｅｓ）、このポーリングスケジュールによって指定される次の局に対してメディアアクセスを許可するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１０６）、ＳＴＥＰ１０１以降の動作を行う。又、逆に、ポーリングスケジュールがないことが確認されると（Ｎｏ）、衝突が発生しない区間ＣＦＰが終了したことが確認されるため、衝突が発生しない区間を終了させるように、ＣＦ−Ｅｎｄを送信部３９から送信する（ＳＴＥＰ１０７）。
このようなフローチャートに従って動作するとき、区間ＣＦＰ内で２つの局に対してメディアアクセスが許可されている場合、第２３図のような通信が行われる。即ち、区間ＣＦＰの開始が確認されて、制御局１よりＣＦ−Ｐｏｌｌが送信されると、ＣＦ−Ｐｏｌｌによって送信局として設定される局からＲＴＳが送信されるとともに、ＲＴＳによって受信局として設定される局からＣＴＳが送信される。その後、送信局となる局と受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認され、ポーリングスケジュールにより次に送信局として設定される局をポーリングするためのＣＦ−Ｐｏｌｌが制御局１より送信される。その後、同様に、次に送信局となる局からＲＴＳが送信された後、次に受信局となる局からＣＴＳが送信されると、この送信局となる局及び受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認されるとともに、次のポーリングスケジュールが確認されないので、区間ＣＦＰを終了するためのＣＦ−Ｅｎｄが制御局１より送信される。
又、第１９図の例において、ＬＡＮと共存するために確保した区間を補償するために、メディアアクセス周期で許容されるジッタが設けられている。即ち、衝突が起きる可能性がある区間ＣＰにおいて、各局間で送受信されるＬＡＮパケットが基本周期から外れても送信許容されるジッタが設定される。又、このように区間ＣＰにおいてＬＡＮパケットが基本周期から外れることで生じた基本周期のずれを解消して帯域補填を行うために、次の基本周期を早く終了するためのジッタが設定される。
このような第１９図に示すジッタを用いた帯域補填動作について、以下に説明する。第２４図は、制御局１のＣＦ−Ｐｏｌｌの送信タイミングにおいて局４が２４Ｍｂｐｓの転送速度でＬＡＮパケットを送信中であったときの、各局の通信動作を示すためのタイミングチャートである。
局４が、基本周期終了後、ＬＡＮパケットの送信を終了すると、この局４からＬＡＮパケット受信した局より、ＬＡＮパケットの送信終了後ＳＩＦＳ時間の間隔でＬＡＮパケットに対するＡＣＫが返信される。そして、局４は、このＡＣＫを受信するために、ＤＩＦＳ＋ランダムバックオフ時間だけ待機する。このとき、制御局１は、ＬＡＮパケット送信終了をＭＡＣ部３８で確認すると、ＰＩＦＳ時間だけ待機した後に、送信部３９より帯域確保フレームＣＦ−Ｐｏｌｌを送信する。よって、基本周期終了からＣＦ−Ｐｏｌｌの送信までの間に、ＬＡＮパケットによる遅延となるジッタが生じる。
このように生じた遅延となるジッタは、ＭＡＣ部３８内に格納される。そして、ＭＡＣ部３８において、この遅延となるジッタを基本周期の長さから減算した時間を、次の基本周期の長さとして設定する。そして、第２２図のフローチャートに従って動作した後、ＣＦ−Ｅｎｄを送信して衝突が発生しない区間ＣＦＰを終了させる。その後、衝突が起きる可能性がある区間ＣＰになるが、制御局１は、上述のようにしてＭＡＣ部３８で設定した基本周期となると、この区間ＣＰを終了させて、次の基本周期を開始するために、ＣＦ−Ｐｏｌｌを送信部３９から送信する。このとき開始させる次の基本周期の長さは、元の周期の長さとされる。
即ち、制御局１では、遅延となるジッタが発生した次の基本周期については、その長さを、発生したジッタの長さ分短い長さとする。よって、遅延となるジッタが発生した次の基本周期では、ＣＦ−Ｐｏｌｌが送信されてから、基本周期の長さからジッタを減算した時間が経過したことを確認すると、次の基本周期が開始されるように、ＣＦ−Ｐｏｌｌを送信する。このとき、帯域補填するために早期終了させた分のジッタが発生する。
このように、局４による妨害によって遅延した分だけ早く衝突が起きる可能性がある区間ＣＰを終了させ、次の基本周期を開始する。この場合、局４による妨害が再び発生する可能性があるが、２４ＭｂｐｓのＬＡＮパケットであれば、その送信時間がジッタの範囲を超えることはないため、問題はない。
又、局４のＬＡＮパケットの転送速度が、本例で第２０図を利用して基本周期を計算した際に使用した転送速度以下である場合は、制御局１は、衝突が起きる可能性がある区間ＣＰにおいて、遅延ＡＣＫの送信終了後ＰＩＦＳ時間だけ待機する。そして、帯域確保フレームＣＦ−Ｐｏｌｌを送信して、衝突が発生しない区間ＣＦＰを再開する。このような動作を、失った帯域を補填するまで続けることによって、局４の妨害を防ぐとともに、速やかに帯域を補填することができる。
このような帯域補填を行うことにより、ＤＶＣによるＡＶソースパケットの送信と２４Ｍｂｐｓで送信される既存ＬＡＮとの共存が可能になる。
２．基本周期内に衝突が発生する区間を備えない場合
上記では、第１９図のような衝突が起きる可能性がある区間ＣＰが基本周期内に設けられるときの例を挙げたが、この区間ＣＰが基本周期内に設けられないものとしても構わない。この区間ＣＰが基本周期内に設けられないときの、ＨＣＦを備えた制御局１と送信局２と受信局３の基本的なパケット交換におけるタイミングチャートを、第２５図に示す。
第２５図の場合においても、第１９図の場合と同様、まず、制御局１から帯域確保フレームであるＣＦ−Ｐｏｌｌが送信部３９から送信された後、ＣＦ−Ｐｏｌｌを受信した送信局２よりＲＴＳが送信され、このＲＴＳを受信した受信局３よりＣＴＳが送信される。このようにして、送信局２及び受信局３が決定されると、送信局２から受信局３に対して、ＭＡＣパケットを含むパケット＃１〜＃ｎが送信される。
そして、制御局１において、パケット＃ｎの送信が終了したことが確認されると、ＣＦ−Ｅｎｄが送信部３９から送信される。このＣＦ−Ｅｎｄを受信局３が受信すると、ＣＦ−Ｅｎｄの受信が終了してからＳＩＦＳ時間が経過後に、受信局３から送信局２に対して遅延ＡＣＫが送信される。尚、ＣＦ−Ｐｏｌｌ、ＲＴＳ、ＣＴＳ、パケット＃１〜＃ｎ、ＣＦ−Ｅｎｄそれぞれの間隔は、第１９図の例と同様、ＳＩＦＳである。
そして、最初のＣＦ−Ｐｏｌｌが送信されてから基本周期分の時間が経過すると、次の基本周期が開始されるように、制御局１から、ＣＦ−Ｐｏｌｌが送信される。尚、基本周期内で最後に送信される遅延ＡＣＫが送信終了した後、送信待機時間ＳＩＦＳ以上の時間が経過してから次の基本周期が開始されるように、ＳＩＦＳ時間分待機した後に送信部３９からＣＦ−Ｐｏｌｌが送信される。
このように基本周期が設定されるとき、制御局１がメディアアクセスを許可する送信局を決定する際の動作については、第１９図の例と同様、第２１図のフローチャートに従って、周期的なメディアアクセスを要求する送信局２に対して、メディアアクセスの許可を行う。よって、その詳細な説明は省略する。
又、本例において、制御局１が送信局２の周期内での送信終了を検出し、送信局２が利用していた帯域を解放するために、第２６図に示すフローチャートに従って動作する。尚、第２６図のフローチャートにおいて、第２２図に示すフローチャートと同一の処理を行うステップについては、同一の符号を付してその詳細な説明は省略する。
まず、制御局１は、受信部４０で受信された信号をＭＡＣ部３８で確認してメディアの監視を行い（ＳＴＥＰ１０１）、送信局２から送信されるパケット内のＭＡＣヘッダにおけるＮＦビットが０となったか否かを確認する（ＳＴＥＰ１０２）。このとき、ＮＦビットが１である場合（Ｎｏ）、次に、送信局２から最後のパケットが送信されてからＳＩＦＳ時間以上経過したか否かが確認される（ＳＴＥＰ１０３）。更に、送信局２からＳＩＦＳ時間以内にパケットが送信されると（Ｎｏ）、ＴＸＯＰ時間が経過したか否かが確認される（ＳＴＥＰ１０４）。
このＳＴＥＰ１０２〜ＳＴＥＰ１０４の処理動作がおこなわれているとき、ＮＦビットが０であること、又は、最後のパケットが送信局２から送信されたこと、又は、ＴＸＯＰ時間が経過したことのそれぞれが確認されると、次のポーリングスケジュールがあるか確認される（ＳＴＥＰ１０５）。
このとき、帯域管理部４１より与えられる帯域確保時間情報から、次のポーリングスケジュールが確認されると（Ｙｅｓ）、送信部３９からＣＦ−Ｅｎｄを送信する（ＳＴＥＰ１５１）。その後、受信部４０で送信局３からの遅延ＡＣＫを受信したか否かがＭＡＣ部３８で確認され（ＳＴＥＰ１５２）、遅延ＡＣＫが受信されなかったとき（Ｎｏ）、ＣＦ−Ｅｎｄ送信終了後ＳＩＦＳ時間が経過したか否かが、システムタイマ３７からの時刻情報より確認される（ＳＴＥＰ１５３）。このとき、ＳＩＦＳ時間の経過が確認されなかったとき（Ｎｏ）、再び、ＳＴＥＰ１５２以降の動作を行う。
又、ＳＴＥＰ１５２において遅延ＡＣＫの受信が確認されたとき（Ｙｅｓ）、又は、ＳＴＥＰ１５３においてＣＦ−Ｅｎｄ送信終了後ＳＩＦＳ時間の経過が確認されたとき（Ｙｅｓ）、ＳＴＥＰ１０５で確認されたポーリングスケジュールによって指定される次の局に対してメディアアクセスを許可するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１０６）、ＳＴＥＰ１０１以降の動作を行う。
又、ＳＴＥＰ１０５において、次のポーリングスケジュールが確認されなかったとき（Ｎｏ）、送信部３９からＣＦ−Ｅｎｄを送信する（ＳＴＥＰ１５５）。その後、遅延ＡＣＫを受信したか否かが確認され（ＳＴＥＰ１５６）、遅延ＡＣＫが受信されなかったとき（Ｙｅｓ）、ＳＩＦＳ時間が経過したか否かが確認される（ＳＴＥＰ１５７）。このとき、ＳＩＦＳ時間の経過が確認されなかったとき（Ｎｏ）、再び、ＳＴＥＰ１５６以降の動作を行う。
又、ＳＴＥＰ１５６において遅延ＡＣＫの受信が確認されたとき（Ｎｏ）、又は、ＳＴＥＰ１５７においてＳＩＦＳ時間の経過が確認されたとき（Ｙｅｓ）、基本周期における最初のＣＦ−Ｐｏｌｌを送信してから基本周期分の時間が経過したことをシステムタイマ３７からの時刻情報より確認した後、次の基本周期を開始するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１５８）、ＳＴＥＰ１０１以降の動作を行う。
このようなフローチャートに従って動作するとき、区間ＣＦＰ内で２つの局に対してメディアアクセスが許可されている場合、第２７図のような通信が行われる。即ち、基本周期の開始が確認されて、制御局１よりＣＦ−Ｐｏｌｌが送信されると、送信局となる局からＲＴＳが送信されるとともに、受信局となる局からＣＴＳが送信される。その後、送信局となる局と受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認され、ＣＦ−Ｅｎｄが制御局１から送信される。このＣＦ−Ｅｎｄの送信終了後ＳＩＦＳ時間が経過して、遅延ＡＣＫが受信局となる局から送信されたことが確認された後、遅延ＡＣＫ送信後ＳＩＦＳ時間経過すると、ポーリングスケジュールにより次に送信局として設定される局をポーリングするためのＣＦ−Ｐｏｌｌが制御局１より送信される。
その後、同様に、次に送信局となる局からＲＴＳが送信された後、次に受信局となる局からＣＴＳが送信されると、この送信局となる局及び受信局となる局との間で通信が行われる。そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認されるとともに、次のポーリングスケジュールが確認されないので、まず、ＣＦ−Ｅｎｄが制御局１から送信される。
このＣＦ−Ｅｎｄの送信終了後ＳＩＦＳ時間が経過して、受信局となる局より遅延ＡＣＫが送信されたことが確認されると、基本周期を開始してＣＦ−Ｐｏｌｌを送信してから、基本周期となる時間が経過したか確認される。そして、基本周期となる時間が経過したことが確認されると、次の基本周期を開始するために、制御局１からＣＦ−Ｐｏｌｌが送信される。
尚、制御局１からＣＦ−Ｅｎｄを送信した後、ＳＩＦＳ時間以上の時間が経過したことが確認されると、ポーリングスケジュールがある場合は、すぐにＣＦ−Ｐｏｌｌが送信され、又、ポーリングスケジュールがない場合は、基本周期が終了したことが確認された後にＣＦ−Ｐｏｌｌが送信される。
又、本実施形態において、第１８図で示したように、ＡＶソースパケットのライフタイムをメディアアクセス周期の整数倍とすることによって、メディアアクセス周期が基本周期の整数倍であるため、ライフタイムを基本周期の整数倍とすることができる。このように、ＡＶソースパケットのライフタイムを基本周期で計測することができるので、このライフタイムの管理が容易になる。
よって、上述したように、ライフタイムがＡＶソースパケットを送受信することのできる時間を示すため、ライフタイムに対するメディアアクセス周期の倍数が再送可能なメディアアクセス周期の計数値に相当するのと同様、基本周期の倍数は再送可能な基本周期の計数値として考えることができる。又、ＡＶソースパック毎の再送回数が多ければ多いほどエラーに対する耐性は向上するが、ネットワークシステムにおいてＡＶソースパケットを再生する際の遅延が大きくなるとともに、送信局２及び受信局３それぞれに備えられるＡＶ伝送用バッファ７，３２のサイズも増大する。
上述のように、基本周期を６．８ｍｓとした場合、この間に転送されるＤＶＣ（スタンダード、３０Ｍｂｐｓ）ソースパケットの量は、２５．５Ｋバイトであり、ＭＰＥＧ２−ＴＳ高画質モード（２４Ｍｂｐｓ）ソースパケット量は２０．４Ｋバイトである。ライフタイムの間に転送される全ＡＶソースパケット量は、ライフタイムに対する基本周期の倍数に比例する。このライフタイムの間に転送される全ＡＶソースパケット量は、即ち、送信局２及び受信局３それぞれのＡＶ伝送用バッファ７，３２に必要とされるサイズになる。
よって、本実施形態における送信局２の機能及び受信局３の機能を一つのＬＳＩで実現する場合には、備えるＡＶ伝送用バッファのバッファサイズを適切なものとして、このバッファサイズに適合するよう基本周期を決める必要がある。又、基本周期が小さいほど、ＡＶ伝送用バッファのバッファサイズを節約しながら再送回数を増やすことができ、同時にライフタイムによるシステム遅延も抑えることができる。
又、本実施形態では高い頻度で時刻合わせを行うために、基本周期毎に必ず制御局１から送信されるＣＦ−ＰｏｌｌやＣＦ−Ｅｎｄに対して、システムタイマ３７から与えられる時刻情報が送信部３９で付加されて送信される。このようなＣＦ−ＰｏｌｌやＣＦ−Ｅｎｄのパケットフォーマットが、第２８図及び第２９図のように表される。
即ち、ＣＦ−Ｐｏｌｌは、第２８図のように、ＣＦ−Ｐｏｌｌであることを示すための３２バイトのＭＡＣヘッダと、システムタイマ３７より与えられた時刻情報となる２バイトのタイムスタンプと、送信局となる局を指定するとともにメディアアクセス時間などを備えるデータと、４バイトの誤り検出符号であるＦＣＳとによって構成される。又、ＣＦ−Ｅｎｄは、第２９図のように、ＣＦ−Ｅｎｄであることを示すための３２バイトのＭＡＣヘッダと、システムタイマ３７より与えられた時刻情報となる２バイトのタイムスタンプと、４バイトの誤り検出符号であるＦＣＳとによって構成される。
又、ＩＥＥＥ８０２．１１のタイマ精度は、上述したように０．０１％であるため、６．８ｍｓに一回で時刻合わせをする場合、ジッタを１．３μｓ程度に抑えることができる。本実施形態では、基本周期毎に送信される第２８図のような構成のＣＦ−Ｐｏｌｌ及び第２９図のような構成のＣＦ−Ｅｎｄそれぞれが受信される度に、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄそれぞれに備えられたシステムスタンプによって時刻合わせが行われる。よって、ＩＥＥＥ８０２．１１のシステムタイマ精度がμｓオーダーであるため、ＡＶソースパケットのタイムシーケンス再生におけるジッタがほとんど無視できる。
但し、基本周期を長くした場合は、制御局１は、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄとは別に時刻合わせ専用のフレームを送信するようにしても構わない。又、制御局１自身が送信局を兼ねる場合は、ＣＦ−Ｐｏｌｌを出さずに送信を開始する場合がある。この場合についても、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄとは別に時刻合わせ専用のフレームを送信するようにしても構わない。
尚、本実施形態では、ＤＶＣを転送するための基本周期を例にしたが、例えば、あるシステムではＤＶＣやＭＰＥＧ２−ＴＳ高画質モードの送信をあきらめ、通常のＭＰＥＧ２−ＴＳを数チャネル分流したいという場合もあるだろうし、またあるシステムではできるかぎりＬＡＮを優先したいという場合もある。衝突が生じない区間においてどのようなＡＶデータを扱うか、衝突が起きる可能性がある区間においてどのような機器と共存するかによって、基本周期と実転送レートが大きく変わる。そのようなシステムの構築例をいくつか取り決めておけば、ユーザーが望む最適な無線ネットワークシステムを簡単に実現できる。
又、本実施形態では、ライフタイムは基本周期の整数倍になるように設定したが、送信局及び受信局それぞれのＡＶ伝送バッファのバッファサイズに制限がある場合は、このＡＶ伝送バッファにおいて、リアルタイムＡＶデータを格納できる最大時間をライフタイムとしても構わない。この場合や、又は、システムとしてのライフタイムが設定されている場合、実転送レートが転送したいＡＶデータの転送量よりも大きく、且つ、その周期の長さがライフタイムの整数分の１になるように、基本周期を設定しても構わない。
更に、本実施形態では、各送信局が送信を行う際に与えるメディアアクセス時間が、リアルタイムＡＶデータが最速の転送速度で転送されるときのメディアアクセス時間とされる。又、このメディアアクセス時間の値の合計がシステムが扱う最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えないように、送信局として新規に参入する局の制限を行う。
これに対して、基本周期毎又は基本周期の整数倍毎に、各送信局がＡＶ伝送用バッファの空きメモリ情報となるキューイング情報を制御局１に通知し、制御局１は、このキューイング情報を用いて、次回以降の基本周期において各送信局が必要とするメディアアクセス時間を予想し、この予想に基づいてメディアアクセス制御を行うようにしても構わない。
又、ＭＰＥＧ２−ＴＳのような可変レートのリアルタイムＡＶデータを扱う送信局は、常に最大の転送速度で送信することがない。本実施形態では、最大転送速度時に各送信局が必要とするメディアアクセス時間の合計が最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えることはできない。しかしながら、上述のキューイング情報からメディアアクセス時間を予想する場合、予想したメディアアクセス時間の合計が最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えない限り、制御局１は各送信局に対するメディアアクセス制御を行うことができる。
しかし、転送レートの可変量はリアルタイムＡＶデータの内容によって変化するため、予測が不可能な場合もある。このような場合には、制御局１が予測した転送速度と各送信局が実際に必要とした転送速度の差分によって発生した齟齬を吸収するため、ＡＶ伝送用バッファのメモリサイズバッファを大きくするとともに、ライフタイムを長くすればよい。
又、再送すべきリードソロモン符号化ブロックを識別するために、本実施形態では、バッファアドレスを識別子として収めたＴａｇを使用したが、受信したパケットのシーケンス番号及びそのパケット内で誤り訂正できなかったリードソロモン符号化ブロックの位置を知らせるようにしても構わない。この場合、受信局３は、例えばＭＡＰにあるＳＰＣとＤＢＩを参照して、ＡＶ伝送用バッファ３２にＡＶデータパックを格納する際にＳＰＣとＤＢＩが連続的になるように格納する。
又、このとき、送信局２においては、送信済みのパケットのシーケンス番号及びＡＶデータパックの格納状況を保存するバッファを備える必要がある。更に、受信局３においては、ソースパケット出力回路３３だけではなく、ＡＶ伝送用バッファ３２においても、ＭＡＰを解析するための機能を備える必要がある。このようにすることにより付加情報となるＴａｇフィールドのオーバーヘッドを減らすことも可能である。
又、本実施形態では説明を省略したが、ＬＬＣ ＰＤＵデータに対しても本実施形態で説明した処理と同じ処理を行うことができる。但し、ＬＬＣ ＰＤＵの場合は、複数のリードソロモン符号化ブロックに分割できても、各リードソロモン符号化ブロック単位ではデータ処理不可能なため、必ずパケットがすべてそろった後に上位層に渡されて処理される。しかし、リードソロモン符号化ブロック単位での再送はパケット単位再送よりも再送に必要とする帯域が少ないため、帯域を有効に使う意味で有効である。
産業上の利用可能性
以上より、ネットワークシステムで各局がメディアアクセスできる基本周期を予め設定することで、制御局において簡単な処理動作と小規模の回路で各局のメディアアクセス制御を実現できる。又、誤り訂正符号と誤り訂正符号化ブロック単位の再送および暗号化を行うことにより、送信局及び受信局において、最小の帯域で信頼性の高くかつプライバシを保護する通信を実現できる。又、帯域制御フレームによる時刻合せによって、送信局と受信局の間で発生するＡＶソースパケットのジッタを最小におさえ、どの局でＡＶソースが再生されても違和感なく鑑賞することが可能になる。
更に、ライフタイムを基本周期の整数倍にすることで、送信局及び受信局におけるＡＶ伝送用バッファを最適なサイズにできるだけでなく、ＡＶソースパケットのライフタイムの管理が容易になる。又、基本周期の計算において既存局のメディアアクセス時間を確保しているため、どのような状況でも既存局との共存を実現できる。又、制御局の帯域解放処理を行うことにより、既存局が使用する帯域を多くとれる。
以上説明したように、本発明によれば、ネットワークシステムで各局がメディアアクセスできる基本周期をあらかじめ決めてしまうことで制御局において簡単なアルゴリズムで各局のメディアアクセス制御を実現できる。
誤り訂正符号と誤り訂正符号化ブロック単位の再送を使用することで、再送の発生頻度を抑え、かつ再送が発生した場合でも再送に必要とされる帯域を抑えつつ信頼性の高い通信を実現できる。
プライバシ保護のため、暗号化を行った場合でも、上記誤り訂正化ブロック単位の再送を実現できる。
ライフタイムを基本周期の整数倍とすることで、送信局、受信局におけるＡＶ伝送用バッファを最適なサイズにできるだけでなく、ＡＶソースパケットのライフタイムの管理が容易になるという効果がある。
基本周期の計算において既存局のメディアアクセス時間を確保していることにより、どのような状況でも既存局との共存を実現できる。さらに既存局が想定したメディアアクセス時間以上の通信を行った場合でも、失った帯域を補填するまで既存局にメディアアクセス権を与えないメディア制御をすることにより、衝突が発生しない区間における通信路の品質を落とさない通信を実現できる。
制御局が積極的に帯域解放処理を行うことにより、衝突が発生しない区間において発生した余剰帯域を衝突が起きる可能性のある区間に分配することで、既存局のメディアアクセス機会を増やすことが可能になる。
さらに帯域制御フレームによる時刻合せによって、送信局と受信局の間で発生するＡＶソースパケットのジッタを最小におさえ、どの局でＡＶソースが再生されても違和感なく鑑賞が可能になる。
【図面の簡単な説明】
第１図は、本発明に係わる無線通信ネットワークの一実施例を示す概略構成図である。
第２図は、本発明に係わる送信装置のブロック図である。
第３図は、本発明に係わる受信装置のブロック図である。
第４図は、本発明に係わる制御局のブロック図である。
第５図は、本発明に係わるＭＰＥＧ２−ＴＳパケット入力処理を示す図である
第６図は、本発明に係わるＤＶＣパケット入力処理を示す図である。
第７Ａ図及び第７Ｂ図は、本発明に係わるＭＡＰフォーマットを示す図である。
第８図は、本発明に係わるパケット送信処理の流れを示す図である。
第９図は、本発明に係わる誤り検出回路出力に対する誤り訂正回路出力の遅延を示す図である。
第１０図は、本発明に係わるパケット内の誤り訂正符号有無を判別するフローチャートを示す図である。
第１１図は、本発明に係わるパケット受信処理の流れを示す図である。
第１２図は、本発明に係わるＭＰＥＧ２−ＴＳパケット出力処理を示す図である。
第１３図は、本発明に係わるＤＶＣパケット出力処理を示す図である。
第１４図は、本発明に係わる現在提案されている遅延ＡＣＫフレームフォーマットを示す図である。
第１５図は、本発明に係わるリードソロモン符号化ブロック単位再送のために拡張した遅延ＡＣＫフレームフォーマットを示す図である。
第１６図は、本発明に係わる遅延ＡＣＫフレームを示す図である。
第１７図は、本発明に係わる送信局の送信状況更新を示す図である。
第１８図は、本発明に係わるライフタイムを考慮したＡＶ伝送用バッファを示す図である。
第１９図は、本発明に係わる送信周期とパケット構成を示す図である。
第２０図は、本発明に係わるＤＶＣ／ＬＡＮ（２４Ｍｂｐｓ）共存時のバースト回数と実転送レートおよび基本周期を示す図である。
第２１図は、本発明に係わる帯域管理のフローチャートを示す図である。
第２２図は、本発明に係わる帯域解放のフローチャートを示す図である。
第２３図は、本発明に係わる送信周期とパケット構成を示す図である。
第２４図は、本発明に係わるＬＡＮパケットによる帯域損失に対する補填を示す図である。
第２５図は、本発明に係わる送信周期とパケット構成を示す図である。
第２６図は、本発明に係わる帯域解放のフローチャートを示す図である。
第２７図は、本発明に係わる送信周期とパケット構成を示す図である。
第２８図は、本発明に係わるＣＦ−Ｐｏｌｌフレームを示す図である。
第２９図は、本発明に係わるＣＦ−Ｅｎｄフレームを示す図である。
第３０図は、ＰＣＦのＣＦＰとＣＰの関係を示す図である。
第３１図は、従来のタイマ精度と時刻合わせを示す図である。
本発明は、リアルタイムＡＶデータの転送を行う無線通信方式および装置、特にＩＥＥＥ８０２．１１無線通信方式および装置に関わる。
背景技術
ＩＥＥＥ８０２．１１無線通信方式は、本来無線ＬＡＮのために規格化された標準である。
この方式では、一定周期で衝突が発生する可能性がある区間（Ｃｏｎｔｅｎｔｉｏｎ Ｐｅｒｉｏｄ：ＣＰ）と衝突が生じない区間（Ｃｏｎｔｅｎｔｉｏｎ Ｆｒｅｅ Ｐｅｒｉｏｄ：ＣＦＰ）が入れ替わることを特徴とし、衝突が発生する区間は主にＬＡＮの用途に、衝突が生じない区間は通信帯域の確保を必要とする通信のために使うことができる。
第３０図は、従来のＩＥＥＥ８０２．１１のＰＣＦ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という機能を使用したときにＣＦＰとＣＰの発生する区間を時間軸で示した図である。
ＣＦＰではＰＣ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｏｒ）と呼ばれる特定の端末が、ＣＦＰを利用する端末をポーリングすることにより、通信帯域の確保を行う。ＰＣは、各端末の時刻合わせなどを行うための情報（ＴＩＭと呼ばれる）をＢｅａｃｏｎと呼ばれるフレームに載せて一定間隔で送信する。送信されるＢｅａｃｏｎのうち数回に１回の割合で、スリープ状態の端末に対する通知情報（ＤＴＩＭと呼ばれる）を含むＢｅａｃｏｎが送られる。スリープしている端末はＤＴＩＭを含むＢｅａｃｏｎが送信される時刻のあたりになるとアクティブ状態になり、ＤＴＩＭを含むＢｅａｃｏｎを受信し必要な通信を行うと再びスリープ状態に入る。
ＣＦＰはＤＴＩＭを含むＢｅａｃｏｎに続いて発生し、次のＢｅａｃｏｎが送信されるまでには終了する。ＩＥＥＥ８０２．１１におけるＢｅａｃｏｎの送信周期は、例えば１００ｍｓ程度の値の場合がある。
しかしながら、ＣＦＰを使って、ＤＶＣまたはＭＰＥＧ２−ＴＳなどのリアルタイムＡＶデータを送信する場合、この周期が問題になる。ＤＶＣの標準画像は３０Ｍｂｐｓ、ＭＰＥＧ２−ＴＳは標準で６Ｍｂｐｓ、高画質モードで２４Ｍｂｐｓの転送レートで連続的または継続的に送信局に入力されつづける。しかし、送信の機会、即ち、従来のＩＥＥＥ８０２．１１においてＣＦＰが発生する間隔は数１００ｍｓに一回と非常に長く、その間に入力される膨大なソースパケットをバッファリングしなければならない。更に、数回のＢｅａｃｏｎ周期のうち１周期にしかＣＦＰが存在しないため、たとえ現在規格化が進められているＩＥＥＥ８０２．１１ａ ５ＧＨｚ物理層（物理転送速度最大５４Ｍｂｐｓ）を用いても、ＡＶデータの転送に必要な帯域を確保することが困難である。
又、有線メディアに比べ信頼性が劣る無線メディアでは、通信路上でエラーやパケット消失が発生しやすい。現在のＩＥＥＥ８０２．１１ＭＡＣ層は誤り訂正符号もパケット消失符号もないため、通信路上でエラーが発生した場合、パケットの再送が必要である。しかしながら、ＣＦＰは数１００ｍｓ周期に一回しか発生せず、且つ再送待機中にもリアルタイムＡＶデータは刻々と入力されつづける。従って、再送を行うには更に数１００ｍｓ分のデータを保持するバッファが必要になる。
更に、この周期は、ユーザーに対し、遅延という形で現れる。このため、ユーザーが流れてくるＡＶデータに対して、停止、巻き戻しなどのコマンドを発行しても、即座に反映できないという問題がある。
上記問題を解決するためにＢｅａｃｏｎの間隔を短くすることは、即ち、スリープしている端末に対してより多くのアクティブ状態を強いることになるため、難しい。
このため、リアルタイムＡＶデータ伝送のようなＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）通信をＩＥＥＥ８０２．１１において実現するための規格化を行っているＩＥＥＥ８０２．１１ｅでは、２００１年３月現在、ＨＣＦ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という手法が提案されている。ＰＣＦでは数回に１回のＢｅａｃｏｎ周期でしか衝突が生じない区間がなかったのに対し、ＨＣＦでは自由に衝突が生じない区間を設けることができる。この方式では、周期的なデータ送信を希望する送信局が制御局（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｏｒ：ＨＣ）に対し、メディアアクセス周期及びメディアアクセス時間の要求を行い、それを認めた制御局は、ＣＦＰ、ＣＰに関わらず、帯域確保フレームを定期的に送信局に送信（ポーリング）することで衝突が発生しない区間を生成する。
従来のＩＥＥＥ８０２．１１のＣＦＰにおいては、一般にＨＣがＰＣを兼ねるため、ＰＣＦを搭載した従来のＩＥＥＥ８０２．１１通信機器に通信を妨害されることはない。
従来のＩＥＥＥ８０２．１１のＣＰにおいては、従来のＩＥＥＥ８０２．１１通信装置はＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）という機能を使って通信を行う。ＤＣＦでは、送信を開始する前にＤＩＦＳ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる３４μｓの待機時間とランダムバックオフで定められた時間だけキャリアセンスするＣＳＭＡ／ＣＡ方式が用いられる。
これに対し、ＨＣＦを備えた制御局（ＨＣ）はＣＦＰ、ＣＰに関わらずＰＩＦＳ（ＰＣＦ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる２５μｓの時間間隔だけキャリアセンスすればメディアアクセスが可能になる。又、制御局（ＨＣ）にポーリングされた被制御局はＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）と呼ばれる１６μｓの時間間隔だけキャリアセンスするだけで送信を開始できる。このため、ＨＣＦ機能を搭載した機器が通信を開始すると、ＤＣＦで動作する従来の局はメディアアクセスができなくなり、ＨＣＦを備えた制御局（ＨＣ）、被制御局は従来の局に妨害されることなく通信できる。
しかしながら、ＰＣＦではＰＣが決めたＢｅａｃｏｎ間隔に基づき各送信局が動作していたのに対し、現在提案されているＨＣＦでは各送信局が、それぞれ、ＨＣに対しメディアアクセス周期（ポーリング周期）及びメディアアクセス周期内での通信を行うための時間を要求する。このため、ＨＣは、複雑な各送信局のメディアアクセススケジューリングをしなければならない。
又、無線メディア上で発生した誤りに対し再送を行う場合、再送用の帯域を別途確保しておく必要がある。この再送による負担を減らすために、現在誤り訂正符号（リードソロモン符号）を使用する提案も行われている。このリードソロモン符号が用いられる場合、パケットが複数のブロックに分割されて、各ブロック毎にリードソロモン符号化が成される。よって、送信されるデータのパケットは、複数のリードソロモン符号化ブロックによって構成される。しかし、現在の提案では、パケット内のほとんどのリードソロモン符号化ブロックでエラー訂正に成功した場合であっても、一つでもリードソロモン復号に失敗すればパケット全体を再送する必要がある。
更に、実際の通信においてはプライバシ保護のため暗号化が行われる。この暗号化が各ブロック毎に行われ、暗号化が行われた各ブロックにリードソロモン符号化による誤り訂正符号が付加される。そして、この誤り訂正符号が付加された複数のリードソロモン符号化ブロックによって成るデータ部全体に対し、誤り検出符号が付加される。
現在の提案ではＭＡＣヘッダと同じリードソロモン符号化ブロックに暗号鍵（公開鍵）が添付されているため、このリードソロモン符号化ブロックに対する誤り訂正が成功すれば、データ部の各リードソロモン符号化ブロックの暗号鍵による復号は可能となる。しかし、パケット自体の復号の成功を保証するには、データ部を構成する全てのリードソロモン符号化ブロックに対する誤り訂正が成功する必要がある。
上記にあげた２つの状況は、ともに誤り訂正に成功したリードソロモン符号化ブロックまでも再送せねばならず、そのために余計な通信帯域を確保せねばならない。即ち、再送するデータ量が、本来再送を必要とするデータ量に比べて大きくなり、データ転送の効率化を図るべき無線通信において、非効率的なデータ転送を行うこととなる。
上記とは別の問題として、システム全体の時刻合わせの問題がある。第３１図が、ネットワークシステムにおける各局のシステムタイマの精度と、受信局のソースパケット出力で発生するジッタを示す図である。
送信局はＡＶソースパケットに対し自局のタイマが示す入力時の時刻情報を添付し、受信局は添付された時刻情報と自局のタイマを使ってＡＶソースパケットのタイムシーケンスを再生する。しかし、各局のタイマは全く同じ精度ではないため、ある程度の時間が経過すると、各々の時刻がずれてくる。この送信局、受信局の間の時刻ずれが、受信局がＡＶソースパケットのタイムシーケンス再生をする際にジッタとして現れる。
即ち、第３１図のように、制御局のシステムタイマに比べて、送信局のシステムタイマが進むと、送信局で送信されるソースパケットのタイミングが早くなるとともに、ソースパケットに付加される時刻情報が制御局のシステムタイマの表す時刻より早いものとなる。逆に、第３１図のように、受信局のシステムタイマが遅れると、受信局で出力されるソースパケットのタイミングが遅れて、ソースパケットの出力間隔が本来の出力間隔と比べて長くなり、ジッタが生じる。更に、定期的に与えられるビーコンによって、各局のシステムタイマが一致させられるので、時間遅れが発生している受信局におけるソースパケットの出力間隔が本来の出力間隔と比べて短くなり、同じくジッタが生じる。
一方、個々のＡＶソースパケットは出力タイミングが厳しく決まっており、定められたジッタ範囲内で出力されなければならない。しかしながら、現在のＨＣＦではビーコンによる時刻合わせしか行われない。ＩＥＥＥ８０２．１１におけるタイマ精度は０．０１％であるが、仮に１００ｍｓに一回送信されるビーコンでしか時刻合わせを行わないとすると、送信局と受信局の間では最大２０μｓ程度の時刻ずれが発生する。
上述したパケット毎のデータ再転送によるデータ転送の非効率化や、許容範囲外となるジッタの発生によるデータの欠落及び出力異常などにより、ＩＥＥＥ８０２．１１などで設定される無線通信システムは、ＡＶデータの転送に十分な通信システムではない。
発明の開示
よって、本発明は、ＡＶデータ転送に適切となる効率的なデータ送信を行うことができる無線通信システムを提供することを目的とする。
本発明の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局によって送信局とされる通信装置が、時刻を管理するシステムタイマと、アプリケーションデータに対して前記システムタイマより得られた該アプリケーションの入力時刻に基づいて生成した時系列的管理用の時刻情報を付加するとともに、前記アプリケーションデータのうち保持期間が定められたアプリケーションデータに対して送信可能な期間を設定するデータ処理部と、該データ処理部で前記時刻情報が与えられた前記アプリケーションデータを一時的に保持するバッファと、該バッファから前記アプリケーションデータを読み出すともに該アプリケーションデータに誤り訂正符号を付加する誤り訂正符号付加部と、該誤り訂正符号付加部で誤り訂正符号が付加されたアプリケーションデータから送信パケットを作成する送信パケット生成部と、該送信パケット生成部で作成した前記送信パケットを送信する送信部と、前記バッファからアプリケーションデータを読み出すことを制御するとともに、前記送信パケット生成部で生成された前記送信パケットを通信帯域が確保された時間に前記送信部から送信することを制御する送信制御部と、前記送信部から送信した一つ又は複数の送信パケットの受信を示す応答信号を受信する受信部と、を備え、前記送信部から送信する際に、前記送信制御部において、前記システムタイマから得られる現在時刻と前記バッファ内に格納されたアプリケーションデータに対して設定された前記送信可能な期間とを比較し、該現在時刻が前記送信可能な期間を超過しているアプリケーションデータについては、前記誤り訂正符号付加部が前記バッファから読み出さず、又、前記送信部より前記送信パケットを送信した後、所定時間以上経過しても、前記送信パケットに対する前記応答信号を前記受信部で受信しなかったことが前記送信制御部において確認されるとき、該送信パケットが正しく受信されていないと判定することを特徴とする。
又、本発明の別の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局によって受信局とされる通信装置が、時刻を管理するシステムタイマと、時系列的管理用の時刻情報が付加されたアプリケーションデータから成る送信パケットを受信する受信部と、該受信部で受信された送信パケットに誤り訂正符号が付加されているか否かを判定する誤り訂正判定部と、前記受信部で受信された送信パケットのうち誤り訂正符号が付加された送信パケットに対して誤り訂正を施す誤り訂正処理部と、誤り訂正が成された送信パケットよりアプリケーションデータを生成する第１復号部と、前記受信部で受信された送信パケットのうち誤り訂正符号が付加されていない送信パケットより前記アプリケーションデータを生成する第２復号部と、前記第１及び第２復号部で生成された前記アプリケーションデータを一時的に格納する第１及び第２バッファと、前記システムタイマによる時刻が前記アプリケーションデータに付加された時刻情報による時刻と一致したことを確認すると、前記アプリケーションデータを前記第１又は第２バッファから読み出して出力するデータ出力部と、１つ又は複数の送信パケットの受信状態を示す応答信号を送信する送信部と、を備え、前記受信部で受信された送信パケットに対して、前記誤り訂正処理部及び前記第１復号部による第１演算処理と、前記第２復号部による第２演算処理とを同時に施すことを特徴とする。
本発明の別の通信システムは、複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、前記制御局となる通信装置が、時刻を管理するシステムタイマと、他の通信装置から送信される通信帯域の確保を要求する帯域確保要求信号を受信する受信部と、通信帯域が確保され衝突が生じない非衝突区間を時分割で管理する帯域管理部と、前記システムタイマより得られる現在時刻を他の通信装置に認識させるための時刻情報信号と、前記非衝突区間の開始を他の通信装置に認識させるための非衝突区間開始信号と、前記非衝突区間の終了を他の通信装置に認識させるための非衝突区間終了信号と、を送信する送信部と、を備え、前記非衝突区間を発生させる周期を基本周期とし、前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間の周期であるメディアアクセス周期が、前記基本周期の整数倍でないとき、該他の通信装置の帯域確保の要求を拒否することを特徴とする。
発明を実施するための最良の形態
以下に本発明の実施例を示す。本発明における通信ネットワークは有線、無線を特定しないが、以下の実施例ではＩＥＥＥ８０２．１１無線通信方式を用いた場合を例にして説明を行う。
第１図は、本発明を実施する無線ネットワーク構成例である。
第１図の１は衝突が発生しない区間において送信を行う局の無線メディアへのアクセスを制御する制御局である。本実施形態ではメディアアクセス制御機能としてＨＣＦを備えるものとする。この制御局１は、通常、ＨＣ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｏｒ）と呼ばれる。
第１図の２はリアルタイムＡＶデータの送信局、３はリアルタイムＡＶデータの受信局である。リアルタイムＡＶデータ送信局２及びリアルタイムＡＶデータ受信局３の衝突が発生しない区間（ＣＦＰ）におけるメディアアクセスは制御局１によって管理される。本実施形態では、このＣＦＰにおけるメディアアクセス管理を機能させるために、制御局１及び送信局２及び受信局３はそれぞれ、ＨＣＦを備えるものとする。
第１図の４は衝突が起きる可能性がある区間（ＣＰ）のみメディアアクセスできる従来の局である。本実施形態では、局４はＤＣＦのみを備えるものとする。
尚、第１図において、それぞれの局には送信、受信、制御、従来のメディアアクセスのようにひとつの機能しか実装されていないように記載しているが、これは説明を簡潔にするためであり、実際には一つの局に複数の機能を実装するものとしてもよい。
第２図は、送信局２の構成を示すブロック図である。
第２図の５はネットワークシステム全体の時刻情報を管理するシステムタイマである。システムタイマ５は制御局１が発行するＢｅａｃｏｎなどの時刻情報を格納したフレームに含まれる現在時刻情報に基づいて時刻合わせをすることで、常に制御局１内のシステムタイマとほぼ同じ時刻になるように動作するとともに、この現在時刻情報に基づいてメディアアクセス時間を管理する。
第２図の６は入力されたＡＶソースパケットを転送に適した形に変換するためのデータブロック生成回路である。又、このデータブロック生成回路６は、複数のデータブロックの集合体に対して、ＡＶソースパケットに対するデータブロックの生成情報（本実施形態ではこの情報をＭＡＰと呼ぶことにする）、及びＡＶソースパケットが入力されたときのシステムタイマ５で測定される時刻情報を添付する。
ＡＶソースパケットのデータブロック生成回路６への入力時刻を管理するタイマを別途用意する方法もあるが、本実施形態では説明を簡単にするために、システムタイマ５を使用している。このＭＡＰと時刻情報を付加されたデータブロックの集合を、本実施形態において、ＡＶデータパックと呼ぶことにする。
第２図の７はＡＶ伝送用バッファであり、データブロック生成回路６で生成されたＡＶデータパックを順次格納する。ＡＶ伝送用バッファ７は、ＡＶデータパック単位でバッファアドレス管理を行い、且つ、送信待機状態にあるバッファアドレスを示す識別子を備える。この識別子は、ＡＶデータパック単位毎のバッファアドレスに対応して与えられる１ビットのデータである。そして、ＡＶ伝送用バッファ７にＡＶデータパックが入力されると、入力されたＡＶデータパックのバッファアドレスに対応する識別子を１とし、又、ＡＶ伝送用バッファ７からＡＶデータパックが出力されると、出力されたＡＶデータパックのバッファアドレスに対応する識別子を０とする。ＡＶ伝送用バッファ７のバッファサイズは、後述するライフタイム分のＡＶデータパックを格納できるサイズとする。又、ＡＶ伝送用バッファ７には、後述する再送可能であることを示す再送可能識別子をも備える。
第２図の８は送信局２のメディアアクセスを制御するＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）部であり、第２図の９はＡＶ伝送用バッファ７から出力されるＡＶデータパック、またはＬＬＣ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層のデータをバッファリングするＬＬＣ−ＰＤＵ（ＬＬＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）用バッファ１０内のデータをＭＡＣパケットに格納するためのＭＡＣパケット生成回路である。
第２図の１１は、他局から送信されたパケットを受信するための受信部である。受信部１１が制御局１が送信したＢｅａｃｏｎを受信した場合、Ｂｅａｃｏｎ内部に格納されている時刻情報をシステムタイマ５に通知し、システムタイマ５はその時刻情報を使って自身の時刻情報を更新する。受信部１１が制御局１からのＡＶ伝送のための帯域確保フレームを受信した場合、ＭＡＣ部８にその旨を通知する。通知されたＭＡＣ部８は、ＡＶ伝送用バッファ７の状態を調べ、バッファに送信待機状態のＡＶデータパックが存在しているときは、ＭＡＣパケット生成回路９に対しＭＡＣパケットの生成を開始するよう要求する。受信部１１が受信局３からのＡＣＫを受信したときは、受信局３が再送を必要としているかどうかを判断し、再送が必要であれば、その旨をＭＡＣ部８に通知し、次回の送信時に必要なデータを送信できるようにする。
ＭＡＣパケット生成回路９は、入力データを選択するセレクタ１２と、入力されたデータに対し誤り検出符号を付加する誤り検出符号付加回路１３と、誤り検出符号を付加した状態のデータを暗号化する暗号化器１４と、ＭＡＣパケットヘッダを生成するＭＡＣパケットヘッダ生成回路１５と、ＭＡＣパケットヘッダと暗号化されたデータを選択するセレクタ１６と、セレクタ１６の出力に対し誤り訂正符号を付加する誤り訂正符号付加回路１７と、誤り訂正符号付加回路１７での誤り訂正符号をデータに付加するか否かを選択するセレクタ１８と、入力されたパケット全体に対し誤り検出符号を付加する誤り検出符号付加回路１９と、で構成される。本実施実施形態において、誤り訂正符号付加回路１７はリードソロモン符号（２２４，２０８）を扱うものとする。即ち、２０８バイトのデータに対し、１６バイトのリードソロモン符号を付加し、全体としては２２４バイトのデータを出力する。
第３図は、受信局３の構成を示すブロック図である。
第３図におけるＭＡＣパケット受信回路２０は、パケット全体の誤り検出を行う誤り検出回路２１と、パケットに付加された誤り訂正符号により誤り訂正を行う誤り訂正回路２２と、ＨＣＦに対応したＭＡＣパケットを解析するＭＡＣパケット解析回路２３と、データに施された暗号を復号する復号器２４と、復号されたデータの誤りを検出する誤り検出回路２５と、データの出力先をＬＬＣ−ＰＤＵ用バッファ３０及びＡＶ伝送用バッファ３２のいずれにするかを選択するセレクタ２９と、リードソロモン符号を付加されていないパケットを解析するＭＡＣパケット解析回路２６と、データに施された暗号を復号する復号器２７と、復号されたデータの誤りを検出する誤り検出回路２８で構成される。本実施形態では、誤り訂正回路２２はリードソロモン符号（２２４，２０８）を扱う。即ち２２４バイトのデータに対し、末尾１６バイトをリードソロモン符号として扱い、エラー訂正を行った２０８バイトのデータを出力する。
尚、第３図の受信局３は、ＭＡＣパケット解析回路、復号器、誤り検出符号をそれぞれ２つずつ備えているが、これはリードソロモン復号処理には時間がかかるため、リードソロモン復号中に従来のＭＡＣパケットを受信したような場合に、従来のＭＡＣパケットの処理ができなくなることを防ぐためである。従って、このような機能が必要ではない場合には、ＭＡＣパケット解析回路、復号器、誤り検出符号それぞれ１つのみを備えるものとしても構わない。又、ＬＬＣ−ＰＤＵ用バッファについても、同時に２系統からの書き込みが可能な制御回路をもつバッファであればＬＬＣ−ＰＤＵ用バッファを１つとしても構わない。
誤り検出回路２５から出力されるデータがＡＶデータパックであるならば、セレクタ２９を通じてＡＶ伝送用バッファ３２に与えられて、ＡＶ伝送用バッファ３２に格納される。ＡＶ伝送用バッファ３２は、ＡＶデータパック単位にアドレス管理を行い、バッファアドレスに対してＡＶデータパックの格納状態を示す識別子を備える。この識別子は、ＡＶデータパック単位毎のバッファアドレスに対応して与えられる１ビットのデータである。そして、ＡＶ伝送用バッファ３２に正常なＡＶデータパックが入力されると、入力されたデータパックのバッファアドレスに対応する識別子を１とし、ＡＶ伝送用バッファ３２からＡＶデータパックが出力されると、出力されたデータパックのバッファアドレスに対応する識別子を０とする。ＡＶ伝送用バッファ３２のバッファサイズは、後述するライフタイム分のＡＶデータパックを格納できるサイズとする。
第３図の３３はソースパケット出力回路である。このソースパケット出力回路３３は、ＡＶ伝送用バッファ３２に蓄えられているＡＶデータパックからソースパケットを再構築し、ソースパケットに添付されている時刻情報又はソースパケットから算出された時刻情報とシステムタイマ３４に従ってタイムシーケンスを再現し、ソースパケットを出力する。
ＭＡＣパケット受信回路２０がＢｅａｃｏｎなどの時刻情報を格納したフレームを受信すると、その時刻情報をシステムタイマ３４に通知し、システムタイマ３４は通知された時刻情報に従って自身の時刻情報を更新する。
第３図の３５は、受信装置のメディアアクセスを制御するＭＡＣ部である。このＭＡＣ部３５によって、システムタイマ３４の時刻情報や、メディアセンスによって自局がメディアアクセス可能であるかどうか、即ち、ＡＣＫ送信可能な時であるかを判断する。
第３図の３６はＡＣＫ生成部である。このＡＣＫ生成部３６は、ＭＡＣパケット受信部２０の状況やＡＶ伝送用バッファ３２の状態に応じて、送信局２に対しＡＣＫを生成する。
第４図は、制御局１の構成を示すブロック図である。
第４図で３７はシステムタイマであり、ＭＡＣ部３８はこのシステムタイマ３７の時刻情報をもとにメディアアクセス制御を行う。システムタイマ３７が規定の時刻を示すと、ＭＡＣ部３８はＢｅａｃｏｎや帯域確保フレームを送信するよう送信部３９に要求する。
第４図の４０は、他局から送信されたパケットを受信するための受信部であり、新規に帯域確保を要求したい送信局からの帯域確保要請フレームなどを受信する。受信部４０が帯域要請フレームを受信すると、その情報は帯域管理部４１に与えられる。帯域管理部４１は周期的に帯域を確保する必要がある局と、ＴＸＯＰと呼ばれるメディアアクセス時間を管理している。帯域管理部４１は、帯域に余裕があれば、この要求を許可し、内部に必要な情報を記憶する。ＭＡＣ部３８は帯域管理部４１から帯域情報が変わったことを通知されると、適当な時間からその局のための帯域確保フレームを送信するよう、送信部３９に要求する。
既存の局４については、ＩＥＥＥ８０２．１１のＰＣＦ／ＤＣＦを備えた従来の装置であるため、その構成の説明を省略する。
以下では送信局２に入力されたＡＶソースパケットが受信局３にて出力されるまでの処理の流れについて順次説明する。ここでは例として、ＡＶソースパケットがＭＰＥＧ２−ＴＳ又はＤＶＣ（スタンダード）である場合について説明する。
データブロック生成回路６は、入力されたＡＶソースパケットを、リードソロモン符号（２２４，２０８）で扱いやすい形式、すなわちデータが２０８バイト以内になるように構成しなおしたＡＶデータパックを生成し、ＡＶ伝送用バッファ７に格納する。
第５図はＭＰＥＧ２−ＴＳが送信局２のＡＶ伝送用バッファ７に格納されるまでの流れを示した図である。
一つのＭＰＥＧ２−ＴＳパケットの大きさは１８８バイトであり、通常の画質で平均６Ｍｂｐｓ程度、高画質のもので２４Ｍｂｐｓの速度で断続的に転送される。データブロック生成回路６では、入力されたＭＰＥＧ２−ＴＳパケットに対し、入力時のシステムタイマ５に基づく４バイトの時刻情報をソースパケットヘッダ（ＳＰＨ）として添付するとともにデータブロックの内容を示す８バイトのＭＡＰ情報を添付することで、２００バイトのＡＶデータパックを生成する。このようにして生成されたＡＶデータパックは順次ＡＶ伝送用バッファ７に与えられ、ＡＶ伝送用バッファ７において、ＡＶデータパックがデータブロック生成回路６より出力される順に後述するＴａｇが付加されて格納される。
即ち、ｎ番目（ソースパケットカウンタによって与えられたカウント値に相当する）に与えられたソースパケットがデータブロック生成回路６に与えられると、入力された時刻がシステムタイマ５で確認される。このシステムタイマ５で確認された時刻に基づく時刻情報によるＳＰＨ及びＭＡＰ情報を添付してＡＶデータパックを生成すると、このＡＶデータパックをＡＶ伝送用バッファ７においてｋ番目となる後述するＴａｇを付加して格納する。又、ｎ＋１番目のソースパケットにより生成されるＡＶデータパックが、ｋ＋１番目となる後述するＴａｇが付加されたＡＶ伝送用バッファ７に格納される。
第６図はＤＶＣパケットが送信局２のＡＶ伝送用バッファ７に格納されるまでの流れを示した図である。
一つのＤＶＣのパケットは４８０バイトであり、３０Ｍｂｐｓの転送速度で連続的に転送される。パケット先頭はフレームパルス入力の立ち上がりで判別される。データブロック生成回路６は入力されたＤＶＣパケットを５つのブロックに分割し、２つのブロック毎にデータブロックの内容を示す８バイトのＭＡＰ情報を添付して、ＡＶデータパックを生成する。このようにして生成されたＡＶデータパックは順次ＡＶ伝送用バッファ７に与えられ、ＡＶ伝送用バッファ７において、ＡＶデータパックがデータブロック生成回路６より出力される順に後述するＴａｇが付加されて格納される。又、ＤＶＣのＭＡＰ情報には、フレームパルス立ち上がり時のシステムタイマ５に基づく２バイトの時刻情報を格納している。
即ち、ｎ番目に与えられたソースパケットがデータブロック生成回路６に与えられると、入力された時刻がシステムタイマ５で確認される。そして、ソースパケットが９６バイトの５つのブロックＦ０ｎ〜Ｆ４ｎに分割されると、２つのブロックＦ０ｎ，Ｆ１ｎに、システムタイマ５で確認された時刻に基づく時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成する。このＡＶデータパックをＡＶ伝送用バッファ７においてｋ番目となる後述するＴａｇを付加して格納する。又、２つのブロックＦ２ｎ，Ｆ３ｎに、同一の時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成し、このＡＶデータパックをＡＶ伝送用バッファ７においてｋ＋１番目となる後述するＴａｇを付加して格納する。
又、ｎ＋１番目のソースパケットが与えられると、データブロック生成回路６で５つのブロックＦ０ｎ＋１〜Ｆ４ｎ＋１に分割される。そして、２つのブロックＦ４ｎ，Ｆ０ｎ＋１に、システムタイマ５で確認されたｎ＋１番目のソースパケットの入力された時刻に基づく時刻情報を備えたＭＡＰ情報を添付してＡＶデータパックを生成する。このＡＶデータパックをＡＶ伝送用バッファ７においてｋ＋２番目となる後述するＴａｇを付加して格納する。その後、ブロックＦ１ｎ＋１，Ｆ２ｎ＋１によるＡＶデータパック、ブロックＦ３ｎ＋１，Ｆ４ｎ＋１によるＡＶデータパックがそれぞれ、順に、後述するＴａｇが付加されてＡＶ伝送用バッファ７に格納される。
尚、システムタイマ５に基づく４バイト又は２バイトの時刻情報は、システムタイマ５によって確認されたソースパケットの入力時刻を表すものであっても構わないし、この入力時刻に送信局２での処理時間及び受信局３への送信時間を付加した時刻としても構わない。
第７図Ａ及び第７図Ｂは、ＭＰＥＧ２−ＴＳ及びＤＶＣそれぞれに対するＭＡＰ情報を格納するパケットヘッダフォーマットの一例である。又、表１は、ＭＡＰ情報における各フィールドのビット数を表した表であり、表２は、ＭＰＥＧ２−ＴＳ及びＤＶＣそれぞれに対する各フィールドの情報を示した表である。
以下に、各フィールドの詳細について説明する。まず、ＤＢＳは８ビットのフィールドで、格納時の最小単位であるデータブロックのサイズをｑｕａｄｌｅｔ（＝４バイト）単位で示している。即ち、ＭＰＥＧ２−ＴＳの場合は、時間情報とソースパケットを合わせた１９２バイトが最小単位になるため、４８（＝｜００１１００００｜２）が、ＤＶＣの場合は、フラグメントされた９６バイトが最小単位になるため、２４（＝｜０００１１０００｜２）が入力される。
ＦＮは３ビットのフィールドで、ソースパケットをいくつのデータブロックに分割したかを整数で示す。１は分割をしていないことを示し、０は８個に分割したことを示す。ＭＰＥＧ２−ＴＳの場合は分割しないため１を、ＤＶＣの場合は５つに分割するため５が入力される。
ＤＢＩは３ビットのフィールドで、ＡＶデータパックの先頭に格納されたブロックが何番目のブロックであるを示す数値が入る。ＭＰＥＧ２−ＴＳの場合、分割しないため、ＤＢＩは常に０であるが、ＤＶＣの場合はソースパケットが分割されるため、ソースパケットが分割されて生成されるブロックの順番を示す０〜４までの整数が入る。
ＳＰＣは８ビットのフィールドで、ＡＶデータパック内に格納されているソースパケットが何番目のパケットであるかを示すソースパケットカウンタによるカウンタ値であり、分割された複数のブロックが格納されているときは、その先頭のブロックのカウンタ値とされる。
ＱＰＣは８ビットのフィールドで、格納したブロックの合計が２００バイトに満たない場合に施すパディングの量をバイト数で示す。ここではＭＰＥＧ２−ＴＳは、パディングを行わないため、常に０（＝｜００００００００｜２）である。しかし、ＤＶＣの場合は、パケットが連続的に入力されなかった場合、９６バイトのパディングが付加される可能性があり、このようなときは９６（＝｜０１１０００００｜２）となり、このような場合以外では０（＝｜００００００００｜２）となる。
ＲＳＶは１ビットのフィールドで、後に利用可能とするための予約フィールドである。ＳＰＨは１ビットのフィールドで、ＡＶデータパックを作成する際にソースパケットヘッダが付加していたか否かを示す。ＭＰＥＧ２−ＴＳの場合は時刻情報として４バイトのソースパケットヘッダを付加するため１が、ＤＶＣの場合は０が格納される。
ＦＭＴは６ビットのフィールドでソースパケットのフォーマットを示す。このＦＭＴは、上位１ビットが１のとき、ＳＹＴフィールドを有することを示す。即ち、ＭＰＥＧ２−ＴＳの場合は｜００００００｜２が、ＤＶＣの場合は時刻情報として２バイトのＳＹＴを備えるため｜１０００００｜２が格納される。
ＦＤＦは８ビット又は２４ビットのフィールドで、ＦＭＴで指定されたフォーマットよりも詳しい情報が入力される。このＦＤＦは、ＤＶＣの場合は２バイトのＳＹＴを備えるため８ビットのフィールドとなり、ＭＰＥＧ２−ＴＳの場合はＳＹＴがないので２４ビットのフィールドとなる。
ＳＹＴは１６ビットのフィールドで、ソースパケットが入力した時刻情報である。ＭＰＥＧ２−ＴＳの場合は、ソースパケットヘッダとして時刻情報をもっているため付加せず、ＤＶＣの場合は先に述べた２バイトの時刻情報をここに格納する。尚、このＳＹＴには、ソースパケットの先頭のブロックがＡＶデータブロックに含まれる場合は、そのブロックのソースパケットが入力された時刻情報が格納される。又、本実施形態では、ＦＭＴ、ＦＤＦ、ＳＹＴは、ＩＥＥＥ１３９４でリアルタイムＡＶデータを転送するための方式であるＩＥＣ６１８８３に従っている。
以上の操作により、ＭＰＥＧ２−ＴＳソースパケット、ＤＶＣソースパケットは、ともに２００バイトのＡＶデータパックに変換され、ＡＶ伝送用バッファ７、に格納される。
第８図は、ＡＶ伝送用バッファ７に格納されたＡＶデータパックからＭＡＣパケットを生成するまでの処理を示す図である。
ＡＶ伝送用バッファ７は、データブロック生成回路６で生成された２００バイトのＡＶデータパックに８ビットの識別子を含む４バイトの付加情報であるＴａｇを添付して出力する。この付加情報であるＴａｇ内の８ビットの識別子は、上述したようにＡＶ伝送用バッファ７に格納された順序を表す値に相当する。このＴａｇを付加された２０４バイトのＡＶデータパックがセレクタ１２で選択されて誤り検出符号付加回路１３に与えられると、誤り検出符号付加回路１３によって４バイトの誤り検出符号（ＦＣＳ）が付加される。
Ｔａｇにある８ビット識別子は、本実施形態において、リードソロモン符号化ブロック単位での再送を行う通信において、受信局３がＡＣＫを返信する際に、どの符号化ブロックを正常に受信したかを示すために使われる。よって、Ｔａｇにある８ビット識別子は、受信局３が判別できる形式、例えば連続的な番号でもよい。
本実施形態では、管理を容易にするとともにその管理に用いられる別のバッファを不要とするために、ＡＶ伝送用バッファ７のバッファアドレスを８ビット識別子として使用する。このことにより、回路が簡略化される。又、本実施形態では、送信するＡＶデータパックにＴａｇ情報を付加しているが、これは一例であり、Ｔａｇ情報を付加せずに上位フォーマットヘッダにより識別を行うなどの方法も可能である。
４バイトのＴａｇと４バイトの誤り検出符号が付加された２０８バイトのＡＶデータパックは、これを１単位として、暗号化器１４によって暗号化される。この暗号化器１４において用いられる方法として、現在、ＩＥＥＥ８０２．１１ｅにおいて提案されているｂａｓｉｃ ＷＥＰと呼ばれる公開鍵法による暗号化方法が用いられる。
この暗号化方法は、予め、送信局２と受信局３の間において秘密鍵を決めておく。そして、送信局２において、この秘密鍵と公開鍵とによって暗号化する。又、公開鍵は、送信パケット毎に変更され、パケットに付加して受信局３に通知される。受信局３では、通知された公開鍵と秘密鍵とによって復号化する。尚、公開鍵はＭＡＣパケットヘッダ生成回路１５で生成されると、暗号化器１４に与えられる。
暗号化されたデータに対し、ＭＡＣヘッダと公開鍵が付加され、更に、誤り訂正符号付加回路１７によって１６バイトのリードソロモン符号が付加される。ここで、誤り訂正符号付加回路１７において、ＭＡＣヘッダと公開鍵を一つのリードソロモン符号化ブロックとし、データに関しては２０８バイトのＡＶデータパックに相当する暗号化データ単位でリードソロモン符号化ブロックとする。
即ち、まず、ＭＡＣパケットヘッダ生成回路１５で生成されたＭＡＣヘッダと公開鍵とがヘッダ部としてセレクタ１６で選択されて誤り訂正符号付加回路１７に与えられ、１６バイトのリードソロモン符号が付加される。その後、暗号化器１４で暗号化された暗号化データ単位毎のＡＶデータパックがデータ部としてセレクタ１６で選択され、誤り訂正符号付加回路１７で１６バイトのリードソロモン符号が付加される。そして、誤り訂正符号付加回路１７で所定数のＡＶデータパックそれぞれに相当する各データ部にリードソロモン符号が付加されて出力されると、セレクタ１６によって、ＭＡＣパケットヘッダ生成回路１５の出力を誤り訂正符号付加回路１７に与えるように接続を切り換える。
又、３２バイトのＭＡＣヘッダと４バイトの公開鍵のデータ量は３６バイトしかなく、２０８バイトに満たない。このため、誤り訂正符号付加回路１７は、このＭＡＣヘッダと公開鍵とによるデータブロック（ヘッダ部）について、１〜１７２バイトに０又は１のパディングが格納されるとともに１７３〜２０８バイトにＭＡＣヘッダと公開鍵とが格納されているデータとして、処理を行う。このヘッダ部を処理する際、誤り訂正符号付加回路１７が、１７２バイト分の０又は１のパディングの処理後の内部状態となるように、初期化すればよい。
そして、セレクタ１８が誤り訂正符号付加回路１７の出力を選択して誤り検出符号付加回路１９に与えるため、リードソロモン符号化処理されたデータ全体に対し、誤り検出符号付加回路１９により４バイトのＦＣＳが付加される。即ち、リードソロモン符号化処理された１つのヘッダ部と所定数（ｎ）のデータ部による誤り訂正符号付データに対して、ＦＣＳが付加される。よって、所定数（ｎ＋１）のリードソロモン符号化ブロックによる誤り訂正符号付きデータに対して、誤り検出符号化が行われる。これは従来のＩＥＥＥ８０２．１１パケットとの互換性を保つための処理である。
上述のように、ＡＶ伝送用バッファ７において、ＡＶデータパックを２０８バイト以内に無駄なく収まるように構成しなおすことには、パディングによって発生する帯域の増加を抑制できるという利点と、後述するリードソロモン符号化ブロック単位で再送する際の処理が簡略化できるという利点がある。
又、ＭＡＣパケット生成回路９でのＭＡＣパケットの生成処理において、固定長のリードソロモン符号を使った例を挙げたが、他の方法として、ソースパケットの大きさにあわせてリードソロモン符号の符号長を可変させる方法もある。例えば、リードソロモン符号として（２５５、２３９）を利用する場合において、ＭＰＥＧ２−ＴＳソースパケットを処理するときは、先頭から２０８バイト目までを誤り訂正符号付加回路１７を通した後、２０９バイト目から２３９バイト目まで０又は１をパディングしたものとして計算を行い、１６バイトのリードソロモン符号を得る。そして、２０９バイト目から２３９バイト目までの０又は１のパディングは除去して、２０８バイト目までＡＶデータパックに１６バイトのリードソロモン符号を付加して誤り検出符号付加回路１９に送出する方法がある。
固定長のリードソロモン符号の場合は、ＡＶデータパックやソースパケットの大きさによってリードソロモン符号化ブロック内にパディングが発生する可能性があるが、この方法では誤り訂正符号付加回路１７においてパディングが除去されるので、メディア上を転送されるパケット内にはパディングが発生せず、帯域の使用効率が向上するという利点がある。
この場合、パディングする量が多くなればなるほど、リードソロモン符号化時のパディング箇所の処理の遅延が大きくなり、パディング分の遅延を補償するために、パディング分だけ先行した先読みを行って処理する必要がある。このため、より速い動作クロックと、先読みでリードソロモン符号化処理を施したデータを保存するために多くのバッファが必要となる。
又、ヘッダ部において、１〜３６バイトまでにＭＡＣヘッダと公開鍵を格納し、残りの３７〜２０８バイトを０又は１のパディングとする形で処理をしても構わないが、その場合は、符号化の際にパディング部で発生する遅延時間を考慮する必要がある。この場合、可変長のリードソロモン符号化処理と同様、先読みでリードソロモン符号化処理を施したデータを保存するためのバッファが必要となる。
又、セレクタ１２によって、ＬＬＣ−ＰＤＵ用バッファ１０からのデータブロックが選択されたとき、ブロック１３〜１９が上述と同様の動作を行うことによって、ＬＬＣ−ＰＤＵ用バッファ１０に格納されたインターネット用のデータなど処理されてＭＡＣパケットが生成される。
更に、セレクタ１８が、セレクタ１６からの出力を選択して誤り検出符号付加回路１９に与えるとき、誤り訂正符号付加回路１７におけるリードソロモン符号化処理が行われずに、ＭＡＣパケットヘッダ生成回路１５で生成されたヘッド部及び暗号化器１４でＡＶデータパックが暗号化されて得られたデータ部が、誤り検出符号付加回路１９に与えられる。よって、リードソロモン符号の付加されていないヘッド部及び所定数のデータ部よりなるデータに対して、ＦＣＳが付加される。
次に、受信局３がＭＡＣパケットを受信したときの処理について述べる。
まず、受信局３では、受信パケットが誤り訂正符号化処理をされているかを判別する必要がある。この判別方法において、ＭＡＣヘッダに設けた誤り訂正符号化処理の有無を示す識別フィールドより判別する方法があるが、無線メディア上で発生したエラーによって、誤り訂正符号化処理識別フィールドに誤りが発生する場合もある。そのため、単純にこの誤り訂正符号化処理の有無を示す識別フィールドのみによる判別だけでは、信頼性が低い。
よって、誤り訂正回路２２によって誤り訂正符号化処理を行うか否かが確認される。今、第９図に、誤り訂正回路２２と誤り検出回路２１とにおいて同一のデータ量のデータに対する処理速度が同じであるものとしたときの、誤り検出回路２１の出力と誤り訂正回路２２の出力の時間的な関係を示す。この第９図を参照して、以下に、誤り検出回路２１及び誤り訂正回路２２それぞれでの時間的な処理関係を説明する。
まず、誤り検出回路２１にＭＡＣパケットが入力されると、ＭＡＣヘッダと公開鍵とリードソロモン符号とによるデータブロック長分の処理時間が経過すると、誤り訂正回路２２にＭＡＣパケットのデータが出力される。そして、誤り訂正回路２２は、入力されたデータを一度バッファリングした後に、ユークリッド演算を開始する。その後、誤り訂正回路２２において、リードソロモン符号化ブロック長分の時間をかけてユークリッド演算が行われると、次に、チェンサーチが行われる。
このため、誤り訂正後のＭＡＣヘッダの出力が開始されるのは、ＭＡＣパケット受信回路２０内の誤り検出回路２１へのＭＡＣヘッダの入力開始から２７６バイト分（ＭＡＣヘッダを含むデータブロック５２バイト＋リードソロモン符号化ブロック２２４バイト）のデータ処理時間後であり、この後、更に５２バイト分のデータ処理時間を経過した後に、ＭＡＣヘッダに対する誤り訂正が成功したか否かが確認されるとともに、誤り訂正処理を行うか否かが確認される。この誤り訂正が正常に行われなかったとき、誤り検出回路２１へのＭＡＣヘッダの入力開始から３２８バイト分のデータ処理時間が経過したタイミングで、誤り訂正エラー信号が出力される。
これに対し、従来のＩＥＥＥ８０２．１１ａパケットにおいては、受信後、ＳＩＦＳ（１６μｓ）の間隔でＡＣＫを返さなければならない。しかしながら、上述のような誤り訂正処理を待った上で誤り訂正処理を行うか否かを判断した場合、ＭＡＣヘッダに対して施されるチェンサーチが終了するまでにかかる処理時間がＳＩＦＳより長くなるため、ＳＩＦＳの間隔でＡＣＫを返すことは難しい。
このため、受信局３は、誤り訂正処理されたＭＡＣパケットと通常の誤り訂正がないＭＡＣパケットをそれぞれ独立かつ並列に処理できるように、ＭＡＣパケット受信回路２０内に２系統のＭＡＣパケット処理用のブロックを備える。
第１０図に、ＭＡＣパケット受信回路２０において、ＭＡＣパケットが誤り訂正処理をされているか否かを判断した後に、ＭＡＣパケットに対して各種処理を施すためのフローチャート示し、以下でその動作を説明する。
最初に、誤り検出回路２１においてＭＡＣパケットの宛先アドレスをチェックする（ＳＴＥＰ１）。このとき、宛先アドレスが自局宛か、又は、宛先指定のないブロードキャストでない場合は（Ｎｏ）、ＭＡＣパケット解析回路２６後段での通常の処理は中止し、誤り訂正回路２２後段での誤り訂正の処理のみを行う（ＳＴＥＰ２）。即ち、宛先アドレスが間違っている場合は、誤り検出回路２１で誤り検出されるために、通常の処理では正常に受信できないので、このＭＡＣパケットに対するＡＣＫを返信する必要がない。又、このとき、宛先アドレスが正しく他局のアドレスを示している場合は、受信局３にとって無関係な通信である。
その後、誤り訂正処理部２２で誤り訂正をした後、誤り訂正されたＭＡＣパケットの宛先アドレスをＭＡＣパケット解析回路２３で再度チェックする（ＳＴＥＰ３）。このとき、ＭＡＣパケットの宛先アドレスが自局宛又はブロードキャストである場合（Ｙｅｓ）、復号器２４後段での処理が行われて、後述する遅延ＡＣＫがＡＣＫ生成回路３６より送信される（ＳＴＥＰ４）。又、逆に、ＭＡＣパケットの宛先アドレスが自局あて又はブロードキャストでない場合（Ｎｏ）、現在行っている誤り訂正処理を中止する（ＳＴＥＰ５）。
ＳＴＥＰ１において、誤り検出回路２１で確認されたＭＡＣパケットの宛先アドレスが自局宛又はブロードキャストである場合は（Ｙｅｓ）、誤り検出回路２１において、ＭＡＣヘッダ内の誤り訂正処理識別フィールドより、誤り訂正符号化されているか否かの判断を行う（ＳＴＥＰ６）。この識別フィールドで誤り訂正符号化されていることが示されていたら（Ｙｅｓ）、ＳＴＥＰ２に移行して、ＳＴＥＰ２〜ＳＴＥＰ５の誤り訂正処理のみを行う。このとき、誤り訂正処理をしていないにも関わらず誤り訂正処理識別フィールドが誤り訂正処理を示している場合、処理するＭＡＣパケットにエラーが発生していることを示し、このＭＡＣパケットは通常の処理ではＡＣＫを返信する必要がない。
又、ＳＴＥＰ６において、ＭＡＣヘッダ内の誤り訂正処理識別フィールドにおいて誤り訂正符号化されていることが示されていない場合は、誤り訂正回路２２後段での誤り訂正の処理と、ＭＡＣパケット解析回路２６後段での通常の処理とを平行して行う（ＳＴＥＰ７）。
ＳＴＥＰ７を経た後、誤り訂正回路２２で誤り訂正処理が行われると（ＳＴＥＰ８）、誤り訂正回路２２から出力される誤り訂正処理後のＭＡＣヘッダの誤り訂正処理識別フィールドがＭＡＣパケット解析回路２３で解析される（ＳＴＥＰ９）。ここで、誤り訂正処理識別フィールドが誤り訂正符号化されていることを示している場合（Ｙｅｓ）、誤り訂正エラー信号の状態を確認する（ＳＴＥＰ１０）。このとき、ＭＡＣヘッダが誤り訂正回路２２において正常に誤り訂正処理が成されたことが確認されると（Ｙｅｓ）、上述の通常の処理を中止するとともに、上述の誤り訂正処理が続けて行われる（ＳＴＥＰ１１）。この誤り訂正処理が行われるとき、遅延ＡＣＫをＡＣＫ生成回路３６で生成して送信する。
ＳＴＥＰ９において、誤り訂正処理識別フィールドが誤り訂正符号化されていることを示していない場合（Ｎｏ）、又は、ＳＴＥＰ１０において、ＭＡＣヘッダが誤り訂正回路２２における誤り訂正処理が正常に成されていない場合（Ｎｏ）、上述の誤り訂正処理を中止するとともに、上述の通常の処理のみを続けて行う（ＳＴＥＰ１４）。この通常の処理が行われるとき、ＡＣＫをＡＣＫ生成回路３６で生成して送信する。
ＳＴＥＰ７を経た後、上述の通常の処理が行われたとき（ＳＴＥＰ１２）、ＭＡＣパケット検出回路２１において、ＭＡＣパケットヘッダにおけるフォーマット的なエラーが確認される（ＳＴＥＰ１３）。このとき、ＭＡＣパケットヘッダにおけるエラーが検出されると（Ｙｅｓ）、上述の通常の処理が中止されるとともに、上述の誤り訂正処理を続けて行う（ＳＴＥＰ１１）。又、ＭＡＣパケットヘッダにおけるエラーが検出されない限り（Ｎｏ）、上述の誤り訂正処理を中止するとともに、上述の通常の処理を続けて行う（ＳＴＥＰ１４）。
ＳＴＥＰ７における通常の処理と誤り訂正処理の平行動作は、それぞれの判別までにかかる時間に差があるため、先に正常と判断された処理動作が優先されて、優先された処理動作に対して、以降のパケット処理を行う。尚、上述の両方の処理において、同時に正常と判断された場合は、以下の２通りの判断方法を用いることができる。一つの判断方法は、物理層から報告されるパケット長から判断する方法、残りの一つの判断方法は、確率的に正しいと考えられる処理動作を選択する方法である。
前者の判断方法では、受信したＭＡＣパケットのパケット長が誤り訂正符号処理をされた場合のパケット長（＝３２バイト（ＭＡＣヘッダ）＋４バイト（ＩＶ：公開鍵）＋１６バイト（ＲＳ符号）＋ｎ×２２４バイト（ｎは、ＭＡＣパケット内に含まれるＡＶデータパックの数に相当する）＋４バイト（ＦＣＳ））であることが誤り検出回路２１で確認されると、誤り訂正処理を優先する。しかしながら、可変長のリードソロモン符号を使用している場合は、この判断方法を使用することはできない。
後者の判断方法では、誤り訂正回路２２と誤り検出回路２１のそれぞれが誤動作する確率を比較し、確率的に誤動作をしにくい方を優先する。尚、リードソロモン符号で誤りを誤訂正をする確率は１／６００００であり、誤り検出符号が誤りを正常に検出できない確率はデータ長によって変化する。
上記判断方法以外に、誤り検出回路２１の出力を一度バッファリングし、誤りが検出されないときは、そのＭＡＣヘッダ内容に従って通常の処理を行い、誤りが検出されたときは、誤り訂正処理を行う方法もある。この場合、同時並行的に処理する必要がないので、第１０図のフローチャートと比べて、その判定アルゴリズムをより簡略化できる反面、バッファによる遅延が発生する。
以下に、誤り訂正符号化処理について説明する。第１１図は、誤り訂正符号化処理されたパケットとして正常に判断された後、パケット内のＡＶデータパックがＡＶ転送用バッファに格納されるまでの流れを示したものである。
誤り検出回路２１から誤り訂正回路２２にＭＡＣパケットが与えられると、まず、ヘッダ部について誤り訂正処理が行われる。このとき、誤り訂正回路２２で正常に訂正されて得られたヘッダ部がＭＡＣパケット解析回路２３に与えられ、ＭＡＣヘッダ及び公開鍵が取り出されると、公開鍵が復号器２４に与えられる。又、ＭＡＣパケット内に含まれるデータ部についても、誤り訂正回路２２で誤り訂正が成される際、訂正エラー信号が出力されたか否かが確認される。又、誤り訂正回路２２で誤り訂正が行われたデータ部は、ＭＡＣパケット解析回路２３を通じて復号器２４に与えられる。
復号器２４は、予め設定していた秘密鍵と、ＭＡＣパケット解析回路２３が得られた公開鍵を用いて、データ部の復号化を行い、その結果を誤り検出回路２５によって、データ部が正しく復号化されているかどうかをＦＣＳによって判別する。ここで、誤り検出回路２５はリードソロモン復号が行われて、正常に訂正できたか否かの判別も行われる。
誤り検出回路２５によってＦＣＳが除去されて得られたＡＶデータパックは、ＡＶ伝送用バッファ３２のＴａｇにある８ビット識別子が示すバッファアドレスに格納されていく。同時に誤り訂正回路２２から出力される誤り訂正エラー信号を観測し、この信号が正常に受信できたことを示す場合には、ＡＶ伝送用バッファ３２において、ＡＶデータパックを格納したバッファアドレスに対応する格納状況表示識別子に対し１を書き込み、誤り訂正エラー信号が訂正エラーを示した場合はその格納状況表示識別子に０を書き込む。
即ち、第１１図の場合、誤り訂正回路２２において、訂正エラー信号が出力されるデータ部＃１，＃３に対しては、ＡＶ伝送用バッファ３２の格納状況表示識別子が０となる。又、データ部＃２に対しては、ＡＶ伝送用バッファ３２の格納状況表示識別子が１となる。即ち、復号器２４及び誤り検出回路２５で復号化されたデータ部＃１，＃３より得られるＴａｇ内の８ビット識別子がｋ−１，ｋ＋１となるＡＶデータパックが格納されるＡＶ伝送用バッファ３２内のバッファアドレスに対応する格納状況表示識別子が０となる。又、同様に、Ｔａｇ内の８ビット識別子がＴａｇとなるＡＶデータパックが格納されるＡＶ伝送用バッファ３２内のバッファアドレスに対応する格納状況識別子が１となる。
ＡＶ伝送用バッファ３２での処理をより簡単にするために、誤り訂正回路２２の出力をリードソロモン符号化ブロック分の長さのバッファでバッファリングし、訂正エラーが発生しなかったことを確認した後、ＭＡＣパケット解析回路２３に出力させるようにしても構わない。この場合、ＭＡＣパケット解析回路２３による解析が遅延するとともに、より多くのバッファがいるが、ＡＶ伝送用バッファ３２の制御は簡略化できる。
又、本実施形態の場合、ＡＶ伝送用バッファ３２に、受信したＭＡＣパケットより得られたＡＶデータパックを書き込む際、誤り訂正が正常に行われて、対応するバッファアドレスの格納状況表示識別子が既に１である場合は、書き込みを中止するようにしてもよい。これは、既に正しく書き込まれていたバッファアドレスのデータ領域に、誤り誤訂正や誤り訂正失敗している可能性があるデータが書き込まれることを防ぐためである。
次に、ＡＶ伝送用バッファ３２内のＡＶデータパックがソースパケットとして再構成され出力されるまでの処理動作を説明する。
ソースパケット出力回路３３は、ＡＶ伝送用バッファ３２に有効なＡＶデータパックが格納されているとき、この有効なＡＶデータパック順次読み出して、ＡＶデータパックの中身を解析する。即ち、ＡＶ伝送用バッファ３２において、格納状況表示識別子が１となるバッファアドレスに格納されるＡＶデータパックが読み出されて、ソースパケット出力回路３３で解析される。
ソースパケット出力回路３３において、ＭＡＰのＦＭＴ、ＦＤＦフィールドによってＡＶデータパックに格納されているＡＶソースパケットの種類を確認する。又、ＭＡＰのＤＢＳによってデータブロックサイズを確認するとともに、この値とＱＰＣで確認されるパディングの値とからＡＶデータパックに格納されているデータブロックの個数が認識される。そして、各データブロックに対して、それぞれのＭＡＰにおけるＳＰＣ及びＤＢＩで指示されたデータブロック番号とＦＮで指示された分割数とに応じて、ＡＶソースパケットを再構築する。更に、ＭＡＰ内のＳＹＴ又はソースパケットヘッダで指示された時刻情報に基づいて、タイムシーケンスを再現しながら、再構築したＡＶソースパケットを出力する。
第１２図は、ＡＶデータパックがＭＰＥＧ２−ＴＳによるＡＶソースパケットのＡＶデータパックである場合のソースパケット出力回路３３の処理の流れを示している。
まず、ソースパケット出力回路３３は、上述のようにＭＡＰを解析する。このとき、ＭＰＥＧ２−ＴＳのＭＡＰが表２に示した値となるため、ソースパケット出力回路３３は、ＡＶ伝送用バッファ３２より読み出されるＡＶデータパックがＭＰＥＧ２−ＴＳによるものであり、ＡＶソースパケットがソースパケットヘッダが付加された状態で分割なしに格納されていることが確認される。
ソースパケット出力回路３３は、更に、ソースパケットヘッダとＡＶソースパケットとを分割して、ソースパケットヘッダ内の時刻情報に後述するオフセット時間を加算した時刻情報と自局のシステムタイマ３４が与える現在時刻情報とを照らし合わせ、両者が一致したときにＡＶソースパケットを出力する。
第１３図は、ＡＶデータパックがＤＶＣによるＡＶソースパケットのＡＶデータパックである場合のソースパケット出力回路３３の処理の流れを示している。
まず、ソースパケット出力回路３３は、上述のようにＭＡＰを解析する。ＤＶＣのＭＡＰが表２に示した値となるため、ソースパケット出力回路３３は、このＡＶデータパックがＤＶＣによるものであり、ＡＶソースパケットが５つに分割されていることが確認される。又、このＡＶデータパックには、何番目のソースパケットの何番目のデータブロックが格納されているかが確認される。
ソースパケット出力回路３３は、ＡＶデータブロックＦ０〜Ｆ４をＦ０，Ｆ１，Ｆ２，Ｆ３，Ｆ４の順の並びになるよう結合して、一つのＡＶソースパケットに再構成する。さらにインデックス０のＡＶデータブロックを格納していたＡＶデータパックのＭＡＰのＳＹＴから時刻情報を確認し、この時刻情報に後述するオフセット時間を加算した時刻情報を求める。オフセットされた時刻情報と自局のシステムタイマ３４が与える現在時刻情報とを照らし合わせ、両者が一致したときにＡＶソースパケットを出力する。
以下に、オフセット時間の計算方法について説明する。
送信局２及び受信局３の内部に構成される回路によって発生する遅延やメディアアクセスのタイミングによって発生する遅延のため、ＡＶソースパケットが送信局２のデータブロック生成回路６に入力された時刻をそのまま利用して、受信局３のソースパケット出力回路３３から出力することはできない。このため、送信局２、受信局３もしくはその両方において、ＡＶソースパケットの時刻情報をオフセットする必要がある。
本実施形態では、オフセット時間の計算は、受信局３のソースパケット出力回路３３が行っている。これは、仮に同じパケットを受信した局が複数台存在する場合、それぞれの局においてパケット出力の時間差ができるが、送信局２が受信局３の内部回路による遅延を考慮せずに送信を行えるという利点がある。各受信局３の間で遅延差が生じるのは、リードソロモン復号処理にかかる時間によるものであるが、すべての局が同じ速度で復号処理をすれば、このような時間差を抑制することができる。
又、逆に、送信局２のデータブロック生成回路６のみでオフセット時間を計算するものとしても構わない。このようにすることで、受信局３が複数台存在する場合でも、すべての受信局のＡＶソースパケット出力をほぼ同じ時間とすることができる。
いずれの方法を用いるとしても、ネットワーク内の送受信局の内部回路構成による遅延量は、システムが破綻しない範囲内であらかじめ決定しておく。又、本発明の装置を備えたネットワークシステムが何を要求しているかによって、いずれの方法がよいかは異なる。
以上のようにして送信局２に入力されたＡＶソースパケットは、受信局３から出力される。
次に無線通信路上でエラーが発生した場合の再送方法について述べる。
受信局３において、ＭＡＣパケット全体が消失したか、又は、ＭＡＣヘッダ部に誤りが発生してこのＭＡＣパケットを破棄した場合、受信局３から送信局２に対してＡＣＫは返信されない。このため、送信局２は次の送信機会において自発的に再送を行う。
次に、受信局３において、ＭＡＣパケット内のデータ部のリードソロモン符号化ブロックにおいて誤りが発生した場合はＡＣＫを使って受信局３から送信局２に対し再送を要求する。このとき、誤り訂正回路２２におけるリードソロモン符号の復号には時間がかかるため、通常のＡＣＫを返すことはできない。よって、復号後に複数のパケットに対し一括してＡＣＫを返すことができる遅延ＡＣＫを使用する。
第１４図に、現在ＩＥＥＥ８０２．１１ｅにおいて提案されている遅延ＡＣＫのフレームフォーマットを示す。
２バイトのＦｒａｍｅ Ｃｏｎｔｒｏｌフィールド及び２バイトのＤｕｒａｔｉｏｎフィールドによって、遅延ＡＣＫであることが宣言される。又、６バイトのＲＡフィールドによって受信側となる送信局２のアドレスが示されるとともに、６バイトのＴＡフィールドによって送信側となる受信局３のアドレスが示される。２バイトのＲｅｃｏｒｄ Ｃｏｕｎｔフィールド内の８ビットの識別子によって、４バイト単位毎のＡＣＫ Ｒｅｃｏｒｄフィールドの数が設定される。第１４図では、４バイトのＡＣＫ Ｒｅｃｏｒｄフィールドを１つとして構成している。又、誤り検出符号として、４バイトのＦＣＳが付加されている。
このＡＣＫ Ｒｅｃｏｒｄフィールド内のシーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｏ．ｆｏｒ ＴＣ−ｂｉｔｍａｐ ＃０ ｂｉｔ）は再送を要求するパケットを示している。即ち、ＴＣ−ｓｅｑ内の４ビットのＴＣＩＤによって、再送する映像ファイルの識別子が示されるとともに、シーケンス番号によって再送するＡＶソースパケットのパケットの番号が示される。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、シーケンス番号で示されるＡＶソースパケット以降のＡＶソースパケットとシーケンス番号で示されるパケットとの時間軸上の位置関係が１ビット毎に示される。ＴＣ−ｂｉｔｍａｐにおいて、再送要求されるＡＶソースパケットの位置を示すビットに１が与えられ、受信が成功したＡＶソースパケットの位置を示すビットに０が与えられる。
尚、現在提案中の遅延ＡＣＫはパケット単位での再送しか考慮されていない。このようなパケット単位での再送は、課題でも述べたが、パケット内に格納されているリードソロモン符号化ブロックのうち一つでも誤り訂正エラーが発生するとすべてを再送しなければならず、非常に効率が悪い。
それに対して、本実施形態では、パケット単位の再送のみならず、リードソロモン符号化ブロック単位（ＡＶデータパック単位）の再送も可能とするように、遅延ＡＣＫを構成する。本実施形態におけるＡＶデータパック格納方法は、パケット内の一部のリードソロモン符号化ブロックしか正常に受信できず、ＡＶ伝送用バッファにそのＡＶデータパックが格納されなかった場合でも、この正常に受信された部分における再生は可能である。又、各ＡＶデータパックはＴａｇにある８ビット識別子によって区別することが可能である。このため、パケット単位で再送をする必要性はなく、誤り訂正ができずに得られなかったＡＶデータパックのみ再送を行えばよい。
第１５図は、第１４図に示したＡＣＫフレームフォーマットのリードソロモン符号化ブロック単位再送拡張の一例であり、パケット単位の再送を行うか、ブロック単位の再送を行うかを識別するためのＢｉｔｍａｐ Ｏｂｊｅｃｔビットを２バイトのＲｅｃｏｒｄ Ｃｏｕｎｔフィールド内に設けている。このＢｉｔｍａｐ Ｏｂｊｅｃｔビットは、ＡＣＫ Ｒｅｃｏｒｄフィールドがパケットのシーケンスナンバーを示すのか、Ｔａｇにある８ビット識別子を示すのかを識別するためのものである。リードソロモン符号化ブロック単位再送を行う場合は、このＢｉｔｍａｐ Ｏｂｊｅｃｔビットを１にする。
Ｂｉｔｍａｐ Ｏｂｊｅｃｔビットが１のとき、ＡＣＫ Ｒｅｃｏｒｄフィールド内の情報は、ＡＶ伝送用バッファ３２内のバッファアドレスに相当するＴａｇにある８ビット識別子の値を示す。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、ＴＣ−Ｓｅｑで示されているＴａｇにある８ビット識別子から以降の受信状況を示すことができる。ＴＣ−ｂｉｔｍａｐにおいて、再送要求されるＡＶデータパックの位置を示すビットに１が与えられ、受信が成功したＡＶデータパックの位置を示すビットに０が与えられる。
即ち、ＴＣ−ｓｅｑ内の４ビットのＴＣＩＤによって、再送する映像ファイルの識別子が示されるとともに、シーケンス番号によって再送するＡＶデータパックの８ビット識別子が示される。そして、１６ビットのＴＣ−ｂｉｔｍａｐには、シーケンス番号で示されるＡＶデータパック以降のＡＶデータパックとシーケンス番号で示されるＡＶデータパックとの時間軸上の位置関係が１ビット毎に示される。
第１１図では、前回の受信においてバッファアドレスＮ−２まではすべて正常な書き込みが行われものとするとともに、受信したＭＡＣパケット内の１番目と３番目のリードソロモン符号化ブロックにおいて誤り訂正エラーが発生しており、ＡＶデータパックが得られないものとする。よって、ＡＶ伝送用バッファ３２のＮ番目のバッファアドレスには正常にデータが書き込まれたが、ｋ−１、ｋ＋１番目のバッファアドレスはヌルになっている。
第１６図は、第１１図で示す受信結果に対し、ＡＣＫ生成回路３６が生成したＡＣＫフレームを示す。ＡＣＫ生成回路３６では、ＡＶ伝送用バッファ３２内の各バッファアドレスの格納状態が、ＡＶ伝送用バッファ３２から与えられる格納状況表示識別子によって確認される。又、ＭＡＣパケット受信部２０で受信されて処理が成されたＡＶデータパックのＴａｇ内の８ビット識別子がＭＡＣ部３５で認識され、ＡＣＫ生成回路３６に伝えられる。
そして、ＭＡＣ部３５よりＭＡＣパケット受信部２０で処理されたＡＶデータパックについての情報が与えられると、ＡＶ伝送用バッファ３２から与えられる格納状況表示識別子によって、再送要求するＡＶデータパックに付加されたＴａｇ内の８ビット識別子が認識され、この認識された８ビット識別子に基づいて、遅延ＡＣＫが生成される。尚、このとき、前回の受信で正常に受信されたＡＶデータパックのＴａｇ内の８ビット識別子はＡＣＫ生成回路３６内に記憶されている。
このとき、まず、ＡＣＫ Ｒｅｃｏｒｄフィールド内の情報がＴａｇにある８ビット識別子を示すために、Ｒｅｃｏｒｄ Ｃｏｕｎｔフィールド内のＢｉｔｍａｐ Ｏｂｊｅｃｔビットが１とされる。又、ＡＣＫ Ｒｅｃｏｒｄフィールドの数がこの場合１つだけとなるので、Ｒｅｃｏｒｄ Ｃｏｕｎｔフィールド内のＲｅｃｏｒｄ Ｃｏｕｎｔが１とされる。
又、ＡＣＫ ＲｅｃｏｒｄフィールドのＴＣ−ｓｅｑにおけるシーケンス番号が、前回正常に受信した最新のバッファアドレスに対応する８ビット識別子ｋ−２の次の８ビット識別子、即ち、今回受信されたＡＶソースパケットの先頭のデータ部に含まれるＡＶデータパックが格納されるバッファアドレスに対応する８ビット識別子ｋ−１となる。
このとき、ＭＡＣ部３５によって与えられる情報より、ＭＡＣパケット受信部２０で受信されて処理されたＡＶデータパックが確認されると、各ＡＶデータパックの受信状況をＡＶ伝送用バッファ３２より与えられる格納状況表示識別子より確認される。今、第１１図において、８ビット識別子ｋ−１，ｋ＋１に対応するバッファアドレスに格納されるべきＡＶデータパックが正常に誤り訂正処理が成されていない。よって、８ビット識別子ｋ−１，ｋ＋１に対応するバッファアドレスにおける格納状況表示識別子が０として与えられる。
よって、この格納状況表示識別子が０となるバッファアドレスに対する８ビット識別子ｋ−１，ｋ＋１が確認されるため、８ビット識別子ｋ−１，ｋ＋１にあたるビット位置が１となるように、ＴＣ−ｂｉｔｍａｐが生成される。即ち、１６ビットのＴＣ−ｂｉｔｍａｐが｜１０１０ ００００ ００００ ００００｜２となる。
尚、ＴＣ−Ｓｅｑに格納されるバッファアドレスは、本実施形態のように前回正常に受信した最新のバッファアドレスの次のアドレスである必要はなく、受信異常が発生したと思われるバッファアドレスとしても構わない。
又、同じ受信機会において受信したすべてのパケットに対する遅延ＡＣＫを生成する必要もない。即ち、受信局３が最後のパケットまでのＡＣＫが返せない場合は、途中までに受信したパケットの遅延ＡＣＫを生成し、送信局２に返すようにしてもよい。又、このとき遅延ＡＣＫを返せなかったパケットに対する遅延ＡＣＫは、ライフタイムを超過しない限りいつ返してもよい。
但し、この場合は、送信局２において、受信局３が何番目のパケットまでに対する遅延ＡＣＫを返信したのかを判別できるようにする必要がある。これは、例えば、遅延ＡＣＫが返されるまでの時間を、送信局２及び受信局３の間、もしくはシステム全体のパラメーターとして、予め設定しておき、その時間を過ぎても遅延ＡＣＫが返されないパケットやバッファアドレスについては再送をするという方法で対処できる。
このような遅延ＡＣＫについては、他の局の送信により遅延ＡＣＫ自体が送信不可能になるということを防ぐために、他の通信より優先させて送信する必要がある。このため、本実施形態では、制御局１から送信される後述するＣＦ−Ｅｎｄを受信した後、ＰＩＦＳ時間が経過したことをＭＡＣ部３５が確認すると、ＡＣＫ生成回路３６で生成した遅延ＡＣＫを送信する。
よって、他の局が送信可能となるまでの時間であるＤＩＦＳ時間＋バックオフ時間よりも短いＰＩＦＳ時間経過後に遅延ＡＣＫが送信されるため、他の局よりも先に受信局３がメディアにアクセスすることが可能となる。尚、ＰＩＦＳ時間よりも短いＳＩＦＳ時間経過後に遅延ＡＣＫの送信を行うようにしても構わないし、制御局１により遅延ＡＣＫ送信のタイミング制御を行うようにしても構わない。
又、上述したようにＭＡＣパケット解析回路２６後段の各回路が動作を行う通常処理が成されるとき、ＡＣＫがＡＣＫ生成回路３６で生成されて送信される。この通常処理が成されるときに送信されるＡＣＫは、誤り検出回路２８でＭＡＣパケットが正常に受信されたことを確認すると、ＭＡＣ部３５によってＡＣＫ生成回路３６にＡＣＫの送信を指示し、ＡＣＫ生成回路３６からＡＣＫが送信される。よって、このＡＣＫの送信は、ＭＡＣパケットの受信を完了してからＳＩＦＳ時間が経過するまでに行われる。
送信局２では、このような遅延ＡＣＫを受信部１１で受信すると、ＡＶ伝送用バッファ７における送信待機状態識別子及び再送可能識別子と、遅延ＡＣＫにおけるＡＣＫ Ｒｅｃｏｒｄフィールドとによって、ＭＡＣ部８がＭＡＣパケット生成回路９がＡＶ伝送用バッファ７より読み出すＡＶデータパックを設定して、ＭＡＣパケット生成回路９の動作を制御する。
又、本実施形態では、ＡＶソースパケットの送受信する際の寿命時間であるライフタイムを考慮した送信を行う。即ち、時間が経過しすぎたＡＶソースパケットを再生すると映像または音声に乱れが生じるため、予めシステム内遅延などを考慮したうえで、ライフタイムを設定しておき、このライフタイムを超えたＡＶソースパケットについては送信を禁止する。
ＡＶソースパケットの再送の場合も同様、受信局３から再送要求されてもライフタイムを経過したＡＶソースパケットは再送しても、受信局３から出力されたＡＶソースパケットが再生不可能となる。そのため、受信局３が送信局２に対して再送要求をするときや、送信局２が実際に再送を開始するときには、ＡＶソースパケットの時刻情報とライフタイムを比較し、ライフタイムを超えているものについては再送を禁止する。
このように、ライフタイムが設定されるときに、遅延ＡＣＫを受信した送信局２における動作を、以下に説明する。第１７図は、第１６図の遅延ＡＣＫを受信した送信局２のＡＶ伝送用バッファ７内において、各バッファアドレスに対する送信待機状態識別子を、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールド内の情報に応じて更新する動作を示す。
上述したように、ＡＶ伝送用バッファ７には、各バッファアドレスに対して、送信待機状態を示す送信待機状態識別子と再送可能である（即ち、バッファアドレスに格納されているＡＶデータパックがライフタイムを超えていない）ことを示す再送可能識別子とが備えられる。
まず、受信部１１で遅延ＡＣＫが受信されると、遅延ＡＣＫのＢｉｔｍａｐ Ｏｂｊｅｃｔビットが１であることが確認されると、ＡＣＫ ＲｅｃｏｒｄフィールドがＴａｇ内の８ビット識別子に関する情報であることをＭＡＣ部８に認識させる。そして、ＭＡＣ部８において、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールドにおけるシーケンス番号が確認されると、このシーケンス番号によって示されれる８ビット識別子が認識される。
そして、シーケンス番号より８ビット識別子がｋ−１であることが認識されるため、Ｔａｇ内の８ビット識別子ｋ−１以降の８ビット識別子に対するバッファアドレスに対する送信待機状態識別子がＡＶ伝送用バッファ７より確認される。今、８ビット識別子ｋ＋２〜ｋ＋４のそれぞれに対するバッファアドレスに格納されるＡＶデータパックが送信待機状態にあるものとすると、第１７図の２段目にあるビットマップように、ＡＶ伝送用バッファ７より｜０００１ １１００ ００００ ００００｜２となる１６ビット分の送信待機状態識別子がＭＡＣ部８に与えられる。
又、ＭＡＣ部８において、遅延ＡＣＫのＡＣＫ Ｒｅｃｏｒｄフィールドにおける第１７図の１段目のような｜１０１０ ００００ ００００ ００００｜２となるＴＣ−ｂｉｔｍａｐが確認される。そして、ＭＡＣ部８において、確認されたＴＣ−ｂｉｔｍａｐとＡＶ伝送用バッファ７より得られた１６ビット分の送信待機状態識別子とのＯＲを取ることで、再送を含めた送信対象となる識別子ビットマップ｜１０１１ １１００ ００００ ００００｜２が得られる。
更に、ＭＡＣ部８において、８ビット識別子ｋ−１以降の８ビット識別子に対するバッファアドレスに対する再送可能識別子がＡＶ伝送用バッファ７より確認される。８ビット識別子ｋ−１〜ｋ＋４のそれぞれに対するバッファアドレスに格納されるＡＶデータパックの有する時刻情報がライフタイム以内にあるものとすると、第１７図の３段目にあるビットマップのように、ＡＶ伝送用バッファ７より｜１１１１ １１００ ００００ ００００｜２となる１６ビット分の再送可能識別子がＭＡＣ部８に与えられる。
そして、上記で得られた送信対象となる識別子ビットマップと、この再送可能識別子によるビットマップとのＡＮＤを取り、その結果を使って送信待機状態識別子のビットマップを｜１０１１ １１００ ００００ ００００｜２として更新する。この更新された１６ビット分の送信待機状態識別子のビットマップと、シーケンス番号より次回の送信時での送信が確認されたＡＶデータパックの８ビット識別子がＭＡＣパケット生成回路９に与えられる。即ち、第１７図の場合、８ビット識別子ｋ−１，ｋ＋１〜ｋ＋４が与えられる。
そして、ＭＡＣパケット生成回路９によって、次回の送信機会に、ＭＡＣ部８によって与えられた８ビット識別子に対応するバッファアドレスのＡＶデータパックがＡＶ伝送バッファ７より読み出されて、ＭＡＣパケットが生成される。よって、第１７図の場合、８ビット識別子ｋ−１，ｋ＋１〜ｋ＋４に対応するバッファアドレスのＡＶデータパックがＡＶ伝送バッファ７より読み出されて、ＭＡＣパケットが生成された後、このＭＡＣパケットが送信される。
又、上述の再送可能識別子は、本来すべてのＡＶデータパックに付加されている時刻情報を調べて、システムタイマ５による現在時刻情報及びライフタイムで認識される時刻情報と比較を行った上で更新される。即ち、システムタイマ５によって確認される現在時刻情報からライフタイムを減算した時刻情報と、ＡＶデータパックに付加されている時刻情報とを比較し、ＡＶデータパックに付加されている時刻情報の方が早い時刻を示す場合は、送信を禁止するために再送可能識別子を０とする。
又、制御局１によって指示されるメディアアクセス周期が決まっており、且つライフタイムがそのメディアアクセス周期の整数倍である場合、送信局２のＡＶ伝送用バッファ７における再送可能識別子とアドレスバッファとの関係が第１８図で示すような関係となるようにしても構わない。このとき、メディアアクセス周期がシステムタイマ５によってカウントされ、ＡＶデータパックがＡＶ伝送用バッファ７に入力されるとき、システムタイマ５によってカウントされたメディアアクセス周期の計数値が第１８図のようにサイクルフィールドに格納される。
又、このＡＶ伝送用バッファ７に入力されるＡＶデータパックのバッファアドレスに対する送信待機状態表示識別子及び再送可能識別子が１とされる。更に、システムタイマ５によってメディアアクセス周期がカウントされる度に、現在の周期回数となる計数値とライフタイムをメディアアクセス周期で割った数との差分を計算し、サイクルフィールドがその計算値より小さくなったとき、そのバッファアドレスに対する再送可能識別子を０にする。
例えば、第１８図のように、ライフタイムがメディアアクセス周期の３倍になっており、又、システムタイマ５によってカウントされるメディアアクセス周期の計数値が２３であるものとする。よって、このとき、ＡＶ伝送用バッファ７において、Ｔａｇ内の８ビット識別子ｋ＋４に対するバッファアドレスにＡＶデータパックが格納されるとき、このバッファアドレスに対するサイクルフィールドに計数値２３が格納される。
又、８ビット識別子ｋ＋４のバッファアドレスに対する送信待機状態表示識別子及び再送可能識別子が１とされる。そして、サイクルフィールドに格納された値が現在の周期回数となる計数値２３とライフリミットをメディアアクセス周期で割った数３との差分２３−３＝２０よりも小さくなるバッファアドレスに対する再送可能識別子が０とされる。
このようにすることで、再送の際に送信局２において、ＡＶ伝送用バッファ７内のすべてのバッファアドレスに格納されたＡＶデータパックの送信時間を調べる必要がなくなるため、上述したＡＶデータパックに付加されている時刻情報を比較する場合にくらべ回路を大幅に簡略化することができる。
次に、制御局１による帯域確保の方法について、基本周期内に衝突が発生する区間を備える場合と備えない場合それぞれに対して説明する。
１．基本周期内に衝突が発生する区間を備える場合
まず、メディアアクセスのための基本周期の決定方法について述べる。第１９図は、ＨＣＦを備えた制御局１と送信局２と受信局３の基本的なパケット交換を時間軸で示した一例である。この第１９図の例では、１つの基本周期に、衝突が発生しない区間ＣＦＰと衝突が発生する区間ＣＰとが含まれる。
第１９図のように、まず、制御局１から帯域確保フレームであるＣＦ−Ｐｏｌｌが送信部３９から送信される。このＣＦ−Ｐｏｌｌが送信されてから、制御局１からＣＦ−Ｅｎｄが送信されるまでの間は衝突が発生しない区間ＣＦＰとして確保される。ＣＦ−Ｐｏｌｌを受信した送信局２は、自局が送信局であることをＣＦ−Ｐｏｌｌより確認して、受信局３に対しＲＴＳを生成して送信する。
又、ＲＴＳを受信した受信局３は、自局が受信局であることをＲＴＳより確認して、送信局２に対し、ＣＴＳを生成して送信する。ＣＴＳを受信した送信局２は受信局３が受信可能な状態であることを確認し、受信局３に対し、ＭＡＣパケット生成回路９で生成したＭＡＣパケットを含むパケット＃１〜＃ｎの単一転送又はバースト転送を行う。
そして、制御局１が、後述する第２２図のアルゴリズムを利用して送信局２が無線メディアの帯域を解放したことを確認すると、ＣＦ−ＥｎｄをＭＡＣ部３８で生成して送信部３９より送信することで、衝突が発生しない区間ＣＦＰを終了させる。この区間ＣＦＰ内でのＣＦ−Ｐｏｌｌ、ＲＴＳ、ＣＴＳ、パケット＃１〜＃ｎ、ＣＦ−Ｅｎｄそれぞれの間隔はＳＩＦＳ（１６μｓ）である。
次に、衝突が起きる可能性のある区間ＣＰが開始する。第１９図の例においては遅延ＡＣＫをこの区間で返すものとしている。但し、遅延ＡＣＫが従来のＩＥＥＥ８０２．１１方式に従った動作を行う通信装置の妨害で返信されなくなることを避けるため、ＰＩＦＳ時間後に返信を行っている。尚、この遅延ＡＣＫの返信方法については、上述の通り制御局１による遅延ＡＣＫの送信時間を制御することによるものでも構わない。
そして、最初のＣＦ−Ｐｏｌｌが送信されてから基本周期分の時間が経過すると、ネットワークシステムを構成する局間で通信が行われていないときは、区間ＣＰを終了させるとともに次の基本周期が開始されるように、制御局１から、ＣＦ−Ｐｏｌｌが送信される。尚、基本周期内で区間ＣＰで送信されるＬＡＮパケットが送信終了する場合、現時点における基本周期が開始されたときに最初に送信されるＣＦ−Ｐｏｌｌが送信されてから基本周期に相当する時間が経過すると、次の基本周期を開始するためにＣＦ−Ｐｏｌｌが送信される。
第１９図の中段において、区間ＣＦＰにおいて送信局２から送信されるパケットの物理層にＩＥＥＥ８０２．１１ａ物理層（５ＧＨｚ）を使用した場合の物理層パケットの構成を示す。ＩＥＥＥ８０２．１１ａ物理層は最大通信速度が５４Ｍｂｐｓで、周波数帯域５ＧＨｚにおけるＯＦＤＭ方式を備えた物理層であり、先に述べたＤＶＣやＭＰＥＧ２−ＴＳ高画質モードの転送を行える可能性のある物理層である。
Ｐｒｅａｍｂｌｅ、Ｓｉｇｎａｌ、Ｓｅｒｖｉｃｅ、Ｔａｉｌ、ＰＡＤＳは、ＩＥＥＥ８０２．１１ａ物理層によってＭＡＣパケットであるＰＤＵに付加されるものであり、ＰｒｅａｍｂｌｅとＳｉｇｎａｌについては、それぞれの転送時間が１６μｓ、４μｓと決まっている。１６ビットのＳｅｒｖｉｃｅと６ビットのＴａｉｌとＰＡＤＳとＭＡＣパケットであるＰＤＵとは、最大通信速度が５４ＭｂｐｓとなるＯＦＤＭ方式で転送することができる。最大通信速度５４Ｍｂｐｓとなる時のＯＦＤＭ方式での１シンボル長は２１６ビットである。そして、ＰＡＤＳは、Ｔａｉｌを含む最後のシンボルのシンボル長が２１６ビットになるように付加される。
第１９図の下段において、上述のＩＥＥＥ８０２．１１ａ物理層におけるＰＤＵであるＭＡＣパケットの構成を示す。ＩＥＥＥ８０２．１１ＭＡＣ層では、３２バイトのＭＡＣヘッダ及び４バイトのＦＣＳを除いたプロトコルのフレームボディと呼ばれるフィールドの最大値が２３１２バイトに制限されている。従って、２２４バイトのリードソロモン符号化ブロックを１０個まで収めることが可能である。
よって、本実施形態で挙げたＡＶソースパケットのうち最も速い転送速度をもつＤＶＣの場合について考えると、上述の１パケットで９６（データブロックサイズ）×２（データブロック個数）×１０（リードソロモン符号化ブロック個数）＝１９２０バイトを転送することができる。
又、第１９図に示すように、各パケット＃１〜＃ｎに含まれる複数のリードソロモン符号化ブロックの内の１ブロックを再送要求されたＡＶデータパックによるリードソロモン符号化ブロックに対する帯域として確保している。実際にデータ送信を行う場合は、このブロックを必ず再送要求されたＡＶデータパックによるリードソロモン符号化ブロックとする必要はないが、演算処理を容易にするためにこのような構成としている。よって、正規の（再送ではない）ＤＶＣによるＡＶソースパケットを格納できるデータサイズは１７２８バイトとなる。
又、ＭＡＣパケット全体の大きさは、３２（ＭＡＣヘッダ）＋４（ＩＶ）＋１６（ＭＡＣヘッダ部のＲＳ符号）＋２２４×１０（リードソロモン符号化ブロック）＋４（ＦＣＳ）＝２２９６バイトである。これに、１６ビットのＳｅｒｖｉｃｅと６ビットのＴａｉｌとを加え、２１６ビット（ＯＦＤＭシンボル長）で割って小数点以下を切り上げた値（＝８６）がＰＡＤＳを含むＯＦＤＭシンボル数となる。
１つのＯＦＤＭシンボルの転送時間は４μｓであるので、４×８６（ＯＦＤＭシンボル数）＋１６（Ｐｒｅａｍｂｌｅ）＋４（Ｓｉｇｎａｌ）＝３６４μｓが一つの物理層パケットを転送するのに必要な時間である。
又、遅延ＡＣＫは、ＣＦ−Ｅｎｄが送信完了した後、ＰＩＦＳ（２５μｓ）経過した後に出力される。リードソロモン符号化処理は、第９図に示すようにリードソロモン符号化ブロック２個分の遅延が発生する。受信局３の内部回路の処理速度が物理転送路の速度と同じとすると、この遅延は６８μｓとなる。これに対し、第１９図における最後のパケット＃ｎ送信終了後からの遅延ＡＣＫを送信するまでの間隔は、１６μｓ（ＳＩＦＳ）＋２７μｓ（ＣＦ−Ｅｎｄ）＋２５μｓ（ＰＩＦＳ）＝６８μｓとなり、リードソロモン復号処理と同等の時間を確保できる。実際に遅延ＡＣＫを送信する際には物理層パケットの１６μｓのプリアンブル区間があるため、遅延ＡＣＫ内のデータ生成に更に時間的な余裕がある。
衝突が起きる可能性がある区間ＣＰで局４がメディアアクセスをするにはＤＩＦＳ時間（３４μｓ）＋ランダムバックオフ時間による期間だけ待機しなければならない。よって、ＣＦ−Ｅｎｄが送信されて、区間ＣＦＰが終了するとともに区間ＣＰが開始すると、ＤＩＦＳ時間よりも短いＰＩＦＳ時間経過後に遅延ＡＣＫが送信されるため、遅延ＡＣＫの送信を局４の送信動作によって妨害されることはない。
尚、遅延ＡＣＫを局４の送信動作によって妨害されないための方法としては、上記以外にも、制御局１が送信する帯域確保フレームＣＦ−Ｐｏｌｌに続いて遅延ＡＣＫを送信するようにしても構わない。この場合、遅延ＡＣＫを送信するまでに、帯域確保フレーム送信時間及び遅延ＡＣＫの送信までの待機時間が更に必要となるが、より確実に遅延ＡＣＫを送信することが可能になる。
又、第２０図は、上述した各制御パケットの転送時間などを考慮して、衝突しない区間ＣＦＰに含まれるパケット数を表すパケットバースト回数と、ＤＶＣソースパケットの実転送レート及び基本周期の長さとの関係を計算した結果をグラフで示したものである。
第２０図でＬＡＮなしと記述されているグラフは衝突が発生しない区間を最小にした場合であり、ＬＡＮ有りと記述されているグラフは転送速度２４Ｍｂｐｓ、フレームボディ長２３１２バイトのＬＡＮパケットと共存したときの値を示す。実転送レートは、再送用の帯域はパケットのデータ部を構成する１０個のリードソロモン符号化ブロックのうち一つを再送専用として割り当てたとして、残りのリードソロモン符号化ブロックで転送できる転送量を示したものである。
第１９図の例では、例えばＬＡＮと共存したときにＤＶＣの実転送速度が３０Ｍｂｐｓ以上となる最小の周期、約６．８ｍｓ（バースト回数１５回、実転送レート３０．２Ｍｂｐｓ）を基本周期とする。このようにすることで、基本周期をもっとも転送速度が速いＤＶＣ転送に適合するよう設計できるため、ＤＶＣよりも転送速度が低いＭＰＥＧ２−ＴＳの送信も可能である。
次に、上述のようにして各局間で通信が行われているときにおいて、制御局１がメディアアクセスを許可する送信局を決定する際の動作について、以下に説明する。第２１図は、制御局１が新規に周期的なメディアアクセスを要求する送信局２に対し、メディアアクセスを許可するか否かを判別するためのフローチャートである。
尚、本実施形態において、通信ネットワークに属する各局のメディアアクセス周期を基本周期の整数倍とする。又、基本周期内における周期的にポーリングされる各局のメディアアクセス時間の合計の上限は、この基本周期におけるＤＶＣ転送の場合にかかるメディアアクセス時間と同等とする。更に、制御局１は、周期的なメディアアクセスを許可した各局の基本周期内におけるメディアアクセス時間及びメディアアクセス周期を帯域管理部４１に記憶し、記憶したメディアアクセス時間を合計した時間をＤＶＣ転送時にかかるメディアアクセス時間から減算し、このようにして得られた時間を残り帯域として記憶する。
制御局１は、制御局１以外の局（以下、送信局とする）から送信される新規に周期的なメディアアクセスの許可を得るための帯域確保要請フレームを受信部４０で受信する（ＳＴＥＰ５１）。このとき、帯域確保要請フレームより、帯域情報として、送信局が必要とするメディアアクセス周期及びメディアアクセス時間が確認される。
そして、この帯域情報が帯域管理部４１に送出されると、帯域管理部４１において、この新規に周期的なメディアアクセスを要求する送信局が必要とするメディアアクセス周期が基本周期の整数倍であるか確認される（ＳＴＥＰ５２）。即ち、この送信局に対して送信する帯域確保フレームＣＦ−Ｐｏｌｌの送信周期が、基本周期の整数倍であるか、帯域管理部４１で確認される。
このとき、メディアアクセス周期が基本周期の整数倍であることが確認されると（Ｙｅｓ）、帯域管理部４１において、帯域確保要請フレームを送信した送信局が必要とするメディアアクセス時間と上述した残り帯域とを比較する（ＳＴＥＰ５３）。そして、メディアアクセス時間が残り帯域よりも短いことが確認されると（Ｙｅｓ）、帯域管理部４１において、このメディアアクセス時間と基本周期とを比較する（ＳＴＥＰ５４）。
この帯域管理部４１で、帯域情報から確認されたメディアアクセス時間が基本周期より短いことが確認されると（Ｙｅｓ）、送信局から要求されたメディアアクセス周期及びメディアアクセス時間が帯域管理部４１に格納されるとともに、このメディアアクセス時間を残り帯域から減算することで、残り帯域の時間を更新する（ＳＴＥＰ５５）。このＳＴＥＰ５５の動作を終了すると、再び、ＳＴＥＰ５１に移行して、帯域確保要請フレームの受信確認が行われる。
又、ＳＴＥＰ５２において、メディアアクセス周期が基本周期の整数倍でないとき（Ｎｏ）、又は、ＳＴＥＰ５３において、メディアアクセス時間が残り帯域より長いとき（Ｎｏ）、又は、ＳＴＥＰ５４において、メディアアクセス時間が基本周期より長いとき（Ｎｏ）、ＳＴＥＰ５１で受信された帯域確保要請フレームによる要求を拒否し、帯域管理部４１における確認されたメディアアクセス周期及びメディアアクセス時間が破棄される（ＳＴＥＰ５６）。そして、このＳＴＥＰ５６の動作を終了すると、ＳＴＥＰ５５の時と同様、再び、ＳＴＥＰ５１に移行して、帯域確保要請フレームの受信確認が行われる。
以上のようにメディアアクセス時間の設定を行うことによって、既存ＬＡＮのための帯域を保護しつつ、ＤＶＣまたはＤＶＣ以下の転送速度をもつリアルタイムＡＶデータの帯域を容易に確保することができる。
このように制御局１が送信局２のメディアアクセスの許可を行うとき、制御局１が送信局２の周期内での送信終了を検出し、送信局２が利用していた帯域を解放するために、第２２図に示すフローチャートに従って動作する。
まず、現在のＩＥＥＥ８０２．１１と同様、制御局１は、受信部４０で送信局２から送信されるパケット及び受信局から送信されるＡＣＫ又は遅延ＡＣＫが受信されると、受信された信号をＭＡＣ部３８で確認してメディアの監視を行う（ＳＴＥＰ１０１）。そして、ＭＡＣ部３８において、送信局２から送信されるパケット内のＭＡＣヘッダに含まれるＮＦ（Ｎｏｎ Ｆｉｎａｌ）ビットより送信局２の状態を監視し、ＮＦビットが０となったか否かを確認することで、送信終了を確認する（ＳＴＥＰ１０２）。即ち、第１９図の場合、パケット＃ｎ内のＭＡＣヘッダに含まれるＮＦビットが０であるとともに、パケット＃１〜＃ｎ−１内のＭＡＣヘッダに含まれるＮＦビットが１である。
このようにＭＡＣヘッダのＮＦビットにより送信終了を確認する処理はＰＣＦに適合したものである。このＰＣＦの通信では、送信局２と受信局３との間で通信を行うときには必ず制御局１を経由するので、このＮＦビットを監視することができる。又、制御局１がパケットを受信できず、送信局２へＡＣＫの返信できなかった場合には、送信局から即座にパケットが再送されていたため、ＳＴＥＰ１０２の処理による送信局２からのパケットの送信終了の確認が可能である。
ＳＴＥＰ１０２で、ＮＦビットが１である場合（Ｎｏ）、送信局２からのパケットの送信が終了してからＳＩＦＳ時間以上の時間が経過するまでに送信局２又は受信局３からの信号を受信部４０で受信したか否かが、ＭＡＣ部３８でシステムタイマ３７より与えられる時刻情報より確認される（ＳＴＥＰ１０３）。即ち、送信局２から送信されるパケットが最後のパケットであり、このパケットが送信されてからＳＩＦＳ時間以上経過したか否かが確認される。
このとき、送信局２からのパケットが送信終了してからＳＩＦＳ時間が経過するまでに、送信局２から送信される次のパケット又は受信局から送信されるＡＣＫを受信すると（Ｎｏ）、送信局２が送信可能とされるメディアアクセス時間であるＴＸＯＰ時間が経過したか否かが、ＭＡＣ部３８によってシステムタイマ３９による時刻情報を参照することで確認される（ＳＴＥＰ１０４）。そして、ＴＸＯＰ時間の経過が確認されなかったときは（Ｎｏ）、再度ＳＴＥＰ１０１以降の処理動作を行う。
このようなＳＴＥＰ１０３及びＳＴＥＰ１０４の処理動作が成されることで、送信局２及び受信局３の間で制御局１を経由しない通信を行うとともに遅延ＡＣＫの送信が可能となるＨＣＦにおいても、送信局２の帯域解放処理を行うことができる。即ち、ＮＦビットの確認を行わない場合でも、送信局２から送信される最後となるパケットを制御局１において確認することができる。
ＳＴＥＰ１０２においてＮＦビットが０であることが確認されたとき（Ｙｅｓ）、又、ＳＴＥＰ１０３において送信局２からのパケットの送信終了後ＳＩＦＳ時間以上経過したことが確認されたとき（Ｙｅｓ）、又、ＳＴＥＰ１０４においてＴＸＯＰ時間が経過したことが確認されたとき（Ｙｅｓ）、現在の衝突が発生しない区間ＣＦＰにおいて別の局へポーリングを行うポーリングスケジュールがあるかどうかが、ＭＡＣ部３８によって、帯域管理部４１より得られる帯域確保時間情報より確認される（ＳＴＥＰ１０５）。
そして、ＭＡＣ部３８によって、帯域確保時間情報よりポーリングスケジュールがあることが確認されると（Ｙｅｓ）、このポーリングスケジュールによって指定される次の局に対してメディアアクセスを許可するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１０６）、ＳＴＥＰ１０１以降の動作を行う。又、逆に、ポーリングスケジュールがないことが確認されると（Ｎｏ）、衝突が発生しない区間ＣＦＰが終了したことが確認されるため、衝突が発生しない区間を終了させるように、ＣＦ−Ｅｎｄを送信部３９から送信する（ＳＴＥＰ１０７）。
このようなフローチャートに従って動作するとき、区間ＣＦＰ内で２つの局に対してメディアアクセスが許可されている場合、第２３図のような通信が行われる。即ち、区間ＣＦＰの開始が確認されて、制御局１よりＣＦ−Ｐｏｌｌが送信されると、ＣＦ−Ｐｏｌｌによって送信局として設定される局からＲＴＳが送信されるとともに、ＲＴＳによって受信局として設定される局からＣＴＳが送信される。その後、送信局となる局と受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認され、ポーリングスケジュールにより次に送信局として設定される局をポーリングするためのＣＦ−Ｐｏｌｌが制御局１より送信される。その後、同様に、次に送信局となる局からＲＴＳが送信された後、次に受信局となる局からＣＴＳが送信されると、この送信局となる局及び受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認されるとともに、次のポーリングスケジュールが確認されないので、区間ＣＦＰを終了するためのＣＦ−Ｅｎｄが制御局１より送信される。
又、第１９図の例において、ＬＡＮと共存するために確保した区間を補償するために、メディアアクセス周期で許容されるジッタが設けられている。即ち、衝突が起きる可能性がある区間ＣＰにおいて、各局間で送受信されるＬＡＮパケットが基本周期から外れても送信許容されるジッタが設定される。又、このように区間ＣＰにおいてＬＡＮパケットが基本周期から外れることで生じた基本周期のずれを解消して帯域補填を行うために、次の基本周期を早く終了するためのジッタが設定される。
このような第１９図に示すジッタを用いた帯域補填動作について、以下に説明する。第２４図は、制御局１のＣＦ−Ｐｏｌｌの送信タイミングにおいて局４が２４Ｍｂｐｓの転送速度でＬＡＮパケットを送信中であったときの、各局の通信動作を示すためのタイミングチャートである。
局４が、基本周期終了後、ＬＡＮパケットの送信を終了すると、この局４からＬＡＮパケット受信した局より、ＬＡＮパケットの送信終了後ＳＩＦＳ時間の間隔でＬＡＮパケットに対するＡＣＫが返信される。そして、局４は、このＡＣＫを受信するために、ＤＩＦＳ＋ランダムバックオフ時間だけ待機する。このとき、制御局１は、ＬＡＮパケット送信終了をＭＡＣ部３８で確認すると、ＰＩＦＳ時間だけ待機した後に、送信部３９より帯域確保フレームＣＦ−Ｐｏｌｌを送信する。よって、基本周期終了からＣＦ−Ｐｏｌｌの送信までの間に、ＬＡＮパケットによる遅延となるジッタが生じる。
このように生じた遅延となるジッタは、ＭＡＣ部３８内に格納される。そして、ＭＡＣ部３８において、この遅延となるジッタを基本周期の長さから減算した時間を、次の基本周期の長さとして設定する。そして、第２２図のフローチャートに従って動作した後、ＣＦ−Ｅｎｄを送信して衝突が発生しない区間ＣＦＰを終了させる。その後、衝突が起きる可能性がある区間ＣＰになるが、制御局１は、上述のようにしてＭＡＣ部３８で設定した基本周期となると、この区間ＣＰを終了させて、次の基本周期を開始するために、ＣＦ−Ｐｏｌｌを送信部３９から送信する。このとき開始させる次の基本周期の長さは、元の周期の長さとされる。
即ち、制御局１では、遅延となるジッタが発生した次の基本周期については、その長さを、発生したジッタの長さ分短い長さとする。よって、遅延となるジッタが発生した次の基本周期では、ＣＦ−Ｐｏｌｌが送信されてから、基本周期の長さからジッタを減算した時間が経過したことを確認すると、次の基本周期が開始されるように、ＣＦ−Ｐｏｌｌを送信する。このとき、帯域補填するために早期終了させた分のジッタが発生する。
このように、局４による妨害によって遅延した分だけ早く衝突が起きる可能性がある区間ＣＰを終了させ、次の基本周期を開始する。この場合、局４による妨害が再び発生する可能性があるが、２４ＭｂｐｓのＬＡＮパケットであれば、その送信時間がジッタの範囲を超えることはないため、問題はない。
又、局４のＬＡＮパケットの転送速度が、本例で第２０図を利用して基本周期を計算した際に使用した転送速度以下である場合は、制御局１は、衝突が起きる可能性がある区間ＣＰにおいて、遅延ＡＣＫの送信終了後ＰＩＦＳ時間だけ待機する。そして、帯域確保フレームＣＦ−Ｐｏｌｌを送信して、衝突が発生しない区間ＣＦＰを再開する。このような動作を、失った帯域を補填するまで続けることによって、局４の妨害を防ぐとともに、速やかに帯域を補填することができる。
このような帯域補填を行うことにより、ＤＶＣによるＡＶソースパケットの送信と２４Ｍｂｐｓで送信される既存ＬＡＮとの共存が可能になる。
２．基本周期内に衝突が発生する区間を備えない場合
上記では、第１９図のような衝突が起きる可能性がある区間ＣＰが基本周期内に設けられるときの例を挙げたが、この区間ＣＰが基本周期内に設けられないものとしても構わない。この区間ＣＰが基本周期内に設けられないときの、ＨＣＦを備えた制御局１と送信局２と受信局３の基本的なパケット交換におけるタイミングチャートを、第２５図に示す。
第２５図の場合においても、第１９図の場合と同様、まず、制御局１から帯域確保フレームであるＣＦ−Ｐｏｌｌが送信部３９から送信された後、ＣＦ−Ｐｏｌｌを受信した送信局２よりＲＴＳが送信され、このＲＴＳを受信した受信局３よりＣＴＳが送信される。このようにして、送信局２及び受信局３が決定されると、送信局２から受信局３に対して、ＭＡＣパケットを含むパケット＃１〜＃ｎが送信される。
そして、制御局１において、パケット＃ｎの送信が終了したことが確認されると、ＣＦ−Ｅｎｄが送信部３９から送信される。このＣＦ−Ｅｎｄを受信局３が受信すると、ＣＦ−Ｅｎｄの受信が終了してからＳＩＦＳ時間が経過後に、受信局３から送信局２に対して遅延ＡＣＫが送信される。尚、ＣＦ−Ｐｏｌｌ、ＲＴＳ、ＣＴＳ、パケット＃１〜＃ｎ、ＣＦ−Ｅｎｄそれぞれの間隔は、第１９図の例と同様、ＳＩＦＳである。
そして、最初のＣＦ−Ｐｏｌｌが送信されてから基本周期分の時間が経過すると、次の基本周期が開始されるように、制御局１から、ＣＦ−Ｐｏｌｌが送信される。尚、基本周期内で最後に送信される遅延ＡＣＫが送信終了した後、送信待機時間ＳＩＦＳ以上の時間が経過してから次の基本周期が開始されるように、ＳＩＦＳ時間分待機した後に送信部３９からＣＦ−Ｐｏｌｌが送信される。
このように基本周期が設定されるとき、制御局１がメディアアクセスを許可する送信局を決定する際の動作については、第１９図の例と同様、第２１図のフローチャートに従って、周期的なメディアアクセスを要求する送信局２に対して、メディアアクセスの許可を行う。よって、その詳細な説明は省略する。
又、本例において、制御局１が送信局２の周期内での送信終了を検出し、送信局２が利用していた帯域を解放するために、第２６図に示すフローチャートに従って動作する。尚、第２６図のフローチャートにおいて、第２２図に示すフローチャートと同一の処理を行うステップについては、同一の符号を付してその詳細な説明は省略する。
まず、制御局１は、受信部４０で受信された信号をＭＡＣ部３８で確認してメディアの監視を行い（ＳＴＥＰ１０１）、送信局２から送信されるパケット内のＭＡＣヘッダにおけるＮＦビットが０となったか否かを確認する（ＳＴＥＰ１０２）。このとき、ＮＦビットが１である場合（Ｎｏ）、次に、送信局２から最後のパケットが送信されてからＳＩＦＳ時間以上経過したか否かが確認される（ＳＴＥＰ１０３）。更に、送信局２からＳＩＦＳ時間以内にパケットが送信されると（Ｎｏ）、ＴＸＯＰ時間が経過したか否かが確認される（ＳＴＥＰ１０４）。
このＳＴＥＰ１０２〜ＳＴＥＰ１０４の処理動作がおこなわれているとき、ＮＦビットが０であること、又は、最後のパケットが送信局２から送信されたこと、又は、ＴＸＯＰ時間が経過したことのそれぞれが確認されると、次のポーリングスケジュールがあるか確認される（ＳＴＥＰ１０５）。
このとき、帯域管理部４１より与えられる帯域確保時間情報から、次のポーリングスケジュールが確認されると（Ｙｅｓ）、送信部３９からＣＦ−Ｅｎｄを送信する（ＳＴＥＰ１５１）。その後、受信部４０で送信局３からの遅延ＡＣＫを受信したか否かがＭＡＣ部３８で確認され（ＳＴＥＰ１５２）、遅延ＡＣＫが受信されなかったとき（Ｎｏ）、ＣＦ−Ｅｎｄ送信終了後ＳＩＦＳ時間が経過したか否かが、システムタイマ３７からの時刻情報より確認される（ＳＴＥＰ１５３）。このとき、ＳＩＦＳ時間の経過が確認されなかったとき（Ｎｏ）、再び、ＳＴＥＰ１５２以降の動作を行う。
又、ＳＴＥＰ１５２において遅延ＡＣＫの受信が確認されたとき（Ｙｅｓ）、又は、ＳＴＥＰ１５３においてＣＦ−Ｅｎｄ送信終了後ＳＩＦＳ時間の経過が確認されたとき（Ｙｅｓ）、ＳＴＥＰ１０５で確認されたポーリングスケジュールによって指定される次の局に対してメディアアクセスを許可するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１０６）、ＳＴＥＰ１０１以降の動作を行う。
又、ＳＴＥＰ１０５において、次のポーリングスケジュールが確認されなかったとき（Ｎｏ）、送信部３９からＣＦ−Ｅｎｄを送信する（ＳＴＥＰ１５５）。その後、遅延ＡＣＫを受信したか否かが確認され（ＳＴＥＰ１５６）、遅延ＡＣＫが受信されなかったとき（Ｙｅｓ）、ＳＩＦＳ時間が経過したか否かが確認される（ＳＴＥＰ１５７）。このとき、ＳＩＦＳ時間の経過が確認されなかったとき（Ｎｏ）、再び、ＳＴＥＰ１５６以降の動作を行う。
又、ＳＴＥＰ１５６において遅延ＡＣＫの受信が確認されたとき（Ｎｏ）、又は、ＳＴＥＰ１５７においてＳＩＦＳ時間の経過が確認されたとき（Ｙｅｓ）、基本周期における最初のＣＦ−Ｐｏｌｌを送信してから基本周期分の時間が経過したことをシステムタイマ３７からの時刻情報より確認した後、次の基本周期を開始するために、ＣＦ−Ｐｏｌｌを送信部３９から送信した後（ＳＴＥＰ１５８）、ＳＴＥＰ１０１以降の動作を行う。
このようなフローチャートに従って動作するとき、区間ＣＦＰ内で２つの局に対してメディアアクセスが許可されている場合、第２７図のような通信が行われる。即ち、基本周期の開始が確認されて、制御局１よりＣＦ−Ｐｏｌｌが送信されると、送信局となる局からＲＴＳが送信されるとともに、受信局となる局からＣＴＳが送信される。その後、送信局となる局と受信局となる局との間で通信が行われる。
そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認され、ＣＦ−Ｅｎｄが制御局１から送信される。このＣＦ−Ｅｎｄの送信終了後ＳＩＦＳ時間が経過して、遅延ＡＣＫが受信局となる局から送信されたことが確認された後、遅延ＡＣＫ送信後ＳＩＦＳ時間経過すると、ポーリングスケジュールにより次に送信局として設定される局をポーリングするためのＣＦ−Ｐｏｌｌが制御局１より送信される。
その後、同様に、次に送信局となる局からＲＴＳが送信された後、次に受信局となる局からＣＴＳが送信されると、この送信局となる局及び受信局となる局との間で通信が行われる。そして、送信局となる局から最後のパケット＃ｎが送信されると、このパケット＃ｎの送信終了後ＳＩＦＳ時間以上の時間が経過したことが制御局１で確認されるとともに、次のポーリングスケジュールが確認されないので、まず、ＣＦ−Ｅｎｄが制御局１から送信される。
このＣＦ−Ｅｎｄの送信終了後ＳＩＦＳ時間が経過して、受信局となる局より遅延ＡＣＫが送信されたことが確認されると、基本周期を開始してＣＦ−Ｐｏｌｌを送信してから、基本周期となる時間が経過したか確認される。そして、基本周期となる時間が経過したことが確認されると、次の基本周期を開始するために、制御局１からＣＦ−Ｐｏｌｌが送信される。
尚、制御局１からＣＦ−Ｅｎｄを送信した後、ＳＩＦＳ時間以上の時間が経過したことが確認されると、ポーリングスケジュールがある場合は、すぐにＣＦ−Ｐｏｌｌが送信され、又、ポーリングスケジュールがない場合は、基本周期が終了したことが確認された後にＣＦ−Ｐｏｌｌが送信される。
又、本実施形態において、第１８図で示したように、ＡＶソースパケットのライフタイムをメディアアクセス周期の整数倍とすることによって、メディアアクセス周期が基本周期の整数倍であるため、ライフタイムを基本周期の整数倍とすることができる。このように、ＡＶソースパケットのライフタイムを基本周期で計測することができるので、このライフタイムの管理が容易になる。
よって、上述したように、ライフタイムがＡＶソースパケットを送受信することのできる時間を示すため、ライフタイムに対するメディアアクセス周期の倍数が再送可能なメディアアクセス周期の計数値に相当するのと同様、基本周期の倍数は再送可能な基本周期の計数値として考えることができる。又、ＡＶソースパック毎の再送回数が多ければ多いほどエラーに対する耐性は向上するが、ネットワークシステムにおいてＡＶソースパケットを再生する際の遅延が大きくなるとともに、送信局２及び受信局３それぞれに備えられるＡＶ伝送用バッファ７，３２のサイズも増大する。
上述のように、基本周期を６．８ｍｓとした場合、この間に転送されるＤＶＣ（スタンダード、３０Ｍｂｐｓ）ソースパケットの量は、２５．５Ｋバイトであり、ＭＰＥＧ２−ＴＳ高画質モード（２４Ｍｂｐｓ）ソースパケット量は２０．４Ｋバイトである。ライフタイムの間に転送される全ＡＶソースパケット量は、ライフタイムに対する基本周期の倍数に比例する。このライフタイムの間に転送される全ＡＶソースパケット量は、即ち、送信局２及び受信局３それぞれのＡＶ伝送用バッファ７，３２に必要とされるサイズになる。
よって、本実施形態における送信局２の機能及び受信局３の機能を一つのＬＳＩで実現する場合には、備えるＡＶ伝送用バッファのバッファサイズを適切なものとして、このバッファサイズに適合するよう基本周期を決める必要がある。又、基本周期が小さいほど、ＡＶ伝送用バッファのバッファサイズを節約しながら再送回数を増やすことができ、同時にライフタイムによるシステム遅延も抑えることができる。
又、本実施形態では高い頻度で時刻合わせを行うために、基本周期毎に必ず制御局１から送信されるＣＦ−ＰｏｌｌやＣＦ−Ｅｎｄに対して、システムタイマ３７から与えられる時刻情報が送信部３９で付加されて送信される。このようなＣＦ−ＰｏｌｌやＣＦ−Ｅｎｄのパケットフォーマットが、第２８図及び第２９図のように表される。
即ち、ＣＦ−Ｐｏｌｌは、第２８図のように、ＣＦ−Ｐｏｌｌであることを示すための３２バイトのＭＡＣヘッダと、システムタイマ３７より与えられた時刻情報となる２バイトのタイムスタンプと、送信局となる局を指定するとともにメディアアクセス時間などを備えるデータと、４バイトの誤り検出符号であるＦＣＳとによって構成される。又、ＣＦ−Ｅｎｄは、第２９図のように、ＣＦ−Ｅｎｄであることを示すための３２バイトのＭＡＣヘッダと、システムタイマ３７より与えられた時刻情報となる２バイトのタイムスタンプと、４バイトの誤り検出符号であるＦＣＳとによって構成される。
又、ＩＥＥＥ８０２．１１のタイマ精度は、上述したように０．０１％であるため、６．８ｍｓに一回で時刻合わせをする場合、ジッタを１．３μｓ程度に抑えることができる。本実施形態では、基本周期毎に送信される第２８図のような構成のＣＦ−Ｐｏｌｌ及び第２９図のような構成のＣＦ−Ｅｎｄそれぞれが受信される度に、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄそれぞれに備えられたシステムスタンプによって時刻合わせが行われる。よって、ＩＥＥＥ８０２．１１のシステムタイマ精度がμｓオーダーであるため、ＡＶソースパケットのタイムシーケンス再生におけるジッタがほとんど無視できる。
但し、基本周期を長くした場合は、制御局１は、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄとは別に時刻合わせ専用のフレームを送信するようにしても構わない。又、制御局１自身が送信局を兼ねる場合は、ＣＦ−Ｐｏｌｌを出さずに送信を開始する場合がある。この場合についても、ＣＦ−Ｐｏｌｌ及びＣＦ−Ｅｎｄとは別に時刻合わせ専用のフレームを送信するようにしても構わない。
尚、本実施形態では、ＤＶＣを転送するための基本周期を例にしたが、例えば、あるシステムではＤＶＣやＭＰＥＧ２−ＴＳ高画質モードの送信をあきらめ、通常のＭＰＥＧ２−ＴＳを数チャネル分流したいという場合もあるだろうし、またあるシステムではできるかぎりＬＡＮを優先したいという場合もある。衝突が生じない区間においてどのようなＡＶデータを扱うか、衝突が起きる可能性がある区間においてどのような機器と共存するかによって、基本周期と実転送レートが大きく変わる。そのようなシステムの構築例をいくつか取り決めておけば、ユーザーが望む最適な無線ネットワークシステムを簡単に実現できる。
又、本実施形態では、ライフタイムは基本周期の整数倍になるように設定したが、送信局及び受信局それぞれのＡＶ伝送バッファのバッファサイズに制限がある場合は、このＡＶ伝送バッファにおいて、リアルタイムＡＶデータを格納できる最大時間をライフタイムとしても構わない。この場合や、又は、システムとしてのライフタイムが設定されている場合、実転送レートが転送したいＡＶデータの転送量よりも大きく、且つ、その周期の長さがライフタイムの整数分の１になるように、基本周期を設定しても構わない。
更に、本実施形態では、各送信局が送信を行う際に与えるメディアアクセス時間が、リアルタイムＡＶデータが最速の転送速度で転送されるときのメディアアクセス時間とされる。又、このメディアアクセス時間の値の合計がシステムが扱う最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えないように、送信局として新規に参入する局の制限を行う。
これに対して、基本周期毎又は基本周期の整数倍毎に、各送信局がＡＶ伝送用バッファの空きメモリ情報となるキューイング情報を制御局１に通知し、制御局１は、このキューイング情報を用いて、次回以降の基本周期において各送信局が必要とするメディアアクセス時間を予想し、この予想に基づいてメディアアクセス制御を行うようにしても構わない。
又、ＭＰＥＧ２−ＴＳのような可変レートのリアルタイムＡＶデータを扱う送信局は、常に最大の転送速度で送信することがない。本実施形態では、最大転送速度時に各送信局が必要とするメディアアクセス時間の合計が最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えることはできない。しかしながら、上述のキューイング情報からメディアアクセス時間を予想する場合、予想したメディアアクセス時間の合計が最も転送速度が速いリアルタイムＡＶデータを転送するために必要なメディアアクセス時間を超えない限り、制御局１は各送信局に対するメディアアクセス制御を行うことができる。
しかし、転送レートの可変量はリアルタイムＡＶデータの内容によって変化するため、予測が不可能な場合もある。このような場合には、制御局１が予測した転送速度と各送信局が実際に必要とした転送速度の差分によって発生した齟齬を吸収するため、ＡＶ伝送用バッファのメモリサイズバッファを大きくするとともに、ライフタイムを長くすればよい。
又、再送すべきリードソロモン符号化ブロックを識別するために、本実施形態では、バッファアドレスを識別子として収めたＴａｇを使用したが、受信したパケットのシーケンス番号及びそのパケット内で誤り訂正できなかったリードソロモン符号化ブロックの位置を知らせるようにしても構わない。この場合、受信局３は、例えばＭＡＰにあるＳＰＣとＤＢＩを参照して、ＡＶ伝送用バッファ３２にＡＶデータパックを格納する際にＳＰＣとＤＢＩが連続的になるように格納する。
又、このとき、送信局２においては、送信済みのパケットのシーケンス番号及びＡＶデータパックの格納状況を保存するバッファを備える必要がある。更に、受信局３においては、ソースパケット出力回路３３だけではなく、ＡＶ伝送用バッファ３２においても、ＭＡＰを解析するための機能を備える必要がある。このようにすることにより付加情報となるＴａｇフィールドのオーバーヘッドを減らすことも可能である。
又、本実施形態では説明を省略したが、ＬＬＣ ＰＤＵデータに対しても本実施形態で説明した処理と同じ処理を行うことができる。但し、ＬＬＣ ＰＤＵの場合は、複数のリードソロモン符号化ブロックに分割できても、各リードソロモン符号化ブロック単位ではデータ処理不可能なため、必ずパケットがすべてそろった後に上位層に渡されて処理される。しかし、リードソロモン符号化ブロック単位での再送はパケット単位再送よりも再送に必要とする帯域が少ないため、帯域を有効に使う意味で有効である。
産業上の利用可能性
以上より、ネットワークシステムで各局がメディアアクセスできる基本周期を予め設定することで、制御局において簡単な処理動作と小規模の回路で各局のメディアアクセス制御を実現できる。又、誤り訂正符号と誤り訂正符号化ブロック単位の再送および暗号化を行うことにより、送信局及び受信局において、最小の帯域で信頼性の高くかつプライバシを保護する通信を実現できる。又、帯域制御フレームによる時刻合せによって、送信局と受信局の間で発生するＡＶソースパケットのジッタを最小におさえ、どの局でＡＶソースが再生されても違和感なく鑑賞することが可能になる。
更に、ライフタイムを基本周期の整数倍にすることで、送信局及び受信局におけるＡＶ伝送用バッファを最適なサイズにできるだけでなく、ＡＶソースパケットのライフタイムの管理が容易になる。又、基本周期の計算において既存局のメディアアクセス時間を確保しているため、どのような状況でも既存局との共存を実現できる。又、制御局の帯域解放処理を行うことにより、既存局が使用する帯域を多くとれる。
以上説明したように、本発明によれば、ネットワークシステムで各局がメディアアクセスできる基本周期をあらかじめ決めてしまうことで制御局において簡単なアルゴリズムで各局のメディアアクセス制御を実現できる。
誤り訂正符号と誤り訂正符号化ブロック単位の再送を使用することで、再送の発生頻度を抑え、かつ再送が発生した場合でも再送に必要とされる帯域を抑えつつ信頼性の高い通信を実現できる。
プライバシ保護のため、暗号化を行った場合でも、上記誤り訂正化ブロック単位の再送を実現できる。
ライフタイムを基本周期の整数倍とすることで、送信局、受信局におけるＡＶ伝送用バッファを最適なサイズにできるだけでなく、ＡＶソースパケットのライフタイムの管理が容易になるという効果がある。
基本周期の計算において既存局のメディアアクセス時間を確保していることにより、どのような状況でも既存局との共存を実現できる。さらに既存局が想定したメディアアクセス時間以上の通信を行った場合でも、失った帯域を補填するまで既存局にメディアアクセス権を与えないメディア制御をすることにより、衝突が発生しない区間における通信路の品質を落とさない通信を実現できる。
制御局が積極的に帯域解放処理を行うことにより、衝突が発生しない区間において発生した余剰帯域を衝突が起きる可能性のある区間に分配することで、既存局のメディアアクセス機会を増やすことが可能になる。
さらに帯域制御フレームによる時刻合せによって、送信局と受信局の間で発生するＡＶソースパケットのジッタを最小におさえ、どの局でＡＶソースが再生されても違和感なく鑑賞が可能になる。
【図面の簡単な説明】
第１図は、本発明に係わる無線通信ネットワークの一実施例を示す概略構成図である。
第２図は、本発明に係わる送信装置のブロック図である。
第３図は、本発明に係わる受信装置のブロック図である。
第４図は、本発明に係わる制御局のブロック図である。
第５図は、本発明に係わるＭＰＥＧ２−ＴＳパケット入力処理を示す図である
第６図は、本発明に係わるＤＶＣパケット入力処理を示す図である。
第７Ａ図及び第７Ｂ図は、本発明に係わるＭＡＰフォーマットを示す図である。
第８図は、本発明に係わるパケット送信処理の流れを示す図である。
第９図は、本発明に係わる誤り検出回路出力に対する誤り訂正回路出力の遅延を示す図である。
第１０図は、本発明に係わるパケット内の誤り訂正符号有無を判別するフローチャートを示す図である。
第１１図は、本発明に係わるパケット受信処理の流れを示す図である。
第１２図は、本発明に係わるＭＰＥＧ２−ＴＳパケット出力処理を示す図である。
第１３図は、本発明に係わるＤＶＣパケット出力処理を示す図である。
第１４図は、本発明に係わる現在提案されている遅延ＡＣＫフレームフォーマットを示す図である。
第１５図は、本発明に係わるリードソロモン符号化ブロック単位再送のために拡張した遅延ＡＣＫフレームフォーマットを示す図である。
第１６図は、本発明に係わる遅延ＡＣＫフレームを示す図である。
第１７図は、本発明に係わる送信局の送信状況更新を示す図である。
第１８図は、本発明に係わるライフタイムを考慮したＡＶ伝送用バッファを示す図である。
第１９図は、本発明に係わる送信周期とパケット構成を示す図である。
第２０図は、本発明に係わるＤＶＣ／ＬＡＮ（２４Ｍｂｐｓ）共存時のバースト回数と実転送レートおよび基本周期を示す図である。
第２１図は、本発明に係わる帯域管理のフローチャートを示す図である。
第２２図は、本発明に係わる帯域解放のフローチャートを示す図である。
第２３図は、本発明に係わる送信周期とパケット構成を示す図である。
第２４図は、本発明に係わるＬＡＮパケットによる帯域損失に対する補填を示す図である。
第２５図は、本発明に係わる送信周期とパケット構成を示す図である。
第２６図は、本発明に係わる帯域解放のフローチャートを示す図である。
第２７図は、本発明に係わる送信周期とパケット構成を示す図である。
第２８図は、本発明に係わるＣＦ−Ｐｏｌｌフレームを示す図である。
第２９図は、本発明に係わるＣＦ−Ｅｎｄフレームを示す図である。
第３０図は、ＰＣＦのＣＦＰとＣＰの関係を示す図である。
第３１図は、従来のタイマ精度と時刻合わせを示す図である。
Claims (85)
- 時刻を管理するシステムタイマと、
アプリケーションデータに対して前記システムタイマより得られた該アプリケーションの入力時刻に基づいて生成した時系列的管理用の時刻情報を付加するとともに、前記アプリケーションデータのうち保持期間が定められたアプリケーションデータに対して送信可能な期間を設定するデータ処理部と、
該データ処理部で前記時刻情報が与えられた前記アプリケーションデータを一時的に保持するバッファと、
該バッファから前記アプリケーションデータを読み出すともに該アプリケーションデータに誤り訂正符号を付加する誤り訂正符号付加部と、
該誤り訂正符号付加部で誤り訂正符号が付加されたアプリケーションデータから送信パケットを作成する送信パケット生成部と、
該送信パケット生成部で作成した前記送信パケットを送信する送信部と、
前記バッファからアプリケーションデータを読み出すことを制御するとともに、前記送信パケット生成部で生成された前記送信パケットを通信帯域が確保された時間に前記送信部から送信することを制御する送信制御部と、
前記送信部から送信した一つ又は複数の送信パケットの受信を示す応答信号を受信する受信部と、
を備え、
前記送信部から送信する際に、前記送信制御部において、前記システムタイマから得られる現在時刻と前記バッファ内に格納されたアプリケーションデータに対して設定された前記送信可能な期間とを比較し、該現在時刻が前記送信可能な期間を超過しているアプリケーションデータについては、前記誤り訂正符号付加部が前記バッファから読み出さず、
又、前記送信部より前記送信パケットを送信した後、所定時間以上経過しても、前記送信パケットに対する前記応答信号を前記受信部で受信しなかったことが前記送信制御部において確認されるとき、該送信パケットが正しく受信されていないと判定することを特徴とする通信装置。 - 前記データ処理部において、前記アプリケーションデータを複数のブロックに分割して前記バッファ内に格納し、
前記誤り訂正符号付加部において、前記バッファ内から各ブロック毎に前記アプリケーションデータを読み出すとともに、各ブロック毎に誤り訂正符号を付与することを特徴とする請求の範囲１に記載の通信装置。 - 前記送信パケットのパケットヘッダ部を生成するヘッダ生成部を備え、
前記誤り訂正符号付加部において、前記ヘッダ生成部で生成したパケットヘッダ部及び前記バッファより読み出した前記アプリケーションデータそれぞれに誤り訂正符号を付加した後、
前記送信パケット生成部において、前記誤り訂正符号付加部で誤り訂正符号が付加された前記パケットヘッダ部及び前記アプリケーションデータによって送信パケットを生成することを特徴とする請求の範囲２に記載の通信装置。 - 前記ブロック単位での再送要求を示す前記応答信号を前記受信部で受信したとき、再送要求されたブロックの前記アプリケーションデータのみを再送することを特徴とする請求の範囲３に記載の通信装置。
- 前記バッファに格納される前記アプリケーションデータのブロック毎の格納位置情報を、前記アプリケーションに対して、各ブロック毎に付加することを特徴とする請求の範囲４に記載の通信装置。
- 前記アプリケーションデータに対して前記暗号キーを用いて暗号化を施す暗号化部を備え、
前記ヘッダ生成部において、暗号キーをパケットヘッダ部に付与するとともに、
前記暗号化部で暗号化したアプリケーションデータ部に対して、前記誤り訂正付加部で誤り訂正符号を付加することを特徴とする請求の範囲５に記載の通信装置。 - 前記アプリケーションデータに対して、ブロック毎に誤り検出符号を付加する誤り検出付加部を備え、
該誤り検出付加部で誤り検出符号が付加されたブロックのアプリケーションデータに対して、前記暗号化部で暗号化することを特徴とする請求の範囲６に記載の通信装置。 - 前記送信可能な期間を、制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が設定される周期である基本周期の整数倍とし、
前記アプリケーションデータの保持期間を前記基本周期毎に管理することを特徴とする請求の範囲７に記載の通信装置。 - 前記制御局となる通信装置によって、通信が許可される時間となるメディアアクセス時間と、該メディアアクセス時間の与えられる周期であるメディアアクセス周期とが、設定され、
該メディアアクセス周期が、前記基本周期の整数倍とされることを特徴とする請求の範囲８に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲９に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲１０に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲１０に記載の通信装置。
- 前記ブロック単位での再送要求を示す前記応答信号を前記受信部で受信したとき、再送要求されたブロックの前記アプリケーションデータのみを再送することを特徴とする請求の範囲２に記載の通信装置。
- 前記バッファに格納される前記アプリケーションデータのブロック毎の格納位置情報を、前記アプリケーションに対して、各ブロック毎に付加することを特徴とする請求の範囲２に記載の通信装置。
- 前記アプリケーションデータに対して前記暗号キーを用いて暗号化を施す暗号化部を備え、
前記ヘッダ生成部において、暗号キーをパケットヘッダ部に付与するとともに、
前記暗号化部で暗号化したアプリケーションデータ部に対して、前記誤り訂正付加部で誤り訂正符号を付加することを特徴とする請求の範囲２に記載の通信装置。 - 前記アプリケーションデータに対して、ブロック毎に誤り検出符号を付加する誤り検出付加部を備え、
該誤り検出付加部で誤り検出符号が付加されたブロックのアプリケーションデータに対して、前記暗号化部で暗号化することを特徴とする請求の範囲１５に記載の通信装置。 - 前記送信可能な期間を、制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が設定される周期である基本周期の整数倍とし、
前記アプリケーションデータの保持期間を前記基本周期毎に管理することを特徴とする請求の範囲２に記載の通信装置。 - 制御局となる通信装置によって、通信が許可される時間となるメディアアクセス時間と、該メディアアクセス時間の与えられる周期であるメディアアクセス周期とが、設定され、
該メディアアクセス周期が、前記制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が設定される周期である基本周期の整数倍とされることを特徴とする請求の範囲２に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲２に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲１９に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲１９に記載の通信装置。
- 前記送信パケットのパケットヘッダ部を生成するヘッダ生成部を備え、
前記誤り訂正符号付加部において、前記ヘッダ生成部で生成したパケットヘッダ部及び前記バッファより読み出した前記アプリケーションデータそれぞれに誤り訂正符号を付加した後、
前記送信パケット生成部において、前記誤り訂正符号付加部で誤り訂正符号が付加された前記パケットヘッダ部及び前記アプリケーションデータによって送信パケットを生成することを特徴とする請求の範囲１に記載の通信装置。 - 前記アプリケーションデータに対して暗号キーを用いて暗号化を施す暗号化部を備え、
前記ヘッダ生成部において、前記暗号キーをパケットヘッダ部に付与するとともに、
前記暗号化部で暗号化したアプリケーションデータ部に対して、前記誤り訂正付加部で誤り訂正符号を付加することを特徴とする請求の範囲１に記載の通信装置。 - 前記送信可能な期間を、制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が設定される周期である基本周期の整数倍とし、
前記アプリケーションデータの保持期間を前記基本周期毎に管理することを特徴とする請求の範囲１に記載の通信装置。 - 制御局となる通信装置によって、通信が許可される時間となるメディアアクセス時間と、該メディアアクセス時間の与えられる周期であるメディアアクセス周期とが、設定され、
該メディアアクセス周期が、前記制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が設定される周期である基本周期の整数倍とされることを特徴とする請求の範囲１に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲１に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲２６に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲２６に記載の通信装置。
- 時刻を管理するシステムタイマと、
時系列的管理用の時刻情報が付加されたアプリケーションデータから成る送信パケットを受信する受信部と、
該受信部で受信された送信パケットに誤り訂正符号が付加されているか否かを判定する誤り訂正判定部と、
前記受信部で受信された送信パケットのうち誤り訂正符号が付加された送信パケットに対して誤り訂正を施す誤り訂正処理部と、
誤り訂正が成された送信パケットよりアプリケーションデータを生成する第１復号部と、
前記受信部で受信された送信パケットのうち誤り訂正符号が付加されていない送信パケットより前記アプリケーションデータを生成する第２復号部と、
前記第１及び第２復号部で生成された前記アプリケーションデータを一時的に格納する第１及び第２バッファと、
前記システムタイマによる時刻が前記アプリケーションデータに付加された時刻情報による時刻と一致したことを確認すると、前記アプリケーションデータを前記第１又は第２バッファから読み出して出力するデータ出力部と、
１つ又は複数の送信パケットの受信状態を示す応答信号を送信する送信部と、
を備え、
前記受信部で受信された送信パケットに対して、前記誤り訂正処理部及び前記第１復号部による第１演算処理と、前記第２復号部による第２演算処理とを同時に施すことを特徴とする通信装置。 - 前記誤り訂正判定部で、前記受信部で受信された送信パケットが他の通信装置宛の送信パケットであることを確認すると、前記第２演算処理を停止して、前記第１演算処理のみを行うことを特徴とする請求の範囲２９に記載の通信装置。
- 前記誤り訂正判定部で、前記受信部で受信された送信パケットに含まれるパケットヘッダに誤り訂正符号が付加されていることを確認すると、前記第２演算処理を停止して、前記第１演算処理のみを行うことを特徴とする請求の範囲３０に記載の通信装置。
- 前記第１及び第２演算処理を平行して行うときに、前記誤り訂正処理部で誤り訂正が施された送信パケットに含まれるパケットヘッダに誤りが確認されたとき、前記第１演算処理を停止して、前記第２演算処理のみを行うことを特徴とする請求の範囲３１に記載の通信装置。
- 前記第１及び第２演算処理を平行して行うときに、前記誤り訂正判定部で前記送信パケットに誤りが確認されたとき、前記第２演算処理を停止して、前記第１演算処理のみを行うことを特徴とする請求の範囲３１に記載の通信装置。
- 前記通信パケットがブロック毎に分割されたアプリケーションデータに対して誤り訂正符号化が成され、
正常に復号できなかった前記アプリケーションデータにおいて前記ブロック単位で再送の要求を行う前記応答信号を前記送信部より送信することを特徴とする請求の範囲３１に記載の通信装置。 - 前記アプリケーションデータの各ブロックを一意に判別できるブロック確認情報を前記各ブロック毎に前記アプリケーションデータに付与して前記第１又は第２バッファに格納し、
前記ブロック確認情報を用いて正常に復号できなかった前記アプリケーションのブロックを認識して、前記ブロック単位の再送要求を行う応答信号を生成することを特徴とする請求の範囲３４に記載の通信装置。 - 前記第１又は第２バッファにおいて、前記アプリケーションデータの各ブロックを、付加された前記ブロック確認情報に応じたバッファアドレスに格納することを特徴とする請求の範囲３５に記載の通信装置。
- 制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が終了すること示す非衝突区間終了信号を前記受信部で受信すると、
非衝突区間終了信号の受信して所定時間経過後に、前記ブロック単位の再送要求を行う応答信号を前記送信部より送信することを特徴とする請求の範囲３６に記載の通信装置。 - 前記送信パケットがアプリケーションデータが前記ブロック単位毎に暗号化されたデータ部と暗号化するための暗号キーを有するパケットヘッダ部を備えるとともに、
前記第１及び第２復号部において、前記パケットヘッダより暗号キーを抽出した後、前記データ部を該暗号キーで前記ブロック単位毎に復号することを特徴とする請求の範囲３７に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲３８に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲３９に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲３９に記載の通信装置。
- 前記送信パケットがアプリケーションデータが暗号化されたデータ部と暗号化するための暗号キーを有するパケットヘッダ部を備えるとともに、
前記第１及び第２復号部において、前記パケットヘッダより暗号キーを抽出した後、前記データ部を該暗号キーで復号することを特徴とする請求の範囲３１に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲３１に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲４３に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲４３に記載の通信装置。
- 前記通信パケットがブロック毎に分割されたアプリケーションデータに対して誤り訂正符号化が成され、
正常に復号できなかった前記アプリケーションデータにおいて前記ブロック単位で再送の要求を行う前記応答信号を前記送信部より送信することを特徴とする請求の範囲２９に記載の通信装置。 - 前記アプリケーションデータの各ブロックを一意に判別できるブロック確認情報を前記各ブロック毎に前記アプリケーションデータに付与して前記第１又は第２バッファに格納し、
前記ブロック確認情報を用いて正常に復号できなかった前記アプリケーションのブロックを認識して、前記ブロック単位の再送要求を行う応答信号を生成することを特徴とする請求の範囲４６に記載の通信装置。 - 前記第１又は第２バッファにおいて、前記アプリケーションデータの各ブロックを、付加された前記ブロック確認情報に応じたバッファアドレスに格納することを特徴とする請求の範囲４７に記載の通信装置。
- 制御局となる通信装置によって通信路における衝突が発生しない非衝突区間が終了すること示す非衝突区間終了信号を前記受信部で受信すると、
非衝突区間終了信号の受信して所定時間経過後に、前記ブロック単位の再送要求を行う応答信号を前記送信部より送信することを特徴とする請求の範囲２９に記載の通信装置。 - 前記送信パケットがアプリケーションデータが暗号化されたデータ部と暗号化するための暗号キーを有するパケットヘッダ部を備えるとともに、
前記第１及び第２復号部において、前記パケットヘッダより暗号キーを抽出した後、前記データ部を該暗号キーで復号することを特徴とする請求の範囲２９に記載の通信装置。 - 前記受信部において、時刻情報を備えるパケットを受信するとともに、
該時刻情報に基づいて前記システムタイマによる時刻を修正することを特徴とする請求の範囲２９に記載の通信装置。 - 前記受信部において、前記時刻情報を備えるパケットを定期的に受信することを特徴とする請求の範囲５１に記載の通信装置。
- 前記受信部において、前記時刻情報を備えるパケットを準定期的に受信することを特徴とする請求の範囲５１に記載の通信装置。
- 時刻を管理するシステムタイマと、
他の通信装置から送信される通信帯域の確保を要求する帯域確保要求信号を受信する受信部と、
通信帯域が確保され衝突が生じない非衝突区間を時分割で管理する帯域管理部と、
前記システムタイマより得られる現在時刻を他の通信装置に認識させるための時刻情報信号と、前記非衝突区間の開始を他の通信装置に認識させるための非衝突区間開始信号と、前記非衝突区間の終了を他の通信装置に認識させるための非衝突区間終了信号と、を送信する送信部と、
を備え、
前記非衝突区間を発生させる周期を基本周期とし、
前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間の周期であるメディアアクセス周期が、前記基本周期の整数倍でないとき、該他の通信装置の帯域確保の要求を拒否することを特徴とする通信装置。 - 前記基本周期を、最も転送速度の速いデータを送信局となる通信装置から受信局となる通信装置へ転送するために必要な時間間隔とすることを特徴とする請求の範囲５４に記載の通信装置。
- 前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間であるメディアアクセス時間が、前記非衝突区間より既に通信許可を行った通信装置のメディアアクセス時間の合計を減算して得た残り帯域より短いとき、前記帯域確保要求信号を送信した通信装置の帯域確保を行うことを特徴とする請求の範囲５５に記載の通信装置。
- アプリケーションデータのタイムシーケンス再生時のジッタ許容値と、送信局となる通信装置と受信局となる通信装置との間で発生するタイマ誤差の値から、前記時刻情報信号の送信間隔を決定することを特徴とする請求の範囲５６に記載の通信装置。
- 帯域確保が行われて前記帯域管理部で帯域が管理された他の通信装置に対して、メディアアクセス時間が開始されたことを示す帯域確保信号を送信部より送信するとともに、前記非衝突区間開始信号が該帯域確保信号の一つであることを特徴とする請求項５７に記載の通信装置。
- 前記帯域確保信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項５８に記載の通信装置。
- 前記非衝突区間終了信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項５９に記載の通信装置。
- 前記非衝突区間開始信号の送信が遅延した場合、該非衝突区間開始信号によって開始する基本周期の長さを本来の周期間隔よりも短くすることを特徴とする請求の範囲６０に記載の通信装置。
- 前記非衝突区間に送信されたパケットを受信した他の通信装置の応答状態を示す応答信号を該他の通信装置が送信するための帯域確保を、他のパケットより優先的に行うことを特徴とする請求項６１に記載の通信装置。
- 前記送信部が、前記時刻情報信号を準定期的にも送信することを特徴とする請求項６２に記載の通信装置。
- 前記基本周期に、通信路における衝突が発生する可能性がある衝突可能性区間が、前記非衝突区間の後に設けられ、
前記非衝突区間終了信号を送信部から送信したとき、前記衝突可能性区間が開始することを特徴とする請求項５４に記載の通信装置。 - 前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間であるメディアアクセス時間が、前記非衝突区間より既に通信許可を行った通信装置のメディアアクセス時間の合計を減算して得た残り帯域より短いとき、前記帯域確保要求信号を送信した通信装置の帯域確保を行うことを特徴とする請求の範囲６４に記載の通信装置。
- アプリケーションデータのタイムシーケンス再生時のジッタ許容値と、送信局となる通信装置と受信局となる通信装置との間で発生するタイマ誤差の値から、前記時刻情報信号の送信間隔を決定することを特徴とする請求の範囲６４に記載の通信装置。
- 前記送信部が、前記時刻情報信号を準定期的にも送信することを特徴とする請求項６６に記載の通信装置。
- 帯域確保が行われて前記帯域管理部で帯域が管理された他の通信装置に対して、メディアアクセス時間が開始されたことを示す帯域確保信号を送信部より送信するとともに、前記非衝突区間開始信号が該帯域確保信号の一つであることを特徴とする請求項６４に記載の通信装置。
- 前記帯域確保信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項６８に記載の通信装置。
- 前記非衝突区間終了信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項６４に記載の通信装置。
- 前記非衝突区間開始信号の送信が遅延した場合、該非衝突区間開始信号によって開始する基本周期の長さを本来の周期間隔よりも短くすることを特徴とする請求の範囲６４に記載の通信装置。
- 前記非衝突区間に送信されたパケットを受信した他の通信装置の応答状態を示す応答信号を該他の通信装置が送信するための帯域確保を、他のパケットより優先的に行うことを特徴とする請求項６４に記載の通信装置。
- 前記送信部が、前記時刻情報信号を準定期的にも送信することを特徴とする請求項６４に記載の通信装置。
- 前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間であるメディアアクセス時間が、前記非衝突区間より既に通信許可を行った通信装置のメディアアクセス時間の合計を減算して得た残り帯域より短いとき、前記帯域確保要求信号を送信した通信装置の帯域確保を行うことを特徴とする請求の範囲５４に記載の通信装置。
- アプリケーションデータのタイムシーケンス再生時のジッタ許容値と、送信局となる通信装置と受信局となる通信装置との間で発生するタイマ誤差の値から、前記時刻情報信号の送信間隔を決定することを特徴とする請求の範囲５４に記載の通信装置。
- 前記送信部が、前記時刻情報信号を準定期的にも送信することを特徴とする請求項５４に記載の通信装置。
- 帯域確保が行われて前記帯域管理部で帯域が管理された他の通信装置に対して、メディアアクセス時間が開始されたことを示す帯域確保信号を送信部より送信するとともに、前記非衝突区間開始信号が該帯域確保信号の一つであることを特徴とする請求項５４に記載の通信装置。
- 前記帯域確保信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項７８に記載の通信装置。
- 前記非衝突区間終了信号が、前記時刻情報信号としての機能を備えることを特徴とする請求項５４に記載の通信装置。
- 前記非衝突区間開始信号の送信が遅延した場合、該非衝突区間開始ｈしんごうによって開始する基本周期の長さを本来の周期間隔よりも短くすることを特徴とする請求の範囲５４に記載の通信装置。
- 前記非衝突区間に送信されたパケットを受信した他の通信装置の応答状態を示す応答信号を該他の通信装置が送信するための帯域確保を、他のパケットより優先的に行うことを特徴とする請求項５４に記載の通信装置。
- 前記送信部が、前記時刻情報信号を準定期的にも送信することを特徴とする請求項５４に記載の通信装置。
- 複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、
前記制御局によって送信局とされる通信装置が、
時刻を管理するシステムタイマと、
アプリケーションデータに対して前記システムタイマより得られた該アプリケーションの入力時刻に基づいて生成した時系列的管理用の時刻情報を付加するとともに、前記アプリケーションデータのうち保持期間が定められたアプリケーションデータに対して送信可能な期間を設定するデータ処理部と、
該データ処理部で前記時刻情報が与えられた前記アプリケーションデータを一時的に保持するバッファと、
該バッファから前記アプリケーションデータを読み出すともに該アプリケーションデータに誤り訂正符号を付加する誤り訂正符号付加部と、
該誤り訂正符号付加部で誤り訂正符号が付加されたアプリケーションデータから送信パケットを作成する送信パケット生成部と、
該送信パケット生成部で作成した前記送信パケットを送信する送信部と、
前記バッファからアプリケーションデータを読み出すことを制御するとともに、前記送信パケット生成部で生成された前記送信パケットを通信帯域が確保された時間に前記送信部から送信することを制御する送信制御部と、
前記送信部から送信した一つ又は複数の送信パケットの受信を示す応答信号を受信する受信部と、
を備え、
前記送信部から送信する際に、前記送信制御部において、前記システムタイマから得られる現在時刻と前記バッファ内に格納されたアプリケーションデータに対して設定された前記送信可能な期間とを比較し、該現在時刻が前記送信可能な期間を超過しているアプリケーションデータについては、前記誤り訂正符号付加部が前記バッファから読み出さず、
又、前記送信部より前記送信パケットを送信した後、所定時間以上経過しても、前記送信パケットに対する前記応答信号を前記受信部で受信しなかったことが前記送信制御部において確認されるとき、該送信パケットが正しく受信されていないと判定する、
ことを特徴とする通信システム。 - 複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、
前記制御局によって受信局とされる通信装置が、
時刻を管理するシステムタイマと、
時系列的管理用の時刻情報が付加されたアプリケーションデータから成る送信パケットを受信する受信部と、
該受信部で受信された送信パケットに誤り訂正符号が付加されているか否かを判定する誤り訂正判定部と、
前記受信部で受信された送信パケットのうち誤り訂正符号が付加された送信パケットに対して誤り訂正を施す誤り訂正処理部と、
誤り訂正が成された送信パケットよりアプリケーションデータを生成する第１復号部と、
前記受信部で受信された送信パケットのうち誤り訂正符号が付加されていない送信パケットより前記アプリケーションデータを生成する第２復号部と、
前記第１及び第２復号部で生成された前記アプリケーションデータを一時的に格納する第１及び第２バッファと、
前記システムタイマによる時刻が前記アプリケーションデータに付加された時刻情報による時刻と一致したことを確認すると、前記アプリケーションデータを前記第１又は第２バッファから読み出して出力するデータ出力部と、
１つ又は複数の送信パケットの受信状態を示す応答信号を送信する送信部と、
を備え、
前記受信部で受信された送信パケットに対して、前記誤り訂正処理部及び前記第１復号部による第１演算処理と、前記第２復号部による第２演算処理とを同時に施す
ことを特徴とする通信システム。 - 複数の通信装置によって構成されるとともに、該複数の通信装置の内の１つを制御局とする通信システムにおいて、
前記制御局となる通信装置が、
時刻を管理するシステムタイマと、
他の通信装置から送信される通信帯域の確保を要求する帯域確保要求信号を受信する受信部と、
通信帯域が確保され衝突が生じない非衝突区間を時分割で管理する帯域管理部と、
前記システムタイマより得られる現在時刻を他の通信装置に認識させるための時刻情報信号と、前記非衝突区間の開始を他の通信装置に認識させるための非衝突区間開始信号と、前記非衝突区間の終了を他の通信装置に認識させるための非衝突区間終了信号と、を送信する送信部と、
を備え、
前記非衝突区間を発生させる周期を基本周期とし、
前記受信部で受信された前記帯域確保要求信号より確認される通信許可を求める期間の周期であるメディアアクセス周期が、前記基本周期の整数倍でないとき、該他の通信装置の帯域確保の要求を拒否する
ことを特徴とする通信システム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001128657 | 2001-04-26 | ||
| JP2001128657 | 2001-04-26 | ||
| PCT/JP2002/004107 WO2002089413A1 (fr) | 2001-04-26 | 2002-04-24 | Appareil de communication et systeme de communication faisant appel a ce dernier |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2002089413A1 true JPWO2002089413A1 (ja) | 2004-11-11 |
| JP3703456B2 JP3703456B2 (ja) | 2005-10-05 |
Family
ID=18977320
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002586576A Expired - Fee Related JP3703456B2 (ja) | 2001-04-26 | 2002-04-24 | 通信装置及びこの通信装置によって構成される通信システム |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP3703456B2 (ja) |
| WO (1) | WO2002089413A1 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20050113623A (ko) * | 2003-02-28 | 2005-12-02 | 톰슨 라이센싱 | 무선 근거리 통신망 독점 다운링크 채널 방법 |
| WO2005067213A1 (ja) * | 2003-12-26 | 2005-07-21 | Matsushita Electric Industrial Co., Ltd. | 無線アクセスシステム |
| JP4440037B2 (ja) | 2004-08-11 | 2010-03-24 | 株式会社東芝 | 通信装置及び通信方法 |
| JP4736434B2 (ja) * | 2005-01-11 | 2011-07-27 | ソニー株式会社 | データ伝送システム |
| JP4596256B2 (ja) * | 2005-08-02 | 2010-12-08 | ソニー株式会社 | 送受信システムおよび方法、送信装置および方法、受信装置および方法、並びにプログラム |
| US8014818B2 (en) | 2006-01-04 | 2011-09-06 | Interdigital Technology Corporation | Methods and systems for providing efficient operation of multiple modes in a WLAN system |
| TWI419533B (zh) * | 2006-01-04 | 2013-12-11 | Interdigital Tech Corp | Ｗｌａｎ系統中提供多模式有效率操作方法及系統 |
| WO2007082229A2 (en) * | 2006-01-10 | 2007-07-19 | Conexant Systems, Inc. | Symmetric transmit opportunity (txop) truncation |
| JP2008079150A (ja) * | 2006-09-22 | 2008-04-03 | Canon Inc | 通信機器及びデータ転送方法 |
| JP2008109471A (ja) * | 2006-10-26 | 2008-05-08 | Nec Corp | Ｌａｎシステム、送信装置、受信装置、ｌａｎシステム制御方法、プログラム、及び複数のフレーム |
| JP2009239451A (ja) * | 2008-03-26 | 2009-10-15 | Nec Electronics Corp | 到着確認及び中継処理確認型ネットワーク装置及びシステム、フレーム転送方法 |
| US8706878B1 (en) | 2008-08-21 | 2014-04-22 | United Services Automobile Association | Preferential loading in data centers |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2531454B2 (ja) * | 1993-10-05 | 1996-09-04 | 日本電気株式会社 | 時刻設定方式 |
| JPH09130447A (ja) * | 1995-10-31 | 1997-05-16 | Nec Corp | 無線データ伝送装置 |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| JPH11213044A (ja) * | 1998-01-26 | 1999-08-06 | Nippon Telegr & Teleph Corp <Ntt> | カード情報転送方法及びシステム装置 |
| JP3489472B2 (ja) * | 1999-03-02 | 2004-01-19 | 日本電信電話株式会社 | 無線パケット制御局 |
| JP3640844B2 (ja) * | 1999-09-17 | 2005-04-20 | 株式会社東芝 | エラー処理機能を備えた伝送装置及びエラー処理方法 |
-
2002
- 2002-04-24 WO PCT/JP2002/004107 patent/WO2002089413A1/ja active Application Filing
- 2002-04-24 JP JP2002586576A patent/JP3703456B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002089413A1 (fr) | 2002-11-07 |
| JP3703456B2 (ja) | 2005-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9749091B2 (en) | Method and device for data communication in a communication network | |
| JP4391316B2 (ja) | ワイヤレスｌａｎ用のメディア・アクセス・コントロール装置 | |
| JP4834253B2 (ja) | 優先権及び無競合間隔を有するメディアアクセス制御プロトコル | |
| EP3013094B1 (en) | Information processing apparatus | |
| US8472468B2 (en) | Communication apparatus, communication method, and communication system | |
| JP4528541B2 (ja) | 通信装置、通信方法、および通信システム | |
| US8228889B2 (en) | Communication apparatus, communication system and communication control program | |
| US6909723B1 (en) | Segment bursting with priority pre-emption and reduced latency | |
| EP2923514B1 (en) | Method and system for improving wireless link efficiency | |
| JP4558515B2 (ja) | 伝送エラー制御方法及び伝送エラー制御デバイス | |
| US8718089B2 (en) | Aggregation and fragmentation of multiplexed downlink packets | |
| JP3703456B2 (ja) | 通信装置及びこの通信装置によって構成される通信システム | |
| US10028306B2 (en) | Method and device for data communication in a network | |
| JP3730245B2 (ja) | 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、通信装置、中央管理装置、およびネットワークシステム | |
| JP2005027298A (ja) | 無線ネットワークのステーションにおけるデータの伝送を管理するための方法及び装置 | |
| JP3770399B2 (ja) | 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、通信システム、通信装置、および中央管理装置 | |
| JP2004007336A (ja) | 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、ならびに通信局 | |
| KR101648556B1 (ko) | 무선 근거리 통신망에서의 패킷 송신 방법 및 장치 | |
| JP4033860B2 (ja) | データ通信方法及びデータ送信装置 | |
| JP2007151171A (ja) | 通信装置、通信方法、および通信システム | |
| GB2520692A (en) | Method and device for data communication in an ad-hoc wireless network | |
| JP2009010552A (ja) | フレーム制御方法及び通信システム | |
| US7606233B2 (en) | Method for micro-controller and DSP based data communication within a transceiver | |
| JP2007519294A (ja) | 少ないフレーム間隔（ｉｆｓ）時間のデータフレームの送信 | |
| GB2529673A (en) | Method and device for data communication in a network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040729 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050719 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050719 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |