JPH11500890A

JPH11500890A - 非均一非透過的データチャンネルのレート適応方法及び装置

Info

Publication number: JPH11500890A
Application number: JP9521766A
Authority: JP
Inventors: ユーハレーセネン
Original assignee: ノキアテレコミュニカシオンスオサケユキチュア
Priority date: 1995-12-11
Filing date: 1996-12-10
Publication date: 1999-01-19
Also published as: US6118834A; FI955944A; AU717658B2; EP0808537A1; KR19980702011A; AU1098697A; FI955944A0; CN1173955A; NO973655D0; WO1997022196A1; NO973655L; CA2212435A1

Abstract

(57)【要約】本発明は、容量の高いトラフィックチャンネル区分及び容量の低いトラフィックチャンネル区分を含む非均一な非透過的トラフィックチャンネル又は１組のトラフィックチャンネルを経て、送信者のテレコミュニケーション装置(IWF,TAF)と受信者のテレコミュニケーション装置(TAF,IWF)との間にフレーム構造化データ送信プロトコル(RLP)を使用してデータ送信を行うためのテレコミュニケーションシステムのレート適応方法及び装置に係る。高い容量と低い容量のトラフィックチャンネル区分間のインターフェイスに設けられるこのレート適応装置は、データバッファ(51)及びデータバッファコントローラ(52)を備えている。データバッファ(51)は、高い容量のトラフィックチャンネル区分から受け取ったフレームを、それらが低い容量のトラフィックチャンネル区分へ送信されるまでバッファする。データバッファコントローラ(52,53)は、送信者のテレコミュニケーション装置(IWF,TAF)において上記データ送信プロトコルに基づきデータ流コントローラを必要に応じて作動することにより、データバッファ(51)の充満レベルを調整する。

Description

【発明の詳細な説明】非均一非透過的データチャンネルのレート適応方法及び装置発明の分野本発明は、特に、無線インターフェイスに非標準的な送信容量を有する移動システムにおいて、非均一非透過的データ送信チャンネルのためのレート適応方法及びレートアダプタに係る。先行技術の説明移動システムとは、一般に、システム内を移動する加入者に対して専用のワイヤレスデータ送信を行うことのできる種々のテレコミュニケーションシステムを意味する。典型的な移動システムは、公衆地上移動ネットワーク（ＰＬＭＮ）である。ＰＬＭＮは、移動ネットワークのサービスエリアに配置された固定の無線ステーション（ベースステーション）を備えており、これらベースステーションの無線有効到達エリア（セル）が均一なセルラーネットワークを形成する。ベースステーションは、移動ステーションとＰＬＭＮとの間で通信するためのインターフェイス（エアインターフェイス）をセルに形成する。移動ステーションは、ネットワーク内を移動することができ、そしていずれかのベースステーションを経てＰＬＭＮにアクセスするので、ＰＬＭＮには、加入者データの管理、ハンドオーバー（通話中のベースステーションの切り換え）に対する移動加入者の確証及び位置管理、等のための複雑な構成体が設けられる。又、ネットワークには、通常のスピーチ通話（スピーチサービス）以外の情報、例えば、データ、ファクシミリ、ビデオ像等の送信をサポートするサービスも提供される。これらの新たなサービスは、著しい量の開発作業及び新たな構成体をネットワークに必要とする。移動システムの別のエリアは、衛星をベースとする移動サービスを含む。衛星システムにおいては、地上ベースステーションではなく衛星により無線有効到達範囲が得られる。衛星は、地球を回る軌道に配置され、移動ステーション（又はユーザターミナルＵＴ）と地上の地球ステーション（ＬＥＳ）との間に無線信号を送信する。個々の衛星の有効到達エリアは、移動ステーションが常に少なくとも１つの衛星の有効到達エリア内に位置するように、連続的な有効到達範囲を与えるように構成される。必要とされる衛星の数は、所望の有効到達範囲によって左右される。地表面における連続的な有効到達範囲は、例えば、１０個の衛星を必要とする。加入者の移動は、ＰＬＭＮの場合と同様の構成体、即ち加入者データの管理、移動加入者の確証及び位置管理、ハンドオーバー等の構成体を衛星移動システムに必要とする。又、衛星システムは、ＰＬＭＮと同様のサービスをサポートしなければならない。衛星移動システムにおいてこれらの要求を実施する１つの方法は、既存のＰＬＭＮ構成体を使用することである。原理的に、このやり方は非常に簡単である。というのは、衛星システムは、互換性のない無線インターフェイスを有する移動システムのベースステーションシステムに基本的に匹敵し得るからである。換言すれば、ベースステーションシステムが衛星システムであるような従来のＰＬＭＮインフラストラクチャーを使用することができる。このような場合に、原理的には、同じネットワークインフラストラクチャーが、従来のＰＬＭＮベースステーションシステム及び衛星の「ベースステーションシステム」の両方を含むことができる。しかしながら、ＰＬＭＮインフラストラクチャー及び衛星システムの適応に関連して多数の実際的な問題が生じる。本出願人に明らかな問題は、ＰＬＭＮのトラフィックチャンネルと、衛星システムの「無線インターフェイス」のトラフィックチャンネルとが著しく異なることである。ＰＬＭＮが環ヨーロッパデジタル移動システムＧＳＭ（移動通信用のグローバルなシステム）であり、そして衛星移動システムが現在開発中のインマルサットＰシステムである例について検討する。ＧＳＭシステムのトラフィックチャンネルは、ユーザレート２４００、４８００、７２００及び９６００ビット／ｓのデータ送信をサポートする。将来、無線インターフェイスに２つ以上のトラフィックチャンネルを用いる（マルチスロットアクセス）高速データサービス（ＨＳＣＳＤ＝高速回路切り換えデータ）は、更に高いユーザレート（１４４００ビット／ｓ、１９６００ビット／ｓ・・・）もサポートする。又、非透過的データサービスは、移動ステーションＭＳと、典型的に移動サービス交換センターＭＳＣに位置するインターワーキング機能ＩＷＦとの間に無線リンクプロトコルＲＬＰを使用する。ＲＬＰは、フレーム構造化バランス型（ＨＤＣＬ型）データ送信プロトコルである。ＲＬＰにおけるエラー修正は、トラフィックチャンネルにおいて崩壊したフレームであって受信者により要求されるフレームを再送信することに基づいている。トラフィックチャンネルは、送信エラーの影響を減少する目的でチャンネルコード化を使用する。チャンネルコード化及び他のオーバーヘッド情報により、無線インターフェイスのビットレートは実際のユーザレートよりも高くなる。ユーザレート２４００、４８００及び９６００ビット／ｓに対する無線インターフェイスのレートは、各々、３６００、６０００及び１２０００ビット／ｓである。インマルサットＰ衛星システムは、４８００ビット／ｓまでの標準的なデータレートを１つのトラフィックチャンネル（例えば、１２００、２４００、４８００ビット／ｓ）において送信でき、そして４８００ビット／ｓを越える標準的なデータレート（例えば、９６００、１４４００、１９２００ビット／ｓ等）を、例えば、ＧＳＭシステムのＨＳＣＳＤサービスの場合のように、多数の並列なトラフィックチャンネルを使用することにより送信できることを必要とする。インマルサットＰ衛星システムでは、無線インターフェイスにおける１つのトラフィックチャンネルのデータレートがせいぜい４８００ビット／ｓであり、これは、ターミナルインターフェイスにおける４８００ビット／ｓのユーザデータレートに等しい。２つのトラフィックチャンネルを使用するデータサービスにおいては、無線インターフェイスのデータレートがターミナルインターフェイスにおける９６００ビット／ｓのユーザデータレートに等しい。換言すれば、ＭＳとＭＳＣとの間の端−端トラフィックチャンネルは、衛星岐路にわたるトラフィックチャンネル区分の容量がＬＥＳとＭＳＣとの間のトラフィックチャンネル区分の容量よりも低いので、非均一である。トラフィックチャンネルのこの非均一性は、ＲＬＰプロトコルを用いる非透過的なデータサービスにおいて次のような問題を引き起こす。先ず第１に、ＭＳＣ−ＩＷＦは、ＩＳＤＮ又はＰＳＴＮのような固定のネットワークからデータが受信されるのと同じレートでＭＳに向かってデータを送信する。実際に、これは、非透過的通話において１２０００ビット／ｓのデータレートを意味する。というのは、ＩＷＦのデータモデムが固定のネットワークに向かって自動ボー決めモードで動作するからである。ＬＥＳは、ＭＳＣ−ＩＷＦから受け取ったデータを非常に低いレート即ち４８００ビット／ｓでＭＳに向かって送信する。ＭＳは、ＬＥＳが低いデータレートで送信するデータを容易に受け取るが、データは累積し始め、ＬＥＳにおいて失われることがある。しかし、ＭＳＣ−ＩＷＦは、ＲＬＰプロトコルで設定された送信窓がいっぱいになるまで１２０００ビット／ｓの全レートで送信を続ける。送信窓は、受信者から確認を受け取ることなく送信者が送信できるＲＬＰフレームの個数を指す。他の形式の無線インターフェイスがＰＬＭＮ、例えば、ワイヤレス電話システムに接続されたときにも、無線インターフェイスのトラフィックチャンネル区分の容量がＰＬＭＮの残りの部分のトラフィックチャンネル区分の容量よりも低い場合には同様の問題が生じる。発明の要旨本発明の目的は、上記問題を解消又は軽減することである。本発明は、容量の高いトラフィックチャンネル区分と、容量の低いトラフィックチャンネル区分とを含む非均一な非透過的トラフィックチャンネル又は１組のトラフィックチャンネルを経て、送信者のテレコミュニケーション装置と受信者のテレコミュニケーション装置との間にフレーム構造化データ送信プロトコルを使用してデータ送信を行うためのテレコミュニケーションシステムのレート適応装置に係る。このレート適応装置は、高い容量と低い容量のトラフィックチャンネル区分間のインターフェイスに配置され、そして高い容量のトラフィックチャンネル区分から受け取ったフレームを、それらが低い容量のトラフィックチャンネル区分へ送信されるまでバッファするデータバッファと、送信者のテレコミュニケーション装置において上記データ送信プロトコルに基づきデータ流コントローラを必要に応じて作動することにより、データバッファの充満レベルを調整するように構成されたデータバッファコントローラと、を備えたことを特徴とする。又、本発明は、容量の高いトラフィックチャンネル区分及び容量の低いトラフィックチャンネル区分を含む非均一な非透過的トラフィックチャンネル又は１組のトラフィックチャンネルを経て、送信者のテレコミュニケーション装置と受信者のテレコミュニケーション装置との間にフレーム構造化データ送信プロトコルを使用してデータ送信を行うためのレート適応方法にも係る。このレート適応方法は、高い容量のトラフィックチャンネル区分から受け取ったフレームを、それらが低い容量のトラフィックチャンネル区分へ送信されるまでデータバッファにバッファし、上記データバッファの充満レベルを監視し、両テレコミュニケーション装置間にデータ送信プロトコルを介在させ、そしてデータバッファの充満レベルが第１のスレッシュホールド値まで増加したときに送信者においてデータ送信プロトコルに基づいてデータ流コントローラを作動化し、そしてデータバッファの充満レベルが第２のスレッシュホールド値まで減少しそしてデータ流コントローラの作動が受信者により要求されないときには送信者の方向にデータ送信プロトコルに基づきデータ流コントローラを不作動化する、という段階を備えたことを特徴とする。本発明においては、高い容量のトラフィックチャンネル区分と低い容量のトラフィックチャンネル区分との間に（例えば、移動ネットワークからＭＳに向かうダウンリンク方向に）データバッファがあり、このデータバッファは、高い容量のトラフィックチャンネル区分から受け取ったデータフレームを、低い容量のトラフィックチャンネル区分を経てそれらを送信できるまで記憶することにより、所要のレート適応を与える。例えば、無線リンクプロトコルＲＬＰに関連して、最も簡単な解決策は、高い容量のトラフィックチャンネル区分から受け取ったＲＬＰフレームの１つのＲＬＰ窓を記憶できるようにデータバッファを設計することである。この解決策は、ある環境のもとでは作用するが、多数の欠点を伴う。１）長いバッファ動作は、送信端のＲＬＰ再送信タイマーをデータセッションの始めの交渉において充分に長い値にセットしない限り、そのタイマーの時間切れを生じるような遅延を招く。２）一方、不必要な再送信を防止するに充分な長い値に再送信タイマーの時間切れが交渉された場合は、再送信タイマーが時間切れするときにフレームの再送信に基づく実際のエラー修正が低速になる。これは、再送信されたフレーム（及び最初に送信されたフレーム）をＬＥＳの再送信待ち行列にまだ留めておかねばならないときに更に低速化を招く。３）ベースステーション又は衛星システムのＬＥＳに付加的なメモリ容量が必要とされる。４）この問題は、高いレートのマルチチャンネル接続が使用されるときに最悪となる。このような場合には、ＲＬＰ窓を大きくすると、長いデータバッファ及び長い再送信タイマーが必要となる（接続にわたるチャンネルの個数に基づき８倍の長さまで）。マルチチャンネル接続の場合には、この問題は、マルチチャンネル接続の無線インターフェイス容量がベースステーション又は地上の地球ステーションとＰＬＭＮの他部分との間の送信チャンネル容量よりも大きい場合に、他の方向（ＭＳからネットワークに向かう）にも生じることがある。それ故、本発明の好ましい実施形態では、上記データバッファの状態が監視され、そしてデータ送信プロトコル、例えば、送信者と受信者との間で動作する無線リンクプロトコルが中断され、ＲＬＰ流れコントローラがＲＬＰ送信者に向かって作動化される。換言すれば、データバッファは、高い容量のトラフィックチャンネル区分から受け取ったデータをバッファし、そして低い容量のトラフィックチャンネルによりサポートされるデータレートでそのトラフィックチャンネルへデータを送信するよう構成される。通常のモードにおいては、ＲＬＰフレームは、データバッファを通して変更なしに送られる。データバッファが所定のスレッシュホールド値まで充満した場合には、データバッファを制御するユニット、例えばベースステーション又は衛星システムのＬＥＳは、送信者と受信者との間の無線リンクプロトコルを中断し、そしてＲＬＰ流れコントロールモードを開始する。これは、「受信者非レディ（ＲＮＲ）」無線リンクプロトコルフレームを送信者に向かって送信することにより達成される。送信者は、流れコントロールモードがアクティブであるときにＲＬＰフレームの送信を停止する。このような場合には、データバッファにはそれ以上のフレームが受け取られず、低い容量のトラフィックチャンネルにより可能となるレートでデータバッファは空になる。一方、流れコントロールモードがアクティブであるときは、おそらく受信者から得られる「受信者レディ（ＲＲ）」フレームを送信者へ送ることができない。というのは、これが流れコントロールモードを打ち消すからである。データバッファを制御するユニットは、考えられるＲＲフレームをＲＮＲフレームに変換し、ＲＬＰフレームの確認手順が妨げられないようにしなければならない。又、データバッファを制御するユニットは、受信者から送信者へ送信されたＲＬＰフレームを監視し、フレームの確認状態に従うと共に、受信者が他の何らかの理由でＲＮＲフレームを送信するかどうか検出する。データバッファが低いスレッシュホールド値まで空になったときには、データバッファを制御するユニットは、受信者がＲＮＲフレームを送信しそしてこれがその後のＲＲフレームを打ち消していないかどうかチェックする。受信者によって開始されたこのようなＲＮＲモードがアクティブでない場合には、データバッファを制御するユニットは、受信者と送信者との間のＲＬＰプロトコルに再び介入し、そして送信者へＲＲフレームを送信し、即ちＲＬＰ流れコントロールモードを打ち消す。受信者が開始したＲＮＲモードがアクティブである場合には、データバッファを制御するユニットは、ＲＬＰプロトコルを中断せず、その後の全てのＲＲフレームを受信者から送信者へ通過させるように準備する。本発明は、接続の異なる区分が異なるデータ送信容量を有しそしてこの非均一なトラフィックチャンネル全体にわたりエラー修正プロトコルが使用されるような非均一なトラフィックチャンネルにおけるレート適応の問題を克服する。又、本発明は、僅かにしか維持できないバッファを使用するが、そのバッファの充満レベルを監視しそして必要に応じて送信端において流れコントロールモードを開始することにより、トラフィックチャンネル区分のインターフェイスにおけるデータの過剰な累積を防止する。図面の簡単な説明以下、添付図面を参照し、本発明の好ましい実施形態を詳細に説明する。図１は、データ送信のためのＧＳＭ推奨勧告に基づく構成を示すブロック図である。図２は、ＲＬＰフレームの構造を示す図である。図３は、ＲＬＰフレームのヘッダのフォーマットを示す図である。図４は、インマルサットＰ衛星システムがベースステーションシステムとしてＧＳＭベースの移動システムにいかに接続されるかを示すブロック図である。図５は、本発明によるバッファ装置を示す機能的ブロック図である。図６は、図５のバッファ装置の動作を説明するフローチャートである。好ましい実施形態の詳細な説明本発明は、送信レートの異なる２つ以上の区分より成るトラフィックチャンネル全体にわたりデータを送信するのに適用することができる。本発明の好ましい実施形態は、ＧＳＭベースの移動システムと、これに「ベースステーションシステム」として接続されたインマルサットＰ衛星システムとの間の相互作用を一例として用いることにより説明する。しかしながら、本発明は、これらのシステムに限定されるものではない。ＧＳＭ移動システムの構造及び動作は、当業者に良く知られており、ＥＴＳＩ（ヨーロピアン・テレコミュニケーションズ・スタンダーズ・インスティテュート）のＧＳＭ仕様書に規定されている。又、Ｍ．モーリ及びＭ．ポーテット著の「移動通信用のＧＳＭシステム(GSM System for Mobile Communication)」（パライゼウ、フランス、１９９２年、ＩＳＢＮ：２−９５０７１９０−０−７）も参照する。ＧＳＭベースの移動システムは、ＤＣＳ１８００（デジタルコミュニケーションシステム）及びＵＳデジタルセルラーシステムＰＣＳ（パーソナルコミュニケーションシステム）を含む。データ送信のためのＧＳＭ推奨勧告に基づく構成が図１に示されている。ＧＳＭ移動システムの基本的な構造が図１に示されている。ＧＳＭ構造体は、２つの部分、即ちベースステーションシステムＢＳＳと、ネットワークサブシステムＮＳＳとを備えている。ＢＳＳ及びＭＳは、無線接続を経て通信する。ＢＳＳにおいては、各セルは、ベースステーションＢＴＳ（図示せず）によりサービスされる。多数のベースステーションがベースステーションコントローラＢＳＣ（図１には示さず）に接続され、その機能は、ＢＴＳにより使用される無線周波数及びチャンネルを制御することである。ＢＳＳは、ＭＳＣに接続される。幾つかのＭＳＣが、公衆交換電話ネットワークＰＳＴＮ及びＩＳＤＮのような他のテレコミュニケーションネットワークに接続される。ＧＳＭシステムにおいては、ＭＳのターミナル適応機能ＴＡＦと移動ネットワーク（通常はＭＳＣ）のＩＷＦとの間にデータ接続が確立される。ＧＳＭネットワークに生じるデータ送信では、この接続が、Ｖ．２４インターフェイスに適応されるＶ．１１０レート適応のＵＤＩコード化デジタル全二重接続である。ここに述べるＶ．１１０接続は、ＩＳＤＮ（サービス総合デジタル網）技術に対して最初に開発されたデジタル送信チャンネルであり、これは、Ｖ．２４インターフェイスに適応され、そしてＶ．２４状態（制御信号）を送信する機能を与える。Ｖ．１１０レート適応接続のＣＣＩＴＴ推奨勧告は、ＣＣＩＴＴブルーブック：Ｖ．１１０に掲載されている。Ｖ．２４インターフェイスのＣＣＩＴＴ推奨勧告は、ＣＣＩＴＴブルーブック：Ｖ．２４に掲載されている。ＴＡＦは、ＭＳに接続されたデータターミナルＴＥを、１つ又は多数のトラフィックチャンネル（ＨＳＣＳＤ）を用いて物理的接続上に確立される上記のＧＳＭＶ．１１０データ接続に適応させる。ＩＷＦは、ＧＳＭＶ．１１０データ接続をＶ．２４インターフェイスに適応させるレートアダプタと、接続がＰＳＴＮへ拡張されるかＩＳＤＮへ拡張されるかに基づいてデータモデムか又は別のレートアダプタとを備えている。ＩＳＤＮ又はＰＳＴＮにおいては、データ接続が、例えば、別のＴＥに確立される。ＭＳとＴＥとの間のＶ．２４インターフェイスは、ここでは、ターミナルインターフェイスと称する。又、ＩＳＤＮ又はＰＳＴＮにおいては、ＩＷＦ及び他のＴＥに対応するターミナルインターフェイスが配置される。ＧＳＭトラフィックチャンネルは、ユーザレート２４００、４８００、７２００及び９６００ビット／ｓのデータ送信をサポートする。将来は、無線インターフェイスに２つ以上のトラフィックチャンネルを使用する（マルチスロットアクセス）高速データサービス（ＨＳＣＳＤ＝高速回路切り換えデータ）が、更に高いユーザレート（１４４００ビット／ｓ、１９６００ビット／ｓ・・・）もサポートする。トラフィックチャンネルは、送信エラーの影響を減少する目的でチャンネルコード化を使用する。チャンネルコード化及び種々のオーバーヘッド情報は、無線インターフェイスのビットレートを実際のユーザレート以上に増加させる。２４００、４８００及び９６００ビット／ｓのユーザレートに対応する無線インターフェイスレートは、各々、３６００、６０００及び１２０００ビット／ｓである。又、非透過的データサービスは、ＭＳとＩＷＦとの間に無線リンクプロトコルＲＬＰを使用している。ＩＷＦは、典型的に、ＭＳＣに配置される。ＲＬＰは、ＧＳＭ推奨勧告０４．２２に規定されたフレーム構造化平衡型（ＨＤＬＣ型）のデータ送信プロトコルである。より詳細には、データは、図２のＲＬＰフレームにおいてＴＡＦとＩＷＦとの間に送信される。図３は、ヘッダフィールドのフォーマットを示す。ヘッダのパラメータは、ＧＳＭ推奨勧告０４．２２に規定されている。ＲＬＰフレームは、ヘッダ（１６ビット）と、情報フィールド（２００ビット）と、フレームチェックシーケンス（ＦＣＳ）（２４ビット）とで構成される２４０ビットの固定長さを有する。ＲＬＰにおけるエラー修正は、トラフィックチャンネルにおいて崩壊したフレームであって受信者により要求されるフレームを再送信することに基づいている。それ故、送信されたＲＬＰフレームは、受信端から確認が受け取られるまで送信端に記憶される。送信端が確認を受け取らないか又は否定確認を受け取る場合には、送信端が送信を所定の回数だけ繰り返す。再送信の回数は、非常に悪い接続によるエンドレスな送信ループが回避されるようにパラメータＮ２によって制限される。ＲＬＰフレームの送信は、手前の送信からプリセット時間Ｔ１が経過したときに繰り返される。送信端に必要とされるバッファの量を減少するために、スライド窓が確認のために使用される。これは、受信者から確認が必要とされるまで送信者が多数のフレームを送信できることを意味する。それ故、ＲＬＰ窓は、既に送信されたがまだ確認されていないフレームのスライドグループを表す。窓のサイズ（フレーム数）は、パラメータＷにより決定される。ＲＬＰの当事者は、セッションの開始時にパラメータＮ２、Ｔ１及びＷＳの値を交渉する。又、ＲＬＰプロトコルは、ＴＡＦ及びＩＷＦにおける送信及び受信バッファの充満レベルを調整するのに使用される流れコントローラも備えている。この流れコントローラは、例えば、ＧＳＭ推奨勧告０７．０２に規定されている。ＲＬＰ受信者（ＴＡＦ又はＩＷＦ）は、無線経路からの受信バッファが所定のスレッシュホールド値に到達するか、又はＴＥがターミナルインターフェイスにおいてローカルの流れ制御を開始した場合に、送信者（ＩＷＦ又はＴＡＦ）に「流れコントロールアクティブ」指示を直ちに送信する。後者の場合に、ＴＡＦは、ターミナルインターフェイスからこの流れコントロール指示を受け取ると、受信バッファからターミナルインターフェイスへのデータ送信を中断する。バッファディスエイブルモード又はローカル流れコントローラが除去されたときには、ＴＡＦ／ＩＷＦは、「流れコントロールインアクティブ」指示を送信する。又、受信バッファからのデータ送信が再作動される。送信者は、送信バッファが所定のスレッシュホールド値に到達するか、又は受信者から「流れコントロールアクティブ」指示を受け取ったときに、ローカル流れコントローラを直ちに作動する。バッファディスエイブルモードが終了するか又は「流れコントロールインアクティブ」指示が受け取られたときに、ＩＷＦ／ＴＡＦは、ローカル流れコントローラを除去する。送信バッファは、ＭＳが無線経路を経てデータを直ちに送信できない場合にデータが失われないように、Ｖ．２４インターフェイスから受け取ったデータをバッファする。受信バッファは、トラフィックチャンネルから受け取ったデータを、Ｖ．２４インターフェイスを経て例えばＴＥに直ちに送信できない場合にそれが失われないように、Ｖ．２４インターフェイスへ送信されるデータをバッファする。流れコントローラを作動する上記所定のスレッシュホールド値は、例えば、送信又は受信バッファが半分満たされるというものである。「流れコントロールアクティブ」指示は、ヘッダフィールドに「ＲＮＲ（受信者非レディ）」コード即ちビットＳ１Ｓ２＝１０を含むＲＬＰフレームである。このフレームはＲＮＲフレームと称する。「流れコントロールインアクティブ」指示は、ヘッダフィールドに「ＲＲ（受信者レディ）」コード、即ちビットＳ１Ｓ２＝００を含むＲＬＰフレームである。このフレームは、ＲＲフレームと称する。図４において、インマルサットＰ衛星システムは、ベースステーションシステムとしてＧＳＭベースの移動システムに接続される。インマルサット衛星システムにおいては、無線有効到達範囲が、地上に配置されたベースステーションではなくて、衛星により得られ、衛星は、地球を回る軌道上にあり、そしてＭＳ（又はユーザターミナルＵＴ）とＬＥＳとの間に無線信号を送信する。衛星のビームは、地球上に有効到達エリア即ちセルを形成する。個々の衛星の有効到達エリアは、ＭＳが常に少なくとも１つの衛星の有効到達エリア内に位置するような連続的な有効到達範囲を形成するよう構成される。必要とされる衛星の数は、所望の有効到達範囲によって左右される。地表面における連続的な有効到達範囲は、例えば、１０個の衛星を必要とする。図４は、明瞭化のため、１つのＬＥＳ、１つの衛星ＳＡＴ及び１つのＭＳのみを示す。ＬＥＳは、図１のＢＳＳと同様にＧＳＭネットワークのＭＳＣに接続される。又、ＭＳＣとＬＥＳとの間のＧＳＭプロトコルは、図１のＭＳＣとＢＳＳとの間と同一である（ＧＳＭＶ．１１０）。ターミナルインターフェイスも、図１と同一である。相違点は、図４において、ＭＳＣとＭＳとの間の全接続にわたりＧＳＭＶ．１１０接続が使用されるのではなく、ＬＥＳとＭＳとの間の無線インターフェイスがインマルサットプロトコル及びトラフィックチャンネルを使用することである。無線インターフェイスは、ＭＳとＬＥＳとの間の両方向性衛星無線接続より成る。衛星システムのユニットＳＡＴ、ＬＥＳ及びＭＳの厳密な構造及び動作、或いは無線インターフェイスの正確な仕様は、本発明に関わりない。本発明は、実際の衛星システムに何ら変更を必要とせず、その詳細は、インマルサット仕様から得ることができる。本発明にとって重要な唯一の特徴は、無線インターフェイスにわたって形成されるトラフィックチャンネルの容量である。換言すれば、インマルサットＰシステムでは、トラフィックチャンネルの最大データレートが、４８００ビット／ｓであり、一方、ＧＳＭネットワーク区分では、トラフィックチャンネルの最大データレートが１２０００ビット／ｓである。それ故、ＴＡＦとＩＷＦとの間の端−端トラフィックチャンネルは、非均一であり、上記問題、即ちＬＥＳにおけるデータの累積を生じる。又、トラフィックチャンネルが非均一であり、即ちトラフィックチャンネルの容量が無線インターフェイスにおいてネットワークの他の部分とは異なるような他のシステムにおいても、同様の問題が生じる。これは、本発明によれば、異なる容量のトラフィックチャンネル区分のインターフェイスに位置した衛星システムのＬＥＳ又は無線システムのＢＴＳのようなネットワークユニットに、必要なレート適応を与えるデータバッファを設けることにより克服される。このデータバッファの使用の程度は、送信者と受信者との間で動作する端−端ＲＬＰプロトコルを用いることによって監視されそして調整される。これは、バッファがいっぱいであるときはＲＮＲフレームによりＲＬＰ送信者の方向にＲＬＰデータ流コントローラを作動し、そしてバッファが空であるときはＲＲフレームによりデータ流コントローラの作動を削除することにより実行される。本発明は、ＩＷＦ及びＴＡＦのようなＲＬＰユニットにいかなる変更も必要としないことに注意されたい。それ故、これらのユニットの厳密な実施は、本発明にとって重要ではなく、ここでは詳細に説明しない。むしろ、本発明は、ＲＬＰプロトコル即ちデータ流コントローラの既存の特徴を利用する。本発明によるデータ流コントローラは、ＲＲ及びＲＮＲフレームの新たな形式の使用に完全に基づくものである。送信及び受信ＲＬＰユニットは、端−端プロトコルの中断及びトラフィックチャンネル上のフレームの使用に気付かない。むしろ、プロトコルに基づいてそれらの間で直接フレームを交換するものと仮定する。それ故、本発明を理解しそして実施するためには当事者間に位置するネットワークユニットにより実行される本発明による動作を説明するだけでよかろう。図５は、衛星システムのＬＥＳにおける本発明の実施を示している。図５は、本発明にとって重要な機能的ブロックのみを示している。図５において、ダウンリンク方向は、ＩＷＦからＴＡＦへの送信方向であり、そしてアップリンク方向は、その逆方向である。ＬＥＳは、１２０００ビット／ｓのレートを有するＧＳＭトラフィックチャンネルを経てＩＷＦからＲＬＰフレームを受信するデータバッファ５１を備えている。このデータバッファ５１は、受信したＲＬＰフレームをバッファし、４８００ビット／ｓのレートでインマルサットＰトラフィックチャンネルを経てＴＡＦへそれらを送信する。又、ＬＥＳは、本発明による方法でデータバッファ５１の充満レベルを調整するデータバッファモードコントローラも備えている。又、ＬＥＳは、フレームを監視しそして処理するためのユニット５３も備え、このユニットは、４８００ビット／ｓのレートでＴＡＦからアップリンクＲＬＰフレームを受信する。このユニット５３は、フレームの形式に関する情報をコントローラユニット５２へ送り、そして以下に詳細に述べるように、フレームを１２０００ビット／ｓのレートでＩＷＦへ、そのような形態又は変形形態で送信する。図５の装置の動作を、図６を参照して以下に説明する。図６は、データバッファ５１のモード制御においてユニット５２の動作を説明するフローチャートである。先ず、データバッファ５１には、そのデータバッファの充満レベルを規定する高スレッシュホールド値ＴＨＲＥＳＨ１及び低スレッシュホールド値ＴＨＲＥＳＨ２が与えられると仮定する。各スレッシュホールド値は、例えば、データバッファにおけるＲＬＰフレームのプリセット数に対応する。又、データバッファ５１は、通常の動作モードにあると仮定する。換言すれば、データバッファの充満レベルは、ＴＨＲＥＳＨ１とＴＨＲＥＳＨ２との間にあり、そして本発明によるデータ流コントローラはアクティブでない。図６を参照すれば、コントローラユニット５２は、ＴＡＦがＩＷＦへ送信するアップリンクＲＬＰフレームを監視する。より詳細には、フレーム監視及び処理ユニット５３、例えば、バッファ記憶装置は、フレームを捕獲し、フレーム番号を読み取り、そしてフレーム番号をコントローラユニット５２へ送る。コントローラユニット５２は、確認された最新のフレーム番号をそのメモリに記憶する。このように、コントローラユニット５２は、フレームの確認状態を監視することができる。又、コントローラユニット５２は、データバッファ５１の充満レベルも監視する（ステップ６３及び６４）。バッファの充満レベルが高いスレッシュホールド値ＴＨＲＥＳＨ１に到達しない場合には、プロセスは、ステップ６４からステップ６２へ戻る。データバッファ５１がスレッシュホールド値ＴＨＲＥＳＨ１まで充満した場合には、コントローラユニット５２がＴＡＦとＩＷＦとの間のＲＬＰプロトコルに介入し、そしてＩＷＦのデータ流コントローラを作動させる。これは、コントローラユニット５２が、確認された最新のフレーム番号を含むＲＮＲフレームをＩＷＦに送信するようにフレーム監視及び処理ユニット５３に指令するように行われる。ＩＷＦは、ＲＮＲフレームを受信すると、データフレームをダウンリンク方向にデータバッファ５１へ送信するのを停止し、そしてＧＳＭ推奨勧告０７．０２に基づいてローカルデータ流コントローラを作動させる。しかしながら、データバッファ５１は、ＲＬＰフレームをダウンリンク方向にＴＡＦへ送信し続け、その結果、データバッファは徐々に空になる。これと同時に、ＴＡＦは、ＲＬＰプロトコルに基づきＲＬＰフレームをアップリンク方向に送信し続ける。エラー状態を回避するために、コントローラユニット５２は、アップリンクフレームがＲＲフレームを含むかＲＮＲフレームを含むか監視しなければならない。このため、フレーム監視及び処理ユニット５３は、コントローラユニット５２が各アップリンクフレームを分析しそしておそらくそれを変更するまで、そのアップリンクフレームをバッファする。コントローラユニット５２は、アップリンクフレームがＲＲフレームであることを検出すると（ステップ６６）、フレームをＲＮＲフレームに変換し（ステップ６７）そしてＲＮＲフラグをリセットする（ステップ６８）。フレーム形式のこの変換の目的は、データバッファ５１が充分に空になる前にＲＲフレームがＩＷＦのローカルデータ流コントローラを排除するのを防止するためである。次いで、ステップ７１へ進む。ステップ６６の分析の結果、アップリンクフレームがＲＲフレームでない場合には、コントローラユニット５２は、ステップ６９において、それがＲＮＲフレームであるかどうか分析する。フレームがＲＮＲフレームである場合には、コントローラユニット５２によってメモリに維持されたＲＮＲフラグがセットされる（ステップ７０）。ＲＮＲフラグは、ＴＡＦ自体がＲＮＲフレームを送信してＩＷＦのローカル流れコントローラを作動させたことを指示する。ＲＮＲフレームは、ステップ６８において次のＲＲフレームがそれをリセットするまでセットされる。プロセスは、ステップ７０からステップ７１へ進む。又、アップリンクフレームがＲＮＲフレームでない場合は、ステップ６９の直後にステップ７１に続く。ステップ７１では、コントローラユニット５２のメモリのフレーム番号が更新され、そしてアップリンクフレームがＩＷＦへ送られる。ステップ７２において、コントローラユニット５２は、データバッファ５１の充満レベルが低いスレッシュホールド値ＴＨＲＥＳＨ２まで減少したかどうかチェックする。もしそうでなければ、プロセスは、ステップ６６へ復帰する。もしそうであれば、ステップ７３において、ＲＮＲフラグがセットされたかどうかチェックする。もしそうでない場合には、確認された最新のフレーム番号が設けられたＲＲフレームがＩＷＦへ送られる（ステップ７４）。これは、データバッファ５１を空にするためにコントローラユニット５２により作動されたローカルデータ流制御を終了させる。次いで、プロセスは、ステップ６２へ復帰する。ステップ７３において、ＲＮＲフラグがセットされたことが検出されると、これは、ＴＡＦがＩＷＦのローカルデータ流コントローラも作動していることを指示する。それ故、プロセスは、ステップ７３からステップ６２へ直接進み、ＴＡＦがＲＲフレームを送信するまでＩＷＦのデータ流制御が続けられる。本発明は、ダウンリンク方向に適用して以上に述べた。それに対応するレート適応が、例えば、ＨＳＣＤサービスに関連してアップリンク方向にも必要とされる。このような場合には、１つのＧＳＭトラフィックチャンネルの最大データレート１２０００ビット／ｓよりも全データレートが高くなるようなトラフィックチャンネル数を無線インターフェイスに割り当てることができる。従って、無線インターフェイスのトラフィックチャンネルは、容量の高い上記トラフィックチャンネル区分を形成し、そしてＧＳＭトラフィックチャンネルは、容量の低いトラフィックチャンネル区分を形成する。その結果、アップリンクＲＬＰフレームがＬＥＳに累積される。この問題は、ダウンリンク方向について上記したように解消される。この場合に、ローカルデータ流制御は、ＴＡＦにおいて作動され、そしてＩＷＦにより送信されるフレームが監視されそして処理される。一般に、添付図面及びそれを参照した以上の説明は、単に、本発明を例示するものに過ぎない。本発明の細部は、請求の範囲内で種々変更することができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．容量の高いトラフィックチャンネル区分と、容量の低いトラフィックチャンネル区分とを含む非均一な非透過的トラフィックチャンネル又は１組のトラフィックチャンネルを経て、送信者のテレコミュニケーション装置(IWF,TAF)と受信者のテレコミュニケーション装置(TAF,IWF)との間にフレーム構造化データ送信プロトコル(RLP)を使用してデータ送信を行うためのテレコミュニケーションシステムのレート適応装置において、このレート適応装置は、高い容量と低い容量のトラフィックチャンネル区分間のインターフェイスに配置され、そして高い容量のトラフィックチャンネル区分から受け取ったフレームを、それらが低い容量のトラフィックチャンネル区分へ送信されるまでバッファするデータバッファ(51)と、送信者のテレコミュニケーション装置(IWF,TAF)において上記データ送信プロトコルに基づきデータ流コントローラを必要に応じて作動することにより、上記データバッファ(51)の充満レベルを調整するよう構成されたデータバッファコントローラ(52,53)と、を備えたことを特徴とするレート適応装置。２．上記フレーム構造化データ送信プロトコルは、受信側のテレコミュニケーション装置(TAF,IWF)により送られた第１フレーム形式に応答して送信者のテレコミュニケーション装置(IWF,TAF)において作動されるデータ流コントローラを備え、このデータ流コントローラは、第２フレーム形式を受け取るのに応答して終了され、上記データバッファコントローラ(52)は、上記データバッファ(51)の充満レベルと、受信者が送信者へ送る確認フレームとを監視するように構成され、上記データバッファコントローラ(52)は、両テレコミュニケーション装置間の上記データ送信プロトコルに介入し、そしてデータバッファの充満レベルが第１のスレッシュホールド値(THRESH1)まで増加したときに第１フレーム形式を送信することにより送信者のテレコミュニケーション装置において上記ローカルデータ流コントローラを作動するように構成され、上記データバッファコントローラ(52)は、受信者により送られた第２フレーム形式の確認フレームを、上記ローカルデータ流コントローラがアクティブであるときにそれらを送信者へ送る前に第１フレーム形式の確認フレームに変換するように構成され、そして上記データバッファコントローラは、上記データバッファの充満レベルが第２のスレッシュホールド値に減少したときは第２フレーム形式のフレームを送信することによりデータ流コントローラの上記作動を排除するように構成された請求項１に記載のレート適応装置。３．上記データバッファコントローラは、受信者が確認フレームで確認した最新のフレーム番号を登録するように構成され、そして上記データバッファコントローラは、その登録された最新の確認番号を送信フレームに挿入して、データ流コントローラを作動又は排除するように構成された請求項２に記載のレート適応装置。４．上記データバッファコントローラは、上記データ流コントローラが上記データバッファコントローラにより作動される間に受信者が第１フレーム形式のフレームを送信しそしてこれが第２フレーム形式のフレームにより確認されない場合には、たとえデータバッファの充満レベルが上記第２スレッシュホールド値に減少しても、データ流コントローラの作動を排除しないように構成された請求項２又は３に記載のレート適応装置。５．上記テレコミュニケーションシステムは、衛星システムにより形成された無線インターフェイスを有する移動ネットワークを備え、上記衛星システムは、移動ネットワークの移動サービス交換センター(MSC) にベースステーションシステム(BSS)として接続された少なくとも１つの地上地球ステーション(LES)を備え、上記容量の高いトラフィックチャンネル区分を与える移動ネットワークのトラフィックチャンネルは、地上地球ステーション(LES )と移動サービス交換センター(MSC)との間に使用され、上記無線インターフェイスは、地上地球ステーション(LES)と移動ステーション(MS)との間に衛星中継器(SAT)を通して設けられ、上記無線インターフェイスは、上記容量の低いトラフィックチャンネル区分を与える衛星システムのトラフィックチャンネルを使用し、そして上記レート適応装置は、上記衛星システムの地上地球ステーションに配置される請求項１に記載のレート適応装置。６．上記テレコミュニケーションシステムは、衛星システムにより形成された無線インターフェイスを有する移動ネットワークを備え、上記衛星システムは、移動ネットワークの移動サービス交換センター(MSC) にベースステーションシステム(BSS)として接続された少なくとも１つの地上地球ステーション(LES)を備え、上記容量の低いトラフィックチャンネル区分を与える移動ネットワークのトラフィックチャンネル又は１組のトラフィックチャンネルは、地上地球ステーション(LES)と移動サービス交換センター(MSC)との間に使用され、上記無線インターフェイスは、地上地球ステーション(LES)と移動ステーション(MS)との間に衛星中継器(SAT)を通して設けられ、上記無線インターフェイスは、上記容量の高いトラフィックチャンネル区分を与える衛星システムの１組のトラフィックチャンネルを使用し、そして上記レート適応装置は、上記衛星システムの地上地球ステーションに配置される請求項１に記載のレート適応装置。７．上記第１及び第２のテレコミュニケーション装置は、移動ステーションのターミナル適応機能(TAF)と移動ネットワークのインターワーキング機能(IWF)を含む請求項の前記いずれかに記載のレート適応装置。８．上記データ送信プロトコルは、ＧＳＭ推奨勧告０４．２２に基づく無線リンクプロトコルのような無線リンクプロトコルである請求項７に記載のレート適応装置。９．上記ローカルデータ流コントローラは、ＧＳＭ推奨勧告０７．０２に基づく流れコントローラである請求項８に記載のレート適応装置。 10．容量の高いトラフィックチャンネル区分及び容量の低いトラフィックチャンネル区分を含む非均一な非透過的トラフィックチャンネル又は１組のトラフィックチャンネルを経て、送信者のテレコミュニケーション装置と受信者のテレコミュニケーション装置との間にフレーム構造化データ送信プロトコルを使用してデータ送信を行うためのレート適応方法において、高い容量のトラフィックチャンネル区分から受け取ったフレームを、それらが低い容量のトラフィックチャンネル区分へ送信されるまでデータバッファにバッファし、上記データバッファの充満レベルを監視し、両テレコミュニケーション装置間にデータ送信プロトコルを介在させ、そしてデータバッファの充満レベルが第１のスレッシュホールド値まで増加したときに送信者の方向にデータ送信プロトコルに基づいてデータ流コントローラを作動化し、そしてデータバッファの充満レベルが第２のスレッシュホールド値まで減少しそしてデータ流コントローラの作動が受信者により要求されないときには送信者の方向にデータ送信プロトコルに基づきデータ流コントローラを不作動化する、という段階を備えたことを特徴とする方法。