JP3589343B2 - フレーム伝送方法及びフレーム伝送装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、フレーム構成変更が可能なフレーム伝送方法及びフレーム伝送装置に関する。
【０００２】
【従来の技術】
高速なデータ通信、マルチメディア通信を実現する方法として、複数の物理チャネルを束ねて一本のチャネルとして用いるマルチリンクがある。このマルチリンクに関する方式としては、ＩＴＵ−Ｔ勧告 Ｈ．２２６が標準化されている。Ｈ．２２６は異なる種類、異なる伝送速度の物理チャネルを束ねることができる汎用的で柔軟なマルチリンクプロトコルを規定している。
図５は、マルチリンクに入力される情報ビットストリーム（Ｄａｔａ Ｓｔｒｅａｍ ｆｒｏｍ Ｈｉｇｈｅｒ Ｌａｙｅｒｓ）とそれに対応するＨ．２２６のフレームフォーマットを示す図である。情報ビットストリームは任意長のデータセット（Ｄａｔａ ｓｅｔ１、２）に区切られ、データセットごとに複数の物理チャネル（Ｃｈａｎｎｅｌ０〜Ｍ−１）にマッピングされる。マッピングの単位はサンプル（Ｓａｍｐｌｅｓ）と呼ばれ、Ｈ．２２６では８ビットのサンプルが用いられる。各データセットの区切りを受信側が識別可能とするために、データセットの先頭を示すヘッダセット（Ｈｅｄｅｒ Ｓｅｔ１、２）が挿入される。ヘッダセットは、各チャネルで伝送されるヘッダ群から構成されており、受信側でデータセットを再構築するための情報が含まれている。
図６は、ヘッダの構成を示す図である。ヘッダは、大きく分けて必須フィールドとオプションフィールドという２種類のフィールドから構成されている。必須フィールドにはフレーム同期確立に用いられるフラグ（ＦＬＡＧ）や各オプションフィールドの有無を示すコントロールフィールド（Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ） 、ヘッダ用ＣＲＣ（Ｈｅａｄｅｒ ＣＲＣ）がある。オプションフィールドには、シーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）やチャネル番号（Ｃｈａｎｎｅｌ ＴＡＧ）、チャネルビットレート比（Ｃｈａｎｎｅｌ Ｐｒｏｐｏｒｔｉｏｎ）、データ用ＣＲＣ（Ｄａｔａ ＣＲＣ）があり、コントロールフィールドを用いてフレーム毎にその有無を選択できる。
図７は、コントロールフィールドを用いたフレーム構成の変更手順を説明する図である。コントロールフィールドは、各オプションフィールドの有無およびフィールド長を示すフラグ群から構成されている。なお、この図７では、説明の便宜上、シーケンス番号をＳＮ、チャネル番号をＣＴ、チャネルビットレート比をＣＰ、データ用ＣＲＣをＤとする。例えば、コントロールフィールドの各フラグがＳＮ＝０１、ＣＴ＝０１、ＣＰ＝００、Ｄ＝００の場合、１バイトのシーケンス番号フィールド、１バイトのチャネル番号フィールドがオプションフィールドとして含まれており、チャネルビットレート比フィールド、データ用ＣＲＣは伝送されないことを示している。
このように、通信中に必要に応じてヘッダ構成を設定することにより、柔軟かつ効率的な伝送を可能としている。
ここで、Ｈ．２２６は有線での通信を対象に考えられているが、Ｈ．２２６をさらに移動通信を対象に拡張したものとして、モバイルマルチリンクプロトコル（以下、単にモバイルマルチリンクという）が提案されている。これは、ビット誤り率が有線網と比較して高い無線伝送路の特徴を考慮したものである。
モバイルマルチリンクでは、誤り耐性を改善するために、同期フラグの延長やフレーム長情報の導入によるフレーム同期の強化を図っている。通信開始時には、受信ビットストリームから同期フラグの検出を行い、検出された同期フラグに続くヘッダのフレーム長情報を用いてフレーム同期を確立する。ここで、フレーム長はフレーム毎に任意に設定可能であるが、モバイルマルチリンクではフレームヘッダ部にビット誤りが発生した場合の同期外れを防止するために、固定長のフレームを推奨している。このモバイルマルチリンクにおいて固定長のフレームを用いた場合、フレーム長情報は、通信開始時にのみ必要な情報であり、フレーム同期が確立し通信状態が安定した後には不要となる情報である。このフレーム長情報のように通信途中で不要となった情報を送信しつづけることは、伝送効率の面から望ましいことではない。
このような事情に鑑み、Ｈ．２２６と同様に通信中にヘッダ構成を変更し、不要な情報を削除することにより伝送効率を向上するフレーム伝送方法が望まれる。
【０００３】
【発明が解決しようとする課題】
ところが、Ｈ．２２６で用いられているコントロールフィールドのみを用いたヘッダ構成変更方法を適用した場合、送信側がヘッダ構成を自由に変更できるため非常に柔軟で効率的な伝送が可能になるが、ビット誤りに対して脆弱であるという問題がある。図８は、ビット誤り存在下におけるこの方法の問題点を説明する図である。
まず、図８（ａ）の例において、通信開始時にフレーム同期を確立するために、送信側はフレーム長情報（図８に示す長さ情報）をヘッダに含むフレームをある設定回数だけ伝送し、その後、フレーム同期が確立したものと想定してフレーム長情報をヘッダから削除したフレームを送信し始める。ところが、伝送路においてバースト的なビット誤りが発生し、通信開始時に送信されたフレーム長情報を含むヘッダを全て正常に受信できなかった場合、その後のフレーム長情報が含まれないヘッダからフレーム同期を確立することはビット誤り存在下では非常に困難となってしまう。
次に、図８（ｂ）の例では、通信中にフレーム長を変更するために、送信側はフレーム長情報をヘッダに含むフレームをある設定回数だけ伝送し、その後、フレーム長情報をヘッダから削除したフレームを再び送信し始める。ところが、伝送路においてバースト的なビット誤りが発生し、変更後のフレーム長情報を含むヘッダを全て正常に受信できなかった場合、受信側ではフレーム長が変更されたことを認識できず、変更前のフレーム長でフレーム同期を維持しつづけようとするため、以後のフレームで同期外れが発生する。また、再同期を行う場合も、フレーム長情報が含まれないヘッダから再同期を行うことはビット誤り存在下では非常に困難となってしまう。
上記の問題は、いずれもフレーム構成の変更を送信側主導で行い、受信側が変更手順に関わっていないことに起因している。
これに対し、送信側がヘッダ構成変更前に受信側に対しヘッダ構成変更要求メッセージを送信する方法が考えられる。この方法では、受信側は、ヘッダ構成変更要求メッセージを受信した場合、ヘッダ構成の変更を受け入れることができる場合は要求応答メッセージを送信側に送り、受け入れることができない場合には要求拒否メッセージを送るか何も送らないこととする。送信側は、受信側からの要求応答メッセージを受信した場合にのみヘッダ構成を変更できる。
この方法は、前期の方法のように、受信側でフレーム長情報の受信に失敗することを防止することができ、確実なヘッダ構成変更が可能となるが、ヘッダ構成変更手順に要する時間が大きくなることが問題となる。特に、衛星通信や移動通信などのようにラウンドトリップ伝送遅延時間が比較的大きい場合には、ヘッダ構成変更に要する時間は１秒以上になる場合も有り、その間は効率の低いフレーム伝送を行うこととなる。
本発明は、以上説明した事情を鑑みてなされたものであり、確実かつ速やかにフレームの構成を変更することが可能なフレーム伝送装置を提供することを目的とする。
【０００４】
【課題を解決するための手段】
上述した問題を解決するため、請求項１に記載のフレーム伝送方法は、相手装置から送信されるフレームを受信する受信側の装置が、フレーム構成変更要求コマンドを前記相手装置へ送信する過程と、前記受信側の装置が、前記フレーム構成変更要求コマンドの送信に応じて、フレーム構成変更前のフレーム受信を継続しながらフレーム構成変更後のフレーム待ち受けを行う過程とを具備することを特徴とする。
また、請求項２に記載のフレーム伝送装置は、相手装置に対してフレームを送信するとともに、フレーム構成変更の要求コマンドを送信するフレーム送信手段と、前記相手装置からフレームを受信する手段であって、前記フレーム構成変更の要求コマンドが当該相手装置に送信されたときには、フレーム構成変更前のフレーム受信を継続しながらフレーム構成変更後の待ち受けを行うフレーム受信手段とを具備することを特徴とする。
また、請求項３に記載のフレーム伝送装置は、請求項２に記載の構成において、
前記フレーム送信手段は、制御チャネルを介して前記フレーム構成変更の要求コマンドを送信し、前記フレーム受信手段により、相手装置から制御チャネルを介してフレーム構成変更の要求コマンドが受信された場合には、該要求コマンドに従って、フレーム構成の変更を行うことを特徴とする。
また、請求項４に記載のフレーム伝送装置は、請求項２または３のいずれか１の請求項に記載の構成において、前記フレーム構成の変更がヘッダフィールドを追加する変更である場合には、相手装置からの要求コマンドを待つことなくフレーム構成の変更を行い、フレーム構成変更後のフレームを相手装置に送信することを特徴とする。
【０００５】
【発明の実施の形態】
以下、本発明をさらに理解しやすくするため、実施の形態について説明する。かかる実施の形態は、本発明の一態様を示すものであり、この発明を限定するものではなく、本発明の範囲で任意に変更可能である。
【０００６】
Ａ．本実施形態
（１）実施形態の構成
図１は、この発明の第一の実施形態に係るフレーム伝送装置の構成を示すブロック図である。このフレーム伝送装置１００は、フレームの送信及び受信が可能なフレーム伝送装置であり、受信系統１１０と送信系統１２０と制御部１３０とにより構成されている。
【０００７】
受信系統１１０は、受信部１１１と、フレーム分離部１１２と、多重分離部１１３とを有している。
受信部１１１は、ネットワーク側から通信チャネルを介してフレームを受信する。
フレーム分離部１１２では、同期フラグとフレーム長情報を用いてフレーム同期をとり、フレームヘッダの情報に基いて、フレームをヘッダとペイロード部に分離する。ペイロード部は、多重分離部１１３に入力され、音声・画像・データなどのユーザデータと制御コマンドとに分離される。
本実施形態に関わるフレーム伝送装置１００は、通信チャネル内に多重化された（インバンド）制御チャネルを介して制御コマンド（例えば、フレーム構成変更要求など）の送信及び受信を行う。多重分離部１１３から出力された制御コマンドは送信制御部１３１に入力され、送信側のフレームヘッダ構成の制御に用いられる。
【０００８】
送信系統１２０は、送信部１２１と、フレーム生成部１２２と、多重化部１２３とを有している。
送信部１２１は、通信チャネルを介してフレームを送信する。
フレーム生成部１２２は、多重化部１２３から入力されるデータにヘッダを付加してフレームを生成する。ここで付加されるヘッダは、送信制御部１３１から受け取った制御メッセージに基づいて生成される。
多重化部１２３では、音声・画像・データなどのユーザデータや制御コマンドを一本のビットストリームに多重化する。ここで、多重化部１２３に入力される制御コマンドは、通信状態（フレーム同期など）に応じて、受信制御部１３２で生成される。
送信制御部１３１は、制御チャネルを介して受信された制御コマンドの解析を行い、その結果に基づいてフレーム生成部１２２におけるヘッダ生成を制御する。
受信制御部１３２は、フレーム分離部１１２のフレーム受信状況をモニタしフレーム同期が確立したことを検出すると、現在のフレーム長などの情報を含むフレームヘッダの構成変更要求コマンドを多重化部１２３に対して送出すると共に、コマンドを送信したことをフレーム分離部１１２に通知する。
【０００９】
（２）実施形態の動作
図２は、本実施形態に係るフレーム伝送装置１００を用いて通信開始時からヘッダ構成変更を行う際のシーケンス図である。図２に示すシーケンスは、端末１と端末２との間において同期が確立し、構成１のフレーム伝送が行われていることを前提としている。
【００１０】
端末１の受信側でフレーム同期が確立すると、端末１の受信制御部１３２は、ヘッダ構成変更を要求するコマンド（以下、単にコマンドという）を多重化部１２３に出力する。多重化部１２３は、コマンドと画像、音声、データなどユーザデータを多重化し、フレーム生成部１２２を介して送信部１２１に出力する。
【００１１】
コマンドを生成した端末１の受信制御部１３２は、構成１のフレーム分離を行っているフレーム分離部１１２に対して、構成１のフレーム分離を継続して行うと共に、構成２のフレームを待ち受けるよう指示する。（図２の▲２▼）
【００１２】
ここで、受信制御部１３２から構成２のフレーム待ち受け指示を受けたフレーム分離部１１２にフレームが入力されると、フレーム分離部１１２は受信フレームヘッダのコントロールフィールド２２（図３）を参照し、フレーム構成の判定を開始する。フレーム分離部１１２の具体的な動作については、図４に示すフローチャートを参照して説明する。
【００１３】
まず、通信開始時には、フレーム分離部１１２は、受信部１１１から受信ビットストリームを受け取り、フレームヘッダ２０の構成情報を元に構成１のフレーム同期確立を試みる。同期確立後、フレーム分離部１１２は構成１フレームの待ち受け状態に入る（状態１）。
状態１にあるフレーム分離部１１２は、受信部１１１から受信フレームを受け取ると、まずフレームヘッダ２０のコントロールフィールド２２を読み出し、受信したフレームの構成を判定する。
図２の▲２▼の期間にフレーム分離部１１２に入力されるフレームは、端末１からのコマンドを受信する前に、端末２が端末１宛てに送信した構成１のフレームである。すなわち、端末１からのコマンドを受信する前に端末２のフレーム生成部１２２が生成した構成１のフレームが分離部１１２に入力されるのである。
【００１４】
フレーム分離部１１２は、受け取ったフレームのコントロールフィールド２２が「１１１１」であることから、受け取ったフレームは構成１のフレームであると判断する。フレーム分離部１１２は、この判断結果に基づき受け取ったフレームをヘッダとペイロードとに分離する。
フレームの分離操作を終えたフレーム分離部１１３は、再び状態１に戻り、構成１のフレーム待ち受けを行う。
【００１５】
ここで、固定長フレームを用いている場合、フレーム同期が確立した後は、構成１のフレームヘッダに含まれるフレーム長情報は不要となる。そこで、端末１の受信制御部１３２は、フレーム同期確立後の任意の時間に、構成１から構成２への変更要求コマンドを送出すると共に、このコマンドに関するタイマを起動する。
また、コマンドの送出後直ちに、フレーム分離部１１２に対し、構成２へのヘッダ構成の変更要求コマンドを送出したことを通知する。このコマンドの中には、フレーム長情報の削除要求と同期フレーム長情報が含まれている。
端末１から送信されたコマンドが端末２に受信されるまでの間、端末２は構成１のフレーム送信を行う。
ここで、端末１から送信されたコマンドは、端末２の受信部１２１とフレーム分離部１１２と多重分離部１１３を経て送信制御部１３１に入力される。端末２の送信制御部１３１は、このコマンドの解析を行い、受信されたコマンドがヘッダ構成の変更を要求するコマンドである場合には、フレーム生成部１２２に対してヘッダ構成の変更要求を行う。具体的には、フレーム構成を構成１から構成２に変更すべき旨をフレーム生成部１２２に通知するのである。
ここで、コマンドがフレーム長情報の削除要求であった場合には、送信制御部１３０は、コマンドに含まれる端末１の同期フレーム長情報を端末２が送信しているフレーム長と比較し、等しい場合にはその要求を受け入れることとする。
【００１６】
フレーム生成部１２２は、送信制御部１３１からの通知を受け、直ちにフレーム構成の切り替え（構成１から構成２）を行う。そして、フレーム生成部１２２は、構成２のフレーム生成を開始し、生成した構成２のフレームを送信部１２１に出力する。
送信部１２１は、フレーム生成部１２２から構成２のフレームを受け取ると、通信チャネルを介して構成２のフレームを端末１宛てに送信する。（図２の▲３▼）。
【００１７】
このとき、端末１は、構成１のフレーム受信を継続すると共に、構成２のフレーム待ち受けを行っている（図２の▲２▼）。従って、端末１はこの構成２のフレームを受信することができる。構成２のフレームが入力されたフレーム分離部１１２の動作については、前掲図４を参照して説明する。
【００１８】
フレーム分離部１１２は、受信部１１１からフレームを受け取ると、前述した場合と同様にフレームヘッダ２０のコントロールフィールド２２を読み出し、受信したフレームの構成を判定する。
【００１９】
フレーム分離部１１２は、受信フレームのコントロールフィールド２２が「０１１１」であることから、フレーム長情報が削除された構成２のフレームであると判断する。
ここで、構成２のフレームを受け入れるかどうかは、受信制御部１３２からコマンド送信通知を受けているか否かによって決定する。通知を受けている場合には、フレーム分離部は、構成２のフレーム情報に基づき、受信フレームをヘッダとペイロードとに分離すると共に、構成２のフレームの受信待ち受け状態に入る（状態２）。そして、フレームの分離操作を終えると、フレーム分離部１１２は受信制御部１３２に対し、構成２への変更が完了したことを通知する。
一方、受信制御部１３２から通知を受けていない場合には、何らかの誤りが発生しているものと判断し、誤り処理を実行し、引き続き構成１のフレーム受信待ち状態に入る（状態１）。
【００２０】
受信制御部１３２は、フレーム分離部１１２からの通知を受け、受信フレームの構成が構成１から構成２に変わったことを確認すると、当該コマンドに関するタイマを終了する。タイマ値が規定のスレッショルド値を超えてもフレーム分離部１１２から完了通知を受け取れない場合（タイムアウト）は、再び変更要求コマンドを端末２に対して送出する。
【００２１】
状態２にあるフレーム分離部１１２は、構成２のフレームを受信した場合、構成２のフレーム情報に基づき、受信フレームをヘッダとペイロードに分離し、状態２に戻る。
一方、構成１のフレームを受信した場合は、構成１のフレーム情報に基づき受信フレームをヘッダとペイロードに分離し、構成１のフレーム待ち受け状態（状態１）に入る。ここで、構成２から構成１への変更は、フレーム長情報を追加することであり、ヘッダ構成の変更要求コマンドによる変更手順は不要である。なぜならば、変更後はフレーム長情報を用いたフレーム同期が可能となり、伝送誤り存在下においても受信側でフレーム同期を再生することが容易であるからである。
また、固定のフレーム長を端末２側で変更したい場合は、構成１のフレームを用いて、すなわちフレーム長変更後のフレーム長情報を含むフレームを用いて新しいフレーム長を端末１に通知することによって、迅速に新しいフレーム長での通信が可能となる。新しいフレーム長へ移行した後、再びヘッダ構成を変更したい場合は前述の手順を繰り返す。
【００２２】
Ｂ．その他
本実施形態においては、ヘッダ構成変更の要求コマンドをユーザデータと多重化してインバンドで伝送することとしたが、アウトバンドの制御チャネルを介して送信及び受信するようにしても良い。また、制御コマンド用チャネルの品質については特に言及しなかったが、品質保証されたチャネルを用いて、確実な制御を実現するようにしても良い。
また、本実施形態においてはフレーム長情報フィールドの変更についてのみ説明を行ったが、これに限定する趣旨ではない。例えば、データ用ＣＲＣフィールドの変更についても本発明を適用することが可能である。
また、本実施形態に置いては、フレーム長情報フィールドの変更を説明する都合上、固定長フレームを前提として、ヘッダ構成変更前後におけるフレームのフレーム長に変更が無いものとして説明を行ったが、これに限定する趣旨ではない。ヘッダ構成変更前後においてフレーム長が変化する可変長のフレームを採用することも可能である。但し、可変長フレームを採用した場合には、フレーム長情報を削除することは望ましくない。
【００２３】
【発明の効果】
以上説明したように、本発明によれば、フレーム構成変更前後における伝送誤りの影響を回避することができると共に、フレーム構成変更の要求があった場合、応答などを返すことなく、迅速にフレーム構成の変更を行うことができるという効果がある。
【図面の簡単な説明】
【図１】本実施形態に係るフレーム伝送装置１００の構成を示すブロック図である。
【図２】同実施形態に係るヘッダ構成変更制御手順を示すシーケンス図である。
【図３】同実施形態に係るフレーム構成を示す図である。
【図４】同実施形態に係るヘッダ構成変更制御手順を示すシーケンス図である。
【図５】ＩＴＵ−Ｔ勧告Ｈ．２２６で用いられているフレーム構成を示す図である。
【図６】Ｈ．２２６で用いられているフレームヘッダ構成を示す図である。
【図７】Ｈ．２２６のヘッダ構成変更手順を示す図である。
【図８】Ｈ．２２６のヘッダ構成変更手順における問題点を示す図である。
【符号の説明】
１００ … フレーム伝送装置 １１０ … 受信系統
１１１ … 受信部 １１２ … フレーム分離部
１１３ … 多重分離部 １２０ … 送信系統
１２１ … 送信部 １２２ … フレーム生成部
１２３ … 多重部 １３０ … 制御部
１３１ … 送信制御部 １３２ … 受信制御部

Claims (4)

1. 相手装置から送信されるフレームを受信する受信側の装置が、フレーム構成変更要求コマンドを前記相手装置へ送信する過程と、
   前記受信側の装置が、前記フレーム構成変更要求コマンドの送信に応じて、フレーム構成変更前のフレーム受信を継続しながらフレーム構成変更後のフレーム待ち受けを行う過程と
   を具備することを特徴とするフレーム伝送方法。
2. 相手装置に対してフレームを送信するとともに、フレーム構成変更の要求コマンドを送信するフレーム送信手段と、
   前記相手装置からフレームを受信する手段であって、前記フレーム構成変更の要求コマンドが当該相手装置に送信されたときには、フレーム構成変更前のフレーム受信を継続しながらフレーム構成変更後の待ち受けを行うフレーム受信手段と
   を具備することを特徴とするフレーム伝送装置。
3. 前記フレーム送信手段は、制御チャネルを介して前記フレーム構成変更の要求コマンドを送信し、前記フレーム受信手段により、相手装置から制御チャネルを介してフレーム構成変更の要求コマンドが受信された場合には、該要求コマンドに従って、フレーム構成の変更を行うことを特徴とする請求項２に記載のフレーム伝送装置。
4. 前記フレーム構成の変更がヘッダフィールドを追加する変更である場合には、相手装置からの要求コマンドを待つことなくフレーム構成の変更を行い、フレーム構成変更後のフレームを相手装置に送信することを特徴とする請求項２または３のいずれか１の請求項に記載のフレーム伝送装置。

Images