JP2004500785A - 移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置 - Google Patents
移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置 Download PDFInfo
- Publication number
- JP2004500785A JP2004500785A JP2001573821A JP2001573821A JP2004500785A JP 2004500785 A JP2004500785 A JP 2004500785A JP 2001573821 A JP2001573821 A JP 2001573821A JP 2001573821 A JP2001573821 A JP 2001573821A JP 2004500785 A JP2004500785 A JP 2004500785A
- Authority
- JP
- Japan
- Prior art keywords
- mobile station
- application
- station application
- interface
- function
- 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.)
- Withdrawn
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本発明は、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置を記載している。本発明はアプリケーションプログラムインターフェイス(application program interface, API)を含み、APIは通信ネットワークと通信する移動局の通信プロトコルのスタックと、移動局のアプリケーションとの間の通信を容易にする。移動局のアプリケーションは機能を呼出す。APIは、指定された状況メッセージの少なくとも1つを、その状態および呼出された機能に基づいて選択する。次にAPIは、選択した指定された状況メッセージを移動局のアプリケーションへ報告する。
【選択図】 図3
【選択図】 図3
Description
【0001】
背景
1.発明の分野
本発明は、概ね、無線通信の分野に関する。とくに、本発明は無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別できるようにする斬新な方法および装置に関する。
【0002】
2.関係する技術の記述
A.無線通信
無線通信およびコンピュータに関係する技術における最近の革新、並びにインターネット加入者の今までにない増加によって、モバイルコンピューティングへの道が開かれた。事実、モバイルコンピューティングの大衆性により、現在のインターネットのインフラストラクチャに対して、モバイルのユーザにより多くのサポートを与える要求が強まった。このインフラストラクチャの原動力は、種々のサービスを提供するパケット指向のインターネットプロトコル(Internet Protocol, IP)であり、種々のサービスには、パケット(データグラム)をローカルエリアネットワーク(local area network, LAN)とワイドエリアネットワーク(wide area network, WAN)との間でアドレス指定してルート設定するサービスが含まれる。IPプロトコルは、Request For Comment(RFC 791)(“INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, 1981 9)において規定されている。
【0003】
IPプロトコルは、送信のためにデータをIPパケットへカプセル化するネットワーク層プロトコルである。アドレス指定およびルート設定の情報はパケットのヘッダに付される。IPヘッダには、例えば送信ホストおよび受信ホストを識別する32ビットのアドレスが含まれている。中間のルータはこれらのアドレスを使用して、パケットを、意図されたアドレスをもつその最終的な宛先へ向わせるためのネットワーク上の経路を選択する。したがって、IPプロトコルにより、世界中の何れかのインターネットノードにおいて発信されたパケットを、世界中の他の何れかのインターネットノードへルート設定することができる。これに対して、特定のアプリケーションに対処するためには、伝送制御プロトコル(Transmission Control Protocol, TCP)またはユーザデータグラムプロトコル(User Datagram Protocol, UDP)の何れかを含むトランスポート層が使用される。
【0004】
現在の傾向では、モバイルのユーザはラップトップまたはパームトップコンピュータのようなモバイルコンピュータを、セルラまたは携帯電話のような無線通信デバイスと共に使用して、インターネットにアクセスしている。したがって、ちょうど、従来からユーザが“有線の”通信デバイスを使用してコンピュータを陸上ネットワーク(land−based network)へ接続していたように、モバイルのユーザは一般的に“移動局”(mobile station, MS)と呼ばれる無線通信デバイスを使用してモバイル端末をこのようなネットワークへ接続する。本明細書で使用しているように、移動局またはMSは、公共の無線ラジオネットワーク(wireless radio network)の加入者局を指す。
【0005】
(従来技術を示している)図1は、無線データ通信システムの高レベルのブロック図を示しており、この中でMS110は基地局/移動局スイッチングセンタ(Base Station/Mobile Switching Center, BS/MSC)106を介して相互接続機能(Interworking Function, IWF)108と通信する。IWF108は、インターネットへのアクセス点として働く。IWF108はBS/MSC106に接続されていて、一緒に位置していることも多く、BS/MSC106はこの技術において知られているように従来の無線基地局であってもよい。無線データ通信システムに対処する別の標準プロトコルは、“WIRELESS IP NETWORK STANDARD”というタイトルで1999年12月に発行された第3世代パートナーシッププロジェクト2(3rd Generation Partnership Project 2, “3GPP2”)である。3G無線IPネットワークの標準規格には、例えば、IWF108のように機能するパケットデータ供給ノード(Packet Data Serving Node, PDSN)が含まれる。
【0006】
種々のプロトコルが、MS110とIWF108との間のデータ通信に対処している。例えば、米国電気通信工業会(Telecommunications Industry Association, TIA)/電子機械工業会(Electronics Industries Association, EIA)の暫定的標準規格(Interim Standard)のIS−95は、“MOBILE STATION−BASE STATION COMPATIBILITY STANDARD FOR DUAL−MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM”というタイトルで1993年7月に発行されていて、これは概して広帯域拡散スペクトル無線通信システムの標準規格を与えている。さらに加えて、標準規格のTIA/EIA IS−707.5は、“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルで1998年2月に発行されていて、これはTIA/EIA IS−95のシステムのパケットデータ伝送能力のサポート要件を規定し、BS/MSC106を介してのMS110とIWF108との間の通信に使用できるパケットデータ伝達サービスを指定している。さらに加えて、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルのTIA/EIA IS−707−A.5の標準規格と、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: HIGH−SPEED PACKET DATA SERVICES”というタイトルのTIA/EIA IS−707−A.9の標準規格とは、両者とも1999年3月に発行されており、これらもTIA/EIA IS−95のシステムのパケットデータ伝送のサポート要件を規定している。さらに加えて、MS110とIWF108との間の通信に対処している別の標準規格のプロトコルにはTIA/EIA IS−2000があり、これは“INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS”というタイトルで1999年7月に発行されている。
【0007】
IS−707.5では、MS110とBS/MSC106(Umインターフェイス)との間およびBS/MSC106とIWF108(Lインターフェイス)との間の通信プロトコルのオプションモデルを取り入れている。例えば、中継モデルは、ポイント−ツウ−ポイントプロトコル(Point to Point Protocol, PPP)のリンクがMS110とIWF108との間のUmインターフェイス上に存在している情況を表わしている。PPPプロトコルは、Request For Comment(RFC 1661)(“THE POINT−TO−POINT PROTOCOL (PPP)”)に詳しく記載されている。
【0008】
(従来技術を示している)図2は、IS−707.5の中継モデルの各エンティティ内のプロトコルスタックの図である。図の左端には、従来の垂直形のフォーマットで示された通信プロトコルスタックが記載されており、これはMS110上で実行されるプロトコル層を示している。MS110のプロトコルスタックは、Umインターフェイスを通してBS/MSC106のプロトコルスタックへ論理的に接続されているように示されている。また、MS/MSC106のプロトコルスタックは、Lインターフェイスを通してIWF108のプロトコルスタックへ論理的に接続されているように示されている。
【0009】
図2は次に記載する動作が行われることを示している。すなわち、MS110上で実行される上位層プロトコル200のエンティティ、例えばアプリケーションプログラムは、インターネットを通してデータを送る必要がある。代表的なアプリケーションには、ウエブブラウザプログラム(例えば、Netscape Navigator(ネットスケープナビゲータ)(商標)、Microsoft Internet explorer(マイクロソフトインターネットエクスプローラ)(商標))がある。ウエブブラウザには、ハイパーリンク“http://www.Qualcomm.com/”のようなユニバーサルリソースロケータ(Universal Resource Locator, URL)が必要である。同じく上位層プロトコル200内のドメイン名システム(Domain Name System (DNS))プロトコルはドメイン名の分解(resolution)を使用して、名前をインターネットのアドレスへ変換することによって、テキストホスト名www.Qualcom.comを32ビットの数字のIPアドレスへ変換する。同じく上位層プロトコル200であるハイパーテキスト転送プロトコル(Hypertext Transfer Protocol, HTTP)は、要求されているURLのためのGETメッセージを作成し、このメッセージを送るのに使用されるTCPおよびHTTPの動作を指定する。トランスポート層202では、宛先ポートとして、この技術において使用されているポート80を使用して、HTTPの動作をアプリケーションへルート設定する。
【0010】
TCPプロトコルは、トランスポート層プロトコル202であり、DNSによって指定されるIPアドレスとの接続を開き、アプリケーションレベルのHTTPのGETメッセージを送る。TCPプロトコルでは、IPプロトコルを使用してメッセージを転送することを指定している。IPプロトコルはネットワーク層プロトコル204であり、TCPパケットを指定されたIPアドレスへ送る。PPPはリンク層プロトコル206であり、IPパケットをコード化し、それらを中継層プロトコル208へ送る。中継層プロトコル208は、例えば、TIA/EIA−232Fの標準規格であり、TIA/EIA−232Fの標準規格は“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”とが含まれる。最後に、PPPパケットは中継層プロトコル208から無線リンクプロトコル(Radio Link Protocol, RLP)210、次にIS−95プロトコル212を経由して、Umインターフェイスを通してBS/MSC106へ送られる。RLPプロトコル210はIS−707.2の標準規格に規定されており、IS−707.2の標準規格は“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL”というタイトルで1998年2月に発行されていて、IS−95プロトコルは上述で識別したIS−95の標準規格に規定されている。
【0011】
PPPパケットはUmインターフェイスを通してBS/MSC106上のIS−95の層218、次にRLPの層216へ送られ、相補的な中継層プロトコル220によって受信される。中継層プロトコル220は、このPPPパケットをLインターフェイスを通してIWF108上の中継層プロトコル228へ送る。IWF108上のPPPプロトコルリンク層226が中継層プロトコル228からPPPパケットを受信すると、MS110とIWF108との間のPPP接続は終了する。パケットは、IWF108上のPPP層226からIP層224へ送られ、IP層224では最後のルート設定のためにIPパケットのヘッダ(このシナリオではwww.Qualcomm.comである)を調べる。
【0012】
MS110によって生成されたIPパケットの最終的な宛先がIWF108ではないと仮定すると、パケットはネットワーク層プロトコル224、さらにリンク層プロトコル225を経由して、インターネット上の次のルータ(図示されていない)へ送られる。このやり方では、MS110からのIPパケットは、IS−707.5の標準規格の中継モデルにしたがって、BS/MSC106、およびIWF108を経由して、インターネット内の最終的な意図された宛先へ伝達される。
【0013】
MS110のパケットがその宛先へ到達する前に、先ずデータリンク接続が設定されなければならない。RFC1661に指定されているように、このデータリンク接続では、先ずポイント−ツウ−ポイントリンクの各終端(すなわち、PPPプロトコル206および226)がPPPリンク制御プロトコル(Link Control Protocol, LCP)へパケットを送って、データリンク接続を設定し、構成し、試験することが求められている。LCPによってリンクが設定された後で、PPPプロトコル206はネットワーク制御プロトコル(Network Control Protocol, NCP)のパケットを送って、ネットワーク層プロトコル204および224を構成する。PPPリンクにおけるIPのためのNCPはIP制御プロトコル(IP Control Protocol, IPCP)である。IPCPは、Request For Comment 1332(RFC 1332)に詳しく記載されており、RFC 1332は“THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)”というタイトルで1992年5月に発行されている。しかしながら、IPCPのネゴシエーションの前には、認証段階が必要である。各ネットワーク層プロトコルが構成された後では、各ネットワーク層プロトコルからのパケットは、プロトコル間のリンクを通して送られる。
【0014】
B.アプリケーションプログラムインターフェイス
MS110上の通信プロトコルスタックをサポートするプロセスは、その全てではないが、ほとんどがアプリケーションプログラムによって実行される。一般的に従来のデータネットワークでは、アプリケーションプログラムインターフェイス(application program interface, API)を採用して、あるコンピュータ上で実行されるアプリケーションプログラムと別のコンピュータ上で実行されるアプリケーションプログラムとの通信を可能にしている。APIは“ソケット”を使用して、基礎ネットワークのプロトコルの相違によって、呼出しているアプリケーションを保護する。ネットワーク間の通信(inter−networked communication)を実現するために、APIには、アプリケーションが、例えばソケットを開き、データをネットワークへ送り、ネットワークからデータを受信し、ソケットを閉じることを可能にする機能(function)が含まれている。通信ネットワークのプログラミングインターフェイスには、Unix(ユニックス)(商標)のオペレーティングシステムのもとで動作するバークレイシステム開発(Berkeley System Development, BSD)のソケットインターフェイス、およびWindows(ウインドウズ)(商標)のオペレーティングシステムのもとで動作するWindows(ウインドウズ)(商標)Sockets Interface(ソケットインターフェイス) (WinSock(ウインソック)(商標))が含まれる。
【0015】
BSDソケットもWinSock(ウインソック)(商標)の何れも無線MS110上の通信プロトコルスタック(図2参照)をサポートしていないので、このようなスタックをサポートする斬新なAPIが必要である。とくに、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための斬新な方法および装置が必要とされている。
【0016】
本発明の概要
本発明では、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置を提供することによって、上述で識別した必要に対処している。1つの構成では、本発明は、通信ネットワークと通信する移動局の通信プロトコルスタックと、移動局のアプリケーションとの間の通信を容易にするアプリケーションプログラムインターフェイス(application program interface, API)を含んでいる。移動局のアプリケーションは機能を呼出す。APIは、その状態と呼出された機能とに基づいて、指定された状況メッセージの少なくとも1つを選択する。次にAPIは、選択した指定された状況メッセージを移動局のアプリケーションへ報告する。
【0017】
詳細な記述
本発明の実施形態は、ソフトウエア、ファームウエア、および/またはハードウエアを含む種々の構成において実現することができる。したがって、本発明の動作および働き(behavior)はソフトウエアコードまたはハードウエアの構成要素をとくに参照せずに記載されているが、この技術において普通の技能をもつ人には、本明細書の記述に基づいて、本発明を構成するソフトウエアまたはハードウエア、あるいはこの両者を設計でき、これにより移動局のアプリケーションが指定された状況メッセージを識別できることが分かるであろう。
【0018】
図3には、MS110内のアプリケーション260、通信プロトコルスタック280、およびAPI270が示されている。アプリケーション260および通信プロトコルスタック280(すなわち、プロトコル層202、204、206、208、210、212)は、API270によって与えられる機能呼出し(function call)によって通信する。言い換えると、API270は、アプリケーション260および通信プロトコルスタック280を機能を損わずに異なるプロセッサおよびオペレーティングシステム上で実行できるようにする。当業者には、本発明の技術的範囲から逸脱することなく、呼出された機能に対して種々の名前が可能であることが分かるであろう。
【0019】
通信プロトコルスタック280には、複数の送信待ち行列と受信待ち行列とが含まれていて、これらの待ち行列はデータを記憶することに注意すべきである。出力機能では、アプリケーション260のメモリからデータを読出し、そのデータを通信プロトコルスタック280の送信待ち行列の1つへ記憶する。入力機能では、通信プロトコルスタック280の受信待ち行列の1つからデータを読出し、そのデータをアプリケーション260のメモリへ記憶する。
【0020】
動作を示すために、MS110はIPパケットを受信する。MS110の通信プロトコルスタック280は、IPパケットを逆カプセル化して(unencapsulate)、それらをトランスポート層202へ送る(図3参照)。IPパケットヘッダ内の1つのフィールドはトランスポートを示していて、TCPまたはUDPの何れかでを含む。トランスポート層のヘッダにおいて指定されている宛先ポートの番号に基づいて、データは、特定のソケットに対応する通信プロトコルスタック280の適切な受信待ち行列へルート設定される。次にデータは、アプリケーション260へ送られる。
【0021】
一定の情況では、プロトコルスタック280の種々の層をバイパスするパケットを使用して動作して、待ち時間の影響を軽減することが望ましい。このようなパケットには、生のIPパケットのような生のパケット化されたデータが含まれているが、これには宛先の情報(すなわち、宛先ポートの番号)が欠けている。したがって、宛先のアプリケーションは、生のIPパケットから判断できない。このような情況では、通信プロトコルスタック280は受信した生のIPパケットを、例えばIPプロトコルをサポートするために登録されている全てのソケットへ送る。このようにしてペイロードデータは宛先のアプリケーションへ送られる。インターネット制御メッセージングプロトコル(Internet Control Messaging Protocol, ICMP)のパーシングエンジンはIPパケットに応答して、生のパケット化されたデータも受信することができる。周知のICMPのパーシングエンジンは、“INTERNET CONTROL MESSAGE PROTOCOL”というタイトルでRFC 792に規定されている。したがって、通信プロトコルスタック280は、受信したパケットを処理し、その後でパケットをスタックを逆上ってアプリケーション260へ送り、アプリケーション260が逆カプセル化する量を低減することが明らかである。
【0022】
逆に、アプリケーション260は、ソケットを使用することによって生のパケット化されたデータをUmインターフェイスを通して送り、通信プロトコルスタック280とアプリケーション260との間の通信を容易にすることもできる。さらに、アプリケーション260は、生のパケット化されたデータをUmインターフェイスを通して送ることもできる。また、通信プロトコルスタック280は、例えばパケット化された、または生のパケット化されたデータをIPパケットへカプセル化し、それらをUmインターフェイスを通して送る。この例では、通信プロトコルスタック280はIPヘッダおよびチェックサムを用意して、IPパケットを生成する。他方で、ICMPでは、指定されたプロトコルのタイプはIPヘッダへコピーされる。
【0023】
既に記載したように、アプリケーション260はソケットを生成し、ソケットはプロトコル層202、204、206、208、210、212の少なくとも1つとアプリケーション260との間のデータ通信が、通信プロトコルスタック280を使用するときに必ず伴う待ち時間を低減できるようにする。したがってアプリケーション260はソケットを生成し、ソケットはトランスポート層202、ネットワーク層204、およびリンク層206をバイパスして、アプリケーション260がRLP層210との間でペイロードデータを送受信できるようにする。さらに加えて、アプリケーション260はソケットを生成し、ソケットはアプリケーション260がIS−95の層212との間でペイロードデータを送受信できるようにする。
【0024】
1つの実施形態では、アプリケーション260は機能open netlib()を呼出して、通信プロトコルスタック280を開き、アプリケーションの識別を割り当てる。アプリケーションを識別すると、多数のアプリケーションが通信プロトコルスタック280と通信すること(すなわち、マルチタスキング)ができる。例えば、機能open netlib()の呼出しの一部として、アプリケーション260はネットワークコールバック機能およびソケットコールバック機能へのポインタを指定する。トラヒックチャンネル(すなわち、Um)またはリンク層(すなわち、PPP206)、あるいはこの両者から読出し、そこへ書込み、それを閉じるといった、ネットワークサブシステムの指定されたイベントが生成される(または、イネーブルされる)たびに、ネットワークコールバック機能が呼出されて、アプリケーション260に知らせる。トランスポート層(すなわち、TCP)から読出し、そこへ書込み、それを閉じるといったソケットの指定されたイベントが生成される(または、イネーブルされる)たびに、ソケットコールバック機能が呼出され、アプリケーション260へ知らされる。通信ネットワークがトラヒックチャンネル、リンク層、およびトランスポート層の少なくとも1つを含むことは、当業者には明らかである。
【0025】
通信プロトコルスタック280が開かれると、機能pppopen()が呼出され、トラヒックチャンネルおよびリンク層を含むネットワークサブシステムの接続を開始する。これはアプリケーション全体の呼であり、個々のソケットに依存していない。しかしながら、これはアプリケーションの識別を必要とする。ネットワークサブシステムの接続が設定されるか、またはそれが故障すると、ネットワークコールバック機能が呼出されて、指定されたイベントが通知される。例えば、トラヒックチャンネルが設定されていないときは、ネットワークサブシステムは故障する。さらに加えて、ネットワークサブシステムの特徴は、機能net ioctl()を呼出すことによって設定される。この呼出しは、例えば、ソケットのデータレートを指定する。
【0026】
ネットワークサブシステムの接続が設定されると、機能socket()を呼出すことによって、ソケットが生成されて初期設定される。しかしながら、ソケットの機能が使用できる前に、機能socket()を呼出して、ソケット記述子を戻してもよい。次に、アプリケーション260は機能async select()を呼出して、指定されたイベントを登録し、非同期の通知を受信する。この登録は、アプリケーション260によって機能呼出しの一部として実行され、指定されたイベントの要求する通知のソケット記述子およびビットマスクを指定する(すなわち、多数のイベントの論理和がとられる)。指定されたイベントが生成され(すなわち、イネーブルされ)、それが、例えば通信プロトコルスタック280またはAPI270によって検出されると、ソケットコールバック機能が呼出されて、非同期の通知を与える。コールバック機能では、信号、メッセージ、例えば遠隔手続き呼出し(remote procedure call, RPC)についてのメッセージ、あるいはハードウエアまたはソフトウエアの割込みを使用することによって、指定されたイベントのアプリケーション260を通知することができる。
【0027】
アプリケーション260は、指定されたイベントについて通知されると、機能getnextevent()を呼出して、指定されたイベントを判断してサービスする。この機能は、生成された指定されたイベントのマスクを指定されたソケット記述子へ戻す。さらに加えて、この機能は、生成された指定されたイベントのマスク内のビットをクリアする。したがって、アプリケーション260は、ディスエーブルされた指定されたイベントの通知を最早受信できない。アプリケーション260は、次に機能async select()を呼出すことによって、これらの指定されたイベントを再登録(すなわち、再イネーブル)しなければならない。
【0028】
さらに加えて、アプリケーション260は、指定されたイベントのビットマスク内の対応するビットをクリアすることによって、登録された指定されたイベントを変更する。ビットマスク内でビットが既にクリアされているときは、要求は単に無視される。簡潔に言えば、イベントの通知は、例えば機能async deselect()を呼出すことによって、イベントごとにディスエーブルされる。
【0029】
図4および5は、指定されたイベントを検出するフローチャートである。図4に示したように、例えばブロック400では、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。指定されたイベントが登録されると、ブロック402では、通信プロトコルスタック280はメモリをポーリングする。ブロック404では、ブロック402のポーリングされた情報に基づいて、指定されたイベントが検出される。ブロック406では、例えば通信プロトコルスタック280のメモリ(すなわち、送信待ち行列)が十分な量のデータを受け付けるのに使用可能であるときは、書込みイベントが検出される。データはアプリケーション260から送られる。ブロック404においてポーリングされた情報が十分でない(すなわち、指定されたイベントが生成されなかった)ときは、通信プロトコルスタック280は、ブロック402のように、メモリをポーリングし続ける。
【0030】
図5では、ブロック500に示したように、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。この時間の間は、割込み通知はディスエーブルされる。したがって、割込み通知はトリガすることも、トリガされることもできない。ブロック500において指定されたイベントが登録された後で、ブロック502において、指定されたイベントが生成されたことに基づいて、割込み通知がトリガされる。例えば、データが通信プロトコルスタック280(すなわち、受信待ち行列)のメモリへ書込まれるとき、読出しイベントが生成される。したがって、ブロック504では、イベントの生成によってトリガされた割込み通知を通信プロトコルスタック280が受信するとき、通信プロトコルスタック280は読出しイベントを検出する。通信プロトコルスタック280のメモリ内に記憶されるデータは、通信ネットワークから送られる。さらに、読出しイベントにおいて記憶されるデータは、アプリケーション260へ送られる。
【0031】
最後に、ソケットが再使用に利用できるとき、トランスポート層のようにデータリンク接続は終了しているので、閉鎖イベントが検出される。
【0032】
次に示す非同期接続(図6参照)および非同期入力(図7参照)の例では、非同期のイベントの通知の使用を示す。
【0033】
図6を参照すると、機能open netlib()を呼出すことによって、通信プロトコルスタック280へ入り、かつコールバック機能が指定される。機能pppopen()を呼出すと(A)、ネットワークサブシステムの接続が始まる(B)。ネットワークサブシステムの接続が設定された後で、コールバック機能が呼出され(C)、ネットワークサブシステムが使用可能であることが報告される。
【0034】
ソケットが開かれて、割り当てられていると仮定すると、機能connect()を呼出して(D)、TCP接続が始まる(E)。さらに、アプリケーション260は機能async select()を呼出すと(F)、指定されたイベントを登録して、通知を受信する。この例では、目的の指定されたイベントは書込みイベントであり、書込みイベントは接続を設定するときに生成される。
【0035】
接続を設定する際に、指定されたイベントがマスク内に登録されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され(G)、非同期の通知が与えられる。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し(H)、生成された何れかの指定されたイベントを判断する(I)。さらに加えて、この呼はマスク内のイベント(すなわち、書込みイベント)のビットをクリアする(J)。アプリケーション260は、機能async select()を呼出すことによって、指定されたイベントの次の通知を再登録しなければならない。
【0036】
図7には、非同期のソケットの読出しが示されている。読出しを開始するために、アプリケーション260は機能read()を呼出す(A)。読出すデータがないとみなされると、アプリケーション260は機能async select()を呼出し(B)、イベントを登録し(すなわち、マスク内の対応するビットを設定し)、通知を受信する。この例では、目的の指定されたイベントは読出しイベントであり、読出しイベントは、アプリケーション260によって読出されるデータがあるときに生成される。
【0037】
受信待ち行列内にデータを記憶する際に、読出しイベントがマスク内で指定されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され(C)、非同期の通知を与える。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し(D)、何れのイベントが生成されるかを判断する(E)。さらに加えて、この呼出しは、マスク内のイベントのビットをクリアする(F)。アプリケーション260は、機能async select()を呼出すことによって、イベントの次の通知を再びイネーブルしなければならない。最後に、受信待ち行列内に記憶されたデータを読出すために、アプリケーション260は機能read()を呼出す(G)。
【0038】
図8ないし10には、本発明の実施形態の状態機械が示されている。図8ないし10では、通信プロトコルスタック280は開いていて、ネットワークサブシステムの接続(すなわち、トラヒックチャンネル、および必要であればリンク層の接続−生のソケットはネットワークサブシステムをバイパスする)が設定されると仮定されている。当業者には、本発明の技術的範囲から逸脱することなく、状態に対する種々の名前が可能であることが分かるであろう。
【0039】
状態機械は、状態間を非同期で遷移でき、読取り、書込み、および閉鎖といった指定されたイベントを制御する(すなわち、イネーブルおよびディスエーブルする)。指定されたイベントは動作の開始時にはディスエーブルされていて、所定の状態でイネーブルされ、アプリケーション260がMS110の状態を識別するのを助ける。
【0040】
さらに加えて、API270は、API270の状態およびアプリケーション260によって呼出される機能のタイプに基づいて、特定の(すなわち、単に一般的でない)指定された状況メッセージをアプリケーション260へ報告する。指定された状況メッセージは、基礎の通信ネットワークの状態を反映する。状況メッセージは、例えば機能呼出しの立証(argument)としてアプリケーション260へ報告される。
【0041】
図8には、例えばAPI270のTCPソケットの状態図が示されている。初期設定されていないソケットは、“ナル”状態800で始まる。ソケットは、このときはまだ割り当てられていないので、“存在”しない。ソケットは、機能socket()を呼出すことによって生成されて初期設定され、ソケット記述子を戻して、ソケットに関係する機能を使用する。機能socket()を呼出した後で、状態機械は“初期設定”状態805へ遷移する。
【0042】
初期設定状態805では、状態機械は、機能close()を呼出すことによってTCP接続が終了可能になるたびに、ナル状態800へ再び遷移する。機能close()を呼出すと、全てのソケットに関係する資源が解放される。他方で、機能connect()を呼出すと、TCP接続が開始され、状態機械は“オープニング”状態810へ遷移する。
【0043】
オープニング状態810では、(1)ネットワークサブシステムが故障したとき、(2)TCP接続の設定に失敗したとき、または(3)IPアドレスを変更したときは、そのたびに状態機械は“クローズド”状態815へ遷移する。さらに加えて、TCP接続を終了する機能close()を呼出した後に、状態機械はソケットを“クロージング”状態820へ遷移し、一方では終了手続きが開始される。最後に、TCP接続が設定されたときは、状態機械は“オープン”状態825へ遷移する。
【0044】
オープン状態825では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ぐにイネーブルされ、読出しイベントは、通信プロトコルスタック280のメモリへデータが記憶されるかどうかに基づいてイネーブルされる。(1)ネットワークサブシステムが故障したとき、(2)TCP接続を設定するのに失敗したとき、(3)TCPのリセット、TCPのアボート、またはTCPの閉鎖のようなTCP接続を終了する試みをネットワークサーバが開始したとき、および(4)IPアドレスが変更されたときは、そのたびに状態機械はクローズド状態815に遷移する。例えば機能close()を呼出すことによって、アプリケーションがTCP接続の終了を開始すると、状態機械はクロージング状態820へ遷移する。
【0045】
クローズド状態815では、読出し、書込み、および閉鎖イベントは全てアサートされる。TCP接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態800へ遷移し、ソケットを解放し、それを再使用に利用できるようにする。
【0046】
クロージング状態820では、(1)ネットワークサブシステムが故障したとき、(2)ネットワークサーバが、例えばTCPのリセットまたはTCPの閉鎖のようなTCP接続の終了の試みを開始したとき、(3)タイマの時限が切れたとき、および(4)IPアドレスを変更したときは、そのたびに状態機械は“閉鎖待機”の状態830へ遷移する。TCP接続を終了するときに遅延するのを防ぐために、API270は、TCP接続の終了を開始するときに作動するタイマを含んでいる。タイマの時限が切れると、状態機械は閉鎖待機の状態830に遷移することが分かるであろう。
【0047】
閉鎖待機の状態830では、機能close()を呼出して、TCP接続を終了し、状態機械をナル状態800へ遷移する。閉鎖イベントは、この状態830でアサートされる。
【0048】
表1−3は、API270によってサポートされる指定された状況メッセージを示している。(表1ないし3には示されていない)ナル状態では、記述的な指定された状況メッセージ、すなわち“追加の資源は使用できない(no additional resources are available)”が、アプリケーション260へ報告される。
【0049】
【表1】
【0050】
【表2】
【0051】
【表3】
【0052】
例として、図9はAPI270のUDPソケットの状態図を示している。初期設定されていないソケットは“ナル”状態900で始まる。ナル状態800に関して既に記載したように、ソケットは、割り当てられていないので“存在”しない。ソケットは、機能socket()を呼出すことによって生成および初期設定され、ソケットに関係する機能で使用するためにソケットの記述子を戻す。機能socket()を呼出した後で、状態機械は“オープン”状態905へ遷移する。
【0053】
オープン状態905では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ちにイネーブルされ、一方で読出しイベントはデータが通信プロトコルスタック280のメモリへ記憶されるかどうかに基づいてイネーブルされる。状態機械は、ネットワークサブシステムが故障するたびに“クローズド”状態910へ遷移する。例えば機能close()を呼出すことによって、アプリケーションはUDP接続の終了を開始して、状態機械をナル状態900へ遷移する。
【0054】
クローズド状態910では、読出し、書込み、および閉鎖の状態は全てイネーブルされる。UDP接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態900へ遷移し、ソケットを解放し、再使用に利用できるようにする。
【0055】
表4ないし6は、API270によってサポートされる指定された状況メッセージを示している。(表4ないし6には示されていない)ナル状態では、既出の指定された状況メッセージである“追加の資源は使用できない(no additional resources are available)”が、アプリケーション260へ報告される。
【0056】
【表4】
【0057】
【表5】
【0058】
【表6】
【0059】
図10は、トラヒックチャンネル(すなわち、Um)およびリンク層(すなわち、PPP206)のようなネットワークサブシステムを制御する状態図を示している。機能open netlib()を呼出すことによって、ネットワークサブシステムを開き、“クローズド”状態1000へソケットを初期設定する。機能pppopen()を呼出すことにより、ネットワークサブシステムの接続を開始し、ソケットを“オープニング”状態1005へ遷移する。さらに加えて、到来するPPP呼出しによるMS110へのページは、ソケットをオープニング状態1005へ遷移する。両者の場合において、ネゴシエーションが成功するときは、MS110はトラヒックチャンネルにおいてRLPおよびPPPの両者を同期させて設定することを試みる。
【0060】
オープニング状態1005では、ネットワークサブシステムの接続が設定されたときに、ソケットは“オープン”状態1010へ遷移する。他方では、ネットワークサブシステムの接続が設定されていないときは、ソケットはクローズド状態1000へ再び遷移する。
【0061】
オープン状態1010では、コールバック機能が呼出されて、イネーブルされた読出し、書込み、および閉鎖のようなアプリケーション1060の指定されたイベントを識別する。このとき、MS110はトラヒックチャンネルによって通信することができる。しかしながらソケットは、ネットワークサブシステムが故障し、コールバック機能を呼出すたびに、クローズド状態1000へ遷移する。例えば機能close()を呼出すことによって、アプリケーションは、ネットワークサブシステムの接続の終了を開始し、ソケットを“クロージング”状態1015へ遷移する。
【0062】
クロージング状態1015では、ネットワークサブシステムの接続が終了するたびに、ソケットはクローズド状態1000へ遷移する。クローズド状態1000では、コールバック機能を呼出して、イネーブルされたアプリケーション260の指定されたイベントを識別する。
【0063】
表7は、特定の機能呼出しに対応し、かつAPI270によってサポートされる指定された状況メッセージを示している。
【0064】
【表7】
【0065】
【表8】
【0066】
【表9】
【0067】
【表10】
【0068】
【表11】
【0069】
【表12】
【0070】
【表13】
【0071】
【表14】
【0072】
別の実施形態では、機械は、コード化されたソフトウエアコードのようなコード化された情報を含む機械読出し可能媒体を読出して、移動局のアプリケーションが指定された状況メッセージを識別できるようにする上述のプロセスを行なう。機械読出し可能媒体は、メモリまたは記憶ディスクのような記憶デバイスから、あるいは通信ネットワークから、コード化された情報を受取る。さらに加えて、機械読出し可能媒体は、製造されたときに、コード化された情報でプログラムされる。機械は、アプリケーション260、通信プロトコルスタック280、およびAPI270の少なくとも1つを含み、一方で機械の読出し媒体はメモリまたは記憶ディスクを含む。
【0073】
本発明は特定の実施形態に関連して示したが、そのように制限されているわけではないと考えられる。むしろ、本発明は特許請求の範囲およびそれに相当するものの技術的範囲のみによって制限される。
【図面の簡単な説明】
【図1】
(従来技術において)移動局がインターネットに接続している無線通信システムの高レベルのブロック図。
【図2】
(従来技術において)TIA/EIA IS−707.5の中継モデルの各エンティティにおけるプロトコルスタックを模式的に示す図。
【図3】
本発明の実施形態の特徴を模式的に示す図。
【図4】
指定されたイベントを検出するフローチャート。
【図5】
指定されたイベントを検出するフローチャート。
【図6】
非同期接続を示すブロック図。
【図7】
非同期ソケット入力を示すブロック図。
【図8】
本発明の実施形態の状態図。
【図9】
本発明の実施形態の状態図。
【図10】
本発明の実施形態の状態図。
背景
1.発明の分野
本発明は、概ね、無線通信の分野に関する。とくに、本発明は無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別できるようにする斬新な方法および装置に関する。
【0002】
2.関係する技術の記述
A.無線通信
無線通信およびコンピュータに関係する技術における最近の革新、並びにインターネット加入者の今までにない増加によって、モバイルコンピューティングへの道が開かれた。事実、モバイルコンピューティングの大衆性により、現在のインターネットのインフラストラクチャに対して、モバイルのユーザにより多くのサポートを与える要求が強まった。このインフラストラクチャの原動力は、種々のサービスを提供するパケット指向のインターネットプロトコル(Internet Protocol, IP)であり、種々のサービスには、パケット(データグラム)をローカルエリアネットワーク(local area network, LAN)とワイドエリアネットワーク(wide area network, WAN)との間でアドレス指定してルート設定するサービスが含まれる。IPプロトコルは、Request For Comment(RFC 791)(“INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, 1981 9)において規定されている。
【0003】
IPプロトコルは、送信のためにデータをIPパケットへカプセル化するネットワーク層プロトコルである。アドレス指定およびルート設定の情報はパケットのヘッダに付される。IPヘッダには、例えば送信ホストおよび受信ホストを識別する32ビットのアドレスが含まれている。中間のルータはこれらのアドレスを使用して、パケットを、意図されたアドレスをもつその最終的な宛先へ向わせるためのネットワーク上の経路を選択する。したがって、IPプロトコルにより、世界中の何れかのインターネットノードにおいて発信されたパケットを、世界中の他の何れかのインターネットノードへルート設定することができる。これに対して、特定のアプリケーションに対処するためには、伝送制御プロトコル(Transmission Control Protocol, TCP)またはユーザデータグラムプロトコル(User Datagram Protocol, UDP)の何れかを含むトランスポート層が使用される。
【0004】
現在の傾向では、モバイルのユーザはラップトップまたはパームトップコンピュータのようなモバイルコンピュータを、セルラまたは携帯電話のような無線通信デバイスと共に使用して、インターネットにアクセスしている。したがって、ちょうど、従来からユーザが“有線の”通信デバイスを使用してコンピュータを陸上ネットワーク(land−based network)へ接続していたように、モバイルのユーザは一般的に“移動局”(mobile station, MS)と呼ばれる無線通信デバイスを使用してモバイル端末をこのようなネットワークへ接続する。本明細書で使用しているように、移動局またはMSは、公共の無線ラジオネットワーク(wireless radio network)の加入者局を指す。
【0005】
(従来技術を示している)図1は、無線データ通信システムの高レベルのブロック図を示しており、この中でMS110は基地局/移動局スイッチングセンタ(Base Station/Mobile Switching Center, BS/MSC)106を介して相互接続機能(Interworking Function, IWF)108と通信する。IWF108は、インターネットへのアクセス点として働く。IWF108はBS/MSC106に接続されていて、一緒に位置していることも多く、BS/MSC106はこの技術において知られているように従来の無線基地局であってもよい。無線データ通信システムに対処する別の標準プロトコルは、“WIRELESS IP NETWORK STANDARD”というタイトルで1999年12月に発行された第3世代パートナーシッププロジェクト2(3rd Generation Partnership Project 2, “3GPP2”)である。3G無線IPネットワークの標準規格には、例えば、IWF108のように機能するパケットデータ供給ノード(Packet Data Serving Node, PDSN)が含まれる。
【0006】
種々のプロトコルが、MS110とIWF108との間のデータ通信に対処している。例えば、米国電気通信工業会(Telecommunications Industry Association, TIA)/電子機械工業会(Electronics Industries Association, EIA)の暫定的標準規格(Interim Standard)のIS−95は、“MOBILE STATION−BASE STATION COMPATIBILITY STANDARD FOR DUAL−MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM”というタイトルで1993年7月に発行されていて、これは概して広帯域拡散スペクトル無線通信システムの標準規格を与えている。さらに加えて、標準規格のTIA/EIA IS−707.5は、“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルで1998年2月に発行されていて、これはTIA/EIA IS−95のシステムのパケットデータ伝送能力のサポート要件を規定し、BS/MSC106を介してのMS110とIWF108との間の通信に使用できるパケットデータ伝達サービスを指定している。さらに加えて、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES”というタイトルのTIA/EIA IS−707−A.5の標準規格と、“DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: HIGH−SPEED PACKET DATA SERVICES”というタイトルのTIA/EIA IS−707−A.9の標準規格とは、両者とも1999年3月に発行されており、これらもTIA/EIA IS−95のシステムのパケットデータ伝送のサポート要件を規定している。さらに加えて、MS110とIWF108との間の通信に対処している別の標準規格のプロトコルにはTIA/EIA IS−2000があり、これは“INTRODUCTION TO CDMA 2000 STANDARDS FOR SPREAD SPECTRUM SYSTEMS”というタイトルで1999年7月に発行されている。
【0007】
IS−707.5では、MS110とBS/MSC106(Umインターフェイス)との間およびBS/MSC106とIWF108(Lインターフェイス)との間の通信プロトコルのオプションモデルを取り入れている。例えば、中継モデルは、ポイント−ツウ−ポイントプロトコル(Point to Point Protocol, PPP)のリンクがMS110とIWF108との間のUmインターフェイス上に存在している情況を表わしている。PPPプロトコルは、Request For Comment(RFC 1661)(“THE POINT−TO−POINT PROTOCOL (PPP)”)に詳しく記載されている。
【0008】
(従来技術を示している)図2は、IS−707.5の中継モデルの各エンティティ内のプロトコルスタックの図である。図の左端には、従来の垂直形のフォーマットで示された通信プロトコルスタックが記載されており、これはMS110上で実行されるプロトコル層を示している。MS110のプロトコルスタックは、Umインターフェイスを通してBS/MSC106のプロトコルスタックへ論理的に接続されているように示されている。また、MS/MSC106のプロトコルスタックは、Lインターフェイスを通してIWF108のプロトコルスタックへ論理的に接続されているように示されている。
【0009】
図2は次に記載する動作が行われることを示している。すなわち、MS110上で実行される上位層プロトコル200のエンティティ、例えばアプリケーションプログラムは、インターネットを通してデータを送る必要がある。代表的なアプリケーションには、ウエブブラウザプログラム(例えば、Netscape Navigator(ネットスケープナビゲータ)(商標)、Microsoft Internet explorer(マイクロソフトインターネットエクスプローラ)(商標))がある。ウエブブラウザには、ハイパーリンク“http://www.Qualcomm.com/”のようなユニバーサルリソースロケータ(Universal Resource Locator, URL)が必要である。同じく上位層プロトコル200内のドメイン名システム(Domain Name System (DNS))プロトコルはドメイン名の分解(resolution)を使用して、名前をインターネットのアドレスへ変換することによって、テキストホスト名www.Qualcom.comを32ビットの数字のIPアドレスへ変換する。同じく上位層プロトコル200であるハイパーテキスト転送プロトコル(Hypertext Transfer Protocol, HTTP)は、要求されているURLのためのGETメッセージを作成し、このメッセージを送るのに使用されるTCPおよびHTTPの動作を指定する。トランスポート層202では、宛先ポートとして、この技術において使用されているポート80を使用して、HTTPの動作をアプリケーションへルート設定する。
【0010】
TCPプロトコルは、トランスポート層プロトコル202であり、DNSによって指定されるIPアドレスとの接続を開き、アプリケーションレベルのHTTPのGETメッセージを送る。TCPプロトコルでは、IPプロトコルを使用してメッセージを転送することを指定している。IPプロトコルはネットワーク層プロトコル204であり、TCPパケットを指定されたIPアドレスへ送る。PPPはリンク層プロトコル206であり、IPパケットをコード化し、それらを中継層プロトコル208へ送る。中継層プロトコル208は、例えば、TIA/EIA−232Fの標準規格であり、TIA/EIA−232Fの標準規格は“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”とが含まれる。最後に、PPPパケットは中継層プロトコル208から無線リンクプロトコル(Radio Link Protocol, RLP)210、次にIS−95プロトコル212を経由して、Umインターフェイスを通してBS/MSC106へ送られる。RLPプロトコル210はIS−707.2の標準規格に規定されており、IS−707.2の標準規格は“DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL”というタイトルで1998年2月に発行されていて、IS−95プロトコルは上述で識別したIS−95の標準規格に規定されている。
【0011】
PPPパケットはUmインターフェイスを通してBS/MSC106上のIS−95の層218、次にRLPの層216へ送られ、相補的な中継層プロトコル220によって受信される。中継層プロトコル220は、このPPPパケットをLインターフェイスを通してIWF108上の中継層プロトコル228へ送る。IWF108上のPPPプロトコルリンク層226が中継層プロトコル228からPPPパケットを受信すると、MS110とIWF108との間のPPP接続は終了する。パケットは、IWF108上のPPP層226からIP層224へ送られ、IP層224では最後のルート設定のためにIPパケットのヘッダ(このシナリオではwww.Qualcomm.comである)を調べる。
【0012】
MS110によって生成されたIPパケットの最終的な宛先がIWF108ではないと仮定すると、パケットはネットワーク層プロトコル224、さらにリンク層プロトコル225を経由して、インターネット上の次のルータ(図示されていない)へ送られる。このやり方では、MS110からのIPパケットは、IS−707.5の標準規格の中継モデルにしたがって、BS/MSC106、およびIWF108を経由して、インターネット内の最終的な意図された宛先へ伝達される。
【0013】
MS110のパケットがその宛先へ到達する前に、先ずデータリンク接続が設定されなければならない。RFC1661に指定されているように、このデータリンク接続では、先ずポイント−ツウ−ポイントリンクの各終端(すなわち、PPPプロトコル206および226)がPPPリンク制御プロトコル(Link Control Protocol, LCP)へパケットを送って、データリンク接続を設定し、構成し、試験することが求められている。LCPによってリンクが設定された後で、PPPプロトコル206はネットワーク制御プロトコル(Network Control Protocol, NCP)のパケットを送って、ネットワーク層プロトコル204および224を構成する。PPPリンクにおけるIPのためのNCPはIP制御プロトコル(IP Control Protocol, IPCP)である。IPCPは、Request For Comment 1332(RFC 1332)に詳しく記載されており、RFC 1332は“THE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)”というタイトルで1992年5月に発行されている。しかしながら、IPCPのネゴシエーションの前には、認証段階が必要である。各ネットワーク層プロトコルが構成された後では、各ネットワーク層プロトコルからのパケットは、プロトコル間のリンクを通して送られる。
【0014】
B.アプリケーションプログラムインターフェイス
MS110上の通信プロトコルスタックをサポートするプロセスは、その全てではないが、ほとんどがアプリケーションプログラムによって実行される。一般的に従来のデータネットワークでは、アプリケーションプログラムインターフェイス(application program interface, API)を採用して、あるコンピュータ上で実行されるアプリケーションプログラムと別のコンピュータ上で実行されるアプリケーションプログラムとの通信を可能にしている。APIは“ソケット”を使用して、基礎ネットワークのプロトコルの相違によって、呼出しているアプリケーションを保護する。ネットワーク間の通信(inter−networked communication)を実現するために、APIには、アプリケーションが、例えばソケットを開き、データをネットワークへ送り、ネットワークからデータを受信し、ソケットを閉じることを可能にする機能(function)が含まれている。通信ネットワークのプログラミングインターフェイスには、Unix(ユニックス)(商標)のオペレーティングシステムのもとで動作するバークレイシステム開発(Berkeley System Development, BSD)のソケットインターフェイス、およびWindows(ウインドウズ)(商標)のオペレーティングシステムのもとで動作するWindows(ウインドウズ)(商標)Sockets Interface(ソケットインターフェイス) (WinSock(ウインソック)(商標))が含まれる。
【0015】
BSDソケットもWinSock(ウインソック)(商標)の何れも無線MS110上の通信プロトコルスタック(図2参照)をサポートしていないので、このようなスタックをサポートする斬新なAPIが必要である。とくに、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための斬新な方法および装置が必要とされている。
【0016】
本発明の概要
本発明では、無線通信システムにおいて移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置を提供することによって、上述で識別した必要に対処している。1つの構成では、本発明は、通信ネットワークと通信する移動局の通信プロトコルスタックと、移動局のアプリケーションとの間の通信を容易にするアプリケーションプログラムインターフェイス(application program interface, API)を含んでいる。移動局のアプリケーションは機能を呼出す。APIは、その状態と呼出された機能とに基づいて、指定された状況メッセージの少なくとも1つを選択する。次にAPIは、選択した指定された状況メッセージを移動局のアプリケーションへ報告する。
【0017】
詳細な記述
本発明の実施形態は、ソフトウエア、ファームウエア、および/またはハードウエアを含む種々の構成において実現することができる。したがって、本発明の動作および働き(behavior)はソフトウエアコードまたはハードウエアの構成要素をとくに参照せずに記載されているが、この技術において普通の技能をもつ人には、本明細書の記述に基づいて、本発明を構成するソフトウエアまたはハードウエア、あるいはこの両者を設計でき、これにより移動局のアプリケーションが指定された状況メッセージを識別できることが分かるであろう。
【0018】
図3には、MS110内のアプリケーション260、通信プロトコルスタック280、およびAPI270が示されている。アプリケーション260および通信プロトコルスタック280(すなわち、プロトコル層202、204、206、208、210、212)は、API270によって与えられる機能呼出し(function call)によって通信する。言い換えると、API270は、アプリケーション260および通信プロトコルスタック280を機能を損わずに異なるプロセッサおよびオペレーティングシステム上で実行できるようにする。当業者には、本発明の技術的範囲から逸脱することなく、呼出された機能に対して種々の名前が可能であることが分かるであろう。
【0019】
通信プロトコルスタック280には、複数の送信待ち行列と受信待ち行列とが含まれていて、これらの待ち行列はデータを記憶することに注意すべきである。出力機能では、アプリケーション260のメモリからデータを読出し、そのデータを通信プロトコルスタック280の送信待ち行列の1つへ記憶する。入力機能では、通信プロトコルスタック280の受信待ち行列の1つからデータを読出し、そのデータをアプリケーション260のメモリへ記憶する。
【0020】
動作を示すために、MS110はIPパケットを受信する。MS110の通信プロトコルスタック280は、IPパケットを逆カプセル化して(unencapsulate)、それらをトランスポート層202へ送る(図3参照)。IPパケットヘッダ内の1つのフィールドはトランスポートを示していて、TCPまたはUDPの何れかでを含む。トランスポート層のヘッダにおいて指定されている宛先ポートの番号に基づいて、データは、特定のソケットに対応する通信プロトコルスタック280の適切な受信待ち行列へルート設定される。次にデータは、アプリケーション260へ送られる。
【0021】
一定の情況では、プロトコルスタック280の種々の層をバイパスするパケットを使用して動作して、待ち時間の影響を軽減することが望ましい。このようなパケットには、生のIPパケットのような生のパケット化されたデータが含まれているが、これには宛先の情報(すなわち、宛先ポートの番号)が欠けている。したがって、宛先のアプリケーションは、生のIPパケットから判断できない。このような情況では、通信プロトコルスタック280は受信した生のIPパケットを、例えばIPプロトコルをサポートするために登録されている全てのソケットへ送る。このようにしてペイロードデータは宛先のアプリケーションへ送られる。インターネット制御メッセージングプロトコル(Internet Control Messaging Protocol, ICMP)のパーシングエンジンはIPパケットに応答して、生のパケット化されたデータも受信することができる。周知のICMPのパーシングエンジンは、“INTERNET CONTROL MESSAGE PROTOCOL”というタイトルでRFC 792に規定されている。したがって、通信プロトコルスタック280は、受信したパケットを処理し、その後でパケットをスタックを逆上ってアプリケーション260へ送り、アプリケーション260が逆カプセル化する量を低減することが明らかである。
【0022】
逆に、アプリケーション260は、ソケットを使用することによって生のパケット化されたデータをUmインターフェイスを通して送り、通信プロトコルスタック280とアプリケーション260との間の通信を容易にすることもできる。さらに、アプリケーション260は、生のパケット化されたデータをUmインターフェイスを通して送ることもできる。また、通信プロトコルスタック280は、例えばパケット化された、または生のパケット化されたデータをIPパケットへカプセル化し、それらをUmインターフェイスを通して送る。この例では、通信プロトコルスタック280はIPヘッダおよびチェックサムを用意して、IPパケットを生成する。他方で、ICMPでは、指定されたプロトコルのタイプはIPヘッダへコピーされる。
【0023】
既に記載したように、アプリケーション260はソケットを生成し、ソケットはプロトコル層202、204、206、208、210、212の少なくとも1つとアプリケーション260との間のデータ通信が、通信プロトコルスタック280を使用するときに必ず伴う待ち時間を低減できるようにする。したがってアプリケーション260はソケットを生成し、ソケットはトランスポート層202、ネットワーク層204、およびリンク層206をバイパスして、アプリケーション260がRLP層210との間でペイロードデータを送受信できるようにする。さらに加えて、アプリケーション260はソケットを生成し、ソケットはアプリケーション260がIS−95の層212との間でペイロードデータを送受信できるようにする。
【0024】
1つの実施形態では、アプリケーション260は機能open netlib()を呼出して、通信プロトコルスタック280を開き、アプリケーションの識別を割り当てる。アプリケーションを識別すると、多数のアプリケーションが通信プロトコルスタック280と通信すること(すなわち、マルチタスキング)ができる。例えば、機能open netlib()の呼出しの一部として、アプリケーション260はネットワークコールバック機能およびソケットコールバック機能へのポインタを指定する。トラヒックチャンネル(すなわち、Um)またはリンク層(すなわち、PPP206)、あるいはこの両者から読出し、そこへ書込み、それを閉じるといった、ネットワークサブシステムの指定されたイベントが生成される(または、イネーブルされる)たびに、ネットワークコールバック機能が呼出されて、アプリケーション260に知らせる。トランスポート層(すなわち、TCP)から読出し、そこへ書込み、それを閉じるといったソケットの指定されたイベントが生成される(または、イネーブルされる)たびに、ソケットコールバック機能が呼出され、アプリケーション260へ知らされる。通信ネットワークがトラヒックチャンネル、リンク層、およびトランスポート層の少なくとも1つを含むことは、当業者には明らかである。
【0025】
通信プロトコルスタック280が開かれると、機能pppopen()が呼出され、トラヒックチャンネルおよびリンク層を含むネットワークサブシステムの接続を開始する。これはアプリケーション全体の呼であり、個々のソケットに依存していない。しかしながら、これはアプリケーションの識別を必要とする。ネットワークサブシステムの接続が設定されるか、またはそれが故障すると、ネットワークコールバック機能が呼出されて、指定されたイベントが通知される。例えば、トラヒックチャンネルが設定されていないときは、ネットワークサブシステムは故障する。さらに加えて、ネットワークサブシステムの特徴は、機能net ioctl()を呼出すことによって設定される。この呼出しは、例えば、ソケットのデータレートを指定する。
【0026】
ネットワークサブシステムの接続が設定されると、機能socket()を呼出すことによって、ソケットが生成されて初期設定される。しかしながら、ソケットの機能が使用できる前に、機能socket()を呼出して、ソケット記述子を戻してもよい。次に、アプリケーション260は機能async select()を呼出して、指定されたイベントを登録し、非同期の通知を受信する。この登録は、アプリケーション260によって機能呼出しの一部として実行され、指定されたイベントの要求する通知のソケット記述子およびビットマスクを指定する(すなわち、多数のイベントの論理和がとられる)。指定されたイベントが生成され(すなわち、イネーブルされ)、それが、例えば通信プロトコルスタック280またはAPI270によって検出されると、ソケットコールバック機能が呼出されて、非同期の通知を与える。コールバック機能では、信号、メッセージ、例えば遠隔手続き呼出し(remote procedure call, RPC)についてのメッセージ、あるいはハードウエアまたはソフトウエアの割込みを使用することによって、指定されたイベントのアプリケーション260を通知することができる。
【0027】
アプリケーション260は、指定されたイベントについて通知されると、機能getnextevent()を呼出して、指定されたイベントを判断してサービスする。この機能は、生成された指定されたイベントのマスクを指定されたソケット記述子へ戻す。さらに加えて、この機能は、生成された指定されたイベントのマスク内のビットをクリアする。したがって、アプリケーション260は、ディスエーブルされた指定されたイベントの通知を最早受信できない。アプリケーション260は、次に機能async select()を呼出すことによって、これらの指定されたイベントを再登録(すなわち、再イネーブル)しなければならない。
【0028】
さらに加えて、アプリケーション260は、指定されたイベントのビットマスク内の対応するビットをクリアすることによって、登録された指定されたイベントを変更する。ビットマスク内でビットが既にクリアされているときは、要求は単に無視される。簡潔に言えば、イベントの通知は、例えば機能async deselect()を呼出すことによって、イベントごとにディスエーブルされる。
【0029】
図4および5は、指定されたイベントを検出するフローチャートである。図4に示したように、例えばブロック400では、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。指定されたイベントが登録されると、ブロック402では、通信プロトコルスタック280はメモリをポーリングする。ブロック404では、ブロック402のポーリングされた情報に基づいて、指定されたイベントが検出される。ブロック406では、例えば通信プロトコルスタック280のメモリ(すなわち、送信待ち行列)が十分な量のデータを受け付けるのに使用可能であるときは、書込みイベントが検出される。データはアプリケーション260から送られる。ブロック404においてポーリングされた情報が十分でない(すなわち、指定されたイベントが生成されなかった)ときは、通信プロトコルスタック280は、ブロック402のように、メモリをポーリングし続ける。
【0030】
図5では、ブロック500に示したように、通信プロトコルスタック280は、アプリケーション260が指定されたイベントを登録するのを待つ。この時間の間は、割込み通知はディスエーブルされる。したがって、割込み通知はトリガすることも、トリガされることもできない。ブロック500において指定されたイベントが登録された後で、ブロック502において、指定されたイベントが生成されたことに基づいて、割込み通知がトリガされる。例えば、データが通信プロトコルスタック280(すなわち、受信待ち行列)のメモリへ書込まれるとき、読出しイベントが生成される。したがって、ブロック504では、イベントの生成によってトリガされた割込み通知を通信プロトコルスタック280が受信するとき、通信プロトコルスタック280は読出しイベントを検出する。通信プロトコルスタック280のメモリ内に記憶されるデータは、通信ネットワークから送られる。さらに、読出しイベントにおいて記憶されるデータは、アプリケーション260へ送られる。
【0031】
最後に、ソケットが再使用に利用できるとき、トランスポート層のようにデータリンク接続は終了しているので、閉鎖イベントが検出される。
【0032】
次に示す非同期接続(図6参照)および非同期入力(図7参照)の例では、非同期のイベントの通知の使用を示す。
【0033】
図6を参照すると、機能open netlib()を呼出すことによって、通信プロトコルスタック280へ入り、かつコールバック機能が指定される。機能pppopen()を呼出すと(A)、ネットワークサブシステムの接続が始まる(B)。ネットワークサブシステムの接続が設定された後で、コールバック機能が呼出され(C)、ネットワークサブシステムが使用可能であることが報告される。
【0034】
ソケットが開かれて、割り当てられていると仮定すると、機能connect()を呼出して(D)、TCP接続が始まる(E)。さらに、アプリケーション260は機能async select()を呼出すと(F)、指定されたイベントを登録して、通知を受信する。この例では、目的の指定されたイベントは書込みイベントであり、書込みイベントは接続を設定するときに生成される。
【0035】
接続を設定する際に、指定されたイベントがマスク内に登録されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され(G)、非同期の通知が与えられる。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し(H)、生成された何れかの指定されたイベントを判断する(I)。さらに加えて、この呼はマスク内のイベント(すなわち、書込みイベント)のビットをクリアする(J)。アプリケーション260は、機能async select()を呼出すことによって、指定されたイベントの次の通知を再登録しなければならない。
【0036】
図7には、非同期のソケットの読出しが示されている。読出しを開始するために、アプリケーション260は機能read()を呼出す(A)。読出すデータがないとみなされると、アプリケーション260は機能async select()を呼出し(B)、イベントを登録し(すなわち、マスク内の対応するビットを設定し)、通知を受信する。この例では、目的の指定されたイベントは読出しイベントであり、読出しイベントは、アプリケーション260によって読出されるデータがあるときに生成される。
【0037】
受信待ち行列内にデータを記憶する際に、読出しイベントがマスク内で指定されるときは、コールバック機能が呼出される。そのときは、コールバック機能が呼出され(C)、非同期の通知を与える。アプリケーション260は、通知を受取ると、機能getnextevent()を呼出し(D)、何れのイベントが生成されるかを判断する(E)。さらに加えて、この呼出しは、マスク内のイベントのビットをクリアする(F)。アプリケーション260は、機能async select()を呼出すことによって、イベントの次の通知を再びイネーブルしなければならない。最後に、受信待ち行列内に記憶されたデータを読出すために、アプリケーション260は機能read()を呼出す(G)。
【0038】
図8ないし10には、本発明の実施形態の状態機械が示されている。図8ないし10では、通信プロトコルスタック280は開いていて、ネットワークサブシステムの接続(すなわち、トラヒックチャンネル、および必要であればリンク層の接続−生のソケットはネットワークサブシステムをバイパスする)が設定されると仮定されている。当業者には、本発明の技術的範囲から逸脱することなく、状態に対する種々の名前が可能であることが分かるであろう。
【0039】
状態機械は、状態間を非同期で遷移でき、読取り、書込み、および閉鎖といった指定されたイベントを制御する(すなわち、イネーブルおよびディスエーブルする)。指定されたイベントは動作の開始時にはディスエーブルされていて、所定の状態でイネーブルされ、アプリケーション260がMS110の状態を識別するのを助ける。
【0040】
さらに加えて、API270は、API270の状態およびアプリケーション260によって呼出される機能のタイプに基づいて、特定の(すなわち、単に一般的でない)指定された状況メッセージをアプリケーション260へ報告する。指定された状況メッセージは、基礎の通信ネットワークの状態を反映する。状況メッセージは、例えば機能呼出しの立証(argument)としてアプリケーション260へ報告される。
【0041】
図8には、例えばAPI270のTCPソケットの状態図が示されている。初期設定されていないソケットは、“ナル”状態800で始まる。ソケットは、このときはまだ割り当てられていないので、“存在”しない。ソケットは、機能socket()を呼出すことによって生成されて初期設定され、ソケット記述子を戻して、ソケットに関係する機能を使用する。機能socket()を呼出した後で、状態機械は“初期設定”状態805へ遷移する。
【0042】
初期設定状態805では、状態機械は、機能close()を呼出すことによってTCP接続が終了可能になるたびに、ナル状態800へ再び遷移する。機能close()を呼出すと、全てのソケットに関係する資源が解放される。他方で、機能connect()を呼出すと、TCP接続が開始され、状態機械は“オープニング”状態810へ遷移する。
【0043】
オープニング状態810では、(1)ネットワークサブシステムが故障したとき、(2)TCP接続の設定に失敗したとき、または(3)IPアドレスを変更したときは、そのたびに状態機械は“クローズド”状態815へ遷移する。さらに加えて、TCP接続を終了する機能close()を呼出した後に、状態機械はソケットを“クロージング”状態820へ遷移し、一方では終了手続きが開始される。最後に、TCP接続が設定されたときは、状態機械は“オープン”状態825へ遷移する。
【0044】
オープン状態825では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ぐにイネーブルされ、読出しイベントは、通信プロトコルスタック280のメモリへデータが記憶されるかどうかに基づいてイネーブルされる。(1)ネットワークサブシステムが故障したとき、(2)TCP接続を設定するのに失敗したとき、(3)TCPのリセット、TCPのアボート、またはTCPの閉鎖のようなTCP接続を終了する試みをネットワークサーバが開始したとき、および(4)IPアドレスが変更されたときは、そのたびに状態機械はクローズド状態815に遷移する。例えば機能close()を呼出すことによって、アプリケーションがTCP接続の終了を開始すると、状態機械はクロージング状態820へ遷移する。
【0045】
クローズド状態815では、読出し、書込み、および閉鎖イベントは全てアサートされる。TCP接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態800へ遷移し、ソケットを解放し、それを再使用に利用できるようにする。
【0046】
クロージング状態820では、(1)ネットワークサブシステムが故障したとき、(2)ネットワークサーバが、例えばTCPのリセットまたはTCPの閉鎖のようなTCP接続の終了の試みを開始したとき、(3)タイマの時限が切れたとき、および(4)IPアドレスを変更したときは、そのたびに状態機械は“閉鎖待機”の状態830へ遷移する。TCP接続を終了するときに遅延するのを防ぐために、API270は、TCP接続の終了を開始するときに作動するタイマを含んでいる。タイマの時限が切れると、状態機械は閉鎖待機の状態830に遷移することが分かるであろう。
【0047】
閉鎖待機の状態830では、機能close()を呼出して、TCP接続を終了し、状態機械をナル状態800へ遷移する。閉鎖イベントは、この状態830でアサートされる。
【0048】
表1−3は、API270によってサポートされる指定された状況メッセージを示している。(表1ないし3には示されていない)ナル状態では、記述的な指定された状況メッセージ、すなわち“追加の資源は使用できない(no additional resources are available)”が、アプリケーション260へ報告される。
【0049】
【表1】
【0050】
【表2】
【0051】
【表3】
【0052】
例として、図9はAPI270のUDPソケットの状態図を示している。初期設定されていないソケットは“ナル”状態900で始まる。ナル状態800に関して既に記載したように、ソケットは、割り当てられていないので“存在”しない。ソケットは、機能socket()を呼出すことによって生成および初期設定され、ソケットに関係する機能で使用するためにソケットの記述子を戻す。機能socket()を呼出した後で、状態機械は“オープン”状態905へ遷移する。
【0053】
オープン状態905では、ソケットは読出しおよび書込みのために開いている。とくに、書込みイベントは直ちにイネーブルされ、一方で読出しイベントはデータが通信プロトコルスタック280のメモリへ記憶されるかどうかに基づいてイネーブルされる。状態機械は、ネットワークサブシステムが故障するたびに“クローズド”状態910へ遷移する。例えば機能close()を呼出すことによって、アプリケーションはUDP接続の終了を開始して、状態機械をナル状態900へ遷移する。
【0054】
クローズド状態910では、読出し、書込み、および閉鎖の状態は全てイネーブルされる。UDP接続を終了する機能close()を呼出した後で、状態機械はソケットをナル状態900へ遷移し、ソケットを解放し、再使用に利用できるようにする。
【0055】
表4ないし6は、API270によってサポートされる指定された状況メッセージを示している。(表4ないし6には示されていない)ナル状態では、既出の指定された状況メッセージである“追加の資源は使用できない(no additional resources are available)”が、アプリケーション260へ報告される。
【0056】
【表4】
【0057】
【表5】
【0058】
【表6】
【0059】
図10は、トラヒックチャンネル(すなわち、Um)およびリンク層(すなわち、PPP206)のようなネットワークサブシステムを制御する状態図を示している。機能open netlib()を呼出すことによって、ネットワークサブシステムを開き、“クローズド”状態1000へソケットを初期設定する。機能pppopen()を呼出すことにより、ネットワークサブシステムの接続を開始し、ソケットを“オープニング”状態1005へ遷移する。さらに加えて、到来するPPP呼出しによるMS110へのページは、ソケットをオープニング状態1005へ遷移する。両者の場合において、ネゴシエーションが成功するときは、MS110はトラヒックチャンネルにおいてRLPおよびPPPの両者を同期させて設定することを試みる。
【0060】
オープニング状態1005では、ネットワークサブシステムの接続が設定されたときに、ソケットは“オープン”状態1010へ遷移する。他方では、ネットワークサブシステムの接続が設定されていないときは、ソケットはクローズド状態1000へ再び遷移する。
【0061】
オープン状態1010では、コールバック機能が呼出されて、イネーブルされた読出し、書込み、および閉鎖のようなアプリケーション1060の指定されたイベントを識別する。このとき、MS110はトラヒックチャンネルによって通信することができる。しかしながらソケットは、ネットワークサブシステムが故障し、コールバック機能を呼出すたびに、クローズド状態1000へ遷移する。例えば機能close()を呼出すことによって、アプリケーションは、ネットワークサブシステムの接続の終了を開始し、ソケットを“クロージング”状態1015へ遷移する。
【0062】
クロージング状態1015では、ネットワークサブシステムの接続が終了するたびに、ソケットはクローズド状態1000へ遷移する。クローズド状態1000では、コールバック機能を呼出して、イネーブルされたアプリケーション260の指定されたイベントを識別する。
【0063】
表7は、特定の機能呼出しに対応し、かつAPI270によってサポートされる指定された状況メッセージを示している。
【0064】
【表7】
【0065】
【表8】
【0066】
【表9】
【0067】
【表10】
【0068】
【表11】
【0069】
【表12】
【0070】
【表13】
【0071】
【表14】
【0072】
別の実施形態では、機械は、コード化されたソフトウエアコードのようなコード化された情報を含む機械読出し可能媒体を読出して、移動局のアプリケーションが指定された状況メッセージを識別できるようにする上述のプロセスを行なう。機械読出し可能媒体は、メモリまたは記憶ディスクのような記憶デバイスから、あるいは通信ネットワークから、コード化された情報を受取る。さらに加えて、機械読出し可能媒体は、製造されたときに、コード化された情報でプログラムされる。機械は、アプリケーション260、通信プロトコルスタック280、およびAPI270の少なくとも1つを含み、一方で機械の読出し媒体はメモリまたは記憶ディスクを含む。
【0073】
本発明は特定の実施形態に関連して示したが、そのように制限されているわけではないと考えられる。むしろ、本発明は特許請求の範囲およびそれに相当するものの技術的範囲のみによって制限される。
【図面の簡単な説明】
【図1】
(従来技術において)移動局がインターネットに接続している無線通信システムの高レベルのブロック図。
【図2】
(従来技術において)TIA/EIA IS−707.5の中継モデルの各エンティティにおけるプロトコルスタックを模式的に示す図。
【図3】
本発明の実施形態の特徴を模式的に示す図。
【図4】
指定されたイベントを検出するフローチャート。
【図5】
指定されたイベントを検出するフローチャート。
【図6】
非同期接続を示すブロック図。
【図7】
非同期ソケット入力を示すブロック図。
【図8】
本発明の実施形態の状態図。
【図9】
本発明の実施形態の状態図。
【図10】
本発明の実施形態の状態図。
Claims (12)
- 移動局のアプリケーションが複数の指定された状況メッセージを識別するための方法であって、
移動局の通信プロトコルスタックと通信ネットワークとの間で通信することと、
移動局の通信プロトコルスタックと移動局のアプリケーションとの間で移動局のアプリケーションのインターフェイスを通して通信することと、
移動局のアプリケーションによって機能を呼出すことと、
移動局のアプリケーションのインターフェイスによって、移動局のアプリケーションのインターフェイスの状態と呼出された機能とに基づいて、指定された状況メッセージの少なくとも1つを選択することと、
移動局のアプリケーションのインターフェイスによって、指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告することとを含む方法。 - 移動局のアプリケーションのインターフェイスが、呼出された機能の立証によって指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告する請求項1記載の方法。
- 移動局のアプリケーションのインターフェイスが複数の状態を含む請求項1記載の方法。
- 移動局のアプリケーションのインターフェイスが状態間を非同期に遷移する請求項3記載の方法。
- 移動局のアプリケーションが複数の指定された状況メッセージを識別するための装置であって、
通信ネットワークと通信するための移動局の通信プロトコルスタックと、
機能を呼出すための移動局のアプリケーションと、
移動局のアプリケーションのインターフェイスの状態と呼出される機能とに基づいて、指定された状況メッセージの少なくとも1つを選択するための移動局のアプリケーションのインターフェイスとを含み、
移動局のアプリケーションのインターフェイスが、移動局のアプリケーションと移動局の通信プロトコルスタックとの間の通信を可能にするようにされていて、かつ、
移動局のアプリケーションのインターフェイスが、指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告するようにされている装置。 - 移動局のアプリケーションのインターフェイスが、呼出された機能の立証によって指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告するようにされている請求項5記載の装置。
- 移動局のアプリケーションのインターフェイスが複数の状態を含む請求項5記載の装置。
- 移動局のアプリケーションのインターフェイスが、状態間を非同期に遷移するようにされている請求項7記載の装置。
- コード化された情報を含む機械読出し可能媒体であって、機械によって読出されたときに、
移動局の通信プロトコルスタックと通信ネットワークとの間で通信するプロセスと、
移動局の通信プロトコルスタックと移動局のアプリケーションとの間で移動局のアプリケーションのインターフェイスを通して通信するプロセスと、
移動局のアプリケーションのインターフェイスによって機能を呼出すプロセスと、
移動局のアプリケーションのインターフェイスによって、移動局のアプリケーションのインターフェイスの状態と呼出された機能とに基づいて、指定された状況メッセージの少なくとも1つを選択するプロセスと、
移動局のアプリケーションのインターフェイスによって、指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告するプロセスとを行なう機械読出し可能媒体。 - 移動局のアプリケーションが、呼出された機能の立証によって指定された状況メッセージの少なくとも1つを移動局のアプリケーションへ報告する請求項9記載の機械読出し可能媒体。
- 移動局のアプリケーションのインターフェイスが複数の状態を含む請求項9記載の方法。
- 移動局のアプリケーションのインターフェイスが、状態間を非同期に遷移する請求項11記載の方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US53949700A | 2000-03-30 | 2000-03-30 | |
PCT/US2001/010144 WO2001076279A2 (en) | 2000-03-30 | 2001-03-29 | Method and apparatus for a mobile station application to identify specified status messages |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004500785A true JP2004500785A (ja) | 2004-01-08 |
JP2004500785A5 JP2004500785A5 (ja) | 2008-05-08 |
Family
ID=24151469
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001573821A Withdrawn JP2004500785A (ja) | 2000-03-30 | 2001-03-29 | 移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置 |
Country Status (9)
Country | Link |
---|---|
EP (1) | EP1273150A2 (ja) |
JP (1) | JP2004500785A (ja) |
KR (1) | KR20040007214A (ja) |
CN (2) | CN1620157A (ja) |
AU (1) | AU2001251106A1 (ja) |
CA (1) | CA2403813A1 (ja) |
IL (1) | IL151707A0 (ja) |
MX (1) | MXPA02009507A (ja) |
WO (1) | WO2001076279A2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2008075580A1 (ja) * | 2006-12-20 | 2010-04-08 | 日本電気株式会社 | 通信端末、端末、通信システム、通信方法及びプログラム |
US10728855B2 (en) | 2005-06-30 | 2020-07-28 | Nokia Technologies Oy | System coordinated WLAN scanning |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100901715B1 (ko) | 2003-03-12 | 2009-06-08 | 엘지전자 주식회사 | 개인 휴대 단말기와 무선 통신모듈의 인터페이스를 위한 계층구조 |
KR100539903B1 (ko) * | 2004-01-17 | 2005-12-28 | 삼성전자주식회사 | 휴대용 단말기의 vod 데이터 처리방법 |
US7742444B2 (en) | 2005-03-15 | 2010-06-22 | Qualcomm Incorporated | Multiple other sector information combining for power control in a wireless communication system |
US9055552B2 (en) | 2005-06-16 | 2015-06-09 | Qualcomm Incorporated | Quick paging channel with reduced probability of missed page |
US8750908B2 (en) | 2005-06-16 | 2014-06-10 | Qualcomm Incorporated | Quick paging channel with reduced probability of missed page |
CA2513016A1 (en) | 2005-07-22 | 2007-01-22 | Research In Motion Limited | A secure method of synchronizing cache contents of a mobile browser with a proxy server |
CA2513018A1 (en) | 2005-07-22 | 2007-01-22 | Research In Motion Limited | Method for training a proxy server for content delivery based on communication of state information from a mobile device browser |
CA2513022A1 (en) | 2005-07-22 | 2007-01-22 | Research In Motion Limited | System and method for communicating state management between a browser user-agent and a mobile data server |
JP2009514413A (ja) | 2005-10-27 | 2009-04-02 | クゥアルコム・インコーポレイテッド | 無線通信システムにおけるサービングセクタを保守する方法 |
US20090207790A1 (en) | 2005-10-27 | 2009-08-20 | Qualcomm Incorporated | Method and apparatus for settingtuneawaystatus in an open state in wireless communication system |
CN101222443B (zh) * | 2008-01-30 | 2012-04-25 | 杭州华三通信技术有限公司 | 一种处理报文的方法和网络设备 |
CN103582170B (zh) * | 2012-07-23 | 2018-08-10 | 百度在线网络技术(北京)有限公司 | 在移动设备中为多个候选应用提供通信连接的方法与设备 |
CN112637329B (zh) * | 2020-12-21 | 2022-08-23 | 网络通信与安全紫金山实验室 | 一种多应用程序的标识方法、装置、设备及存储介质 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6016511A (en) * | 1997-09-12 | 2000-01-18 | Motorola Inc. | Apparatus and method for interfacing protocol application data frame operation requests with a data frame input/output device |
-
2001
- 2001-03-29 CN CNA2004100898482A patent/CN1620157A/zh active Pending
- 2001-03-29 AU AU2001251106A patent/AU2001251106A1/en not_active Abandoned
- 2001-03-29 WO PCT/US2001/010144 patent/WO2001076279A2/en not_active Application Discontinuation
- 2001-03-29 CA CA002403813A patent/CA2403813A1/en not_active Abandoned
- 2001-03-29 IL IL15170701A patent/IL151707A0/xx unknown
- 2001-03-29 KR KR1020027013065A patent/KR20040007214A/ko not_active Application Discontinuation
- 2001-03-29 JP JP2001573821A patent/JP2004500785A/ja not_active Withdrawn
- 2001-03-29 MX MXPA02009507A patent/MXPA02009507A/es unknown
- 2001-03-29 EP EP01924455A patent/EP1273150A2/en not_active Withdrawn
- 2001-03-29 CN CN01807775A patent/CN1449614A/zh active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10728855B2 (en) | 2005-06-30 | 2020-07-28 | Nokia Technologies Oy | System coordinated WLAN scanning |
US11057835B2 (en) | 2005-06-30 | 2021-07-06 | Nokia Technologies Oy | System coordinated WLAN scanning |
JPWO2008075580A1 (ja) * | 2006-12-20 | 2010-04-08 | 日本電気株式会社 | 通信端末、端末、通信システム、通信方法及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
EP1273150A2 (en) | 2003-01-08 |
CN1449614A (zh) | 2003-10-15 |
AU2001251106A1 (en) | 2001-10-15 |
CA2403813A1 (en) | 2001-10-11 |
MXPA02009507A (es) | 2003-05-14 |
WO2001076279A2 (en) | 2001-10-11 |
CN1620157A (zh) | 2005-05-25 |
KR20040007214A (ko) | 2004-01-24 |
WO2001076279A3 (en) | 2002-03-14 |
IL151707A0 (en) | 2003-04-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4971513B2 (ja) | 移動局のアプリケーションが生のパケット化されたデータを受信および送信するための方法および装置 | |
JP5174206B2 (ja) | 移動局における指定された事象を検出するための方法および装置 | |
JP4745586B2 (ja) | 移動局のアプリケーションが指定されたイベントを識別するための方法および装置 | |
AU2001251105A1 (en) | Method and apparatus for a mobile station application to receive and transmit raw packetized data | |
JP2004500785A (ja) | 移動局のアプリケーションが指定された状況メッセージを識別するための方法および装置 | |
EP1273154A2 (en) | Method and apparatus for notifying a mobile station application of specified events | |
JP2004500784A (ja) | 指定されたイベントを移動局のアプリケーションによってサービスするための方法および装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080313 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080313 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20080520 |