JP2004509539A - コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 - Google Patents
コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 Download PDFInfo
- Publication number
- JP2004509539A JP2004509539A JP2002527943A JP2002527943A JP2004509539A JP 2004509539 A JP2004509539 A JP 2004509539A JP 2002527943 A JP2002527943 A JP 2002527943A JP 2002527943 A JP2002527943 A JP 2002527943A JP 2004509539 A JP2004509539 A JP 2004509539A
- Authority
- JP
- Japan
- Prior art keywords
- network
- mobile computing
- computing device
- mobile
- interface
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 201
- 238000012545 processing Methods 0.000 claims abstract description 47
- 230000002085 persistent effect Effects 0.000 claims abstract description 8
- 238000007726 management method Methods 0.000 claims description 200
- 230000008569 process Effects 0.000 claims description 72
- 230000006854 communication Effects 0.000 claims description 58
- 238000004891 communication Methods 0.000 claims description 58
- 230000032258 transport Effects 0.000 claims description 57
- 230000004044 response Effects 0.000 claims description 54
- 230000005540 biological transmission Effects 0.000 claims description 47
- 230000008859 change Effects 0.000 claims description 46
- 230000007246 mechanism Effects 0.000 claims description 16
- 230000000694 effects Effects 0.000 claims description 12
- 238000001514 detection method Methods 0.000 claims description 9
- 230000011664 signaling Effects 0.000 claims description 6
- 238000012546 transfer Methods 0.000 claims description 6
- 230000006399 behavior Effects 0.000 claims description 5
- 230000003111 delayed effect Effects 0.000 claims description 5
- 238000012986 modification Methods 0.000 claims description 5
- 230000004048 modification Effects 0.000 claims description 5
- 238000013500 data storage Methods 0.000 claims description 2
- 238000007499 fusion processing Methods 0.000 claims description 2
- 238000005259 measurement Methods 0.000 claims 1
- 230000006870 function Effects 0.000 description 46
- 239000012634 fragment Substances 0.000 description 26
- 238000005516 engineering process Methods 0.000 description 13
- 230000009471 action Effects 0.000 description 9
- 230000006855 networking Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000004927 fusion Effects 0.000 description 7
- 230000000670 limiting effect Effects 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 6
- 238000013467 fragmentation Methods 0.000 description 6
- 238000006062 fragmentation reaction Methods 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 238000003860 storage Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 230000003068 static effect Effects 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 206010000210 abortion Diseases 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 238000003619 Marshal aromatic alkylation reaction Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000003032 molecular docking Methods 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 230000002459 sustained effect Effects 0.000 description 2
- 241001417511 Ardis Species 0.000 description 1
- 208000015976 Corneal dystrophy-perceptive deafness syndrome Diseases 0.000 description 1
- 206010019233 Headaches Diseases 0.000 description 1
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 238000002592 echocardiography Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 231100000869 headache Toxicity 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012876 topography Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000011282 treatment Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1887—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/088—Access security using filters or firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
ノマディックなシステムの特性を透過的にする、シームレスなソリューションであって、既存のネットワーク・アプリケーションが、モバイル環境でも確実に動作するようにする。モバイルネットワークと組み合わされたモビリティ管理サーバ(102)は、数量を限定されないモバイル端末システム(104)それぞれの状態を維持し、ネットワークへ、および他のピアでの処理への持続的な接続の維持に必要な、複雑なセッション管理を実行する。モバイル端末システムが圏外に出たり、サスペンドしたり、(例えば、あるネットワーク相互接続から別のものへとローミングして)ネットワークアドレスを変更したりした場合、モビリティ管理サーバは、結合しているピアのタスクとの接続を維持し、モバイル端末システムとネットワーク媒体とのコンタクトが一時的に失われても、モバイル端末システムが持続的な接続を維持できるようにする。インターフェイスベースのリスナは、ネットワーク・インターフェイスからのネットワーク接続ポイント情報を利用して、ローミング状態を判定し、ローミングに際した接続を効率的に確立する。モビリティ管理サーバは、非接続のネットワーク上で該サーバとコンタクトをとるためのリストを、モバイル端末システムに配布する。
Description
[発明の背景]
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック(nomadic)システムの特性を透過性(トランスペアレント)を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末(handheld data units)やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術およびシステムに関する。
【0001】
[発明の背景および要約]
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【0002】
モバイルネットワーキングに関する問題の多くは、イーサネット(登録商標)登場以前にローカルエリア・ネットワーク(LAN)構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【0003】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線装置を経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【0004】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント/サーバ、ホスト/ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【0005】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、TCP/IPセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング(ネットワークアドレスの変更)が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【0006】
(非接続あるいは圏外のユーザ)
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う(つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする)と、携帯装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【0007】
(他のネットワークへの、あるいはルータ境界を越える移動(ネットワークアドレス変更))
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【0008】
(セキュリティ)
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ(つまり、安全な施設の内部に構築されたケーブルを使って実行され)、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【0009】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【0010】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも持たせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【0011】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続(mobile interconnect)に接続されたモビリティ管理サーバ(Mobility Management Server; MMS)は、数量を限定されないモバイル端末システム(Mobile End Systems; MES)それぞれの状態の維持や、ネットワークへおよびピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは(あるモバイル相互接続から別の相互接続へとローミングすることなどで)ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【0012】
また、上記本発明の非限定的で具体的な実施の形態は、以下の(これらに限定されないが)新規かつ有用な技術、構成を提示する。
【0013】
・ユーザによって設定可能なセッション特性をモバイル・クライアントに付与するモビリティ管理サーバ。
【0014】
・ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシーを管理。
【0015】
・工業規格である動的ホスト構成プロトコル(Dynamic Host Configuration Protocol; DHCP)をモビリティ管理サーバと連携させて用いるローミング方法。
【0016】
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【0017】
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【0018】
より詳細には、上記本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムそれぞれの状態を維持し、ネットワークへおよび他の処理(例えば他のネットワークベースのピア・システムにて実行される処理)への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは(あるモバイル相互接続から別の相互接続へとローミングすることなどで)ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【0019】
また、上記本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【0020】
上記本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール(制御)アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション特性を、プロキシ・サーバ上で実行されるモバイル・クライアントについて実現し、ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシー設定を管理する。
【0021】
さらに、上記一側面においては、遠隔プロシージャ・コール(RPC)・プロトコル(Remote Procedure Call protocol)およびインターネット・モビリティ・プロトコル(Internet Mobility Protocol)が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【0022】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、RPCプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【0023】
RPCプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコルおよびインフラを経由して送られるメッセージに生成する。このRPCメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。RPCを備える上記本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【0024】
上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線LANおよびWANといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【0025】
上記本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル(例としてTCP/IP、UDP/IP、DHCPなど)を使用して構築される。上記本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム(信頼度の高いものも低いものも)を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられる、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【0026】
RPC層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違うまたは同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化/逆多重化により、利用可能な帯域幅を(最大限のサイズのネットワークフレームを生成することで)最大限に使うことができ、複数のチャネルを確立することができる(よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある)。
【0027】
上記本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような特徴や利点を実現する。なお、本発明は以下の点に限定されるものではない。
【0028】
・トランスポート・プロトコルの独立性
・ネットワーク上における位置(point of presence; POP)あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能(物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ)
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更(あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。)
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供(これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる)
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現(ヒステリシスに基づいて、フレームサイズ/フラグメント化の閾値、待機中のフレーム数(ウィンドウ)、再伝送時間、およびネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整)。
【0029】
・ネットワーク障害に対する耐性(モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない)
・操作パラメータを調整するための帯域内信号方式をピアに対して提供(接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能)
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現(これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持)
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用(このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる)
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策(インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能)
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能(例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了および/または拒否が可能)。
【0030】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【0031】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」(lock out)ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」(extend)されてしまっていることを考えると非常に重要である(例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ)。これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるURLに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【0032】
また、モバイル端末システムは「信頼性の低い」(untrusted)ネットワーク(つまり組織の管理が及ぶ範囲外のネットワーク)とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入(ingress)フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【0033】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナ(listener)によって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスによって補助されたローミングを行うことが可能になる。本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象(例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など)に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。再接続の際、リスナは予め記録された接続識別情報(attachment identification information)におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」(roam)状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする(これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい)。リスナは(操作を介して学習した)ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号(「同一サブネット上のローミング」、「ローミング」等)の適否を判定する一助としてもよい。
【0034】
上記本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ(MMS)に「非接続ネットワーキング」(disjoint networking)モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、MMSとの通信を確立する/持続するのに使われる、代替のネットワークアドレスを動的/静的に見つけ出すことができるようになる。この構成により、MMSが利用可能な代替アドレスのリストが予め設定され、通信中にMES(モバイル端末システム)に送られるかあるいはMESによって動的に学習される。実施の一形態において、MMSはMESに、一つ以上のMMSネットワークアドレスもしくは他のネットワークに対応した他のMMSのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付/更新が可能である。
【0035】
MESが別のネットワークへと移動するとき、MESは該ネットワークにおける新規のネットワーク接続を通じてMMSとコンタクトをとるために、MMSの「エイリアス」(alias)アドレス/アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、MESは新規のネットワーク接続を通じてMMSとのコンタクトを再確立することができる。
【0036】
上記本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて要求の遂行を許可、拒絶、または制限する。このような管理形態は、例えば、マルチホーム/パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【0037】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得(つまりローミング)に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置(ネットワークのどの接続ポイント、例えばアクセスポイント/基地局、ハブ、ルータ、GPS座標等に近いかなど)に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員(例えばユーザや装置)がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という3つの状態のいずれかをもたらすようにすることも可能である(例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される)。
【0038】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジン(policy engine)によって該アプリケーションによる操作/トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元(例えば、利用可能な/許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング)がある。
【0039】
さらに、ルールエンジン(rules engine)は、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【0040】
上記実施例におけるポリシー管理エンジン(policy management engine)において、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【0041】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、および/またはアセット・トラッキングのために取得され/備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【0042】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース PAN、IEEE 802.11 LAN、802.15 PAN、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としは、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【0043】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【0044】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。3G WANネットワーク、ブルートゥースネットワーク、802.11ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【0045】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【0046】
本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【0047】
[好ましい実施の形態の詳細な説明]
図1は、本発明の、モバイル強化ネットワークコンピュータシステム100を例示している。該ネットワークコンピュータシステム100は、モビリティ管理サーバ102と、一つ以上のモバイル端末システム104とを含んでいる。モバイル端末システム104は、ローカルエリア・ネットワーク(LAN)108を通じてモビリティ管理サーバ102と通信することができる。モビリティ管理サーバ102は、モバイル端末システム104のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ102はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム110とも、モビリティ管理サーバ102とモバイル端末システム104との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。本好ましい実施形態では、モビリティ管理サーバ102は、本発明の遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いて、モバイル端末システム104と通信する。
【0048】
この場合、モバイル端末システム104はモビリティ管理サーバ102とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム104a‐104kが、モビリティ管理サーバ102と、モバイル相互接続によって(この場合無線で)通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク108と無線(あるいは有線)でつながった、従来型の電磁(電波)トランシーバ106が考えられる。上記のようなモバイル相互接続により、モバイル端末システム104a‐104kが、一つのカバーエリア(cover area)107aから別のカバーエリア107kへとローミングすることが可能になる。一般的に、モバイル端末システム104が、あるカバーエリア107から別のエリアにローミングしたり、最も近いトランシーバ106から届く範囲を外れたり、あるいは信号を一時的に遮断(例えばビルの柱の裏側を通るなどで)されたりした場合、一時的に通信が切断される。
【0049】
・別のモバイル端末システム104l、104m…が、モビリティ管理サーバ102と、ドッキングポートやネットワークケーブルコネクタなどの着脱式(non−permanent)有線相互接続109を介して通信する。モバイル端末システム104は、接続109が外れたり、モバイル端末システム104の電源が切られたりした場合、一時的にLAN108から切断される。
【0050】
・さらに別のモバイル端末システム(例えば104n)が、モビリティ管理サーバ102と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ111を介してノマディック接続される。一例として、ネットワーク111のサービスは断続的なものであってもよく、他の例として、モバイル端末システム104がある種類の接続形態から別の種類のものへと移行(例えば、モビリティ管理サーバ102と有線相互接続109を通じて接続される状態からネットワーク111を通じて接続される状態へ移行、もしくはその逆)し、移行時に一時的に接続が切断されるという構成であってもよい。
【0051】
モバイル端末システム104は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム104は、市販のトランシーバおよび/またはネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム104は、標準的なネットワーク・アプリケーションや標準的なOS(オペレーティングシステム)を実行し、標準的なトランスポート・レベル・プロトコル(例えばTCP/IP)を利用して、トランスポート層で通信を行うものであってよい。本発明において、さらに、モバイル端末システム104がクライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ102との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【0052】
モビリティ管理サーバ102は、ウィンドウズ(登録商標)NTサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本好ましい実施形態では、モビリティ管理サーバ102は、規格に準拠したクライアント/サーバ型のインテリジェントサーバであって、企業ネットワーク108を透過性を有した状態でノマディック環境にまで延長するものである。モビリティ管理サーバ102は、数量を限定されないモバイル端末システム104それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ102はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム110とも、モバイル端末システム104とトランシーバ106との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【0053】
例えば、サーバ102はどのような標準的(例えばTCP/IPベースの)ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム104のセッションは、サーバ102によって維持され、該システムが復帰した際にはサーバ102が上記セッションをレジュームする。モバイル端末システム104が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ102は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム110との接続を維持する。
【0054】
サーバ102はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【0055】
一例として、モビリティ管理サーバ102が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク108と接続され、該ネットワーク108は、様々な固定端末システム(例えば一つ以上のホストコンピュータ110)110と接続される状況が考えられる。モビリティ管理サーバ102によって、モバイル端末システム104と固定端末システム110との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム104が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続106、109、111から別のネットワーク相互接続へと移動したりしても(例えば、無線相互接続の場合、ある無線トランシーバ106のカバーエリア107から別のカバーエリアにローミングしても)、利用可能となっている。
【0056】
モバイル端末システム104は、モビリティ管理サーバ102との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム104は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。モバイル端末システム104−モビリティ管理サーバ102間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本好ましい実施形態では上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【0057】
本発明の一例において、モバイル端末システム104は、UDP/IPのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ102と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム104が、標準的なルータ112など企業ネットワーク108に既存のインフラを用いて、モビリティ管理サーバ102と通信することが可能になる。本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク108を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージへと生成する。本好ましい実施形態において、上記のようなモバイルRPCメッセージは、モバイル端末システム104にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ102によって全てを完了させることができる。このことにより、モビリティ管理サーバ102とモバイル端末システム104とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【0058】
モバイル端末システム104のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルRPCプロトコルを通じてモビリティ管理サーバ102にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。本好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム104に実装されているOS(ウィンドウズ(登録商標)NT、ウィンドウズ(登録商標)98、ウィンドウズ(登録商標)95、ウィンドウズ(登録商標)CEなど)と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【0059】
モビリティ管理サーバ102は、それぞれのモバイル端末システム104の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ110のような通信相手のピア108との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。モバイル端末システム104との通信ができなくなったり、モバイル端末システム104がサスペンドしたり、あるいはネットワークアドレスを変更したり(例えばあるネットワーク相互接続から別のものにローミングしたり)した場合、モビリティ管理サーバ102は、モバイル端末システム104とホストシステム110などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム104との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア107K内において、あるネットワーク相互接続106Aから別のネットワーク相互接続106Kへとローミングしたりした場合でも、(物理的接続が再確立された際に単純に作業をレジュームすることで)モバイル端末システム104のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【0060】
モビリティ管理サーバ102はまた、モバイル端末システム104がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。モバイル端末システム104はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム104のそれぞれについて、モビリティ管理サーバ102は該システムの現状における実際の(位置)アドレスに対応して仮想アドレスを割り当てる。モバイル端末システム104の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム104の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【0061】
よって、モバイル端末システム104の位置アドレスの変更は、モビリティ管理サーバ102を介して、結合しているホストシステム110(および他のピア)におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア110から見えるのは、サーバ102によってプロキシされた(不変の)仮想アドレスのみということになる。
【0062】
本好ましい実施形態では、モビリティ管理サーバ102はさらに、コンソール(制御)アプリケーションと包括的なメトリクス(exhaustive metrics)とによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続およびシステムにおける問題を解決することができる。
【0063】
モビリティ管理サーバ102によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ102が有する処理用のリソースが有限であることを鑑みれば、有用なものである。システム管理者が上記のようにモビリティ管理サーバ102の設定を変更できることで、システムおよびネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ102の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ102のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【0064】
詳しく説明すると、モビリティ管理サーバ102は、アプリケーション、もしくはSNMPのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合(association)そのものの優先度、および/または、ある結合における複数のアプリケーションの優先度を設定することも可能である。例えば、モビリティ管理サーバ102を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である(本実施形態では、ユーザおよびユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい)。あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の3つの優先レベルが設定される例が考えられる。
【0065】
(サーバ/クライアント型ソフトウェア・アーキテクチャの例)
図2に、モバイル端末システム104とモビリティ管理サーバ102とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム104とモビリティ管理サーバ102は標準的なOSおよびアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク108を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。図2に示すように、モバイル端末システム104は、ネットワーク・インターフェイス・ドライバ200、TCP/UDPトランスポートサポート202、トランスポート・ドライバ・インターフェイス(TDI)204、および一つ以上の従来型のネットワーク・アプリケーション208に対するインターフェイスとして使われるソケットAPI206を含む、従来型のOSソフトウェアを実行する。従来型のネットワーク・ファイル/プリント・サービス210が、従来型のTDI204との通信用にさらに設けられていてもよい。サーバ102は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ200’、TCP/UDPトランスポートサポート202’、トランスポート・ドライバ・インターフェイス(TDI)204’、および一つ以上の従来型のネットワーク・アプリケーション208’に対するインターフェイスとして使われるソケットAPI206’を有していてもよい。モバイル端末システム104とモビリティ管理サーバ102はそれぞれ、さらにネットワーク/セキュリティ・プロバイダ236(モバイル端末システム)、ユーザ/セキュリティ・データベース238(サーバ)を備えていてもよい。
【0066】
本発明では、新規のモバイル・インターセプタ・コンポーネント212が、モバイル端末システム104のソフトウェア・アーキテクチャにおける、TCP/UDPトランスポートモジュール202とトランスポート・ドライバ・インターフェイス(TDI)204との間に挿入されている。該モバイル・インターセプタ・コンポーネント212は、トランスポート・ドライバ・インターフェイス(TDI)204における特定のコールを傍受して、該コールを、ネットワーク108を介し、RPCおよびインターネット・モビリティ・プロトコル、標準的なTCP/IPトランスポート・プロトコルを通じてモビリティ管理サーバ102へと転送する。こうして、モバイル・インターセプタ212は、全てのネットワーク活動を傍受して、サーバ102へと転送することができる。該インターセプタ212はOSと透過性を有する状態で協働するので、モバイル端末システム104がネットワーク108とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【0067】
モバイル・インターセプタ212は、トランスポート・ドライバ・インターフェイス204とは違うレベルで(例えばソケットAPI206のレベルで)動作することもできるが、TDIのレベルでモバイル・インターセプタ212が動作する、より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをTDIという略語で表わすこととする。多くの標準的なOS(例えば、マイクロソフト社のウィンドウズ(登録商標)95、ウィンドウズ(登録商標)98、ウィンドウズ(登録商標)NT、ウィンドウズ(登録商標)CEなど)はTDIインターフェイス204を実装しているので、OSのコンポーネントを変更することなく互換性が保証される。さらに、トランスポート・ドライバ・インターフェイス204は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【0068】
さらに、TDIインターフェイス204のレベルで作動するモバイル・インターセプタ212は、様々な別のネットワーク・アプリケーション208(例えば複数の同時に動作しているアプリケーション)に加えて、ネットワークにおけるファイル、プリント、および他のカーネル・モードなどのサービス210(インターセプタが例えばソケットAPI206のレベルで動作している場合はそれぞれ別に扱う必要がある)を傍受することができる。
【0069】
図2Aに、どのようにインターセプタ212が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム104のTDIインターフェイス204へのコール(ブロック250)は、モバイル・インターセプタ212によって傍受される(ブロック252)。モバイル・インターセプタ212によって傍受されたRPCコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、UDPやTCPといった標準的なトランスポート・プロトコルにより、LAN、WAN等のトランスポート108を介してモビリティ管理サーバ102へと送られる(ブロック252)。モビリティ管理サーバ102は受信したRPCデータグラムをアンパックして(ブロック254)、要求されたサービスを実行する(例えば、データや応答を、固定端末システム110で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション208のプロキシとして振舞う)。
【0070】
再び図2に戻って、モビリティ管理サーバ102は、従来型のネットワーク・インターフェイス・ドライバ222を介して送られる、モバイル端末システム104からの、あるいはモバイル端末システム104へ向かうメッセージを傍受する、アドレス変換部220を有している。例えば、アドレス変換部220は、セッションの相手のピア(固定端末システム110)からのモバイル端末システム104の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ224へと送られる。プロキシ・サーバ224は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム104の現在位置アドレスへと転送する。
【0071】
さらに、図2によると、モビリティ管理サーバ102は、アドレス変換部(中間ドライバ)220とプロキシ・サーバ224に加えて、設定マネージャ228、操作/ユーザインターフェイス230、およびモニタ232を有している。設定マネージャ228は設定情報とパラメータとを提供して、プロキシ・サーバ224が接続の管理を行えるようにする。操作/ユーザインターフェイス230とモニタ232により、ユーザとプロキシ・サーバ224との間のやりとりが可能になる。
【0072】
(モバイル・インターセプタ)
図3は、本発明のRPCプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ212のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ212は、遠隔プロシージャ・コール・プロトコル・エンジン240と、インターネット・モビリティ・プロトコル・エンジン244の、二つの機能コンポーネントを有している。モビリティ管理サーバ102において動作するプロキシ・サーバ224によって、対応するエンジン240’、244’が用意される。
【0073】
このように、本好ましい実施形態におけるモバイル・インターセプタ212は、モビリティ管理サーバ102をそれぞれのモバイル端末システム104と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。RPCプロトコルの利用によって、モバイル端末システム104が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク108において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【0074】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケット(Windows sockets)のようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのAPIへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信および受信データパケットが生成される。優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はRPCを備えており、モビリティ管理サーバ102とモバイル端末システム104とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【0075】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【0076】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ102とモバイル端末システム104との間の通信がなされる際の、機密情報のセキュリティを保証する。インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ102とモバイル端末システム104との間での全ての通信を認証、暗号化することを可能にする。
【0077】
図3のモバイル端末システム104における遠隔プロシージャ・コール・プロトコル・エンジン240は、TDIコールパラメータをマーシャリングし、データをフォーマットし、要求を、TDI遠隔プロシージャ・コール・プロトコル・エンジン240’がコールを実行するモビリティ管理サーバ102まで転送するべく、インターネット・モビリティ・プロトコル・エンジン244に送る。モバイル端末システム104は、遠隔プロシージャ・コール・プロトコルに基づいてTDIコールパラメータをマーシャリングする。モビリティ管理サーバ102のTDI遠隔プロシージャ・コール・プロトコル・エンジン240’が上記のRPCを受信すると、モビリティ管理サーバ102はモバイル端末システム104に代わってコールを実行する。モビリティ管理サーバ102のTDI遠隔プロシージャ・コール・プロトコル・エンジン240’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム104のRPCエンジン240と共有する。モバイル端末システム104の代理としての遠隔プロシージャ・コール実行に加え、サーバのRPCエンジン240’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの(アドレス変換機構220が行うサービスに対応した)多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、および融合処理(coalescing)を行う。
【0078】
インターネット・モビリティ・プロトコル・エンジン244は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、およびメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。インターネット・モビリティ・プロトコル・エンジン244は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【0079】
図3Aは、モバイル・インターセプタ212がモビリティ管理サーバ102と通信してTDIコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ212のRPCプロトコル・エンジン240は、マーシャリングされたTDIコールを、モビリティ管理サーバ102へと送るべく、インターネット・モビリティ・プロトコル・エンジン244へと転送する。RPCプロトコル・エンジン240は、この作業を、インターネット・モビリティ・プロトコル・エンジン244によって管理されるキューにRPCコールを加えることで達成する(ブロック302)。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン244は受信したRPCコールの転送を所定の期間(RPC融合タイムアウト期間)遅延させる(ブロック304)。一般的に、RPC融合タイムアウトは5ミリ秒から15ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、RPCエンジン240はTDIコールをインターネット・モビリティ・プロトコル・エンジン244のキューに加えて、一つ以上のRPCコールが同一のデータグラム(フラグメント)によって転送されるようにすることができる。
【0080】
融合タイムアウトが終了するか、RPCエンジン240がそれ以上のRPCコールの受信を拒否する(判定ブロック306)ことを決定すると、RPCエンジン240は、インターネット・モビリティ・プロトコル・エンジン244に、キューをフラッシュ(flush)し、RPCコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する(ブロック308)。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー244をフラッシュすることもしなければならず、本好ましい実施形態において、単一のRPC要求でフレーム全体が占められてしまう場合、IMP層は自動的に要求をピアに送るよう試みる。
【0081】
上記のように、モビリティ管理サーバ102のプロキシ・サーバはRPCプロトコル・エンジン240’とインターネット・モビリティ・プロトコル・エンジン244’とを有している。図3Bは、モバイル端末システム104からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ102で実行される処理を例示している。該フレームをモビリティ管理サーバ102が受信すると、インターネット・モビリティ・プロトコル・エンジン244’は、フレームが(基礎となるトランスポートの最大伝送量の制約で)フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム104からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン244’は、遠隔プロシージャ・コール・プロトコル・エンジン240’に、的確な結合関連文脈情報(association−specific context information)を伝えることができる。
【0082】
続いて、インターネット・モビリティ・プロトコル・エンジン244’は、受信したメッセージを、RPC受信示唆システム作業要求(RPC receive indication system work request)354にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ102のRPCプロトコル・エンジン240’に与える。RPCプロトコル・エンジン240’が作業要求352を受信すると、該エンジン240’は作業要求352を結合関連作業キュー356に加え、次に予定済みの要求をグローバルキュー358に送ることによって、結合処理のスケジューリングが行われる。続いて、RPCエンジン240’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー358がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー356が処理される。
【0083】
結合関連作業キュー356から、上記メインスレッドはそれまで待機していたRPC受信示唆作業要求を見つけ出す。次に、メインスレッドはRPC受信示唆作業要求356をキューから外し、該要求を解析する。図3Aを参照して説明した上記融合処理により、モビリティ管理サーバ102は、それぞれのデータグラムに内包された複数のRPCトランザクションを頻繁に受信することになる。モビリティ管理サーバ102は次に、該RPCトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム104に代わって実行する。パフォーマンス向上のため、RPCエンジン240’に、RPCメッセージ解析処理中の先読みメカニズムを備えさせて、RPCエンジン240’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か(パイプライン処理できるか否か)を確認してもよい。
【0084】
(RPCエンジン240’によるRPC結合の実行手法)
図4は、結合作業キュー356に加えられたRPC結合を実行する処理を例示したフローチャートである。RPC結合の実行が予定されている時、RPCプロトコル・エンジン240’(状態機械として設けられていてもよい)のメインスレッドは、グローバルネットワークキュー358からの作業要求を待機状態から外し、作業要求の種類を決定する。
【0085】
本実施形態のRPC作業要求は、以下のような6つの基本的な種類に分けられる。
【0086】
・スケジューリング要求(schedule request)
・接続示唆
・切断示唆
・ローカル結合中止(local terminate association)
・「リソース使用可」要求(”resource available” request)
・ping休止タイムアウト(ping inactivity timeout)
RPCプロトコル・エンジン240’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。RPCプロトコル・エンジン240’は要求の種類(グローバルキュー358に記憶された、要求に関する情報によって識別される)をテストして、該要求をどう処理するかを決定する。
【0087】
作業要求の種類が「スケジューリング要求」である場合(判定ブロック360)、RPCプロトコル・エンジン240’はどの結合が予定されているかを判別する(ブロック362)。RPCプロトコル・エンジン240’はこの判別を、グローバルキュー358に記憶されている情報に基づいて実行することができる。上記判別がなされると、RPCプロトコル・エンジン240’が、それぞれが対応する要求を記憶している結合作業キュー356(1)〜356(n)のうちの一つを特定することが可能となる。RPCエンジン240’によって、対応する結合制御ブロックが取得され(ブロック362)、結合作業処理タスク(Process Association Work task)364が呼び出されて、上記の特定された作業キュー356における作業の処理が始められる。
【0088】
図5は、図4の「結合作業処理」タスク364によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク364が呼び出され、対応する結合作業キュー356内の作業が処理される。待機状態から外された作業要求(ブロック390)がRPC受信要求(判定ブロック392)である場合、該RPC受信要求はRPC構文解析部(parser)に送られ、処理される(ブロック394)。あるいは、待機状態から外された作業要求(ブロック390)が、保留中の(pending)受信要求である場合(判定ブロック396)、RPCエンジン240’はTDI204’に、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する(ブロック398)。上記待機状態から外された作業要求が、保留中の接続要求である場合(判定ブロック400)、RPCエンジン240’はTDI204’に、アプリケーション用途TCP(あるいは他のトランスポート・プロトコル)接続要求を発するよう要求し(ブロック402)、TDI層204’からの応答を待つ。TDI204’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、RPCエンジン240’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー(356)へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅およびリソースの消費を減らすためのものである。
【0089】
上記の処理は、「スケジューリング重み付け」(scheduling weight complete)テスト(ブロック404)にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ228によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される(図4、ブロック372)。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【0090】
RPCエンジンが結合作業キュー356の作業を(少なくとも一時的に)終了した後、ディスパッチ・キューの処理に移ってもよい(ブロック406)(詳細は以下)。結合の作業キュー356における作業の処理後、RPCエンジン240’は、グローバル作業キュー358に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う(図4の判定ブロック366、ブロック368、図5の判定ブロック408、ブロック410)。
【0091】
再度図4を参照すれば、RPC作業要求が「接続示唆」の場合(判定ブロック370)、RPCエンジン240’に、モバイル・ピア(通常はモバイル端末システム104だがこれに限らない)との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がRPCエンジン240’に与えられる。
【0092】
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのRPCエンジン240からの、付加的な接続データ
接続示唆(判定ブロック370)を受け、RPCエンジン240は上記のパラメータをもって設定マネージャ228をコールする。設定マネージャ228は該パラメータを用いて、上記新規接続の設定を確定する。この設定(例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど)は、RPCエンジン240’に戻されて記憶、実行される。そしてRPCエンジン240’は新規の結合を開始し、新規の結合制御ブロックを形成する(ブロック372)。図5Aが示すように、以下のような動作が実行されてもよい。
【0093】
・結合制御ブロックを割り当てる(ブロック372A)
・システム全体のリソースをデフォルトにまで初期化する(ブロック372B)
・現在の設定をオーバーライドする(ブロック372C)
・フラグを初期化する(ブロック372D)
・結合特有作業キューを初期化する(ブロック372E)
・結合のオブジェクト・ハッシュ・テーブルを初期化する(ブロック372F)
・融合タイマーを初期化する(ブロック372G)
・結合制御ブロックをセッションテーブルに挿入する(ブロック372H)
インターネット・モビリティ・プロトコル・エンジン244’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン244’からRPCエンジン240’に出される。RPCエンジン240’はこの切断示唆をテストし(ブロック374)、示唆に応じて結合を停止し、結合制御ブロックを破棄する(ブロック376)。図5Bに示されるように、以下のステップが実行されてもよい。
【0094】
・待機中の作業がこれ以上処理されないように、停止される結合をマークする(ブロック376A)
・処理を含む、結合されている全ての結合オブジェクトをクローズする(ブロック376B)
・作業キューにある全てのエレメントを開放する(ブロック376C)
・融合タイマーが動作中ならば停止する(ブロック376D)
・結合制御ブロックの参照カウントを減少させる(ブロック376E)
・参照カウントが0の場合、(ブロック376Fにてテストされる)
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する(376G)
システム102が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、OS、あるいはアプリケーションから発される。RPCエンジン240’は、セッション中止要求を上記切断示唆と同様に扱う(判定ブロック378、ブロック376)。
【0095】
本好ましい実施形態では、RPCエンジン240’とインターネット・モビリティ・プロトコル・エンジン244’との間のインターフェイスが、クレジット(credits)を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは0になるが、慣例として、コールする側のスレッドは、クレジットのカウントが0ならばそれ以上作業通知をしない。よって、ユーザによって設定可能あるいは所定の最低点(low−water mark)をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である(判定ブロック380にてテストされる)。図5Cが示すように、クレジットのカウントが0になったとき、以下のようなステップが実行されてもよい。
【0096】
・RPC_LMPQ_SEND_FLAGと設定して、結合に「ロー・マーク保留」(low mark pending)とマークを付ける(ブロック379A)。この状態になったら、
・受信された全てのデータグラムを破棄する(ブロック379B)
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える(ブロック379C)(これにより、TCP他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム110とモビリティ管理サーバ102との間のフロー制御がなされる。復帰の前に、本好ましい実施形態では「保留受信要求」(pending receive request)を結合関連作業キュー356の前に押し込むので、保留中のストリーム受信イベントの処理(outstanding stream receive event processing)が、リソースが利用可能になると直ちに継続される)。
【0097】
・全ての受信された接続イベントが、受動接続のために拒否される(ブロック379D)
「リソース使用可」示唆をRPCエンジン240’が受け取ると(図4、判定ブロック380)、該RPCエンジンは、結合された結合作業キュー356に待機中の作業があるか否かを判定する。もしあれば、RPCエンジンは該結合についてグローバル作業キュー358に通知して、上記結合作業キュー356が動作の優先権を持つことをマークしておく(ブロック382)。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される(本好ましい実施形態では、RPCエンジン240’は、この処理中も全ての受信された接続要求を受け入れる)。
【0098】
再度図4を参照すると、RPCエンジン240’が、モビリティ管理サーバ102の「ping」に使われるチャネルが所定の期間にわたって休止していると判定した場合(判定ブロック384)、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される(ブロック386)。
【0099】
(RPC構文解析と優先キュー)
再度図5を参照すると、RPCエンジンがRPC受信要求をその受信に際して構文解析することは前述した(ブロック392、394参照)。本好ましい実施形態において、構文解析は以下の点で必要とされる。即ち、受信された単一のデータグラムが複数のRPCコールを含む可能性があるからであり、また、RPCコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。RPC受信作業要求500のフォーマットの例が図6に示される。RPC受信作業要求のそれぞれは、少なくともメイン・フラグメント502(1)を有し、加えて任意の数の付加的フラグメント502(2)〜502(N)を有していることもある。メイン・フラグメント502(1)は、作業要求構造ヘッダ(work request structure header)503と、受信オーバーレイ504とを有している。受信オーバーレイ504は、インターネット・モビリティ・プロトコル・エンジン244によってメイン・フラグメント502(1)の先頭に設けられた受信オーバーレイである。この受信オーバーレイ504には、pユーザデータと呼ばれる、作業要求500内で最初のRPCコール506(1)を指し示す構造メンバがある。
【0100】
図6の例に、複数のRPCコール506(1)、506(2)…506(8)を含む、作業要求500が図示されている。図6の例が示すように、RPC作業要求500は、メモリの隣接するブロックや単一のフラグメント502に含まれていなくてもよい。同例において、第二フラグメント502(2)と第三フラグメント502(3)とは、リンクしたリスト中でメイン・フラグメント502(1)に連鎖されている。
【0101】
よって、上記例のRPCパーサ394は以下の境界条件を取り扱う。
【0102】
・RPC受信要求500それぞれが一つ以上のRPCコールを含んでもよい
・一つ以上のRPCコール506が、単一のフラグメント502中に存在してもよい
・RPCコール506それぞれが、フラグメント502中に完全に含まれていてもよい
・RPCコール506それぞれは、一つ以上のフラグメント502にまたがっていてもよい
図7は、RPC受信作業要求500を解析するRPC構文解析部394を例示している。本例において、RPC構文解析部394は作業要求中の第一フラグメント502(1)を取得し、該フラグメント中の第一RPCコール506(1)を取得し、そしてRPCコールを解析する。構文解析部394はRPC受信作業要求500中を進んで、RPCコール506それぞれを処理していく。RPC受信作業要求500のフラグメント502(1)の残りのフラグメント・バイト数が、RPCヘッダ503のサイズよりも多い場合、構文解析部394は、RPCコールが完全にRPCフラグメント502に含まれていて、処理を実行してもよいかどうかを判定する(該判定は、RPCコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい)。RPCコールの種類が連鎖例外である場合、RPCコールはRPC構文解析部394のアップデートを行うことになる。プロキシ・サーバ224において、連鎖例外であるRPCコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、RPCエンジンは、RPC送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【0103】
構文解析部394がRPCコールの種類を判別すると、RPC情報の始めへのポインタは、実行のためにRPCエンジン240へと転送される。RPCエンジンは、実行のために全てのTDIプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、RPCディスパッチャ395へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー510にディスパッチされる。ディスパッチ・キュー510はそれぞれ離散的な優先度を表わしている。
【0104】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクト機能を、他のTDIネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレスまたは接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【0105】
例えば、RPCコールがTDIオープンアドレスオブジェクト要求あるいはTDIオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくRPCディスパッチャ395に送られる。オープンアドレスおよびオープン接続オブジェクトRPCコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ228からもたらされる情報との対応に用いられる、処理IDあるいは処理名へのアクセスが可能になる。該処理IDあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【0106】
本好ましい実施形態では、全てのRPCコールは、パラメータとして少なくともアドレスオブジェクトまたは接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、RPCコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するRPCコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー510にディスパッチされることなく、全てのRPCコールが直ちに実行される。割り当てられた優先度が「1」の場合、全てのRPCコールが、ディスパッチ・キュー510(1)に加えられる。
【0107】
再度図5を参照すると、「結合作業処理」(process association work)タスク364の処理が、予定された結合作業量の実行を完了すると(判定ブロック404)、ディスパッチ・キューがサービスを要求しているか否かが確認される(ブロック406)。図8は、図7に示されるディスパッチ・キュー510の処理のための「ディスパッチ・キュー処理」(ブロック406、図6)によって実行されるステップを例示したフローチャートである。
【0108】
この例では、ディスパッチ・キュー510は優先度が最高のキュー(本例では510(1))から処理される(ブロック408)。ディスパッチ・キュー510にはそれぞれ重み係数が設定されている。この重み係数は、モバイル端末システム104とモビリティ管理サーバ102との結合が確立された際に、設定マネージャ228によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー510の重み係数は4であり、優先度が中程度のディスパッチ・キュー510重み係数は8である。本例では、優先度の高いRPCコールは解析後直ちに処理されるため、重み係数を有していない。
【0109】
RPCエンジン240’は、現在のキューより始めて、RPCコールをキューから外していき、キューが空になるか、RPCコールのキュー重み番号(queue weight number)が処理されるまでループする(ブロック412−416)。キューから外されたRPCコールそれぞれに対して、その実行のためにRPCディスパッチャ395が呼び出される。RPCディスパッチャ395はモバイル端末システム104の代理としてプロシージャ・コール(procedural call)を実行し、応答を要求している上記RPCコールに対するモバイル端末システムからの応答を生成する。
【0110】
上記ループを出た後、キューに残っている作業がまだある場合(判定ブロック418)、該キューが再実行を要することがマークされる(ブロック420)。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる(ブロック424、410)。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図4の「グローバル作業処理」ルーチンにおいて予定される。上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ102のCPUへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にCPUにアクセスできるようになる。
【0111】
(モビリティ管理サーバのRPC応答)
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム104からモビリティ管理サーバ102に送られて実行されるかを説明した。この型のRPCコールに加え、モビリティ管理サーバ102のRPCエンジン240’はRPCイベントとRPC受信応答とをサポートしている。結合関連接続ピア(通常は固定端末システム110)の活動の結果として、RPCメッセージが非同期的に生成される。モビリティ管理サーバ102のRPCエンジン240’は、RPCディスパッチャ395によって実行されるRPCトランザクションを完了する。完了が成功したからといって、全てのRPCコールが応答を要求するわけではないが、応答を要求する一部のRPCコールにより、RPCディスパッチャ395は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン244’に知らせ、そして該応答はピアのモバイル端末システム104に返される。RPCコールが失敗したときは、全てのRPCコールが応答を生成する(上記においてRPC受信応答は例外)。
【0112】
RPCイベントは、結合関連接続(通常は固定端末システム110)によるネットワーク108の活動の結果として発信される。本好ましい実施形態では、こうしたRPCイベントメッセージはモビリティ管理サーバ102によってプロキシされ、モバイル端末システム104へ送られる。本好ましい実施形態のモビリティ管理サーバ102は、以下のRPCイベントコールをサポートする。
【0113】
・切断イベント(結合特定接続ピア(通常は固定端末システム110)がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム104に代わってプロキシ・サーバ224に受信され、プロキシ・サーバ224は切断イベントをモバイル端末システムに送る)
・ストリーム受信イベント(結合特定接続ピア(通常は固定端末システム110)がストリームデータをモバイル端末システム104へ送る際に生起。プロキシ・サーバ224はモバイル端末システム104に代わって該データを受け取り、受信応答(Receive Response)として該データをモバイル端末システムに送る)
・データグラム受信イベント(結合特定ポータル(association−specific portal)のいずれかが、ネットワーク・ピア(通常は固定端末システム110)から送られ、モビリティ管理サーバ102を経由してモバイル端末システム104へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ224はモバイル端末システム104に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム104へ転送する)
・接続イベント(結合特定リスニングポータル(association−specific listening portal)が、トランスポート層とモバイル端末システム104との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求(通常は固定端末システム110から)を受信するときに生起する。プロキシ・サーバ224はモバイル端末システムに代わって接続要求を受け入れ、接続イベントRPCコールを生成してモバイル端末システムに送る)
図9は、RPCエンジン240’が、いかにしてプロキシ・サーバによって生成されたRPCコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、RPCエンジン240’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン244’に向けてディスパッチする。該送信要求によって、RPCメッセージがピアのモバイル端末システム104に転送される。優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン244の送信要求が適切な優先キュー510’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー358’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図5および8を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【0114】
(インターネット・モビリティ・プロトコルの例)
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、(再)オーダ検出((re)order detection)、ロス回復が可能である。さらに、他の従来型接続指向プロトコル(即ちTCP)とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【0115】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点(POP)あるいはネットワーク・インフラは、物理的境界、特定のポリシー、あるいは帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【0116】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【0117】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、(下層のネットワークがサポートしていれば)サービス品質の保証も可能になる。
【0118】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間(validity time period)か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【0119】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールド(optional field)によって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールド(header flag field)のビットによって示される。ピアによる通信に必要な他の制御および設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【0120】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズム(Fletcher checksum algorithm)が、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【0121】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、TCPの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大65535バイト(インターネット・モビリティ・プロトコル・ヘッダを含む)までの、データのフレームを表現している。該シーケンス番号は32ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【0122】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送(再試行)されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームIDを設定して最新のバージョンのフレームが検知することも可能だが、本好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【0123】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる(伝送できる)。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【0124】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値(retransmission timeout value)の基準となる。フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値および下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【0125】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ(フラグメント化閾値)、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【0126】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性(例えばフレームサイズ)が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい(大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため)。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される(あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる)。
【0127】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。運営上必要な操作を可能にするため、モビリティ管理サーバ102上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム104からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ102はセッションを終了させることができる。また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ102側からのみ操作できるようにしてもよい。
【0128】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ(登録商標)NT、9x、CE環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層(network abstraction layer; NAL)のサービスが採用されている。メモリ管理、キューおよびリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム104に備えられているか、あるいはモビリティ管理サーバ102側に備えられているかによって変更される。これについて、数例を以下に示す。
【0129】
・特定のタイムアウトは、モビリティ管理サーバ102からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム104の設定により、着信接続(inbound connection)の拒否が可能
・警報はモビリティ管理サーバ102にのみ通知される
・電力管理はモバイル端末システム104ではイネーブルにされるが、モビリティ管理サーバ102では必ずしも必要でない
インターネット・モビリティ・プロトコルのインターフェイスは、Cコーラブルでプラットフォームに依存しない標準的なAPI機能をほんの少数有し、作業(上記の標準的なユーティリティ機能以外)を予定する、OS特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト(作業要求)の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【0130】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、FIFOオーダに従ってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ProtocolRequestwork()」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでOSのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム(例えばウィンドウズ(登録商標)NT)や同期式のシステム(例えばマイクロソフト・ウィンドウズ(登録商標)9xやウィンドウズ(登録商標)CE)で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、(下の層がサポートしていれば)サービス品質を保証することができる。
【0131】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術(scatter−gather techniques)を利用している。伝送はそれぞれフラグメントのリストとしてNALに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、NAL層により、NAL登録処理(NAL registration process)時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【0132】
(インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例)
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップおよびシャットダウン行動を管理する、4つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
【0133】
1.Internet Mobility ProtocolCreate()
2.Internet Mobility ProtocolRun()
3.Internet Mobility ProtocolHalt()
4.Internet Mobility ProtocolUnload()
(Internet Mobility ProtocolCreate()の例)
Internet Mobility ProtocolCreate()機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ228のサービスを利用して該テーブルを設定(populate)する。
【0134】
次に、インターネット・モビリティ・プロトコルは、サスペンドおよびレジューム通知機能をAPMハンドラに登録する。一例ではこれらの機能はモバイル端末システム104の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ102がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルNALポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【0135】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の2段配列構成(2−tier array scheme)を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、_STATE_INITIALIZE_となる。
【0136】
(Internet Mobility ProtocolRun()の例)
Internet Mobility ProtocolRun()機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【0137】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−NAL間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、NALの全てのリスナをスタートさせることができる。一例として、この動作は2つのステップを含んだ以下の処理のようになる。
【0138】
・インターネット・モビリティ・プロトコルは、NAL層に、初期化中に供給される設定に基づいたポータルを結びつけて(bind)オープンし、
・インターネット・モビリティ・プロトコルは、次に、Internet Mobility ProtocolRCVFROMCBコールバックを登録して、受信したフレームの処理を始める準備ができたことを、NAL層に通知する。
【0139】
・引き続き、ローカル持続識別子(local persistent identifier; PID)が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、_STATE_RUN_に変わる。
【0140】
(Internet Mobility ProtocolHalt()の例)
Internet Mobility ProtocolHalt()機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが_STATE_HALTED_状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【0141】
(Internet Mobility ProtocolUnload()の例)
Internet Mobility ProtocolUnload()機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【0142】
(インターネット・モビリティ・プロトコル・ハンドルの例)
少なくともいくつかの例においては、メモリ(インターネット・モビリティ・プロトコル状態情報を記憶)のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。元々のピアが、(電源が切られていたり、サスペンドしていたり、圏外にあったりなどで)セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。TCPの場合はこれが起こり、ピアのIPアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドル(manufactured handle)を採用している。該ハンドルは2列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【0143】
テーブル1:接続オブジェクトの配列を指すポインタの配列
テーブル2:インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル1は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム104の側では、少量のメモリの割り当てが可能になる(モビリティ管理サーバ102側でテーブル1が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる)。
【0144】
テーブル1は必要時に設定(populate)される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル1内でテーブル2への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル2に256個の接続オブジェクトを割り当て、テーブル2へのポインタを、テーブル1の適切なスロットに記録する。次に、プロトコル・エンジンはテーブル2を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル1中をサーチして、テーブル2への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
【0145】
・テーブル2から全ての接続オブジェクトが無くなった場合、新たにテーブル2が割り当てられ、初期化されて、該テーブル2を示すポインタが、テーブル1の次に利用可能なスロットに設定される。
【0146】
・全ての接続オブジェクトが特定のテーブル2のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル2の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル1の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる(テーブル2の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る)。
【0147】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル2が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル2のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【0148】
(ワークフローの例)
Internet Mobility ProtocolRequestWork()機能によって、作業はローカルクライアントから要求される。該作業が検査(validate)され、グローバル作業キューに加えられると、Internet Mobility ProtocolQueueEligible()機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ(適合マークがつけられ)、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Internet Mobility ProtocolProcessWork()機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【0149】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Internet Mobility ProtocolRequestWork()機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【0150】
SENDタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、SENDタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。SENDオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのSENDオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【0151】
(接続スタートアップの例)
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低3フレームをやり取りすることでなされる。開始側は、そのピアにIMP SYNCフレームを送って接続確立が要求されていることを警告する。受け入れ側は、IMP ESTABLISHフレームを送って接続受け入れを確認するか、あるいはIMP ABORTフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由および状態コードが、IMP ABORTフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム(プロトコル・データ・ユニットおよび制御データがふくまれていることもある)が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【0152】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザおよび制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるようにすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【0153】
(データ転送の例)
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、NALからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてNALが返答するまでは、他のデータグラムを送信しない。
【0154】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【0155】
(黙認(acquiescing)の例)
再伝送時のネットワーク帯域幅およびモビリティ管理サーバ102の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ102が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ102は、対応するモバイル端末システム104から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ102は、モバイル端末システム104が通信できない状態(圏外、サスペンドなど)であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
【0156】
・モビリティ管理サーバ102がモバイル端末システム104からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、または
・システム管理者によって接続が中止される
モビリティ管理サーバ102が、モバイル端末システム104からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム104には以前の接続の終了が通知され、モバイル端末システム104に送られることを待機していた作業は破棄される。
【0157】
(接続および送信要求の例)
図10A〜10Cは、インターネット・モビリティ・エンジン244によって生成される接続および送信要求ロジックを例示する、フローチャートを形成している。RPCエンジン240からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン244は、該命令が「接続」要求かどうかを判定する(判定ブロック602)。該命令が「接続」要求であれば、エンジン244は、接続リソースの割り当てが可能かどうかを判断する(判定ブロック603)。十分な接続リソースが割り当てられない場合(判定ブロック603で「ノー」である場合)、エンジン244はエラーを宣言して(ブロック603a)応答する。接続リソースの割り当てが可能であれば、エンジン244は状態設定処理を行って、接続要求の処理に備える(ブロック603b)。
【0158】
接続その他の要求に対し、エンジン244は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する(ブロック604)。
【0159】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン244はまず、保留されている作業の有無を判定する(判定ブロック605)。保留されている作業が無ければ(判定ブロック605で「ノー」である場合)、エンジン244は、図10Cのブロック625に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ(ブロック605A)。保留されている作業があれば(判定ブロック605で「イエス」の場合)、エンジン244は現在の状態が確立されているか否かを判定する(ブロック606)。状態が確立されている場合(判定ブロック606で「イエス」の場合)、エンジン244は状態確立への移行のためのステップを飛ばして、図10Bの判定ブロック615に移る(ブロック606a)。状態が確立されていない場合、エンジン244は状態確立のための一連のステップを実行する必要がある(判定ブロック606で「ノー」である場合)。
【0160】
状態確立に移行するために、エンジン244はまず、そのピアのアドレスが既知かどうかを判定する(判定ブロック607)。既知でなければ、エンジン244は作業をさらに待機させ、図10Cのブロック625に移って、ピアのアドレスが来るのを待つ(ブロック607a)。ピアのアドレスが既知の場合(判定ブロック607で「イエス」の場合)、エンジン244は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する(判定ブロック608)。取得されていない場合、エンジン244は作業をさらに待機させ、図10Cのブロック625に移って、セキュリティコンテキストが来るのを待つ必要がある(ブロック607a)。セキュリティコンテキストが既に取得されている場合(判定ブロック608で「イエス」の場合)、エンジン244は「状態保留」状態を宣言して(ブロック608b)、インターネット・モビリティ・プロトコルの同期フレームを送信し(ブロック609)、再伝送タイマーをスタートさせる(ブロック610)。エンジン244は、対応する確立フレームが受信されたかどうかを判定する(ブロック611)。受信されていない場合(判定ブロック611で「ノー」の場合)、エンジン244は、再伝送時間の期限が来たかどうかを判定する(判定ブロック612)。再伝送時間の期限が来ていない場合(判定ブロック612で「ノー」の場合)、エンジン244は待機し、続いてステップ625に移ってもよい(ブロック613)。最終的に、確立フレームが受信されず(ブロック611で判定)、再伝送時間の期限が全て切れた(判定ブロック614)場合、接続は中止されてもよい(ブロック614a)。結局確立フレームが受信された場合(判定ブロック611で「イエス」の場合)、エンジン244は「状態確立」状態を宣言する(ブロック611a)。
【0161】
状態確立がなされると、エンジン244は新規の接続の認証がなされているかどうかを判定する(判定ブロック615)。なされていない場合、エンジン244は待機し、ステップ625へと移ってよい(ブロック616)。接続の認証がなされている場合(判定ブロック615で「イエス」の場合)、エンジン244は認証が成功したかどうかを判定する(判定ブロック617)。成功していない場合(判定ブロック617で「ノー」の場合)接続は中止される(ブロック614a)。成功している場合、エンジン244は、ピア伝送ウィンドウがフルになっているかどうかを判定する(判定ブロック618)。フルになっていれば(判定ブロック618で「イエス」の場合)、エンジン244は確認応答を待ち、ステップ625に進む(判定ブロック619)。ウィンドウがフルになっていなければ(判定ブロック618で「ノー」の場合)、エンジン244はインターネット・モビリティ・プロトコル・データフレームを生成し(ブロック620)、送信する(ブロック621)。次に、エンジン244は再伝送タイマーがスタートしているかどうかを判定する(判定ブロック622)。していない場合、エンジン244は再伝送タイマーをスタートさせる(ブロック623)。エンジン244は、それ以上送信するデータが無くなるまで(判定ブロック624で判断される)、ブロック618〜623を繰り返す。そして、エンジン244はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る(ブロック625)。
【0162】
(中止の例)
図11は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示したフローチャートである。「接続中止」要求を受けて(ブロック626)、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する(ブロック626a)。中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる(ブロック627)。エンジン244は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する(判定ブロック628)。緊急のものの場合(判定ブロック628で「中止」の場合)、エンジン244は直ちに接続を中止する(ブロック629)。余裕があるものであれば(判定ブロック628で「余裕」の場合)、エンジン244は「状態クローズ(state close)」状態を宣言し(ブロック628a)、インターネット・モビリティ・プロトコルの「モーティス(Mortis)」フレームを送信し(ブロック630)、ピアに接続がクローズされることを示唆する。次に、エンジン244は「モーティス」状態を宣言し(ブロック630a)、再伝送タイマーをスタートさせる(ブロック631)。エンジン244は、ピアから「ポスト・モーテム(post mortem)」フレームが応答されたかどうかを判定する(判定ブロック632)。応答されていなければ(判定ブロック632で「ノー」の場合)、エンジン244は、再伝送タイマーが時間切れになっているか否かを判定する(判定ブロック633)。まだ時間切れになっていない場合(判定ブロック633で「ノー」の場合)、エンジン244は待機し、ステップ637へ進む(ブロック634)。再伝送タイマーが時間切れになっている場合(判定ブロック633で「イエス」の場合)、エンジン244は総再伝送時間の期限が切れているかどうかを判定する(判定ブロック635)。まだ切れていない場合(判定ブロック635で「ノー」の場合)、ブロック630に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合(判定ブロック635で「イエス」の場合)、エンジン244は直ちに接続を中止する(ブロック635a)。
【0163】
「ポスト・モーテム」応答フレームがピアから受信されると(判定ブロック632で「イエス」)、エンジン244は「ポスト・モーテム」状態を宣言して(ブロック632a)、接続リソースを開放し(ブロック636)、スリープ状態に戻ってさらに作業を待つ(ブロック637)。
【0164】
(再伝送の例)
図12は、インターネット・モビリティ・プロトコル・エンジン244が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える(ブロック650)と、エンジン244は、保留中のフレームがあるかどうかを判定する(判定ブロック651)。保留中のフレームがなければ(判定ブロック651で「ノー」の場合)、エンジン244はタイマーを破棄して(ブロック652)スリープ状態に戻る(ブロック660)。逆に保留中のフレームがあれば(判定ブロック651で「イエス」の場合)、エンジン244は、再伝送期間全体(entire)が終了したかどうかを判定する(判定ブロック653)。まだ終了していなければ(判定ブロック653で「ノー」の場合)、処理は時間差のためにスリープ状態に戻る(ブロック654)。既に終了していれば(判定ブロック653で「イエス」の場合)、エンジン244は、総ての(total)再伝送期間が終了したかどうかを判定する(判定ブロック655)。既に終了しており(判定ブロック655で「イエス」)、このイベントがモビリティ管理サーバのエンジン244’(モバイル端末システムのエンジン244に対応)で実行されている場合、休眠状態が宣言される(判定ブロック656、ブロック656a)。同じ状態で、モバイル端末システム104において実行されるインターネット・モビリティ・プロトコル・エンジン244は、接続を中止する(ブロック656b)。
【0165】
総ての再伝送期間がまだ終了していない場合(判定ブロック655で「ノー」の場合)、エンジン244はフレームを再処理して時間切れのデータを除去し(ブロック657)、それを再転送し(ブロック658)、再転送タイマーをそのまま再始動させる(ブロック659)。そして処理は休眠状態に入り(ブロック660)、次のイベントを待つ。
【0166】
(インターネット・モビリティ・プロトコルのPDUの期限切れの例)
図12のブロック657において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット(つまりSEND作業要求)506の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン244は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。上層からのPDU(プロトコル・データ・ユニット)それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン244によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト(validity timeout)および/または再試行カウントを、特定することができる。有効期限タイムアウトおよび/または再試行カウント(アプリケーションによってはユーザによって特定可能)は、エンジン244による再伝送の前に、どのPDU506が、転送されずにフレームから除去されるべきかを決定するために使われる。
【0167】
PDU506に関わる有効期限タイムアウトは、PDUそれぞれが伝送に際して考慮すべき、相対期間(relative time period)を特定する。実行依頼の間、Internet Mobility ProtocolRequestWork機能によって有効期限の値(expiry timeout value)がチェックされる。該値が0で無い場合、時期タイマー(age timer)は初期化される。次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるPDU506が、有効期限パラメータ(validity period parameter)が特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該(全ての)PDUは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗(timeout failure)」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなる(grow stale)こと、および/または際限なくシステムリソースを消費することを防ぐ。
【0168】
図12Aの例において、少なくとも3つの独立したPDU506が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン244でキューに加わっている。PDU506(1)は有効期限を持たず、要求に対するタイムアウトが無い。PDU506(2)は、2秒の有効期間を持ち、時系列的にPDU506(1)の後に並んでいる。PDU506(n)は、2.5秒の有効期間を持ち、時系列的にPDU506(2)の後に並んでいる。PDU506(n)の待機が、キューの処理をさせ、PDU506(2)の有効期間を経過させる最初のイベントであるため、PDU506(2)は作業キューから外され、ローカルに完了されて、PDU506(n)がリストに加えられる。有効期間がPDU506(n)に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント(キューに加える、キューから外す等)によっても、古くなったPDUが除去され、完了される。
【0169】
上記のように、PDU506はインターネット・モビリティ・プロトコル・エンジン244の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン244は、最終的にこれらのPDU506をピアに送り、関係するフレームをフレーム保留リスト(Frames−Outstanding list)に加える。ピアが一定期間内に該フレームを認識しなかった場合(図12の再伝送アルゴリズムを参照)、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するPDUリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが0ではなく、0に向かって減少してゆく場合、PDU506はリストから外され、フレームヘッダはデータの消去を示すように修正される。このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン244’の再伝送アルゴリズムによって負担をかけられることがない。
【0170】
図12Bの例においても、少なくとも3つの独立したPDU506が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン244でキューに加わっている。PDU506(1)は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。PDU502(2)は再試行カウントが1でキューに加わり、時系列的にPDU506(1)の後に並ぶ。PDU506(n)は、ある程度の時間が経過してからPDU502(2)より後ろに加わる。この時点で、いくつかの外部イベント(例えば上層融合・タイマー)が、エンジン244’に、インターネット・モビリティ・プロトコル・データフレーム500を生成するための作業キューから十分なPDU506を集めて新しいフレームを生成するための論理を送信させる。フレームヘッダ503が求められ、これに、フレームの最初の伝送であることを示すための、再試行IDとして0が付けられる。続いてフレームは、ネットワークへの後の伝送用に、NAL層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン244の再伝送ロジックにより、当該するフレーム500が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをNAL層に再送する前に、エンジン244’の再伝送ロジックは、関連しているPDU506のリストを反復する。PDU506(2)それぞれの再試行カウントが調べられ、0でなければ、該カウントは減少させられる。PDU506(2)の再試行カウントを減少させる処理により、該カウントは0になる。PDU506(2)の再試行カウントが0になったことにより、PDU506(2)はリストから外され、「再試行失敗(retry failure)」のステータスをもってローカルに完了する。続いて、PDU506(2)のデータが無いことを示すため、フレームヘッダ503のサイズが調整される。この処理は、残っている全てのPDUについて繰り返される。フレーム500全体が、「編集後」フレーム500’の作成のために再処理されると、ヘッダの再試行IDが増加させられて、生成されたデータグラムが、続く(再)伝送に向けてNAL層に送られる。
【0171】
(受信の例)
図13A〜13Dは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク108から送られた際に生成される。この受信イベントを受けて、エンジン244は該イベントを事前検査(pre−validate)し(ブロック670)、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する(判定ブロック671)。エンジンが可能性無しと判断した場合(判定ブロック671で「ノー」の場合)、該フレームは破棄される(ブロック672)。可能性ありという判断の場合(判定ブロック671で「イエス」の場合)、エンジン244は、受信したフレームと関連する接続があるかどうかを判定する(判定フレーム673)。受信したフレームと関連する接続がある場合(判定ブロック673で「イエス」の場合)、エンジン244は作業を接続受信キューに加え(ブロック674)、該接続に受信に適格であるとマークを付け(ブロック675)、該接続をグローバル作業キューに加える(ブロック676)。まだどの接続も受信したフレームと関連していない場合(判定ブロック673で「ノー」の場合)、エンジン244は、受信したフレームをソケット受信キューに加え(ブロック677)、該ソケット受信キューをグローバル作業キューに加える(ブロック678)。どちらの場合でも、エンジン244はグローバル作業イベントを送る(ブロック679)。「受信適格」イベントをグローバル作業キューからディスパッチする際(図13B参照)、エンジン244はフレームをそれぞれの受信キューから外す(ブロック680)。インターネット・モビリティ・プロトコル・エンジン244がメッセージをキューから外し始められるようになる前に、複数のIMPフレームを受信し、キューに加えることが可能である。エンジン244は、全てのフレームがキューから外れるまで作業を繰り返す(ブロック681、682)。あるフレームがキューから外れると(判定ブロック681で「イエス」)、エンジン244は受信したフレームを検査し(ブロック683)、該フレームが有効かどうかを判定する(判定ブロック684)。該受信したフレームが無効である場合、エンジン244は該フレームを破棄し(ブロック685)、受信キューから次のフレームを外す(ブロック680)。上記フレームが有効である場合(判定ブロック684で「イエス」の場合)、エンジン244は、該フレームが既存の接続と関連しているか否かを判定する(ブロック686)。していなければ(判定ブロック686で「ノー」の場合)、エンジン244は同期フレームがあるかどうかを判定する(判定ブロック687)。同期フレームがなければ(判定ブロック687で「ノー」の場合)、該フレームは破棄される(ブロック685)。反対に、同期フレームが受信されていれば(判定ブロック687で「イエス」の場合)、エンジン244は、図14Aおよび14Bを参照して説明される受動接続要求により、該フレームを処理する(ブロック688)。
【0172】
上記フレームが接続と関係していれば(判定ブロック686で「イエス」の場合)、エンジン244は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する(判定ブロック689)。接続が既に「ポスト・モーテム」である場合、フレームは破棄される(ブロック685)。そうでない場合、エンジン244はフレームを解析し(ブロック690)、該フレームが中止フレームであるかどうかを判定する(判定ブロック691)。該フレームが中止フレームであれば、エンジン244は直ちに接続を中止する(ブロック691a)。該フレームが中止フレームでなければ(判定ブロック691で「イエス」の場合)、エンジン244は確認応答情報を処理し、全ての保留中の送信フレームを開放する(ブロック692)。次に、エンジン244は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る(ブロック693)。フレームがセキュリティ用のサブシステムから戻ると、エンジン244は全ての制御データを処理する(ブロック694)。続いて、エンジン244はフレームがアプリケーションデータを含んでいるかどうかを判定する(判定ブロック695)。含んでいる場合、該データはアプリケーション層においてキューに加えられる(ブロック696)。エンジン244はまた、接続が休止状態であるかどうかを判定し(ブロック697および697a:これは、好ましい実施形態におけるモビリティ管理サーバのエンジン244’にもあてはまる)、確立状態に戻す。
【0173】
フレームが「モーティス」フレームである可能性があれば(判定ブロック698で「イエス」の場合)、エンジン244は、アプリケーション層に「切断」を示唆し(ブロック699)、「モーティス」状態に入る(ブロック699a)。エンジン244は「ポスト・モーテム」フレームをピアに送り(ブロック700)、「ポスト・モーテム」状態に入る(ブロック700a)。続いて、エンジン244は接続リソースを解放し(ブロック701)、スリープ状態に戻って作業を待つ(ブロック702)。解析されたフレームが「ポスト・モーテム」フレームだった場合(判定ブロック703で「イエス」の場合)、ブロック700a、701、702が実行される。これ以外の場合、制御はブロック680に戻って、次のフレームを受信キューから外す(ブロック704)。
【0174】
(受動接続の例)
図14A〜14Bは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。まず、エンジン244は、当該装置に他の接続が存在するかどうかを判定する(ブロック720)。存在すれば(判定ブロック720で「イエス」の場合)、該エンジンは、それが最初の接続であるか否かを判定する(判定ブロック721)。ピアが、新規の接続が最初の接続であると認識している場合(判定ブロック721で「イエス」の場合)、エンジン244はそれ以前の接続を中止する(ブロック722)。最初の接続ではない場合(判定ブロック721で「ノー」の場合)、エンジン244は、シーケンスと接続IDとが対応しているかどうかを判定する(判定ブロック723)。対応していなければ(判定ブロック723で「ノー」の場合)、制御は判定ブロック720へ戻る。シーケンスと接続IDが対応していれば(判定ブロック723で「イエス」の場合)、エンジン244は複製フレームを破棄し(ブロック724)、図13Bのステップ680に戻る(ブロック725)。
【0175】
他の接続が無ければ(判定ブロック720で「ノー」の場合)、エンジン244は、接続に接続リソースを割り当て可能か否かを判定する(判定ブロック726)。割り当て可能でない場合、エラーが宣言され(判定ブロック726で「ノー」の場合、ブロック727)、接続が中止される(ブロック728)。接続リソースを割り当て可能な場合(判定ブロック726で「イエス」の場合)、エンジン244は「設定」状態を宣言し(ブロック726a)、接続についてのセキュリティコンテキストを取得する(ブロック730)。十分なセキュリティコンテキストの取得ができなかった場合(判定ブロック731で「ノー」の場合)、接続は中止される(ブロック728)。取得できた場合、エンジン244は確立フレームを送り(ブロック732)、接続が「確立」状態になったことを宣言する(ブロック732a)。続いて、エンジン244は再送部(retransmitter)を始動させ(ブロック733)、完了に向けて認証処理を待つ(ブロック734)。最後に、エンジン244は装置とユーザとが両方認証済みか否かを判定する(ブロック735)。装置とユーザのどちらかが認証されていない場合、接続は中止される(ブロック736)。それ以外の場合、エンジン244は監視中の(listening)アプリケーションへの接続を示唆し(ブロック737)、設定を取得する(ブロック738)。この2ステップのどちらかが成功しなかった場合、接続は中止される(判定ブロック739、ブロック740)。成功した場合、処理はスリープ状態に戻って作業を待つ(ブロック741)。
【0176】
(異常終了の例)
図15Aおよび15Bは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理(ブロック999)から受信すると(ブロック1000)、エンジン244は、接続が該要求と関係しているかどうかを判断する(判定ブロック1001)。関係していれば(判定ブロック1001で「イエス」の場合)、エンジン244は元の状態をセーブして(ブロック1002)、「中止」状態を宣言する(ブロック1002a)。次に、エンジン244は、接続がRPCエンジンに示唆されていたか否かを判定する(判定ブロック1003)。されていれば、エンジン244は切断イベントを示唆し(ブロック1004)、「ポスト・モーテム」状態を宣言して(ブロック1003a)、該接続に割り当てられていたリソースを解放し(ブロック1005)、元の状態が保留中の状態より大きいか否かを判定する(判定ブロック1006)。元の状態が保留中の状態より大きくなければ、(判定ブロック1006で「ノー」の場合)、処理は、呼び出しルーチンに戻るべく、ブロック1012に移る(ブロック1007)。元の状態が保留中の状態より大きい場合には、エンジン244は、上記要求が受信フレームと関係しているかどうかを判定する(判定ブロック1008)。中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合(判定ブロック1009)、受信フレームは呼び出しルーチンに戻る(ブロック1012)前に破棄される(ブロック1011)。
【0177】
(ローミング制御の例)
再度図1を参照すると、モバイルネットワーク108は、それぞれ別のネットワーク相互接続(107a〜107k、無線トランシーバ106a〜106kにそれぞれ対応)を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ102を含むネットワーク108は、モバイル端末システム104があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って(gracefully)扱うことができる。一般に、ネットワーク108のトポロジは、管理等の理由により、いくつかのセグメント(サブネット)に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク(伝送)アドレスが複数のモバイル端末システム104それぞれに割り当てられている。
【0178】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル(DHCP)を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のDHCPサーバは、一般的に、そのクライアントに(他のものの提供に加えて)有効なネットワークアドレスを「リース」する。DHCPクライアントは、永続的に割り当てられた、「固定符号化された(hard−coded)」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、DHCPクライアントはDHCPサーバにネットワークアドレスを要求する。DHCPサーバは、割り当てに使用可能なネットワークアドレスをプールしている。DHCPクライアントがネットワークアドレスを要求すると、DHCPサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間(リース期間)だけ、クライアントに所有される。リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、DHCPはネットマスク等の設定情報を、DHCPクライアントソフトウェアを動作させているクライアントに提供する。標準的なDHCPプロトコルについての詳しい情報は、RFC2131に記載されている。
【0179】
よって、DHCPを使用するモバイル端末システム104が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム104とモビリティ管理サーバ102とがDHCPの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム104の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【0180】
ある実施例では、モバイル端末システム104が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答(echo request−response)として、標準的なクライアント/サーバ型同報通信用のDHCP Discover/Offerメッセージのシーケンスが使用される。標準的なDHCPプロトコルに従って、ネットワークアドレスを要求するモバイル端末システム104が、DHCP Discoverメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、DHCPサーバはOffer応答を同報通信する(要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる)。よって、当該サブネット上の全てのモバイル端末システム104は、DHCP Offerサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【0181】
本実施例では、DHCP同報通信メッセージをモニターするDHCPリスナが設けられており、モバイル端末システム104が、あるサブネットから別のサブネットへローミングしているか、およびDHCPによって新規のネットワークアドレスが取得できるようになっているかが確認される。図16は、DHCPリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造902は、以下の要素を有していてもよい。
【0182】
・サーバデータ構造の連結リスト、
・整数トランザクションID番号(xid)、
・カウンタ(「ping」)、および
・タイムアウト値
サーバデータ構造904は、それぞれ別のDHCPサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
【0183】
・次のサーバへのポインタ、
・サーバID(DHCPサーバのネットワークアドレス)、
・最近該DHCPサーバと結合したBOOTPリレーエージェントのアドレス(giaddr)、
・「ping」値(socket−>ping)、および
・フラグ
これらのデータ構造は、ネットワーク108上のDHCP同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
【0184】
・roamCreate() (変数を初期化)
・roamDeinitialize() (全てのリスナを消去)
・roamSrartIndications() (モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆(registrant roaming indications)のために、供給されたコールバックルーチンを呼び出す)
・roamStopIndications() (適当なコールバックをリストから除去して登録ローミング示唆を停止)
・インターフェイス変更(インターフェイスがネットワークアドレスを変更したことを示す、OSからのコールバック通知)
・リスナ信号(ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック)
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【0185】
本好ましい実施形態では、全てのモバイル端末システム104が、DHCP Discover要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのDiscover要求と、他のネットワーク装置からのDiscover要求とを、区別することができるようになる。DHCPサーバも同様に応答を同報通信するので、どのモバイル端末システム104および/またはモビリティ管理サーバ102も、DHCPサーバからどのモバイル端末システムに出されたOffer応答でも受け取ることができる。複数のDHCPサーバが単一のDHCP Discover要求に応答できるため、図16のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【0186】
所定のクライアントハードウェアアドレスおよびクライアント識別子を有するDiscover要求の受信に際し、本好ましい実施形態では、該要求がモバイル端末システム104から送られてきたものとして認識される。該メッセージが0に設定されたBOOTPリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。リスナは、最近モバイル端末システム104から送られたDiscoverメッセージのトランザクションID(xid)と対応したトランザクションID(xid)が含まれていない限り、DHCP Offer応答を無視してもよい。該リスナは、新規のBOOTPリレーエージェントIDおよび/または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム104がローミングしたと判定する。リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図16のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される(これについては設定によって変更可能である)。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される(この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる)。
【0187】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本好ましい実施形態では、新規のBOOTPリレーエージェントID(または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス)を持つ、既知のサーバから応答があれば、モバイル端末システム104がローミングしたと判定する。リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム104は圏外にある可能性があるので、モビリティ管理サーバ102は該システムが圏内に戻るのを待つ。
【0188】
図17は、本好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、DHCPリスナ処理は、適切なメモリをハンドルに割り当て、NALソケットをDHCPクライアントおよびサーバUDPポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され(ブロック802)、上記処理は「待機」状態に入ってローミング関連のイベントを待つ(ブロック804)。イベントは、以下の3種の外部入力によって引き起こされる。
【0189】
・DHCPサーバパケットを受信する
・他のモバイル端末システムからのDHCPクライアントパケットを受信する ・タイマーの期限が切れる
DHCPサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントIDと一致するか否かを判定するために調べられる(判定ブロック806)。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントIDを含んでいる場合、該パケットがDHCP Offerパケットであるか否かが判定される(判定ブロック808)。該Offerパケットは、最近送られたDHCP Discoverシーケンスに対応したトランザクションIDを含んでいない限り、拒絶される。
【0190】
パケットトランザクションIDが対応していれば(ブロック810)、DHCP Offerパケットを送信したサーバが既知であるか否か(つまり、サーバIDが図16のリスナのデータ構造に含まれているか否か)が判定される(ブロック812)。サーバIDがリストに無い場合(判定ブロック812で「ノー」の場合)、サーバIDがリストに加えられ、「新規」とマークされる(あるいは、リストの最初のサーバであれば、「最初」とマークされる)(ブロック822)。サーバが既にリストにある場合(判定ブロック812で「イエス」の場合)、さらに、パケットBOOTPリレーアドレス(「GIADDR」)がサーバアドレス(「GIADDR」)に対応しているか否かが判定される(判定ブロック814)。対応していなければ、Offerパケットは他のサブネットからのものということになるので、「ハードローミング(hard roam)」が実行されたと判定される(ブロック816)。呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック814でBOOTPリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のping番号をサーバに記憶するというリスナ処理が行われる(ブロック818、820)。続いて、処理は「待機」期間に戻る。
【0191】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントIDを有しているか、DHCP Discoverパケットか、および0のパケットBOOTPリレーアドレス(GIADDR)を有しているかどうかが判定される(ブロック824、826、828)。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたDHCP Discoverメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションIDが、後に受信されるDHCP Offerパケットの比較に用いられる、ピアのトランザクションIDに設定され(ブロック830)、「ping確認」が呼び出され(ブロック834)、タイマーがリセットされる(ブロック836)。
【0192】
タイマーの期限切れにより、処理は「ping確認」を呼び出す(ブロック838)。本好ましい実施形態における「ping」は、ランダムな新規のxidを有するDHCP Discoverパケットである。このping確認838のステップが、図17Aに例示されている。ping確認ルーチンの目的は、「ソフトローミング(soft roam)」状態(つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態)が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
【0193】
・モバイル端末システムが、あるサブネットから別のものにローミングしたか?
・モバイル端末システムは圏外にあるか?
・DHCPサーバは不在か?
これらの状態は、モバイル端末システムの、前「ping」応答と現「ping」応答とを比較することによって判定される(判定ブロック846、850)。例えば、現ping数から旧サーバの前ping応答を引いた数が、サブネットのサーバのpingよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される(あるいはいずれも示唆されない)。
【0194】
図18は、モバイル端末システム104のローミング制御センター(roaming control center)が実行するステップを例示したフローチャートである。モバイル端末システム104でのローミングを可能にするため、既知のアドレスのリストが0に初期化され(ブロック850)、OSインターフェイス変更通知がイネーブルになり(ブロック852)、次に、OSを呼び出して、DHCPを利用する現在のアドレスのリストを所得する(ブロック854)。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ(ブロック856)、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される(ブロック858)。次に、登録主体に「ローミング」を示唆する(ブロック860)。
【0195】
図17のリスナ処理から信号が送られると(ブロック862)、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される(判定ブロック864、870、874)。ローミング信号(判定ブロック864で「イエス」)により、対応するリスナ866が閉じられ、OSがコールされて、ネットワークアドレスのDHCPリースが解放、更新される(ブロック868)。リスナ信号が「圏外」の場合(判定ブロック870)、該状態が登録主体に示唆される(ブロック872)。該信号が「圏内復帰」の場合(判定ブロック874)、該状態は全ての登録主体に示唆される(ブロック876)。無効のローミング命令を受信すると(ブロック878)、全てのリスナが閉じられ(ブロック880)、OSインターフェイス変更通知が無効になる(ブロック882)。
【0196】
(インターフェイスによって補助されたローミングのリスナの例)
さらに、インターフェイスベースのリスナによって、同じネットワークおよび別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の(複数の)インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【0197】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの(例えば低レベルのインターフェイス・ローミング・ドライバを経由した)情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。図19Aと19Bは、モバイルノードの移動パス(migration path)を効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、(例えば、冗長パスを使った自己回復インフラ構築のために)様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【0198】
図19Aを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に(図19A、ブロック2000)、低レベルのインターフェイス・ローミング・ドライバは、図18のローミング制御センターモジュールに登録を実行する(ブロック2010)。このような登録(例示の実施形態では、crRegisterCardHandler()機能を通じて実現される)により、下記のエントリポイントが与えられる。
【0199】
・開
・閉
・状態(status)取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース(等)のポーリングを使わなければならない場合は、ブール演算を偽とする
実施例のcrRegisterCardHandler()機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆/問合せ(signaling/querying)媒体接続性およびネットワーク接続ポイントの変更に関するOS包括メカニズム(O/S generic mechanism)を使用するインターフェイスに、インストールされてもよい。
【0200】
本実施例では、インターフェイスの状態がイネーブルになると(つまりネットワークへのアクセスが可能になると)(ブロック2020)、ローミング制御センターは、インターフェイス補助ローミング(interface assisted roaming; IAR)を、以下のステップに基づいて試みる(ただし、以下のステップは、OSの設計および/または特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある)。
【0201】
1.包括ハンドラ(generic handler)がインストールされている場合、包括crOpenInstance()ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態およびネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する(ブロック2030)。インターフェイスドライバが該機能を包括的にサポートできない場合(判定ブロック2030で「ノー」の場合)、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【0202】
2.包括ハンドラがエラー(判定ブロック2030で「ノー」)を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される(ブロック2040)。該インターフェイスが、crRegisterCardHandler()フェイズ中に登録されたトークンのうちの一つと一致する場合(ブロック2050)、ローミング制御センターは、アダプタのインスタンスへの特定のcrOpenInstance()をコールする。この機能は、低レベルドライバを開き、状態(媒体接続性、ネットワーク接続ポイントID)を再度ポーリングし、定期ポーリングタイマーを(可能ならば)設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【0203】
3.ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、IAR機能を使用せずに、図17および17Aのビーコンリスナ(beaconing listener)、モバイルIP、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される(判定ブロック2050で「ノー」の場合、ブロック2060)。これ以外の場合、インターフェイス補助ローミングがイネーブルになり(ブロック2060)、ローミング制御センターは下記のアルゴリズムに従う。
【0204】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する(ブロック2060)。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ(ブロック2100)。該イベントは、例えば以下のものを有している。
【0205】
・低レベルローミングドライバからのコールバック、
・ポーリング間隔(timed poll interval)(ブロック2070、2090)、あるいは
・ネットワーク・レベルの活動(つまり、伝送/受信にかかわる問題)からの示唆
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと(図19Bの判定ブロック2110もしくは2120で「イエス」の場合)、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【0206】
1.状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し(ブロック2120で「イエス」)、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ROAM_SIGNAL_OUT_OF_CONTACT状態を示唆する(ブロック2140)。
【0207】
2.上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し(ブロック2120で「ノー」の後、ブロック2150で「ノー」の場合)、ROAM_SIGNAL_OUT_OF_CONTACTが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。この場合、ローミング制御センターは、適切なアクセスのために登録または取得された全てのネットワークアドレスを再確認し(ブロック2170)、ROAM_SIGNAL_ROAM_SAME_SUBNETを出して(ブロック2180)、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【0208】
3.上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合(ブロック2150で「イエス」の場合)、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。該データストアは、通常動的にポピュレートされている(学習している)が、パフォーマンス向上のため、該データストアに静的な情報(既に学習された情報)が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【0209】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【0210】
a)データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される(ブロック2190)。対応が見つかれば(ブロック2200で「イエス」)、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ROAM_SIGNAL_ROAM_SAME_SUBNETを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【0211】
b)検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する(ブロック2220)。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを(再)取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、(例えばDHCPを通じて)ネットワークでアドレスを取得することは、(モバイルIPの外部エージェントを通じて)ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを(再)取得(例えばDHCPサーバからのリースを確立/アップデートして)するか、あるいは現アドレスを外部エージェント(モバイルIP)に登録する。
【0212】
・別のサブネットへのローミングを示唆する、ROAM_SIGNAL_ローミング信号を、該ローミング制御センターのクライアント向けに生成する(ブロック2230)。
【0213】
c)検索の結果対応が見つからなければ(ブロック2200で「ノー」)、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する(ブロック2210)。次に、ローミング制御センターはブロック2220および2230を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【0214】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、(ユーザおよび/またはシステムによって定義された)付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス(ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択)を選ぶことができる。これは、帯域幅、(1バイトあたりの)コスト、および/またはサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。例えば、他の利用可能なヒューリスティクス(媒体接続性、信号強度、再伝送率等)による、「メークビフォアブレーク(make before brake)」ハンドオフ構造が提供可能で、よってローミングノードからの/に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【0215】
図20は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図20のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「NPOA」は、例えば、アクセスポイントのMACアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「NPOA」は、介入的なネットワーク相互接続(ゲートウェイ、IWF等)の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報(例えばMTUのサイズ、待ち時間、コスト、利用可能かどうかなど)とが結合していてもよい。
【0216】
(特定の競合状態を扱う他の実施例)
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と(再)接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、従って、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に1度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークIDがいつ有効になるかを判定するのは困難である。
【0217】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。従って、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求/応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやpingフレームは1つのピア(ローミング中のノードである可能性が高い)によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでNPOA情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【0218】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるROAM_SIGNAL_ROUTE_CHANGEが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【0219】
(非接続ネットワークを通じたローミング例)
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」(disjoint networking)モードでMMS(モビリティ管理サーバ)にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、MMSとの通信を確立する/持続するのに使われる、代替のネットワークアドレスを動的/静的に見つけ出すことができるようになる。
【0220】
一般に、アルゴリズムによって、通信中にMES(モバイル端末システム)に送るための、MMSが利用可能な代替アドレスのリストが可能となる。このように、MMSはMESに、一つ以上のMMSネットワークアドレスもしくは他のネットワークに対応した他のMMSのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【0221】
MESが別のネットワークへと移動するとき、MESは新規のネットワークの接続ポイントからMMSとコンタクトをとるために、MMSの「エイリアス」(alias)アドレス/アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、MESは新規のネットワーク接続を通じてMMSとのコンタクトを再確立することができる。
【0222】
この新しい技術を簡略化したフローチャートを図21に示す。MMS102は、2つの異なる非接続ネットワーク、すなわちネットワーク・セグメントN1及びN2と接続しているものとする。MES104は、最初にMMS102とネットワークN1を介して接続されるものとする。ネットワークN1を介してMES104とMMS102との間で接続が確立されるとすぐに、MMS102は、MES104に対して、MMSが一以上の他のネットワーク(例えば、ネットワークN2)から求められるネットワークアドレスのリストL又は他の識別子を送ることができる。MES104は、該リストLを受け取り、記憶する。その後、MES104は別のネットワーク(N2)に移動する時、MES104はこの記憶されたリストLにアクセスし、それを用いて新規のネットワーク(N2)を通じたMMS102との通信を効果的に再確立することが可能となる。
【0223】
この新しいアルゴリズムには、非接続ネットワークを通じて、MMS102と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。例えば、図21に示すアルゴリズムを用いて、多くのネットワーク(いくつか、又は全てが無線ネットワーク)からの安全なファイアウォール/ゲートウェイ、及びコーポレートバックボーンとしてMMS102が使用される安全なネットワークをセットアップでき、モバイルノード104が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。例えば、MMS102がハブとして1つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、MMS102(この例ではルータとして動作可能)を介した場合を除いて、1つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【0224】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、MMS102との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報/経路(つまり、デフォルトルート等)をルーティングが必要となる。
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。MES104からフレームが送られる時、クライアント及び及び中間ノード(ルータ)におけるIPネットワーク(層3)のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地(MMS102)にパケットを正確に送る。このことは、一般にIP送信(IP forwarding)、あるいはIPルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム(ブロードキャスト等)が別のネットワーク・セグメントへ流れる。IP送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【0225】
図21に示す代替アドレスリストは、ルーティング情報のうちの幾つかをMES104に送出する、又は配布する効果を有する。従って、各セグメントは、MMS102とつながっている他のセグメントの情報はない状態で離散された状態となる。MES104はMMS102によって認証可能であるため、MMSは認証されたMESユニット104にのみリストLを送る。MES104が別のネットワーク・セグメントへ移動する時、MES104は自動的に正しいアドレスを選択し、それを用いて途中MMSとの通信を開始/継続することができる。従って、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【0226】
例えば、このようにユーザレベルのセキュリティ/暗号化と組み合わせてMMS102を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【0227】
例を図22に示す。図22において、MMS102は通信網やルート情報を共有しない4つの別々に分かれたネットワーク(Ia、Ib、Ic、Id)と接続されている。どの点から見ても各ネットワークIは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ(例えば、Ic)とドッキングしているMES104を想定する。例えば、MES104は192.168.x.xネットワーク上のアドレスを取得してMMS102と通信するものとする。
【0228】
ある理由によりMESが10.1.x.x(Ia)ネットワークに渡る、又は移動する必要があるものとする。10.1.x.x(Ia)ネットワークは192.168.x.x(Ib)ネットワークのことを知らない(つまり、(Ib)ネットワークへのルートがない)ため、MES104がその領域へ移動する時に、たとえMMSが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード104が図示される他の10.xネットワークのいずれかと接続する場合においても同じことが起こる。
【0229】
図21に示すアルゴリズムを用いて、接続開始時間の(あるいは他の方法で)MMS102は各種非接続ネットワークIa、Ib、Ic、Idに関するそのインターフェイスアドレスをMES104と共有し、MESはこれらを記録する。一旦記録されると、MES104は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、MESは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでMMSと通信できる。2以上のアドレスが使用される場合、MES104は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図21と同様のリストを受け取らなかったMES104は、その「ホーム」ネットワーク以外のネットワークを通じてMMSと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【0230】
他に、図21の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ(Network Address Translators;NATs)として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス/ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス/ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはNATにおいても静的に定義される。
【0231】
誰かがLAN/WLANの内部でMMS102を使用するために、それをNATに置くことを想定する。現在、MMS102がNATでない限り、あるいは異なるプロキシを用いてMMSと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、MMSと通信するアドレスがもはやアクセス可能ではないため、MMSとはアクセス可能ではない。図21のアルゴリズムを用いれば、MMSと直接接続されていない別のインターフェイスアドレスを静的/動的に明確にすることができる。従って、上記のアルゴリズムを使用すれば、MES104は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【0232】
この概要を図23に示す。ノードがインターフェイス“d”からインターフェイス“g”へ渡るとする。MMS102にローカルインターフェイスを供給するだけではアクセスはできない。MES104は分散されたインターフェイスの優先順位を知る必要がある。それからMES104は必要なアドレスを選択してインターフェイス“g”上で使用する。その後、NAT2000は、各パケットに関するネットワークアドレス/ポート情報を、内部インターフェイス“c”アドレスへ適切に変換する。MMS102からMES104に送られるフレームには逆の処理が行われる。
【0233】
(ポリシー管理及びロケーションベースのサービス例)
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のMMSはMESが確立する各アプリケーションのセッションと深く関わっているため、どちらの側(すなわち、MMSおよび/またはMES)もポリシーベースのルールを適用してMESとその最終的なピアとの間の通信を適合して制御することができる。さらに、MMSおよび/またはMESはデバイスのロケール、又は近接性(proximity)、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、MMSおよび/またはMESは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。MMSはさらにMESにこのようなルールの幾つか、全くなし、あるいは一部、および/または処理を配分して、メータリング(metering)、又は傍受者によるモバイルデバイスへの侵入(rogue attacks)に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、MMSが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【0234】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、および/またはネットワークの接続ポイントに基づき構成可能である。一旦定義されると(学習されると)、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、および/またはサービスを管理し、制御する。
【0235】
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
【0236】
・モバイルデバイスについての近接性、場所、高度、および/または他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作(例えば、帯域幅条件)
・現在のネットワーク状態
・他の静的又は動的要素
さらに分散型アーキテクチャを利用することで、MMSは同じ決定セットを適用又は共有することができる。ポリシー管理処理および/または意思決定をMMSに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【0237】
サンプルMESの制御に使用される可能性のあるメトリクス(ルール)の幾つかを示すテーブルの例を図24に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ(例えば、ウィザード)や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、または割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【0238】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図24に示す。
【0239】
・MESの通信機能(送信のみ、受信のみ、送受信)
・MESの要求がプロキシされるか否か
・MESのソースポート
・MESのソースアドレス
・MESの目的地ポート
・MESの目的地アドレス
・MESのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション(例えば、GPS座標又は他のロケーション情報)
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム(例えば、ワイルドカード)であることが可能である。
【0240】
図24のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図24のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で100,000バイト以下に低減される場合、目的地ポート20、21との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール(列)3、4によってネットワークトラフィックのみがMMSへ、又はMMSから流れることが可能となる(プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。)。
【0241】
一例において、各RPC要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにMMSおよび/またはMESによって行われる処理のフローチャート例を図25に示す。
【0242】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、MMSはモバイル端末システムがいつ1箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【0243】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとPRCエンジンの両方の改良点について概要を説明する。新しいRPCのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【0244】
(ロケーション変更RPC(Location Change RPC)の例)
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更RPC要求(Location Change RPC Request)」メッセージをそのピア、この場合モビリティ管理サーバに送る。「ロケーション変更RPC」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはASCIIの48ビットIEEE MAC アドレス、IPV4 アドレス、IPV6 アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。「ロケーション変更RPC要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、PID等の他の関連情報を含む「ロケーション変更警告(Location Change Alert)」を作成する。この警告は「ロケーション変更RPC要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はMMSの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、および/またはポリシー変更が含まれる。
【0245】
ロケーション変更RPCはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【0246】
ある例では、MESは自身が移動したことを知らない場合がある。MESが接続する媒体やネットワーク・アダプタに応じて、MMSはMESが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、MMSはMESのアドレスを新しく管理することを認識する。したがって、動作の検出を完了するためには、行動検出するためのMESとMMSの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいIMPメッセージが受け取られる時に、MMSはIMP層でクライアントの行動を検出する。このことが行われると、MMSは局所的にロケーション変更警告を生成する。また、MMSは接続ポイントが変更したというメッセージをMESに送る。
【0247】
(トポロジRPCの例)
「トポロジRPC要求(Topology RPC Request)」はモビリティ管理サーバからモバイル端末システムへ送られる。このRPCの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジRPC応答(Topology RPC Response)を作成する。トポロジRPC応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド(Total Length Field)、タイプ、長さ情報が後に続く接続ポイント識別子、および、サブネットおよびネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【0248】
(ロケーション情報UIの例)
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が48ビットのIEEE MACアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのMACアドレスが表示される。接続ポイントが「ホールマークカード(HallMark Cards)」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【0249】
(ロケーションRPCタイマーの例)
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更RPCがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更RPCを生成する。
【0250】
(距離変更通知の例)
距離メトリクスは、ロケーション変更RPCの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、nフィート、nキロメータ毎、あるいは他の適当な測定単位で3次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【0251】
(速度閾値通知の例)
速度変更メトリクスは、ロケーション変更RPCの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔(すなわち、10分間で0MPH、又は1分間で70MPH)を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【0252】
[応用例]
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【0253】
(断続的に接続される携帯用コンピュータ)
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット(Ethernet)等のローカルエリア・ネットワーク(Local area network)に接続する。LAN接続によってネットワークサービス(例えば、プリンタ、ネットワークドライブ)やネットワーク・アプリケーション(例えば、データベースアクセス、電子データサービス)にアクセスが可能となる。
【0254】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【0255】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、および/またはインターネットを通じてオフィスLANと再接続する。(ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した)モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【0256】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【0257】
(モバイル在庫管理及び倉庫への応用)
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物(すなわち、トラックやフォークリフト)を使って商品の在庫管理が行われる。
【0258】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム104の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ102の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【0259】
(モバイル医療への応用)
無線LAN技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブ(World Wide Web)を通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム104への連続的な接続が可能なので、病院にいる間(一方向又は双方向の)ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム104を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム104によって医療関係者は無線送信が望ましくないとされるエリア内(例えば、電波の放射によって医療機器に障害が出る可能性のある場所)での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【0260】
(トラック輸送及び貨物輸送)
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム104はLAN技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム104はCDPDやARDIS等のWide Area WANサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム104はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
モバイル企業
企業の社員は、802.11.等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制(pay−per−use)」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【0261】
(IPマルチプリケーション)
ある組織がインターネットに接続する必要のあるLANを有する場合、LANの管理者には二つの選択肢がある。一つ目の選択は、LAN上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ102を使用することである。多数のIPアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ(Internet Service Privider; ISP)を利用してインターネットにアクセスする小規模の企業は、ISPが割り当てるIPアドレスだけを使用することになる。IPアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ISPは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【0262】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ102を用いれば、これらの問題の多くを解決することができる。企業は、ISPを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ102を用いることができる。これにより、モバイル端末システム104は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ102を通じて行われるため、一つのアドレスだけをISPから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数(多くの場合一つ)のアドレスとアカウントをISPから取得すればよくなり、全体のLANでインターネットへの同時接続(十分な帯域幅が備えられていることを前提として)が可能になる。
【0263】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【図1】
本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図2】
モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図2A】
モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図3】
モバイル・インターセプタ・アーキテクチャを例示している。
【図3A】
モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図3B】
RPC作業要求を扱うRPCエンジン(RPC engine)によって実行されるステップを例示したフローチャートである。
【図4】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5A】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5B】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5C】
RPC作業要求を処理するステップを例示したフローチャートである。
【図6】
受信された作業要求を例示している。
【図7】
受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図8】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図9】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図10A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図10B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図10C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図11】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図14A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図14B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図15A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図15B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図16】
リスナのデータ構造を例示している。
【図17】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図17A】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図18】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図19A】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図19B】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図20】
インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図21】
モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図22】
図21の技術を、セキュアな通信を実現するために利用した例を示している。
【図23】
図21の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図24】
ポリシー管理テーブルを例示している。
【図25】
ポリシー管理処理のステップを例示したフローチャートである。
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック(nomadic)システムの特性を透過性(トランスペアレント)を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末(handheld data units)やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術およびシステムに関する。
【0001】
[発明の背景および要約]
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【0002】
モバイルネットワーキングに関する問題の多くは、イーサネット(登録商標)登場以前にローカルエリア・ネットワーク(LAN)構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【0003】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線装置を経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【0004】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント/サーバ、ホスト/ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【0005】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、TCP/IPセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング(ネットワークアドレスの変更)が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【0006】
(非接続あるいは圏外のユーザ)
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う(つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする)と、携帯装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【0007】
(他のネットワークへの、あるいはルータ境界を越える移動(ネットワークアドレス変更))
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【0008】
(セキュリティ)
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ(つまり、安全な施設の内部に構築されたケーブルを使って実行され)、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【0009】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【0010】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも持たせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【0011】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続(mobile interconnect)に接続されたモビリティ管理サーバ(Mobility Management Server; MMS)は、数量を限定されないモバイル端末システム(Mobile End Systems; MES)それぞれの状態の維持や、ネットワークへおよびピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは(あるモバイル相互接続から別の相互接続へとローミングすることなどで)ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【0012】
また、上記本発明の非限定的で具体的な実施の形態は、以下の(これらに限定されないが)新規かつ有用な技術、構成を提示する。
【0013】
・ユーザによって設定可能なセッション特性をモバイル・クライアントに付与するモビリティ管理サーバ。
【0014】
・ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシーを管理。
【0015】
・工業規格である動的ホスト構成プロトコル(Dynamic Host Configuration Protocol; DHCP)をモビリティ管理サーバと連携させて用いるローミング方法。
【0016】
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【0017】
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【0018】
より詳細には、上記本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムそれぞれの状態を維持し、ネットワークへおよび他の処理(例えば他のネットワークベースのピア・システムにて実行される処理)への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは(あるモバイル相互接続から別の相互接続へとローミングすることなどで)ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【0019】
また、上記本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【0020】
上記本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール(制御)アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション特性を、プロキシ・サーバ上で実行されるモバイル・クライアントについて実現し、ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシー設定を管理する。
【0021】
さらに、上記一側面においては、遠隔プロシージャ・コール(RPC)・プロトコル(Remote Procedure Call protocol)およびインターネット・モビリティ・プロトコル(Internet Mobility Protocol)が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【0022】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、RPCプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【0023】
RPCプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコルおよびインフラを経由して送られるメッセージに生成する。このRPCメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。RPCを備える上記本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【0024】
上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線LANおよびWANといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【0025】
上記本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル(例としてTCP/IP、UDP/IP、DHCPなど)を使用して構築される。上記本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム(信頼度の高いものも低いものも)を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられる、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【0026】
RPC層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違うまたは同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化/逆多重化により、利用可能な帯域幅を(最大限のサイズのネットワークフレームを生成することで)最大限に使うことができ、複数のチャネルを確立することができる(よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある)。
【0027】
上記本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような特徴や利点を実現する。なお、本発明は以下の点に限定されるものではない。
【0028】
・トランスポート・プロトコルの独立性
・ネットワーク上における位置(point of presence; POP)あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能(物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ)
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更(あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。)
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供(これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる)
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現(ヒステリシスに基づいて、フレームサイズ/フラグメント化の閾値、待機中のフレーム数(ウィンドウ)、再伝送時間、およびネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整)。
【0029】
・ネットワーク障害に対する耐性(モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない)
・操作パラメータを調整するための帯域内信号方式をピアに対して提供(接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能)
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現(これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持)
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用(このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる)
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策(インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能)
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能(例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了および/または拒否が可能)。
【0030】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【0031】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」(lock out)ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」(extend)されてしまっていることを考えると非常に重要である(例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ)。これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるURLに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【0032】
また、モバイル端末システムは「信頼性の低い」(untrusted)ネットワーク(つまり組織の管理が及ぶ範囲外のネットワーク)とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入(ingress)フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【0033】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナ(listener)によって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスによって補助されたローミングを行うことが可能になる。本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象(例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など)に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。再接続の際、リスナは予め記録された接続識別情報(attachment identification information)におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」(roam)状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする(これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい)。リスナは(操作を介して学習した)ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号(「同一サブネット上のローミング」、「ローミング」等)の適否を判定する一助としてもよい。
【0034】
上記本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ(MMS)に「非接続ネットワーキング」(disjoint networking)モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、MMSとの通信を確立する/持続するのに使われる、代替のネットワークアドレスを動的/静的に見つけ出すことができるようになる。この構成により、MMSが利用可能な代替アドレスのリストが予め設定され、通信中にMES(モバイル端末システム)に送られるかあるいはMESによって動的に学習される。実施の一形態において、MMSはMESに、一つ以上のMMSネットワークアドレスもしくは他のネットワークに対応した他のMMSのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付/更新が可能である。
【0035】
MESが別のネットワークへと移動するとき、MESは該ネットワークにおける新規のネットワーク接続を通じてMMSとコンタクトをとるために、MMSの「エイリアス」(alias)アドレス/アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、MESは新規のネットワーク接続を通じてMMSとのコンタクトを再確立することができる。
【0036】
上記本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて要求の遂行を許可、拒絶、または制限する。このような管理形態は、例えば、マルチホーム/パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【0037】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得(つまりローミング)に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置(ネットワークのどの接続ポイント、例えばアクセスポイント/基地局、ハブ、ルータ、GPS座標等に近いかなど)に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員(例えばユーザや装置)がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という3つの状態のいずれかをもたらすようにすることも可能である(例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される)。
【0038】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジン(policy engine)によって該アプリケーションによる操作/トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元(例えば、利用可能な/許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング)がある。
【0039】
さらに、ルールエンジン(rules engine)は、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【0040】
上記実施例におけるポリシー管理エンジン(policy management engine)において、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【0041】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、および/またはアセット・トラッキングのために取得され/備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【0042】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース PAN、IEEE 802.11 LAN、802.15 PAN、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としは、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【0043】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【0044】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。3G WANネットワーク、ブルートゥースネットワーク、802.11ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【0045】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【0046】
本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【0047】
[好ましい実施の形態の詳細な説明]
図1は、本発明の、モバイル強化ネットワークコンピュータシステム100を例示している。該ネットワークコンピュータシステム100は、モビリティ管理サーバ102と、一つ以上のモバイル端末システム104とを含んでいる。モバイル端末システム104は、ローカルエリア・ネットワーク(LAN)108を通じてモビリティ管理サーバ102と通信することができる。モビリティ管理サーバ102は、モバイル端末システム104のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ102はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム110とも、モビリティ管理サーバ102とモバイル端末システム104との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。本好ましい実施形態では、モビリティ管理サーバ102は、本発明の遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いて、モバイル端末システム104と通信する。
【0048】
この場合、モバイル端末システム104はモビリティ管理サーバ102とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム104a‐104kが、モビリティ管理サーバ102と、モバイル相互接続によって(この場合無線で)通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク108と無線(あるいは有線)でつながった、従来型の電磁(電波)トランシーバ106が考えられる。上記のようなモバイル相互接続により、モバイル端末システム104a‐104kが、一つのカバーエリア(cover area)107aから別のカバーエリア107kへとローミングすることが可能になる。一般的に、モバイル端末システム104が、あるカバーエリア107から別のエリアにローミングしたり、最も近いトランシーバ106から届く範囲を外れたり、あるいは信号を一時的に遮断(例えばビルの柱の裏側を通るなどで)されたりした場合、一時的に通信が切断される。
【0049】
・別のモバイル端末システム104l、104m…が、モビリティ管理サーバ102と、ドッキングポートやネットワークケーブルコネクタなどの着脱式(non−permanent)有線相互接続109を介して通信する。モバイル端末システム104は、接続109が外れたり、モバイル端末システム104の電源が切られたりした場合、一時的にLAN108から切断される。
【0050】
・さらに別のモバイル端末システム(例えば104n)が、モビリティ管理サーバ102と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ111を介してノマディック接続される。一例として、ネットワーク111のサービスは断続的なものであってもよく、他の例として、モバイル端末システム104がある種類の接続形態から別の種類のものへと移行(例えば、モビリティ管理サーバ102と有線相互接続109を通じて接続される状態からネットワーク111を通じて接続される状態へ移行、もしくはその逆)し、移行時に一時的に接続が切断されるという構成であってもよい。
【0051】
モバイル端末システム104は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム104は、市販のトランシーバおよび/またはネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム104は、標準的なネットワーク・アプリケーションや標準的なOS(オペレーティングシステム)を実行し、標準的なトランスポート・レベル・プロトコル(例えばTCP/IP)を利用して、トランスポート層で通信を行うものであってよい。本発明において、さらに、モバイル端末システム104がクライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ102との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【0052】
モビリティ管理サーバ102は、ウィンドウズ(登録商標)NTサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本好ましい実施形態では、モビリティ管理サーバ102は、規格に準拠したクライアント/サーバ型のインテリジェントサーバであって、企業ネットワーク108を透過性を有した状態でノマディック環境にまで延長するものである。モビリティ管理サーバ102は、数量を限定されないモバイル端末システム104それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ102はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム110とも、モバイル端末システム104とトランシーバ106との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【0053】
例えば、サーバ102はどのような標準的(例えばTCP/IPベースの)ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム104のセッションは、サーバ102によって維持され、該システムが復帰した際にはサーバ102が上記セッションをレジュームする。モバイル端末システム104が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ102は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム110との接続を維持する。
【0054】
サーバ102はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【0055】
一例として、モビリティ管理サーバ102が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク108と接続され、該ネットワーク108は、様々な固定端末システム(例えば一つ以上のホストコンピュータ110)110と接続される状況が考えられる。モビリティ管理サーバ102によって、モバイル端末システム104と固定端末システム110との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム104が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続106、109、111から別のネットワーク相互接続へと移動したりしても(例えば、無線相互接続の場合、ある無線トランシーバ106のカバーエリア107から別のカバーエリアにローミングしても)、利用可能となっている。
【0056】
モバイル端末システム104は、モビリティ管理サーバ102との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム104は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。モバイル端末システム104−モビリティ管理サーバ102間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本好ましい実施形態では上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【0057】
本発明の一例において、モバイル端末システム104は、UDP/IPのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ102と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム104が、標準的なルータ112など企業ネットワーク108に既存のインフラを用いて、モビリティ管理サーバ102と通信することが可能になる。本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク108を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージへと生成する。本好ましい実施形態において、上記のようなモバイルRPCメッセージは、モバイル端末システム104にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ102によって全てを完了させることができる。このことにより、モビリティ管理サーバ102とモバイル端末システム104とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【0058】
モバイル端末システム104のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルRPCプロトコルを通じてモビリティ管理サーバ102にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。本好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム104に実装されているOS(ウィンドウズ(登録商標)NT、ウィンドウズ(登録商標)98、ウィンドウズ(登録商標)95、ウィンドウズ(登録商標)CEなど)と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【0059】
モビリティ管理サーバ102は、それぞれのモバイル端末システム104の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ110のような通信相手のピア108との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。モバイル端末システム104との通信ができなくなったり、モバイル端末システム104がサスペンドしたり、あるいはネットワークアドレスを変更したり(例えばあるネットワーク相互接続から別のものにローミングしたり)した場合、モビリティ管理サーバ102は、モバイル端末システム104とホストシステム110などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム104との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア107K内において、あるネットワーク相互接続106Aから別のネットワーク相互接続106Kへとローミングしたりした場合でも、(物理的接続が再確立された際に単純に作業をレジュームすることで)モバイル端末システム104のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【0060】
モビリティ管理サーバ102はまた、モバイル端末システム104がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。モバイル端末システム104はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム104のそれぞれについて、モビリティ管理サーバ102は該システムの現状における実際の(位置)アドレスに対応して仮想アドレスを割り当てる。モバイル端末システム104の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム104の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【0061】
よって、モバイル端末システム104の位置アドレスの変更は、モビリティ管理サーバ102を介して、結合しているホストシステム110(および他のピア)におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア110から見えるのは、サーバ102によってプロキシされた(不変の)仮想アドレスのみということになる。
【0062】
本好ましい実施形態では、モビリティ管理サーバ102はさらに、コンソール(制御)アプリケーションと包括的なメトリクス(exhaustive metrics)とによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続およびシステムにおける問題を解決することができる。
【0063】
モビリティ管理サーバ102によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ102が有する処理用のリソースが有限であることを鑑みれば、有用なものである。システム管理者が上記のようにモビリティ管理サーバ102の設定を変更できることで、システムおよびネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ102の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ102のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【0064】
詳しく説明すると、モビリティ管理サーバ102は、アプリケーション、もしくはSNMPのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合(association)そのものの優先度、および/または、ある結合における複数のアプリケーションの優先度を設定することも可能である。例えば、モビリティ管理サーバ102を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である(本実施形態では、ユーザおよびユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい)。あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の3つの優先レベルが設定される例が考えられる。
【0065】
(サーバ/クライアント型ソフトウェア・アーキテクチャの例)
図2に、モバイル端末システム104とモビリティ管理サーバ102とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム104とモビリティ管理サーバ102は標準的なOSおよびアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク108を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。図2に示すように、モバイル端末システム104は、ネットワーク・インターフェイス・ドライバ200、TCP/UDPトランスポートサポート202、トランスポート・ドライバ・インターフェイス(TDI)204、および一つ以上の従来型のネットワーク・アプリケーション208に対するインターフェイスとして使われるソケットAPI206を含む、従来型のOSソフトウェアを実行する。従来型のネットワーク・ファイル/プリント・サービス210が、従来型のTDI204との通信用にさらに設けられていてもよい。サーバ102は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ200’、TCP/UDPトランスポートサポート202’、トランスポート・ドライバ・インターフェイス(TDI)204’、および一つ以上の従来型のネットワーク・アプリケーション208’に対するインターフェイスとして使われるソケットAPI206’を有していてもよい。モバイル端末システム104とモビリティ管理サーバ102はそれぞれ、さらにネットワーク/セキュリティ・プロバイダ236(モバイル端末システム)、ユーザ/セキュリティ・データベース238(サーバ)を備えていてもよい。
【0066】
本発明では、新規のモバイル・インターセプタ・コンポーネント212が、モバイル端末システム104のソフトウェア・アーキテクチャにおける、TCP/UDPトランスポートモジュール202とトランスポート・ドライバ・インターフェイス(TDI)204との間に挿入されている。該モバイル・インターセプタ・コンポーネント212は、トランスポート・ドライバ・インターフェイス(TDI)204における特定のコールを傍受して、該コールを、ネットワーク108を介し、RPCおよびインターネット・モビリティ・プロトコル、標準的なTCP/IPトランスポート・プロトコルを通じてモビリティ管理サーバ102へと転送する。こうして、モバイル・インターセプタ212は、全てのネットワーク活動を傍受して、サーバ102へと転送することができる。該インターセプタ212はOSと透過性を有する状態で協働するので、モバイル端末システム104がネットワーク108とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【0067】
モバイル・インターセプタ212は、トランスポート・ドライバ・インターフェイス204とは違うレベルで(例えばソケットAPI206のレベルで)動作することもできるが、TDIのレベルでモバイル・インターセプタ212が動作する、より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをTDIという略語で表わすこととする。多くの標準的なOS(例えば、マイクロソフト社のウィンドウズ(登録商標)95、ウィンドウズ(登録商標)98、ウィンドウズ(登録商標)NT、ウィンドウズ(登録商標)CEなど)はTDIインターフェイス204を実装しているので、OSのコンポーネントを変更することなく互換性が保証される。さらに、トランスポート・ドライバ・インターフェイス204は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【0068】
さらに、TDIインターフェイス204のレベルで作動するモバイル・インターセプタ212は、様々な別のネットワーク・アプリケーション208(例えば複数の同時に動作しているアプリケーション)に加えて、ネットワークにおけるファイル、プリント、および他のカーネル・モードなどのサービス210(インターセプタが例えばソケットAPI206のレベルで動作している場合はそれぞれ別に扱う必要がある)を傍受することができる。
【0069】
図2Aに、どのようにインターセプタ212が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム104のTDIインターフェイス204へのコール(ブロック250)は、モバイル・インターセプタ212によって傍受される(ブロック252)。モバイル・インターセプタ212によって傍受されたRPCコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、UDPやTCPといった標準的なトランスポート・プロトコルにより、LAN、WAN等のトランスポート108を介してモビリティ管理サーバ102へと送られる(ブロック252)。モビリティ管理サーバ102は受信したRPCデータグラムをアンパックして(ブロック254)、要求されたサービスを実行する(例えば、データや応答を、固定端末システム110で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション208のプロキシとして振舞う)。
【0070】
再び図2に戻って、モビリティ管理サーバ102は、従来型のネットワーク・インターフェイス・ドライバ222を介して送られる、モバイル端末システム104からの、あるいはモバイル端末システム104へ向かうメッセージを傍受する、アドレス変換部220を有している。例えば、アドレス変換部220は、セッションの相手のピア(固定端末システム110)からのモバイル端末システム104の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ224へと送られる。プロキシ・サーバ224は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム104の現在位置アドレスへと転送する。
【0071】
さらに、図2によると、モビリティ管理サーバ102は、アドレス変換部(中間ドライバ)220とプロキシ・サーバ224に加えて、設定マネージャ228、操作/ユーザインターフェイス230、およびモニタ232を有している。設定マネージャ228は設定情報とパラメータとを提供して、プロキシ・サーバ224が接続の管理を行えるようにする。操作/ユーザインターフェイス230とモニタ232により、ユーザとプロキシ・サーバ224との間のやりとりが可能になる。
【0072】
(モバイル・インターセプタ)
図3は、本発明のRPCプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ212のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ212は、遠隔プロシージャ・コール・プロトコル・エンジン240と、インターネット・モビリティ・プロトコル・エンジン244の、二つの機能コンポーネントを有している。モビリティ管理サーバ102において動作するプロキシ・サーバ224によって、対応するエンジン240’、244’が用意される。
【0073】
このように、本好ましい実施形態におけるモバイル・インターセプタ212は、モビリティ管理サーバ102をそれぞれのモバイル端末システム104と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。RPCプロトコルの利用によって、モバイル端末システム104が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク108において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【0074】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケット(Windows sockets)のようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのAPIへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信および受信データパケットが生成される。優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はRPCを備えており、モビリティ管理サーバ102とモバイル端末システム104とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【0075】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【0076】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ102とモバイル端末システム104との間の通信がなされる際の、機密情報のセキュリティを保証する。インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ102とモバイル端末システム104との間での全ての通信を認証、暗号化することを可能にする。
【0077】
図3のモバイル端末システム104における遠隔プロシージャ・コール・プロトコル・エンジン240は、TDIコールパラメータをマーシャリングし、データをフォーマットし、要求を、TDI遠隔プロシージャ・コール・プロトコル・エンジン240’がコールを実行するモビリティ管理サーバ102まで転送するべく、インターネット・モビリティ・プロトコル・エンジン244に送る。モバイル端末システム104は、遠隔プロシージャ・コール・プロトコルに基づいてTDIコールパラメータをマーシャリングする。モビリティ管理サーバ102のTDI遠隔プロシージャ・コール・プロトコル・エンジン240’が上記のRPCを受信すると、モビリティ管理サーバ102はモバイル端末システム104に代わってコールを実行する。モビリティ管理サーバ102のTDI遠隔プロシージャ・コール・プロトコル・エンジン240’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム104のRPCエンジン240と共有する。モバイル端末システム104の代理としての遠隔プロシージャ・コール実行に加え、サーバのRPCエンジン240’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの(アドレス変換機構220が行うサービスに対応した)多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、および融合処理(coalescing)を行う。
【0078】
インターネット・モビリティ・プロトコル・エンジン244は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、およびメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。インターネット・モビリティ・プロトコル・エンジン244は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【0079】
図3Aは、モバイル・インターセプタ212がモビリティ管理サーバ102と通信してTDIコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ212のRPCプロトコル・エンジン240は、マーシャリングされたTDIコールを、モビリティ管理サーバ102へと送るべく、インターネット・モビリティ・プロトコル・エンジン244へと転送する。RPCプロトコル・エンジン240は、この作業を、インターネット・モビリティ・プロトコル・エンジン244によって管理されるキューにRPCコールを加えることで達成する(ブロック302)。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン244は受信したRPCコールの転送を所定の期間(RPC融合タイムアウト期間)遅延させる(ブロック304)。一般的に、RPC融合タイムアウトは5ミリ秒から15ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、RPCエンジン240はTDIコールをインターネット・モビリティ・プロトコル・エンジン244のキューに加えて、一つ以上のRPCコールが同一のデータグラム(フラグメント)によって転送されるようにすることができる。
【0080】
融合タイムアウトが終了するか、RPCエンジン240がそれ以上のRPCコールの受信を拒否する(判定ブロック306)ことを決定すると、RPCエンジン240は、インターネット・モビリティ・プロトコル・エンジン244に、キューをフラッシュ(flush)し、RPCコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する(ブロック308)。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー244をフラッシュすることもしなければならず、本好ましい実施形態において、単一のRPC要求でフレーム全体が占められてしまう場合、IMP層は自動的に要求をピアに送るよう試みる。
【0081】
上記のように、モビリティ管理サーバ102のプロキシ・サーバはRPCプロトコル・エンジン240’とインターネット・モビリティ・プロトコル・エンジン244’とを有している。図3Bは、モバイル端末システム104からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ102で実行される処理を例示している。該フレームをモビリティ管理サーバ102が受信すると、インターネット・モビリティ・プロトコル・エンジン244’は、フレームが(基礎となるトランスポートの最大伝送量の制約で)フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム104からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン244’は、遠隔プロシージャ・コール・プロトコル・エンジン240’に、的確な結合関連文脈情報(association−specific context information)を伝えることができる。
【0082】
続いて、インターネット・モビリティ・プロトコル・エンジン244’は、受信したメッセージを、RPC受信示唆システム作業要求(RPC receive indication system work request)354にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ102のRPCプロトコル・エンジン240’に与える。RPCプロトコル・エンジン240’が作業要求352を受信すると、該エンジン240’は作業要求352を結合関連作業キュー356に加え、次に予定済みの要求をグローバルキュー358に送ることによって、結合処理のスケジューリングが行われる。続いて、RPCエンジン240’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー358がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー356が処理される。
【0083】
結合関連作業キュー356から、上記メインスレッドはそれまで待機していたRPC受信示唆作業要求を見つけ出す。次に、メインスレッドはRPC受信示唆作業要求356をキューから外し、該要求を解析する。図3Aを参照して説明した上記融合処理により、モビリティ管理サーバ102は、それぞれのデータグラムに内包された複数のRPCトランザクションを頻繁に受信することになる。モビリティ管理サーバ102は次に、該RPCトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム104に代わって実行する。パフォーマンス向上のため、RPCエンジン240’に、RPCメッセージ解析処理中の先読みメカニズムを備えさせて、RPCエンジン240’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か(パイプライン処理できるか否か)を確認してもよい。
【0084】
(RPCエンジン240’によるRPC結合の実行手法)
図4は、結合作業キュー356に加えられたRPC結合を実行する処理を例示したフローチャートである。RPC結合の実行が予定されている時、RPCプロトコル・エンジン240’(状態機械として設けられていてもよい)のメインスレッドは、グローバルネットワークキュー358からの作業要求を待機状態から外し、作業要求の種類を決定する。
【0085】
本実施形態のRPC作業要求は、以下のような6つの基本的な種類に分けられる。
【0086】
・スケジューリング要求(schedule request)
・接続示唆
・切断示唆
・ローカル結合中止(local terminate association)
・「リソース使用可」要求(”resource available” request)
・ping休止タイムアウト(ping inactivity timeout)
RPCプロトコル・エンジン240’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。RPCプロトコル・エンジン240’は要求の種類(グローバルキュー358に記憶された、要求に関する情報によって識別される)をテストして、該要求をどう処理するかを決定する。
【0087】
作業要求の種類が「スケジューリング要求」である場合(判定ブロック360)、RPCプロトコル・エンジン240’はどの結合が予定されているかを判別する(ブロック362)。RPCプロトコル・エンジン240’はこの判別を、グローバルキュー358に記憶されている情報に基づいて実行することができる。上記判別がなされると、RPCプロトコル・エンジン240’が、それぞれが対応する要求を記憶している結合作業キュー356(1)〜356(n)のうちの一つを特定することが可能となる。RPCエンジン240’によって、対応する結合制御ブロックが取得され(ブロック362)、結合作業処理タスク(Process Association Work task)364が呼び出されて、上記の特定された作業キュー356における作業の処理が始められる。
【0088】
図5は、図4の「結合作業処理」タスク364によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク364が呼び出され、対応する結合作業キュー356内の作業が処理される。待機状態から外された作業要求(ブロック390)がRPC受信要求(判定ブロック392)である場合、該RPC受信要求はRPC構文解析部(parser)に送られ、処理される(ブロック394)。あるいは、待機状態から外された作業要求(ブロック390)が、保留中の(pending)受信要求である場合(判定ブロック396)、RPCエンジン240’はTDI204’に、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する(ブロック398)。上記待機状態から外された作業要求が、保留中の接続要求である場合(判定ブロック400)、RPCエンジン240’はTDI204’に、アプリケーション用途TCP(あるいは他のトランスポート・プロトコル)接続要求を発するよう要求し(ブロック402)、TDI層204’からの応答を待つ。TDI204’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、RPCエンジン240’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー(356)へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅およびリソースの消費を減らすためのものである。
【0089】
上記の処理は、「スケジューリング重み付け」(scheduling weight complete)テスト(ブロック404)にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ228によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される(図4、ブロック372)。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【0090】
RPCエンジンが結合作業キュー356の作業を(少なくとも一時的に)終了した後、ディスパッチ・キューの処理に移ってもよい(ブロック406)(詳細は以下)。結合の作業キュー356における作業の処理後、RPCエンジン240’は、グローバル作業キュー358に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う(図4の判定ブロック366、ブロック368、図5の判定ブロック408、ブロック410)。
【0091】
再度図4を参照すれば、RPC作業要求が「接続示唆」の場合(判定ブロック370)、RPCエンジン240’に、モバイル・ピア(通常はモバイル端末システム104だがこれに限らない)との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がRPCエンジン240’に与えられる。
【0092】
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのRPCエンジン240からの、付加的な接続データ
接続示唆(判定ブロック370)を受け、RPCエンジン240は上記のパラメータをもって設定マネージャ228をコールする。設定マネージャ228は該パラメータを用いて、上記新規接続の設定を確定する。この設定(例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど)は、RPCエンジン240’に戻されて記憶、実行される。そしてRPCエンジン240’は新規の結合を開始し、新規の結合制御ブロックを形成する(ブロック372)。図5Aが示すように、以下のような動作が実行されてもよい。
【0093】
・結合制御ブロックを割り当てる(ブロック372A)
・システム全体のリソースをデフォルトにまで初期化する(ブロック372B)
・現在の設定をオーバーライドする(ブロック372C)
・フラグを初期化する(ブロック372D)
・結合特有作業キューを初期化する(ブロック372E)
・結合のオブジェクト・ハッシュ・テーブルを初期化する(ブロック372F)
・融合タイマーを初期化する(ブロック372G)
・結合制御ブロックをセッションテーブルに挿入する(ブロック372H)
インターネット・モビリティ・プロトコル・エンジン244’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン244’からRPCエンジン240’に出される。RPCエンジン240’はこの切断示唆をテストし(ブロック374)、示唆に応じて結合を停止し、結合制御ブロックを破棄する(ブロック376)。図5Bに示されるように、以下のステップが実行されてもよい。
【0094】
・待機中の作業がこれ以上処理されないように、停止される結合をマークする(ブロック376A)
・処理を含む、結合されている全ての結合オブジェクトをクローズする(ブロック376B)
・作業キューにある全てのエレメントを開放する(ブロック376C)
・融合タイマーが動作中ならば停止する(ブロック376D)
・結合制御ブロックの参照カウントを減少させる(ブロック376E)
・参照カウントが0の場合、(ブロック376Fにてテストされる)
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する(376G)
システム102が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、OS、あるいはアプリケーションから発される。RPCエンジン240’は、セッション中止要求を上記切断示唆と同様に扱う(判定ブロック378、ブロック376)。
【0095】
本好ましい実施形態では、RPCエンジン240’とインターネット・モビリティ・プロトコル・エンジン244’との間のインターフェイスが、クレジット(credits)を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは0になるが、慣例として、コールする側のスレッドは、クレジットのカウントが0ならばそれ以上作業通知をしない。よって、ユーザによって設定可能あるいは所定の最低点(low−water mark)をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である(判定ブロック380にてテストされる)。図5Cが示すように、クレジットのカウントが0になったとき、以下のようなステップが実行されてもよい。
【0096】
・RPC_LMPQ_SEND_FLAGと設定して、結合に「ロー・マーク保留」(low mark pending)とマークを付ける(ブロック379A)。この状態になったら、
・受信された全てのデータグラムを破棄する(ブロック379B)
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える(ブロック379C)(これにより、TCP他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム110とモビリティ管理サーバ102との間のフロー制御がなされる。復帰の前に、本好ましい実施形態では「保留受信要求」(pending receive request)を結合関連作業キュー356の前に押し込むので、保留中のストリーム受信イベントの処理(outstanding stream receive event processing)が、リソースが利用可能になると直ちに継続される)。
【0097】
・全ての受信された接続イベントが、受動接続のために拒否される(ブロック379D)
「リソース使用可」示唆をRPCエンジン240’が受け取ると(図4、判定ブロック380)、該RPCエンジンは、結合された結合作業キュー356に待機中の作業があるか否かを判定する。もしあれば、RPCエンジンは該結合についてグローバル作業キュー358に通知して、上記結合作業キュー356が動作の優先権を持つことをマークしておく(ブロック382)。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される(本好ましい実施形態では、RPCエンジン240’は、この処理中も全ての受信された接続要求を受け入れる)。
【0098】
再度図4を参照すると、RPCエンジン240’が、モビリティ管理サーバ102の「ping」に使われるチャネルが所定の期間にわたって休止していると判定した場合(判定ブロック384)、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される(ブロック386)。
【0099】
(RPC構文解析と優先キュー)
再度図5を参照すると、RPCエンジンがRPC受信要求をその受信に際して構文解析することは前述した(ブロック392、394参照)。本好ましい実施形態において、構文解析は以下の点で必要とされる。即ち、受信された単一のデータグラムが複数のRPCコールを含む可能性があるからであり、また、RPCコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。RPC受信作業要求500のフォーマットの例が図6に示される。RPC受信作業要求のそれぞれは、少なくともメイン・フラグメント502(1)を有し、加えて任意の数の付加的フラグメント502(2)〜502(N)を有していることもある。メイン・フラグメント502(1)は、作業要求構造ヘッダ(work request structure header)503と、受信オーバーレイ504とを有している。受信オーバーレイ504は、インターネット・モビリティ・プロトコル・エンジン244によってメイン・フラグメント502(1)の先頭に設けられた受信オーバーレイである。この受信オーバーレイ504には、pユーザデータと呼ばれる、作業要求500内で最初のRPCコール506(1)を指し示す構造メンバがある。
【0100】
図6の例に、複数のRPCコール506(1)、506(2)…506(8)を含む、作業要求500が図示されている。図6の例が示すように、RPC作業要求500は、メモリの隣接するブロックや単一のフラグメント502に含まれていなくてもよい。同例において、第二フラグメント502(2)と第三フラグメント502(3)とは、リンクしたリスト中でメイン・フラグメント502(1)に連鎖されている。
【0101】
よって、上記例のRPCパーサ394は以下の境界条件を取り扱う。
【0102】
・RPC受信要求500それぞれが一つ以上のRPCコールを含んでもよい
・一つ以上のRPCコール506が、単一のフラグメント502中に存在してもよい
・RPCコール506それぞれが、フラグメント502中に完全に含まれていてもよい
・RPCコール506それぞれは、一つ以上のフラグメント502にまたがっていてもよい
図7は、RPC受信作業要求500を解析するRPC構文解析部394を例示している。本例において、RPC構文解析部394は作業要求中の第一フラグメント502(1)を取得し、該フラグメント中の第一RPCコール506(1)を取得し、そしてRPCコールを解析する。構文解析部394はRPC受信作業要求500中を進んで、RPCコール506それぞれを処理していく。RPC受信作業要求500のフラグメント502(1)の残りのフラグメント・バイト数が、RPCヘッダ503のサイズよりも多い場合、構文解析部394は、RPCコールが完全にRPCフラグメント502に含まれていて、処理を実行してもよいかどうかを判定する(該判定は、RPCコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい)。RPCコールの種類が連鎖例外である場合、RPCコールはRPC構文解析部394のアップデートを行うことになる。プロキシ・サーバ224において、連鎖例外であるRPCコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、RPCエンジンは、RPC送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【0103】
構文解析部394がRPCコールの種類を判別すると、RPC情報の始めへのポインタは、実行のためにRPCエンジン240へと転送される。RPCエンジンは、実行のために全てのTDIプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、RPCディスパッチャ395へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー510にディスパッチされる。ディスパッチ・キュー510はそれぞれ離散的な優先度を表わしている。
【0104】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクト機能を、他のTDIネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレスまたは接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【0105】
例えば、RPCコールがTDIオープンアドレスオブジェクト要求あるいはTDIオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくRPCディスパッチャ395に送られる。オープンアドレスおよびオープン接続オブジェクトRPCコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ228からもたらされる情報との対応に用いられる、処理IDあるいは処理名へのアクセスが可能になる。該処理IDあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【0106】
本好ましい実施形態では、全てのRPCコールは、パラメータとして少なくともアドレスオブジェクトまたは接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、RPCコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するRPCコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー510にディスパッチされることなく、全てのRPCコールが直ちに実行される。割り当てられた優先度が「1」の場合、全てのRPCコールが、ディスパッチ・キュー510(1)に加えられる。
【0107】
再度図5を参照すると、「結合作業処理」(process association work)タスク364の処理が、予定された結合作業量の実行を完了すると(判定ブロック404)、ディスパッチ・キューがサービスを要求しているか否かが確認される(ブロック406)。図8は、図7に示されるディスパッチ・キュー510の処理のための「ディスパッチ・キュー処理」(ブロック406、図6)によって実行されるステップを例示したフローチャートである。
【0108】
この例では、ディスパッチ・キュー510は優先度が最高のキュー(本例では510(1))から処理される(ブロック408)。ディスパッチ・キュー510にはそれぞれ重み係数が設定されている。この重み係数は、モバイル端末システム104とモビリティ管理サーバ102との結合が確立された際に、設定マネージャ228によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー510の重み係数は4であり、優先度が中程度のディスパッチ・キュー510重み係数は8である。本例では、優先度の高いRPCコールは解析後直ちに処理されるため、重み係数を有していない。
【0109】
RPCエンジン240’は、現在のキューより始めて、RPCコールをキューから外していき、キューが空になるか、RPCコールのキュー重み番号(queue weight number)が処理されるまでループする(ブロック412−416)。キューから外されたRPCコールそれぞれに対して、その実行のためにRPCディスパッチャ395が呼び出される。RPCディスパッチャ395はモバイル端末システム104の代理としてプロシージャ・コール(procedural call)を実行し、応答を要求している上記RPCコールに対するモバイル端末システムからの応答を生成する。
【0110】
上記ループを出た後、キューに残っている作業がまだある場合(判定ブロック418)、該キューが再実行を要することがマークされる(ブロック420)。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる(ブロック424、410)。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図4の「グローバル作業処理」ルーチンにおいて予定される。上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ102のCPUへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にCPUにアクセスできるようになる。
【0111】
(モビリティ管理サーバのRPC応答)
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム104からモビリティ管理サーバ102に送られて実行されるかを説明した。この型のRPCコールに加え、モビリティ管理サーバ102のRPCエンジン240’はRPCイベントとRPC受信応答とをサポートしている。結合関連接続ピア(通常は固定端末システム110)の活動の結果として、RPCメッセージが非同期的に生成される。モビリティ管理サーバ102のRPCエンジン240’は、RPCディスパッチャ395によって実行されるRPCトランザクションを完了する。完了が成功したからといって、全てのRPCコールが応答を要求するわけではないが、応答を要求する一部のRPCコールにより、RPCディスパッチャ395は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン244’に知らせ、そして該応答はピアのモバイル端末システム104に返される。RPCコールが失敗したときは、全てのRPCコールが応答を生成する(上記においてRPC受信応答は例外)。
【0112】
RPCイベントは、結合関連接続(通常は固定端末システム110)によるネットワーク108の活動の結果として発信される。本好ましい実施形態では、こうしたRPCイベントメッセージはモビリティ管理サーバ102によってプロキシされ、モバイル端末システム104へ送られる。本好ましい実施形態のモビリティ管理サーバ102は、以下のRPCイベントコールをサポートする。
【0113】
・切断イベント(結合特定接続ピア(通常は固定端末システム110)がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム104に代わってプロキシ・サーバ224に受信され、プロキシ・サーバ224は切断イベントをモバイル端末システムに送る)
・ストリーム受信イベント(結合特定接続ピア(通常は固定端末システム110)がストリームデータをモバイル端末システム104へ送る際に生起。プロキシ・サーバ224はモバイル端末システム104に代わって該データを受け取り、受信応答(Receive Response)として該データをモバイル端末システムに送る)
・データグラム受信イベント(結合特定ポータル(association−specific portal)のいずれかが、ネットワーク・ピア(通常は固定端末システム110)から送られ、モビリティ管理サーバ102を経由してモバイル端末システム104へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ224はモバイル端末システム104に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム104へ転送する)
・接続イベント(結合特定リスニングポータル(association−specific listening portal)が、トランスポート層とモバイル端末システム104との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求(通常は固定端末システム110から)を受信するときに生起する。プロキシ・サーバ224はモバイル端末システムに代わって接続要求を受け入れ、接続イベントRPCコールを生成してモバイル端末システムに送る)
図9は、RPCエンジン240’が、いかにしてプロキシ・サーバによって生成されたRPCコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、RPCエンジン240’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン244’に向けてディスパッチする。該送信要求によって、RPCメッセージがピアのモバイル端末システム104に転送される。優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン244の送信要求が適切な優先キュー510’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー358’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図5および8を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【0114】
(インターネット・モビリティ・プロトコルの例)
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、(再)オーダ検出((re)order detection)、ロス回復が可能である。さらに、他の従来型接続指向プロトコル(即ちTCP)とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【0115】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点(POP)あるいはネットワーク・インフラは、物理的境界、特定のポリシー、あるいは帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【0116】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【0117】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、(下層のネットワークがサポートしていれば)サービス品質の保証も可能になる。
【0118】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間(validity time period)か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【0119】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールド(optional field)によって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールド(header flag field)のビットによって示される。ピアによる通信に必要な他の制御および設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【0120】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズム(Fletcher checksum algorithm)が、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【0121】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、TCPの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大65535バイト(インターネット・モビリティ・プロトコル・ヘッダを含む)までの、データのフレームを表現している。該シーケンス番号は32ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【0122】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送(再試行)されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームIDを設定して最新のバージョンのフレームが検知することも可能だが、本好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【0123】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる(伝送できる)。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【0124】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値(retransmission timeout value)の基準となる。フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値および下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【0125】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ(フラグメント化閾値)、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【0126】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性(例えばフレームサイズ)が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい(大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため)。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される(あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる)。
【0127】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。運営上必要な操作を可能にするため、モビリティ管理サーバ102上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム104からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ102はセッションを終了させることができる。また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ102側からのみ操作できるようにしてもよい。
【0128】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ(登録商標)NT、9x、CE環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層(network abstraction layer; NAL)のサービスが採用されている。メモリ管理、キューおよびリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム104に備えられているか、あるいはモビリティ管理サーバ102側に備えられているかによって変更される。これについて、数例を以下に示す。
【0129】
・特定のタイムアウトは、モビリティ管理サーバ102からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム104の設定により、着信接続(inbound connection)の拒否が可能
・警報はモビリティ管理サーバ102にのみ通知される
・電力管理はモバイル端末システム104ではイネーブルにされるが、モビリティ管理サーバ102では必ずしも必要でない
インターネット・モビリティ・プロトコルのインターフェイスは、Cコーラブルでプラットフォームに依存しない標準的なAPI機能をほんの少数有し、作業(上記の標準的なユーティリティ機能以外)を予定する、OS特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト(作業要求)の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【0130】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、FIFOオーダに従ってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ProtocolRequestwork()」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでOSのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム(例えばウィンドウズ(登録商標)NT)や同期式のシステム(例えばマイクロソフト・ウィンドウズ(登録商標)9xやウィンドウズ(登録商標)CE)で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、(下の層がサポートしていれば)サービス品質を保証することができる。
【0131】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術(scatter−gather techniques)を利用している。伝送はそれぞれフラグメントのリストとしてNALに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、NAL層により、NAL登録処理(NAL registration process)時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【0132】
(インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例)
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップおよびシャットダウン行動を管理する、4つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
【0133】
1.Internet Mobility ProtocolCreate()
2.Internet Mobility ProtocolRun()
3.Internet Mobility ProtocolHalt()
4.Internet Mobility ProtocolUnload()
(Internet Mobility ProtocolCreate()の例)
Internet Mobility ProtocolCreate()機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ228のサービスを利用して該テーブルを設定(populate)する。
【0134】
次に、インターネット・モビリティ・プロトコルは、サスペンドおよびレジューム通知機能をAPMハンドラに登録する。一例ではこれらの機能はモバイル端末システム104の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ102がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルNALポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【0135】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の2段配列構成(2−tier array scheme)を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、_STATE_INITIALIZE_となる。
【0136】
(Internet Mobility ProtocolRun()の例)
Internet Mobility ProtocolRun()機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【0137】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−NAL間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、NALの全てのリスナをスタートさせることができる。一例として、この動作は2つのステップを含んだ以下の処理のようになる。
【0138】
・インターネット・モビリティ・プロトコルは、NAL層に、初期化中に供給される設定に基づいたポータルを結びつけて(bind)オープンし、
・インターネット・モビリティ・プロトコルは、次に、Internet Mobility ProtocolRCVFROMCBコールバックを登録して、受信したフレームの処理を始める準備ができたことを、NAL層に通知する。
【0139】
・引き続き、ローカル持続識別子(local persistent identifier; PID)が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、_STATE_RUN_に変わる。
【0140】
(Internet Mobility ProtocolHalt()の例)
Internet Mobility ProtocolHalt()機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが_STATE_HALTED_状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【0141】
(Internet Mobility ProtocolUnload()の例)
Internet Mobility ProtocolUnload()機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【0142】
(インターネット・モビリティ・プロトコル・ハンドルの例)
少なくともいくつかの例においては、メモリ(インターネット・モビリティ・プロトコル状態情報を記憶)のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。元々のピアが、(電源が切られていたり、サスペンドしていたり、圏外にあったりなどで)セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。TCPの場合はこれが起こり、ピアのIPアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドル(manufactured handle)を採用している。該ハンドルは2列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【0143】
テーブル1:接続オブジェクトの配列を指すポインタの配列
テーブル2:インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル1は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム104の側では、少量のメモリの割り当てが可能になる(モビリティ管理サーバ102側でテーブル1が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる)。
【0144】
テーブル1は必要時に設定(populate)される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル1内でテーブル2への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル2に256個の接続オブジェクトを割り当て、テーブル2へのポインタを、テーブル1の適切なスロットに記録する。次に、プロトコル・エンジンはテーブル2を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル1中をサーチして、テーブル2への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
【0145】
・テーブル2から全ての接続オブジェクトが無くなった場合、新たにテーブル2が割り当てられ、初期化されて、該テーブル2を示すポインタが、テーブル1の次に利用可能なスロットに設定される。
【0146】
・全ての接続オブジェクトが特定のテーブル2のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル2の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル1の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる(テーブル2の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る)。
【0147】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル2が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル2のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【0148】
(ワークフローの例)
Internet Mobility ProtocolRequestWork()機能によって、作業はローカルクライアントから要求される。該作業が検査(validate)され、グローバル作業キューに加えられると、Internet Mobility ProtocolQueueEligible()機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ(適合マークがつけられ)、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Internet Mobility ProtocolProcessWork()機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【0149】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Internet Mobility ProtocolRequestWork()機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【0150】
SENDタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、SENDタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。SENDオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのSENDオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【0151】
(接続スタートアップの例)
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低3フレームをやり取りすることでなされる。開始側は、そのピアにIMP SYNCフレームを送って接続確立が要求されていることを警告する。受け入れ側は、IMP ESTABLISHフレームを送って接続受け入れを確認するか、あるいはIMP ABORTフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由および状態コードが、IMP ABORTフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム(プロトコル・データ・ユニットおよび制御データがふくまれていることもある)が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【0152】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザおよび制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるようにすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【0153】
(データ転送の例)
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、NALからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてNALが返答するまでは、他のデータグラムを送信しない。
【0154】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【0155】
(黙認(acquiescing)の例)
再伝送時のネットワーク帯域幅およびモビリティ管理サーバ102の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ102が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ102は、対応するモバイル端末システム104から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ102は、モバイル端末システム104が通信できない状態(圏外、サスペンドなど)であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
【0156】
・モビリティ管理サーバ102がモバイル端末システム104からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、または
・システム管理者によって接続が中止される
モビリティ管理サーバ102が、モバイル端末システム104からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム104には以前の接続の終了が通知され、モバイル端末システム104に送られることを待機していた作業は破棄される。
【0157】
(接続および送信要求の例)
図10A〜10Cは、インターネット・モビリティ・エンジン244によって生成される接続および送信要求ロジックを例示する、フローチャートを形成している。RPCエンジン240からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン244は、該命令が「接続」要求かどうかを判定する(判定ブロック602)。該命令が「接続」要求であれば、エンジン244は、接続リソースの割り当てが可能かどうかを判断する(判定ブロック603)。十分な接続リソースが割り当てられない場合(判定ブロック603で「ノー」である場合)、エンジン244はエラーを宣言して(ブロック603a)応答する。接続リソースの割り当てが可能であれば、エンジン244は状態設定処理を行って、接続要求の処理に備える(ブロック603b)。
【0158】
接続その他の要求に対し、エンジン244は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する(ブロック604)。
【0159】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン244はまず、保留されている作業の有無を判定する(判定ブロック605)。保留されている作業が無ければ(判定ブロック605で「ノー」である場合)、エンジン244は、図10Cのブロック625に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ(ブロック605A)。保留されている作業があれば(判定ブロック605で「イエス」の場合)、エンジン244は現在の状態が確立されているか否かを判定する(ブロック606)。状態が確立されている場合(判定ブロック606で「イエス」の場合)、エンジン244は状態確立への移行のためのステップを飛ばして、図10Bの判定ブロック615に移る(ブロック606a)。状態が確立されていない場合、エンジン244は状態確立のための一連のステップを実行する必要がある(判定ブロック606で「ノー」である場合)。
【0160】
状態確立に移行するために、エンジン244はまず、そのピアのアドレスが既知かどうかを判定する(判定ブロック607)。既知でなければ、エンジン244は作業をさらに待機させ、図10Cのブロック625に移って、ピアのアドレスが来るのを待つ(ブロック607a)。ピアのアドレスが既知の場合(判定ブロック607で「イエス」の場合)、エンジン244は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する(判定ブロック608)。取得されていない場合、エンジン244は作業をさらに待機させ、図10Cのブロック625に移って、セキュリティコンテキストが来るのを待つ必要がある(ブロック607a)。セキュリティコンテキストが既に取得されている場合(判定ブロック608で「イエス」の場合)、エンジン244は「状態保留」状態を宣言して(ブロック608b)、インターネット・モビリティ・プロトコルの同期フレームを送信し(ブロック609)、再伝送タイマーをスタートさせる(ブロック610)。エンジン244は、対応する確立フレームが受信されたかどうかを判定する(ブロック611)。受信されていない場合(判定ブロック611で「ノー」の場合)、エンジン244は、再伝送時間の期限が来たかどうかを判定する(判定ブロック612)。再伝送時間の期限が来ていない場合(判定ブロック612で「ノー」の場合)、エンジン244は待機し、続いてステップ625に移ってもよい(ブロック613)。最終的に、確立フレームが受信されず(ブロック611で判定)、再伝送時間の期限が全て切れた(判定ブロック614)場合、接続は中止されてもよい(ブロック614a)。結局確立フレームが受信された場合(判定ブロック611で「イエス」の場合)、エンジン244は「状態確立」状態を宣言する(ブロック611a)。
【0161】
状態確立がなされると、エンジン244は新規の接続の認証がなされているかどうかを判定する(判定ブロック615)。なされていない場合、エンジン244は待機し、ステップ625へと移ってよい(ブロック616)。接続の認証がなされている場合(判定ブロック615で「イエス」の場合)、エンジン244は認証が成功したかどうかを判定する(判定ブロック617)。成功していない場合(判定ブロック617で「ノー」の場合)接続は中止される(ブロック614a)。成功している場合、エンジン244は、ピア伝送ウィンドウがフルになっているかどうかを判定する(判定ブロック618)。フルになっていれば(判定ブロック618で「イエス」の場合)、エンジン244は確認応答を待ち、ステップ625に進む(判定ブロック619)。ウィンドウがフルになっていなければ(判定ブロック618で「ノー」の場合)、エンジン244はインターネット・モビリティ・プロトコル・データフレームを生成し(ブロック620)、送信する(ブロック621)。次に、エンジン244は再伝送タイマーがスタートしているかどうかを判定する(判定ブロック622)。していない場合、エンジン244は再伝送タイマーをスタートさせる(ブロック623)。エンジン244は、それ以上送信するデータが無くなるまで(判定ブロック624で判断される)、ブロック618〜623を繰り返す。そして、エンジン244はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る(ブロック625)。
【0162】
(中止の例)
図11は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示したフローチャートである。「接続中止」要求を受けて(ブロック626)、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する(ブロック626a)。中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる(ブロック627)。エンジン244は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する(判定ブロック628)。緊急のものの場合(判定ブロック628で「中止」の場合)、エンジン244は直ちに接続を中止する(ブロック629)。余裕があるものであれば(判定ブロック628で「余裕」の場合)、エンジン244は「状態クローズ(state close)」状態を宣言し(ブロック628a)、インターネット・モビリティ・プロトコルの「モーティス(Mortis)」フレームを送信し(ブロック630)、ピアに接続がクローズされることを示唆する。次に、エンジン244は「モーティス」状態を宣言し(ブロック630a)、再伝送タイマーをスタートさせる(ブロック631)。エンジン244は、ピアから「ポスト・モーテム(post mortem)」フレームが応答されたかどうかを判定する(判定ブロック632)。応答されていなければ(判定ブロック632で「ノー」の場合)、エンジン244は、再伝送タイマーが時間切れになっているか否かを判定する(判定ブロック633)。まだ時間切れになっていない場合(判定ブロック633で「ノー」の場合)、エンジン244は待機し、ステップ637へ進む(ブロック634)。再伝送タイマーが時間切れになっている場合(判定ブロック633で「イエス」の場合)、エンジン244は総再伝送時間の期限が切れているかどうかを判定する(判定ブロック635)。まだ切れていない場合(判定ブロック635で「ノー」の場合)、ブロック630に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合(判定ブロック635で「イエス」の場合)、エンジン244は直ちに接続を中止する(ブロック635a)。
【0163】
「ポスト・モーテム」応答フレームがピアから受信されると(判定ブロック632で「イエス」)、エンジン244は「ポスト・モーテム」状態を宣言して(ブロック632a)、接続リソースを開放し(ブロック636)、スリープ状態に戻ってさらに作業を待つ(ブロック637)。
【0164】
(再伝送の例)
図12は、インターネット・モビリティ・プロトコル・エンジン244が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える(ブロック650)と、エンジン244は、保留中のフレームがあるかどうかを判定する(判定ブロック651)。保留中のフレームがなければ(判定ブロック651で「ノー」の場合)、エンジン244はタイマーを破棄して(ブロック652)スリープ状態に戻る(ブロック660)。逆に保留中のフレームがあれば(判定ブロック651で「イエス」の場合)、エンジン244は、再伝送期間全体(entire)が終了したかどうかを判定する(判定ブロック653)。まだ終了していなければ(判定ブロック653で「ノー」の場合)、処理は時間差のためにスリープ状態に戻る(ブロック654)。既に終了していれば(判定ブロック653で「イエス」の場合)、エンジン244は、総ての(total)再伝送期間が終了したかどうかを判定する(判定ブロック655)。既に終了しており(判定ブロック655で「イエス」)、このイベントがモビリティ管理サーバのエンジン244’(モバイル端末システムのエンジン244に対応)で実行されている場合、休眠状態が宣言される(判定ブロック656、ブロック656a)。同じ状態で、モバイル端末システム104において実行されるインターネット・モビリティ・プロトコル・エンジン244は、接続を中止する(ブロック656b)。
【0165】
総ての再伝送期間がまだ終了していない場合(判定ブロック655で「ノー」の場合)、エンジン244はフレームを再処理して時間切れのデータを除去し(ブロック657)、それを再転送し(ブロック658)、再転送タイマーをそのまま再始動させる(ブロック659)。そして処理は休眠状態に入り(ブロック660)、次のイベントを待つ。
【0166】
(インターネット・モビリティ・プロトコルのPDUの期限切れの例)
図12のブロック657において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット(つまりSEND作業要求)506の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン244は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。上層からのPDU(プロトコル・データ・ユニット)それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン244によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト(validity timeout)および/または再試行カウントを、特定することができる。有効期限タイムアウトおよび/または再試行カウント(アプリケーションによってはユーザによって特定可能)は、エンジン244による再伝送の前に、どのPDU506が、転送されずにフレームから除去されるべきかを決定するために使われる。
【0167】
PDU506に関わる有効期限タイムアウトは、PDUそれぞれが伝送に際して考慮すべき、相対期間(relative time period)を特定する。実行依頼の間、Internet Mobility ProtocolRequestWork機能によって有効期限の値(expiry timeout value)がチェックされる。該値が0で無い場合、時期タイマー(age timer)は初期化される。次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるPDU506が、有効期限パラメータ(validity period parameter)が特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該(全ての)PDUは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗(timeout failure)」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなる(grow stale)こと、および/または際限なくシステムリソースを消費することを防ぐ。
【0168】
図12Aの例において、少なくとも3つの独立したPDU506が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン244でキューに加わっている。PDU506(1)は有効期限を持たず、要求に対するタイムアウトが無い。PDU506(2)は、2秒の有効期間を持ち、時系列的にPDU506(1)の後に並んでいる。PDU506(n)は、2.5秒の有効期間を持ち、時系列的にPDU506(2)の後に並んでいる。PDU506(n)の待機が、キューの処理をさせ、PDU506(2)の有効期間を経過させる最初のイベントであるため、PDU506(2)は作業キューから外され、ローカルに完了されて、PDU506(n)がリストに加えられる。有効期間がPDU506(n)に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント(キューに加える、キューから外す等)によっても、古くなったPDUが除去され、完了される。
【0169】
上記のように、PDU506はインターネット・モビリティ・プロトコル・エンジン244の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン244は、最終的にこれらのPDU506をピアに送り、関係するフレームをフレーム保留リスト(Frames−Outstanding list)に加える。ピアが一定期間内に該フレームを認識しなかった場合(図12の再伝送アルゴリズムを参照)、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するPDUリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが0ではなく、0に向かって減少してゆく場合、PDU506はリストから外され、フレームヘッダはデータの消去を示すように修正される。このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン244’の再伝送アルゴリズムによって負担をかけられることがない。
【0170】
図12Bの例においても、少なくとも3つの独立したPDU506が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン244でキューに加わっている。PDU506(1)は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。PDU502(2)は再試行カウントが1でキューに加わり、時系列的にPDU506(1)の後に並ぶ。PDU506(n)は、ある程度の時間が経過してからPDU502(2)より後ろに加わる。この時点で、いくつかの外部イベント(例えば上層融合・タイマー)が、エンジン244’に、インターネット・モビリティ・プロトコル・データフレーム500を生成するための作業キューから十分なPDU506を集めて新しいフレームを生成するための論理を送信させる。フレームヘッダ503が求められ、これに、フレームの最初の伝送であることを示すための、再試行IDとして0が付けられる。続いてフレームは、ネットワークへの後の伝送用に、NAL層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン244の再伝送ロジックにより、当該するフレーム500が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをNAL層に再送する前に、エンジン244’の再伝送ロジックは、関連しているPDU506のリストを反復する。PDU506(2)それぞれの再試行カウントが調べられ、0でなければ、該カウントは減少させられる。PDU506(2)の再試行カウントを減少させる処理により、該カウントは0になる。PDU506(2)の再試行カウントが0になったことにより、PDU506(2)はリストから外され、「再試行失敗(retry failure)」のステータスをもってローカルに完了する。続いて、PDU506(2)のデータが無いことを示すため、フレームヘッダ503のサイズが調整される。この処理は、残っている全てのPDUについて繰り返される。フレーム500全体が、「編集後」フレーム500’の作成のために再処理されると、ヘッダの再試行IDが増加させられて、生成されたデータグラムが、続く(再)伝送に向けてNAL層に送られる。
【0171】
(受信の例)
図13A〜13Dは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク108から送られた際に生成される。この受信イベントを受けて、エンジン244は該イベントを事前検査(pre−validate)し(ブロック670)、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する(判定ブロック671)。エンジンが可能性無しと判断した場合(判定ブロック671で「ノー」の場合)、該フレームは破棄される(ブロック672)。可能性ありという判断の場合(判定ブロック671で「イエス」の場合)、エンジン244は、受信したフレームと関連する接続があるかどうかを判定する(判定フレーム673)。受信したフレームと関連する接続がある場合(判定ブロック673で「イエス」の場合)、エンジン244は作業を接続受信キューに加え(ブロック674)、該接続に受信に適格であるとマークを付け(ブロック675)、該接続をグローバル作業キューに加える(ブロック676)。まだどの接続も受信したフレームと関連していない場合(判定ブロック673で「ノー」の場合)、エンジン244は、受信したフレームをソケット受信キューに加え(ブロック677)、該ソケット受信キューをグローバル作業キューに加える(ブロック678)。どちらの場合でも、エンジン244はグローバル作業イベントを送る(ブロック679)。「受信適格」イベントをグローバル作業キューからディスパッチする際(図13B参照)、エンジン244はフレームをそれぞれの受信キューから外す(ブロック680)。インターネット・モビリティ・プロトコル・エンジン244がメッセージをキューから外し始められるようになる前に、複数のIMPフレームを受信し、キューに加えることが可能である。エンジン244は、全てのフレームがキューから外れるまで作業を繰り返す(ブロック681、682)。あるフレームがキューから外れると(判定ブロック681で「イエス」)、エンジン244は受信したフレームを検査し(ブロック683)、該フレームが有効かどうかを判定する(判定ブロック684)。該受信したフレームが無効である場合、エンジン244は該フレームを破棄し(ブロック685)、受信キューから次のフレームを外す(ブロック680)。上記フレームが有効である場合(判定ブロック684で「イエス」の場合)、エンジン244は、該フレームが既存の接続と関連しているか否かを判定する(ブロック686)。していなければ(判定ブロック686で「ノー」の場合)、エンジン244は同期フレームがあるかどうかを判定する(判定ブロック687)。同期フレームがなければ(判定ブロック687で「ノー」の場合)、該フレームは破棄される(ブロック685)。反対に、同期フレームが受信されていれば(判定ブロック687で「イエス」の場合)、エンジン244は、図14Aおよび14Bを参照して説明される受動接続要求により、該フレームを処理する(ブロック688)。
【0172】
上記フレームが接続と関係していれば(判定ブロック686で「イエス」の場合)、エンジン244は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する(判定ブロック689)。接続が既に「ポスト・モーテム」である場合、フレームは破棄される(ブロック685)。そうでない場合、エンジン244はフレームを解析し(ブロック690)、該フレームが中止フレームであるかどうかを判定する(判定ブロック691)。該フレームが中止フレームであれば、エンジン244は直ちに接続を中止する(ブロック691a)。該フレームが中止フレームでなければ(判定ブロック691で「イエス」の場合)、エンジン244は確認応答情報を処理し、全ての保留中の送信フレームを開放する(ブロック692)。次に、エンジン244は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る(ブロック693)。フレームがセキュリティ用のサブシステムから戻ると、エンジン244は全ての制御データを処理する(ブロック694)。続いて、エンジン244はフレームがアプリケーションデータを含んでいるかどうかを判定する(判定ブロック695)。含んでいる場合、該データはアプリケーション層においてキューに加えられる(ブロック696)。エンジン244はまた、接続が休止状態であるかどうかを判定し(ブロック697および697a:これは、好ましい実施形態におけるモビリティ管理サーバのエンジン244’にもあてはまる)、確立状態に戻す。
【0173】
フレームが「モーティス」フレームである可能性があれば(判定ブロック698で「イエス」の場合)、エンジン244は、アプリケーション層に「切断」を示唆し(ブロック699)、「モーティス」状態に入る(ブロック699a)。エンジン244は「ポスト・モーテム」フレームをピアに送り(ブロック700)、「ポスト・モーテム」状態に入る(ブロック700a)。続いて、エンジン244は接続リソースを解放し(ブロック701)、スリープ状態に戻って作業を待つ(ブロック702)。解析されたフレームが「ポスト・モーテム」フレームだった場合(判定ブロック703で「イエス」の場合)、ブロック700a、701、702が実行される。これ以外の場合、制御はブロック680に戻って、次のフレームを受信キューから外す(ブロック704)。
【0174】
(受動接続の例)
図14A〜14Bは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。まず、エンジン244は、当該装置に他の接続が存在するかどうかを判定する(ブロック720)。存在すれば(判定ブロック720で「イエス」の場合)、該エンジンは、それが最初の接続であるか否かを判定する(判定ブロック721)。ピアが、新規の接続が最初の接続であると認識している場合(判定ブロック721で「イエス」の場合)、エンジン244はそれ以前の接続を中止する(ブロック722)。最初の接続ではない場合(判定ブロック721で「ノー」の場合)、エンジン244は、シーケンスと接続IDとが対応しているかどうかを判定する(判定ブロック723)。対応していなければ(判定ブロック723で「ノー」の場合)、制御は判定ブロック720へ戻る。シーケンスと接続IDが対応していれば(判定ブロック723で「イエス」の場合)、エンジン244は複製フレームを破棄し(ブロック724)、図13Bのステップ680に戻る(ブロック725)。
【0175】
他の接続が無ければ(判定ブロック720で「ノー」の場合)、エンジン244は、接続に接続リソースを割り当て可能か否かを判定する(判定ブロック726)。割り当て可能でない場合、エラーが宣言され(判定ブロック726で「ノー」の場合、ブロック727)、接続が中止される(ブロック728)。接続リソースを割り当て可能な場合(判定ブロック726で「イエス」の場合)、エンジン244は「設定」状態を宣言し(ブロック726a)、接続についてのセキュリティコンテキストを取得する(ブロック730)。十分なセキュリティコンテキストの取得ができなかった場合(判定ブロック731で「ノー」の場合)、接続は中止される(ブロック728)。取得できた場合、エンジン244は確立フレームを送り(ブロック732)、接続が「確立」状態になったことを宣言する(ブロック732a)。続いて、エンジン244は再送部(retransmitter)を始動させ(ブロック733)、完了に向けて認証処理を待つ(ブロック734)。最後に、エンジン244は装置とユーザとが両方認証済みか否かを判定する(ブロック735)。装置とユーザのどちらかが認証されていない場合、接続は中止される(ブロック736)。それ以外の場合、エンジン244は監視中の(listening)アプリケーションへの接続を示唆し(ブロック737)、設定を取得する(ブロック738)。この2ステップのどちらかが成功しなかった場合、接続は中止される(判定ブロック739、ブロック740)。成功した場合、処理はスリープ状態に戻って作業を待つ(ブロック741)。
【0176】
(異常終了の例)
図15Aおよび15Bは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン244が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理(ブロック999)から受信すると(ブロック1000)、エンジン244は、接続が該要求と関係しているかどうかを判断する(判定ブロック1001)。関係していれば(判定ブロック1001で「イエス」の場合)、エンジン244は元の状態をセーブして(ブロック1002)、「中止」状態を宣言する(ブロック1002a)。次に、エンジン244は、接続がRPCエンジンに示唆されていたか否かを判定する(判定ブロック1003)。されていれば、エンジン244は切断イベントを示唆し(ブロック1004)、「ポスト・モーテム」状態を宣言して(ブロック1003a)、該接続に割り当てられていたリソースを解放し(ブロック1005)、元の状態が保留中の状態より大きいか否かを判定する(判定ブロック1006)。元の状態が保留中の状態より大きくなければ、(判定ブロック1006で「ノー」の場合)、処理は、呼び出しルーチンに戻るべく、ブロック1012に移る(ブロック1007)。元の状態が保留中の状態より大きい場合には、エンジン244は、上記要求が受信フレームと関係しているかどうかを判定する(判定ブロック1008)。中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合(判定ブロック1009)、受信フレームは呼び出しルーチンに戻る(ブロック1012)前に破棄される(ブロック1011)。
【0177】
(ローミング制御の例)
再度図1を参照すると、モバイルネットワーク108は、それぞれ別のネットワーク相互接続(107a〜107k、無線トランシーバ106a〜106kにそれぞれ対応)を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ102を含むネットワーク108は、モバイル端末システム104があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って(gracefully)扱うことができる。一般に、ネットワーク108のトポロジは、管理等の理由により、いくつかのセグメント(サブネット)に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク(伝送)アドレスが複数のモバイル端末システム104それぞれに割り当てられている。
【0178】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル(DHCP)を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のDHCPサーバは、一般的に、そのクライアントに(他のものの提供に加えて)有効なネットワークアドレスを「リース」する。DHCPクライアントは、永続的に割り当てられた、「固定符号化された(hard−coded)」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、DHCPクライアントはDHCPサーバにネットワークアドレスを要求する。DHCPサーバは、割り当てに使用可能なネットワークアドレスをプールしている。DHCPクライアントがネットワークアドレスを要求すると、DHCPサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間(リース期間)だけ、クライアントに所有される。リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、DHCPはネットマスク等の設定情報を、DHCPクライアントソフトウェアを動作させているクライアントに提供する。標準的なDHCPプロトコルについての詳しい情報は、RFC2131に記載されている。
【0179】
よって、DHCPを使用するモバイル端末システム104が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム104とモビリティ管理サーバ102とがDHCPの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム104の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【0180】
ある実施例では、モバイル端末システム104が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答(echo request−response)として、標準的なクライアント/サーバ型同報通信用のDHCP Discover/Offerメッセージのシーケンスが使用される。標準的なDHCPプロトコルに従って、ネットワークアドレスを要求するモバイル端末システム104が、DHCP Discoverメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、DHCPサーバはOffer応答を同報通信する(要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる)。よって、当該サブネット上の全てのモバイル端末システム104は、DHCP Offerサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【0181】
本実施例では、DHCP同報通信メッセージをモニターするDHCPリスナが設けられており、モバイル端末システム104が、あるサブネットから別のサブネットへローミングしているか、およびDHCPによって新規のネットワークアドレスが取得できるようになっているかが確認される。図16は、DHCPリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造902は、以下の要素を有していてもよい。
【0182】
・サーバデータ構造の連結リスト、
・整数トランザクションID番号(xid)、
・カウンタ(「ping」)、および
・タイムアウト値
サーバデータ構造904は、それぞれ別のDHCPサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
【0183】
・次のサーバへのポインタ、
・サーバID(DHCPサーバのネットワークアドレス)、
・最近該DHCPサーバと結合したBOOTPリレーエージェントのアドレス(giaddr)、
・「ping」値(socket−>ping)、および
・フラグ
これらのデータ構造は、ネットワーク108上のDHCP同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
【0184】
・roamCreate() (変数を初期化)
・roamDeinitialize() (全てのリスナを消去)
・roamSrartIndications() (モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆(registrant roaming indications)のために、供給されたコールバックルーチンを呼び出す)
・roamStopIndications() (適当なコールバックをリストから除去して登録ローミング示唆を停止)
・インターフェイス変更(インターフェイスがネットワークアドレスを変更したことを示す、OSからのコールバック通知)
・リスナ信号(ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック)
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【0185】
本好ましい実施形態では、全てのモバイル端末システム104が、DHCP Discover要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのDiscover要求と、他のネットワーク装置からのDiscover要求とを、区別することができるようになる。DHCPサーバも同様に応答を同報通信するので、どのモバイル端末システム104および/またはモビリティ管理サーバ102も、DHCPサーバからどのモバイル端末システムに出されたOffer応答でも受け取ることができる。複数のDHCPサーバが単一のDHCP Discover要求に応答できるため、図16のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【0186】
所定のクライアントハードウェアアドレスおよびクライアント識別子を有するDiscover要求の受信に際し、本好ましい実施形態では、該要求がモバイル端末システム104から送られてきたものとして認識される。該メッセージが0に設定されたBOOTPリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。リスナは、最近モバイル端末システム104から送られたDiscoverメッセージのトランザクションID(xid)と対応したトランザクションID(xid)が含まれていない限り、DHCP Offer応答を無視してもよい。該リスナは、新規のBOOTPリレーエージェントIDおよび/または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム104がローミングしたと判定する。リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図16のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される(これについては設定によって変更可能である)。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される(この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる)。
【0187】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本好ましい実施形態では、新規のBOOTPリレーエージェントID(または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス)を持つ、既知のサーバから応答があれば、モバイル端末システム104がローミングしたと判定する。リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム104は圏外にある可能性があるので、モビリティ管理サーバ102は該システムが圏内に戻るのを待つ。
【0188】
図17は、本好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、DHCPリスナ処理は、適切なメモリをハンドルに割り当て、NALソケットをDHCPクライアントおよびサーバUDPポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され(ブロック802)、上記処理は「待機」状態に入ってローミング関連のイベントを待つ(ブロック804)。イベントは、以下の3種の外部入力によって引き起こされる。
【0189】
・DHCPサーバパケットを受信する
・他のモバイル端末システムからのDHCPクライアントパケットを受信する ・タイマーの期限が切れる
DHCPサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントIDと一致するか否かを判定するために調べられる(判定ブロック806)。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントIDを含んでいる場合、該パケットがDHCP Offerパケットであるか否かが判定される(判定ブロック808)。該Offerパケットは、最近送られたDHCP Discoverシーケンスに対応したトランザクションIDを含んでいない限り、拒絶される。
【0190】
パケットトランザクションIDが対応していれば(ブロック810)、DHCP Offerパケットを送信したサーバが既知であるか否か(つまり、サーバIDが図16のリスナのデータ構造に含まれているか否か)が判定される(ブロック812)。サーバIDがリストに無い場合(判定ブロック812で「ノー」の場合)、サーバIDがリストに加えられ、「新規」とマークされる(あるいは、リストの最初のサーバであれば、「最初」とマークされる)(ブロック822)。サーバが既にリストにある場合(判定ブロック812で「イエス」の場合)、さらに、パケットBOOTPリレーアドレス(「GIADDR」)がサーバアドレス(「GIADDR」)に対応しているか否かが判定される(判定ブロック814)。対応していなければ、Offerパケットは他のサブネットからのものということになるので、「ハードローミング(hard roam)」が実行されたと判定される(ブロック816)。呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック814でBOOTPリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のping番号をサーバに記憶するというリスナ処理が行われる(ブロック818、820)。続いて、処理は「待機」期間に戻る。
【0191】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントIDを有しているか、DHCP Discoverパケットか、および0のパケットBOOTPリレーアドレス(GIADDR)を有しているかどうかが判定される(ブロック824、826、828)。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたDHCP Discoverメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションIDが、後に受信されるDHCP Offerパケットの比較に用いられる、ピアのトランザクションIDに設定され(ブロック830)、「ping確認」が呼び出され(ブロック834)、タイマーがリセットされる(ブロック836)。
【0192】
タイマーの期限切れにより、処理は「ping確認」を呼び出す(ブロック838)。本好ましい実施形態における「ping」は、ランダムな新規のxidを有するDHCP Discoverパケットである。このping確認838のステップが、図17Aに例示されている。ping確認ルーチンの目的は、「ソフトローミング(soft roam)」状態(つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態)が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
【0193】
・モバイル端末システムが、あるサブネットから別のものにローミングしたか?
・モバイル端末システムは圏外にあるか?
・DHCPサーバは不在か?
これらの状態は、モバイル端末システムの、前「ping」応答と現「ping」応答とを比較することによって判定される(判定ブロック846、850)。例えば、現ping数から旧サーバの前ping応答を引いた数が、サブネットのサーバのpingよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される(あるいはいずれも示唆されない)。
【0194】
図18は、モバイル端末システム104のローミング制御センター(roaming control center)が実行するステップを例示したフローチャートである。モバイル端末システム104でのローミングを可能にするため、既知のアドレスのリストが0に初期化され(ブロック850)、OSインターフェイス変更通知がイネーブルになり(ブロック852)、次に、OSを呼び出して、DHCPを利用する現在のアドレスのリストを所得する(ブロック854)。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ(ブロック856)、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される(ブロック858)。次に、登録主体に「ローミング」を示唆する(ブロック860)。
【0195】
図17のリスナ処理から信号が送られると(ブロック862)、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される(判定ブロック864、870、874)。ローミング信号(判定ブロック864で「イエス」)により、対応するリスナ866が閉じられ、OSがコールされて、ネットワークアドレスのDHCPリースが解放、更新される(ブロック868)。リスナ信号が「圏外」の場合(判定ブロック870)、該状態が登録主体に示唆される(ブロック872)。該信号が「圏内復帰」の場合(判定ブロック874)、該状態は全ての登録主体に示唆される(ブロック876)。無効のローミング命令を受信すると(ブロック878)、全てのリスナが閉じられ(ブロック880)、OSインターフェイス変更通知が無効になる(ブロック882)。
【0196】
(インターフェイスによって補助されたローミングのリスナの例)
さらに、インターフェイスベースのリスナによって、同じネットワークおよび別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の(複数の)インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【0197】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの(例えば低レベルのインターフェイス・ローミング・ドライバを経由した)情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。図19Aと19Bは、モバイルノードの移動パス(migration path)を効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、(例えば、冗長パスを使った自己回復インフラ構築のために)様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【0198】
図19Aを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に(図19A、ブロック2000)、低レベルのインターフェイス・ローミング・ドライバは、図18のローミング制御センターモジュールに登録を実行する(ブロック2010)。このような登録(例示の実施形態では、crRegisterCardHandler()機能を通じて実現される)により、下記のエントリポイントが与えられる。
【0199】
・開
・閉
・状態(status)取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース(等)のポーリングを使わなければならない場合は、ブール演算を偽とする
実施例のcrRegisterCardHandler()機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆/問合せ(signaling/querying)媒体接続性およびネットワーク接続ポイントの変更に関するOS包括メカニズム(O/S generic mechanism)を使用するインターフェイスに、インストールされてもよい。
【0200】
本実施例では、インターフェイスの状態がイネーブルになると(つまりネットワークへのアクセスが可能になると)(ブロック2020)、ローミング制御センターは、インターフェイス補助ローミング(interface assisted roaming; IAR)を、以下のステップに基づいて試みる(ただし、以下のステップは、OSの設計および/または特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある)。
【0201】
1.包括ハンドラ(generic handler)がインストールされている場合、包括crOpenInstance()ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態およびネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する(ブロック2030)。インターフェイスドライバが該機能を包括的にサポートできない場合(判定ブロック2030で「ノー」の場合)、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【0202】
2.包括ハンドラがエラー(判定ブロック2030で「ノー」)を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される(ブロック2040)。該インターフェイスが、crRegisterCardHandler()フェイズ中に登録されたトークンのうちの一つと一致する場合(ブロック2050)、ローミング制御センターは、アダプタのインスタンスへの特定のcrOpenInstance()をコールする。この機能は、低レベルドライバを開き、状態(媒体接続性、ネットワーク接続ポイントID)を再度ポーリングし、定期ポーリングタイマーを(可能ならば)設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【0203】
3.ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、IAR機能を使用せずに、図17および17Aのビーコンリスナ(beaconing listener)、モバイルIP、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される(判定ブロック2050で「ノー」の場合、ブロック2060)。これ以外の場合、インターフェイス補助ローミングがイネーブルになり(ブロック2060)、ローミング制御センターは下記のアルゴリズムに従う。
【0204】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する(ブロック2060)。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ(ブロック2100)。該イベントは、例えば以下のものを有している。
【0205】
・低レベルローミングドライバからのコールバック、
・ポーリング間隔(timed poll interval)(ブロック2070、2090)、あるいは
・ネットワーク・レベルの活動(つまり、伝送/受信にかかわる問題)からの示唆
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと(図19Bの判定ブロック2110もしくは2120で「イエス」の場合)、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【0206】
1.状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し(ブロック2120で「イエス」)、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ROAM_SIGNAL_OUT_OF_CONTACT状態を示唆する(ブロック2140)。
【0207】
2.上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し(ブロック2120で「ノー」の後、ブロック2150で「ノー」の場合)、ROAM_SIGNAL_OUT_OF_CONTACTが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。この場合、ローミング制御センターは、適切なアクセスのために登録または取得された全てのネットワークアドレスを再確認し(ブロック2170)、ROAM_SIGNAL_ROAM_SAME_SUBNETを出して(ブロック2180)、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【0208】
3.上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合(ブロック2150で「イエス」の場合)、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。該データストアは、通常動的にポピュレートされている(学習している)が、パフォーマンス向上のため、該データストアに静的な情報(既に学習された情報)が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【0209】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【0210】
a)データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される(ブロック2190)。対応が見つかれば(ブロック2200で「イエス」)、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ROAM_SIGNAL_ROAM_SAME_SUBNETを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【0211】
b)検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する(ブロック2220)。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを(再)取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、(例えばDHCPを通じて)ネットワークでアドレスを取得することは、(モバイルIPの外部エージェントを通じて)ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを(再)取得(例えばDHCPサーバからのリースを確立/アップデートして)するか、あるいは現アドレスを外部エージェント(モバイルIP)に登録する。
【0212】
・別のサブネットへのローミングを示唆する、ROAM_SIGNAL_ローミング信号を、該ローミング制御センターのクライアント向けに生成する(ブロック2230)。
【0213】
c)検索の結果対応が見つからなければ(ブロック2200で「ノー」)、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する(ブロック2210)。次に、ローミング制御センターはブロック2220および2230を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【0214】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、(ユーザおよび/またはシステムによって定義された)付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス(ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択)を選ぶことができる。これは、帯域幅、(1バイトあたりの)コスト、および/またはサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。例えば、他の利用可能なヒューリスティクス(媒体接続性、信号強度、再伝送率等)による、「メークビフォアブレーク(make before brake)」ハンドオフ構造が提供可能で、よってローミングノードからの/に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【0215】
図20は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図20のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「NPOA」は、例えば、アクセスポイントのMACアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「NPOA」は、介入的なネットワーク相互接続(ゲートウェイ、IWF等)の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報(例えばMTUのサイズ、待ち時間、コスト、利用可能かどうかなど)とが結合していてもよい。
【0216】
(特定の競合状態を扱う他の実施例)
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と(再)接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、従って、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に1度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークIDがいつ有効になるかを判定するのは困難である。
【0217】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。従って、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求/応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやpingフレームは1つのピア(ローミング中のノードである可能性が高い)によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでNPOA情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【0218】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるROAM_SIGNAL_ROUTE_CHANGEが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【0219】
(非接続ネットワークを通じたローミング例)
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」(disjoint networking)モードでMMS(モビリティ管理サーバ)にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、MMSとの通信を確立する/持続するのに使われる、代替のネットワークアドレスを動的/静的に見つけ出すことができるようになる。
【0220】
一般に、アルゴリズムによって、通信中にMES(モバイル端末システム)に送るための、MMSが利用可能な代替アドレスのリストが可能となる。このように、MMSはMESに、一つ以上のMMSネットワークアドレスもしくは他のネットワークに対応した他のMMSのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【0221】
MESが別のネットワークへと移動するとき、MESは新規のネットワークの接続ポイントからMMSとコンタクトをとるために、MMSの「エイリアス」(alias)アドレス/アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、MESは新規のネットワーク接続を通じてMMSとのコンタクトを再確立することができる。
【0222】
この新しい技術を簡略化したフローチャートを図21に示す。MMS102は、2つの異なる非接続ネットワーク、すなわちネットワーク・セグメントN1及びN2と接続しているものとする。MES104は、最初にMMS102とネットワークN1を介して接続されるものとする。ネットワークN1を介してMES104とMMS102との間で接続が確立されるとすぐに、MMS102は、MES104に対して、MMSが一以上の他のネットワーク(例えば、ネットワークN2)から求められるネットワークアドレスのリストL又は他の識別子を送ることができる。MES104は、該リストLを受け取り、記憶する。その後、MES104は別のネットワーク(N2)に移動する時、MES104はこの記憶されたリストLにアクセスし、それを用いて新規のネットワーク(N2)を通じたMMS102との通信を効果的に再確立することが可能となる。
【0223】
この新しいアルゴリズムには、非接続ネットワークを通じて、MMS102と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。例えば、図21に示すアルゴリズムを用いて、多くのネットワーク(いくつか、又は全てが無線ネットワーク)からの安全なファイアウォール/ゲートウェイ、及びコーポレートバックボーンとしてMMS102が使用される安全なネットワークをセットアップでき、モバイルノード104が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。例えば、MMS102がハブとして1つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、MMS102(この例ではルータとして動作可能)を介した場合を除いて、1つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【0224】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、MMS102との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報/経路(つまり、デフォルトルート等)をルーティングが必要となる。
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。MES104からフレームが送られる時、クライアント及び及び中間ノード(ルータ)におけるIPネットワーク(層3)のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地(MMS102)にパケットを正確に送る。このことは、一般にIP送信(IP forwarding)、あるいはIPルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム(ブロードキャスト等)が別のネットワーク・セグメントへ流れる。IP送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【0225】
図21に示す代替アドレスリストは、ルーティング情報のうちの幾つかをMES104に送出する、又は配布する効果を有する。従って、各セグメントは、MMS102とつながっている他のセグメントの情報はない状態で離散された状態となる。MES104はMMS102によって認証可能であるため、MMSは認証されたMESユニット104にのみリストLを送る。MES104が別のネットワーク・セグメントへ移動する時、MES104は自動的に正しいアドレスを選択し、それを用いて途中MMSとの通信を開始/継続することができる。従って、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【0226】
例えば、このようにユーザレベルのセキュリティ/暗号化と組み合わせてMMS102を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【0227】
例を図22に示す。図22において、MMS102は通信網やルート情報を共有しない4つの別々に分かれたネットワーク(Ia、Ib、Ic、Id)と接続されている。どの点から見ても各ネットワークIは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ(例えば、Ic)とドッキングしているMES104を想定する。例えば、MES104は192.168.x.xネットワーク上のアドレスを取得してMMS102と通信するものとする。
【0228】
ある理由によりMESが10.1.x.x(Ia)ネットワークに渡る、又は移動する必要があるものとする。10.1.x.x(Ia)ネットワークは192.168.x.x(Ib)ネットワークのことを知らない(つまり、(Ib)ネットワークへのルートがない)ため、MES104がその領域へ移動する時に、たとえMMSが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード104が図示される他の10.xネットワークのいずれかと接続する場合においても同じことが起こる。
【0229】
図21に示すアルゴリズムを用いて、接続開始時間の(あるいは他の方法で)MMS102は各種非接続ネットワークIa、Ib、Ic、Idに関するそのインターフェイスアドレスをMES104と共有し、MESはこれらを記録する。一旦記録されると、MES104は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、MESは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでMMSと通信できる。2以上のアドレスが使用される場合、MES104は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図21と同様のリストを受け取らなかったMES104は、その「ホーム」ネットワーク以外のネットワークを通じてMMSと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【0230】
他に、図21の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ(Network Address Translators;NATs)として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス/ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス/ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはNATにおいても静的に定義される。
【0231】
誰かがLAN/WLANの内部でMMS102を使用するために、それをNATに置くことを想定する。現在、MMS102がNATでない限り、あるいは異なるプロキシを用いてMMSと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、MMSと通信するアドレスがもはやアクセス可能ではないため、MMSとはアクセス可能ではない。図21のアルゴリズムを用いれば、MMSと直接接続されていない別のインターフェイスアドレスを静的/動的に明確にすることができる。従って、上記のアルゴリズムを使用すれば、MES104は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【0232】
この概要を図23に示す。ノードがインターフェイス“d”からインターフェイス“g”へ渡るとする。MMS102にローカルインターフェイスを供給するだけではアクセスはできない。MES104は分散されたインターフェイスの優先順位を知る必要がある。それからMES104は必要なアドレスを選択してインターフェイス“g”上で使用する。その後、NAT2000は、各パケットに関するネットワークアドレス/ポート情報を、内部インターフェイス“c”アドレスへ適切に変換する。MMS102からMES104に送られるフレームには逆の処理が行われる。
【0233】
(ポリシー管理及びロケーションベースのサービス例)
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のMMSはMESが確立する各アプリケーションのセッションと深く関わっているため、どちらの側(すなわち、MMSおよび/またはMES)もポリシーベースのルールを適用してMESとその最終的なピアとの間の通信を適合して制御することができる。さらに、MMSおよび/またはMESはデバイスのロケール、又は近接性(proximity)、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、MMSおよび/またはMESは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。MMSはさらにMESにこのようなルールの幾つか、全くなし、あるいは一部、および/または処理を配分して、メータリング(metering)、又は傍受者によるモバイルデバイスへの侵入(rogue attacks)に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、MMSが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【0234】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、および/またはネットワークの接続ポイントに基づき構成可能である。一旦定義されると(学習されると)、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、および/またはサービスを管理し、制御する。
【0235】
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
【0236】
・モバイルデバイスについての近接性、場所、高度、および/または他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作(例えば、帯域幅条件)
・現在のネットワーク状態
・他の静的又は動的要素
さらに分散型アーキテクチャを利用することで、MMSは同じ決定セットを適用又は共有することができる。ポリシー管理処理および/または意思決定をMMSに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【0237】
サンプルMESの制御に使用される可能性のあるメトリクス(ルール)の幾つかを示すテーブルの例を図24に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ(例えば、ウィザード)や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、または割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【0238】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図24に示す。
【0239】
・MESの通信機能(送信のみ、受信のみ、送受信)
・MESの要求がプロキシされるか否か
・MESのソースポート
・MESのソースアドレス
・MESの目的地ポート
・MESの目的地アドレス
・MESのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション(例えば、GPS座標又は他のロケーション情報)
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム(例えば、ワイルドカード)であることが可能である。
【0240】
図24のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図24のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で100,000バイト以下に低減される場合、目的地ポート20、21との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール(列)3、4によってネットワークトラフィックのみがMMSへ、又はMMSから流れることが可能となる(プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。)。
【0241】
一例において、各RPC要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにMMSおよび/またはMESによって行われる処理のフローチャート例を図25に示す。
【0242】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、MMSはモバイル端末システムがいつ1箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【0243】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとPRCエンジンの両方の改良点について概要を説明する。新しいRPCのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【0244】
(ロケーション変更RPC(Location Change RPC)の例)
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更RPC要求(Location Change RPC Request)」メッセージをそのピア、この場合モビリティ管理サーバに送る。「ロケーション変更RPC」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはASCIIの48ビットIEEE MAC アドレス、IPV4 アドレス、IPV6 アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。「ロケーション変更RPC要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、PID等の他の関連情報を含む「ロケーション変更警告(Location Change Alert)」を作成する。この警告は「ロケーション変更RPC要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はMMSの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、および/またはポリシー変更が含まれる。
【0245】
ロケーション変更RPCはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【0246】
ある例では、MESは自身が移動したことを知らない場合がある。MESが接続する媒体やネットワーク・アダプタに応じて、MMSはMESが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、MMSはMESのアドレスを新しく管理することを認識する。したがって、動作の検出を完了するためには、行動検出するためのMESとMMSの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいIMPメッセージが受け取られる時に、MMSはIMP層でクライアントの行動を検出する。このことが行われると、MMSは局所的にロケーション変更警告を生成する。また、MMSは接続ポイントが変更したというメッセージをMESに送る。
【0247】
(トポロジRPCの例)
「トポロジRPC要求(Topology RPC Request)」はモビリティ管理サーバからモバイル端末システムへ送られる。このRPCの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジRPC応答(Topology RPC Response)を作成する。トポロジRPC応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド(Total Length Field)、タイプ、長さ情報が後に続く接続ポイント識別子、および、サブネットおよびネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【0248】
(ロケーション情報UIの例)
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が48ビットのIEEE MACアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのMACアドレスが表示される。接続ポイントが「ホールマークカード(HallMark Cards)」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【0249】
(ロケーションRPCタイマーの例)
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更RPCがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更RPCを生成する。
【0250】
(距離変更通知の例)
距離メトリクスは、ロケーション変更RPCの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、nフィート、nキロメータ毎、あるいは他の適当な測定単位で3次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【0251】
(速度閾値通知の例)
速度変更メトリクスは、ロケーション変更RPCの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔(すなわち、10分間で0MPH、又は1分間で70MPH)を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【0252】
[応用例]
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【0253】
(断続的に接続される携帯用コンピュータ)
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット(Ethernet)等のローカルエリア・ネットワーク(Local area network)に接続する。LAN接続によってネットワークサービス(例えば、プリンタ、ネットワークドライブ)やネットワーク・アプリケーション(例えば、データベースアクセス、電子データサービス)にアクセスが可能となる。
【0254】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【0255】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、および/またはインターネットを通じてオフィスLANと再接続する。(ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した)モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【0256】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【0257】
(モバイル在庫管理及び倉庫への応用)
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物(すなわち、トラックやフォークリフト)を使って商品の在庫管理が行われる。
【0258】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム104の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ102の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【0259】
(モバイル医療への応用)
無線LAN技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブ(World Wide Web)を通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム104への連続的な接続が可能なので、病院にいる間(一方向又は双方向の)ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム104を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム104によって医療関係者は無線送信が望ましくないとされるエリア内(例えば、電波の放射によって医療機器に障害が出る可能性のある場所)での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【0260】
(トラック輸送及び貨物輸送)
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム104はLAN技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム104はCDPDやARDIS等のWide Area WANサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム104はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
モバイル企業
企業の社員は、802.11.等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制(pay−per−use)」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【0261】
(IPマルチプリケーション)
ある組織がインターネットに接続する必要のあるLANを有する場合、LANの管理者には二つの選択肢がある。一つ目の選択は、LAN上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ102を使用することである。多数のIPアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ(Internet Service Privider; ISP)を利用してインターネットにアクセスする小規模の企業は、ISPが割り当てるIPアドレスだけを使用することになる。IPアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ISPは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【0262】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ102を用いれば、これらの問題の多くを解決することができる。企業は、ISPを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ102を用いることができる。これにより、モバイル端末システム104は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ102を通じて行われるため、一つのアドレスだけをISPから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数(多くの場合一つ)のアドレスとアカウントをISPから取得すればよくなり、全体のLANでインターネットへの同時接続(十分な帯域幅が備えられていることを前提として)が可能になる。
【0263】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【図1】
本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図2】
モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図2A】
モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図3】
モバイル・インターセプタ・アーキテクチャを例示している。
【図3A】
モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図3B】
RPC作業要求を扱うRPCエンジン(RPC engine)によって実行されるステップを例示したフローチャートである。
【図4】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5A】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5B】
RPC作業要求を処理するステップを例示したフローチャートである。
【図5C】
RPC作業要求を処理するステップを例示したフローチャートである。
【図6】
受信された作業要求を例示している。
【図7】
受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図8】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図9】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図10A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図10B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図10C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図11】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図12C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図13C】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図14A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図14B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図15A】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図15B】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図16】
リスナのデータ構造を例示している。
【図17】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図17A】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図18】
モバイル相互接続ローミング(mobile interconnect roaming)を提供するためのステップを例示している。
【図19A】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図19B】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図20】
インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図21】
モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図22】
図21の技術を、セキュアな通信を実現するために利用した例を示している。
【図23】
図21の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図24】
ポリシー管理テーブルを例示している。
【図25】
ポリシー管理処理のステップを例示したフローチャートである。
Claims (125)
- ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークであって、モバイルコンピュータ装置のロケーションを含む様々なメトリクスに基づくポリシー管理ルールを適用するポリシー管理手法を特徴とするモバイル・コンピューティング・ネットワーク。
- 前記ルールの属性についての処理は、モバイルコンピュータ装置あるいはモビリティ管理サーバのいずれか、またはその両方に対して分配され適用されることを特徴とする請求項1記載のネットワーク。
- 前記ルールの優先順位は、そのようなテーブルの項目における位置で暗示されるか、あるいは期待動作を確実にするための順序が明白に記されることを特徴とする請求項1または2記載のネットワーク。
- 前記ルールの属性のデータ保存は、中央管理サービスを介して局所的または集中的に管理されることを特徴とする請求項1、2または3記載のネットワーク。
- 特定のアプリケーションの動作は、サービス費用、ネットワーク接続ポイント、信頼関係等を含む多数のメトリクスに基づいて修正されることを特徴とする請求項1〜4のいずれか1項に記載のネットワーク。
- 動作修正の結果、前記ルールの属性に基づいて要求が許可、拒否、または遅延されることを特徴とする請求項1〜5のいずれか1項に記載のネットワーク。
- アプリケーションが既に開始されている場合でも、アプリケーションプロセスを修正するため、1つのルール、または一連のルールが呼び出されることを特徴とする請求項1〜6のいずれか1項に記載のネットワーク。
- 現在位置情報(ロケーション)は、アプリケーション動作を管理するため、あるいはモバイルコンピュータ装置の関連情報を提供するためにも使用されることを特徴とする請求項1〜7のいずれか1項に記載のネットワーク。
- 距離測定に伴う動作速度は、アプリケーションの動作または通信パスを変更するために使用されることを特徴とする請求項1〜8のいずれか1項に記載のネットワーク。
- ロケーション情報の結果としてトポロジ情報が抽出され、表示されることを特徴とする請求項1〜9のいずれか1項に記載のネットワーク。
- ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークにおいて、ネットワーク接続ポイントの識別子の少なくとも一部分に基づき、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したかどうか検出するインターフェイス補助ローミングリスナを備えることを特徴とするモバイル・コンピューティング・ネットワーク。
- 前記モバイルコンピュータ装置はネットワーク・インターフェイス・アダプタを含み、前記インターフェイス補助ローミングリスナは前記ネットワーク・インターフェイス・アダプタから前記ネットワーク接続ポイントの識別子を取得することを特徴とする請求項11記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、前記ネットワーク接続ポイントの識別子をネットワーク接続についての詳細情報に相関させる情報を記憶するネットワーク・トポロジ・マップを保持することを特徴とする請求項11記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、前記ネットワークとの通信がいつ中断または再確立されるかを検出することを特徴とする請求項11記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、(a)ネットワーク通信の中断及び再確立、及び(b)前記ネットワーク接続ポイントの識別子の変化の検出を受けて、ローミング信号を生成することを特徴とする請求項14記載のネットワーク。
- モバイルコンピュータ装置において使用されるインターフェイスベースのリスナであって、インターフェイスベースのリスナは少なくとも1つのネットワーク・インターフェイス・アダプタからの情報と、少なくとも1つのネットワークスタックから入手可能な情報を統合して、前記モバイルコンピュータ装置が新しいネットワーク接続ポイントに移動したかどうか判定することを特徴とする、インターフェイスベースのリスナ。
- ネットワーク接続ポイント情報を含むネットワーク接続情報を提供するネットワーク・トポロジ・マップを含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- 上記リスナは学習情報に基づき前記ネットワーク・トポロジ・マップを動的に構成することを特徴とする請求項17記載のリスナ。
- イベント発生に基づき、ステータスをチェックするステータスチェッカーを含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- 前記イベントはタイマーのタイムアウト、ローレベルのローミング・ドライバ・コールバック、ネットワーク・レベル・アクティビティ・ヒントのいずれかを含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- モバイルコンピュータ装置が既に現在のネットワーク接続ポイントを訪れたかどうかインターフェイスに照会する接続情報探索部を含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- 新規のネットワーク・セグメントにおいて有効となる現行のアドレスを登録または再取得する接続構成を含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- インターフェイスから提供された情報の少なくとも一部分に基づいて、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したことの検出を受けてローミング信号を生成するローミング信号発生部を含むことを特徴とする請求項16記載のインターフェイスベースのリスナ。
- 予め割り当てられたアドレスがまだ有効かどうかを判定するヒューリスティック・アナライザをさらに含むことを特徴とする請求項23記載のインターフェイスベースのリスナ。
- モバイルノードが新しいネットワーク接続ポイントに移動したかどうか判定する方法であって、
(a)ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
(b)前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
(c)前記ステップ(b)を受けて信号を生成するステップとを含むことを特徴とする方法。 - 請求項25記載の方法であって、
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ(c)を行うステップをさらに含むことを特徴とする方法。 - 請求項25記載の方法であって、
前記ステップ(c)はローミング信号を生成するステップを含むことを特徴とする方法。 - 請求項25記載の方法であって、
前記ステップ(b)はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。 - 請求項25記載の方法であって、
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出メカニズムにフォールバックするステップをさらに含むことを特徴とする方法。 - 請求項25記載の方法であって、
前記ネットワーク接続ポイント情報の少なくとも一部に応じて、代わりになるネットワーク接続パスの中から選択するステップをさらに含むことを特徴とする方法。 - 非接続のネットワークを介したモバイルシステムとの通信を円滑にするための方法であって、
第1ネットワークを介してノードと前記モバイルシステム間の通信を確立するステップと、
前記第1ネットワークと非接続の少なくとも第2ネットワーク上の前記ノードを識別するデータを、前記第1ネットワークを介して前記モバイルシステムに送信するステップと、
前記第2ネットワークを介して前記モバイルシステムと前記ノードとの通信を確立するために前記データを使用するステップとを含むことを特徴とする方法。 - 請求項31記載の方法であって、
前記第1ネットワークを介して前記ノードに前記データを送信する前に、前記第2ネットワークを介して前記ノードとの通信許可を付与するために前記モバイルシステムを認証するステップをさらに含むことを特徴とする請求項31記載の方法。 - 請求項21記載の方法であって、
前記送信ステップは、分配されるインターフェイスデータを前記第1ネットワークを介して前記モバイルシステムに送信するステップを含むことを特徴とする方法。 - 前記モバイルコンピュータ装置のネットワーク・インターフェイス・アダプタは、前記ネットワークと物理的に接続されていることを特徴とする請求項12記載のネットワーク。
- 前記モバイルコンピュータ装置はネットワーク接続ポイントと無線で通信することを特徴とする請求項12記載のネットワーク。
- モバイルコンピュータシステムが複数の別個のネットワーク間を移動する際、モバイルコンピュータシステムとネットワークノードとの間での通信を維持するための方法であって、
第1ネットワークセグメントを介してモバイルシステムとノード間の通信を確立するステップと、
第1ネットワークセグメントを介して、それぞれ第1ネットワークセグメントとは別個の複数のさらなるネットワーク・セグメントを介して前記ノードとの通信を再確立する際に使用される情報をモバイルコンピュータシステムに送信するステップと、
前記情報を使用して、前記別個の複数のさらなるネットワーク・セグメントのいずれかを介してモバイルコンピュータシステムとノード間の通信を再確立するステップとを含むことを特徴とする方法。 - 請求項36記載の方法であって、
前記情報は分配されるインターフェイスデータを含むことを特徴とする方法。 - 複数の別個のセグメントを有するネットワークにおいて最少コストルーティングを提供するための方法において、
(a)ネットワークと、一時的に接続されたモバイルコンピュータ装置との間の通信を確立するステップと、
(b)一時的に接続されたモバイルコンピュータ装置が前記複数の別個のセグメント間を移動することができるローミング機構を使用するステップと、
(c)モバイル・コンピューティングのローミングに応じて、ネットワークとモバイルコンピュータ装置との間の通信を再確立するための選択的で有効なネットワークパスを効率的に自動選択可能にするように、少なくとも1つのポリシーパラメータに実行させるステップとを含むことを特徴とする方法。 - 請求項38記載の方法であって、
前記ポリシーパラメータは、帯域幅、1データ単位当りのコスト、およびサービス品質からなるグループの中から選択された要素を含むことを特徴とする方法。 - 少なくとも1つのピア・コンピュータシステムと、物理的リンクを介してネットワークに接続された少なくとも一つのモバイルコンピュータ装置とを含むモバイル・コンピューティング・ネットワークにおいて、
ネットワークに接続されたサーバを含み、前記サーバは、モバイルコンピュータ装置への物理的リンクが一時的に中断される間に、モバイルコンピュータ装置とピア・コンピュータシステムとの間の継続的な仮想データストリーム接続を維持するために、モバイルコンピュータ装置とピア・コンピュータシステムとの間の通信をプロキシすることを特徴とするモバイル・コンピューティング・ネットワーク。 - 前記モバイルコンピュータ装置は前記ネットワーク上の位置アドレスを有し、前記ピア・コンピュータシステムは仮想アドレスを使用して前記サーバと通信し、前記サーバは前記仮想アドレスを前記位置アドレスと対応付けることを特徴とする請求項40記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置がその位置アドレスをいつ変更したかを検出し、前記仮想アドレスを前記変更された位置アドレスと再び対応付けることを特徴とする請求項41記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置が一時的に圏外に出たり、またはローミング中である時に、前記モバイルコンピュータ装置に代わって、キューに入れ、前記ピア・コンピュータシステムからの要求に応答することを特徴とする請求項40記載のネットワーク。
- 前記サーバは、従来のトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項40記載のネットワーク。
- 前記サーバは、遠隔プロシージャ・コールを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項44記載のネットワーク。
- 前記サーバは、インターネット・モビリティ・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項44記載のネットワーク。
- 前記インターネット・モビリティ・プロトコルは、ユーザ設定可能なタイムアウトに基づいてデータグラムの自動除去を行うことを特徴とする請求項46記載のネットワーク。
- 前記インターネット・モビリティ・プロトコルは、ユーザ設定可能な再試行に基づいてデータグラムの自動除去を行うことを特徴とする請求項46記載のネットワーク。
- 前記サーバは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費に関するユーザ毎のポリシー管理を行うことを特徴とする請求項40記載のネットワーク。
- 前記サーバは、ユーザ設定可能なセッション優先順位を、前記モバイルコンピュータ装置の前記セッションに付与することを特徴とする請求項40記載のネットワーク。
- 前記モバイルネットワークは複数のサブネットワークを含み、前記モバイルコンピュータ装置は、前記モバイルコンピュータ装置によって前記複数のサブネットワークのうちの1つから前記複数のサブネットワークの別の1つへのローミングを可能にする他の手順と共に動的ホスト構成プロトコルを用いることを特徴とする請求項40記載のネットワーク。
- 前記サーバは、モビリティ管理サーバを含むことを特徴とする請求項40記載のネットワーク。
- 前記モバイルコンピュータ装置と前記サーバとを接続する少なくとも1つのモバイル相互接続をさらに含むことを特徴とする請求項40記載のネットワーク。
- モバイルコンピュータ環境において少なくとも一つのモバイルコンピュータ装置との持続的な接続を維持する方法であって、
前記モバイルコンピュータ装置と、少なくとも一つのさらなるコンピュータ装置との間の少なくとも1つのセッションを管理するステップと、
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時に、セッションを維持するステップとを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記セッションのために少なくとも1つのユーザ設定可能なセッション優先順位を付与するステップをさらに含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理するステップを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記モバイルコンピュータ環境は複数のサブネットワークを含み、前記維持ステップでは、動的ホスト構成プロトコルを使用して前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時にセッションを維持することを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置とデータグラムのやり取りを行い、少なくとも1つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする方法。 - 請求項58記載の方法であって、
前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする方法。 - 請求項58記載の方法であって、
前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記モバイルコンピュータ装置に可変の位置アドレスを付与するステップをさらに含み、前記管理ステップはセッションと関連付けされる仮想アドレスに前記位置アドレスを対応付けするステップを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、遠隔プロシージャ・コール・プロトコルを用いてモバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記維持ステップは、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する物理的リンクの中断時に前記セッションの接続状態を維持することを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、少なくとも1つの標準的なトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記管理ステップは、前記複数のアプリケーションソースからのデータをストリームに融合するステップと、前記ストリームを送信するステップとを含むことを特徴とする方法。 - 請求項65記載の方法であって、
前記ストリームから融合されたデータを逆多重化して、前記逆多重化されたデータを複数の関連する目的地に送信するステップをさらに含むことを特徴とする方法。 - 請求項65記載の方法であって、
前記ストリームはフレームを含み、前記融合処理は、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行う処理を含むことを特徴とする方法。 - 請求項65記載の方法であって、
前記融合処理は、信頼性の低いデータのセマンティクスを維持する処理と、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄する処理とを含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置へのメッセージの保証配信、および/または前記モバイルコンピュータ装置からのメッセージの保証配信を行う処理を含むことを特徴とする方法。 - 請求項54記載の方法であって、
前記管理ステップは、前記モバイルコンピュータ装置がどのネットワーク・リソースにアクセス可能かを制御する処理を含むことを特徴とする方法。 - 少なくとも一つのさらなるコンピュータ装置を含むモバイルコンピュータ環境において少なくとも一つのモバイルコンピュータ装置との持続的な接続を維持するためのサーバであって、
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時にセッションを維持し、前記モバイルコンピュータ装置と少なくとも一つのさらなるコンピュータ装置間の少なくとも1つのセッションを管理するセッション・マネージャを含むサーバ。 - 前記セッション・マネージャは、前記セッションのためにユーザ設定可能なセッション優先順位を少なくとも1つ付与するセッション優先キューを含むことを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理する手段を含むことを特徴とする請求項71記載のサーバ。
- 前記モバイルコンピュータ環境は、複数のサブネットワークを含み、前記セッション・マネージャは、動的ホスト構成プロトコルを使用して前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時にセッションを維持することを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置とデータグラムのやり取りを行い、少なくとも1つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする請求項71記載のサーバ。
- 前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする請求項75記載のサーバ。
- 前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする請求項75記載のサーバ。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置に可変の位置アドレスを付与し、前記セッション・マネージャはセッションと関連付けされる仮想アドレスに前記位置アドレスを対応付けすることを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、遠隔プロシージャ・コール・プロトコルを用いてモバイルコンピュータ装置と通信することを特徴とする請求項71記載のサーバ。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する少なくとも1つの物理的リンクを含み、前記セッション・マネージャは、前記物理的リンクの中断時に前記セッションの接続状態を維持することを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、少なくとも1つの標準的なトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信することを特徴とする請求項71記載のサーバ。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記セッション・マネージャは、前記複数のアプリケーションソースに関連するデータをストリームに融合して、前記ストリームを送信することを特徴とする請求項71記載のサーバ。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記セッション・マネージャは、前記複数のアプリケーションソースからの融合されたデータを逆多重化して、前記逆多重化されたデータを複数の関連する目的地に送信することを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、フレームを用いて前記モバイルコンピュータ装置と通信し、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行うことを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、信頼性の低いデータのセマンティクスを維持し、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄することを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置へのメッセージの保証配信、および/または前記モバイルコンピュータ装置からのメッセージの保証配信を行うことを特徴とする請求項71記載のサーバ。
- 前記セッション・マネージャは、前記モバイルコンピュータ装置がアクセス可能なネットワーク・リソースの制御を行うことを特徴とする請求項71記載のサーバ。
- プロキシ・サーバを含むモバイルコンピュータ環境において、モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時に、少なくとも一つのさらなるコンピュータ装置と持続的な仮想接続を維持するモバイルコンピュータ装置であって、
トランスポート・ドライバ・インターフェイスと、
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含み、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求に応じて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを前記プロキシ・サーバに送信することを特徴とするモバイルコンピュータ装置。 - 前記モバイル・インターセプタは、ユーザ設定可能なセッション優先順位を少なくとも1つ付与するセッション優先キューを含むことを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理する手段を含むことを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ環境は、複数のサブネットワークを含み、前記モバイルコンピュータ装置は、前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時に位置アドレスを取得するために動的ホスト構成プロトコルを使用する手段をさらに含むことを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記プロキシ・サーバとデータグラムのやり取りを行い、少なくとも1つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする請求項92記載のモバイルコンピュータ装置。
- 前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする請求項92記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は、前記モビリティ管理サーバを仮想アドレスと対応付ける、関連付けされた可変の位置アドレスを有することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、遠隔プロシージャ・コール・プロトコルを用いて前記モビリティ管理サーバと通信することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ環境は、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する少なくとも1つの物理的リンクを含み、前記モバイル・インターセプタは、前記物理的リンクでの中断後に前記モビリティ管理サーバから少なくとも1つのセッションの更新された接続状態情報を受け取ることを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は標準的なトランスポート・プロトコル・ハンドラを含み、前記モバイル・インターセプタは前記標準的なトランスポート・プロトコル・ハンドラを介して前記モビリティ管理サーバと通信することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記モバイル・インターセプタは前記複数のアプリケーションソースに関連するデータをストリームに融合して、前記ストリームを前記モビリティ管理サーバに送信することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイルコンピュータ装置は複数のアプリケーション目的地を含み、前記モバイル・インターセプタは、前記複数のアプリケーションソースからの融合されたデータを逆多重化して、前記逆多重化されたデータを複数のアプリケーション目的地に送信することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、フレームを用いて前記プロキシ・サーバと通信し、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行うことを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、信頼性の低いデータのセマンティクスを維持し、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄することを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記プロキシ・サーバへのメッセージの保証配信、および/または前記プロキシ・サーバからのメッセージの保証配信を行うことを特徴とする請求項88記載のモバイルコンピュータ装置。
- 前記モバイル・インターセプタは、前記モバイルコンピュータ装置がアクセス可能なモバイルコンピュータ環境のリソースの制御を行うことを特徴とする請求項88記載のモバイルコンピュータ装置。
- トランスポート・ドライバ・インターフェイスと、
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含む少なくとも一つのモバイルコンピュータ装置を含むモバイルコンピュータ環境であって、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求を受けて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを少なくとも1つのプロキシ・サーバに送信し、
前記プロキシ・サーバは、前記モバイル・インターセプタによって送信された前記遠隔プロシージャ・コールを受信及び処理するワーク・ディスパッチャを少なくとも1つ含み、前記プロキシ・サーバは、前記モバイルコンピュータ装置が前記モバイルコンピュータ環境と一時的に切断された時に、前記モバイルコンピュータ装置の代わりに仮想セッションをプロキシするプロキシ・キューを含むことを特徴とするモバイルコンピュータ環境。 - ネットワーク接続ポイントを介してネットワークと接続されるモバイルコンピュータ装置を少なくとも一つ含むモバイル・コンピューティング・ネットワークにおいて、ネットワーク接続ポイントの識別子の少なくとも一部分に基づき、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したかどうか検出するインターフェイス補助ローミングリスナを含むことを特徴とするモバイル・コンピューティング・ネットワーク。
- 前記モバイルコンピュータ装置はネットワーク・インターフェイス・アダプタを含み、前記リスナは前記ネットワーク・インターフェイス・アダプタから前記ネットワーク接続ポイントの識別子を取得することを特徴とする請求項106記載のネットワーク。
- 前記リスナは、前記ネットワーク接続ポイントの識別子をネットワーク接続についての詳細情報に相関させる情報を記憶するネットワーク・トポロジ・マップを保持することを特徴とする請求項106記載のネットワーク。
- 前記リスナは、前記ネットワークとの通信がいつ中断または再確立されるかを検出することを特徴とする請求項106記載のネットワーク。
- 前記インターフェイス補助ローミングリスナは、(a)ネットワーク通信の中断及び再確立、及び(b)前記ネットワーク接続ポイントの識別子の変化の検出を受けて、ローミング信号を生成することを特徴とする請求項109記載のネットワーク。
- 前記モバイルコンピュータ装置において使用されるインターフェイスベースのリスナであって、インターフェイスベースのリスナは少なくとも1つのネットワーク・インターフェイス・アダプタからの情報と、少なくとも1つのネットワークスタックから入手可能な情報を統合して、前記モバイルコンピュータ装置が新しいネットワーク接続ポイントに移動したかどうか判定することを特徴とするインターフェイスベースのリスナ。
- ネットワーク接続ポイント情報を含むネットワーク接続情報を提供するネットワーク・トポロジ・マップを含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- 上記リスナは学習情報に基づき前記ネットワーク・トポロジ・マップを動的に構成することを特徴とする請求項112記載のリスナ。
- イベント発生に基づき、ステータスをチェックするステータスチェッカーを含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- 前記イベントはタイマーのタイムアウト、ローレベルのローミング・ドライバ・コールバック、ネットワーク・レベル・アクティビティ・ヒントのいずれかを含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- モバイルコンピュータ装置が既に現在のネットワーク接続ポイントを訪れたかどうかインターフェイスに照会する接続情報探索部を含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- 新しいネットワーク・セグメントにおいて有効となる現行のアドレスを登録または再取得する接続構成を含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- インターフェイスから提供された情報の少なくとも一部分に基づいて、前記モバイルコンピュータ装置が異なるネットワーク・セグメントに移動したことの検出を受けてローミング信号を生成するローミング信号発生器を含むことを特徴とする請求項111記載のインターフェイスベースのリスナ。
- 予め割り当てられたアドレスがまだ有効かどうかを判定するヒューリスティック・アナライザをさらに含むことを特徴とする請求項118記載のインターフェイスベースのリスナ。
- モバイルノードが新しいネットワーク接続ポイントに移動したかどうか判定する方法であって、
(a)ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
(b)前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
(c)前記ステップ(b)を受けて信号を生成するステップを含むことを特徴とする方法。 - 請求項120記載の方法であって、
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ(c)を行うステップをさらに含むことを特徴とする方法。 - 請求項120記載の方法であって、
前記ステップ(c)はローミング信号を生成するステップを含むことを特徴とする方法。 - 請求項120記載の方法であって、
前記ステップ(b)はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。 - 請求項120記載の方法であって、
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出機構にフォールバックするステップをさらに含むことを特徴とする方法。 - 請求項120記載の方法であって、
前記ネットワーク接続ポイント情報の少なくとも一部分を受けて、択一的なネットワーク接続パスから選択するステップをさらに含むことを特徴とする方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/660,500 US7293107B1 (en) | 1998-10-09 | 2000-09-12 | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US27461501P | 2001-03-12 | 2001-03-12 | |
PCT/US2001/028391 WO2002023362A1 (en) | 2000-09-12 | 2001-09-12 | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004509539A true JP2004509539A (ja) | 2004-03-25 |
JP2004509539A5 JP2004509539A5 (ja) | 2005-04-07 |
Family
ID=26956948
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002527943A Pending JP2004509539A (ja) | 2000-09-12 | 2001-09-12 | コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP1364296A4 (ja) |
JP (1) | JP2004509539A (ja) |
AU (1) | AU2001289010A1 (ja) |
CA (1) | CA2421609A1 (ja) |
WO (1) | WO2002023362A1 (ja) |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006352337A (ja) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | 通信装置及び通信制御方法 |
JP2007306577A (ja) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
JP2008508837A (ja) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 |
JP2009119849A (ja) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | 情報処理装置、情報処理方法及びプログラム |
JP2009532765A (ja) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | 存在状態情報に基づいてセッションを維持するための方法およびデバイス |
JP2009535873A (ja) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | サーバと通信オブジェクトとの間のデータ伝送 |
US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
US7760693B2 (en) | 2004-12-10 | 2010-07-20 | Nec Corporation | Packet distribution system, PAN registration device, PAN control device, packet transfer device, and packet distribution method |
US7779034B2 (en) | 2005-10-07 | 2010-08-17 | Citrix Systems, Inc. | Method and system for accessing a remote file in a directory structure associated with an application program executing locally |
US7870153B2 (en) | 2006-01-24 | 2011-01-11 | Citrix Systems, Inc. | Methods and systems for executing, by a virtual machine, an application program requested by a client machine |
JP2011070279A (ja) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | アプリケーション・サーバおよびその動作制御方法 |
US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
US8302101B2 (en) | 2004-09-30 | 2012-10-30 | Citrix Systems, Inc. | Methods and systems for accessing, by application programs, resources provided by an operating system |
JP2013520138A (ja) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | インテリジェントな無線選択をレガシーおよび非レガシーアプリケーションに提供する方法および装置 |
US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
US8731547B2 (en) | 2007-09-27 | 2014-05-20 | Panasonic Corporation | Network node and mobile terminal |
US9009720B2 (en) | 2007-10-20 | 2015-04-14 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
US9178965B2 (en) | 2011-03-18 | 2015-11-03 | Qualcomm Incorporated | Systems and methods for synchronization of application communications |
US9264868B2 (en) | 2011-01-19 | 2016-02-16 | Qualcomm Incorporated | Management of network access requests |
JP2017502394A (ja) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Rpcコールの傍受 |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8078727B2 (en) | 1998-10-09 | 2011-12-13 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US7293107B1 (en) | 1998-10-09 | 2007-11-06 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment |
US7562146B2 (en) * | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
US20050198379A1 (en) | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
WO2003061188A1 (en) * | 2002-01-14 | 2003-07-24 | Netmotion Wireless, Inc. | Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments |
US7984157B2 (en) * | 2002-02-26 | 2011-07-19 | Citrix Systems, Inc. | Persistent and reliable session securely traversing network components using an encapsulating protocol |
US7661129B2 (en) | 2002-02-26 | 2010-02-09 | Citrix Systems, Inc. | Secure traversal of network components |
US8068833B2 (en) * | 2002-04-26 | 2011-11-29 | Nokia Corporation | Candidate access router discovery |
JP4290967B2 (ja) | 2002-11-26 | 2009-07-08 | Necインフロンティア株式会社 | 無線LANネットワークQoS制御システム、基地局、端末、QoS制御方法およびプログラム |
FR2856540A1 (fr) * | 2003-06-19 | 2004-12-24 | Filfree Networks | Architecture de reseau local sans fil |
DE10346007A1 (de) * | 2003-10-02 | 2005-04-28 | Siemens Ag | Kommunikationseinrichtung und Verfahren zum Einstellen einer Sicherheitskonfiguration einer Kommunikationseinrichtung |
US7594018B2 (en) * | 2003-10-10 | 2009-09-22 | Citrix Systems, Inc. | Methods and apparatus for providing access to persistent application sessions |
US7760882B2 (en) | 2004-06-28 | 2010-07-20 | Japan Communications, Inc. | Systems and methods for mutual authentication of network nodes |
US7725716B2 (en) | 2004-06-28 | 2010-05-25 | Japan Communications, Inc. | Methods and systems for encrypting, transmitting, and storing electronic information and files |
AU2005266945A1 (en) | 2004-07-23 | 2006-02-02 | Citrix Systems, Inc. | A method and systems for securing remote access to private networks |
AU2005266943C1 (en) | 2004-07-23 | 2011-01-06 | Citrix Systems, Inc. | Systems and methods for optimizing communications between network nodes |
GB2417396A (en) | 2004-08-18 | 2006-02-22 | Wecomm Ltd | Internet protocol having session identifier for mobile device internet access |
US8613048B2 (en) | 2004-09-30 | 2013-12-17 | Citrix Systems, Inc. | Method and apparatus for providing authorized remote access to application sessions |
US8171479B2 (en) | 2004-09-30 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers |
US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
US7810089B2 (en) | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
US7359919B2 (en) * | 2005-03-08 | 2008-04-15 | Microsoft Corporation | Reliable request-response messaging over a request-response transport |
US8131825B2 (en) | 2005-10-07 | 2012-03-06 | Citrix Systems, Inc. | Method and a system for responding locally to requests for file metadata associated with files stored remotely |
US8533338B2 (en) | 2006-03-21 | 2013-09-10 | Japan Communications, Inc. | Systems and methods for providing secure communications for transactions |
JP2008098813A (ja) * | 2006-10-10 | 2008-04-24 | Matsushita Electric Ind Co Ltd | 情報通信装置、情報通信方法、及びプログラム |
US8701010B2 (en) | 2007-03-12 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods of using the refresh button to determine freshness policy |
US8490148B2 (en) | 2007-03-12 | 2013-07-16 | Citrix Systems, Inc | Systems and methods for managing application security profiles |
US8631147B2 (en) | 2007-03-12 | 2014-01-14 | Citrix Systems, Inc. | Systems and methods for configuring policy bank invocations |
US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
US9979797B2 (en) * | 2012-07-27 | 2018-05-22 | Nokia Technologies Oy | Methods and apparatuses for facilitating utilization of cloud services |
US9253545B2 (en) | 2013-12-04 | 2016-02-02 | Wowza Media Systems, LLC | Routing media content based on monetary cost |
US9113182B2 (en) | 2013-12-04 | 2015-08-18 | Wowza Media Systems, LLC | Selecting a media content source based on monetary cost |
WO2015147860A1 (en) * | 2014-03-28 | 2015-10-01 | Hewlett-Packard Development Company, L.P. | Rescheduling a service on a node |
US10721680B2 (en) | 2016-04-21 | 2020-07-21 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a virtual network function in a network |
EP3987843A1 (en) * | 2019-06-20 | 2022-04-27 | Koninklijke Philips N.V. | Method to enhance system analysis |
US11469890B2 (en) * | 2020-02-06 | 2022-10-11 | Google Llc | Derived keys for connectionless network protocols |
CN113364652B (zh) * | 2021-06-30 | 2023-07-25 | 脸萌有限公司 | 网卡流量测试方法、装置、网络设备、***及可读介质 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000115253A (ja) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | 通信方法、携帯端末装置及びゲートウェイ装置 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6006090A (en) * | 1993-04-28 | 1999-12-21 | Proxim, Inc. | Providing roaming capability for mobile computers in a standard network |
US6249818B1 (en) * | 1993-06-30 | 2001-06-19 | Compaq Computer Corporation | Network transport driver interfacing |
JP3492865B2 (ja) * | 1996-10-16 | 2004-02-03 | 株式会社東芝 | 移動計算機装置及びパケット暗号化認証方法 |
JP3651721B2 (ja) * | 1996-11-01 | 2005-05-25 | 株式会社東芝 | 移動計算機装置、パケット処理装置及び通信制御方法 |
US6091951A (en) * | 1997-05-14 | 2000-07-18 | Telxon Corporation | Seamless roaming among multiple networks |
US6230004B1 (en) * | 1997-12-01 | 2001-05-08 | Telefonaktiebolaget Lm Ericsson | Remote procedure calls using short message service |
US6147986A (en) * | 1998-03-06 | 2000-11-14 | Lucent Technologies Inc. | Address updating of wireless mobile terminal hosts affiliated with a wired network |
FI105978B (fi) * | 1998-05-12 | 2000-10-31 | Nokia Mobile Phones Ltd | Menetelmä langattoman päätelaitteen kytkemiseksi tiedonsiirtoverkkoon ja langaton päätelaite |
-
2001
- 2001-09-12 AU AU2001289010A patent/AU2001289010A1/en not_active Abandoned
- 2001-09-12 WO PCT/US2001/028391 patent/WO2002023362A1/en active Application Filing
- 2001-09-12 CA CA002421609A patent/CA2421609A1/en not_active Abandoned
- 2001-09-12 EP EP01968790A patent/EP1364296A4/en not_active Ceased
- 2001-09-12 JP JP2002527943A patent/JP2004509539A/ja active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000115253A (ja) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | 通信方法、携帯端末装置及びゲートウェイ装置 |
Cited By (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4638904B2 (ja) * | 2002-08-01 | 2011-02-23 | リサーチ イン モーション リミテッド | 常時オンのワイヤレスインターネットプロトコル通信 |
JP2007306577A (ja) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
JP2008160826A (ja) * | 2002-08-01 | 2008-07-10 | Research In Motion Ltd | 常時オンのワイヤレスインターネットプロトコル通信 |
JP2008508837A (ja) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 |
US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
US7870294B2 (en) | 2004-09-30 | 2011-01-11 | Citrix Systems, Inc. | Method and apparatus for providing policy-based document control |
US8302101B2 (en) | 2004-09-30 | 2012-10-30 | Citrix Systems, Inc. | Methods and systems for accessing, by application programs, resources provided by an operating system |
US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
US8065423B2 (en) | 2004-09-30 | 2011-11-22 | Citrix Systems, Inc. | Method and system for assigning access control levels in providing access to networked content files |
US8352964B2 (en) | 2004-09-30 | 2013-01-08 | Citrix Systems, Inc. | Method and apparatus for moving processes between isolation environments |
US7865603B2 (en) | 2004-09-30 | 2011-01-04 | Citrix Systems, Inc. | Method and apparatus for assigning access control levels in providing access to networked content files |
US7760693B2 (en) | 2004-12-10 | 2010-07-20 | Nec Corporation | Packet distribution system, PAN registration device, PAN control device, packet transfer device, and packet distribution method |
US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
US8312261B2 (en) | 2005-01-28 | 2012-11-13 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
JP2006352337A (ja) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | 通信装置及び通信制御方法 |
JP4628194B2 (ja) * | 2005-06-14 | 2011-02-09 | 株式会社エヌ・ティ・ティ・ドコモ | 通信装置、所要時間測定方法及び通信制御方法 |
US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
US7779034B2 (en) | 2005-10-07 | 2010-08-17 | Citrix Systems, Inc. | Method and system for accessing a remote file in a directory structure associated with an application program executing locally |
US7870153B2 (en) | 2006-01-24 | 2011-01-11 | Citrix Systems, Inc. | Methods and systems for executing, by a virtual machine, an application program requested by a client machine |
US8355407B2 (en) | 2006-01-24 | 2013-01-15 | Citrix Systems, Inc. | Methods and systems for interacting, via a hypermedium page, with a virtual machine executing in a terminal services session |
US7954150B2 (en) | 2006-01-24 | 2011-05-31 | Citrix Systems, Inc. | Methods and systems for assigning access control levels in providing access to resources via virtual machines |
US8051180B2 (en) | 2006-01-24 | 2011-11-01 | Citrix Systems, Inc. | Methods and servers for establishing a connection between a client system and a virtual machine executing in a terminal services session and hosting a requested computing environment |
US7949677B2 (en) | 2006-01-24 | 2011-05-24 | Citrix Systems, Inc. | Methods and systems for providing authorized remote access to a computing environment provided by a virtual machine |
US8010679B2 (en) | 2006-01-24 | 2011-08-30 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment provided by a virtual machine executing in a hypervisor executing in a terminal services session |
US8117314B2 (en) | 2006-01-24 | 2012-02-14 | Citrix Systems, Inc. | Methods and systems for providing remote access to a computing environment provided by a virtual machine |
US8341270B2 (en) | 2006-01-24 | 2012-12-25 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment |
US8341732B2 (en) | 2006-01-24 | 2012-12-25 | Citrix Systems, Inc. | Methods and systems for selecting a method for execution, by a virtual machine, of an application program |
KR101372011B1 (ko) * | 2006-03-31 | 2014-03-26 | 알카텔-루센트 유에스에이 인코포레이티드 | 세션 유지 방법, 하나 이상의 세션과 연관된 하나 이상의 그룹 형성 방법, 및 온라인 게임 세션 유지 시스템 |
JP2009532765A (ja) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | 存在状態情報に基づいてセッションを維持するための方法およびデバイス |
JP2009535873A (ja) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | サーバと通信オブジェクトとの間のデータ伝送 |
US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
US10028190B2 (en) | 2007-09-27 | 2018-07-17 | Sun Patent Trust | Mobile terminal |
US11082852B2 (en) | 2007-09-27 | 2021-08-03 | Sun Patent Trust | Mobile terminal |
US10484920B2 (en) | 2007-09-27 | 2019-11-19 | Sun Patent Trust | Mobile terminal |
US8731547B2 (en) | 2007-09-27 | 2014-05-20 | Panasonic Corporation | Network node and mobile terminal |
US9178803B2 (en) | 2007-09-27 | 2015-11-03 | Panasonic Intellectual Property Corporation Of America | Network node and mobile terminal |
US9642057B2 (en) | 2007-09-27 | 2017-05-02 | Sun Patent Trust | Network node and mobile terminal |
US9009720B2 (en) | 2007-10-20 | 2015-04-14 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
JP2009119849A (ja) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | 情報処理装置、情報処理方法及びプログラム |
US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
JP2011070279A (ja) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | アプリケーション・サーバおよびその動作制御方法 |
JP2013520138A (ja) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | インテリジェントな無線選択をレガシーおよび非レガシーアプリケーションに提供する方法および装置 |
US9603085B2 (en) | 2010-02-16 | 2017-03-21 | Qualcomm Incorporated | Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications |
US9264868B2 (en) | 2011-01-19 | 2016-02-16 | Qualcomm Incorporated | Management of network access requests |
US9178965B2 (en) | 2011-03-18 | 2015-11-03 | Qualcomm Incorporated | Systems and methods for synchronization of application communications |
US11876784B2 (en) | 2013-12-05 | 2024-01-16 | Crowdstrike, Inc. | RPC call interception |
US10356047B2 (en) | 2013-12-05 | 2019-07-16 | Crowdstrike, Inc. | RPC call interception |
US11082404B2 (en) | 2013-12-05 | 2021-08-03 | Crowdstrike, Inc. | RPC call interception |
JP2017502394A (ja) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Rpcコールの傍受 |
Also Published As
Publication number | Publication date |
---|---|
AU2001289010A1 (en) | 2002-03-26 |
EP1364296A4 (en) | 2004-09-15 |
EP1364296A1 (en) | 2003-11-26 |
WO2002023362A1 (en) | 2002-03-21 |
CA2421609A1 (en) | 2002-03-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2004509539A (ja) | コンピュータ環境におけるモバイル他の断続的接続性を提供する方法および装置 | |
US7778260B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
US7136645B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
US7644171B2 (en) | Mobile networking system and method using IPv4 and IPv6 | |
US7293107B1 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
US8078727B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
US6546425B1 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
US8060656B2 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computing environment | |
JP2008508837A (ja) | コンピュータ環境におけるモバイル及び他の断続的接続性を提供する方法及び装置 | |
US8909743B2 (en) | Dynamic session maintenance for mobile computing devices | |
US7984492B2 (en) | Methods and apparatus for policy enforcement in a wireless communication system | |
US7107609B2 (en) | Stateful packet forwarding in a firewall cluster | |
US20160156507A1 (en) | System and Method for Developing Applications in Wireless and Wireline Environments | |
US20020164952A1 (en) | Location-aware service proxies in a short-range wireless environment | |
US20050243857A1 (en) | Simultaneously routing data over multiple wireless networks | |
JP2004509539A5 (ja) | ||
AU2007235059A1 (en) | Session persistence on a wireless network | |
CN110830461B (zh) | 基于tls长连接的跨区的rpc服务调用方法及*** | |
US7447905B2 (en) | System and method of unacknowledged network layer service access point identifier (NSAPI) recovery in sub-network dependent convergence protocol (SNDCP) communication | |
Bhagwat et al. | MSOCKS+: an architecture for transport layer mobility |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080709 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110607 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20111101 |