JP2011223587A - 移動局のアプリケーションが生のパケット化されたデータを受信および送信するための方法および装置 - Google Patents

Abstract

【課題】移動局のアプリケーションが無線通信システムにおいて生のパケット化されたデータを受信および送信するための方法および装置を提供する。
【解決手段】移動局のアプリケーションは少なくとも１つのソケットを生成する。通信プロトコルスタックの移動局のプロトコル層は、カプセル化され、宛先ポートの情報を欠いている生のパケット化されたデータを通信ネットワークから受信する。移動局のプロトコル層は、逆カプセル化された生のパケット化されたデータを、生成されたソケットへ送る。そして、生成されたソケットが、生のパケット化されたデータを移動局のアプリケーションへ送る。別の構成では、生成されたソケットは、移動局のアプリケーションの生のパケット化されたデータを、移動局のプロトコル層へ送る。そして、移動局のプロトコル層が、カプセル化された生のパケット化されたデータを通信ネットワークへ送る。
【選択図】図３

Description

本発明は、概ね、無線通信の分野に関する。とくに、本発明は無線通信システムにおいて移動局のアプリケーションが生のパケット化されたデータを受信および送信するための斬新な方法および装置に関する。

Ａ．無線通信
無線通信およびコンピュータに関係する技術における最近の革新、並びにインターネット加入者の今までにない増加によって、モバイルコンピューティングへの道が開かれた。事実、モバイルコンピューティングの大衆性により、現在のインターネットのインフラストラクチャに対して、モバイルのユーザにより多くのサポートを与える要求が強まった。このインフラストラクチャの原動力は、種々のサービスを提供するパケット指向のインターネットプロトコル（Internet Protocol, IP）であり、種々のサービスには、パケット（データグラム）をローカルエリアネットワーク（local area network, LAN）とワイドエリアネットワーク（wide area network, WAN）との間でアドレス指定してルート設定するサービスが含まれる。ＩＰプロトコルは、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ（ＲＦＣ ７９１）（“INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, 1981 9）において規定されている。

ＩＰプロトコルは、送信のためにデータをＩＰパケットへカプセル化するネットワーク層プロトコルである。アドレス指定およびルート設定の情報はパケットのヘッダに付される。ＩＰヘッダには、例えば送信ホストおよび受信ホストを識別する３２ビットのアドレスが含まれている。中間のルータはこれらのアドレスを使用して、パケットを、意図されたアドレスをもつその最終的な宛先へ向わせるためのネットワーク上の経路を選択する。したがって、ＩＰプロトコルにより、世界中の何れかのインターネットノードにおいて発信されたパケットを、世界中の他の何れかのインターネットノードへルート設定することができる。これに対して、特定のアプリケーションに対処するためには、伝送制御プロトコル（Transmission Control Protocol, TCP）またはユーザデータグラムプロトコル（User Datagram Protocol, UDP）の何れかを含むトランスポート層が使用される。

現在の傾向では、モバイルのユーザはラップトップまたはパームトップコンピュータのようなモバイルコンピュータを、セルラまたは携帯電話のような無線通信デバイスと共に使用して、インターネットにアクセスしている。したがって、ちょうど、従来からユーザが“有線の”通信デバイスを使用してコンピュータを陸上ネットワーク（land-based network）へ接続していたように、モバイルのユーザは一般的に“移動局”（mobile station, MS）と呼ばれる無線通信デバイスを使用してモバイル端末をこのようなネットワークへ接続する。本明細書で使用しているように、移動局またはＭＳは、公共の無線ラジオネットワーク（wireless radio network）の加入者局を指す。

（従来技術を示している）図１は、無線データ通信システムの高レベルのブロック図を示しており、この中でＭＳ110は基地局／移動局スイッチングセンタ（Base Station/Mobile Switching Center, BS/MSC）106を介して相互接続機能（Interworking Function, IWF）108と通信する。ＩＷＦ108は、インターネットへのアクセス点として働く。ＩＷＦ108はＢＳ／ＭＳＣ106に接続されていて、一緒に位置していることも多く、ＢＳ／ＭＳＣ106はこの技術において知られているように従来の無線基地局であってもよい。無線データ通信システムに対処する別の標準プロトコルは、“WIRELESS IP NETWORK STANDARD”というタイトルで1999年12月に発行された第３世代パートナーシッププロジェクト２（3rd Generation Partnership Project 2, “3GPP2”）である。３Ｇ無線ＩＰネットワークの標準規格には、例えば、ＩＷＦ108のように機能するパケットデータ供給ノード（Packet Data Serving Node, PDSN）が含まれる。

種々のプロトコルが、ＭＳ110とＩＷＦ108との間のデータ通信に対処している。例えば、米国電気通信工業会（Telecommunications Industry Association, TIA）／電子機械工業会（Electronics Industries Association, EIA）の暫定的標準規格（Interim Standard）のＩＳ−９５は、“MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM”というタイトルで1993年7月に発行されていて、これは概して広帯域拡散スペクトル無線通信システムの標準規格を与えている。さらに加えて、標準規格のＴＩＡ／ＥＩＡ ＩＳ−７０７．５は、“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルで1998年2月に発行されていて、これはＴＩＡ／ＥＩＡ ＩＳ−９５のシステムのパケットデータ伝送能力のサポート要件を規定し、ＢＳ／ＭＳＣ106を介してのＭＳ110とＩＷＦ108との間の通信に使用できるパケットデータ伝達サービスを指定している。さらに加えて、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルのＴＩＡ／ＥＩＡ ＩＳ−７０７−Ａ．５の標準規格と、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: HIGH-SPEED PACKET DATA SERVICES”というタイトルのＴＩＡ／ＥＩＡ ＩＳ−７０７−Ａ．９の標準規格とは、両者とも1999年3月に発行されており、これらもＴＩＡ／ＥＩＡ ＩＳ−９５のシステムのパケットデータ伝送のサポート要件を規定している。さらに加えて、ＭＳ110とＩＷＦ108との間の通信に対処している別の標準規格のプロトコルにはＴＩＡ／ＥＩＡ ＩＳ−２０００があり、これは“INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS”というタイトルで1999年7月に発行されている。

ＩＳ−７０７．５では、ＭＳ110とＢＳ／ＭＳＣ106（Ｕｍインターフェイス）との間およびＢＳ／ＭＳＣ106とＩＷＦ108（Ｌインターフェイス）との間の通信プロトコルのオプションモデルを取り入れている。例えば、中継モデルは、ポイント−ツウ−ポイントプロトコル（Point to Point Protocol, PPP）のリンクがＭＳ110とＩＷＦ108との間のＵｍインターフェイス上に存在している情況を表わしている。ＰＰＰプロトコルは、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ（ＲＦＣ １６６１）（“THE POINT-TO-POINT PROTOCOL (PPP)”）に詳しく記載されている。

（従来技術を示している）図２は、ＩＳ−７０７．５の中継モデルの各エンティティ内のプロトコルスタックの図である。図の左端には、従来の垂直形のフォーマットで示された通信プロトコルスタックが記載されており、これはＭＳ１１０上で実行されるプロトコル層を示している。ＭＳ110のプロトコルスタックは、Ｕｍインターフェイスを通してＢＳ／ＭＳＣ106のプロトコルスタックへ論理的に接続されているように示されている。また、ＭＳ／ＭＳＣ106のプロトコルスタックは、Ｌインターフェイスを通してＩＷＦ108のプロトコルスタックへ論理的に接続されているように示されている。

図２は次に記載する動作が行われることを示している。すなわち、ＭＳ110上で実行される上位層プロトコル200のエンティティ、例えばアプリケーションプログラムは、インターネットを通してデータを送る必要がある。代表的なアプリケーションには、ウエブブラウザプログラム（例えば、Netscape Navigator(ネットスケープナビゲータ)（商標）、Microsoft Internet explorer(マイクロソフトインターネットエクスプローラ)（商標））がある。ウエブブラウザには、ハイパーリンク“http://www.Qualcomm.com/”のようなユニバーサルリソースロケータ（Universal Resource Locator, URL）が必要である。同じく上位層プロトコル200内のドメイン名システム（Domain Name System (DNS)）プロトコルは
ドメイン名の分解（resolution）を使用して、名前をインターネットのアドレスへ変換することによって、テキストホスト名www.Qualcom.comを３２ビットの数字のＩＰアドレスへ変換する。同じく上位層プロトコル200であるハイパーテキスト転送プロトコル（Hypertext Transfer Protocol, HTTP）は、要求されているＵＲＬのためのＧＥＴメッセージを作成し、このメッセージを送るのに使用されるＴＣＰおよびＨＴＴＰの動作を指定する。トランスポート層202では、宛先ポートとして、この技術において使用されているポート８０を使用して、ＨＴＴＰの動作をアプリケーションへルート設定する。

ＴＣＰプロトコルは、トランスポート層プロトコル202であり、ＤＮＳによって指定されるＩＰアドレスとの接続を開き、アプリケーションレベルのＨＴＴＰのＧＥＴメッセージを送る。ＴＣＰプロトコルでは、ＩＰプロトコルを使用してメッセージを転送することを指定している。ＩＰプロトコルはネットワーク層プロトコル204であり、ＴＣＰパケットを指定されたＩＰアドレスへ送る。ＰＰＰはリンク層プロトコル206であり、ＩＰパケットをコード化し、それらを中継層プロトコル208へ送る。中継層プロトコル208は、例えば、ＴＩＡ／ＥＩＡ−２３２Ｆの標準規格であり、ＴＩＡ／ＥＩＡ−２３２Ｆの標準規格は“INTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGE”に規定されており、1997年10月に発行されている。層間の伝送を規定するのに、この技術において普通の技能をもつ技術者に知られている他の標準規格またはプロトコルを使用できることが分かるであろう。例えば、他の応用可能な標準規格には、1998年9月に発行された“UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1”と、1999年7月に発行された“BLUETOOTH（登録商標） SPECIFICATION VERSION 1.0A CORE”とが含まれる。最後に、ＰＰＰパケットは中継層プロトコル208から無線リンクプロトコル（Radio Link Protocol, RLP）210、次にＩＳ−９５プロトコル212を経由して、Ｕｍインターフェイスを通してＢＳ／ＭＳＣ106へ送られる。ＲＬＰプロトコル210はＩＳ−７０７．２の標準規格に規定されており、ＩＳ−７０７．２の標準規格は“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL”というタイトルで1998年2月に発行されていて、ＩＳ−９５プロトコルは上述で識別したＩＳ−９５の標準規格に規定されている。

ＰＰＰパケットはＵｍインターフェイスを通してＢＳ／ＭＳＣ106上のＩＳ−９５の層218、次にＲＬＰの層216へ送られ、相補的な中継層プロトコル220によって受信される。中継層プロトコル220は、このＰＰＰパケットをＬインターフェイスを通してＩＷＦ108上の中継層プロトコル228へ送る。ＩＷＦ108上のＰＰＰプロトコルリンク層226が中継層プロトコル228からＰＰＰパケットを受信すると、ＭＳ110とＩＷＦ108との間のＰＰＰ接続は終了する。パケットは、ＩＷＦ108上のＰＰＰ層226からＩＰ層224へ送られ、ＩＰ層224では最後のルート設定のためにＩＰパケットのヘッダ（このシナリオではwww.Qualcomm.comである）を調べる。

ＭＳ110によって生成されたＩＰパケットの最終的な宛先がＩＷＦ108ではないと仮定すると、パケットはネットワーク層プロトコル224、さらにリンク層プロトコル225を経由して、インターネット上の次のルータ（図示されていない）へ送られる。このやり方では、ＭＳ110からのＩＰパケットは、ＩＳ−７０７．５の標準規格の中継モデルにしたがって、ＢＳ／ＭＳＣ106、およびＩＷＦ108を経由して、インターネット内の最終的な意図された宛先へ伝達される。

ＭＳ110のパケットがその宛先へ到達する前に、先ずデータリンク接続が設定されなければならない。ＲＦＣ１６６１に指定されているように、このデータリンク接続では、先ずポイント−ツウ−ポイントリンクの各終端（すなわち、ＰＰＰプロトコル206および226）がＰＰＰリンク制御プロトコル（Link Control Protocol, LCP）へパケットを送って、データリンク接続を設定し、構成し、試験することが求められている。ＬＣＰによってリンクが設定された後で、ＰＰＰプロトコル206はネットワーク制御プロトコル（Network Control Protocol, NCP）のパケットを送って、ネットワーク層プロトコル204および224を構成する。ＰＰＰリンクにおけるＩＰのためのＮＣＰはＩＰ制御プロトコル（IP Control Protocol, IPCP）である。ＩＰＣＰは、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ １３３２（ＲＦＣ １３３２）に詳しく記載されており、ＲＦＣ １３３２は“THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)”というタイトルで1992年5月に発行されている。しかしながら、ＩＰＣＰのネゴシエーションの前には、認証段階が必要である。各ネットワーク層プロトコルが構成された後では、各ネットワーク層プロトコルからのパケットは、プロトコル間のリンクを通して送られる。

Ｂ．アプリケーションプログラムインターフェイス
ＭＳ110上の通信プロトコルスタックをサポートするプロセスは、その全てではないが、ほとんどがアプリケーションプログラムによって実行される。一般的に従来のデータネットワークでは、アプリケーションプログラムインターフェイス（application program interface, API）を採用して、あるコンピュータ上で実行されるアプリケーションプログラムと別のコンピュータ上で実行されるアプリケーションプログラムとの通信を可能にしている。ＡＰＩは“ソケット”を使用して、基礎ネットワークのプロトコルの相違によって、呼出しているアプリケーションを保護する。ネットワーク間の通信（inter-networked communication）を実現するために、ＡＰＩには、アプリケーションが、例えばソケットを開き、データをネットワークへ送り、ネットワークからデータを受信し、ソケットを閉じることを可能にする機能（function）が含まれている。通信ネットワークのプログラミングインターフェイスには、UNIX（登録商標）(ユニックス)(商標)のオペレーティングシステムのもとで動作するバークレイシステム開発（Berkeley System Development, BSD）のソケットインターフェイス、およびWindows（登録商標）（ウインドウズ）のオペレーティングシステムのもとで動作するWindows（登録商標）（ウインドウズ）Sockets Interface（ソケットインターフェイス） (WinSock（ウインソック）(登録商標))が含まれる。

ＢＳＤソケットもWinSock（ウインソック）（登録商標）の何れも無線ＭＳ110上の通信プロトコルスタック（図２参照）をサポートしていないので、このようなスタックをサポートする斬新なＡＰＩが必要である。とくに、無線通信システムにおいて移動局のアプリケーションが生のパケット化されたデータを受信および送信するための斬新な方法および装置が必要とされている。

本発明では、移動局のアプリケーションが無線通信システムにおいて生のパケット化されたデータを受信および送信するための方法および装置を提供することによって、上述で識別した必要に対処している。１つの構成では、移動局のアプリケーションは少なくとも１つのソケットを生成する。移動局のプロトコル層の少なくとも１つは、宛先ポートの情報を欠いているカプセル化された生のパケット化されたデータを通信ネットワークから受信する。移動局のプロトコル層の少なくとも１つは、逆カプセル化された生のパケット化されたデータを少なくとも1つのソケットへ送る。そして今度は、少なくとも1つのソケットが生のパケット化されたデータを移動局のアプリケーションへ送る。別の構成では、少なくとも１つのソケットは、移動局のアプリケーションの生のパケット化されたデータを、移動局のプロトコル層の少なくとも１つへ送る。そして今度は、移動局のプロトコル層の少なくとも１つが、カプセル化された生のパケット化されたデータを通信ネットワークへ送る。

（従来技術において）移動局がインターネットに接続している無線通信システムの高レベルのブロック図。 （従来技術において）ＴＩＡ／ＥＩＡ ＩＳ−７０７．５の中継モデルの各エンティティにおけるプロトコルスタックを模式的に示す図。 本発明の実施形態の特徴を模式的に示す図。 指定されたイベントを検出するフローチャート。 指定されたイベントを検出するフローチャート。 非同期接続を示すブロック図。 非同期ソケット入力を示すブロック図。 本発明の実施形態の状態図。 本発明の実施形態の状態図。 本発明の実施形態の状態図。

発明を実施するための態様

本発明の実施形態は、ソフトウエア、ファームウエア、および／またはハードウエアを含む種々の構成において実現することができる。したがって、本発明の動作および働き（behavior）はソフトウエアコードまたはハードウエアの構成要素をとくに参照せずに記載されているが、この技術において普通の技能をもつ人には、本明細書の記述に基づいて、本発明を構成するソフトウエアまたはハードウエア、あるいはこの両者を設計でき、これにより移動局のアプリケーションが生のパケット化されたデータを受信および送信できることが分かるであろう。

図３には、ＭＳ110内のアプリケーション260、通信プロトコルスタック280、およびＡＰＩ270が示されている。アプリケーション260および通信プロトコルスタック280（すなわち、プロトコル層202、204、206、208、210、212）は、ＡＰＩ270によって与えられる機能呼出し（function call）によって通信する。言い換えると、ＡＰＩ270は、アプリケーション260および通信プロトコルスタック280を機能を損わずに異なるプロセッサおよびオペレーティングシステム上で実行できるようにする。当業者には、本発明の技術的範囲から逸脱することなく、呼出された機能に対して種々の名前が可能であることが分かるであろう。

通信プロトコルスタック280には、複数の送信待ち行列と受信待ち行列とが含まれていて、これらの待ち行列はデータを記憶することに注意すべきである。出力機能では、アプリケーション260のメモリからデータを読出し、そのデータを通信プロトコルスタック280の送信待ち行列の1つへ記憶する。入力機能では、通信プロトコルスタック280の受信待ち行列の１つからデータを読出し、そのデータをアプリケーション260のメモリへ記憶する。

動作を示すために、ＭＳ110はＩＰパケットを受信する。ＭＳ110の通信プロトコルスタック280は、ＩＰパケットを逆カプセル化して（unencapsulate）、それらをトランスポート層202へ送る（図３参照）。ＩＰパケットヘッダ内の１つのフィールドはトランスポートを示していて、ＴＣＰまたはＵＤＰの何れかでを含む。トランスポート層のヘッダにおいて指定されている宛先ポートの番号に基づいて、データは、特定のソケットに対応する通信プロトコルスタック280の適切な受信待ち行列へルート設定される。次にデータは、アプリケーション260へ送られる。

一定の情況では、プロトコルスタック280の種々の層をバイパスするパケットを使用して動作して、待ち時間の影響を軽減することが望ましい。このようなパケットには、生のＩＰパケットのような生のパケット化されたデータが含まれているが、これには宛先の情報（すなわち、宛先ポートの番号）が欠けている。したがって、宛先のアプリケーションは、生のＩＰパケットから判断できない。このような情況では、通信プロトコルスタック280は受信した生のＩＰパケットを、例えばＩＰプロトコルをサポートするために登録されている全てのソケットへ送る。このようにしてペイロードデータは宛先のアプリケーションへ送られる。インターネット制御メッセージングプロトコル（Internet Control Messaging Protocol, ICMP）のパーシングエンジンはＩＰパケットに応答して、生のパケット化されたデータも受信することができる。周知のＩＣＭＰのパーシングエンジンは、“INTERNET CONTROL MESSAGE PROTOCOL”というタイトルでＲＦＣ ７９２に規定されている。したがって、通信プロトコルスタック280は、受信したパケットを処理し、その後でパケットをスタックを逆上ってアプリケーション260へ送り、アプリケーション260が逆カプセル化する量を低減することが明らかである。

逆に、アプリケーション260は、ソケットを使用することによって生のパケット化されたデータをＵｍインターフェイスを通して送り、通信プロトコルスタック280とアプリケーション260との間の通信を容易にすることもできる。さらに、アプリケーション260は、生のパケット化されたデータをＵｍインターフェイスを通して送ることもできる。また、通信プロトコルスタック280は、例えばパケット化された、または生のパケット化されたデータをＩＰパケットへカプセル化し、それらをＵｍインターフェイスを通して送る。この例では、通信プロトコルスタック280はＩＰヘッダおよびチェックサムを用意して、ＩＰパケットを生成する。他方で、ＩＣＭＰでは、指定されたプロトコルのタイプはＩＰヘッダへコピーされる。

既に記載したように、アプリケーション260はソケットを生成し、ソケットはプロトコル層202、204、206、208、210、212の少なくとも１つとアプリケーション260との間のデータ通信が、通信プロトコルスタック280を使用するときに必ず伴う待ち時間を低減できるようにする。したがってアプリケーション260はソケットを生成し、ソケットはトランスポート層202、ネットワーク層204、およびリンク層206をバイパスして、アプリケーション260がＲＬＰ層210との間でペイロードデータを送受信できるようにする。さらに加えて、アプリケーション260はソケットを生成し、ソケットはアプリケーション260がＩＳ−９５の層212との間でペイロードデータを送受信できるようにする。

１つの実施形態では、アプリケーション260は機能open netlib()を呼出して、通信プロトコルスタック280を開き、アプリケーションの識別を割り当てる。アプリケーションを識別すると、多数のアプリケーションが通信プロトコルスタック280と通信すること（すなわち、マルチタスキング）ができる。例えば、機能open netlib（）の呼出しの一部として、アプリケーション260はネットワークコールバック機能およびソケットコールバック機能へのポインタを指定する。トラヒックチャンネル（すなわち、Ｕｍ）またはリンク層（すなわち、ＰＰＰ206）、あるいはこの両者から読出し、そこへ書込み、それを閉じるといった、ネットワークサブシステムの指定されたイベントが生成される（または、イネーブルされる）たびに、ネットワークコールバック機能が呼出されて、アプリケーション260に知らせる。トランスポート層（すなわち、ＴＣＰ）から読出し、そこへ書込み、それを閉じるといったソケットの指定されたイベントが生成される（または、イネーブルされる）たびに、ソケットコールバック機能が呼出され、アプリケーション260へ知らされる。通信ネットワークがトラヒックチャンネル、リンク層、およびトランスポート層の少なくとも１つを含むことは、当業者には明らかである。

通信プロトコルスタック280が開かれると、機能pppopen()が呼出され、トラヒックチャンネルおよびリンク層を含むネットワークサブシステムの接続を開始する。これはアプリケーション全体の呼であり、個々のソケットに依存していない。しかしながら、これはアプリケーションの識別を必要とする。ネットワークサブシステムの接続が設定されるか、またはそれが故障すると、ネットワークコールバック機能が呼出されて、指定されたイベントが通知される。例えば、トラヒックチャンネルが設定されていないときは、ネットワークサブシステムは故障する。さらに加えて、ネットワークサブシステムの特徴は、機能net ioctl()を呼出すことによって設定される。この呼出しは、例えば、ソケットのデータレートを指定する。

ネットワークサブシステムの接続が設定されると、機能socket（）を呼出すことによって、ソケットが生成されて初期設定される。しかしながら、ソケットの機能が使用できる前に、機能socket（）を呼出して、ソケット記述子を戻してもよい。次に、アプリケーション260は機能async select()を呼出して、指定されたイベントを登録し、非同期の通知を受信する。この登録は、アプリケーション260によって機能呼出しの一部として実行され、指定されたイベントの要求する通知のソケット記述子およびビットマスクを指定する（すなわち、多数のイベントの論理和がとられる）。指定されたイベントが生成され（すなわち、イネーブルされ）、それが、例えば通信プロトコルスタック280またはＡＰＩ270によって検出されると、ソケットコールバック機能が呼出されて、非同期の通知を与える。コールバック機能では、信号、メッセージ、例えば遠隔手続き呼出し（remote procedure call, RPC）についてのメッセージ、あるいはハードウエアまたはソフトウエアの割込みを使用することによって、指定されたイベントのアプリケーション260を通知することができる。

アプリケーション260は、指定されたイベントについて通知されると、機能getnextevent()を呼出して、指定されたイベントを判断してサービスする。この機能は、生成された指定されたイベントのマスクを指定されたソケット記述子へ戻す。さらに加えて、この機能は、生成された指定されたイベントのマスク内のビットをクリアする。したがって、アプリケーション260は、ディスエーブルされた指定されたイベントの通知を最早受信できない。アプリケーション260は、次に機能async select()を呼出すことによって、これらの指定されたイベントを再登録（すなわち、再イネーブル）しなければならない。

さらに加えて、アプリケーション260は、指定されたイベントのビットマスク内の対応するビットをクリアすることによって、登録された指定されたイベントを変更する。ビットマスク内でビットが既にクリアされているときは、要求は単に無視される。簡潔に言えば、イベントの通知は、例えば機能async deselect()を呼出すことによって、イベントごとにディスエーブルされる。

図４および５は、指定されたイベントを検出するフローチャートである。図４に示したように、例えばブロック400では、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。指定されたイベントが登録されると、ブロック402では、通信プロトコルスタック280はメモリをポーリングする。ブロック404では、ブロック402のポーリングされた情報に基づいて、指定されたイベントが検出される。ブロック406では、例えば通信プロトコルスタック280のメモリ（すなわち、送信待ち行列）が十分な量のデータを受け付けるのに使用可能であるときは、書込みイベントが検出される。データはアプリケーション260から送られる。ブロック404においてポーリングされた情報が十分でない（すなわち、指定されたイベントが生成されなかった）ときは、通信プロトコルスタック280は、ブロック402のように、メモリをポーリングし続ける。

図５では、ブロック500に示したように、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。この時間の間は、割込み通知はディスエーブルされる。したがって、割込み通知はトリガすることも、トリガされることもできない。ブロック500において指定されたイベントが登録された後で、ブロック502において、指定されたイベントが生成されたことに基づいて、割込み通知がトリガされる。例えば、データが通信プロトコルスタック280（すなわち、受信待ち行列）のメモリへ書込まれるとき、読出しイベントが生成される。したがって、ブロック504では、イベントの生成によってトリガされた割込み通知を通信プロトコルスタック280が受信するとき、通信プロトコルスタック280は読出しイベントを検出する。通信プロトコルスタック280のメモリ内に記憶されるデータは、通信ネットワークから送られる。さらに、読出しイベントにおいて記憶されるデータは、アプリケーション260へ送られる。

最後に、ソケットが再使用に利用できるとき、トランスポート層のようにデータリンク接続は終了しているので、閉鎖イベントが検出される。

次に示す非同期接続（図６参照）および非同期入力（図７参照）の例では、非
同期のイベントの通知の使用を示す。

図６を参照すると、機能open netlib()を呼出すことによって、通信プロトコルスタック280へ入り、かつコールバック機能が指定される。機能pppopen()を呼出すと（Ａ）、ネットワークサブシステムの接続が始まる（Ｂ）。ネットワークサブシステムの接続が設定された後で、コールバック機能が呼出され（Ｃ）、ネットワークサブシステムが使用可能であることが報告される。

ソケットが開かれて、割り当てられていると仮定すると、機能connect()を呼出して（Ｄ）、ＴＣＰ接続が始まる（Ｅ）。さらに、アプリケーション260は機能async select()を呼出すと（Ｆ）、指定されたイベントを登録して、通知を受信する。この例では、目的の指定されたイベントは書込みイベントであり、書込みイベントは接続を設定するときに生成される。

接続を設定する際に、指定されたイベントがマスク内に登録されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され（Ｇ）、非同期の通知が与えられる。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し（Ｈ）、生成された何れかの指定されたイベントを判断する（Ｉ）。さらに加えて、この呼はマスク内のイベント（すなわち、書込みイベント）のビットをクリアする（Ｊ）。アプリケーション260は、機能async select()を呼出すことによって、指定されたイベントの次の通知を再登録しなければならない。

図７には、非同期のソケットの読出しが示されている。読出しを開始するために、アプリケーション260は機能read()を呼出す（Ａ）。読出すデータがないとみなされると、アプリケーション260は機能async select()を呼出し（Ｂ）、イベントを登録し（すなわち、マスク内の対応するビットを設定し）、通知を受信する。この例では、目的の指定されたイベントは読出しイベントであり、読出しイベントは、アプリケーション260によって読出されるデータがあるときに生成される。

受信待ち行列内にデータを記憶する際に、読出しイベントがマスク内で指定されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され（Ｃ）、非同期の通知を与える。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し（Ｄ）、何れのイベントが生成されるかを判断する（Ｅ）。さらに加えて、この呼出しは、マスク内のイベントのビットをクリアする（Ｆ）。アプリケーション260は、機能async select()を呼出すことによって、イベントの次の通知を再びイネーブルしなければならない。最後に、受信待ち行列内に記憶されたデータを読出すために、アプリケーション260は機能read()を呼出す（Ｇ）。

図８ないし１０には、本発明の実施形態の状態機械が示されている。図８ないし１０では、通信プロトコルスタック280は開いていて、ネットワークサブシステムの接続（すなわち、トラヒックチャンネル、および必要であればリンク層の接続−生のソケットはネットワークサブシステムをバイパスする）が設定されると仮定されている。当業者には、本発明の技術的範囲から逸脱することなく、状態に対する種々の名前が可能であることが分かるであろう。

状態機械は、状態間を非同期で遷移でき、読取り、書込み、および閉鎖といった指定されたイベントを制御する（すなわち、イネーブルおよびディスエーブルする）。指定されたイベントは動作の開始時にはディスエーブルされていて、所定の状態でイネーブルされ、アプリケーション260がＭＳ110の状態を識別するのを助ける。

さらに加えて、ＡＰＩ270は、ＡＰＩ270の状態およびアプリケーション260によって呼出される機能のタイプに基づいて、特定の（すなわち、単に一般的でない）指定された状況メッセージをアプリケーション260へ報告する。指定された状況メッセージは、基礎の通信ネットワークの状態を反映する。状況メッセージは、例えば機能呼出しの立証（argument）としてアプリケーション260へ報告される。

図８には、例えばＡＰＩ270のＴＣＰソケットの状態図が示されている。初期設定されていないソケットは、“ナル”状態800で始まる。ソケットは、このときはまだ割り当てられていないので、“存在”しない。ソケットは、機能socket()を呼出すことによって生成されて初期設定され、ソケット記述子を戻して、ソケットに関係する機能を使用する。機能socket()を呼出した後で、状態機械は“初期設定”状態805へ遷移する。

初期設定状態805では、状態機械は、機能close()を呼出すことによってＴＣＰ接続が終了可能になるたびに、ナル状態800へ再び遷移する。機能close()を呼出すと、全てのソケットに関係する資源が解放される。他方で、機能connect()を呼出すと、ＴＣＰ接続が開始され、状態機械は“オープニング”状態810へ遷移する。

オープニング状態810では、（１）ネットワークサブシステムが故障したとき、（２）ＴＣＰ接続の設定に失敗したとき、または（３）ＩＰアドレスを変更したときは、そのたびに状態機械は“クローズド”状態815へ遷移する。さらに加えて、ＴＣＰ接続を終了する機能close()を呼出した後に、状態機械はソケットを“クロージング”状態820へ遷移し、一方では終了手続きが開始される。最後に、ＴＣＰ接続が設定されたときは、状態機械は“オープン”状態825へ遷移する。

オープン状態825では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ぐにイネーブルされ、読出しイベントは、通信プロトコルスタック280のメモリへデータが記憶されるかどうかに基づいてイネーブルされる。（１）ネットワークサブシステムが故障したとき、（２）ＴＣＰ接続を設定するのに失敗したとき、（３）ＴＣＰのリセット、ＴＣＰのアボート、またはＴＣＰの閉鎖のようなＴＣＰ接続を終了する試みをネットワークサーバが開始したとき、および（４）ＩＰアドレスが変更されたときは、そのたびに状態機械はクローズド状態815に遷移する。例えば機能close()を呼出すことによって、アプリケーションがＴＣＰ接続の終了を開始すると、状態機械はクロージング状態820へ遷移する。

クローズド状態815では、読出し、書込み、および閉鎖イベントは全てアサートされる。ＴＣＰ接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態800へ遷移し、ソケットを解放し、それを再使用に利用できるようにする。

クロージング状態820では、（１）ネットワークサブシステムが故障したとき、（２）ネットワークサーバが、例えばＴＣＰのリセットまたはＴＣＰの閉鎖のようなＴＣＰ接続の終了の試みを開始したとき、（３）タイマの時限が切れたとき、および（４）ＩＰアドレスを変更したときは、そのたびに状態機械は“閉鎖待機”の状態830へ遷移する。ＴＣＰ接続を終了するときに遅延するのを防ぐために、ＡＰＩ270は、ＴＣＰ接続の終了を開始するときに作動するタイマを含んでいる。タイマの時限が切れると、状態機械は閉鎖待機の状態830に遷移することが分かるであろう。

閉鎖待機の状態830では、機能close()を呼出して、ＴＣＰ接続を終了し、状態機械をナル状態800へ遷移する。閉鎖イベントは、この状態830でアサートされる。

表１−３は、ＡＰＩ270によってサポートされる指定された状況メッセージを示している。（表１ないし３には示されていない）ナル状態では、記述的な指定された状況メッセージ、すなわち“追加の資源は使用できない（no additional resources are available）”が、アプリケーション260へ報告される。

例として、図９はＡＰＩ270のＵＤＰソケットの状態図を示している。初期設定されていないソケットは“ナル”状態900で始まる。ナル状態800に関して既に記載したように、ソケットは、割り当てられていないので“存在”しない。ソケットは、機能socket()を呼出すことによって生成および初期設定され、ソケットに関係する機能で使用するためにソケットの記述子を戻す。機能socket()を呼出した後で、状態機械は“オープン”状態905へ遷移する。

オープン状態905では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ちにイネーブルされ、一方で読出しイベントはデータが通信プロトコルスタック280のメモリへ記憶されるかどうかに基づいてイネーブルされる。状態機械は、ネットワークサブシステムが故障するたびに“クローズド”状態910へ遷移する。例えば機能close()を呼出すことによって、アプリケーションはＵＤＰ接続の終了を開始して、状態機械をナル状態900へ遷移する。

クローズド状態910では、読出し、書込み、および閉鎖の状態は全てイネーブルされる。ＵＤＰ接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態900へ遷移し、ソケットを解放し、再使用に利用できるようにする。

表４ないし６は、ＡＰＩ270によってサポートされる指定された状況メッセージを示している。（表４ないし６には示されていない）ナル状態では、既出の指定された状況メッセージである“追加の資源は使用できない（no additional resources are available）”が、アプリケーション260へ報告される。

図１０は、トラヒックチャンネル（すなわち、Ｕｍ）およびリンク層（すなわち、ＰＰＰ206）のようなネットワークサブシステムを制御する状態図を示している。機能open netlib()を呼出すことによって、ネットワークサブシステムを開き、“クローズド”状態1000へソケットを初期設定する。機能pppopen()を呼出すことにより、ネットワークサブシステムの接続を開始し、ソケットを“オープニング”状態1005へ遷移する。さらに加えて、到来するＰＰＰ呼出しによるＭＳ110へのページは、ソケットをオープニング状態1005へ遷移する。両者の場合において、ネゴシエーションが成功するときは、ＭＳ110はトラヒックチャンネルにおいてＲＬＰおよびＰＰＰの両者を同期させて設定することを試みる。

オープニング状態1005では、ネットワークサブシステムの接続が設定されたときに、ソケットは“オープン”状態1010へ遷移する。他方では、ネットワークサブシステムの接続が設定されていないときは、ソケットはクローズド状態1000へ再び遷移する。

オープン状態1010では、コールバック機能が呼出されて、イネーブルされた読出し、書込み、および閉鎖のようなアプリケーション1060の指定されたイベントを識別する。このとき、ＭＳ110はトラヒックチャンネルによって通信することができる。しかしながらソケットは、ネットワークサブシステムが故障し、コールバック機能を呼出すたびに、クローズド状態1000へ遷移する。例えば機能close()を呼出すことによって、アプリケーションは、ネットワークサブシステムの接続の終了を開始し、ソケットを“クロージング”状態1015へ遷移する。

クロージング状態1015では、ネットワークサブシステムの接続が終了するたびに、ソケットはクローズド状態1000へ遷移する。クローズド状態1000では、コールバック機能を呼出して、イネーブルされたアプリケーション260の指定されたイベントを識別する。

表７は、特定の機能呼出しに対応し、かつＡＰＩ270によってサポートされる指定された状況メッセージを示している。

別の実施形態では、機械は、コード化されたソフトウエアコードのようなコード化された情報を含む機械読出し可能媒体を読出して、移動局のアプリケーションが生のパケット化されたデータを受信および送信できるようにする上述のプロセスを行う。機械読出し可能媒体は、メモリまたは記憶ディスクのような記憶デバイスから、あるいは通信ネットワークから、コード化された情報を受取る。さらに加えて、機械読出し可能媒体は、製造されたときに、コード化された情報でプログラムされる。機械は、アプリケーション260、通信プロトコルスタック280、およびＡＰＩ270の少なくとも１つを含み、一方で機械の読出し媒体はメモリまたは記憶ディスクを含む。

本発明は特定の実施形態に関連して示したが、そのように制限されているわけではないと考えられる。むしろ、本発明は特許請求の範囲およびそれに相当するものの技術的範囲のみによって制限される。

Claims (27)

1. 移動局のアプリケーションが生のパケット化されたデータを受信するための方法であって、
   移動局のアプリケーションによって、少なくとも1つのソケットを生成することと、
   複数の移動局のプロトコル層の少なくとも１つによって、宛先ポートの情報を欠いているカプセル化された生のパケット化されたデータを、通信ネットワークから受信することと、
   移動局のプロトコル層の少なくとも１つによって、逆カプセル化された生のパケット化されたデータを少なくとも1つのソケットへ送ることと、
   少なくとも1つのソケットによって、生のパケット化されたデータを移動局のアプリケーションへ送ることとを含む方法。
2. 生のパケット化されたデータをインターネット制御メッセージングプロトコルのパーシングエンジンへ送ることをさらに含む請求項１記載の方法。
3. 生のパケット化されたデータが、生のＩＰパケットを含む請求項１記載の方法。
4. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項１記載の方法。
5. 複数の移動局のプロトコル層が、移動局の通信プロトコルスタックを含む請求項１記載の方法。
6. 移動局のアプリケーションが生のパケット化されたデータを受信する装置であって、装置が、
   少なくとも1つのソケットを生成するための移動局のアプリケーションと、
   複数の移動局のプロトコル層とを含んでいて、
   移動局のプロトコル層の少なくとも１つが、宛先ポートの情報を欠いているカプセル化された生のパケット化されたデータを、通信ネットワークから受信するようにされていて、
   移動局のプロトコル層の少なくとも１つが、逆カプセル化された生のパケット化されたデータを少なくとも1つのソケットへ送るようにされていて、かつ、
   少なくとも１つのソケットが、生のパケット化されたデータを移動局のアプリケーションへ送るようにされている装置。
7. 少なくとも１つのソケットが、生のパケット化されたデータをインターネット制御メッセージングプロトコルのパーシングエンジンへ送るようにされている請求項６記載の装置。
8. 生のパケット化されたデータが生のＩＰパケットを含む請求項６記載の装置。
9. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項６記載の装置。
10. 複数の移動局のプロトコル層が、移動局の通信プロトコルスタックを含む請求項６記載の装置。
11. コード化された情報を含む機械読出し可能媒体であって、機械によって読出されたときに、
    移動局のアプリケーションによって、少なくとも１つのソケットを生成するプロセスと、
    複数の移動局のプロトコル層の少なくとも１つによって、宛先ポートの情報を欠いているカプセル化された生のパケット化されたデータを、通信ネットワークから受信するプロセスと、
    移動局のプロトコル層の少なくとも１つによって、逆カプセル化された生のパケット化されたデータを少なくとも１つのソケットへ送るプロセスと、
    少なくとも１つのソケットによって、生のパケット化されたデータを移動局のアプリケーションへ送るプロセスとを行なう機械読出し可能媒体。
12. 生のパケット化されたデータを、インターネット制御メッセージングプロトコルのパーシングエンジンへ送ることをさらに含む請求項１１記載の機械読出し可能媒体。
13. 生のパケット化されたデータが、生のＩＰパケットを含む
    請求項１１記載の機械読出し可能媒体。
14. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項１１記載の機械読出し可能媒体。
15. 複数の移動局のプロトコル層が、移動局の通信プロトコルスタックを含む請求項１１記載の機械読出し可能媒体。
16. 移動局のアプリケーションが生のパケット化されたデータを送るための方法であって、
    移動局のアプリケーションによって、少なくとも1つのソケットを生成することと、
    少なくとも1つのソケットによって、移動局のアプリケーションの生のパケット化されたデータを、複数の移動局のプロトコル層の少なくとも１つへ送ることと、
    複数の移動局のプロトコル層の少なくとも１つによって、カプセル化された生のパケット化されたデータを通信ネットワークへ送ることとを含む方法。
17. 生のパケット化されたデータが、生のＩＰパケットを含む請求項１６記載の方法。
18. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項１６記載の方法。
19. 複数の移動局のプロトコル層が移動局の通信プロトコルスタックを含む請求項１６記載の方法。
20. 移動局のアプリケーションが生のパケット化されたデータを送るための装置であって、装置が、
    少なくとも１つのソケットを生成するための移動局のアプリケーションと、
    複数の移動局のプロトコル層とを含み、
    少なくとも１つのソケットが、移動局のアプリケーションの生のパケット化されたデータを、移動局のプロトコル層の少なくとも1つへ送るようにされていて、かつ、
    移動局のプロトコル層の少なくとも１つが、カプセル化された生のパケット化されたデータを通信ネットワークへ送るようにされている装置。
21. 生のパケット化されたデータが、生のＩＰパケットを含む請求項２０記載の装置。
22. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項２０記載の装置。
23. 複数の移動局のプロトコル層が、移動局の通信プロトコルスタックを含む請求項２０記載の装置。
24. コード化された情報を含む機械読出し可能媒体であって、機械によって読出されたときに、
    移動局のアプリケーションによって、少なくとも１つのソケットを生成するプロセスと、
    少なくとも１つのソケットによって、移動局のアプリケーションの生のパケット化されたデータを、複数の移動局のプロトコル層の少なくとも１つへ送るプロセスと、
    複数の移動局のプロトコル層の少なくとも1つによって、カプセル化された生のパケット化されたデータを通信ネットワークへ送るプロセスとを行なう機械読出し可能媒体。
25. 生のパケット化されたデータが、生のＩＰパケットを含む請求項２４記載の機械読出し可能媒体。
26. 複数の移動局のプロトコル層が、移動局の無線リンクプロトコル層および移動局のＩＳ−９５のプロトコル層の少なくとも一方を含む請求項２４記載の機械読出し可能媒体。
27. 複数の移動局のプロトコル層が、移動局の通信プロトコルスタックを含む請求項２４記載の機械読出し可能媒体。

Images