Registration method for network
Abstract
[Task] Disclose a coupled data network with a system for registering end systems.
Solution.The Foreign Network includes Foreign Mobile Exchange Center 40 and Foreign Base Station 36. The Foreign Mobile Exchange Center contains a registered server in service, the Foreign Base Station contains a Foreign Access Hub, and the Foreign Access Hub contains a proxy registration agent. The home network includes a home mobile exchange center with a home registration server. The first end system is subscribed to the home network and operates within the foreign network. This end system includes an end enrollment agent, the end enrollment agent is associated with the proxy enrollment agent, the proxy enrollment agent is associated with the service enrollment server, and the service enrollment server is associated with the home enrollment server. ing.
Term
Term ended
Projected expiry passed 14 October 2018, 7.9 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
47 claims: 3 independent, 44 dependent
- 1【特許請求の範囲】 【請求項1】 結合型のデータ・ネットワークであって、 フォーリン移動交換センターとフォーリン基地局とを含み、前記フォーリン移動交換センターはサービス登録サーバを含み、前記フォーリン基地局はフォーリン・アクセス・ハブを含み、前記フォーリン・アクセス・ハブはプロキシ登録エージェントを含んでいるフォーリン・ネットワークと、 ホーム登録サーバを伴うホーム移動交換センターを含むホーム・ネットワークと、 前記ホーム・ネットワークに加入していて、前記フォーリン・ネットワーク内で動作している第1のエンド・システムとを含み、前記エンド・システムはエンド登録エージェントを含み、前記エンド登録エージェントは前記プロキシ登録エージェントに結合され、前記プロキシ登録エージェントは前記サービス登録サーバに結合され、前記サービス登録サーバは前記ホーム登録サーバに結合されているネットワーク。
- 2【請求項2】 請求項1に記載のネットワークにおいて、前記ホーム登録サーバは、前記フォーリン・ネットワークが前記第1のエンド・システムに対してホストとして処理を行うために認証されていることを証明するためのモジュールを含むネットワーク。
- 3【請求項3】 請求項1に記載のネットワークにおいて、前記ホーム登録サーバは、前記第1のエンド・システムが前記ホーム・ネットワークのサービスを受けるために認証されていることを証明するためのモジュールを含むネットワーク。
- 4【請求項4】 請求項1に記載のネットワークにおいて、前記サービス登録サーバは、前記第1のエンド・システムが前記ホーム・ネットワークの加入者であることを認証するためのモジュールを含むネットワーク。
- 5【請求項5】 請求項1に記載のネットワークにおいて、 前記ホーム登録サーバは、前記フォーリン・ネットワークが前記第1のエンド・システムに対してホストとして処理を行うために認証されていることを証明するためのモジュールを含み、 前記ホーム登録サーバは、前記第1のエンド・システムが前記ホーム・ネットワークのサービスを受けるために認証されていることを証明するためのモジュールを含み、 前記サービス登録サーバは、前記第1のエンド・システムが前記ホーム・ネットワークの加入者であることを認証するためのモジュールを含むネットワーク。
- 6【請求項6】 請求項1に記載のネットワークにおいて、 前記フォーリン・アクセス・ハブは第1のサービス・インターワーキング機能を含み、 前記ホーム・ネットワークは第1のホーム・インターワーキング機能をさらに含み、 前記第1のエンド・システムと第1の通信サーバとの間で、前記フォーリン基地局の中の前記フォーリン・アクセス・ハブの第1のサービス・インターワーキング機能を通じて、第1のメッセージを転送することができるようになっているネットワーク。
- 7【請求項7】 請求項6に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能を通じて、前記第1の通信サーバに対して、前記第1のメッセージを転送することができるようになっているネットワーク。
- 8【請求項8】 請求項6に記載のネットワークにおいて、前記第1のエンド・システムは前記フォーリン・アクセス・ハブに結合することができる無線モデムを含むネットワーク。
- 9【請求項9】 請求項6に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能が前記ホーム移動交換センターに含まれているネットワーク。
- 10【請求項10】 請求項6に記載のネットワークにおいて、 前記ホーム・ネットワークに加入していて前記ホーム・ネットワークの内部で固定のエンド・システムとして動作している第2のエンド・システムと、 第2のホーム・インターワーキング機能を伴うホーム・アクセス・ハブを含むホーム基地局とを含み、前記第2のエンド・システムと第2の通信サーバとの間で、前記第2のホーム・インターワーキング機能を通じて、第2のメッセージを転送することができるようになっているネットワーク。
- 11【請求項11】 請求項6に記載のネットワークにおいて、 前記ホーム・ネットワークに加入していて、前記ホーム・ネットワーク内で移動エンド・システムとして動作している第2のエンド・システムをさらに含み、 前記ホーム移動交換センターは第2のホーム・インターワーキング機能を備え、前記第1のホーム・インターワーキング機能は前記ホーム移動交換センターに含まれていて、 第2のサービス・インターワーキング機能を伴うホーム・アクセス・ハブを含むホーム基地局をさらに含み、前記第2のエンド・システムと第2の通信サーバとの間で、前記第2のサービス・インターワーキング機能を通じて、そして前記第2のホーム・インターワーキング機能を通じて、第2のメッセージを転送することができるようになっているネットワーク。
- 12【請求項12】 請求項6に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能は、前記第1のホーム・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのホーム・アカウンティング収集モジュールを含むネットワーク。
- 13【請求項13】 請求項12に記載のネットワークにおいて、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記ホーム・アカウンティング収集モジュールは、ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 14【請求項14】 請求項13に記載のネットワークにおいて、 前記ホーム・ネットワークはホーム料金請求書作成プロセッサをさらに含み、 前記ホーム・アカウンティング・サーバは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記ホーム・アカウンティング・サーバからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 15【請求項15】 請求項14に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記第1のサービス・インターワーキング機能は、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのフォーリン・アカウンティング収集モジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 16【請求項16】 請求項6に記載のネットワークにおいて、 前記ホーム・ネットワークはホーム料金請求書作成プロセッサをさらに含み、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記第1のサービス・インターワーキング機能は、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのフォーリン・アカウンティング収集モジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 17【請求項17】 請求項1に記載のネットワークにおいて、 前記フォーリン・アクセス・ハブはサービス・インターワーキング機能を含み、前記サービス・インターワーキング機能はフォーリン・アカウンティング収集モジュールを含んでいて、 前記ホーム移動交換センターはホーム・インターワーキング機能をさらに含み、前記ホーム・インターワーキング機能はホーム・アカウンティング収集モジュールを含んでいて、 前記第1のエンド・システムは前記無線データ・ネットワークに加入していて、前記フォーリン・アクセス・ハブに結合可能であり、前記ホームおよびサービス・アカウンティング収集モジュールは前記第1のエンド・システムと通信サーバとの間で前記ホーム・インターワーキング機能を通じて、そして前記サービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するようになっているネットワーク。
- 18【請求項18】 請求項17に記載のネットワークにおいて、前記ホーム・アカウンティング収集モジュールは、前記ホーム・インターワーキング機能を通じて前記第1のエンド・システムから前記通信サーバへ転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含むネットワーク。
- 19【請求項19】 請求項17に記載のネットワークにおいて、 前記フォーリン移動交換センターはフォーリン・アカウンティング・サーバを含み、 前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 20【請求項20】 請求項17に記載のネットワークにおいて、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記ホーム・アカウンティング収集モジュールは、前記ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 21【請求項21】 請求項20に記載のネットワークにおいて、 前記ホーム・ネットワークはホーム料金請求書作成プロセッサをさらに含み、 前記ホーム・アカウンティング・サーバは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記ホーム・アカウンティング・サーバからのアカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 22【請求項22】 請求項21に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記フォーリン・アカウンティング収集モジュールは、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールをさらに含んでいて、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 23【請求項23】 請求項17に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記フォーリン・アカウンティング収集モジュールは、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールをさらに含んでいて、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 24【請求項24】 請求項17に記載のネットワークにおいて、 前記フォーリン移動交換センターはフォーリンアカウンティング・サーバを含み、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記フォーリン・アカウンティング収集モジュールは、フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、 前記ホーム・アカウンティング収集モジュールは、ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 25【請求項25】 請求項1に記載のネットワークにおいて、 前記フォーリン・アクセス・ハブはサービス・インターワーキング機能をさらに含み、 前記ホーム移動交換センターはホーム・インターワーキング機能を含み、 前記第1のエンド・システムと前記ホーム・インターワーキング機能との間で、データ・パケットのイン・シーケンス配送を確保するプロトコルを使って、前記サービス・インターワーキング機能を通じて、メッセージを転送することができるようになっているネットワーク。
- 26【請求項26】 フォーリン移動交換センターとフォーリン基地局を含んでいるフォーリン・ネットワークに結合されているデータ・ネットワークであって、前記フォーリン移動交換センターはサービス登録サーバを含み、前記フォーリン基地局はフォーリン・アクセス・ハブを含み、前記フォーリン・アクセス・ハブはプロキシ登録エージェントを含んでいて、前記データ・ネットワークは、 ホーム登録サーバを含むホーム移動交換センターを含むホーム・ネットワークと、 前記ホーム・ネットワークに加入していて、前記フォーリン・ネットワーク内で動作している第1の移動エンド・システムとを含み、前記第1の移動エンド・システムはエンド登録エージェントを含み、前記エンド登録エージェントは前記プロキシ登録エージェントに結合され、前記プロキシ登録エージェントは前記サービス登録サーバに結合され、前記サービス登録サーバは前記ホーム登録サーバに結合されているネットワーク。
- 27【請求項27】 請求項26に記載のネットワークにおいて、前記ホーム登録サーバは、前記フォーリン・ネットワークが前記第1のエンド・システムに対してホストとして処理を行なうために認証されていることを証明するためのモジュールを含むネットワーク。
- 28【請求項28】 請求項26に記載のネットワークにおいて、前記ホーム登録サーバは、前記第1のエンド・システムが前記ホーム・ネットワークのサービスを受けるために認証されていることを証明するためのモジュールを含むネットワーク。
- 29【請求項29】 請求項26に記載のネットワークにおいて、 前記ホーム・ネットワークは第1のホーム・インターワーキング機能を含み、 前記第1のエンド・システムと第1の通信サーバとの間で、前記第1のホーム・インターワーキング機能を通じて、そして前記フォーリン基地局の中の前記フォーリン・アクセス・ハブの第1のサービス・インターワーキング機能を通じて、第1のメッセージを転送することができるようになっているネットワーク。
- 30【請求項30】 請求項29に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能を通じて前記第1のエンド・システムから前記第1の通信サーバに対して、前記第1のメッセージを転送することができるようになっているネットワーク。
- 31【請求項31】 請求項29に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能が前記ホーム移動交換センターに含まれているネットワーク。
- 32【請求項32】 請求項29に記載のネットワークにおいて、 前記ホーム・ネットワークに加入していて、前記ホーム・ネットワークの内部で固定のエンド・システムとして動作している第2のエンド・システムと、 第2のホーム・インターワーキング機能を伴うホーム・アクセス・ハブを含んでいるホーム基地局とを含み、前記第2のエンド・システムと第2の通信サーバとの間で、前記第2のホーム・インターワーキング機能を通じて、第2のメッセージを転送することができるようになっているネットワーク。
- 33【請求項33】 請求項29に記載のネットワークにおいて、 前記ホーム・ネットワークに加入していて前記ホーム・ネットワーク内で移動エンド・システムとして動作している第2のエンド・システムをさらに含み、 第2のホーム・インターワーキング機能を備え、前記第1のホーム・インターワーキング機能を中に含んでいる前記ホーム移動交換センターと、 第2のサービス・インターワーキング機能を伴うホーム・アクセス・ハブを含むホーム基地局とをさらに含み、前記第2のエンド・システムと第2通信サーバとの間で、前記第2のサービス・インターワーキング機能を通じて、そして前記第2のホーム・インターワーキング機能を通じて、第2のメッセージを転送することができるようになっているネットワーク。
- 34【請求項34】 請求項29に記載のネットワークにおいて、前記第1のホーム・インターワーキング機能は、前記第1のホーム・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのホーム・アカウンティング収集モジュールを含むネットワーク。
- 35【請求項35】 請求項34に記載のネットワークにおいて、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記ホーム・アカウンティング収集モジュールは、ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 36【請求項36】 請求項35に記載のネットワークにおいて、 前記ホーム・ネットワークは料金請求書作成プロセッサをさらに含み、 前記ホーム・アカウンティング・サーバは、前記料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記料金請求書作成プロセッサは、前記ホーム・アカウンティング・サーバからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 37【請求項37】 請求項36に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記第1のサービス・インターワーキング機能は、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのフォーリン・アカウンティング収集モジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 38【請求項38】 請求項29に記載のネットワークにおいて、 前記ホーム・ネットワークはホーム料金請求書作成プロセッサをさらに含み、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記第1のサービス・インターワーキング機能は、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのフォーリン・アカウンティング収集モジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 39【請求項39】 請求項26に記載のネットワークにおいて、前記フォーリン・アクセス・ハブはサービス・インターワーキング機能を含み、前記サービス・インターワーキング機能はサービス・アカウンティング収集モジュールを含んでいて、 前記ホーム移動交換センターはホーム・インターワーキング機能をさらに含み、前記ホーム・インターワーキング機能は、ホーム・アカウンティング収集モジュールを含んでおり、そして、 前記第1のエンド・システムは前記無線データ・ネットワークに加入していて前記フォーリン・アクセス・ハブに結合可能であり、前記ホームおよびサービス・アカウンティング収集モジュールは前記第1のエンド・システムと通信サーバとの間で、前記ホーム・インターワーキング機能を通じて、そして前記サービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するようになっているネットワーク。
- 40【請求項40】 請求項39に記載のネットワークにおいて、前記ホーム・アカウンティング収集モジュールは、前記ホーム・インターワーキング機能を通じて前記第1のエンド・システムから前記通信サーバに対して転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含むネットワーク。
- 41【請求項41】 請求項39に記載のネットワークにおいて、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記ホーム・アカウンティング収集モジュールは、前記ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 42【請求項42】 請求項41に記載のネットワークにおいて、 前記ホーム・ネットワークはホーム料金請求書作成プロセッサをさらに含み、 前記ホーム・アカウンティング・サーバは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記ホーム・アカウンティング・サーバからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 43【請求項43】 請求項42に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記フォーリン・アカウンティング収集モジュールは、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールをさらに含んでいて、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 44【請求項44】 請求項39に記載のネットワークにおいて、 前記フォーリン・ネットワークはフォーリン・アカウンティング・サーバとフォーリン料金請求書作成プロセッサとをさらに含み、 前記フォーリン・アカウンティング収集モジュールは、前記第1のサービス・インターワーキング機能を通じて転送されたメッセージ・トラヒックについてのアカウンティング・データを収集するためのサブモジュールを含み、前記フォーリン・アカウンティング収集モジュールは、前記フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールをさらに含んでいて、前記フォーリン・アカウンティング・サーバは、前記フォーリン料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記フォーリン料金請求書作成プロセッサは、前記ホーム料金請求書作成プロセッサに対してアカウンティング・レポートを送信するためのモジュールを含み、前記ホーム料金請求書作成プロセッサは、前記フォーリン料金請求書作成プロセッサからの前記アカウンティング・レポートに基づいて、顧客の料金請求書を作成するためのモジュールを含むネットワーク。
- 45【請求項45】 請求項39に記載のネットワークにおいて、 前記フォーリン移動交換センターはフォーリンアカウンティング・サーバを含み、 前記ホーム移動交換センターはホーム・アカウンティング・サーバを含み、 前記フォーリン・アカウンティング収集モジュールは、フォーリン・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含み、 前記ホーム・アカウンティング収集モジュールは、ホーム・アカウンティング・サーバに対してアカウンティング・レポートを定期的に送信するためのサブモジュールを含むネットワーク。
- 46【請求項46】 請求項26に記載のネットワークにおいて、前記フォーリン・アクセス・ハブはサービス・インターワーキング機能をさらに含み、 前記ホーム移動交換センターはホーム・インターワーキング機能を含み、 前記第1のエンド・システムと前記ホーム・インターワーキング機能との間で、データ・パケットのイン・シーケンス配送を確保するプロトコルを使って、前記サービス・インターワーキング機能を通じて、メッセージを転送することができるようになっているネットワーク。
- 47【請求項47】 フォーリン移動交換センターとフォーリン基地局を含むフォーリン・ネットワークに結合されているデータ・ネットワークにおいて使うための移動エンド・システムであって、前記フォーリン移動交換センターはサービス登録サーバを含み、前記フォーリン基地局はフォーリン・アクセス・ハブを含み、前記フォーリン・アクセス・ハブはプロキシ登録エージェントおよびホーム登録サーバを伴うホーム移動交換センターを含むホーム・ネットワークとを含んでいて、前記移動エンド・システムは、 前記ホーム・ネットワークに加入していて、前記フォーリン・ネットワーク内で動作しており、前記移動エンド・システムはエンド登録エージェントを含み、前記エンド登録エージェントは前記プロキシ登録エージェントに結合され、前記プロキシ登録エージェントは前記サービスしている登録サーバに対して結合され、前記サービス中の登録サーバは前記ホーム登録サーバに結合されている移動エンド・システム。
Independent claims47
559 paragraphs in 1 section, as filed
Description: TECHNICAL FIELD [Detailed description of the invention]
【0001】
[Technical field to which the invention belongs]
The present invention relates to a combined data network, particularly to a registration system within the combined data network.
【0002】
[Problems to be Solved by Conventional Techniques and Inventions]
<Background of the Invention> The priority privilege of Provisional Application No. 60 / 061,915 dated October 14, 1997 is claimed by the present application.
【0003】
Figure 1 shows three business entities whose cooperating devices typically provide remote Internet access to the user's computer 2 through modem 4. The user's computer 2 and modem 4 make up the end system.
【0004】
The first business entity is the dial-up plain old telephone system (POTS), or the telephone company (telco) that owns and operates the Integrated Services Digital Network (ISDN). telco provides a transmission medium in the form of a public switched telephone network (PSTN) 6 that allows bits (or packets) to flow between the user and two other business entities.
【0005】
The second business entity is the Internet Service Provider (ISP). The ISP has one or more Point of Presence (POP) 8 deployed within its service area, manages it, and end users connect to it for network services. .. An ISP usually establishes a POP within each major calling area, hoping that there will be subscribers to that ISP. POP transforms message traffic from the PSTN into a digital format carried over the intranet backbone 10. Intranet Backbone 10 is owned by ISP or MCI, Inc. It is either leased from an intranet backbone provider such as. ISPs typically lease partial or full T1 or T3 lines from the telco for connections to the PSTN. The POP and ISP media data centers 14 are connected together on the backbone of the intranet through router 12A. The data center houses the ISP's web servers, mail servers, accounting and registration servers, enabling the ISP to provide web content, email and web hosting services to end users. .. Future value-added services can be added by deploying additional types of servers within the data center. The ISP also maintains router 12A to connect to the public internet backbone 20. In the current model for remote access, end users typically have a service relationship with both their telco and their ISP, and are usually charged separately from each. End users contact their ISP by dialing the nearest POP and by executing a communication protocol known as the Internet Engineering Task Force (IETF) Point-to-Point Protocol (PPP). Access and access Public Internet 20 through its ISP.
【0006】
The third business entity is a private company that owns and runs its own Private Intranet 18 through Router 12B for business reasons. Enterprise employees make POTS / ISDN calls to the enterprise remote access server 16 and remotely to the enterprise network 18 by running the IETF's PPP protocol (for example, from their own home or from their own home). Can be accessed (while on the street). When accessing the enterprise, the end user only pays for the cost of connecting to the enterprise's remote access server 16. ISP is not involved. The private company maintains Router 12B to connect end users to the company's intranet 18 and / or public Internet 20.
【0007】
End users now pay telco both the cost of making a call and the cost of a telephone line to their home. The end user also pays the ISP to access the ISP's networks and services. The present invention provides benefits to wireless service providers such as Sprint PCS and PrimeCo, and also benefits to Internet service providers such as AOL and AT & T's Worldnet.
【0008】
Internet service providers now offer Internet access services, web content services, email services, content hosting services, and roaming to end users. With low margins and no room for feature and price-based market segmentation, ISPs are looking for value-added services to improve their margins. In the short term, device vendors will allow ISPs to access faster, virtual private networking (the ability to securely use public networks as private networks and the ability to connect to intranets), roaming consortiums, pushes. It will be possible to provide ISPs with solutions that enable them to provide technology and quality of specific services. In the long run, it will provide voice over the Internet and mobility. At that time, ISPs will be able to use these value-added services to escape the low-margin shackles. Many of these added values fall into the category of network services and can only be provided through the infrastructure equipment of the network. Other value-added services fall into the category of application services that require support from the network infrastructure, while others do not require support from the network infrastructure. Services such as faster access, virtual private networks, roaming, mobility, voice, quality of service, and QOS-based accounting all require sophisticated network infrastructure. The system described here either provides these advanced services directly or provides clues for later addition of these services as future enhancements. Wireless service providers have more revenue You can get a good share. The ISP can offer more services with better market segmentation.
【0009】
The present invention provides end users with remote wireless access to public internet, private intranets and internet service providers. Radio access is provided through base stations in the home network and base stations in the foreign network with which you have a replacement contract.
【0010】
One purpose of this system is to end the wireless packet switching network that divides mobility management into local, micro, macro, and global connection handover categories and minimizes handoff updates according to the handover categories. To provide to the user. Another goal is to integrate MAC handoff messages with network handoff messages. Furthermore, another object of the present invention is to direct the registration function separately to the registration server and the routing function separately to the interworking function unit. Yet another purpose is to provide an intermediate XTunnel channel between the wireless hub (also known as the access hub AH) in the foreign network and the interworking functional unit (IWF unit). Yet another objective is to provide an IXTunnel channel between the interworking functional unit in the foreign network and the interworking functional in the home network. Yet another objective is to upgrade the Layer 2 Tunneling Protocol (L2TP) to support mobile end systems. Yet another purpose is to perform network layer registration before initiating a PPP communication session.
【0011】
[Means for solving problems]
According to one embodiment of the invention, a coupled data network with a system for registering end systems is disclosed. Combined data networks include foreign networks and home networks. The foreign network includes a foreign mobile exchange center and a foreign base station, the foreign mobile exchange center contains a registered server in service, the foreign base station contains a foreign access hub, and the foreign access hub is a proxy registration. Contains agents. The home network includes a home mobile exchange center with a home registration server. The first end system is a subscriber to the home network and operates within the foreign network. The end system contains an end registration agent, the end registration agent is bound to a proxy registration agent, the proxy registration agent is bound to the serviced registration server, and the serviced registration server is bound to the home registration server. ing.
【0012】
According to another embodiment of the present invention, a data network with a home network including a home mobile exchange center with a home registration server is disclosed. The first mobile end system is a subscriber to the home network and operates within the foreign network. The first mobile end system contains an end registration agent, the end registration agent is bound to the proxy registration agent, the proxy registration agent is bound to the serviced registration server, and the serviced registration server is to the home registration server. It is combined.
【0013】
The present invention will be described in detail in the following description of preferred embodiments with reference to the drawings.
【0014】
BEST MODE FOR CARRYING OUT THE INVENTION
The system uses virtual private network services over high-speed packet-switched wireless data links to provide computer users with remote access to the Internet and private intranets. These users can access the public internet, private intranet and their respective internet service providers over wireless links. The network supports roaming, the ability to access the Internet and private intranets using virtual private network services from anywhere the services provided by the current system are available. The network also supports handoffs, the ability to change the user's point of addition to the network without disrupting the PPP link between the PPP client and the PPP server. The network targets users running horizontal internet and intranet applications. These applications include email, file transfer, browser-based WWW access, and other business applications built around the intranet. Since the network will be based on the IETF standard, it can run streaming media protocols such as RTP and conferencing protocols such as H.323 on it.
【0015】
Other Internet remote access technologies that have already been deployed or are in various stages of deployment include dial-up access to wireless lines based on POTS and ISDN, XDSL access. There are GSM / CDMA / TDMA-based wireless circuit-switched access, GSM / CDMA / TDMA-based wireless packet-switched access, cable modems and satellite-based systems. However, the systems of the invention have low deployment costs, ease of maintenance, wide feature sets, scalability, the ability to degrade performance in sophisticated ways under heavy load, and virtual private networking, roaming, mobility, etc. And provide support for the sophistication of network services, such as quality of service for the relevant benefits of users and service providers.
【0016】
For wireless service providers that own the personal communication system (PCS) spectrum, the invention can compete with the services provided by the traditional wired line telcos that owns and operates the PSTN. Enable to provide wireless packet-switched data access services. The wireless service provider can also decide to become an internet service provider itself, in which case the service provider will own and operate the entire network and end-to-end to the user. Providing two-end services.
【0017】
For Internet Service Providers, the System allows Internet Service Providers to bypass telcos (if they purchase or lease their spectrum), and a direct end. Providing users with a two-end service, perhaps saving access to telcos. The service may increase in the future as the Internet grows larger than it is today.
【0018】
The system of the present invention is flexible and may be advantageous to wireless service providers who are not Internet service providers but who only provide ISP, Internet or private intranet access to end users. is there. The system may also benefit service providers who provide wireless access and Internet services to end users. The system can also benefit service providers that provide wireless access and Internet services, but so that the wireless portion of the network is used for access to other ISPs or private intranets. Can be.
【0019】
In Figure 2, the end system 32 (for example, Win) A system based on 95 personal computers) connects to wireless network 30 using an external or internal modem. These modems allow the end system to send and receive media access control (MAC) frames over airlink 34. An external modem is attached to the PC via a wired or wireless link. The external modem is fixed and, for example, is co-located with a rooftop mount directional antenna. The external modem can be connected to the user's PC using one of 802.3, a general purpose serial bus, a parallel port, infrared, or an ISM wireless link. The built-in modem is preferably a PCMCIA card for the laptop and is plugged into the backplane of the laptop. Using small omnidirectional antennas, they transmit and receive MAC frames over airlinks. The end system may also be a laptop with a directional antenna, a home fixed radio station with a directional antenna connected via an AC power line, and so on.
【0020】
Wide area radio coverage is provided by base station 36. Base station 36 can employ a 5-channel reusable communication scheme as described in US Patent Application No. 08 / 998,505 filed December 26, 1997. The range of coverage provided by base station 36 depends on factors such as link budget, capacity and coverage. Base stations are typically installed at cell sites by PCS (Personal Communications Services) wireless service providers. From each coverage area, the base station multiplexes the end system traffic to the system's mobile exchange center (MSC) 40 over a wired line or microwave backhaul network 38.
【0021】
The system is independent of the Airlink's MAC and PHY (physical) layer and modem type. Its architecture is also independent of the physical layer and backhaul network 38 topology. The only requirement for a backhaul network is that it must be able to forward Internet Protocol (IP) packets between the base station and the MSC with sufficient performance. At the Mobile Exchange Center 40 (MSC40), the Packet Data Interworking Function (IWF) 52 terminates the radio protocol for this network. IP router 42 connects MSC40 to public internet 44, private intranet 46 or internet service provider 46. Accounting and directory service 48 in MSC40 stores accounting data and directory information. Element management server 50 manages equipment including base stations, IWF and accounting / directory servers.
【0022】
The accounting server collects accounting data on behalf of the user and sends the data to the service provider's billing system. The interface supported by the accounting server is the TCP / IP (Transport Control Protocol / Internet Protocol) transport in the American Management Association (AMA) billing record format, or any other suitable billing format. Send accounting information to the billing system (not shown) above.
【0023】
The network infrastructure provides PPP (Point to Point Protocol) services to end systems. The network provides fixed wireless access by (1) roaming to the end system (logging in wherever its wireless coverage is available) and (2) slow mobility and handoff. Fixed services (ie, static services that do not require handoff services) or mobile services (ie, services that require handoff services) when the end system logs on to the network. Can be requested. An end system that does not specify fixed or mobile is considered to specify a mobile service. The actual registration of that end system is a negotiation with a home registration server based on the required level of service, the level of service requested by the user of that end system, and the facilities available in the network. Is the result of.
【0024】
If the end system negotiates a fixed service registration (ie, does not require a handoff service) and the end system is on the home network, then the IWF (Interworking Function) will be with the end user. With communication servers such as PPP servers (ie, points to be connected to, such as ISP PPP servers running by wireless service providers or corporate intranet PPP servers to provide customers with direct access to the public Internet). It is implemented in the base station to relay traffic between. Probably 80% of message traffic is expected to be in this category, so this architecture distributes IWF processing to base stations and avoids traffic congestion at the central mobile exchange center.
【0025】
If the end system requires mobile services (from your home network or foreign network), or if the end system requires roaming services (ie, services from your home network through the foreign network). Two IWFs are established. They are the servicing IWFs that are usually established at the base station of the network to which the end system is attached (either home or foreign networks), and usually the home network. It is a home IWF established in the mobile exchange center MSC. This situation is expected to require only about 20% of message traffic, so congestion of message traffic around the mobile exchange center is minimized. Serviced IWFs and wireless hubs can coexist on the same nested computer, or even be programmed to the same computer, so that tunnels using the X Tunnel protocol can coexist with wireless hubs and service IWFs. It does not have to be established during.
【0026】
However, based on the facilities available and the type and quality of service requested, the IWFs servicing in one foreign network can be selected instead from the facilities in the foreign MSC. In general, home IWF is an anchor point that does not change during a communication session, but serviced IWF can change if the end system moves large enough.
【0027】
A base station includes one access hub and at least one access point (whether it is remote or co-located with that access hub). Access hubs typically serve multiple access points. The end system can be attached to the access point by wire or cable as described in the present invention, but in one preferred embodiment the end system is attached to the access point by a wireless "air link". Added, in which case the access hub is conveniently referred to as a wireless hub. Access hubs are referred to as "wireless hubs" throughout this description, but end systems that are coupled through one access point to one access hub by wire or cable are equivalent implementations and "access. It should be understood that it is considered by the term "hub".
【0028】
In the present invention, the end system includes an end user registration agent (eg, software running on the computer of the end system, its modem, or both), which communicates with the access point, and Communicate to the wireless hub through its access point. A wireless hub includes a proxy registration agent (for example, software running on a processor in the wireless hub) that acts on behalf of the end user's registration agent. For example, the concept used in the IETF's proposed mobile IP standard is commonly referred to as a foreign agent (FA). For this reason, the proxy registration agent of the system of the present invention is called a foreign agent, and aspects of the foreign agent of the system of the present invention that differ from the foreign agent of mobile IP are described throughout the following description. Will be done.
【0029】
Using the proxy registration agent in the base station (ie, Foreign Agent FA), the end system user registration agent can discover additional points for that network, and the MSC (Movement) of that home network. It can be registered by the registration server in the exchange center). The home registration server determines the availability of each of the multiple interworking function modules (IWFs) in the network (actually, software modules running on the processor in both the MSC and the wireless hub). , Assign IWF to the registered end system. For each registered end system, one tunnel (using the XTunnel protocol) is between the wireless hub in the base station and the interworking function (IWF) in the mobile exchange center (MSC). Generated, this tunnel forwards PPP frames between the end system and IWF.
【0030】
As used here, the XTunnel protocol is a protocol that provides flow control for the in-sequence transfer of PPP data frames. This protocol can run on standard IP networks, point-to-point networks, or on exchange networks such as ATM data networks or Frame Relay data networks. Such networks can be based on T1 or T3 links, or can be based on wireless links, whether ground-based or space-based. The XTunnel protocol can be constructed by adapting algorithms from L2TP (Level 2 Transport Protocol). In networks based on links where data packet loss can occur, the ability to retransmit is a desirable option.
【0031】
The end system's PPP peers (ie, communication servers) can reside within IWF or on the corporate intranet or ISP's network. When the PPP peer is stationed at IWF, the end system is provided with direct internet access. When the PPP peer is stationed on the intranet or ISP, the end system is provided with intranet access or access to the ISP. To support intranet or ISP access, IWF uses Layer 2 Tunneling Protocol (L2TP) to connect to the intranet or ISP's PPP server. From the perspective of an intranet ISP's PPP server, IWF looks like a network access server (NAS). The PPP traffic between the end system and the IWF is relayed by a foreign agent inside the base station.
【0032】
In the opposite (uplink) direction, PPP frames forwarded from the end system to the IWF are sent to the base station over the MAC and airlinks. The base station uses the XTunnel protocol to relay these frames to the IWF in the MSC. IWF delivers them to the PPP server for processing. For internet access, the PPP server can be on the same machine as the IWF. For ISP or intranet access, the PPP server is on a private network, and IWF connects to it using Layer 2 Tunneling Protocol (L2TP).
【0033】
In the forward direction (downlink), PPP frames from the PPP server are relayed by IWF to the base station using the XTunnel protocol. The base station takes the downlink frames out of the tunnel and relays them over the airlink to the end system, where they are processed by the end system's PPP layer.
【0034】
Includes support for handoffs to support mobility. The MAC layer helps mobility management software in base stations and end systems perform handoffs efficiently. The handoff is processed unnoticed (transparently) by the peer's PPP entity and L2TP tunnel. When an end system moves from one base station to another, a new X Tunnel is created between the new base station and the original IWF. The previous X Tunnel from the previous base station is deleted. The PPP frame will transparently pass through the new route.
【0035】
The network supports roaming (ie, when the end user connects to their home wireless service provider through Foreign's wireless service provider). This feature allows an end system to roam to a foreign network away from its home network and still be serviced. However, of course, if the foreign radio service provider and the home radio service provider of the end system have a service contract.
【0036】
In Figure 3, the roaming end system 60 has come to the point where Foreign Radio Service Provider 62 is providing coverage. However, the ROHM End System 60 has a subscriber relationship with the home wireless service provider 70. In the present invention, the home wireless service provider 70 provides access services under a contractual relationship with Foreign wireless service provider 62. Therefore, the roaming end system 60 connects to base station 64 of Foreign wireless service provider 62 over the air link. At that time, the data is relayed from the roaming end system 60 through base station 64 to the home IWF72 of the home radio service provider 70 through the IWF66 serviced by the foreign radio service provider 62, or of the home. It can also be relayed to Internet service provider 74 through the home IWF72 of wireless service provider 70.
【0037】
An interface between service providers, called the I interface, is used for communication across the boundaries of the wireless service provider (WSP) to support roaming. This interface is used to authenticate, register, and forward end system PPP frames between the foreign WSP and the home WSP.
【0038】
Uplink and downlink PPP frames are forwarded through the home radio provider (WSP) of the end system. Instead, PPP frames are forwarded directly from the foreign WSP to the destination network. The base station in a foreign WSP is the point at which the end system is added in the foreign network. This base station sends PPP frames to the servicing IWF in Foreign WSP's mobile exchange center (and receives PPP frames from the servicing IWF in Foreign's WSP mobile exchange center). To do). The servicing IWF uses a Layer 2 tunnel to connect to the home IWF on the I interface to forward the end system's PPP frames in both directions. The IWF serviced within Foreign's WSP collects accounting data for auditing. The Home IWF within the Home WSP collects accounting data for billing. The serviced IWF in Foreign WSP can be combined with base stations in the same system, thereby eliminating the need for X Tunnel.
【0039】
During the registration phase, the registration server in Foreign's WSP knows the identity of the roaming end system's home network. Using this information, the foreign registration server communicates with the home registration server to authenticate and register its end system. These registration messages flow on the I interface. Once the end system is authenticated and registered, a Layer 2 tunnel is created between the base station and its servicing IWF using the XTUNNEL protocol, and another Layer 2 tunnel is created. Generated between the IWF servicing on the I interface and the home IWF. Home IWF uses L2TP (Level 2 Tunneling Protocol) to connect to the end system's PPP peers as before. During the handoff, the home IWF and L2TP tunnel locations remain fixed. As the end system moves from one base station to another, a new tunnel is created between the new base station and the IWF servicing, and the IWF servicing the previous base station. The previous tunnel between and is deleted. If the end system moves far enough and therefore requires a new servicing IWF, a new tunnel will be created between the new servicing IWF and the home IWF. The previous tunnel between the previous servicing IWF and the home IWF is deleted.
【0040】
To support roaming, the I interface supports authentication, registration and data transfer across the boundaries of wireless service providers. Authentication and registration services are supported using the IETF's Radius protocol. Data transfer services for transferring PPP frames over Layer 2 tunnels are supported using the I-X Tunnel protocol. This protocol is based on the IETF's L2TP protocol.
【0041】
As used in this description, home IWF refers to IWF within the home network of the end system. The term servicing IWF refers to IWF within a foreign network that is temporarily servicing an end system. Similarly, the term home registration server refers to a registration server in the home network of its end system, and the foreign registration server refers to a registration server in the foreign network through which the end system is roaming. Register with.
【0042】
The network supports both fixed and dynamic IP address assignments to the end system. There are two types of IP addresses that need to be considered. The first type is the identity of the end system within its home network. This can be a username structured in the format user @ domain. This is different from the home IP address used in Mobile IP. The second address is the IP address assigned to the end system via the PPP IPCP address negotiation process. The domain subfield of the home address is used to identify the user's home domain, which is a fully qualified domain name. The user subfield of that home address is used to identify the user within that home domain. The User-Name is stored on the end system and in the subscriber database at the MSC and is assigned to the user when he / she subscribes to the service. The domain subfield of the username is used during roaming to identify roaming relationships and home registration servers for registration and authentication purposes. Instead of a structured username, another unique identifier can be used to identify the user's home network and the user's identity within the home network. This identifier is sent by the end system in the registration request.
【0043】
PPP IPCP is used to negotiate IP addresses for end systems. The IP configuration protocol IPCP allows end systems to negotiate fixed or dynamic IP addresses.
【0044】
Using a structured username field as the home address and not using an IP address is a feature that characterizes the systems of the invention on known mobile IPs, but with respect to mobile IPs and PPP end systems. As its use becomes more common, the network can also be enhanced to support end systems that have no username and only non-null home addresses. The PPP server can be configured by the service provider to assign the same IP address as the home IP address of its end system during the IPCP address allocation phase. In this case, the home address and the IP address assigned by IPCP will be the same.
【0045】
In Figure 4, air links from base station 64 and the end system form a wireless subnetwork 80, which is the air link for end-user access, at least one base station (eg, base station 64). ) And at least one backhaul network from its base station to the MSC40 (Figure 2) (eg 38 in Figure 2). For example, the architecture of a three-sector base station radio subnetwork includes the following logical functions:
【0046】
1. Access point function. Access point 82 performs the steps of bridging the MAC layer and associating and disassociating the MAC layer. The access point is a single processor (preferably in the form of a custom application-specific integrated circuit (ASIC)), a link to a wireless hub (preferably an Ethernet link on the card or a form built into the ASIC), and a link to an antenna. Includes (preferably in the form of a card with a data modulator / demodulator and transmitter and receiver), and an antenna to which its end system is coupled. The processor performs software for bridging data and various other functions that support registration and mobility handovers as further described below. See the description of Figures 7, 8 and 11.
【0047】
Access points (APs) take MAC layer frames from air links, relay them to wireless hubs, and vice versa. The MAC tier associating and disassociating procedure is used by the AP, which maintains a list of end system MAC addresses in its respective address filter table. The AP simply bridges the MAC layer on behalf of the end system whose MAC address resides in that table. The access point and its associated wireless hub are usually located in the same location. In its simplest form, the access point is just one port to the wireless hub. When APs and wireless hubs coexist at the same cell site, they can be connected together via IEEE 802.3 links. Sometimes the access point is located away from the wireless hub and is connected via a wired T1 trunk line or, in some cases, a long-distance link such as a wireless trunk line. For multi-sector cells, multiple access points (ie, one per sector) are used.
【0048】
2. Wireless hub function. Radio hub 84 performs foreign agent (FA) procedures, backhaul load balancing (eg, on multiple T1s), backhaul network interfacing, and xtunnel procedures. When there is support for quality of service (QOS), the wireless hub provides support for QOS by running the xtunnel protocol on backhaul with different QOS attributes. At multi-sector cell sites, a single radio hub function is typically shared by multiple access points.
【0049】
A wireless hub is one processor, one link to one or more access points (preferably in the form of an Ethernet link on the card or built into the ASIC), and one link to a backhaul line. including. The backhaul line is usually a T1 or T3 communication line, which is terminated at the mobile exchange center of the wireless service provider. Links to backhaul lines format the data in a preferred format, such as Ethernet format, Frame Relay format, or ATM format. The wireless hub processor runs software to support data bridging and various other functions as described herein. See the description of FIGS. 9, 10 and 11.
【0050】
The base station design supports the following types of cell architectures: 1. Local AP architecture. In the local AP architecture, the range of access points is large (typically> = 2km). These access points coexist with the wireless hub at the cell site (Figure 4). The access point can be connected to the radio hub using an IEEE 802.3 network, or can be plugged directly into the backplane of the radio hub, or some other mechanism (eg, general purpose serial). You can connect to a wireless hub using a bus, printer port, infrared, etc.). It is assumed that the first option is used for the rest of this description. The cell site can be a shared or sector site by adding multiple access points and sector antennas to the radio hub.
【0051】
2. Remote AP architecture. In remote AP architectures, the range of access points is typically very small, typically with a radius of about 1 km. They are installed away from the wireless hub (indoor or outdoor). Linking remote access points to cell sites where radios are located is preferably the T1 or radio trunks. Wired backhaul or microwave links are typically used to connect to the IWF within the MSC from that cell site. When a radio trunk line is used between a remote AP and a radio hub, a multipurpose or sector radio is used for the trunk line. Devices for trunk connections to remote access points are preferably co-located with the wireless hub and either connected to it using an IEEE 802.3 network or directly to the backplane of that wireless hub. Can be plugged in. These devices are referred to by the term trunk AP.
【0052】
3. Mixed AP architecture. In a mixed architecture, wireless subnetworks will have to support remote and local access points. Remote access points may be added to fill in the blanks and for other capacity reasons. As explained earlier, a remote AP can be connected to a wireless hub using a T1 or wireless trunk line.
【0053】
Figure 5 shows a cell with three sectors using only local APs. Access points and radio hubs coexist in the base station and are connected to each other with an 802.3 link.
【0054】
Figure 6 shows the architecture with a remote access point 82 connected to the radio hub 84 using the radio trunk line 86. Each trunk access point in the base station provides a point-to-multipoint wireless radio link to a remote micro access point (R-AP in the figure). The remote access point provides Airlink services to the end system. Radio hubs and trunk access points coexist at the base station and are connected to each other via the 802.3 link. The figure also shows the 82R of a remote access point connected to a wireless hub via a point-to-point T1 link. No trunk AP is required in this scenario.
【0055】
To support all of the above cell architectures and the various types of access points that each cell may use, the network architecture follows these rules: 1. The access point acts as a bridge in the MAC layer. The remote access point performs MAC bridging between the air link to the end system and the radio or T1 trunk line to the cell site. The local access point performs MAC bridging between the air link to the end system and the wireless hub.
【0056】
2. The trunk access point also functions as a bridge in the MAC layer. They perform MAC bridging between the trunk line (which is connected to the access point) and the wireless hub. 3. The wireless hub is initially connected to all coexisting MAC bridges (ie local or trunk access points) using the 802.3 link. In addition, if a local or remote access point with a T1 trunk line is used, follow these rules:
【0057】
1. A local access point is located in the same location as the wireless hub and is connected to it using a point-to-point 802.3 link or a shared 802.3 network. The remote access point is connected to the wireless hub using a point-to-point T1 trunk line. 2. Sectorization is supported by adding access points with sector antennas to the cell site. 3. For each access point connected to the wireless hub, there is a foreign agent running within the wireless hub that participates in the end system registration. The MAC layer association procedure is used to keep the access point's MAC address filter table up-to-date and to efficiently perform MAC layer bridging. The wireless hub participates in the MAC association function so that only valid MAC addresses are added to the access point's MAC address filter table.
【0058】
4. The foreign agent in the wireless hub uses the xtunnel protocol to relay frames between the access point and the MAC's IWF. The MAC address filter table is used to filter out unicast MAC data frames whose MAC address does not exist in that table. The AP always forwards MAC broadcast frames and MAC frames associated with the end system registration function, regardless of the contents of the MAC address filter table. 5. The local access point uses ARP to resolve the MAC address for forwarding IP traffic to the wireless hub. Conversely, wireless hubs also use ARP to forward IP packets to access points. UDP / IP is used for network management of access points.
【0059】
6. Remote access points connected via T1 do not use ARP. That's because the link is a point-to-point link. 7. Support for handoffs is provided by support from the MAC layer. In cell architectures using wireless trunks and trunk APs, the following rules are observed:
【0060】
1. The trunk access point is located in the same location as the wireless hub and is connected to it using a point-to-point 802.3 link or other suitable means. 2. Radio trunk sectorization is supported by adding trunk access points with sector antennas to the cell site. 3. Handoffs across the backhaul sector are done using foreign agents in the wireless hub. For each backhaul sector, there is a foreign agent running inside the wireless hub.
【0061】
4. Trunk APs do not need to participate in MAC layer end system association and handoff procedures. Each MAC address filter table is dynamically programmed by the wireless hub as the end system registers with its network. The MAC address filter table is used to filter out MAC frames. Broadcast MAC frames or MAC frames containing registered packets are always allowed to pass. 5. The trunk AP uses ARP to resolve the MAC address for forwarding IP traffic to the wireless hub. Conversely, the wireless hub uses ARP to forward IP packets to the trunk AP. UDP / IP is used for network management of trunk APs.
【0062】
6. In a single radio trunk sector, MAC association and handoff from one access point to another is done using the MAC layer with the help of foreign agents in the radio hub. Using these MAC layer procedures, the end system is associated with the access point. As the end system moves from one access point to another, it uses the MAC handoff protocol to update its MAC address filter table. The wireless hub at that cell site provides access points to assist in performing this function. This assistance is for relaying MAC layer handoff messages (because access points cannot communicate directly with each other on the MAC layer) and for MAC layer registration and handoff, and for that access point. Includes end system authentication for updating the MAC address filter table.
【0063】
7. Foreign agents for the radio trunk sector are responsible for relaying frames between trunk APs and MSCs using the xtunnel protocol. Therefore, the foreign agent for the trunk AP is irrelevant for the location of the end system with respect to the access point within its radio trunk sector. In the downlink direction, it is a suitable trunk line that uses MAC layer bridging to send frames from that tunnel to all remote access points attached to its backhaul sector. It just forwards the frame to the AP. The access point refers to its respective MAC address filter table and either forwards the MAC frame over the access network or drops the MAC frame. As mentioned above, the MAC address filter table is kept up to date using MAC layer association and handoff procedures. In the uplink direction, MAC frames are forwarded by the access point to the backhaul bridge, which forwards them to the foreign agent in the wireless hub using the 802.3 link. To do.
【0064】
8. ARP is not used to send or receive IP packets to remote access points. The access point uses the BOOTP procedure to determine the MAC address of the wireless hub. Conversely, a wireless hub consists of the MAC address of a remote access point. UDP / IP is used for network management of access points and for end system association and handoff messages.
【0065】
IEEE standard 802.3 links at cell sites can be replaced by links of other speeds. Figure 7 shows the protocol stack for local access points. At the base of the stack is the physical layer PHY. The physical layer PHY, for example, uses radio waves to carry data to and from the end system in the air. When received from the end system, the AP receives data from the physical layer and unpacks it from the MAC frame (MAC layer). The end system data frames are then repacked into the Ethernet physical layer format (IEEE 802.3 format) and sent over the Ethernet link to the wireless hub. When the AP's processor receives data from the wireless hub via its Ethernet link, the physical layer, the data is sent to the end system and the AP packs the data into medium access control (MAC) format. , The data in the MAC layer is transmitted to the modulator as it is transmitted to the end system using the physical layer.
【0066】
In FIG. 8, the MAC and PHY layers to and from the end system of FIG. 7 are replaced by MAC and PHY for trunk lines to cell sites for remote access points. Specifically, for T1 trunk lines, it is preferred that a higher level data link control protocol (HDLC protocol) be used on T1.
【0067】
Figure 9 shows the protocol stack for a wireless hub that bridges a backhaul line to a trunk line to a remote access point. A trunk line to a remote AP is only needed to support remote access points (unlike access points connected to Ethernet). The MAC and PHY layers for wireless trunks to remote APs provide point-to-multipoint links, allowing one trunk line to be used to communicate with many remote APs in the same sector. ..
【0068】
The wireless hub bridges trunk lines to remote APs and backhaul lines (eg, T1 or T3) to the mobile exchange center (MSC) of the network. The protocol stack in the wireless hub implements the MAC and PHY layers for MSC, the top of which is the IP (Internet Protocol) layer, and the top of the IP layer is for network management. The UDP layer (Universal Datagram Protocol, combined with UDP / IP) is implemented, and the XTunnel protocol is implemented at the top of the UDP layer. The XTunnel protocol is a new format protocol, which includes aspects of mobility (eg, in mobile IP) and Level 2 Tunneling Protocol (L2TP). The XTunnel protocol is used to communicate from wireless hubs to MSCs and between different networks or interworking features (IWFs) within the same network.
【0069】
Figure 10 shows the protocol stack for the relay function at the base station to support remote access points. The relay function includes an interface to the backhaul line (shown as a wireless hub) and an interface to a remote AP (shown as a trunk AP). From the point of view of the wireless hub, the trunk AP (shown in Figures 7 and 10) actually behaves like the AP shown in Figure 7. The base station protocol stack is preferably divided into a radio hub and a trunk AP with Ethernet in between. In the N sector radio trunk line, there are N radio trunk line APs and one radio hub in the cell site.
【0070】
Figure 11 shows the base station protocol stack for cell architectures using local APs. The relay function includes an interface to the backhaul line (shown as a wireless hub) and an air link interface to the end system (shown as an AP). From the point of view of the wireless hub, the AP (shown in Figures 8 and 11) actually behaves like the trunk AP shown in Figure 8. The base station's protocol stack is divided into a wireless hub and a trunk AP over Ethernet between them. Within the N sector cell, there are N access points and a single radio hub.
【0071】
The backhaul network from the base station to the MSC has the following attributes: 1. The network can forward IP datagrams between the base station and the MSC. 2. The network is secure. It's not the public internet. Only traffic from trusted nodes is allowed on the network. This is because the network is used not only for forwarding end-system traffic, but also for authentication forwarding, accounting, registration and management traffic. 3. The network has the required performance characteristics. In a typical application, the service provider is responsible for installing and maintaining the backhaul network on which the equipment is installed. The base station supports the following backhaul interfaces to communicate with the MSC.
【0072】
1. The base station supports IP over PPP with HDLC using point-to-point T1 or fragmented T3 links. 2. The base station supports IP over Frame Relay using T1 or fragmented T3 links. 3. The base station supports IP on AAL5 / ATM using T1 or fragmented T3 links.
【0073】
4. The base station supports IP over the Ethernet link. Since all of the above interfaces are based on IETF standard encapsulation, commercial routers can be used within the MSC to terminate the physical links of the backhaul network. It is passed to the upper layers by various servers and other processors for processing. End system registration procedures on the MAC layer are supported. In the following, end system registration procedures at the MAC layer are ignored unless they affect the layers above it.
【0074】
End systems can register for services on their respective home networks or from foreign networks. In both scenarios, the end system uses a foreign agent (FA) in its base station to discover and register additional points for its network. In the former case, the FA is in the home network of its end system. In the latter case, the FA is in the foreign network. In either case, the network uses the IWF in the end system's home network as an anchor point (that is, it is immutable throughout the session, ignoring mobility). PPP frames to and from the end system are forwarded to the IWF in the home network via the FA in that base station. If the end system is at home, its home IWF is directly connected by means of the xtunnel protocol to its base station. Note that home IWF can be combined with base stations within the same node. If the end system is roaming, the servicing IWF in the foreign network is connected to the home IWF on the I interface. The serviced IWF relays frames between the base station and the home IWF. Note that home IWF can be combined with base stations within the same node. Data is sent from the home IWF to a PPP server that can reside within the same IWF, or to another server that uses the L2TP protocol. The other server may be owned and operated by a private network operator (eg, an ISP or corporate intranet) that is different from the wireless service provider. The home IWF and PPP server locations remain fixed for the duration of the session. If the end system moves while connected It will have to re-register with the new foreign agent. However, the same home IWF and PPP servers will continue to be used. A new xtunnel is created between the new FA and IWF, and the xtunnel between the previous foreign agent and its IWF is destroyed.
【0075】
Figure 12 shows this network configuration for two end systems A and B. Both of them have their home wireless network as a wireless service provider A (WSP-A). One end system is registered from the home radio network, and the other end system is registered from the foreign radio network. The home IWF in WSP-A acts as an anchor point for both end systems. For both end systems, data is relayed to the home IWF, which is connected to the PPP server of the Internet service provider owned by ISP-A. It is now assumed that both end systems are subscribed to the same ISP. If not, the home IWF is also indicated to connect to another ISP.
【0076】
Within the wireless service provider's network, data between the base station and IWF is carried using the xtunnel protocol. Data between the IWF and the PPP server is transported using the Level 2 Tunneling Protocol (L2TP). Data between the serviced IWF and the home IWF is carried using the I-x tunnel protocol.
【0077】
In a simple scenario, the Home IWF functionality can be dynamically activated at the base station for users in each home network requesting fixed services. In addition, the function of the serviced IWF can be activated for the user who is roaming in the base station. There are advantages and disadvantages to always using one IWF in your home network. One obvious advantage is simplicity. One drawback is that data must always be relayed to and from the remote home IWF. The alternative is to send all the necessary information to the serving IWF, allowing it to connect to the ISP / intranet of the end system, and providing accounting information to the serving IWF in near real time. It can be sent back to the accounting server in the home network. This feature is relatively complex to implement, but efficient. This reduces the need to relay data over potentially long distances from foreign networks to home networks.
【0078】
For example, consider the case of a user roaming from Chicago to Hong Kong. If the user's home network is in Chicago and the user registers with a wireless service provider in Hong Kong, in the first configuration the anchor point will be the home IWF in Chicago, and all the data will be It will have to be relayed from Hong Kong to Chicago and vice versa. Home IWF in Chicago connects to your ISP in Chicago. In the second configuration, users of the end system are assigned an ISP located in Hong Kong. Therefore, the data does not necessarily have to be relayed back and forth between Chicago and Hong Kong. In this second configuration, the servicing IWF acts as an anchor and never changes during the session as the end system moves. However, the location of FAs can change as a result of the movement of end systems in Hong Kong.
【0079】
FIG. 13 shows the second network configuration. In this figure, the home network of end systems A and B is WSP-A. End system A uses its home IWF as an anchor point to register from its home network and also uses the ISP's PPP server to connect to that ISP-A. End system B uses IWF registered and serviced from WSP-B's foreign network. The IWF acts as an anchor point and connects the end system to the ISP using the ISP's PPP server. In this configuration, the data for end system B need not be relayed from the foreign network to the home network and vice versa.
【0080】
Not only must there be a roaming contract between the home and the foreign wireless service provider for this configuration to work properly, but the foreign wireless service provider and the end system's internet service provider as well. There must also be a contract with or through an intermediary. In the above example, not only must the wireless service provider in Hong Kong have a business contract with the wireless service provider in Chicago, but the WSP in Hong Kong also has a business contract with its user's Chicago ISP. Must, and must access the PPP server of Chicago's ISP in Hong Kong, or do business with another local ISP in Hong Kong that has a business contract with the user's Chicago ISP for roaming. You must have a contract. In addition, the WSP in Hong Kong must be able to dynamically discover these roaming relationships in order to authenticate and account for users and to set up appropriate tunnels.
【0081】
For companies entering the Internet infrastructure business, it is difficult to properly apply the appropriate IETF standards for all of these scenarios. Therefore, one preferred embodiment for the systems of the invention is to implement a simpler, potentially less efficient configuration in which the IWF in the home network is always used as the anchor point. However, in the presence of suitable industry standard protocols for Internet roaming, the second configuration should be considered an equivalent or alternative embodiment.
【0082】
The end system will have to register with the wireless network before it can start PPP and send and receive data. The end system first goes through the FA discovery and registration phase. These phases authenticate and register the end system with the wireless service provider. At the end of these phases, the end system initiates PPP. This includes the PPP link establishment phase, the PPP authentication phase and the PPP network control protocol phase. At the end of these phases, the end system can use PPP to send and receive IP packets.
【0083】
The following description assumes that the end system is roaming and registering from the foreign network. During the FA discovery phase, the end system waits for or requests a notice from the foreign agent (through its user negotiation agent). The user registration agent discovers and registers the FA's identity using a publicity message sent by a nearby foreign agent. During this phase, the end system user registration agent selects one FA and issues a registration request to it. The FA operating as a proxy registration agent forwards the registration request to the registration server (registration server in Foreign WSP). The registration server uses the username from the user's registration agent request to know the home network of its end system and forwards the registration request to the registration server in the home network for authentication. Upon receiving the registration request relayed by the foreign registration server, the home registration server authenticates the identity of the foreign registration server and also the identity of its end system. If authentication and registration is successful, the home registration server selects one IWF in the home network and links the I-x tunnel between the home IWF and the serviced IWF (in the Foreign WSP). To generate. The IWF in the home network acts as an anchor point throughout the PPP session.
【0084】
After the authentication and registration phases, various PPP phases are started. At the start of PPP, one L2TP connection is created between the home IWF and the requested ISP / Intranet PPP server. During the PPP authentication phase, PPP passwords are exchanged using Password Authentication Protocol (PAP) or Challenge Authentication Protocol (CHAP), and the ISP or intranet PPP server independently authenticates the identity of its end system. To do.
【0085】
If this is successful, the PPP network control phase begins. During this phase, the IP address is negotiated, assigned to the end system by the PPP server, and the TCP / IP header compression specification is also negotiated. Once this is done, the end system can use PPP to send and receive IP packets to and from the ISP or corporate intranet.
【0086】
Note that two levels of authentication are performed here. The first authentication authenticates the identity of the end system to the registration server in the home network, and authenticates the mutual identity of the foreign network and the home network. To perform this function, the foreign agent, for example, in a Radius access request packet, makes an end system registration request to the registration server in its local MSC using the IETF's Radius protocol. Forward. Using the domain name of the end system, the foreign registration server knows the identity of the end system's home network and home registration server, and acts as a proxy for Radius, making the request to that end system's home registration server. Encapsulate and transfer to. If the foreign registration server fails to know the home identity of its end system, it optionally requests Radius, like one broker (for example, owned by a consortium of wireless service providers). It forwards to a registration server that works on, and that registration server can in turn delegate access requests for that Radius to the final home registration server. If the local registration server is unable to serve the registration request locally or on behalf of it, it rejects the foreign agent's registration request, which rejects the end system's registration request. Upon receiving a Radius access request, the home registration server performs the required authentication of its foreign network and end system identities. If the authentication and registration is successful, the home registration server responds to the foreign registration server with a Radius access response packet, and the foreign registration server sends a response to the foreign agent to complete the migration. Can be done. If the home registration server cannot be met for some reason, the registration request will be rejected.
【0087】
The second level of authentication verifies the identity of the end system to the intranet or ISP PPP server. PPP authentication, apart from mobility authentication, allows infrastructure equipment to be deployed and owned separately by the ISP.
【0088】
Figure 14 is a ladder diagram showing the sequence of registrations for the roaming end system. It is assumed that the PPP server and home IWF are in the same server and L2TP is not needed. Note the interaction by having the accounting server initiate accounting on behalf of the registered end system, the directory server knowing the identity of the home registration server, and authenticating the identity of the end system. Details regarding accounting, billing, roaming (between service providers) and clearing are provided below.
【0089】
Agent requests can be invoked using MAC tier messages from end-system user registration agents. For simplicity, MAC layer messages are not shown.
【0090】
In Figure 14, the end system (mobile) first requests a report, and the foreign agent ends information about the network to which the foreign agent belongs, including the care of address of the foreign agent. Respond by public notice provided to the system. Alternatively, this phase can be removed, and all network announcements can be made by constantly outgoing MAC layer beacon messages. In this case, the network is assumed to be a foreign radio service provider. The user registration agent (in the end system) then incorporates information about the foreign agent (including username and other security credential) and information about its network into a single request. Send the request to the foreign agent. The foreign agent, as a proxy registration agent, relays the request to the foreign registration server (ie, the registration server for the foreign radio service provider). The foreign registration server then recognizes that it is not in the home directory and accesses the foreign directory server by FDD in the foreign wireless service provider, and the end system makes the registration request. Know how to direct to the home registration server of your wireless service provider. The foreign registration server responds with the required forwarding information. The foreign registration server then encapsulates the registration request for the end system in a Radius access request, and the encapsulated request is the home registration server of the wireless service provider to which the end system belongs. Relay to. The home registration server accesses the home directory server through the HDD of the home registration server and knows at least the authentication information about the foreign service provider. To. Optionally, the home registration server accesses the subscriber's directory for detailed subscriber service profile information (for example, the quality option of the service you are subscribed to). Once all parties are authenticated, the home registration server sends an IWF start request to the home IWF and PPP servers. The home IWF and PPP servers start the home accounting server and send an IWF start response to the home registration server. The home registration server then sends the Radius access response to the foreign registration server. The foreign registration server then sends an IWF start request to the serving IWF server. The servicing IWF server starts the servicing accounting server and then sends the IWF start response to the foreign registration server. The foreign registration server sends a registration response to the foreign agent, which relays the registration response to the end system.
【0091】
A link control protocol (LCP) configuration request is sent by the end system through the foreign registration server to the home IWF and PPP servers. The home IWF and PPP servers send LCP configuration knowledge to the end system through the foreign registration server.
【0092】
Similarly, a Password Authentication Protocol (PAP) authentication request is sent and acknowledged by the home IWF and PPP servers. Alternatively, it can be authenticated using the Challenge Authentication Protocol (CHAP). Both protocols can be used to authenticate. Alternatively, this phase may be skipped. Similarly, IP Configuration Protocol (IPCP) configuration requests are sent to and acknowledged by the home IWF and PPP servers. Connections to the end system may be terminated for one of the following reasons:
【0093】
1. User activation termination. In this scenario, the end system first terminates PPP in order. This includes the termination of the PPP Network Control Protocol (IPCP) followed by the PPP link protocol. When this is done, the end system unregisters from the network and then terminates the wireless link to the access point. 2. Loss of wireless link. This scenario is detected by the modem and reported to the modem driver in the end system. The top layer of this software is notified to terminate the stack and notify the user. 3. Lost connection to foreign agent. This scenario is detected by the mobility driver in the end system. After an attempt to reestablish contact with a foreign agent (which may be new) fails, the driver sends an appropriate notification on the protocol stack and also signals to terminate the radio link. Send a signal to the hardware of the lower modem.
【0094】
4. Lost connection to IWF. This is virtually the same as the loss of a connection to a foreign agent. 5. PPP termination by IWF or PPP server. This scenario is detected by the PPP server in the end system. The end system PPP driver is notified of this event. It initiates deregistration from the network, followed by termination of the radio link to the access point.
【0095】
End system service configuration refers to the concept of configuring network services for an end system based on its subscriber's service profile. The subscriber's service profile is stored in the subscriber directory. The service profile contains information that allows the software to customize wireless data services on its behalf. It contains information to authenticate the end system, which allows the end system to roam and set up a connection to the end system's Internet service provider. This information also preferably includes other parameters, such as quality of service. In addition to the subscriber directory, the home domain directory (HDD) and foreign domain directory (FDD) are used for roaming and for authenticating foreign and home registration servers with each other. The HDD stores information about the end system's home network, and the FDD stores information about foreign networks that subscribers may visit.
【0096】
Figure 15 shows how these directories map to the network architecture and are used during registration for the end system that is registering at home. In step 0, the end system (mobile) requests and receives a public announcement from the foreign agent that provides the end system with information about the network to which the foreign agent belongs. In this case, the network is the home wireless service provider. In step 1, the user registration agent (in the end system) incorporates information about the foreign agent and its network and its security credential into the request and submits the request to the foreign agent. Send. In step 2, the foreign agent, as a proxy registration agent, relays the request to the home registration server. In step 3, the home registration server accesses the home wireless service provider's HDD to know at least the credentials. In step 4, the home registration server accesses the subscriber directory for detailed subscriber service profile information (for example, quality options for subscribed services). In step 5, the home registration server notifies the foreign agent of its access response. In steps 6 and 7, the foreign agent notifies the end system (ie, mobile) of the registration response.
【0097】
Figure 16 shows how directories are used for end systems that are registering from the foreign network. In step 0, the end system (mobile) requests and receives the announcement, and the foreign agent generates a notification that provides the end system with information about the network to which the foreign agent belongs. In this case, the network is Foreign's wireless service provider. In step 1, the user registration agent (in the end system) incorporates the foreign agent and its network and its security credential into the request and sends the request to the foreign agent. In step 2, the foreign agent, as a proxy registration agent, relays the request to the foreign registration server (ie, the registration server for the foreign radio service provider). In step 3, the foreign registration server accesses the foreign wireless service provider's HDD and learns about the network to which the end system belongs. In step 4, the foreign registration server forwards the end system request to the home registration server of the home radio service provider of that end system. In step 5, the home registration server accesses the home registration server's FDD to know at least credentials for its foreign service provider. In step 6, the home registration server accesses the subscriber's directory for detailed subscriber service profile information (for example, the quality option of the subscribed service). In step 7, the home registration server notifies the foreign registration server of its access response. In step 8, the foreign registration server forwards its access response to the foreign agent. In step 9, the foreign agent responds to its registration.
【0098】
The protocol processing scenario processes bearer data and the associated stack for transporting bearer data to and from the end system. The protocol stack for the cell architecture uses local APs (Figure 17) and remote APs (Figure 18).
【0099】
Figure 17 shows the protocol stack for handling communication between the end system (in its home network) and the home IWF for the end system at home. Figure 17 shows the protocol processing for the cell architecture when the access point and radio hub are co-located.
【0100】
Figure 18 shows the protocol processing for the cell architecture when the access point is far away from the wireless hub. As shown in the figure, PPP is terminated at IWF and its configuration provides direct internet access. The configuration when the PPP server is separated from IWF will be described later.
【0101】
In Figure 18, the PPP frame from the end system is encapsulated within an RLP (Radio Link Protocol) frame, which is physically placed near the trunk access point (ie, its radio hub). The remote access point is encapsulated in a MAC frame to communicate with the access point), and the remote access point is attached to the access point, for example, by a radio trunk line. The access point acts as a bridge in the MAC layer, relaying frames from the air link to foreign agents in the radio hub. The foreign agent decapsulates the RLP frame from the MAC frame and uses the xtunnel protocol to relay the RLP frame to the IWF. Similarly, vice versa, there is a process for sending frames from IWF to the end system.
【0102】
If the end system moves to another foreign agent, a new xtunnel will be automatically generated between the new foreign agent and the IWF to ensure that PPP traffic continues to flow between them uninterrupted. .. In a remote AP cell architecture using a wireless trunk line between a remote AP and a trunk AP (Figure 18), the air link between the end system and the access point is the trunk frequency (f2). It operates at a different frequency (f1) and can use different wireless technologies.
【0103】
Figure 19 shows the protocol stack for the roaming end system. The servicing IWF uses the I-x tunnel protocol between the servicing IWF and the home IWF. The rest of the protocol stack remains unchanged and is not shown in the figure. This architecture can be simplified by merging the serving IWF into the base station, thereby eliminating the XWD protocol.
【0104】
The RLP layer uses sequence numbers to drop duplicate PPP datagrams and provide in-sequence delivery of PPP datagrams between the end system and IWF. It also provides a configurable keep-alive mechanism for monitoring the connectivity of the link between the end system and the IWF. In addition, in other embodiments, the RLP layer also provides retransmission and flow control services to reduce the overall bit error rate of the link between the end system and the IWF. The RLP between the end system and the IWF started at the beginning of the session and remains active during the handoff throughout the session.
【0105】
In contrast to the specifications in the mobile IP RFC (RFC 2003), IP in IP encapsulation is not used for tunneling between foreign agents and home IWF. Instead, a new tunneling protocol implemented at the top of UDP will be used. This tunneling protocol is a simplified version of the L2TP protocol. The reason for this selection is as follows.
【0106】
1. The encapsulation protocol specified in RFC 2003 does not provide packet flow control or in-sequence delivery. The networks currently described may require these services in tunnels on the backhaul. The amount of retransmissions on the air link due to packet loss due to flow control issues on the network between the base station and the MSC, or due to flow control issues at the base station or IWF. Flow control may be required to reduce. 2. By using the UDP-based tunneling protocol, it can be implemented at the user level, after which it can be debugged and then put into the kernel for performance reasons.
【0107】
3. There is no easy way to create a tunnel using RFC 2003, taking into account quality of service and load balancing. In order to take into account QoS, you must be able to set up the tunnel on a link that already provides the required QoS. Second, there is no easy way to use RFC 2003 to provide load balancing to balance the load of carrier traffic over multiple links between base stations and MSCs. 4. In order to implement IP in IP encapsulation as specified in RFC 2003, the developer needs access to the IP source code. In commercial operating systems, the source code for the TCP / IP stack is generally owned by other equipment manufacturers. Purchasing a TCP / IP stack from a vendor and making changes to the IP layer to support mobile IP tunneling requires developers to continue to support different versions of the TCP / IP stack. Become. This increases costs and risks.
【0108】
It should be noted that the tunneling protocol between the base station and the IWF is non-standard, and wireless service providers cannot mix and match devices from different vendors, but a single wireless service. The use of non-standard tunneling protocols within the provider network is transparent to equipment from end systems and other vendors. The new tunneling protocol is based on L2TP. As such, L2TP is a heavyweight tunneling protocol, and L2TP has a lot of overhead associated with tunneling and authentication. The overhead of the new tunneling protocol of the system of the present invention is low. This new xtunnel protocol has the following features:
【0109】
1. xtunnel generation adds vendor-specific extensions to Radius access requests and Radius access response messages between the base station and the registration server. These extensions are for negotiating tunnel parameters and creating tunnels. 2. Registered servers can perform the actual work of tunneling and relaying packets to different IP addresses and therefore to different servers in the MSC. This allows the registration server to load balance across multiple IWF servers and provide different QoS for different users.
【0110】
3. The xtunnel protocol supports in-band control messages for tunnel management. These messages include an echo request / response to test tunnel connectivity, a disconnect request / response / notification to disconnect the tunnel, and an error notification to notify an error. These messages are sent over tunneling media, such as UDP / IP. 4. The xtunnel protocol sends payload data over tunneling media, such as UDP / IP. The xtunnel protocol supports flow control and in-sequence packet delivery.
【0111】
5. The xtunnel protocol can be implemented on media other than UDP / IP for quality of service. The network terminates PPP in the home IWF and supports direct Internet connectivity by forwarding IP packets from the IWF to the Internet via routers using standard IP routing techniques. The IWF preferably runs the Information Routing Process (RIP), and the router also preferably runs the RIP and, in some cases, other possible routing protocols such as Open Shortest Path First (OSPF). ..
【0112】
This network supports the first configuration for wireless service providers, who are also Internet service providers. In this configuration, it acts as a PPP server for the home IWF in the MSC. The IWF also runs Internet routing protocols such as RIP and uses routers to connect to the backbone network of Internet service providers.
【0113】
This network is either because the wireless service provider (WSP) itself is not an ISP, or because the WSP has a contract with another ISP to provide access to end users. Supports a second configuration for wireless service providers who want to allow their end system to connect to one or more Internet service providers. For example, a wireless service provider can choose to provide network access to end users, and has an account with a third-party ISP to access the ISP from that WSP network. You can contract with a third-party ISP to allow your users. In this configuration, the PPP server does not run inside the home IWF installed on the MSC. Instead, a tunneling protocol, such as L2TP (Layer 2 Tunneling Protocol), is used to tunnel back to the ISP's PPP server. Figure 10 shows the protocol stack for this configuration for the home end system. The location of the home IWF and ISP's PPP server remains fixed throughout the PPP session. Also, the L2TP tunnel between IWF and its ISP's PPP server remains intact throughout the PPP session. The physical link between the IWP and the PPP server goes through one router using a dedicated T1 or T3 or Frame Relay or ATM network. The actual nature of the physical link is not important from an architectural point of view.
【0114】
This configuration also supports intranet access. For intranet access, the PPP server resides within the corporate intranet, and the home IWF tunnels to it using L2TP. For a fixed end system, the protocol processing for intranet or ISP access is shown in Figure 20, which uses the IWF serviced by the roaming end system to make its home IWF. It is different to connect to. Protocol processing between the servicing IWF and the home IWF has been described earlier. In Figure 20, the home IWF can be merged into a wireless hub, eliminating the XTunnel protocol. You can also merge the serving IWF into a wireless hub, thereby eliminating the XTunnel protocol.
【0115】
Figure 21 shows the protocol stack used during the registration phase (end system registration) for the local AP cell architecture. The stack for the remote AP cell architecture is very similar. The scenario shown above is for a roaming end system. For home-based end systems, there is no foreign registration server in the registration path. Note the mobility agents in the end system. Mobility agents in end systems and foreign agents in wireless hubs are conceptually similar to Mobile IP RFC 2002. Mobility agents use timeouts and retries to handle network errors. Unlike known protocol stacks for bearer data, RLP is not used. Foreign agents and registration servers use Radius over UDP / IP to communicate with each other to register end systems.
【0116】
Several aspects of security must be considered. The first is to authenticate the identity of the end system and foreign / home networks during the wireless registration phase. The second is to authenticate the identity of the end system by the PPP server during the PPP authentication phase. Third is authentication for storing accounting data, for billing, and for updating home domain information. Fourth is bearer traffic encryption transferred to and from the end system. Fifth is encryption for the exchange of billing information across service provider boundaries. A shared secret key is used to authenticate the identity of each home network of the end system and of each other during wireless registration of the home and foreign networks.
【0117】
End system authentication uses a 128-bit shared secret key to generate an authentication directive for its registration request. The authentication directive is generated using a known MD5 message digest algorithm as described in Mobile IP RFC 2002. Alternatively, different algorithms can be used. The shared secret key is not sent in the registration request by the end system. Only authentication directives are sent. Upon receiving the registration request from the end system, the home registration server recalculates the authentication directive on the registration request data using the shared secret key. If the calculated value of the authentication indicator matches the value of the authentication indicator sent by the end system, the home registration server allows the registration process to proceed. If the values do not match, the home registration server logs the event and raises a security breach alert and NAK (ie, the specified acknowledgement) for the request.
【0118】
In the registration response, the home registration server does the same. That is, it uses the shared secret key to generate an authentication directive for the registration response to be sent to the end system. Upon receiving the response, the end system recalculates its authentication directive using the shared secret key. If that value does not match the value of the authentication directive sent by the home registration server in the response, the end system discards the response and retries.
【0119】
These network security concepts are Mobile IP RFCs Similar to the concept defined in 2002. According to the RFC, a mobility security association exists between each end system and its home network. The security association for each mobility defines a collection of security contexts. Each security context defines an authentication algorithm, mode, secret key (shared or public-private), replay protection style and type of cipher to use. In the context of the network of the present invention, the username of the end system (instead of the mobile IP home address) identifies the security association of mobility between the end system and its home network. Used for. Another parameter, called the Security Parameter Index (SPI), is used to select the security context within the security association of mobility. In a basic embodiment of the invention, a default mobile IP authentication algorithm (MD5 with key) and a default mode ("prefix + suffix") are supported by a 128-bit shared secret key. Network users are allowed to define multiple shared secret keys with their home networks. To generate a security context for the end system, to assign an SPI to each security context, to set the content of the security context (including the shared secret key), and to modify each content The mechanism for doing so is described below. Upon registration, a 128-bit message digest is calculated by the end system in prefix + suffix mode using the MD5 algorithm. The shared secret key is used as a prefix and suffix to the data to be protected in the registration request. The authentication directive calculated in this way , SPI and sent by the end system in the registration request along with the username. Upon receiving the end system registration request, the foreign reservation server, along with its authentication directive and SPI, relays the request unchanged to the home registration server. Upon receiving the registration request directly from the end system or indirectly via the foreign registration server, the home registration server uses its SPI and username to select its security context. The home server uses the shared secret key to recalculate its authentication directive. If the calculated value of the authenticator matches the value of the authenticator sent by the end system in the request, then the user's identity has been successfully authenticated. Otherwise, the home registration server returns a nak (negative acknowledgment) for the registration request sent by the end system.
【0120】
The registration response sent by the home registration server to the end system is also authenticated using the above algorithm. The SPI and calculated authentication directive values are sent by the home server to the end system in the registration response message. Upon receiving the response, the end system recalculates the authentication directive, and if the calculated value does not match the sent value, discards the response and retries.
【0121】
A user's end system must consist of a shared secret key and SPI for all security contexts that the user shares with his registration server. This configuration information is preferably stored in the Win 95 registry for Windows 95-based end systems. During registration, this information is accessed and used for authentication purposes. In the network, the Radius protocol is used by the foreign agent FA to register the end system and to configure the xtunnel between the wireless hub and the home and servicing IWF on behalf of the end system. It is said. Upon receiving a registration request from the end system, the FA generates a Radius access request packet, stores its own attributes in that packet, and copies the end system's registration request attributes unchanged into this packet. , Send the combined request to the registration server in the MSC.
【0122】
Radius authentication requires the Radius client (in this case, the FA in the base station) and the Radius server (in this case, the registration server in the MSC) to share a secret key for authentication purposes. To do. This shared secret key is also used to encrypt all private information communicated between the Radius client and the Radius server. The secret key to that sharing is a configurable parameter. The network follows the recommendations in the RADIUS RFC and uses the shared secret key and MD5 algorithm wherever encryption is required, for authentication and for encryption. The Radius access request packet sent by the FA contains the Radius username attribute (provided by the end system) and the Radius user password attribute. The value of the user password attribute is also a configurable value and is encrypted in the manner recommended by the Radius protocol. Other network-specific attributes, which are non-standard attributes from the perspective of the Radius RFC standard, are encoded as vendor-specific Radius attributes and sent in the access request packet.
【0123】
The following attributes are sent by the FA to its registration server in a Radius access request packet. 1. Username attribute: This is the end system username provided by the end system in the end system registration request. 2. User Password Attribute: This user password is provided by the base station / wireless hub on behalf of the user. It is encoded as described in the Radius EFC, using a secret key shared between the base station and its registration server. 3. NAS port: This is the port at the base station. 4. NAS-IP address: This is the IP address of the base station.
【0124】
5. Service type: This is a framed service. 6. Framed protocol: This is the PPP protocol. 7. Xtunnel protocol parameters: These parameters are the parameters sent by the base station to specify the parameters needed to set up the XTunnel protocol on behalf of the end system. 8. AP-IP Address: This is the IP address of the AP that the user has registered through it. This is a vendor-specific attribute. 9. AP-MAC Address: This is the MAC address of the AP that the user has registered through it. This is a vendor-specific attribute. 10. End system registration request: The registration request from the end system remains unchanged and is copied to this vendor-specific attribute. The following attributes are sent from the registration server to the FA in the Radius access request packet.
【0125】
1. Service type: This is a frame type service. 2. Framed protocol: This is PPP. 3. XTunnel protocol parameters: These parameters are sent by the registration server to specify the parameters needed to set up the xtunnel protocol on behalf of the end system. This is a vendor-specific attribute. 4. Home registration server registration response: This attribute is sent to the FA from the home registration server. The FA relays this attribute unchanged to the end system in the registration response packet. If there is a foreign registration server in the path, this attribute is thereby relayed unchanged by the FA. It is encoded as a vendor-specific attribute.
【0126】
To provide services for end system roaming, foreign and home networks are authenticated to each other for accounting and billing purposes using the Radius protocol for authentication and configuration. This authentication is performed at the time of end system registration. As previously explained, when a registration server in a foreign network receives a registration request from the end system (encapsulated by the FA as a vendor-specific attribute in a Radius access request packet), It knows the identity of the home registration server of the end system by referencing the home domain directory HDD using the username of the end system. The following information is stored in the home domain directory HDD and is accessed by the foreign registration server to forward end system registration requests.
【0127】
1. Home registration address IP address: This is the IP address of the home registration server for forwarding registration requests. 2. Foreign Registration Server Machine Id: This is the format of the SMTP (Simplified Mail Transfer Protocol) (for example, machine @ fqdn where machine is the name of the foreign registration server machine and fqdn is the foreign registration) The machine ID of the foreign registration server in (which is the fully qualified domain name of the server's domain). 3. Tunneling Protocol Parameters: These are the parameters for configuring the tunnel between the serviced IWF and the home IWF on behalf of the end system. These include the tunneling protocol to be used between them and the parameters for constructing the tunnel.
【0128】
4. Shared secret key: This is the shared secret key that should be used for authentication between the foreign registration server and the home registration server. This secret key is used to calculate the Radius user password attribute in the Radius packet sent from the Foreign Registration Server to the Home Registration Server. It is defined between two wireless service providers. 5. User Password: This is the user password used on behalf of the roaming end system. This user password is defined by two wireless service providers. This password is encrypted using a shared secret key as described in Radius RSC. 6. Accounting parameters: These are the parameters for configuring accounting on behalf of the end system being registered. These parameters are sent by the registration server to its IWF to configure accounting on behalf of the end system.
【0129】
Using this information, the Foreign Registration Server generates a Radius access request, adds its own registration and credentials to the Radius access request, and leaves a copy of the registration information sent by the end system unchanged. Copy to the Radius access request and send the combined request to the home registration server. Upon receiving a Radius access request from the foreign registration server (for roaming end systems) or directly from the FA (for home end systems), the home registration server is its own directory server. Verify the foreign registration server identity and end system identity in roaming scenarios by accessing and referencing the shared secret key and recalculating the authentication directive.
【0130】
After successfully processing the request, the home registration server generates a Radius access acceptance response packet, which is sent to the foreign registration server if the end system is roaming, or receives the Radius access request. Send directly to the FA. The response contains a registration response attribute that the FA relays to the end system. If the request cannot be processed correctly, the home enrollment server generates a Radius access reject response packet and sends it to the foreign enrollment server if its end system is roaming. Alternatively, the Radius access request is sent directly to the sending FA. The response contains a registration response attribute that the FA will relay to the end system.
【0131】
In the roaming scenario, the response from the home registration server is received by the foreign registration server. It is authenticated by the Foreign Registration Server using a shared private key. After authentication, the foreign registration server processes the response, which in turn sends a Radius response packet (accept or reject) to the FA. The foreign registration server copies the registration response attribute from the Radius response packet of the home registration server to the Radius response packet without changing it.
【0132】
When the FA receives a Radius access response or a Radius access reject response packet, it generates a registration response packet from that Radius response using the registration response attribute and sends the response to the end system, thereby. Complete the migratory registration sequence. The Mobile IP standard stipulates that replay protection against registrations is implemented using time stamps or, optionally, nonces. However, playback protection using time stamps requires a well-synchronized clock between the corresponding nodes, so in the system of the present invention, playback protection using time stamps is the standard for mobile IP. Even if it is essential to use the temporary information and it is an option, the temporary information is used to protect the playback at the time of registration. However, as another embodiment, reproduction protection using a time stamp is also conceivable.
【0133】
The replay protection styles used between the nodes are stored in the security context as well as the authentication context, mode, secret key and encryption type. This network supports the use of PPP PAP (Password Authentication) and CHAP (Challenge Authentication Password) between the end system and its PPP server. This is independent of the registration and authentication mechanism previously described. This allows a private intranet or ISP to independently verify the user's identity. Authentication for accounting and directory services is described below with respect to accounting security. Access to the directory server from network devices within the same MSC does not need to be authenticated.
【0134】
This network supports encryption of bearer data sent between the end system and the home IWF. The end system negotiates to turn encryption on or off by choosing the appropriate security context. Upon receiving the registration request, the home registration server allows the end system's request to be encrypted based on its security context. In addition to storing authentication algorithms, modes, shared secret keys, and replay protection styles, security contexts are also used to specify the style of encryption algorithm to use. If encryption is negotiated between the end system and the home agent, then the entire PPP frame is so encrypted before it is encapsulated in the RLP.
【0135】
The IWF, accounting server and billing system are part of the same trusted domain within the MSC. These entities are connected to either the same LAN on the owned trusted intranet or part of it. Encrypting the transfer of accounting statistics between the IWF and the accounting server and between the accounting server and its customer's billing system using Internet IP security protocols such as IP-Sec. Can be done. This network makes it even more difficult to monitor the location of end systems. This is because all PPP frames transferred to and from an end system pass through the home IWF regardless of the actual location of the end system's equipment.
【0136】
Accounting data is collected by serviced IWFs and home IWFs in the network. The accounting data collected by the serving IWF is sent to the accounting server in the MSC of the serving IWF. The accounting data collected by Home IWF is sent to the accounting server in the MSC of Home IWF. Accounting data collected by the IWF in service is used by foreign wireless service providers to audit and clear billing information across wireless service provider boundaries (to support roaming and mobility). ). Accounting data collected by Home IWF is used to charge end users, and is also used for cross-border clearing of wireless service providers to handle roaming and mobility. ..
【0137】
Regardless of the location of the end system and the location of the foreign agent, all data traffic flows through the home IWF, so the home IWF has all the information to invoice the customer and / or foreign. Has all the information to generate clearing information for network usage.
【0138】
Serviced IWFs and home IWFs preferably use the Radius accounting protocol to send accounting records for registered end systems. The Radius accounting protocol is a protocol documented in the draft IETF RFC. In the case of the present invention, the protocol must be extended by adding vendor-specific attributes to the network and by adding checkpointing to the Radius accounting protocol. Checkpointing in this context refers to updating accounting data on a regular basis to minimize the risk of accounting records being lost.
【0139】
Radius accounting protocols run over UDP / IP and use acknowledgment and time-out based retries. The Radius accounting client (serving IWF or home IWF) sends a UDP accounting request packet to its respective accounting server, which sends the accounting back to the accounting client.
【0140】
Within the network, accounting clients (serving IWF and home IWF) issue an instruction to start accounting at the start of a user's session and an instruction to stop accounting at the end of the user's session. In the middle of the session, the accounting client gives instructions for accounting checkpoints. In contrast, the Radius Accounting RFC does not specify accounting checkpoint instructions. The software of the system of the present invention generates vendor-specific accounting attributes for this purpose. This accounting attribute is Acct-Status-Type of It is present in all Radius accounting request packets that contain Start. The value of this attribute is used to tell the accounting server if the accounting record is a checkpointing record. The checkpointing accounting record contains the time attribute and contains the cumulative accounting data from the start of the session. In the present invention, the frequency of transmitting check point packets can be configured and set.
【0141】
The servicing IWF and the home IWF are configured by their respective registration servers to connect to their respective accounting servers during the registration phase. Its configurable accounting parameters include the accounting server's IP address and UDP port, checkpointing frequency, session / multisession ID, and the share used between the accounting client and the accounting server. There is a secret key and so on.
【0142】
The network records the following accounting attributes for each registered end system: These accounting attributes are reported in Radius accounting packets by accounting clients to their respective accounting servers at the beginning of the session, at the end of the session, and in the middle (checkpoints). To.
【0143】
1. Username: This is similar to the Radius username attribute above. This attribute is used to identify the user and is present in all accounting records. Its format is "user @ domain", where domain is the fully qualified domain name of the user's home. 2. NAS IP Address: This is similar to the Radius NAS-IP address above. This attribute is used to identify the IP address of the machine running the home IWF or the IWF in service.
【0144】
3. Wireless Port: This attribute identifies the wireless port on the access point servicing the user. This attribute is encoded as a vendor-specific attribute. 4. Access point IP address: This attribute identifies the IP address of the access point servicing the user. This attribute is encoded as a vendor-specific attribute. 5. Service Type: This is similar to the Radius service type attribute above. The value of this attribute is framed. 6. Framed Protocol: This is similar to the Radius Framed Protocol attribute above. The value of this attribute is set to indicate PPP.
【0145】
7. Accounting Status Type: This is similar to the Radius Acct-Status-Type attribute above. The value of this attribute can be Start to mark the start of the user's session with the Radius client and Stop to mark the end of the user's session with the Radius client. For accounting clients, the Acct-Status-Type / Start attribute is raised when the end system is registered. The Acct-Status-Type / Stop attribute occurs when the end system unregisters for some reason. For checkpoints, the value of this attribute is Start, and the accounting checkpoint attribute also exists.
【0146】
8. Accounting Session Id: This is similar to the Radius Accounting Session Id above. In a roaming scenario, this session Id is assigned by the foreign registration server when the end system issues a registration request. It is communicated by the home registration server to the foreign registration server during the registration sequence. Both the home network and the foreign network know their Acct-Session-Id attribute and can issue this attribute while sending accounting records to their respective accounting servers. In the "end system is at home" scenario, this attribute is generated by the home registration server. The registration server communicates the value of this attribute to the IWF that issues it in all accounting records.
【0147】
9. Accounting Multi-Session Id: This is similar to Radius' Acct-Multi-Session-Id above. This Id is assigned by the home registration server when the registration request is received directly from the FA on behalf of the end system or via the foreign registration server. It is communicated to the foreign registration server by the home registration server in its registration response message. The registration server communicates the value of this attribute to IWF, which puts it in every accounting record and sends it.
【0148】
The true mobility added to that architecture allows accounting records from different IWFs for that same end system to be associated together when an end system moves from one IWF to another. That Id is used. For handoffs that span IWF boundaries, Acct-Session-Id is different for accounting records coming from different IWFs. However, the Acct-Multi-Session-Id attribute is the same for accounting records issued by all IWFs that have served that user. Since session Ids and multi-Ids are known for both foreign and home networks, they can publish these attributes in accounting reports for their respective accounting servers. This session Id and multi-session Id allow the billing system to correlate accounting records across IWF boundaries at the same wireless service provider and even across wireless service provider boundaries.
【0149】
1. Accounting Delay: See Radius Accounting Delay Attribute. 2. Number of Accounting Input Octets: See Number of Accounting Input Octets in Radius. This attribute is used to track the number of octets sent by an end system (inputs from the end system to its network). None of the airlink overheads or overheads imposed by RLP are counted. 3. Number of Accounting Output Octets: See Number of Accounting Output Octets in Radius. This attribute is used to track the number of octets (network-to-end system output) sent to the end system. This count is used to track only PPP frames. None of the airlink overheads or overheads imposed by RLP are counted.
【0150】
4. Accounting Authentication: See Radius Accounting Authentication Attributes. The value of this attribute can be Local or Remote, depending on whether the serving IWF or the home IWF generates the accounting record. 5. Accounting Session Times: See Radius Accounting Session Times. This attribute indicates the amount of time the user has been in service. When sent by a servicing IWF, this attribute keeps track of the amount of time a user has been serviced by the servicing IWF. When sent by the Home IWF, this attribute keeps track of the amount of time the user has been serviced by the Home IWF.
【0151】
6. Accounting Input Packets: See Radius Accounting Input Packets attribute. This attribute indicates the number of packets received from the end system. For servicing IWFs, this attribute keeps track of the number of PPP frames entered by the end system into servicing IWFs. For home IWF, this attribute keeps track of the number of PPP frames input from the end system to home IWF. 7. Accounting Output Packets: See Radius Accounting Output Packets attribute. This attribute indicates the number of packets sent to the end system. For servicing IWFs, this attribute keeps track of the number of PPP frames output by the servicing IWF to the end system. For home IWF, this attribute represents the number of PPP frames sent from that home IWF to the end system.
【0152】
8. Accounting Termination Reasons: See Radius Accounting Termination Reasons attribute. This attribute indicates why the user's session was terminated. In addition, there is a unique reason code to provide additional details. This attribute is only included in the accounting report at the end of the session. 9. Reasons for Network Accounting Termination: This attribute gives the detailed reason for terminating the session. This particular attribute is encoded as a vendor-specific attribute and is reported only within the Radius accounting attributes at the end of the session. There is also a standard Radius attribute Acct-Terminate-Cause. This attribute provides a specific reason code that is not covered by the Acct-Terminate-Cause attribute.
【0153】
10. Network Airlink Access Protocol: This attribute indicates the airlink access protocol used by the end system. This attribute is encoded as a vendor-specific attribute. 11. Network Backhaul Access Protocol: This attribute indicates the backhaul access protocol used by the access point to pass data to and from the end system. This attribute is encoded as a vendor-specific attribute.
【0154】
12. Network Agent Machine Name: This attribute is the fully qualified domain name of the machine running the home IWF or the IWF in service. This particular attribute is encoded in a vendor-specific format. 13. Network Accounting Checkpoints: Radius accounting RFCs do not define checkpoint packets, so the network examples of the present invention use Radius accounting start packets with this attribute to mark checkpoints. To do. The absence of the checkpoint attribute means that it is a normal accounting start packet. An accounting start packet in which this attribute is present means an accounting checkpoint packet. Accounting stop packets do not have this attribute.
【0155】
In this preferred embodiment, all accounting packets and their corresponding responses must be authenticated using MD5 and a shared secret key. The IWF consists of a shared secret key used by them for authentication during communication with each Radius accounting server. The shared secret key used by IWF to communicate with the accounting server is stored in the home / foreign domain directory within the MSC. The shared secret key for accounting security is communicated to IWF by each registration server during the end system registration sequence.
【0156】
The accounting server software runs inside the computer at the MSC. The role of the accounting server in the system is to collect raw accounting data from network elements (home and IWF servicing), process that data, and process it into the wireless service provider's billing system. Is to store for transfer to. The accounting server does not include a billing system. Instead, it supports automatic or manual accounting data transfer mechanisms. Using its automatic accounting data transfer mechanism, the accounting server transfers accounting records in AMA's billing format to the customer's billing system over TCP / IP transport. To this end, the system defines an AMA billing record format for packet data. Using a manual transfer mechanism, customers can make tapes to transfer accounting records to their respective billing systems. To make tapes for each specification, customers are provided with information to access accounting records so that they can process them before writing them to tape.
【0157】
In FIG. 22, the raw accounting data received by the accounting server from the home or servicing IWF is processed and stored by the accounting server. The processing performed by the accounting server includes filtering, compression and correlation of raw accounting data received from IWF. A highly available file server and hot swappable RAID disk using dual active / standby processors buffers the accounting data while it is being transported through the accounting server. used.
【0158】
The accounting server delays the processing of raw accounting data until the end system ends its session. When the end system terminates the session, the accounting server processes the raw accounting data collected for the session and stores the accounting aggregate records in the SQL database. Accounting aggregate records stored in the SQL database point to one ASN.1 coded file. This file contains detailed accounting information about the session on that end system. The data stored in the accounting server is then transferred by the billing data transfer agent to the customer's billing system. Alternatively, the wireless service provider can transfer accounting data from its SQL database and / or ASN.1 encoded file to the billing system via tape. The database scheme and ASN.1 coded file format are documented and made available to customers for this purpose. If the volume of processed accounting data stored in the accounting system exceeds the higher limit, the accounting server raises an NMS alarm. This alarm is cleared when the volume of data stored on the accounting server drops below the lower limit. The higher and lower limits for raising and clearing the alarm are configurable. The accounting server also raises an NMS alarm when the storage period for stored accounting data exceeds a configurable threshold. On the contrary, when the storage period of the accounting data falls below the threshold value, the alarm is cleared.
【0159】
The subscriber directory is used to store information about subscribers and is located on your home network. The home registration server references this directory during its registration phase to authenticate and register the end system. For each subscriber, the subscription directory stores the following information:
【0160】
1. Username: This field in the subscriber record will be in SMTP format (for example, user @ fqdn). Here the user subfield identifies the subscriber within the subscriber's wireless home domain, and the fqdn subfield identifies the subscriber's wireless home domain. This field is sent by the end system in its registration request during the registration phase. This field is assigned by the wireless service provider to the subscriber when subscribing to the network service. This field is different from the username field used in PPP.
【0161】
2. Mobility Security Association: This field in the subscriber record contains a mobility security association between the subscriber and that subscriber's home network. As mentioned above, a mobility security association exists between each subscriber and its home registration server. Mobility security associations define a collection of security contexts. Each security context uses an authentication algorithm, authentication mode, shared secret key, replay protection style, and encryption type (including non-encryption) between the end system and its home server. Define for. During registration, the home registration server calls the subscriber's security context from the subscriber directory using the username and security parameter index (SPI) shared by the end system in the registration request. The information in that security context is used to perform authentication, encryption and replay protection during the session. Mobility security associations are generated by the wireless service provider at the time of subscription. Whether or not the subscriber is allowed to change this association by either calling a customer service representative or by allowing the subscriber to access a secure website is the wireless service. It's up to the provider. Website software exports web pages that allow wireless service providers to make them accessible to subscribers from secure web servers. In this way, the subscriber can view / change the context of the mobility security association, as well as other subscriber information that the service provider can access.
【0162】
3. Modem MAC Address: This field contains the MAC address of the modem owned by the subscriber. In addition to the secret key provided, this field is used during registration to authenticate the user. MAC address-based authentication can be turned off on a per-user basis. The MAC address is communicated to the home registration server at the time of registration. 4. Enable MAC Address Authentication: This field is used to determine whether MAC address-based authentication is enabled or disabled. When enabled, the home enrollment server checks the MAC address of the enrolling end system for this field to verify the identity of that end system. If disabled, no check is done.
【0163】
5. Roaming enable flag: If this field is set to "enabled", the end system is allowed to roam to the foreign network. If the field is "disabled", the end system is not allowed to roam to the foreign network. 6. List of roaming domains: This field is meaningful only if the roaming enable flag is enabled. This field contains a list of foreign domains that the end system is allowed to roam. When the contents of this list are null and the roaming enable flag is set to "enable", the end system is allowed to roam freely.
【0164】
7. Service Enable / Able Flag: This field can be "disabled" by the system administrator to disable services for subscribers. If this field is disabled, the subscriber is allowed to register for the service. If the subscriber is registered and the value of this field is set to "disabled", the subscriber's end system is immediately disconnected by the network. 8. Internet Service Provider Association: This field contains information about the subscriber's Internet service provider. This information is in the PPP registration phase to perform authentication by the Internet service provider on behalf of the end system and to create an L2TP tunnel between IWF and its Internet service provider's PPP server. Used by IWF in. This field contains the identity of the subscriber's ISP. IWF uses this information to access the ISP's directory to perform authentication on behalf of the end system and to set up an L2TP tunnel. 9. Subscriber Name and Address Information: This field includes the subscriber's name, address, phone number, fax number, email address, etc.
【0165】
The home domain directory (HDD) is used by the registration server to call parameters related to the end system to complete registration on behalf of the end system. Using this information, the registration server determines if the end system is registered at home or if the end system is a roaming end system. In the former case, the registration server assumes the role of the home registration server and proceeds with the registration of the end system. In the latter case, the registration server assumes the role of a foreign registration server and acts as a proxy for Radius, forwarding the request to the actual home registration server that has an identity from this directory. For roaming end systems, the parameters stored on the HDD are the IP address of the home registration server, the secret key for sharing between the home and foreign, and the configuration of the tunnel between the home and the serviced IWF. And so on. The HDD is located inside the MSC.
【0166】
The following information is stored on the HDD. 1. Home domain name: This field is used as a key to search the HDD for an entry that matches the fully qualified home domain name provided by the end system in its registration request. 2. Proxy Registration Request: This field is used by the registration server to determine whether it should act as a foreign registration server and whether to delegate a registration request to the actual registration server for that end system.
【0167】
3. Home registration server DNS name: If the proxy registration request flag is TRUE, this field is used to access the actual home registration server DNS name. Otherwise, this field is ignored. The DNS name is converted to an IP address by the foreign registration server. The foreign registration server uses its IP address to relay end system registration requests. 4. Foreign domain name: If the proxy registration request flag is TRUE, this field is used to identify the foreign domain name for the end system home registration server. Otherwise, this field is ignored. The foreign registration server uses this information to generate the id of the foreign server machine in SMTP format, for example machine @ fqdn. This machine id is sent to the home registration server by the foreign registration server in a Radius access request.
【0168】
5. Shared secret key: If the proxy request flag is TRUE, the shared secret key is used to authenticate each other's identities between the foreign registration server and the home registration server. Otherwise, this field is ignored. 6. Tunneling Protocol Parameters: This field is used to store parameters for constructing a tunnel to service the end system. For home-based end systems, this contains information about tunnel parameters between the base station and the home IWF, and from the home IWF to the PPP server. For roaming end systems, this includes tunneling parameters for IWF servicing from the base station and tunneling parameters for IWF servicing to home IWF. At a minimum, for each tunnel, this field contains the type of tunneling protocol used and any parameters specific to the tunneling protocol. For example, this field can contain an identifier for the tunneling protocol L2TP and additional parameters needed to configure an L2TP tunnel between IWF and its peers.
【0169】
7. Accounting server association. This field is used by IWF to store the information needed to generate accounting data on behalf of the end system. It is the name of the accounting protocol (for example, RADIUS), the DNS name of the accounting server, and additional parameters specific to the accounting protocol, such as the UDP port number, that IWF must be used in Radius's accounting protocol. Includes shared secret key that must be used, frequency of check pointing, seed for generating session / multisession id, and so on. The accounting server's DNS name is translated into the accounting server's IP address, which is sent to IWF.
【0170】
For wireless service providers that have roaming contracts with each other, HDDs are used for authentication and to complete the registration process. If an end system roams from its home network to one foreign network, the foreign registration servers within that network can obtain information about the home registration of the end system they are visiting, and Refer to the HDD in the MSC to authenticate the home network before the home network provides services to the end system it is visiting.
【0171】
Software for managing home domain directories preferably provides system administrators with a graphical user interface (GUI) based HDD management interface. This GUI allows system administrators to view and update entries in the HDD. This GUI is not intended to be used by foreign wireless network service providers to perform remote updates under roaming contracts. It is intended only for use by trusted persons of home wireless service providers operating behind a firewall.
【0172】
Foreign domain directories (FDDs) provide the opposite functionality of home domain directories. The FDD authenticates the foreign network with the home registration server and home-registers to call parameters for the foreign registration server and foreign network to create a tunnel between the serving IWF and the home IWF. Used by the server. These parameters include the home-foreign shared secret key, the home IWF-serving IWF tunnel configuration, and so on. The FDD is preferably located inside the MSC of the home registration server. The FDD is used by the home registration server to register roaming end systems.
【0173】
The following information is stored in the FDD. 1. Foreign domain name: This field is used as a key to search the FDD for an entry that matches the fully qualified domain name of the foreign registration server relaying the registration request. 2. Shared secret key: This is the shared secret key used by the foreign registration server and the home registration server to mutually authenticate their identities.
【0174】
3. Tunneling protocol parameters between the home IWF and the servicing IWF: This field is used to store the parameters for constructing the tunnel between the home IWF and the servicing IWF. At a minimum, this field contains the type of tunneling protocol to use and any parameters specific to the tunneling protocol. For example, this field can contain an identifier for the tunneling protocol L2TP and additional parameters needed to configure the L2TP tunnel between the serving IWF and the home IWF. 4. Accounting Server Association: This field is used by IWF to store the information needed to generate accounting data on behalf of the end system. It is the name of the accounting protocol (for example, RADIUS), the DNS name of the accounting server, and additional parameters specific to the accounting protocol, such as the UDP port number, that IWF must be used in Radius's accounting protocol. Includes shared secret key that must be used, frequency of check pointing, seed for generating session / multisession id, and so on. The accounting server's DNS name is translated into the accounting server's IP address, which is sent to the foreign agent.
【0175】
For wireless service providers that have roaming contracts with each other, FDD is used to authenticate and complete the registration process. When an end system roams from its home network to a foreign network, the registration servers in that home network need to obtain and authenticate the foreign network servicing the end system. , Refer to the FDD in that MSC.
【0176】
Foreign domain directory management software provides system administrators with a graphical user interface (GUI) -based FDD management interface. This GUI allows system administrators to view and update entries in the FDD. This GUI is not intended to be used by foreign wireless network service providers to perform remote updates under roaming contracts. It is intended only for use by trusted persons of home wireless service providers operating behind a firewall.
【0177】
The Internet Service Provider Directory (ISPD) manages connectivity between wireless service providers and ISPs that have service contracts so that subscribers can use their network to access their respective ISPs. Used by Home IWF for. For each subscriber, the subscriber directory has one entry for that subscriber's ISP. This field points to one entry in the ISPD. Home IWF uses this information to set up a connection to the ISP on behalf of the subscriber.
【0178】
The network architecture supports roaming. For roaming between wireless service providers to work properly, the architecture must support the setup of roaming contracts between wireless service providers. This means two things: (1) updating the system directory across wireless service providers and (2) reimbursing bills between service providers.
【0179】
To allow subscribers access to Internet service providers, this architecture supports roaming contracts with Internet service providers. This means that the architecture must send and receive data to and from the ISP's PPP server (ie, supporting industry standard protocols such as PPP, L2TP and Radius). It also means that the architecture handles directory updates for ISP access and billing with the ISP.
【0180】
When a roaming contract is signed between two wireless service providers, both providers support authentication and registration capabilities for end systems visiting their respective networks from other networks. , The respective home and foreign domain directories must be updated. At a minimum, the architecture of this embodiment supports manual directory updates. When a roaming contract is signed between two wireless service providers, the two parties exchange information to fill their home and foreign domain directories. The actual update of that directory is done manually by the staff of each service provider. Later, if the information in the home and foreign domain directories needs to be updated, the two parties will exchange the updated information for the contract and then each update to the directory. And apply manually.
【0181】
In other embodiments, directory management software is used to enable roaming between Internet service providers and to allow ISPs to automatically manage and discover roaming relationships. Incorporate standards under development at the IETF. This eliminates the need for manual directory management. The network system automatically propagates roaming relationships, discovers them, and authenticates and registers the visiting end system.
【0182】
At a minimum, the network architecture only processes accounting data, stores it, and makes that data available to the wireless service provider's billing system. It is up to the billing system to handle the settlement of billing for roaming. In another embodiment, IEFT to allow the ISP to settle charges for roaming end systems to handle the distribution of accounting records between Internet service providers. The standard under development is incorporated in.
【0183】
The system software supports access to the ISP and private intranet by supporting L2TP between the home IWF and the PPP server on the ISP or intranet. The Internet service provider's directory contains information that is useful to IWF to create these tunnels. If an access contract has been signed between the wireless service provider and the Internet service provider, this directory will be manually updated by the wireless service provider staff. Automatic updates and discoveries of access relationships between wireless service providers and Internet service providers are currently under consideration and will be implemented as Internet standards evolve. While accessing the Internet service provider, the subscriber receives two bills. One is from the wireless service provider for the use of the wireless network and the other is from the internet service provider. A common billing that combines the two types of billing is not covered by the minimum configuration example software, but the subscriber charges a common billing based on the roaming contract between the ISP and the wireless service provider. It is conceivable that the software will take advantage of it as the Internet standard for payouts evolves so that it can be received.
【0184】
This system includes an element management system for managing network elements. From the Element Manager, the system administrator performs configuration, performance and failure / alarm management functions. The element management application runs at the top of the web browser. Using a web browser, the system administrator manages the network from anywhere with TCP / IP access. The element manager also acts as an agent for higher level managers. In this role, it exports an SNMP MIB for alarm and fault monitoring.
【0185】
The higher level SNMP manager is notified of the alarm status via SNMP traps. Higher-level SNMP managers periodically pole element manager MIBs for network health and its status. System administration personnel at higher level managers can see icons that represent the network and its current alarm status. By point-and-click the icon of the network elements, the staff of system management is a web browser to run an application using The element management, and to perform a more detailed management functions.
【0186】
Within the network, management of physical and logical network elements is performed using a combination of the SNMP protocol and an internally managed application programming interface. Applications in Element Manager use SNMP or other management APIs to perform network management functions. Architecturally, an element management system contains two distinctly different sets of functional elements. The first set of functional elements includes a configuration data server, performance data monitor and health / status monitor and network element recovery software and runs on an HA server equipped with RAID disks. The second set of functional elements, including management applications, runs on a dedicated, non-HA management system. If the element manager system goes down, network elements can continue to run, report alarms, and even recover from a failed state. However, all management applications run inside a non-HA element manager, so if an element manager goes down, there is no recovery action that requires human intervention until that element manager is up and running. It is possible.
【0187】
Wireless hubs (WHs) in base stations are usually owned by wireless service providers (WSPs), and they are either via point-to-point links, intranets, or the Internet. You are connected to the WSP's registration server (RS). A WSP registration server is typically a software module running on a processor to perform certain registration functions. An interworking functional unit (IWF unit) is usually a software module running on a processor to perform certain interface functions. The IWF unit is usually connected to the registration server via an intranet / WAN, and the IWF unit is usually owned by the WSP. However, the IWF unit does not have to be inside the same LAN as the registration server. Accounting and directory servers (also software modules running on the processor) are typically one or more hosting service provider data centers (for example, various servers and other software modules). It is connected to the registration server via the LAN in the center (center including the processor). Traffic from the end system is routed through a router (connected to the LAN) to the public Internet or the ISP's intranet. The registration server located on the Foreign WSP network is called the Foreign Registration Server (FRS), and the registration server located on the end system's home network (where mobile purchases its services) is home. Called the Registration Server (HRS). The interworking function unit in the home network is called the home IWF, while the interworking function in the foreign network (ie, the network the end system is visiting) is called the servicing IWF.
【0188】
For fixed wireless services (ie, non-moving end systems), the end system is from a home network (for example, services at home) or from a foreign network (for example, roaming services). You can register for the above services. The end system receives the announcement sent by the agent in its wireless hub (for example, the agent function implemented in the software) via the access point. In addition to the network layer registration, the MAC layer is also registered. These can be combined together for efficiency.
【0189】
For home-based end systems (Figure 23), network layer registration (such as local registration) makes the wireless hub to which the end system is currently attached known to the home registration server. The IWF in the home network of the end system becomes the anchor, or home IWF. Therefore, PPP frames to and from the end system are forwarded via the wireless hub to the home IWF in the home network. If the end system is at home, its home IWF is connected to its wireless hub via the XTunnel protocol.
【0190】
For roaming wireless services (Figure 24), the foreign registration server knows the identity of the home network of the roaming end system during the registration phase. Using this information, the foreign registration server communicates with the home registration server to authenticate and register its end system. The foreign registration server is then assigned one servicing IWF, and an I-XTunnel protocol connection is established to roam the end system between its home IWF and the servicing IWF. .. The serviced IWF relays frames between the wireless hub and the home IWF. Data is sent from that home IWF to a PPP server (ie, a point-to-point protocol server) that may reside within that same IWF. However, if the data is sent to a company intranet that has its own PPP server or an ISP intranet, the data is sent to another PPP server via the L2TP protocol. The other server is typically owned and operated by an Internet service provider that is different from the wireless service provider. The home IWF and PPP server locations remain fixed throughout the session. MAC layer registration can be combined with network registration to economicalize separate communication overheads for MAC layer and network layer registration. However, it may be advantageous not to combine these registration processes so that the WSP's equipment can interoperate with other wireless networks that support pure IETF mobile IP.
【0191】
Registration sets up three tables. Table 1 is associated with each access point, which identifies each connection (eg, each end system) by connection ID (CID), and that connection ID is for a particular wireless modem (WM). Associate with an address (that is, the end system or the address of the end system). Table 2 is associated with each wireless hub (WH), and Table 2 associates each connection ID with the corresponding wireless modem address, access point, and XTunnel ID (XID). Table 3 is associated with each interworking function (IWF), and Table 3 associates each connection ID with the corresponding wireless modem address, wireless hub address, XTunnel ID and IP port (IP / port). The entries described for these tables are described to include only relevant entries that support a description of mobility management. In fact, there are other important fields that need to be included.
[table 1]
<img file="JPH11331276A_D0001.tif" />【0192】
The protocol stacks for dial-up users at home in the network, as well as roaming users, are shown in Figures 25-28. Figure 25 shows the protocol stack used for direct Internet access by a fixed (ie, non-moving) end system at home, where PPP protocol messages are at home IWF (usually home IWF). Terminated at (located in the same location as the line hub), the home IWF relays messages to and from the IP router, from which it relays to the public Internet. Figure 26 shows the protocol stack used to access a remote intranet (ie, a private company net or ISP) by a home-based (ie, non-moving) end system, PPP. Protocol messages are relayed through your home IWF (usually co-located with your wireless hub) to your corporate intranet or your ISP's PPP server. Figure 27 shows the protocol stack used to access the Internet directly by a roaming but fixed (ie, non-moving) end system or a moving end system. The PPP protocol terminates at the home IWF (usually at the mobile exchange center of the home network), which relays messages to and from the IP router. Note in Figure 27 how message traffic passes through IWFs that are servicing other than the home IWF (usually in the same location as the wireless hub). Figure 28 is for accessing a remote intranet (ie, a private company net or ISP) by a roaming but fixed (ie, non-moving) end system or a moving end system. Indicates the protocol stack used for, and the PPP protocol message is the home IWF (usually the home net). It is relayed to the company's intranet or the ISP's PPP server through (in the work mobile exchange center). Note how message traffic passes through the serviced IWF (usually in the same location as the wireless hub) in addition to the home IWF in Figure 28. When a servicing IWF and a wireless hub coexist in the same nest of computers or are programmed on the same computer, establish a tunnel between the servicing IWF and the wireless hub using the XTunnel protocol. do not have to.
【0193】
Equivalent variants of these protocol stacks (eg, mobiles at home can be terminated at a wireless hub rather than at the IWF servicing RLP or at home IWF). The RLP protocol can be terminated on a wireless hub if the IWF is remote from the wireless hub and if packets can be carried over a lossy IP network between the IWF and the wireless hub. It will be preferable. Another variant is that the X Tunnel between the wireless hub and IWF does not need to be built on top of UDP / IP. XTunnel can be built using the Frame Relay / ATM link layer. However, UDP / IP makes it easy to move wireless hubs and IWF software from one network to another.
【0194】
In addition, the PPP protocol can be terminated in a wireless modem and sent over an Ethernet connection to one or more end systems. As shown in Figure 29, the wireless modem 300 receives PPP protocol information, encapsulates its PPP payload in Ethernet frames, and for at least one end system 304 and 306 over Internet connection 302. To be transferred.
【0195】
XWD DIX Ethernet can be used to encapsulate the MAC, but the system is not limited to that. The format of the Ethernet frame for the XWD control frame is shown in Figure 30. The Ethernet header contains the destination address, source address and Ethernet type field. The destination address field contains the Ethernet address of the MAC entity to which the primitive is being sent. For MAC primitives called by a MAC user, this field will contain the Ethernet address of that MAC user. For broadcast primitives, this address is the Ethernet broadcast address. The source address field contains the Ethernet address of the MAC entity calling the primitive. The Ethernet type field contains the Ethernet type for XWD. Possible values are XWD_Control for control frames and XWD_Data for data frames. These values must be different from all Ethernet types that have been standardized so far, and must be registered by the control authority.
【0196】
Second, the Ethernet frame has an XWD header field. This XWD header can be 16 bits in length and is only present for XWD control frames. The field is shown in Figure 31. This Ethernet frame also contains a protocol header, a PPP payload field and an XWD MAC field. The header values for primitives using Ethernet encapsulation are shown in Table 4 below.
[Table 2]
<img file="JPH11331276A_D0002.tif" />【0197】
In another alternative, the PPP protocol can be terminated within a wireless router and sent to at least one end system connected to a local area network (LAN). As shown in FIG. 32, the wireless router 350 receives PPP protocol information via the wireless modem 352. Router 354 receives PPP information from the wireless modem 352 and sends the PPP information over LAN link 362 to at least one of the end systems 356, 358, 360.
【0198】
Four types of handoff scenarios can occur, which are named (i) local mobility, (ii) micro-mobility, (iii) macro-mobility, and (iv) global mobility. In all four scenarios (in one embodiment of the invention), route optimization options are not considered and the locations of the home registration server and the ISP's PPP server remain unchanged. In another embodiment of the system with route optimization, the ISP's PPP server can change. However, this is explained below. Moreover, in the first three scenarios, the foreign registration server and IWF locations do not change.
【0199】
The proposed IETF mobile IP standard is that whenever an end system changes the IP subnet to which it is attached, it sends a registration request message to home agents within that home subnet. There is a need to. This message carries the care of address, which the end system can access within the new subnet. For example, when an ISP sends a traffic to the end system, the home agent intercepts the traffic heading to the end system when it arrives at the home subnet, and then steals the traffic. Forward to the Care of Address. The care of address identifies a particular foreign agent within the foreign subnet. The foreign agent of an end system can reside within the end system itself, or in another node that sequentially forwards traffic to that end system (ie, a proxy registration agent). It is possible. Mobile IP handoffs require the exchange of control messages between end system agents, end systems, home agents and potentially corresponding hosts (CHs) (with route optimization options). ..
【0200】
The proposed IETF mobile IP standard finds it difficult to meet latency and scalability goals for all movements in large internetwork. However, the hierarchical mobility management of the present invention satisfies such a goal. For small moves (for example, changing access points), only MAC layer re-registration is required. In the case of relatively large movements, the network layer is re-registered. The hierarchical mobility management of the present invention differs from the flat structure used in the IETF's proposed mobile IP standard and is based on CPDP (a standard guaranteed by the Cellular Digital Packet Data Forum). It is also different from the servicing / anchor interworking function used in such cellular systems.
【0201】
As shown in Figure 33, the local mobility handoff deals with the movement of the end system (indicated by MN as a mobile node) between APs belonging to the same radio hub. Therefore, only re-registration of the MAC layer is required. The end system receives the wireless hub announcement from the new AP and responds with a registration request addressed to the new AP.
【0202】
The new AP (ie, the AP that receives the registration request from its end system) creates a new entry in its connection table and relays its registration message to its wireless hub. In the handoff of local mobility, the wireless hub does not change. The wireless hub authenticates the end system registration request as a MAC-level registration request and updates its connection table to reflect the connection to the new AP. The previous AP then removes the connection entry from its connection table. There are at least three ways a previous AP can delete a previous entry. They (i) when they time out, (ii) when they receive a copy of the relayed MAC layer association message from the new AP to the wireless hub (if this relay message is a broadcast message), (iii) their entry. When the wireless hub notifies you that you need to remove.
【0203】
As shown in Figure 34, the micro-mobility handoff belongs to the same registration server and the end system is an end system (mobile) between wireless hubs that can still be serviced by an existing servicing IWF. -Handle the movement of (indicated by MN as a node). When the announcement is received from the new wireless hub (through the new AP), the end system sends a message to the registration server requesting registration. The registration request is relayed from the new AP to the new wireless hub and sent to the registration server.
【0204】
If it determines that the existing IWF is still available, the registration server sends an XTunnel request message created to request the existing IWF and creates an XTunnel for the new wireless hub. The registration server then sends an XTunnel destruction request message to request the existing IWF to destroy the existing XTunnel with the previous wireless hub. The create and destroy XTunnel request messages can be combined into a single message. The foreign registration server does not forward the registration message to the home registration server because neither the serviced IWF nor the home IWF has changed IWF.
【0205】
Upon receiving a positive XTunnel create response and a positive XTunnel destroy response, the registration server sends a registration response to the end system. When the registration response arrives at the new wireless hub, the connection table on the new wireless hub is updated to reflect the connection to the new AP. After receiving the message from the new wireless hub, the new AP updates its MAC filter address table and connection table, and the registration response is forwarded to the end system.
【0206】
The registration server sends a release message to the previous wireless hub. When the previous wireless hub receives the release message, it updates its connection table, MAC filter address table, and connection table of the previous AP. As shown in Figure 35, the macro mobility handoff deals with movements between wireless hubs that require changes to the IWFs in service within the foreign network but do not require changes to the registration server. .. When the announcement is received from the new wireless hub (through the new AP), the end system sends a message to the registration server requesting registration of the new network layer. The registration request is relayed from the new AP to the new wireless hub and sent to the registration server.
【0207】
The registration server recognizes that it is a foreign registration server when the end system does not belong to the current registration server network. This foreign registration server identifies the home registration server by using one request (Preferably a Radius access request (RA request)) for a foreign directory server (like a large yellow page). Request and assign the appropriate IWF as servicing IWF, and forward the registration request to the home registration server through one request (preferably a Radius access request (RA request)). Notify the home registration server of the newly selected IWF.
【0208】
The home registration server authenticates the registration request by using one request (preferably a Radius access request (RA request)) to the home directory server. After authenticating the request and knowing that the existing home IWF is still available, the home registration server tells the home IWF to create a new I-XTunnel for the newly assigned serviced IWF, and Instructs the previous servicing IWF to destroy the existing I-XTunnel. Upon receiving a positive I-XTunnel create response and a positive I-XTunnel discard response from the home IWF, the home registration server sends a registration response to the foreign registration server.
【0209】
The foreign registration server then instructs the newly assigned IWF to create an XTunnel for the new wireless hub. Upon receiving a positive XTunnel creation response, the foreign registration server instructs the previous IWF to destroy the XTunnel for the previous radio hub. Upon receiving a positive XTunnel create response and a positive XTunnel discard response, the foreign registration server sends a registration response to the end system.
【0210】
When the registration response arrives at the new wireless hub, the connection table on the new wireless hub is updated to reflect the connection to the new AP. After receiving the message from the new wireless hub, the new AP updates its MAC filter address table and connection table, and the registration response is forwarded to the end system. The registration server sends a release message to the previous wireless hub. Upon receiving the release message, the previous wireless hub updates its connection table and MAC filter address table, and the previous AP receives a message from the previous wireless hub and then its MAC filter. Update the address table and connection table.
【0211】
For global mobility handoffs, handle movements between wireless hubs that require changes to the registration server. Figure 36 shows the global mobility handoff when the home IWF does not change, and Figure 37 shows the global mobility handoff when the home IWF changes. When a notification is received (through a new AP) from a new wireless hub in a new foreign network, the end system sends a message to the new foreign registration server requesting network layer registration. The registration request is relayed from the new AP to the new wireless hub and sent to the new foreign registration server.
【0212】
The registration server recognizes that it is the new foreign registration server when the end system does not belong to the current registration server network. This foreign registration server is a home registration server by using one request (preferably a Radius access request (RA request)) for a foreign directory server (like a large yellow page). To the home registration server through one request (preferably a Radius access request (RA request)), asking for the identity of, and assigning one appropriate IWF as the IWF in service. Forward the registration request and inform the home registration server about the newly selected IWF.
【0213】
The home registration server authenticates the registration request to the home directory server by using one request (preferably a Radius access request (RA request)). After authenticating the request and knowing that the existing home IWF is still available (Figure 36), the home registration server will home to create a new I-XTunnel for the serviced IWF newly assigned by the new registration server. Instruct IWF. The home registration server also sends a deregistration message to the previous foreign registration server and destroys the existing I-XTunnel for the servicing IWF where the previous foreign network resides. Instruct the home IWF. Upon receiving a positive I-XTunnel create response and a positive I-XTunnel discard response from the home IWF, the home registration server sends a registration response to the new foreign registration server.
【0214】
The new foreign registration server then instructs its newly assigned IWF to create an XTunnel for the new wireless hub. Upon receiving a positive XTunnel creation response, the foreign registration server sends a registration response to the end system. When the registration response arrives at the new wireless hub, the connection table on the new wireless hub is updated to reflect that connection to the new AP. After receiving the message from the new wireless hub, the new AP updates its MAC filter address table and connection table, and the registration response is forwarded to the end system.
【0215】
The previous foreign registration server tells the previous IWF to destroy the XTunnel for the previous wireless hub. Upon receiving a positive XTunnel destroy response, or at the same time as the XTunnel destroy request, the previous foreign registration server sends a release message to the previous wireless hub. Upon receiving the release message, the previous wireless hub updates its connection table and MAC filter address table, and the previous AP receives a message from the previous wireless hub and then its MAC filter address. -Update the table and connection table.
【0216】
Instead, after the home registration server authenticates the registration request from the new foreign registration server and learns that the existing home IWF cannot be used (Figure 37), the home registration server selects the new home IWF and the current PPP. Instruct the new home IWF to create a new Level 2 Tunnel Protocol Tunnel (L2TP Tunnel) for the server (for example, the PPP server on the connected ISP intranet). The home registration server then instructs the previous IWF to forward its L2TP tunnel traffic to the new home IWF.
【0217】
The home registration server then instructs the new home IWF to create a new I-XTunnel for the newly assigned serviced IWF to the new foreign registration server. The home registration server also sends a deregistration message to the previous foreign registration server and destroys the existing I-XTunnel for the existing serviced IWF on the previous foreign network. Instruct. Upon receiving a positive I-XTunnel create response and a positive I-XTunnel discard response from the home IWF, the home registration server sends a registration response to the new foreign registration server.
【0218】
The new foreign registration server then instructs its newly assigned IWF to create an XTunnel for the new wireless hub. Upon receiving a positive XTunnel creation response, the foreign registration server sends a registration response to the end system. When the registration response arrives at the new wireless hub, the connection table on the new wireless hub is updated to reflect that connection to the new AP. After receiving the message from the new wireless hub, the new AP updates its MAC filter address table and connection table, and the registration response is forwarded to the end system.
【0219】
The previous foreign registration server tells the previous IWF to destroy the XTunnel for the previous wireless hub. Upon receiving a positive XTunnel destroy response, or at the same time as the XTunnel destroy request, the previous foreign registration server sends a release message to the previous wireless hub. Upon receiving the release message, the previous wireless hub updates its connection table and MAC filter address table, and the previous AP receives a message from the previous wireless hub and then its MAC filter address. -Update the table and connection table.
【0220】
End systems built according to the systems of the invention are interoperable with networks built according to the proposed IETF mobile IP standard, and end systems built according to the proposed IETF mobile IP standard It is interoperable with networks constructed according to the present invention.
【0221】
Differences between the system of the invention and the IETF Mobile IP (RFC 2002, standard documentation) include: (i) The system of the present invention is not a flat structure as in the proposed IETF mobile IP standard, but a hierarchical concept for mobility management. Small moves within a small area do not have network level registration. Micro-mobility involves setting up a new XTunnel and destroying an existing XTunnel Global mobility is minimal and requires setting up a new IXTunnel and destroying an existing IXTunnel separately from XTunnel setup / destruction. Global mobility also requires the setup of a new L2TP tunnel and the transfer of L2TP state from an existing L2TP tunnel to a new L2TP tunnel.
【0222】
(ii) In the present invention, one username plus one range is used to identify remote dial-up users and is fixed as in the case of the proposed IETF mobile IP standard. Different from home address. (iii) In the present invention, the functions of registration and routing are performed by another entity. These two functions are performed by the home agent in the proposed IETF mobile IP standard, and both functions are performed by the foreign agent in the proposed IETF mobile IP standard. In contrast, in one embodiment of the invention, registration is performed on the registration server, and routing functions are performed by Home and Foreign IWFs and wireless hubs (also referred to as access hubs).
【0223】
(iv) The system of the present invention utilizes three tunnels per PPP session. The XTunnel is more than a link layer tunnel between a wireless hub and the serving IWF. The I-XTunnel between the serviced IWF and the home IWF is relatively similar to the tunnel between the home agent and the foreign agent in the proposed IETF mobile IP standard. However, it also has additional features beyond the tunnels proposed by the Mobile IP standard. L2TP tunnels are only used when the home IWF is not a PPP server. The number of these tunnels can be reduced by combining several features within the same node, as previously explained.
【0224】
(v) In the present invention, wireless registration occurs before the PPP session is started, while in the proposed IETF mobile IP standard, mobile IP registration occurs after the PPP session enters its open state. appear. (vi) In the present invention, the network entity (ie, wireless hub) that publishes the agent's public information is not on a direct link to the end system, while in the case of the proposed IETF mobile IP standard. Must have a TTL of 1 which means that the agent's announcement has a direct link with the foreign agent. Moreover, agent publications in the systems of the invention are not extensions to ICMP router publications as in the proposed IETF mobile IP standard.
【0225】
The end system of the present invention needs to support the request of the agent. When an end system in the system of the invention visits a network that supports the proposed IETF mobile IP standard, it waits until it hears the agent's announcement. If the agent's announcement is not received within a reasonable time frame, the end system broadcasts the agent's request.
【0226】
In the present invention, the network operator negotiates with other networks that support the proposed IETF mobile IP standard and provides a home address for the end system of the present invention that wishes to use the other network. It can be made available for assignment. Upon receiving the agent's announcement, the end system of the system of the present invention will use its assigned home address to register because the network it is visiting is not a network according to the invention. You can know.
【0227】
For networks that support the proposed IETF mobile IP standard, PPP sessions are initiated prior to mobile IP registration and the PPP server is assumed to be co-located with foreign agents in such networks. To. In one embodiment, the SNAP header is used to encapsulate the PPP frame within the MAC frame of the system of the invention (in a manner similar to the Ethernet format), and the foreign agent uses this format for Ethernet. Interpret as a privately owned PPP format for encapsulation. Therefore, the end system of the system of the invention and its PPP peers can enter the open state before the foreign agent begins sending the agent's announcement, and the end system of the system of the invention can register. it can.
【0228】
In order for end systems that support the proposed IETF mobile IP standard to operate successfully in the type of network of the invention, such mobiles should be at least similar to MAC layer registration. Can be executed. By making the format of the agent's announcement message similar to the proposed mobile IP standard agent's announcement message format, the visiting end system interprets the agent's announcement and puts it on the wireless hub. You can register. In the present invention, the registration request and response messages are similar to the proposed registration request and response messages of the IETF Mobile IP standard (without unnecessary extensions) and are characteristic of the mobility management of the system of the present invention. The other part has become transparent to the end system you are visiting.
【0229】
End systems that support the proposed IETF mobile IP standard expect PPP sessions to begin prior to mobile IP registration, so an optional feature in the wireless hub of the system of the invention. Starts interpreting PPP LCP and NCP packets after registering the MAC layer. To avoid the loss of traffic during the handoff, the mobility management of the system of the present invention is based on the concept of make before break. For local mobility, make-before-break connections are achieved by turning the MAC layer registration message relayed by the new AP to the wireless hub into a broadcast message. In that way, the previous AP can hear about the new registration and forward packets destined for the end system that have not been forwarded to the new AP.
【0230】
In the case of micro-mobility, information about the new wireless hub is contained in the XTunnel destruction message exchanged between the serving IWF and the previous WH. In that way, the old radio hub can forward the buffered packets to the new radio hub when it hears the XTunnel discard message from the serving IWF. Instead, the RLP layer at IWF knows the sequence number previously acknowledged by the previous wireless hub.
【0231】
At the same time, IWF knows the current transmission sequence number of the latest packet sent to the previous wireless hub. Therefore, IWF can forward packets ordered between these two numbers to the new radio hub before sending the newer packet to the new radio hub. It is assumed that the RLP layer can filter duplicate packets. The second method is probably preferable to the first method because the previous wireless hubs may not be able to communicate directly with each other.
【0232】
In the case of macro mobility, the previous servicing IWF can forward packets from the previous radio hub to the new radio hub, as well as packets to the new servicing IWF. All you need to do is transfer the identity of the new servicing IWF to the new servicing IWF in the IXTunnel discard message. Another way to achieve the same result is to have the home IWF forward the missing packets to the new serving IWF instead of asking the previous serving IWF to do the job. It is a way to make it. This is because the home IWF knows the sequence number of the IX Tunnel that was recently acknowledged by the previous servicing IWF and the sequence number of the current IX Tunnel sent by the home IWF.
【0233】
A way to estimate how many buffers should be allocated per mobile, AP, wireless hub, IWF so that the loss of traffic during handoffs can be minimized is AP, wireless hub. , A method of having its end system estimate the arrival rate and handoff time of a packet to an IWF. This information is passed to the AP in front of the IWF's wireless hub and knows how much traffic should be forwarded to each new AP in that IWF's wireless hub at handoff.
【0234】
In order to achieve route optimization in the present invention, the end system selects the PPP server closest to the IWF in service. If routes are not optimized, transfer delays and physical line usage can be excessive. For example, an end system that subscribes to a home network in New York City can roam to Hong Kong. To establish a link to a Hong Kong ISP, End Systems has established an IWF servicing within a wireless hub in Hong Kong, and a home IWF within a home network in New York City. It will be. At that time, the message is forwarded from the end system (roamed to Hong Kong) and returned to the Hong Kong ISP through the serviced IWF (in Hong Kong) and the home IWF (in New York City).
【0235】
The preferred method is to connect directly to your Hong Kong ISP from the serviced IWF (in Hong Kong). The serviced IWF works the same as the home IWF. In this embodiment, a roaming contract exists between Home and Foreign's wireless provider. In addition, various accounting / billing systems will automatically communicate with each other to share billing information. The exchange of accounting and billing information can be implemented using standards such as those proposed by the IETF's ROAMOPS Working Group.
【0236】
However, the IWF in service still has to find the closest PPP server (eg Hong Kong ISP). In this embodiment, when the foreign registration server receives a registration request from the end system, it knows that the end system wants to connect to a PPP server (eg, an ISP in Hong Kong). When the foreign registration server finds that the IWF in service is closer to its desired PPP server (eg, an ISP in Hong Kong) than the home IWF, the foreign registration server is most likely to serve the IWF. Instructs the nearest PPP server (as opposed to the nearest PPP server and home IWF) to establish an L2TP tunnel to the home registration server. The foreign registration server then notifies the home registration server that its end system is being serviced by IWF and foreign PPP.
【0237】
In another embodiment, the foreign registration server receives a registration request from the end system that the IWF in service is closer to the desired PPP server than the home IWF (eg, an ISP in Hong Kong). know. The foreign registration server relays the registration request message to the home registration server with an additional message indicating the information of the IWF in service and the notification that the optimization of the route is preferable. At the same time, the foreign registration server instructs the IWF, which is servicing the PPP server to establish an L2TP tunnel. After approving the registration request, the home registration server instructs the home IWF to forward the L2TP status to the foreign IWF.
【0238】
Although described in preferred embodiments of new network architectures that allow wireless end users to roam, which are intended to give examples and are not limiting, they are proficient in the arts of this area. Please note that you can make changes and variants according to the above. For example, the connection links described here can make references to known connection protocols (eg, IP, TCP / IP, L2TP, IEEE 802.3, etc.). However, the system considers other connection protocols that provide the same or similar data delivery capabilities in the connection link. The agent operating in the above embodiments may be in the form of a software controlled processor or other form of control (eg, programmable logic array). Agents in operation are grouped as described above, or grouped in a different format, preserving the contents of the connection described here, and given the security and authentication content described here. Can be transformed into. In addition, a single access point, access hub (ie, wireless hub) or interworking function (IWF unit) can also provide multi-channel functionality. Therefore, a single access point or access hub or IWF unit can operate on traffic from multiple end systems and is described herein as a separate access point, access hub or IWF unit. Matters are equally considered for a single multichannel access point, access hub or IWF unit. Therefore, it should be understood that changes in certain embodiments of the disclosed system may be made without departing from the spirit and scope of the invention described in the appended claims.
【0239】
Although this system has been described in detail and as specifically required by patent law, what is claimed and desired to be protected by an open letter is described in the appended claims.
[Simple explanation of drawings]
[Figure 1]
It is a block diagram of a known remote access architecture through the public switched telephone network.
[Figure 2]
It is a block diagram of the remote access architecture through the wireless packet switching data network by this invention.
[Fig. 3]
It is a block diagram of a selected part of the network architecture of FIG. 2 showing a roaming scenario.
[Fig. 4]
It is a block diagram of the base station which has a local access point.
[Fig. 5]
It is a block diagram of the base station which has a remote access point.
[Fig. 6]
It is a block diagram of a base station equipped with remote access points, and some of the remote access points are connected using a wireless trunk connection.
[Fig. 7]
Diagram of the protocol stack for local access points.
[Fig. 8]
FIG. 5 is a diagram of a protocol stack for a remote access point with a wireless trunk line.
[Fig. 9]
It is a diagram of a protocol stack for a relay function in a base station to support a remote access point with a wireless trunk line.
[Fig. 10]
It is a diagram of the protocol stack for implementing the relay function shown in FIG.
[Fig. 11]
It is a diagram of a protocol stack for a base station relay function to support a local access point.
[Fig. 12]
A block diagram of selected parts of the network architecture in Figure 2, with the first end system registered from the home network to the home network and the foreign network using the home interworking feature as anchors. Shows the second system registered in the home network from.
[Fig. 13]
A block diagram of selected parts of the network architecture in Figure 2 that foreigners use the first end system registered from the home network to the home network and the interworking function they are servicing as anchors. -Indicates the second system registered from the network to the home network.
[Fig. 14]
A ladder diagram of request and response messages for registering from a foreign network to a home network, and for establishing, authenticating, and configuring data links.
[Fig. 15]
FIG. 2 is a block diagram of selected parts of the network architecture, showing registration requests and responses for registering mobiles in a home network from the home network.
[Fig. 16]
FIG. 2 is a block diagram of selected parts of the network architecture, showing registration requests and responses for registering mobiles in a home network from a foreign network.
[Fig. 17]
Diagram of a protocol stack showing communication between an end system in a home network and an interworking feature in a home network when the cell site has a local access point. Is.
[Fig. 18]
Communication between an end system in your home network and an interworking feature in your home network when the cell site has a remote access point that is coupled to a wireless hub through a wireless trunk line. It is a block diagram of the protocol stack which shows.
[Fig. 19]
It is a block diagram of a protocol stack showing communication between a base station coupled to a roaming end system and a home interworking function.
[Fig. 20]
It is a block diagram of a protocol stack showing communication with an end system in a home network to an Internet service provider through an interworking function in the home network.
[Fig. 21]
FIG. 5 is a configuration diagram of a protocol stack showing communication in the registration phase between an end system in a foreign network and a home registration server in a home network.
[Fig. 22]
It is a process flow diagram which shows the flow of processing accounting data and passing it to a customer's billing system.
[Fig. 23]
Ladder diagrams showing the registration process for end systems in the home network and in the foreign network, respectively.
[Fig. 24]
Ladder diagrams showing the registration process for end systems in the home network and in the foreign network, respectively.
[Fig. 25]
It is a diagram of a protocol stack showing the end system connections in the home network when the PPP protocol terminates in the interworking function of the home network and when the PPP protocol terminates in the ISP or intranet.
[Fig. 26]
It is a diagram of a protocol stack showing the end system connections in the home network when the PPP protocol terminates in the interworking function of the home network and when the PPP protocol terminates in the ISP or intranet.
[Fig. 27]
It is a diagram of a protocol stack showing the end system connections in a foreign network when the PPP protocol terminates in the interworking function of the foreign network and when the PPP protocol terminates in the ISP or intranet.
[Fig. 28]
It is a diagram of a protocol stack showing the end system connections in a foreign network when the PPP protocol terminates in the interworking function of the foreign network and when the PPP protocol terminates in the ISP or intranet.
[Fig. 29]
Indicates the end system connected to a wireless modem via Ethernet when the PPP protocol is encapsulated in an Ethernet frame.
[Fig. 30]
Indicates the format of the Ethernet frame.
[Fig. 31]
Indicates a field in the XWD header.
[Fig. 32]
Indicates the end system connected to the wireless router via the local area network when the PPP protocol terminates on the wireless router.
[Fig. 33]
A ladder diagram showing a local handoff scenario, a micro handoff scenario, and a macro handoff scenario, respectively.
[Fig. 34]
A ladder diagram showing a local handoff scenario, a micro handoff scenario, and a macro handoff scenario, respectively.
[Fig. 35]
A ladder diagram showing a local handoff scenario, a micro handoff scenario, and a macro handoff scenario, respectively.
[Fig. 36]
This is a ladder diagram showing a global handoff scenario when the foreign registration server changes and the home interworking function does not change.
[Fig. 37]
This is a ladder diagram showing a global handoff scenario when both the foreign registration server and the home interworking function change.
76 members in 7 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 60061915 | United States of America | – | |
| 6191597 | United States of America | P | |
| 13874498 | United States of America | A | |
| 09138744 | United States of America | – | – |
Members76
| Document | Office | Kind | |
|---|---|---|---|
| CA2249817A1 | Canada | A1 | |
| CA2249830A1 | Canada | A1 | |
| CA2249831A1 | Canada | A1 | |
| CA2249836A1 | Canada | A1 | |
| CA2249837A1 | Canada | A1 | |
| CA2249838A1 | Canada | A1 | |
| CA2249839A1 | Canada | A1 | |
| CA2249862A1 | Canada | A1 | |
| CA2249863A1 | Canada | A1 | |
| EP0910198A2 | European Patent Office (EPO) | A2 | |
| EP0912012A2 | European Patent Office (EPO) | A2 | |
| EP0912017A2 | European Patent Office (EPO) | A2 | |
| EP0912026A2 | European Patent Office (EPO) | A2 | |
| EP0912027A2 | European Patent Office (EPO) | A2 | |
| EP0917318A2 | European Patent Office (EPO) | A2 | |
| EP0917320A2 | European Patent Office (EPO) | A2 | |
| EP0917328A2 | European Patent Office (EPO) | A2 | |
| EP0918417A2 | European Patent Office (EPO) | A2 | |
| IL126513A0 | Israel | A0 | |
| IL126514A0 | Israel | A0 | |
| IL126515A0 | Israel | A0 | |
| IL126516A0 | Israel | A0 | |
| IL126517A0 | Israel | A0 | |
| IL126518A0 | Israel | A0 | |
| IL126519A0 | Israel | A0 | |
| IL126527A0 | Israel | A0 | |
| IL126528A0 | Israel | A0 | |
| EP0917318A3 | European Patent Office (EPO) | A3 | |
| JPH11252183A | Japan | A | |
| JPH11275154A | Japan | A | |
| JPH11275155A | Japan | A | |
| JPH11275156A | Japan | A | |
| JPH11275157A | Japan | A | |
| JPH11284666A | Japan | A | |
| JPH11289353A | Japan | A | |
| EP0918417A3 | European Patent Office (EPO) | A3 | |
| JPH11331276AThis record | Japan | A | |
| JP2000022758A | Japan | A | |
| AR013544A1 | Argentina | A1 | |
| AR015959A1 | Argentina | A1 | |
| AR015960A1 | Argentina | A1 | |
| AR016408A1 | Argentina | A1 | |
| AR016409A1 | Argentina | A1 | |
| AR017327A1 | Argentina | A1 | |
| AR020046A1 | Argentina | A1 | |
| US6377982B1 | United States of America | B1 | |
| US6393482B1 | United States of America | B1 | |
| US6400722B1 | United States of America | B1 | |
| US6414950B1 | United States of America | B1 | |
| US2002089958A1 | United States of America | A1 | |
| US6421714B1 | United States of America | B1 | |
| US6512754B2 | United States of America | B2 | |
| CA2249817C | Canada | C | |
| US6577643B1 | United States of America | B1 | |
| CA2249863C | Canada | C | |
| CA2249830C | Canada | C | |
| US6665718B1 | United States of America | B1 | |
| US6675208B1 | United States of America | B1 | |
| CA2249837C | Canada | C | |
| EP0917318B1 | European Patent Office (EPO) | B1 | |
| EP0910198A3 | European Patent Office (EPO) | A3 | |
| EP0912017A3 | European Patent Office (EPO) | A3 | |
| EP0917320A3 | European Patent Office (EPO) | A3 | |
| DE69830223D1 | Germany | D1 | |
| EP0912026A3 | European Patent Office (EPO) | A3 | |
| EP0917328A3 | European Patent Office (EPO) | A3 | |
| EP0912012A3 | European Patent Office (EPO) | A3 | |
| EP0912027A3 | European Patent Office (EPO) | A3 | |
| CA2249836C | Canada | C | |
| CA2249862C | Canada | C | |
| DE69830223T2 | Germany | T2 | |
| EP0917320B1 | European Patent Office (EPO) | B1 | |
| DE69837136D1 | Germany | D1 | |
| DE69837136T2 | Germany | T2 | |
| EP0912026B1 | European Patent Office (EPO) | B1 | |
| DE69840955D1 | Germany | D1 |
Numbers
- Publication
- 11-331276
- Application
- 10306447
Titles2
- Japanese
- ネットワークのための登録方法
- English
- [Title of Invention] Registration method for network
Classification
- CPC, 12
- H04W4/24
- H04L12/4633
- H04W8/12
- H04W36/0038
- H04W80/04
- H04W88/182
- H04L2212/00
- H04W12/02
- H04W12/06
- H04W12/033
- H04L63/0281
- H04L9/40
- IPC, 12
- H04M3 42
- H04L12 14
- H04L12 28
- H04L12 46
- H04L12 56
- H04L12 66
- H04L29 06
- H04W4 24
- H04W8 12
- H04W36 14
- H04W80 04
- H04W88 18