(57)【要約】データパケットを受信する動作を行なう方法や移動局のようなデバイス、デジタル処理装置で実行可能なマシン読み出し可能命令からなるプログラムを具現化する情報記憶媒体が開示される。この受信動作は、受信されたデータパケットの正誤を確認し、誤ったTCP層ヘッダチェックサムを有することが判明したデータパケットを格納し、受信されたデータパケットの送信側に信号で通知し、以前に受信された誤りのあるデータパケットの次回の受信に応じて次回に受信されたデータパケットの正誤を確認し、正しい場合は、次回に受信されたデータパケットヘッダの正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータパケットの正誤を再確認する処理を含む。受信データパケットの正誤はPPP層FCSチェックサムやIP層ヘッダチェックサム、TCP層チェックサムで確認されることが好ましい。データパケットヘッダはV−Jヘッダ圧縮技術を使用して圧縮されることが好ましい。【選択図】図7
2007532073.tif 000002
【特許請求の範囲】
【請求項１】
データ・パケットを受信する動作を行なう、デジタル処理装置で実行可能なマシン読み出し可能命令からなるプログラムを具現化する情報記憶媒体において、該動作は、
受信されたデータ・パケットの正誤を確認し、
誤ったTCP層チェックサムを有することが判明したデータ・パケットを格納し、該受信されたデータ・パケットの送信側に信号で通知し、
以前に受信された誤りのあるデータ・パケットの別のインスタンスの受信に応じて、該受信された別のインスタンスのデータ・パケットの正誤を確認し、正しい場合は、該受信された別のインスタンスのデータ・パケットのヘッダの正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータ・パケットの正誤を再確認する処理を含む情報記憶媒体。
【請求項２】
前記受信されたデータ・パケットの前記正誤が、PPP層FCSチェックサム、IP層ヘッダ・チェックサムおよびTCP層チェックサムで確認される、請求項1に記載の情報記憶媒体。
【請求項３】
前記ヘッダの前記正誤がTCP層チェックサムを得ることで確認される、請求項1に記載の情報記憶媒体。
【請求項４】
データ・パケット・ヘッダが圧縮されている、請求項1に記載の情報記憶媒体。
【請求項５】
データ・パケット・ヘッダがV−Jヘッダ圧縮技術を使用して圧縮されている、請求項1に記載の情報記憶媒体。
【請求項６】
少なくとも1つの格納されたデータ・パケットの前記正誤の再確認に応じて、前記以前に格納されたデータ・パケットを含めて前記データ・パケットが正しく受信されたことを通知するため、前記受信されたデータ・パケットの前記送信側に応答確認を送信する処理をさらに含む、請求項1に記載の情報記憶媒体。
【請求項７】
前記デジタル処理装置が移動局の一部を形成し、前記データ・パケットが無線チャネルを介して受信されるTCP／IP／PPPデータ・パケットである、請求項1に記載の情報記憶媒体。
【請求項８】
受信されたデータ・パケットの正誤を確認し、
誤ったTCP層チェックサムを有することが判明したデータ・パケットを格納し、該受信されたデータ・パケットの送信側に信号で通知し、
以前に受信された誤りのあるデータ・パケットの別のインスタンスの受信に応じて、該受信された別のインスタンスのデータ・パケットの正誤を確認し、正しい場合は、該受信された別のインスタンスのデータ・パケットのヘッダの該正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータ・パケットの該正誤を再確認するデータ・パケットの受信方法。
【請求項９】
前記受信されたデータ・パケットの前記正誤が、PPP層FCSチェックサム、IP層ヘッダ・チェックサムおよびTCP層チェックサムで確認される、請求項8に記載の方法。
【請求項１０】
前記ヘッダの前記正誤がTCP層チェックサムを得ることで確認される、請求項8に記載の方法。
【請求項１１】
前記データ・パケット・ヘッダが圧縮されている、請求項8に記載の方法。
【請求項１２】
前記データ・パケット・ヘッダがV−Jヘッダ圧縮技術を使用して圧縮されている、請求項8に記載の方法。
【請求項１３】
少なくとも1つの格納されたデータ・パケットの前記正誤の再確認に応じて、前記以前に格納されたデータ・パケットを含めて前記データ・パケットが正しく受信されたことを通知するため、前記受信されたデータ・パケットの前記送信側に応答確認を送信する方法をさらに含む、請求項8に記載の方法。
【請求項１４】
前記方法が、移動局の一部を形成するデジタル処理装置により実行され、前記データ・パケットが無線チャネルを介して受信されるTCP／IP／PPPデータ・パケットである、請求項8に記載の方法。
【請求項１５】
チャネルを介してデータ・パケットを受信するインターフェースを備えるデバイスにおいて、受信されたデータ・パケットの正誤を確認し、誤っていると判断されたデータ・パケットを格納し、該受信されたデータ・パケットの送信側に信号で通知し、以前に受信された誤りのあるデータ・パケットの別のインスタンスの受信に応じて、該受信された別のインスタンスのデータ・パケットの正誤を確認し、正しい場合は、該受信された別のインスタンスのデータ・パケットのヘッダの正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータ・パケットの正誤を再確認するように協働するデータ処理装置およびメモリをさらに含むデバイス。
【請求項１６】
前記受信されたデータ・パケットの前記正誤が、PPP層FCSチェックサム、IP層ヘッダ・チェックサムおよびTCP層チェックサムを使用して確認される、請求項15に記載のデバイス。
【請求項１７】
前記ヘッダの前記正誤がTCP層チェックサムを得ることで確認される、請求項15に記載のデバイス。
【請求項１８】
前記データ・パケット・ヘッダが圧縮されている、請求項15に記載のデバイス。
【請求項１９】
前記データ・パケット・ヘッダがV−Jヘッダ圧縮技術を使用して圧縮されている、請求項15に記載のデバイス。
【請求項２０】
少なくとも1つの格納されたデータ・パケットの前記正誤の再確認に応じて、前記以前に格納されたデータ・パケットを含めて前記データ・パケットが正しく受信されたことを通知するため、前記受信されたデータ・パケットの前記送信側に応答確認を送信する動作をさらに含む、請求項15に記載のデバイス。
【請求項２１】
前記デバイスが移動局を備え、前記データ・パケットが無線チャネルを介して受信されるTCP／IP／PPPデータ・パケットである、請求項15に記載のデバイス。
【請求項２２】
チャネルを介してデータ・パケットを受信する手段と、
受信されたデータ・パケットの正誤を確認する手段と、
誤っていると判断されたデータ・パケットを格納する手段と、
該受信されたデータ・パケットの送信側に信号で通知する手段と
を含む装置であって、
以前に受信された誤りのあるデータ・パケットの別のインスタンスの受信に応じて、該受信された別のインスタンスのデータ・パケットの正誤を確認し、正しい場合は、該受信された別のインスタンスのデータ・パケットのヘッダの正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータ・パケットの正誤を再確認する装置。
【請求項２３】
前記受信されたデータ・パケットの前記正誤が、PPP層FCSチェックサム、IP層ヘッダ・チェックサムおよびTCP層チェックサムを使用することで確認される、請求項22に記載の装置。
【請求項２４】
前記ヘッダの前記正誤がTCP層チェックサムを得ることで確認される、請求項22に記載の装置。
【請求項２５】
データ・パケット・ヘッダが圧縮されている、請求項22に記載の装置。
【請求項２６】
データ・パケット・ヘッダがV−Jヘッダ圧縮技術を使用して圧縮されている、請求項22に記載の装置。
【請求項２７】
少なくとも1つの格納されたデータ・パケットの前記正誤の再確認に応じて、以前に誤っていると判断された該少なくとも1つの格納されたデータ・パケットを含めてデータ・パケットが正しく受信されたことを通知するため、前記受信されたデータ・パケットの前記送信側に応答確認を送信する手段をさらに含む、請求項22に記載の装置。
【請求項２８】
データ・パケットが無線チャネルを介して受信されるTCP／IP／PPPデータ・パケットである、移動局として具現化された請求項22に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にデータ通信ネットワークを介したデータ伝送に関し、特にヘッダ圧縮を用いたTCP／IP（伝送制御プロトコル／インターネットプロトコル（Transfer Control Protocol/Internet Protocol））データ・パケット伝送に関する。ここで、ヘッダ圧縮技術は、周知のヘッダ圧縮技術であるIETF RFC1144「低速シリアル・リンクでのTCP／IPヘッダの圧縮（Compressing TCP/IP Headers for Low-Speed Serial Links）」，1990年2月に記載のV.ヤコブソン（V.Jacobson）ヘッダ圧縮（V−Jヘッダ圧縮）が好ましい。
【背景技術】
【０００２】
TCP／IPヘッダ圧縮（V−Jヘッダ圧縮）では、シリアル接続されたPPP（ポイントツーポイント・プロトコル（Point-to-Point Protocol））リンクを介し、40バイトのTCP／IPヘッダをわずか3、4バイトに圧縮することが可能である。このようなヘッダ圧縮技術の使用は、転送されたデータが物理インターフェース上の障害および他の障害により、消失されたり、歪められたりすることがほとんどないメディア信頼性のある環境においては、一般的にスループットについての問題は無い。
【０００３】
しかし、無線データ伝送環境などの信頼性の低い伝送リンク環境では、ノイズは一般にバースト性がある。したがって、データ・パケットの消失が一般的に起こる。例えば、第一世代の無線CDMA（符号分割多重接続（code division multiple access））では、RLP（ラジオ・リンク・プロトコル（radio link protocol））がPPP層の下位のリンク層としてデータ転送に使用される。RLPは、ベストエフォート型のプロトコルであり、消失したフレームに対し数回の修復のみを行なう。さらに、RLPは消失したフレームを修復できない場合、破損したフレームを上位のレイヤに引き渡す。
【０００４】
V−Jヘッダ圧縮は、以前に受信された順序の整った正しいパケットに基づいて、圧縮されたTCP／IPヘッダからの情報を復元する。その結果、CDMA無線データ転送の間、TCP／IPのV−Jヘッダ圧縮が使用されている場合、1つのデータ・パケット消失が、以降受信されるすべてのデータ・パケットのデコーディング障害を引き起こし得る。以降受信されるパケットの合計サイズ（バイト）は、通知されているTCP受信側のウィンドウ・サイズ全体にもなり得る。デコーディング障害は、TCPヘッダ部の誤って復元されたTCPシーケンス番号により、誤ったTCPチェックサムとして示される。
【０００５】
RFC1144の4.2章は、「エラー・リカバリ」（Error Recovery）と題され、CRCエラーの発生後、デコンプレッサに再び有効なパケットを生成させる技術が提案されている。
【０００６】
現在、誤ったTCPチェックサムを有するこれらのデータ・パケットは（データ・ペイロードは正しくても）、暗に破棄される。また、データ・パケットが受信側により暗に破棄されるため、ピアTCP（すなわち、データ送信側）の高速再送／リカバリ・アルゴリズムを作動するTCPのACK（応答確認）が送り返されない。この問題は、エアチャネル・リソースの浪費および低いデータ転送スループットを引き起こす。
【０００７】
図1は、典型的なTCP／IP／PPPプロトコル・スタック・インプリメンテーションである。ここで、ピア・アプリケーションに届けることが必要とされるユーザ・データ1のブロックがあるとする。ユーザ・データ1は、まず、TCP層2に届けられる。TCP層2は、ユーザ・データ1のブロックを、いくつかのセグメントに分割できる。各セグメントに対し、TCP層2は、データをフレームのペイロード部に格納し、TCPヘッダ2Aでラップし、TCPフレームにする。図2は、ヘッダ部に16ビットのチェックサム部を有する、従来のTCPフレーム・フォーマットを示している。次に、TCP層2は、TCPフレーム全体をIP層3に届ける。IP層3は、TCPフレーム全体をデータとみなし、これをフレームのペイロード部内に置き、IPヘッダ3Aを追加し、IPフレームを生成する。図3は、16ビットのヘッダ・チェックサムを有する従来のIPフレームフォーマットを示している。IPフレームは、その後、PPP層4に届けられ、PPPペイロード部内に置かれ、ラップされてPPPヘッダ4Aを有するPPPフレームになる。図4は、16ビットのフレーム・チェック・シーケンス（16ビットCRCチェックである、FCS）を有する、従来のPPPフレーム・フォーマットである。PPPフレームは、ピアに引き渡されるよう、下位の層に届けられる。例えば、第一世代の無線CDMAシステムでは、下位層はRLP層およびIS2000／IS−95物理層である。
【０００８】
図2および図3より、IPヘッダおよびTCPヘッダ共に20バイトで構成されていることがわかる。V−Jヘッダ圧縮が使用されている場合、合計40バイトのTCP／IPヘッダがおよそ3（フラグビット1バイトおよびTCPチェックサム2バイト）から4バイトに圧縮され、フレーム間の差分のみを転送することができる。
【０００９】
無線環境では、データ転送は、しばしば次の例のように行なわれることがある。
フレーム番号
1    2    3    4    5    6    7
X    X    Y    Z    Z    Z    Z
ここで
Xは、良好で順序の正しい受信フレームを示し、
Yは、RLP層でのデータ消失または破損による破損したPPPフレームを示し、
Zは、順序の誤った受信フレームを示している。
【００１０】
破損したYフレーム番号3では、フレーム中のいくつかのバイト（またはビット）が消失または変更されていることがあり、その場合、通常はPPP層でのFCSチェックを通らないフレームとなる。その結果、このフレームはPPP層で破棄されることになる。
【００１１】
V−Jヘッダ圧縮がオフされている場合、Zフレーム（フレーム4、5、6および7）は良好なPPP層のFCS、良好なIPヘッダ・チェックサムおよびTCPチェックサムを有する。Zフレームを受信するごとに、TCP受信側は、そのフレームをバッファに格納する。また、TCP ACKパッケージをデータ送信側に送り返し、パケット番号3までのすべてのデータ・パケットを受信したことを送信側に知らせる。例えば、データ受信側がフレーム4、5、6および7の4つのZフレームを受信すると、それぞれがパケット番号2の応答確認番号を有する4つのTCP ACKフレームをデータ送信側に返送する。データ送信側は、同じパケット番号2を通知している3つまたはそれ以上の連続したTCP ACKフレームを受信すると、パケット番号3が消失していることを直ちに知る。そして、データ送信側は、データ・パケット番号3を直ちに再送するが、パケット番号3のみの再送である。データ受信側が、破損したフレーム番号3を受信した場合、フレーム番号7までのすべてのデータについての応答確認をするためTCP ACKを送信する。したがって、すべてのZフレームが有効となる。これは、高速再送および高速リカバリ・アルゴリズムと呼ばれ、RFC2581で定義されている。ほとんどすべてのTCPプロトコル・スタックがこのアルゴリズムを実装している。
【００１２】
次に、V−Jヘッダ圧縮がオン（使用）されている場合を考えると、フレーム番号4、5、6および7は良好なPPP層フレーム・チェックサム（FCS）を有し、IP層に引き渡される。IP層では、1つのTCP接続に対してすべてのパケットが同じIPヘッダ情報を有するため、IPヘッダが正しく復元され、IPヘッダ・チェックも正しいものとなる。その結果、データをTCP層に渡すことができる。しかし、フレーム番号3が消失しており、TCP層はTCPシーケンス番号のデコードをフレーム順に基づいて行なうため、すべてのZフレームが不良のTCP層・ヘッダを示すことになり、これがエラーのあるTCPチェックサムを引き起こす。したがって、これらのZフレームは直ちに破棄される。よって、Zフレームすべてが正しいデータを含んでいるにもかかわらず、TCPヘッダが正しく復元できず、不良であるとみなされるため、使用されない。さらに、データ送信側にTCP ACKフレームは送り返されず、高速再送および高速リカバリ・アルゴリズムは作動しない。この場合、データ送信側は、自身の再送タイマのタイムアウトにしたがって、フレーム4、5、6および7のすべてを再送するよう要求されるが、これにより再送が行なわれるまでの間にかなりの遅延が生じる可能性がある。この遅延期間の間、データは送信されず、データ転送スループットが低減することになる。
【００１３】
したがって、V−Jヘッダ圧縮がオンであることによりTCP／IPパケットが消失される場合、結果としてTCPチェックサムが残りのTCPウィンドウ・セグメントでは誤っていることが理解されよう。その結果、TCP層2は、誤ったチェックサムを有するパケットを暗に破棄するので、ネットワーク・チャネルの容量を無駄にする。現代のセルラータイプの通信システムのような無線通信システムでは、チャネルの帯域幅の有効利用が考慮すべき重要な点であるため、この問題は、ユーザおよびネットワーク・オペレータの両者に対して多くの不利益をもたらす。
【非特許文献１】IETF RFC1144「低速シリアル・リンクでのTCP／IPヘッダの圧縮（Compressing TCP/IP Headers for Low-Speed Serial Links）」，1990年2月に記載のV.ヤコブソン（V.Jacobson）ヘッダ圧縮（V−Jヘッダ圧縮）
【発明の好適な実施形態のまとめ】
【００１４】
これらの教示に対して現在好適な実施形態によれば、上記およびその他の問題が解決され、他の有利な点が実現される。
【００１５】
本発明により、データ・パケットを受信する動作を行なう、方法、移動局などの装置、およびデジタル処理装置で実行可能なマシン読み出し可能命令からなるプログラムを具現化する情報記憶媒体が提供される。この受信動作は、受信されたデータ・パケットの正誤を確認し、誤ったTCP層ヘッダ・チェックサムを有することが判明したデータ・パケットを格納し、受信されたデータ・パケットの送信側に信号で通知し、以前に受信された誤りのあるデータ・パケットの別のインスタンスの受信に応じて、該受信された別のインスタンスのデータ・パケットの正誤を確認し、正しい場合は、該受信された別のインスタンスのデータ・パケットのヘッダの正誤を確認することによって得られた情報を使用して、以前に誤っていると判断された少なくとも1つの格納されたデータ・パケットの正誤を再確認する処理を含む。受信データ・パケットの正誤は、PPP層FCSチェックサム、IP層ヘッダ・チェックサムおよびTCP層チェックサムで確認されることが好ましい。データ・パケット・ヘッダは、V−Jヘッダ圧縮技術を使用して圧縮されることが好ましい。
【００１６】
また、少なくとも1つの格納されたデータ・パケットが正しいことを再確認されると、データ・パケットが誤った順序で受信されたことを通知するため、受信されたデータ・パケットの送信側に応答確認を送信し、データ送信側の高速再送および高速リカバリを作動させる処理をさらに含む。
【００１７】
本発明の限定されない好適な一実施例において、デジタル処理装置は移動局の一部を形成し、データ・パケットは無線チャネルを介して受信されるTCP／IP／PPPデータ・パケットである。
【００１８】
これらの教示の上記およびその他の態様は、以下の発明を実施するための最良の形態を添付の図面とともに読むことで明らかになるであろう。
【好適な実施形態の詳細な説明】
【００１９】
IETF RFC1144「低速シリアル・リンクでのTCP／IPヘッダの圧縮（Compressing TCP/IP Headers for Low-Speed Serial Links）」（V−Jヘッダ圧縮），1990年2月の開示は、その内容を参照によって本願明細書に援用したものとする。
【００２０】
ここで、説明のため図7を参照すると、本発明の実施に適した無線通信システム10の実施例を示す簡略ブロック図が示されている。無線通信システム10は、少なくとも1つの移動局（MS）100を備えている。また、図7において、例えば公衆パケット・データ網（PDN）等の電気通信網に接続するためのノード30、少なくとも1つの基地局制御装置（BSC）40または同等の装置、および所定のエアインターフェース規格に従って、フォワードまたはダウンリンク方向へ物理的および論理的チャネルを使用して移動局100に対して伝送を行なう、基地局（BS）とも称される複数の基地送受信局（BTS）50を有する、例としてのネットワーク・オペレータ20が示されている。また、移動局100からネットワーク・オペレータ20へのリバースまたはアップリンク通信路もあり、モバイルからのアクセス要求やトラフィックを伝える。セルは、各BTS50に対して各々に設けられており、1つのセルをある時点でサービング・セルと考えると、これに隣接するセルは隣接セルと考えられる。セルは、より小さいセル（例えば、ピコセル）であってもよい。
【００２１】
エアインターフェース規格は、適切な規格またはプロトコルに準拠することができ、音声およびデータ・トラフィックの両方を可能とでき、データ・トラフィックではインターネット70へのアクセスやウェブ・ページのダウンロード等も可能とできる。本発明の好適な実施例においては、エアインターフェース規格は、cdma2000として知られるようなCDMA（符号分割多重接続（code division multiple access））のエアインターフェース規格と互換性があるが、これは本発明の実施形態を限定するものではない。
【００２２】
移動局100は、ディスプレイ140の入力に結合された出力とキーボードまたはキーパッド160の出力に結合された入力を有する、マイクロ・コントロール・ユニット（MCU）120のような制御ユニットまたは制御ロジックを一般的に備えている。移動局100は、携帯電話またはパーソナル・コミュニケータなどの携帯用無線電話機であってもよい。移動局100は、使用時、他のデバイスに接続されるカードまたはモジュールに含まれていても良い。例えば、移動局100は、使用時、ラップトッブ、ノートブック・コンピュータ、またはユーザが持ち運び可能なコンピュータ等の携帯用データ処理装置に取り付けられたPCMCIAまたは同類のカードもしくはモジュールに含まれていてもよい。
【００２３】
MCU120は、必要なデータを一時的に格納する揮発性メモリ、スクラッチパッドメモリ、受信されたパケット・データ、送信されるパケット・データなどに加えて、動作プログラムおよびその他の情報を格納する不揮発性メモリなどのある種のメモリ130を備えるか、これに接続していることとする。メモリ130の一部は、以下で詳細に説明する、誤ったTCPチェックサムを有した受信パケットをバッファリングするパケット・バッファ130Aを形成している。本発明の目的において、この動作プログラムは、MCU120が本発明に係る方法を実現させるために必要なソフトウェア・ルーチン、レイヤおよびプロトコルを実行させることを可能とするものとする。例えば、動作プログラムはTCP、IPおよびPPP層およびプロトコルを図1から図4で示されるように実現し、また受信されたV−Jヘッダ圧縮パケットを解凍する少なくとも1つの解凍アルゴリズムを実現するよう動作できるものとする。したがって、MCU120は便宜上、TCP／IP機能120Aを備え、さらにV−Jヘッダ機能ブロック120Bのようなヘッダ圧縮／解凍機能を備えているよう示されている。動作プログラムは、通常、ユーザに対し、ディスプレイ140およびキーパッド160を介し、適切なユーザ・インターフェース（UI）を提供する。図示されていないが、ユーザが従来のように音声通話を行なえるよう、マイクおよびスピーカが通常は備えられている。
【００２４】
一般的に、メモリ130の少なくとも一部は、デジタル処理装置、すなわちこの場合はMCU120で実行可能な、マシン読み出し可能命令からなるプログラムを具現化して、本発明に係るデータ・パケット受信動作を行なうための情報記憶媒体であると考えてもよい。
【００２５】
移動局100には、デジタル信号プロセッサ（DSP）180または同等の高速処理装置もしくはロジックを含む無線部ならびにネットワーク・オペレータとの通信を行なうアンテナ240に接続されたトランスミッタ200およびレシーバ220を備えた無線トランシーバも含まれる。トランシーバのチューニングには、周波数シンセサイザ（SYNTH）260等の少なくとも1つの局部発信器が設けられている。デジタル化された音声およびパケット・データ等のデータは、アンテナ240を介して送受信される。
【００２６】
本発明に基づいて、TCP／IP機能120Aが誤ったTCPチェックサムを有するパケットを受信するごとに、TCP層2は、ピアTCPにTCP ACKパケットを返送して、現在期待されているデータ・パケット（RCV−−＞NXTに）を通知する。これにより、ピアTCPの高速再送機構が作動する。さらに、TCP／IP機能120Aは、誤ったチェックサムを有するこれらのパケットを暗に破棄する代わりに、これらの誤ったTCPチェックサムを有するパケットをパケット・バッファ130Aに格納する。続いて、TCP／IP機能120Aが期待した正しいパケット（RCV−−＞NXT）を受信すると、TCP／IP機能120Aは現在の受信ポインタを使用して、パケット・バッファ130Aにバッファされたパケットのヘッダ・チェックサムをチェックする。バッファされたTCP／IPパケットのチェックサムが正しい場合、TCP／IP機能120Aは、これらのパケットを正しく受信されたTCP／IPパケットとして、通常のように使用する。また、エラー状態からの高速リカバリを容易とするよう、送信側にACKパッケージを返信し、現在受信されているすべての正しいデータを通知する。
【００２７】
V−Jヘッダ機能120Bおよびパケット・バッファ130Aと組み合わせたTCP／IP機能120Aの動作を記述した、限定されない擬似コード例を以下に示す（図8の論理フロー図も参照。本発明の実施では、TCPデータ受信部の変更のみが必要であることも留意されたい。）。
DO{
IF(V−Jヘッダ圧縮がオン) AND (このパケットに対するTCPチェックサムが誤り)
{
TCP機能120Aは、ACKパケットを、現在正しく受信されたポインタ
RCV−−＞NXTにセットされたack_seqとともに送信側に直ちに送信する。
TCP／IP機能120Aは、誤ったチェックサムを有するパケットをパケット
・バッファ130Aにバッファする。
}
}WHILE (続いて受信される各パケットが誤ったTCPチェックサムを有する)
IF(正しいTCPパケット（RCV−−＞NXT）を受信)（＊注）
{
RCV−−＞NXTが変更される。現在のRCV−−＞NXTポインタを使用して、
バッファされた最初のパケットのTCPシーケンス番号を更新し、
バッファされたTCPパケットのTCPチェックサムを再計算させる。
IF(バッファされたパケットのTCPチェックサムが再計算後正しく
デコードされた)
デコードされたパケットを正しいTCP／IPパケットとして使用し、
RCV−−＞NXTポインタを更新させる。
更新されたRCV−−＞NXTポインタを使用して残りのバッファされた
TCP／IPパケットをデコードさせる。
}
TCP／IP機能120Aは、現在のRCV−−＞NXTポインタの値を通知するため、ピアTCPにTCP ACKパケットを返信する。バッファされたパケットの残りは破棄し、バッファを空けさせる。
＊注：TCPはコネクション型の、信頼性の高いデータ転送プロトコルであるため、最終的には期待されたRCV−−＞NXTが受信される。そうでない場合、データ／ファイル転送は中止される。
【００２８】
図5は、データ・バースト・エラーのある、ヘッダ圧縮が使用された、FTPアップロード中の従来のTCP伝送のデータ転送時間／シーケンスグラフを示している。X軸は秒で示される時間、Y軸はバイトで示される、関連するTCPシーケンス数を表している。中央の実線は、実際に転送されたデータを表し、上側の細線は特定の時間に対応するTCP通知されたウィンドウ制限である。下側の細線は、TCP ACKが受信された瞬間である。データ・バースト・エラーは、X軸のおよそ5秒、16秒、21秒、31秒および41秒で発生している。エラーが発生するたびに、TCPがエラー発生後に、すでに送信されたデータ・パケットをすべて再送していることがわかる。この従来技術の図は、データ・バースト・エラーのある、ヘッダ圧縮が使用された、本発明によるFTPアップロード中（MS100へ）のTCP伝送のデータ転送時間／シーケンスグラフである図6と対照される。本発明による利点は、ヘッダ圧縮機能が禁止されていても得られることも留意されたい。ここで、データ・バースト・エラーは、X軸の1.8秒、10秒、11秒、12秒、14秒、17秒、30秒および31秒で発生している。この場合、エラーが発生するたび、TCPは消失されたデータ・パケットのみを再送すればよいことがわかる。この結果、転送時間が大幅に減り、スループットが大幅に向上する。したがって、本発明を用いることにより、データ・パケットのスループットが著しく改善されることが理解されよう。
【００２９】
前述の手順により、V−Jヘッダ圧縮がオンにされた状態で動作するTCP高速再送／リカバリ手順が可能となる。また、前述の手順によって、CDMA無線および他の本来的に信頼性の低い伝送環境（例えば、バースト、インパルス・ノイズおよび他のチャネル障害の影響を受けやすい伝送チャネルを採用した環境）でのデータ・スループットも改善される。
【００３０】
前述の手順の実行時、TCP／IP機能120Aは、通常送られるよりも多くのTCP ACKパケットを送信する傾向があるが、データ転送の大部分が通常一方向であるため（例えば、ある一定期間MS100はダウンロード中またはアップロード中のいずれかである）、ピアTCPに追加のTCP ACKパケットを返信するためにより相対的にビジーではないチャネル（例えば、ダウンリンク・チャネルでMS100にパケットをダウンロードしている際のアップリンクチャネル等）を使用することは、全体のトラフィック量に深刻な影響を与えることはない。さらに、同時転送が行なわれている場合、TCP／IP機能120Aは、ACKメッセージを他のメッセージに重畳することもある。
【００３１】
上記記載は、本発明を実施するため、発明者らにより現時点で考慮された最良の方法および装置について、余すところなく情報を提供する限定の意図を有しない例を示す記載であるが、前述の記載に鑑みて、添付図面および特許請求の範囲とともに併せ読むことにより、種々の変更および改作が可能であることは、関連技術における当業者に理解されよう。また、いくつかの例において、上記の発明は、ブラウザ、Java（登録商標）、ネットワーク層HSD（ハイスピード・データ（High Speed Data））アプリケーション等、およびこれらに限定されないソケット・サーバ・コードを使用するデバイスまたは製品の類で使用されても良い。また、当業者は、同様または同等のアルゴリズム、ヘッダ圧縮技術およびネットワーク・プロトコルの使用を試してみることもできよう。さらに、前述の移動局の説明で触れたが、本発明の教示は、固定ネットワークならびに他の無線および有線インフラ機器およびデバイスでも実施でき、一般的に、チャネル障害を受けやすいチャネルを介したデータ・パケットを受信するいかなるデバイスにも利用できるものと理解される。しかし、本発明の教示によるこれらすべておよび同等の変更は、本発明の範囲内のものである。
【００３２】
さらに、本発明のいくつかの機能は、対応する他機能を用いることなく利用できる。したがって、前述の記載は単に本発明の原理を説明するものに過ぎず、これを限定するものではない。
【図面の簡単な説明】
【００３３】
【図１】典型的な従来のTCP／IP／PPPプロトコル・スタック・アーキテクトを示す図である。
【図２】従来のTCPフレーム・フォーマットを示す図である。
【図３】従来のIPフレーム・フォーマットを示す図である。
【図４】従来のPPPフレーム・フォーマットを示す図である。
【図５】バーストエラーがあり、ヘッダ圧縮が使用された従来のFTPアップロード中のTCP伝送を示すデータ転送時間／シーケンス・グラフである。
【図６】バーストエラーがあり、ヘッダ圧縮が使用された、本発明によるFTPアップロード中のTCP伝送を示すデータ転送時間／シーケンス・グラフである。
【図７】本発明の実施に適した移動局を含む無線通信システムの簡略ブロック図である。
【図８】図7の移動局の一部を構成するTCP／IP機能の動作を示す論理フロー図である。
【図１】
2007532073.tif 000003
【図２】
2007532073.tif 000004
【図３】
2007532073.tif 000005
【図４】
2007532073.tif 000006
【図５】
2007532073.tif 000007
【図６】
2007532073.tif 000008
【図７】
2007532073.tif 000009
【図８】
2007532073.tif 000010
【国際調査報告】
2007532073.tif 000011
2007532073.tif 000012