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

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

Info

Publication number
JP4594530B2
JP4594530B2 JP2000590357A JP2000590357A JP4594530B2 JP 4594530 B2 JP4594530 B2 JP 4594530B2 JP 2000590357 A JP2000590357 A JP 2000590357A JP 2000590357 A JP2000590357 A JP 2000590357A JP 4594530 B2 JP4594530 B2 JP 4594530B2
Authority
JP
Japan
Prior art keywords
protocol layer
data
protocol
packet
data packet
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
Application number
JP2000590357A
Other languages
English (en)
Other versions
JP2002534001A5 (ja
JP2002534001A (ja
Inventor
ライナー ルトヴィッヒ,
ベラ ラトニー,
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン(パブル) filed Critical テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Publication of JP2002534001A publication Critical patent/JP2002534001A/ja
Publication of JP2002534001A5 publication Critical patent/JP2002534001A5/ja
Application granted granted Critical
Publication of JP4594530B2 publication Critical patent/JP4594530B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は 通信ネットワークを通して、特にグローバル移動体通信システム(GSM)、ユニバーサル移動体電話システム(UMTS)、汎用パケット無線サービス(GPRS)のような移動体通信ネットワークとIPネットワークを通して通信を行うパケット指向アプリケーションにおいて、受信データの処理速度を改善するための装置と方法に関する。
【0002】
【従来技術】
プロトコルは、共通に通信をするため、通信相手との間ですべての取り決めの全体として定義される。従って、共通の束縛プロトコルは、2つの通信ネットワークノード間でデータのやりとりをするのに不可欠である。プロトコルは、普遍的で矛盾なく定義され、同一の基礎の上で、システムの限界を超えて異なるネットワークを連結させて通信することが可能であることが要求される。
【0003】
標準的な構成による通信のプロトコル全体は、層に分けられている。それぞれの層は独自のプロトコルによって割り当てられた課題を解決する。隣接した層間での通信は、明確に定義されたインターフェースによって保証される。この場合、n番目の層は、すぐ上のn+1層に直接連結されてサービスを提供し、すぐ下のn−1番目の層と直接連結されて当該層からサービスの提供を受ける。さらに、下位のすべての層のサービス層nと通信してサービスを提供する。よって、プロトコルデータユニットPDUの論理的なデータの流れは、一つのプロトコル層それぞれに実現される。受信側ではデータは逆の手順で処理される。すなわち、データは下位層からすぐ上のプロトコル層へ直接送られる
【0004】
プロトコル群の構造は物理的なネットワークやアプリケーションに応じて違っている可能性がある。しかしながら、異なるネットワーク間における通信の互換性を保証するには限界がある。標準化されたインターネットアプリケーションに対するプロトコル群は、TCP/IP(通信制御プロトコル/インターネットプロトコル)である。それは4つの層を有し、最上部の層−アプリケーション層−はアプリケーションプロトコルを具備する。通信プロトコル、例えばTCP(通信制御プロトコル)と呼ばれているものは、そのすぐ下に配置される。インターネットプロトコル−IPと呼ばれている−はネットワーク層を形成する。最も下の2層は−リンク層と物理層−ネットワーク指向層を形成するために連結することができ、それらはその下に配置されたネットワークに応じて特別に定義される。前記TCP/IPプロトコル群の標準構造とそれぞれの層間の通信リンクを図2に記載した。
【0005】
TCP伝送プロトコルは、ビットの流れに対し確実な伝送サービスを提供する。信頼性は、ここでは、エラーが無いこと、シーケンスの保守、データの喪失および重複に対する保護を意味する。エラー訂正はARQ(自動再送信要求)によって行われる。送信のためのパケットのコピーは送信側で作成されて、データパケットの送信が相手側に確実に承認されるまで保存される。受信側は受け取ったパケットを検査し、正確に受け取ったことをポジティブに確認し、誤って受け取ったパケットを削除する。この点に関して、TCPはネガティブな受信確認の伝送を許さないことは注目すべきである。不正確な伝送パケットの再送信はポジティブな承認の機構によって実行される、すなわち、もしポジティブな承認がなければ、状況によるが、パケットは受け取られていなかったと送信側は結論する。
【0006】
アプリケーション層からTCP層へ伝送されるビットの流れは、IPデータグラムとして伝送されるTCPによってセグメントに分割される。IPデータグラムはIPプロトコルの規則によってフォーマットされたデータパケットとして示される。データグラムを使うデータ交換によるデータグラムの特性は信頼できないというのがダイヤグラムの特性である。IPでは、パケットが本当に受信側に伝送されたかについては保証しない。IPデータグラムもまた順序が混乱し、あるいは受信側に2重に到着する。この概念の限界の中で、しかしながら、誤った伝送の検出や発生したエラーの訂正がTCPの仕事である。
【0007】
IPデータグラムは、さらには、その下に直接配置されたリンク層の階層原理によって伝送される。前記層はIPデータグラムを受け取って整理する、これはフレームと呼ばれる。これはフレーミングという名で知られている方法で行われる。すなわち、リンク層は一つかそれ以上のフレームの中にIPデータグラムとしてパッケージ化される。フレームは特別なビットの結合によって区画されている。ビット結合はフレームの始まりの分離符号、初期符号と呼ばれる、と終わりの分離符号、終端符号と呼ばれるどのようなビットの並びと対応するかが明記されている。
【0008】
フレームとは別に、リンク層は2つの特別な仕事をする。リンク層は誤り検出に関して信頼できる。従って、誤って伝送されたフレームは通常、受信側のリンク層によって削除される。この目的に対しデータパケットは、巡回符号、フレームチェック手順FCS、循環冗長チェックCRC、などと呼ばれる、が適用できる場を提供する。この考えは複数のデータパケットを解釈するためのものである。送信側は受信側が受け取った、生成多項式と呼ばれるわり算による残りの0を受け取ることにより、データパケット補足する。このようにして誤り検出は実現される。リンク層は、例えばARQ法を用いて、任意に誤り収集を行う。
【0009】
リンク層のプロトコルは、直接物理的に隣接したネットワークノード間で適用される。この目的のため、たくさんの代替プロトコルが定義される。2つのネットワークノード間にどのプロトコルが適用されるかは、2つのネットワークノードを連結するネットワークに依存する。よく知られているポイント・トゥー・ポイントプロトコル、PPP、はリンク層のプロトコルに対する例である。PPPは、構成と誤り検出というリンク層の最初の2つの仕事を実施する。よって、PPPが番号付けモードRFC1663と呼ばれるで動く特別な方法があるが、通常これは使用されていない。
【0010】
実際のところ、PPPは再送されたパケットを通しての修正をサポートしない、あるいは送信エラー率が高い場合にはこの方法は効率が悪いので、データ伝送で特にエラー率が高いネットワークでは特別な追加のプロトコルが適用される。例えば、移動体通信ネットワークは、高い伝送エラー比のネットワークとして知られている。GSM(移動体通信に対する広域システム)とGPRS(一般パケット無線サービス)はそこに分類される。特別なプロトコル−RLP(無線連結プロトコル)と呼ばれる、はGSMネットワークのリンク層に応用される。RLPセグメントのビットの流れはフレーム内のPPP層から受ける、それは普通PPPレベルのフレームより小さい。エラー訂正は、前記フレームを基礎としてARQ法によって取り扱われる。ARQの機能は、連続的に番号付けされたフレームを要求する。それゆえに、それぞれのフレームは、分類している間に、連続的な一連の順序番号を受け取る。今日の実施ではビットの流れはRLPフレームの中に確実に区分され、パッケージ化される。よって、データの種類、制御データまたは現実のデータに関する限り、データの種類は考慮されないままである。RLP層だけがビットの流れを知ることができる。それによって、2つの異なるPPPフレームからのデータは、一つのRLPフレームに結合される。RLPフレームはこのとき、最初のPPPフレームの終端符号を受ける、そして同様に次のPPPパケットの初期符号を受ける。この問題に対する解決法は、送信側の分離子に対するビットの流れを検査することを提案するヨーロッパ特許出願EP98 113 212.9で提供されている。このように、送信側でRLPパケットへのバイトの流れをパッケージ化するときに、異なるPPPパケットが区別され、それによって2つのPPPパケットからのデータがRLPの中で結合されることを防止している。
【0011】
両プロトコル、RLPとRLCはHDLC(高レベルデータリンクプロトコル)ISO87と似ているために、GPRSネットワークにおいても同様な機能がRLCプロトコルで実現されている。プロトコル間の差異はフレーム作成方法の中に存在する。
【0012】
プロトコル層と、とりわけプロトコルが互いに水平的に独立であるようにすることが階層構造の目的である。このように、IPプロトコルのように、同じネットワークプロトコルを経由して異なるアプリケーションと異なる通信プロトコルが通信することができる。さらに、IPプロトコルは異なるプラットフォーム上で機能できる。したがって、IPダイアグラムはGSM、GPRSのような異なる物理ネットワークを経由して伝送できる。
【0013】
ユーザにとって、プロトコルレベルでの通信はほとんど目にすることができな。ユーザーは、電子メール、ウェブブラウザのような異なるアプリケーションサービスをサポートする役立つシステムを期待する。データは、物理的リンクを通って送信することのできる限界を超えたサイズのパッケージを送信しようとすることが良くある。このため、メッセージは連続的に配置される小さなパケットに分割される。データの分割はフォーマットの一部である。データのフォーマットはそれぞれのプロトコル層で行われる。特定のプロトコル層、例えばRLP層、はデータの分割を行う、すなわち前記データは小さなデータブロックに再区分される。データブロックは異なる層では異なる名前を持つ。それらは、IPプロトコル層上のデータグラム、リンク層上のフレーム、と呼ばれる。さらに、それぞれプロトコル層に関係しないデータブロックは、データパケットによって明示される。
【0014】
データのフォーマットは、特に各プロトコル層で特徴付けられる制御データを有する。ほとんどの場合、制御データはヘッダーと呼ばれる形をデータパケットの始まりに付加する、そして/またはテールと呼ばれる形を最後に付加する。実データはユーザーデータ領域に含まれる。前記機構は以下のTCP/IPプロトコルスタックで詳細に説明する。
【0015】
図3によると、ユーザーデータはアプリケーション層で区分される、そして制御情報がそれぞれのデータパケットに付加される。前記データパケットは結果としてTCP伝送層へ転送される。前記層はそれのヘッダー形式の制御データを加える。前記データはネットワーク層へ伝えられる。それは、例えば、IPは処理手順情報のような適切な制御データを含む。この方法でIPダイヤグラムは形成され、以下の方法でリンク層に伝えられる。リンク層のプロトコル、例えばPPP、は分離子のような自身の制御情報を付け加えて受信したデータを処理する。この段階で生成されたデータパケットはフレームと呼ばれる。前記フレームは適切なネットワークを経由して伝送される。データパケットは異なる手順で受信側の適切な層に到着する。伝送された手順を再生するために、この層の受信側の処理ができる。これは、例えばTCPまたはRLP受信機の処理であるが、IP受信機の処理ではない。プロトコル層のデータパッケージ化の機構は、カプセル化として知られている。逆の機能は復カプセル化と呼ばれ、受信側で行われる。以下、RLPフレーム、RLCフレーム、またはPPPフレームの番号付けされたモードで働くデータパケットは、一般的な呼び名L2ARQフレームと称する。
【0016】
ユーザーデータはL2ARQの形式で、受信機に送られる。同時にL2ARQフレームは送信側のバッファーに蓄えられる。これはパケットが再送される場合には必要であろう。L2ARQフレームの連続番号によって、パケットが伝送の間に失なわれたかどうかを、受信側が判断する。もし一つのL2ARQフレームが失われると、前記L2ARQフレームの再送を始める。対応する機構によって送信側は発生したエラーのメッセージを受け取る。一致する番号のパケットをバッファから取り出して再送する。パケットが受信側にうまく伝送されると、送信側のバッファからそのパケットを削除する。
【0017】
この機構は番号付けモードと呼ばれる。前記モードは、送信側から受信側へ正確なデータが伝送されることをことを保証することによって、正確なサービスを提供する。非番号付けモードと呼ばれるものもある。前記モードは、ARQ処理を用いるので誤り訂正をしない。したがってこのモードは不正確な伝送である。
【0018】
パケットの再送信は、しかし、受信側に到達したパケットの順序は、送信された順序とは一致していないことになる。
【0019】
本発明に基づく手順では、L2ARQフレームを送信された順序に並べることは、−リンク層プロトコルがARQをサポートすることを条件として−リンク層プロトコルの役目である。これは、例えば受信されたPLPパケットは、RLPパケットが再作成される手順まで受信側のバッファに蓄積されることを意味する。これはまた、前記フレームが完全に該パケットを受信したとき、また前記フレームが以下の手順の時、RLPフレームRLPフレームは層の上に直接生成されることを意味する。もし、しかしながら、一つのフレームがエラーのために再送されると、すでに受信されたその後のすべてのフレームは再送されたフレームがエラー無く受信されるまでバッファに保存される。RLPパケットが一致する順序番号によって生成される手順に配置されるときのみ、PPP層を通過する。制御情報に先立って削除される。
【0020】
PPP層の受信機は、PPPフレームの確認を行う。このため、該受信機は分離子を探す。PPPフレームが完全に認識されたとき、IPダイヤグラムはIP層へ伝えられる、そのとき、該IPダイヤグラムはTCPプロトコル層上で受信したTCPセグメントを通過する。
【0021】
L2ARQフレームは、一致する手順の中の前記フレームを持ってくるために、リンク層上に一時的に蓄えられる、このため処理時間が長くなる。とくにこれは時間遅れに敏感なアプリケーションでは負の効果である。どんな程度であれ、長時間の遅れはデータ処理の効率を損ねる。遅れに敏感なアプリケーションの場合は、処理を中止する原因になる可能性もある。そのうえ、この方法は通信するプロトコル層上に多大なバッファを必要とする。とくに、RLPプロトコル層上で、パケットは要求された手順が再生されるまで、前記レベル上で一時的にバッファに蓄えられる。長いデータの貯蔵時間は、階層的なプロトコル構造の中ではデータ処理に対する時間を長くする。
【0022】
【発明が解決しようとする課題】
従って、データ伝送において、パケット指向アプリケーションの受信側のデータ処理をより効率的に行う方法と装置を提供することが、本発明の目的である。特に受信側で、必要なメモリー空間を削減することが本発明の目的である。
【0023】
【課題を解決するための手段】
本発明によれば前記目的は、特許請求項1及び特許請求項24によって提供される。
【0024】
リンク層上で完全に生成されたパケットをすぐ上のプロトコル層に直接伝送することによって、長時間の一時保存を行わないことが利点である。
【0025】
この理由のため、受信したデータはより早くアプリケーション層に伝送され、それによって遅延に対して敏感なアプリケーションのより安定した動作を保証するという利点も提供する。
【0026】
別の利点として、受信したデータが、受信したデータのシーケンスが提供されるまでバッファに蓄えられず、いくつかのデータパケットが受信されていない可能性があったとしても、完全に生成されたパケットはプロトコル層上に直接生成されるので、対応する受信側上のプロトコル層で必要とされる記憶容量を削減することができることである。
【0027】
発明のさらなる利点は、特許請求項2,23,25からもたらされるものである。
【0028】
【実施例】
以下に、図1と請求項1によって発明を説明する。
【0029】
図1によると、最初のプロトコル層のデータパケットは、伝送側10に提供され、直ぐ下の第2のプロトコル層20に直接伝達される。前記層は第2のプロトコル層30のデータパケットの中に受信したデータをパッケージ化する。第2のプロトコル層のデータパケットは、最初のプロトコル層の異なる2つのデータパケットを含まない。第2のプロトコル層のそれぞれのデータパケットはただ一つの順序番号を受け取る。この方法でパッケージ化された第2のプロトコル層のデータパケットは、前述の手順40が有効なネットワークへ送られる、そして、その結果としてネットワーク50を通して伝送される。第2のプロトコル層の個々のデータパケットは、受信側60で受信される。受信された第2のプロトコル層のデータパケットは、番号70の順序に従って並び替えられて、提供されるバッファ80に蓄えられる。それらは最初のプロトコル層90のデータパケットを認識するために順番に検査される。もし、第2のプロトコル層のデータパケットが受信されると、このデータが、最初のプロトコル層の分離子含むかどうかが検査される。もし含むならば、最初のプロトコル層の初期符号か終端符号のどちらか一方が重要である。初期補号の場合は、第2のプロトコル層のそれに続くデータパケットは最初のプロトコル層の新しいデータパケットに属することを意味する。第2のプロトコル層のデータパケットは、最初のプロトコル層のデータパケットが100に完全に受信されるまで、バッファに蓄えられる。これは第2のプロトコル層のデータパケットの受領書によって検出される、データ領域は終端符号を含む、そしてさらに手順の中に以下の一つを含む。最初のプロトコル層の完全に生成された唯一のデータパケットだけが110の上のプロトコル層に直接生成される。
【0030】
以下に、特許請求項23による発明を説明する。
【0031】
第2のプロトコル層上の第1のプロトコル層のデータパケットと、送信順序に従うそれらの配置は、第2のプロトコル層へ、最初のプロトコル層のデータパケットが提供されることによって実現される。前記データパケットは伝送手段によって提供されるネットワークを通して伝送される。受信側のデータパケットの受信に対する受信手段はパケットを受信する。受信されたデータパケットの分類に対する分類手段で、連続的な順序の中へ組み込まれる、そして、第2のプロトコル層の受信したデータパケットを一時的に保存するためのバッファに蓄えられる。第2のプロトコル層のデータパケットは、第1のプロトコル層のデータパケットが認識できるかどうかで検査される。これは第1のプロトコル層における、完全に結合されたデータパケットを検出するための検出手段によって行う。その結果として、最初のプロトコル層で完全に生成されたデータパケットはデータの流れの結合として検査手段によって検査される。それ故に、検査されたデータパケットは、最初のプロトコル層へ完全に生成されたデータを解放するために解放手段によって解放される。
【0032】
本発明の応用の可能な領域は、GSMのような、移動データネットワークを通してのインターネットアプリケーションの領域である。本発明の可能な応用は、本発明の実施例により詳細に説明した。それによって、データの処理は受信側の完全に生成されたデータパケットの解放までを、伝送側のアプリケーションとして図示した。
【0033】
この目的のため、模式的に示した図4のネットワークシステムが使われる。移動加入者間通信、例えば、移動局と固定ネットワーク内の加入者の集合、サーバー、はこれによって模式的に図示される。図中上部は、通信ユニットと一致する物理的な接続を示している、そして下部は複雑なプロトコルの論理的な結合を構成する。
【0034】
移動局MSは、例えば、ラップトップコンピュータである。前記ラップトップコンピュータは末端の接続機能(TAF)を通して接続する。その仕事は、例えば、移動電話のような移動局MSと、PCMCIA(Personal Computer Memory Card International Association)によって行われる。移動局MSはBTS(基地無線局)と通信する、それは、再度BSC(基地局コントローラ)と通信する。公衆アナログ電話ネットワークとの接続、公衆切り替え電話ネットワーク(PTSN)と呼ばれている、はインターワーキング機能IWFと呼ばれている中に集積されているモデムにより実現する。インターワーキング機能IWFは移動切り替えセンター、移動サービス切り替えセンタ(MSC)と呼ばれている。さらに、接続はインターネットへのネットワーク伝送ノードを持っているインターネットサービスプロバイダー(ISP)へ、公衆電話ネットワークPTSNを通して接続される。末端加入者への接続、サーバー、はインターネットを通して成立する。明確のためインターネットを通しての接続は図4にさらに詳細に記載しない。
【0035】
アプリケーションは下部のプロトコル層から独立に実施する。それによって生成されたデータの伝送は、ユーザに明瞭な方法で実行される。これはまた、プロトコルスタックの階層構造の目標でもある、すなわち、システムの中にユーザーを含めることなく、最適で安定な伝送を保証する。それは、しかしながら、映像データの伝送やインターネットへのアクセスのようなユーザーによって使用されるすべてのアプリケーションサポートするシステムから期待される。異なるアプリケーションは、しかしながら、システムで異なる要求を持っている。
【0036】
銀行取引のような確かなインターネットアプリケーション、例えば、安全な伝送プロトコルの要求、このやり方に対してのみインターネットを通してお金の取引の間エラーのないデータの流れが保証される。データの安全な伝送は、伝制御プロトコルTCPと呼ばれる物によって保証される。
【0037】
対照的に、それに加えて、映像伝送の場合は、データ伝送の確実な安全の報償をするプロトコルの使用は要求されない。伝送時に長い遅れ時間の可能性でも確実なデータの流れは安全として。映像伝送の場合は、映像の提示の中で現実的な感じを得るために、手順の中でデータのより早い伝送に対する保証がよりよい。伝送中に起こるかもしれないエラーは、一定の限界である、そして、映像の放送の時我慢できる。この理由のため、誤り訂正プロトコルは、映像伝送では使われない。伝送段階のそのようなプロトコルの例は、ユーザーデータグラムプロトコルUDPである。
【0038】
一つのセッションでユーザーが使ういくつかのアプリケーションの最も多くの場合は、例えば、ユーザーが、Eメールを送り、背景で同時に映像を伝送したいときはいつでもである。この場合、ユーザーは異なる2つのデータの流れを生成する。Eメールの伝送はTCPが基礎である、映像伝送はUDPが基礎である。別の例ではインターネットのアクセスである。一つのセッションのあいだ複数のインターネットのページが開かれている、それはしばしば異なるサーバに置かれる。だけれども、生成されたデータの流れは独占的にTCPの流れである。異なるデータの流れは、この場合、当該受信者は異なる。
【0039】
前記特徴は、IP層のような、ネットワークプロトコル層を考慮される。前記層は、伝送プロトコル層からパケットを受信する、独自フォーマットのパケットを形成するために束ねる。図5はIPパケットのフォーマットを図示する。前記パケットは、例えば、IPプロトコルバージョンのIPv4またはIPv6のバージョンのなかのデータを含む。これはず5に詳細には示されていない。さらに、IPデータフォーマットは伝送プロトコルに関しての情報を含む領域で提供される。UDPプロトコルの場合は、ビットの結合は前記領域内へはいる、これはUDPの呼称に相当する。
【0040】
データの流れを識別する決定的な要因は、しかしながら、プロトコルのタイプだけでなく、IPヘッダに含まれるアドレスに関する要因もである。これは、もし送信側のIPアドレスと受信側のIPアドレスが図5による2つのIPパケットが一致するならば、TCPヘッダーはさらにデータの流れの違いを見つける手順で、検査される。異なるポート番号が異なるデータの流れに割り当てられる。前記ポート番号は、相手との間の通信が保証されるために、伝送段階の一致するデータの流れが同一である。TCPパケットのヘッダーはポート番号についての情報を含む、それは、データの流れを区別するとき比較される。伝送側と受信側のポート番号が同じとき、データの流れは同じである。もし前記アドレスが異なるとき、すなわち、もし両IPアドレスとポート番号が互いに異なるとき、受信機は異なる、そして、データの流れが異なる。前記の仕組みが今日使用されているIPのバージョンで実現されている、これはインターネットプロトコルバージョンIPv4と呼ばれている。次のIPのバージョンは6、IPv6、である、定義は基本的に同じである。ここで、異なるデータの流れは、データフロー身分証明と呼ばれる物−あるいはフロー身分証明によって区別される。記述された方法はIPv6上に転移できる、そして基本的にデータの流れのような、それぞれのプロトコルスタックは認識できる。
【0041】
IP層上のパケット同一か又は異なるデータの流れを得るかどうかの依存性、違いは2つのモード間で作られる。同一のデータの流れ、イントラデータ流またはイントラ流モードと呼ばれる、IPパケットの場合に関する。インターフローモードの間はモードを明示する、これは異なるデータに属するIPパケットは区別される。
【0042】
図4によると、インターネットにおける移動局とサーバー間の伝送層上の結合はすでに築きあげられている、前記サーバーから移動局MSへのデータの流れの一例を以下に示す。この例では通信ユニットと通信プロトコルを含めてより詳細に説明する。
【0043】
ネットワーク層上でパッケージ化されたIPダイヤグラムは、インターネットサービスプロバイダーISPと呼ばれるインターネットを経由して伝送される。ISPは受け取ったIPパケットをPPP層に伝送する。前記層は得たデータからPPPフレ−ムでフォーマットされたビットの流れを生成する。受け取ったパケット間の区別のために、分離子を付け加える。その結果として、PPPフレームはアナログ伝送に対して提供される。ISPは、伝送比とモードに応じてデータをアナログ信号に変調して伝送するためのモデムを提供する。図示した例では、アナログネットワークを経由して接続か実行される。PSTN、これはv32モデムである。もし、ISDNネットワークを経由して接続されるならば、v.110プロトコルが例えば使われる。流れの制御のため、すなわち、インターネットの中の機能IWFでデータがオーバーフローしないための手順として、v.42が使われる。前記機能はGSMの中の無線リンクプロトコルRPLの機能と一致する。
【0044】
インターネットの機能IWF内で、受け取ったデータのフォーマットへの換算はGSMを実行することによって行われる。
【0045】
この手段は、PPP層のビットの流れは、RLP層へ放たれる。前記層は、受け取ったビットの流れをRLPフレームへパッケージ化する。RLPフレームのフォーマットは図6に記載した。RLPフレームは240ビットある。16ビットはヘッダー情報のために予定されている、24ビットはフレームチェック手順FCSである。RLPフレームの中でPPPフレームをパッケージングするときの決定的な要因は、より高いプロトコル層のデータパケットは、受け取ったビットの流れの中でRLP層へ直接明白でないことである。これは、RLP層はPPPフレーム間、またはIPダイアグラム間、そして伝送層のパケット間で違いを作ることができない。パケットの区別のためにビットの流れは分離子をチェックしなければならない。これは異なる2つのPPPフレームからのデータを、一つのRLPフレームにパッケージ化しないようにするために必要である。それぞれの新たに生成されたRLPフレームは、順序番号と共に提供される。このやり方で配置されたパケットは提供された移動ネットワークを経由して伝送される。伝送の間、RLPフレームの手順は、発生する伝送エラーと接続のためのARQ処理のために混乱する。フレームは代わった手順内で受信側によって受信される。受信機はの中でRLPフレームのポジションを見つけるための手順内の順序番号に対して受信したRLPフレームをチェックする。別な段階で、RLPフレームが分離子を含んで受信したかどうかをチェックする。もしそれが初期符号を含んでいるならば、それに続くPPPフレーム内で最初のフレームとして検出されるだろう、そして、一致するポジション上のバッファーへ蓄えられる。それに続く連続的な番号を示すRLPフレームは、一致するポジション上のバッファーへ蓄えられる。これはPPPフレームが完全に生成されたフレームの状態を受信するまで続く。PPPフレームは完全に生成される、もし初期及び終端両符号が確実に受信されたならば、そしてすべてのRLPフレームが確実に受信されたならば、そしてそれらがどんな飛び越しも無しに、そして初期符号と終端符号含むRLPフレーム間の正しい手順に置かれるならば。RLPフレームがバッファーに蓄えられる前に、フレームが復カプセル化、すなわち、RLPプロトコル層の制御データが削除される
【0046】
RLPフレームがチェックされるときPPPパケットが区別されるだけでなく、フレームのチェックIPパケットの検出に拡張できる。これは、イントラーフローモードとインターフローモードを区別するための基礎である。すでに述べたように、IPヘッダーは伝送プロトコルの使用を考慮する情報を含む、そして、同じアドレスを含む。IPダイアグラム全体がPPPフレームに合致するという事実のため、PPPフレームを終わらせる検査は、IPダイアグラムと情報の認識のため指定することができる、すなわち、異なるデータの流れのIPダイアグラムが同じかどうか。
【0047】
この目的のため、フレームの制御データは、完全なPPPフレームが生成された後にチェックされる。データはそれぞれのプロトコル層の制御データに対して特に検査される。これは、完全に結合されたデータパケットに対する承認のために、承認手段を用いて承認される。それぞれの層の制御データを考慮した情報は前記手段で役立つ、この基礎はリンク層から引き出された制御データで作られた決定である。特にPPPから、IP制御層の制御データ始まる。データの復カプセル化のフォーマットはそれぞれの層で標準化されている。実現化は前記のメカニズムで作られなければならない、それはカプセル化の正当な標準に似ている。IPダイアグラムのより厳密な説明は以下に説明する実施例に示す。
【0048】
IPダイアグラムは直接プロトコル層の上に伝送される−伝送層−。TCPパケットは等分に連続に番号付けされる、そして伝送層上のTCPパケットのあらかじめ番号付けされた手順は生成される。言い換えると、TCPは正確な手順の中で、TCPパケットの配置に対して信頼できる、この段階で、適切でないパケットも検出される、エラーはパケットの再送信に対する照会を始めることによって削除される。
【0049】
TCPは伝送されたTCPパケットの正確な手順を生成するために信頼できる。これはもはや、ネットワークプロトコル層と同じ振る舞いを要求する必要はない。これは特に、変更された手順内で受け取ったIPダイアグラムを許す。不正確な手順のIPダイアグラムの受信に対する原因は、非同期伝送である。個々のパケットは異なる通り道を取ることができる。パケットはそれらの通り道上で互いに追い越して送られる、それによって、変わった手順でレシーバーに到達する。伝送層、特にTCP、は手順の生成に対して信頼できる。ネットワーク層でのIPパケットの順序が変わる範囲は重要ではない。これは特にパケット処理の効率が影響されないことを意味する、もしRLPプロトコル層によって後から順序が変わっても。
【0050】
UDPの同じ理由により、パッケージの順序の変更が認められる
【0051】
以下に、インターフローモードに対する、特許請求項16による発明の実現を図7を用いてより詳細に説明する。
【0052】
インターフロ−モードでは、異なるデータの流れに属するパケットは、区別される。この目的のため、完全に生成されたPPPフレームは検査される、上記に記載された。前記モードにおいて、PPPフレームはRLPレシーバーによってすでに放たれる、最初に、それらが完全で正確に受け取ったとき、そして、2番目に、PPPフレームはRLP受信機によって緩衝される可能性のデータに含まれない、それは、放たれるべきPPPフレームの同じデータの流れに属する。
【0053】
IP層の制御データの後、認識される、伝送プロトコル領域は前記データ内を探すことができる。前記領域の入り口が検査されたPPPフレームで異なるとき、明確に異なるデータの流れが関係する。もし、しかしながら、伝送プロトコルを考慮した入り口は存在する、伝送側と受信側のIPアドレスは、検査される。アドレスが一致した場合、伝送側と受信側のポート番号が検査される。もし違いがなければ、この検査の間に検出される。同じデータの流れのPPPフレームは関係する。
【0054】
図7によると、以下の場合が仮定されている、伝送側は、異なる2つのデータの流れ、UDPデータ流れとTCPデータ流、170、からデータを伝送する。PPPデータパケットは、カプセル化処理180内のデータから生成される。UDPデータの流れかTCPのデータの流れ上の依存性は関係している、2種類のPPPデータパケット、PPP(IP(TCP(n)))とPPP(IP(UDP(n)))は区別される。nはこれによってUDPパケットまたはTCPパケットの順序番号を明示する。図7によると、2つのUDPパケットPPP(IP(UDP(1)))、PPP(IP(UDP(2)))と2つのTCPパケット、PPP(IP(TCP(1)))、PPP(IP(TCP(2)))は、PPPプロトコル層上に生成される。それらはRLPプロトコル層へ伝送される、そのパッケージは、連続的なRLPフレームRLP(1)、RLP(2),...RLP(12)、190、の中で同じ。それはすでに上で述べた、プロトコル層の異なるデータパッケージ上の間の違いのなさはRLPプロトコル層上で作られる。図7によると、データパケットPPP(IP(TCP(1)))はRLP(1)、RLP(2)、RLP(3)およびRLP(4)に分割される。ネットワークプロトコル層の別のデータパケットは、同じやり方で分割される。RLPフレームの最終処理は、ネットワーク200を経由して伝送することである。伝送の間、RLPフレームの順序の変化が起こるかもしれない、それは、TCPデータの流れの不正確なRLP伝送のよくある繰り返しのためである。
【0055】
図7によると、受信側は、RLPフレームRLP(1)を最初に受け取る、210、そして、RLPフレームRLP(5)、RLP(6)、RLP(7)をその後に受け取る、220。これらは完全に受信されたパケットとして認識される。その結果、前記パケットは、データの流れのタイプのの検出の手順の中で検査される。それはUDPパケットPPP(IP(UDP(1)))として認識される、そしてPPP層230に放たれる。PPP層は、しかしながら、同じデータの流れにPPPフレームがないのは、たぶんRLP受信機によってバッファーされたデータが含まれる。この実施例で、異なるデータの流れに属するPPPプロトコル層へPPPフレームを解放することのみを認める。または、同じデータの流れに対し、しかしながら、RLPフレームの番号付けを考慮して正しい手順のみである。
【0056】
図7によると、RLPフレーム、RLP(8)、RLP(9)、RLP(10)は次の受信される、240。これらは完全なPPPパケットPPP(IP(UDP(2)))250であることが認識され、バッファーに蓄えられる。RLPプロトコルは、すでに放たれた同じデータの流れに属する最初のUDPパケットPPP(IP(UDP(1)))の情報を持っている、PPPぷろとこるそうへはなたれたPPP(IP(UDP(2)))の情報に基づいて決定される。TCPパケットのPPPフレームはまだ完全に生成されていない、RLP(1)のみを含むPPP(IP(TCP(1)))、それはまだバッファに維持される。もし、しかしながら、PPP(IP(UDP)(1)))もまた完全でない場合は、PPP(IP(UDP(2)))が、PPP(IP(UDP(1)))が完全に生成されるまで、バッファにたくわえられる。
【0057】
以下の実施例で拡張した実現を提案する、そこで、異なる、同一の両データ流に属する完全に生成されたPPPフレーム放流を受け入れる。
【0058】
以下に、前記実施例を、図8と特許請求項17を用いてより詳細に説明する。
【0059】
一時的に悪い伝送品質の接続を仮定する、それは高速PPPパケットの伝送の間に起こる、最初に、PPP(IP(UDP(2)))が完全に受信される。これはフレームRLP(8)、RLP(9)、RLP(10)を受け取るために起こる、280。中間のメモリは、一つのRLPフレーム、RLP(5)、のみを含む、270。インターフローモードを認めるため、すべて完全に生成されたフレーム、これらもまた同じデータの流れに属する、は放たれる。これは独占的にPPPフレームの完全を認めるを意味する。より高い層は、このとき、正しい手順の中でパケットの配置に対する応答をする。RLP(1)は最初に受信された、そしてそれは不完全に生成されたPPP(IP(TCP(1)))の最初のフレームを構成する、はバッファの中で維持される260。
【0060】
以上、本発明はGSMの中で典型的な応用によって紹介された。他のネットワークにも、GPRSネットワークのような、同じ応用の可能性がある。前記ネットワークは、伝送側から受信側へパケット指向アプリケーションの伝送のために設計されている。このプロトコル構造は両方の場合に比較できる。
【0061】
本発明はまた、一つのリンクプロトコルのみが提供されている環境にも応用できる。これは、単リンクプロトコルはGSMの中でPPPとRLP、またはGPRSの中でLLCとRLCの代わりに実現されることを意味する。この場合、前記プロトコルは確実なモードの中で働くことが要求される。それは、例えば、UMTSの中で この形の実現を見つけることが可能である。
【図面の簡単な説明】
以下に、発明の実施例と図を用いてより詳細に発明を説明する。
【図1】 本発明の方法のフローチャートである。
【図2】 インターネットのプロトコル層の図である。
【図3】 ユーザーデータの模式的な図である。
【図4】 ネットワークシステムの図である。
【図5】 インターネットプロトコルダイアグラムである。
【図6】 RLPフレームの図である。
【図7】 インターフローモードの図である。
【図8】 イントラフローモードの図である。

Claims (24)

  1. 通信ネットワークを経由した、第1とその下の第2のプロトコル層をそれぞれが具備する送信側と受信側間のデータ通信において、パケット指向アプリケーションの受信したデータの処理時間を改善する方法であって、
    −送信側(20)で第1のプロトコル層からのデータは第2のプロトコル層へ解放され
    −第1のプロトコル層のデータは、連続番号を有する一連のデータパケットを生成する第2のプロトコル層の連続するデータパケットに分割され、第2のプロトコル層の1つのデータパケットは第1のプロトコル層(30)のただ1つのデータパケットからのデータを含むようにし、
    −第2のプロトコル層のデータパケット通信ネットワーク(50)を経由して送信され
    −受信側(60)によって受信された第2のプロトコル層のデータパケット第2のプロトコル層上で該連続番号によって該一連のデータパケットに並べ替えられて
    −受信されたデータパケットを、第2のプロトコル層上で第1のプロトコル層のデータパケットに対応付けを行い、
    −第1のプロトコル層のデータパケットが完全に作成(100)されたで、前記データパケットはデータの流れの関連を調べられ、第1のプロトコル層(110)に解放される方法。
  2. 前記第2のプロトコル層のデータパケットは連続的に番号付けされていて、対応する連続番号によって符号付けされている、請求項に記載の方法。
  3. 前記第1のプロトコル層が、信頼と非信頼モードの少なくとも2つの通信モードをサポートする請求項1からのいずれかに記載の方法。
  4. 第2のプロトコル層のデータパケットは、信頼通信モードと、送信エラーの場合は何度でも再送信して修正される、請求項記載の方法。
  5. 第1のプロトコル層のデータは、分離子によって互いに明確に区別される請求項1からいずれかに記載の方法。
  6. 受け取ったデータパケットは、順序番号に従った順序に並べ替えられる、請求項記載の方法。
  7. 順序番号が、RLP(無線リンクプロトコル)順序番号、またはRLC(無線リンク制御)順序番号である請求項2から6いずれかに記載の方法。
  8. 受信したデータパケットは受信側のバッファ内で並べ替えられる、前記請求項1からのいずれかに記載の方法。
  9. 第2のプロトコル層のデータパケットの初期及び終端符号の両方が確実に受信され、そして、両者の間にある、第2のプロトコル層のすべてのデータパケットが、正しい順番に従って受信されたならば、第1のプロトコル層のデータパケットを完全に生成されたデータパケットの状態にする請求項1から記載の方法。
  10. 最初のプロトコル層の完全に生成されたデータパケットは、付加的なプロトコル層のパケットの検証のために、カプセル化処理の規則によって検査される、請求項に記載の方法。
  11. 関連するデータの流れに関する情報を提供するために、制御データを有する少なくとも一つの制御領域が、第1のプロトコル層の完全に生成されたデータパケット内に提供される、請求項9または10のいずれかに記載の方法。
  12. 制御データは、ヘッダーそして/またはテールの形で対応するプロトコル層内の制御領域として実データシーケンスに付け加えられる、請求項11に記載の方法。
  13. データの流れは、そのために提供される制御領域内の所定の制御データによって区別される、請求項1から12のいずれかに記載の方法。
  14. データの流れを区別するための制御データは、源アドレス、指定アドレスおよびポート番号の形式の、送信および/または受信のアドレスである、請求項13に記載の方法。
  15. 第1に、第2のプロトコル層上のデータパケットが、完全で正確に受け取られており、そして第2に、第2のプロトコル層の受信器によってバッファーされた可能性のあるデータが、解放すべき第1のプロトコル層のデータパケットの同じデータの流れに属する第1のプロトコル層の付加的なデータパケットを含まないことが保証されているなら、第1のプロトコル層のデータパケットは、第2のプロトコル層の上にある第1のプロトコル層へ直接解放される請求項1から14のいずれかに記載の方法。
  16. もし前記データパケットが完全で正確に受信されたなら、第2のプロトコル層上で、第1のプロトコル層のデータは第1のプロトコル層へ直接解放される、請求項1から14に記載のいずれかの方法。
  17. 第1のプロトコル層のデータパケットはIPダイアグラムであり、第2のプロトコル層のデータパケットはPPPフレームであって、該PPPフレームはエラーが発生したときに再送信することで訂正される、請求項1に記載の方法。
  18. 第1のプロトコル層のデータパケットはPPPフレームであって、第2のプロトコル層のデータパケットはRLPフレームである、請求項1に記載の方法。
  19. データ伝送が、IPネットワークと、移動体通信ネットワークを経由して行われる、請求項1に記載の方法。
  20. パケット指向アプリケーションは、インターネットアプリケーションである、請求項1に記載の方法。
  21. インターネットアプリケーションは、伝送プロトコル、伝送制御プロトコル(TCP)によって伝送される請求項17から20に記載の方法。
  22. インターネットアプリケーションは、伝送プロトコルユーザーダイアグラムプロトコル(UDP)によって伝送される、請求項17から20に記載の方法。
  23. 通信ネットワークを経由した、第1とその下の第2のプロトコル層をそれぞれが具備する、伝送側と受信側間のデータ通信において、パケット指向アプリケーション内の受信データの処理時間を改善する装置であって、
    −第1のプロトコル層のデータパケットを、第2のプロトコル層提供する手段(10)であって、第1のプロトコル層のデータを、連続番号を有する一連のデータパケットを生成する第2のプロトコル層の連続するデータパケットに分割するように構成され、第2のプロトコル層の1つのデータパケットは第1のプロトコル層(30)のただ1つのデータパケットからのデータを含むようにした手段と、
    −データパケットを送信するための送信手段(40)と、
    −データパケットを受信するための受信手段(60)と、
    −受信したデータパケットを該連続番号によって該一連のデータパケットに並べ替えるための整列手段(70)と、
    該一連のデータの順序通りに第1のプロトコル層の完全に結合されたデータパケットを認識するための認識手段(100)と、
    第1のプロトコル層の完全に結合されたデータパケットが認識された後でデータの流れと、第1のプロトコル層のデータパケットとの関係を検査するための手段と、
    −第1のプロトコル層へ完全に生成されたデータパケットを解放するための解放手段(110)とを有する装置。
  24. 第2のプロトコル層の受信されたデータパケットを一時的に保存するためのバッファを有する請求項23に記載の装置。
JP2000590357A 1998-12-22 1999-12-13 通信ネットワークにおけるデータ処理時間の削減に関する方法および装置 Expired - Lifetime JP4594530B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP98124010A EP1014641A1 (de) 1998-12-22 1998-12-22 Verfahren und Vorrichtung zur Reduzierung der Aufarbeitungszeit von Daten in Kommunikationsnetzen
EP98124010.4 1998-12-22
PCT/EP1999/009861 WO2000038390A1 (en) 1998-12-22 1999-12-13 Method and device for reducing the processing time of data in communication networks

Publications (3)

Publication Number Publication Date
JP2002534001A JP2002534001A (ja) 2002-10-08
JP2002534001A5 JP2002534001A5 (ja) 2006-12-07
JP4594530B2 true JP4594530B2 (ja) 2010-12-08

Family

ID=8233163

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000590357A Expired - Lifetime JP4594530B2 (ja) 1998-12-22 1999-12-13 通信ネットワークにおけるデータ処理時間の削減に関する方法および装置

Country Status (10)

Country Link
US (1) US6948108B1 (ja)
EP (2) EP1014641A1 (ja)
JP (1) JP4594530B2 (ja)
CN (1) CN1287576C (ja)
AT (1) ATE332051T1 (ja)
AU (1) AU760994B2 (ja)
CA (1) CA2356900A1 (ja)
DE (1) DE69932184T2 (ja)
ES (1) ES2270631T3 (ja)
WO (1) WO2000038390A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3525869B2 (ja) * 2000-07-12 2004-05-10 日本電気株式会社 パケット通信システムの接続装置及び方法
FR2818066B1 (fr) 2000-12-12 2003-10-10 Eads Airbus Sa Procede et dispositif de transmission deterministe de donnees asynchrones mises en paquet
FR2818844B1 (fr) * 2000-12-22 2003-03-07 Mitsubishi Electricite Procede de transmission de donnees entre au moins un emetteur et au moins un recepteur, emetteur, recepteur et systeme de transmission correspondants
WO2002069519A1 (en) * 2001-02-23 2002-09-06 Nokia Inc. System and method for fast gprs for ipv6 communications
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
EP1253736A3 (en) * 2001-04-26 2003-12-10 NTT DoCoMo, Inc. Data link transmission control for mobile communications
US20030002467A1 (en) * 2001-06-29 2003-01-02 Leung Nikolai K.N. Internet protocol framing using radio link protocol
KR100469720B1 (ko) * 2001-10-15 2005-02-02 삼성전자주식회사 이동통신시스템에서 과금장치 및 방법
CN100438492C (zh) * 2003-09-30 2008-11-26 美国博通公司 用于IEEE802.11g接收器的分类器
US7269146B2 (en) * 2003-10-20 2007-09-11 Motorola Inc. Method and apparatus for interchanging and processing mobile radio subsystem control information
US7814219B2 (en) * 2003-12-19 2010-10-12 Intel Corporation Method, apparatus, system, and article of manufacture for grouping packets
KR100583872B1 (ko) * 2004-03-17 2006-05-26 주식회사 팬택앤큐리텔 기지국의 상향 링크 패킷 전송 방법 및 그 방법이 구현된이동통신 시스템
WO2005094020A1 (en) * 2004-03-19 2005-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using rlp
US7586882B2 (en) 2004-03-19 2009-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using RLP
US7626926B2 (en) * 2004-12-09 2009-12-01 Airvana, Inc. Traffic management in a wireless data network
JP5210895B2 (ja) * 2008-02-20 2013-06-12 株式会社日立製作所 無線通信システム、端末及び基地局
CN101729224A (zh) * 2008-10-20 2010-06-09 富士通株式会社 传输数据生成装置和接收机
CN102377805A (zh) * 2010-08-20 2012-03-14 贺心雅 自动腹膜透析无线网络系统及数据传输方法
CN102761571B (zh) * 2011-04-28 2014-11-12 上海市特种设备监督检验技术研究院 电梯智能物联终端
CN109743766B (zh) 2018-02-13 2020-06-16 华为技术有限公司 一种数据路由选择的方法及装置

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4703475A (en) * 1985-12-04 1987-10-27 American Telephone And Telegraph Company At&T Bell Laboratories Data communication method and apparatus using multiple physical data links
JPS6399651A (ja) * 1986-10-15 1988-04-30 Nec Corp デ−タ通信方式
US5243592A (en) * 1990-10-15 1993-09-07 Digital Equipment Corporation Method and apparatus for distance vector routing on datagram point-to-point links
JPH04291556A (ja) * 1991-03-20 1992-10-15 Fujitsu Ltd 通信制御方式
US6088342A (en) * 1997-05-05 2000-07-11 Nokia Mobile Phones Limited Dynamic configuration of radio link protocol in a telecommunications system
US5570367A (en) * 1994-07-29 1996-10-29 Lucent Technologies Inc. Asymmetric protocol for wireless communications
FI98027C (fi) * 1995-01-10 1997-03-25 Nokia Telecommunications Oy Pakettiradiojärjestelmä ja päätelaitteisto pakettiradiojärjestelmää varten
FI97927C (fi) * 1995-05-09 1997-03-10 Nokia Telecommunications Oy Ei-transparentti datansiirto digitaalisessa tietoliikennejärjestelmässä
FI98174C (fi) * 1995-05-09 1997-04-25 Nokia Telecommunications Oy Datansiirtojärjestelmä, jossa on liukuvaan ikkunaan perustuva datavuonohjaus
US5729536A (en) * 1996-04-10 1998-03-17 Lucent Technologies Cellular system architectures supporting data services
US5936965A (en) * 1996-07-08 1999-08-10 Lucent Technologies, Inc. Method and apparatus for transmission of asynchronous, synchronous, and variable length mode protocols multiplexed over a common bytestream
US5708656A (en) * 1996-09-11 1998-01-13 Nokia Mobile Phones Limited Method and apparatus for packet data transmission
KR100260516B1 (ko) * 1997-04-01 2000-07-01 정선종 코드분할 다중접속 이동통신망에서의 비동기통신 데이터발신호 및 착신호 서비스 방법
JPH10341487A (ja) * 1997-04-09 1998-12-22 Sony Corp 情報端末装置、情報処理方法、情報提供装置および方法、情報ネットワークシステム、並びに提供媒体
KR19990001580A (ko) * 1997-06-16 1999-01-15 양승택 Cdma 이동통신망을 이용한 g3 팩스 서비스 방법
US6011796A (en) * 1997-06-17 2000-01-04 Qualcomm Incorporated Extended range sequence numbering for selective repeat data transmission protocol
US6314101B1 (en) * 1997-06-17 2001-11-06 Qualcomm Incorporated Method for detecting delayed data frames in a transport function
US6236647B1 (en) * 1998-02-24 2001-05-22 Tantivy Communications, Inc. Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate
US5862452A (en) * 1997-10-20 1999-01-19 Motorola, Inc. Method, access point device and peripheral devices for low complexity dynamic persistence mode for random access in a wireless communication system
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
US6112084A (en) * 1998-03-24 2000-08-29 Telefonaktiebolaget Lm Ericsson Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork
US6307867B1 (en) * 1998-05-14 2001-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Data transmission over a communications link with variable transmission rates
US6310893B1 (en) * 1998-06-17 2001-10-30 Genuity Inc. Method and system for connectionless communication in a cell relay satellite network
US6160804A (en) * 1998-11-13 2000-12-12 Lucent Technologies Inc. Mobility management for a multimedia mobile network
US6169732B1 (en) * 1999-06-29 2001-01-02 Motorola, Inc. Method and apparatus in a wireless communication system
US6301479B1 (en) * 1999-07-08 2001-10-09 Telefonaktiebolaget Lm Ericsson Technique for providing a secure link in a mobile communication system
US6317224B1 (en) * 1999-09-17 2001-11-13 Motorola, Inc. Method and apparatus for modifying facsimile data transfer rates based upon varying bit rates of a transport medium

Also Published As

Publication number Publication date
AU760994B2 (en) 2003-05-29
EP1014641A1 (de) 2000-06-28
ATE332051T1 (de) 2006-07-15
EP1142263B1 (en) 2006-06-28
DE69932184T2 (de) 2007-06-14
JP2002534001A (ja) 2002-10-08
DE69932184D1 (de) 2006-08-10
CN1287576C (zh) 2006-11-29
ES2270631T3 (es) 2007-04-01
EP1142263A1 (en) 2001-10-10
CN1331877A (zh) 2002-01-16
AU2096300A (en) 2000-07-12
US6948108B1 (en) 2005-09-20
WO2000038390A1 (en) 2000-06-29
CA2356900A1 (en) 2000-06-29

Similar Documents

Publication Publication Date Title
JP4594530B2 (ja) 通信ネットワークにおけるデータ処理時間の削減に関する方法および装置
US6795435B1 (en) Method for transmitting data transmission flows
RU2296423C2 (ru) Способ и устройство для обеспечения уровней с множеством показателей качества обслуживания в соединениях беспроводной передачи пакетов данных
US7382763B2 (en) Communication device and method
JP5523350B2 (ja) Tcpフロー制御のための方法及び装置
US6985459B2 (en) Early transmission and playout of packets in wireless communication systems
WO2006095385A1 (ja) 無線通信装置
AU2002247311A1 (en) Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
EP1325640A1 (en) Synchronization of data packet numbers in packet-switched data transmission
MXPA02009502A (es) Metodo y aparato para aplicarse a una estacion movil para identificar eventos especificos.
MXPA02009369A (es) Metodo y aparato para notificar a la aplicacion de una estacion movil eventos especificos.
EP1230764A1 (en) Method and device for improving a data throughput in a communication system
JP3950865B2 (ja) Atm通信システム
CN1886951A (zh) 被损坏分组的选择性转发
JP4617568B2 (ja) 無線通信装置
EP0973302A1 (en) Device and method for reliable and low-delay packet transmission
KR19980021577A (ko) 수신 패킷의 파손 검출 및 복구 방법
Pils et al. Wireless Internet access with DECT

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061017

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061017

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090513

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090609

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090909

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091130

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: 20100824

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: 20100917

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130924

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4594530

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

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