JP2004509539A - Method and apparatus for providing mobile and other intermittent connectivity in a computer environment - Google Patents
Method and apparatus for providing mobile and other intermittent connectivity in a computer environment 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
ノマディックなシステムの特性を透過的にする、シームレスなソリューションであって、既存のネットワーク・アプリケーションが、モバイル環境でも確実に動作するようにする。モバイルネットワークと組み合わされたモビリティ管理サーバ（１０２）は、数量を限定されないモバイル端末システム（１０４）それぞれの状態を維持し、ネットワークへ、および他のピアでの処理への持続的な接続の維持に必要な、複雑なセッション管理を実行する。モバイル端末システムが圏外に出たり、サスペンドしたり、（例えば、あるネットワーク相互接続から別のものへとローミングして）ネットワークアドレスを変更したりした場合、モビリティ管理サーバは、結合しているピアのタスクとの接続を維持し、モバイル端末システムとネットワーク媒体とのコンタクトが一時的に失われても、モバイル端末システムが持続的な接続を維持できるようにする。インターフェイスベースのリスナは、ネットワーク・インターフェイスからのネットワーク接続ポイント情報を利用して、ローミング状態を判定し、ローミングに際した接続を効率的に確立する。モビリティ管理サーバは、非接続のネットワーク上で該サーバとコンタクトをとるためのリストを、モバイル端末システムに配布する。A seamless solution that makes the characteristics of a nomadic system transparent, ensuring that existing network applications work in a mobile environment. The mobility management server (102) combined with the mobile network maintains the state of each of the unlimited number of mobile terminal systems (104) and maintains a continuous connection to the network and to the processing at other peers. Perform any necessary complex session management. If the mobile terminal system goes out of range, suspends, or changes the network address (e.g., roaming from one network interconnect to another), the mobility management server will notify the associated peer Maintains a connection with the task and enables the mobile terminal system to maintain a persistent connection even if the contact between the mobile terminal system and the network medium is temporarily lost. An interface-based listener utilizes network connection point information from a network interface to determine a roaming state and to efficiently establish a connection during roaming. The mobility management server distributes a list for contacting the server on the disconnected network to the mobile terminal system.
Description
［発明の背景］
本発明は、ネットワークによって接続されたコンピュータ装置間の接続性に関する。より詳細には、ノマディック（ｎｏｍａｄｉｃ）システムの特性を透過性（トランスペアレント）を有する状態で扱うとともに、既存のネットワーク・アプリケーションを、対応するモバイル環境で確実に動作させる方法とシステムに関する。さらに詳細には、断続的に接続される、携帯型データ端末（ｈａｎｄｈｅｌｄ ｄａｔａ ｕｎｉｔｓ）やパソコン装置などの装置間における、連続的なデータストリームのやり取りを可能にする技術およびシステムに関する。
【０００１】
［発明の背景および要約］
近年、各企業は、重要な情報への迅速なアクセスこそが競争優位を保つための方策であると認識するようになってきた。このことから、特に安価なラップトップやハンドヘルドのコンピュータ装置の普及とも相まって、モバイルなどの断続的な接続が行われるコンピュータ装置が急速に企業ネットワークの重要な一要素となりつつある。しかしながら、こうしたノマディックな装置を既存のネットワーク・インフラへと統合することは、各企業の情報管理担当者にとって頭の痛い問題ともなっている。
【０００２】
モバイルネットワーキングに関する問題の多くは、イーサネット（登録商標）登場以前にローカルエリア・ネットワーク（ＬＡＮ）構築に伴っていた問題に近い。即ち、モバイル・プロトコルやインターフェイスには多くの種類があり、また、まだ規格が制定段階にあることから、異なるシステム間の相互運用性は無いも同然である。さらに、上記のようなネットワーク技術による通信はたいてい低速で帯域幅も限られており、各システムの特殊性から、アップデートに伴う費用も高額になっている。
【０００３】
こうした問題に加えて、モバイル技術は、以下のような固有の問題も有している。即ち、メインのネットワークと相互接続するの際には公共のネットワーク・インフラを経由する場合があるが、この際に機密情報が傍受されてしまう危険性がある。さらに、無線装置を経由して相互接続する場合であれば、機密情報がいわば「放送」されてしまうことになり、類似のインターフェイスを所有する誰もが該情報をたいした障害もなく傍受することができてしまう。
【０００４】
しかし、おそらく上記のような問題よりもさらに重要な問題としては、従来、モバイルネットワーキングが使われるのは基本的にメッセージ指向あるいはステートレスなアプリケーションに限られていて、クライアント／サーバ、ホスト／ターミナル方式をとるウェブベースあるいはファイル共有型のシステムモデルを利用した、既存あるいは新規の業務用アプリケーションには適さなかったことである。これは、一般的な業務用アプリケーションが効果的かつ確実に動作するためには、ステートレスなパケット交換だけでなく、連続的なデータストリームを用いたステートフルなセッションが必要であるという理由からであった。
【０００５】
このため、主要な市販のネットワーク・アプリケーションのほとんどは、ＴＣＰ／ＩＰセッションか、専用の仮想回路を必要としている。このようなセッションは、ネットワークが中断された場合はそれ以上機能できず、また接続時には、ネットワーク間のローミング（ネットワークアドレスの変更）が不可能である。さらに、モバイルネットワーキングは本質的に動的であり信頼性が低い。これらの問題について、以下では、モバイルネットワークにおいてよく見られる状況をいくつか考察することにする。
【０００６】
（非接続あるいは圏外のユーザ）
モバイル装置が所与のネットワークから切断されるかあるいはネットワークとのコンタクトを失う（つまり、無線相互接続の圏外に出たりネットワークがカバーしていない「穴」に入ったりする）と、携帯装置上で動作しているセッション指向のアプリケーションはピアとのステートフルな接続を失い、動作を停止する。装置が再び取り付けられるかあるいは装置とネットワークとのコンタクトが回復すると、ユーザはネットワークとの再接続を行い、セキュリティ確保のために再ログインを実行して、アプリケーションにおいてどこで作業が中断されたかを同定し、必要ならば失われたデータの再入力を行わなければならない。このような再接続処理は時間を要し、費用もかかり、またユーザを非常に苛立たせることにもなる。
【０００７】
（他のネットワークへの、あるいはルータ境界を越える移動（ネットワークアドレス変更））
モバイルネットワークは通常、管理容易性の見地からセグメント化されているが、一方でモバイル装置はその用途上、ローミングが可能になっている。相互接続されたネットワーク間のローミングとは、ネットワークアドレスが変更されるということを意味する。ネットワークアドレスがシステムの動作中に変更される場合、対応しているピア同士の接続を保つためにルーティング情報を変更することが必要になる。さらに、新しいネットワークアドレスを取得するために、それまでに確立されたステートフルなアプリケーションのセッション全てを終了させなければならない場合もあり、上記の再接続処理に関わる問題がここでも浮上する。
【０００８】
（セキュリティ）
既に述べたように、各企業は機密情報を守る必要がある。市販のアプリケーションの多くは、物理的ネットワークへのアクセスがコントロールされ（つまり、安全な施設の内部に構築されたケーブルを使って実行され）、セキュリティは、認証や場合によっては暗号化に関する付加的な層を通じて保持されることを前提として作成されている。しかしながら、ノマディック・コンピューティングではこうした前提は自明のものではない。というのも、公共の電波や有線インフラを通過する際にデータが傍受されてしまう危険性があるからである。
【０００９】
このため、ノマディックなシステムの特性を透過性を有するものとすることによって、既存のネットワーク・アプリケーションが種々のモバイル環境で確実に動作することを可能にした、統合的なソリューションの登場が大いに望まれる。
【００１０】
本発明は、上記の問題を解決するために、企業内ネットワークを延長して、ネットワーク管理者がモバイル装置のユーザも固定装置のユーザと同じアプリケーションに容易にアクセスできるようにすることを可能にすると同時に、信頼性やネットワーク管理の一元性も失わない、一貫したソリューションを提示する。該ソリューションは、これまでの有線ネットワーク規格の長所を、発展しつつあるモバイルネットワーキングに関する規格にも持たせることで、既存のネットワーク・アプリケーションにも対応したものとなっている。
【００１１】
本発明の非限定的で例示的具体的な実施の形態の一側面においては、モバイル相互接続（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ）に接続されたモビリティ管理サーバ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ； ＭＭＳ）は、数量を限定されないモバイル端末システム（Ｍｏｂｉｌｅ Ｅｎｄ Ｓｙｓｔｅｍｓ； ＭＥＳ）それぞれの状態の維持や、ネットワークへおよびピアにおけるアプリケーション処理への持続的な接続の維持に必要な、複雑なセッションの管理を行う。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合でも、モビリティ管理サーバは該システムと、該システムと対応しているピアとの接続を維持する。言い換えれば、該モバイル端末システムは、実際には物理的な接続が一時中断されてしまうにも関わらず、ピアとの仮想的な接続を維持し続けることになる。
【００１２】
また、上記本発明の非限定的で具体的な実施の形態は、以下の（これらに限定されないが）新規かつ有用な技術、構成を提示する。
【００１３】
・ユーザによって設定可能なセッション特性をモバイル・クライアントに付与するモビリティ管理サーバ。
【００１４】
・ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシーを管理。
【００１５】
・工業規格である動的ホスト構成プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ； ＤＨＣＰ）をモビリティ管理サーバと連携させて用いるローミング方法。
【００１６】
・ユーザによって設定可能なタイムアウト条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１７】
・ユーザによって設定可能な再試行条件に基づいて、信頼性の低いデータグラムを自動的にシステムから除去。
【００１８】
より詳細には、上記本発明の好ましい具体的な実施形態の一例において、モバイル相互接続ネットワークに接続されたモビリティ管理サーバが備えられている。該モビリティ管理サーバは、数量を限定されないモバイル端末システムそれぞれの状態を維持し、ネットワークへおよび他の処理（例えば他のネットワークベースのピア・システムにて実行される処理）への持続的な接続の維持に必要な、複合的なセッションを管理する。あるモバイル端末システムが、圏外に出てしまったり、サスペンドしたり、あるいは（あるモバイル相互接続から別の相互接続へとローミングすることなどで）ネットワークアドレスを変更したりした場合、モビリティ管理サーバはデータの受信と待機要求を認識して、該システムと、該システムと対応しているピアとの接続を維持する。このようにモビリティ管理サーバがプロキシとして働くことにより、モバイル端末システム上で動作するアプリケーションは、あるネットワーク媒体との物理的な接続が一時的に中断された場合でも、持続的な接続を維持することができる。
【００１９】
また、上記本発明の好ましい実施の形態の他の一例において、モビリティ管理サーバはモバイル端末システム用のアドレスを管理する。モバイル端末システムには、それぞれにプライマリネットワーク上のプロキシ・アドレスが割り当てられている。この非常に汎用性の高いアドレスはモバイル端末システムの「仮想アドレス」と呼ばれる。モビリティ管理サーバはこの仮想アドレスを、ノマディック・システムにおける現在の「位置」アドレスと対応付ける。モバイル端末システムの位置アドレスは、該システムがネットワーク間を移動する際に変更されるが、仮想アドレスの方は、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００２０】
上記本発明の好ましい実施形態のさらに他の一例において、モビリティ管理サーバは、コンソール（制御）アプリケーションと包括的なメトリクスとによってモバイル端末システムの集中的な管理を実現する。さらに、好ましい実施形態では、ユーザによって設定可能なセッション特性を、プロキシ・サーバ上で実行されるモバイル・クライアントについて実現し、ネットワーク・リソースの消費に関し、ユーザごとにモバイル装置のポリシー設定を管理する。
【００２１】
さらに、上記一側面においては、遠隔プロシージャ・コール（ＲＰＣ）・プロトコル（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ ｐｒｏｔｏｃｏｌ）およびインターネット・モビリティ・プロトコル（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ Ｐｒｏｔｏｃｏｌ）が、プロキシ・サーバと各モバイル端末システムとの間の通信の確立に使用されている。
【００２２】
遠隔プロシージャ・コールによって、ローカルなシステムから、遠隔のシステムにおけるプロシージャを呼び出す処理が可能になり、ＲＰＣプロトコルを使用することで、モバイル端末システムが接続を切ったり、圏外に行ったり、動作をサスペンドしたりということを、アクティブなネットワークセッションを中断することなくできるようになる。このように、セッションの維持は専用のアプリケーションによってなされるわけではないので、市販のアプリケーションを、何ら変更することなくノマディックな環境下で使用することができるようになる。
【００２３】
ＲＰＣプロトコルは、トランザクションを、標準的なネットワークトランスポート・プロトコルおよびインフラを経由して送られるメッセージに生成する。このＲＰＣメッセージは、モバイル端末システムにおいて実行されているアプリケーションによって開始されたネットワーク・トランザクション全体を含んでおり、これにより、モビリティ管理サーバとモバイル端末システムとの間の接続状態情報を、両者の間の物理的な接続が途切れているときをも含め、常にシンクロさせておくことが可能になる。ＲＰＣを備える上記本発明の実施の形態において、プロキシ・サーバとモバイル端末システムとは、全ての時間における全ての共有接続に関する統一された論理データベースを管理すべく、各トランザクションの状態について十分な情報を共有している。
【００２４】
上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルは、有線のローカルエリア・ネットワークと、それよりも信頼性の低い、無線ＬＡＮおよびＷＡＮといったネットワークとの間の相違を補償する。フレームサイズとプロトコルタイミングとが調整されることで、モバイル環境を考慮していない通信に比べるとパフォーマンスが大幅に改善され、ネットワークのトラフィックは大きく減少する。これは、帯域幅が限られているときやバッテリーの寿命を考慮に入れなければならないときに、特に重要になる。さらに、上記本発明の好ましい実施形態におけるインターネット・モビリティ・プロトコルによって、公共のネットワークもしくは無線を通じて、モバイル端末システム―モビリティ管理サーバ間で伝送が行われる際の、機密データの安全性が確保される。インターネット・モビリティ・プロトコルは、認証された装置からのみプライベートなネットワークにアクセスできるようにすることで、基本的なファイアウォールとしての機能も果たす。また、インターネット・モビリティ・プロトコルにより、モバイル端末システム―モビリティ管理サーバ間の全ての通信を認証、暗号化することも可能である。
【００２５】
上記本発明の好ましい実施形態のさらに他の一例において、モバイル相互接続は、標準的なネットワーク・アプリケーションのインターフェイスが適用できる範囲を広げるべく、標準的なトランスポート・プロトコル（例としてＴＣＰ／ＩＰ、ＵＤＰ／ＩＰ、ＤＨＣＰなど）を使用して構築される。上記本発明の好ましい実施形態によって、データ転送、セキュリティ、アドレス管理、装置管理、ユーザ管理が効果的に統合され、ノマディック環境を効果的に透過性を有する状態とすることができる。インターネット・モビリティ・プロトコルは、複数のデータストリーム（信頼度の高いものも低いものも）を、標準的なネットワーク・インフラ上で標準的なトランスポート・プロトコルによって与えられる、単一の仮想チャネルを通じて多重化するための効果的な方法を提供する。
【００２６】
ＲＰＣ層を用いて、インターネット・モビリティ・プロトコルは、違うソースから供給され、違うまたは同じ目的地へと向かうデータを融合させて単一のデータストリームとし、これをモバイルリンクを介して送る。該モバイルリンクの反対側の端において、該データストリームは逆多重化されて複数の異なったデータストリームとなり、それぞれの最終的な目的地に伝送される。この多重化／逆多重化により、利用可能な帯域幅を（最大限のサイズのネットワークフレームを生成することで）最大限に使うことができ、複数のチャネルを確立することができる（よって、優先順位付けが可能になり、基礎をなしているネットワークがデータ通信サービスを供給している場合であれば、その品質を保証することができる可能性もある）。
【００２７】
上記本発明の実施の形態に関するインターネット・モビリティ・プロトコルは、さらに以下のような特徴や利点を実現する。なお、本発明は以下の点に限定されるものではない。
【００２８】
・トランスポート・プロトコルの独立性
・ネットワーク上における位置（ｐｏｉｎｔ ｏｆ ｐｒｅｓｅｎｃｅ； ＰＯＰ）あるいはネットワーク・インフラを、データの流れに影響を与えることなく変更可能（物理的境界、ポリシー、あるいは帯域幅による制約が無い場合のみ）
・付加的な経費が最小限
・伝送媒体に適した自動的なフラグメントのサイズ変更（あるフレームのプロトコル・データ・ユニットがネットワーク媒体の利用可能な上限の伝送ユニットよりも多いとき、インターネット・モビリティ・プロトコルは該フレームをフラグメント化し、再構築する。このことにより、該フレームのネットワーク伝送を保障することが可能となる。再伝送の際、該フレームは再度検査される。ネットワーク・インフラもしくは環境が変化していた場合、該フレームは再度フラグメント化されるか、あるいは伝送ユニットの上限が実際に上昇しているときには単一のフレームとして伝送される。）
・再伝送の際に、フレームに信頼性の低いデータを破棄させることで、信頼性の低いデータのセマンティクスを保持
・信頼性の高いデータグラムサービスにおける新しいセマンティクスを提供（これにより、インターネット・モビリティ・プロトコルによるピアの端末へのデータグラムの伝達が保証され、要求しているエンティティに伝達の通知がなされる）
・上りと下りの伝送パスをそれぞれ別に扱って、自動的に操作パラメータを調整し最適なスループットを実現（ヒステリシスに基づいて、フレームサイズ／フラグメント化の閾値、待機中のフレーム数（ウィンドウ）、再伝送時間、およびネットワークを通じて送られる複製データの量を減少させるための遅延承認時間などのパラメータを調整）。
【００２９】
・ネットワーク障害に対する耐性（モバイル環境での使用が想定されているため、一時的にネットワーク媒体間の接続が切断されても、仮想チャネルが切断されたりアプリケーションベースの接続が切断されたりしてしまうことがない）
・操作パラメータを調整するための帯域内信号方式をピアに対して提供（接続された端末のそれぞれから、そのピアに対してネットワーク・トポロジや環境の変化に関する警告を出すことが可能）
・輻輳回避アルゴリズムを採用し、必要なときにはスループットを効果的に減衰
・選択的な確認応答と高速での再伝送とによって無駄な再伝送の回数を制限し、ノマディック環境におけるハンドオフ回復のスピードアップを実現（これにより、プロトコルはロスの多いネットワーク環境においても最適なスループットを維持）
・複数のフレームを待機状態にする、スライディング・ウィンドウ技術を採用（このパラメータは各方向に調整可能で、ピアからの確認応答を要することなくフレームを所定の上限までストリーミングするために与えられる）
・シーケンス番号が非バイト指向であることにより、単一のシーケンス番号で最大のペイロード・サイズまでを表現可能
・セキュリティ対策（インターネット・モビリティ・プロトコル層に認証層と暗号化層を追加可能）
・圧縮によって、帯域幅の限られた接続における効率性を確保
・どちらのピアも新たな位置に移動することが可能な平衡型設計
・どちらの側からでもピアへの接続が確立可能
・休止している接続を迅速に破棄して消費されていたリソースを回復する、休止タイムアウトを発動可能
・接続に対して任意の最大持続時間を設定可能（例えば、所定の期間経過後あるいは所定の日時の後に、接続の終了および／または拒否が可能）。
【００３０】
本発明の好ましい具体的な実施形態においては、システム管理者によるネットワーク・リソースの消費の管理が可能である。例えば、システム管理者は、モバイル端末システム、モビリティ管理サーバの少なくとも一方をコントロールすることができる。この場合のコントロールとは、例えばネットワーク帯域幅や他のリソースの配分の管理や、セキュリティ関連の事項を指す。管理はクライアント側で多数のリソースを持っているクライアントについて実行するのが効果的である。しかしながら、リソースを多く持たないシン・クライアントにポリシー管理のための付加的なコードや処理を負わせるのは望ましくない。よって、シン・クライアントの管理についてはモビリティ管理サーバ等によって集中的に行う、あるいはその一部を分担するのが最も現実的な解決策であると考えられる。モビリティ管理サーバがモバイル端末システムの各データストリームをプロキシすることによって、ポリシー管理が集中的に行われる。さらに、モビリティ管理サーバがユーザごとにプロキシを行うので、ユーザごと、装置ごとに、ネットワーク・リソースへのアクセスを管理し制限することができる。
【００３１】
簡単な例を挙げると、モビリティ管理サーバは、特定のユーザによるあるネットワーク・リソースへのアクセスを「締め出す」（ｌｏｃｋ ｏｕｔ）ことができる。この点は、インターフェイスのネットワークが、モバイル相互接続によって組織の管理下にある施設の境界よりも外に「延長」（ｅｘｔｅｎｄ）されてしまっていることを考えると非常に重要である（例えば、以前勤めていた職場のネットワークに、元従業員が外部からアクセスを試みるといった場合を考えよ）。これにとどまらず、モビリティ管理サーバによるポリシー管理はさらに多くの利点を提供しうる。例えば、モビリティ管理サーバによって、あるＵＲＬに特定のユーザのみがアクセスできるようにしたり、ネットワークサービスによる要求によって戻されるデータをフィルタリングしたり、ネットワークの帯域幅保全のためにデータを圧縮したりということが可能になるといった点である。このように、既存もしくは新規のアプリケーションレベルのサービスを、シームレスかつ透過的な形で強化することができる。
【００３２】
また、モバイル端末システムは「信頼性の低い」（ｕｎｔｒｕｓｔｅｄ）ネットワーク（つまり組織の管理が及ぶ範囲外のネットワーク）とも接続されるため、リモート接続中に悪質なサイバー攻撃に遭う可能性がある。モバイル端末システムとの間でポリシーやフィルタを共有することで、悪質な接続からのモバイル端末システムの保全、リモート・ノードにおける進入（ｉｎｇｒｅｓｓ）フィルタリング、そして企業インフラの集中管理のさらなるセキュリティ向上が可能になる。
【００３３】
本発明の実施形態の他の一例では、インターフェイスによって補助されたローミングのリスナ（ｌｉｓｔｅｎｅｒ）によって、モバイル端末システムが一般的な信号伝達をサポートしたインターフェイスを利用し、インターフェイスによって補助されたローミングを行うことが可能になる。本発明の上記実施形態の一例の一側面において、モバイル端末システムの、インターフェイスベースのリスナは、所定の事象（例えばコールバックや、タイマーによるタイムアウト、データの損失を示唆するネットワーク活動など）に際して、モバイル端末システムの媒体の接続状態が変化したか否かを判定する。これは例えば、リスナが、モバイル端末システムが切り離されてネットワークと通信できる状態でなくなったことを検知して、インターフェイスにこれを示唆するといったことを意味する。再接続の際、リスナは予め記録された接続識別情報（ａｔｔａｃｈｍｅｎｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）におけるネットワークポイントを参照して、モバイル端末システムが同じネットワークポイントに再接続されたか否かを判定する。再接続が同じネットワークポイントになされていた場合、リスナはモバイル・クライアントに、トランスポート・レベルでの通信の再確立を進めることを警告する。再接続が別のネットワークポイントになされていた場合、リスナはモバイル端末システムが「ローミング」（ｒｏａｍ）状態であることを示し、現状におけるネットワーク・セグメントで使用可能なアドレスをシステムに取得させるようにする（これは例えば、現行のアドレスを新規のサブネットにおいて有効であるように登録することを含んでもよい）。リスナは（操作を介して学習した）ネットワーク・トポロジのマップを保持して、そのクライアントに対して生成される信号（「同一サブネット上のローミング」、「ローミング」等）の適否を判定する一助としてもよい。
【００３４】
上記本発明の非限定的な好ましい具体的実施形態の他の一例においては、モビリティ管理サーバ（ＭＭＳ）に「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでアクセスすることが可能である。この新しいアルゴリズムによって、あるネットワーク・インフラからは別のネットワーク・インフラにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。この構成により、ＭＭＳが利用可能な代替アドレスのリストが予め設定され、通信中にＭＥＳ（モバイル端末システム）に送られるかあるいはＭＥＳによって動的に学習される。実施の一形態において、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送ることができる。該リストは、回路構築の際やその他接続が確立されている間のいかなる時にも、送付／更新が可能である。
【００３５】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは該ネットワークにおける新規のネットワーク接続を通じてＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、ルートその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【００３６】
上記本発明の実施の形態のさらに他の例において、ポリシー管理に関する意思決定は分散型モバイルネットワークトポロジの内部にて行われ、例えば、ルールベースのポリシー管理プロシージャが、様々なメトリクスに基づいて要求の遂行を許可、拒絶、または制限する。このような管理形態は、例えば、マルチホーム／パス環境における最少コストルーティングといったコストメトリクスに基づいて意思決定をする際に用いられる。
【００３７】
このようなポリシー管理技術では、意思決定の際にモビリティあるいは位置取得（つまりローミング）に関する事項が考慮に入れられてもよい。例えば、管理ルールが装置の位置（ネットワークのどの接続ポイント、例えばアクセスポイント／基地局、ハブ、ルータ、ＧＰＳ座標等に近いかなど）に基づいて決定されてもよく、これにより、特定の操作が、あるビル内では許可されるが別のビルでは許可されないといったことが可能になる。例えば複数の違った無線ネットワークを利用している企業の場合にこの構成が有用であると考えられる。このような企業において、例えば積込ドックとオフィスとが無線ネットワークで接続されている場合がある。システム管理者は、積込ドックにいる従業員（例えばユーザや装置）がオフィス環境の無線ネットワークにアクセスできないようにすることができる。さらに、ポリシー管理によって、許可、拒否、遅延という３つの状態のいずれかをもたらすようにすることも可能である（例えば、決定が帯域幅やコストに基づいてなされる場合、操作の実行はより適切な時期がくるまで遅延される）。
【００３８】
上記実施例におけるポリシー管理においては、決定に基づいて動作を変更することが可能となっている。ひとつのアクションの例としては、全てのアクティブなアプリケーションによる帯域幅の消費を抑えるというものがある。また、例えば、著しく帯域幅を消費する特定のアプリケーションが存在する場合に、ポリシーエンジン（ｐｏｌｉｃｙ ｅｎｇｉｎｅ）によって該アプリケーションによる操作／トランザクションの完了までの速度を管理することが可能となる。この動作は、誤ったアプリケーションの動作を抑制させることを動的に学習するようになっていてもよい。もうひとつのアクションの例として、データの復元（例えば、利用可能な／許可された帯域幅やコスト、ユーザによる制限に基づいたグラフィックイメージのディザリング）がある。
【００３９】
さらに、ルールエンジン（ｒｕｌｅｓ ｅｎｇｉｎｅ）は、ルール評価に基づいて他のアクションを発動させる。イベントをロギングする、警告を発する、ユーザにアクションが拒否、遅延、あるいは条件付けされたことを通知するといった外部プロシージャが実行されてもよい。これらのような通知は、既存のルールへのオーバーライドがオペレータから求められるというような、インタラクティブなものであってもよい。
【００４０】
上記実施例におけるポリシー管理エンジン（ｐｏｌｉｃｙ ｍａｎａｇｅｍｅｎｔ ｅｎｇｉｎｅ）において、その意思決定は、装置、装置のグループ、ユーザ・グループ、ユーザ、あるいはネットワーク接続ポイントに関連した、任意の数のメトリクスもしくはその組み合わせに基づいてなされていてもよい。
【００４１】
ポリシー管理機能の一部として、他にもローカルベースの情報やサービスが、ポリシー管理、ネットワーク・モデリング、および／またはアセット・トラッキングのために取得され／備えられていてもよい。このようなサービスには、モバイル端末システムの現在位置に関連した情報がユーザやモバイル端末システムに自動的に提供される機能が含まれる。該情報は、メッセージ、ファイルその他の電子的フォーマットにて供給されてもよい。
【００４２】
この機能の非限定的な利用例としては、ショッピングモール運営者、各種業界団体、大規模小売業者などがショッピングセンターに、ブルートゥース ＰＡＮ、ＩＥＥＥ ８０２．１１ ＬＡＮ、８０２．１５ ＰＡＮ、その他の無線ネットワーク規格に準拠した、無線アクセスポイントを戦略的に設けるというものがある。この場合、顧客がセンター内を歩き回るのにあわせて、モバイル端末システムの現在位置周辺の店舗は顧客に情報を提示することができる。この情報としは、セールやディスカウント、特典などについてのものが含まれる。これに加え、モバイル端末システムに販促用の電子クーポン券が供給されるのもよい。店舗側は上記のようなサービスを、モール運営者、業界団体、小売業者、あるいはその他のサービス提供者による集中的な管理機構に登録することになる。
【００４３】
上記技術が利用される他の非限定的な例として、現場サービス、訪問販売、宅配などのバーティカル産業において、位置を基準にして情報を収集する、地域サービス、地図、方角、顧客、事故など公共の情報を、位置を基準にモバイル端末システムに送る、などがある。
【００４４】
さらに他の非限定的な例として、モバイル端末システムをモニタリング、トラッキングするウェブベースのサービスがある。例えば、顧客は該トラッキングサービスに登録し、信頼の置ける第三者機関が、ホスティングされているウェブサービスにログオンして顧客のモバイル端末システムの精確な位置を同定する。この場合、モバイル端末システムは車両に備え付けられてもよいし、歩行者に所持されていてもよい。モバイル端末システムのさらなる小型軽量化に伴い、このようなサービスはますます現実味を帯びてきている。該サービスを利用することで、危険度の高い人々、例えば高齢者、障害者、病人などを追跡、位置確認することができる。該サービスは、自動車その他の高価な動産や荷物をトラッキングすることにも利用できる。３Ｇ ＷＡＮネットワーク、ブルートゥースネットワーク、８０２．１１ネットワークその他の無線技術を利用し、ネットワーク媒体や接続ポイントを切り替えてもシームレスな接続性を保つことができるという特性を生かして、上記のサービスを非常に低いコストで実施することが可能である。
【００４５】
このように、本発明は企業ネットワークを延長して、ネットワーク管理者が、信頼性や集中的な管理形態を犠牲にすることなく、モバイル端末のユーザに、アプリケーションへの簡便なアクセスを固定端末のユーザの場合と同様に提供することを可能にする。本ソリューションは、既存の有線ネットワーク規格の長所を制定段階にあるモビリティ規格にも持たせて、既存のネットワーク・アプリケーション上で動作可能なソリューションを生み出すものである。
【００４６】
本発明の他の目的、特徴、および優れた点は、以下に示す記載によって十分分かるであろう。また、本発明の利点は、図面を参照した以下の説明で明白になるであろう。
【００４７】
［好ましい実施の形態の詳細な説明］
図１は、本発明の、モバイル強化ネットワークコンピュータシステム１００を例示している。該ネットワークコンピュータシステム１００は、モビリティ管理サーバ１０２と、一つ以上のモバイル端末システム１０４とを含んでいる。モバイル端末システム１０４は、ローカルエリア・ネットワーク（ＬＡＮ）１０８を通じてモビリティ管理サーバ１０２と通信することができる。モビリティ管理サーバ１０２は、モバイル端末システム１０４のネットワーク・レベルでのプロキシとして機能する。モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モビリティ管理サーバ１０２とモバイル端末システム１０４との間の相互接続が断続的で信頼性の低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。本好ましい実施形態では、モビリティ管理サーバ１０２は、本発明の遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いて、モバイル端末システム１０４と通信する。
【００４８】
この場合、モバイル端末システム１０４はモビリティ管理サーバ１０２とアクティブに接続されるが、該接続は常時アクティブに行われるものではない。例えば、
・複数のモバイル端末システム１０４ａ‐１０４ｋが、モビリティ管理サーバ１０２と、モバイル相互接続によって（この場合無線で）通信する。例として、ローカル・エリアもしくはワイドエリア・ネットワーク１０８と無線（あるいは有線）でつながった、従来型の電磁（電波）トランシーバ１０６が考えられる。上記のようなモバイル相互接続により、モバイル端末システム１０４ａ‐１０４ｋが、一つのカバーエリア（ｃｏｖｅｒ ａｒｅａ）１０７ａから別のカバーエリア１０７ｋへとローミングすることが可能になる。一般的に、モバイル端末システム１０４が、あるカバーエリア１０７から別のエリアにローミングしたり、最も近いトランシーバ１０６から届く範囲を外れたり、あるいは信号を一時的に遮断（例えばビルの柱の裏側を通るなどで）されたりした場合、一時的に通信が切断される。
【００４９】
・別のモバイル端末システム１０４ｌ、１０４ｍ…が、モビリティ管理サーバ１０２と、ドッキングポートやネットワークケーブルコネクタなどの着脱式（ｎｏｎ−ｐｅｒｍａｎｅｎｔ）有線相互接続１０９を介して通信する。モバイル端末システム１０４は、接続１０９が外れたり、モバイル端末システム１０４の電源が切られたりした場合、一時的にＬＡＮ１０８から切断される。
【００５０】
・さらに別のモバイル端末システム（例えば１０４ｎ）が、モビリティ管理サーバ１０２と、ワイドエリア・ネットワーク、ダイアルアップ・ネットワーク、衛星ネットワーク、インターネット等のネットワーク・トポグラフィ１１１を介してノマディック接続される。一例として、ネットワーク１１１のサービスは断続的なものであってもよく、他の例として、モバイル端末システム１０４がある種類の接続形態から別の種類のものへと移行（例えば、モビリティ管理サーバ１０２と有線相互接続１０９を通じて接続される状態からネットワーク１１１を通じて接続される状態へ移行、もしくはその逆）し、移行時に一時的に接続が切断されるという構成であってもよい。
【００５１】
モバイル端末システム１０４は、標準的なモバイル装置や市販のコンピュータであってよく、例えば、モバイル端末システム１０４は、市販のトランシーバおよび／またはネットワークカードを実装したラップトップコンピュータによって構成される。モバイル端末システム１０４は、標準的なネットワーク・アプリケーションや標準的なＯＳ（オペレーティングシステム）を実行し、標準的なトランスポート・レベル・プロトコル（例えばＴＣＰ／ＩＰ）を利用して、トランスポート層で通信を行うものであってよい。本発明において、さらに、モバイル端末システム１０４がクライアントソフトウェアを実行することで、遠隔プロシージャ・コール・プロトコルおよびインターネット・モビリティ・プロトコルを用いたモビリティ管理サーバ１０２との通信が可能になる。上記両プロトコルは、それらと同様のトランスポート・レベルのプロトコルを利用して伝送される。
【００５２】
モビリティ管理サーバ１０２は、ウィンドウズ（登録商標）ＮＴサーバなどの標準的なサーバによってホスティングされるソフトウェアを含んでいてよい。本好ましい実施形態では、モビリティ管理サーバ１０２は、規格に準拠したクライアント／サーバ型のインテリジェントサーバであって、企業ネットワーク１０８を透過性を有した状態でノマディック環境にまで延長するものである。モビリティ管理サーバ１０２は、数量を限定されないモバイル端末システム１０４それぞれのネットワーク・レベルでのプロキシとして機能するが、モビリティ管理サーバ１０２はこれを、それぞれのモバイル端末システムの状態を管理することと、ネットワーク・アプリケーションをホスティングしているどのピア・システム１１０とも、モバイル端末システム１０４とトランシーバ１０６との間のモバイル相互接続が断続的で信頼性が低いものであっても常時接続を維持してゆくために必要な、複雑なセッション管理を行うこととによって成し遂げている。
【００５３】
例えば、サーバ１０２はどのような標準的（例えばＴＣＰ／ＩＰベースの）ネットワーク・アプリケーションであっても、変更を行うことなしに、モバイル接続を通じて実行させることができる。接続が切断されたり、圏外に出たり、あるいは動作をサスペンドしたりしたモバイル端末システム１０４のセッションは、サーバ１０２によって維持され、該システムが復帰した際にはサーバ１０２が上記セッションをレジュームする。モバイル端末システム１０４が圏外に出てしまったり、シャットダウンしたり、あるいは位置アドレスを変更した場合、モビリティ管理サーバ１０２は、データの受信に関して確認応答し、モバイル端末システムが再度通信可能となるまで要求を待機させることで、モバイル端末システムとピア・システム１１０との接続を維持する。
【００５４】
サーバ１０２はまた、有線ネットワークにおける管理能力をモバイル接続にまで延長する。ネットワークソフトウェア層はそれぞれが互いに独立して動作するので、ソリューションをそれが展開されるそれぞれの環境に合わせてカスタマイズすることが可能である。
【００５５】
一例として、モビリティ管理サーバ１０２が、ローカルエリア・ネットワークやワイドエリア・ネットワークのような標準的な企業ネットワーク１０８と接続され、該ネットワーク１０８は、様々な固定端末システム（例えば一つ以上のホストコンピュータ１１０）１１０と接続される状況が考えられる。モビリティ管理サーバ１０２によって、モバイル端末システム１０４と固定端末システム１１０との間の、連続セッション型データストリームを利用した通信が可能となるが、この通信は、モバイル端末システム１０４が、接続しているネットワーク相互接続とのコンタクトを失ったり、あるネットワーク相互接続１０６、１０９、１１１から別のネットワーク相互接続へと移動したりしても（例えば、無線相互接続の場合、ある無線トランシーバ１０６のカバーエリア１０７から別のカバーエリアにローミングしても）、利用可能となっている。
【００５６】
モバイル端末システム１０４は、モビリティ管理サーバ１０２との結合を、スタートアップ時か、あるいはモバイル端末システムがネットワークサービスを要求した時に確立する。結合が確立されると、モバイル端末システム１０４は、一つ以上のネットワーク・アプリケーションのセッションを、連続的あるいは共時的に始めることができる。モバイル端末システム１０４−モビリティ管理サーバ１０２間の結合確立によって、モバイル端末システムが切断されたり、圏外に出たり、あるいはサスペンドしたりしても、モバイル端末システムにおけるアプリケーションのセッションを維持し、モバイル端末システムの復帰時には該セッションをレジュームすることが可能になる。本好ましい実施形態では上記の処理は完全に自動で行われ、ユーザによる介入は全く必要とされない。
【００５７】
本発明の一例において、モバイル端末システム１０４は、ＵＤＰ／ＩＰのような標準的なトランスポート・プロトコルを用いてモビリティ管理サーバ１０２と通信を行う。標準的なトランスポート・プロトコルを使用することで、モバイル端末システム１０４が、標準的なルータ１１２など企業ネットワーク１０８に既存のインフラを用いて、モビリティ管理サーバ１０２と通信することが可能になる。本発明では、高レベルの遠隔プロシージャ・コール・プロトコルが、トランザクションを、モバイル強化ネットワーク１０８を介して、標準的なトランスポート・プロトコルを使用して送られるメッセージへと生成する。本好ましい実施形態において、上記のようなモバイルＲＰＣメッセージは、モバイル端末システム１０４にて実行されるアプリケーションによって開始された、全てのネットワーク・トランザクションを含んでいるため、モビリティ管理サーバ１０２によって全てを完了させることができる。このことにより、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、ネットワーク媒体の接続性が阻害されているときでも、接続状態情報を常に互いにシンクロさせておくことができる。
【００５８】
モバイル端末システム１０４のそれぞれは、全てのネットワーク活動を傍受し、該ネットワーク活動をモバイルＲＰＣプロトコルを通じてモビリティ管理サーバ１０２にリレーするための情報をモバイル端末システム自体に提供するモビリティ管理ソフトウェアクライアントを実行する。本好ましい実施形態では、該モビリティ管理クライアントは、モバイル端末システム１０４に実装されているＯＳ（ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）ＣＥなど）と透過性を有する状態で協働して、クライアント側でのアプリケーションのセッションを、ネットワークとのコンタクトが失われても維持し続ける。
【００５９】
モビリティ管理サーバ１０２は、それぞれのモバイル端末システム１０４の状態を管理し、例えば接続の反対側の端に接続されたホストコンピュータ１１０のような通信相手のピア１０８との連続的な接続を維持するために必要とされる複合的なセッション管理を行う。モバイル端末システム１０４との通信ができなくなったり、モバイル端末システム１０４がサスペンドしたり、あるいはネットワークアドレスを変更したり（例えばあるネットワーク相互接続から別のものにローミングしたり）した場合、モビリティ管理サーバ１０２は、モバイル端末システム１０４とホストシステム１１０などの接続端との間の接続を、データ受信に関して確認応答したり、要求を待機させたりすることによって維持する。このプロキシ機能によって、ピアのアプリケーションは、モバイル端末システム１０４との物理的な接続が絶たれたことを検知することがなくなる。よって、もしモバイル端末システムが一時的に接続を失ったり、あるカバーエリア１０７Ｋ内において、あるネットワーク相互接続１０６Ａから別のネットワーク相互接続１０６Ｋへとローミングしたりした場合でも、（物理的接続が再確立された際に単純に作業をレジュームすることで）モバイル端末システム１０４のアプリケーションと、その結合しているセッションを実行する端との間の連続的な接続を効果的に維持することができる。
【００６０】
モビリティ管理サーバ１０２はまた、モバイル端末システム１０４がセグメント化されたネットワークの様々な部分をローミングする際、異なったネットワークアドレスを受信するという問題を解決するべく、アドレスを管理することが可能となっている。モバイル端末システム１０４はそれぞれ、プライマリネットワーク上での仮想アドレスを有している。該仮想アドレスは、標準的なプロトコルによって、あるいは静的割り当てによって決定されている。モバイル端末システム１０４のそれぞれについて、モビリティ管理サーバ１０２は該システムの現状における実際の（位置）アドレスに対応して仮想アドレスを割り当てる。モバイル端末システム１０４の、あるネットワーク・セグメントから他のセグメントへの移動に伴って、該システム１０４の現在位置アドレスが変更されても、仮想アドレスは、どの接続がアクティブになっていようが、接続時間が長くなっていようが、上記アドレスが静的に割り当てられている限りは一定となる。
【００６１】
よって、モバイル端末システム１０４の位置アドレスの変更は、モビリティ管理サーバ１０２を介して、結合しているホストシステム１１０（および他のピア）におけるセッションを実行する端からは完全に透過性を有する状態となっている。ピア１１０から見えるのは、サーバ１０２によってプロキシされた（不変の）仮想アドレスのみということになる。
【００６２】
本好ましい実施形態では、モビリティ管理サーバ１０２はさらに、コンソール（制御）アプリケーションと包括的なメトリクス（ｅｘｈａｕｓｔｉｖｅ ｍｅｔｒｉｃｓ）とによる、集中的なシステム管理が可能である。システム管理者は、上記のツールを利用して、遠隔接続を設定、管理し、遠隔接続およびシステムにおける問題を解決することができる。
【００６３】
モビリティ管理サーバ１０２によるプロキシ・サーバ機能によって、ネットワーク・アプリケーション、ユーザ、そして装置にそれぞれ異なった優先レベルを設定することができるようになる。これは、モビリティ管理サーバ１０２が有する処理用のリソースが有限であることを鑑みれば、有用なものである。システム管理者が上記のようにモビリティ管理サーバ１０２の設定を変更できることで、システムおよびネットワークのパフォーマンスが全体として向上する。一例として、システム管理者がモビリティ管理サーバ１０２の設定を変更できることにより、音声や映像のストリーミングのようなリアルタイムのアプリケーションに対して、モビリティ管理サーバ１０２のリソースを、あまりリソースを使用しないメールソフトのようなアプリケーションよりも多く割り当てることができる。
【００６４】
詳しく説明すると、モビリティ管理サーバ１０２は、アプリケーション、もしくはＳＮＭＰのような標準的なネットワーク管理プロトコル、ウェブベースの設定インターフェイス、ローカルなユーザインターフェイスなどのアプリケーション・インターフェイスを介して設定される。結合（ａｓｓｏｃｉａｔｉｏｎ）そのものの優先度、および／または、ある結合における複数のアプリケーションの優先度を設定することも可能である。例えば、モビリティ管理サーバ１０２を介して動作する他の結合と関連している結合それぞれの優先度は、ユーザあるいは装置ごとに設定可能である（本実施形態では、ユーザおよびユーザがログインした装置の両方を優先するように設定された場合に、ユーザに関する設定のほうがより優先されるように設定されてもよい）。あるいは結合それぞれについて、アプリケーションの優先度に関し、ネットワーク・アプリケーションごとにいくつかのレベルが設定されていてもよい。本システムでは、優先レベルはいくつでも設定することが可能である。一例として、低、中、高の３つの優先レベルが設定される例が考えられる。
【００６５】
（サーバ／クライアント型ソフトウェア・アーキテクチャの例）
図２に、モバイル端末システム１０４とモビリティ管理サーバ１０２とのソフトウェア・アーキテクチャの一例を図示する。本発明の一例において、モバイル端末システム１０４とモビリティ管理サーバ１０２は標準的なＯＳおよびアプリケーション・ソフトウェアを実行するが、このときに、ほんの少数のコンポーネントを新しく追加するだけで、断続的に接続されるモバイルネットワーク１０８を介した、信頼性が高くかつ効果的、持続的なセッションが実行可能となっている。図２に示すように、モバイル端末システム１０４は、ネットワーク・インターフェイス・ドライバ２００、ＴＣＰ／ＵＤＰトランスポートサポート２０２、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４、および一つ以上の従来型のネットワーク・アプリケーション２０８に対するインターフェイスとして使われるソケットＡＰＩ２０６を含む、従来型のＯＳソフトウェアを実行する。従来型のネットワーク・ファイル／プリント・サービス２１０が、従来型のＴＤＩ２０４との通信用にさらに設けられていてもよい。サーバ１０２は、上記と類似した、従来型のネットワーク・インターフェイス・ドライバ２００’、ＴＣＰ／ＵＤＰトランスポートサポート２０２’、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４’、および一つ以上の従来型のネットワーク・アプリケーション２０８’に対するインターフェイスとして使われるソケットＡＰＩ２０６’を有していてもよい。モバイル端末システム１０４とモビリティ管理サーバ１０２はそれぞれ、さらにネットワーク／セキュリティ・プロバイダ２３６（モバイル端末システム）、ユーザ／セキュリティ・データベース２３８（サーバ）を備えていてもよい。
【００６６】
本発明では、新規のモバイル・インターセプタ・コンポーネント２１２が、モバイル端末システム１０４のソフトウェア・アーキテクチャにおける、ＴＣＰ／ＵＤＰトランスポートモジュール２０２とトランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４との間に挿入されている。該モバイル・インターセプタ・コンポーネント２１２は、トランスポート・ドライバ・インターフェイス（ＴＤＩ）２０４における特定のコールを傍受して、該コールを、ネットワーク１０８を介し、ＲＰＣおよびインターネット・モビリティ・プロトコル、標準的なＴＣＰ／ＩＰトランスポート・プロトコルを通じてモビリティ管理サーバ１０２へと転送する。こうして、モバイル・インターセプタ２１２は、全てのネットワーク活動を傍受して、サーバ１０２へと転送することができる。該インターセプタ２１２はＯＳと透過性を有する状態で協働するので、モバイル端末システム１０４がネットワーク１０８とのコンタクトを失っても、クライアント側のアプリケーションのセッションはアクティブであり続けることができる。
【００６７】
モバイル・インターセプタ２１２は、トランスポート・ドライバ・インターフェイス２０４とは違うレベルで（例えばソケットＡＰＩ２０６のレベルで）動作することもできるが、ＴＤＩのレベルでモバイル・インターセプタ２１２が動作する、より詳細にはいずれかのトランスポート・プロトコル・インターフェイスにおいて動作することにより、下記のような利点が生まれる。なお、便宜的に、トランスポート・ドライバ・インターフェイスを示す全てのものをＴＤＩという略語で表わすこととする。多くの標準的なＯＳ（例えば、マイクロソフト社のウィンドウズ（登録商標）９５、ウィンドウズ（登録商標）９８、ウィンドウズ（登録商標）ＮＴ、ウィンドウズ（登録商標）ＣＥなど）はＴＤＩインターフェイス２０４を実装しているので、ＯＳのコンポーネントを変更することなく互換性が保証される。さらに、トランスポート・ドライバ・インターフェイス２０４は通常カーネル・レベルのインターフェイスであることから、ユーザモードへの切り替えが必要でなく、これにより性能を向上させることができる。
【００６８】
さらに、ＴＤＩインターフェイス２０４のレベルで作動するモバイル・インターセプタ２１２は、様々な別のネットワーク・アプリケーション２０８（例えば複数の同時に動作しているアプリケーション）に加えて、ネットワークにおけるファイル、プリント、および他のカーネル・モードなどのサービス２１０（インターセプタが例えばソケットＡＰＩ２０６のレベルで動作している場合はそれぞれ別に扱う必要がある）を傍受することができる。
【００６９】
図２Ａに、どのようにインターセプタ２１２が動作するかを示す高レベルのフローチャートの一例を示す。モバイル端末システム１０４のＴＤＩインターフェイス２０４へのコール（ブロック２５０）は、モバイル・インターセプタ２１２によって傍受される（ブロック２５２）。モバイル・インターセプタ２１２によって傍受されたＲＰＣコールはインターネット・モビリティ・プロトコルに準拠してフラグメントにパッケージ化され、該フラグメントはデータグラムとして、ＵＤＰやＴＣＰといった標準的なトランスポート・プロトコルにより、ＬＡＮ、ＷＡＮ等のトランスポート１０８を介してモビリティ管理サーバ１０２へと送られる（ブロック２５２）。モビリティ管理サーバ１０２は受信したＲＰＣデータグラムをアンパックして（ブロック２５４）、要求されたサービスを実行する（例えば、データや応答を、固定端末システム１１０で動作するアプリケーションサーバ処理へと転送することで、モバイル端末システムのアプリケーション２０８のプロキシとして振舞う）。
【００７０】
再び図２に戻って、モビリティ管理サーバ１０２は、従来型のネットワーク・インターフェイス・ドライバ２２２を介して送られる、モバイル端末システム１０４からの、あるいはモバイル端末システム１０４へ向かうメッセージを傍受する、アドレス変換部２２０を有している。例えば、アドレス変換部２２０は、セッションの相手のピア（固定端末システム１１０）からのモバイル端末システム１０４の仮想アドレス宛のメッセージを認識する。モバイル端末システムへの該メッセージはプロキシ・サーバ２２４へと送られる。プロキシ・サーバ２２４は仮想アドレスとメッセージとを待機していたトランザクションに割り当て、該応答を、上記モバイル端末システム１０４の現在位置アドレスへと転送する。
【００７１】
さらに、図２によると、モビリティ管理サーバ１０２は、アドレス変換部（中間ドライバ）２２０とプロキシ・サーバ２２４に加えて、設定マネージャ２２８、操作／ユーザインターフェイス２３０、およびモニタ２３２を有している。設定マネージャ２２８は設定情報とパラメータとを提供して、プロキシ・サーバ２２４が接続の管理を行えるようにする。操作／ユーザインターフェイス２３０とモニタ２３２により、ユーザとプロキシ・サーバ２２４との間のやりとりが可能になる。
【００７２】
（モバイル・インターセプタ）
図３は、本発明のＲＰＣプロトコルとインターネット・モビリティ・プロトコルとをサポートしたモバイル・インターセプタ２１２のソフトウェア・アーキテクチャの一例を示す。本例では、モバイル・インターセプタ２１２は、遠隔プロシージャ・コール・プロトコル・エンジン２４０と、インターネット・モビリティ・プロトコル・エンジン２４４の、二つの機能コンポーネントを有している。モビリティ管理サーバ１０２において動作するプロキシ・サーバ２２４によって、対応するエンジン２４０’、２４４’が用意される。
【００７３】
このように、本好ましい実施形態におけるモバイル・インターセプタ２１２は、モビリティ管理サーバ１０２をそれぞれのモバイル端末システム１０４と接続するための、遠隔プロシージャ・コール・プロトコルと、インターネット・モビリティ・プロトコルとをサポートしている。遠隔プロシージャ・コールは、あるローカルシステムから、離れた別のシステムにおけるプロシージャを発動する処理を可能とするものである。一般的に、ローカルシステムは遠隔のシステムにおいてプロシージャ・コールが実行されたことを感知しない。ＲＰＣプロトコルの利用によって、モバイル端末システム１０４が、アクティブなネットワークセッションを失うことなく、圏外に出たり、操作をサスペンドしたりすることが可能になる。セッションの維持に特別なアプリケーションは必要とされないので、モバイル環境にあるネットワーク１０８において、市販のアプリケーションが何の変更も必要とせずに動作することになる。
【００７４】
ネットワーク・アプリケーションは、一般的に、ウィンドウズソケット（Ｗｉｎｄｏｗｓ ｓｏｃｋｅｔｓ）のようなアプリケーションレベルのインターフェイスを利用している。アプリケーションレベルのＡＰＩへの単一のコールによって、トランスポート層もしくはメディア・アクセス層における複数の送信および受信データパケットが生成される。優先されるモバイルネットワークで、もし上記のパケットのうちの一つが失われた場合、接続全体の状態が不安定になってセッションは中止されるが、本発明の好ましい実施形態はＲＰＣを備えており、モビリティ管理サーバ１０２とモバイル端末システム１０４とは、物理的な接続が絶たれたときであっても、常に統一された論理リンクを維持するために、接続状態に関する情報を共有している。
【００７５】
本発明のインターネット・モビリティ・プロトコルは、有線のネットワークと無線など他の信頼性の劣るネットワークとの相違点を補償する。フレームサイズとプロトコルのタイミングとが修正されることで、モバイル環境を考慮しないトランスポートと比較して性能が著しく向上し、ネットワークのトラフィックを大幅に減少することができる。このことは、帯域幅に制限がある場合やバッテリーの寿命が問題となる場合に重要となる。
【００７６】
また、本発明のインターネット・モビリティ・プロトコルは、公共の有線ネットワークを通じて、もしくは無線によってモビリティ管理サーバ１０２とモバイル端末システム１０４との間の通信がなされる際の、機密情報のセキュリティを保証する。インターネット・モビリティ・プロトコルは、認証された装置のみが企業ネットワークにアクセスすることを許可することで、基本的なファイアウォールとしての機能を果たす。本発明のインターネット・モビリティ・プロトコルはさらに、モビリティ管理サーバ１０２とモバイル端末システム１０４との間での全ての通信を認証、暗号化することを可能にする。
【００７７】
図３のモバイル端末システム１０４における遠隔プロシージャ・コール・プロトコル・エンジン２４０は、ＴＤＩコールパラメータをマーシャリングし、データをフォーマットし、要求を、ＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’がコールを実行するモビリティ管理サーバ１０２まで転送するべく、インターネット・モビリティ・プロトコル・エンジン２４４に送る。モバイル端末システム１０４は、遠隔プロシージャ・コール・プロトコルに基づいてＴＤＩコールパラメータをマーシャリングする。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’が上記のＲＰＣを受信すると、モビリティ管理サーバ１０２はモバイル端末システム１０４に代わってコールを実行する。モビリティ管理サーバ１０２のＴＤＩ遠隔プロシージャ・コール・プロトコル・エンジン２４０’は、接続されたモバイル端末システムそれぞれにおける完全なネットワークの状態を、ピアであるモバイル端末システム１０４のＲＰＣエンジン２４０と共有する。モバイル端末システム１０４の代理としての遠隔プロシージャ・コール実行に加え、サーバのＲＰＣエンジン２４０’は、システムフローの管理、遠隔プロシージャ・コールの解析、仮想アドレスの（アドレス変換機構２２０が行うサービスに対応した）多重化、遠隔プロシージャ・コールのトランザクションの優先順位付け、スケジューリング、ポリシー実行、および融合処理（ｃｏａｌｅｓｃｉｎｇ）を行う。
【００７８】
インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の高いデータグラムサービス、順位付け、フラグメント化、およびメッセージの再組立を行う。また、設定すれば、認証、データ暗号化、プライバシー保護強化、セキュリティ、そしてスループットのための圧縮も行うことができる。インターネット・モビリティ・プロトコル・エンジン２４４は、電力消費を考慮に入れる必要のある環境において、複数の異なるトランスポートを利用して機能するようになっているので、消費電力管理を意識したものであるとともに、各トランスポートに対して独立となっている。
【００７９】
図３Ａは、モバイル・インターセプタ２１２がモビリティ管理サーバ１０２と通信してＴＤＩコールのやり取りを行う処理を例示する。一般的に、モバイル・インターセプタ２１２のＲＰＣプロトコル・エンジン２４０は、マーシャリングされたＴＤＩコールを、モビリティ管理サーバ１０２へと送るべく、インターネット・モビリティ・プロトコル・エンジン２４４へと転送する。ＲＰＣプロトコル・エンジン２４０は、この作業を、インターネット・モビリティ・プロトコル・エンジン２４４によって管理されるキューにＲＰＣコールを加えることで達成する（ブロック３０２）。帯域幅管理を円滑に行うために、インターネット・モビリティ・プロトコル・エンジン２４４は受信したＲＰＣコールの転送を所定の期間（ＲＰＣ融合タイムアウト期間）遅延させる（ブロック３０４）。一般的に、ＲＰＣ融合タイムアウトは５ミリ秒から１５ミリ秒の間に設定されるが、この数値はユーザによって変更可能である。この遅延によって、ＲＰＣエンジン２４０はＴＤＩコールをインターネット・モビリティ・プロトコル・エンジン２４４のキューに加えて、一つ以上のＲＰＣコールが同一のデータグラム（フラグメント）によって転送されるようにすることができる。
【００８０】
融合タイムアウトが終了するか、ＲＰＣエンジン２４０がそれ以上のＲＰＣコールの受信を拒否する（判定ブロック３０６）ことを決定すると、ＲＰＣエンジン２４０は、インターネット・モビリティ・プロトコル・エンジン２４４に、キューをフラッシュ（ｆｌｕｓｈ）し、ＲＰＣコールを単一のフレームに融合し、該フレームをピアに転送するよう要求する（ブロック３０８）。この融合により伝送回数が減少し、プロトコルのパフォーマンスが高められる。しかし、インターネット・モビリティ・プロトコルは、パフォーマンス最適化のために他の外部基準に基づいてキュー２４４をフラッシュすることもしなければならず、本好ましい実施形態において、単一のＲＰＣ要求でフレーム全体が占められてしまう場合、ＩＭＰ層は自動的に要求をピアに送るよう試みる。
【００８１】
上記のように、モビリティ管理サーバ１０２のプロキシ・サーバはＲＰＣプロトコル・エンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’とを有している。図３Ｂは、モバイル端末システム１０４からインターネット・モビリティ・プロトコル・メッセージ・フレームを受信した際に、モビリティ管理サーバ１０２で実行される処理を例示している。該フレームをモビリティ管理サーバ１０２が受信すると、インターネット・モビリティ・プロトコル・エンジン２４４’は、フレームが（基礎となるトランスポートの最大伝送量の制約で）フラグメント化されていれば再構築し、メッセージの内容を逆多重化して、どのモバイル端末システム１０４からの受信かを決定する。この逆多重化により、インターネット・モビリティ・プロトコル・エンジン２４４’は、遠隔プロシージャ・コール・プロトコル・エンジン２４０’に、的確な結合関連文脈情報（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｃｏｎｔｅｘｔ ｉｎｆｏｒｍａｔｉｏｎ）を伝えることができる。
【００８２】
続いて、インターネット・モビリティ・プロトコル・エンジン２４４’は、受信したメッセージを、ＲＰＣ受信示唆システム作業要求（ＲＰＣ ｒｅｃｅｉｖｅ ｉｎｄｉｃａｔｉｏｎ ｓｙｓｔｅｍ ｗｏｒｋ ｒｅｑｕｅｓｔ）３５４にして、該作業要求と結合関連文脈情報を、モビリティ管理サーバ１０２のＲＰＣプロトコル・エンジン２４０’に与える。ＲＰＣプロトコル・エンジン２４０’が作業要求３５２を受信すると、該エンジン２４０’は作業要求３５２を結合関連作業キュー３５６に加え、次に予定済みの要求をグローバルキュー３５８に送ることによって、結合処理のスケジューリングが行われる。続いて、ＲＰＣエンジン２４０’のメイン作業スレッドに、作業が実行可能となったことが伝えられる。該メインスレッドが作業を始めると、グローバルキュー３５８がポーリングされて、待機状態となっているスケジューリングされた結合処理が確認される。その後、メインスレッドは該イベントを待機状態から外し、結合関連作業キュー３５６が処理される。
【００８３】
結合関連作業キュー３５６から、上記メインスレッドはそれまで待機していたＲＰＣ受信示唆作業要求を見つけ出す。次に、メインスレッドはＲＰＣ受信示唆作業要求３５６をキューから外し、該要求を解析する。図３Ａを参照して説明した上記融合処理により、モビリティ管理サーバ１０２は、それぞれのデータグラムに内包された複数のＲＰＣトランザクションを頻繁に受信することになる。モビリティ管理サーバ１０２は次に、該ＲＰＣトランザクションをそれぞれ逆多重化して別個の遠隔プロシージャ・コールに戻し、そして要求された機能をモバイル端末システム１０４に代わって実行する。パフォーマンス向上のため、ＲＰＣエンジン２４０’に、ＲＰＣメッセージ解析処理中の先読みメカニズムを備えさせて、ＲＰＣエンジン２４０’が、要求されたトランザクションのうちのいくつかを同時に実行できるか否か（パイプライン処理できるか否か）を確認してもよい。
【００８４】
（ＲＰＣエンジン２４０’によるＲＰＣ結合の実行手法）
図４は、結合作業キュー３５６に加えられたＲＰＣ結合を実行する処理を例示したフローチャートである。ＲＰＣ結合の実行が予定されている時、ＲＰＣプロトコル・エンジン２４０’（状態機械として設けられていてもよい）のメインスレッドは、グローバルネットワークキュー３５８からの作業要求を待機状態から外し、作業要求の種類を決定する。
【００８５】
本実施形態のＲＰＣ作業要求は、以下のような６つの基本的な種類に分けられる。
【００８６】
・スケジューリング要求（ｓｃｈｅｄｕｌｅ ｒｅｑｕｅｓｔ）
・接続示唆
・切断示唆
・ローカル結合中止（ｌｏｃａｌ ｔｅｒｍｉｎａｔｅ ａｓｓｏｃｉａｔｉｏｎ）
・「リソース使用可」要求（”ｒｅｓｏｕｒｃｅ ａｖａｉｌａｂｌｅ” ｒｅｑｕｅｓｔ）
・ｐｉｎｇ休止タイムアウト（ｐｉｎｇ ｉｎａｃｔｉｖｉｔｙ ｔｉｍｅｏｕｔ）
ＲＰＣプロトコル・エンジン２４０’は、上記の様々な種類の要求をそれぞれ別の方法で取り扱う。ＲＰＣプロトコル・エンジン２４０’は要求の種類（グローバルキュー３５８に記憶された、要求に関する情報によって識別される）をテストして、該要求をどう処理するかを決定する。
【００８７】
作業要求の種類が「スケジューリング要求」である場合（判定ブロック３６０）、ＲＰＣプロトコル・エンジン２４０’はどの結合が予定されているかを判別する（ブロック３６２）。ＲＰＣプロトコル・エンジン２４０’はこの判別を、グローバルキュー３５８に記憶されている情報に基づいて実行することができる。上記判別がなされると、ＲＰＣプロトコル・エンジン２４０’が、それぞれが対応する要求を記憶している結合作業キュー３５６（１）〜３５６（ｎ）のうちの一つを特定することが可能となる。ＲＰＣエンジン２４０’によって、対応する結合制御ブロックが取得され（ブロック３６２）、結合作業処理タスク（Ｐｒｏｃｅｓｓ Ａｓｓｏｃｉａｔｉｏｎ Ｗｏｒｋ ｔａｓｋ）３６４が呼び出されて、上記の特定された作業キュー３５６における作業の処理が始められる。
【００８８】
図５は、図４の「結合作業処理」タスク３６４によって実行されるステップを例示している。結合が特定されると、「結合作業処理」タスク３６４が呼び出され、対応する結合作業キュー３５６内の作業が処理される。待機状態から外された作業要求（ブロック３９０）がＲＰＣ受信要求（判定ブロック３９２）である場合、該ＲＰＣ受信要求はＲＰＣ構文解析部（ｐａｒｓｅｒ）に送られ、処理される（ブロック３９４）。あるいは、待機状態から外された作業要求（ブロック３９０）が、保留中の（ｐｅｎｄｉｎｇ）受信要求である場合（判定ブロック３９６）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーションによる接続の代わりにデータを受信し始めるよう要求する（ブロック３９８）。上記待機状態から外された作業要求が、保留中の接続要求である場合（判定ブロック４００）、ＲＰＣエンジン２４０’はＴＤＩ２０４’に、アプリケーション用途ＴＣＰ（あるいは他のトランスポート・プロトコル）接続要求を発するよう要求し（ブロック４０２）、ＴＤＩ層２０４’からの応答を待つ。ＴＤＩ２０４’による要求が完了すると、該要求の状態が決定されて、元の要求エンティティへと報告が戻される。パフォーマンス向上のため、ＲＰＣエンジン２４０’は、実際に要求を発しているピアへエラーを通知する前に、要求を結合関連作業キュー（３５６）へと戻すことで、接続要求処理を複数回行うようになっていてもよい。この処理も、ネットワーク帯域幅およびリソースの消費を減らすためのものである。
【００８９】
上記の処理は、「スケジューリング重み付け」（ｓｃｈｅｄｕｌｉｎｇ ｗｅｉｇｈｔ ｃｏｍｐｌｅｔｅ）テスト（ブロック４０４）にパスするまで繰り返される。本例では、スケジューリング重みは、どれだけの作業要求が待機状態から外されて、上記の特定の結合がどれだけ処理されるかを決定するのに使われる。該スケジューリング重みは設定マネージャ２２８によって設定されるパラメータであり、結合接続示唆が検出されたときに取得される（図４、ブロック３７２）。この数値はユーザごとに、あるいは物理的な意味での装置ごとに設定可能である。
【００９０】
ＲＰＣエンジンが結合作業キュー３５６の作業を（少なくとも一時的に）終了した後、ディスパッチ・キューの処理に移ってもよい（ブロック４０６）（詳細は以下）。結合の作業キュー３５６における作業の処理後、ＲＰＣエンジン２４０’は、グローバル作業キュー３５８に新たなスケジューリング要求を発信して、後で実行される結合のスケジューリングを再び行う（図４の判定ブロック３６６、ブロック３６８、図５の判定ブロック４０８、ブロック４１０）。
【００９１】
再度図４を参照すれば、ＲＰＣ作業要求が「接続示唆」の場合（判定ブロック３７０）、ＲＰＣエンジン２４０’に、モバイル・ピア（通常はモバイル端末システム１０４だがこれに限らない）との新たな接続のインスタンスを作成せよという要求が入る。一例として、上記接続示唆により、接続を開始しようとしているピアの装置に関する以下のような情報がＲＰＣエンジン２４０’に与えられる。
【００９２】
・装置の物理的識別子
・該装置にログインしているユーザ名
・ピアの装置のアドレス
・ピアのＲＰＣエンジン２４０からの、付加的な接続データ
接続示唆（判定ブロック３７０）を受け、ＲＰＣエンジン２４０は上記のパラメータをもって設定マネージャ２２８をコールする。設定マネージャ２２８は該パラメータを用いて、上記新規接続の設定を確定する。この設定（例えば結合スケジューリング重みや、上記に加えてデフォルトでないスケジューリング特性を要するアプリケーション全てのリストなど）は、ＲＰＣエンジン２４０’に戻されて記憶、実行される。そしてＲＰＣエンジン２４０’は新規の結合を開始し、新規の結合制御ブロックを形成する（ブロック３７２）。図５Ａが示すように、以下のような動作が実行されてもよい。
【００９３】
・結合制御ブロックを割り当てる（ブロック３７２Ａ）
・システム全体のリソースをデフォルトにまで初期化する（ブロック３７２Ｂ）
・現在の設定をオーバーライドする（ブロック３７２Ｃ）
・フラグを初期化する（ブロック３７２Ｄ）
・結合特有作業キューを初期化する（ブロック３７２Ｅ）
・結合のオブジェクト・ハッシュ・テーブルを初期化する（ブロック３７２Ｆ）
・融合タイマーを初期化する（ブロック３７２Ｇ）
・結合制御ブロックをセッションテーブルに挿入する（ブロック３７２Ｈ）
インターネット・モビリティ・プロトコル・エンジン２４４’が結合を終了しなければならないと判断すると、「切断示唆」が該インターネット・モビリティ・プロトコル・エンジン２４４’からＲＰＣエンジン２４０’に出される。ＲＰＣエンジン２４０’はこの切断示唆をテストし（ブロック３７４）、示唆に応じて結合を停止し、結合制御ブロックを破棄する（ブロック３７６）。図５Ｂに示されるように、以下のステップが実行されてもよい。
【００９４】
・待機中の作業がこれ以上処理されないように、停止される結合をマークする（ブロック３７６Ａ）
・処理を含む、結合されている全ての結合オブジェクトをクローズする（ブロック３７６Ｂ）
・作業キューにある全てのエレメントを開放する（ブロック３７６Ｃ）
・融合タイマーが動作中ならば停止する（ブロック３７６Ｄ）
・結合制御ブロックの参照カウントを減少させる（ブロック３７６Ｅ）
・参照カウントが０の場合、（ブロック３７６Ｆにてテストされる）
・結合関連作業キューを破棄し、
・オブジェクト・ハッシュ・テーブルを破棄し、
・融合タイマーを破棄し、
・結合テーブルから結合制御ブロックを取り除き、
・制御ブロックを開放する（３７６Ｇ）
システム１０２が結合終了の必要性を認識すると、「セッション中止」要求が出される。この要求はシステム管理者、ＯＳ、あるいはアプリケーションから発される。ＲＰＣエンジン２４０’は、セッション中止要求を上記切断示唆と同様に扱う（判定ブロック３７８、ブロック３７６）。
【００９５】
本好ましい実施形態では、ＲＰＣエンジン２４０’とインターネット・モビリティ・プロトコル・エンジン２４４’との間のインターフェイスが、クレジット（ｃｒｅｄｉｔｓ）を基にフロー制御メカニズムを特定する。ある単一のスレッドが別のスレッドに作業要求を通知するたびに、コールされたスレッドは作業キューに残っているクレジットの数に戻る。キューが満杯であればクレジットのカウントは０になるが、慣例として、コールする側のスレッドは、クレジットのカウントが０ならばそれ以上作業通知をしない。よって、ユーザによって設定可能あるいは所定の最低点（ｌｏｗ−ｗａｔｅｒ ｍａｒｋ）をキューに付けて、待機中であった作業が処理されてリソースに余裕ができたことを、上記コールする側のスレッドに伝えるような構成が必要となる。これが、「リソース使用可」作業示唆が設けられている理由である（判定ブロック３８０にてテストされる）。図５Ｃが示すように、クレジットのカウントが０になったとき、以下のようなステップが実行されてもよい。
【００９６】
・ＲＰＣ＿ＬＭＰＱ＿ＳＥＮＤ＿ＦＬＡＧと設定して、結合に「ロー・マーク保留」（ｌｏｗ ｍａｒｋ ｐｅｎｄｉｎｇ）とマークを付ける（ブロック３７９Ａ）。この状態になったら、
・受信された全てのデータグラムを破棄する（ブロック３７９Ｂ）
・データ受信を拒否して全ての受信されたストリーム・イベントを抑える（ブロック３７９Ｃ）（これにより、ＴＣＰ他のトランスポート受信ウィンドウが結果的に閉じられ、固定端末システム１１０とモビリティ管理サーバ１０２との間のフロー制御がなされる。復帰の前に、本好ましい実施形態では「保留受信要求」（ｐｅｎｄｉｎｇ ｒｅｃｅｉｖｅ ｒｅｑｕｅｓｔ）を結合関連作業キュー３５６の前に押し込むので、保留中のストリーム受信イベントの処理（ｏｕｔｓｔａｎｄｉｎｇ ｓｔｒｅａｍ ｒｅｃｅｉｖｅ ｅｖｅｎｔ ｐｒｏｃｅｓｓｉｎｇ）が、リソースが利用可能になると直ちに継続される）。
【００９７】
・全ての受信された接続イベントが、受動接続のために拒否される（ブロック３７９Ｄ）
「リソース使用可」示唆をＲＰＣエンジン２４０’が受け取ると（図４、判定ブロック３８０）、該ＲＰＣエンジンは、結合された結合作業キュー３５６に待機中の作業があるか否かを判定する。もしあれば、ＲＰＣエンジンは該結合についてグローバル作業キュー３５８に通知して、上記結合作業キュー３５６が動作の優先権を持つことをマークしておく（ブロック３８２）。保留中の受信要求が、結合が保留受信要求状態にある期間に通知された場合、この期間中に処理される（本好ましい実施形態では、ＲＰＣエンジン２４０’は、この処理中も全ての受信された接続要求を受け入れる）。
【００９８】
再度図４を参照すると、ＲＰＣエンジン２４０’が、モビリティ管理サーバ１０２の「ｐｉｎｇ」に使われるチャネルが所定の期間にわたって休止していると判定した場合（判定ブロック３８４）、該チャネルは閉じられ、リソースは開放されてシステムに復帰し、他の処理に使用される（ブロック３８６）。
【００９９】
（ＲＰＣ構文解析と優先キュー）
再度図５を参照すると、ＲＰＣエンジンがＲＰＣ受信要求をその受信に際して構文解析することは前述した（ブロック３９２、３９４参照）。本好ましい実施形態において、構文解析は以下の点で必要とされる。即ち、受信された単一のデータグラムが複数のＲＰＣコールを含む可能性があるからであり、また、ＲＰＣコールがインターネット・モビリティ・プロトコルのデータグラムにおける複数のフラグメントにまで広がっている可能性があるからである。ＲＰＣ受信作業要求５００のフォーマットの例が図６に示される。ＲＰＣ受信作業要求のそれぞれは、少なくともメイン・フラグメント５０２（１）を有し、加えて任意の数の付加的フラグメント５０２（２）〜５０２（Ｎ）を有していることもある。メイン・フラグメント５０２（１）は、作業要求構造ヘッダ（ｗｏｒｋ ｒｅｑｕｅｓｔ ｓｔｒｕｃｔｕｒｅ ｈｅａｄｅｒ）５０３と、受信オーバーレイ５０４とを有している。受信オーバーレイ５０４は、インターネット・モビリティ・プロトコル・エンジン２４４によってメイン・フラグメント５０２（１）の先頭に設けられた受信オーバーレイである。この受信オーバーレイ５０４には、ｐユーザデータと呼ばれる、作業要求５００内で最初のＲＰＣコール５０６（１）を指し示す構造メンバがある。
【０１００】
図６の例に、複数のＲＰＣコール５０６（１）、５０６（２）…５０６（８）を含む、作業要求５００が図示されている。図６の例が示すように、ＲＰＣ作業要求５００は、メモリの隣接するブロックや単一のフラグメント５０２に含まれていなくてもよい。同例において、第二フラグメント５０２（２）と第三フラグメント５０２（３）とは、リンクしたリスト中でメイン・フラグメント５０２（１）に連鎖されている。
【０１０１】
よって、上記例のＲＰＣパーサ３９４は以下の境界条件を取り扱う。
【０１０２】
・ＲＰＣ受信要求５００それぞれが一つ以上のＲＰＣコールを含んでもよい
・一つ以上のＲＰＣコール５０６が、単一のフラグメント５０２中に存在してもよい
・ＲＰＣコール５０６それぞれが、フラグメント５０２中に完全に含まれていてもよい
・ＲＰＣコール５０６それぞれは、一つ以上のフラグメント５０２にまたがっていてもよい
図７は、ＲＰＣ受信作業要求５００を解析するＲＰＣ構文解析部３９４を例示している。本例において、ＲＰＣ構文解析部３９４は作業要求中の第一フラグメント５０２（１）を取得し、該フラグメント中の第一ＲＰＣコール５０６（１）を取得し、そしてＲＰＣコールを解析する。構文解析部３９４はＲＰＣ受信作業要求５００中を進んで、ＲＰＣコール５０６それぞれを処理していく。ＲＰＣ受信作業要求５００のフラグメント５０２（１）の残りのフラグメント・バイト数が、ＲＰＣヘッダ５０３のサイズよりも多い場合、構文解析部３９４は、ＲＰＣコールが完全にＲＰＣフラグメント５０２に含まれていて、処理を実行してもよいかどうかを判定する（該判定は、ＲＰＣコールの長さが残りのフラグメント・バイト数より大きいかどうかをテストすることでなされてもよい）。ＲＰＣコールの種類が連鎖例外である場合、ＲＰＣコールはＲＰＣ構文解析部３９４のアップデートを行うことになる。プロキシ・サーバ２２４において、連鎖例外であるＲＰＣコールは「データグラム送信」と「ストリーム送信」だけである。この連鎖例外プロシージャによって、ＲＰＣエンジンは、ＲＰＣ送信コールのためにメモリ記述子リストを共に連鎖することによるフラグメントコピーを避けることができる。
【０１０３】
構文解析部３９４がＲＰＣコールの種類を判別すると、ＲＰＣ情報の始めへのポインタは、実行のためにＲＰＣエンジン２４０へと転送される。ＲＰＣエンジンは、実行のために全てのＴＤＩプロシージャ・コールにそれぞれ別の優先順位をつける。最も優先度の高いコールは、ＲＰＣディスパッチャ３９５へ転送され、直ちに処理される。これより下の優先順位のコールは、後に処理されるために全てディスパッチ・キュー５１０にディスパッチされる。ディスパッチ・キュー５１０はそれぞれ離散的な優先度を表わしている。
【０１０４】
本実施形態では、モバイル・アプリケーションは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクト機能を、他のＴＤＩネットワーキング機能を実行する前に呼び出す。よってシステムは、「オープンアドレス」オブジェクトおよび「オープン接続」オブジェクトの呼び出し中に、アプリケーションレベルの優先順位を割り当てることになる。例示の実施形態では、アドレスまたは接続オブジェクトに優先順位が付けられると、該オブジェクトに関連する全てのコールが、その割り当てられた優先順位中に実行される。
【０１０５】
例えば、ＲＰＣコールがＴＤＩオープンアドレスオブジェクト要求あるいはＴＤＩオープン接続オブジェクト要求である場合、該コールは直ちに実行されるべくＲＰＣディスパッチャ３９５に送られる。オープンアドレスおよびオープン接続オブジェクトＲＰＣコールにより、上記の接続示唆中に行われる設定要求の間に設定マネージャ２２８からもたらされる情報との対応に用いられる、処理ＩＤあるいは処理名へのアクセスが可能になる。該処理ＩＤあるいは処理名は、アドレスあるいは接続オブジェクトの設定を得るために用いられる。
【０１０６】
本好ましい実施形態では、全てのＲＰＣコールは、パラメータとして少なくともアドレスオブジェクトまたは接続オブジェクトを有している。コールが実行されると、そのオブジェクトに割り当てられた優先度が、ＲＰＣコールの優先度とされる。アドレスあるいは接続オブジェクトに割り当てられた設定により、実行される、対応するＲＰＣコール全ての優先度が決定される。例えば、割り当てられた優先度が「高」の場合、ディスパッチ・キュー５１０にディスパッチされることなく、全てのＲＰＣコールが直ちに実行される。割り当てられた優先度が「１」の場合、全てのＲＰＣコールが、ディスパッチ・キュー５１０（１）に加えられる。
【０１０７】
再度図５を参照すると、「結合作業処理」（ｐｒｏｃｅｓｓ ａｓｓｏｃｉａｔｉｏｎ ｗｏｒｋ）タスク３６４の処理が、予定された結合作業量の実行を完了すると（判定ブロック４０４）、ディスパッチ・キューがサービスを要求しているか否かが確認される（ブロック４０６）。図８は、図７に示されるディスパッチ・キュー５１０の処理のための「ディスパッチ・キュー処理」（ブロック４０６、図６）によって実行されるステップを例示したフローチャートである。
【０１０８】
この例では、ディスパッチ・キュー５１０は優先度が最高のキュー（本例では５１０（１））から処理される（ブロック４０８）。ディスパッチ・キュー５１０にはそれぞれ重み係数が設定されている。この重み係数は、モバイル端末システム１０４とモビリティ管理サーバ１０２との結合が確立された際に、設定マネージャ２２８によって返される設定パラメータである。例を挙げれば、優先度の低いディスパッチ・キュー５１０の重み係数は４であり、優先度が中程度のディスパッチ・キュー５１０重み係数は８である。本例では、優先度の高いＲＰＣコールは解析後直ちに処理されるため、重み係数を有していない。
【０１０９】
ＲＰＣエンジン２４０’は、現在のキューより始めて、ＲＰＣコールをキューから外していき、キューが空になるか、ＲＰＣコールのキュー重み番号（ｑｕｅｕｅ ｗｅｉｇｈｔ ｎｕｍｂｅｒ）が処理されるまでループする（ブロック４１２−４１６）。キューから外されたＲＰＣコールそれぞれに対して、その実行のためにＲＰＣディスパッチャ３９５が呼び出される。ＲＰＣディスパッチャ３９５はモバイル端末システム１０４の代理としてプロシージャ・コール（ｐｒｏｃｅｄｕｒａｌ ｃａｌｌ）を実行し、応答を要求している上記ＲＰＣコールに対するモバイル端末システムからの応答を生成する。
【０１１０】
上記ループを出た後、キューに残っている作業がまだある場合（判定ブロック４１８）、該キューが再実行を要することがマークされる（ブロック４２０）。ループを出ることで、上記システムはプロセッサを次に低い優先度のキューに移らせる（ブロック４２４、４１０）。これにより、ある特定のキューにどれだけの作業が割り振られていても、どの優先レベルにも実行される可能性が与えられることになる。システムは次のキューのサービスに移り、全てのキューが処理されるまで処理を繰り返す。全てのキューの処理が終了すると、システムは実行を要するマークがついたキューがあるか否かを判定して、もしあれば、スケジュール要求がグローバル作業キューに送られて、結合の再実行が予定されることになる。結合の再実行は、図４の「グローバル作業処理」ルーチンにおいて予定される。上記のアプローチにより、プロセッサが、処理すべき作業を有する他の結合にも実行の機会を与えることになる。キューそれぞれに重み係数を割り振ることで、システムは、モビリティ管理サーバ１０２のＣＰＵへのアクセスが優先レベルに応じて許可されるように調整されてもよい。これにより、優先度の高いキューは、先に実行されるだけでなく、さらに容易にＣＰＵにアクセスできるようになる。
【０１１１】
（モビリティ管理サーバのＲＰＣ応答）
上記では、どのように遠隔プロシージャ・コールがモバイル端末システム１０４からモビリティ管理サーバ１０２に送られて実行されるかを説明した。この型のＲＰＣコールに加え、モビリティ管理サーバ１０２のＲＰＣエンジン２４０’はＲＰＣイベントとＲＰＣ受信応答とをサポートしている。結合関連接続ピア（通常は固定端末システム１１０）の活動の結果として、ＲＰＣメッセージが非同期的に生成される。モビリティ管理サーバ１０２のＲＰＣエンジン２４０’は、ＲＰＣディスパッチャ３９５によって実行されるＲＰＣトランザクションを完了する。完了が成功したからといって、全てのＲＰＣコールが応答を要求するわけではないが、応答を要求する一部のＲＰＣコールにより、ＲＰＣディスパッチャ３９５は適切な応答を作成し、インターネット・モビリティ・プロトコル・エンジン２４４’に知らせ、そして該応答はピアのモバイル端末システム１０４に返される。ＲＰＣコールが失敗したときは、全てのＲＰＣコールが応答を生成する（上記においてＲＰＣ受信応答は例外）。
【０１１２】
ＲＰＣイベントは、結合関連接続（通常は固定端末システム１１０）によるネットワーク１０８の活動の結果として発信される。本好ましい実施形態では、こうしたＲＰＣイベントメッセージはモビリティ管理サーバ１０２によってプロキシされ、モバイル端末システム１０４へ送られる。本好ましい実施形態のモビリティ管理サーバ１０２は、以下のＲＰＣイベントコールをサポートする。
【０１１３】
・切断イベント（結合特定接続ピア（通常は固定端末システム１１０）がトランスポート・レベルで切断要求を出した場合に生起する。該要求はモバイル端末システム１０４に代わってプロキシ・サーバ２２４に受信され、プロキシ・サーバ２２４は切断イベントをモバイル端末システムに送る）
・ストリーム受信イベント（結合特定接続ピア（通常は固定端末システム１１０）がストリームデータをモバイル端末システム１０４へ送る際に生起。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データを受け取り、受信応答（Ｒｅｃｅｉｖｅ Ｒｅｓｐｏｎｓｅ）として該データをモバイル端末システムに送る）
・データグラム受信イベント（結合特定ポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｐｏｒｔａｌ）のいずれかが、ネットワーク・ピア（通常は固定端末システム１１０）から送られ、モビリティ管理サーバ１０２を経由してモバイル端末システム１０４へ送られることになっている、データグラムを受け取る際に生起する。プロキシ・サーバ２２４はモバイル端末システム１０４に代わって該データグラムを受け入れ、データグラム受信イベントという形で該データグラムをモバイル端末システム１０４へ転送する）
・接続イベント（結合特定リスニングポータル（ａｓｓｏｃｉａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｌｉｓｔｅｎｉｎｇ ｐｏｒｔａｌ）が、トランスポート層とモバイル端末システム１０４との終端間接続を確立しようとする際、該結合特定リスニングポータルがトランスポート層接続要求（通常は固定端末システム１１０から）を受信するときに生起する。プロキシ・サーバ２２４はモバイル端末システムに代わって接続要求を受け入れ、接続イベントＲＰＣコールを生成してモバイル端末システムに送る）
図９は、ＲＰＣエンジン２４０’が、いかにしてプロキシ・サーバによって生成されたＲＰＣコールを扱うかということを示している。優先度の高いアドレスと接続オブジェクトに対し、ＲＰＣエンジン２４０’は、直ちに送信要求をインターネット・モビリティ・プロトコル・エンジン２４４’に向けてディスパッチする。該送信要求によって、ＲＰＣメッセージがピアのモバイル端末システム１０４に転送される。優先度の低いオブジェクトに対しては、インターネット・モビリティ・プロトコル・エンジン２４４の送信要求が適切な優先キュー５１０’に通知される。結合の実行が予定されていない場合、スケジュール要求もグローバルキュー３５８’に通知される。インターネット・モビリティ・プロトコルの送信要求は、最終的に、図５および８を参照して既に説明したディスパッチ・キューの処理の際に実行される。
【０１１４】
（インターネット・モビリティ・プロトコルの例）
本発明のインターネット・モビリティ・プロトコルは、メッセージ指向で接続ベースのプロトコルであり、配信保証、（再）オーダ検出（（ｒｅ）ｏｒｄｅｒ ｄｅｔｅｃｔｉｏｎ）、ロス回復が可能である。さらに、他の従来型接続指向プロトコル（即ちＴＣＰ）とは違い、複数の別のデータストリームを単一のチャネルにまとめることが可能になっており、保証されたデータ、信頼性の低いデータ、そして新規のメッセージ指向で信頼性の高いデータを、単一の仮想チャネルによって同時にネットワークをトラバースさせることができる。この新たなメッセージ指向のサービスのレベルによって、インターネット・モビリティ・プロトコルのピアが所定のプログラムデータユニットを確認したときに、リクエスト部に通知が行われることになる。
【０１１５】
本発明のインターネット・モビリティ・プロトコルは、既存のネットワーク・トポロジや技術にオーバーレイできるように設計されている。下層のネットワークアーキテクチャに左右されないので、該インターネット・モビリティ・プロトコルは汎用性を有する。パケット化されたデータが二つのピアの間を行き来できさえすれば、インターネット・モビリティ・プロトコルの使用が可能である。ノードそれぞれにおけるネットワークの現在地点（ＰＯＰ）あるいはネットワーク・インフラは、物理的境界、特定のポリシー、あるいは帯域幅の制限がある場合を除き、データの流れに影響を与えることなく変更可能である。
【０１１６】
インターネット・モビリティ・プロトコルは上層の助けを借りて様々なソースからのデータを融合し、下層のデータグラム機能を利用して該データを行き来させる。独立したデータユニットがそれぞれ上層から来ると、インターネット・モビリティ・プロトコルは該データユニットを単一のストリームとして、その後伝送する。該データユニットは次に既存のネットワークを通じてピアに送られ、受信時に、上層の助力によって上記ストリームが非多重化されて、元の独立した複数のデータユニットに戻る。これにより、伝送時にはその都度最大限のネットワークフレームが生成されて、帯域幅の利用を最適化することができる。さらに、上記により、帯域幅を最大限利用できるようにチャネルを調整することができるという効果を奏するとともに、全てのセッションレベルの接続に適用可能なパラメータを持たせることが可能となる。
【０１１７】
あるチャネルが不十分であるといった稀なケースでも、インターネット・モビリティ・プロトコルはピア間に複数のチャネルを確立することができる。これにより、データの優先順位付けや、（下層のネットワークがサポートしていれば）サービス品質の保証も可能になる。
【０１１８】
さらに、インターネット・モビリティ・プロトコルは、動的に選択可能で保証されたレベルのサービス、あるいは信頼性の低いレベルのサービスに対しても考慮されている。例えば、伝送されるプロトコル・データ・ユニットをそれぞれ、有効期間（ｖａｌｉｄｉｔｙ ｔｉｍｅ ｐｅｒｉｏｄ）か再伝送試行回数、もしくはその両方で制限して待機させることができる。インターネット・モビリティ・プロトコルは、どちらかの閾値に達するとデータユニットを有効期限切れとし、その後の伝送の試行から排除する。
【０１１９】
インターネット・モビリティ・プロトコルの、付加プロトコルとしてのオーバーヘッドは、可変長ヘッダの採用により最小限に抑えられている。該ヘッダのサイズはフレームの種類や任意フィールド（ｏｐｔｉｏｎａｌ ｆｉｅｌｄ）によって決定される。該任意フィールドは、ある特定のオーダにおいて追加されて、受信側による解析を容易にし、その存在はヘッダ・フラグ・フィールド（ｈｅａｄｅｒ ｆｌａｇ ｆｉｅｌｄ）のビットによって示される。ピアによる通信に必要な他の制御および設定情報は、全てバンド内制御チャネルを通過することができる。送信されるべき制御情報は全て、任意のアプリケーションレベルのプロトコル・データ・ユニットの前のフレームに加えられる。受信側では制御情報を処理して、次にペイロードの残りを上層に送る。
【０１２０】
エラー発生の確率が比較的高い、信頼性の低いネットワークにおける稼動が想定されているため、インターネット・モビリティ・プロトコルでは、データの完全性を保証し、ネットワークのパフォーマンスを最高まで引き出すべく、数々の技術が使われている。データの完全性を保証するため、フレッチャー・チェックサム・アルゴリズム（Ｆｌｅｔｃｈｅｒ ｃｈｅｃｋｓｕｍ ａｌｇｏｒｉｔｈｍ）が、誤ったフレームの検出用に使われている。このアルゴリズムは効率性と高い検出能力を買われて採用され、ビットエラーのみならずビットの並び替えも検出できる。ただし、上記アルゴリズムの代わりに他のチェックサム・アルゴリズムを採用してもよい。
【０１２１】
シーケンス番号は、オーダされたデータの配信を保証するために使われるが、インターネット・モビリティ・プロトコルにおけるシーケンス番号は、ＴＣＰの場合のようにデータのそれぞれのバイトを表わしているわけではない。一例としては、上記シーケンス番号は、最大６５５３５バイト（インターネット・モビリティ・プロトコル・ヘッダを含む）までの、データのフレームを表現している。該シーケンス番号は３２ビットなど適当な長さのものであって、制限された期間内での高い帯域幅のリンクにおいてラップアラウンドを生じさせないようにしている。
【０１２２】
上記の能力にデータの有効期限切れ機能を組み合わせたとき、再伝送（再試行）されたフレームが含んでいるデータ量が、送信側で生成された前バージョンよりも少ないことがある。フレームＩＤを設定して最新のバージョンのフレームが検知することも可能だが、本好ましい実施形態ではデータが追加されることは絶対に無く、削除されたそれぞれの要素がプロトコル・データ・ユニット全体であるため、上記の手法はシーケンス保証には必ずしも必要でない。一例として、インターネット・モビリティ・プロトコルは受信したある特定のフレームを、該フレームの異なったバージョンのものがいくら伝送されてきても、最初の一回目のみ処理する。新規のユーザ・ペイロードを運搬する、生成されたフレームそれぞれには、固有のシーケンス番号が割り振られる。
【０１２３】
スライディング・ウィンドウ技術の採用によってパフォーマンスが向上し、ピアにデータ受信の確認応答を要求する前に、複数のフレームを保留にできる（伝送できる）。適切なタイミングでのデータ配信を保証するため、肯定応答とタイマーベースの再伝送スキームとが採用されている。さらにチャネルの利用を最適化すべく、選択的な確認応答メカニズムが採用され、ネットワーク接続のロスが多い時間帯もしくは混雑した時間帯における、失われたフレームの迅速な再伝送と、素早い回復とが達成される。一例において、この選択的な確認応答メカニズムは、ヘッダに含まれる付加的なビットフィールドとして表わされる。
【０１２４】
輻輳回避アルゴリズムは、プロトコルをフレームの迅速な再伝送からバックオフさせるためにも用いられている。例えば、ラウンドトリップタイムは、再伝送無しで成功裏にピア間を伝送されたフレームそれぞれに対して計測することが可能である。この時間値は平均されて、再伝送タイムアウト値（ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｏｕｔ ｖａｌｕｅ）の基準となる。フレームが送られるごとに、それぞれのフレームに対してタイムアウトが設定される。あるフレームが実際に伝送されたにもかかわらず、該フレームに関する確認応答が受信されない場合、該フレームは再伝送される。このときタイムアウト値は上昇し、次の再伝送時間の基準となる。この再伝送タイムアウトには上限値および下限値が設定されているので、その値は適切な範囲に収まるようになっている。
【０１２５】
また、インターネット・モビリティ・プロトコルでは、送信路と受信路とが別に扱われている。この手法は、本質的に非対称のチャネルにおいて特に有用である。ヒステリシスに基づいて、インターネット・モビリティ・プロトコルは自動的に、フレームサイズ（フラグメント化閾値）、保留中のフレーム数、再伝送時間、遅延承認時間などのパラメータを調整して、ネットワークを通じて送られる複製データの量を減少させる。
【０１２６】
インターネット・モビリティ・プロトコルによって、ノードが様々なネットワークの違った接続ポイントに移動することが可能になるため、下層のネットワークの特性（例えばフレームサイズ）が途中で変わってしまうことがあるが、この移動の結果、あるネットワークで伝送待ちだったフレームが、モバイル装置が現在接続している新しい媒体にはフィットしないこともありうる。このことに、フラグメント化が全てのネットワーク・インフラでサポートされているわけではないことを合わせて考慮して、フラグメント化はインターネット・モビリティ・プロトコルのレベルにおいて扱われる。それぞれのフレームが伝送される前に、インターネット・モビリティ・プロトコルにより、フレームが現時点でのフラグメント化閾値を越えているか否かが判断される。ちなみに、パフォーマンス向上の見地から、この値は現時点での最大伝送ユニットよりも少なくてよい（大きいフレームよりも小さいフレームの方が最終目的地まで到達する可能性が高いため）。プロトコルのオーバーヘッドを増加させることと、再伝送回数の増加とのトレードオフは、インターネット・モビリティ・プロトコルによって吟味され、全体的に再伝送を減少させるため、フレームサイズが減少させられることもある。あるフレームがフィットしていれば、該フレームは分割されずに伝送される。していなければ、該フレームはその接続で許容される最大のサイズにまで分割される。フレームが再伝送される場合、該フレームは再評価を受け、最大伝送ユニットが減少していれば、再度フラグメント化される（あるいは、もし最大伝送ユニットが増加していれば、該フレームはフラグメント化されない一個のフレームとして再送信されることもありうる）。
【０１２７】
プロトコルそのものは直交に設計されており、どちらの側からでもピアとの接続を確立、切断することができるようになっている。しかし、ある場合においては、実行される場所によってプロトコル・エンジンにおける些少な動作上の差異がいくつか存在し、特定の休止検出や接続寿命タイムアウトは片方の側からしか実行できないこともある。運営上必要な操作を可能にするため、モビリティ管理サーバ１０２上で動作するインターネット・モビリティ・プロトコル・エンジンは、休止期間の状況を把握している。モバイル端末システム１０４からの作業が何もないまま一定の期間が経過した場合、モビリティ管理サーバ１０２はセッションを終了させることができる。また、管理者が、ある特定の接続を確立するのに要する総所要時間を制限する、あるいは日時によってアクセスを拒否することが必要なときがあるが、この場合も、一例としてこうしたポリシータイマーはモビリティ管理サーバ１０２側からのみ操作できるようにしてもよい。
【０１２８】
一例として、インターネット・モビリティ・プロトコルを提供するソフトウェアは、ウィンドウズ（登録商標）ＮＴ、９ｘ、ＣＥ環境で、プラットフォームに合わせた修正を必要とすることなくコンパイルされ、動作できるものである。これを実現するために、インターネット・モビリティ・プロトコルでは、インターネット・モビリティ・プロトコル・フレームの送受信に、ネットワーク抽象層（ｎｅｔｗｏｒｋ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ； ＮＡＬ）のサービスが採用されている。メモリ管理、キューおよびリスト管理、イベントロギング、警報システム、電力管理、セキュリティなどの他の標準的なユーティリティ機能も使われる。いくつかのランタイム・パラメータについては、エンジンがモバイル端末システム１０４に備えられているか、あるいはモビリティ管理サーバ１０２側に備えられているかによって変更される。これについて、数例を以下に示す。
【０１２９】
・特定のタイムアウトは、モビリティ管理サーバ１０２からのみ呼び出し可能
・フレームの方向は、エコー検出用のフレームヘッダそれぞれにて示される
・モバイル端末システム１０４の設定により、着信接続（ｉｎｂｏｕｎｄ ｃｏｎｎｅｃｔｉｏｎ）の拒否が可能
・警報はモビリティ管理サーバ１０２にのみ通知される
・電力管理はモバイル端末システム１０４ではイネーブルにされるが、モビリティ管理サーバ１０２では必ずしも必要でない
インターネット・モビリティ・プロトコルのインターフェイスは、Ｃコーラブルでプラットフォームに依存しない標準的なＡＰＩ機能をほんの少数有し、作業（上記の標準的なユーティリティ機能以外）を予定する、ＯＳ特化型の単一の機能を必要とする構成でもよい。ローカルクライアントとの通信は、定義された作業オブジェクト（作業要求）の利用によって可能になる。作業要素それぞれの完了通知は、作業オブジェクトの一部として特定されたオプションの完了コールバックルーチンを通じて、要求エンティティに通知を行うことによって、効果的に達成することができる。
【０１３０】
インターネット・モビリティ・プロトコル・エンジン自体はキューベースのものである。ローカルクライアントからの作業要素は、ＦＩＦＯオーダに従ってグローバル作業キューに追加されるが、これは、ローカルクライアントが、「ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔｗｏｒｋ（）」などの標準的なインターネット・モビリティ・プロトコル機能を呼び出すことによってなされる。続いて、インターネット・モビリティ・プロトコル内のスケジューリング機能が該作業を除去し、適切な機能に対してディスパッチする。待機機能とスケジューリング機能を組み合わせることでＯＳのアーキテクチャ間の差を感じさせなくするので、プロトコル・エンジンが、スレッドベースのシステム（例えばウィンドウズ（登録商標）ＮＴ）や同期式のシステム（例えばマイクロソフト・ウィンドウズ（登録商標）９ｘやウィンドウズ（登録商標）ＣＥ）で動作することが可能になる。優先度に関するスキームを待機機能の上にオーバーレイすることができるので、（下の層がサポートしていれば）サービス品質を保証することができる。
【０１３１】
ネットワークの視点から見ると、インターネット・モビリティ・プロトコルは、データのコピーや移動を減らすべく、分散−集結技術（ｓｃａｔｔｅｒ−ｇａｔｈｅｒ ｔｅｃｈｎｉｑｕｅｓ）を利用している。伝送はそれぞれフラグメントのリストとしてＮＡＬに送られ、ネットワーク層のトランスポートによって融合される。トランスポート・プロトコル自体が分散−集結技術をサポートしている場合、フラグメントリストは上記トランスポートを通じて転送され、媒体アクセス層ドライバあるいはハードウェアによってアセンブルされる。さらに、上記技術を拡張して、プロトコルスタックのどのレベルにおいても、いかなるプロトコルラッパーの挿入や消去を行うことも可能である。フレームの受信は、ＮＡＬ層により、ＮＡＬ登録処理（ＮＡＬ ｒｅｇｉｓｔｒａｔｉｏｎ ｐｒｏｃｅｓｓ）時に指定された特定の入口点においてインターネット・モビリティ・プロトコルをコールバックすることで通知される。
【０１３２】
（インターネット・モビリティ・プロトコル・エンジンのエントリポイントの例）
例示の実施形態におけるインターネット・モビリティ・プロトコルは、該プロトコルのスタートアップおよびシャットダウン行動を管理する、４つの共通エントリポイントを有している。以下に示されるのがこれらのプロシージャである。
【０１３３】
１．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）
２．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）
３．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）
４．Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＣｒｅａｔｅ（）機能は、ブートサブシステムによって呼び出され、インターネット・モビリティ・プロトコルを初期化する。この第一フェイズ中に、作業の処理を開始するのに必要なリソース全てが所得され、初期化されなければならない。該フェイズの終了時、エンジンは、システムの他の層からの作業をすぐに受け入れ可能な状態である必要がある。このとき、インターネット・モビリティ・プロトコルはグローバル設定テーブルを初期化するが、このために、インターネット・モビリティ・プロトコルは、設定マネージャ２２８のサービスを利用して該テーブルを設定（ｐｏｐｕｌａｔｅ）する。
【０１３４】
次に、インターネット・モビリティ・プロトコルは、サスペンドおよびレジューム通知機能をＡＰＭハンドラに登録する。一例ではこれらの機能はモバイル端末システム１０４の側からのみ呼び出し可能であるが、他の例として、動作中にモビリティ管理サーバ１０２がサスペンドできるようにするのが望ましいこともある。続いて、グローバル作業キュー、グローバルＮＡＬポータルリストなど他の作業用記憶域がメモリプールから割り当てられる。
【０１３５】
必要なランタイムメモリの最大量を制限し、インターネット・モビリティ・プロトコルのハンドルの固有性を保証するため、インターネット・モビリティ・プロトコルは、ハンドル生成用の２段配列構成（２−ｔｉｅｒ ａｒｒａｙ ｓｃｈｅｍｅ）を採用している。グローバル接続配列テーブルのサイズは、システムが設定する同時接続の最大数によって決まり、この時点で割り当てられる。全てのグローバル記憶域が割り当てられ、初期化されると、グローバル・インターネット・モビリティ・プロトコルの状態が、＿ＳＴＡＴＥ＿ＩＮＩＴＩＡＬＩＺＥ＿となる。
【０１３６】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｕｎ（）機能は、全てのサブシステムが初期化された後で呼び出され、インターネット・モビリティ・プロトコルのサブシステムに、待機中の作業をどれでも処理し始めてよいことを通知する。これが、一般的な動作状況におけるインターネット・モビリティ・プロトコル・エンジンの通常の状態である。該エンジンを動作状態にする前に、いくつかの第二パス初期化ステップがこの時点で実行される。
【０１３７】
インターネット・モビリティ・プロトコルは、ネットワーク通信が、任意のインターフェイスのどれを通じてでも実行されるようにする。初期化ステップの間に、インターネット・モビリティ・プロトコル−ＮＡＬ間のインターフェイス用の記憶域が割り当てられるので、インターネット・モビリティ・プロトコルはグローバルポータルリスト中を横断して、ＮＡＬの全てのリスナをスタートさせることができる。一例として、この動作は２つのステップを含んだ以下の処理のようになる。
【０１３８】
・インターネット・モビリティ・プロトコルは、ＮＡＬ層に、初期化中に供給される設定に基づいたポータルを結びつけて（ｂｉｎｄ）オープンし、
・インターネット・モビリティ・プロトコルは、次に、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲＣＶＦＲＯＭＣＢコールバックを登録して、受信したフレームの処理を始める準備ができたことを、ＮＡＬ層に通知する。
【０１３９】
・引き続き、ローカル持続識別子（ｌｏｃａｌ ｐｅｒｓｉｓｔｅｎｔ ｉｄｅｎｔｉｆｉｅｒ； ＰＩＤ）が初期化される。グローバル・インターネット・モビリティ・プロトコルの状態は、＿ＳＴＡＴＥ＿ＲＵＮ＿に変わる。
【０１４０】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＨａｌｔ（）機能は、システムがシャットダウンしたことをエンジンに警告するために呼びだされる。動作中に得られたリソースは、この機能から戻る前に全て開放される。インターネット・モビリティ・プロトコルの全てのセッションは、管理用に設定された理由コードによって異常終了する。エンジンが＿ＳＴＡＴＥ＿ＨＡＬＴＥＤ＿状態になると、それ以降、他の層からの作業は受け付けられず、他の層に通知されることも無い。
【０１４１】
（Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）の例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＵｎｌｏａｄ（）機能は、シャットダウン処理の第二フェイズである。これが、復帰以前に、割り当てられたシステムリソースをエンジンが解放する最後の機会となる。エンジンがこの機能から戻ると、システム自体が停止するので、これ以上の作業は実行されない。
【０１４２】
（インターネット・モビリティ・プロトコル・ハンドルの例）
少なくともいくつかの例においては、メモリ（インターネット・モビリティ・プロトコル状態情報を記憶）のアドレスを、インターネット・モビリティ・プロトコルの接続を記述するトークンとして用いるだけでは不十分である。これは主に、短い期間のうちに、ある接続が終了して別の新しい接続が開始される可能性のためである。メモリアロケータが、別の接続に前のものと同じアドレスを再配分してしまう可能性が高く、この値が前の接続と新しい接続との両方を示すことになってしまう。元々のピアが、（電源が切られていたり、サスペンドしていたり、圏外にあったりなどで）セッションの終了を認識しなかった場合、前のセッションのフレームを新しいセッションの方に送ってしまうこともあり得る。ＴＣＰの場合はこれが起こり、ピアのＩＰアドレスが同じ場合、新しいセッションを生成するためにリセットが行われる。これを避けるため、インターネット・モビリティ・プロトコルは製造ハンドル（ｍａｎｕｆａｃｔｕｒｅｄ ｈａｎｄｌｅ）を採用している。該ハンドルは２列のインデックスによって形成され、独自性を保つため一回限りのものである。テーブルは以下のようなレイアウトとなっている。
【０１４３】
テーブル１：接続オブジェクトの配列を指すポインタの配列
テーブル２：インターネット・モビリティ・プロトコル制御ブロックを指す、実ポインタを含む接続オブジェクトの配列
この技術により、初期化期間に割り当てられるメモリの量が最小化される。テーブル１は、スタートアップの際にサイズが決められ、割り当てがなされる。これにより、モバイル端末システム１０４の側では、少量のメモリの割り当てが可能になる（モビリティ管理サーバ１０２側でテーブル１が割り当てを要求するメモリは、サーバが多くの接続を有しているため少し大きなものになる）。
【０１４４】
テーブル１は必要時に設定（ｐｏｐｕｌａｔｅ）される。接続要求が出されると、インターネット・モビリティ・プロトコルは、テーブル１内でテーブル２への有効なポインタを探す。エントリポイントが見つからない場合、インターネット・モビリティ・プロトコルは、新規のテーブル２に２５６個の接続オブジェクトを割り当て、テーブル２へのポインタを、テーブル１の適切なスロットに記録する。次に、プロトコル・エンジンはテーブル２を初期化し、新しく生成されたテーブルからの接続オブジェクトを割り当てて、製造ハンドルへ戻る。他のセッションが要求された場合、インターネット・モビリティ・プロトコルは再度テーブル１中をサーチして、テーブル２への有効なポインタを見つけ、該セッション用の次の接続オブジェクトを割り当てる。この作業は、以下の二つの状態のうちのどちらかになるまで続けられる。
【０１４５】
・テーブル２から全ての接続オブジェクトが無くなった場合、新たにテーブル２が割り当てられ、初期化されて、該テーブル２を示すポインタが、テーブル１の次に利用可能なスロットに設定される。
【０１４６】
・全ての接続オブジェクトが特定のテーブル２のインスタンスに開放され、全ての要素がある特定の期間使用されなかった場合、テーブル２の上記インスタンスにおける記憶域が開放されてメモリプールに戻され、テーブル１の関連しているポインタはゼロにされて、次の接続要求が開始された際、該入口が使用可能であることを示すようになる（テーブル２の他のインスタンスで、利用可能な接続オブジェクトがない場合に限る）。
【０１４７】
二つのグローバルカウンタは、割り当てられる接続の総数を制限できるようにするために維持されている。片方のグローバルカウンタは現時点でアクティブな接続を数え、もう片方のカウンタは、割り当てられていない接続オブジェクトの数を把握する。さらに、第二のカウンタは、任意に設定された制限まで生成可能な接続オブジェクトの総数の管理も行う。新規のテーブル２が割り当てられると、該カウンタは、該新規のテーブルが表現するオブジェクトの数を把握するため、下方に調整される。反対側では、インターネット・モビリティ・プロトコルがテーブル２のインスタンスをメモリプールに開放するときに、カウンタは、開放された接続オブジェクトの数を合わせて上方修正される。
【０１４８】
（ワークフローの例）
Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能によって、作業はローカルクライアントから要求される。該作業が検査（ｖａｌｉｄａｔｅ）され、グローバル作業キューに加えられると、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＱｕｅｕｅＥｌｉｇｉｂｌｅ（）機能が呼び出される。スレッド化された環境であれば、インターネット・モビリティ・プロトコルのワーカースレッドに信号が送られ（適合マークがつけられ）、制御は直ちに呼び出しエンティティへと戻る。同期的な環境であれば、グローバル作業キューが直ちに実行されて、要求された作業はいかなるものであっても処理される。どちらの場合でも、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＰｒｏｃｅｓｓＷｏｒｋ（）機能が実行されることになる。これが作業処理のためのメインディスパッチ機能である。
【０１４９】
例示の実施形態では、グローバルキューからの作業をディスパッチできるのが一回に一つのスレッドのみの場合があり、再入を防ぐべくグローバルセマフォが用いられてもよい。プライベートなインターネット・モビリティ・プロトコルの作業では、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ（）機能を使用せず、直接グローバル作業キューに作業を送ることができる。
【０１５０】
ＳＥＮＤタイプの作業オブジェクトでは、特殊な場合が想定される。信頼性の低いデータグラムのセマンティクスが保たれていることを保証するため、ＳＥＮＤタイプの作業オブジェクトをそれぞれ、有効期限あるいは再試行カウントを伴って待機させることができる。作業は該有効期限に基づいて寿命を算定される。このような所定のタイムアウトが生じた場合、作業オブジェクトは接続特定キューから除かれ、エラー状態で完了する。ＳＥＮＤオブジェクトが既にデータパスに融合されている場合、プロトコルは、再試行カウントが設定されたどのＳＥＮＤオブジェクトでも、除去を許可する。再試行カウントを超過した場合、該オブジェクトは、特定のフレームを形成する要素のリストから外され、適当なエラー状態を示しつつリクエスタへ戻される。
【０１５１】
（接続スタートアップの例）
インターネット・モビリティ・プロトコルは、ピア間の接続を確立する非常に効率的なメカニズムを有している。接続の確認は、ピア間で最低３フレームをやり取りすることでなされる。開始側は、そのピアにＩＭＰ ＳＹＮＣフレームを送って接続確立が要求されていることを警告する。受け入れ側は、ＩＭＰ ＥＳＴＡＢＬＩＳＨフレームを送って接続受け入れを確認するか、あるいはＩＭＰ ＡＢＯＲＴフレームを送ることで、接続要求が拒否されたことをピアに警告する。ユーザに接続拒否の理由を理解しやすくするため、理由および状態コードが、ＩＭＰ ＡＢＯＲＴフレームに含まれる形で送られる。接続が許可されると、確認応答フレーム（プロトコル・データ・ユニットおよび制御データがふくまれていることもある）が送られて、受け入れ側に転送され、確立フレームの受信が確認される。
【０１５２】
ネットワークのトラフィックを最小化するため、プロトコルは、ユーザおよび制御データを、接続スタートアップ時の最初のハンドシェーク機構に含まれるようにすることができる。この構成は、セキュリティが保障されていない環境や、同じデータパスでセキュリティ用の認証が二重に行われたり、暗号化処理が同じデータパスで行われたりすることによるパフォーマンスの低下を避けるよう、インターネット・モビリティ・プロトコルが調整されているというような、セキュリティが下層で扱われている環境において使用される。
【０１５３】
（データ転送の例）
インターネット・モビリティ・プロトコルは、フレームがネットワークに配信されたことを、ＮＡＬからの通知によって検知する。インターネット・モビリティ・プロトコルは、当該ネットワークリンクが絶えずフロー制御されているか否かを上記メトリクスによって判定するので、当初の要求が完了されるまで同じフレームを再伝送することはない。しかし、ネットワークドライバによっては、フレームの伝送について、誤って、該フレームをネットワークに送る前に配信を示唆してしまうものもある。セマフォの利用により、インターネット・モビリティ・プロトコル層はこれを検知し、当初の要求についてＮＡＬが返答するまでは、他のデータグラムを送信しない。
【０１５４】
フレームがインターネット・モビリティ・プロトコルに受信されると、該フレームは迅速に検査されて、適切な接続キューに加えられる。該フレームが、インターネット・モビリティ・プロトコルがその最終目的地を識別するのに足る情報を有していない場合、該フレームは、それを受信したインターネット・モビリティ・プロトコル・ソケット・キューに加えられ、該ソケット・キューは、続く処理のためにグローバル作業キューに加えられる。この最初の逆多重化により、受信した作業は、処理オーバーヘッドが限定された状態で、迅速に拡散させられる。
【０１５５】
（黙認（ａｃｑｕｉｅｓｃｉｎｇ）の例）
再伝送時のネットワーク帯域幅およびモビリティ管理サーバ１０２の処理に要する電力の最小化のため、プロトコルは、モビリティ管理サーバ１０２が接続を「黙認」できるようにする。ユーザによる設定が可能な期間の後、モビリティ管理サーバ１０２は、対応するモバイル端末システム１０４から通知が無ければ、特定の接続へのフレームの再伝送を停止する。この時、モビリティ管理サーバ１０２は、モバイル端末システム１０４が通信できない状態（圏外、サスペンドなど）であると仮定し、接続を休止状態にする。該接続へのこの後の作業は全て、後の配信のために記憶される。該接続は、以下の状況のいずれかが満たされない限り、同じ状態にとどまり続ける。
【０１５６】
・モビリティ管理サーバ１０２がモバイル端末システム１０４からフレームを受信し、接続を本来の状態に戻す、
・接続寿命タイムアウトの期限が切れる、
・休止タイムアウトの期限が切れる、または
・システム管理者によって接続が中止される
モビリティ管理サーバ１０２が、モバイル端末システム１０４からフレームを受信し、中断された所から接続が再開された場合、該接続で待機していた作業は全て転送され、状態が再同期化される。これ以外の場合、再接続がなされると、モバイル端末システム１０４には以前の接続の終了が通知され、モバイル端末システム１０４に送られることを待機していた作業は破棄される。
【０１５７】
（接続および送信要求の例）
図１０Ａ〜１０Ｃは、インターネット・モビリティ・エンジン２４４によって生成される接続および送信要求ロジックを例示する、フローチャートを形成している。ＲＰＣエンジン２４０からの命令を受信すると、インターネット・モビリティ・プロトコル・エンジン２４４は、該命令が「接続」要求かどうかを判定する（判定ブロック６０２）。該命令が「接続」要求であれば、エンジン２４４は、接続リソースの割り当てが可能かどうかを判断する（判定ブロック６０３）。十分な接続リソースが割り当てられない場合（判定ブロック６０３で「ノー」である場合）、エンジン２４４はエラーを宣言して（ブロック６０３ａ）応答する。接続リソースの割り当てが可能であれば、エンジン２４４は状態設定処理を行って、接続要求の処理に備える（ブロック６０３ｂ）。
【０１５８】
接続その他の要求に対し、エンジン２４４は該接続あるいは送信要求を待機させ、呼び出しを実行しているアプリケーションに応答する前に、グローバルイベントに通知する（ブロック６０４）。
【０１５９】
インターネット・モビリティ・プロトコルのグローバル要求キューからの接続あるいは送信要求をディスパッチするために、エンジン２４４はまず、保留されている作業の有無を判定する（判定ブロック６０５）。保留されている作業が無ければ（判定ブロック６０５で「ノー」である場合）、エンジン２４４は、図１０Ｃのブロック６２５に移って、接続用の作業を待機させるため、アプリケーションからの応答を待つ（ブロック６０５Ａ）。保留されている作業があれば（判定ブロック６０５で「イエス」の場合）、エンジン２４４は現在の状態が確立されているか否かを判定する（ブロック６０６）。状態が確立されている場合（判定ブロック６０６で「イエス」の場合）、エンジン２４４は状態確立への移行のためのステップを飛ばして、図１０Ｂの判定ブロック６１５に移る（ブロック６０６ａ）。状態が確立されていない場合、エンジン２４４は状態確立のための一連のステップを実行する必要がある（判定ブロック６０６で「ノー」である場合）。
【０１６０】
状態確立に移行するために、エンジン２４４はまず、そのピアのアドレスが既知かどうかを判定する（判定ブロック６０７）。既知でなければ、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、ピアのアドレスが来るのを待つ（ブロック６０７ａ）。ピアのアドレスが既知の場合（判定ブロック６０７で「イエス」の場合）、エンジン２４４は次に、必要なセキュリティコンテキストが取得されているかどうかを判定する（判定ブロック６０８）。取得されていない場合、エンジン２４４は作業をさらに待機させ、図１０Ｃのブロック６２５に移って、セキュリティコンテキストが来るのを待つ必要がある（ブロック６０７ａ）。セキュリティコンテキストが既に取得されている場合（判定ブロック６０８で「イエス」の場合）、エンジン２４４は「状態保留」状態を宣言して（ブロック６０８ｂ）、インターネット・モビリティ・プロトコルの同期フレームを送信し（ブロック６０９）、再伝送タイマーをスタートさせる（ブロック６１０）。エンジン２４４は、対応する確立フレームが受信されたかどうかを判定する（ブロック６１１）。受信されていない場合（判定ブロック６１１で「ノー」の場合）、エンジン２４４は、再伝送時間の期限が来たかどうかを判定する（判定ブロック６１２）。再伝送時間の期限が来ていない場合（判定ブロック６１２で「ノー」の場合）、エンジン２４４は待機し、続いてステップ６２５に移ってもよい（ブロック６１３）。最終的に、確立フレームが受信されず（ブロック６１１で判定）、再伝送時間の期限が全て切れた（判定ブロック６１４）場合、接続は中止されてもよい（ブロック６１４ａ）。結局確立フレームが受信された場合（判定ブロック６１１で「イエス」の場合）、エンジン２４４は「状態確立」状態を宣言する（ブロック６１１ａ）。
【０１６１】
状態確立がなされると、エンジン２４４は新規の接続の認証がなされているかどうかを判定する（判定ブロック６１５）。なされていない場合、エンジン２４４は待機し、ステップ６２５へと移ってよい（ブロック６１６）。接続の認証がなされている場合（判定ブロック６１５で「イエス」の場合）、エンジン２４４は認証が成功したかどうかを判定する（判定ブロック６１７）。成功していない場合（判定ブロック６１７で「ノー」の場合）接続は中止される（ブロック６１４ａ）。成功している場合、エンジン２４４は、ピア伝送ウィンドウがフルになっているかどうかを判定する（判定ブロック６１８）。フルになっていれば（判定ブロック６１８で「イエス」の場合）、エンジン２４４は確認応答を待ち、ステップ６２５に進む（判定ブロック６１９）。ウィンドウがフルになっていなければ（判定ブロック６１８で「ノー」の場合）、エンジン２４４はインターネット・モビリティ・プロトコル・データフレームを生成し（ブロック６２０）、送信する（ブロック６２１）。次に、エンジン２４４は再伝送タイマーがスタートしているかどうかを判定する（判定ブロック６２２）。していない場合、エンジン２４４は再伝送タイマーをスタートさせる（ブロック６２３）。エンジン２４４は、それ以上送信するデータが無くなるまで（判定ブロック６２４で判断される）、ブロック６１８〜６２３を繰り返す。そして、エンジン２４４はスリープモードに入ってさらに作業が来るのを待ち、グローバルディスパッチャに戻る（ブロック６２５）。
【０１６２】
（中止の例）
図１１は、接続を中止するためにインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示したフローチャートである。「接続中止」要求を受けて（ブロック６２６）、該エンジンは該要求をグローバル作業キューに加え、呼び出しを行っているアプリケーションに返答する（ブロック６２６ａ）。中止要求は最終的に、実行のため、インターネット・モビリティ・プロトコルの処理グローバル作業キューからディスパッチされる（ブロック６２７）。エンジン２４４は中止要求を調べて、該要求が緊急のものであるか、あるいは余裕のあるものであるかを判定する（判定ブロック６２８）。緊急のものの場合（判定ブロック６２８で「中止」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６２９）。余裕があるものであれば（判定ブロック６２８で「余裕」の場合）、エンジン２４４は「状態クローズ（ｓｔａｔｅ ｃｌｏｓｅ）」状態を宣言し（ブロック６２８ａ）、インターネット・モビリティ・プロトコルの「モーティス（Ｍｏｒｔｉｓ）」フレームを送信し（ブロック６３０）、ピアに接続がクローズされることを示唆する。次に、エンジン２４４は「モーティス」状態を宣言し（ブロック６３０ａ）、再伝送タイマーをスタートさせる（ブロック６３１）。エンジン２４４は、ピアから「ポスト・モーテム（ｐｏｓｔ ｍｏｒｔｅｍ）」フレームが応答されたかどうかを判定する（判定ブロック６３２）。応答されていなければ（判定ブロック６３２で「ノー」の場合）、エンジン２４４は、再伝送タイマーが時間切れになっているか否かを判定する（判定ブロック６３３）。まだ時間切れになっていない場合（判定ブロック６３３で「ノー」の場合）、エンジン２４４は待機し、ステップ６３７へ進む（ブロック６３４）。再伝送タイマーが時間切れになっている場合（判定ブロック６３３で「イエス」の場合）、エンジン２４４は総再伝送時間の期限が切れているかどうかを判定する（判定ブロック６３５）。まだ切れていない場合（判定ブロック６３５で「ノー」の場合）、ブロック６３０に戻り、モーティスフレームを再送する。すでに総再伝送時間の期限が切れている場合（判定ブロック６３５で「イエス」の場合）、エンジン２４４は直ちに接続を中止する（ブロック６３５ａ）。
【０１６３】
「ポスト・モーテム」応答フレームがピアから受信されると（判定ブロック６３２で「イエス」）、エンジン２４４は「ポスト・モーテム」状態を宣言して（ブロック６３２ａ）、接続リソースを開放し（ブロック６３６）、スリープ状態に戻ってさらに作業を待つ（ブロック６３７）。
【０１６４】
（再伝送の例）
図１２は、インターネット・モビリティ・プロトコル・エンジン２４４が実行する「再伝送」イベントロジックの例を示している。再伝送タイマーが時間切れを迎える（ブロック６５０）と、エンジン２４４は、保留中のフレームがあるかどうかを判定する（判定ブロック６５１）。保留中のフレームがなければ（判定ブロック６５１で「ノー」の場合）、エンジン２４４はタイマーを破棄して（ブロック６５２）スリープ状態に戻る（ブロック６６０）。逆に保留中のフレームがあれば（判定ブロック６５１で「イエス」の場合）、エンジン２４４は、再伝送期間全体（ｅｎｔｉｒｅ）が終了したかどうかを判定する（判定ブロック６５３）。まだ終了していなければ（判定ブロック６５３で「ノー」の場合）、処理は時間差のためにスリープ状態に戻る（ブロック６５４）。既に終了していれば（判定ブロック６５３で「イエス」の場合）、エンジン２４４は、総ての（ｔｏｔａｌ）再伝送期間が終了したかどうかを判定する（判定ブロック６５５）。既に終了しており（判定ブロック６５５で「イエス」）、このイベントがモビリティ管理サーバのエンジン２４４’（モバイル端末システムのエンジン２４４に対応）で実行されている場合、休眠状態が宣言される（判定ブロック６５６、ブロック６５６ａ）。同じ状態で、モバイル端末システム１０４において実行されるインターネット・モビリティ・プロトコル・エンジン２４４は、接続を中止する（ブロック６５６ｂ）。
【０１６５】
総ての再伝送期間がまだ終了していない場合（判定ブロック６５５で「ノー」の場合）、エンジン２４４はフレームを再処理して時間切れのデータを除去し（ブロック６５７）、それを再転送し（ブロック６５８）、再転送タイマーをそのまま再始動させる（ブロック６５９）。そして処理は休眠状態に入り（ブロック６６０）、次のイベントを待つ。
【０１６６】
（インターネット・モビリティ・プロトコルのＰＤＵの期限切れの例）
図１２のブロック６５７において、要求を出している上層のインターフェイスが、結合しているピアに送られるプロトコル・データ・ユニット（つまりＳＥＮＤ作業要求）５０６の期限切れに関するタイムアウトあるいは再試行カウントを特定することが可能になる。この機能により、インターネット・モビリティ・プロトコル・エンジン２４４は、信頼性の低いデータのセマンティクス維持、再伝送されたデータからの信頼性の低いデータの除去など、他の機能も果たせるようになる。上層からのＰＤＵ（プロトコル・データ・ユニット）それぞれは、最終的にインターネット・モビリティ・プロトコル・エンジン２４４によってコーリシングされる、それぞれの要素に対する有効期限タイムアウト（ｖａｌｉｄｉｔｙ ｔｉｍｅｏｕｔ）および／または再試行カウントを、特定することができる。有効期限タイムアウトおよび／または再試行カウント（アプリケーションによってはユーザによって特定可能）は、エンジン２４４による再伝送の前に、どのＰＤＵ５０６が、転送されずにフレームから除去されるべきかを決定するために使われる。
【０１６７】
ＰＤＵ５０６に関わる有効期限タイムアウトは、ＰＤＵそれぞれが伝送に際して考慮すべき、相対期間（ｒｅｌａｔｉｖｅ ｔｉｍｅ ｐｅｒｉｏｄ）を特定する。実行依頼の間、Ｉｎｔｅｒｎｅｔ Ｍｏｂｉｌｉｔｙ ＰｒｏｔｏｃｏｌＲｅｑｕｅｓｔＷｏｒｋ機能によって有効期限の値（ｅｘｐｉｒｙ ｔｉｍｅｏｕｔ ｖａｌｕｅ）がチェックされる。該値が０で無い場合、時期タイマー（ａｇｅ ｔｉｍｅｒ）は初期化される。次に、要求されたデータは、結合しているピアに送られる他のデータと同じキューに加えられる。あるＰＤＵ５０６が、有効期限パラメータ（ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ ｐａｒａｍｅｔｅｒ）が特定する期間よりも長くキューにある場合、該キューを処理する次イベントの間に、有効期限の切れた該（全ての）ＰＤＵは除去され、フレームの再伝送時に再伝送されるのではなく、ローカルに「タイムアウトによる失敗（ｔｉｍｅｏｕｔ ｆａｉｌｕｒｅ）」のステータスコードをもって完了する。このアルゴリズムにより、ピアへの伝送のために待機している信頼性の低いデータが古くなる（ｇｒｏｗ ｓｔａｌｅ）こと、および／または際限なくシステムリソースを消費することを防ぐ。
【０１６８】
図１２Ａの例において、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は有効期限を持たず、要求に対するタイムアウトが無い。ＰＤＵ５０６（２）は、２秒の有効期間を持ち、時系列的にＰＤＵ５０６（１）の後に並んでいる。ＰＤＵ５０６（ｎ）は、２．５秒の有効期間を持ち、時系列的にＰＤＵ５０６（２）の後に並んでいる。ＰＤＵ５０６（ｎ）の待機が、キューの処理をさせ、ＰＤＵ５０６（２）の有効期間を経過させる最初のイベントであるため、ＰＤＵ５０６（２）は作業キューから外され、ローカルに完了されて、ＰＤＵ５０６（ｎ）がリストに加えられる。有効期間がＰＤＵ５０６（ｎ）に設定されている場合、ここまでの一連のイベントが繰り返される。作業キューを操作するいかなるイベント（キューに加える、キューから外す等）によっても、古くなったＰＤＵが除去され、完了される。
【０１６９】
上記のように、ＰＤＵ５０６はインターネット・モビリティ・プロトコル・エンジン２４４の伝送ロジックによって融合され、単一のデータストリームにフォーマットされる。独立した作業要素それぞれは、有効期限タイムアウトによって期限切れになっていなければ、集められてインターネット・モビリティ・プロトコル・データフレームを形成する。インターネット・モビリティ・プロトコル・エンジン２４４は、最終的にこれらのＰＤＵ５０６をピアに送り、関係するフレームをフレーム保留リスト（Ｆｒａｍｅｓ−Ｏｕｔｓｔａｎｄｉｎｇ ｌｉｓｔ）に加える。ピアが一定期間内に該フレームを認識しなかった場合（図１２の再伝送アルゴリズムを参照）、フレームは再伝送され、失われたかあるいは破損したパケットを回復する。再伝送の直前、フレームを形成するＰＤＵリストは、再試行カウントを伴った要求が待機しているかどうかを判定すべく反復される。該再試行カウントが０ではなく、０に向かって減少してゆく場合、ＰＤＵ５０６はリストから外され、フレームヘッダはデータの消去を示すように修正される。このように、古くなったデータ、低信頼のデータ、あるいは独自の再伝送ポリシーを持つアプリケーションは、エンジン２４４’の再伝送アルゴリズムによって負担をかけられることがない。
【０１７０】
図１２Ｂの例においても、少なくとも３つの独立したＰＤＵ５０６が、続く処理のためにインターネット・モビリティ・プロトコル・エンジン２４４でキューに加わっている。ＰＤＵ５０６（１）は再試行カウント無しでキューに加わっているが、これは、継続的な再伝送の試行と、保証された配送レベルのサービスとを示している。ＰＤＵ５０２（２）は再試行カウントが１でキューに加わり、時系列的にＰＤＵ５０６（１）の後に並ぶ。ＰＤＵ５０６（ｎ）は、ある程度の時間が経過してからＰＤＵ５０２（２）より後ろに加わる。この時点で、いくつかの外部イベント（例えば上層融合・タイマー）が、エンジン２４４’に、インターネット・モビリティ・プロトコル・データフレーム５００を生成するための作業キューから十分なＰＤＵ５０６を集めて新しいフレームを生成するための論理を送信させる。フレームヘッダ５０３が求められ、これに、フレームの最初の伝送であることを示すための、再試行ＩＤとして０が付けられる。続いてフレームは、ネットワークへの後の伝送用に、ＮＡＬ層へと送られる。このときに再伝送タイマーがスタートするが、これは、当該のフレームがペイロードを含んでいるためである。説明を容易にするため、再伝送タイマーが期限を迎える前に、様々な理由でピアからの確認応答が受け取られなかったと仮定すると、エンジン２４４の再伝送ロジックにより、当該するフレーム５００が、ネットワークへ再伝送されるのに的確であるか否かが判断される。フレームをＮＡＬ層に再送する前に、エンジン２４４’の再伝送ロジックは、関連しているＰＤＵ５０６のリストを反復する。ＰＤＵ５０６（２）それぞれの再試行カウントが調べられ、０でなければ、該カウントは減少させられる。ＰＤＵ５０６（２）の再試行カウントを減少させる処理により、該カウントは０になる。ＰＤＵ５０６（２）の再試行カウントが０になったことにより、ＰＤＵ５０６（２）はリストから外され、「再試行失敗（ｒｅｔｒｙ ｆａｉｌｕｒｅ）」のステータスをもってローカルに完了する。続いて、ＰＤＵ５０６（２）のデータが無いことを示すため、フレームヘッダ５０３のサイズが調整される。この処理は、残っている全てのＰＤＵについて繰り返される。フレーム５００全体が、「編集後」フレーム５００’の作成のために再処理されると、ヘッダの再試行ＩＤが増加させられて、生成されたデータグラムが、続く（再）伝送に向けてＮＡＬ層に送られる。
【０１７１】
（受信の例）
図１３Ａ〜１３Ｄは、「受信」イベント受信に伴ってインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。このような受信イベントは、インターネット・モビリティ・プロトコル・エンジン・フレームがネットワーク１０８から送られた際に生成される。この受信イベントを受けて、エンジン２４４は該イベントを事前検査（ｐｒｅ−ｖａｌｉｄａｔｅ）し（ブロック６７０）、インターネット・モビリティ・プロトコル・エンジン・フレームである可能性があるか否かを判定する（判定ブロック６７１）。エンジンが可能性無しと判断した場合（判定ブロック６７１で「ノー」の場合）、該フレームは破棄される（ブロック６７２）。可能性ありという判断の場合（判定ブロック６７１で「イエス」の場合）、エンジン２４４は、受信したフレームと関連する接続があるかどうかを判定する（判定フレーム６７３）。受信したフレームと関連する接続がある場合（判定ブロック６７３で「イエス」の場合）、エンジン２４４は作業を接続受信キューに加え（ブロック６７４）、該接続に受信に適格であるとマークを付け（ブロック６７５）、該接続をグローバル作業キューに加える（ブロック６７６）。まだどの接続も受信したフレームと関連していない場合（判定ブロック６７３で「ノー」の場合）、エンジン２４４は、受信したフレームをソケット受信キューに加え（ブロック６７７）、該ソケット受信キューをグローバル作業キューに加える（ブロック６７８）。どちらの場合でも、エンジン２４４はグローバル作業イベントを送る（ブロック６７９）。「受信適格」イベントをグローバル作業キューからディスパッチする際（図１３Ｂ参照）、エンジン２４４はフレームをそれぞれの受信キューから外す（ブロック６８０）。インターネット・モビリティ・プロトコル・エンジン２４４がメッセージをキューから外し始められるようになる前に、複数のＩＭＰフレームを受信し、キューに加えることが可能である。エンジン２４４は、全てのフレームがキューから外れるまで作業を繰り返す（ブロック６８１、６８２）。あるフレームがキューから外れると（判定ブロック６８１で「イエス」）、エンジン２４４は受信したフレームを検査し（ブロック６８３）、該フレームが有効かどうかを判定する（判定ブロック６８４）。該受信したフレームが無効である場合、エンジン２４４は該フレームを破棄し（ブロック６８５）、受信キューから次のフレームを外す（ブロック６８０）。上記フレームが有効である場合（判定ブロック６８４で「イエス」の場合）、エンジン２４４は、該フレームが既存の接続と関連しているか否かを判定する（ブロック６８６）。していなければ（判定ブロック６８６で「ノー」の場合）、エンジン２４４は同期フレームがあるかどうかを判定する（判定ブロック６８７）。同期フレームがなければ（判定ブロック６８７で「ノー」の場合）、該フレームは破棄される（ブロック６８５）。反対に、同期フレームが受信されていれば（判定ブロック６８７で「イエス」の場合）、エンジン２４４は、図１４Ａおよび１４Ｂを参照して説明される受動接続要求により、該フレームを処理する（ブロック６８８）。
【０１７２】
上記フレームが接続と関係していれば（判定ブロック６８６で「イエス」の場合）、エンジン２４４は接続状態が依然アクティブで、まだ「ポスト・モーテム」になっていないかどうかを判定する（判定ブロック６８９）。接続が既に「ポスト・モーテム」である場合、フレームは破棄される（ブロック６８５）。そうでない場合、エンジン２４４はフレームを解析し（ブロック６９０）、該フレームが中止フレームであるかどうかを判定する（判定ブロック６９１）。該フレームが中止フレームであれば、エンジン２４４は直ちに接続を中止する（ブロック６９１ａ）。該フレームが中止フレームでなければ（判定ブロック６９１で「イエス」の場合）、エンジン２４４は確認応答情報を処理し、全ての保留中の送信フレームを開放する（ブロック６９２）。次に、エンジン２４４は、解読の必要がある場合のため、セキュリティ用のサブシステムへと送る（ブロック６９３）。フレームがセキュリティ用のサブシステムから戻ると、エンジン２４４は全ての制御データを処理する（ブロック６９４）。続いて、エンジン２４４はフレームがアプリケーションデータを含んでいるかどうかを判定する（判定ブロック６９５）。含んでいる場合、該データはアプリケーション層においてキューに加えられる（ブロック６９６）。エンジン２４４はまた、接続が休止状態であるかどうかを判定し（ブロック６９７および６９７ａ：これは、好ましい実施形態におけるモビリティ管理サーバのエンジン２４４’にもあてはまる）、確立状態に戻す。
【０１７３】
フレームが「モーティス」フレームである可能性があれば（判定ブロック６９８で「イエス」の場合）、エンジン２４４は、アプリケーション層に「切断」を示唆し（ブロック６９９）、「モーティス」状態に入る（ブロック６９９ａ）。エンジン２４４は「ポスト・モーテム」フレームをピアに送り（ブロック７００）、「ポスト・モーテム」状態に入る（ブロック７００ａ）。続いて、エンジン２４４は接続リソースを解放し（ブロック７０１）、スリープ状態に戻って作業を待つ（ブロック７０２）。解析されたフレームが「ポスト・モーテム」フレームだった場合（判定ブロック７０３で「イエス」の場合）、ブロック７００ａ、７０１、７０２が実行される。これ以外の場合、制御はブロック６８０に戻って、次のフレームを受信キューから外す（ブロック７０４）。
【０１７４】
（受動接続の例）
図１４Ａ〜１４Ｂは、「受動接続」要求に対してインターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。まず、エンジン２４４は、当該装置に他の接続が存在するかどうかを判定する（ブロック７２０）。存在すれば（判定ブロック７２０で「イエス」の場合）、該エンジンは、それが最初の接続であるか否かを判定する（判定ブロック７２１）。ピアが、新規の接続が最初の接続であると認識している場合（判定ブロック７２１で「イエス」の場合）、エンジン２４４はそれ以前の接続を中止する（ブロック７２２）。最初の接続ではない場合（判定ブロック７２１で「ノー」の場合）、エンジン２４４は、シーケンスと接続ＩＤとが対応しているかどうかを判定する（判定ブロック７２３）。対応していなければ（判定ブロック７２３で「ノー」の場合）、制御は判定ブロック７２０へ戻る。シーケンスと接続ＩＤが対応していれば（判定ブロック７２３で「イエス」の場合）、エンジン２４４は複製フレームを破棄し（ブロック７２４）、図１３Ｂのステップ６８０に戻る（ブロック７２５）。
【０１７５】
他の接続が無ければ（判定ブロック７２０で「ノー」の場合）、エンジン２４４は、接続に接続リソースを割り当て可能か否かを判定する（判定ブロック７２６）。割り当て可能でない場合、エラーが宣言され（判定ブロック７２６で「ノー」の場合、ブロック７２７）、接続が中止される（ブロック７２８）。接続リソースを割り当て可能な場合（判定ブロック７２６で「イエス」の場合）、エンジン２４４は「設定」状態を宣言し（ブロック７２６ａ）、接続についてのセキュリティコンテキストを取得する（ブロック７３０）。十分なセキュリティコンテキストの取得ができなかった場合（判定ブロック７３１で「ノー」の場合）、接続は中止される（ブロック７２８）。取得できた場合、エンジン２４４は確立フレームを送り（ブロック７３２）、接続が「確立」状態になったことを宣言する（ブロック７３２ａ）。続いて、エンジン２４４は再送部（ｒｅｔｒａｎｓｍｉｔｔｅｒ）を始動させ（ブロック７３３）、完了に向けて認証処理を待つ（ブロック７３４）。最後に、エンジン２４４は装置とユーザとが両方認証済みか否かを判定する（ブロック７３５）。装置とユーザのどちらかが認証されていない場合、接続は中止される（ブロック７３６）。それ以外の場合、エンジン２４４は監視中の（ｌｉｓｔｅｎｉｎｇ）アプリケーションへの接続を示唆し（ブロック７３７）、設定を取得する（ブロック７３８）。この２ステップのどちらかが成功しなかった場合、接続は中止される（判定ブロック７３９、ブロック７４０）。成功した場合、処理はスリープ状態に戻って作業を待つ（ブロック７４１）。
【０１７６】
（異常終了の例）
図１５Ａおよび１５Ｂは、接続「中止」要求を受けて、インターネット・モビリティ・プロトコル・エンジン２４４が実行するステップを例示する、フローチャートを形成している。キューを介してディスパッチされた、上記のような要求を他の処理（ブロック９９９）から受信すると（ブロック１０００）、エンジン２４４は、接続が該要求と関係しているかどうかを判断する（判定ブロック１００１）。関係していれば（判定ブロック１００１で「イエス」の場合）、エンジン２４４は元の状態をセーブして（ブロック１００２）、「中止」状態を宣言する（ブロック１００２ａ）。次に、エンジン２４４は、接続がＲＰＣエンジンに示唆されていたか否かを判定する（判定ブロック１００３）。されていれば、エンジン２４４は切断イベントを示唆し（ブロック１００４）、「ポスト・モーテム」状態を宣言して（ブロック１００３ａ）、該接続に割り当てられていたリソースを解放し（ブロック１００５）、元の状態が保留中の状態より大きいか否かを判定する（判定ブロック１００６）。元の状態が保留中の状態より大きくなければ、（判定ブロック１００６で「ノー」の場合）、処理は、呼び出しルーチンに戻るべく、ブロック１０１２に移る（ブロック１００７）。元の状態が保留中の状態より大きい場合には、エンジン２４４は、上記要求が受信フレームと関係しているかどうかを判定する（判定ブロック１００８）。中止要求が受信フレームと関係していて、受信フレームが中止フレームである場合（判定ブロック１００９）、受信フレームは呼び出しルーチンに戻る（ブロック１０１２）前に破棄される（ブロック１０１１）。
【０１７７】
（ローミング制御の例）
再度図１を参照すると、モバイルネットワーク１０８は、それぞれ別のネットワーク相互接続（１０７ａ〜１０７ｋ、無線トランシーバ１０６ａ〜１０６ｋにそれぞれ対応）を提供する、複数のセグメントを含んでいてもよい。本発明の別の側面において、モビリティ管理サーバ１０２を含むネットワーク１０８は、モバイル端末システム１０４があるネットワーク相互接続から別のネットワーク相互接続へと移る「ローミング」状況を、余裕を持って（ｇｒａｃｅｆｕｌｌｙ）扱うことができる。一般に、ネットワーク１０８のトポロジは、管理等の理由により、いくつかのセグメント（サブネット）に分けられ、一般的には、あるセグメントにおいて、別個のネットワーク（伝送）アドレスが複数のモバイル端末システム１０４それぞれに割り当てられている。
【０１７８】
上記のようなサブネットで新規に起動したネットワーク装置は、動的ホスト構成プロトコル（ＤＨＣＰ）を使用して、自動的に設定されるのが一般的である。例えば、サブネット上のＤＨＣＰサーバは、一般的に、そのクライアントに（他のものの提供に加えて）有効なネットワークアドレスを「リース」する。ＤＨＣＰクライアントは、永続的に割り当てられた、「固定符号化された（ｈａｒｄ−ｃｏｄｅｄ）」ネットワークアドレスを有していなくてもよい。その代わり、ブート時に、ＤＨＣＰクライアントはＤＨＣＰサーバにネットワークアドレスを要求する。ＤＨＣＰサーバは、割り当てに使用可能なネットワークアドレスをプールしている。ＤＨＣＰクライアントがネットワークアドレスを要求すると、ＤＨＣＰサーバはプールしていたアドレスを、該クライアントに割り当てあるいはリースする。割り当てられたネットワークアドレスは、特定の期間（リース期間）だけ、クライアントに所有される。リース期間が終わると、ネットワークアドレスはプールに戻され、他のクライアントへの割り当てに使用できるようになる。ネットワークアドレスの自動割り当てに加え、ＤＨＣＰはネットマスク等の設定情報を、ＤＨＣＰクライアントソフトウェアを動作させているクライアントに提供する。標準的なＤＨＣＰプロトコルについての詳しい情報は、ＲＦＣ２１３１に記載されている。
【０１７９】
よって、ＤＨＣＰを使用するモバイル端末システム１０４が、サブネットからサブネットへとローミングすると、該システムは新規のネットワークアドレスを持つことになる。本発明の一側面において、モバイル端末システム１０４とモビリティ管理サーバ１０２とがＤＨＣＰの自動設定機能を利用し協調することで、モビリティ管理サーバによるモバイル端末システム１０４の「新しい」ネットワークアドレスの認識や、該アドレスと、モビリティ管理サーバがプロキシする、以前に確立されていた接続との結合が保証される。
【０１８０】
ある実施例では、モバイル端末システム１０４が別のサブネットにローミングしたり圏外に出たりしたか否かを判定するために利用される、他の標準的な方法と並んで、エコー要求−応答（ｅｃｈｏ ｒｅｑｕｅｓｔ−ｒｅｓｐｏｎｓｅ）として、標準的なクライアント／サーバ型同報通信用のＤＨＣＰ Ｄｉｓｃｏｖｅｒ／Ｏｆｆｅｒメッセージのシーケンスが使用される。標準的なＤＨＣＰプロトコルに従って、ネットワークアドレスを要求するモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージの一部として、クライアント識別子とハードウェアのアドレスとを定期的に同報通信すると、これに対し、ＤＨＣＰサーバはＯｆｆｅｒ応答を同報通信する（要求しているモバイル端末システムがまだネットワークアドレスを持っていないため、該システムを特定して該応答を送るというよりも、同報通信によって該応答が伝えられるという形になる）。よって、当該サブネット上の全てのモバイル端末システム１０４は、ＤＨＣＰ Ｏｆｆｅｒサーバからの、同サブネット上のどのモバイル端末システムに同報通信された応答であっても受信することになる。
【０１８１】
本実施例では、ＤＨＣＰ同報通信メッセージをモニターするＤＨＣＰリスナが設けられており、モバイル端末システム１０４が、あるサブネットから別のサブネットへローミングしているか、およびＤＨＣＰによって新規のネットワークアドレスが取得できるようになっているかが確認される。図１６は、ＤＨＣＰリスナのデータ構造の例を示している。例えば、モバイル端末システムのリスナのデータ構造９０２は、以下の要素を有していてもよい。
【０１８２】
・サーバデータ構造の連結リスト、
・整数トランザクションＩＤ番号（ｘｉｄ）、
・カウンタ（「ｐｉｎｇ」）、および
・タイムアウト値
サーバデータ構造９０４は、それぞれ別のＤＨＣＰサーバを定義するデータブロックの連結リストを有していてもよい。該データブロックそれぞれは、以下の要素を有していてもよい。
【０１８３】
・次のサーバへのポインタ、
・サーバＩＤ（ＤＨＣＰサーバのネットワークアドレス）、
・最近該ＤＨＣＰサーバと結合したＢＯＯＴＰリレーエージェントのアドレス（ｇｉａｄｄｒ）、
・「ｐｉｎｇ」値（ｓｏｃｋｅｔ−＞ｐｉｎｇ）、および
・フラグ
これらのデータ構造は、ネットワーク１０８上のＤＨＣＰ同報通信トラフィックに基づいて、持続的にアップデートされる。以下に例示の諸機能は、該データ構造の維持に使用される。
【０１８４】
・ｒｏａｍＣｒｅａｔｅ（） （変数を初期化）
・ｒｏａｍＤｅｉｎｉｔｉａｌｉｚｅ（） （全てのリスナを消去）
・ｒｏａｍＳｒａｒｔＩｎｄｉｃａｔｉｏｎｓ（） （モバイル端末システムがローミングするかインターフェイスを変更した際に、登録主体ローミング示唆（ｒｅｇｉｓｔｒａｎｔ ｒｏａｍｉｎｇ ｉｎｄｉｃａｔｉｏｎｓ）のために、供給されたコールバックルーチンを呼び出す）
・ｒｏａｍＳｔｏｐＩｎｄｉｃａｔｉｏｎｓ（） （適当なコールバックをリストから除去して登録ローミング示唆を停止）
・インターフェイス変更（インターフェイスがネットワークアドレスを変更したことを示す、ＯＳからのコールバック通知）
・リスナ信号（ローミング、圏外、圏内復帰のいずれかの状態を示す、リスナからのインターフェイスごとのコールバック）
これに加え、リフレッシュ処理が、インターフェイス変更後にリスナをアップデートするために利用されてもよい。
【０１８５】
本好ましい実施形態では、全てのモバイル端末システム１０４が、ＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求によって同じクライアント識別子とハードウェアアドレスとを伝送する。これにより、リスナのデータ構造とこれに関連する処理とが、モバイル端末システムからのＤｉｓｃｏｖｅｒ要求と、他のネットワーク装置からのＤｉｓｃｏｖｅｒ要求とを、区別することができるようになる。ＤＨＣＰサーバも同様に応答を同報通信するので、どのモバイル端末システム１０４および／またはモビリティ管理サーバ１０２も、ＤＨＣＰサーバからどのモバイル端末システムに出されたＯｆｆｅｒ応答でも受け取ることができる。複数のＤＨＣＰサーバが単一のＤＨＣＰ Ｄｉｓｃｏｖｅｒ要求に応答できるため、図１６のリスナのデータ構造は、サーバからの応答それぞれを、メインハンドルに連結リスト経由で結びつけられた、個別のデータブロックに記憶する。
【０１８６】
所定のクライアントハードウェアアドレスおよびクライアント識別子を有するＤｉｓｃｏｖｅｒ要求の受信に際し、本好ましい実施形態では、該要求がモバイル端末システム１０４から送られてきたものとして認識される。該メッセージが０に設定されたＢＯＯＴＰリレーアドレスをさらに有している場合、該メッセージはリスナと同じサブネットからのものであることが示唆されている。リスナは、最近モバイル端末システム１０４から送られたＤｉｓｃｏｖｅｒメッセージのトランザクションＩＤ（ｘｉｄ）と対応したトランザクションＩＤ（ｘｉｄ）が含まれていない限り、ＤＨＣＰ Ｏｆｆｅｒ応答を無視してもよい。該リスナは、新規のＢＯＯＴＰリレーエージェントＩＤおよび／または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレスを持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナは、旧サーバから肯定応答を受け取って初めて、新サーバを図１６のデータ構造に加える。リスナが新サーバからの応答は受け取ったが旧サーバからは受け取っていない場合、ローミング状態が示唆される（これについては設定によって変更可能である）。リスナが新旧両サーバのどちらからも応答を受け取っていない場合、リスナは圏外にあると判定される（この判定は、アプリケーションなど上層に警告を出して、停止や、バッファ・オーバーフロー回避のためのデータ送信量の減少に利用できる）。
【０１８７】
リスナがどのサーバからも応答を受信しない場合、参照点が無いため、ローミングが行われているかどうかが判定できない。この状況は、タイムアウト後にエラー警告して、呼び出し側に処理を再試行させることによって解消される。本好ましい実施形態では、新規のＢＯＯＴＰリレーエージェントＩＤ（または提供されたサブネットマスクでマスクされた、提供されたネットワークアドレス）を持つ、既知のサーバから応答があれば、モバイル端末システム１０４がローミングしたと判定する。リスナのデータ構造に、新サーバからの応答はあったが旧サーバからのものは無い場合、ローミングが行われた可能性はあるが、旧サーバからの応答がその後あるかもしれないので、待機して通知を遅らせる。新旧どちらのサーバからも応答が無い場合、モバイル端末システム１０４は圏外にある可能性があるので、モビリティ管理サーバ１０２は該システムが圏内に戻るのを待つ。
【０１８８】
図１７は、本好ましい実施形態のリスナ処理のステップを例示したフローチャートである。同図によると、ＤＨＣＰリスナ処理は、適切なメモリをハンドルに割り当て、ＮＡＬソケットをＤＨＣＰクライアントおよびサーバＵＤＰポートに解放し、その両者に対して受信コールバックを設定することによってなされる。次にタイマーが設定され（ブロック８０２）、上記処理は「待機」状態に入ってローミング関連のイベントを待つ（ブロック８０４）。イベントは、以下の３種の外部入力によって引き起こされる。
【０１８９】
・ＤＨＣＰサーバパケットを受信する
・他のモバイル端末システムからのＤＨＣＰクライアントパケットを受信する ・タイマーの期限が切れる
ＤＨＣＰサーバパケットを受信した場合、該パケットは、そのクライアント識別子が所定のクライアントＩＤと一致するか否かを判定するために調べられる（判定ブロック８０６）。一致しなければ、該パケットは破棄される。しかし、該パケットが所定のクライアントＩＤを含んでいる場合、該パケットがＤＨＣＰ Ｏｆｆｅｒパケットであるか否かが判定される（判定ブロック８０８）。該Ｏｆｆｅｒパケットは、最近送られたＤＨＣＰ Ｄｉｓｃｏｖｅｒシーケンスに対応したトランザクションＩＤを含んでいない限り、拒絶される。
【０１９０】
パケットトランザクションＩＤが対応していれば（ブロック８１０）、ＤＨＣＰ Ｏｆｆｅｒパケットを送信したサーバが既知であるか否か（つまり、サーバＩＤが図１６のリスナのデータ構造に含まれているか否か）が判定される（ブロック８１２）。サーバＩＤがリストに無い場合（判定ブロック８１２で「ノー」の場合）、サーバＩＤがリストに加えられ、「新規」とマークされる（あるいは、リストの最初のサーバであれば、「最初」とマークされる）（ブロック８２２）。サーバが既にリストにある場合（判定ブロック８１２で「イエス」の場合）、さらに、パケットＢＯＯＴＰリレーアドレス（「ＧＩＡＤＤＲ」）がサーバアドレス（「ＧＩＡＤＤＲ」）に対応しているか否かが判定される（判定ブロック８１４）。対応していなければ、Ｏｆｆｅｒパケットは他のサブネットからのものということになるので、「ハードローミング（ｈａｒｄ ｒｏａｍ）」が実行されたと判定される（ブロック８１６）。呼び出し側のアプリケーションには、ローミングが行われたことが通知される。判定ブロック８１４でＢＯＯＴＰリレーアドレスが対応していると判定されると、ローミングは行われていないということになり、サーバ受信時間を記録し、リストの他のサーバ全てについて「新規」フラグをリセットし、現在のｐｉｎｇ番号をサーバに記憶するというリスナ処理が行われる（ブロック８１８、８２０）。続いて、処理は「待機」期間に戻る。
【０１９１】
イベントがクライアントパケットに受信されると、リスナ処理では、該パケットが所定のクライアントＩＤを有しているか、ＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットか、および０のパケットＢＯＯＴＰリレーアドレス（ＧＩＡＤＤＲ）を有しているかどうかが判定される（ブロック８２４、８２６、８２８）。これらのステップにより、上記受信パケットが、リスナと同じサブネット上にある、他のモバイル端末システムから送信されたＤＨＣＰ Ｄｉｓｃｏｖｅｒメッセージであるか否かが判定される。そうであれば、リスナ処理により、上記トランザクションＩＤが、後に受信されるＤＨＣＰ Ｏｆｆｅｒパケットの比較に用いられる、ピアのトランザクションＩＤに設定され（ブロック８３０）、「ｐｉｎｇ確認」が呼び出され（ブロック８３４）、タイマーがリセットされる（ブロック８３６）。
【０１９２】
タイマーの期限切れにより、処理は「ｐｉｎｇ確認」を呼び出す（ブロック８３８）。本好ましい実施形態における「ｐｉｎｇ」は、ランダムな新規のｘｉｄを有するＤＨＣＰ Ｄｉｓｃｏｖｅｒパケットである。このｐｉｎｇ確認８３８のステップが、図１７Ａに例示されている。ｐｉｎｇ確認ルーチンの目的は、「ソフトローミング（ｓｏｆｔ ｒｏａｍ）」状態（つまり、モバイル端末システムが、一時的にサブネットとのコンタクトを失ったもののその後回復したが、まだ他のサブネットにローミングはしていない状態）が発生しているか否かの判定である。処理によって、サブネット・ローミング状態、圏外状態、あるいは「サーバ無し」状態が発生しているか否かが判定される。これらを言い換えると以下のようになる。
【０１９３】
・モバイル端末システムが、あるサブネットから別のものにローミングしたか？
・モバイル端末システムは圏外にあるか？
・ＤＨＣＰサーバは不在か？
これらの状態は、モバイル端末システムの、前「ｐｉｎｇ」応答と現「ｐｉｎｇ」応答とを比較することによって判定される（判定ブロック８４６、８５０）。例えば、現ｐｉｎｇ数から旧サーバの前ｐｉｎｇ応答を引いた数が、サブネットのサーバのｐｉｎｇよりも大きく、少なくとも一つのサーバが「新規」とマークされている場合、別のサーバへのサブネット・ローミングがあったということになる。この論理により、コーリング処理に対し、サブネット・ローミング状態、圏外状態、あるいはサーバ無し状態が示唆される（あるいはいずれも示唆されない）。
【０１９４】
図１８は、モバイル端末システム１０４のローミング制御センター（ｒｏａｍｉｎｇ ｃｏｎｔｒｏｌ ｃｅｎｔｅｒ）が実行するステップを例示したフローチャートである。モバイル端末システム１０４でのローミングを可能にするため、既知のアドレスのリストが０に初期化され（ブロック８５０）、ＯＳインターフェイス変更通知がイネーブルになり（ブロック８５２）、次に、ＯＳを呼び出して、ＤＨＣＰを利用する現在のアドレスのリストを所得する（ブロック８５４）。現在のリストから無くなった全ての既知のアドレスに対応するリスナが閉じられ（ブロック８５６）、一方、現在のリストにあるが未知のインターフェイスにあるリスナが開放される（ブロック８５８）。次に、登録主体に「ローミング」を示唆する（ブロック８６０）。
【０１９５】
図１７のリスナ処理から信号が送られると（ブロック８６２）、該信号が、「ローミング」、「圏外」、「圏内復帰」のいずれの状態を示しているかが判定される（判定ブロック８６４、８７０、８７４）。ローミング信号（判定ブロック８６４で「イエス」）により、対応するリスナ８６６が閉じられ、ＯＳがコールされて、ネットワークアドレスのＤＨＣＰリースが解放、更新される（ブロック８６８）。リスナ信号が「圏外」の場合（判定ブロック８７０）、該状態が登録主体に示唆される（ブロック８７２）。該信号が「圏内復帰」の場合（判定ブロック８７４）、該状態は全ての登録主体に示唆される（ブロック８７６）。無効のローミング命令を受信すると（ブロック８７８）、全てのリスナが閉じられ（ブロック８８０）、ＯＳインターフェイス変更通知が無効になる（ブロック８８２）。
【０１９６】
（インターフェイスによって補助されたローミングのリスナの例）
さらに、インターフェイスベースのリスナによって、同じネットワークおよび別のネットワーク媒体のネットワーク接続ポイントを横断したローミングが可能になる。該インターフェイスベースのリスナが上述のビーコン技術を要することなく動作する一方、下層の（複数の）インターフェイスが適切な信号をサポートしていない場合には、システムをビーコン状態にフォールバックさせることもできる。
【０１９７】
本実施形態において、インターフェイスベースのリスナは、ネットワーク・インターフェイス・アダプタからの（例えば低レベルのインターフェイス・ローミング・ドライバを経由した）情報を、ネットワークスタックからの情報と統合して、モバイルノードが新規のネットワーク接続ポイントに移動したか否かを判定する。図１９Ａと１９Ｂは、モバイルノードの移動パス（ｍｉｇｒａｔｉｏｎ ｐａｔｈ）を効率的に決定するのに利用される、リスナ・アルゴリズムを例示する。該処理では、単一のネットワーク媒体に接続された単一のネットワーク・インターフェイスが使用されているが、単独で、もしくは他のローミング・アルゴリズムと協働して、（例えば、冗長パスを使った自己回復インフラ構築のために）様々なネットワーク媒体やインターフェイスを横断するようにもできる。
【０１９８】
図１９Ａを参照すると、システム初期化時や、ネットワークアダプタドライバがロードする際に（図１９Ａ、ブロック２０００）、低レベルのインターフェイス・ローミング・ドライバは、図１８のローミング制御センターモジュールに登録を実行する（ブロック２０１０）。このような登録（例示の実施形態では、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能を通じて実現される）により、下記のエントリポイントが与えられる。
【０１９９】
・開
・閉
・状態（ｓｔａｔｕｓ）取得
・ドライバが登録主体に状態の変化を通知可能であれば、ブール演算を真とし、ローミング制御センターモジュールが、状態確認にタイマーベース（等）のポーリングを使わなければならない場合は、ブール演算を偽とする
実施例のｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）機能により、インターフェイス記述ストリング、あるいはローミング制御センターモジュールを正しいローミングドライバと予備的に組み合わせるために使用できるトークンが与えられる。また、デフォルトのローミングドライバが、示唆／問合せ（ｓｉｇｎａｌｉｎｇ／ｑｕｅｒｙｉｎｇ）媒体接続性およびネットワーク接続ポイントの変更に関するＯＳ包括メカニズム（Ｏ／Ｓ ｇｅｎｅｒｉｃ ｍｅｃｈａｎｉｓｍ）を使用するインターフェイスに、インストールされてもよい。
【０２００】
本実施例では、インターフェイスの状態がイネーブルになると（つまりネットワークへのアクセスが可能になると）（ブロック２０２０）、ローミング制御センターは、インターフェイス補助ローミング（ｉｎｔｅｒｆａｃｅ ａｓｓｉｓｔｅｄ ｒｏａｍｉｎｇ； ＩＡＲ）を、以下のステップに基づいて試みる（ただし、以下のステップは、ＯＳの設計および／または特定のアプリケーションに使われるホスティング装置によって、入れ替えられたり省略されたりすることがある）。
【０２０１】
１．包括ハンドラ（ｇｅｎｅｒｉｃ ｈａｎｄｌｅｒ）がインストールされている場合、包括ｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）ハンドラへのコールがなされる。包括ハンドラは低レベルアダプタドライバに問合せをして、該ドライバが、媒体接続性の状態およびネットワーク接続ポイントの変更に関する信号を包括的にサポートしているか否かを判定する（ブロック２０３０）。インターフェイスドライバが該機能を包括的にサポートできない場合（判定ブロック２０３０で「ノー」の場合）、エラー状態が、コール実行側に返され、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０２】
２．包括ハンドラがエラー（判定ブロック２０３０で「ノー」）を返した場合、アクティブなインターフェイスに関する検索が、現在登録されているローミングドライバにおいて実行される（ブロック２０４０）。該インターフェイスが、ｃｒＲｅｇｉｓｔｅｒＣａｒｄＨａｎｄｌｅｒ（）フェイズ中に登録されたトークンのうちの一つと一致する場合（ブロック２０５０）、ローミング制御センターは、アダプタのインスタンスへの特定のｃｒＯｐｅｎＩｎｓｔａｎｃｅ（）をコールする。この機能は、低レベルドライバを開き、状態（媒体接続性、ネットワーク接続ポイントＩＤ）を再度ポーリングし、定期ポーリングタイマーを（可能ならば）設定することを試みるものである。低レベルドライバが、なんらかの理由で該要求をサポートしていない場合、ローミング制御センターにエラーが返されて、信号情報の取得に他のメカニズムを使用することが示唆される。
【０２０３】
３．ここまでのステップのいずれかが、要求された機能を達成できない場合、エラーがローミング制御センターに返されて、ＩＡＲ機能を使用せずに、図１７および１７Ａのビーコンリスナ（ｂｅａｃｏｎｉｎｇ ｌｉｓｔｅｎｅｒ）、モバイルＩＰ、あるいは場合により、ローミングを扱っている、現在接続されているネットワークなど、他のローミング・アルゴリズムにフォールバックすることが示唆される（判定ブロック２０５０で「ノー」の場合、ブロック２０６０）。これ以外の場合、インターフェイス補助ローミングがイネーブルになり（ブロック２０６０）、ローミング制御センターは下記のアルゴリズムに従う。
【０２０４】
まず、インターフェイスによって補助されたリスナは、現在の媒体接続性の状態と、ネットワーク接続ポイントの識別情報とを、ローカルデータストアに記録する（ブロック２０６０）。インターフェイスによって補助されたサブシステムがローミングフィードバックの供給に成功したと仮定して、該サブシステムは状態イベントを待つ（ブロック２１００）。該イベントは、例えば以下のものを有している。
【０２０５】
・低レベルローミングドライバからのコールバック、
・ポーリング間隔（ｔｉｍｅｄ ｐｏｌｌ ｉｎｔｅｒｖａｌ）（ブロック２０７０、２０９０）、あるいは
・ネットワーク・レベルの活動（つまり、伝送／受信にかかわる問題）からの示唆
インターフェイスの状態が、媒体接続性に変化が生じたか、あるいはネットワーク接続ポイントが変更されたかを示すと（図１９Ｂの判定ブロック２１１０もしくは２１２０で「イエス」の場合）、ローミング制御センターの全てのクライアントに、以下のルールに基づいて、状態の変化が知らされる。
【０２０６】
１．状態が、下層のネットワーク媒体への接続から切断へと変化したことを示し（ブロック２１２０で「イエス」）、ピアへのパスが他に無い場合、リスナは、モバイル端末システムが接続を失ったと結論付け、ローミング制御センターはそのクライアントに、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴ状態を示唆する（ブロック２１４０）。
【０２０７】
２．上記状態が、インターフェイスが媒体に再接続され、ネットワーク接続ポイントが変わっていないことを示し（ブロック２１２０で「ノー」の後、ブロック２１５０で「ノー」の場合）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＯＵＴ＿ＯＦ＿ＣＯＮＴＡＣＴが既に示唆されている場合、モバイル端末システムが、特定のネットワーク接続ポイントとのコンタクトを失ったがその後取り戻したことが示唆される。この場合、ローミング制御センターは、適切なアクセスのために登録または取得された全てのネットワークアドレスを再確認し（ブロック２１７０）、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを出して（ブロック２１８０）、ローミング制御センターのクライアントに、再接続が行われたので、トランスポート・レベルでの通信の再確立に必要な措置を全て実行するように警告する。例えば、サービス中断中にいくつかのデータが失われることがあれば、クライアントは該データを回復するために措置を講じるといったことである。
【０２０８】
３．上記状態が、インターフェイスが媒体に取り付けられているが、ネットワーク接続ポイントが変更されたことを示している場合（ブロック２１５０で「イエス」の場合）、ローミング制御センターはクライアントに、ローミング状態になったことを示唆する。ネットワーク接続ポイント間のハンドオフをさらに効率的にサポートするために、本例のローミング制御センターは、ローカルデータストアと並行して学習アルゴリズムを使用している。該データストアは、通常動的にポピュレートされている（学習している）が、パフォーマンス向上のため、該データストアに静的な情報（既に学習された情報）が準備されていてもよい。データストア自体は、ネットワーク接続ポイント識別子のリストを、ネットワークや媒体へのアクセスのアドレスやネットワークマスクなどの情報とともに維持している。この「ネットワーク・トポロジ・マップ」は、ローミング制御センターがクライアントに対して正しい信号の生成を決定できるように補助するものである。
【０２０９】
正しい信号の決定は、本実施例では以下のようにしてなされる。
【０２１０】
ａ）データストアのネットワーク・トポロジ・マップを検索して、インターフェイスが特定のネットワーク接続ポイントを訪れたか否かが判定される（ブロック２１９０）。対応が見つかれば（ブロック２２００で「イエス」）、該ネットワーク接続ポイントが、以前にインターフェイスが結合していたのと同じネットワーク・セグメントにあるか否かがさらにチェックされる。ネットワーク・セグメントが同じであれば、ローミング制御センターは、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＡＭ＿ＳＡＭＥ＿ＳＵＢＮＥＴを生成する。これにより、ローミング制御センターのクライアントに、ハンドオフが実行され、ハンドオフ中にデータのいくつかが失われた可能性があるため、直ちにトランスポート・レベルでの通信の再確立をするための可能な限りの措置を講じなければならないことが示唆される。
【０２１１】
ｂ）検索中に対応は発見されたが、新しいネットワーク接続ポイントは前と同じネットワーク・セグメントにない場合、リスナは、モバイル端末システムが別のサブネットワークにローミングしたと結論付ける。この場合、ローミング制御センターは、
・新規のネットワーク・セグメントで使用可能なアドレスを取得する（ブロック２２２０）。この動作は、現在のアドレスを新規のセグメントで有効なように登録すること、ローカルサーバからアドレスを（再）取得すること、あるいは以前に割り当てられたアドレスがまだ有効かどうか判定するヒューリスティックな手法を用いてもよい。最後のケースでは、ローミング制御センターにより、インターフェイスが所与のネットワーク接続ポイント間をローミングしていて、パフォーマンス維持の観点から、直ちにネットワークアドレスを破棄したり、その登録を抹消したりできないような状態にあるかどうかが判断される。この例では、（例えばＤＨＣＰを通じて）ネットワークでアドレスを取得することは、（モバイルＩＰの外部エージェントを通じて）ローカルネットワークでアドレスを登録することとは相違している。ローミングエンティティは、アドレスを（再）取得（例えばＤＨＣＰサーバからのリースを確立／アップデートして）するか、あるいは現アドレスを外部エージェント（モバイルＩＰ）に登録する。
【０２１２】
・別のサブネットへのローミングを示唆する、ＲＯＡＭ＿ＳＩＧＮＡＬ＿ローミング信号を、該ローミング制御センターのクライアント向けに生成する（ブロック２２３０）。
【０２１３】
ｃ）検索の結果対応が見つからなければ（ブロック２２００で「ノー」）、ネットワーク接続ポイントの識別子、媒体アクセスアドレス、ネットワークマスクや他の補助的な情報によってポピュレートされた、新規の記録を生成する（ブロック２２１０）。次に、ローミング制御センターはブロック２２２０および２２３０を、ネットワークアドレスを取得、登録し、「ローミング」信号を生成するために実行する。
【０２１４】
上記のインターフェイスによって補助されたローミング技術により、下層のインターフェイス情報へのアクセスができるようになり、自動的かつ効率的に別の有効なネットワークパスを選択することを可能にする、（ユーザおよび／またはシステムによって定義された）付加的なポリシーパラメータが採用できるようになる。一つ以上のネットワークが同時に使用可能な場合、サブシステムは、最も負担がかからないパス（ワイドエリア・ネットワークかローカル・エリア・ネットワークかという選択）を選ぶことができる。これは、帯域幅、（１バイトあたりの）コスト、および／またはサービス品質といった様々なメトリクスによって決定可能である。この「最低負担ルーティング」技術により、ネットワーク接続の品質、効率、フレーム損失の減少などの点で効果を得ることができる。例えば、他の利用可能なヒューリスティクス（媒体接続性、信号強度、再伝送率等）による、「メークビフォアブレーク（ｍａｋｅ ｂｅｆｏｒｅ ｂｒａｋｅ）」ハンドオフ構造が提供可能で、よってローミングノードからの／に向かう継続的なパケットフローの損失を最小化できる。下記のポリシー管理についての記述を参照のこと。
【０２１５】
図２０は、インターフェイス補助ローミングトポロジのノードのデータ構造を例示している。図２０のこのデータ構造は連結リストとして実施されているが、前後のフィールドを省略した配列として表現されることもある。無線ネットワーク・インフラにおいて、「ＮＰＯＡ」は、例えば、アクセスポイントのＭＡＣアドレスあるいはモバイルノードが結合している基地局でもよい。他のネットワークにおいては、「ＮＰＯＡ」は、介入的なネットワーク相互接続（ゲートウェイ、ＩＷＦ等）の固有の識別子であってもよい。データ構造には静的な情報が予め与えられていてもよいし、動的に情報が学習されてもよい。また、ノードそれぞれと、他の情報（例えばＭＴＵのサイズ、待ち時間、コスト、利用可能かどうかなど）とが結合していてもよい。
【０２１６】
（特定の競合状態を扱う他の実施例）
さらに行われた実験から、ネットワーク・アダプタの中には、ネットワーク・セグメントに完全登録される前に、媒体と（再）接続されていると誤って信号を出すものがあることが明らかとなった。例えば、ローミングの間、ネットワーク識別子を保持する記憶領域はまだ更新されず、従って、システムがこれらのネットワーク・アダプタが同じサブネットにロームバックしたと誤解することが考えられる。最終的には、デバイスが登録を終了すると、記憶領域は新しいネットワーク識別子と共に更新され、さらに別のローミング信号が生成される。両方の情報が一緒にゲートされ、インターフェイスがネットワークでの登録を終了した時に１度だけ信号が送られると、このシナリオ通りに進む。しかし、ポーリングの際、「ネットワークと接続中」を示す信号が以前に生成された場合に、ネットワークＩＤがいつ有効になるかを判定するのは困難である。
【０２１７】
基本的に、ローミング中のノードはネットワークと媒体アクセスレベルで通信できるため、事実上媒体と接続状態にあるが、登録プロセスが完了していないので、事実上、リンクを通じていずれのアプリケーションデータを送ることはまだできない。従って、この状態を補償するのが望ましい。このような補償を行う方法の一つとして、一般にはエコー要求／応答パケットとして知られているリンク確認フレームを送ることによってピア接続を判定する方法がある。これらのエコーやｐｉｎｇフレームは１つのピア（ローミング中のノードである可能性が高い）によって生成され、双方向のピア・トゥ・ピア接続が達成可能か判定する。要求を出しているピアがその要求に対する応答フレームを受け取る場合、二重通信が実現し終了する。この時点で、次に切断状態になるまでＮＰＯＡ情報が有効であると見なされる。また、該当インターフェイス上のピアからのフレーム受領等、他の情報によって、ローミング中のノードが登録プロセスが終了し、双方向通信が達成可能であることが想定可能となる。
【０２１８】
ネットワーク・インターフェイスと内在するプロトコルスタック状況間における別の競合状態は、問題を生じることがある。デバイスは、新しいネットワーク・セグメントに移動し、以下のインターフェイスから正確に信号が送られるようにすることは可能であるが、トランスポート・スタック自体はフローするアプリケーションデータのルーティング・テーブルに必要な調整を行わないことがある。この状態を補償するために、内在するトランスポートのルーティング・テーブルに変更が生じる度に、付加的信号であるＲＯＡＭ＿ＳＩＧＮＡＬ＿ＲＯＵＴＥ＿ＣＨＡＮＧＥが追加されて生成される。この信号が示されると、ローミング中のサブシステムクライアントはピア・システムとの接続が達成可能かどうか判定するために必要なアクションは何でも行う。これによりローミング中のクライアントは、ルーティング修正がピアへの通信経路に影響を及ぼしたかどうか判定するために、内在するトランスポートのルーティング・テーブルを介して列挙する必要がある。また、上記記載のアルゴリズム等のように、よりイントルーシブな他のアルゴリズムが、ピア間に双方向通信経路が存在することを確認するために行われてもよい。
【０２１９】
（非接続ネットワークを通じたローミング例）
本発明の非限定的な好ましい実施形態の他の一側面として、いわゆる「非接続ネットワーキング」（ｄｉｓｊｏｉｎｔ ｎｅｔｗｏｒｋｉｎｇ）モードでＭＭＳ（モビリティ管理サーバ）にアクセスするためのアルゴリズム及び構成がある。新しいアルゴリズムによって、あるネットワークからは別のネットワークにおけるネットワークアドレスが分からないような非接続ネットワーク・トポロジにおいても、ＭＭＳとの通信を確立する／持続するのに使われる、代替のネットワークアドレスを動的／静的に見つけ出すことができるようになる。
【０２２０】
一般に、アルゴリズムによって、通信中にＭＥＳ（モバイル端末システム）に送るための、ＭＭＳが利用可能な代替アドレスのリストが可能となる。このように、ＭＭＳはＭＥＳに、一つ以上のＭＭＳネットワークアドレスもしくは他のネットワークに対応した他のＭＭＳのアイデンティティを、単一のネットワークによる通信によって送る。一例として、該リストは、回路構築の際に送付可能である。また、該リストは途中で変更可能である。この場合、該リストは接続が確立されている間のいかなる時にも更新が可能である。
【０２２１】
ＭＥＳが別のネットワークへと移動するとき、ＭＥＳは新規のネットワークの接続ポイントからＭＭＳとコンタクトをとるために、ＭＭＳの「エイリアス」（ａｌｉａｓ）アドレス／アイデンティティのリストを用いる。これにより、移動前のネットワークと移動後のネットワークとがアドレス、又はその他の情報を共有していなくても、ＭＥＳは新規のネットワーク接続を通じてＭＭＳとのコンタクトを再確立することができる。
【０２２２】
この新しい技術を簡略化したフローチャートを図２１に示す。ＭＭＳ１０２は、２つの異なる非接続ネットワーク、すなわちネットワーク・セグメントＮ１及びＮ２と接続しているものとする。ＭＥＳ１０４は、最初にＭＭＳ１０２とネットワークＮ１を介して接続されるものとする。ネットワークＮ１を介してＭＥＳ１０４とＭＭＳ１０２との間で接続が確立されるとすぐに、ＭＭＳ１０２は、ＭＥＳ１０４に対して、ＭＭＳが一以上の他のネットワーク（例えば、ネットワークＮ２）から求められるネットワークアドレスのリストＬ又は他の識別子を送ることができる。ＭＥＳ１０４は、該リストＬを受け取り、記憶する。その後、ＭＥＳ１０４は別のネットワーク（Ｎ２）に移動する時、ＭＥＳ１０４はこの記憶されたリストＬにアクセスし、それを用いて新規のネットワーク（Ｎ２）を通じたＭＭＳ１０２との通信を効果的に再確立することが可能となる。
【０２２３】
この新しいアルゴリズムには、非接続ネットワークを通じて、ＭＭＳ１０２と通信するための代替ネットワークアドレス又は他の識別子をより効率的に取得することに加え、少なくともいくつかの用途がある。その用途の一例としてネットワークオペレーションがある。例えば、図２１に示すアルゴリズムを用いて、多くのネットワーク（いくつか、又は全てが無線ネットワーク）からの安全なファイアウォール／ゲートウェイ、及びコーポレートバックボーンとしてＭＭＳ１０２が使用される安全なネットワークをセットアップでき、モバイルノード１０４が安全に、接続を切断されることなく別々のネットワーク全てに移動することが可能となる。例えば、ＭＭＳ１０２がハブとして１つの太いパイプでコーポレートネットワーク、及び論理的に分離した多くのネットワークを接続する多数の小さなスポークと接続しているとする。ネットワークは論理的に分離しているため、ＭＭＳ１０２（この例ではルータとして動作可能）を介した場合を除いて、１つのネットワーク・セグメント上のトラフィックが別のネットワーク・セグメントに達することができない。
【０２２４】
普通、ネットワーク・セグメントからネットワーク・セグメントへ移動するノードにとって、ＭＭＳ１０２との接続に使用される「メインパブリックアドレス又は初期アドレス」への戻り方を示す、各ネットワーク・セグメントに設けられた情報／経路（つまり、デフォルトルート等）をルーティングが必要となる。
接続が確立されるとすぐに、そのアドレスが接続の存続のために用いられる。ＭＥＳ１０４からフレームが送られる時、クライアント及び及び中間ノード（ルータ）におけるＩＰネットワーク（層３）のインフラストラクチャは、フレームの目的地アドレスを見て、最終目的地（ＭＭＳ１０２）にパケットを正確に送る。このことは、一般にＩＰ送信（ＩＰ ｆｏｒｗａｒｄｉｎｇ）、あるいはＩＰルーティングと呼ばれるもので行われる。この機能がオンになると、あるネットワーク・セグメントのフレーム（ブロードキャスト等）が別のネットワーク・セグメントへ流れる。ＩＰ送信をしないと、あるセグメントに送られたフレームは他のセグメントへ送られることはないので、通信パイプが切断され、あるいは非接続ネットワークができてしまう。
【０２２５】
図２１に示す代替アドレスリストは、ルーティング情報のうちの幾つかをＭＥＳ１０４に送出する、又は配布する効果を有する。従って、各セグメントは、ＭＭＳ１０２とつながっている他のセグメントの情報はない状態で離散された状態となる。ＭＥＳ１０４はＭＭＳ１０２によって認証可能であるため、ＭＭＳは認証されたＭＥＳユニット１０４にのみリストＬを送る。ＭＥＳ１０４が別のネットワーク・セグメントへ移動する時、ＭＥＳ１０４は自動的に正しいアドレスを選択し、それを用いて途中ＭＭＳとの通信を開始／継続することができる。従って、非接続ネットワークの問題は解決され、ルーティング・インフラストラクチャの変更は必要なくなる。これにより、有効なユーザに対してのみネットワークへのアクセスを有効にすることによって、より安全なコンピュータ環境を提供することが可能となる。
【０２２６】
例えば、このようにユーザレベルのセキュリティ／暗号化と組み合わせてＭＭＳ１０２を用いることで、コーポレートバックボーンからのトラフィック、及びコーポレートバックボーンへのトラフィックを、上記のローミング技術を用いてそのセグメント上のノードを目的地としたフレームのみに限定することが可能である。フレームは選択的に暗号化でき、スポーク・ネットワーク・インフラストラクチャが有効にしたデバイスによって行われる可能性のある盗聴を阻止することができる。
【０２２７】
例を図２２に示す。図２２において、ＭＭＳ１０２は通信網やルート情報を共有しない４つの別々に分かれたネットワーク（Ｉａ、Ｉｂ、Ｉｃ、Ｉｄ）と接続されている。どの点から見ても各ネットワークＩは島となっている。コーポレートバックボーン上の有線通信を用いてネットワークの一つ（例えば、Ｉｃ）とドッキングしているＭＥＳ１０４を想定する。例えば、ＭＥＳ１０４は１９２．１６８．ｘ．ｘネットワーク上のアドレスを取得してＭＭＳ１０２と通信するものとする。
【０２２８】
ある理由によりＭＥＳが１０．１．ｘ．ｘ（Ｉａ）ネットワークに渡る、又は移動する必要があるものとする。１０．１．ｘ．ｘ（Ｉａ）ネットワークは１９２．１６８．ｘ．ｘ（Ｉｂ）ネットワークのことを知らない（つまり、（Ｉｂ）ネットワークへのルートがない）ため、ＭＥＳ１０４がその領域へ移動する時に、たとえＭＭＳが通信パイプに接続されていても通信パイプは切断される。また、モバイルノード１０４が図示される他の１０．ｘネットワークのいずれかと接続する場合においても同じことが起こる。
【０２２９】
図２１に示すアルゴリズムを用いて、接続開始時間の（あるいは他の方法で）ＭＭＳ１０２は各種非接続ネットワークＩａ、Ｉｂ、Ｉｃ、Ｉｄに関するそのインターフェイスアドレスをＭＥＳ１０４と共有し、ＭＥＳはこれらを記録する。一旦記録されると、ＭＥＳ１０４は上記ネットワークのいずれか一つに移動して新しいネットワーク・セグメントに移動したことを検出する場合、ＭＥＳは適切なネットワークアドレスを選択し、そのネットワーク・セグメントでＭＭＳと通信できる。２以上のアドレスが使用される場合、ＭＥＳ１０４は適切なアドレスを選択してスピード、コスト、有効性、ホップ等、多くのメトリクスに基づき使用する。図２１と同様のリストを受け取らなかったＭＥＳ１０４は、その「ホーム」ネットワーク以外のネットワークを通じてＭＭＳと接続することができないので、種々のネットワーク間の移動を事実上阻まれることになる。
【０２３０】
他に、図２１の技術は分散型ネットワーク・インターフェイスに用いられる。今日のネットワークにおいて、ネットワーク・アドレス・トランスレータ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒｓ；ＮＡＴｓ）として知られるものが開発されている。この従来の技術を利用すれば、一つの公開ネットワークアドレスを用いるだけで多くのネットワークデバイスはインターネット上の情報へのアクセスが可能となる。この技術は、単一もしくはわずかなデバイスを介してインターネットに向けられた情報やクエリを全て送ることによって上記の機能を可能とする。該デバイスはネットワーク層で要求を記録し、その後パケットのアドレスとポート情報をデバイスのアドレス／ポートのタプルに再度対応付けし、それをその目的地に送信する。インターネット、あるいは他の当該ネットワークからフレームを受け取ると同時に、デバイスはリバースルックし、そのアドレス／ポートのタプル情報を開始デバイスのものと取り替えて、フレームを送り返す。これらの対応付けはＮＡＴにおいても静的に定義される。
【０２３１】
誰かがＬＡＮ／ＷＬＡＮの内部でＭＭＳ１０２を使用するために、それをＮＡＴに置くことを想定する。現在、ＭＭＳ１０２がＮＡＴでない限り、あるいは異なるプロキシを用いてＭＭＳと通信を全て行うことによって、誰かがイントラネットの境界範囲外に移動する時、ＭＭＳと通信するアドレスがもはやアクセス可能ではないため、ＭＭＳとはアクセス可能ではない。図２１のアルゴリズムを用いれば、ＭＭＳと直接接続されていない別のインターフェイスアドレスを静的／動的に明確にすることができる。従って、上記のアルゴリズムを使用すれば、ＭＥＳ１０４は自動的に適切な非接続アドレスを選択し、イントラネットの領域外のネットワークと接続する時にそのアドレスを使用することができる。
【０２３２】
この概要を図２３に示す。ノードがインターフェイス“ｄ”からインターフェイス“ｇ”へ渡るとする。ＭＭＳ１０２にローカルインターフェイスを供給するだけではアクセスはできない。ＭＥＳ１０４は分散されたインターフェイスの優先順位を知る必要がある。それからＭＥＳ１０４は必要なアドレスを選択してインターフェイス“ｇ”上で使用する。その後、ＮＡＴ２０００は、各パケットに関するネットワークアドレス／ポート情報を、内部インターフェイス“ｃ”アドレスへ適切に変換する。ＭＭＳ１０２からＭＥＳ１０４に送られるフレームには逆の処理が行われる。
【０２３３】
（ポリシー管理及びロケーションベースのサービス例）
本発明の他の非限定的な実施形態として、多くのメトリクスに基づき付加的なセキュリティ、コスト削減、サービスを提供することが独自にできる手法を提供する。上記のＭＭＳはＭＥＳが確立する各アプリケーションのセッションと深く関わっているため、どちらの側（すなわち、ＭＭＳおよび／またはＭＥＳ）もポリシーベースのルールを適用してＭＥＳとその最終的なピアとの間の通信を適合して制御することができる。さらに、ＭＭＳおよび／またはＭＥＳはデバイスのロケール、又は近接性（ｐｒｏｘｉｍｉｔｙ）、並びにネットワークの接続に基づきアプリケーション要求を調整又は修正することができる。例えば、ＭＭＳおよび／またはＭＥＳは学習され静的に定義されて適用されたルールエンジン、あるいは確立する各アプリケーションセッション、又は試みる要求に対するポリシーに基づく他のルールを含むことができる。ＭＭＳはさらにＭＥＳにこのようなルールの幾つか、全くなし、あるいは一部、および／または処理を配分して、メータリング（ｍｅｔｅｒｉｎｇ）、又は傍受者によるモバイルデバイスへの侵入（ｒｏｇｕｅ ａｔｔａｃｋｓ）に対するセキュリティを提供する。分散型トポロジで利用可能な特定の他のポリシー管理技術とは違い、ＭＭＳが中心となり、ルールやポリシー決定を管理し、それらを通信中いかなる時にも遠隔地のデバイスに分散させる。
【０２３４】
ルール自体は、ユーザ、ユーザ・グループ、デバイス、デバイスグループ、プロセスアプリケーションアイデンティティ、および／またはネットワークの接続ポイントに基づき構成可能である。一旦定義されると（学習されると）、ルールは組み合わされて、例えば、以下のものを含む種々の異なる事象、活動、および／またはサービスを管理し、制御する。
【０２３５】
・遠隔地のデバイスへの侵入アクセスの拒否、許可、又は調整
・アイデンティティに基づく特定のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・利用可能、又は許可された帯域幅へのアクセスの拒否、許可、又は調整
・他のネットワーク・リソースへのアクセスの拒否、許可、又は調整
・内容又は情報の修正、調整、又は変更
このような決定は例えば、以下の要素を含む種々の異なる要素に基づいて行われる。
【０２３６】
・モバイルデバイスについての近接性、場所、高度、および／または他の特性
・日時
・アプリケーション又はプロセスアイデンティティ、アドレス等
・アプリケーション動作（例えば、帯域幅条件）
・現在のネットワーク状態
・他の静的又は動的要素
さらに分散型アーキテクチャを利用することで、ＭＭＳは同じ決定セットを適用又は共有することができる。ポリシー管理処理および／または意思決定をＭＭＳに行わせるのは、例えばモバイル装置がエンジンを実行するのに限られた処理能力を持ったり、帯域幅の限度が適用されたり、あるいはセキュリティが目的の場合に望ましい。
【０２３７】
サンプルＭＥＳの制御に使用される可能性のあるメトリクス（ルール）の幾つかを示すテーブルの例を図２４に示す。このテーブルは静的又は動的のどちらかに内容を占めてもよいし、場合によっては通信前、通信中、又は通信後に更新されてもよい。例えば、ユーザはテーブルの項目を定義するルール・エディタ（例えば、ウィザード）や他のメカニズムを使用することができる。他の構成例において、メトリクスが学習に基づくシステムによって自動的に定義され、あるいは状態の変更に基づき動的に変更される。また、ルールにはそれぞれ優先順位が割り当てられ、テーブルの場所で暗示、または割り当てによって明確に指定される。この優先順位によってエンジンが期待動作を正確に決定することができる。付加的なユーザインターフェイスの機能によって、システム管理者やデバイスのユーザはルールエンジンに問い合わせて所定のルールセットの機能を試みることが可能となる。
【０２３８】
ポリシー管理決定の基になる、以下のメトリクスをはじめとする多数のメトリクス例を示すテーブル例を図２４に示す。
【０２３９】
・ＭＥＳの通信機能（送信のみ、受信のみ、送受信）
・ＭＥＳの要求がプロキシされるか否か
・ＭＥＳのソースポート
・ＭＥＳのソースアドレス
・ＭＥＳの目的地ポート
・ＭＥＳの目的地アドレス
・ＭＥＳのプロトコル
・利用可能な帯域幅量
・プロセス名、アイデンティティ又は他の特性
・ネットワーク名、アイデンティティ又は他の特性
・ロケーション（例えば、ＧＰＳ座標又は他のロケーション情報）
・ネットワークの接続ポイント
・ユーザの識別子、アイデンティティ又は他の特性
・他のメトリクス
上記テーブル例は完全なリストではなく、本発明は上記テーブル例のメトリクス項目の範囲に限定されるものではない。ネットワークアクセス及び権利付与に関してモバイルノードの所望の動作を示すために、該項目はこの例のように具体的であり、あるいは包括的なメカニズム（例えば、ワイルドカード）であることが可能である。
【０２４０】
図２４のテーブル例には、メトリクスに基づくポリシー管理決定の結果を示す「否定要求」項目がさらに含まれる。一例として、図２４のテーブルに示す特定の項目例は、利用可能な帯域幅が一秒間で１００，０００バイト以下に低減される場合、目的地ポート２０、２１との接続は否定され、減速されることを示す。さらに、示した特定の例において、ルール（列）３、４によってネットワークトラフィックのみがＭＭＳへ、又はＭＭＳから流れることが可能となる（プロキシが行われない他の全てのネットワークトラフィックは暗に破棄される。）。
【０２４１】
一例において、各ＲＰＣ要求又はフレームが処理される前に、ルールエンジンはオペレーションの状況を決定するよう求められる。このプロセスの結果に基づき、その要求が許可、否定、あるいは遅延される。ポリシー管理決定をするためにＭＭＳおよび／またはＭＥＳによって行われる処理のフローチャート例を図２５に示す。
【０２４２】
先に概略を説明したローミング技術と、利用可能な他のロケーション又はナビゲーション情報とを組み合わせることによって、ＭＭＳはモバイル端末システムがいつ１箇所の接続ポイントから別の接続ポイントへ移動したか検出する。ネットワーク・トポロジの環境の変化を検出するために、モバイル端末システムの機能と関連してこの情報を組み合わせることによって、ロケールによって本発明はロケーションベースの傍受及びサービスの付加的なレベルを提供することができる。
【０２４３】
この情報の可能性を十分実現させるために、インターネット・モビリティ・プロトコルとＰＲＣエンジンの両方の改良点について概要を説明する。新しいＲＰＣのプロトコル及び構成の改良点が追加され、この機能が可能となる。これらを以下に挙げる。
【０２４４】
（ロケーション変更ＲＰＣ（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ）の例）
モバイル端末システムが、インターフェイス支援型ローミング又はグローバル・ポジショニング・システムから変更を検出するといった他の方法を用いて新しい接続ポイントへ移動したことを判断した時、モバイル端末システムは、フォーマットされた「ロケーション変更ＲＰＣ要求（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ ＲＰＣ Ｒｅｑｕｅｓｔ）」メッセージをそのピア、この場合モビリティ管理サーバに送る。「ロケーション変更ＲＰＣ」は、一以上の接続ポイント識別情報をタイプ、長さ、値の形式にフォーマットする。タイプは識別情報の種類を示し、対応するタイプはＡＳＣＩＩの４８ビットＩＥＥＥ ＭＡＣ アドレス、ＩＰＶ４ アドレス、ＩＰＶ６ アドレス、経度、緯度、高度、接続機構名を含むが、これらに限定されない。長さは識別データのバイト長を示し、該データは実際の接続ポイント識別子を含む。「ロケーション変更ＲＰＣ要求」を受け取ると、モビリティ管理サーバは、接続ポイント識別子、並びにモビリティ端末システムの識別子、ユーザ名、ＰＩＤ等の他の関連情報を含む「ロケーション変更警告（Ｌｏｃａｔｉｏｎ Ｃｈａｎｇｅ Ａｌｅｒｔ）」を作成する。この警告は「ロケーション変更ＲＰＣ要求」内で使用された同じタイプ、長さ、データフォーマットでフォーマットされる。その後警告サブシステムが、警告のために登録された全てのアプリケーションにロケーション変更警告と共にこの情報を送る。警告のために登録されたアプリケーションは、現在の活動状況のモニタ、長期の動作ログ、ポリシー管理エンジン、第三者アプリケーション等の監視アプリケーション、並びにネットワーク管理ツールを含んでもよい。単一のそのような第三者アプリケーションは、このロケーション情報と、ウェブベースのマップとを組み合わせてモバイル端末システム又はＭＭＳの場所についての詳細情報を提供する。そのようなアプリケーションに加えて、他の動作をロケーション変更警告と関連付けることができる。これには、電子メールの送信、メッセージの印刷、プログラムの起動、および／またはポリシー変更が含まれる。
【０２４５】
ロケーション変更ＲＰＣはそのヘッダにロケーション変更、距離変更、又は速度変更によってトリガされたかどうかを示すフィールドを含む。
【０２４６】
ある例では、ＭＥＳは自身が移動したことを知らない場合がある。ＭＥＳが接続する媒体やネットワーク・アダプタに応じて、ＭＭＳはＭＥＳが新しい接続ポイントに渡ったことを知らせる唯一のエンティティであってもよい。モバイルルータの場合を考えてみる。ルータ以降のアドレスは同じままで、ルータのアドレスだけが変わる。この場合、ＭＭＳはＭＥＳのアドレスを新しく管理することを認識する。したがって、動作の検出を完了するためには、行動検出するためのＭＥＳとＭＭＳの両方の組み合わせの動作の検出が必要となる。本実施の形態では、ソースアドレスが変更され、新しいＩＭＰメッセージが受け取られる時に、ＭＭＳはＩＭＰ層でクライアントの行動を検出する。このことが行われると、ＭＭＳは局所的にロケーション変更警告を生成する。また、ＭＭＳは接続ポイントが変更したというメッセージをＭＥＳに送る。
【０２４７】
（トポロジＲＰＣの例）
「トポロジＲＰＣ要求（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｑｕｅｓｔ）」はモビリティ管理サーバからモバイル端末システムへ送られる。このＲＰＣの受け取りと同時に、モバイル端末システムはそのローカルデータ記憶装置に記憶されるトポロジ情報を読み出して、トポロジＲＰＣ応答（Ｔｏｐｏｌｏｇｙ ＲＰＣ Ｒｅｓｐｏｎｓｅ）を作成する。トポロジＲＰＣ応答は、前後との接続のタイプ、長さ情報が後に続く全長フィールド（Ｔｏｔａｌ Ｌｅｎｇｔｈ Ｆｉｅｌｄ）、タイプ、長さ情報が後に続く接続ポイント識別子、および、サブネットおよびネットワーク情報を示す値のデータによってフォーマットされる。この情報は、サーバで提供されるモバイルネットワークの完全なトポロジカル・マップを作成するのにサーバ上で使用されてもよい。
【０２４８】
（ロケーション情報ＵＩの例）
サーバ上のユーザインターフェイスは、ロケーション情報を対応付けして表示するための方法を提供する。このロケーション情報は、各アクティブなモバイル端末システムが利用でき、長期の動作ログは全てのアクティブなモバイル端末システム及び以前アクティブだったモバイル端末システムのロケーション変更履歴を保持する。ユーザインターフェイスによって、システム管理者は接続ポイント情報を人間が読める形式に構成できる。例えば、接続ポイント情報が４８ビットのＩＥＥＥ ＭＡＣアドレスの形式で与えられると、サーバ上のユーザインターフェイスを介して提供される情報と共にこのＭＡＣアドレスが表示される。接続ポイントが「ホールマークカード（ＨａｌｌＭａｒｋ Ｃａｒｄｓ）」店のアクセスポイントを示すと、次の情報「ホールマーク、住所、市、州、郵便番号」を提示するように設定される。この情報がユーザに対して表示されることによって、「ホールマーク、住所、市、州、郵便番号」情報が提供されることになる。
【０２４９】
（ロケーションＲＰＣタイマーの例）
設定可能なタイマーがモバイル端末システムに設けられており、ロケーション変更ＲＰＣがモバイル端末システムからモビリティ管理サーバに送信される速度を制限する。タイマー間隔が接続ポイントの変更が起こる速度よりも大きい場合、モバイル端末システムはタイマー間隔が終了するまで待ってから別のロケーション変更ＲＰＣを生成する。
【０２５０】
（距離変更通知の例）
距離メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。この設定によって、ユーザが前にいた元のポイントから、ｎフィート、ｎキロメータ毎、あるいは他の適当な測定単位で３次元的に移動する時に、更新を送信するようにシステムが構成される。デフォルトによってこの設定は無効になる。この設定を可能にすることによって、設定された距離間隔を上回った時に変更通知が出される。
【０２５１】
（速度閾値通知の例）
速度変更メトリクスは、ロケーション変更ＲＰＣの生成をトリガするために設けられる。このパラメータは、一時間当たりのマイル等、一秒当たりの距離で構成される。このパラメータは、上限及び下限、並びに到達した速度を持続する必要のある時間間隔（すなわち、１０分間で０ＭＰＨ、又は１分間で７０ＭＰＨ）を特定する。このスピードに達すると、ロケーション変更通知が生成される。
【０２５２】
［応用例］
本発明は、実社会の様々な場面で応用される。例を以下に示す。
【０２５３】
（断続的に接続される携帯用コンピュータ）
多くの企業では、在宅勤務や、自宅で仕事をする社員がいることがある。そういった社員は、多くの場合、ラップトップコンピュータを使用して仕事をする。作業中に、社員は一般に自分達のラップトップコンピュータをドッキングポート又は他のコネクタを使用してイーサネット（Ｅｔｈｅｒｎｅｔ）等のローカルエリア・ネットワーク（Ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）に接続する。ＬＡＮ接続によってネットワークサービス（例えば、プリンタ、ネットワークドライブ）やネットワーク・アプリケーション（例えば、データベースアクセス、電子データサービス）にアクセスが可能となる。
【０２５４】
あるプロジェクトに取り組む社員が、晩に帰宅する必要があり、自宅で仕事を続行したいとする。この社員は、ラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「サスペンド」して、ラップトップコンピュータを片付け、そのラップトップコンピュータを自宅に持って帰ることができる。
【０２５５】
自宅に戻るとすぐに、その社員はラップトップコンピュータで実行しているオペレーティングシステムとアプリケーションを「レジューム」して、ダイアルアップ接続を介して、および／またはインターネットを通じてオフィスＬＡＮと再接続する。（ラップトップコンピュータが一時的に中断された間、ネットワークに対するラップトップコンピュータとそのアプリケーションのプロキシを継続した）モビリティ管理サーバは、ラップトップコンピュータを再認証し、ラップトップコンピュータとの通信を再開する。
【０２５６】
自宅で仕事をしている社員の立場から見ると、ネットワーク・ドライブ・マッピング、印刷サービス、電子メールセッション、データベースクエリ、他のネットワークサービスやアプリケーションは全て会社で終わった状態そのままである。さらに、モビリティ管理サーバはラップトップコンピュータのセッションのプロキシを継続したため、社員の会社から自宅までの帰宅途中に、いずれのネットワーク・アプリケーションもラップトップコンピュータのセッションを終了しなかった。このように、本発明は、上記のような状況や他の状況において、高性能且つ有用な同一又は複数のネットワーク媒体を通じて効果的にセッションを持続可能とする。
【０２５７】
（モバイル在庫管理及び倉庫への応用）
大きな倉庫又は小売店チェーンを想定する。この構内において、在庫管理を行う従業員がパーソナルラップトップコンピュータ、並びにハンドヘルドデータ収集ユニットや端末装置などを搭載した乗物（すなわち、トラックやフォークリフト）を使って商品の在庫管理が行われる。
【０２５８】
倉庫や小売店の従業員は、ネットワークサブネットのわからない、管理監督の必要な不慣れなコンピュータユーザであることが多い。本発明によって倉庫ユーザがモバイルネットワークの複雑さを感じない、即使用可能なシステムの構築が可能となる。倉庫ユーザは、アクセスポイントの範囲内及び範囲外を動いたり、自分たちのモバイル端末システム１０４の中断及び再開をしたり、ホストセッション、ネットワークアドレス、又はトランスポート接続を気にせずに、位置を変えたりできる。さらに、モビリティ管理サーバ１０２の管理ソフトウェアは、従業員の生産能力を測るのに利用される処理数等のメトリクスを管理関係者に提供する。また、管理によりネットワークサブネット及びアクセスポイントを使用して従業員が最後にいたとされる物理的な位置を判定できる。
【０２５９】
（モバイル医療への応用）
無線ＬＡＮ技術を利用して幾つかの建物間でネットワーク通信を行う大きな病院を想定する。各建物は独自のサブネット上にある。本発明によって看護士や医師がハンドヘルドパーソナルコンピュータや端末を持って病室から病室を動き、病院のデータベースから患者情報の読出しや書込みが可能となる。ローカルデータベースやワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を通じて、薬物治療や医療処置に関する最新記事へのアクセスが即座に可能となる。本発明はモバイル端末システム１０４への連続的な接続が可能なので、病院にいる間（一方向又は双方向の）ポケットベルはもはや必要なくなる。メッセージはモバイル端末システム１０４を介して医療関係者に直接送られる。倉庫の従業員の場合と同様、医療関係者は自分たちが利用しているモバイルネットワークについてわかる必要はない。さらに、モバイル端末システム１０４によって医療関係者は無線送信が望ましくないとされるエリア内（例えば、電波の放射によって医療機器に障害が出る可能性のある場所）での無線伝送ができなくなるが、中断したところから容易に再開して再接続可能となる。
【０２６０】
（トラック輸送及び貨物輸送）
運送会社は、貨物の状況を把握するのに本発明を用いる。倉庫に入っている間は、モバイル端末システム１０４はＬＡＮ技術を使用して倉庫内の貨物数を更新する。ローカルサービスから離れている間は、モバイル端末システム１０４はＣＤＰＤやＡＲＤＩＳ等のＷｉｄｅ Ａｒｅａ ＷＡＮサービスを使用してリアルタイムで貨物の状況や位置を維持できる。モバイル端末システム１０４はネットワーク・インフラストラクチャ間を自動的に切り替えるので、輸送関係者にネットワーク・トポロジの複雑さを感じさせない。
モバイル企業
企業の社員は、８０２．１１．等のインフラストラクチャが設けられた企業構内にいる間、本発明によるシステムを使用して、電子メール、ウェブコンテント、メッセージサービスへのアクセスを行う。ポケットベルサービスや他のモバイル機器のサービスはもはや必要ないので、これらを維持するためのコストが削減される。既存のモバイル機器サービスの多くが提供する、コストのかかる「利用回数制（ｐａｙ−ｐｅｒ−ｕｓｅ）」モデルに対し、モバイルインフラストラクチャは一度の資金支出で購入できる。
【０２６１】
（ＩＰマルチプリケーション）
ある組織がインターネットに接続する必要のあるＬＡＮを有する場合、ＬＡＮの管理者には二つの選択肢がある。一つ目の選択は、ＬＡＮ上の全てのコンピュータに対して割り当てるためのグローバルアドレスを取得することであり、二つ目の選択は、グローバルアドレスをいくつか取得して、アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を使用することである。多数のＩＰアドレスを取得することは、高額であるか不可能であるかである場合が多い。インターネット・サービス・プロバイダ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｉｖｉｄｅｒ； ＩＳＰ）を利用してインターネットにアクセスする小規模の企業は、ＩＳＰが割り当てるＩＰアドレスだけを使用することになる。ＩＰアドレスの数は同時にインターネットに接続できるコンピュータの数を制限する。また、ＩＳＰは一回の接続につき課金するため、インターネット接続が必要なコンピュータが増えれば増えるほど、この方法はそれだけ費用がかかる。
【０２６２】
アドレス・マルチプライヤとして本発明に従ったモビリティ管理サーバ１０２を用いれば、これらの問題の多くを解決することができる。企業は、ＩＳＰを介してインターネットに接続するためのハードウェアとしてモビリティ管理サーバ１０２を用いることができる。これにより、モバイル端末システム１０４は容易に接続することができる。インターネットへの接続は全てモビリティ管理サーバ１０２を通じて行われるため、一つのアドレスだけをＩＳＰから取得すればよい。このように、アドレス・マルチプライヤとして本発明を用いることによって、企業はわずかな数（多くの場合一つ）のアドレスとアカウントをＩＳＰから取得すればよくなり、全体のＬＡＮでインターネットへの同時接続（十分な帯域幅が備えられていることを前提として）が可能になる。
【０２６３】
以上現在最も実用的且つ好適な実施形態とされる例と共に本発明を説明したが、本発明は開示した実施形態に限定されず、添付クレームの範囲内で種々に変形、同等に構成できるものとする。
【図面の簡単な説明】
【図１】
本発明のモバイル・コンピューティング・ネットワークの全体図である。
【図２】
モバイル端末システムとモビリティ管理サーバとのソフトウェア・アーキテクチャを例示するものである。
【図２Ａ】
モバイル端末システムとモビリティ管理サーバとの間で情報伝達を実行するステップを例示している。
【図３】
モバイル・インターセプタ・アーキテクチャを例示している。
【図３Ａ】
モバイル・インターセプタによって実行されるステップを例示したフローチャートである。
【図３Ｂ】
ＲＰＣ作業要求を扱うＲＰＣエンジン（ＲＰＣ ｅｎｇｉｎｅ）によって実行されるステップを例示したフローチャートである。
【図４】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ａ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｂ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図５Ｃ】
ＲＰＣ作業要求を処理するステップを例示したフローチャートである。
【図６】
受信された作業要求を例示している。
【図７】
受信された作業要求が、どのようにそれぞれ別の優先度のキューにディスパッチされるかを示すものである。
【図８】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図９】
上記それぞれ別の優先度のキューにおけるコンテンツの処理を示している。
【図１０Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１０Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１１】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１２Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１３Ｃ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１４Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ａ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１５Ｂ】
インターネット・モビリティ・プロトコルを提供するために実行されるステップを例示している。
【図１６】
リスナのデータ構造を例示している。
【図１７】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１７Ａ】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１８】
モバイル相互接続ローミング（ｍｏｂｉｌｅ ｉｎｔｅｒｃｏｎｎｅｃｔ ｒｏａｍｉｎｇ）を提供するためのステップを例示している。
【図１９Ａ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図１９Ｂ】
インターフェイスによって補助されたローミング処理を例示する一つのフローチャートを形成している。
【図２０】
インターフェイスによって補助されているローミングのトポロジ・ノード・データ構造を例示する。
【図２１】
モビリティ管理システムのネットワークアドレスを、非接続ネットワーク・トポロジにおいてモバイル端末システムに配布する技術を例示している。
【図２２】
図２１の技術を、セキュアな通信を実現するために利用した例を示している。
【図２３】
図２１の技術を、分散型ネットワーク・インターフェイス・シナリオにおけるネットワークアドレスの変換に用いた例を示している。
【図２４】
ポリシー管理テーブルを例示している。
【図２５】
ポリシー管理処理のステップを例示したフローチャートである。[Background of the Invention]
The present invention relates to connectivity between computer devices connected by a network. More particularly, the present invention relates to a method and a system for treating the characteristics of a nomadic system in a state of being transparent, and for ensuring that existing network applications operate in a corresponding mobile environment. More specifically, the present invention relates to a technology and a system that enable continuous data streams to be exchanged between devices such as handheld data units and personal computer devices that are intermittently connected.
[0001]
[Background and Abstract of the Invention]
In recent years, companies have come to recognize that quick access to important information is a way to stay competitive. For this reason, especially with the spread of inexpensive laptops and handheld computer devices, computer devices with intermittent connections, such as mobile devices, are rapidly becoming an important element of corporate networks. However, integrating these nomadic devices into the existing network infrastructure has been a headache for information managers at each company.
[0002]
Many of the problems associated with mobile networking are similar to those associated with building a local area network (LAN) prior to the advent of Ethernet. That is, since there are many types of mobile protocols and interfaces, and standards are still being established, there is no interoperability between different systems. Furthermore, communication using the above network technologies is usually slow and has a limited bandwidth, and the costs associated with updating are high due to the particularity of each system.
[0003]
In addition to these issues, mobile technology also has the following inherent problems. That is, when interconnecting with the main network, there is a case where the connection is made via a public network infrastructure. At this time, there is a risk that confidential information may be intercepted. Furthermore, if interconnected via wireless devices, confidential information would be "broadcast", so to speak, anyone with a similar interface would be able to intercept that information without much obstacles. I can do it.
[0004]
But perhaps even more important than the above, mobile networking has traditionally been limited to message-oriented or stateless applications, and has a client / server, host / terminal approach. It is not suitable for existing or new business applications using Web-based or file-sharing system models. This is because a typical business application requires not only stateless packet exchange but also a stateful session using a continuous data stream to operate effectively and reliably. .
[0005]
For this reason, most major commercial network applications require TCP / IP sessions or dedicated virtual circuits. Such sessions cannot function anymore if the network is interrupted, and roaming between networks (change of network address) is not possible when connected. Further, mobile networking is dynamic in nature and unreliable. Regarding these issues, the following considers some common situations in mobile networks.
[0006]
(Disconnected or out of service users)
When a mobile device is disconnected from a given network or loses contact with the network (ie, goes out of range of the wireless interconnect or enters a "hole" that the network does not cover), A running session-oriented application loses its stateful connection with its peer and stops working. When the device is re-attached or the device and network contact is restored, the user reconnects to the network and performs a re-login for security to identify where in the application the work was interrupted. If necessary, the lost data must be re-entered. Such a reconnection process is time consuming, expensive, and very frustrating for the user.
[0007]
(Move to another network or cross router boundaries (change of network address))
Mobile networks are typically segmented from a manageability standpoint, while mobile devices are roaming enabled for their use. Roaming between interconnected networks means that the network address is changed. If the network address is changed during the operation of the system, it is necessary to change the routing information in order to maintain the connection between the corresponding peers. Furthermore, in order to obtain a new network address, it may be necessary to terminate all sessions of the stateful application established up to that point, and the above-mentioned problem relating to the reconnection process also emerges here.
[0008]
(Security)
As mentioned, companies need to protect sensitive information. Many off-the-shelf applications have controlled access to the physical network (that is, performed using cables built inside secure facilities), and security requires additional authentication and possibly encryption. It is created on the assumption that it is retained through layers. However, in nomadic computing these assumptions are not self-evident. This is because there is a risk that data may be intercepted when passing through public radio waves or wired infrastructure.
[0009]
Therefore, there is a great need for an integrated solution that allows existing network applications to operate reliably in various mobile environments by making the characteristics of the nomadic system transparent. .
[0010]
The present invention solves the above problem by extending the corporate network so that network administrators can easily access mobile device users with the same applications as fixed device users. At the same time, it offers a consistent solution without losing reliability or centralized network management. The solution also supports existing network applications by adding the strengths of the previous wired networking standard to the evolving mobile networking standard.
[0011]
In one aspect of the non-limiting exemplary specific embodiment of the present invention, a mobility management server (MMS) connected to a mobile interconnect comprises a mobile terminal with an unlimited number of mobile terminals. It manages the state of each system (Mobile End Systems; MES) and manages the complex sessions required to maintain a continuous connection to the network and application processing at the peer. If a mobile terminal system goes out of range, suspends, or changes its network address (for example, by roaming from one mobile interconnect to another), the mobility management server will Maintain a connection between the system and a peer that corresponds to the system. In other words, the mobile terminal system keeps maintaining the virtual connection with the peer even though the physical connection is actually interrupted.
[0012]
Further, the non-limiting and specific embodiments of the present invention present the following (but not limited to) new and useful techniques and configurations.
[0013]
A mobility management server that gives session characteristics configurable by the user to the mobile client.
[0014]
-Manage mobile device policies on a per user basis with respect to network resource consumption.
[0015]
A roaming method that uses an industrial standard Dynamic Host Configuration Protocol (DHCP) in cooperation with a mobility management server.
[0016]
-Automatically remove unreliable datagrams from the system based on timeout conditions that can be set by the user.
[0017]
-Automatically remove unreliable datagrams from the system based on retry conditions that can be set by the user.
[0018]
More specifically, in an example of the preferred specific embodiment of the present invention, there is provided a mobility management server connected to the mobile interconnect network. The mobility management server maintains the state of each of the mobile terminal systems in an unlimited number, and provides a continuous connection to the network and other processing (eg, processing performed in other network-based peer systems). Manage complex sessions needed for maintenance. If a mobile terminal system goes out of range, suspends, or changes the network address (for example, by roaming from one mobile interconnect to another), the mobility management server will Recognizing the reception and waiting request of the system, it maintains the connection between the system and the corresponding peer. By operating the mobility management server as a proxy in this way, an application operating on the mobile terminal system can maintain a persistent connection even if the physical connection with a certain network medium is temporarily interrupted. Can be.
[0019]
In another example of the preferred embodiment of the present invention, the mobility management server manages an address for the mobile terminal system. Each mobile terminal system is assigned a proxy address on the primary network. This very versatile address is called the "virtual address" of the mobile terminal system. The mobility management server associates this virtual address with the current "location" address in the nomadic system. The location address of the mobile terminal system changes as the system moves between networks, but the virtual address is the same as the address, no matter which connection is active or the connection time is long. Is constant as long as is statically assigned.
[0020]
In yet another example of the preferred embodiment of the present invention, the mobility management server implements centralized management of the mobile terminal system by means of a console (control) application and comprehensive metrics. Furthermore, in a preferred embodiment, user-configurable session characteristics are implemented for mobile clients running on a proxy server, and policy settings of the mobile device are managed on a per-user basis with respect to consumption of network resources.
[0021]
Further, in one aspect, the remote procedure call (RPC) protocol (Remote Procedure Call protocol) and the Internet Mobility Protocol (Internet Mobility Protocol) are used for communication between the proxy server and each mobile terminal system. Used for establishment.
[0022]
The remote procedure call allows a local system to call a procedure in a remote system. Using the RPC protocol, the mobile terminal system disconnects, goes out of service, or suspends operation. Can be done without interrupting active network sessions. As described above, since session maintenance is not performed by a dedicated application, a commercially available application can be used in a nomadic environment without any change.
[0023]
The RPC protocol creates transactions into messages sent over standard network transport protocols and infrastructure. This RPC message contains the entire network transaction initiated by the application running on the mobile terminal system, thereby providing connection status information between the mobility management server and the mobile terminal system between them. It is possible to always synchronize even when the physical connection is interrupted. In the above embodiment of the present invention with RPC, the proxy server and the mobile terminal system provide sufficient information about the status of each transaction to manage a unified logical database for all shared connections at all times. Sharing.
[0024]
The Internet Mobility Protocol in the preferred embodiment of the present invention compensates for differences between wired local area networks and less reliable networks such as wireless LANs and WANs. By adjusting the frame size and the protocol timing, the performance is greatly improved and the traffic of the network is greatly reduced as compared with the communication not considering the mobile environment. This is especially important when bandwidth is limited or when battery life has to be taken into account. Furthermore, the Internet mobility protocol in the preferred embodiment of the present invention ensures the security of confidential data when transmission is performed between the mobile terminal system and the mobility management server through a public network or wirelessly. The Internet Mobility Protocol also acts as a basic firewall by allowing only authorized devices to access private networks. In addition, all communication between the mobile terminal system and the mobility management server can be authenticated and encrypted by the Internet mobility protocol.
[0025]
In yet another example of the preferred embodiment of the present invention, the mobile interconnect uses standard transport protocols (e.g., TCP / IP, UDP, etc.) to extend the scope of standard network application interfaces. / IP, DHCP, etc.). According to the preferred embodiment of the present invention, data transfer, security, address management, device management, and user management can be effectively integrated, and the nomadic environment can be effectively made transparent. The Internet Mobility Protocol multiplexes multiple data streams, both reliable and unreliable, over a standard network infrastructure over a single virtual channel provided by a standard transport protocol. Provide an effective way to
[0026]
Using the RPC layer, the Internet Mobility Protocol fuses data coming from different sources and destined for different or same destinations into a single data stream that is sent over the mobile link. At the opposite end of the mobile link, the data stream is demultiplexed into a plurality of different data streams, which are transmitted to their respective final destinations. This multiplexing / demultiplexing makes it possible to make maximum use of the available bandwidth (by generating network frames of the maximum size) and to establish multiple channels (thus priority) Ranking can be provided, and if the underlying network provides a data communication service, its quality could be guaranteed).
[0027]
The Internet mobility protocol according to the embodiment of the present invention further realizes the following features and advantages. The present invention is not limited to the following points.
[0028]
Transport protocol independence
The ability to change the point of presence (POP) or network infrastructure on the network without affecting data flow (only if there are no physical boundaries, policies, or bandwidth constraints)
・ Minimum additional costs
Automatic fragment resizing suitable for the transmission medium (when the protocol data units of a frame are larger than the maximum available transmission units of the network medium, the Internet Mobility Protocol fragments the frame; Rebuilding, which ensures that the frame is transmitted over the network, upon retransmission, the frame is checked again, and if the network infrastructure or environment has changed, It is re-fragmented or transmitted as a single frame when the upper limit of the transmission unit is actually raised.)
Keeps unreliable data semantics by causing frames to discard unreliable data during retransmission
Providing new semantics in reliable datagram services (this guarantees the transmission of datagrams to peer terminals by the Internet Mobility Protocol and informs the requesting entity of the transmission)
-Handles uplink and downlink transmission paths separately and automatically adjusts operation parameters to achieve optimal throughput (based on hysteresis, frame size / fragmentation threshold, number of waiting frames (window), Adjust parameters such as transmission time and delayed acknowledgment time to reduce the amount of duplicate data sent over the network).
[0029]
・ Resilience against network failure (Since use in a mobile environment is assumed, even if the connection between network media is temporarily disconnected, the virtual channel is disconnected or the application-based connection is disconnected. No)
Providing peers with in-band signaling to adjust operating parameters (Each connected terminal can alert its peers about changes in network topology or environment)
・ Adopts congestion avoidance algorithm and effectively attenuates throughput when necessary
-Selective acknowledgments and high-speed retransmissions limit the number of unnecessary retransmissions, speeding up handoff recovery in nomadic environments. (This allows the protocol to have optimal throughput even in a lossy network environment.) Maintain)
Adopting sliding window technology, which puts multiple frames in a standby state (this parameter is adjustable in each direction and given to stream frames up to a certain upper limit without the need for acknowledgment from peers)
・ Sequence numbers are non-byte oriented, so a single sequence number can represent up to the maximum payload size
・ Security measures (authentication layer and encryption layer can be added to Internet mobility protocol layer)
Compression ensures efficiency over limited bandwidth connections
・ Balanced design that both peers can move to new positions
-Connection to peer can be established from either side
-Pause timeout can be triggered to quickly destroy dormant connections and recover consumed resources
An arbitrary maximum duration can be set for the connection (for example, the connection can be terminated and / or rejected after a predetermined period of time or after a predetermined date and time).
[0030]
In a preferred specific embodiment of the invention, the consumption of network resources by a system administrator can be managed. For example, the system administrator can control at least one of the mobile terminal system and the mobility management server. The control in this case refers to, for example, management of network bandwidth and distribution of other resources, and security-related matters. Effectively, management is performed for clients that have a large number of resources on the client side. However, it is undesirable to impose additional code and processing for policy management on thin clients that do not have many resources. Therefore, it is considered that the most practical solution is to manage the thin client intensively by the mobility management server or the like, or to share a part thereof. Policy management is centralized by the mobility management server proxying each data stream of the mobile terminal system. Further, since the mobility management server performs proxy for each user, access to network resources can be managed and restricted for each user and each device.
[0031]
As a simple example, a mobility management server may “lock out” access to certain network resources by a particular user. This is very important given that the network of interfaces has been “extended” beyond the boundaries of the facility under the control of the organization by the mobile interconnect (eg, as previously described). (Suppose a former employee attempts to access the network of the workplace where he worked.) Beyond this, policy management by the mobility management server can provide even more benefits. For example, the mobility management server may make certain URLs accessible only to specific users, filter data returned by requests by network services, and compress data to conserve network bandwidth. It is possible. In this way, existing or new application-level services can be enhanced in a seamless and transparent manner.
[0032]
In addition, since the mobile terminal system is also connected to an “untrusted” network (that is, a network outside the control of the organization), a malicious cyber attack may occur during remote connection. Sharing policies and filters with the mobile terminal system enables the mobile terminal system to be protected from malicious connections, ingress filtering at remote nodes, and further security for centralized management of enterprise infrastructure. Become.
[0033]
In another example of an embodiment of the present invention, an interface assisted roaming listener enables a mobile terminal system to perform an interface assisted roaming using an interface that supports general signaling. Becomes possible. In one aspect of the exemplary embodiment of the present invention, the interface-based listener of the mobile terminal system allows the mobile terminal system to perform a mobile event upon a predetermined event (e.g., callback, timer timeout, network activity indicating data loss, etc.). It is determined whether or not the connection state of the medium of the terminal system has changed. This means, for example, that the listener detects that the mobile terminal system has been disconnected and is no longer able to communicate with the network, and indicates this to the interface. At the time of reconnection, the listener refers to the network point in the connection identification information (attachment identification information) recorded in advance, and determines whether the mobile terminal system has been reconnected to the same network point. If the reconnection was to the same network point, the listener alerts the mobile client to proceed with re-establishing communication at the transport level. If the reconnection has been made to another network point, the listener indicates that the mobile terminal system is in a "roaming" state and causes the system to obtain an address available on the current network segment. (This may include, for example, registering the current address to be valid in the new subnet). The listener maintains a map of the network topology (learned through operations) to help determine the suitability of signals generated for that client ("roaming on the same subnet", "roaming", etc.). Is also good.
[0034]
In another example of the non-limiting preferred embodiment of the present invention, the mobility management server (MMS) can be accessed in a "disconnected networking" mode. This new algorithm allows an alternative network to be used to establish / persistent communication with the MMS, even in disconnected network topologies where one network infrastructure does not know the network address in another network infrastructure. Addresses can be found dynamically / statically. With this configuration, a list of alternative addresses available to the MMS is preset and sent to the MES (mobile terminal system) during communication or dynamically learned by the MES. In one embodiment, the MMS may send the MES one or more MMS network addresses or other MMS identities corresponding to other networks by communication over a single network. The list can be sent / updated at the time of circuit construction or any other time during connection establishment.
[0035]
As the MES moves to another network, the MES uses the MMS's "alias" address / identity list to contact the MMS through a new network connection in that network. This allows the MES to re-establish contact with the MMS through a new network connection even if the pre-move and post-move networks do not share addresses, routes, or other information.
[0036]
In yet another example of the embodiment of the present invention, the decision on policy management is made inside a distributed mobile network topology, for example, where a rule-based policy management procedure is used to request based on various metrics. Allow, reject, or restrict performance. Such a management form is used, for example, when making a decision based on cost metrics such as minimum cost routing in a multihome / path environment.
[0037]
In such a policy management technique, matters relating to mobility or location acquisition (that is, roaming) may be taken into account when making a decision. For example, management rules may be determined based on the location of the device (eg, which connection point of the network, eg, which access point / base station, hub, router, GPS coordinates, etc.), so that certain operations may be For example, it may be allowed in one building but not in another. For example, this configuration may be useful for a company that uses a plurality of different wireless networks. In such a company, for example, a loading dock and an office may be connected by a wireless network. The system administrator can prevent employees (e.g., users and devices) at the loading dock from accessing the wireless network in the office environment. In addition, policy management can result in one of three states: allow, deny, or delay (e.g., if the decision is made based on bandwidth or cost, the operation may be more appropriate). Is delayed until the right time comes).
[0038]
In the policy management in the above embodiment, the operation can be changed based on the determination. One example of an action is to reduce bandwidth consumption by all active applications. Also, for example, when there is a specific application that consumes a significant amount of bandwidth, a policy engine can manage the speed of completion of an operation / transaction by the application. This operation may dynamically learn to suppress the operation of the wrong application. Another example of an action is data recovery (e.g., dithering a graphic image based on available / allowed bandwidth and cost, and user restrictions).
[0039]
Furthermore, the rules engine fires other actions based on the rule evaluation. External procedures may be performed, such as logging an event, issuing an alert, or notifying a user that an action has been denied, delayed, or conditioned. Notifications such as these may be interactive, such that an operator may be required to override an existing rule.
[0040]
In the policy management engine in the above embodiment, the decision is made based on any number or combination of metrics associated with a device, a group of devices, a user group, a user, or a network connection point. It may be done.
[0041]
Other local-based information and services may be obtained / provided for policy management, network modeling, and / or asset tracking as part of the policy management function. Such a service includes a function of automatically providing information related to the current position of the mobile terminal system to the user or the mobile terminal system. The information may be provided in a message, file, or other electronic format.
[0042]
Non-limiting examples of use of this function include shopping mall operators, various industry groups, and large-scale retailers, who are installing Bluetooth PAN, IEEE 802.11 LAN, 802.15 PAN, and other wireless network standards on shopping centers. In some cases, wireless access points are strategically provided. In this case, the shop near the current location of the mobile terminal system can present information to the customer as the customer roams around the center. This information includes information on sales, discounts, benefits, and the like. In addition, an electronic coupon for sales promotion may be supplied to the mobile terminal system. Stores will register such services with mall management, industry associations, retailers, or other centralized administrations of service providers.
[0043]
Other non-limiting examples of where the above technology can be used include in the vertical industry, such as on-site services, door-to-door sales, home delivery, etc., to collect information based on location, community services, maps, directions, customers, accidents and other public services. Is sent to the mobile terminal system based on the location.
[0044]
Yet another non-limiting example is a web-based service for monitoring and tracking mobile terminal systems. For example, a customer registers with the tracking service, and a trusted third party logs on to a hosted web service to identify the exact location of the customer's mobile terminal system. In this case, the mobile terminal system may be provided in a vehicle or may be carried by a pedestrian. Such services are becoming more and more realistic as mobile terminal systems become smaller and lighter. By using the service, it is possible to track and confirm the location of high-risk people, for example, the elderly, the disabled, and the sick. The service can also be used to track automobiles and other expensive personal property and luggage. The above service is extremely low by utilizing a characteristic that 3G WAN network, Bluetooth network, 802.11 network and other wireless technologies can be used to maintain seamless connectivity even when switching network media and connection points. It can be implemented at cost.
[0045]
Thus, the present invention extends the corporate network and allows network administrators to provide users of mobile terminals with easy access to applications on fixed terminals without sacrificing reliability or centralized management. It is possible to provide as in the case of the user. The solution combines the strengths of existing wired network standards with the mobility standards that are in the process of being created, creating a solution that can run on existing network applications.
[0046]
Other objects, features and advantages of the present invention will be more fully understood from the following description. Also, the advantages of the present invention will become apparent in the following description with reference to the drawings.
[0047]
[Detailed description of preferred embodiments]
FIG. 1 illustrates a mobile enhanced
[0048]
In this case, the
-A plurality of mobile
[0049]
Communicate with the
[0050]
-Yet another mobile terminal system (e.g., 104n) is nomadically connected to the
[0051]
The
[0052]
The
[0053]
For example, the
[0054]
The
[0055]
As an example, the
[0056]
The
[0057]
In one example of the present invention,
[0058]
Each of the mobile
[0059]
The
[0060]
The
[0061]
Thus, a change in the location address of the
[0062]
In the presently preferred embodiment, the
[0063]
The proxy server function of the
[0064]
More specifically, the
[0065]
(Example of server / client type software architecture)
FIG. 2 illustrates an example of a software architecture of the
[0066]
In the present invention, a new
[0067]
The
[0068]
In addition, the
[0069]
FIG. 2A shows an example of a high-level flowchart showing how the
[0070]
Returning again to FIG. 2, the
[0071]
Further, according to FIG. 2, the
[0072]
(Mobile interceptor)
FIG. 3 shows an example of the software architecture of the
[0073]
Thus, the
[0074]
Network applications typically utilize application-level interfaces, such as Windows sockets. A single call to an application-level API generates multiple transmitted and received data packets at the transport or media access layer. In a preferred mobile network, if one of the above packets is lost, the session will be aborted due to the unstable state of the entire connection, but a preferred embodiment of the present invention comprises RPC. The
[0075]
The Internet Mobility Protocol of the present invention compensates for differences between wired networks and other less reliable networks such as wireless. Modifying the frame size and protocol timing can significantly improve performance and significantly reduce network traffic as compared to transports that do not consider the mobile environment. This is important when bandwidth is limited or battery life is a concern.
[0076]
The Internet Mobility Protocol of the present invention also guarantees the security of confidential information when communication between the
[0077]
The remote procedure
[0078]
The Internet
[0079]
FIG. 3A illustrates a process in which the
[0080]
If the fusion timeout expires or the
[0081]
As described above, the proxy server of the
[0082]
Subsequently, the Internet mobility protocol engine 244 'converts the received message into an RPC receive indication
[0083]
From the join-related
[0084]
(Method of executing RPC combination by RPC engine 240 ')
FIG. 4 is a flowchart illustrating a process of executing the RPC combination added to the
[0085]
The RPC work requests according to the present embodiment are classified into the following six basic types.
[0086]
-Scheduling request (schedule request)
・ Connection suggestion
・ Disconnect suggestion
-Local terminating association
・ "Resource available" request ("resource available" request)
-Ping inactivity timeout
The RPC protocol engine 240 'handles the various types of requests described above in different ways. RPC protocol engine 240 'tests the type of request (identified by information about the request stored in global queue 358) to determine how to handle the request.
[0087]
If the type of work request is "scheduling request" (decision block 360), the RPC protocol engine 240 'determines which combination is scheduled (block 362). The RPC protocol engine 240 'can make this determination based on information stored in the
[0088]
FIG. 5 illustrates the steps performed by the “join work process”
[0089]
The above process is repeated until the "scheduling weight complete" test (block 404) is passed. In this example, the scheduling weights are used to determine how many work requests are taken out of the wait state and how much of the particular combination is processed. The scheduling weight is a parameter set by the
[0090]
After the RPC engine completes (at least temporarily) work on the combined
[0091]
Referring again to FIG. 4, if the RPC work request is a "connection suggestion" (decision block 370), the RPC engine 240 'will provide a new connection with the mobile peer (typically, but not limited to the mobile terminal system 104). There is a request to create an instance of the connection. As an example, the connection suggestion provides RPC engine 240 'with the following information about the device of the peer that is initiating the connection.
[0092]
.Physical identifier of the device
・ User name logged in to the device
The address of the peer device
Additional connection data from
Upon receiving the connection suggestion (decision block 370), the
[0093]
Allocate a coupling control block (
Initialize the resources of the entire system to the default (block 372B)
Override current settings (block 372C)
Initialize the flag (block 372D)
Initialize the join specific work queue (block 372E)
Initialize the object hash table for the join (block 372F)
Initialize the fusion timer (block 372G)
Insert a join control block into the session table (
If the Internet Mobility Protocol Engine 244 'determines that the binding must be terminated, a "disconnect indication" is issued from the Internet Mobility Protocol Engine 244' to the RPC engine 240 '. The RPC engine 240 'tests this disconnect suggestion (block 374), stops binding in response to the suggestion, and discards the bind control block (block 376). As shown in FIG. 5B, the following steps may be performed.
[0094]
Mark the join to be stopped so that pending work is not processed further (block 376A)
Close all joined objects, including processing (block 376B)
Release all elements in the work queue (block 376C)
Stop if the fusion timer is running (block 376D)
Decrement the reference count of the join control block (block 376E)
If the reference count is 0 (tested at block 376F)
-Discard the join-related work queue,
Destroy the object hash table,
-Discard the fusion timer,
・ Remove the join control block from the join table,
-Release the control block (376G)
When the
[0095]
In the preferred embodiment, the interface between the RPC engine 240 'and the Internet Mobility Protocol engine 244' specifies a flow control mechanism based on credits. Each time a single thread notifies another thread of a work request, the called thread returns to the number of credits remaining in the work queue. If the queue is full, the credit count will be zero, but by convention, the calling thread will not send any more work notifications if the credit count is zero. Thus, a queue that can be set by the user or a predetermined low-water mark is given to the calling thread to inform that the work that has been waiting has been processed and resources have been made available. Such a configuration is required. This is why a "resource available" work suggestion is provided (tested at decision block 380). As shown in FIG. 5C, when the credit count becomes 0, the following steps may be executed.
[0096]
Set the RPC_LMPQ_SEND_FLAG to mark the join as "low mark pending" (block 379A). When this happens,
Discard all datagrams received (block 379B)
Reject data reception and suppress all received stream events (block 379C) (this will eventually close the TCP and other transport reception windows and cause the fixed
[0097]
-All received connection events are rejected due to passive connection (block 379D)
When the "resource available" indication is received by the RPC engine 240 '(FIG. 4, decision block 380), the RPC engine determines whether there is work waiting in the combined
[0098]
Referring again to FIG. 4, if the RPC engine 240 'determines that the channel used for "ping" the
[0099]
(RPC parsing and priority queue)
Referring again to FIG. 5, it was mentioned above that the RPC engine parses the RPC receive request upon receiving it (see
[0100]
In the example of FIG. 6, a
[0101]
Therefore, the
[0102]
-Each RPC receive
One or more RPC calls 506 may be present in a
-Each RPC call 506 may be completely included in
-Each RPC call 506 may span one or
FIG. 7 illustrates an RPC
[0103]
When the
[0104]
In this embodiment, the mobile application calls the "open address" and "open connection" object functions before performing other TDI networking functions. Thus, the system assigns application-level priorities during the invocation of the "open address" and "open connection" objects. In the illustrated embodiment, once an address or connection object has been prioritized, all calls associated with that object are performed during its assigned priority.
[0105]
For example, if the RPC call is a TDI open address object request or a TDI open connection object request, the call is sent to the
[0106]
In the preferred embodiment, all RPC calls have at least an address object or connection object as a parameter. When the call is executed, the priority assigned to the object is made the priority of the RPC call. The settings assigned to the address or connection object determine the priority of all corresponding RPC calls to be made. For example, if the assigned priority is “high”, all RPC calls are executed immediately without being dispatched to dispatch
[0107]
Referring again to FIG. 5, once the processing of the "process association work"
[0108]
In this example,
[0109]
Starting from the current queue, the RPC engine 240 'dequeues the RPC call from the queue and loops until the queue is empty or the queue weight number of the RPC call has been processed (block 412). 416). For each de-queued RPC call, an
[0110]
After exiting the loop, if there is more work left in the queue (decision block 418), the queue is marked as needing re-execution (block 420). Upon exiting the loop, the system moves the processor to the next lower priority queue (
[0111]
(Mobility management server RPC response)
The above describes how a remote procedure call is sent from the
[0112]
The RPC event is emitted as a result of the activity of the
[0113]
A disconnection event (occurs when a binding specific connection peer (usually the fixed terminal system 110) issues a disconnection request at the transport level, the request being received by the
A stream reception event (occurs when a combined specific connecting peer (usually the fixed terminal system 110) sends stream data to the
A datagram reception event (any of the association-specific portals is sent from a network peer (usually a fixed terminal system 110) and sent to the
When a connection event (association-specific listening portal) attempts to establish an end-to-end connection between the transport layer and the
FIG. 9 illustrates how the RPC engine 240 'handles RPC calls generated by a proxy server. For higher priority addresses and connection objects, the RPC engine 240 'immediately dispatches transmission requests to the Internet Mobility Protocol Engine 244'. The transmission request causes the RPC message to be forwarded to the
[0114]
(Example of Internet Mobility Protocol)
The Internet Mobility Protocol of the present invention is a message-oriented, connection-based protocol that can guarantee delivery, (re) order detection, and recover from loss. Further, unlike other traditional connection oriented protocols (ie, TCP), it allows multiple separate data streams to be combined into a single channel, providing guaranteed data, unreliable data, and New message-oriented and reliable data can be simultaneously traversed over the network by a single virtual channel. This new level of message-oriented service will cause the request portion to be notified when the Internet Mobility Protocol peer sees a given program data unit.
[0115]
The Internet Mobility Protocol of the present invention is designed to overlay existing network topologies and technologies. The Internet mobility protocol is versatile because it is independent of the underlying network architecture. As long as the packetized data can move between the two peers, the use of the Internet Mobility Protocol is possible. The point of network (POP) or network infrastructure at each node can be changed without affecting the data flow, unless there are physical boundaries, specific policies, or bandwidth limitations.
[0116]
The Internet Mobility Protocol fuses data from various sources with the help of the upper layer and uses the datagram function of the lower layer to move the data back and forth. As each independent data unit comes from the upper layer, the Internet Mobility Protocol then transmits the data unit as a single stream. The data unit is then sent to the peer over the existing network, and upon reception, the stream is demultiplexed with the help of the upper layers back to the original independent data units. As a result, a maximum number of network frames are generated each time transmission is performed, and the use of the bandwidth can be optimized. Further, according to the above, it is possible to adjust the channel so that the bandwidth can be used to the maximum, and it is possible to provide parameters applicable to all session-level connections.
[0117]
In the rare case where one channel is inadequate, the Internet Mobility Protocol can establish multiple channels between peers. This allows prioritization of data and guarantees of service quality (if supported by the underlying network).
[0118]
In addition, Internet mobility protocols are being considered for dynamically selectable and guaranteed levels of service, or for unreliable levels of service. For example, each protocol data unit to be transmitted can be made to wait with a limitation on a validity time period and / or the number of retransmission attempts. The Internet Mobility Protocol expires the data unit when either threshold is reached and excludes it from subsequent transmission attempts.
[0119]
The overhead of the Internet Mobility Protocol as an additional protocol has been minimized by the use of variable length headers. The size of the header is determined by the type of the frame and an optional field. The optional field is added in a particular order to facilitate parsing by the receiver, the presence of which is indicated by a bit in the header flag field. All other control and configuration information required for peer communication can pass through the in-band control channel. All control information to be transmitted is added to the previous frame of any application-level protocol data unit. The receiving side processes the control information and then sends the rest of the payload to the upper layer.
[0120]
Because it is expected to operate in unreliable networks with a relatively high probability of error, the Internet Mobility Protocol employs a number of technologies to ensure data integrity and maximize network performance. Is used. To ensure data integrity, a Fletcher checksum algorithm is used for detecting erroneous frames. This algorithm is employed with high efficiency and high detection capability, and can detect not only bit errors but also bit rearrangement. However, another checksum algorithm may be employed instead of the above algorithm.
[0121]
Although sequence numbers are used to ensure delivery of ordered data, sequence numbers in the Internet Mobility Protocol do not represent each byte of data as in TCP. As an example, the sequence number represents a frame of data up to 65535 bytes (including the Internet Mobility Protocol header). The sequence number is of an appropriate length, such as 32 bits, to prevent wraparound on high bandwidth links within a limited time period.
[0122]
When the above capabilities are combined with the data expiration function, the retransmitted (retryed) frame may contain less data than the previous version generated at the sender. Although it is possible to set the frame ID to detect the latest version of the frame, in the preferred embodiment no data is added, and each deleted element is the entire protocol data unit Therefore, the above method is not always necessary for sequence assurance. As an example, the Internet Mobility Protocol processes a particular frame received only the first time, no matter how many different versions of the frame are transmitted. Each generated frame that carries a new user payload is assigned a unique sequence number.
[0123]
The adoption of sliding window technology improves performance and allows multiple frames to be held (transmitted) before requiring the peer to acknowledge data reception. Acknowledgments and timer-based retransmission schemes are employed to ensure timely data delivery. In addition, a selective acknowledgment mechanism has been adopted to optimize channel utilization, resulting in faster retransmission of lost frames and faster recovery during periods of high or low network connectivity. Is done. In one example, this optional acknowledgment mechanism is represented as an additional bit field included in the header.
[0124]
Congestion avoidance algorithms have also been used to back off the protocol from rapid retransmission of frames. For example, the round trip time can be measured for each frame successfully transmitted between peers without retransmission. This time value is averaged to provide a reference for a retransmission timeout value. Each time a frame is sent, a timeout is set for each frame. If a frame is actually transmitted but no acknowledgment is received for the frame, the frame is retransmitted. At this time, the timeout value increases and becomes a reference for the next retransmission time. Since an upper limit value and a lower limit value are set for the retransmission timeout, the values fall within an appropriate range.
[0125]
In the Internet Mobility Protocol, a transmission path and a reception path are treated separately. This approach is particularly useful in channels that are inherently asymmetric. Based on the hysteresis, the Internet Mobility Protocol automatically adjusts parameters such as frame size (fragmentation threshold), number of pending frames, retransmission time, delay acknowledgment time, and replicated data sent over the network. Decrease the amount of
[0126]
The Internet Mobility Protocol allows nodes to move to different points of connection in various networks, which may change the characteristics of the underlying network (eg, frame size) along the way. As a result, frames that were waiting to be transmitted on a certain network may not fit the new medium to which the mobile device is currently connected. Fragmentation is handled at the level of the Internet mobility protocol, taking into account that fragmentation is not supported in all network infrastructures. Before each frame is transmitted, the Internet Mobility Protocol determines whether the frame exceeds the current fragmentation threshold. Incidentally, this value may be smaller than the current maximum transmission unit from the viewpoint of improving performance (because a smaller frame is more likely to reach the final destination than a larger frame). The trade-off between increasing protocol overhead and increasing the number of retransmissions is examined by the Internet Mobility Protocol, and frame sizes may be reduced to reduce overall retransmissions. If a certain frame fits, the frame is transmitted without being divided. If not, the frame is split to the maximum size allowed for the connection. If a frame is retransmitted, it is re-evaluated and re-fragmented if the maximum transmission unit is reduced (or if the maximum transmission unit is increased, the frame is fragmented May be retransmitted as a single frame that is not transmitted).
[0127]
The protocol itself is designed to be orthogonal, so that either side can establish or break a connection with a peer. However, in some cases, there are some minor operational differences in the protocol engine depending on where they are performed, and certain sleep detections and connection lifetime timeouts can only be performed from one side. In order to enable operations necessary for operation, the Internet Mobility Protocol Engine running on the
[0128]
As an example, software that provides the Internet Mobility Protocol can be compiled and run in a Windows NT, 9x, CE environment without the need for platform-specific modifications. In order to realize this, the Internet Mobility Protocol employs a service of a network abstraction layer (NAL) for transmitting and receiving Internet Mobility Protocol frames. Other standard utility functions such as memory management, queue and list management, event logging, alarm systems, power management, security, etc. are also used. Some runtime parameters are changed depending on whether the engine is provided in the
[0129]
-A specific timeout can be called only from the
・ The direction of the frame is indicated in each frame header for echo detection
-By setting the
An alert is notified only to the
Power management is enabled in the
The interface of the Internet Mobility Protocol has a small number of standard API functions that are C-callable and platform-independent, and is dedicated to a single OS-specific, scheduled work (other than the standard utility functions described above). A configuration that requires a function may be used. Communication with the local client is enabled by using a defined work object (work request). Completion notification for each work element can be effectively accomplished by notifying the requesting entity through an optional completion callback routine identified as part of the work object.
[0130]
The Internet Mobility Protocol Engine itself is queue-based. Work elements from the local client are added to the global work queue according to the FIFO order, which is done by the local client calling a standard Internet Mobility Protocol function such as "ProtocolRequestwork ()". Subsequently, a scheduling function within the Internet Mobility Protocol removes the work and dispatches to the appropriate function. The combination of the standby and scheduling functions makes the difference between OS architectures invisible, so that the protocol engine can be implemented in a thread-based system (eg, Windows NT) or a synchronous system (eg, Microsoft Windows). (Registered trademark) 9x or Windows (registered trademark) CE). Since the priority scheme can be overlaid on the waiting function, quality of service (if supported by lower layers) can be guaranteed.
[0131]
From a network perspective, Internet mobility protocols utilize scatter-gather techniques to reduce data copying and movement. Each transmission is sent to the NAL as a list of fragments and fused by the network layer transport. If the transport protocol itself supports the scatter-gather technique, the fragment list is transferred over the transport and assembled by the media access layer driver or hardware. Further, the above technique can be extended to insert or delete any protocol wrapper at any level of the protocol stack. The reception of the frame is notified by the NAL layer by calling back the Internet mobility protocol at a specific entry point designated at the time of the NAL registration process (NAL registration process).
[0132]
(Example of Internet Mobility Protocol Engine entry point)
The Internet Mobility Protocol in the illustrated embodiment has four common entry points that manage the startup and shutdown behavior of the protocol. Shown below are these procedures.
[0133]
1. Internet Mobility ProtocolCreate ()
2. Internet Mobility ProtocolRun ()
3. Internet Mobility ProtocolHalt ()
4. Internet Mobility ProtocolUnload ()
(Example of Internet Mobility ProtocolCreate ())
The Internet Mobility ProtocolCreate () function is called by the boot subsystem to initialize the Internet Mobility Protocol. During this first phase, all resources necessary to start processing the work must be acquired and initialized. At the end of the phase, the engine should be ready to accept work from other layers of the system. At this time, the Internet Mobility Protocol initializes the global setting table. To this end, the Internet Mobility Protocol uses the service of the
[0134]
Next, the Internet Mobility Protocol registers the suspend and resume notification functions with the APM handler. In one example, these functions can be invoked only from the
[0135]
To limit the maximum amount of runtime memory required and to guarantee the uniqueness of the Internet Mobility Protocol handle, the Internet Mobility Protocol employs a two-tier array scheme for handle generation. are doing. The size of the global connection array table is determined by the maximum number of simultaneous connections set by the system and is allocated at this time. When all global storage has been allocated and initialized, the state of the Global Internet Mobility Protocol will be _STATE_INITIALIZE_.
[0136]
(Example of Internet Mobility ProtocolRun ())
The Internet Mobility ProtocolRun () function is called after all subsystems have been initialized and notifies the Internet Mobility Protocol subsystem that it may begin processing any pending work. This is the normal state of the Internet Mobility Protocol Engine in general operating situations. Before putting the engine into operation, several second pass initialization steps are performed at this point.
[0137]
The Internet Mobility Protocol allows network communications to take place over any of the interfaces. During the initialization step, the storage for the Internet Mobility Protocol-NAL interface is allocated so that the Internet Mobility Protocol starts all listeners of the NAL, traversing the global portal list. Can be. As an example, this operation is as follows, which includes two steps.
[0138]
The Internet Mobility Protocol binds and opens the NAL layer with a portal based on settings provided during initialization;
The Internet Mobility Protocol then registers an Internet Mobility Protocol RCVFROMCB callback to notify the NAL layer that it is ready to begin processing the received frame.
[0139]
Subsequently, a local persistent identifier (PID) is initialized. The state of the Global Internet Mobility Protocol changes to _STATE_RUN_.
[0140]
(Example of Internet Mobility ProtocolHalt ())
The Internet Mobility ProtocolHalt () function is called to alert the engine that the system has shut down. All resources obtained during operation are released before returning from this function. All sessions of the Internet Mobility Protocol terminate abnormally with a reason code set for management. When the engine enters the _STATE_HALTED_ state, thereafter, work from another layer is not accepted, and the other layers are not notified.
[0141]
(Example of Internet Mobility ProtocolUnload ())
The Internet Mobility ProtocolUnload () function is the second phase of the shutdown process. This is the last opportunity for the engine to release the allocated system resources before returning. When the engine returns from this function, the system itself shuts down and no further work is performed.
[0142]
(Example of Internet Mobility Protocol Handle)
In at least some instances, it is not sufficient to simply use the address of the memory (which stores the Internet Mobility Protocol state information) as a token that describes the Internet Mobility Protocol connection. This is mainly due to the possibility that one connection will end and another new connection will be started within a short period of time. It is likely that the memory allocator will redistribute the same address to another connection as the previous one, and this value will indicate both the previous connection and the new connection. If the original peer does not recognize the end of the session (because it has been powered off, suspended, out of range, etc.), it will send the frames of the previous session towards the new session It is possible. This occurs for TCP, and if the peers have the same IP address, a reset is performed to create a new session. To avoid this, the Internet Mobility Protocol employs a manufactured handle. The handle is formed by a two-row index and is one-time only to maintain uniqueness. The table has the following layout.
[0143]
Table 1: Array of pointers to arrays of connection objects
Table 2: Array of connection objects containing real pointers to Internet Mobility Protocol control blocks
This technique minimizes the amount of memory allocated during the initialization period. Table 1 is sized and assigned at startup. As a result, a small amount of memory can be allocated on the
[0144]
Table 1 is populated as needed. When a connection request is made, the Internet Mobility Protocol looks for a valid pointer to Table 2 in Table 1. If no entry point is found, the Internet Mobility Protocol allocates 256 connection objects to the new Table 2 and records a pointer to Table 2 in the appropriate slot of Table 1. Next, the protocol engine initializes Table 2, allocates a connection object from the newly created table, and returns to the manufacturing handle. If another session is requested, the Internet Mobility Protocol will again search Table 1 to find a valid pointer to Table 2 and assign the next connection object for the session. This process continues until one of the following two states is reached.
[0145]
When all the connection objects are lost from the table 2, the table 2 is newly allocated and initialized, and the pointer indicating the table 2 is set to the next available slot of the table 1.
[0146]
If all connection objects are released to a particular instance of table 2 and if all elements have not been used for a particular period, the storage in said instance of table 2 is released back to the memory pool and table 1 The associated pointer is zeroed to indicate that the entry is available when the next connection request is initiated (in other instances of Table 2, the available connection objects are If not).
[0147]
Two global counters are maintained to allow the total number of allocated connections to be limited. One global counter counts the number of currently active connections, and the other keeps track of the number of unassigned connection objects. Furthermore, the second counter also manages the total number of connection objects that can be created up to an arbitrarily set limit. When a new table 2 is allocated, the counter is adjusted downward to keep track of the number of objects represented by the new table. On the other side, when the Internet Mobility Protocol releases an instance of Table 2 to the memory pool, the counter is revised upward to match the number of connection objects released.
[0148]
(Example of workflow)
With the Internet Mobility ProtocolRequestWork () function, work is requested from the local client. When the work is validated and added to the global work queue, the Internet Mobility ProtocolQueueEligible () function is called. In a threaded environment, an Internet Mobility Protocol worker thread is signaled (marked conforming) and control immediately returns to the calling entity. In a synchronous environment, the global work queue is immediately executed and any requested work is processed. In either case, the Internet Mobility ProtocolProcessWork () function will be executed. This is the main dispatch function for work processing.
[0149]
In the illustrated embodiment, work from the global queue may only be dispatched by one thread at a time, and a global semaphore may be used to prevent reentry. For private Internet Mobility Protocol work, work can be sent directly to the global work queue without using the Internet Mobility ProtocolRequestWork () function.
[0150]
A special case is assumed for the SEND type work object. To ensure that the semantics of unreliable datagrams are maintained, each SEND-type work object can be queued with an expiration date or retry count. The life of the work is calculated based on the expiration date. If such a predetermined timeout occurs, the work object is removed from the connection specific queue and completes with an error condition. If the SEND object has already been merged into the data path, the protocol allows removal of any SEND object with a retry count set. If the retry count is exceeded, the object is removed from the list of elements that make up the particular frame and returned to the requester, indicating an appropriate error condition.
[0151]
(Example of connection startup)
Internet mobility protocols have a very efficient mechanism for establishing connections between peers. Confirmation of the connection is made by exchanging at least three frames between the peers. The initiator sends an IMP SYNC frame to its peer to warn that connection establishment is required. The acceptor warns the peer that the connection request has been rejected by sending an IMP ESTABLISH frame to confirm connection acceptance or by sending an IMP ABORT frame. The reason and status code are sent in an IMP ABORT frame to help the user understand the reason for the connection refusal. If the connection is granted, an acknowledgment frame (which may contain the protocol data unit and control data) is sent and forwarded to the acceptor to acknowledge receipt of the establishment frame.
[0152]
To minimize network traffic, the protocol may allow user and control data to be included in the initial handshake mechanism at connection startup. This configuration avoids performance degradation due to unsecured environments, double security authentication on the same data path, and encryption processing on the same data path. It is used in environments where security is handled at a lower level, such as where Internet mobility protocols are being coordinated.
[0153]
(Example of data transfer)
The Internet Mobility Protocol detects that a frame has been delivered to the network by notification from the NAL. The Internet Mobility Protocol does not retransmit the same frame until the original request is completed, since the metrics determine whether the network link is constantly being flow controlled. However, some network drivers erroneously suggest transmission of a frame before sending the frame to the network. With the use of semaphores, the Internet Mobility Protocol layer will detect this and will not send another datagram until the NAL replies to the original request.
[0154]
When a frame is received by the Internet Mobility Protocol, it is quickly inspected and added to the appropriate connection queue. If the frame does not have enough information for the Internet Mobility Protocol to identify its final destination, the frame is added to the Internet Mobility Protocol socket queue that received it and the The socket queue is added to the global work queue for subsequent processing. This initial demultiplexing allows the received work to be quickly spread with limited processing overhead.
[0155]
(Example of acquiescing)
To minimize the network bandwidth during retransmissions and the power required by the
[0156]
The
The connection lifetime timeout expires,
The sleep timeout expires, or
Connection is canceled by the system administrator
If the
[0157]
(Example of connection and transmission request)
10A-10C form a flowchart illustrating the connection and transmission request logic generated by the
[0158]
In response to a connection or other request, the
[0159]
To dispatch a connection or transmission request from the Internet Mobility Protocol global request queue,
[0160]
To move to state establishment,
[0161]
Once the status has been established, the
[0162]
(Example of cancellation)
FIG. 11 is a flowchart illustrating the steps performed by the Internet
[0163]
If a "post mortem" response frame is received from the peer ("yes" at decision block 632),
[0164]
(Example of retransmission)
FIG. 12 shows an example of the “retransmission” event logic executed by the Internet
[0165]
If all retransmission periods have not expired ("No" at decision block 655),
[0166]
(Example of expired PDU of Internet Mobility Protocol)
In
[0167]
The expiration time out associated with the
[0168]
In the example of FIG. 12A, at least three
[0169]
As described above, the
[0170]
Also in the example of FIG. 12B, at least three
[0171]
(Example of reception)
13A-13D form a flowchart illustrating the steps performed by the Internet
[0172]
If the frame is associated with a connection ("Yes" in decision block 686),
[0173]
If the frame may be a "Mortis" frame ("Yes" in decision block 698),
[0174]
(Example of passive connection)
14A-14B form a flowchart illustrating the steps performed by Internet
[0175]
If there is no other connection ("No" in decision block 720),
[0176]
(Example of abnormal termination)
15A and 15B form a flowchart illustrating the steps performed by the Internet
[0177]
(Example of roaming control)
Referring again to FIG. 1, the
[0178]
Generally, a network device newly started in the above subnet is automatically set by using a dynamic host configuration protocol (DHCP). For example, a DHCP server on a subnet typically "leases" its clients (in addition to providing others) with a valid network address. A DHCP client may not have a permanently assigned, "hard-coded" network address. Instead, at boot time, the DHCP client requests a network address from the DHCP server. The DHCP server pools available network addresses for assignment. When a DHCP client requests a network address, the DHCP server assigns or leases the pooled address to the client. The assigned network address is owned by the client for a specific period (lease period). At the end of the lease period, the network address is returned to the pool and becomes available for assignment to other clients. In addition to the automatic assignment of network addresses, DHCP provides setting information such as a netmask to clients running DHCP client software. More information about the standard DHCP protocol can be found in RFC2131.
[0179]
Thus, when the
[0180]
In one embodiment, along with other standard methods used to determine whether the
[0181]
In this embodiment, a DHCP listener is provided to monitor DHCP broadcast messages so that the
[0182]
A linked list of server data structures,
An integer transaction ID number (xid),
A counter ("ping"), and
・ Timeout value
The
[0183]
A pointer to the next server,
Server ID (network address of DHCP server),
The address of the BOOTP relay agent recently bound to the DHCP server (giaddr),
A "ping" value (socket-> ping), and
·flag
These data structures are continuously updated based on the DHCP broadcast traffic on the
[0184]
-RoomCreate () (initialize variables)
・ RoamDeinitialize () (delete all listeners)
RoamSertIndications () (calls the provided callback routine for registering roaming indications when the mobile terminal system roams or changes interface)
• roomStopIndications () (remove appropriate callbacks from list to stop suggesting registered roaming)
Interface change (callback notification from OS indicating that the interface has changed the network address)
-Listener signal (callback for each interface from the listener, indicating any of the following states: roaming, out of service, return to service)
In addition, a refresh process may be used to update the listener after an interface change.
[0185]
In the preferred embodiment, all mobile
[0186]
Upon receiving a Discover request having a predetermined client hardware address and client identifier, the preferred embodiment recognizes the request as having been sent from the
[0187]
If the listener does not receive a response from any server, it cannot determine whether roaming is occurring because there is no reference point. This situation is relieved by giving an error warning after the timeout and forcing the caller to retry the operation. In the preferred embodiment, if there is a response from a known server with a new BOOTP relay agent ID (or the provided network address masked with the provided subnet mask), the
[0188]
FIG. 17 is a flowchart illustrating steps of a listener process according to the preferred embodiment. According to the figure, the DHCP listener process is performed by allocating appropriate memory to the handle, releasing the NAL socket to the DHCP client and server UDP ports, and setting a receive callback for both. Next, a timer is set (block 802) and the process enters a "wait" state to wait for a roaming related event (block 804). Events are triggered by the following three types of external inputs.
[0189]
・ Receive DHCP server packet
・ Receive a DHCP client packet from another mobile terminal system ・ Timer expires
If a DHCP server packet is received, the packet is examined to determine whether the client identifier matches a predetermined client ID (decision block 806). If they do not match, the packet is discarded. However, if the packet does include the predetermined client ID, it is determined whether the packet is a DHCP Offer packet (decision block 808). The Offer packet is rejected unless it contains the transaction ID corresponding to the recently sent DHCP Discover sequence.
[0190]
If the packet transaction IDs correspond (block 810), it is determined whether the server that sent the DHCP Offer packet is known (ie, whether the server ID is included in the listener data structure of FIG. 16). A determination is made (block 812). If the server ID is not in the list ("No" in decision block 812), the server ID is added to the list and marked "New" (or "First" if it is the first server in the list). Marked) (block 822). If the server is already on the list ("Yes" at decision block 812), it is further determined whether the packet BOOTP relay address ("GIADDR") corresponds to the server address ("GIADDR") ( Decision block 814). If not, it is determined that a "hard roam" has been performed since the Offer packet is from another subnet (block 816). The calling application is notified that roaming has taken place. If it is determined at
[0191]
When an event is received in a client packet, the listener process determines whether the packet has a predetermined client ID, is a DHCP Discover packet, and has a packet BOOTP relay address (GIADDR) of 0. (
[0192]
Upon expiration of the timer, the process calls "ping ping" (block 838). “Ping” in the preferred embodiment is a DHCP Discover packet with a random new xid. This step of
[0193]
• Did the mobile terminal system roam from one subnet to another?
・ Is the mobile terminal system out of range?
・ Is there no DHCP server?
These states are determined by comparing the previous "ping" response and the current "ping" response of the mobile terminal system (decision blocks 846, 850). For example, if the number of current pings minus the previous ping response of the old server is greater than the pings of the servers in the subnet and at least one server is marked as "new," subnet roaming to another server It means that there was. This logic indicates (or does not indicate any) a subnet roaming state, an out-of-service state, or a server-less state for the calling process.
[0194]
FIG. 18 is a flowchart illustrating steps performed by a roaming control center of the
[0195]
When a signal is sent from the listener process of FIG. 17 (block 862), it is determined whether the signal indicates "roaming", "out of service", or "return to service" (decision blocks 864, 870). 874). A roaming signal ("yes" at decision block 864) closes the
[0196]
(Example of roaming listener assisted by interface)
In addition, interface-based listeners allow roaming across network connection points of the same network and another network medium. While the interface-based listener operates without the need for beacon technology described above, the system may fall back to a beacon state if the underlying interface (s) do not support the appropriate signals.
[0197]
In this embodiment, the interface-based listener integrates information from the network interface adapter (eg, via a low-level interface roaming driver) with information from the network stack to allow the mobile node to create a new It is determined whether or not it has moved to a network connection point. 19A and 19B illustrate a listener algorithm used to efficiently determine the migration path of a mobile node. The process uses a single network interface connected to a single network medium, but alone or in conjunction with other roaming algorithms (e.g., self-service using redundant paths). It can also traverse various network media and interfaces (to build a recovery infrastructure).
[0198]
Referring to FIG. 19A, at system initialization or when the network adapter driver loads (FIG. 19A, block 2000), the low-level interface roaming driver performs registration with the roaming control center module of FIG. (Block 2010). Such registration (implemented through the crRegisterCardHandler () function in the illustrated embodiment) provides the following entry points:
[0199]
・ Open
・ Closed
・ Acquisition of status
Boolean operation is true if the driver can notify the registered entity of a change in state, and false if the roaming control center module must use timer-based (or the like) polling for state confirmation. To be
The embodiment's crRegisterCardHandler () function provides an interface description string or token that can be used to pre-associate the roaming control center module with the correct roaming driver. Also, a default roaming driver may be installed on the interface that uses the OS / O generic mechanism for changing signaling / querying media connectivity and network attachment points.
[0200]
In this embodiment, when the state of the interface is enabled (ie, when access to the network is enabled) (block 2020), the roaming control center performs an interface assisted roaming (IAR) based on the following steps. (However, the following steps may be replaced or omitted depending on the OS design and / or the hosting device used for a particular application).
[0201]
1. If a generic handler is installed, a call is made to the generic crOpenInstance () handler. The generic handler queries the low-level adapter driver to determine whether the driver comprehensively supports signals regarding the state of media connectivity and changes in network attachment points (block 2030). If the interface driver cannot comprehensively support the function ("No" at decision block 2030), an error condition is returned to the call executor, suggesting that another mechanism be used to obtain signal information. You.
[0202]
2. If the generic handler returns an error ("No" at decision block 2030), a search for active interfaces is performed on the currently registered roaming driver (block 2040). If the interface matches one of the tokens registered during the crRegisterCardHandler () phase (block 2050), the roaming control center calls a specific crOpenInstance () on the instance of the adapter. This function attempts to open the low-level driver, poll the state (media connectivity, network connection point ID) again, and set a periodic polling timer (if possible). If the low-level driver does not support the request for any reason, an error is returned to the roaming control center, suggesting that another mechanism be used to obtain signal information.
[0203]
3. If any of the preceding steps fail to achieve the required function, an error is returned to the roaming control center and the beaconing listener, mobile IP of FIGS. 17 and 17A, without using the IAR function. Alternatively, it is suggested to fall back to another roaming algorithm, such as a currently connected network that is handling roaming (if no at
[0204]
First, the listener assisted by the interface records the current state of media connectivity and the identity of the network connection point in a local data store (block 2060). Assuming that the interface assisted subsystem has successfully provided roaming feedback, the subsystem waits for a status event (block 2100). The event has, for example, the following:
[0205]
・ Callback from low-level roaming driver,
A polled interval (
• Implications from network-level activities (ie transmission / reception issues)
If the state of the interface indicates that the media connectivity has changed or the network connection point has changed ("Yes" in
[0206]
1. If the state indicates that the connection has changed from connecting to the underlying network medium to disconnecting ("yes" at block 2120) and there are no other paths to the peer, the listener concludes that the mobile terminal system has lost connection. In turn, the roaming control center suggests to the client the ROAM_SIGNAL_OUT_OF_CONTACT state (block 2140).
[0207]
2. If the above condition indicates that the interface has been reconnected to the medium and the network attachment point has not changed ("no" at
[0208]
3. If the status indicates that the interface is attached to the media but the network connection point has changed ("yes" at block 2150), the roaming control center has entered the roaming state with the client. Suggest that. To more efficiently support handoffs between network attachment points, the roaming control center of the present example uses a learning algorithm in parallel with the local data store. The data store is usually dynamically populated (learned), but static information (already learned information) may be prepared in the data store to improve performance. The data store itself maintains a list of network connection point identifiers along with information such as addresses and network masks for accessing networks and media. This "network topology map" assists the roaming control center in determining the correct signal generation for the client.
[0209]
The determination of the correct signal is made in this embodiment as follows.
[0210]
a) Searching the data store's network topology map to determine if the interface has visited a particular network attachment point (block 2190). If a match is found (“yes” at block 2200), it is further checked whether the network connection point is on the same network segment that the interface was previously attached to. If the network segments are the same, the roaming control center generates ROAM_SIGNAL_ROAM_SAME_SUBNET. This allows the roaming control center client to perform a handoff as much as possible to immediately re-establish communication at the transport level, as some data may have been lost during the handoff. It is suggested that measures must be taken.
[0211]
b) If a correspondence was found during the search, but the new network attachment point is not on the same network segment as before, the listener concludes that the mobile terminal system has roamed to another subnetwork. In this case, the roaming control center
Obtain an address available on the new network segment (block 2220). This action may involve registering the current address as valid for the new segment, (re-) acquiring the address from the local server, or a heuristic method of determining whether a previously assigned address is still valid. May be used. In the last case, the roaming control center ensures that the interface is roaming between given network attachment points and cannot be immediately discarded or deregistered for performance reasons. It is determined whether there is. In this example, obtaining an address on the network (eg, via DHCP) is different from registering an address on the local network (through a mobile IP foreign agent). The roaming entity either (re) acquires the address (eg, establishes / updates a lease from a DHCP server) or registers the current address with a foreign agent (Mobile IP).
[0212]
Generate a ROAM_SIGNAL_Roaming signal for the roaming control center client, indicating roaming to another subnet (block 2230).
[0213]
c) If the search does not find a match ("No" at block 2200), then create a new record populated with the network attachment point identifier, media access address, network mask, and other auxiliary information ( Block 2210). Next, the roaming control center executes
[0214]
The roaming technique assisted by the above interface allows access to the underlying interface information and allows automatic and efficient selection of another valid network path (user and / or Additional policy parameters (defined by the system) can be adopted. If more than one network is available at the same time, the subsystem can choose the least burdensome path (the choice between a wide area network and a local area network). This can be determined by various metrics such as bandwidth, cost (per byte), and / or quality of service. This "least burden routing" technique can provide benefits in terms of network connection quality, efficiency, reduced frame loss, and the like. For example, due to other available heuristics (medium connectivity, signal strength, retransmission rate, etc.), a "make before break" handoff structure can be provided, thus continuing from / to the roaming node. Packet loss can be minimized. See the description of policy management below.
[0215]
FIG. 20 illustrates the data structure of a node in the interface assisted roaming topology. Although this data structure in FIG. 20 is implemented as a linked list, it may be expressed as an array in which the preceding and following fields are omitted. In a wireless network infrastructure, "NPOA" may be, for example, the MAC address of an access point or a base station to which a mobile node is associated. In other networks, "NPOA" may be a unique identifier for an intervening network interconnect (gateway, IWF, etc.). Static information may be given to the data structure in advance, or information may be dynamically learned. Also, each node may be combined with other information (eg, MTU size, waiting time, cost, availability, etc.).
[0216]
(Other embodiments that deal with specific race conditions)
Further experiments have revealed that some network adapters may falsely signal that they are (re) connected to the media before being fully registered to the network segment. . For example, during roaming, the storage area holding the network identifier has not yet been updated, and it is possible that the system will mistakenly think that these network adapters have roamed back to the same subnet. Eventually, when the device has finished registering, the storage area is updated with the new network identifier and another roaming signal is generated. If both signals are gated together and signaled only once when the interface has finished registering with the network, we proceed in this scenario. However, at the time of polling, it is difficult to determine when the network ID becomes valid if a signal indicating "connected to the network" was previously generated.
[0219]
Basically, roaming nodes can communicate with the network at the medium access level, so they are effectively connected to the medium, but since the registration process has not been completed, virtually any application data can be sent over the link. Can not yet. Therefore, it is desirable to compensate for this condition. One way to make such compensation is to determine the peer connection by sending a link confirmation frame, commonly known as an echo request / response packet. These echoes and ping frames are generated by one peer (most likely a roaming node) to determine if a bidirectional peer-to-peer connection is achievable. If the requesting peer receives a response frame for the request, duplex communication is realized and terminated. At this point, the NPOA information is considered valid until the next disconnected state. Also, other information, such as the receipt of a frame from a peer on the interface, allows the roaming node to complete the registration process and assume that two-way communication is achievable.
[0218]
Another race condition between the network interface and the underlying protocol stack situation can cause problems. The device can move to a new network segment and ensure accurate signaling from the following interfaces, but the transport stack itself makes the necessary adjustments to the routing tables of the flowing application data: May not be done. To compensate for this condition, an additional signal, ROAM_SIGNAL_ROUTE_CHANGE, is generated for each change in the underlying transport's routing table. When this signal is signaled, the roaming subsystem client takes whatever action is necessary to determine if a connection with the peer system is achievable. This requires roaming clients to enumerate through the underlying transport's routing table in order to determine if the routing modification has affected the communication path to the peer. Also, other more intrusive algorithms, such as those described above, may be performed to confirm that a bidirectional communication path exists between peers.
[0219]
(Example of roaming through a disconnected network)
Another aspect of the non-limiting preferred embodiment of the present invention is an algorithm and configuration for accessing a MMS (Mobility Management Server) in a so-called "disjoint networking" mode. With the new algorithm, an alternative network address can be dynamically / used to establish / persistently communicate with the MMS even in a disconnected network topology where one network does not know the network address in another network. You will be able to find them statically.
[0220]
In general, the algorithm allows a list of alternate addresses available to the MMS to send to the MES (Mobile Terminal System) during communication. In this way, the MMS sends the MES one or more MMS network addresses or other MMS identities corresponding to other networks by communication over a single network. As an example, the list can be sent at the time of circuit construction. The list can be changed in the middle. In this case, the list can be updated at any time while the connection is being established.
[0221]
As the MES moves to another network, the MES uses the MMS's "alias" address / identity list to contact the MMS from the point of attachment of the new network. This allows the MES to re-establish contact with the MMS through a new network connection, even if the old and new networks do not share addresses or other information.
[0222]
FIG. 21 shows a simplified flowchart of this new technique. It is assumed that
[0223]
This new algorithm has at least some uses in addition to more efficiently obtaining alternative network addresses or other identifiers for communicating with the
[0224]
Normally, for nodes traveling from network segment to network segment, the information / routes provided in each network segment (showing how to return to the "main public address or initial address" used to connect to MMS 102) That is, a default route, etc.) needs to be routed.
As soon as the connection is established, its address is used for the life of the connection. When a frame is sent from the
[0225]
The alternative address list shown in FIG. 21 has the effect of sending or distributing some of the routing information to the
[0226]
For example, using
[0227]
An example is shown in FIG. In FIG. 22, the
[0228]
For some reason MES is 10.1. x. Suppose we need to cross or move to the x (Ia) network. 10.1. x. x (Ia) network is 192.168. x. Because the x (Ib) network is ignorant (ie, there is no route to the (Ib) network), when the
[0229]
Using the algorithm shown in FIG. 21, the
[0230]
Alternatively, the technique of FIG. 21 is used for a distributed network interface. In today's networks, what are known as Network Address Translators (NATs) have been developed. Using this conventional technique, many network devices can access information on the Internet by using only one public network address. This technology enables the above functionality by sending all information and queries directed to the Internet via a single or few devices. The device records the request at the network layer and then reassociates the packet's address and port information with the device's address / port tuple and sends it to its destination. Upon receiving a frame from the Internet, or other such network, the device reverse-looks, replaces its address / port tuple information with that of the initiating device, and sends the frame back. These associations are also statically defined in the NAT.
[0231]
Suppose that someone uses the
[0232]
The outline is shown in FIG. Suppose a node passes from interface "d" to interface "g". Access is not possible simply by providing a local interface to the
[0233]
(Examples of policy management and location-based services)
Another non-limiting embodiment of the present invention provides a unique approach to providing additional security, cost savings and services based on many metrics. Since the above MMS is deeply involved in each application session that the MES establishes, both sides (ie, MMS and / or MES) apply policy-based rules between the MES and its final peer. Communication can be adapted and controlled. In addition, the MMS and / or MES may adjust or modify application requirements based on device locale, or proximity, and network connectivity. For example, the MMS and / or MES may include a learned and statically defined and applied rules engine, or other rules based on each application session to establish, or policy on attempted requests. The MMS may further allocate some, none, or some, and / or processing of such rules to the MES to provide metering or security against eavesdropping on mobile devices. I will provide a. Unlike certain other policy management techniques available in a distributed topology, MMS is central to managing rules and policy decisions and distributing them to remote devices at any time during communication.
[0234]
The rules themselves can be configured based on users, user groups, devices, device groups, process application identities, and / or network connection points. Once defined (learned), the rules are combined to manage and control a variety of different events, activities, and / or services, including, for example, the following:
[0235]
Deny, allow, or adjust intrusion access to remote devices
Deny, allow, or adjust access to specific network resources based on identity
Denying, granting, or adjusting access to available or permitted bandwidth
Denying, granting, or adjusting access to other network resources
・ Modification, adjustment, or change of content or information
Such a determination may be made based on various different factors, including, for example, the following:
[0236]
The proximity, location, altitude, and / or other characteristics of the mobile device
・ Date
・ Application or process identity, address, etc.
Application operation (eg, bandwidth conditions)
・ Current network status
.Other static or dynamic elements
Further, by utilizing a distributed architecture, the MMS can apply or share the same set of decisions. The policy management process and / or decision making performed by the MMS may be performed, for example, when the mobile device has limited processing power to run the engine, bandwidth limitations apply, or for security purposes. Desirable.
[0237]
FIG. 24 shows an example of a table showing some of the metrics (rules) that may be used for controlling the sample MES. This table may occupy either static or dynamic content and may be updated before, during, or after communication, as the case may be. For example, a user may use a rule editor (eg, a wizard) or other mechanism to define table entries. In other implementations, the metrics are automatically defined by a learning-based system or dynamically changed based on a change in state. Each rule is also assigned a priority, which is implied or explicitly specified at the table location. This priority allows the engine to accurately determine the expected operation. Additional user interface features allow system administrators and device users to query the rules engine to try a given set of rules.
[0238]
FIG. 24 shows a table example showing a number of metrics examples including the following metrics, which are the basis of the policy management decision.
[0239]
-MES communication function (transmission only, reception only, transmission and reception)
Whether the MES request is proxied
・ MES source port
・ MES source address
・ MES destination port
-MES destination address
・ MES protocol
・ Available bandwidth
• process name, identity or other characteristics
Network name, identity or other characteristics
Location (eg, GPS coordinates or other location information)
・ Network connection points
The identity, identity or other characteristics of the user
・ Other metrics
The above example table is not a complete list, and the present invention is not limited to the range of metric items in the above example table. The item can be specific, as in this example, or a generic mechanism (eg, wildcard) to indicate the desired behavior of the mobile node with respect to network access and entitlement.
[0240]
The table example of FIG. 24 further includes a “denial request” item indicating the result of the policy management decision based on the metrics. As an example, the specific item example shown in the table of FIG. 24 shows that if the available bandwidth is reduced to 100,000 bytes or less per second, the connection with
[0241]
In one example, before each RPC request or frame is processed, a rules engine is required to determine the status of the operation. Based on the outcome of this process, the request is granted, denied, or delayed. FIG. 25 shows a flowchart example of a process performed by the MMS and / or the MES to make a policy management decision.
[0242]
By combining the roaming techniques outlined above with other available location or navigation information, the MMS detects when the mobile terminal system has moved from one connection point to another. By combining this information in conjunction with the capabilities of the mobile terminal system to detect changes in the environment of the network topology, depending on the locale, the present invention can provide additional levels of location-based interception and service. it can.
[0243]
In order to fully realize the potential of this information, we outline the improvements in both the Internet Mobility Protocol and the PRC engine. New RPC protocol and configuration improvements have been added to enable this feature. These are listed below.
[0244]
(Example of Location Change RPC)
When the mobile terminal system determines that it has moved to a new point of attachment using another method, such as detecting a change from an interface assisted roaming or global positioning system, the mobile terminal system performs a formatted "location change". Send a "Location Change RPC Request" message to the peer, in this case the mobility management server. The "change location RPC" formats one or more connection point identities in the form of type, length, value. The type indicates the type of the identification information, and the corresponding type includes, but is not limited to, a 48-bit IEEE MAC address of ASCII, an IPV4 address, an IPV6 address, a longitude, a latitude, an altitude, and a connection mechanism name. The length indicates the byte length of the identification data, which contains the actual connection point identifier. Upon receiving the “location change RPC request”, the mobility management server generates a “location change alert” including the connection point identifier and other relevant information such as the identifier of the mobility terminal system, the user name, and the PID. I do. This alert is formatted with the same type, length and data format used in the "change location RPC request". The alert subsystem then sends this information along with the location change alert to all applications registered for the alert. Applications registered for alerts may include monitoring current activity, long-term activity logs, policy management engines, monitoring applications such as third party applications, and network management tools. A single such third party application combines this location information with a web-based map to provide detailed information about the location of the mobile terminal system or MMS. In addition to such applications, other actions can be associated with location change alerts. This includes sending an e-mail, printing a message, launching a program, and / or changing policies.
[0245]
The location change RPC includes in its header a field indicating whether it was triggered by a location change, a distance change, or a speed change.
[0246]
In one example, the MES may not know that it has moved. Depending on the medium and network adapter to which the MES connects, the MMS may be the only entity that signals that the MES has reached a new point of attachment. Consider the case of a mobile router. The address after the router remains the same, only the router address changes. In this case, the MMS recognizes that the address of the MES is newly managed. Therefore, in order to complete the detection of the operation, it is necessary to detect the operation of the combination of both MES and MMS for detecting the action. In the present embodiment, when the source address is changed and a new IMP message is received, the MMS detects the behavior of the client at the IMP layer. When this is done, the MMS generates a location change alert locally. The MMS also sends a message to the MES that the connection point has changed.
[0247]
(Example of topology RPC)
The “Topology RPC Request” is sent from the mobility management server to the mobile terminal system. Upon receipt of this RPC, the mobile terminal system reads the topology information stored in its local data storage device and creates a Topology RPC Response. The topology RPC response is composed of data of the type of connection before and after, a total length field followed by length information, a connection point identifier followed by type and length information, and data indicating values of subnet and network information. Formatted. This information may be used on the server to create a complete topological map of the mobile network provided by the server.
[0248]
(Example of location information UI)
The user interface on the server provides a method for associating and displaying location information. This location information is available to each active mobile terminal system, and the long-term operation log keeps a history of location changes for all active mobile terminal systems and previously active mobile terminal systems. The user interface allows the system administrator to configure the connection point information into a human readable format. For example, given connection point information in the form of a 48-bit IEEE MAC address, this MAC address is displayed along with information provided via a user interface on the server. When the connection point indicates the access point of the “HallMark Cards” shop, the setting is made so as to present the following information “Hallmark, address, city, state, zip code”. Displaying this information to the user provides "hole mark, address, city, state, postal code" information.
[0249]
(Example of location RPC timer)
A configurable timer is provided in the mobile terminal system to limit the rate at which the location change RPC is transmitted from the mobile terminal system to the mobility management server. If the timer interval is greater than the rate at which the connection point change occurs, the mobile terminal system waits until the timer interval expires before generating another location change RPC.
[0250]
(Example of distance change notification)
Distance metrics are provided to trigger the generation of a location change RPC. This setting configures the system to send updates as the user moves three-dimensionally from the previous point in n feet, n kilometers, or any other suitable unit of measure. This setting is disabled by default. By enabling this setting, a change notification is issued when the distance exceeds the set distance interval.
[0251]
(Example of speed threshold notification)
Speed change metrics are provided to trigger the generation of a location change RPC. This parameter consists of distance per second, such as miles per hour. This parameter specifies the upper and lower limits, as well as the time interval over which the reached speed needs to be sustained (ie, 0 MPH for 10 minutes, or 70 MPH for 1 minute). When this speed is reached, a location change notification is generated.
[0252]
[Application example]
The present invention has applications in various real world situations. An example is shown below.
[0253]
(Portable computer connected intermittently)
Many companies have employees who work from home or work from home. Such employees often work using laptop computers. During work, employees typically connect their laptop computers to a local area network, such as Ethernet, using a docking port or other connector. A LAN connection allows access to network services (eg, printers, network drives) and network applications (eg, database access, electronic data services).
[0254]
An employee working on a project needs to return home in the evening and wants to continue working from home. The employee can "suspend" the operating system and applications running on the laptop computer, clean up the laptop computer, and take the laptop computer home.
[0255]
Upon returning home, the employee "resumes" the operating system and applications running on the laptop computer and reconnects to the office LAN via a dial-up connection and / or via the Internet. The mobility management server (which continued to proxy the laptop computer and its applications to the network while the laptop computer was temporarily interrupted) re-authenticates the laptop computer and resumes communication with the laptop computer.
[0256]
From the perspective of an employee working from home, network drive mapping, printing services, e-mail sessions, database queries, and other network services and applications are all finished with the company. Further, since the mobility management server continued to proxy the laptop computer session, none of the network applications terminated the laptop computer session on the way home from the employee's office. In this manner, the present invention effectively enables a session to be sustained through the same or multiple high-performance and useful network media in the above situation and other situations.
[0257]
(Application to mobile inventory management and warehouse)
Assume a large warehouse or retail chain. In this premises, an employee who performs inventory management manages inventory of goods using a personal laptop computer and a vehicle (that is, a truck or a forklift) equipped with a handheld data collection unit, a terminal device, and the like.
[0258]
Warehouse and retail employees are often inexperienced computer users who do not know the network subnet and need supervision. According to the present invention, a warehouse user can construct a system that can be used immediately without feeling the complexity of the mobile network. Warehouse users can move in and out of range of access points, suspend and resume their mobile
[0259]
(Application to mobile medicine)
A large hospital that performs network communication between several buildings using wireless LAN technology is assumed. Each building is on its own subnet. According to the present invention, it becomes possible for a nurse or a doctor to move from a hospital room to a patient room with a handheld personal computer or terminal and read and write patient information from a hospital database. Immediate access to the latest articles on drug treatments and medical procedures is provided through local databases and the World Wide Web. The present invention allows for continuous connection to the
[0260]
(Truck transportation and freight transportation)
The shipping company uses the present invention to understand the status of the cargo. While in the warehouse, the
Mobile companies
The employees of the company are 802.11. The system according to the present invention is used to access e-mail, web content, and message services while on a corporate premises with such infrastructure. The cost of maintaining pager services and other mobile device services is reduced as they are no longer needed. In contrast to the costly “pay-per-use” model offered by many of the existing mobile device services, mobile infrastructure can be purchased with a single funding.
[0261]
(IP multiplication)
If an organization has a LAN that needs to connect to the Internet, the LAN administrator has two options. The first option is to obtain a global address to be assigned to all computers on the LAN, and the second option is to obtain some global addresses and use them as address multipliers. The use of the
[0262]
Using the
[0263]
Although the present invention has been described above with examples that are presently the most practical and preferred embodiments, the present invention is not limited to the disclosed embodiments, and can be variously modified and equivalently configured within the scope of the appended claims. I do.
[Brief description of the drawings]
FIG.
1 is an overall view of a mobile computing network of the present invention.
FIG. 2
2 illustrates a software architecture of a mobile terminal system and a mobility management server.
FIG. 2A
Fig. 4 illustrates steps for performing information transmission between a mobile terminal system and a mobility management server.
FIG. 3
1 illustrates a mobile interceptor architecture.
FIG. 3A
5 is a flowchart illustrating steps performed by a mobile interceptor.
FIG. 3B
5 is a flowchart illustrating steps performed by an RPC engine that handles an RPC work request.
FIG. 4
5 is a flowchart illustrating steps for processing an RPC work request.
FIG. 5
5 is a flowchart illustrating steps for processing an RPC work request.
FIG. 5A
5 is a flowchart illustrating steps for processing an RPC work request.
FIG. 5B
5 is a flowchart illustrating steps for processing an RPC work request.
FIG. 5C
5 is a flowchart illustrating steps for processing an RPC work request.
FIG. 6
7 illustrates a received work request.
FIG. 7
It shows how received work requests are dispatched to different priority queues.
FIG. 8
The processing of contents in the queues having different priorities is shown.
FIG. 9
The processing of contents in the queues having different priorities is shown.
FIG. 10A
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 10B
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 10C
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 11
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG.
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 12A
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 12B
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 12C
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 13A
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 13B
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 13C
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 14A
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 14B
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 15A
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG. 15B
2 illustrates steps performed to provide an Internet Mobility Protocol.
FIG.
4 illustrates a data structure of a listener.
FIG.
FIG. 2 illustrates steps for providing mobile interconnect roaming. FIG.
FIG. 17A
FIG. 2 illustrates steps for providing mobile interconnect roaming. FIG.
FIG.
FIG. 2 illustrates steps for providing mobile interconnect roaming. FIG.
FIG. 19A
FIG. 4 forms one flowchart illustrating a roaming process assisted by the interface.
FIG. 19B
FIG. 4 forms one flowchart illustrating a roaming process assisted by the interface.
FIG.
FIG. 5 illustrates a topology node data structure for roaming assisted by an interface.
FIG. 21
1 illustrates a technique for distributing a network address of a mobility management system to a mobile terminal system in a disconnected network topology.
FIG.
FIG. 22 shows an example in which the technique of FIG. 21 is used to realize secure communication.
FIG. 23
23 illustrates an example in which the technique of FIG. 21 is used for network address translation in a distributed network interface scenario.
FIG. 24
9 illustrates a policy management table.
FIG. 25
9 is a flowchart illustrating steps of a policy management process.
Claims (125)
（ａ）ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
（ｂ）前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
（ｃ）前記ステップ（ｂ）を受けて信号を生成するステップとを含むことを特徴とする方法。A method for determining whether a mobile node has moved to a new network attachment point,
(A) receiving identification information of a network connection point from a network interface;
(B) using the identity of the network attachment point to determine whether the mobile node has moved to a new network attachment point;
(C) generating a signal in response to step (b).
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ（ｃ）を行うステップをさらに含むことを特徴とする方法。26. The method of claim 25, wherein
Maintaining the network topology map, and using the network topology map to perform step (c).
前記ステップ（ｃ）はローミング信号を生成するステップを含むことを特徴とする方法。26. The method of claim 25, wherein
The method of claim 1, wherein step (c) comprises generating a roaming signal.
前記ステップ（ｂ）はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。26. The method of claim 25, wherein
The method of claim 2, wherein step (b) comprises obtaining identification information of the network connection point from a network adapter.
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出メカニズムにフォールバックするステップをさらに含むことを特徴とする方法。26. The method of claim 25, wherein
A method, further comprising the step of falling back to a selective roaming detection mechanism if a network interface supporting general signaling is unavailable.
前記ネットワーク接続ポイント情報の少なくとも一部に応じて、代わりになるネットワーク接続パスの中から選択するステップをさらに含むことを特徴とする方法。26. The method of claim 25, wherein
The method further comprising selecting from alternative network connection paths in response to at least a portion of the network connection point information.
第１ネットワークを介してノードと前記モバイルシステム間の通信を確立するステップと、
前記第１ネットワークと非接続の少なくとも第２ネットワーク上の前記ノードを識別するデータを、前記第１ネットワークを介して前記モバイルシステムに送信するステップと、
前記第２ネットワークを介して前記モバイルシステムと前記ノードとの通信を確立するために前記データを使用するステップとを含むことを特徴とする方法。A method for facilitating communication with a mobile system over a disconnected network,
Establishing communication between a node and the mobile system via a first network;
Transmitting data identifying the node on at least a second network not connected to the first network to the mobile system via the first network;
Using the data to establish communication between the mobile system and the node over the second network.
前記第１ネットワークを介して前記ノードに前記データを送信する前に、前記第２ネットワークを介して前記ノードとの通信許可を付与するために前記モバイルシステムを認証するステップをさらに含むことを特徴とする請求項３１記載の方法。32. The method of claim 31, wherein
Authenticating the mobile system to grant permission to communicate with the node via the second network before transmitting the data to the node via the first network. 32. The method of claim 31, wherein the method comprises:
前記送信ステップは、分配されるインターフェイスデータを前記第１ネットワークを介して前記モバイルシステムに送信するステップを含むことを特徴とする方法。22. The method of claim 21, wherein
The method of transmitting, wherein the transmitting comprises transmitting distributed interface data to the mobile system via the first network.
第１ネットワークセグメントを介してモバイルシステムとノード間の通信を確立するステップと、
第１ネットワークセグメントを介して、それぞれ第１ネットワークセグメントとは別個の複数のさらなるネットワーク・セグメントを介して前記ノードとの通信を再確立する際に使用される情報をモバイルコンピュータシステムに送信するステップと、
前記情報を使用して、前記別個の複数のさらなるネットワーク・セグメントのいずれかを介してモバイルコンピュータシステムとノード間の通信を再確立するステップとを含むことを特徴とする方法。A method for maintaining communication between a mobile computer system and a network node as the mobile computer system moves between a plurality of separate networks, the method comprising:
Establishing communication between the mobile system and the node via the first network segment;
Sending information to the mobile computer system via the first network segment for use in re-establishing communication with the node via a plurality of further network segments, each separate from the first network segment; ,
Using said information to re-establish communication between a mobile computer system and a node via any of said separate plurality of additional network segments.
前記情報は分配されるインターフェイスデータを含むことを特徴とする方法。37. The method of claim 36, wherein
The method wherein the information comprises interface data to be distributed.
（ａ）ネットワークと、一時的に接続されたモバイルコンピュータ装置との間の通信を確立するステップと、
（ｂ）一時的に接続されたモバイルコンピュータ装置が前記複数の別個のセグメント間を移動することができるローミング機構を使用するステップと、
（ｃ）モバイル・コンピューティングのローミングに応じて、ネットワークとモバイルコンピュータ装置との間の通信を再確立するための選択的で有効なネットワークパスを効率的に自動選択可能にするように、少なくとも１つのポリシーパラメータに実行させるステップとを含むことを特徴とする方法。In a method for providing least cost routing in a network having multiple distinct segments,
(A) establishing communication between the network and the temporarily connected mobile computing device;
(B) using a roaming mechanism that allows a temporarily connected mobile computing device to move between the plurality of distinct segments;
(C) at least one such that in response to roaming of mobile computing, a selective and effective network path for re-establishing communication between the network and the mobile computing device can be efficiently and automatically selected. Causing two policy parameters to execute.
前記ポリシーパラメータは、帯域幅、１データ単位当りのコスト、およびサービス品質からなるグループの中から選択された要素を含むことを特徴とする方法。39. The method of claim 38, wherein
The method of claim 1, wherein the policy parameters include an element selected from the group consisting of bandwidth, cost per data unit, and quality of service.
ネットワークに接続されたサーバを含み、前記サーバは、モバイルコンピュータ装置への物理的リンクが一時的に中断される間に、モバイルコンピュータ装置とピア・コンピュータシステムとの間の継続的な仮想データストリーム接続を維持するために、モバイルコンピュータ装置とピア・コンピュータシステムとの間の通信をプロキシすることを特徴とするモバイル・コンピューティング・ネットワーク。In a mobile computing network including at least one peer computer system and at least one mobile computing device connected to the network via a physical link,
A server connected to the network, the server providing a continuous virtual data stream connection between the mobile computing device and a peer computer system while the physical link to the mobile computing device is temporarily interrupted A mobile computing network, which proxies communication between mobile computing devices and peer computing systems to maintain communication.
前記モバイルコンピュータ装置と、少なくとも一つのさらなるコンピュータ装置との間の少なくとも１つのセッションを管理するステップと、
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時に、セッションを維持するステップとを含むことを特徴とする方法。A method for maintaining a persistent connection with at least one mobile computing device in a mobile computing environment, comprising:
Managing at least one session between the mobile computing device and at least one additional computing device;
Maintaining the session when the mobile computing device goes out of range, suspends, or changes the network address.
前記セッションのために少なくとも１つのユーザ設定可能なセッション優先順位を付与するステップをさらに含むことを特徴とする方法。The method according to claim 54, wherein
Assigning at least one user-configurable session priority for the session.
前記管理ステップは、前記モバイルコンピュータ装置によるネットワーク・リソースの消費を管理するステップを含むことを特徴とする方法。The method according to claim 54, wherein
The method of claim 1, wherein the managing step includes managing network resource consumption by the mobile computing device.
前記モバイルコンピュータ環境は複数のサブネットワークを含み、前記維持ステップでは、動的ホスト構成プロトコルを使用して前記モバイルコンピュータ装置が前記サブネットワーク間を移動する時にセッションを維持することを特徴とする方法。The method according to claim 54, wherein
The method, wherein the mobile computing environment includes a plurality of sub-networks, and wherein the maintaining comprises maintaining a session as the mobile computing device moves between the sub-networks using a dynamic host configuration protocol.
前記管理ステップは、前記モバイルコンピュータ装置とデータグラムのやり取りを行い、少なくとも１つのユーザ設定可能なパラメータに基づき前記データグラムのうち信頼性の低いデータグラムを自動的に除去することを特徴とする方法。The method according to claim 54, wherein
The managing step includes exchanging datagrams with the mobile computing device and automatically removing unreliable datagrams among the datagrams based on at least one user-configurable parameter. .
前記ユーザ設定可能なパラメータは、タイムアウトを含むことを特徴とする方法。59. The method of claim 58, wherein
The method wherein the user-configurable parameter comprises a timeout.
前記ユーザ設定可能なパラメータは、ユーザ設定可能な再試行番号を含むことを特徴とする方法。59. The method of claim 58, wherein
The method of claim 11, wherein the user-configurable parameter comprises a user-configurable retry number.
前記モバイルコンピュータ装置に可変の位置アドレスを付与するステップをさらに含み、前記管理ステップはセッションと関連付けされる仮想アドレスに前記位置アドレスを対応付けするステップを含むことを特徴とする方法。The method according to claim 54, wherein
The method further comprising assigning a variable location address to the mobile computing device, wherein the managing step comprises associating the location address with a virtual address associated with a session.
前記管理ステップは、遠隔プロシージャ・コール・プロトコルを用いてモバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。The method according to claim 54, wherein
The method of claim 1, wherein the managing step comprises communicating with the mobile computing device using a remote procedure call protocol.
前記維持ステップは、前記モバイルコンピュータ装置を前記モバイルコンピュータ環境に接続する物理的リンクの中断時に前記セッションの接続状態を維持することを特徴とする方法。The method according to claim 54, wherein
The method of claim 1, wherein the maintaining step maintains a connection state of the session when a physical link connecting the mobile computing device to the mobile computing environment is interrupted.
前記管理ステップは、少なくとも１つの標準的なトランスポート・プロトコルを用いて前記モバイルコンピュータ装置と通信するステップを含むことを特徴とする方法。The method according to claim 54, wherein
The method of claim 1, wherein the managing step comprises communicating with the mobile computing device using at least one standard transport protocol.
前記モバイルコンピュータ装置は複数のアプリケーションソースを含み、前記管理ステップは、前記複数のアプリケーションソースからのデータをストリームに融合するステップと、前記ストリームを送信するステップとを含むことを特徴とする方法。The method according to claim 54, wherein
The method wherein the mobile computing device includes a plurality of application sources, and wherein the managing step includes the steps of fusing data from the plurality of application sources into a stream and transmitting the stream.
前記ストリームから融合されたデータを逆多重化して、前記逆多重化されたデータを複数の関連する目的地に送信するステップをさらに含むことを特徴とする方法。66. The method of claim 65, wherein
The method further comprising demultiplexing the fused data from the stream and transmitting the demultiplexed data to a plurality of associated destinations.
前記ストリームはフレームを含み、前記融合処理は、モバイルコンピュータ環境の最大伝送単位に適合するように、前記フレームに対して動的なサイズ変更を行う処理を含むことを特徴とする方法。66. The method of claim 65, wherein
The method of claim 1, wherein the stream includes frames, and wherein the coalescing includes dynamically resizing the frames to fit a maximum transmission unit of a mobile computing environment.
前記融合処理は、信頼性の低いデータのセマンティクスを維持する処理と、前記信頼性の低いデータを前記セマンティクスに基づき選択的に破棄する処理とを含むことを特徴とする方法。66. The method of claim 65, wherein
The method according to claim 1, wherein the fusion process includes a process of maintaining semantics of unreliable data, and a process of selectively discarding the unreliable data based on the semantics.
前記管理ステップは、前記モバイルコンピュータ装置へのメッセージの保証配信、および／または前記モバイルコンピュータ装置からのメッセージの保証配信を行う処理を含むことを特徴とする方法。The method according to claim 54, wherein
The method wherein the managing step comprises a process of providing guaranteed delivery of messages to the mobile computing device and / or providing guaranteed delivery of messages from the mobile computing device.
前記管理ステップは、前記モバイルコンピュータ装置がどのネットワーク・リソースにアクセス可能かを制御する処理を含むことを特徴とする方法。The method according to claim 54, wherein
The method of claim 1, wherein the managing step comprises controlling which network resources the mobile computing device can access.
モバイルコンピュータ装置が圏外に出たり、サスペンドしたり、あるいはネットワークアドレスを変更した時にセッションを維持し、前記モバイルコンピュータ装置と少なくとも一つのさらなるコンピュータ装置間の少なくとも１つのセッションを管理するセッション・マネージャを含むサーバ。A server for maintaining a persistent connection with at least one mobile computing device in a mobile computing environment including at least one additional computing device,
A session manager that maintains a session when the mobile computing device goes out of service, suspends, or changes a network address, and manages at least one session between the mobile computing device and at least one additional computing device. server.
トランスポート・ドライバ・インターフェイスと、
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含み、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求に応じて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを前記プロキシ・サーバに送信することを特徴とするモバイルコンピュータ装置。In a mobile computing environment that includes a proxy server, a mobile computing device that maintains a persistent virtual connection with at least one additional computing device when the mobile computing device goes out of range, suspends, or changes its network address. So,
A transport driver interface,
A mobile interceptor connected to the transport driver interface,
The mobile interceptor intercepts a network service request at the transport driver interface, generates a remote procedure call in response to the network service request, and sends the remote procedure call to the proxy server. A mobile computer device, comprising:
前記トランスポート・ドライバ・インターフェイスと接続されるモバイル・インターセプタを含む少なくとも一つのモバイルコンピュータ装置を含むモバイルコンピュータ環境であって、
前記モバイル・インターセプタは、前記トランスポート・ドライバ・インターフェイスでのネットワークサービス要求を傍受し、前記ネットワークサービス要求を受けて、遠隔プロシージャ・コールを生成し、前記遠隔プロシージャ・コールを少なくとも１つのプロキシ・サーバに送信し、
前記プロキシ・サーバは、前記モバイル・インターセプタによって送信された前記遠隔プロシージャ・コールを受信及び処理するワーク・ディスパッチャを少なくとも１つ含み、前記プロキシ・サーバは、前記モバイルコンピュータ装置が前記モバイルコンピュータ環境と一時的に切断された時に、前記モバイルコンピュータ装置の代わりに仮想セッションをプロキシするプロキシ・キューを含むことを特徴とするモバイルコンピュータ環境。A transport driver interface,
A mobile computing environment including at least one mobile computing device including a mobile interceptor connected with the transport driver interface,
The mobile interceptor intercepts a network service request at the transport driver interface, generates a remote procedure call in response to the network service request, and directs the remote procedure call to at least one proxy server. Send to
The proxy server includes at least one work dispatcher that receives and processes the remote procedure call sent by the mobile interceptor, wherein the proxy server establishes a connection between the mobile computing device and the mobile computing environment. A mobile computing environment comprising a proxy queue for proxying a virtual session on behalf of the mobile computing device when disconnected.
（ａ）ネットワーク・インターフェイスからネットワーク接続ポイントの識別情報を受け取るステップと、
（ｂ）前記ネットワーク接続ポイントの識別情報を使用して前記モバイルノードが新しいネットワーク接続ポイントに移動したかどうかを判定するステップと、
（ｃ）前記ステップ（ｂ）を受けて信号を生成するステップを含むことを特徴とする方法。A method for determining whether a mobile node has moved to a new network attachment point,
(A) receiving identification information of a network connection point from a network interface;
(B) using the identity of the network attachment point to determine whether the mobile node has moved to a new network attachment point;
(C) generating a signal in response to step (b).
ネットワーク・トポロジ・マップを保持するステップ、及び前記ネットワーク・トポロジ・マップを使用して前記ステップ（ｃ）を行うステップをさらに含むことを特徴とする方法。121. The method of claim 120,
Maintaining the network topology map, and using the network topology map to perform step (c).
前記ステップ（ｃ）はローミング信号を生成するステップを含むことを特徴とする方法。121. The method of claim 120,
The method of claim 1, wherein step (c) comprises generating a roaming signal.
前記ステップ（ｂ）はネットワーク・アダプタから前記ネットワーク接続ポイントの識別情報を取得するステップを含むことを特徴とする方法。121. The method of claim 120,
The method of claim 2, wherein step (b) comprises obtaining identification information of the network connection point from a network adapter.
一般的な信号をサポートするネットワーク・インターフェイスが利用不可の場合、選択的ローミング検出機構にフォールバックするステップをさらに含むことを特徴とする方法。121. The method of claim 120,
The method, further comprising the step of falling back to a selective roaming detection mechanism if a network interface supporting general signaling is unavailable.
前記ネットワーク接続ポイント情報の少なくとも一部分を受けて、択一的なネットワーク接続パスから選択するステップをさらに含むことを特徴とする方法。121. The method of claim 120,
Receiving at least a portion of the network connection point information and selecting from an alternative network connection path.
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 (en) | 2004-03-25 |
| JP2004509539A5 JP2004509539A5 (en) | 2005-04-07 |
Family
ID=26956948
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002527943A Pending JP2004509539A (en) | 2000-09-12 | 2001-09-12 | Method and apparatus for providing mobile and other intermittent connectivity in a computer environment |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1364296A4 (en) |
| JP (1) | JP2004509539A (en) |
| AU (1) | AU2001289010A1 (en) |
| CA (1) | CA2421609A1 (en) |
| WO (1) | WO2002023362A1 (en) |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006352337A (en) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | Communication apparatus and communication control method |
| JP2007306577A (en) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | Always-on wireless internet protocol communication |
| JP2008508837A (en) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | Method and apparatus for providing mobile and other intermittent connectivity in a computer environment |
| JP2009119849A (en) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | Information processor, information processing method, and program |
| JP2009532765A (en) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | Method and device for maintaining a session based on presence state information |
| JP2009535873A (en) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | Data transmission between server and communication object |
| 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 (en) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | Application server and method of controlling operation of the same |
| 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 (en) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | Method and apparatus for providing intelligent radio selection for legacy and non-legacy applications |
| 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 (en) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Interception of RPC calls |
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 |
| US20050198379A1 (en) | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
| US7562146B2 (en) * | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
| JP2005515700A (en) * | 2002-01-14 | 2005-05-26 | ネットモーション ワイヤレス インコーポレイテッド | Methods and devices for providing secure connections in mobile computing environments 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 (en) | 2002-11-26 | 2009-07-08 | Ｎｅｃインフロンティア株式会社 | Wireless LAN network QoS control system, base station, terminal, QoS control method and program |
| FR2856540A1 (en) * | 2003-06-19 | 2004-12-24 | Filfree Networks | WIRELESS LOCAL AREA NETWORK ARCHITECTURE |
| DE10346007A1 (en) * | 2003-10-02 | 2005-04-28 | Siemens Ag | Communication device and method for setting a security configuration of a communication device |
| US7594018B2 (en) * | 2003-10-10 | 2009-09-22 | Citrix Systems, Inc. | Methods and apparatus for providing access to persistent application sessions |
| US7725716B2 (en) | 2004-06-28 | 2010-05-25 | Japan Communications, Inc. | Methods and systems for encrypting, transmitting, and storing electronic information and files |
| WO2006012058A1 (en) * | 2004-06-28 | 2006-02-02 | Japan Communications, Inc. | Systems and methods for mutual authentication of network |
| US9219579B2 (en) | 2004-07-23 | 2015-12-22 | Citrix Systems, Inc. | Systems and methods for client-side application-aware prioritization of network communications |
| KR20070037649A (en) | 2004-07-23 | 2007-04-05 | 사이트릭스 시스템스, 인크. | A method and systems for routing packets from a gateway to an endpoint |
| 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 |
| 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 |
| 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 |
| 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 (en) * | 2006-10-10 | 2008-04-24 | Matsushita Electric Ind Co Ltd | Information communication device, information communication method, and program |
| 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 |
| US8701010B2 (en) | 2007-03-12 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods of using the refresh button to determine freshness policy |
| US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
| WO2014016652A1 (en) | 2012-07-27 | 2014-01-30 | Nokia Corporation | 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 |
| US20170141950A1 (en) * | 2014-03-28 | 2017-05-18 | Hewlett Packard Enterprise Development Lp | 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 (en) * | 2021-06-30 | 2023-07-25 | 脸萌有限公司 | Network card flow testing method, device, network equipment, system and readable medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000115253A (en) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | Communication method, portable terminal and gateway device |
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 (en) * | 1996-10-16 | 2004-02-03 | 株式会社東芝 | Mobile computer device and packet encryption authentication method |
| JP3651721B2 (en) * | 1996-11-01 | 2005-05-25 | 株式会社東芝 | Mobile computer device, packet processing device, and communication control method |
| 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 (en) * | 1998-05-12 | 2000-10-31 | Nokia Mobile Phones Ltd | Method of connecting a wireless data terminal in a data transmission network and a wireless data terminal |
-
2001
- 2001-09-12 EP EP01968790A patent/EP1364296A4/en not_active Ceased
- 2001-09-12 CA CA002421609A patent/CA2421609A1/en not_active Abandoned
- 2001-09-12 JP JP2002527943A patent/JP2004509539A/en active Pending
- 2001-09-12 WO PCT/US2001/028391 patent/WO2002023362A1/en active Application Filing
- 2001-09-12 AU AU2001289010A patent/AU2001289010A1/en not_active Abandoned
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000115253A (en) * | 1998-09-30 | 2000-04-21 | Toshiba Corp | Communication method, portable terminal and gateway device |
Cited By (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4638904B2 (en) * | 2002-08-01 | 2011-02-23 | リサーチ イン モーション リミテッド | Always-on wireless internet protocol communication |
| JP2007306577A (en) * | 2002-08-01 | 2007-11-22 | Research In Motion Ltd | Always-on wireless internet protocol communication |
| JP2008160826A (en) * | 2002-08-01 | 2008-07-10 | Research In Motion Ltd | Always-on wireless internet protocol communication |
| JP2008508837A (en) * | 2004-06-10 | 2008-03-21 | ネットモーション ワイヤレス インコーポレイテッド | Method and apparatus for providing mobile and other intermittent connectivity in a computer environment |
| US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
| 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 |
| 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 |
| US7870294B2 (en) | 2004-09-30 | 2011-01-11 | Citrix Systems, Inc. | Method and apparatus for providing policy-based document control |
| 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 |
| 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 |
| US8312261B2 (en) | 2005-01-28 | 2012-11-13 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| JP2006352337A (en) * | 2005-06-14 | 2006-12-28 | Ntt Docomo Inc | Communication apparatus and communication control method |
| JP4628194B2 (en) * | 2005-06-14 | 2011-02-09 | 株式会社エヌ・ティ・ティ・ドコモ | Communication device, required time measurement method and communication control method |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| KR101372011B1 (en) * | 2006-03-31 | 2014-03-26 | 알카텔-루센트 유에스에이 인코포레이티드 | Method and device for maintaining sessions based on presence status information |
| JP2009532765A (en) * | 2006-03-31 | 2009-09-10 | アルカテル−ルーセント ユーエスエー インコーポレーテッド | Method and device for maintaining a session based on presence state information |
| JP2009535873A (en) * | 2006-04-28 | 2009-10-01 | ジェムアルト エスアー | Data transmission between server and communication object |
| 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 |
| US9642057B2 (en) | 2007-09-27 | 2017-05-02 | Sun Patent Trust | Network node and 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 |
| US9009720B2 (en) | 2007-10-20 | 2015-04-14 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| JP2009119849A (en) * | 2007-10-23 | 2009-06-04 | Ricoh Co Ltd | Information processor, information processing method, and program |
| US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
| JP2011070279A (en) * | 2009-09-24 | 2011-04-07 | Fujifilm Corp | Application server and method of controlling operation of the same |
| JP2013520138A (en) * | 2010-02-16 | 2013-05-30 | クゥアルコム・インコーポレイテッド | Method and apparatus for providing intelligent radio selection for legacy and non-legacy applications |
| 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 (en) * | 2013-12-05 | 2017-01-19 | クラウドストライク インコーポレイテッド | Interception of RPC calls |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1364296A4 (en) | 2004-09-15 |
| WO2002023362A1 (en) | 2002-03-21 |
| CA2421609A1 (en) | 2002-03-21 |
| EP1364296A1 (en) | 2003-11-26 |
| AU2001289010A1 (en) | 2002-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004509539A (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computer environment | |
| 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 (en) | Method and apparatus for providing mobile and other intermittent connectivity in a computer environment | |
| 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 | |
| US20050243857A1 (en) | Simultaneously routing data over multiple wireless networks | |
| JP2004509539A5 (en) | ||
| CN110830461B (en) | Cross-region RPC service calling method and system based on TLS long connection | |
| 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 | |
| Fox et al. | IBM's Shared Memory Communications over RDMA (SMC-R) Protocol |
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 |