JP2004500785A

JP2004500785A - Method and apparatus for a mobile station application to identify a specified status message

Info

Publication number: JP2004500785A
Application number: JP2001573821A
Authority: JP
Inventors: アブロール、ニシャール; ギルキー、ハロルド
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2000-03-30
Filing date: 2001-03-29
Publication date: 2004-01-08
Also published as: KR20040007214A; EP1273150A2; CA2403813A1; CN1620157A; WO2001076279A2; IL151707A0; AU2001251106A1; WO2001076279A3; CN1449614A; MXPA02009507A

Abstract

本発明は、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置を記載している。本発明はアプリケーションプログラムインターフェイス（ａｐｐｌｉｃａｔｉｏｎｐｒｏｇｒａｍｉｎｔｅｒｆａｃｅ，ＡＰＩ）を含み、ＡＰＩは通信ネットワークと通信する移動局の通信プロトコルのスタックと、移動局のアプリケーションとの間の通信を容易にする。移動局のアプリケーションは機能を呼出す。ＡＰＩは、指定された状況メッセージの少なくとも１つを、その状態および呼出された機能に基づいて選択する。次にＡＰＩは、選択した指定された状況メッセージを移動局のアプリケーションへ報告する。
【選択図】図３The present invention describes a method and apparatus for a mobile station application identifying a specified status message in a wireless communication system. The present invention includes an application program interface (API), which facilitates communication between a mobile station's communication protocol stack and a mobile station's application for communicating with a communication network. The mobile station application calls the function. The API selects at least one of the specified status messages based on its status and the function invoked. The API then reports the selected designated status message to the mobile station application.
[Selection diagram] FIG.

Description

【０００１】
背景
１．発明の分野
本発明は、概ね、無線通信の分野に関する。とくに、本発明は無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別できるようにする斬新な方法および装置に関する。
【０００２】
２．関係する技術の記述
Ａ．無線通信
無線通信およびコンピュータに関係する技術における最近の革新、並びにインターネット加入者の今までにない増加によって、モバイルコンピューティングへの道が開かれた。事実、モバイルコンピューティングの大衆性により、現在のインターネットのインフラストラクチャに対して、モバイルのユーザにより多くのサポートを与える要求が強まった。このインフラストラクチャの原動力は、種々のサービスを提供するパケット指向のインターネットプロトコル（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ，ＩＰ）であり、種々のサービスには、パケット（データグラム）をローカルエリアネットワーク（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ，ＬＡＮ）とワイドエリアネットワーク（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋ，ＷＡＮ）との間でアドレス指定してルート設定するサービスが含まれる。ＩＰプロトコルは、ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔ（ＲＦＣ７９１）（“ＩＮＴＥＲＮＥＴＰＲＯＴＯＣＯＬＤＡＲＰＡＩＮＴＥＲＮＥＴＰＲＯＧＲＡＭＰＲＯＴＯＣＯＬＳＰＥＣＩＦＩＣＡＴＩＯＮ”，１９８１９）において規定されている。
【０００３】
ＩＰプロトコルは、送信のためにデータをＩＰパケットへカプセル化するネットワーク層プロトコルである。アドレス指定およびルート設定の情報はパケットのヘッダに付される。ＩＰヘッダには、例えば送信ホストおよび受信ホストを識別する３２ビットのアドレスが含まれている。中間のルータはこれらのアドレスを使用して、パケットを、意図されたアドレスをもつその最終的な宛先へ向わせるためのネットワーク上の経路を選択する。したがって、ＩＰプロトコルにより、世界中の何れかのインターネットノードにおいて発信されたパケットを、世界中の他の何れかのインターネットノードへルート設定することができる。これに対して、特定のアプリケーションに対処するためには、伝送制御プロトコル（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ，ＴＣＰ）またはユーザデータグラムプロトコル（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ，ＵＤＰ）の何れかを含むトランスポート層が使用される。
【０００４】
現在の傾向では、モバイルのユーザはラップトップまたはパームトップコンピュータのようなモバイルコンピュータを、セルラまたは携帯電話のような無線通信デバイスと共に使用して、インターネットにアクセスしている。したがって、ちょうど、従来からユーザが“有線の”通信デバイスを使用してコンピュータを陸上ネットワーク（ｌａｎｄ−ｂａｓｅｄｎｅｔｗｏｒｋ）へ接続していたように、モバイルのユーザは一般的に“移動局”（ｍｏｂｉｌｅｓｔａｔｉｏｎ，ＭＳ）と呼ばれる無線通信デバイスを使用してモバイル端末をこのようなネットワークへ接続する。本明細書で使用しているように、移動局またはＭＳは、公共の無線ラジオネットワーク（ｗｉｒｅｌｅｓｓｒａｄｉｏｎｅｔｗｏｒｋ）の加入者局を指す。
【０００５】
（従来技術を示している）図１は、無線データ通信システムの高レベルのブロック図を示しており、この中でＭＳ１１０は基地局／移動局スイッチングセンタ（ＢａｓｅＳｔａｔｉｏｎ／ＭｏｂｉｌｅＳｗｉｔｃｈｉｎｇＣｅｎｔｅｒ，ＢＳ／ＭＳＣ）１０６を介して相互接続機能（ＩｎｔｅｒｗｏｒｋｉｎｇＦｕｎｃｔｉｏｎ，ＩＷＦ）１０８と通信する。ＩＷＦ１０８は、インターネットへのアクセス点として働く。ＩＷＦ１０８はＢＳ／ＭＳＣ１０６に接続されていて、一緒に位置していることも多く、ＢＳ／ＭＳＣ１０６はこの技術において知られているように従来の無線基地局であってもよい。無線データ通信システムに対処する別の標準プロトコルは、“ＷＩＲＥＬＥＳＳＩＰＮＥＴＷＯＲＫＳＴＡＮＤＡＲＤ”というタイトルで１９９９年１２月に発行された第３世代パートナーシッププロジェクト２（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ２， “３ＧＰＰ２”）である。３Ｇ無線ＩＰネットワークの標準規格には、例えば、ＩＷＦ１０８のように機能するパケットデータ供給ノード（ＰａｃｋｅｔＤａｔａＳｅｒｖｉｎｇＮｏｄｅ，ＰＤＳＮ）が含まれる。
【０００６】
種々のプロトコルが、ＭＳ１１０とＩＷＦ１０８との間のデータ通信に対処している。例えば、米国電気通信工業会（ＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＩｎｄｕｓｔｒｙＡｓｓｏｃｉａｔｉｏｎ，ＴＩＡ）／電子機械工業会（ＥｌｅｃｔｒｏｎｉｃｓＩｎｄｕｓｔｒｉｅｓＡｓｓｏｃｉａｔｉｏｎ，ＥＩＡ）の暫定的標準規格（ＩｎｔｅｒｉｍＳｔａｎｄａｒｄ）のＩＳ−９５は、“ＭＯＢＩＬＥＳＴＡＴＩＯＮ−ＢＡＳＥＳＴＡＴＩＯＮＣＯＭＰＡＴＩＢＩＬＩＴＹＳＴＡＮＤＡＲＤＦＯＲＤＵＡＬ−ＭＯＤＥＷＩＤＥＢＡＮＤＳＰＲＥＡＤＳＰＥＣＴＲＵＭＣＥＬＬＵＬＡＲＳＹＳＴＥＭ”というタイトルで１９９３年７月に発行されていて、これは概して広帯域拡散スペクトル無線通信システムの標準規格を与えている。さらに加えて、標準規格のＴＩＡ／ＥＩＡＩＳ−７０７．５は、“ＤＡＴＡＳＥＲＶＩＣＥＯＰＴＩＯＮＳＦＯＲＷＩＤＥＢＡＮＤＳＰＲＥＡＤＳＰＥＣＴＲＵＭＳＹＳＴＥＭＳ：ＰＡＣＫＥＴＤＡＴＡＳＥＲＶＩＣＥＳ”というタイトルで１９９８年２月に発行されていて、これはＴＩＡ／ＥＩＡＩＳ−９５のシステムのパケットデータ伝送能力のサポート要件を規定し、ＢＳ／ＭＳＣ１０６を介してのＭＳ１１０とＩＷＦ１０８との間の通信に使用できるパケットデータ伝達サービスを指定している。さらに加えて、“ＤＡＴＡＳＥＲＶＩＣＥＯＰＴＩＯＮＳＦＯＲＳＰＲＥＡＤＳＰＥＣＴＲＵＭＳＹＳＴＥＭＳ：ＰＡＣＫＥＴＤＡＴＡＳＥＲＶＩＣＥＳ”というタイトルのＴＩＡ／ＥＩＡＩＳ−７０７−Ａ．５の標準規格と、“ＤＡＴＡＳＥＲＶＩＣＥＯＰＴＩＯＮＳＦＯＲＳＰＲＥＡＤＳＰＥＣＴＲＵＭＳＹＳＴＥＭＳ：ＨＩＧＨ−ＳＰＥＥＤＰＡＣＫＥＴＤＡＴＡＳＥＲＶＩＣＥＳ”というタイトルのＴＩＡ／ＥＩＡＩＳ−７０７−Ａ．９の標準規格とは、両者とも１９９９年３月に発行されており、これらもＴＩＡ／ＥＩＡＩＳ−９５のシステムのパケットデータ伝送のサポート要件を規定している。さらに加えて、ＭＳ１１０とＩＷＦ１０８との間の通信に対処している別の標準規格のプロトコルにはＴＩＡ／ＥＩＡＩＳ−２０００があり、これは“ＩＮＴＲＯＤＵＣＴＩＯＮＴＯＣＤＭＡ２０００ＳＴＡＮＤＡＲＤＳＦＯＲＳＰＲＥＡＤＳＰＥＣＴＲＵＭＳＹＳＴＥＭＳ”というタイトルで１９９９年７月に発行されている。
【０００７】
ＩＳ−７０７．５では、ＭＳ１１０とＢＳ／ＭＳＣ１０６（Ｕｍインターフェイス）との間およびＢＳ／ＭＳＣ１０６とＩＷＦ１０８（Ｌインターフェイス）との間の通信プロトコルのオプションモデルを取り入れている。例えば、中継モデルは、ポイント−ツウ−ポイントプロトコル（ＰｏｉｎｔｔｏＰｏｉｎｔＰｒｏｔｏｃｏｌ，ＰＰＰ）のリンクがＭＳ１１０とＩＷＦ１０８との間のＵｍインターフェイス上に存在している情況を表わしている。ＰＰＰプロトコルは、ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔ（ＲＦＣ１６６１）（“ＴＨＥＰＯＩＮＴ−ＴＯ−ＰＯＩＮＴＰＲＯＴＯＣＯＬ（ＰＰＰ）”）に詳しく記載されている。
【０００８】
（従来技術を示している）図２は、ＩＳ−７０７．５の中継モデルの各エンティティ内のプロトコルスタックの図である。図の左端には、従来の垂直形のフォーマットで示された通信プロトコルスタックが記載されており、これはＭＳ１１０上で実行されるプロトコル層を示している。ＭＳ１１０のプロトコルスタックは、Ｕｍインターフェイスを通してＢＳ／ＭＳＣ１０６のプロトコルスタックへ論理的に接続されているように示されている。また、ＭＳ／ＭＳＣ１０６のプロトコルスタックは、Ｌインターフェイスを通してＩＷＦ１０８のプロトコルスタックへ論理的に接続されているように示されている。
【０００９】
図２は次に記載する動作が行われることを示している。すなわち、ＭＳ１１０上で実行される上位層プロトコル２００のエンティティ、例えばアプリケーションプログラムは、インターネットを通してデータを送る必要がある。代表的なアプリケーションには、ウエブブラウザプログラム（例えば、ＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒ（ネットスケープナビゲータ）（商標）、ＭｉｃｒｏｓｏｆｔＩｎｔｅｒｎｅｔｅｘｐｌｏｒｅｒ（マイクロソフトインターネットエクスプローラ）（商標））がある。ウエブブラウザには、ハイパーリンク“ｈｔｔｐ：／／ｗｗｗ．Ｑｕａｌｃｏｍｍ．ｃｏｍ／”のようなユニバーサルリソースロケータ（ＵｎｉｖｅｒｓａｌＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ，ＵＲＬ）が必要である。同じく上位層プロトコル２００内のドメイン名システム（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ（ＤＮＳ））プロトコルはドメイン名の分解（ｒｅｓｏｌｕｔｉｏｎ）を使用して、名前をインターネットのアドレスへ変換することによって、テキストホスト名ｗｗｗ．Ｑｕａｌｃｏｍ．ｃｏｍを３２ビットの数字のＩＰアドレスへ変換する。同じく上位層プロトコル２００であるハイパーテキスト転送プロトコル（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ，ＨＴＴＰ）は、要求されているＵＲＬのためのＧＥＴメッセージを作成し、このメッセージを送るのに使用されるＴＣＰおよびＨＴＴＰの動作を指定する。トランスポート層２０２では、宛先ポートとして、この技術において使用されているポート８０を使用して、ＨＴＴＰの動作をアプリケーションへルート設定する。
【００１０】
ＴＣＰプロトコルは、トランスポート層プロトコル２０２であり、ＤＮＳによって指定されるＩＰアドレスとの接続を開き、アプリケーションレベルのＨＴＴＰのＧＥＴメッセージを送る。ＴＣＰプロトコルでは、ＩＰプロトコルを使用してメッセージを転送することを指定している。ＩＰプロトコルはネットワーク層プロトコル２０４であり、ＴＣＰパケットを指定されたＩＰアドレスへ送る。ＰＰＰはリンク層プロトコル２０６であり、ＩＰパケットをコード化し、それらを中継層プロトコル２０８へ送る。中継層プロトコル２０８は、例えば、ＴＩＡ／ＥＩＡ−２３２Ｆの標準規格であり、ＴＩＡ／ＥＩＡ−２３２Ｆの標準規格は“ＩＮＴＥＲＦＡＣＥＢＥＴＷＥＥＮＤＡＴＡＴＥＲＭＩＮＡＬＥＱＵＩＰＭＥＮＴＡＮＤＤＡＴＡＣＩＲＣＵＩＴ−ＴＥＲＭＩＮＡＴＩＮＧＥＱＵＩＰＭＥＮＴＥＭＰＬＯＹＩＮＧＳＥＲＩＡＬＢＩＮＡＲＹＤＡＴＡＩＮＴＥＲＣＨＡＮＧＥ”に規定されており、１９９７年１０月に発行されている。層間の伝送を規定するのに、この技術において普通の技能をもつ技術者に知られている他の標準規格またはプロトコルを使用できることが分かるであろう。例えば、他の応用可能な標準規格には、１９９８年９月に発行された“ＵＮＩＶＥＲＳＡＬＳＥＲＩＡＬＢＵＳ（ＵＳＢ）ＳＰＥＣＩＦＩＣＡＴＩＯＮ，Ｒｅｖｉｓｉｏｎ１．１”と、１９９９年７月に発行された“ＢＬＵＥＴＯＯＴＨＳＰＥＣＩＦＩＣＡＴＩＯＮＶＥＲＳＩＯＮ１．０ＡＣＯＲＥ”とが含まれる。最後に、ＰＰＰパケットは中継層プロトコル２０８から無線リンクプロトコル（ＲａｄｉｏＬｉｎｋＰｒｏｔｏｃｏｌ，ＲＬＰ）２１０、次にＩＳ−９５プロトコル２１２を経由して、Ｕｍインターフェイスを通してＢＳ／ＭＳＣ１０６へ送られる。ＲＬＰプロトコル２１０はＩＳ−７０７．２の標準規格に規定されており、ＩＳ−７０７．２の標準規格は“ＤＡＴＡＳＥＲＶＩＣＥＯＰＴＩＯＮＳＦＯＲＷＩＤＥＢＡＮＤＳＰＲＥＡＤＳＰＥＣＴＲＵＭＳＹＳＴＥＭＳ：ＲＡＤＩＯＬＩＮＫＰＲＯＴＯＣＯＬ”というタイトルで１９９８年２月に発行されていて、ＩＳ−９５プロトコルは上述で識別したＩＳ−９５の標準規格に規定されている。
【００１１】
ＰＰＰパケットはＵｍインターフェイスを通してＢＳ／ＭＳＣ１０６上のＩＳ−９５の層２１８、次にＲＬＰの層２１６へ送られ、相補的な中継層プロトコル２２０によって受信される。中継層プロトコル２２０は、このＰＰＰパケットをＬインターフェイスを通してＩＷＦ１０８上の中継層プロトコル２２８へ送る。ＩＷＦ１０８上のＰＰＰプロトコルリンク層２２６が中継層プロトコル２２８からＰＰＰパケットを受信すると、ＭＳ１１０とＩＷＦ１０８との間のＰＰＰ接続は終了する。パケットは、ＩＷＦ１０８上のＰＰＰ層２２６からＩＰ層２２４へ送られ、ＩＰ層２２４では最後のルート設定のためにＩＰパケットのヘッダ（このシナリオではｗｗｗ．Ｑｕａｌｃｏｍｍ．ｃｏｍである）を調べる。
【００１２】
ＭＳ１１０によって生成されたＩＰパケットの最終的な宛先がＩＷＦ１０８ではないと仮定すると、パケットはネットワーク層プロトコル２２４、さらにリンク層プロトコル２２５を経由して、インターネット上の次のルータ（図示されていない）へ送られる。このやり方では、ＭＳ１１０からのＩＰパケットは、ＩＳ−７０７．５の標準規格の中継モデルにしたがって、ＢＳ／ＭＳＣ１０６、およびＩＷＦ１０８を経由して、インターネット内の最終的な意図された宛先へ伝達される。
【００１３】
ＭＳ１１０のパケットがその宛先へ到達する前に、先ずデータリンク接続が設定されなければならない。ＲＦＣ１６６１に指定されているように、このデータリンク接続では、先ずポイント−ツウ−ポイントリンクの各終端（すなわち、ＰＰＰプロトコル２０６および２２６）がＰＰＰリンク制御プロトコル（ＬｉｎｋＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ，ＬＣＰ）へパケットを送って、データリンク接続を設定し、構成し、試験することが求められている。ＬＣＰによってリンクが設定された後で、ＰＰＰプロトコル２０６はネットワーク制御プロトコル（ＮｅｔｗｏｒｋＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ，ＮＣＰ）のパケットを送って、ネットワーク層プロトコル２０４および２２４を構成する。ＰＰＰリンクにおけるＩＰのためのＮＣＰはＩＰ制御プロトコル（ＩＰＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ，ＩＰＣＰ）である。ＩＰＣＰは、ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔ１３３２（ＲＦＣ１３３２）に詳しく記載されており、ＲＦＣ１３３２は“ＴＨＥＰＰＰＩＮＴＥＲＮＥＴＰＲＯＴＯＣＯＬＣＯＮＴＲＯＬＰＲＯＴＯＣＯＬ（ＩＰＣＰ）”というタイトルで１９９２年５月に発行されている。しかしながら、ＩＰＣＰのネゴシエーションの前には、認証段階が必要である。各ネットワーク層プロトコルが構成された後では、各ネットワーク層プロトコルからのパケットは、プロトコル間のリンクを通して送られる。
【００１４】
Ｂ．アプリケーションプログラムインターフェイス
ＭＳ１１０上の通信プロトコルスタックをサポートするプロセスは、その全てではないが、ほとんどがアプリケーションプログラムによって実行される。一般的に従来のデータネットワークでは、アプリケーションプログラムインターフェイス（ａｐｐｌｉｃａｔｉｏｎｐｒｏｇｒａｍｉｎｔｅｒｆａｃｅ，ＡＰＩ）を採用して、あるコンピュータ上で実行されるアプリケーションプログラムと別のコンピュータ上で実行されるアプリケーションプログラムとの通信を可能にしている。ＡＰＩは“ソケット”を使用して、基礎ネットワークのプロトコルの相違によって、呼出しているアプリケーションを保護する。ネットワーク間の通信（ｉｎｔｅｒ−ｎｅｔｗｏｒｋｅｄｃｏｍｍｕｎｉｃａｔｉｏｎ）を実現するために、ＡＰＩには、アプリケーションが、例えばソケットを開き、データをネットワークへ送り、ネットワークからデータを受信し、ソケットを閉じることを可能にする機能（ｆｕｎｃｔｉｏｎ）が含まれている。通信ネットワークのプログラミングインターフェイスには、Ｕｎｉｘ（ユニックス）（商標）のオペレーティングシステムのもとで動作するバークレイシステム開発（ＢｅｒｋｅｌｅｙＳｙｓｔｅｍＤｅｖｅｌｏｐｍｅｎｔ，ＢＳＤ）のソケットインターフェイス、およびＷｉｎｄｏｗｓ（ウインドウズ）（商標）のオペレーティングシステムのもとで動作するＷｉｎｄｏｗｓ（ウインドウズ）（商標）ＳｏｃｋｅｔｓＩｎｔｅｒｆａｃｅ（ソケットインターフェイス）（ＷｉｎＳｏｃｋ（ウインソック）（商標））が含まれる。
【００１５】
ＢＳＤソケットもＷｉｎＳｏｃｋ（ウインソック）（商標）の何れも無線ＭＳ１１０上の通信プロトコルスタック（図２参照）をサポートしていないので、このようなスタックをサポートする斬新なＡＰＩが必要である。とくに、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための斬新な方法および装置が必要とされている。
【００１６】
本発明の概要
本発明では、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置を提供することによって、上述で識別した必要に対処している。１つの構成では、本発明は、通信ネットワークと通信する移動局の通信プロトコルスタックと、移動局のアプリケーションとの間の通信を容易にするアプリケーションプログラムインターフェイス（ａｐｐｌｉｃａｔｉｏｎｐｒｏｇｒａｍｉｎｔｅｒｆａｃｅ，ＡＰＩ）を含んでいる。移動局のアプリケーションは機能を呼出す。ＡＰＩは、その状態と呼出された機能とに基づいて、指定された状況メッセージの少なくとも１つを選択する。次にＡＰＩは、選択した指定された状況メッセージを移動局のアプリケーションへ報告する。
【００１７】
詳細な記述
本発明の実施形態は、ソフトウエア、ファームウエア、および／またはハードウエアを含む種々の構成において実現することができる。したがって、本発明の動作および働き（ｂｅｈａｖｉｏｒ）はソフトウエアコードまたはハードウエアの構成要素をとくに参照せずに記載されているが、この技術において普通の技能をもつ人には、本明細書の記述に基づいて、本発明を構成するソフトウエアまたはハードウエア、あるいはこの両者を設計でき、これにより移動局のアプリケーションが指定された状況メッセージを識別できることが分かるであろう。
【００１８】
図３には、ＭＳ１１０内のアプリケーション２６０、通信プロトコルスタック２８０、およびＡＰＩ２７０が示されている。アプリケーション２６０および通信プロトコルスタック２８０（すなわち、プロトコル層２０２、２０４、２０６、２０８、２１０、２１２）は、ＡＰＩ２７０によって与えられる機能呼出し（ｆｕｎｃｔｉｏｎｃａｌｌ）によって通信する。言い換えると、ＡＰＩ２７０は、アプリケーション２６０および通信プロトコルスタック２８０を機能を損わずに異なるプロセッサおよびオペレーティングシステム上で実行できるようにする。当業者には、本発明の技術的範囲から逸脱することなく、呼出された機能に対して種々の名前が可能であることが分かるであろう。
【００１９】
通信プロトコルスタック２８０には、複数の送信待ち行列と受信待ち行列とが含まれていて、これらの待ち行列はデータを記憶することに注意すべきである。出力機能では、アプリケーション２６０のメモリからデータを読出し、そのデータを通信プロトコルスタック２８０の送信待ち行列の１つへ記憶する。入力機能では、通信プロトコルスタック２８０の受信待ち行列の１つからデータを読出し、そのデータをアプリケーション２６０のメモリへ記憶する。
【００２０】
動作を示すために、ＭＳ１１０はＩＰパケットを受信する。ＭＳ１１０の通信プロトコルスタック２８０は、ＩＰパケットを逆カプセル化して（ｕｎｅｎｃａｐｓｕｌａｔｅ）、それらをトランスポート層２０２へ送る（図３参照）。ＩＰパケットヘッダ内の１つのフィールドはトランスポートを示していて、ＴＣＰまたはＵＤＰの何れかでを含む。トランスポート層のヘッダにおいて指定されている宛先ポートの番号に基づいて、データは、特定のソケットに対応する通信プロトコルスタック２８０の適切な受信待ち行列へルート設定される。次にデータは、アプリケーション２６０へ送られる。
【００２１】
一定の情況では、プロトコルスタック２８０の種々の層をバイパスするパケットを使用して動作して、待ち時間の影響を軽減することが望ましい。このようなパケットには、生のＩＰパケットのような生のパケット化されたデータが含まれているが、これには宛先の情報（すなわち、宛先ポートの番号）が欠けている。したがって、宛先のアプリケーションは、生のＩＰパケットから判断できない。このような情況では、通信プロトコルスタック２８０は受信した生のＩＰパケットを、例えばＩＰプロトコルをサポートするために登録されている全てのソケットへ送る。このようにしてペイロードデータは宛先のアプリケーションへ送られる。インターネット制御メッセージングプロトコル（ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｉｎｇＰｒｏｔｏｃｏｌ，ＩＣＭＰ）のパーシングエンジンはＩＰパケットに応答して、生のパケット化されたデータも受信することができる。周知のＩＣＭＰのパーシングエンジンは、“ＩＮＴＥＲＮＥＴＣＯＮＴＲＯＬＭＥＳＳＡＧＥＰＲＯＴＯＣＯＬ”というタイトルでＲＦＣ７９２に規定されている。したがって、通信プロトコルスタック２８０は、受信したパケットを処理し、その後でパケットをスタックを逆上ってアプリケーション２６０へ送り、アプリケーション２６０が逆カプセル化する量を低減することが明らかである。
【００２２】
逆に、アプリケーション２６０は、ソケットを使用することによって生のパケット化されたデータをＵｍインターフェイスを通して送り、通信プロトコルスタック２８０とアプリケーション２６０との間の通信を容易にすることもできる。さらに、アプリケーション２６０は、生のパケット化されたデータをＵｍインターフェイスを通して送ることもできる。また、通信プロトコルスタック２８０は、例えばパケット化された、または生のパケット化されたデータをＩＰパケットへカプセル化し、それらをＵｍインターフェイスを通して送る。この例では、通信プロトコルスタック２８０はＩＰヘッダおよびチェックサムを用意して、ＩＰパケットを生成する。他方で、ＩＣＭＰでは、指定されたプロトコルのタイプはＩＰヘッダへコピーされる。
【００２３】
既に記載したように、アプリケーション２６０はソケットを生成し、ソケットはプロトコル層２０２、２０４、２０６、２０８、２１０、２１２の少なくとも１つとアプリケーション２６０との間のデータ通信が、通信プロトコルスタック２８０を使用するときに必ず伴う待ち時間を低減できるようにする。したがってアプリケーション２６０はソケットを生成し、ソケットはトランスポート層２０２、ネットワーク層２０４、およびリンク層２０６をバイパスして、アプリケーション２６０がＲＬＰ層２１０との間でペイロードデータを送受信できるようにする。さらに加えて、アプリケーション２６０はソケットを生成し、ソケットはアプリケーション２６０がＩＳ−９５の層２１２との間でペイロードデータを送受信できるようにする。
【００２４】
１つの実施形態では、アプリケーション２６０は機能ｏｐｅｎｎｅｔｌｉｂ（）を呼出して、通信プロトコルスタック２８０を開き、アプリケーションの識別を割り当てる。アプリケーションを識別すると、多数のアプリケーションが通信プロトコルスタック２８０と通信すること（すなわち、マルチタスキング）ができる。例えば、機能ｏｐｅｎｎｅｔｌｉｂ（）の呼出しの一部として、アプリケーション２６０はネットワークコールバック機能およびソケットコールバック機能へのポインタを指定する。トラヒックチャンネル（すなわち、Ｕｍ）またはリンク層（すなわち、ＰＰＰ２０６）、あるいはこの両者から読出し、そこへ書込み、それを閉じるといった、ネットワークサブシステムの指定されたイベントが生成される（または、イネーブルされる）たびに、ネットワークコールバック機能が呼出されて、アプリケーション２６０に知らせる。トランスポート層（すなわち、ＴＣＰ）から読出し、そこへ書込み、それを閉じるといったソケットの指定されたイベントが生成される（または、イネーブルされる）たびに、ソケットコールバック機能が呼出され、アプリケーション２６０へ知らされる。通信ネットワークがトラヒックチャンネル、リンク層、およびトランスポート層の少なくとも１つを含むことは、当業者には明らかである。
【００２５】
通信プロトコルスタック２８０が開かれると、機能ｐｐｐｏｐｅｎ（）が呼出され、トラヒックチャンネルおよびリンク層を含むネットワークサブシステムの接続を開始する。これはアプリケーション全体の呼であり、個々のソケットに依存していない。しかしながら、これはアプリケーションの識別を必要とする。ネットワークサブシステムの接続が設定されるか、またはそれが故障すると、ネットワークコールバック機能が呼出されて、指定されたイベントが通知される。例えば、トラヒックチャンネルが設定されていないときは、ネットワークサブシステムは故障する。さらに加えて、ネットワークサブシステムの特徴は、機能ｎｅｔｉｏｃｔｌ（）を呼出すことによって設定される。この呼出しは、例えば、ソケットのデータレートを指定する。
【００２６】
ネットワークサブシステムの接続が設定されると、機能ｓｏｃｋｅｔ（）を呼出すことによって、ソケットが生成されて初期設定される。しかしながら、ソケットの機能が使用できる前に、機能ｓｏｃｋｅｔ（）を呼出して、ソケット記述子を戻してもよい。次に、アプリケーション２６０は機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出して、指定されたイベントを登録し、非同期の通知を受信する。この登録は、アプリケーション２６０によって機能呼出しの一部として実行され、指定されたイベントの要求する通知のソケット記述子およびビットマスクを指定する（すなわち、多数のイベントの論理和がとられる）。指定されたイベントが生成され（すなわち、イネーブルされ）、それが、例えば通信プロトコルスタック２８０またはＡＰＩ２７０によって検出されると、ソケットコールバック機能が呼出されて、非同期の通知を与える。コールバック機能では、信号、メッセージ、例えば遠隔手続き呼出し（ｒｅｍｏｔｅｐｒｏｃｅｄｕｒｅｃａｌｌ，ＲＰＣ）についてのメッセージ、あるいはハードウエアまたはソフトウエアの割込みを使用することによって、指定されたイベントのアプリケーション２６０を通知することができる。
【００２７】
アプリケーション２６０は、指定されたイベントについて通知されると、機能ｇｅｔｎｅｘｔｅｖｅｎｔ（）を呼出して、指定されたイベントを判断してサービスする。この機能は、生成された指定されたイベントのマスクを指定されたソケット記述子へ戻す。さらに加えて、この機能は、生成された指定されたイベントのマスク内のビットをクリアする。したがって、アプリケーション２６０は、ディスエーブルされた指定されたイベントの通知を最早受信できない。アプリケーション２６０は、次に機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出すことによって、これらの指定されたイベントを再登録（すなわち、再イネーブル）しなければならない。
【００２８】
さらに加えて、アプリケーション２６０は、指定されたイベントのビットマスク内の対応するビットをクリアすることによって、登録された指定されたイベントを変更する。ビットマスク内でビットが既にクリアされているときは、要求は単に無視される。簡潔に言えば、イベントの通知は、例えば機能ａｓｙｎｃｄｅｓｅｌｅｃｔ（）を呼出すことによって、イベントごとにディスエーブルされる。
【００２９】
図４および５は、指定されたイベントを検出するフローチャートである。図４に示したように、例えばブロック４００では、通信プロトコルスタック２８０は、アプリケーション２６０が指定されたイベントを登録するのを待つ。指定されたイベントが登録されると、ブロック４０２では、通信プロトコルスタック２８０はメモリをポーリングする。ブロック４０４では、ブロック４０２のポーリングされた情報に基づいて、指定されたイベントが検出される。ブロック４０６では、例えば通信プロトコルスタック２８０のメモリ（すなわち、送信待ち行列）が十分な量のデータを受け付けるのに使用可能であるときは、書込みイベントが検出される。データはアプリケーション２６０から送られる。ブロック４０４においてポーリングされた情報が十分でない（すなわち、指定されたイベントが生成されなかった）ときは、通信プロトコルスタック２８０は、ブロック４０２のように、メモリをポーリングし続ける。
【００３０】
図５では、ブロック５００に示したように、通信プロトコルスタック２８０は、アプリケーション２６０が指定されたイベントを登録するのを待つ。この時間の間は、割込み通知はディスエーブルされる。したがって、割込み通知はトリガすることも、トリガされることもできない。ブロック５００において指定されたイベントが登録された後で、ブロック５０２において、指定されたイベントが生成されたことに基づいて、割込み通知がトリガされる。例えば、データが通信プロトコルスタック２８０（すなわち、受信待ち行列）のメモリへ書込まれるとき、読出しイベントが生成される。したがって、ブロック５０４では、イベントの生成によってトリガされた割込み通知を通信プロトコルスタック２８０が受信するとき、通信プロトコルスタック２８０は読出しイベントを検出する。通信プロトコルスタック２８０のメモリ内に記憶されるデータは、通信ネットワークから送られる。さらに、読出しイベントにおいて記憶されるデータは、アプリケーション２６０へ送られる。
【００３１】
最後に、ソケットが再使用に利用できるとき、トランスポート層のようにデータリンク接続は終了しているので、閉鎖イベントが検出される。
【００３２】
次に示す非同期接続（図６参照）および非同期入力（図７参照）の例では、非同期のイベントの通知の使用を示す。
【００３３】
図６を参照すると、機能ｏｐｅｎｎｅｔｌｉｂ（）を呼出すことによって、通信プロトコルスタック２８０へ入り、かつコールバック機能が指定される。機能ｐｐｐｏｐｅｎ（）を呼出すと（Ａ）、ネットワークサブシステムの接続が始まる（Ｂ）。ネットワークサブシステムの接続が設定された後で、コールバック機能が呼出され（Ｃ）、ネットワークサブシステムが使用可能であることが報告される。
【００３４】
ソケットが開かれて、割り当てられていると仮定すると、機能ｃｏｎｎｅｃｔ（）を呼出して（Ｄ）、ＴＣＰ接続が始まる（Ｅ）。さらに、アプリケーション２６０は機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出すと（Ｆ）、指定されたイベントを登録して、通知を受信する。この例では、目的の指定されたイベントは書込みイベントであり、書込みイベントは接続を設定するときに生成される。
【００３５】
接続を設定する際に、指定されたイベントがマスク内に登録されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され（Ｇ）、非同期の通知が与えられる。アプリケーション２６０は、通知を受取ると、機能ｇｅｔｎｅｘｔｅｖｅｎｔ（）を呼出し（Ｈ）、生成された何れかの指定されたイベントを判断する（Ｉ）。さらに加えて、この呼はマスク内のイベント（すなわち、書込みイベント）のビットをクリアする（Ｊ）。アプリケーション２６０は、機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出すことによって、指定されたイベントの次の通知を再登録しなければならない。
【００３６】
図７には、非同期のソケットの読出しが示されている。読出しを開始するために、アプリケーション２６０は機能ｒｅａｄ（）を呼出す（Ａ）。読出すデータがないとみなされると、アプリケーション２６０は機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出し（Ｂ）、イベントを登録し（すなわち、マスク内の対応するビットを設定し）、通知を受信する。この例では、目的の指定されたイベントは読出しイベントであり、読出しイベントは、アプリケーション２６０によって読出されるデータがあるときに生成される。
【００３７】
受信待ち行列内にデータを記憶する際に、読出しイベントがマスク内で指定されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され（Ｃ）、非同期の通知を与える。アプリケーション２６０は、通知を受取ると、機能ｇｅｔｎｅｘｔｅｖｅｎｔ（）を呼出し（Ｄ）、何れのイベントが生成されるかを判断する（Ｅ）。さらに加えて、この呼出しは、マスク内のイベントのビットをクリアする（Ｆ）。アプリケーション２６０は、機能ａｓｙｎｃｓｅｌｅｃｔ（）を呼出すことによって、イベントの次の通知を再びイネーブルしなければならない。最後に、受信待ち行列内に記憶されたデータを読出すために、アプリケーション２６０は機能ｒｅａｄ（）を呼出す（Ｇ）。
【００３８】
図８ないし１０には、本発明の実施形態の状態機械が示されている。図８ないし１０では、通信プロトコルスタック２８０は開いていて、ネットワークサブシステムの接続（すなわち、トラヒックチャンネル、および必要であればリンク層の接続−生のソケットはネットワークサブシステムをバイパスする）が設定されると仮定されている。当業者には、本発明の技術的範囲から逸脱することなく、状態に対する種々の名前が可能であることが分かるであろう。
【００３９】
状態機械は、状態間を非同期で遷移でき、読取り、書込み、および閉鎖といった指定されたイベントを制御する（すなわち、イネーブルおよびディスエーブルする）。指定されたイベントは動作の開始時にはディスエーブルされていて、所定の状態でイネーブルされ、アプリケーション２６０がＭＳ１１０の状態を識別するのを助ける。
【００４０】
さらに加えて、ＡＰＩ２７０は、ＡＰＩ２７０の状態およびアプリケーション２６０によって呼出される機能のタイプに基づいて、特定の（すなわち、単に一般的でない）指定された状況メッセージをアプリケーション２６０へ報告する。指定された状況メッセージは、基礎の通信ネットワークの状態を反映する。状況メッセージは、例えば機能呼出しの立証（ａｒｇｕｍｅｎｔ）としてアプリケーション２６０へ報告される。
【００４１】
図８には、例えばＡＰＩ２７０のＴＣＰソケットの状態図が示されている。初期設定されていないソケットは、“ナル”状態８００で始まる。ソケットは、このときはまだ割り当てられていないので、“存在”しない。ソケットは、機能ｓｏｃｋｅｔ（）を呼出すことによって生成されて初期設定され、ソケット記述子を戻して、ソケットに関係する機能を使用する。機能ｓｏｃｋｅｔ（）を呼出した後で、状態機械は“初期設定”状態８０５へ遷移する。
【００４２】
初期設定状態８０５では、状態機械は、機能ｃｌｏｓｅ（）を呼出すことによってＴＣＰ接続が終了可能になるたびに、ナル状態８００へ再び遷移する。機能ｃｌｏｓｅ（）を呼出すと、全てのソケットに関係する資源が解放される。他方で、機能ｃｏｎｎｅｃｔ（）を呼出すと、ＴＣＰ接続が開始され、状態機械は“オープニング”状態８１０へ遷移する。
【００４３】
オープニング状態８１０では、（１）ネットワークサブシステムが故障したとき、（２）ＴＣＰ接続の設定に失敗したとき、または（３）ＩＰアドレスを変更したときは、そのたびに状態機械は“クローズド”状態８１５へ遷移する。さらに加えて、ＴＣＰ接続を終了する機能ｃｌｏｓｅ（）を呼出した後に、状態機械はソケットを“クロージング”状態８２０へ遷移し、一方では終了手続きが開始される。最後に、ＴＣＰ接続が設定されたときは、状態機械は“オープン”状態８２５へ遷移する。
【００４４】
オープン状態８２５では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ぐにイネーブルされ、読出しイベントは、通信プロトコルスタック２８０のメモリへデータが記憶されるかどうかに基づいてイネーブルされる。（１）ネットワークサブシステムが故障したとき、（２）ＴＣＰ接続を設定するのに失敗したとき、（３）ＴＣＰのリセット、ＴＣＰのアボート、またはＴＣＰの閉鎖のようなＴＣＰ接続を終了する試みをネットワークサーバが開始したとき、および（４）ＩＰアドレスが変更されたときは、そのたびに状態機械はクローズド状態８１５に遷移する。例えば機能ｃｌｏｓｅ（）を呼出すことによって、アプリケーションがＴＣＰ接続の終了を開始すると、状態機械はクロージング状態８２０へ遷移する。
【００４５】
クローズド状態８１５では、読出し、書込み、および閉鎖イベントは全てアサートされる。ＴＣＰ接続を終了する機能ｃｌｏｓｅ（）を呼出した後で、状態機械はソケットをナル状態８００へ遷移し、ソケットを解放し、それを再使用に利用できるようにする。
【００４６】
クロージング状態８２０では、（１）ネットワークサブシステムが故障したとき、（２）ネットワークサーバが、例えばＴＣＰのリセットまたはＴＣＰの閉鎖のようなＴＣＰ接続の終了の試みを開始したとき、（３）タイマの時限が切れたとき、および（４）ＩＰアドレスを変更したときは、そのたびに状態機械は“閉鎖待機”の状態８３０へ遷移する。ＴＣＰ接続を終了するときに遅延するのを防ぐために、ＡＰＩ２７０は、ＴＣＰ接続の終了を開始するときに作動するタイマを含んでいる。タイマの時限が切れると、状態機械は閉鎖待機の状態８３０に遷移することが分かるであろう。
【００４７】
閉鎖待機の状態８３０では、機能ｃｌｏｓｅ（）を呼出して、ＴＣＰ接続を終了し、状態機械をナル状態８００へ遷移する。閉鎖イベントは、この状態８３０でアサートされる。
【００４８】
表１−３は、ＡＰＩ２７０によってサポートされる指定された状況メッセージを示している。（表１ないし３には示されていない）ナル状態では、記述的な指定された状況メッセージ、すなわち“追加の資源は使用できない（ｎｏａｄｄｉｔｉｏｎａｌｒｅｓｏｕｒｃｅｓａｒｅａｖａｉｌａｂｌｅ）”が、アプリケーション２６０へ報告される。
【００４９】
【表１】

【００５０】
【表２】

【００５１】
【表３】

【００５２】
例として、図９はＡＰＩ２７０のＵＤＰソケットの状態図を示している。初期設定されていないソケットは“ナル”状態９００で始まる。ナル状態８００に関して既に記載したように、ソケットは、割り当てられていないので“存在”しない。ソケットは、機能ｓｏｃｋｅｔ（）を呼出すことによって生成および初期設定され、ソケットに関係する機能で使用するためにソケットの記述子を戻す。機能ｓｏｃｋｅｔ（）を呼出した後で、状態機械は“オープン”状態９０５へ遷移する。
【００５３】
オープン状態９０５では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ちにイネーブルされ、一方で読出しイベントはデータが通信プロトコルスタック２８０のメモリへ記憶されるかどうかに基づいてイネーブルされる。状態機械は、ネットワークサブシステムが故障するたびに“クローズド”状態９１０へ遷移する。例えば機能ｃｌｏｓｅ（）を呼出すことによって、アプリケーションはＵＤＰ接続の終了を開始して、状態機械をナル状態９００へ遷移する。
【００５４】
クローズド状態９１０では、読出し、書込み、および閉鎖の状態は全てイネーブルされる。ＵＤＰ接続を終了する機能ｃｌｏｓｅ（）を呼出した後で、状態機械はソケットをナル状態９００へ遷移し、ソケットを解放し、再使用に利用できるようにする。
【００５５】
表４ないし６は、ＡＰＩ２７０によってサポートされる指定された状況メッセージを示している。（表４ないし６には示されていない）ナル状態では、既出の指定された状況メッセージである“追加の資源は使用できない（ｎｏａｄｄｉｔｉｏｎａｌｒｅｓｏｕｒｃｅｓａｒｅａｖａｉｌａｂｌｅ）”が、アプリケーション２６０へ報告される。
【００５６】
【表４】

【００５７】
【表５】

【００５８】
【表６】

【００５９】
図１０は、トラヒックチャンネル（すなわち、Ｕｍ）およびリンク層（すなわち、ＰＰＰ２０６）のようなネットワークサブシステムを制御する状態図を示している。機能ｏｐｅｎｎｅｔｌｉｂ（）を呼出すことによって、ネットワークサブシステムを開き、“クローズド”状態１０００へソケットを初期設定する。機能ｐｐｐｏｐｅｎ（）を呼出すことにより、ネットワークサブシステムの接続を開始し、ソケットを“オープニング”状態１００５へ遷移する。さらに加えて、到来するＰＰＰ呼出しによるＭＳ１１０へのページは、ソケットをオープニング状態１００５へ遷移する。両者の場合において、ネゴシエーションが成功するときは、ＭＳ１１０はトラヒックチャンネルにおいてＲＬＰおよびＰＰＰの両者を同期させて設定することを試みる。
【００６０】
オープニング状態１００５では、ネットワークサブシステムの接続が設定されたときに、ソケットは“オープン”状態１０１０へ遷移する。他方では、ネットワークサブシステムの接続が設定されていないときは、ソケットはクローズド状態１０００へ再び遷移する。
【００６１】
オープン状態１０１０では、コールバック機能が呼出されて、イネーブルされた読出し、書込み、および閉鎖のようなアプリケーション１０６０の指定されたイベントを識別する。このとき、ＭＳ１１０はトラヒックチャンネルによって通信することができる。しかしながらソケットは、ネットワークサブシステムが故障し、コールバック機能を呼出すたびに、クローズド状態１０００へ遷移する。例えば機能ｃｌｏｓｅ（）を呼出すことによって、アプリケーションは、ネットワークサブシステムの接続の終了を開始し、ソケットを“クロージング”状態１０１５へ遷移する。
【００６２】
クロージング状態１０１５では、ネットワークサブシステムの接続が終了するたびに、ソケットはクローズド状態１０００へ遷移する。クローズド状態１０００では、コールバック機能を呼出して、イネーブルされたアプリケーション２６０の指定されたイベントを識別する。
【００６３】
表７は、特定の機能呼出しに対応し、かつＡＰＩ２７０によってサポートされる指定された状況メッセージを示している。
【００６４】
【表７】

【００６５】
【表８】

【００６６】
【表９】

【００６７】
【表１０】

【００６８】
【表１１】

【００６９】
【表１２】

【００７０】
【表１３】

【００７１】
【表１４】

【００７２】
別の実施形態では、機械は、コード化されたソフトウエアコードのようなコード化された情報を含む機械読出し可能媒体を読出して、移動局のアプリケーションが指定された状況メッセージを識別できるようにする上述のプロセスを行なう。機械読出し可能媒体は、メモリまたは記憶ディスクのような記憶デバイスから、あるいは通信ネットワークから、コード化された情報を受取る。さらに加えて、機械読出し可能媒体は、製造されたときに、コード化された情報でプログラムされる。機械は、アプリケーション２６０、通信プロトコルスタック２８０、およびＡＰＩ２７０の少なくとも１つを含み、一方で機械の読出し媒体はメモリまたは記憶ディスクを含む。
【００７３】
本発明は特定の実施形態に関連して示したが、そのように制限されているわけではないと考えられる。むしろ、本発明は特許請求の範囲およびそれに相当するものの技術的範囲のみによって制限される。
【図面の簡単な説明】
【図１】
（従来技術において）移動局がインターネットに接続している無線通信システムの高レベルのブロック図。
【図２】
（従来技術において）ＴＩＡ／ＥＩＡＩＳ−７０７．５の中継モデルの各エンティティにおけるプロトコルスタックを模式的に示す図。
【図３】
本発明の実施形態の特徴を模式的に示す図。
【図４】
指定されたイベントを検出するフローチャート。
【図５】
指定されたイベントを検出するフローチャート。
【図６】
非同期接続を示すブロック図。
【図７】
非同期ソケット入力を示すブロック図。
【図８】
本発明の実施形態の状態図。
【図９】
本発明の実施形態の状態図。
【図１０】
本発明の実施形態の状態図。[0001]
Background 1. FIELD OF THE INVENTION The present invention relates generally to the field of wireless communications. More particularly, the present invention relates to a novel method and apparatus for enabling a mobile station application to identify a specified status message in a wireless communication system.
[0002]
2. Description of Related Technology Wireless Communications Recent innovations in wireless communications and computer-related technologies, and an unprecedented increase in Internet subscribers, have paved the way for mobile computing. In fact, the pervasiveness of mobile computing has increased the demand for more support for mobile users of the current Internet infrastructure. The driving force of this infrastructure is a packet-oriented Internet protocol (Internet Protocol, IP) that provides various services. For various services, packets (datagrams) are transferred to a local area network (LAN) and a local area network (LAN). Includes services that address and route to and from wide area networks (WANs). The IP protocol is defined in Request For Comment (RFC 791) (“INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, 1981 9).
[0003]
The IP protocol is a network layer protocol that encapsulates data into IP packets for transmission. Information on address designation and route setting is added to the header of the packet. The IP header includes, for example, a 32-bit address that identifies the sending host and the receiving host. Intermediate routers use these addresses to select a route on the network to direct the packet to its final destination with the intended address. Thus, the IP protocol allows packets originating at any Internet node in the world to be routed to any other Internet node in the world. On the other hand, in order to cope with a specific application, a transport layer including either a transmission control protocol (Transmission Control Protocol, TCP) or a user datagram protocol (User Datagram Protocol, UDP) is used.
[0004]
In the current trend, mobile users use mobile computers, such as laptop or palmtop computers, with wireless communication devices, such as cellular or mobile phones, to access the Internet. Thus, mobile users are typically referred to as "mobile stations", just as traditionally users connected computers to "land-based networks" using "wired" communication devices. , MS) are used to connect mobile terminals to such networks. As used herein, mobile station or MS refers to a subscriber station of a public wireless radio network.
[0005]
FIG. 1 (showing the prior art) shows a high-level block diagram of a wireless data communication system, in which MS 110 is a Base Station / Mobile Switching Center (BS / MSC). ) 106 and communicate with an interconnecting function (Interworking Function, IWF) 108. IWF 108 serves as an access point to the Internet. The IWF 108 is connected to the BS / MSC 106 and is often co-located, and the BS / MSC 106 may be a conventional wireless base station as is known in the art. Another standard protocol for wireless data communication systems is the 3rd Generation Partnership Project 2, "3GPP2", published December 1999 under the title "WIRELESS IP NETWORK STANDARD". Standards for the 3G wireless IP network include, for example, a packet data serving node (PDSN) that functions like the IWF 108.
[0006]
Various protocols address data communication between the MS 110 and the IWF 108. For example, the provisional standard of the Telecommunications Industry Association (TIA) / Electronics Industries Association (EIA) of the United States Telecommunications Industry Association (TIA) is an interim standard (International Standards Institute of Technology) for IS-95A, which is a provisional standard (International Standards Institute). Published in July 1993, entitled "DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM", which generally provides a standard for broadband spread spectrum wireless communication systems. In addition, the standard TIA / EIA IS-707.5 was published in February 1998 under the title "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES", which was published in the TIA / EIA. -95 specifies the packet data transmission service that can be used for communication between the MS 110 and the IWF 108 via the BS / MSC 106. In addition, TIA / EIA IS-707-A. Titled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES". 5 and a TIA / EIA IS-707-A. Titled "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: HIGH-SPEED PACKET DATA SERVICES". The 9 standards, both published in March 1999, also define the requirements for supporting packet data transmission for TIA / EIA IS-95 systems. In addition, another standardized protocol that addresses communications between MS 110 and IWF 108 is TIA / EIA IS-2000, which is titled "INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS". It was issued in July 1999.
[0007]
IS-707.5 incorporates an optional model of the communication protocol between MS 110 and BS / MSC 106 (Um interface) and between BS / MSC 106 and IWF 108 (L interface). For example, the relay model represents a situation where a Point-to-Point Protocol (PPP) link exists on the Um interface between the MS 110 and the IWF 108. The PPP protocol is described in detail in Request For Comment (RFC 1661) ("THE POINT-TO-POINT PROTOCOL (PPP)").
[0008]
FIG. 2 (showing prior art) is a diagram of the protocol stack within each entity of the IS-707.5 relay model. At the left end of the figure, a communication protocol stack shown in a conventional vertical format is described, which indicates a protocol layer executed on the MS 110. The MS 110 protocol stack is shown as being logically connected to the BS / MSC 106 protocol stack through the Um interface. Also, the protocol stack of the MS / MSC 106 is shown as being logically connected to the protocol stack of the IWF 108 via the L interface.
[0009]
FIG. 2 shows that the following operation is performed. That is, an entity of the upper layer protocol 200 that runs on the MS 110, such as an application program, needs to send data over the Internet. Representative applications include web browser programs (eg, Netscape Navigator (trademark), Microsoft Internet explorer (Microsoft Internet Explorer) (trademark)). The web browser requires a Universal Resource Locator (URL) such as a hyperlink " http://www.Qualcomm.com/ ". The Domain Name System (DNS) protocol, also within the upper layer protocol 200, uses resolution of the domain name to resolve the text host name to the Internet address, using domain name resolution . Qualcom. com to a 32-bit numeric IP address. Hypertext Transfer Protocol (HTTP), also an upper layer protocol 200, creates a GET message for the requested URL and specifies the TCP and HTTP operations used to send this message. I do. The transport layer 202 routes HTTP operations to applications using port 80 used in this technology as the destination port.
[0010]
The TCP protocol is a transport layer protocol 202 that opens a connection with an IP address specified by DNS and sends an application-level HTTP GET message. The TCP protocol specifies that messages be transferred using the IP protocol. The IP protocol is the network layer protocol 204, which sends a TCP packet to a specified IP address. PPP is a link layer protocol 206 that encodes IP packets and sends them to a relay layer protocol 208. The relay layer protocol 208 is, for example, a standard of TIA / EIA-232F. And was issued in October 1997. It will be appreciated that other standards or protocols known to those of ordinary skill in the art can be used to define the transmission between the layers. For example, other applicable standards include "UNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1", published in September 1998, and "BLUETOOTH SPECIFICATION VERSION 1. OA CORE "is included. Finally, the PPP packet is sent from the relay layer protocol 208 to the BS / MSC 106 via the Um interface via the radio link protocol (RLP) 210 and then via the IS-95 protocol 212. The RLP protocol 210 is defined in the IS-707.2 standard. The IS-707.2 standard is published in February 1998 under the title "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL". And the IS-95 protocol is defined in the IS-95 standard identified above.
[0011]
The PPP packet is sent through the Um interface to the IS-95 layer 218 on the BS / MSC 106, then to the RLP layer 216, and is received by the complementary relay layer protocol 220. The relay layer protocol 220 sends the PPP packet to the relay layer protocol 228 on the IWF 108 through the L interface. When the PPP protocol link layer 226 on the IWF 108 receives a PPP packet from the relay layer protocol 228, the PPP connection between the MS 110 and the IWF 108 ends. The packet is sent from the PPP layer 226 on the IWF 108 to the IP layer 224, which examines the IP packet's header (in this scenario, www.Qualcomm.com ) for final routing .
[0012]
Assuming that the final destination of the IP packet generated by MS 110 is not IWF 108, the packet is routed through network layer protocol 224 and then link layer protocol 225 to the next router on the Internet (not shown). Sent. In this manner, IP packets from the MS 110 are conveyed via the BS / MSC 106 and the IWF 108 to the final intended destination in the Internet according to the IS-707.5 standard relay model. .
[0013]
Before the MS 110 packet reaches its destination, a data link connection must first be established. As specified in RFC 1661, in this data link connection, each end of the point-to-point link (ie, PPP protocols 206 and 226) first sends a packet to the PPP link control protocol (Link Control Protocol, LCP). There is a need to set up, configure and test data link connections. After the link is set up by the LCP, the PPP protocol 206 sends a Network Control Protocol (NCP) packet to configure the

network layer protocols

204 and 224. The NCP for IP on the PPP link is the IP Control Protocol (IPCP). IPCP is described in detail in Request For Comment 1332 (RFC 1332), which was issued in May 1992 under the title "THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)". However, before IPCP negotiation, an authentication phase is required. After each network layer protocol is configured, packets from each network layer protocol are sent over the link between the protocols.
[0014]
B. Most, if not all, of the processes that support the communication protocol stack on application program interface MS110 are performed by application programs. In general, a conventional data network employs an application program interface (API) to enable communication between an application program executed on one computer and an application program executed on another computer. ing. The API uses "sockets" to protect the calling application by differences in the protocols of the underlying network. In order to achieve inter-networked communication, the API includes a function that allows an application to open a socket, send data to the network, receive data from the network, and close the socket, for example. (Function) is included. The communication interface of the communication network includes a socket interface of the Berkeley System Development (BSD) operating under the Unix (trademark) operating system, and a socket interface of the Windows (trademark) operating system. Windows (trademark) Sockets Interface (WinSock (trademark)) that operates under its own.
[0015]
Since neither the BSD socket nor WinSock (TM) support the communication protocol stack on the wireless MS 110 (see FIG. 2), a novel API that supports such a stack is needed. In particular, there is a need for a novel method and apparatus for a mobile station application to identify a specified status message in a wireless communication system.
[0016]
SUMMARY OF THE INVENTION The present invention addresses the needs identified above by providing a method and apparatus for an application of a mobile station to identify a designated status message in a wireless communication system. In one configuration, the invention includes a communication protocol stack of a mobile station communicating with a communication network, and an application program interface (API) that facilitates communication between applications of the mobile station. The mobile station application calls the function. The API selects at least one of the specified status messages based on its state and the function invoked. The API then reports the selected designated status message to the mobile station application.
[0017]
DETAILED DESCRIPTION Embodiments of the present invention may be implemented in various configurations including software, firmware, and / or hardware. Thus, while the operations and behaviors of the present invention have been described without specific reference to software code or hardware components, those of ordinary skill in the art will appreciate the description herein. It will be appreciated that the software and / or hardware making up the present invention can be designed based on this, so that the mobile station application can identify the specified status message.
[0018]
FIG. 3 shows the application 260, the communication protocol stack 280, and the API 270 in the MS 110. Application 260 and communication protocol stack 280 (ie, protocol layers 202, 204, 206, 208, 210, 212) communicate via a function call provided by API 270. In other words, the API 270 allows the application 260 and the communication protocol stack 280 to run on different processors and operating systems without compromising functionality. Those skilled in the art will recognize that various names for the called function are possible without departing from the scope of the invention.
[0019]
It should be noted that communication protocol stack 280 includes a plurality of transmit and receive queues, which store data. The output function reads data from the memory of the application 260 and stores the data in one of the transmission queues of the communication protocol stack 280. The input function reads data from one of the reception queues of the communication protocol stack 280 and stores the data in the memory of the application 260.
[0020]
To indicate operation, MS 110 receives an IP packet. The communication protocol stack 280 of the MS 110 unencapsulates the IP packets and sends them to the transport layer 202 (see FIG. 3). One field in the IP packet header indicates the transport and includes either TCP or UDP. Based on the destination port number specified in the transport layer header, the data is routed to the appropriate receive queue of the communication protocol stack 280 corresponding to the particular socket. The data is then sent to application 260.
[0021]
In certain circumstances, it may be desirable to operate with packets that bypass various layers of the protocol stack 280 to reduce the effects of latency. Such a packet contains raw packetized data, such as a raw IP packet, but lacks destination information (ie, destination port number). Therefore, the destination application cannot determine from the raw IP packet. In such a situation, the communication protocol stack 280 sends the received raw IP packet to all sockets registered to support, for example, the IP protocol. In this way, the payload data is sent to the destination application. The parsing engine of the Internet Control Messaging Protocol (ICMP) can also receive raw packetized data in response to IP packets. A well-known ICMP parsing engine is specified in RFC 792 under the title "INTERNET CONTROL MESSAGE PROTOCOL". Thus, it is clear that the communication protocol stack 280 processes the received packet and then forwards the packet up the stack to the application 260, reducing the amount of application 260 de-encapsulation.
[0022]
Conversely, the application 260 may send raw packetized data through the Um interface by using sockets to facilitate communication between the communication protocol stack 280 and the application 260. In addition, application 260 can send raw packetized data through the Um interface. The communication protocol stack 280 also encapsulates, for example, packetized or raw packetized data into IP packets and sends them through the Um interface. In this example, the communication protocol stack 280 prepares an IP header and a checksum and generates an IP packet. On the other hand, in ICMP, the specified protocol type is copied into the IP header.
[0023]
As described above, the application 260 creates a socket, and the socket communicates data between at least one of the protocol layers 202, 204, 206, 208, 210, 212 and the application 260 using the communication protocol stack 280. To be able to reduce the waiting time that always occurs. Thus, application 260 creates a socket, which bypasses transport layer 202, network layer 204, and link layer 206, allowing application 260 to send and receive payload data to and from RLP layer 210. In addition, the application 260 creates a socket, which allows the application 260 to send and receive payload data to and from the IS-95 layer 212.
[0024]
In one embodiment, the application 260 has the function open Call netlib () to open the communication protocol stack 280 and assign an application identity. Having identified the applications, multiple applications can communicate with communication protocol stack 280 (ie, multitasking). For example, the function open As part of the call to netlib (), the application 260 specifies pointers to network and socket callback functions. A specified event of the network subsystem is generated (or enabled), such as reading from, writing to, and closing it from the traffic channel (ie, Um) and / or link layer (ie, PPP 206). Each time, the network callback function is invoked to notify the application 260. Each time a specified socket event is generated (or enabled), such as reading from, writing to, or closing from the transport layer (ie, TCP), the socket callback function is invoked and sent to the application 260. Be informed. It will be apparent to those skilled in the art that a communication network includes at least one of a traffic channel, a link layer, and a transport layer.
[0025]
When the communication protocol stack 280 is opened, the function pppopen () is called to initiate the connection of the network subsystem including the traffic channel and link layer. This is an application-wide call and does not depend on individual sockets. However, this requires identification of the application. When the connection of the network subsystem is set up or fails, the network callback function is invoked to notify the specified event. For example, when no traffic channel is set, the network subsystem fails. In addition, a feature of the network subsystem is the function net. Set by calling ioctl (). This call specifies, for example, the data rate of the socket.
[0026]
Once the network subsystem connection is set up, a socket is created and initialized by calling the function socket (). However, the function socket () may be called to return the socket descriptor before the socket's function is available. Next, the application 260 has the function asyn. Call select () to register the specified event and receive an asynchronous notification. This registration is performed by the application 260 as part of the function call and specifies the socket descriptor and bitmask of the notification required for the specified event (ie, multiple events are OR'ed). When the specified event is generated (ie, enabled) and detected by, for example, the communication protocol stack 280 or API 270, the socket callback function is invoked to provide an asynchronous notification. The callback function can notify the application 260 of a specified event by using a signal, message, eg, a message about a remote procedure call (RPC), or a hardware or software interrupt. it can.
[0027]
When notified about the specified event, the application 260 calls the function getnextevent (), determines the specified event, and provides a service. This function returns the specified event mask generated to the specified socket descriptor. In addition, this function clears the bits in the generated mask of the specified event. Therefore, the application 260 can no longer receive notification of the disabled specified event. The application 260 then has the function async These specified events must be re-registered (ie, re-enabled) by calling select ().
[0028]
In addition, the application 260 modifies the registered specified event by clearing the corresponding bit in the specified event bitmask. If the bit has already been cleared in the bit mask, the request is simply ignored. Briefly, notification of an event is, for example, a function async It is disabled on an event-by-event basis by calling deselect ().
[0029]
4 and 5 are flowcharts for detecting a designated event. As shown in FIG. 4, for example, at block 400, the communication protocol stack 280 waits for the application 260 to register for the specified event. Once the specified event has been registered, at block 402, the communication protocol stack 280 polls the memory. At block 404, a designated event is detected based on the polled information of block 402. At block 406, a write event is detected, for example, when the memory (ie, transmission queue) of the communication protocol stack 280 is available to accept a sufficient amount of data. Data is sent from the application 260. If the information polled at block 404 is not sufficient (ie, the specified event was not generated), communication protocol stack 280 continues to poll memory, as at block 402.
[0030]
In FIG. 5, as shown at block 500, the communication protocol stack 280 waits for the application 260 to register for the specified event. During this time, interrupt notifications are disabled. Thus, an interrupt notification cannot be triggered or triggered. After the specified event is registered at block 500, an interrupt notification is triggered at block 502 based on the generation of the specified event. For example, when data is written to the memory of the communication protocol stack 280 (ie, the receive queue), a read event is generated. Thus, at block 504, when the communication protocol stack 280 receives an interrupt notification triggered by the generation of an event, the communication protocol stack 280 detects a read event. Data stored in the memory of the communication protocol stack 280 is sent from the communication network. Further, the data stored in the read event is sent to the application 260.
[0031]
Finally, when the socket is available for reuse, the data link connection is closed, as in the transport layer, so a closure event is detected.
[0032]
The following examples of asynchronous connection (see FIG. 6) and asynchronous input (see FIG. 7) illustrate the use of asynchronous event notification.
[0033]
Referring to FIG. 6, the function open Calling netlib () enters the communication protocol stack 280 and specifies a callback function. When the function pppopen () is called (A), the connection of the network subsystem starts (B). After the network subsystem connection has been set up, the callback function is invoked (C), reporting that the network subsystem is available.
[0034]
Assuming that the socket is opened and allocated, the function connect () is called (D) and the TCP connection is started (E). Further, the application 260 has the function async. When select () is called (F), the designated event is registered and a notification is received. In this example, the specified event of interest is a write event, which is generated when setting up the connection.
[0035]
When setting up a connection, if the specified event is registered in the mask, a callback function is invoked. At that time, the callback function is called (G) and an asynchronous notification is given. When the application 260 receives the notification, it calls the function getnextevent () (H) and determines any specified event generated (I). In addition, the call clears the event (ie, write event) bit in the mask (J). The application 260 has the function asyn The next notification of the specified event must be re-registered by calling select ().
[0036]
FIG. 7 shows asynchronous socket reading. To start reading, application 260 calls function read () (A). If it is assumed that there is no data to read, the application 260 Call select () (B) to register the event (ie, set the corresponding bit in the mask) and receive the notification. In this example, the specified event of interest is a read event, and the read event is generated when there is data to be read by application 260.
[0037]
When storing data in the receive queue, a callback function is invoked when a read event is specified in the mask. At that time, the callback function is called (C) to give an asynchronous notification. Upon receiving the notification, the application 260 calls the function getnextevent () (D) and determines which event is generated (E). In addition, this call clears the bit of the event in the mask (F). The application 260 has the function asyn The next notification of the event must be re-enabled by calling select (). Finally, to read the data stored in the receive queue, application 260 calls function read () (G).
[0038]
8 to 10 show a state machine according to an embodiment of the present invention. In FIGS. 8-10, the communication protocol stack 280 is open and the network subsystem connections (ie, traffic channels and, if necessary, link layer connections-raw sockets bypass the network subsystem) are set up. It is assumed that Those skilled in the art will recognize that various names for the states are possible without departing from the scope of the invention.
[0039]
State machines can transition between states asynchronously and control (i.e., enable and disable) specified events such as read, write, and close. The designated events are disabled at the beginning of the operation and are enabled in certain states to help the application 260 identify the state of the MS 110.
[0040]
In addition, the API 270 reports specific (ie, not just general) specified status messages to the application 260 based on the state of the API 270 and the type of function invoked by the application 260. The specified status message reflects the state of the underlying communication network. The status message is reported to the application 260, for example, as an argument for a function call.
[0041]
FIG. 8 shows a state diagram of a TCP socket of the API 270, for example. Uninitialized sockets begin with a "null" state 800. The socket does not "exist" because it has not been allocated at this time. The socket is created and initialized by calling the function socket () and returns a socket descriptor to use the functions associated with the socket. After calling the function socket (), the state machine transitions to an “initialization” state 805.
[0042]
In the initialization state 805, the state machine transitions back to the null state 800 each time the TCP connection can be terminated by calling the function close (). Calling the function close () releases resources associated with all sockets. On the other hand, calling the function connect () initiates a TCP connection and the state machine transitions to the “opening” state 810.
[0043]
In the opening state 810, the state machine is in a "closed" state each time (1) the network subsystem fails, (2) the TCP connection setup fails, or (3) the IP address changes. Transition is made to 815. In addition, after calling the function close () that terminates the TCP connection, the state machine transitions the socket to a “closing” state 820, while the termination procedure is initiated. Finally, when a TCP connection is established, the state machine transitions to an "open" state 825.
[0044]
In the open state 825, the socket is open for reading and writing. In particular, write events are enabled immediately and read events are enabled based on whether data is stored in the memory of communication protocol stack 280. Attempts to terminate a TCP connection, such as (1) when the network subsystem fails, (2) when it fails to set up a TCP connection, or (3) TCP reset, TCP abort, or TCP close. The state machine transitions to the closed state 815 each time the network server starts and (4) the IP address changes. The state machine transitions to the closing state 820 when the application starts terminating the TCP connection, for example, by calling the function close ().
[0045]
In the closed state 815, read, write, and close events are all asserted. After calling the function close () that terminates the TCP connection, the state machine transitions the socket to the null state 800, releasing the socket and making it available for reuse.
[0046]
In the closing state 820, (1) when the network subsystem fails, (2) when the network server initiates an attempt to terminate the TCP connection, for example, reset TCP or close TCP, (3) timer Each time the time expires and (4) the IP address changes, the state machine transitions to state 830 of "waiting for closure". To prevent delays when terminating a TCP connection, API 270 includes a timer that runs when initiating termination of a TCP connection. It will be noted that upon expiration of the timer, the state machine transitions to state 830 to wait for closure.
[0047]
In the wait-for-close state 830, the function close () is called to terminate the TCP connection and transition the state machine to the null state 800. The close event is asserted in this state 830.
[0048]
Table 1-3 shows the specified status messages supported by API 270. In the null state (not shown in Tables 1-3), a descriptive designated status message, "no additional resources are available" is reported to application 260.
[0049]
[Table 1]

[0050]
[Table 2]

[0051]
[Table 3]

[0052]
By way of example, FIG. 9 shows a state diagram of the UDP socket of API 270. An uninitialized socket starts in a "null" state 900. As described above for null state 800, the socket does not "exist" because it has not been allocated. A socket is created and initialized by calling the function socket () and returns a descriptor of the socket for use by functions related to the socket. After calling the function socket (), the state machine transitions to an “open” state 905.
[0053]
In the open state 905, the socket is open for reading and writing. In particular, write events are enabled immediately, while read events are enabled based on whether data is stored in communication protocol stack 280 memory. The state machine transitions to a "closed" state 910 whenever the network subsystem fails. For example, by calling the function close (), the application initiates the termination of the UDP connection and transitions the state machine to the null state 900.
[0054]
In the closed state 910, the read, write, and closed states are all enabled. After calling the function close () to terminate the UDP connection, the state machine transitions the socket to the null state 900, releasing the socket and making it available for reuse.
[0055]
Tables 4-6 show the specified status messages supported by API 270. In the null state (not shown in Tables 4-6), the previously specified status message "no additional resources are available" is reported to application 260.
[0056]
[Table 4]

[0057]
[Table 5]

[0058]
[Table 6]

[0059]
FIG. 10 shows a state diagram for controlling network subsystems such as the traffic channel (ie, Um) and the link layer (ie, PPP 206). Open the network subsystem by invoking the function open netlib () and initialize the socket to the “closed” state 1000. Calling the function pppopen () initiates the connection of the network subsystem and transitions the socket to the “opening” state 1005. In addition, a page to MS 110 due to an incoming PPP call transitions the socket to opening state 1005. In both cases, if the negotiation is successful, MS 110 attempts to synchronize and set both RLP and PPP on the traffic channel.
[0060]
In the opening state 1005, the socket transitions to an "open" state 1010 when a connection of the network subsystem is established. On the other hand, if the network subsystem connection has not been set up, the socket transitions back to the closed state 1000.
[0061]
In the open state 1010, the callback function is invoked to identify specified events of the application 1060, such as enabled reads, writes, and closures. At this time, the MS 110 can communicate using a traffic channel. However, the socket transitions to the closed state 1000 each time the network subsystem fails and invokes the callback function. For example, by calling the function close (), the application initiates termination of the network subsystem connection and transitions the socket to a “closed” state 1015.
[0062]
In the closing state 1015, the socket transitions to the closed state 1000 every time the connection of the network subsystem ends. In the closed state 1000, the callback function is invoked to identify the specified event of the enabled application 260.
[0063]
Table 7 shows the specified status messages corresponding to specific function calls and supported by API 270.
[0064]
[Table 7]

[0065]
[Table 8]

[0066]
[Table 9]

[0067]
[Table 10]

[0068]
[Table 11]

[0069]
[Table 12]

[0070]
[Table 13]

[0071]
[Table 14]

[0072]
In another embodiment, the machine reads a machine readable medium that includes coded information, such as coded software code, so that the mobile station application can identify the specified status message. Perform the above process. The machine-readable medium receives the encoded information from a storage device, such as a memory or storage disk, or from a communication network. In addition, the machine-readable medium is programmed with the encoded information when manufactured. The machine includes at least one of application 260, communication protocol stack 280, and API 270, while the machine's readout medium includes a memory or storage disk.
[0073]
Although the present invention has been shown in connection with particular embodiments, it is not intended to be so limited. Rather, the invention is limited only by the claims and the equivalents thereof.
[Brief description of the drawings]
FIG.
1 is a high-level block diagram (in the prior art) of a wireless communication system in which a mobile station is connected to the Internet.
FIG. 2
FIG. 3 (in the prior art) schematically illustrates a protocol stack at each entity of the TIA / EIA IS-707.5 relay model.
FIG. 3
FIG. 1 is a diagram schematically showing features of an embodiment of the present invention.
FIG. 4
9 is a flowchart for detecting a specified event.
FIG. 5
9 is a flowchart for detecting a specified event.
FIG. 6
FIG. 2 is a block diagram showing an asynchronous connection.
FIG. 7
FIG. 4 is a block diagram illustrating asynchronous socket input.
FIG. 8
The state diagram of the embodiment of the present invention.
FIG. 9
The state diagram of the embodiment of the present invention.
FIG. 10
The state diagram of the embodiment of the present invention.

Claims

A method for a mobile station application to identify a plurality of designated status messages,
Communicating between the mobile station's communication protocol stack and the communication network;
Communicating through the mobile station application interface between the mobile station communication protocol stack and the mobile station application;
Calling the function by the mobile station application;
Selecting at least one of the specified status messages by the mobile station application interface based on the state of the mobile station application interface and the called function;
Reporting at least one of the specified status messages to the mobile station application by an interface of the mobile station application.

The method of claim 1, wherein the mobile station application interface reports at least one of the status messages specified by the verification of the invoked function to the mobile station application.

The method of claim 1, wherein the interface of the mobile station application includes a plurality of states.

4. The method of claim 3, wherein the interface of the mobile station application transitions between states asynchronously.

A device for an application of a mobile station to identify a plurality of designated status messages,
A mobile station communication protocol stack for communicating with the communication network;
A mobile station application for invoking the function;
A mobile station application interface for selecting at least one of the designated status messages based on a state of the mobile station application interface and the called function;
The interface of the mobile station application is adapted to enable communication between the mobile station application and the mobile station communication protocol stack; and
A device wherein an interface of a mobile station application is adapted to report at least one of the specified status messages to the mobile station application.

The apparatus of claim 5, wherein the interface of the mobile station application is adapted to report at least one of the status messages specified by the verification of the invoked function to the mobile station application.

The apparatus of claim 5, wherein the interface of the mobile station application includes a plurality of states.

The apparatus of claim 7, wherein the interface of the mobile station application is adapted to transition asynchronously between states.

A machine-readable medium containing encoded information, wherein when read by a machine,
A process for communicating between a communication protocol stack of a mobile station and a communication network;
Communicating between the mobile station communication protocol stack and the mobile station application through the mobile station application interface;
The process of invoking the function through the interface of the mobile station application;
Selecting at least one of the specified status messages by the mobile station application interface based on the state of the mobile station application interface and the called function;
Reporting at least one of the specified status messages to the mobile station application by an interface of the mobile station application.

10. The machine-readable medium of claim 9, wherein the mobile station application reports at least one of the status messages specified by the verification of the called function to the mobile station application.

The method of claim 9, wherein the interface of the mobile station application comprises a plurality of states.

The method of claim 11, wherein an interface of a mobile station application transitions between states asynchronously.