JP4519382B2 - 動的容量無線データ・チャンネルのための無線回線プロトコルの改良 - Google Patents
動的容量無線データ・チャンネルのための無線回線プロトコルの改良 Download PDFInfo
- Publication number
- JP4519382B2 JP4519382B2 JP2001500453A JP2001500453A JP4519382B2 JP 4519382 B2 JP4519382 B2 JP 4519382B2 JP 2001500453 A JP2001500453 A JP 2001500453A JP 2001500453 A JP2001500453 A JP 2001500453A JP 4519382 B2 JP4519382 B2 JP 4519382B2
- Authority
- JP
- Japan
- Prior art keywords
- sequence number
- frame
- rlp
- data bytes
- data
- 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.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
-
- 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/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for 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/1607—Details of the supervisory signal
- H04L1/1642—Formats specially adapted for sequence numbers
-
- 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
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Circuits Of Receivers In General (AREA)
Description
【０００１】
発明の背景
Ｉ．発明の分野
本発明は無線通信に関する。特に、本発明は誤り制御プロトコルに固有のオーバーヘッドを最小にするとともに無線チャンネルを介してデータを確実に送信する改良された方法及びシステムに関する。
ＩＩ．関連技術の説明
符号分割多重接続（ＣＤＭＡ）変調技術の利用は大多数のシステム・ユーザがいる通信を容易にする幾つかの技術の一つである。他の多重接続技術、例えば時分割多重接続（ＴＤＭＡ）、周波数分割多重接続（ＦＤＭＡ）、及び振幅圧伸単側帯（ＡＣＳＳＢ）のようなＡＭ変調法はこの技術分野では既知である。これらの技術は違う会社で製造された装置間で相互動作を容易にするために標準化されてきた。符号分割多重接続通信システムは、米国においては“二重モード広帯域拡散スペクトラム・セルラ・システムのための移動局−基地局互換規格（MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS）”と題し、この中にも組み入れられ、そして以後ＩＳ−９５として参照され、米国電気通信工業会ＴＩＡ／ＥＩＡ／ＩＳ−９５−Ｂにて標準化された。
【０００２】
ＩＳ−９５は当初は可変率音声フレームの伝送のために最適化された。無線電話応用では一般的であるように、二方向音声通信を支援するために、通信システムはかなり一定かつ最小のデータ遅延をもつことが望ましい。このため、ＩＳ−９５は強力な前方向誤り訂正（ＦＥＣ）プロトコル及び音声フレーム誤りにしとやかに応答するよう設計されたボコーダでもって設計される。フレーム再送信手順を必要とする誤り制御プロトコルは音声伝送に対して容認できない遅れを与え、したがってＩＳ−９５規格には立案されていない。
【０００３】
スタンドアロンＩＳ−９５規格を音声応用に理想のものに最適化するとパケット・データ応用への使用が困難になる。インターネット・プロトコル（ＩＰ）データの伝送のような、非音声応用においては、通信システムの遅延要請は音声応用におけるほど厳しくない。多分ＩＰネットワークで使用されるプロトコルで最も利用されている、伝送制御プロトコル（ＴＣＰ）においては、誤りのない伝送を保証するために実際には無限の伝送遅延が許容される。この伝送信頼性を提供するために、ＴＣＰは、一般にＩＰパケットと呼ばれる、ＩＰデータグラムの再送信を使用する。
【０００４】
ＩＰデータグラムは一般に大きすぎて単一のＩＳ−９５フレーム内に納めることができない。ＩＰデータグラムをＩＳ−９５フレームの一系列内に納めるに十分小さなセグメント（部分）に分割した後でも、ＩＳ−９５フレームの全系列は単一ＩＰデータグラムがＴＣＰに有用であるために誤りなしで受信されなければならない。ＩＳ−９５システムによくあるフレーム誤り率は単一データグラムの全セグメントの誤りのない受信確率を非常に低くする。
【０００５】
ＩＳ−９５に述べられているように、代わりのサービス・オプションは音声フレームの代わりに他の型のデータの送信を可能にする。“拡散スペクトラム・システムのためのデータ・サービス・オプション（DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS）”と題するＴＩＡ／ＥＩＡ／ＩＳ−７０７−Ａは、以後ＩＳ−７０７として参照されるが、ＩＳ−９５システムにおけるパケット・データの送信に使用される手順を記述する。
【０００６】
無線回線プロトコル（ＲＬＰ）は、“拡散スペクトラム・システムのためのデータ・サービス・オプション：無線回線プロトコル・タイプ２（DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL TYPE 2）”と題し、以後ＲＬＰ２として引用され、そして引例によりこの中に組み込まれた、ＴＩＡ／ＥＩＡ／ＩＳ−７０７−Ａ．８の中に記述されている。ＲＬＰ２はＩＳ−９５フレーム層（ｌａｙｅｒ）上で誤り制御プロトコルをフレーム再送信手順と合併する。ＲＬＰはＮＡＫに基づくＡＲＱプロトコルで知られる誤り制御プロトコルのクラスであり、この技術分野においては周知である。ＩＳ−７０７ＲＬＰは、ＩＳ−９５通信システムを介して、音声フレームの系列よりはむしろ、バイト−ストリームの送信を容易にする。
【０００７】
幾つかのプロトコル層は一般的にＲＬＰ層上に存する。ＩＰデータグラムは、例えば、ＲＬＰプロトコル層にバイト・ストリームとして与えられる前に一般にポイント−ツー−ポイント・プロトコル（ＰＰＰ）・バイト・ストリームに変換される。ＲＬＰ層は高位のプロトコル層のプロトコル及びフレーミング（ｆｒａｍｉｎｇ）を無視するために、ＲＬＰにより伝送されるデータのストリームは“特徴のないバイト・ストリーム”であると云われる。
【０００８】
ＲＬＰは当初はＩＳ−９５チャンネルを介して大きいフレームを送信する要求を満たすために設計された。例えば、５００バイトのＩＰデータグラムがそれぞれ２０バイトを収容するＩＳ−９５フレーム内で単に送信されるならば、ＩＰデータグラムは２５個の連続するＩＳ−９５フレームを満たせばよい。ある種の誤り制御層なしで、これら全２５個のフレームはＩＰデータグラムが高位のプロトコル層に有用であるために誤りなしで受信されなければならない。１％のフレーム誤り率を有するＩＳ−９５チャンネル上で、ＩＰデータグラム配送の実効誤り率は（１−（０．９９）２５）、または２２％である。これはインターネット・プロトコル・トラフィックを伝送するために使用される大抵のネットワークに較べると非常に高い誤り率である。ＲＬＰは、１０Ｂａｓｅ２イーサネット・チャンネルの代表的な誤り率に比較できるようにＩＰトラフィックの誤り率を減少させる回線層プロトコルとして設計された。
【０００９】
最近、国際電気通信連盟（ＩＴＵ）は無線通信チャンネル上における高データ率及び高品質音声サービスを提供するための方法の提案を要請した。この提案の第一は、“ｃｄｍａ２０００ ＩＴＵ−Ｒ ＲＴＴ候補提案”と題し、以後ｃｄｍａ２０００として引用されるもので、米国電気通信工業会から発行された。この提案の第二は、“ＥＴＳＩ ＵＭＩＳ地上無線接続（ＵＩＲＡ）ＩＴＵ−Ｒ ＲＴＴ候補提案”と題し、“広帯域ＣＤＭＡ”といても知られ、以後Ｗ−ＣＤＭＡとして引用されるもので、ヨーロッパ電気通信標準化協会（ＥＴＳＩ）により発行された。第三の提案は、“ＵＷＣ−１３６候補提案”と題し、以後ＥＤＧＥとして引用されるもので、Ｕ．Ｓ．ＴＧ８／１により提出された。これらの提案の内容は公開記録であり、この技術分野においては周知である。
【００１０】
ＲＬＰ２はＩＳ−９５Ｂとともに使用するため最適化され、そこではチャンネル容量から導出され、パケット・データ呼び出しの間使用される、率設定（ｒａｔｅ ｓｅｔ）が呼び出しの持続期間は本質的に固定されている。固定率設定のこの仮定に基づいて、ＲＬＰ２は再送信ＲＬＰフレームが三つの連続ＲＬＰセグメントの最大値内で送信できると仮定して設計される。三つのセグメントの一つが失われ、再送信ＲＬＰフレームの喪失をもたらす確率はＲＬＰ２の設計者により許容できると見なされた。
【００１１】
ｃｄｍａ２０００においては、しかしながら、単一ユーザに利用できるチャンネル容量、したがってパケット・データ呼び出しの間に使用される最大データ率は広くかつ急速に変えることができる。例えば、単一ｃｄｍａ２０００呼び出しの進行中には、パケット・データ・サービス・オプションにより使用される補足チャンネル容量は９．６ｋｂｐｓ（秒当たり９．６キロビット）から３０７ｋｂｐｓ以上まで変えることができる。ＲＬＰ２の単純な拡張では、再送信の間に使用される最大セグメント数はデータ率の変化に適応するに必要なだけ増やすことができる。呼び出しチャンネルの容量は呼び出しの間に減少するために、高データ率で旨く伝送されないフルレート・フレームは３０またはそれ以上の連続する低率設定ｃｄｍａ２０００セグメントに及ぶかもしれない。一またはそれ以上のこれらｃｄｍａ２０００セグメントがそのようなＲＬＰ２の単純な拡張をする高い見込みはｃｄｍａ２０００を用いる場合大抵は非実用的である。
【００１２】
ＲＬＰ２は率設定１（ＲＳ１）及び率設定２（ＲＳ２）として知られる、二つのＩＳ−９５率設定上で最小プロトコル・オーバーヘッド空間を必要とするために最適化された。ＲＬＰ２におけるＲＬＰフレーム・シーケンス番号は８ビット長で、コンピュータ処理のために理想のサイズである。ｃｄｍａ２０００において指定された率設定はＲＳ１とＲＳ２を含むから、ｃｄｍａ２０００について設計されたＲＬＰ（ＲＬＰ２０００）がＲＳ１及びＲＳ２で使用されるとき少なくともＲＬＰ２と同様に有効であることは非常に望ましい。率設定が変化するたびにＲＬＰプロトコルを切り替えることはＲＬＰ２０００に複雑さを加えるために、単一のＲＬＰ２０００プロトコルが有効にＲＳ１及びＲＳ２を支援し、そして全てのより高いｃｄｍａ２０００データ率が再同期または実質的なプロトコルの複雑さを必要としないことが望ましい。
【００１３】
発明の概要
本発明は可変容量のチャンネルを介して特徴のないバイト・ストリームの有効な送信を可能にするため性能のよいＲＬＰを設計するために使用することができる。本発明の典型的な実施例はＩＳ−９５のＲＳ１及びＲＳ２と同じ容量をもつチャンネル上で使用されるときＲＬＰ２と同様に有効である。同時に、本発明にしたがって設計された、性能のよいＲＬＰはまたｃｄｍａ２０００において指定された最大値まで及びそれを凌駕する可変チャンネル容量でデータの有効な伝送を可能にする。本発明は無線チャンネル上でバイト・ストリームの送信を用いるある通信システムに適用できる。本発明はｃｄｍａ２０００、Ｗ−ＣＤＭＡ、及びＥＤＧＥのようなシステムに適用でき、ここではバイト・ストリームは無線通信システムにより使用されるために指定されたオーバー・ザ・エア（ｏｖｅｒ−ｔｈｅ−ａｉｒ）フレーム内で搬送することができる。
【００１４】
本発明の実施例の可変率での効率はＲＬＰプロトコル・ヘッダ内で搬送されるシーケンス番号の解釈を変えることにより可能になる。ＲＬＰ２においては、シーケンス番号はフレーム番号を表すのに使用される。これはパケット・データ呼出において使用されるチャンネル容量と同様に、ＲＬＰ２には適正であり、ここからフルレート・フレーム内で搬送されるデータ・バイトの最大数は両方とも一定である。ＲＬＰ２は一バイトのフレームシーケンス数を使用し、そしてフレームは２０ミリ秒（ｍｓ）間隔で送信される。ＲＬＰ２フレームが送信中に喪失すると、喪失フレームのデータは三つの再送信セグメントに分解され、それぞれはもとの喪失フレームと同じシーケンス番号を有する。
【００１５】
広範に容量が変化するチャンネル上で使用するためＲＬＰ２を適応させようとすると、高容量チャンネル（例えば、３０７ｋｂｐｓ）上で送信されるフレームを低容量チャンネル（例えば、９．６ｋｂｐｓ）上で送信しなければならないとき困難が発生する。２０ｍｓのフレーム間隔を用いると、３０７ｋｂｐｓのチャンネル上のフルレート・フレームは７５０バイトだけのデータを搬送することができる。そのようなフレームは送信中に喪失し、そして同時にチャンネル容量は９．６ｋｂｐｓに低下することがある。ＲＬＰ２では、９．６ｋｂｐｓのフルレート２０ｍｓフレームの容量は２０バイトである。最大許容再送信セグメントの単純な拡張では、７５０バイト・データの単一フレームを首尾よく再送信することは、約３８個の連続９．６ｋｂｐｓのフルレートＲＬＰ２再送信セグメントの首尾よい送信を必要とする。全ての再送信セグメントは同じシーケンス番号をもっているから、これら３８個の再送信セグメントの一つの喪失は全体の再送信フレームの喪失をもたらすことになる。受信器は個々の再送信セグメントを否定的認知（ＮＡＫ）できない。オーバー・ザ・エア・フレーム誤り率が１％であれば、３８個の連続フルレートＲＬＰ２再送信セグメントの送信成功確率は約６８％である。この筋書きでは、セグメントの再送信はしばしば失敗することになり、ＲＬＰ２再同期によるバイト・ストリームにおけるデータ喪失および中断をもたらす。斯くして、そのようなＲＬＰ２の単純な拡張は高容量フルレート・フレームが低容量チャンネル上で再送信されなければならない度ごとに喪失データの起因となる。
【００１６】
さらに信頼できるデータ再送信を達成する一方法はフレーム・シーケンス番号の代わりにＲＬＰヘッダ内のバイト・シーケンス番号を用いることである。チャンネル容量の減少により密接に従う大きな高率ＲＬＰの喪失に際して、喪失フレーム中のデータは小さな独立したＲＬＰ再送信フレームに分割することができる。受信器は誤りなしで３８個の連続再送信フレームを受信する必要はない。受信器は旨く受信したどの再送信フレームでも受取り、ある喪失再送信フレームを単純に否定的認知（ＮＡＫ）することができる。さらにオーバー・ザ・エア・フレーム誤りが１％であることを用いると、列内で同じセグメントが二度喪失する確率は０．０１％になる。
【００１７】
フレーム・シーケンス番号の代わりにバイト・シーケンス番号を用いる一欠点は同じデータを表すためにバイト・シーケンス番号における非常に多くのビット数である。９．６ｋｂｐｓフルレートＲＬＰ２フレーム内でバイト・シーケンス番号を使用すれば、シーケンス番号は８ビットフレーム・シーケンス番号より５ビット長くしなければならない。ｃｄｍａ２０００においては、チャンネル容量が９．６ｋｂｐｓからその容量の３２倍（約３０７ｋｂｐｓ）まで変化し、フルレート３０７ｋｂｐｓフレームは７５０ＲＬＰデータ・バイトだけをもつことになる。ＲＬＰ２におけると同じ２０ミリ秒の期間を追尾するに必要なバイト・シーケンス番号ビットの数は少なくとも１８ビットである。９．６ｋｂｐｓＲＬＰフレーム中に１８ビット・バイト・シーケンス番号の場所を空けるために、フレームは二少ないデータ・バイト、即ち１０％の減少、をもつことが可能になる。
【００１８】
発明の実施例は大多数のオーバー・ザ・エア・フレーム内のシーケンス番号ビットの一部を送信すると同時に大きなバイト・シーケンス番号の利益を提供する。発明の一実施例において、２０ビット・バイト・シーケンス番号が受信データを追尾するために使用される。シーケンス番号で追尾されるバイト数はシーケンス番号空間（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ ｓｐａｃｅ）と呼ばれる。２０ビットシーケンス番号の場合は、シーケンス番号空間の大きさ（サイズ）は２２０である。
【００１９】
平均フレーム・ヘッダの大きさに加えないで大きなシーケンス番号の利益を得ることは、送信データ・バイトに割り当てられないシーケンス番号空間の部分を注意深く選択することにより達成される。言い換えれば、幾つかのシーケンス番号空間は実際の送信バイトを追尾するために使用されず、消費されたものと見てよい。選択されたシーケンス番号の大きさは、シーケンス番号空間の消費がプロトコルの動作に影響しないで許容されるように選択される。例えば、１８ビット・シーケンス番号が３０７ｋｂｐｓチャンネル上で５秒の送信喪失を耐えるに必要であれば、２０ビット・シーケンス番号の使用は送信損失の最大許容長に影響しないで未使用のため４分の３のシーケンス番号空間を許容する。
【００２０】
シーケンス番号空間の未使用部分は各々の新しい送信データ・フレームの最初（ｆｉｒｓｔ）のバイトが、ページ・サイズと呼ばれる所定の距離で、前のデータ・フレームの最初のバイトから始まるように選択される。例えば、フレームｎ内の最初のバイトが１０００のシーケンス番号を有し、ページ・サイズが１００であれば、フレームｎ＋１の最初のバイトは次のページ上で１１００のシーケンス番号で始まる。フレームｎが１０００から１０３９の数の４０バイトを収容するのみであれば、１０４０から１０９９までのシーケンス番号空間は未使用になる。シーケンス番号空間の見かけの消費を許容する動機はフレーム内で送信されるシーケンス番号のビット・サイズの減少を許容する。今ここで示した例において、シーケンス番号はフレームに挿入する前に１００で分割することができ、したがって少なくとも６少ないビットにより表すことができる。発明の好ましい実施例において、ページ・サイズは、シーケンス番号のコンピュータ・ソフトウェア操作を容易にするため、６４といった２の累乗である。
【００２１】
高率フレーム中の７５０データ・バイトが喪失するという、前に述べた筋書きにおいて、発明の好ましい実施例は高容量及び低容量チャンネル上の再送信に同様に容易に適応する。高容量チャンネルでは、データは一または二再送信フレーム中で容易に送信される。しかしながら、チャンネルの容量が減少すれば、再送信されるべきデータ・バイトは幾つかの独立した再送信フレームに分割され、各々はそれ自身のシーケンス番号を持つ。独立再送信シーケンス番号の使用はＲＬＰ２により指定されたセグメント化再送信に有利である。単一ＲＬＰ２再送信セグメントが送信中に喪失すると、同じシーケンス番号をもつ全てのセグメントは喪失セグメントのデータを回復させるために再び再送信しなければならない。逆に、独立の番号がついた一またはそれ以上の再送信フレームが送信中に喪失すると、受信器は個々の喪失フレームを否定的認知（ＮＡＫ）することができる。第二のＮＡＫを受信した後で、送信器は二度目に個々の再送信フレームを送信することができる。さらに１％のオーバー・ザ・エア・フレーム誤りを用いると、列内で同じ再送信フレームが二度喪失する確率は０．０１％である。ＲＬＰ再同期、及びその付随データ喪失及びバイト・ストリーム不連続性は殆ど必要ない。
【００２２】
フレームの代わりにバイトに対応するシーケンス番号を用いる一つの欠点は多くのビットがシーケンス番号を表すのに一般に必要なことである。これは喪失フレームのデータを搬送するために必要な独立番号のついた再送信フレームの数に僅かな増加をもたらす。しかしながら、発明の典型的な実施例においては、この影響はシーケンス番号から最上位ビットと最下位ビットを時々省略することにより最小化される。
【００２３】
本発明の特徴、目的、および長所は、同様な参照符号が全体にわたり対応して同一である図面と関連して取られる以下に始まる詳細な記述からさらに明らかになるであろう。
【００２４】
好ましい実施例の詳細な説明
図１はシーケンス番号空間が発明の実施例に如何に使用されるかを示す。送信されるべき新しいデータはフルレートＲＬＰフレーム１４０中に置かれる。ＲＬＰフレーム１４０内にはシーケンス番号１５０及びデータ１００がある。送信されるべき新しいデータ１０２はフルレートＲＬＰフレーム１４２中に置かれる。ＲＬＰフレーム１４２内にはシーケンス番号１５２及びデータ１００がある。
【００２５】
新しいデータ１０４がフルレートＲＬＰフレームについて最大値より少ないバイトを有していれば、非フルレートＲＬＰフレーム１４４中に置かれる。ＲＬＰフレーム１４４内にシーケンス番号１５４及びデータ１０４だけでなく、データ長１６４もある。ＲＬＰ２と同様に、発明のこの実施例はより小さいＲＬＰフレームを搬送するために、所定のチャンネル容量、例えば９６００ｂｐｓにおけるハーフレート・フレーム内で低率フレームの使用を許容する。
【００２６】
発明の典型的な実施例において、各シーケンス番号はＲＬＰフレーム中のデータの最初（ｆｉｒｓｔ）のバイトに対応する。ＲＬＰフレーム内で搬送されるシーケンス番号はＲＬＰシーケンス番号と呼ばれる。
【００２７】
三つのＲＬＰフレーム１４０、１４２、及び１４４中で送信されるデータ１００、１０２、及び１０４はシーケンス番号空間１１０に存在する。発明の典型的な実施例において、シーケンス番号はバイト・シーケンス番号であり、左の低い値から右の高い値に連続して進行する。本実施例において、シーケンス番号は使用されるか飛び越されるかのいずれかなので、シーケンス番号は単調に増加する。所定のシーケンスの最大シーケンス番号値に達すると、シーケンス番号は再びゼロで始まる。
【００２８】
データ・バイト１０２はＲＬＰフレーム１４２中へ置かれるので、それらはシーケンス番号１２６のブロックから連続バイト番号を各々割り当てられる。典型的な実施例では、ブロック１２６の最初のバイトは前のＲＬＰフレームを送信するために使用されるブロック１２２の最初のバイトから所定数の距離１３４ａにある。この所定距離はページ・サイズと呼ばれ、所定距離内のシーケンス番号は一纏めにしてページと呼ばれる。データを送信するために使用されるシーケンス番号ブロックはページの先頭から常に始まる。例えば、シーケンス番号ブロック１２２はページ１３４ａの先頭から始まり、シーケンス番号ブロック１２６はページ１３４ｂの先頭から始まり、シーケンス番号ブロック１３０はページ１３４ｃの先頭から始まる。ページの先頭で新しいフレームを常に始めることの一つの副効果はページの末端、例えば１２４、１２８、及び１３２でのシーケンス番号のブロックを送信されるデータ・バイトに割り当てなくてもよいということである。
【００２９】
発明の典型的な実施例において、短縮ＲＬＰシーケンス番号が使用され、それはページ・サイズで分割したＲＬＰフレーム中の最初のデータ・バイトのバイト・シーケンス番号に等しい。短縮ＲＬＰシーケンス番号を表すために必要なビット数は実際のバイト系列番号を表すために必要なビット数より少ない。
【００３０】
発明の別の実施例において、省略によりどのデータがＲＬＰフレームのデータ部分に含まれるか曖昧にならないとき最上位ビットがバイト・シーケンス番号から省略される。例えば、２０ビットのバイト・シーケンス番号が使用され、しかし２１６バイト以下が顕著（明らかに、または暗に認知されない）であれば、バイト・シーケンス番号の最上位４ビットはＲＬＰシーケンス番号中で送信する必要はない。これらの４最上位ビットはフレーム中に含まれるバイトのシーケンス番号に曖昧さをもたらすことなくＲＬＰシーケンス番号から安全に省略される。
【００３１】
シーケンス番号の短縮はシーケンス番号から最上位ビットの番号を書略するものとして描かれているけれども、この技術分野に熟達するものは現発明から逸脱することなしに同じ結果がシーケンス番号にモジュロ関数を作用させることにより得られることを認識している。
【００３２】
しかしながら、２１６バイト以上が顕著であれば、顕著なデータバイトの一以上は同じ短縮ＲＬＰシーケンス番号を有するかもしれない。発明の典型的な実施例において、そのようなデータ・バイトをもつ再送信フレームは完全な２０ビットのシーケンス番号を含む。
【００３３】
ＲＬＰフレームが否定的に認知（ＮＡＫ）され、再送信されなければならないとき、データはＲＬＰ再送信フレームに挿入され、再送信される。再送信間のチャンネル容量が十分であれば、再送信フレームは元の喪失ＲＬＰフレームと同じ大きさ（サイズ）である。再送信フレームと元のＲＬＰフレームが同じ大きさである場合には、そうすることがシーケンス番号の曖昧さをもたらさない限り、元と同じ短縮ＲＬＰシーケンス番号を使用することができる。
【００３４】
チャンネル容量が減少したとき可能なように、元の送信フレームが単一送信フレーム中に適合する以上のデータを持っていれば、元の送信フレームからのデータは幾つかのより小さな再送信フレームに分割される。各再送信フレームはそれ自身のシーケンス番号を有し、それは前に論じた方法の一つで短縮してもよいし、しなくてもよい。再送信フレームが送信中に喪失すれば、個々の再送信フレームは否定的認知（ＮＡＫ）され、その後で送信することができる。再送信フレームが否定的認知（ＮＡＫ）される前にチャンネル容量が減少するまれな場合には、第二の再送信の前に再送信フレームは同じより小さな独立した再送信フレームにさらに分割することができる。
【００３５】
この手順は、単一喪失フレームに対応する再送信セグメントが全て同じＲＬＰシーケンス番号をもつＲＬＰ２とは異なる。単一喪失再送信セグメント中のデータを回復させるために、喪失フレームのシーケンス番号をもつ全ての再送信セグメントは再び再送信しなければならない。
【００３６】
図２は、喪失ＲＬＰフレーム中のデータが幾つかのより小さなＲＬＰ再送信フレーム中で再送信されねばならないとき、発明の典型的な実施例にしたがう、バイト・シーケンス番号空間及びＲＬＰシーケンス番号の使用を示す。チャンネル容量が元のＲＬＰフレームの送信とそのデータの再送信の時間の間で減少するとき再送信バイトの分割が必要である。
【００３７】
示された例において、元の喪失ＲＬＰフレーム中のバイトを表すために使用されるシーケンス番号空間２２８は幾つかのＲＬＰ再送信フレーム２３０に分割される。シーケンス番号空間２２８はより小さな部分２２０に分割され、各々は現送信チャンネル上のフルレート・フレームの容量より少ないか、または等しい大きさ（サイズ）を有する。より小さなシーケンス番号空間部分２２０の各々に対応するデータ２００はＲＬＰ再送信フレーム２３０中へ置かれる。
【００３８】
各ＲＬＰ再送信セグメントはそのそれぞれのシーケンス番号空間２２０の最初（ｆｉｒｓｔ）のバイトに対応するＲＬＰシーケンス番号２４０を有する。例えば、シーケンス番号２４０ａはシーケンス番号空間２２０ａ中の最初のバイトを表す値を有する。各再送信フレーム２３０中のＲＬＰシーケンス番号２４０は、そうすることがシーケンス番号の曖昧さをもたらさない限り、ＲＬＰシーケンス番号について論じたと同じ方法で随意に短縮することができる。
【００３９】
各ＲＬＰ再送信フレームは随意にデータ長２５０をもつことができる。各ＲＬＰ再送信フレームにより搬送されるデータ長２５０はフレーム内のデータ・バイト２００の数を示す。例えば、データ長２５０ａは再送信フレーム２３０ａ中のデータ・バイト２００ａの数に等しい。データ長が再送信フレーム２３０の他の部分、例えば図では示されてない型の領域（ｆｉｅｌｄ）で示されれば、データ長２５０は省略することができる。
【００４０】
ＲＬＰ再送信フレームの形成はデータ２００ｎの最後の部分がＲＬＰ再送信フレーム２３０ｎの中へ置かれるまで続く。一連のＲＬＰ再送信フレームの最後はデータ・バイト２００ｎの最大数より少なく含み、したがって一般的にはデータ長２５０ｎを含む。
【００４１】
発明の好ましい実施例において、最も共通な送信フレームのＲＬＰシーケンス番号は最下位ビット及び最上位ビットを省略することにより短縮される。発明の典型的な実施例において、バイト・シーケンス番号は２０ビットを有し、６４バイトのページ・サイズが使用され、そして顕著なＲＬＰ送信フレームの数はまれに２５６を超える。
【表１】
表１は発明の好ましい実施例にしたがって使用されるＲＬＰフレーム・ヘッダの領域を示す。フレーム・ヘッダの内容は先頭、末端に置かれ、またはＲＬＰフレームのいたる所で決定論的に分散することができる。発明の好ましい実施例において、ＲＬＰフレーム・ヘッダは各ＲＬＰフレームの先頭に現れる。受信器で受信されたとき非一様なビット誤り確率がＲＬＰフレームを通して存在すれば、フレームのいたる所にヘッダの内容を分散することが望ましい。
【００４２】
いろいろな型ビット（ｔｙｐｅ ｂｉｔｓ）の番号がＲＬＰフレーム型を表すのに使用される。一纏めにして、これらの型ビットは可変ビット長型領域を形成し、それは送信されるＲＬＰフレームの型を示し、同様にＲＬＰヘッダの残りのフォーマットを示す。表１において、“フレーム型記述”欄は各型領域値に対応するフレーム型の記述を含む。“フレーム型記述”欄のフレーム型記述は議論のためにフレーム型番号と同一にしてある。“フレーム型記述”欄以外の全ての欄はＲＬＰヘッダに実際に含まれる領域を示す。
【００４３】
型領域（ｔｙｐｅ ｆｉｅｌｄ）の次にＲＬＰシーケンス番号が続く。シーケンス番号の曖昧さをもたらすことなく可能なときは、８ビットの短縮ＲＬＰシーケンス番号が使用される。別な時は、１４ビットの短縮ＲＬＰシーケンス番号または最大の２０ビットＲＬＰシーケンス番号がＲＬＰヘッダにより含まれる。
【００４４】
８ビットの短縮ＲＬＰシーケンス番号はフレーム中の最初のデータ・バイトに対応する２０ビット・バイト・シーケンス番号から生成される。２０ビット・バイト・シーケンス番号はバイト・シーケンス番号の最下位６ビット及び最上位６ビットを省略することにより８ビットの短縮ＲＬＰシーケンス番号に変換される。８ビット番号は最新のマイクロプロセッサ及びモデム・ソフトウェアで非常に容易に処理されるので、８ビットＲＬＰシーケンス番号の使用は特に有利である。発明の好ましい実施例において、改良ＲＬＰプロトコルが８ビットＲＬＰシーケンス番号で送信されるＲＬＰフレームの数を最大化するために設計されている。
【００４５】
２０ビット・バイト・シーケンス番号はバイト・シーケンス番号の最下位６ビットを省略することにより１４ビットの短縮ＲＬＰシーケンス番号に変換される。２０ビットＲＬＰシーケンス番号がＲＬＰフレーム中で送信されるべきとき、２０ビット・バイト・シーケンス番号はＲＬＰシーケンス番号中に単純に複写（ｃｏｐｙ）される。
【００４６】
発明の好ましい実施例において、最初に送信されるべきデータをもつ大方のフレームは８ビットＲＬＰシーケンス番号を使用する。これらのフレーム型は“フレーム型記述”欄の型１及び３と同じである。さらに、型２で示されているように、ＲＬＰ再送信フレームはまた８ビットＲＬＰシーケンス番号を使用できる。
【００４７】
フレーム型４、５，及び６は１４ビットＲＬＰシーケンス番号を含む。これらのフレームは顕著なフレームが同じ８ビットＲＬＰシーケンス番号を有する場合にはシーケンス番号の曖昧さを避けるために使用でき、そうでなければ送信されるべき次のフレームにより使用される。これらのフレームはまた否定的認知（ＮＡＫ）されたフレームからデータを再送信するのに随意に使用できる。
【００４８】
フレーム型７及び８は最大の２０ビットＲＬＰシーケンス番号を含む。これらのフレームはＮＡＫデータが少ない再送信フレーム中で再送信できる前にチャンネル容量が減少するとき使用される。
【００４９】
ここに再送信の前にチャンネル容量が減少するとき再送信フレーム型の使用の例がある。バイト・シーケンス番号１０００から１７４９をもつ、７５０バイトのデータが３０７ｋｂｐｓチャンネル上の単一ＲＬＰ送信フレームの送信の間に喪失する。受信器がＮＡＫフレームを送信器に送り返す時までに、チャンネル容量は９．６ｋｂｐｓまで低減してしまった。７５０バイトの喪失データはすぐに９．６ｋｂｐｓチャンネル上で再送信されなければならない。この筋書きを表すため図２を用いると、シーケンス番号空間２２８は１０００から１７４９の範囲にある。ＲＬＰ２の単純な拡張では、９．６ｋｂｐｓチャンネル上のフレーム型８のヘッダを用いる各再送信フレームは１５バイトのデータをもつ。例としてこれを用いると、７５０バイトの再送信データは５０ＲＬＰ再送信フレームの間に分配される。図２において、ＲＬＰ再送信フレーム２３０ｎは１０００の２０ビット・シーケンス番号とデータ長１５をもつフレーム型８のヘッダを有する。ｎ＝５０で、フレーム２３０ｎ-１は１７２０の２０ビット・シーケンス番号とデータ長１５をもつフレーム型８のヘッダを有する。フレーム型８の使用は再送信フレームと次のページの境界との間のシーケンス番号空間に割り当てられた多くのデータバイトがあることを受信器に指示する。フレーム２３０ｎは１７３５の２０ビット・シーケンス番号とデータ長１５をもつフレーム型７のヘッダを有する。末端の再送信フレームにおけるフレーム型７の使用はフレーム中の末端のバイトと次のページの境界との間のシーケンス番号空間に割り当てられたデータがないことを受信器に指示する。型７または８の何れのフレームも個々にＮＡＫ（否定的認知）され、再び再送信される。前の例の単純な改良では、フレーム型８の変形は無データ長バイトをもつヘッダ有し、フレームが１６バイトのデータをもつことを許容する。
【００５０】
フレーム型９はＲＬＰプロトコルにおける同期のために使用される制御／シーケンス・フレームをもつ。制御／シーケンス・フレームの使用は前述のＲＬＰ２に詳細に記載されている。
【００５１】
無長領域を有するフレーム・ヘッダにおいて、データ長は送信されたフレームの残余中へ適合できるバイトの最大数であると解釈される。このようにして、この中で述べられた改良ＲＬＰプロトコルは前述のＲＬＰ２またはｃｄｍａ２０００で指定されるより大きな容量を有するチャンネル中での使用のために容易に拡張できる。多くの予想される拡張において、改良ＲＬＰプロトコルの変形は新しいチャンネル容量のために便宜をはかる必要はない。
【００５２】
受信器は、この中で述べられたフォーマット中のＲＬＰフレームを受信する際、各ＲＬＰフレーム中に含まれるバイトに適用されるべき元のバイト・シーケンス番号を再生するため短縮シーケンス番号を使用する。そのＲＬＰシーケンス番号が一またはそれ以上の先立つフレームの喪失を指示するフレームが受信されるとき、受信器はＮＡＫを送信機に送信する。ＮＡＫフレームは対応するＲＬＰ再送信フレームに対応するＲＬＰシーケンス番号で使用されるべきビット数を随意に指定できる。
【００５３】
発明の好ましい実施例は２０ビットのバイト・シーケンス番号及び８、１４、及び２０ビットのＲＬＰシーケンス番号を指定するけれども、他の多くのシーケンス番号サイズの選択は現発明から逸脱することなしに行うことができる。バイト・シーケンス番号空間の最上位または最下位部分の明白な省略を可能にするＲＬＰシーケンス番号の使用は、２の累乗であるページ・サイズの選択及び８ビットの短縮ＲＬＰシーケンス番号の使用と同様、現発明の種々の実施例の目的である。
【００５４】
図３は発明の実施例にしたがってデータ・フレームを送信するために使用されるステップのフローチャートである。フレーム送信処理３０２の始まりで、送信器は新しいＲＬＰフレームまたはＲＬＰフレームを送信しなければならいかどうかを評価３０４する。この決定は喪失送信データを指定するＮＡＫフレームが以前に受信されたかどうかに基づいている。
【００５５】
送信フレームを形成する前に、送信器が送るべき新データを有するかどうかを判定３０６するため送信バッファまたはキュー（ｑｕｅｕｅ）が点検される。送信されるべきデータがなければ、アイドル・フレーム（ｉｄｌｅ ｆｒａｍｅ）が形成３０８され、送信３２６される。ＳＹＮＣ、ＡＣＫ、及びＩＤＬＥフレームの使用は前述のＲＬＰ２に詳述されている。発明の一実施例において、アイドル・フレームの空中回線容量の影響を最小にするためアイドル・フレームはより小さな低データ率オーバー・ザ・エア・フレーム中に置かれる。発明の別の実施例において、アイドル・フレームは全く送らなくてもよく、また各フレーム期間よりは少ない頻度で送ってもよい。
【００５６】
送信器が送信すべき新データを有することが判定３０６されれば、シーケンス番号の曖昧さをもたらさない８ビットＲＬＰシーケンス番号を有するフレーム中にデータがあるかどうかを送信器は評価３０８する。８ビットシーケンス番号が曖昧さをもたらさなければ、８ビットＲＬＰシーケンス番号を有するＲＬＰ送信フレームが形成３１４され、送信３２６される。送信されるべきデータ・バイトの数がフルレート・フレームの最大値より小さければ、形成３１４されたフレームはデータ長領域（ｌｅｎｇｔｈ ｆｉｅｌｄ）をもつ。送信されるべきデータ・バイトの数がフルレート・フレームの最大値より大きいか等しければ、データ・バイトの最大番号がフルレート・フレーム中に挿入３１４され、そのフレームが送信３２６される。ステップ３１２または３１４で新送信フレーム中へ挿入されたＲＬＰシーケンス番号は次の未使用ページを始めるバイト・シーケンス番号から生成される。
【００５７】
送信器がＲＬＰ再送信フレームを送信しなければならないことを送信器が判定３０４すれば、次のステップは、最大の２０ビットＲＬＰシーケンス番号が次のＲＬＰ再送信フレームで要求されるかどうかを判定３２２することである。チャンネル容量が送信と再送信との間で減少するとき可能であるのように、もともとデータを送信するために使用されるより多くのＲＬＰフレーム中で再送信されるべきデータを再送信しなければならない場合は、最大の２０ビットＲＬＰシーケンス番号が要求される。次のフレームを２０ビットＲＬＰシーケンス番号で送信しなければならない場合は、ＲＬＰ再送信フレームが形成され、データで満たされ３２４、そしてＲＬＰ再送信フレーム中の最初のデータ・バイトに対応するＲＬＰシーケンス番号で送信３２６される。２０ビットＲＬＰシーケンス番号が必要ないと送信器が判定３２２すれば、送信器は次の再送信ＲＬＰフレームについて８ビットまたは１４ビットＲＬＰシーケンス番号の使用の間を選択３１８しなければならない。一旦、要求されるシーケンス番号のビット・サイズの判定が終了３１８すると、送信器は８ビットＲＬＰシーケンス番号でＲＬＰ送信フレームを形成３２０し、または１４ビットＲＬＰシーケンス番号でＲＬＰ送信フレームを形成３１６し、フレームを送信３２６する。ケース３１６または３２０のいずれにおいても、フレームに挿入されるＲＬＰシーケンス番号はフレーム中に含まれる最初のデータ・バイトに対応するバイト・シーケンス番号から生成される。そのバイト・シーケンス番号はシーケンス番号ページの最初のバイト・シーケンス番号である。データ・サイズについて曖昧さを避ける必要があれば、再送信ＲＬＰフレームのＲＬＰヘッダはデータ長領域を含める。
【００５８】
図４は発明の実施例にしたがって受信データ・フレームからデータを取り出すために使用されるステップのフローチャートである。ＲＬＰシーケンス番号を含むＲＬＰデータ・フレームまたはアイドル・フレームを受信４０２すると、受信器はバイト・シーケンス番号を形成するために必要なものとしてＲＬＰフレームから受信ＲＬＰシーケンス番号を展開し、フレームからあるデータ・バイトを取り出す４０４。そこで、受信器はそのバイト・シーケンス番号から、データを搬送するＲＬＰフレームが喪失したかどうかを判定４０６する。
【００５９】
発明の典型的な実施例において、最も新しく（ｒｅｃｅｎｔｌｙ）受信されたＲＬＰデータ・フレームにより指示されたバイト・シーケンス番号を連続して受信された最終（ｌａｔｅｓｔ）の前データ・バイトに対応するバイト・シーケンス番号と比較することにより、喪失データの判定が行われる。例えば、再送信でない受信ＲＬＰデータ・フレームの最後のバイトは旨く受信された最終の前データ・バイトと考えられる。再送信でない受信ＲＬＰデータ・フレームから展開された、または受信ＲＬＰアイドル・フレームの、バイト・シーケンス番号が旨く受信された最終の前データ・バイトのシーケンス番号からページより大きく異なれば、一またはそれ以上の喪失ＲＬＰデータ・フレームの喪失が発生した。
【００６０】
前述のＲＬＰ２プロトコルは再送信ＲＬＰフレームの喪失の判定においてタイマー及びフレーム・カウンタの使用を述べている。この技術は現発明の実施例においても使用される。
【００６１】
データが喪失したことを判定４０６すると、受信器は喪失データの再送信を要求するためＮＡＫフレームを形成し、送信４０８する。発明の別の実施例において、旨く受信されたバイトのバイト・シーケンス番号空間の受信器の知識に基づいて、受信器は、ＮＡＫフレーム内で、再送信ＲＬＰフレーム内のＲＬＰシーケンス番号において使用されるべき低減ビット数を指定できる。
【００６２】
データが喪失しなかったことを判定４０６すると、受信器はＲＬＰアイドルまたはＲＬＰデータ・フレームを適切なものとして形成し、送信する。発明の別の実施例において、アイドル・フレームは全く送らなくてもよく、また各フレーム期間よりは少ない頻度で送ってもよい。
【００６３】
図５は発明の実施例にしたがって配置されたデータ通信システムの図である。図に示したように、送信器５０２は無線通信チャンネル５０６上で受信器５０４と通信を行う。ＲＬＰデータ・フレーム及び制御フレームはチャンネル５０６ａに沿って送信器５０２から受信器５０４へ送信され、ＲＬＰ認知またはＮＡＫ（否定的認知）はチャンネル５０６ｂに沿って受信器５０４から送信器５０２へ送信される。送信中は、送信チャンネル５０６の容量は変化し、元の送信において使用されるよりは少ない容量のチャンネル上でデータの再送信をときどき要求する。
【００６４】
例えば、大きなフルレートＲＬＰデータ・フレームはチャンネル５０６ａ上で送信器５０２により送信されるが、受信器５０４で旨く受信されないかもしれない。そのときは、受信器がチャンネル５０６ｂ上で喪失データのためにＮＡＫフレームを送信する直前または直後にチャンネル５０６の容量が低減される。そこで送信器５０２は低減容量チャンネル５０６ｂ上で再送信のために元の喪失フルレートＲＬＰデータ・フレームからのデータバイトを複数のより小さなＲＬＰフレームの中に分配しなければならない。一またはそれ以上の再送信ＲＬＰフレームが低減容量チャンネル５０６ａ上で喪失されたことを受信器５０４が判定すれば、受信器５０４はチャンネル５０６ｂ上でこれら個々の喪失再送信フレームを個々にＮＡＫ（否定的認知）する。
【００６５】
発明の典型的な実施例において、送信器５０２はメモリに接続されたプロセッサとプロセッサで処理されたバイトを無線で送信および受信するための装置を含む。プロセッサは送信装置上で送信されるべきバイト・ストリームが供給され、上文で述べた改良無線回線プロトコル（ＲＬＰ）に従って送信信号を形成する。
【００６６】
発明の典型的な実施例において、受信器５０４はメモリに接続されたプロセッサとプロセッサで処理されたバイトを無線で送信および受信するための装置を含む。プロセッサは受信装置から受信された受信データが供給され、上文で述べた改良無線回線プロトコル（ＲＬＰ）に従って送信の応答フレームを形成する。
【００６７】
先述の好ましい実施例はこの技術分野に熟達する人が本発明を為しまたは使用を可能にするために提供される。これらの実施例に対する種々の変形はこの技術分野に熟達する者には直ちに明白であり、この中に定義された一般原理は発明能力を用いることなく他の実施例に適用可能である。斯くして、本発明はこの中に示された実施例に限定されると解釈されるものではなく、この中に開示された原理及び新規な特徴と両立する広範な領域を認容すべきものである。
【図面の簡単な説明】
【図１】 発明の実施例にしたがう幾つかの新ＲＬＰフレームにおけるシーケンス番号空間とその使用を示す図である。
【図２】 発明の実施例にしたがう幾つかのＲＬＰフレームにおけるシーケンス番号とその使用を示す図である。
【図３】 発明の実施例にしたがってデータ・フレームを送信するために使用されるステップのフローチャートである。
【図４】 発明の実施例にしたがって受信データ・フレームからデータを取り出すために使用されるステップのフローチャートである。
【図５】 発明の実施例にしたがって配置されたデータ通信システムの図である。
【符号の説明】
５０２…送信器、５０４…受信器、５０６…無線通信チャンネル
発明の背景
Ｉ．発明の分野
本発明は無線通信に関する。特に、本発明は誤り制御プロトコルに固有のオーバーヘッドを最小にするとともに無線チャンネルを介してデータを確実に送信する改良された方法及びシステムに関する。
ＩＩ．関連技術の説明
符号分割多重接続（ＣＤＭＡ）変調技術の利用は大多数のシステム・ユーザがいる通信を容易にする幾つかの技術の一つである。他の多重接続技術、例えば時分割多重接続（ＴＤＭＡ）、周波数分割多重接続（ＦＤＭＡ）、及び振幅圧伸単側帯（ＡＣＳＳＢ）のようなＡＭ変調法はこの技術分野では既知である。これらの技術は違う会社で製造された装置間で相互動作を容易にするために標準化されてきた。符号分割多重接続通信システムは、米国においては“二重モード広帯域拡散スペクトラム・セルラ・システムのための移動局−基地局互換規格（MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS）”と題し、この中にも組み入れられ、そして以後ＩＳ−９５として参照され、米国電気通信工業会ＴＩＡ／ＥＩＡ／ＩＳ−９５−Ｂにて標準化された。
【０００２】
ＩＳ−９５は当初は可変率音声フレームの伝送のために最適化された。無線電話応用では一般的であるように、二方向音声通信を支援するために、通信システムはかなり一定かつ最小のデータ遅延をもつことが望ましい。このため、ＩＳ−９５は強力な前方向誤り訂正（ＦＥＣ）プロトコル及び音声フレーム誤りにしとやかに応答するよう設計されたボコーダでもって設計される。フレーム再送信手順を必要とする誤り制御プロトコルは音声伝送に対して容認できない遅れを与え、したがってＩＳ−９５規格には立案されていない。
【０００３】
スタンドアロンＩＳ−９５規格を音声応用に理想のものに最適化するとパケット・データ応用への使用が困難になる。インターネット・プロトコル（ＩＰ）データの伝送のような、非音声応用においては、通信システムの遅延要請は音声応用におけるほど厳しくない。多分ＩＰネットワークで使用されるプロトコルで最も利用されている、伝送制御プロトコル（ＴＣＰ）においては、誤りのない伝送を保証するために実際には無限の伝送遅延が許容される。この伝送信頼性を提供するために、ＴＣＰは、一般にＩＰパケットと呼ばれる、ＩＰデータグラムの再送信を使用する。
【０００４】
ＩＰデータグラムは一般に大きすぎて単一のＩＳ−９５フレーム内に納めることができない。ＩＰデータグラムをＩＳ−９５フレームの一系列内に納めるに十分小さなセグメント（部分）に分割した後でも、ＩＳ−９５フレームの全系列は単一ＩＰデータグラムがＴＣＰに有用であるために誤りなしで受信されなければならない。ＩＳ−９５システムによくあるフレーム誤り率は単一データグラムの全セグメントの誤りのない受信確率を非常に低くする。
【０００５】
ＩＳ−９５に述べられているように、代わりのサービス・オプションは音声フレームの代わりに他の型のデータの送信を可能にする。“拡散スペクトラム・システムのためのデータ・サービス・オプション（DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS）”と題するＴＩＡ／ＥＩＡ／ＩＳ−７０７−Ａは、以後ＩＳ−７０７として参照されるが、ＩＳ−９５システムにおけるパケット・データの送信に使用される手順を記述する。
【０００６】
無線回線プロトコル（ＲＬＰ）は、“拡散スペクトラム・システムのためのデータ・サービス・オプション：無線回線プロトコル・タイプ２（DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL TYPE 2）”と題し、以後ＲＬＰ２として引用され、そして引例によりこの中に組み込まれた、ＴＩＡ／ＥＩＡ／ＩＳ−７０７−Ａ．８の中に記述されている。ＲＬＰ２はＩＳ−９５フレーム層（ｌａｙｅｒ）上で誤り制御プロトコルをフレーム再送信手順と合併する。ＲＬＰはＮＡＫに基づくＡＲＱプロトコルで知られる誤り制御プロトコルのクラスであり、この技術分野においては周知である。ＩＳ−７０７ＲＬＰは、ＩＳ−９５通信システムを介して、音声フレームの系列よりはむしろ、バイト−ストリームの送信を容易にする。
【０００７】
幾つかのプロトコル層は一般的にＲＬＰ層上に存する。ＩＰデータグラムは、例えば、ＲＬＰプロトコル層にバイト・ストリームとして与えられる前に一般にポイント−ツー−ポイント・プロトコル（ＰＰＰ）・バイト・ストリームに変換される。ＲＬＰ層は高位のプロトコル層のプロトコル及びフレーミング（ｆｒａｍｉｎｇ）を無視するために、ＲＬＰにより伝送されるデータのストリームは“特徴のないバイト・ストリーム”であると云われる。
【０００８】
ＲＬＰは当初はＩＳ−９５チャンネルを介して大きいフレームを送信する要求を満たすために設計された。例えば、５００バイトのＩＰデータグラムがそれぞれ２０バイトを収容するＩＳ−９５フレーム内で単に送信されるならば、ＩＰデータグラムは２５個の連続するＩＳ−９５フレームを満たせばよい。ある種の誤り制御層なしで、これら全２５個のフレームはＩＰデータグラムが高位のプロトコル層に有用であるために誤りなしで受信されなければならない。１％のフレーム誤り率を有するＩＳ−９５チャンネル上で、ＩＰデータグラム配送の実効誤り率は（１−（０．９９）２５）、または２２％である。これはインターネット・プロトコル・トラフィックを伝送するために使用される大抵のネットワークに較べると非常に高い誤り率である。ＲＬＰは、１０Ｂａｓｅ２イーサネット・チャンネルの代表的な誤り率に比較できるようにＩＰトラフィックの誤り率を減少させる回線層プロトコルとして設計された。
【０００９】
最近、国際電気通信連盟（ＩＴＵ）は無線通信チャンネル上における高データ率及び高品質音声サービスを提供するための方法の提案を要請した。この提案の第一は、“ｃｄｍａ２０００ ＩＴＵ−Ｒ ＲＴＴ候補提案”と題し、以後ｃｄｍａ２０００として引用されるもので、米国電気通信工業会から発行された。この提案の第二は、“ＥＴＳＩ ＵＭＩＳ地上無線接続（ＵＩＲＡ）ＩＴＵ−Ｒ ＲＴＴ候補提案”と題し、“広帯域ＣＤＭＡ”といても知られ、以後Ｗ−ＣＤＭＡとして引用されるもので、ヨーロッパ電気通信標準化協会（ＥＴＳＩ）により発行された。第三の提案は、“ＵＷＣ−１３６候補提案”と題し、以後ＥＤＧＥとして引用されるもので、Ｕ．Ｓ．ＴＧ８／１により提出された。これらの提案の内容は公開記録であり、この技術分野においては周知である。
【００１０】
ＲＬＰ２はＩＳ−９５Ｂとともに使用するため最適化され、そこではチャンネル容量から導出され、パケット・データ呼び出しの間使用される、率設定（ｒａｔｅ ｓｅｔ）が呼び出しの持続期間は本質的に固定されている。固定率設定のこの仮定に基づいて、ＲＬＰ２は再送信ＲＬＰフレームが三つの連続ＲＬＰセグメントの最大値内で送信できると仮定して設計される。三つのセグメントの一つが失われ、再送信ＲＬＰフレームの喪失をもたらす確率はＲＬＰ２の設計者により許容できると見なされた。
【００１１】
ｃｄｍａ２０００においては、しかしながら、単一ユーザに利用できるチャンネル容量、したがってパケット・データ呼び出しの間に使用される最大データ率は広くかつ急速に変えることができる。例えば、単一ｃｄｍａ２０００呼び出しの進行中には、パケット・データ・サービス・オプションにより使用される補足チャンネル容量は９．６ｋｂｐｓ（秒当たり９．６キロビット）から３０７ｋｂｐｓ以上まで変えることができる。ＲＬＰ２の単純な拡張では、再送信の間に使用される最大セグメント数はデータ率の変化に適応するに必要なだけ増やすことができる。呼び出しチャンネルの容量は呼び出しの間に減少するために、高データ率で旨く伝送されないフルレート・フレームは３０またはそれ以上の連続する低率設定ｃｄｍａ２０００セグメントに及ぶかもしれない。一またはそれ以上のこれらｃｄｍａ２０００セグメントがそのようなＲＬＰ２の単純な拡張をする高い見込みはｃｄｍａ２０００を用いる場合大抵は非実用的である。
【００１２】
ＲＬＰ２は率設定１（ＲＳ１）及び率設定２（ＲＳ２）として知られる、二つのＩＳ−９５率設定上で最小プロトコル・オーバーヘッド空間を必要とするために最適化された。ＲＬＰ２におけるＲＬＰフレーム・シーケンス番号は８ビット長で、コンピュータ処理のために理想のサイズである。ｃｄｍａ２０００において指定された率設定はＲＳ１とＲＳ２を含むから、ｃｄｍａ２０００について設計されたＲＬＰ（ＲＬＰ２０００）がＲＳ１及びＲＳ２で使用されるとき少なくともＲＬＰ２と同様に有効であることは非常に望ましい。率設定が変化するたびにＲＬＰプロトコルを切り替えることはＲＬＰ２０００に複雑さを加えるために、単一のＲＬＰ２０００プロトコルが有効にＲＳ１及びＲＳ２を支援し、そして全てのより高いｃｄｍａ２０００データ率が再同期または実質的なプロトコルの複雑さを必要としないことが望ましい。
【００１３】
発明の概要
本発明は可変容量のチャンネルを介して特徴のないバイト・ストリームの有効な送信を可能にするため性能のよいＲＬＰを設計するために使用することができる。本発明の典型的な実施例はＩＳ−９５のＲＳ１及びＲＳ２と同じ容量をもつチャンネル上で使用されるときＲＬＰ２と同様に有効である。同時に、本発明にしたがって設計された、性能のよいＲＬＰはまたｃｄｍａ２０００において指定された最大値まで及びそれを凌駕する可変チャンネル容量でデータの有効な伝送を可能にする。本発明は無線チャンネル上でバイト・ストリームの送信を用いるある通信システムに適用できる。本発明はｃｄｍａ２０００、Ｗ−ＣＤＭＡ、及びＥＤＧＥのようなシステムに適用でき、ここではバイト・ストリームは無線通信システムにより使用されるために指定されたオーバー・ザ・エア（ｏｖｅｒ−ｔｈｅ−ａｉｒ）フレーム内で搬送することができる。
【００１４】
本発明の実施例の可変率での効率はＲＬＰプロトコル・ヘッダ内で搬送されるシーケンス番号の解釈を変えることにより可能になる。ＲＬＰ２においては、シーケンス番号はフレーム番号を表すのに使用される。これはパケット・データ呼出において使用されるチャンネル容量と同様に、ＲＬＰ２には適正であり、ここからフルレート・フレーム内で搬送されるデータ・バイトの最大数は両方とも一定である。ＲＬＰ２は一バイトのフレームシーケンス数を使用し、そしてフレームは２０ミリ秒（ｍｓ）間隔で送信される。ＲＬＰ２フレームが送信中に喪失すると、喪失フレームのデータは三つの再送信セグメントに分解され、それぞれはもとの喪失フレームと同じシーケンス番号を有する。
【００１５】
広範に容量が変化するチャンネル上で使用するためＲＬＰ２を適応させようとすると、高容量チャンネル（例えば、３０７ｋｂｐｓ）上で送信されるフレームを低容量チャンネル（例えば、９．６ｋｂｐｓ）上で送信しなければならないとき困難が発生する。２０ｍｓのフレーム間隔を用いると、３０７ｋｂｐｓのチャンネル上のフルレート・フレームは７５０バイトだけのデータを搬送することができる。そのようなフレームは送信中に喪失し、そして同時にチャンネル容量は９．６ｋｂｐｓに低下することがある。ＲＬＰ２では、９．６ｋｂｐｓのフルレート２０ｍｓフレームの容量は２０バイトである。最大許容再送信セグメントの単純な拡張では、７５０バイト・データの単一フレームを首尾よく再送信することは、約３８個の連続９．６ｋｂｐｓのフルレートＲＬＰ２再送信セグメントの首尾よい送信を必要とする。全ての再送信セグメントは同じシーケンス番号をもっているから、これら３８個の再送信セグメントの一つの喪失は全体の再送信フレームの喪失をもたらすことになる。受信器は個々の再送信セグメントを否定的認知（ＮＡＫ）できない。オーバー・ザ・エア・フレーム誤り率が１％であれば、３８個の連続フルレートＲＬＰ２再送信セグメントの送信成功確率は約６８％である。この筋書きでは、セグメントの再送信はしばしば失敗することになり、ＲＬＰ２再同期によるバイト・ストリームにおけるデータ喪失および中断をもたらす。斯くして、そのようなＲＬＰ２の単純な拡張は高容量フルレート・フレームが低容量チャンネル上で再送信されなければならない度ごとに喪失データの起因となる。
【００１６】
さらに信頼できるデータ再送信を達成する一方法はフレーム・シーケンス番号の代わりにＲＬＰヘッダ内のバイト・シーケンス番号を用いることである。チャンネル容量の減少により密接に従う大きな高率ＲＬＰの喪失に際して、喪失フレーム中のデータは小さな独立したＲＬＰ再送信フレームに分割することができる。受信器は誤りなしで３８個の連続再送信フレームを受信する必要はない。受信器は旨く受信したどの再送信フレームでも受取り、ある喪失再送信フレームを単純に否定的認知（ＮＡＫ）することができる。さらにオーバー・ザ・エア・フレーム誤りが１％であることを用いると、列内で同じセグメントが二度喪失する確率は０．０１％になる。
【００１７】
フレーム・シーケンス番号の代わりにバイト・シーケンス番号を用いる一欠点は同じデータを表すためにバイト・シーケンス番号における非常に多くのビット数である。９．６ｋｂｐｓフルレートＲＬＰ２フレーム内でバイト・シーケンス番号を使用すれば、シーケンス番号は８ビットフレーム・シーケンス番号より５ビット長くしなければならない。ｃｄｍａ２０００においては、チャンネル容量が９．６ｋｂｐｓからその容量の３２倍（約３０７ｋｂｐｓ）まで変化し、フルレート３０７ｋｂｐｓフレームは７５０ＲＬＰデータ・バイトだけをもつことになる。ＲＬＰ２におけると同じ２０ミリ秒の期間を追尾するに必要なバイト・シーケンス番号ビットの数は少なくとも１８ビットである。９．６ｋｂｐｓＲＬＰフレーム中に１８ビット・バイト・シーケンス番号の場所を空けるために、フレームは二少ないデータ・バイト、即ち１０％の減少、をもつことが可能になる。
【００１８】
発明の実施例は大多数のオーバー・ザ・エア・フレーム内のシーケンス番号ビットの一部を送信すると同時に大きなバイト・シーケンス番号の利益を提供する。発明の一実施例において、２０ビット・バイト・シーケンス番号が受信データを追尾するために使用される。シーケンス番号で追尾されるバイト数はシーケンス番号空間（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ ｓｐａｃｅ）と呼ばれる。２０ビットシーケンス番号の場合は、シーケンス番号空間の大きさ（サイズ）は２２０である。
【００１９】
平均フレーム・ヘッダの大きさに加えないで大きなシーケンス番号の利益を得ることは、送信データ・バイトに割り当てられないシーケンス番号空間の部分を注意深く選択することにより達成される。言い換えれば、幾つかのシーケンス番号空間は実際の送信バイトを追尾するために使用されず、消費されたものと見てよい。選択されたシーケンス番号の大きさは、シーケンス番号空間の消費がプロトコルの動作に影響しないで許容されるように選択される。例えば、１８ビット・シーケンス番号が３０７ｋｂｐｓチャンネル上で５秒の送信喪失を耐えるに必要であれば、２０ビット・シーケンス番号の使用は送信損失の最大許容長に影響しないで未使用のため４分の３のシーケンス番号空間を許容する。
【００２０】
シーケンス番号空間の未使用部分は各々の新しい送信データ・フレームの最初（ｆｉｒｓｔ）のバイトが、ページ・サイズと呼ばれる所定の距離で、前のデータ・フレームの最初のバイトから始まるように選択される。例えば、フレームｎ内の最初のバイトが１０００のシーケンス番号を有し、ページ・サイズが１００であれば、フレームｎ＋１の最初のバイトは次のページ上で１１００のシーケンス番号で始まる。フレームｎが１０００から１０３９の数の４０バイトを収容するのみであれば、１０４０から１０９９までのシーケンス番号空間は未使用になる。シーケンス番号空間の見かけの消費を許容する動機はフレーム内で送信されるシーケンス番号のビット・サイズの減少を許容する。今ここで示した例において、シーケンス番号はフレームに挿入する前に１００で分割することができ、したがって少なくとも６少ないビットにより表すことができる。発明の好ましい実施例において、ページ・サイズは、シーケンス番号のコンピュータ・ソフトウェア操作を容易にするため、６４といった２の累乗である。
【００２１】
高率フレーム中の７５０データ・バイトが喪失するという、前に述べた筋書きにおいて、発明の好ましい実施例は高容量及び低容量チャンネル上の再送信に同様に容易に適応する。高容量チャンネルでは、データは一または二再送信フレーム中で容易に送信される。しかしながら、チャンネルの容量が減少すれば、再送信されるべきデータ・バイトは幾つかの独立した再送信フレームに分割され、各々はそれ自身のシーケンス番号を持つ。独立再送信シーケンス番号の使用はＲＬＰ２により指定されたセグメント化再送信に有利である。単一ＲＬＰ２再送信セグメントが送信中に喪失すると、同じシーケンス番号をもつ全てのセグメントは喪失セグメントのデータを回復させるために再び再送信しなければならない。逆に、独立の番号がついた一またはそれ以上の再送信フレームが送信中に喪失すると、受信器は個々の喪失フレームを否定的認知（ＮＡＫ）することができる。第二のＮＡＫを受信した後で、送信器は二度目に個々の再送信フレームを送信することができる。さらに１％のオーバー・ザ・エア・フレーム誤りを用いると、列内で同じ再送信フレームが二度喪失する確率は０．０１％である。ＲＬＰ再同期、及びその付随データ喪失及びバイト・ストリーム不連続性は殆ど必要ない。
【００２２】
フレームの代わりにバイトに対応するシーケンス番号を用いる一つの欠点は多くのビットがシーケンス番号を表すのに一般に必要なことである。これは喪失フレームのデータを搬送するために必要な独立番号のついた再送信フレームの数に僅かな増加をもたらす。しかしながら、発明の典型的な実施例においては、この影響はシーケンス番号から最上位ビットと最下位ビットを時々省略することにより最小化される。
【００２３】
本発明の特徴、目的、および長所は、同様な参照符号が全体にわたり対応して同一である図面と関連して取られる以下に始まる詳細な記述からさらに明らかになるであろう。
【００２４】
好ましい実施例の詳細な説明
図１はシーケンス番号空間が発明の実施例に如何に使用されるかを示す。送信されるべき新しいデータはフルレートＲＬＰフレーム１４０中に置かれる。ＲＬＰフレーム１４０内にはシーケンス番号１５０及びデータ１００がある。送信されるべき新しいデータ１０２はフルレートＲＬＰフレーム１４２中に置かれる。ＲＬＰフレーム１４２内にはシーケンス番号１５２及びデータ１００がある。
【００２５】
新しいデータ１０４がフルレートＲＬＰフレームについて最大値より少ないバイトを有していれば、非フルレートＲＬＰフレーム１４４中に置かれる。ＲＬＰフレーム１４４内にシーケンス番号１５４及びデータ１０４だけでなく、データ長１６４もある。ＲＬＰ２と同様に、発明のこの実施例はより小さいＲＬＰフレームを搬送するために、所定のチャンネル容量、例えば９６００ｂｐｓにおけるハーフレート・フレーム内で低率フレームの使用を許容する。
【００２６】
発明の典型的な実施例において、各シーケンス番号はＲＬＰフレーム中のデータの最初（ｆｉｒｓｔ）のバイトに対応する。ＲＬＰフレーム内で搬送されるシーケンス番号はＲＬＰシーケンス番号と呼ばれる。
【００２７】
三つのＲＬＰフレーム１４０、１４２、及び１４４中で送信されるデータ１００、１０２、及び１０４はシーケンス番号空間１１０に存在する。発明の典型的な実施例において、シーケンス番号はバイト・シーケンス番号であり、左の低い値から右の高い値に連続して進行する。本実施例において、シーケンス番号は使用されるか飛び越されるかのいずれかなので、シーケンス番号は単調に増加する。所定のシーケンスの最大シーケンス番号値に達すると、シーケンス番号は再びゼロで始まる。
【００２８】
データ・バイト１０２はＲＬＰフレーム１４２中へ置かれるので、それらはシーケンス番号１２６のブロックから連続バイト番号を各々割り当てられる。典型的な実施例では、ブロック１２６の最初のバイトは前のＲＬＰフレームを送信するために使用されるブロック１２２の最初のバイトから所定数の距離１３４ａにある。この所定距離はページ・サイズと呼ばれ、所定距離内のシーケンス番号は一纏めにしてページと呼ばれる。データを送信するために使用されるシーケンス番号ブロックはページの先頭から常に始まる。例えば、シーケンス番号ブロック１２２はページ１３４ａの先頭から始まり、シーケンス番号ブロック１２６はページ１３４ｂの先頭から始まり、シーケンス番号ブロック１３０はページ１３４ｃの先頭から始まる。ページの先頭で新しいフレームを常に始めることの一つの副効果はページの末端、例えば１２４、１２８、及び１３２でのシーケンス番号のブロックを送信されるデータ・バイトに割り当てなくてもよいということである。
【００２９】
発明の典型的な実施例において、短縮ＲＬＰシーケンス番号が使用され、それはページ・サイズで分割したＲＬＰフレーム中の最初のデータ・バイトのバイト・シーケンス番号に等しい。短縮ＲＬＰシーケンス番号を表すために必要なビット数は実際のバイト系列番号を表すために必要なビット数より少ない。
【００３０】
発明の別の実施例において、省略によりどのデータがＲＬＰフレームのデータ部分に含まれるか曖昧にならないとき最上位ビットがバイト・シーケンス番号から省略される。例えば、２０ビットのバイト・シーケンス番号が使用され、しかし２１６バイト以下が顕著（明らかに、または暗に認知されない）であれば、バイト・シーケンス番号の最上位４ビットはＲＬＰシーケンス番号中で送信する必要はない。これらの４最上位ビットはフレーム中に含まれるバイトのシーケンス番号に曖昧さをもたらすことなくＲＬＰシーケンス番号から安全に省略される。
【００３１】
シーケンス番号の短縮はシーケンス番号から最上位ビットの番号を書略するものとして描かれているけれども、この技術分野に熟達するものは現発明から逸脱することなしに同じ結果がシーケンス番号にモジュロ関数を作用させることにより得られることを認識している。
【００３２】
しかしながら、２１６バイト以上が顕著であれば、顕著なデータバイトの一以上は同じ短縮ＲＬＰシーケンス番号を有するかもしれない。発明の典型的な実施例において、そのようなデータ・バイトをもつ再送信フレームは完全な２０ビットのシーケンス番号を含む。
【００３３】
ＲＬＰフレームが否定的に認知（ＮＡＫ）され、再送信されなければならないとき、データはＲＬＰ再送信フレームに挿入され、再送信される。再送信間のチャンネル容量が十分であれば、再送信フレームは元の喪失ＲＬＰフレームと同じ大きさ（サイズ）である。再送信フレームと元のＲＬＰフレームが同じ大きさである場合には、そうすることがシーケンス番号の曖昧さをもたらさない限り、元と同じ短縮ＲＬＰシーケンス番号を使用することができる。
【００３４】
チャンネル容量が減少したとき可能なように、元の送信フレームが単一送信フレーム中に適合する以上のデータを持っていれば、元の送信フレームからのデータは幾つかのより小さな再送信フレームに分割される。各再送信フレームはそれ自身のシーケンス番号を有し、それは前に論じた方法の一つで短縮してもよいし、しなくてもよい。再送信フレームが送信中に喪失すれば、個々の再送信フレームは否定的認知（ＮＡＫ）され、その後で送信することができる。再送信フレームが否定的認知（ＮＡＫ）される前にチャンネル容量が減少するまれな場合には、第二の再送信の前に再送信フレームは同じより小さな独立した再送信フレームにさらに分割することができる。
【００３５】
この手順は、単一喪失フレームに対応する再送信セグメントが全て同じＲＬＰシーケンス番号をもつＲＬＰ２とは異なる。単一喪失再送信セグメント中のデータを回復させるために、喪失フレームのシーケンス番号をもつ全ての再送信セグメントは再び再送信しなければならない。
【００３６】
図２は、喪失ＲＬＰフレーム中のデータが幾つかのより小さなＲＬＰ再送信フレーム中で再送信されねばならないとき、発明の典型的な実施例にしたがう、バイト・シーケンス番号空間及びＲＬＰシーケンス番号の使用を示す。チャンネル容量が元のＲＬＰフレームの送信とそのデータの再送信の時間の間で減少するとき再送信バイトの分割が必要である。
【００３７】
示された例において、元の喪失ＲＬＰフレーム中のバイトを表すために使用されるシーケンス番号空間２２８は幾つかのＲＬＰ再送信フレーム２３０に分割される。シーケンス番号空間２２８はより小さな部分２２０に分割され、各々は現送信チャンネル上のフルレート・フレームの容量より少ないか、または等しい大きさ（サイズ）を有する。より小さなシーケンス番号空間部分２２０の各々に対応するデータ２００はＲＬＰ再送信フレーム２３０中へ置かれる。
【００３８】
各ＲＬＰ再送信セグメントはそのそれぞれのシーケンス番号空間２２０の最初（ｆｉｒｓｔ）のバイトに対応するＲＬＰシーケンス番号２４０を有する。例えば、シーケンス番号２４０ａはシーケンス番号空間２２０ａ中の最初のバイトを表す値を有する。各再送信フレーム２３０中のＲＬＰシーケンス番号２４０は、そうすることがシーケンス番号の曖昧さをもたらさない限り、ＲＬＰシーケンス番号について論じたと同じ方法で随意に短縮することができる。
【００３９】
各ＲＬＰ再送信フレームは随意にデータ長２５０をもつことができる。各ＲＬＰ再送信フレームにより搬送されるデータ長２５０はフレーム内のデータ・バイト２００の数を示す。例えば、データ長２５０ａは再送信フレーム２３０ａ中のデータ・バイト２００ａの数に等しい。データ長が再送信フレーム２３０の他の部分、例えば図では示されてない型の領域（ｆｉｅｌｄ）で示されれば、データ長２５０は省略することができる。
【００４０】
ＲＬＰ再送信フレームの形成はデータ２００ｎの最後の部分がＲＬＰ再送信フレーム２３０ｎの中へ置かれるまで続く。一連のＲＬＰ再送信フレームの最後はデータ・バイト２００ｎの最大数より少なく含み、したがって一般的にはデータ長２５０ｎを含む。
【００４１】
発明の好ましい実施例において、最も共通な送信フレームのＲＬＰシーケンス番号は最下位ビット及び最上位ビットを省略することにより短縮される。発明の典型的な実施例において、バイト・シーケンス番号は２０ビットを有し、６４バイトのページ・サイズが使用され、そして顕著なＲＬＰ送信フレームの数はまれに２５６を超える。
【表１】
【００４２】
いろいろな型ビット（ｔｙｐｅ ｂｉｔｓ）の番号がＲＬＰフレーム型を表すのに使用される。一纏めにして、これらの型ビットは可変ビット長型領域を形成し、それは送信されるＲＬＰフレームの型を示し、同様にＲＬＰヘッダの残りのフォーマットを示す。表１において、“フレーム型記述”欄は各型領域値に対応するフレーム型の記述を含む。“フレーム型記述”欄のフレーム型記述は議論のためにフレーム型番号と同一にしてある。“フレーム型記述”欄以外の全ての欄はＲＬＰヘッダに実際に含まれる領域を示す。
【００４３】
型領域（ｔｙｐｅ ｆｉｅｌｄ）の次にＲＬＰシーケンス番号が続く。シーケンス番号の曖昧さをもたらすことなく可能なときは、８ビットの短縮ＲＬＰシーケンス番号が使用される。別な時は、１４ビットの短縮ＲＬＰシーケンス番号または最大の２０ビットＲＬＰシーケンス番号がＲＬＰヘッダにより含まれる。
【００４４】
８ビットの短縮ＲＬＰシーケンス番号はフレーム中の最初のデータ・バイトに対応する２０ビット・バイト・シーケンス番号から生成される。２０ビット・バイト・シーケンス番号はバイト・シーケンス番号の最下位６ビット及び最上位６ビットを省略することにより８ビットの短縮ＲＬＰシーケンス番号に変換される。８ビット番号は最新のマイクロプロセッサ及びモデム・ソフトウェアで非常に容易に処理されるので、８ビットＲＬＰシーケンス番号の使用は特に有利である。発明の好ましい実施例において、改良ＲＬＰプロトコルが８ビットＲＬＰシーケンス番号で送信されるＲＬＰフレームの数を最大化するために設計されている。
【００４５】
２０ビット・バイト・シーケンス番号はバイト・シーケンス番号の最下位６ビットを省略することにより１４ビットの短縮ＲＬＰシーケンス番号に変換される。２０ビットＲＬＰシーケンス番号がＲＬＰフレーム中で送信されるべきとき、２０ビット・バイト・シーケンス番号はＲＬＰシーケンス番号中に単純に複写（ｃｏｐｙ）される。
【００４６】
発明の好ましい実施例において、最初に送信されるべきデータをもつ大方のフレームは８ビットＲＬＰシーケンス番号を使用する。これらのフレーム型は“フレーム型記述”欄の型１及び３と同じである。さらに、型２で示されているように、ＲＬＰ再送信フレームはまた８ビットＲＬＰシーケンス番号を使用できる。
【００４７】
フレーム型４、５，及び６は１４ビットＲＬＰシーケンス番号を含む。これらのフレームは顕著なフレームが同じ８ビットＲＬＰシーケンス番号を有する場合にはシーケンス番号の曖昧さを避けるために使用でき、そうでなければ送信されるべき次のフレームにより使用される。これらのフレームはまた否定的認知（ＮＡＫ）されたフレームからデータを再送信するのに随意に使用できる。
【００４８】
フレーム型７及び８は最大の２０ビットＲＬＰシーケンス番号を含む。これらのフレームはＮＡＫデータが少ない再送信フレーム中で再送信できる前にチャンネル容量が減少するとき使用される。
【００４９】
ここに再送信の前にチャンネル容量が減少するとき再送信フレーム型の使用の例がある。バイト・シーケンス番号１０００から１７４９をもつ、７５０バイトのデータが３０７ｋｂｐｓチャンネル上の単一ＲＬＰ送信フレームの送信の間に喪失する。受信器がＮＡＫフレームを送信器に送り返す時までに、チャンネル容量は９．６ｋｂｐｓまで低減してしまった。７５０バイトの喪失データはすぐに９．６ｋｂｐｓチャンネル上で再送信されなければならない。この筋書きを表すため図２を用いると、シーケンス番号空間２２８は１０００から１７４９の範囲にある。ＲＬＰ２の単純な拡張では、９．６ｋｂｐｓチャンネル上のフレーム型８のヘッダを用いる各再送信フレームは１５バイトのデータをもつ。例としてこれを用いると、７５０バイトの再送信データは５０ＲＬＰ再送信フレームの間に分配される。図２において、ＲＬＰ再送信フレーム２３０ｎは１０００の２０ビット・シーケンス番号とデータ長１５をもつフレーム型８のヘッダを有する。ｎ＝５０で、フレーム２３０ｎ-１は１７２０の２０ビット・シーケンス番号とデータ長１５をもつフレーム型８のヘッダを有する。フレーム型８の使用は再送信フレームと次のページの境界との間のシーケンス番号空間に割り当てられた多くのデータバイトがあることを受信器に指示する。フレーム２３０ｎは１７３５の２０ビット・シーケンス番号とデータ長１５をもつフレーム型７のヘッダを有する。末端の再送信フレームにおけるフレーム型７の使用はフレーム中の末端のバイトと次のページの境界との間のシーケンス番号空間に割り当てられたデータがないことを受信器に指示する。型７または８の何れのフレームも個々にＮＡＫ（否定的認知）され、再び再送信される。前の例の単純な改良では、フレーム型８の変形は無データ長バイトをもつヘッダ有し、フレームが１６バイトのデータをもつことを許容する。
【００５０】
フレーム型９はＲＬＰプロトコルにおける同期のために使用される制御／シーケンス・フレームをもつ。制御／シーケンス・フレームの使用は前述のＲＬＰ２に詳細に記載されている。
【００５１】
無長領域を有するフレーム・ヘッダにおいて、データ長は送信されたフレームの残余中へ適合できるバイトの最大数であると解釈される。このようにして、この中で述べられた改良ＲＬＰプロトコルは前述のＲＬＰ２またはｃｄｍａ２０００で指定されるより大きな容量を有するチャンネル中での使用のために容易に拡張できる。多くの予想される拡張において、改良ＲＬＰプロトコルの変形は新しいチャンネル容量のために便宜をはかる必要はない。
【００５２】
受信器は、この中で述べられたフォーマット中のＲＬＰフレームを受信する際、各ＲＬＰフレーム中に含まれるバイトに適用されるべき元のバイト・シーケンス番号を再生するため短縮シーケンス番号を使用する。そのＲＬＰシーケンス番号が一またはそれ以上の先立つフレームの喪失を指示するフレームが受信されるとき、受信器はＮＡＫを送信機に送信する。ＮＡＫフレームは対応するＲＬＰ再送信フレームに対応するＲＬＰシーケンス番号で使用されるべきビット数を随意に指定できる。
【００５３】
発明の好ましい実施例は２０ビットのバイト・シーケンス番号及び８、１４、及び２０ビットのＲＬＰシーケンス番号を指定するけれども、他の多くのシーケンス番号サイズの選択は現発明から逸脱することなしに行うことができる。バイト・シーケンス番号空間の最上位または最下位部分の明白な省略を可能にするＲＬＰシーケンス番号の使用は、２の累乗であるページ・サイズの選択及び８ビットの短縮ＲＬＰシーケンス番号の使用と同様、現発明の種々の実施例の目的である。
【００５４】
図３は発明の実施例にしたがってデータ・フレームを送信するために使用されるステップのフローチャートである。フレーム送信処理３０２の始まりで、送信器は新しいＲＬＰフレームまたはＲＬＰフレームを送信しなければならいかどうかを評価３０４する。この決定は喪失送信データを指定するＮＡＫフレームが以前に受信されたかどうかに基づいている。
【００５５】
送信フレームを形成する前に、送信器が送るべき新データを有するかどうかを判定３０６するため送信バッファまたはキュー（ｑｕｅｕｅ）が点検される。送信されるべきデータがなければ、アイドル・フレーム（ｉｄｌｅ ｆｒａｍｅ）が形成３０８され、送信３２６される。ＳＹＮＣ、ＡＣＫ、及びＩＤＬＥフレームの使用は前述のＲＬＰ２に詳述されている。発明の一実施例において、アイドル・フレームの空中回線容量の影響を最小にするためアイドル・フレームはより小さな低データ率オーバー・ザ・エア・フレーム中に置かれる。発明の別の実施例において、アイドル・フレームは全く送らなくてもよく、また各フレーム期間よりは少ない頻度で送ってもよい。
【００５６】
送信器が送信すべき新データを有することが判定３０６されれば、シーケンス番号の曖昧さをもたらさない８ビットＲＬＰシーケンス番号を有するフレーム中にデータがあるかどうかを送信器は評価３０８する。８ビットシーケンス番号が曖昧さをもたらさなければ、８ビットＲＬＰシーケンス番号を有するＲＬＰ送信フレームが形成３１４され、送信３２６される。送信されるべきデータ・バイトの数がフルレート・フレームの最大値より小さければ、形成３１４されたフレームはデータ長領域（ｌｅｎｇｔｈ ｆｉｅｌｄ）をもつ。送信されるべきデータ・バイトの数がフルレート・フレームの最大値より大きいか等しければ、データ・バイトの最大番号がフルレート・フレーム中に挿入３１４され、そのフレームが送信３２６される。ステップ３１２または３１４で新送信フレーム中へ挿入されたＲＬＰシーケンス番号は次の未使用ページを始めるバイト・シーケンス番号から生成される。
【００５７】
送信器がＲＬＰ再送信フレームを送信しなければならないことを送信器が判定３０４すれば、次のステップは、最大の２０ビットＲＬＰシーケンス番号が次のＲＬＰ再送信フレームで要求されるかどうかを判定３２２することである。チャンネル容量が送信と再送信との間で減少するとき可能であるのように、もともとデータを送信するために使用されるより多くのＲＬＰフレーム中で再送信されるべきデータを再送信しなければならない場合は、最大の２０ビットＲＬＰシーケンス番号が要求される。次のフレームを２０ビットＲＬＰシーケンス番号で送信しなければならない場合は、ＲＬＰ再送信フレームが形成され、データで満たされ３２４、そしてＲＬＰ再送信フレーム中の最初のデータ・バイトに対応するＲＬＰシーケンス番号で送信３２６される。２０ビットＲＬＰシーケンス番号が必要ないと送信器が判定３２２すれば、送信器は次の再送信ＲＬＰフレームについて８ビットまたは１４ビットＲＬＰシーケンス番号の使用の間を選択３１８しなければならない。一旦、要求されるシーケンス番号のビット・サイズの判定が終了３１８すると、送信器は８ビットＲＬＰシーケンス番号でＲＬＰ送信フレームを形成３２０し、または１４ビットＲＬＰシーケンス番号でＲＬＰ送信フレームを形成３１６し、フレームを送信３２６する。ケース３１６または３２０のいずれにおいても、フレームに挿入されるＲＬＰシーケンス番号はフレーム中に含まれる最初のデータ・バイトに対応するバイト・シーケンス番号から生成される。そのバイト・シーケンス番号はシーケンス番号ページの最初のバイト・シーケンス番号である。データ・サイズについて曖昧さを避ける必要があれば、再送信ＲＬＰフレームのＲＬＰヘッダはデータ長領域を含める。
【００５８】
図４は発明の実施例にしたがって受信データ・フレームからデータを取り出すために使用されるステップのフローチャートである。ＲＬＰシーケンス番号を含むＲＬＰデータ・フレームまたはアイドル・フレームを受信４０２すると、受信器はバイト・シーケンス番号を形成するために必要なものとしてＲＬＰフレームから受信ＲＬＰシーケンス番号を展開し、フレームからあるデータ・バイトを取り出す４０４。そこで、受信器はそのバイト・シーケンス番号から、データを搬送するＲＬＰフレームが喪失したかどうかを判定４０６する。
【００５９】
発明の典型的な実施例において、最も新しく（ｒｅｃｅｎｔｌｙ）受信されたＲＬＰデータ・フレームにより指示されたバイト・シーケンス番号を連続して受信された最終（ｌａｔｅｓｔ）の前データ・バイトに対応するバイト・シーケンス番号と比較することにより、喪失データの判定が行われる。例えば、再送信でない受信ＲＬＰデータ・フレームの最後のバイトは旨く受信された最終の前データ・バイトと考えられる。再送信でない受信ＲＬＰデータ・フレームから展開された、または受信ＲＬＰアイドル・フレームの、バイト・シーケンス番号が旨く受信された最終の前データ・バイトのシーケンス番号からページより大きく異なれば、一またはそれ以上の喪失ＲＬＰデータ・フレームの喪失が発生した。
【００６０】
前述のＲＬＰ２プロトコルは再送信ＲＬＰフレームの喪失の判定においてタイマー及びフレーム・カウンタの使用を述べている。この技術は現発明の実施例においても使用される。
【００６１】
データが喪失したことを判定４０６すると、受信器は喪失データの再送信を要求するためＮＡＫフレームを形成し、送信４０８する。発明の別の実施例において、旨く受信されたバイトのバイト・シーケンス番号空間の受信器の知識に基づいて、受信器は、ＮＡＫフレーム内で、再送信ＲＬＰフレーム内のＲＬＰシーケンス番号において使用されるべき低減ビット数を指定できる。
【００６２】
データが喪失しなかったことを判定４０６すると、受信器はＲＬＰアイドルまたはＲＬＰデータ・フレームを適切なものとして形成し、送信する。発明の別の実施例において、アイドル・フレームは全く送らなくてもよく、また各フレーム期間よりは少ない頻度で送ってもよい。
【００６３】
図５は発明の実施例にしたがって配置されたデータ通信システムの図である。図に示したように、送信器５０２は無線通信チャンネル５０６上で受信器５０４と通信を行う。ＲＬＰデータ・フレーム及び制御フレームはチャンネル５０６ａに沿って送信器５０２から受信器５０４へ送信され、ＲＬＰ認知またはＮＡＫ（否定的認知）はチャンネル５０６ｂに沿って受信器５０４から送信器５０２へ送信される。送信中は、送信チャンネル５０６の容量は変化し、元の送信において使用されるよりは少ない容量のチャンネル上でデータの再送信をときどき要求する。
【００６４】
例えば、大きなフルレートＲＬＰデータ・フレームはチャンネル５０６ａ上で送信器５０２により送信されるが、受信器５０４で旨く受信されないかもしれない。そのときは、受信器がチャンネル５０６ｂ上で喪失データのためにＮＡＫフレームを送信する直前または直後にチャンネル５０６の容量が低減される。そこで送信器５０２は低減容量チャンネル５０６ｂ上で再送信のために元の喪失フルレートＲＬＰデータ・フレームからのデータバイトを複数のより小さなＲＬＰフレームの中に分配しなければならない。一またはそれ以上の再送信ＲＬＰフレームが低減容量チャンネル５０６ａ上で喪失されたことを受信器５０４が判定すれば、受信器５０４はチャンネル５０６ｂ上でこれら個々の喪失再送信フレームを個々にＮＡＫ（否定的認知）する。
【００６５】
発明の典型的な実施例において、送信器５０２はメモリに接続されたプロセッサとプロセッサで処理されたバイトを無線で送信および受信するための装置を含む。プロセッサは送信装置上で送信されるべきバイト・ストリームが供給され、上文で述べた改良無線回線プロトコル（ＲＬＰ）に従って送信信号を形成する。
【００６６】
発明の典型的な実施例において、受信器５０４はメモリに接続されたプロセッサとプロセッサで処理されたバイトを無線で送信および受信するための装置を含む。プロセッサは受信装置から受信された受信データが供給され、上文で述べた改良無線回線プロトコル（ＲＬＰ）に従って送信の応答フレームを形成する。
【００６７】
先述の好ましい実施例はこの技術分野に熟達する人が本発明を為しまたは使用を可能にするために提供される。これらの実施例に対する種々の変形はこの技術分野に熟達する者には直ちに明白であり、この中に定義された一般原理は発明能力を用いることなく他の実施例に適用可能である。斯くして、本発明はこの中に示された実施例に限定されると解釈されるものではなく、この中に開示された原理及び新規な特徴と両立する広範な領域を認容すべきものである。
【図面の簡単な説明】
【図１】 発明の実施例にしたがう幾つかの新ＲＬＰフレームにおけるシーケンス番号空間とその使用を示す図である。
【図２】 発明の実施例にしたがう幾つかのＲＬＰフレームにおけるシーケンス番号とその使用を示す図である。
【図３】 発明の実施例にしたがってデータ・フレームを送信するために使用されるステップのフローチャートである。
【図４】 発明の実施例にしたがって受信データ・フレームからデータを取り出すために使用されるステップのフローチャートである。
【図５】 発明の実施例にしたがって配置されたデータ通信システムの図である。
【符号の説明】
５０２…送信器、５０４…受信器、５０６…無線通信チャンネル
Claims (12)
- データ・バイトのストリームを送信する方法であって：
（ａ）所定のシーケンス番号空間のサブセットからのシーケンス番号をデータ・バイトの前記ストリームからの１つのセットの複数のデータ・バイトの各々に割り当てるステップ；
（ｂ）第一のシーケンス番号を所定のページ・サイズで除算することにより前記サブセットの第一のシーケンス番号から第一の短縮シーケンス番号を生成するステップ；
（ｃ）送信フレームのフレーム・ヘッダ中に前記第一の短縮シーケンス番号をフォーマットするステップ；及び
（ｄ）前記フレーム・ヘッダ及びデータ・バイトの前記セットをもった前記送信フレームを送信するステップを含む方法。 - 前記第一の短縮シーケンス番号を生成するステップはさらに所定のモジュロ関数ベースを用いて前記第一のシーケンス番号のモジュロ関数を実行するステップを含む請求項１の方法。
- データ・バイトのストリームを受信する方法であって：
（ａ）受信フレームのフレーム・ヘッダから短縮シーケンス番号を取り出すステップ；
（ｂ）前記短縮シーケンス番号を所定のページ・サイズにより乗算することにより第一の非短縮シーケンス番号を生成するステップ；
（ｃ）所定のシーケンス番号空間のサブセットからのシーケンス番号を前記受信フレームに含まれる１つのセットの複数のデータ・バイトの各々に割り当てるステップ；及び
（ｄ）前記シーケンス番号に基づくデータ・バイトの前記セットからデータ・バイトの前記ストリームを形成するステップを含む方法。 - 前記第一の非短縮シーケンス番号を生成するステップはさらに所定のモジュロ関数ベースを用いて前記第一のシーケンス番号のモジュロ関数を実行するステップを含む請求項３の方法。
- データ・バイトのストリームを送信するシステムであって：
（ａ）所定のページ・サイズにより除算された非短縮無線回線プロトコル（ＲＬＰ）シーケンス番号の商を含む短縮ＲＬＰシーケンス番号を生成し、前記短縮ＲＬＰシーケンス番号及びデータ・バイトの前記ストリームの部分を含むデータ・フレームを送信する送信器；及び
（ｂ）前記データ・フレームを受信し、前記短縮ＲＰＬシーケンス番号に基づく前記部分からデータ・バイトの前記ストリームを復元する受信器を含むシステム。 - データ・バイトのストリームを送信するシステムであって：
（ａ）所定のページ・サイズにより除算された非短縮無線回線プロトコル（ＲＬＰ）シーケンス番号の商を含む短縮ＲＬＰシーケンス番号を生成し、前記短縮ＲＬＰシーケンス番号及びデータ・バイトの前記ストリームの部分を含むデータ・フレームを送信するための第一のプロセッサ及び第一のメモリを含む送信器手段；及び
（ｂ）前記データ・フレームを受信し、前記短縮ＲＬＰシーケンス番号に基づく前記部分からデータ・バイトの前記ストリームを復元するための第二のプロセッサ及び第二のメモリを含む受信器手段を含むシステム。 - メモリに接続されたプロセッサを含み、メモリがデータ・バイトのストリームを送信する方法を具体化するコンピュータ実行可能な指示を含む送信器であって、方法が、
所定のシーケンス番号空間のサブセットからのシーケンス番号をデータ・バイトの前記ストリームからの１つのセットの複数のデータ・バイトの各々に割り当て；
第一のシーケンス番号を所定のページ・サイズで除算することにより前記サブセットの第一のシーケンス番号から第一の短縮シーケンス番号を生成し；
送信フレームのフレーム・ヘッダ中に前記第一の短縮シーケンス番号をフォーマットし；及び
前記フレーム・ヘッダ及びデータ・バイトの前記セットをもった前記送信フレームを送信することを含む送信器。 - 前記生成することが、所定のモジュロ関数ベースを用いて前記第一のシーケンス番号のモジュロ関数を実行することをさらに含む請求項７の送信器。
- メモリに接続されたプロセッサを含み、メモリがデータ・バイトのストリームを受信する方法を具体化するコンピュータ実行可能な指示を含む受信器であって、方法が、
受信フレームのフレーム・ヘッダから短縮シーケンス番号を取り出し；
前記短縮シーケンス番号を所定のページ・サイズにより乗算することにより第一の非短縮シーケンス番号を生成し；
所定のシーケンス番号空間のサブセットからのシーケンス番号を前記受信フレームに含まれる１つのセットの複数のデータ・バイトの各々に割り当て；及び
前記シーケンス番号に基づくデータ・バイトの前記セットからデータ・バイトの前記ストリームを形成することを含む受信器。 - 前記生成することが所定のモジュロ関数ベースを用いて前記第一のシーケンス番号のモジュロ関数を実行することをさらに含む請求項９の受信器。
- データ・バイトのストリームを送信する送信器であって：
所定のシーケンス番号空間のサブセットからのシーケンス番号をデータ・バイトの前記ストリームからの１つのセットの複数のデータ・バイトの各々に割り当てる手段；
第一のシーケンス番号を所定のページ・サイズで除算することにより前記サブセットの第一のシーケンス番号から第一の短縮シーケンス番号を生成する手段；
送信フレームのフレーム・ヘッダ中に前記第一の短縮シーケンス番号をフォーマットする手段；及び
前記フレーム・ヘッダ及びデータ・バイトの前記セットをもった前記送信フレームを送信する手段を含む送信器。 - データ・バイトのストリームを受信する受信器であって：
受信フレームのフレーム・ヘッダから短縮シーケンス番号を取り出す手段；
前記短縮シーケンス番号を所定のページ・サイズにより乗算することにより第一の非短縮シーケンス番号を生成する手段；
所定のシーケンス番号空間のサブセットからのシーケンス番号を前記受信フレームに含まれる１つのセットの複数のデータ・バイトの各々に割り当てる手段；及び
前記シーケンス番号に基づくデータ・バイトの前記セットからデータ・バイトの前記ストリームを形成する手段を含む受信器。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/321,296 US6507582B1 (en) | 1999-05-27 | 1999-05-27 | Radio link protocol enhancements for dynamic capacity wireless data channels |
| US09/321,296 | 1999-05-27 | ||
| PCT/US2000/014699 WO2000074259A2 (en) | 1999-05-27 | 2000-05-26 | Sequence numbering of data packets |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003501865A JP2003501865A (ja) | 2003-01-14 |
| JP2003501865A5 JP2003501865A5 (ja) | 2007-07-12 |
| JP4519382B2 true JP4519382B2 (ja) | 2010-08-04 |
Family
ID=23250018
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001500453A Expired - Lifetime JP4519382B2 (ja) | 1999-05-27 | 2000-05-26 | 動的容量無線データ・チャンネルのための無線回線プロトコルの改良 |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US6507582B1 (ja) |
| EP (2) | EP1183846B1 (ja) |
| JP (1) | JP4519382B2 (ja) |
| KR (1) | KR100714505B1 (ja) |
| CN (1) | CN1165146C (ja) |
| AT (1) | ATE366497T1 (ja) |
| AU (1) | AU5447000A (ja) |
| BR (1) | BR0010924B1 (ja) |
| DE (1) | DE60035417T2 (ja) |
| HK (1) | HK1044431B (ja) |
| WO (1) | WO2000074259A2 (ja) |
Families Citing this family (59)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4015773B2 (ja) * | 1999-03-10 | 2007-11-28 | 松下電器産業株式会社 | 送受信装置 |
| KR100416996B1 (ko) * | 1999-05-10 | 2004-02-05 | 삼성전자주식회사 | 이동 통신시스템에서 라디오링크프로토콜에 따른 가변 길이의 데이터 송수신 장치 및 방법 |
| KR100532321B1 (ko) * | 1999-05-21 | 2005-11-29 | 삼성전자주식회사 | 이동 통신시스템에서 라디오링크프로토콜에 따른 가변 길이의 블록 일련번호 생성 및 바이트 일련번호 확인 장치 및 방법 |
| KR100539879B1 (ko) * | 1999-06-29 | 2005-12-28 | 삼성전자주식회사 | 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 송수신 장치 및 방법 |
| US7149193B2 (en) * | 1999-12-15 | 2006-12-12 | Nortel Networks Limited | Dynamic, dual-mode wireless network architecture with a split layer 2 protocol |
| FI109862B (fi) * | 2000-01-10 | 2002-10-15 | Nokia Corp | Menetelmä taajuudenvälisen yhteydenvaihdon valmistelemiseksi, verkkoelementti ja matkaviestin |
| US7315544B2 (en) * | 2000-01-21 | 2008-01-01 | Bytemobile, Inc. | Global sequence numbers in wireless communications systems and methods |
| US6859456B1 (en) * | 2000-03-13 | 2005-02-22 | Motorola, Inc. | Method and apparatus for checking communicated data |
| KR100667739B1 (ko) * | 2000-06-09 | 2007-01-12 | 삼성전자주식회사 | 무선 데이터 송수신 장치 및 그 방법 |
| EP1175063A3 (en) * | 2000-07-20 | 2003-08-27 | Nortel Networks Limited | Network layer protocol aware link layer |
| KR100447162B1 (ko) * | 2000-08-19 | 2004-09-04 | 엘지전자 주식회사 | 래디오 링크 콘트롤(ｒｌｃ)에서 프로토콜 데이터 유닛(ｐｄｕ) 정보의 길이 지시자(ｌｉ) 처리방법 |
| US7746953B1 (en) * | 2000-09-12 | 2010-06-29 | Alcatel-Lucent Usa Inc. | Method and apparatus for asynchronous incremental redundancy transmission in a communication system |
| US7031257B1 (en) * | 2000-09-22 | 2006-04-18 | Lucent Technologies Inc. | Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol |
| TW511340B (en) * | 2000-12-12 | 2002-11-21 | Elan Microelectronics Corp | Method and system for data loss detection and recovery in wireless communication |
| DE10108146A1 (de) * | 2001-02-20 | 2002-08-29 | Siemens Ag | Datenübertragungsverfahren |
| US7096261B2 (en) * | 2001-03-12 | 2006-08-22 | Qualcomm Incorporated | Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection |
| US7170896B2 (en) * | 2001-06-20 | 2007-01-30 | Motorola, Inc. | Communication infrastructure and method to preserve communication link bandwidth in a packet communication session |
| KR100735692B1 (ko) * | 2001-07-12 | 2007-07-06 | 엘지전자 주식회사 | 적응 부호화와 재전송을 이용한 부호화 변환 방법 |
| US7362707B2 (en) * | 2001-07-23 | 2008-04-22 | Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
| US7327694B2 (en) * | 2001-07-31 | 2008-02-05 | Sasken Communication Technologies Ltd. | Adaptive radio link protocol (RLP) to improve performance of TCP in wireless environment for CDMAone and CDMA2000 systems |
| US7856660B2 (en) * | 2001-08-21 | 2010-12-21 | Telecommunication Systems, Inc. | System for efficiently handling cryptographic messages containing nonce values |
| JP3912091B2 (ja) * | 2001-12-04 | 2007-05-09 | ソニー株式会社 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| US20030126196A1 (en) * | 2001-12-27 | 2003-07-03 | Todd Lagimonier | System for optimizing the invocation of computer-based services deployed in a distributed computing environment |
| US7280480B2 (en) * | 2002-01-07 | 2007-10-09 | Motorola, Inc. | Method and apparatus for transmitting and receiving data |
| US8233501B2 (en) * | 2002-02-13 | 2012-07-31 | Interdigital Technology Corporation | Transport block set segmentation |
| US6975650B2 (en) * | 2002-02-13 | 2005-12-13 | Interdigital Technology Corporation | Transport block set segmentation |
| US7167476B1 (en) * | 2002-04-12 | 2007-01-23 | Juniper Networks, Inc. | Systems and methods for routing data in a network device |
| EP1495566A4 (en) * | 2002-04-15 | 2005-07-20 | Nokia Corp | RLP LOGIC LAYER OF A COMMUNICATION STATION |
| KR100547842B1 (ko) * | 2002-07-29 | 2006-01-31 | 삼성전자주식회사 | 무선 패킷 데이터 통신 시스템에서 서로 다른 데이터 유형들을 전송하는 장치 |
| US7414989B2 (en) * | 2003-05-07 | 2008-08-19 | Motorola, Inc. | ACK/NACK determination reliability for a communication device |
| JP2005033399A (ja) * | 2003-07-10 | 2005-02-03 | Fujitsu Ltd | パケット送受信装置 |
| KR100565627B1 (ko) * | 2003-10-13 | 2006-03-29 | 엘지전자 주식회사 | 이동통신 시스템에서의 고속 데이터 통신을 위한 라디오링크 프로토콜 제어 프레임 및 그것을 이용한 라디오 링크프로토콜 시퀀스의 업데이트 방법 |
| US7197026B2 (en) * | 2003-12-23 | 2007-03-27 | Nokia Corporation | Method and system for RLP optimization |
| KR100714675B1 (ko) * | 2004-01-30 | 2007-05-07 | 삼성전자주식회사 | 데이터 프레임 재전송 방법 및 상기 방법을 사용하는네트워크 장치 |
| GB0414057D0 (en) * | 2004-06-23 | 2004-07-28 | Koninkl Philips Electronics Nv | Method of,and system for,communicating data, and a station for transmitting data |
| US7539214B2 (en) * | 2004-12-08 | 2009-05-26 | Motorola, Inc. | Variable reliability wireless communication transmission method and apparatus |
| EP1834424B1 (en) * | 2005-01-03 | 2016-08-31 | Nokia Technologies Oy | Method and device of frame number encoding for synchronization of electronic devices |
| FR2882599B1 (fr) * | 2005-02-25 | 2007-05-04 | Somfy Soc Par Actions Simplifi | Systeme de communication avec comptabilite croisee et trame de communication associee |
| US8867336B2 (en) * | 2005-09-28 | 2014-10-21 | Qualcomm Incorporated | System for early detection of decoding errors |
| US8208474B2 (en) * | 2006-07-31 | 2012-06-26 | Samsung Electronics Co., Ltd | Method and apparatus for transmitting/receiving packet in a mobile communication system |
| US7661038B2 (en) * | 2006-10-09 | 2010-02-09 | Intel Corporation | Link adaptation for retransmission error-control technique transmissions |
| DK2958393T3 (en) | 2006-11-01 | 2018-04-23 | Ericsson Telefon Ab L M | DISTRIBUTION OF BROADCAST / MULTICAST DATA IN TELECOMMUNICATION SYSTEMS |
| US7453379B2 (en) * | 2007-03-12 | 2008-11-18 | Citrix Systems, Inc. | Systems and methods for identifying long matches of data in a compression history |
| US8255570B2 (en) | 2007-03-12 | 2012-08-28 | Citrix Systems, Inc. | Systems and methods of compression history expiration and synchronization |
| US7460038B2 (en) | 2007-03-12 | 2008-12-02 | Citrix Systems, Inc. | Systems and methods of clustered sharing of compression histories |
| US7865585B2 (en) | 2007-03-12 | 2011-01-04 | Citrix Systems, Inc. | Systems and methods for providing dynamic ad hoc proxy-cache hierarchies |
| US7827237B2 (en) | 2007-03-12 | 2010-11-02 | Citrix Systems, Inc. | Systems and methods for identifying long matches of data in a compression history |
| US7532134B2 (en) * | 2007-03-12 | 2009-05-12 | Citrix Systems, Inc. | Systems and methods for sharing compression histories between multiple devices |
| US7619545B2 (en) * | 2007-03-12 | 2009-11-17 | Citrix Systems, Inc. | Systems and methods of using application and protocol specific parsing for compression |
| US7712150B2 (en) * | 2007-10-01 | 2010-05-11 | Pardillo Joseph M | Protective pad assembly magnetically attachable to garment |
| US20110286404A1 (en) * | 2009-11-20 | 2011-11-24 | Qualcomm Incorporated | Method and apparatus for seamless transitions of transfer between radio links for data reception |
| US20110286322A1 (en) * | 2009-11-20 | 2011-11-24 | Qualcomm Incorporated | Method and apparatus for seamless transitions of data transmission transfer between radio links |
| US8743763B2 (en) * | 2010-07-23 | 2014-06-03 | Qualcomm Incorporated | User device dormancy |
| US9510285B2 (en) | 2010-07-23 | 2016-11-29 | Qualcomm Incorporated | User device dormancy |
| US9055464B2 (en) * | 2011-07-07 | 2015-06-09 | Optis Cellular Technology, Llc | RLC Data transmission control based on UE memory capacity |
| CN108541359B (zh) * | 2016-02-05 | 2022-04-22 | 英特尔公司 | 用于nb-iot系统中npdcch和npdsch资源映射的系统和方法 |
| CN111512579A (zh) * | 2018-03-30 | 2020-08-07 | 英特尔公司 | 多接入管理服务分组恢复机制 |
| US10892858B2 (en) | 2018-09-28 | 2021-01-12 | At&T Intellectual Property I, L.P. | Chain broadcasting in vehicle-to-everything (V2X) communications |
| US10972958B1 (en) | 2020-03-05 | 2021-04-06 | At&T Intellectual Property I, L.P. | Location-based route management for vehicle-to-everything relay communications |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1220830A (en) * | 1984-12-28 | 1987-04-21 | David S. Drynan | Transmitting sequence numbers of information in a packet data transmission system |
| JPS6251326A (ja) * | 1985-08-30 | 1987-03-06 | Oki Electric Ind Co Ltd | デ−タ通信における再送制御方式 |
| JPH02112327A (ja) * | 1988-10-21 | 1990-04-25 | Fujitsu Ltd | パケット衛星通信方式 |
| JPH0454046A (ja) * | 1990-06-22 | 1992-02-21 | Nippon Telegr & Teleph Corp <Ntt> | Ｉｓｄｎ通信制御装置 |
| JPH04168841A (ja) * | 1990-11-01 | 1992-06-17 | Nec Eng Ltd | フレーム送受信方式 |
| US5151899A (en) | 1991-02-11 | 1992-09-29 | Digital Equipment Corporation | Tracking sequence numbers in packet data communication system |
| US6088342A (en) * | 1997-05-05 | 2000-07-11 | Nokia Mobile Phones Limited | Dynamic configuration of radio link protocol in a telecommunications system |
| US5610595A (en) * | 1991-12-09 | 1997-03-11 | Intermec Corporation | Packet radio communication system protocol |
| US5337313A (en) * | 1992-11-12 | 1994-08-09 | Motorola, Inc. | Method and apparatus for preserving packet squencing in a packet transmission system |
| US5444709A (en) | 1993-09-30 | 1995-08-22 | Apple Computer, Inc. | Protocol for transporting real time data |
| US5920352A (en) * | 1994-10-28 | 1999-07-06 | Matsushita Electric Industrial Co., Ltd. | Image memory storage system and method for a block oriented image processing system |
| US5553083B1 (en) * | 1995-01-19 | 2000-05-16 | Starburst Comm Corp | Method for quickly and reliably transmitting frames of data over communications links |
| JPH08223217A (ja) * | 1995-02-08 | 1996-08-30 | Nippon Telegr & Teleph Corp <Ntt> | 無線パケット多重方法 |
| US5703902A (en) * | 1995-06-16 | 1997-12-30 | Qualcomm Incorporated | Method and apparatus for determining signal strength in a variable data rate system |
| FI101332B1 (fi) * | 1995-12-18 | 1998-05-29 | Nokia Telecommunications Oy | Epäjatkuvalähetys monikanavaisessa suurinopeuksisessa datasiirrossa |
| US5771033A (en) * | 1996-05-24 | 1998-06-23 | Microsoft Corporation | Method and system for dissolving an image displayed on a computer screen |
| CA2270604A1 (en) * | 1996-11-08 | 1998-05-14 | Atx Research, Inc. | Cellular telephone communication protocol |
| US6314101B1 (en) * | 1997-06-17 | 2001-11-06 | Qualcomm Incorporated | Method for detecting delayed data frames in a transport function |
| KR100234134B1 (ko) * | 1997-08-29 | 1999-12-15 | 윤종용 | 디지털 셀롤러 무선 복합단말기에서 수신 데이터 관리방법 |
| US6317430B1 (en) * | 1998-02-19 | 2001-11-13 | Lucent Technologies Inc. | ARQ protocol support for variable size transmission data unit sizes using a hierarchically structured sequence number approach |
| US6226301B1 (en) * | 1998-02-19 | 2001-05-01 | Nokia Mobile Phones Ltd | Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system |
| KR100282403B1 (ko) * | 1998-08-20 | 2001-02-15 | 서평원 | 이동통신 시스템에서 전파 회선 프로토콜의 프레임 전송 방법 |
| US6167273A (en) * | 1999-04-28 | 2000-12-26 | Nokia Mobile Phones Ltd. | Apparatus, and associated method, for effectuating power control to maintain desired QoS levels in the performance of a communication service |
| JP2002314601A (ja) * | 2001-04-18 | 2002-10-25 | Ntt Docomo Inc | 受信状態報告方法、ノード装置及び受信装置 |
-
1999
- 1999-05-27 US US09/321,296 patent/US6507582B1/en not_active Expired - Lifetime
- 1999-07-28 US US09/362,953 patent/US7123617B1/en not_active Expired - Lifetime
-
2000
- 2000-05-26 EP EP00939379A patent/EP1183846B1/en not_active Expired - Lifetime
- 2000-05-26 EP EP07007397A patent/EP1865682A3/en not_active Withdrawn
- 2000-05-26 BR BRPI0010924-0A patent/BR0010924B1/pt not_active IP Right Cessation
- 2000-05-26 DE DE60035417T patent/DE60035417T2/de not_active Expired - Lifetime
- 2000-05-26 CN CNB008081093A patent/CN1165146C/zh not_active Expired - Lifetime
- 2000-05-26 AT AT00939379T patent/ATE366497T1/de not_active IP Right Cessation
- 2000-05-26 AU AU54470/00A patent/AU5447000A/en not_active Abandoned
- 2000-05-26 KR KR1020017015195A patent/KR100714505B1/ko active IP Right Grant
- 2000-05-26 WO PCT/US2000/014699 patent/WO2000074259A2/en active IP Right Grant
- 2000-05-26 JP JP2001500453A patent/JP4519382B2/ja not_active Expired - Lifetime
-
2002
- 2002-08-13 HK HK02105913.1A patent/HK1044431B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| EP1865682A3 (en) | 2010-05-26 |
| JP2003501865A (ja) | 2003-01-14 |
| DE60035417T2 (de) | 2008-03-13 |
| BR0010924B1 (pt) | 2014-01-28 |
| US6507582B1 (en) | 2003-01-14 |
| KR100714505B1 (ko) | 2007-05-07 |
| HK1044431A1 (en) | 2002-10-18 |
| DE60035417D1 (de) | 2007-08-16 |
| EP1183846B1 (en) | 2007-07-04 |
| CN1165146C (zh) | 2004-09-01 |
| ATE366497T1 (de) | 2007-07-15 |
| EP1183846A2 (en) | 2002-03-06 |
| BR0010924A (pt) | 2002-04-02 |
| US7123617B1 (en) | 2006-10-17 |
| HK1044431B (zh) | 2005-04-22 |
| CN1352848A (zh) | 2002-06-05 |
| WO2000074259A3 (en) | 2001-05-03 |
| WO2000074259A2 (en) | 2000-12-07 |
| AU5447000A (en) | 2000-12-18 |
| EP1865682A2 (en) | 2007-12-12 |
| KR20020030273A (ko) | 2002-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4519382B2 (ja) | 動的容量無線データ・チャンネルのための無線回線プロトコルの改良 | |
| RU2249923C2 (ru) | Механизм сортировки кадров протокола радиосвязи для беспроводных каналов данных с динамической емкостью | |
| KR100594543B1 (ko) | 통신시스템에서 무선링크 프로토콜을 동적으로 구성하는 방법 및 그 장치 | |
| US6226301B1 (en) | Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system | |
| JP4842480B2 (ja) | データ呼出しの設定時間を低減する無線通信回線プロトコルの改良 | |
| US6189122B1 (en) | Method and apparatus for controlling data retransmission | |
| EP1833189B1 (en) | Method and apparatus for efficient data retransmission in a voice-over-data communication system | |
| KR100282403B1 (ko) | 이동통신 시스템에서 전파 회선 프로토콜의 프레임 전송 방법 | |
| US7936664B2 (en) | Multi-carrier radio link protocol supervision in a radio communication system | |
| JP2002521936A (ja) | 通信システムのオーバヘッドの最小化方法及び装置 | |
| KR100720786B1 (ko) | 정보 바이트 스트림을 전송 또는 수신하는 방법, 시스템,송신기 및 수신기 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070522 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070522 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091023 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091104 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100204 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100212 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100304 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100311 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100318 |
|
| 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: 20100420 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100519 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130528 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4519382 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130528 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |