JP4230663B2 - 無線通信ネットワークにおけるパケット・ヘッダの削減 - Google Patents
無線通信ネットワークにおけるパケット・ヘッダの削減 Download PDFInfo
- Publication number
- JP4230663B2 JP4230663B2 JP2000535121A JP2000535121A JP4230663B2 JP 4230663 B2 JP4230663 B2 JP 4230663B2 JP 2000535121 A JP2000535121 A JP 2000535121A JP 2000535121 A JP2000535121 A JP 2000535121A JP 4230663 B2 JP4230663 B2 JP 4230663B2
- Authority
- JP
- Japan
- Prior art keywords
- alias
- message
- address
- addresses
- predetermined
- 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 - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9042—Separate storage for different parts of the packet, e.g. header and payload
-
- 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
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
- H04L61/106—Mapping addresses of different types across networks, e.g. mapping telephone numbers to data network addresses
-
- 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/04—Protocols for data compression, e.g. ROHC
-
- 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
-
- 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/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
（発明の分野）
本発明は、通信ネットワークに関し、より詳細には、イーサネット・プロトコルのようなパケット通信プロトコルを使用する通信ネットワークに関する。
【０００２】
（発明の背景）
計算器の使用や通信においては、コンピュータなど、データ処理装置を通信ネットワークで結ぶことが普通になっている。処理システムを通信ネットワークに接続することに伴う問題点の１つは、プロセッサ間の通信に必要な基盤設備（infrastructure）に関する。通信が行われるのは、イーサネット・プロトコルのような通信プロトコルを用いた固定配線のインターフェースである。しかし、この基盤設備は、常に利用できるとは限らない。つまり、ある種の環境やある種の用途には、固定した基盤設備をつくることは非現実的である。たとえば、住宅用の建物で、コンピュータ・ネットワーク用設備を配線することは、あまりにも費用がかかりすぎて非現実的である。同様にビジネス環境でも、通信ネットワークのリンクを維持しながら場所から場所へと携帯形処理システムを移動できることが必要かもしれない。
【０００３】
このような状況の結果として、処理システム間の通信のメカニズムとして、無線通信システムなど、固定された基盤設備の量を少なくした通信システムが使用されてきた。しかし、無線システムは概して運用に費用がかかり、帯域幅も有線システムと比較すると狭いことが一般的であった。高速度の専用無線システムを運用してもよいが、これらの無線通信ネットワークは、既存の有線通信ネットワークに統合されていることが多いため、イーサネット、トークンリングまたはネットワーキング・プロトコルのような既存のネットワーキング・プロトコルを使用することが望ましい。しかし、イーサネット・プロトコルなど、従来のネットワーキング・プロトコルは、無線通信環境における使用のために開発されたのではないため、無線通信ネットワークの環境で運用するときは能率が悪い。
米国特許第 5,446,736 号は、標準プロトコルを使用して、無線通信ネットワークにノードを接続するための方法と装置を説明している。この第 '736 号特許は、接続の間、ヘッダの一部を置き換えるためにトークンが使用される接続向けシステムを説明している。文献、「Ｘ .25 規格にもとづく伝送用プロトコル（ Protocols De Transmission De Donnees X 25 ）」「マイクロ・システムズ（ Micro Systemes ）」第 74 号、 1987 年４月１日、ページ 94 〜 100 に、ハイ・レベル・データリンク制御（ＨＤＬＣ）のデータ伝送プロトコルの試験結果が記載されている。 1997 年 10 月１日発行の「無線通信ネットワーク」、第３巻、第５号、ページ 375 〜 387 の文献、「無線通信ネットワーク用の TCP/IP ヘッダの低損失圧縮（ Low-Loss TCP/IP Header Compression For Wireless Networks ）」は、 TCP/IP 通信のヘッダの圧縮を説明している。
【０００４】
上記考察から考ると、無線通信リンクで既存通信プロトコルがもっと能率的に動作できるように、無線通信の性能を向上させる必要がある。
【０００５】
（発明の要約）
上記考察の視点から、本発明の目的は、無線通信リンクなど、帯域幅を狭くした通信リンクでコンピュータをネットワーク化するときの能率を向上させることである。
【０００６】
本発明の別の目的は、帯域幅の狭い通信リンクのスループットを向上させるとともに、ユーザに対して透明にすることである。
【０００７】
本発明の更に別の目的は、既存のネットワーキング・プロトコルと互換性を維持すると同時に、通信リンクのスループットを向上させることである。
【０００８】
本発明のこれらの目的は、通信リンクを通じてメッセージ・ヘッダを備えたメッセージを伝達するときのオーバーヘッドを削減する方法、システムおよびコンピュータ・プログラム・プロダクトによって与えられる。このオーバーヘッドの削減は、通信リンクで転送されるメッセージを受信した後、所定の第１組のエイリアス・アドレスからの未使用のエイリアス・アドレスの使用の可否を決定することによって達成される。未使用のエイリアス・アドレスが使用可能な場合は、その未使用のエイリアス・アドレスが、受信したメッセージのヘッダの少なくとも一部と対応付けられる。未使用のエイリアス・アドレスが使用不能な場合は、所定の第１組のエイリアス・アドレスからの使用済みエイリアス・アドレスが、受信したメッセージのヘッダの少なくとも一部と対応付けられる。メッセージ・ヘッダを備えた後続メッセージからメッセージ・ヘッダの少なくとも一部が除去されてデータ・メッセージを削減するが、この後続メッセージのメッセージ・ヘッダの一部は、受信したメッセージのメッセージ・ヘッダと実質的に同一である。この削減されたデータ・メッセージと、対応付けられたエイリアス・アドレスが通信リンクで転送される。この通信リンクは、無線通信リンクでもよい。
【０００９】
メッセージのヘッダ情報にエイリアス・アドレスを対応付けることにより、ヘッダ情報として、そのエイリアス・アドレスを代入することができる。この代入によって、通信リンクで転送されるデータのバイト数が削減される。その上、最近使用されていない使用済みのリンクを自動的に選択することにより、本発明は、前に確定済みのリンクを「はずす（take down）」ことを不要にする。したがって、未使用リンクの除去に伴うオーバーヘッドはない。
【００１０】
本発明の特定の実施例では、エイリアス・アドレスと、メッセージに付随するメッセージ・ヘッダの少なくとも一部が通信リンクで転送される。メッセージ・ヘッダの一部と、対応付けられたエイリアス・アドレスとの対応付けの確認も通信リンクから受信される。削減されたデータ・メッセージが転送されて、通信リンクから受信されると、後続メッセージは、受信したエイリアス・アドレスに対応付けられたメッセージ・ヘッダの一部と、削減されたデータ・メッセージとから再構成される。
【００１１】
最初のメッセージのヘッダの一部とエイリアス・アドレスを対応付け、このエイリアス・アドレスにもとづいて最初のメッセージを再構成することにより、本発明は、通信ごとにオーバーヘッドを削減する。オーバーヘッドの削減は、最初のメッセージのプロトコルに関係なく、メッセージの中の複数のパケットを識別するヘッダを用いて、いかなるプロトコルに対しても達成される。何故ならば、最初のメッセージは、そのプロトコルに準拠して再構成されるが、ヘッダ情報をメッセージのデータ部と分離できるとすれば、通信リンクで転送される削減されたデータ・パケットのフォーマットは、最初のメッセージと無関係でよいからである。
【００１２】
本発明の別の実施例では、メッセージ・ヘッダの少なくとも一部に対応付けられたエイリアス・アドレスは、使用済みとして識別される。しかし、所定の第１組からの各使用済みエイリアス・アドレスが、最後に使用された時を決定することにより、各使用済みエイリアス・アドレスごとに最終使用時（time of last use）を与えることができるので、使用済みエイリアス・アドレスをメッセージ・ヘッダの一部に対応付けることができる。そうすると、未使用のエイリアス・アドレスが使用不能な場合は、受信したメッセージのヘッダの一部に、最終使用時が最も古い使用済みエイリアス・アドレスが対応付けられる。したがって本発明では、もはや使用済みエイリアス・アドレスの対応付けをはずす必要はない。
【００１３】
本発明の特定の一実施例では、削減されたデータ・メッセージをつくるために除去されたメッセージ・ヘッダの一部は、そのメッセージの発信元アドレスおよび宛先アドレスを含む。
【００１４】
本発明の別の実施例では、エイリアス・アドレスとメッセージ・ヘッダとの対応付けが監視される。所定の第１組のエイリアス・アドレスの中のエイリアス・アドレスの数は、この監視にもとづいて増加して、所定の第２組のエイリアス・アドレスになる。
【００１５】
エイリアス・アドレスの対応付けを監視することにより、本発明は、使用可能なアドレスの数を選択的に増加させて、エイリアス・アドレスの対応付けを確定するために使用される通信帯域幅を狭くする。したがって、使用可能なアドレスの数を動的に調節して、エイリアス・アドレスの攪乱（churning）の可能性を小さくする。
【００１６】
更に別の実施例では、エイリアス・アドレスが活動状態にないと決定されると、そのエイリアス・アドレスは、所定の第２組のエイリアス・アドレスから除去される。特に、所定の第２組のエイリアス・アドレスが、所定の第１組のエイリアス・アドレスと第３の所定の１組のエイリアス・アドレスとの組み合わせを含んでいる場合は、第３の所定の１組のエイリアス・アドレスのすべてが、所定の第２組のエイリアス・アドレスから除去されていると、エイリアス・アドレスの数は、所定の第１組のエイリアス・アドレスに削減される。したがって、攪乱を回避するために必要なエイリアス・アドレスの数が減少すると、エイリアス・アドレスの数も動的に減少する。
【００１７】
当業者には判るように、本発明は、方法、装置、システムまたはコンピュータ・プログラム・プロダクトとして具体化される。
【００１８】
（発明の詳細な説明）
本発明の好適実施例を示す添付の図面を参照しつつ、以下、本発明を詳細に説明する。しかし、この発明は、多数の異なる形で具体化されうるので、本明細書に詳述された実施例に限定されていると解釈すべきではなく、これらの実施例は、この開示が十分かつ完全であって、当業者に本発明の範囲を完全に伝えるように用意されているのである。全図面を通じて、同じ番号は同じ要素を示す。当業者には判るように、本発明は、方法または装置として具体化されている。したがって、本発明は、完全にハードウエアの実施例、完全にソフトウエアの実施例、またはソフトウエアとハードウエアの態様を組み合わせた実施例の形になってもよい。
【００１９】
図１は、本発明の一実施例を示す。図１で判るように、通信メッセージの発信元１０は、無線通信インターフェース１２にアクセスする。この通信メッセージの宛先は、無線通信リンク１６を通じて第１の無線通信インターフェース１２と交信する第２の無線通信インターフェース１４にアクセスする。
【００２０】
本発明の特定の実施例における発信元１０および宛先１８は、イーサネットの発信元および宛先である。このようなケースでは、通信インターフェース１２、１４は、無線イーサネットのアダプタなど無線通信リンクを通じてイーサネットのパケットを転送することができるアダプタである。発信元および宛先の装置は、ネットワーク・コンピュータ、ワークステーション、パーソナル・コンピュータ、個人情報管理端末（personal information managers）など、イーサネット通信プロトコルのようなパケット通信プロトコルでデータ・パケットの発信元または宛先として機能することができる装置である。
【００２１】
本明細書では、イーサネット・プロトコルを参照して本発明が説明されているが、当業者にはよく判るように、パケットを使用する他の通信プロトコルも本発明の教示から利することができる。たとえば、本発明の教示を利用して、伝送制御プロトコル／インターネット・プロトコル（TCP/IP）、非同期転送モード（ATM）プロトコルなど、パケット通信を使用するプロトコルを用いることができる。
【００２２】
その上、本発明は、無線通信リンクに言及して説明されているが、本発明が無線通信に限定されていると解釈してはならない。ここで使用されている通信リンクという用語は、相互に離れている２つのプロセッサの間のリンクのことであり、２つのプロセッサの間の通信を可能にするならばいかなるタイプのリンクでもよい。本発明の教示は、通信リンクを通じて転送されるデータ量が削減される通信リンクならば、いかなる通信リンクにも利点をもたらす。このような通信リンクの例には、低速度モデム通信、衛星通信リンク、セルラー通信リンク、無線周波通信リンク、マイクロ波通信リンクなど、通信リンクを通じて転送されるデータ量にもとづいて速度が調整されるいかなる通信リンクも含まれる。
【００２３】
図１は、無線通信リンク１６を通じて交信できる１つの発信元と１つの宛先を示す。しかし、当業者には判るように、通信インターフェース１２、１４を通じて、複数の発信元および宛先がアクセス可能である。更に発信元および宛先間の通信は、無線通信リンク１６を隔てた両方向で可能である。通信インターフェース１２、１４は、通信インターフェース１２、１４を使用し無線通信リンク１６を隔てて交信する発信元および宛先の両方にアクセスすることができる。このように図１は一例であって、本発明を限定していると解釈してはならない。
【００２４】
概観すると、本発明のある種の実施例の動作は、通信パケットのヘッダの大きさを削減することにより、無線通信リンク１６のような、通信リンクを通じてパケットを転送する場合のデータの削減機能を備えている。より詳細には、発信元アドレスおよび宛先アドレスのようなルーティング情報を持ったデータ・パケットは、通信リンクで転送される前にヘッダ情報が除去される。エイリアス・アドレスがヘッダに割り当てられると、そのエイリアス・アドレスがデータ・パケットに追加される。ここで使用される「エイリアス・アドレス」という用語は、最初のメッセージのヘッダ情報に対応付けられる名称であって、エイリアス・アドレスが判ると最初のメッセージを再生できるのである。このようにしてデータとエイリアス・アドレスが通信リンクで転送される。通信リンクの受信側は、修正されたデータ・パケットを受信して、受信したエイリアス・アドレスにもとづいて最初のデータ・パケットを再構成する。発信元および宛先のアドレスが同じ後続メッセージからも発信元および宛先のアドレス情報が除去され、この対応付けられたエイリアス・アドレスが、通信リンクを通じて転送されるために使用される。エイリアス・アドレスは、最初のデータの対応する発信元および宛先のアドレスの発信元および宛先のアドレスより小さくてもよいので、通信リンクを通じて転送されるデータ量は、削減される。
【００２５】
本発明の特定の態様におけるエイリアス・アドレスは、すべてのエイリアス・アドレスが使用されてしまうまで、未使用エイリアス・アドレスに割り当てられる。すべてのエイリアス・アドレスが使用されてしまった後で、通信リンクで転送されるための新しい発信元と宛先を備えたデータ・パケットが受信されると、最近使用されたことが最少の（least recently used）エイリアス・アドレスが、この新しい発信元および宛先のアドレスに割り当てられる。したがって、本発明は、前のエイリアス・アドレスの対応付けを明白に終了するためのオーバーヘッドを伴わずにエイリアス・アドレスの対応付けを変えることができる。その上、エイリアス・アドレスの割り当てのために、通信リンクの帯域幅の広さが非常に大きく占有されていることが決定されると、エイリアス・アドレスの大きさを拡張して、再割り当てが発生する頻度を小さくする。
【００２６】
以下、イーサネットの例と図１のブロック図について、本発明の各種実施例の特定の動作を説明する。本発明の実施例を示す流れ図である図３、４および図６から図８についても言及する。流れ図の各ブロックと、流れ図のブロックの組み合わせは、コンピュータ・プログラムの命令によって実行される。これらのプログラム命令がプロセッサに与えられると、プロセッサ上で実行する命令が、流れ図の中のブロックまたは複数のブロックで指定される機能を実行する手段を生成するようなマシンを作動させる。コンピュータ・プログラムは、プロセッサで実行する命令が、流れ図のブロックまたは複数のブロックで指定される機能を実行するようにプロセッサで実行され、プロセッサで実行される一連の演算ステップを発生して、コンピュータで実行される処理を生成することができる。
【００２７】
したがって、流れ図のブロックは、指定された機能を実行する手段の組み合わせと、指定された機能を実行するステップの組み合わせと、指定された機能を実行するプログラム命令の手段をサポートする。流れ図の各ブロックと、流れ図の中のブロックのいろいろな組み合わせは、指定された機能つまりステップを実行する特殊目的用のハードウエアを使用したシステム、または特殊目的用ハードウエアとコンピュータ命令の組み合わせによって実行される。
【００２８】
図３は、無線通信リンク１６のような通信リンクで転送されるデータ・パケットが受信されるときの、通信インターフェース１２のような通信インターフェースの動作を示す。図３に示されているように、無線通信インターフェース１２が発信元１０からデータ・パケットを受信すると、無線通信インターフェース１２は、データ・パケットからヘッダを抽出して、そのヘッダから発信元および宛先のアドレスを決定する（ブロック３０）。次に現在のリンク（つまり、エイリアス・アドレス）が、通信リンク１６の両側で発信元および宛先のアドレスに対応しているか、つまり通信リンク１６が、その発信元および宛先のアドレスのために確定されているか否か決定される（ブロック３２）。リンクが確定されていない場合は、最近使用されたことが最少のエイリアス・アドレスが、その発信元および宛先のアドレスに割り当てられ（ブロック３４）、そのエイリアス・アドレスを発信元および宛先のアドレスに割り当てるように無線通信リンク１６に要求が送られる（ブロック３６）。すべてのエイリアス・アドレスが割り当てられていない場合は、最近使用されたことが最少のエイリアス・アドレスが、未使用のエイリアス・アドレスである。この例では、エイリアス・アドレスは、２５４個のエイリアス・アドレスの所定の１組を定義するように制御するために予約されている２つのアドレス（「００」および「０１」）を備えた１バイト（８ビット）の大きさなので、前に割り当てられたエイリアス・アドレス（使用済みエイリアス・アドレス）を再使用する前に、２５４個のエイリアス・アドレスを割り当てる必要がある。
【００２９】
図２Ｂは、リンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイトとして「００」を含む。「００」は、このパケットがリンクが確定されることを要求していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する１バイトが続く。図２Ｂに示すフォーマットを使用すると、リンク要求は１６バイトのパケットになる。
【００３０】
図３に戻り、リンクを確定する要求を送ると、通信インターフェース１２、１４は、再割り当てフラグをセットする（ブロック３８）。この再割り当てフラグは、受信中の無線通信インターフェース１４または１２とのハンドシェーキングの一部として使用され、リンクが確定されて（つまり、無線通信リンク１６の両側が、エイリアス・アドレスに対する発信元および宛先のアドレスの対応付けが同じになっていて）、無線通信リンク１６から受信されるはずの肯定応答パケットを待っていることを検証する。肯定応答を受信すると、通信インターフェース１２または１４は、再割り当てフラグが設定されたままになっているか否かを見るためにチェックする（ブロック４０）。再割り当てフラグが設定されたままになっている場合はリンクの要求が失敗したので、新しいエイリアス・アドレスが選択され（ブロック３４）、この処理が繰り返される（ブロック３６、３８）。この処理は、リンクが確定されるまで繰り返されるか、一定回数の試行の間繰り返され、それでも成功しない場合は、このメッセージは廃棄される。つまり、このパケットの発信元にエラーが連絡される。
【００３１】
再割り当てフラグが設定されていない場合は（ブロック４０）、リンクが確定されている。通信インターフェース１２または１４は、最初のパケットのＣＲＣをチェックし（ブロック４２）、ＣＲＣエラーが示されると、このパケットを廃棄する（ブロック４４）。また、ＣＲＣのチェックは、リンクを確定する前に実行される。
【００３２】
ＣＲＣエラーが検出されない場合は、ＣＲＣと発信元および宛先のアドレスがパケットから除去されて、エイリアス・アドレスと置き換えられる（ブロック４６）。このイーサネットの例では、無線通信リンク１６で転送されるパケットのフォーマットが図２Ａに示されている。図２Ａで判るように、無線通信リンク１６を隔てて転送されるパケットはフレーム・ヘッダを含み、その後にエイリアス・アドレス（１バイト）が続き、ついでメッセージのタイプ（２バイト）が続き、その後に４６バイトから５７６バイトのデータが続く。削減されたデータ・パケットがつくられると、この削減されたデータ・パケットは無線通信リンク１６で転送される（ブロック４８）。
【００３３】
通信インターフェース１２または１４で受信され、同じエイリアス・アドレスを備えた後続データ・パケットの処理も図３に示されている。図３で判るように、パケットが受信されると、ヘッダが抽出され（ブロック３０）、リンクが存在するか否か決定される（ブロック３２）。このパケットは後続パケットなので、リンクが存在しており再割り当てフラグが設定されることはない（ブロック４０）。パケットのＣＲＣがチェックされ（ブロック４２）、エラーが示されなければ、ヘッダ情報が除去され（ブロック４６）、削減されたデータ・パケットが無線通信リンク１６で転送される（ブロック４８）。
【００３４】
図４は、無線通信リンク１６からパケットが受信されるときの本発明の一実施例による通信インターフェース１２または１４の動作を示す。パケットが受信されると、フレーム・ヘッダ「７Ｅ」の後の第１バイト（Ｃ）が抽出され（ブロック５０）、フレーム・ヘッダの後のこの第１バイトがリンクを確定する要求を指定しているか否か決定される（Ｃ＝「００」）（ブロック５２）。フレーム・ヘッダの後の第１バイトがフレームの要求を指定している場合は、パケットの発信元および宛先のアドレスとエイリアス・アドレス（図２Ｂを参照）のフィールドが抽出され（ブロック５４）、発信元および宛先のアドレスにエイリアス・アドレスが対応付けられる（ブロック５６）。次に確認パケットが構成され（ブロック５８）、通信リンク１６で転送される予定に入れられる（ブロック６０）。
【００３５】
図２Ｃは、リンクが確定されていることを確認するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイト（Ｃ＝「０１」）として「０１」を含む。「０１」は、このパケットがリンクが確定されることを確認していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられているエイリアス・アドレスを指定する１バイトが続く。図２Ｃに示すフォーマットを使用すると、リンク確認パケットは１６バイトのパケットになる。
【００３６】
図４のブロック５２に戻り、フレーム・ヘッダの後の第１バイトが「００」でない場合は、そのバイトが「０１」かどうか判定し、このバイトが、図２Ｃに示す確認パケットであることを示しているか否か決定される。フレーム・ヘッダの後の第１バイトが、リンク確認パケットを指定していると、パケットの発信元および宛先のアドレスとエイリアス・アドレスのフィールド（図２Ｃを参照）が抽出され（ブロック６４）、エイリアス・アドレスに対応付けられた再割り当てフラグがリセットされる（ブロック６６）。処理は、図３に関する上記説明のとおりに続き、通信リンク１６を通じて最初のパケットのデータを転送する。
【００３７】
フレーム・ヘッダの後の第１バイトが「００」でも「０１」でもない場合は、このパケットが、図２Ａで指定されるフォーマットのデータ・パケットである。フレーム・ヘッダの後の第１バイトは、エイリアス・アドレスに対応付けられた発信元および宛先のアドレスの対と一致するパケットのエイリアス・アドレスを指定する（ブロック６８）。最初のパケットは再構成され、最初の宛先１８に転送する予定に入れられる（ブロック７２）。
【００３８】
図５Ａから図８は本発明の代替実施例を示しており、この場合、エイリアス・アドレスの大きさが拡張される。このような実施例は、エイリアス・アドレスの「攪乱」の可能性を小さくする。エイリアス・アドレスを発信元および宛先のアドレスに対応付けるリンクを確定することに関連して何らかのオーバーヘッドが存在するので、リンクを確定するパケットによって、通信リンク１６の帯域幅の大きな割合が占有されるという条件が生起する。本明細書の中で「攪乱」と呼ばれるこの条件は、エイリアス・アドレスのフィールドを拡張して２バイトのアドレスデータを含めることによって、その始まりを遅らせるか予防することができ、このため、使用可能なエイリアス・アドレスの数を実質的に増加させて、エイリアス・アドレスの再割り当ての頻度を低減する。
【００３９】
図５Ａ、５Ｂは、本発明の代替実施例に関連するシングルバイトおよびダブルバイトのアドレスの例を示す。図５Ａで判るように、シングルバイトの第１ビットは、シングルバイト・アドレスを示す「０」に設定されている。図５Ｂは、拡張（extended）アドレス・フィールドの第１ビットが、拡張アドレスを示す「１」に設定されていることを示す。
【００４０】
図６は、通信リンク１６で転送されるパケットを受信するときの本発明の代替実施例の動作を示す。図６で判るように、通信インターフェース１２または１４は、まず現在のリンクが、受信したパケットの発信元および宛先のアドレスに対応付けられているか否か決定する（ブロック８０）。リンクが存在しない場合は、未使用のエイリアス・アドレスが使用可能か否か決定される（ブロック８２）。拡張エイリアス・アドレスが使用されていない場合、この決定はシングルバイトのエイリアス・アドレスの稼働率にもとづいて行われる。拡張エイリアス・アドレスが使用されている場合、この決定は拡張エイリアス・アドレスの稼働率にもとづいて行われる。未使用のエイリアス・アドレスが使用可能でない場合は、エイリアス・アドレスが攪乱されているか否か決定される（ブロック８４）。
【００４１】
攪乱が発生しているか否かの決定は、通信リンクを通じて転送されるデータ・パケットに対するリンク確定要求の割合、全アドレス空間が再割り当てされてからの時間（たとえば、８ビットのエイリアス・アドレスに対して行われた最新の２５４回の再割り当て中に経過した時間）、または当業者には既知の方法にもとづいて行われる。一実施例では、（発生の相対頻度で推定される）確率が非常に大きくて、活動状態にあるリンクがエイリアス・アドレスの再割り当てによって中断されるときに攪乱が宣言され、この場合、最後のＴミリセコンド中にリンクが使用されたときはリンクは活動状態にあると考えられる。
【００４２】
攪乱が発生している場合は、エイリアス・アドレス・フィールドのフィールド長が２バイト以上に拡張され、拡張エイリアス・アドレスが使用される（ブロック８６）。次に未使用の拡張エイリアス・アドレスからエイリアス・アドレスが選択される（ブロック９０）。攪乱が発生していない場合は、発信元および宛先のアドレスと対応付けるために、最近使用されたことが最少のエイリアス・アドレスが選択される（ブロック８８）。拡張エイリアス・アドレスが使用されている場合、この選択は、シングルバイトのエイリアス・アドレスの最後の使用にもとづいて行われる。
【００４３】
いずれのケースでも、エイリアス・アドレスが選択されると、リンク確定要求が通信リンクで転送される（ブロック９２）。代表的なリンク確定要求パケットのフォーマットは、拡張エイリアス・アドレス用が図５Ｄに示され、シングルバイト・アドレス用が図２Ｂに示されている。図２Ｂは上に説明されている。図５Ｄは、拡張エイリアス・アドレスのリンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後のデータ・パケットの第１バイトとして「０２」を含む。「０２」は、このパケットが拡張エイリアス・アドレスのリンクが確定されることを要求していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する２バイトが続く。図５Ｄに示すフォーマットを使用すると、リンク要求は１７バイトのパケットになる。
【００４４】
リンク確定要求パケットを送ると、通信インターフェース１２または１４は、リンクが確定された確認の受信を待つ（ブロック９４）。リンクを確定する動作（ブロック９２、９４）は、図３、４を参照して上に説明したように実行され、この場合、リンクを確定するためにエラー時の再試行の手法が使用される。
【００４５】
リンクが確定されると、最初のデータ・パケットは、上に説明したように、発信元および宛先のアドレスとＣＲＣを除去して、データ・パケットを削減するエイリアス・アドレスを含むように変更され（ブロック９６）この削減されたデータ・パケットがリンク１６で転送される（ブロック９８）。代表的な削減されたデータ・パケットのフォーマットが図２Ａおよび図５Ｃに示されている。
【００４６】
図７、８は、通信リンク１６からパケットを受信するときに拡張エイリアス・アドレスを使用する本発明の代替実施例の動作を示す。図７で判るように、通信リンク１６からパケットが受信されると、フレーム・ヘッダの後の第１バイトが抽出される（ブロック１００）。この第１バイトが「００」または「０２」の場合、このパケットはリンク確定要求なので、パケットのフォーマット（図２Ｂおよび図５Ｄを参照）にもとづいて適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される（ブロック１０２、１０４）。抽出されたエイリアス・アドレスは、発信元および宛先のアドレスに対応付けられる（ブロック１０６）。次に確認パケットが構成され（ブロック１０８）、通信リンク１６で転送される予定に入れられる（ブロック１１０）。
【００４７】
確認パケットのフォーマットは、確定要求パケットのフォーマットに対応する。したがって、「００」のリンク確定要求が受信されると、図２Ｃに示す「０１」フォーマットの確認パケットが構成される。図２Ｃの確定要求パケットのフォーマットは、上に説明されている。しかし、受信したリンク確定要求が、「０２」の拡張エイリアス・アドレスのリンク確定要求であった場合は、フォーマットが図５Ｅの確認パケットが構成される。
【００４８】
図５Ｅは、拡張エイリアス・アドレスのリンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイトとして「０３」を含む。「０３」は、このパケットが拡張エイリアス・アドレスのリンクが確定されることを確認していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する２バイトが続く。図５Ｅに示すフォーマットを使用すると、リンク確認パケットは１７バイトのパケットになる。
【００４９】
図７に戻り、通信リンク１６から受信したパケットのフレーム・ヘッダの後の第１バイトが、「００」でも「０２」でもない場合は、フレーム・ヘッダの後の第１バイトが、「０１」または「０３」であるか否か決定される（ブロック１１２）。第１バイトが「０１」または「０３」の場合、このパケットは確認パケットなので、パケットのフォーマット（図２Ｃおよび図５Ｅを参照）にもとづいて、適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される（ブロック１１２およびブロック１１４）。抽出されたエイリアス・アドレスに対応付けられた再割り当てフラグはリセットされて、リンクの確定に成功したことを示す（ブロック１１６）。
【００５０】
受信したパケットのフレーム・ヘッダの後の第１バイトが、「００」、「０１」、「０２」または「０３」でない場合、このパケットは、図２Ａまたは図５Ｃに示すフォーマットのどちらか１つのフォーマットのデータ・パケットである。エイリアス・アドレスは、フレーム・ヘッダの後の第１バイトの第１ビットを調べることによって、データ・パケットから決定される。そのビットが「０」の場合は、シングルバイトのエイリアス・アドレスが使用される（図５Ａを参照）。そのビットが「１」の場合は、拡張エイリアス・アドレスが使用される（図５Ｂを参照）。いずれのケースでも、エイリアス・アドレスはこのパケットから抽出されるので、対応付けられた発信元および宛先のアドレスと一致する（ブロック１１８）。最初のパケットはＣＲＣを含めて再構成され（ブロック１２０）、通信リンクで転送される予定に入れられる（ブロック１２２）。
【００５１】
図８は、通信リンク１６からパケットを受信するときに拡張エイリアス・アドレス指定を使用するが、拡張エイリアス・アドレスのために別の要求パケットや確認パケットを使用しない、本発明の代替実施例の動作を示す。攪乱が発生しているか否か決定するために、同じ方法論を使用することにより、攪乱が発生しているか否か、通信リンク１６の両側で独立に決定できるため、拡張エイリアス・アドレスを使用すべきことを信号で明確に知らせる必要が回避されている。
【００５２】
図８で判るように、通信リンク１６からパケットが受信されると、フレーム・ヘッダの後の第１バイトが抽出される（ブロック１３０）。第１バイトが「００」または「０１」の場合、このパケットは、リンク確定要求パケットまたは確認パケットのいずれかなので、シングルバイトまたは拡張エイリアス・アドレス指定が使用されていることを示す攪乱が発生しているか否か決定される（ブロック１３２、１４２）。また、受信側の通信インターフェースは、エイリアス・アドレス・フィールドの第１ビットを調べ、そのビットが、シングルバイトを示す「０」、または拡張エイリアス・アドレス指定を示す「１」であったことを決定してもよい。通信インターフェースはパケットの全長を決定できるので、その長さが１６バイトの場合は、シングルバイトのエイリアス・アドレス指定が使用されている。パケットが１７バイトの場合は、拡張エイリアス・アドレス指定が使用されている。いずれのケースでも、シングルバイトまたは拡張エイリアス・アドレス指定が使用されていることが決定されると、パケットのフォーマット（図２Ｂ、２Ｃまたは図５Ｄ、５Ｅを参照）にもとづいて、適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される。（ブロック１４０またはブロック１４４）
【００５３】
エイリアス・アドレスが抽出されると、フレーム・ヘッダの後の第１バイトが、リンク要求パケットを示す「００」であるか否か決定される（ブロック１４６）。違っている場合は、このパケットはリンク確認であり、そのエイリアス・アドレスに対応付けられた再割り当てフラグがリセットされる（ブロック１４８）。フレーム・ヘッダの後の第１バイトが「００」の場合、このパケットはリンク確定要求なので、発信元および宛先にエイリアス・アドレスが割り当てられ（ブロック１５０）、適切な確認パケットが構成される（ブロック１５２）。次にこの確認パケットは、通信リンク１６で転送される予定に入れられる（ブロック１５４）。
【００５４】
ブロック１３２に戻り、フレーム・ヘッダの後の第１バイトが、「００」でも「０１」でもない場合、このパケットはデータ・パケットである。上に説明したように、エイリアス・アドレスが抽出され、このアドレスの第１ビットを使用して、アドレスが拡張されているか否か決定する（ブロック１３４）。次に最初のパケットが再構成され（ブロック１３６）、宛先へ転送される予定に入れられる（ブロック１３８）。
【００５５】
エイリアス・アドレスと発信元および宛先のアドレスとの対応付けは、項目（item）を結びつけるための非常に多くの手法を用いて行うことができる。たとえば、ルックアップテーブルや方向付きリスト（linked list）を使用して、エイリアス・アドレスと、発信元および宛先のアドレスとの間の対応付けをつくり出すことができる。テーブルで実行する場合は、前に使用されたエイリアス・アドレスであって、最近使用されたことが最少のエイリアス・アドレスの選択を容易にするように、エイリアス・アドレス、発信元および宛先のアドレスおよびエイリアス・アドレスの最終使用時を、通信リンク１６の両側で保守することができる。
【００５６】
本発明の拡張エイリアス・アドレスの実施例中の「ゴミ集め（trash-collection）」ルーチンは、拡張された長さのエイリアス・アドレスをもつ各リンクごとに最終使用時を調べ、アドレスが拡張されていて長時間使用されないリンクは、通信リンク１６の両端にあるテーブルから除去される。このように、エイリアス・アドレスの長さは、知らず知らずのうちに最短のオプションに戻っていく。拡張フィールドのエイリアス・アドレスがテーブルに存在しなくなると、「０２」および「０３」メッセージの使用は、攪乱がもう一度検出されるまで中断されたままになり、両側のテーブル（bridge tables）は、拡張以前の大きさに戻る。
【００５７】
また、「ゴミ集め」ルーチンは、リンクの両端にあるテーブルから、最終使用時が所定の閾値より古いリンクを定期的に除去する。リンクの総数が、１組の非拡張エイリアス・アドレスの中で使用可能なリンクの数以下になると、拡張エイリアス・アドレスのリンクを、後続の通信の非拡張エイリアス・アドレスに再割り当てしてもよい。当業者には判るように、本開示を考えると、非拡張エイリアス・アドレスで動作するようにシステムを元に戻す別の方法を使用してもよい。
【００５８】
イーサネット通信プロトコルに関して本発明を説明してきたが、当業者には判るように、本発明の教示は、他の通信プロトコルにも適用される。たとえば、通信インターフェース１２、１４がＩＰルーティング機能を実行し、イーサネット・パケットがＩＰデータグラムを含む場合、通信インターフェース１２、１４は、内部のデータグラムからＩＰルーティング情報を除去する。このようなケースでは、ルーティング情報を保存または再計算して、データグラムの経路内の次のホップを与えてもよい。したがって、本発明は、ＴＣＰ／ＩＰとともに使用して、イーサネットおよびＩＰのアドレス指定が除去されたり、各終端部のゲートウエイまたはルータが、ＩＰ経路の次のホップを指定するイーサネットのパケットにＩＰデータグラムを再バンドルする場合のオーバーヘッドを更に削減することができる。
【００５９】
特殊な用語が使用されているとはいえ、図面および明細書の中で本発明の代表的な実施例が開示されているが、これらの実施例は一般的かつ説明的な意味で使用されているにすぎず、限定する目的では使用されていないので、本発明の範囲は、以下の特許請求の範囲に詳述されている。
【図面の簡単な説明】
【図１】 本発明の一実施例を使用した通信システムのブロック図。
【図２Ａ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図２Ｂ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図２Ｃ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図３】 本発明の一実施例のとおり、通信インターフェースによってパケットを受信するときに実行される動作を示す流れ図。
【図４】 本発明の一実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
【図５Ａ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｂ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｃ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｄ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｅ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図６】 本発明の代替実施例のとおり、通信インターフェースによって、パケットを受信するときに実行される動作を示す流れ図。
【図７】 本発明の代替実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
【図８】 本発明の第２の代替実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
（発明の分野）
本発明は、通信ネットワークに関し、より詳細には、イーサネット・プロトコルのようなパケット通信プロトコルを使用する通信ネットワークに関する。
【０００２】
（発明の背景）
計算器の使用や通信においては、コンピュータなど、データ処理装置を通信ネットワークで結ぶことが普通になっている。処理システムを通信ネットワークに接続することに伴う問題点の１つは、プロセッサ間の通信に必要な基盤設備（infrastructure）に関する。通信が行われるのは、イーサネット・プロトコルのような通信プロトコルを用いた固定配線のインターフェースである。しかし、この基盤設備は、常に利用できるとは限らない。つまり、ある種の環境やある種の用途には、固定した基盤設備をつくることは非現実的である。たとえば、住宅用の建物で、コンピュータ・ネットワーク用設備を配線することは、あまりにも費用がかかりすぎて非現実的である。同様にビジネス環境でも、通信ネットワークのリンクを維持しながら場所から場所へと携帯形処理システムを移動できることが必要かもしれない。
【０００３】
このような状況の結果として、処理システム間の通信のメカニズムとして、無線通信システムなど、固定された基盤設備の量を少なくした通信システムが使用されてきた。しかし、無線システムは概して運用に費用がかかり、帯域幅も有線システムと比較すると狭いことが一般的であった。高速度の専用無線システムを運用してもよいが、これらの無線通信ネットワークは、既存の有線通信ネットワークに統合されていることが多いため、イーサネット、トークンリングまたはネットワーキング・プロトコルのような既存のネットワーキング・プロトコルを使用することが望ましい。しかし、イーサネット・プロトコルなど、従来のネットワーキング・プロトコルは、無線通信環境における使用のために開発されたのではないため、無線通信ネットワークの環境で運用するときは能率が悪い。
米国特許第 5,446,736 号は、標準プロトコルを使用して、無線通信ネットワークにノードを接続するための方法と装置を説明している。この第 '736 号特許は、接続の間、ヘッダの一部を置き換えるためにトークンが使用される接続向けシステムを説明している。文献、「Ｘ .25 規格にもとづく伝送用プロトコル（ Protocols De Transmission De Donnees X 25 ）」「マイクロ・システムズ（ Micro Systemes ）」第 74 号、 1987 年４月１日、ページ 94 〜 100 に、ハイ・レベル・データリンク制御（ＨＤＬＣ）のデータ伝送プロトコルの試験結果が記載されている。 1997 年 10 月１日発行の「無線通信ネットワーク」、第３巻、第５号、ページ 375 〜 387 の文献、「無線通信ネットワーク用の TCP/IP ヘッダの低損失圧縮（ Low-Loss TCP/IP Header Compression For Wireless Networks ）」は、 TCP/IP 通信のヘッダの圧縮を説明している。
【０００４】
上記考察から考ると、無線通信リンクで既存通信プロトコルがもっと能率的に動作できるように、無線通信の性能を向上させる必要がある。
【０００５】
（発明の要約）
上記考察の視点から、本発明の目的は、無線通信リンクなど、帯域幅を狭くした通信リンクでコンピュータをネットワーク化するときの能率を向上させることである。
【０００６】
本発明の別の目的は、帯域幅の狭い通信リンクのスループットを向上させるとともに、ユーザに対して透明にすることである。
【０００７】
本発明の更に別の目的は、既存のネットワーキング・プロトコルと互換性を維持すると同時に、通信リンクのスループットを向上させることである。
【０００８】
本発明のこれらの目的は、通信リンクを通じてメッセージ・ヘッダを備えたメッセージを伝達するときのオーバーヘッドを削減する方法、システムおよびコンピュータ・プログラム・プロダクトによって与えられる。このオーバーヘッドの削減は、通信リンクで転送されるメッセージを受信した後、所定の第１組のエイリアス・アドレスからの未使用のエイリアス・アドレスの使用の可否を決定することによって達成される。未使用のエイリアス・アドレスが使用可能な場合は、その未使用のエイリアス・アドレスが、受信したメッセージのヘッダの少なくとも一部と対応付けられる。未使用のエイリアス・アドレスが使用不能な場合は、所定の第１組のエイリアス・アドレスからの使用済みエイリアス・アドレスが、受信したメッセージのヘッダの少なくとも一部と対応付けられる。メッセージ・ヘッダを備えた後続メッセージからメッセージ・ヘッダの少なくとも一部が除去されてデータ・メッセージを削減するが、この後続メッセージのメッセージ・ヘッダの一部は、受信したメッセージのメッセージ・ヘッダと実質的に同一である。この削減されたデータ・メッセージと、対応付けられたエイリアス・アドレスが通信リンクで転送される。この通信リンクは、無線通信リンクでもよい。
【０００９】
メッセージのヘッダ情報にエイリアス・アドレスを対応付けることにより、ヘッダ情報として、そのエイリアス・アドレスを代入することができる。この代入によって、通信リンクで転送されるデータのバイト数が削減される。その上、最近使用されていない使用済みのリンクを自動的に選択することにより、本発明は、前に確定済みのリンクを「はずす（take down）」ことを不要にする。したがって、未使用リンクの除去に伴うオーバーヘッドはない。
【００１０】
本発明の特定の実施例では、エイリアス・アドレスと、メッセージに付随するメッセージ・ヘッダの少なくとも一部が通信リンクで転送される。メッセージ・ヘッダの一部と、対応付けられたエイリアス・アドレスとの対応付けの確認も通信リンクから受信される。削減されたデータ・メッセージが転送されて、通信リンクから受信されると、後続メッセージは、受信したエイリアス・アドレスに対応付けられたメッセージ・ヘッダの一部と、削減されたデータ・メッセージとから再構成される。
【００１１】
最初のメッセージのヘッダの一部とエイリアス・アドレスを対応付け、このエイリアス・アドレスにもとづいて最初のメッセージを再構成することにより、本発明は、通信ごとにオーバーヘッドを削減する。オーバーヘッドの削減は、最初のメッセージのプロトコルに関係なく、メッセージの中の複数のパケットを識別するヘッダを用いて、いかなるプロトコルに対しても達成される。何故ならば、最初のメッセージは、そのプロトコルに準拠して再構成されるが、ヘッダ情報をメッセージのデータ部と分離できるとすれば、通信リンクで転送される削減されたデータ・パケットのフォーマットは、最初のメッセージと無関係でよいからである。
【００１２】
本発明の別の実施例では、メッセージ・ヘッダの少なくとも一部に対応付けられたエイリアス・アドレスは、使用済みとして識別される。しかし、所定の第１組からの各使用済みエイリアス・アドレスが、最後に使用された時を決定することにより、各使用済みエイリアス・アドレスごとに最終使用時（time of last use）を与えることができるので、使用済みエイリアス・アドレスをメッセージ・ヘッダの一部に対応付けることができる。そうすると、未使用のエイリアス・アドレスが使用不能な場合は、受信したメッセージのヘッダの一部に、最終使用時が最も古い使用済みエイリアス・アドレスが対応付けられる。したがって本発明では、もはや使用済みエイリアス・アドレスの対応付けをはずす必要はない。
【００１３】
本発明の特定の一実施例では、削減されたデータ・メッセージをつくるために除去されたメッセージ・ヘッダの一部は、そのメッセージの発信元アドレスおよび宛先アドレスを含む。
【００１４】
本発明の別の実施例では、エイリアス・アドレスとメッセージ・ヘッダとの対応付けが監視される。所定の第１組のエイリアス・アドレスの中のエイリアス・アドレスの数は、この監視にもとづいて増加して、所定の第２組のエイリアス・アドレスになる。
【００１５】
エイリアス・アドレスの対応付けを監視することにより、本発明は、使用可能なアドレスの数を選択的に増加させて、エイリアス・アドレスの対応付けを確定するために使用される通信帯域幅を狭くする。したがって、使用可能なアドレスの数を動的に調節して、エイリアス・アドレスの攪乱（churning）の可能性を小さくする。
【００１６】
更に別の実施例では、エイリアス・アドレスが活動状態にないと決定されると、そのエイリアス・アドレスは、所定の第２組のエイリアス・アドレスから除去される。特に、所定の第２組のエイリアス・アドレスが、所定の第１組のエイリアス・アドレスと第３の所定の１組のエイリアス・アドレスとの組み合わせを含んでいる場合は、第３の所定の１組のエイリアス・アドレスのすべてが、所定の第２組のエイリアス・アドレスから除去されていると、エイリアス・アドレスの数は、所定の第１組のエイリアス・アドレスに削減される。したがって、攪乱を回避するために必要なエイリアス・アドレスの数が減少すると、エイリアス・アドレスの数も動的に減少する。
【００１７】
当業者には判るように、本発明は、方法、装置、システムまたはコンピュータ・プログラム・プロダクトとして具体化される。
【００１８】
（発明の詳細な説明）
本発明の好適実施例を示す添付の図面を参照しつつ、以下、本発明を詳細に説明する。しかし、この発明は、多数の異なる形で具体化されうるので、本明細書に詳述された実施例に限定されていると解釈すべきではなく、これらの実施例は、この開示が十分かつ完全であって、当業者に本発明の範囲を完全に伝えるように用意されているのである。全図面を通じて、同じ番号は同じ要素を示す。当業者には判るように、本発明は、方法または装置として具体化されている。したがって、本発明は、完全にハードウエアの実施例、完全にソフトウエアの実施例、またはソフトウエアとハードウエアの態様を組み合わせた実施例の形になってもよい。
【００１９】
図１は、本発明の一実施例を示す。図１で判るように、通信メッセージの発信元１０は、無線通信インターフェース１２にアクセスする。この通信メッセージの宛先は、無線通信リンク１６を通じて第１の無線通信インターフェース１２と交信する第２の無線通信インターフェース１４にアクセスする。
【００２０】
本発明の特定の実施例における発信元１０および宛先１８は、イーサネットの発信元および宛先である。このようなケースでは、通信インターフェース１２、１４は、無線イーサネットのアダプタなど無線通信リンクを通じてイーサネットのパケットを転送することができるアダプタである。発信元および宛先の装置は、ネットワーク・コンピュータ、ワークステーション、パーソナル・コンピュータ、個人情報管理端末（personal information managers）など、イーサネット通信プロトコルのようなパケット通信プロトコルでデータ・パケットの発信元または宛先として機能することができる装置である。
【００２１】
本明細書では、イーサネット・プロトコルを参照して本発明が説明されているが、当業者にはよく判るように、パケットを使用する他の通信プロトコルも本発明の教示から利することができる。たとえば、本発明の教示を利用して、伝送制御プロトコル／インターネット・プロトコル（TCP/IP）、非同期転送モード（ATM）プロトコルなど、パケット通信を使用するプロトコルを用いることができる。
【００２２】
その上、本発明は、無線通信リンクに言及して説明されているが、本発明が無線通信に限定されていると解釈してはならない。ここで使用されている通信リンクという用語は、相互に離れている２つのプロセッサの間のリンクのことであり、２つのプロセッサの間の通信を可能にするならばいかなるタイプのリンクでもよい。本発明の教示は、通信リンクを通じて転送されるデータ量が削減される通信リンクならば、いかなる通信リンクにも利点をもたらす。このような通信リンクの例には、低速度モデム通信、衛星通信リンク、セルラー通信リンク、無線周波通信リンク、マイクロ波通信リンクなど、通信リンクを通じて転送されるデータ量にもとづいて速度が調整されるいかなる通信リンクも含まれる。
【００２３】
図１は、無線通信リンク１６を通じて交信できる１つの発信元と１つの宛先を示す。しかし、当業者には判るように、通信インターフェース１２、１４を通じて、複数の発信元および宛先がアクセス可能である。更に発信元および宛先間の通信は、無線通信リンク１６を隔てた両方向で可能である。通信インターフェース１２、１４は、通信インターフェース１２、１４を使用し無線通信リンク１６を隔てて交信する発信元および宛先の両方にアクセスすることができる。このように図１は一例であって、本発明を限定していると解釈してはならない。
【００２４】
概観すると、本発明のある種の実施例の動作は、通信パケットのヘッダの大きさを削減することにより、無線通信リンク１６のような、通信リンクを通じてパケットを転送する場合のデータの削減機能を備えている。より詳細には、発信元アドレスおよび宛先アドレスのようなルーティング情報を持ったデータ・パケットは、通信リンクで転送される前にヘッダ情報が除去される。エイリアス・アドレスがヘッダに割り当てられると、そのエイリアス・アドレスがデータ・パケットに追加される。ここで使用される「エイリアス・アドレス」という用語は、最初のメッセージのヘッダ情報に対応付けられる名称であって、エイリアス・アドレスが判ると最初のメッセージを再生できるのである。このようにしてデータとエイリアス・アドレスが通信リンクで転送される。通信リンクの受信側は、修正されたデータ・パケットを受信して、受信したエイリアス・アドレスにもとづいて最初のデータ・パケットを再構成する。発信元および宛先のアドレスが同じ後続メッセージからも発信元および宛先のアドレス情報が除去され、この対応付けられたエイリアス・アドレスが、通信リンクを通じて転送されるために使用される。エイリアス・アドレスは、最初のデータの対応する発信元および宛先のアドレスの発信元および宛先のアドレスより小さくてもよいので、通信リンクを通じて転送されるデータ量は、削減される。
【００２５】
本発明の特定の態様におけるエイリアス・アドレスは、すべてのエイリアス・アドレスが使用されてしまうまで、未使用エイリアス・アドレスに割り当てられる。すべてのエイリアス・アドレスが使用されてしまった後で、通信リンクで転送されるための新しい発信元と宛先を備えたデータ・パケットが受信されると、最近使用されたことが最少の（least recently used）エイリアス・アドレスが、この新しい発信元および宛先のアドレスに割り当てられる。したがって、本発明は、前のエイリアス・アドレスの対応付けを明白に終了するためのオーバーヘッドを伴わずにエイリアス・アドレスの対応付けを変えることができる。その上、エイリアス・アドレスの割り当てのために、通信リンクの帯域幅の広さが非常に大きく占有されていることが決定されると、エイリアス・アドレスの大きさを拡張して、再割り当てが発生する頻度を小さくする。
【００２６】
以下、イーサネットの例と図１のブロック図について、本発明の各種実施例の特定の動作を説明する。本発明の実施例を示す流れ図である図３、４および図６から図８についても言及する。流れ図の各ブロックと、流れ図のブロックの組み合わせは、コンピュータ・プログラムの命令によって実行される。これらのプログラム命令がプロセッサに与えられると、プロセッサ上で実行する命令が、流れ図の中のブロックまたは複数のブロックで指定される機能を実行する手段を生成するようなマシンを作動させる。コンピュータ・プログラムは、プロセッサで実行する命令が、流れ図のブロックまたは複数のブロックで指定される機能を実行するようにプロセッサで実行され、プロセッサで実行される一連の演算ステップを発生して、コンピュータで実行される処理を生成することができる。
【００２７】
したがって、流れ図のブロックは、指定された機能を実行する手段の組み合わせと、指定された機能を実行するステップの組み合わせと、指定された機能を実行するプログラム命令の手段をサポートする。流れ図の各ブロックと、流れ図の中のブロックのいろいろな組み合わせは、指定された機能つまりステップを実行する特殊目的用のハードウエアを使用したシステム、または特殊目的用ハードウエアとコンピュータ命令の組み合わせによって実行される。
【００２８】
図３は、無線通信リンク１６のような通信リンクで転送されるデータ・パケットが受信されるときの、通信インターフェース１２のような通信インターフェースの動作を示す。図３に示されているように、無線通信インターフェース１２が発信元１０からデータ・パケットを受信すると、無線通信インターフェース１２は、データ・パケットからヘッダを抽出して、そのヘッダから発信元および宛先のアドレスを決定する（ブロック３０）。次に現在のリンク（つまり、エイリアス・アドレス）が、通信リンク１６の両側で発信元および宛先のアドレスに対応しているか、つまり通信リンク１６が、その発信元および宛先のアドレスのために確定されているか否か決定される（ブロック３２）。リンクが確定されていない場合は、最近使用されたことが最少のエイリアス・アドレスが、その発信元および宛先のアドレスに割り当てられ（ブロック３４）、そのエイリアス・アドレスを発信元および宛先のアドレスに割り当てるように無線通信リンク１６に要求が送られる（ブロック３６）。すべてのエイリアス・アドレスが割り当てられていない場合は、最近使用されたことが最少のエイリアス・アドレスが、未使用のエイリアス・アドレスである。この例では、エイリアス・アドレスは、２５４個のエイリアス・アドレスの所定の１組を定義するように制御するために予約されている２つのアドレス（「００」および「０１」）を備えた１バイト（８ビット）の大きさなので、前に割り当てられたエイリアス・アドレス（使用済みエイリアス・アドレス）を再使用する前に、２５４個のエイリアス・アドレスを割り当てる必要がある。
【００２９】
図２Ｂは、リンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイトとして「００」を含む。「００」は、このパケットがリンクが確定されることを要求していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する１バイトが続く。図２Ｂに示すフォーマットを使用すると、リンク要求は１６バイトのパケットになる。
【００３０】
図３に戻り、リンクを確定する要求を送ると、通信インターフェース１２、１４は、再割り当てフラグをセットする（ブロック３８）。この再割り当てフラグは、受信中の無線通信インターフェース１４または１２とのハンドシェーキングの一部として使用され、リンクが確定されて（つまり、無線通信リンク１６の両側が、エイリアス・アドレスに対する発信元および宛先のアドレスの対応付けが同じになっていて）、無線通信リンク１６から受信されるはずの肯定応答パケットを待っていることを検証する。肯定応答を受信すると、通信インターフェース１２または１４は、再割り当てフラグが設定されたままになっているか否かを見るためにチェックする（ブロック４０）。再割り当てフラグが設定されたままになっている場合はリンクの要求が失敗したので、新しいエイリアス・アドレスが選択され（ブロック３４）、この処理が繰り返される（ブロック３６、３８）。この処理は、リンクが確定されるまで繰り返されるか、一定回数の試行の間繰り返され、それでも成功しない場合は、このメッセージは廃棄される。つまり、このパケットの発信元にエラーが連絡される。
【００３１】
再割り当てフラグが設定されていない場合は（ブロック４０）、リンクが確定されている。通信インターフェース１２または１４は、最初のパケットのＣＲＣをチェックし（ブロック４２）、ＣＲＣエラーが示されると、このパケットを廃棄する（ブロック４４）。また、ＣＲＣのチェックは、リンクを確定する前に実行される。
【００３２】
ＣＲＣエラーが検出されない場合は、ＣＲＣと発信元および宛先のアドレスがパケットから除去されて、エイリアス・アドレスと置き換えられる（ブロック４６）。このイーサネットの例では、無線通信リンク１６で転送されるパケットのフォーマットが図２Ａに示されている。図２Ａで判るように、無線通信リンク１６を隔てて転送されるパケットはフレーム・ヘッダを含み、その後にエイリアス・アドレス（１バイト）が続き、ついでメッセージのタイプ（２バイト）が続き、その後に４６バイトから５７６バイトのデータが続く。削減されたデータ・パケットがつくられると、この削減されたデータ・パケットは無線通信リンク１６で転送される（ブロック４８）。
【００３３】
通信インターフェース１２または１４で受信され、同じエイリアス・アドレスを備えた後続データ・パケットの処理も図３に示されている。図３で判るように、パケットが受信されると、ヘッダが抽出され（ブロック３０）、リンクが存在するか否か決定される（ブロック３２）。このパケットは後続パケットなので、リンクが存在しており再割り当てフラグが設定されることはない（ブロック４０）。パケットのＣＲＣがチェックされ（ブロック４２）、エラーが示されなければ、ヘッダ情報が除去され（ブロック４６）、削減されたデータ・パケットが無線通信リンク１６で転送される（ブロック４８）。
【００３４】
図４は、無線通信リンク１６からパケットが受信されるときの本発明の一実施例による通信インターフェース１２または１４の動作を示す。パケットが受信されると、フレーム・ヘッダ「７Ｅ」の後の第１バイト（Ｃ）が抽出され（ブロック５０）、フレーム・ヘッダの後のこの第１バイトがリンクを確定する要求を指定しているか否か決定される（Ｃ＝「００」）（ブロック５２）。フレーム・ヘッダの後の第１バイトがフレームの要求を指定している場合は、パケットの発信元および宛先のアドレスとエイリアス・アドレス（図２Ｂを参照）のフィールドが抽出され（ブロック５４）、発信元および宛先のアドレスにエイリアス・アドレスが対応付けられる（ブロック５６）。次に確認パケットが構成され（ブロック５８）、通信リンク１６で転送される予定に入れられる（ブロック６０）。
【００３５】
図２Ｃは、リンクが確定されていることを確認するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイト（Ｃ＝「０１」）として「０１」を含む。「０１」は、このパケットがリンクが確定されることを確認していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられているエイリアス・アドレスを指定する１バイトが続く。図２Ｃに示すフォーマットを使用すると、リンク確認パケットは１６バイトのパケットになる。
【００３６】
図４のブロック５２に戻り、フレーム・ヘッダの後の第１バイトが「００」でない場合は、そのバイトが「０１」かどうか判定し、このバイトが、図２Ｃに示す確認パケットであることを示しているか否か決定される。フレーム・ヘッダの後の第１バイトが、リンク確認パケットを指定していると、パケットの発信元および宛先のアドレスとエイリアス・アドレスのフィールド（図２Ｃを参照）が抽出され（ブロック６４）、エイリアス・アドレスに対応付けられた再割り当てフラグがリセットされる（ブロック６６）。処理は、図３に関する上記説明のとおりに続き、通信リンク１６を通じて最初のパケットのデータを転送する。
【００３７】
フレーム・ヘッダの後の第１バイトが「００」でも「０１」でもない場合は、このパケットが、図２Ａで指定されるフォーマットのデータ・パケットである。フレーム・ヘッダの後の第１バイトは、エイリアス・アドレスに対応付けられた発信元および宛先のアドレスの対と一致するパケットのエイリアス・アドレスを指定する（ブロック６８）。最初のパケットは再構成され、最初の宛先１８に転送する予定に入れられる（ブロック７２）。
【００３８】
図５Ａから図８は本発明の代替実施例を示しており、この場合、エイリアス・アドレスの大きさが拡張される。このような実施例は、エイリアス・アドレスの「攪乱」の可能性を小さくする。エイリアス・アドレスを発信元および宛先のアドレスに対応付けるリンクを確定することに関連して何らかのオーバーヘッドが存在するので、リンクを確定するパケットによって、通信リンク１６の帯域幅の大きな割合が占有されるという条件が生起する。本明細書の中で「攪乱」と呼ばれるこの条件は、エイリアス・アドレスのフィールドを拡張して２バイトのアドレスデータを含めることによって、その始まりを遅らせるか予防することができ、このため、使用可能なエイリアス・アドレスの数を実質的に増加させて、エイリアス・アドレスの再割り当ての頻度を低減する。
【００３９】
図５Ａ、５Ｂは、本発明の代替実施例に関連するシングルバイトおよびダブルバイトのアドレスの例を示す。図５Ａで判るように、シングルバイトの第１ビットは、シングルバイト・アドレスを示す「０」に設定されている。図５Ｂは、拡張（extended）アドレス・フィールドの第１ビットが、拡張アドレスを示す「１」に設定されていることを示す。
【００４０】
図６は、通信リンク１６で転送されるパケットを受信するときの本発明の代替実施例の動作を示す。図６で判るように、通信インターフェース１２または１４は、まず現在のリンクが、受信したパケットの発信元および宛先のアドレスに対応付けられているか否か決定する（ブロック８０）。リンクが存在しない場合は、未使用のエイリアス・アドレスが使用可能か否か決定される（ブロック８２）。拡張エイリアス・アドレスが使用されていない場合、この決定はシングルバイトのエイリアス・アドレスの稼働率にもとづいて行われる。拡張エイリアス・アドレスが使用されている場合、この決定は拡張エイリアス・アドレスの稼働率にもとづいて行われる。未使用のエイリアス・アドレスが使用可能でない場合は、エイリアス・アドレスが攪乱されているか否か決定される（ブロック８４）。
【００４１】
攪乱が発生しているか否かの決定は、通信リンクを通じて転送されるデータ・パケットに対するリンク確定要求の割合、全アドレス空間が再割り当てされてからの時間（たとえば、８ビットのエイリアス・アドレスに対して行われた最新の２５４回の再割り当て中に経過した時間）、または当業者には既知の方法にもとづいて行われる。一実施例では、（発生の相対頻度で推定される）確率が非常に大きくて、活動状態にあるリンクがエイリアス・アドレスの再割り当てによって中断されるときに攪乱が宣言され、この場合、最後のＴミリセコンド中にリンクが使用されたときはリンクは活動状態にあると考えられる。
【００４２】
攪乱が発生している場合は、エイリアス・アドレス・フィールドのフィールド長が２バイト以上に拡張され、拡張エイリアス・アドレスが使用される（ブロック８６）。次に未使用の拡張エイリアス・アドレスからエイリアス・アドレスが選択される（ブロック９０）。攪乱が発生していない場合は、発信元および宛先のアドレスと対応付けるために、最近使用されたことが最少のエイリアス・アドレスが選択される（ブロック８８）。拡張エイリアス・アドレスが使用されている場合、この選択は、シングルバイトのエイリアス・アドレスの最後の使用にもとづいて行われる。
【００４３】
いずれのケースでも、エイリアス・アドレスが選択されると、リンク確定要求が通信リンクで転送される（ブロック９２）。代表的なリンク確定要求パケットのフォーマットは、拡張エイリアス・アドレス用が図５Ｄに示され、シングルバイト・アドレス用が図２Ｂに示されている。図２Ｂは上に説明されている。図５Ｄは、拡張エイリアス・アドレスのリンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後のデータ・パケットの第１バイトとして「０２」を含む。「０２」は、このパケットが拡張エイリアス・アドレスのリンクが確定されることを要求していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する２バイトが続く。図５Ｄに示すフォーマットを使用すると、リンク要求は１７バイトのパケットになる。
【００４４】
リンク確定要求パケットを送ると、通信インターフェース１２または１４は、リンクが確定された確認の受信を待つ（ブロック９４）。リンクを確定する動作（ブロック９２、９４）は、図３、４を参照して上に説明したように実行され、この場合、リンクを確定するためにエラー時の再試行の手法が使用される。
【００４５】
リンクが確定されると、最初のデータ・パケットは、上に説明したように、発信元および宛先のアドレスとＣＲＣを除去して、データ・パケットを削減するエイリアス・アドレスを含むように変更され（ブロック９６）この削減されたデータ・パケットがリンク１６で転送される（ブロック９８）。代表的な削減されたデータ・パケットのフォーマットが図２Ａおよび図５Ｃに示されている。
【００４６】
図７、８は、通信リンク１６からパケットを受信するときに拡張エイリアス・アドレスを使用する本発明の代替実施例の動作を示す。図７で判るように、通信リンク１６からパケットが受信されると、フレーム・ヘッダの後の第１バイトが抽出される（ブロック１００）。この第１バイトが「００」または「０２」の場合、このパケットはリンク確定要求なので、パケットのフォーマット（図２Ｂおよび図５Ｄを参照）にもとづいて適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される（ブロック１０２、１０４）。抽出されたエイリアス・アドレスは、発信元および宛先のアドレスに対応付けられる（ブロック１０６）。次に確認パケットが構成され（ブロック１０８）、通信リンク１６で転送される予定に入れられる（ブロック１１０）。
【００４７】
確認パケットのフォーマットは、確定要求パケットのフォーマットに対応する。したがって、「００」のリンク確定要求が受信されると、図２Ｃに示す「０１」フォーマットの確認パケットが構成される。図２Ｃの確定要求パケットのフォーマットは、上に説明されている。しかし、受信したリンク確定要求が、「０２」の拡張エイリアス・アドレスのリンク確定要求であった場合は、フォーマットが図５Ｅの確認パケットが構成される。
【００４８】
図５Ｅは、拡張エイリアス・アドレスのリンクが確定されることを要求するため、通信インターフェース１２または１４によって通信リンク１６で転送されるデータ・パケットを示す。このデータ・パケットのフォーマットは、フレーム・ヘッダの後の第１バイトとして「０３」を含む。「０３」は、このパケットが拡張エイリアス・アドレスのリンクが確定されることを確認していることを示す。このパケットの次の１２バイトは、最初のデータ・パケットの発信元および宛先のアドレスを指定する。この発信元および宛先のアドレスの後に、発信元および宛先のアドレスに対応付けられることを要求されたエイリアス・アドレスを指定する２バイトが続く。図５Ｅに示すフォーマットを使用すると、リンク確認パケットは１７バイトのパケットになる。
【００４９】
図７に戻り、通信リンク１６から受信したパケットのフレーム・ヘッダの後の第１バイトが、「００」でも「０２」でもない場合は、フレーム・ヘッダの後の第１バイトが、「０１」または「０３」であるか否か決定される（ブロック１１２）。第１バイトが「０１」または「０３」の場合、このパケットは確認パケットなので、パケットのフォーマット（図２Ｃおよび図５Ｅを参照）にもとづいて、適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される（ブロック１１２およびブロック１１４）。抽出されたエイリアス・アドレスに対応付けられた再割り当てフラグはリセットされて、リンクの確定に成功したことを示す（ブロック１１６）。
【００５０】
受信したパケットのフレーム・ヘッダの後の第１バイトが、「００」、「０１」、「０２」または「０３」でない場合、このパケットは、図２Ａまたは図５Ｃに示すフォーマットのどちらか１つのフォーマットのデータ・パケットである。エイリアス・アドレスは、フレーム・ヘッダの後の第１バイトの第１ビットを調べることによって、データ・パケットから決定される。そのビットが「０」の場合は、シングルバイトのエイリアス・アドレスが使用される（図５Ａを参照）。そのビットが「１」の場合は、拡張エイリアス・アドレスが使用される（図５Ｂを参照）。いずれのケースでも、エイリアス・アドレスはこのパケットから抽出されるので、対応付けられた発信元および宛先のアドレスと一致する（ブロック１１８）。最初のパケットはＣＲＣを含めて再構成され（ブロック１２０）、通信リンクで転送される予定に入れられる（ブロック１２２）。
【００５１】
図８は、通信リンク１６からパケットを受信するときに拡張エイリアス・アドレス指定を使用するが、拡張エイリアス・アドレスのために別の要求パケットや確認パケットを使用しない、本発明の代替実施例の動作を示す。攪乱が発生しているか否か決定するために、同じ方法論を使用することにより、攪乱が発生しているか否か、通信リンク１６の両側で独立に決定できるため、拡張エイリアス・アドレスを使用すべきことを信号で明確に知らせる必要が回避されている。
【００５２】
図８で判るように、通信リンク１６からパケットが受信されると、フレーム・ヘッダの後の第１バイトが抽出される（ブロック１３０）。第１バイトが「００」または「０１」の場合、このパケットは、リンク確定要求パケットまたは確認パケットのいずれかなので、シングルバイトまたは拡張エイリアス・アドレス指定が使用されていることを示す攪乱が発生しているか否か決定される（ブロック１３２、１４２）。また、受信側の通信インターフェースは、エイリアス・アドレス・フィールドの第１ビットを調べ、そのビットが、シングルバイトを示す「０」、または拡張エイリアス・アドレス指定を示す「１」であったことを決定してもよい。通信インターフェースはパケットの全長を決定できるので、その長さが１６バイトの場合は、シングルバイトのエイリアス・アドレス指定が使用されている。パケットが１７バイトの場合は、拡張エイリアス・アドレス指定が使用されている。いずれのケースでも、シングルバイトまたは拡張エイリアス・アドレス指定が使用されていることが決定されると、パケットのフォーマット（図２Ｂ、２Ｃまたは図５Ｄ、５Ｅを参照）にもとづいて、適切な発信元および宛先のアドレスとエイリアス・アドレスがパケットから抽出される。（ブロック１４０またはブロック１４４）
【００５３】
エイリアス・アドレスが抽出されると、フレーム・ヘッダの後の第１バイトが、リンク要求パケットを示す「００」であるか否か決定される（ブロック１４６）。違っている場合は、このパケットはリンク確認であり、そのエイリアス・アドレスに対応付けられた再割り当てフラグがリセットされる（ブロック１４８）。フレーム・ヘッダの後の第１バイトが「００」の場合、このパケットはリンク確定要求なので、発信元および宛先にエイリアス・アドレスが割り当てられ（ブロック１５０）、適切な確認パケットが構成される（ブロック１５２）。次にこの確認パケットは、通信リンク１６で転送される予定に入れられる（ブロック１５４）。
【００５４】
ブロック１３２に戻り、フレーム・ヘッダの後の第１バイトが、「００」でも「０１」でもない場合、このパケットはデータ・パケットである。上に説明したように、エイリアス・アドレスが抽出され、このアドレスの第１ビットを使用して、アドレスが拡張されているか否か決定する（ブロック１３４）。次に最初のパケットが再構成され（ブロック１３６）、宛先へ転送される予定に入れられる（ブロック１３８）。
【００５５】
エイリアス・アドレスと発信元および宛先のアドレスとの対応付けは、項目（item）を結びつけるための非常に多くの手法を用いて行うことができる。たとえば、ルックアップテーブルや方向付きリスト（linked list）を使用して、エイリアス・アドレスと、発信元および宛先のアドレスとの間の対応付けをつくり出すことができる。テーブルで実行する場合は、前に使用されたエイリアス・アドレスであって、最近使用されたことが最少のエイリアス・アドレスの選択を容易にするように、エイリアス・アドレス、発信元および宛先のアドレスおよびエイリアス・アドレスの最終使用時を、通信リンク１６の両側で保守することができる。
【００５６】
本発明の拡張エイリアス・アドレスの実施例中の「ゴミ集め（trash-collection）」ルーチンは、拡張された長さのエイリアス・アドレスをもつ各リンクごとに最終使用時を調べ、アドレスが拡張されていて長時間使用されないリンクは、通信リンク１６の両端にあるテーブルから除去される。このように、エイリアス・アドレスの長さは、知らず知らずのうちに最短のオプションに戻っていく。拡張フィールドのエイリアス・アドレスがテーブルに存在しなくなると、「０２」および「０３」メッセージの使用は、攪乱がもう一度検出されるまで中断されたままになり、両側のテーブル（bridge tables）は、拡張以前の大きさに戻る。
【００５７】
また、「ゴミ集め」ルーチンは、リンクの両端にあるテーブルから、最終使用時が所定の閾値より古いリンクを定期的に除去する。リンクの総数が、１組の非拡張エイリアス・アドレスの中で使用可能なリンクの数以下になると、拡張エイリアス・アドレスのリンクを、後続の通信の非拡張エイリアス・アドレスに再割り当てしてもよい。当業者には判るように、本開示を考えると、非拡張エイリアス・アドレスで動作するようにシステムを元に戻す別の方法を使用してもよい。
【００５８】
イーサネット通信プロトコルに関して本発明を説明してきたが、当業者には判るように、本発明の教示は、他の通信プロトコルにも適用される。たとえば、通信インターフェース１２、１４がＩＰルーティング機能を実行し、イーサネット・パケットがＩＰデータグラムを含む場合、通信インターフェース１２、１４は、内部のデータグラムからＩＰルーティング情報を除去する。このようなケースでは、ルーティング情報を保存または再計算して、データグラムの経路内の次のホップを与えてもよい。したがって、本発明は、ＴＣＰ／ＩＰとともに使用して、イーサネットおよびＩＰのアドレス指定が除去されたり、各終端部のゲートウエイまたはルータが、ＩＰ経路の次のホップを指定するイーサネットのパケットにＩＰデータグラムを再バンドルする場合のオーバーヘッドを更に削減することができる。
【００５９】
特殊な用語が使用されているとはいえ、図面および明細書の中で本発明の代表的な実施例が開示されているが、これらの実施例は一般的かつ説明的な意味で使用されているにすぎず、限定する目的では使用されていないので、本発明の範囲は、以下の特許請求の範囲に詳述されている。
【図面の簡単な説明】
【図１】 本発明の一実施例を使用した通信システムのブロック図。
【図２Ａ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図２Ｂ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図２Ｃ】 本発明の一実施例で使用されているデータ・パケットを示す図。
【図３】 本発明の一実施例のとおり、通信インターフェースによってパケットを受信するときに実行される動作を示す流れ図。
【図４】 本発明の一実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
【図５Ａ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｂ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｃ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｄ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図５Ｅ】 本発明の代替実施例で使用されているデータ・パケットを示す図。
【図６】 本発明の代替実施例のとおり、通信インターフェースによって、パケットを受信するときに実行される動作を示す流れ図。
【図７】 本発明の代替実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
【図８】 本発明の第２の代替実施例のとおり、通信インターフェースによって、通信リンクからデータを受信するときに実行される動作を示す流れ図。
Claims (33)
- 通信リンク（１６）を通じて転送される、メッセージヘッダを備えたメッセージを伝達するときのオーバーヘッドを削減する方法であって、
前記通信リンク（１６）を通じて転送されるメッセージが受信され、削減されたデータメッセージおよび対応付けられたエイリアスアドレスが前記通信リンク（１６）で転送される方法において、
所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスが使用可能であるか否か決定するステップと、
未使用のエイリアスアドレスが使用可能な場合は、対応付けられたエイリアスアドレスを与えるように、所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスを、前記受信したメッセージのヘッダの少なくとも一部と対応付けるステップと、
未使用のエイリアスアドレスが使用不能な場合は、前記所定の１組のエイリアスアドレスの使用済みの１つを前記ヘッダと対応付け、対応付けられたエイリアスアドレスを与えるように、前記所定の第１組のエイリアスアドレスからのエイリアスアドレスであって、前に受信したメッセージのヘッダと現在対応付けられているエイリアスアドレスを、前記受信したメッセージの前記ヘッダの少なくとも一部と対応付けるステップと、
メッセージヘッダを備えた後続メッセージから、前記メッセージヘッダの少なくとも一部を除去して、メッセージを削減するステップであって、前記後続メッセージのメッセージヘッダの一部は、前記受信したメッセージの前記メッセージヘッダと実質的に同一である前記ステップ（４６、９６）とを含み、、
前記除去するステップは、前記エイリアスアドレスと、前記メッセージに付随する前記メッセージヘッダの少なくとも一部とを、前記通信リンクで転送するステップ（３６、９８）より先に実行され、
前記メッセージヘッダの少なくとも一部と前記対応付けられたエイリアスアドレスとの対応付けの確認を、前記通信リンクから受信する前記ステップ（３８、９４）を更に含む
ことを特徴とする方法。 - 請求項１記載の方法であって、
エイリアスアドレスと、転送された削減されたデータメッセージとを前記通信リンク（１６）から受信するステップ（５０、１００、１３０）と、
前記受信したエイリアスアドレスに対応付けられた前記メッセージヘッダの前記少なくとも一部と、前記削減されたデータメッセージとから前記後続メッセージを再構成するステップ（７０、１２０、１３６）と、
を更に含む方法。 - 請求項１記載の方法であって、メッセージヘッダの少なくとも一部に対応付けられたエイリアスアドレスが使用済みとして識別するステップを更に含む方法。
- 請求項１記載の方法において、前記所定の第１組のエイリアスアドレスからの使用済みエイリアスアドレスを対応付ける前記ステップは、
前記使用済みエイリアスアドレスごとに最終使用時を与えるように、前記所定の第１組のエイリアスアドレスからの各使用済みエイリアスアドレスが、いつ最後の使用されたかを決定するステップ（３４、８８）と、
使用済みエイリアスアドレスが使用不能な場合は、前記所定の第１組のエイリアスアドレスからの最終使用時が最も古い使用済みエイリアスアドレスと、前記受信したメッセージの前記メッセージヘッダの少なくとも一部とを対応付けるステップと、
を含む方法。 - 請求項１記載の方法において、前記メッセージヘッダの前記少なくとも一部は、前記メッセージの発信元アドレスおよび宛先アドレスを含む方法。
- 請求項１記載の方法において、前記通信リンク（１６）は、無線通信リンクである方法。
- 請求項１記載の方法であって、
エイリアスアドレスと前記メッセージヘッダとの対応付けを監視するステップ（８４、１４２）と、
前記監視にもとづいて前記所定の第１組のエイリアスアドレスの中のエイリアスアドレスの数を増加させ、所定の第２組のエイリアスアドレスを与えるステップ（８６、１４４）と、
を更に含む方法。 - 請求項７記載の方法において、前記増加させるステップは、エイリアスアドレスの長さを増加させた連絡を、前記通信リンクで転送する前記ステップを含む方法。
- 請求項７記載の方法であって、前記エイリアスアドレスが活動状態にないと決定されると、前記所定の第２組のエイリアスアドレスから前記エイリアスアドレスを除去するステップを更に含む方法。
- 請求項９記載の方法において、前記所定の第２組のエイリアスアドレスは、前記所定の第１組のエイリアスアドレスと所定の第３組のエイリアスアドレスの組み合わせを含む方法。
- 請求項１０記載の方法であって、前記所定の第３組のエイリアスアドレスのすべてが、前記所定の第２組のエイリアスアドレスから除去されている場合は、前記エイリアスアドレスの数を前記所定の第１組のエイリアスアドレスに減少させるステップを更に含む方法。
- 通信リンクを通じて、メッセージヘッダを備えたメッセージを伝達するときのオーバーヘッドを削減するシステムであって、前記通信リンク（１６）を通じて転送されるメッセージが受信され、削減されたデータメッセージと対応付けられたエイリアスアドレスが前記通信リンク（１６）で転送されるシステムにおいて、
所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスが使用可能であるか否か決定する手段と、
未使用のエイリアスアドレスが使用可能な場合は、対応付けられたエイリアスアドレスを与えるように、所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスを、前記受信したメッセージのヘッダの少なくとも一部と対応付ける手段と、
未使用のエイリアスアドレスが使用不能な場合は、対応付けられたエイリアスアドレスを与えるように、前記所定の第１組のエイリアスアドレスからの使用済みのエイリアスアドレスを、前記受信したメッセージの前記ヘッダの少なくとも一部と対応付ける手段と、
メッセージヘッダを備えた後続メッセージから、前記メッセージヘッダの少なくとも一部を除去して、メッセージを削減する手段であって、前記後続メッセージのメッセージヘッダの一部は、前記受信したメッセージの前記メッセージヘッダと実質的に同一である前記手段（４６、９６）とを含み、
前記エイリアスアドレスと、前記メッセージに付随する前記メッセージヘッダの少なくとも一部とを、前記通信リンク（１６）で転送する手段（１２、３６、９８）を更に含み、
前記メッセージヘッダの少なくとも一部と、前記対応付けられたエイリアスアドレスとの対応付けの確認を、前記通信リンク（１６）から受信する手段（１２、３８、９４）を更に含む
ことを特徴とするシステム。 - 請求項１２記載のシステムであって、
エイリアスアドレスと、転送された削減されたデータメッセージとを前記通信リンク（１６）から受信する手段（１４、５０、１００、１３０）と、
前記受信したエイリアスアドレスに対応付けられた前記メッセージの前記少なくとも一部と、前記削減されたデータメッセージとから前記後続メッセージを再構成する手段（７０、１２０、１３６）と、
を更に含むシステム。 - 請求項１２記載のシステムであって、メッセージヘッダの少なくとも一部に対応付けられたエイリアスアドレスが使用済みとして識別する手段を更に含むシステム。
- 請求項１２記載のシステムにおいて、前記所定の第１組のエイリアスアドレスからの使用済みエイリアスアドレスを対応付ける前記手段は、
前記使用済みエイリアスアドレスごとに最終使用時を与えるように、前記所定の第１組のエイリアスアドレスからの各使用済みエイリアスアドレスが、いつ最後に使用されたかを決定する手段（３４、８８）と、
使用済みエイリアスアドレスが使用不能な場合は、前記所定の第１組のエイリアスアドレスからの最終使用時が最も古い使用済みエイリアスアドレスと、前記メッセージヘッダの少なくとも一部を対応付ける手段と、
を含むシステム。 - 請求項１２記載のシステムにおいて、前記メッセージヘッダの前記少なくとも一部は、前記メッセージの発信元アドレスおよび宛先アドレスを含むシステム。
- 請求項１２記載のシステムにおいて、前記通信リンク（１６）は、無線通信リンクであるシステム。
- 請求項１２記載のシステムであって、
エイリアスアドレスと前記メッセージヘッダとの対応付けを監視する手段（８４、１４２）と、
所定の第２組のエイリアスアドレスを与えるように、前記監視にもとづいて前記所定の第１組のエイリアスアドレスの中のエイリアスアドレスの数を増加させる手段（８６、１４４）と、
を更に含むシステム。 - 請求項１８記載のシステムにおいて、前記増加させる手段は、エイリアスアドレスの長さを増加させた連絡を、前記通信リンクで転送する手段を更に含むシステム。
- 請求項１８記載のシステムであって、前記エイリアスアドレスが活動状態にないと決定されると、前記所定の第２組のエイリアスアドレスから前記エイリアスアドレスを除去する手段を更に含むシステム。
- 請求項２０記載のシステムにおいて、前記所定の第２組のエイリアスアドレスは、前記所定の第１組のエイリアスアドレスと所定の第３組のエイリアスアドレスの組み合わせを含むシステム。
- 請求項２１記載のシステムであって、前記所定の第３組のエイリアスアドレスのすべてが、前記所定の第２組のエイリアスアドレスから除去されている場合は、前記エイリアスアドレスの数を前記所定の第１組のエイリアスアドレスに減少させる手段を更に含むシステム。
- 通信リンク（１６）を通じて、メッセージヘッダを備えたメッセージを伝達するときのオーバーヘッドを削減するコンピュータプログラムであって、前記通信リンクを通じて転送されるメッセージが受信され、削減されたデータメッセージと対応付けられたエイリアスアドレスが前記通信リンク（１６）で転送されるコンピュータプログラムにおいて、
コンピュータが読み取り可能な記憶媒体であって、前記媒体に含まれるコンピュータが読み取り可能なプログラムコードの手段を備えた前記記憶媒体を含み、前記コンピュータが読み取り可能なプログラムコードの手段は、
所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスが使用可能であるか否か決定するコンピュータが読み取り可能なプログラムコードの手段と、
未使用のエイリアスアドレスが使用可能な場合は、対応付けられたエイリアスアドレスを与えるように、所定の第１組のエイリアスアドレスからの未使用のエイリアスアドレスを、前記受信したメッセージのヘッダの少なくとも一部と対応付けるコンピュータが読み取り可能なプログラムコードの手段と、
未使用のエイリアスアドレスが使用不能な場合は、対応付けられたエイリアスアドレスを与えるように、前記所定の第１組のエイリアスアドレスからの使用済みのエイリアスアドレスを、前記受信したメッセージの前記ヘッダの少なくとも一部と対応付けるコンピュータが読み取り可能なプログラムコードの手段と、
メッセージヘッダを備えた後続メッセージから、前記メッセージヘッダの少なくとも一部を除去して、メッセージを削減するコンピュータが読み取り可能なプログラムコードの手段であって、前記後続メッセージのメッセージヘッダの一部は、前記受信したメッセージの前記メッセージヘッダと実質的に同一である前記コンピュータが読み取り可能なプログラムコードの手段（４６、９６）とを含み、
前記エイリアスアドレスと、前記メッセージに付随する前記メッセージヘッダの少なくとも一部とを、前記通信リンク（１６）で転送するコンピュータが読み取り可能なプログラムコードの手段（３６、９８）を更に含み、
前記メッセージヘッダの少なくとも一部と、前記対応付けられたエイリアスアドレスとの対応付けの確認を、前記通信リンク（１６）から受信するコンピュータが読み取り可能なプログラムコードの手段（３８、９４）を更に含む
ことを特徴とするコンピュータプログラム。 - 請求項２３記載のコンピュータプログラムであって、
エイリアスアドレスと、転送された削減されたデータメッセージとを前記通信リンク（１６）から受信するコンピュータが読み取り可能なプログラムコードの手段（５０、１００、１３０）と、
前記受信したエイリアスアドレスに対応付けられた前記メッセージの前記少なくとも一部と、前記削減されたデータメッセージとから前記後続メッセージを再構成するコンピュータが読み取り可能なプログラムコードの手段（７０、１２０、１３６）と、
を更に含むコンピュータプログラム。 - 請求項２３記載のコンピュータプログラムであって、メッセージヘッダの少なくとも一部に対応付けられたエイリアスアドレスが使用済みとして識別するコンピュータが読み取り可能なプログラムコードの手段を更に含むコンピュータプログラム。
- 請求項２３記載のコンピュータプログラムにおいて、前記所定の第１組のエイリアスアドレスからの使用済みエイリアスアドレスを対応付ける前記コンピュータが読み取り可能なプログラムコードの手段は、
前記使用済みエイリアスアドレスごとに最終使用時を与えるように、前記所定の第１組のエイリアスアドレスからの各使用済みエイリアスアドレスは、いつ最後に使用されたかを決定するコンピュータが読み取り可能なプログラムコードの手段（３４、８８）と、
使用済みエイリアスアドレスが使用不能な場合は、前記所定の第１組のエイリアスアドレスからの最終使用時が最も古い使用済みエイリアスアドレスと、前記メッセージヘッダの少なくとも一部を対応付けるコンピュータが読み取り可能なプログラムコードの手段と、
を含むコンピュータプログラム。 - 請求項２３記載のコンピュータプログラムにおいて、前記メッセージヘッダの前記少なくとも一部は、前記メッセージの発信元アドレスおよび宛先アドレスを更に含むコンピュータプログラム。
- 請求項２３記載のコンピュータプログラムにおいて、前記通信リンク（１６）は、無線通信リンクであるコンピュータプログラム。
- 請求項２３記載のコンピュータプログラムであって、
エイリアスアドレスと前記メッセージヘッダとの対応付けを監視するコンピュータが読み取り可能なプログラムコードの手段（８４、１４２）と、
所定の第２組のエイリアスアドレスを与えるように、前記監視にもとづいて前記所定の第１組のエイリアスアドレスの中のエイリアスアドレスの数を増加させるコンピュータが読み取り可能なプログラムコードの手段（８６、１４４）と、
を更に含むコンピュータプログラム。 - 請求項２９記載のコンピュータプログラムにおいて、前記増加させるコンピュータが読み取り可能なプログラムコードの手段は、エイリアスアドレスの長さを増加させた連絡を、前記通信リンク（１６）で転送する前記コンピュータが読み取り可能なプログラムコードの手段を含むコンピュータプログラム。
- 請求項２９記載のコンピュータプログラムであって、前記エイリアスアドレスが活動状態にないと決定されると、前記所定の第２組のエイリアスアドレスから前記エイリアスアドレスを除去するコンピュータが読み取り可能なプログラムコードの手段を更に含むコンピュータプログラム。
- 請求項３１記載のコンピュータプログラムにおいて、前記所定の第２組のエイリアスアドレスは、前記所定の第１組のエイリアスアドレスと所定の第３組のエイリアスアドレスの組み合わせを含むコンピュータプログラム。
- 請求項３２記載のコンピュータプログラムであって、前記所定の第３組のエイリアスアドレスのすべてが、前記所定の第２組のエイリアスアドレスから除去されている場合は、前記エイリアスアドレスの数を前記所定の第１組のエイリアスアドレスに減少させるコンピュータが読み取り可能なプログラムコードの手段を更に含むコンピュータプログラム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/034,424 US6115394A (en) | 1998-03-04 | 1998-03-04 | Methods, apparatus and computer program products for packet transport over wireless communication links |
| US09/034,424 | 1998-03-04 | ||
| PCT/US1999/003380 WO1999045678A1 (en) | 1998-03-04 | 1999-02-17 | Reduced packet header in wireless communications network |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002506321A JP2002506321A (ja) | 2002-02-26 |
| JP2002506321A5 JP2002506321A5 (ja) | 2006-06-08 |
| JP4230663B2 true JP4230663B2 (ja) | 2009-02-25 |
Family
ID=21876322
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000535121A Expired - Fee Related JP4230663B2 (ja) | 1998-03-04 | 1999-02-17 | 無線通信ネットワークにおけるパケット・ヘッダの削減 |
Country Status (12)
| Country | Link |
|---|---|
| US (1) | US6115394A (ja) |
| EP (1) | EP1060598B1 (ja) |
| JP (1) | JP4230663B2 (ja) |
| KR (1) | KR100621715B1 (ja) |
| CN (1) | CN1143486C (ja) |
| AU (1) | AU747484B2 (ja) |
| BR (1) | BRPI9908426B1 (ja) |
| DE (1) | DE69919994T2 (ja) |
| EE (1) | EE200000507A (ja) |
| HK (1) | HK1036177A1 (ja) |
| IL (1) | IL138066A0 (ja) |
| WO (1) | WO1999045678A1 (ja) |
Families Citing this family (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8516055B2 (en) | 1998-05-29 | 2013-08-20 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device in a wireless data network |
| US6463463B1 (en) | 1998-05-29 | 2002-10-08 | Research In Motion Limited | System and method for pushing calendar event messages from a host system to a mobile data communication device |
| US6438585B2 (en) | 1998-05-29 | 2002-08-20 | Research In Motion Limited | System and method for redirecting message attachments between a host system and a mobile data communication device |
| US7209949B2 (en) | 1998-05-29 | 2007-04-24 | Research In Motion Limited | System and method for synchronizing information between a host system and a mobile data communication device |
| US6779019B1 (en) | 1998-05-29 | 2004-08-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device |
| US6219694B1 (en) | 1998-05-29 | 2001-04-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device having a shared electronic address |
| US9374435B2 (en) | 1998-05-29 | 2016-06-21 | Blackberry Limited | System and method for using trigger events and a redirector flag to redirect messages |
| US6810405B1 (en) * | 1998-08-18 | 2004-10-26 | Starfish Software, Inc. | System and methods for synchronizing data between multiple datasets |
| GB9824594D0 (en) * | 1998-11-11 | 1999-01-06 | 3Com Technologies Ltd | Modifying tag fields in ethernet data packets |
| US7184413B2 (en) * | 1999-02-10 | 2007-02-27 | Nokia Inc. | Adaptive communication protocol for wireless networks |
| US6370605B1 (en) * | 1999-03-04 | 2002-04-09 | Sun Microsystems, Inc. | Switch based scalable performance storage architecture |
| US6397267B1 (en) | 1999-03-04 | 2002-05-28 | Sun Microsystems, Inc. | Redirected I/O for scalable performance storage architecture |
| US6349357B1 (en) | 1999-03-04 | 2002-02-19 | Sun Microsystems, Inc. | Storage architecture providing scalable performance through independent control and data transfer paths |
| US6535925B1 (en) * | 1999-11-09 | 2003-03-18 | Telefonaktiebolaget L M Ericsson (Publ) | Packet header compression using division remainders |
| US6604155B1 (en) | 1999-11-09 | 2003-08-05 | Sun Microsystems, Inc. | Storage architecture employing a transfer node to achieve scalable performance |
| US6622019B1 (en) * | 1999-11-17 | 2003-09-16 | Eci Telecom, Ltd. | Increasing channel capacity in fixed cellular networks |
| ATE529969T1 (de) | 2000-02-15 | 2011-11-15 | Broadcom Corp | Verfahren zur entfernung von sprachpausenperioden im sprachverkehr über ein asynchrones kommunikationsmedium |
| US7161941B1 (en) * | 2000-03-01 | 2007-01-09 | Texas Instruments Incorporated | Wireless packet communications with extended addressing capability |
| US7916723B2 (en) * | 2000-03-03 | 2011-03-29 | Adtran, Inc. | Automatic network topology identification by nodes in the network |
| US7545755B2 (en) * | 2000-03-03 | 2009-06-09 | Adtran Inc. | Routing switch detecting change in session identifier before reconfiguring routing table |
| US6717956B1 (en) * | 2000-03-03 | 2004-04-06 | Luminous Networks, Inc. | Dual-mode virtual network addressing |
| JP3464644B2 (ja) * | 2000-06-23 | 2003-11-10 | 松下電器産業株式会社 | 無線通信システム及びマルチキャスト通信方法 |
| US7469297B1 (en) * | 2000-08-04 | 2008-12-23 | Intellon Corporation | Mechanism for using a quasi-addressed response to bind to a message requesting the response |
| US7215684B1 (en) * | 2000-09-20 | 2007-05-08 | Qualcomm Incorporated | Method and apparatus for reducing transmission overhead in a communication system |
| CA2725700C (en) | 2000-12-22 | 2015-11-24 | Research In Motion Limited | Wireless router system and method |
| GB2382898B (en) * | 2000-12-29 | 2005-06-29 | Zarlink Semiconductor Ltd | A method of managing data |
| CA2368404C (en) | 2001-01-18 | 2005-08-09 | Research In Motion Limited | Unified messaging system and method |
| US7769047B2 (en) | 2001-02-15 | 2010-08-03 | Broadcom Corporation | Methods for specialized data transfer in a wireless communication system |
| US7039052B2 (en) * | 2001-09-19 | 2006-05-02 | International Business Machines Corporation | Selective routing of multi-recipient communications |
| ATE310353T1 (de) * | 2001-10-04 | 2005-12-15 | Cit Alcatel | Verfahren zum übertragen von daten über ein kommunikationsnetzwerk an ein terminal und netzwerkknoten |
| CA2410118C (en) | 2001-10-26 | 2007-12-18 | Research In Motion Limited | System and method for controlling configuration settings for mobile communication devices and services |
| DE60214590T2 (de) | 2001-12-07 | 2007-09-13 | Research In Motion Ltd., Waterloo | Verfahren und vorrichtung zur steuerung der informationsverteilung zu mobilstationen |
| US6915480B2 (en) * | 2001-12-21 | 2005-07-05 | Agere Systems Inc. | Processor with packet data flushing feature |
| US7106733B2 (en) | 2002-03-20 | 2006-09-12 | Intel Corporation | Method and apparatus for network header compression |
| GB0322491D0 (en) * | 2003-09-25 | 2003-10-29 | British Telecomm | Virtual networks |
| US7567523B2 (en) * | 2004-01-29 | 2009-07-28 | Microsoft Corporation | System and method for network topology discovery |
| US7376567B2 (en) * | 2004-02-16 | 2008-05-20 | Celtro Ltd | Method and system for efficiently transmitting encoded communication signals |
| US7881215B1 (en) * | 2004-03-18 | 2011-02-01 | Avaya Inc. | Stateful and stateless data processing |
| US8365240B2 (en) | 2005-04-18 | 2013-01-29 | Research In Motion Limited | Method for providing wireless application privilege management |
| JP4768324B2 (ja) * | 2005-06-07 | 2011-09-07 | 株式会社東芝 | 無線通信機器 |
| US20070245033A1 (en) * | 2006-04-14 | 2007-10-18 | Microsoft Corporation | Link layer discovery and diagnostics |
| CA2651551C (en) * | 2006-06-07 | 2013-05-28 | Qualcomm Incorporated | Efficient address methods, computer readable medium and apparatus for wireless communication |
| US20080101366A1 (en) * | 2006-10-31 | 2008-05-01 | Motorola, Inc. | Methods for optimized tunnel headers in a mobile network |
| US8179872B2 (en) | 2007-05-09 | 2012-05-15 | Research In Motion Limited | Wireless router system and method |
| EP2007078A1 (en) * | 2007-06-19 | 2008-12-24 | Panasonic Corporation | Header size reduction of data packets |
| US8379623B2 (en) * | 2007-07-10 | 2013-02-19 | Motorola Solutions, Inc. | Combining mobile VPN and internet protocol |
| US8571021B2 (en) * | 2009-06-10 | 2013-10-29 | Microchip Technology Incorporated | Packet based data transmission with reduced data size |
| US8621038B2 (en) | 2011-09-27 | 2013-12-31 | Cloudflare, Inc. | Incompatible network gateway provisioned through DNS |
| US10585809B2 (en) * | 2016-04-01 | 2020-03-10 | Intel Corporation | Convolutional memory integrity |
| CN108599823B (zh) * | 2016-05-10 | 2019-06-07 | 华为技术有限公司 | 无线帧的发送与接收方法与装置 |
| US10686605B2 (en) | 2017-09-29 | 2020-06-16 | Intel Corporation | Technologies for implementing mutually distrusting domains |
| EP3699770A1 (en) | 2019-02-25 | 2020-08-26 | Mellanox Technologies TLV Ltd. | Collective communication system and methods |
| US11627106B1 (en) | 2019-09-26 | 2023-04-11 | Joinesty, Inc. | Email alert for unauthorized email |
| US11737121B2 (en) | 2021-08-20 | 2023-08-22 | Rockwell Collins, Inc. | System and method to compile and distribute spatial awareness information for network |
| US11977173B2 (en) | 2019-11-27 | 2024-05-07 | Rockwell Collins, Inc. | Spoofing and denial of service detection and protection with doppler nulling (spatial awareness) |
| US11726162B2 (en) | 2021-04-16 | 2023-08-15 | Rockwell Collins, Inc. | System and method for neighbor direction and relative velocity determination via doppler nulling techniques |
| US12050279B2 (en) | 2019-11-27 | 2024-07-30 | Rockwell Collins, Inc. | Doppler nulling spatial awareness (DNSA) solutions for non-terrestrial networks |
| US11665658B1 (en) | 2021-04-16 | 2023-05-30 | Rockwell Collins, Inc. | System and method for application of doppler corrections for time synchronized transmitter and receiver |
| US11750699B2 (en) * | 2020-01-15 | 2023-09-05 | Mellanox Technologies, Ltd. | Small message aggregation |
| US11876885B2 (en) | 2020-07-02 | 2024-01-16 | Mellanox Technologies, Ltd. | Clock queue with arming and/or self-arming features |
| US11556378B2 (en) | 2020-12-14 | 2023-01-17 | Mellanox Technologies, Ltd. | Offloading execution of a multi-task parameter-dependent operation to a network device |
| US12088559B1 (en) | 2021-01-29 | 2024-09-10 | Joinesty, Inc. | Implementing a proxy server to selectively obfuscate traffic |
| US11757767B2 (en) | 2021-07-20 | 2023-09-12 | Nokia Solutions And Networks Oy | Source routing with shadow addresses |
| US11922237B1 (en) | 2022-09-12 | 2024-03-05 | Mellanox Technologies, Ltd. | Single-step collective operations |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5131016A (en) * | 1991-01-09 | 1992-07-14 | International Business Machines Corporation | Communications network data compression control system and method |
| CA2065578C (en) * | 1991-04-22 | 1999-02-23 | David W. Carr | Packet-based data compression method |
| US5307413A (en) * | 1991-07-19 | 1994-04-26 | Process Software Corporation | Method and apparatus for adding data compression and other services in a computer network |
| FR2687259B1 (fr) * | 1992-02-11 | 1994-05-06 | Ouest Standard Telematique Sa | Procede de compression de donnees pour systeme de transmission par unites de donnees de protocole, procede de decompression et dispositif correspondant. |
| FR2695275B1 (fr) * | 1992-08-27 | 1994-10-14 | Telecommunications Sa | Procédé et équipement de compression-décompression de données pour terminal synchrone. |
| JPH0795230A (ja) * | 1993-09-20 | 1995-04-07 | Fujitsu Ltd | コネクションレスデータサービスにおける加入者情報の処理方式 |
| US5446736A (en) * | 1993-10-07 | 1995-08-29 | Ast Research, Inc. | Method and apparatus for connecting a node to a wireless network using a standard protocol |
| US5414701A (en) * | 1994-07-22 | 1995-05-09 | Motorola, Inc. | Method and data structure for performing address compression in an asynchronous transfer mode (ATM) system |
| US5535199A (en) * | 1994-09-06 | 1996-07-09 | Sun Microsystems, Inc. | TCP/IP header compression X.25 networks |
| US5572530A (en) * | 1994-10-07 | 1996-11-05 | Comsat Corporation | Technique for efficient integration of integrated services digital network (ISDN) into satellite system |
-
1998
- 1998-03-04 US US09/034,424 patent/US6115394A/en not_active Expired - Lifetime
-
1999
- 1999-02-17 AU AU27694/99A patent/AU747484B2/en not_active Expired
- 1999-02-17 EP EP99908202A patent/EP1060598B1/en not_active Expired - Lifetime
- 1999-02-17 IL IL13806699A patent/IL138066A0/xx unknown
- 1999-02-17 KR KR1020007009739A patent/KR100621715B1/ko not_active IP Right Cessation
- 1999-02-17 DE DE69919994T patent/DE69919994T2/de not_active Expired - Lifetime
- 1999-02-17 WO PCT/US1999/003380 patent/WO1999045678A1/en active IP Right Grant
- 1999-02-17 JP JP2000535121A patent/JP4230663B2/ja not_active Expired - Fee Related
- 1999-02-17 BR BRPI9908426A patent/BRPI9908426B1/pt not_active IP Right Cessation
- 1999-02-17 CN CNB998036390A patent/CN1143486C/zh not_active Expired - Lifetime
- 1999-02-17 EE EEP200000507A patent/EE200000507A/xx unknown
-
2001
- 2001-10-15 HK HK01107210A patent/HK1036177A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| BRPI9908426B1 (pt) | 2016-11-08 |
| US6115394A (en) | 2000-09-05 |
| EP1060598B1 (en) | 2004-09-08 |
| BR9908426A (pt) | 2000-10-31 |
| AU2769499A (en) | 1999-09-20 |
| EP1060598A1 (en) | 2000-12-20 |
| KR20010052198A (ko) | 2001-06-25 |
| DE69919994T2 (de) | 2005-09-22 |
| KR100621715B1 (ko) | 2006-09-11 |
| AU747484B2 (en) | 2002-05-16 |
| JP2002506321A (ja) | 2002-02-26 |
| WO1999045678A1 (en) | 1999-09-10 |
| CN1143486C (zh) | 2004-03-24 |
| EE200000507A (et) | 2002-02-15 |
| HK1036177A1 (en) | 2001-12-21 |
| DE69919994D1 (de) | 2004-10-14 |
| IL138066A0 (en) | 2001-10-31 |
| CN1292961A (zh) | 2001-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4230663B2 (ja) | 無線通信ネットワークにおけるパケット・ヘッダの削減 | |
| US7289509B2 (en) | Apparatus and method of splitting a data stream over multiple transport control protocol/internet protocol (TCP/IP) connections | |
| US5790530A (en) | Message-passing multiprocessor system | |
| US7640364B2 (en) | Port aggregation for network connections that are offloaded to network interface devices | |
| US6778495B1 (en) | Combining multilink and IP per-destination load balancing over a multilink bundle | |
| US20030058863A1 (en) | Method for transmitting compressed data in packet-oriented networks | |
| US20080002663A1 (en) | Virtual network interface card loopback fastpath | |
| US7260650B1 (en) | Method and apparatus for tunneling information | |
| JP2005502225A (ja) | ギガビット・イーサネット・アダプタ | |
| JPH08507909A (ja) | ワークステーションを複数個のコンピュータプラットホームにインタフェースする方法および装置 | |
| US7269661B2 (en) | Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet | |
| US20030081605A1 (en) | Method and apparatus to manage packet fragmentation with address translation | |
| US6925078B1 (en) | Network adaptor driver with destination based ordering | |
| US20070291782A1 (en) | Acknowledgement filtering | |
| US6983334B2 (en) | Method and system of tracking missing packets in a multicast TFTP environment | |
| US6985496B2 (en) | Communication management device and communication management method | |
| JP2000235536A (ja) | データ通信方式及び装置 | |
| US7010548B2 (en) | Sparse and non-sparse data management method and system | |
| WO2002003147A2 (en) | Method for detecting invalid packets by rewriting transaction identifiers | |
| EP1491004A1 (en) | Method for path mtu discovery on ip network and apparatus thereof | |
| JP4916482B2 (ja) | ギガビット・イーサネット・アダプタ | |
| WO2002060152A2 (en) | Improvements in or relating to wireless communication systems | |
| JP2003244251A (ja) | トンネル経路を再構成するパケット通信方法 | |
| JPH11191790A (ja) | 通信データ処理方法及びそのネットワーク間接続装置 | |
| JPH09270820A (ja) | 通信経路選択方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060217 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060217 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060217 |
|
| RD05 | Notification of revocation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7425 Effective date: 20060628 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080718 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080911 |
|
| 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: 20081107 |
|
| 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: 20081204 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4230663 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111212 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111212 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121212 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131212 Year of fee payment: 5 |
|
| 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 |
|
| LAPS | Cancellation because of no payment of annual fees |