JP2002534001A - 通信ネットワークにおけるデータ処理時間の削減に関する方法および装置 - Google Patents

Abstract

(57)【要約】 本発明は、移動体通信グローバルシステム（ＧＳＭ）、ユニバーサル移動体電気通信システム（ＵＭＴＳ）、汎用パケット無線サービス（ＧＰＲＳ）のような移動体通信ネットワークとＩＰネットワークのような通信ネットワークを介した通信でのパケット通信アプリケーションにおける受信データの処理時間改善方法と装置に関するものである。例えば、第２のプロトコル層の受信データパケット、ＲＬＰフレームは、第１プロトコル層のデータパケット、例えばＰＰＰフレーム、を作成するために、第２のプロトコル層の受信機で直接組み合わせられる。完全かつ正しく組み合わせられたデータパケットが第１のプロトコル層に対して解放される。第１のプロトコル層に対してデータパケットを開放する間、２つのモードによって差がある。フロー内モードは、すべての完全に作成されたパケットを解放する、つまり、データパケットが同じデータフローに属するか否かとは無関係に解放するモードである。これに対して、フロー間モードは異なる。当該モードでは、データフロー毎に、完全に作成されたデータパケットだけが第１のプロトコル層に対して解放される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は 通信ネットワークを通して、特にグローバル移動体通信システム（
ＧＳＭ）、ユニバーサル移動体電話システム（ＵＭＴＳ）、汎用パケット無線サ
ービス（ＧＰＲＳ）のような移動体通信ネットワークとＩＰネットワークを通し
て通信を行うパケット指向アプリケーションにおいて、受信データの処理速度を
改善するための装置と方法に関する。

【０００２】

【従来技術】

プロトコルは、共通に通信をするため、通信相手との間ですべての取り決めの
全体として定義される。従って、共通の束縛プロトコルは、２つの通信ネットワ
ークノード間でデータのやりとりをするのに不可欠である。プロトコルは、普遍
的で矛盾なく定義され、同一の基礎の上で、システムの限界を超えて異なるネッ
トワークを連結させて通信することが可能であることが要求される。

【０００３】 標準的な構成による通信のプロトコル全体は、層に分けられている。それぞれの
層は独自のプロトコルによって割り当てられた課題を解決する。隣接した層間で
の通信は、明確に定義されたインターフェースによって保証される。この場合、
ｎ番目の層は、すぐ上のｎ＋１層に直接連結されてサービスを提供し、すぐ下の
ｎ−１番目の層と直接連結されて当該層からサービスの提供を受ける。さらに、
下位のすべての層のサービス層ｎと通信してサービスを提供する。よって、プロ
トコルデータユニットＰＤＵの論理的なデータの流れは、一つのプロトコル層そ
れぞれに実現される。受信側ではデータは逆の手順で処理される。すなわち、デ
ータは下位層からすぐ上のプロトコル層へ直接送られる

【０００４】 プロトコル群の構造は物理的なネットワークやアプリケーションに応じて違っ
ている可能性がある。しかしながら、異なるネットワーク間における通信の互換
性を保証するには限界がある。標準化されたインターネットアプリケーションに
対するプロトコル群は、ＴＣＰ／ＩＰ（通信制御プロトコル／インターネットプ
ロトコル）である。それは４つの層を有し、最上部の層−アプリケーション層−
はアプリケーションプロトコルを具備する。通信プロトコル、例えばＴＣＰ（通
信制御プロトコル）と呼ばれているものは、そのすぐ下に配置される。インター
ネットプロトコル−ＩＰと呼ばれている−はネットワーク層を形成する。最も下
の２層は−リンク層と物理層−ネットワーク指向層を形成するために連結するこ
とができ、それらはその下に配置されたネットワークに応じて特別に定義される
。前記ＴＣＰ／ＩＰプロトコル群の標準構造とそれぞれの層間の通信リンクを図
２に記載した。

【０００５】 ＴＣＰ伝送プロトコルは、ビットの流れに対し確実な伝送サービスを提供する
。信頼性は、ここでは、エラーが無いこと、シーケンスの保守、データの喪失お
よび重複に対する保護を意味する。エラー訂正はＡＲＱ（自動再送信要求）によ
って行われる。送信のためのパケットのコピーは送信側で作成されて、データパ
ケットの送信が相手側に確実に承認されるまで保存される。受信側は受け取った
パケットを検査し、正確に受け取ったことをポジティブに確認し、誤って受け取
ったパケットを削除する。この点に関して、ＴＣＰはネガティブな受信確認の伝
送を許さないことは注目すべきである。不正確な伝送パケットの再送信はポジテ
ィブな承認の機構によって実行される、すなわち、もしポジティブな承認がなけ
れば、状況によるが、パケットは受け取られていなかったと送信側は結論する。

【０００６】 アプリケーション層からＴＣＰ層へ伝送されるビットの流れは、ＩＰデータグ
ラムとして伝送されるＴＣＰによってセグメントに分割される。ＩＰデータグラ
ムはＩＰプロトコルの規則によってフォーマットされたデータパケットとして示
される。データグラムを使うデータ交換によるデータグラムの特性は信頼できな
いというのがダイヤグラムの特性である。ＩＰでは、パケットが本当に受信側に
伝送されたかについては保証しない。ＩＰデータグラムもまた順序が混乱し、あ
るいは受信側に２重に到着する。この概念の限界の中で、しかしながら、誤った
伝送の検出や発生したエラーの訂正がＴＣＰの仕事である。

【０００７】 ＩＰデータグラムは、さらには、その下に直接配置されたリンク層の階層原理
によって伝送される。前記層はＩＰデータグラムを受け取って整理する、これは
フレームと呼ばれる。これはフレーミングという名で知られている方法で行われ
る。すなわち、リンク層は一つかそれ以上のフレームの中にＩＰデータグラムと
してパッケージ化される。フレームは特別なビットの結合によって区画されてい
る。ビット結合はフレームの始まりの分離符号、初期符号と呼ばれる、と終わり
の分離符号、終端符号と呼ばれるどのようなビットの並びと対応するかが明記さ
れている。

【０００８】 フレームとは別に、リンク層は２つの特別な仕事をする。リンク層は誤り検出
に関して信頼できる。従って、誤って伝送されたフレームは通常、受信側のリン
ク層によって削除される。この目的に対しデータパケットは、巡回符号、フレー
ムチェック手順ＦＣＳ、循環冗長チェックＣＲＣ、などと呼ばれる、が適用でき
る場を提供する。この考えは複数のデータパケットを解釈するためのものである
。送信側は受信側が受け取った、生成多項式と呼ばれるわり算による残りの０を
受け取ることにより、データパケット補足する。このようにして誤り検出は実現
される。リンク層は、例えばＡＲＱ法を用いて、任意に誤り収集を行う。

【０００９】 リンク層のプロトコルは、直接物理的に隣接したネットワークノード間で適用
される。この目的のため、たくさんの代替プロトコルが定義される。２つのネッ
トワークノード間にどのプロトコルが適用されるかは、２つのネットワークノー
ドを連結するネットワークに依存する。よく知られているポイント・トゥー・ポ
イントプロトコル、ＰＰＰ、はリンク層のプロトコルに対する例である。ＰＰＰ
は、構成と誤り検出というリンク層の最初の２つの仕事を実施する。よって、Ｐ
ＰＰが番号付けモードＲＦＣ１６６３と呼ばれるで動く特別な方法があるが、通
常これは使用されていない。

【００１０】 実際のところ、ＰＰＰは再送されたパケットを通しての修正をサポートしない
、あるいは送信エラー率が高い場合にはこの方法は効率が悪いので、データ伝送
で特にエラー率が高いネットワークでは特別な追加のプロトコルが適用される。
例えば、移動体通信ネットワークは、高い伝送エラー比のネットワークとして知
られている。GSM（移動体通信に対する広域システム）とGPRS（一般パケット無
線サービス）はそこに分類される。特別なプロトコル−RLP（無線連結プロトコ
ル）と呼ばれる、はGSMネットワークのリンク層に応用される。RLPセグメントの
ビットの流れはフレーム内のPPP層から受ける、それは普通PPPレベルのフレーム
より小さい。エラー訂正は、前記フレームを基礎としてARQ法によって取り扱わ
れる。ARQの機能は、連続的に番号付けされたフレームを要求する。それゆえに
、それぞれのフレームは、分類している間に、連続的な一連の順序番号を受け取
る。今日の実施ではビットの流れはRLPフレームの中に確実に区分され、パッケ
ージ化される。よって、データの種類、制御データまたは現実のデータに関する
限り、データの種類は考慮されないままである。RLP層だけがビットの流れを知
ることができる。それによって、２つの異なるPPPフレームからのデータは、一
つのRLPフレームに結合される。RLPフレームはこのとき、最初のPPPフレームの
終端符号を受ける、そして同様に次のPPPパケットの初期符号を受ける。この問
題に対する解決法は、送信側の分離子に対するビットの流れを検査することを提
案するヨーロッパ特許出願EP９８ １１３ ２１２．９で提供されている。この
ように、送信側でRLPパケットへのバイトの流れをパッケージ化するときに、異
なるPPPパケットが区別され、それによって２つのPPPパケットからのデータがRL
Pの中で結合されることを防止している。

【００１１】 両プロトコル、RLPとRLCはHDLC（高レベルデータリンクプロトコル）ISO87と
似ているために、GPRSネットワークにおいても同様な機能がRLCプロトコルで実
現されている。プロトコル間の差異はフレーム作成方法の中に存在する。

【００１２】 プロトコル層と、とりわけプロトコルが互いに水平的に独立であるようにする
ことが階層構造の目的である。このように、IPプロトコルのように、同じネット
ワークプロトコルを経由して異なるアプリケーションと異なる通信プロトコルが
通信することができる。さらに、IPプロトコルは異なるプラットフォーム上で機
能できる。したがって、IPダイアグラムはGSM、GPRSのような異なる物理ネット
ワークを経由して伝送できる。

【００１３】 ユーザにとって、プロトコルレベルでの通信はほとんど目にすることができな
。ユーザーは、電子メール、ウェブブラウザのような異なるアプリケーションサ
ービスをサポートする役立つシステムを期待する。データは、物理的リンクを通
って送信することのできる限界を超えたサイズのパッケージを送信しようとする
ことが良くある。このため、メッセージは連続的に配置される小さなパケットに
分割される。データの分割はフォーマットの一部である。データのフォーマット
はそれぞれのプロトコル層で行われる。特定のプロトコル層、例えばRLP層、は
データの分割を行う、すなわち前記データは小さなデータブロックに再区分され
る。データブロックは異なる層では異なる名前を持つ。それらは、IPプロトコル
層上のデータグラム、リンク層上のフレーム、と呼ばれる。さらに、それぞれプ
ロトコル層に関係しないデータブロックは、データパケットによって明示される
。

【００１４】 データのフォーマットは、特に各プロトコル層で特徴付けられる制御データを
有する。ほとんどの場合、制御データはヘッダーと呼ばれる形をデータパケット
の始まりに付加する、そして／またはテールと呼ばれる形を最後に付加する。実
データはユーザーデータ領域に含まれる。前記機構は以下のTCP／IPプロトコル
スタックで詳細に説明する。

【００１５】 図３によると、ユーザーデータはアプリケーション層で区分される、そして制
御情報がそれぞれのデータパケットに付加される。前記データパケットは結果と
してTCP伝送層へ転送される。前記層はそれのヘッダー形式の制御データを加え
る。前記データはネットワーク層へ伝えられる。それは、例えば、IPは処理手順
情報のような適切な制御データを含む。この方法でIPダイヤグラムは形成され、
以下の方法でリンク層に伝えられる。リンク層のプロトコル、例えばPPP、は分
離子のような自身の制御情報を付け加えて受信したデータを処理する。この段階
で生成されたデータパケットはフレームと呼ばれる。前記フレームは適切なネッ
トワークを経由して伝送される。データパケットは異なる手順で受信側の適切な
層に到着する。伝送された手順を再生するために、この層の受信側の処理ができ
る。これは、例えばＴＣＰまたはＲＬＰ受信機の処理であるが、ＩＰ受信機の処
理ではない。プロトコル層のデータパッケージ化の機構は、カプセル化として知
られている。逆の機能は復カプセル化と呼ばれ、受信側で行われる。以下、ＲＬ
Ｐフレーム、ＲＬＣフレーム、またはＰＰＰフレームの番号付けされたモードで
働くデータパケットは、一般的な呼び名Ｌ２ＡＲＱフレームと称する。

【００１６】 ユーザーデータはＬ２ＡＲＱの形式で、受信機に送られる。同時にＬ２ＡＲＱ
フレームは送信側のバッファーに蓄えられる。これはパケットが再送される場合
には必要であろう。Ｌ２ＡＲＱフレームの連続番号によって、パケットが伝送の
間に失なわれたかどうかを、受信側が判断する。もし一つのＬ２ＡＲＱフレーム
が失われると、前記Ｌ２ＡＲＱフレームの再送を始める。対応する機構によって
送信側は発生したエラーのメッセージを受け取る。一致する番号のパケットをバ
ッファから取り出して再送する。パケットが受信側にうまく伝送されると、送信
側のバッファからそのパケットを削除する。

【００１７】 この機構は番号付けモードと呼ばれる。前記モードは、送信側から受信側へ正
確なデータが伝送されることをことを保証することによって、正確なサービスを
提供する。非番号付けモードと呼ばれるものもある。前記モードは、ＡＲＱ処理
を用いるので誤り訂正をしない。したがってこのモードは不正確な伝送である。

【００１８】 パケットの再送信は、しかし、受信側に到達したパケットの順序は、送信され
た順序とは一致していないことになる。

【００１９】 本発明に基づく手順では、Ｌ２ＡＲＱフレームを送信された順序に並べること
は、−リンク層プロトコルがARQをサポートすることを条件として−リンク層プ
ロトコルの役目である。これは、例えば受信されたＰＬＰパケットは、ＲＬＰパ
ケットが再作成される手順まで受信側のバッファに蓄積されることを意味する。
これはまた、前記フレームが完全に該パケットを受信したとき、また前記フレー
ムが以下の手順の時、ＲＬＰフレームＲＬＰフレームは層の上に直接生成される
ことを意味する。もし、しかしながら、一つのフレームがエラーのために再送さ
れると、すでに受信されたその後のすべてのフレームは再送されたフレームがエ
ラー無く受信されるまでバッファに保存される。ＲＬＰパケットが一致する順序
番号によって生成される手順に配置されるときのみ、ＰＰＰ層を通過する。制御
情報に先立って削除される。

【００２０】 ＰＰＰ層の受信機は、ＰＰＰフレームの確認を行う。このため、該受信機は分
離子を探す。ＰＰＰフレームが完全に認識されたとき、ＩＰダイヤグラムはＩＰ
層へ伝えられる、そのとき、該ＩＰダイヤグラムはＴＣＰプロトコル層上で受信
したＴＣＰセグメントを通過する。

【００２１】 Ｌ２ＡＲＱフレームは、一致する手順の中の前記フレームを持ってくるために
、リンク層上に一時的に蓄えられる、このため処理時間が長くなる。とくにこれ
は時間遅れに敏感なアプリケーションでは負の効果である。どんな程度であれ、
長時間の遅れはデータ処理の効率を損ねる。遅れに敏感なアプリケーションの場
合は、処理を中止する原因になる可能性もある。そのうえ、この方法は通信する
プロトコル層上に多大なバッファを必要とする。とくに、ＲＬＰプロトコル層上
で、パケットは要求された手順が再生されるまで、前記レベル上で一時的にバッ
ファに蓄えられる。長いデータの貯蔵時間は、階層的なプロトコル構造の中では
データ処理に対する時間を長くする。

【００２２】

【発明が解決しようとする課題】

従って、データ伝送において、パケット指向アプリケーションの受信側のデータ
処理をより効率的に行う方法と装置を提供することが、本発明の目的である。特
に受信側で、必要なメモリー空間を削減することが本発明の目的である。

【００２３】

【課題を解決するための手段】

本発明によれば前記目的は、特許請求項１及び特許請求項２４によって提供さ
れる。

【００２４】 リンク層上で完全に生成されたパケットをすぐ上のプロトコル層に直接伝送す
ることによって、長時間の一時保存を行わないことが利点である。

【００２５】 この理由のため、受信したデータはより早くアプリケーション層に伝送され、
それによって遅延に対して敏感なアプリケーションのより安定した動作を保証す
るという利点も提供する。

【００２６】 別の利点として、受信したデータが、受信したデータのシーケンスが提供され
るまでバッファに蓄えられず、いくつかのデータパケットが受信されていない可
能性があったとしても、完全に生成されたパケットはプロトコル層上に直接生成
されるので、対応する受信側上のプロトコル層で必要とされる記憶容量を削減す
ることができることである。

【００２７】 発明のさらなる利点は、特許請求項２，２３，２５からもたらされるものであ
る。

【００２８】

【実施例】

以下に、図１と請求項１によって発明を説明する。

【００２９】 図１によると、最初のプロトコル層のデータパケットは、伝送側１０に提供さ
れ、直ぐ下の第２のプロトコル層２０に直接伝達される。前記層は第２のプロト
コル層３０のデータパケットの中に受信したデータをパッケージ化する。第２の
プロトコル層のデータパケットは、最初のプロトコル層の異なる２つのデータパ
ケットを含まない。第２のプロトコル層のそれぞれのデータパケットはただ一つ
の順序番号を受け取る。この方法でパッケージ化された第２のプロトコル層のデ
ータパケットは、前述の手順４０が有効なネットワークへ送られる、そして、そ
の結果としてネットワーク５０を通して伝送される。第２のプロトコル層の個々
のデータパケットは、受信側６０で受信される。受信された第２のプロトコル層
のデータパケットは、番号７０の順序に従って並び替えられて、提供されるバッ
ファ８０に蓄えられる。それらは最初のプロトコル層９０のデータパケットを認
識するために順番に検査される。もし、第２のプロトコル層のデータパケットが
受信されると、このデータが、最初のプロトコル層の分離子含むかどうかが検査
される。もし含むならば、最初のプロトコル層の初期符号か終端符号のどちらか
一方が重要である。初期補号の場合は、第２のプロトコル層のそれに続くデータ
パケットは最初のプロトコル層の新しいデータパケットに属することを意味する
。第２のプロトコル層のデータパケットは、最初のプロトコル層のデータパケッ
トが１００に完全に受信されるまで、バッファに蓄えられる。これは第２のプロ
トコル層のデータパケットの受領書によって検出される、データ領域は終端符号
を含む、そしてさらに手順の中に以下の一つを含む。最初のプロトコル層の完全
に生成された唯一のデータパケットだけが１１０の上のプロトコル層に直接生成
される。

【００３０】 以下に、特許請求項２４による発明を説明する。

【００３１】 第２のプロトコル層上の第１のプロトコル層のデータパケットと、送信順序に
従うそれらの配置は、第２のプロトコル層へ、最初のプロトコル層のデータパケ
ットが提供されることによって実現される。前記データパケットは伝送手段によ
って提供されるネットワークを通して伝送される。受信側のデータパケットの受
信に対する受信手段はパケットを受信する。受信されたデータパケットの分類に
対する分類手段で、連続的な順序の中へ組み込まれる、そして、第２のプロトコ
ル層の受信したデータパケットを一時的に保存するためのバッファに蓄えられる
。第２のプロトコル層のデータパケットは、第１のプロトコル層のデータパケッ
トが認識できるかどうかで検査される。これは第１のプロトコル層における、完
全に結合されたデータパケットを検出するための検出手段によって行う。その結
果として、最初のプロトコル層で完全に生成されたデータパケットはデータの流
れの結合として検査手段によって検査される。それ故に、検査されたデータパケ
ットは、最初のプロトコル層へ完全に生成されたデータを解放するために解放手
段によって解放される。

【００３２】 本発明の応用の可能な領域は、ＧＳＭのような、移動データネットワークを通
してのインターネットアプリケーションの領域である。本発明の可能な応用は、
本発明の実施例により詳細に説明した。それによって、データの処理は受信側の
完全に生成されたデータパケットの解放までを、伝送側のアプリケーションとし
て図示した。

【００３３】 この目的のため、模式的に示した図４のネットワークシステムが使われる。移
動加入者間通信、例えば、移動局と固定ネットワーク内の加入者の集合、サーバ
ー、はこれによって模式的に図示される。図中上部は、通信ユニットと一致する
物理的な接続を示している、そして下部は複雑なプロトコルの論理的な結合を構
成する。

【００３４】 移動局ＭＳは、例えば、ラップトップコンピュータである。前記ラップトップ
コンピュータは末端の接続機能（ＴＡＦ）を通して接続する。その仕事は、例え
ば、移動電話のような移動局MSと、ＰＣＭＣＩＡ（Personal Computer Memory
Card International Association）によって行われる。移動局MSはBTS（基
地無線局）と通信する、それは、再度BSC（基地局コントローラ）と通信する。
公衆アナログ電話ネットワークとの接続、公衆切り替え電話ネットワーク（PTSN
）と呼ばれている、はインターワーキング機能IWFと呼ばれている中に集積され
ているモデムにより実現する。インターワーキング機能IWFは移動切り替えセン
ター、移動サービス切り替えセンタ（MSＣ）と呼ばれている。さらに、接続はイ
ンターネットへのネットワーク伝送ノードを持っているインターネットサービス
プロバイダー（ISP）へ、公衆電話ネットワークPTSNを通して接続される。末端
加入者への接続、サーバー、はインターネットを通して成立する。明確のためイ
ンターネットを通しての接続は図４にさらに詳細に記載しない。

【００３５】 アプリケーションは下部のプロトコル層から独立に実施する。それによって生
成されたデータの伝送は、ユーザに明瞭な方法で実行される。これはまた、プロ
トコルスタックの階層構造の目標でもある、すなわち、システムの中にユーザー
を含めることなく、最適で安定な伝送を保証する。それは、しかしながら、映像
データの伝送やインターネットへのアクセスのようなユーザーによって使用され
るすべてのアプリケーションサポートするシステムから期待される。異なるアプ
リケーションは、しかしながら、システムで異なる要求を持っている。

【００３６】 銀行取引のような確かなインターネットアプリケーション、例えば、安全な伝
送プロトコルの要求、このやり方に対してのみインターネットを通してお金の取
引の間エラーのないデータの流れが保証される。データの安全な伝送は、伝制御
プロトコルTCPと呼ばれる物によって保証される。

【００３７】 対照的に、それに加えて、映像伝送の場合は、データ伝送の確実な安全の報償
をするプロトコルの使用は要求されない。伝送時に長い遅れ時間の可能性でも確
実なデータの流れは安全として。映像伝送の場合は、映像の提示の中で現実的な
感じを得るために、手順の中でデータのより早い伝送に対する保証がよりよい。
伝送中に起こるかもしれないエラーは、一定の限界である、そして、映像の放送
の時我慢できる。この理由のため、誤り訂正プロトコルは、映像伝送では使われ
ない。伝送段階のそのようなプロトコルの例は、ユーザーデータグラムプロトコ
ルＵＤＰである。

【００３８】 一つのセッションでユーザーが使ういくつかのアプリケーションの最も多くの
場合は、例えば、ユーザーが、Ｅメールを送り、背景で同時に映像を伝送したい
ときはいつでもである。この場合、ユーザーは異なる２つのデータの流れを生成
する。Ｅメールの伝送はＴＣＰが基礎である、映像伝送はＵＤＰが基礎である。
別の例ではインターネットのアクセスである。一つのセッションのあいだ複数の
インターネットのページが開かれている、それはしばしば異なるサーバに置かれ
る。だけれども、生成されたデータの流れは独占的にＴＣＰの流れである。異な
るデータの流れは、この場合、当該受信者は異なる。

【００３９】 前記特徴は、ＩＰ層のような、ネットワークプロトコル層を考慮される。前記
層は、伝送プロトコル層からパケットを受信する、独自フォーマットのパケット
を形成するために束ねる。図５はＩＰパケットのフォーマットを図示する。前記
パケットは、例えば、ＩＰプロトコルバージョンのＩＰｖ４またはＩＰｖ６のバ
ージョンのなかのデータを含む。これはず５に詳細には示されていない。さらに
、ＩＰデータフォーマットは伝送プロトコルに関しての情報を含む領域で提供さ
れる。ＵＤＰプロトコルの場合は、ビットの結合は前記領域内へはいる、これは
ＵＤＰの呼称に相当する。

【００４０】 データの流れを識別する決定的な要因は、しかしながら、プロトコルのタイプ
だけでなく、ＩＰヘッダに含まれるアドレスに関する要因もである。これは、も
し送信側のＩＰアドレスと受信側のＩＰアドレスが図５による２つのＩＰパケッ
トが一致するならば、ＴＣＰヘッダーはさらにデータの流れの違いを見つける手
順で、検査される。異なるポート番号が異なるデータの流れに割り当てられる。
前記ポート番号は、相手との間の通信が保証されるために、伝送段階の一致する
データの流れが同一である。ＴＣＰパケットのヘッダーはポート番号についての
情報を含む、それは、データの流れを区別するとき比較される。伝送側と受信側
のポート番号が同じとき、データの流れは同じである。もし前記アドレスが異な
るとき、すなわち、もし両ＩＰアドレスとポート番号が互いに異なるとき、受信
機は異なる、そして、データの流れが異なる。前記の仕組みが今日使用されてい
るＩＰのバージョンで実現されている、これはインターネットプロトコルバージ
ョンＩＰｖ４と呼ばれている。次のＩＰのバージョンは６、ＩＰｖ６、である、
定義は基本的に同じである。ここで、異なるデータの流れは、データフロー身分
証明と呼ばれる物−あるいはフロー身分証明によって区別される。記述された方
法はＩＰｖ６上に転移できる、そして基本的にデータの流れのような、それぞれ
のプロトコルスタックは認識できる。

【００４１】 ＩＰ層上のパケット同一か又は異なるデータの流れを得るかどうかの依存性、
違いは２つのモード間で作られる。同一のデータの流れ、イントラデータ流また
はイントラ流モードと呼ばれる、ＩＰパケットの場合に関する。インターフロー
モードの間はモードを明示する、これは異なるデータに属するＩＰパケットは区
別される。

【００４２】 図４によると、インターネットにおける移動局とサーバー間の伝送層上の結合
はすでに築きあげられている、前記サーバーから移動局ＭＳへのデータの流れの
一例を以下に示す。この例では通信ユニットと通信プロトコルを含めてより詳細
に説明する。

【００４３】 ネットワーク層上でパッケージ化されたＩＰダイヤグラムは、インターネット
サービスプロバイダーＩＳＰと呼ばれるインターネットを経由して伝送される。
ＩＳＰは受け取ったＩＰパケットをＰＰＰ層に伝送する。前記層は得たデータか
らＰＰＰフレ−ムでフォーマットされたビットの流れを生成する。受け取ったパ
ケット間の区別のために、分離子を付け加える。その結果として、ＰＰＰフレー
ムはアナログ伝送に対して提供される。ＩＳＰは、伝送比とモードに応じてデー
タをアナログ信号に変調して伝送するためのモデムを提供する。図示した例では
、アナログネットワークを経由して接続か実行される。ＰＳＴＮ、これはｖ３２
モデムである。もし、ＩＳＤＮネットワークを経由して接続されるならば、ｖ．
１１０プロトコルが例えば使われる。流れの制御のため、すなわち、インターネ
ットの中の機能ＩＷＦでデータがオーバーフローしないための手順として、ｖ．
４２が使われる。前記機能はＧＳＭの中の無線リンクプロトコルＲＰＬの機能と
一致する。

【００４４】 インターネットの機能ＩＷＦ内で、受け取ったデータのフォーマットへの換算
はＧＳＭを実行することによって行われる。

【００４５】 この手段は、ＰＰＰ層のビットの流れは、ＲＬＰ層へ放たれる。前記層は、受
け取ったビットの流れをＲＬＰフレームへパッケージ化する。ＲＬＰフレームの
フォーマットは図６に記載した。ＲＬＰフレームは２４０ビットある。１６ビッ
トはヘッダー情報のために予定されている、２４ビットはフレームチェック手順
ＦＣＳである。ＲＬＰフレームの中でＰＰＰフレームをパッケージングするとき
の決定的な要因は、より高いプロトコル層のデータパケットは、受け取ったビッ
トの流れの中でＲＬＰ層へ直接明白でないことである。これは、ＲＬＰ層はPPP
フレーム間、またはIPダイアグラム間、そして伝送層のパケット間で違いを作る
ことができない。パケットの区別のためにビットの流れは分離子をチェックしな
ければならない。これは異なる２つのPPPフレームからのデータを、一つのRLPフ
レームにパッケージ化しないようにするために必要である。それぞれの新たに生
成されたRLPフレームは、順序番号と共に提供される。このやり方で配置された
パケットは提供された移動ネットワークを経由して伝送される。伝送の間、ＲＬ
Ｐフレームの手順は、発生する伝送エラーと接続のためのＡＲＱ処理のために混
乱する。フレームは代わった手順内で受信側によって受信される。受信機はの中
でＲＬＰフレームのポジションを見つけるための手順内の順序番号に対して受信
したＲＬＰフレームをチェックする。別な段階で、ＲＬＰフレームが分離子を含
んで受信したかどうかをチェックする。もしそれが初期符号を含んでいるならば
、それに続くＰＰＰフレーム内で最初のフレームとして検出されるだろう、そし
て、一致するポジション上のバッファーへ蓄えられる。それに続く連続的な番号
を示すＲＬＰフレームは、一致するポジション上のバッファーへ蓄えられる。こ
れはＰＰＰフレームが完全に生成されたフレームの状態を受信するまで続く。Ｐ
ＰＰフレームは完全に生成される、もし初期及び終端両符号が確実に受信された
ならば、そしてすべてのＲＬＰフレームが確実に受信されたならば、そしてそれ
らがどんな飛び越しも無しに、そして初期符号と終端符号含むＲＬＰフレーム間
の正しい手順に置かれるならば。ＲＬＰフレームがバッファーに蓄えられる前に
、フレームが復カプセル化、すなわち、ＲＬＰプロトコル層の制御データが削除
される

【００４６】 ＲＬＰフレームがチェックされるときＰＰＰパケットが区別されるだけでなく
、フレームのチェックＩＰパケットの検出に拡張できる。これは、イントラーフ
ローモードとインターフローモードを区別するための基礎である。すでに述べた
ように、ＩＰヘッダーは伝送プロトコルの使用を考慮する情報を含む、そして、
同じアドレスを含む。ＩＰダイアグラム全体がＰＰＰフレームに合致するという
事実のため、ＰＰＰフレームを終わらせる検査は、ＩＰダイアグラムと情報の認
識のため指定することができる、すなわち、異なるデータの流れのＩＰダイアグ
ラムが同じかどうか。

【００４７】 この目的のため、フレームの制御データは、完全なＰＰＰフレームが生成され
た後にチェックされる。データはそれぞれのプロトコル層の制御データに対して
特に検査される。これは、完全に結合されたデータパケットに対する承認のため
に、承認手段を用いて承認される。それぞれの層の制御データを考慮した情報は
前記手段で役立つ、この基礎はリンク層から引き出された制御データで作られた
決定である。特にＰＰＰから、ＩＰ制御層の制御データ始まる。データの復カプ
セル化のフォーマットはそれぞれの層で標準化されている。実現化は前記のメカ
ニズムで作られなければならない、それはカプセル化の正当な標準に似ている。
ＩＰダイアグラムのより厳密な説明は以下に説明する実施例に示す。

【００４８】 ＩＰダイアグラムは直接プロトコル層の上に伝送される−伝送層−。ＴＣＰパ
ケットは等分に連続に番号付けされる、そして伝送層上のＴＣＰパケットのあら
かじめ番号付けされた手順は生成される。言い換えると、ＴＣＰは正確な手順の
中で、ＴＣＰパケットの配置に対して信頼できる、この段階で、適切でないパケ
ットも検出される、エラーはパケットの再送信に対する照会を始めることによっ
て削除される。

【００４９】 ＴＣＰは伝送されたＴＣＰパケットの正確な手順を生成するために信頼できる
。これはもはや、ネットワークプロトコル層と同じ振る舞いを要求する必要はな
い。これは特に、変更された手順内で受け取ったＩＰダイアグラムを許す。不正
確な手順のＩＰダイアグラムの受信に対する原因は、非同期伝送である。個々の
パケットは異なる通り道を取ることができる。パケットはそれらの通り道上で互
いに追い越して送られる、それによって、変わった手順でレシーバーに到達する
。伝送層、特にＴＣＰ、は手順の生成に対して信頼できる。ネットワーク層での
ＩＰパケットの順序が変わる範囲は重要ではない。これは特にパケット処理の効
率が影響されないことを意味する、もしＲＬＰプロトコル層によって後から順序
が変わっても。

【００５０】 ＵＤＰの同じ理由により、パッケージの順序の変更が認められる

【００５１】 以下に、インターフローモードに対する、特許請求項１６による発明の実現を
図７を用いてより詳細に説明する。

【００５２】 インターフロ−モードでは、異なるデータの流れに属するパケットは、区別さ
れる。この目的のため、完全に生成されたＰＰＰフレームは検査される、上記に
記載された。前記モードにおいて、ＰＰＰフレームはＲＬＰレシーバーによって
すでに放たれる、最初に、それらが完全で正確に受け取ったとき、そして、２番
目に、ＰＰＰフレームはＲＬＰ受信機によって緩衝される可能性のデータに含ま
れない、それは、放たれるべきＰＰＰフレームの同じデータの流れに属する。

【００５３】 ＩＰ層の制御データの後、認識される、伝送プロトコル領域は前記データ内を
探すことができる。前記領域の入り口が検査されたＰＰＰフレームで異なるとき
、明確に異なるデータの流れが関係する。もし、しかしながら、伝送プロトコル
を考慮した入り口は存在する、伝送側と受信側のＩＰアドレスは、検査される。
アドレスが一致した場合、伝送側と受信側のポート番号が検査される。もし違い
がなければ、この検査の間に検出される。同じデータの流れのＰＰＰフレームは
関係する。

【００５４】 図７によると、以下の場合が仮定されている、伝送側は、異なる２つのデータ
の流れ、ＵＤＰデータ流れとＴＣＰデータ流、１７０、からデータを伝送する。
ＰＰＰデータパケットは、カプセル化処理１８０内のデータから生成される。Ｕ
ＤＰデータの流れかＴＣＰのデータの流れ上の依存性は関係している、２種類の
ＰＰＰデータパケット、ＰＰＰ（ＩＰ（ＴＣＰ（ｎ）））とＰＰＰ（ＩＰ（ＵＤ
Ｐ（ｎ）））は区別される。ｎはこれによってＵＤＰパケットまたはＴＣＰパケ
ットの順序番号を明示する。図７によると、２つのＵＤＰパケットＰＰＰ（ＩＰ
（ＵＤＰ（１）））、ＰＰＰ（ＩＰ（ＵＤＰ（２）））と２つのＴＣＰパケット
、ＰＰＰ（ＩＰ（ＴＣＰ（１）））、ＰＰＰ（ＩＰ（ＴＣＰ（２）））は、ＰＰ
Ｐプロトコル層上に生成される。それらはＲＬＰプロトコル層へ伝送される、そ
のパッケージは、連続的なＲＬＰフレームＲＬＰ（１）、ＲＬＰ（２），．．．
ＲＬＰ（１２）、１９０、の中で同じ。それはすでに上で述べた、プロトコル層
の異なるデータパッケージ上の間の違いのなさはＲＬＰプロトコル層上で作られ
る。図７によると、データパケットＰＰＰ（ＩＰ（ＴＣＰ（１）））はＲＬＰ（
１）、ＲＬＰ（２）、ＲＬＰ（３）およびＲＬＰ（４）に分割される。ネットワ
ークプロトコル層の別のデータパケットは、同じやり方で分割される。ＲＬＰフ
レームの最終処理は、ネットワーク２００を経由して伝送することである。伝送
の間、ＲＬＰフレームの順序の変化が起こるかもしれない、それは、ＴＣＰデー
タの流れの不正確なＲＬＰ伝送のよくある繰り返しのためである。

【００５５】 図７によると、受信側は、ＲＬＰフレームＲＬＰ（１）を最初に受け取る、２
１０、そして、ＲＬＰフレームＲＬＰ（５）、ＲＬＰ（６）、ＲＬＰ（７）をそ
の後に受け取る、２２０。これらは完全に受信されたパケットとして認識される
。その結果、前記パケットは、データの流れのタイプのの検出の手順の中で検査
される。それはＵＤＰパケットＰＰＰ（ＩＰ（ＵＤＰ（１）））として認識され
る、そしてＰＰＰ層２３０に放たれる。ＰＰＰ層は、しかしながら、同じデータ
の流れにＰＰＰフレームがないのは、たぶんＲＬＰ受信機によってバッファーさ
れたデータが含まれる。この実施例で、異なるデータの流れに属するＰＰＰプロ
トコル層へＰＰＰフレームを解放することのみを認める。または、同じデータの
流れに対し、しかしながら、ＲＬＰフレームの番号付けを考慮して正しい手順の
みである。

【００５６】 図７によると、ＲＬＰフレーム、ＲＬＰ（８）、ＲＬＰ（９）、ＲＬＰ（１０
）は次の受信される、２４０。これらは完全なＰＰＰパケットＰＰＰ（ＩＰ（Ｕ
ＤＰ（２）））２５０であることが認識され、バッファーに蓄えられる。ＲＬＰ
プロトコルは、すでに放たれた同じデータの流れに属する最初のＵＤＰパケット
ＰＰＰ（ＩＰ（ＵＤＰ（１）））の情報を持っている、ＰＰＰぷろとこるそうへ
はなたれたＰＰＰ（ＩＰ（ＵＤＰ（２）））の情報に基づいて決定される。ＴＣ
ＰパケットのＰＰＰフレームはまだ完全に生成されていない、ＲＬＰ（１）のみ
を含むＰＰＰ（ＩＰ（ＴＣＰ（１）））、それはまだバッファに維持される。も
し、しかしながら、ＰＰＰ（ＩＰ（ＵＤＰ）（１）））もまた完全でない場合は
、ＰＰＰ（ＩＰ（ＵＤＰ（２）））が、ＰＰＰ（ＩＰ（ＵＤＰ（１）））が完全
に生成されるまで、バッファにたくわえられる。

【００５７】 以下の実施例で拡張した実現を提案する、そこで、異なる、同一の両データ
流に属する完全に生成されたＰＰＰフレーム放流を受け入れる。

【００５８】 以下に、前記実施例を、図８と特許請求項１７を用いてより詳細に説明する。

【００５９】 一時的に悪い伝送品質の接続を仮定する、それは高速ＰＰＰパケットの伝送の
間に起こる、最初に、ＰＰＰ（ＩＰ（ＵＤＰ（２）））が完全に受信される。こ
れはフレームＲＬＰ（８）、ＲＬＰ（９）、ＲＬＰ（１０）を受け取るために起
こる、２８０。中間のメモリは、一つのＲＬＰフレーム、ＲＬＰ（５）、のみを
含む、２７０。インターフローモードを認めるため、すべて完全に生成されたフ
レーム、これらもまた同じデータの流れに属する、は放たれる。これは独占的に
ＰＰＰフレームの完全を認めるを意味する。より高い層は、このとき、正しい手
順の中でパケットの配置に対する応答をする。ＲＬＰ（１）は最初に受信された
、そしてそれは不完全に生成されたＰＰＰ（ＩＰ（ＴＣＰ（１）））の最初のフ
レームを構成する、はバッファの中で維持される２６０。

【００６０】 以上、本発明はＧＳＭの中で典型的な応用によって紹介された。他のネットワ
ークにも、ＧＰＲＳネットワークのような、同じ応用の可能性がある。前記ネッ
トワークは、伝送側から受信側へパケット指向アプリケーションの伝送のために
設計されている。このプロトコル構造は両方の場合に比較できる。

【００６１】 本発明はまた、一つのリンクプロトコルのみが提供されている環境にも応用で きる。これは、単リンクプロトコルはＧＳＭの中でＰＰＰとＲＬＰ、またはＧＰ ＲＳの中でＬＬＣとＲＬＣの代わりに実現されることを意味する。この場合、前 記プロトコルは確実なモードの中で働くことが要求される。それは、例えば、Ｕ ＭＴＳの中で この形の実現を見つけることが可能である。

【図面の簡単な説明】

以下に、発明の実施例と図を用いてより詳細に発明を説明する。

【図１】 本発明の方法のフローチャートである。

【図２】 インターネットのプロトコル層の図である。

【図３】 ユーザーデータの模式的な図である。

【図４】 ネットワークシステムの図である。

【図５】 インターネットプロトコルダイアグラムである。

【図６】 ＲＬＰフレームの図である。

【図７】 インターフローモードの図である。

【図８】 イントラフローモードの図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ ，ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5K034 DD03 EE03 EE11 MM03 MM18 SS02 5K067 AA21 BB04 BB21 CC08 DD11 DD51 DD57 EE02 EE10 EE16 HH12 HH22 HH23 HH24 HH25 HH28 【要約の続き】 対して解放される。

Claims (25)

【特許請求の範囲】
1. 【請求項１】 通信ネットワークを経由した、第１と第２のプロトコル層を
   具備する送信側と受信側間のデータ通信において、パケット指向アプリケーショ
   ンの受信したデータの処理時間を改善する方法であって、 −送信側で第１のプロトコル層からのデータは第２のプロトコル層へ開放し、 −第１のプロトコル層のデータは、第２のプロトコル層の連続するデータパケッ
   トに分割し、 −第２のプロトコル層のデータパケットを通信ネットワークを経由して送信し、
   受信側によって受信された第２のプロトコル層のデータパケットを送信した順序
   に並べ替え、 −受信されたデータパケットを、第２のプロトコル層上で第１のプロトコル層の
   データパケット対応付けを行い、 −第１のプロトコル層のデータパケットが完全に作成された時点で、前記データ
   パケットは第１のプロトコル層に放出する方法。
2. 【請求項２】 伝送側および／または受信側内のデータ処理は、モジュラー
   プロトコル構造を基礎とする請求項１に記載の方法。
3. 【請求項３】 前記第２のプロトコル層のデータパケットは連続的に番号付
   けされていて、対応する連続番号によって符号付けされている、請求項１又は２
   に記載の方法。
4. 【請求項４】 前記第1のプロトコル層が、信頼と非信頼モードの少なくと
   も２つの通信モードをサポートする請求項１から３のいずれかに記載の方法。
5. 【請求項５】 第２のプロトコル層のデータパケットは、信頼通信モードと
   、送信エラーの場合は何度でも再送信して修正される、請求項４記載の方法。
6. 【請求項６】 第１のプロトコル層のデータは、分離子によって互いに明確
   に区別される請求項１から５いずれかに記載の方法。
7. 【請求項７】 受け取ったデータパケットは、順序番号に従った順序に並べ
   替えられる、請求項３記載の方法。
8. 【請求項８】 順序番号が、ＲＬＰ（無線リンクプロトコル）順序番号、ま
   たはＲＬＣ（無線リンク制御）順序番号である請求項３から７いずれかに記載の
   方法。
9. 【請求項９】 受信したデータパケットは受信側のバッファ内で並べ替えら
   れる、前記請求項１から８のいずれかに記載の方法。
10. 【請求項１０】 第２のプロトコル層のデータパケットの初期及び終端符号
    の両方が確実に受信され、そして、両者の間にある、第２のプロトコル層のすべ
    てのデータパケットが、正しい順番に従って受信されたならば、第１のプロトコ
    ル層のデータパケットを完全に生成されたデータパケットの状態にする請求項１
    から９記載の方法。
11. 【請求項１１】 最初のプロトコル層の完全に生成されたデータパケットは
    、付加的なプロトコル層のパケットの検証のために、カプセル化処理の規則によ
    って検査される、請求項１から１０に記載の方法。
12. 【請求項１２】 関連するデータの流れに関する情報を提供するために、制
    御データを有する少なくとも一つの制御領域が、第１のプロトコル層の完全に生
    成されたデータパケット内に提供される、請求項１から１１のいずれかに記載の
    方法。
13. 【請求項１３】 制御データは、ヘッダーそして／またはテールの形で対応
    するプロトコル層内の制御領域として実データシーケンスに付け加えられる、請
    求項１２に記載の方法。
14. 【請求項１４】 データの流れは、そのために提供される制御領域内の所定
    の制御データによって区別される、請求項１から１３のいずれかに記載の方法。
15. 【請求項１５】 データの流れを区別するための制御データは、源アドレス
    、指定アドレスおよびポート番号の形式の、送信および／または受信のアドレス
    である、請求項１４に記載の方法。
16. 【請求項１６】 第１に、第２のプロトコル層上のデータパケットが、完全
    で正確に受け取られており、そして第２に、第２のプロトコル層の受信器によっ
    てバッファーされた可能性のあるデータが、解放すべき第１のプロトコル層のデ
    ータパケットの同じデータの流れに属する第１のプロトコル層の付加的なデータ
    パケットを含まないことが保証されているなら、第１のプロトコル層のデータパ
    ケットは、第２のプロトコル層の上にある第１のプロトコル層へ直接解放される
    請求項１から１５のいずれかに記載の方法。
17. 【請求項１７】 もし前記データパケットが完全で正確に受信されたなら、
    第２のプロトコル層上で、第１のプロトコル層のデータは第１のプロトコル層へ
    直接解放される、請求項１から１５に記載のいずれかの方法
18. 【請求項１８】 第１のプロトコル層のデータパケットはＩＰダイアグラム
    であり、第２のプロトコル層のデータパケットはＰＰＰフレームであって、該Ｐ
    ＰＰフレームはエラーが発生したときに再送信することで訂正される、請求項１
    に記載の方法
19. 【請求項１９】 第１のプロトコル層のデータパケットはＰＰＰフレームで
    あって、第２のプロトコル層のデータパケットはＲＬＰフレームである、請求項
    １に記載の方法。
20. 【請求項２０】 データ伝送が、ＩＰネットワークと、移動体通信ネットワ
    ークを経由して行われる、請求項１に記載の方法。
21. 【請求項２１】 パケット指向アプリケーションは、インターネットアプリ
    ケーションである、請求項１に記載の方法。
22. 【請求項２２】 インターネットアプリケーションは、伝送プロトコル、伝
    送制御プロトコル（ＴＣＰ）によって伝送される請求項１８から２１に記載の方
    法
23. 【請求項２３】 インターネットアプリケーションは、伝送プロトコルユー
    ザーダイアグラムプロトコル（ＵＤＰ）によって伝送される、請求項１８ら２１
    に記載の方法
24. 【請求項２４】 通信ネットワークを経由した、第１と第２のプロトコル層
    における、伝送側と受信側間のデータ通信において、パケット指向アプリケーシ
    ョン内の受信データの処理時間を改善する装置であって、 −第１のプロトコル層のデータパケットを、第２のプロトコル層提供する手段と
    、 −データパケットを送信するための送信手段と、 −データパケットを受信するための受信手段と、 −データパケットを連続したデータパケットの順序に整列させるための整列手段
    と、 −第１のプロトコル層の完全に接続されたデータパケットを認識するための認識
    手段と、 −データの流れと、データパケットとの関係を検査するための手段と、 −第１のプロトコル層へ完全に生成されたデータパケットを解放するための解放
    手段とを有する装置。
25. 【請求項２５】 第２のプロトコル層の受信されたデータパケットを一時的
    に保存するためのバッファを有する請求項２４に記載の装置。