(57)【特許請求の範囲】
【請求項１】
移動端末が、ＷＬＡＮアクセス・ネットワークから、前記移動端末のホーム・ドメイン・ネットワークで提供されるサービス、又は前記ホーム・ドメイン・ネットワークを経由してサービス・プロバイダ・ネットワークで提供されるサービスにアクセスする場合であって、
前記移動端末が、前記ＷＬＡＮアクセス・ネットワークに接続する接続ステップと、
前記移動端末が、要求するサービスにアクセスするためのサービス要求識別子と前記移動端末の識別子とを含むトンネル開設リクエストメッセージを、前記ＷＬＡＮアクセス・ネットワークから前記ホーム・ドメイン・ネットワークに配置されるホーム・ドメイン・サーバへ送信する送信ステップと、
前記ホーム・ドメイン・サーバは、前記トンネル開設リクエストメッセージを受信し、前記サービス要求識別子と前記移動端末の識別子とに基づき、前記移動端末が要求するサービスへアクセスするためのアドレスを割り当てる割り当てステップと、
を有するアドレス管理方法。
【請求項２】
前記割り当てステップが、前記ホーム・ドメイン・サーバが、前記トンネル開設リクエストメッセージを受信した後、かつ前記アドレスを割り当てる前に、ユーザの加入者情報に基づいて、前記移動端末が要求するサービスへのアクセスを許可すべきかを決定する決定ステップを更に有する請求項１に記載のアドレス管理方法。
【請求項３】
前記決定ステップにおいて、前記ホーム・ドメイン・サーバが、前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワーク内のノードへ問い合わせを行う請求項２に記載のアドレス管理方法。
【請求項４】
前記問い合わせを受けた前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワークのノードが、前記移動端末が要求するサービスへアクセスするための前記アドレスを割り当て、前記アドレスを前記ホーム・ドメイン・サーバに提供する請求項３に記載のアドレス管理方法。
【請求項５】
前記ホーム・ドメイン・サーバが、前記ＷＬＡＮアクセス・ネットワークと前記ホーム・ドメイン・サーバを接続するＷＬＡＮサーバとの間でＱｏＳに関する調整を行う調整ステップを更に有する請求項１に記載のアドレス管理方法。
【請求項６】
前記ＱｏＳに関する調整が、ネットワーク・ドメインのポリシーを制御するポリシー・サーバを経由して行なわれる請求項５に記載のアドレス管理方法。
【請求項７】
前記移動端末が、前記ホーム・ドメイン・ネットワークの情報に基づいて前記ホーム・ドメイン・サーバのアドレスを取得する取得ステップを更に有する請求項１に記載のアドレス管理方法。
【請求項８】
前記ホーム・ドメイン・サーバが、前記割り当てたアドレスを前記移動端末に送信するアドレス送信ステップを更に有する請求項１に記載のアドレス管理方法。
【請求項９】
移動端末及びホーム・ドメイン・サーバを備え、前記移動端末が、ＷＬＡＮアクセス・ネットワークから、前記移動端末のホーム・ドメイン・ネットワークで提供されるサービス、又は前記ホーム・ドメイン・ネットワークを経由して、サービス・プロバイダ・ネットワークで提供されるサービスにアクセスするアドレス管理システムであって、
前記移動端末は、
前記ＷＬＡＮアクセス・ネットワークに接続する接続部と、
要求するサービスにアクセスするためのサービス要求識別子と前記移動端末の識別子とを含むトンネル開設リクエストメッセージを、前記ＷＬＡＮアクセス・ネットワークから前記ホーム・ドメイン・ネットワークに配置される前記ホーム・ドメイン・サーバへ送信する送信部とを、
有し、
前記ホーム・ドメイン・サーバは、
前記トンネル開設リクエストメッセージを受信し、前記サービス要求識別子と前記移動端末の識別子とに基づき、前記移動端末が要求するサービスへアクセスするためのアドレスを割り当てる割り当て部を、
有するアドレス管理システム。
【請求項１０】
前記割り当て部が、前記トンネル開設リクエストメッセージを受信した後、かつ前記アドレスを割り当てる前に、ユーザの加入者情報に基づいて、前記移動端末が要求するサービスへのアクセスを許可すべきかを決定する決定部を更に有する請求項９に記載のアドレス管理システム。
【請求項１１】
前記決定部が、前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワーク内のノードへ問い合わせを行う請求項１０に記載のアドレス管理システム。
【請求項１２】
前記問い合わせを受けた前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワーク内のノードが、前記移動端末が要求するサービスへアクセスするための前記アドレスを割り当て、前記アドレスを前記ホーム・ドメイン・サーバに提供する請求項１１に記載のアドレス管理システム。
【請求項１３】
前記ホーム・ドメイン・サーバが、前記ＷＬＡＮアクセス・ネットワークと前記ホーム・ドメイン・サーバを接続するＷＬＡＮサーバとの間でＱｏＳに関する調整を行う調整部を更に有する請求項９に記載のアドレス管理システム。
【請求項１４】
前記ＱｏＳに関する調整が、ネットワーク・ドメインのポリシーを制御するポリシー・サーバを経由して行なわれる請求項１３に記載のアドレス管理システム。
【請求項１５】
前記移動端末が、前記ホーム・ドメイン・ネットワークの情報に基づいて前記ホーム・ドメイン・サーバのアドレスを取得する取得部を更に有する請求項９に記載のアドレス管理システム。
【請求項１６】
前記ホーム・ドメイン・サーバが、前記割り当てたアドレスを前記移動端末に送信する送信部を更に有する請求項９に記載のアドレス管理システム。
【請求項１７】
ＷＬＡＮアクセス・ネットワークから、前記移動端末のホーム・ドメイン・ネットワークで提供されるサービス、又は前記移動端末のホーム・ドメイン・ネットワークを経由してサービス・プロバイダ・ネットワークで提供されるサービスにアクセスする移動端末であって、
前記ＷＬＡＮアクセス・ネットワークに接続する接続部と、
要求するサービスにアクセスするためのサービス要求識別子と前記移動端末の識別子とを含むトンネル開設リクエストメッセージを、前記ＷＬＡＮアクセス・ネットワークから前記ホーム・ドメイン・ネットワークに配置されるホーム・ドメイン・サーバへ送信する送信部とを、
有する移動端末。
【請求項１８】
前記ホーム・ドメイン・ネットワークの情報に基づいて前記ホーム・ドメイン・サーバのアドレスを取得する取得部を更に有する請求項１７に記載の移動端末。
【請求項１９】
前記ホーム・ドメイン・サーバから、前記サービス要求識別子と前記移動端末の識別子とに基づいて、前記移動端末が要求するサービスへアクセスするために割り当てられたアドレスを受信する受信部を更に有する請求項１７に記載の移動端末。
【請求項２０】
ＷＬＡＮアクセス・ネットワークから、前記移動端末のホーム・ドメイン・ネットワークで提供されるサービス、又は前記ホーム・ドメイン・ネットワークを経由してサービス・プロバイダ・ネットワークで提供されるサービスにアクセスする移動端末の前記ホーム・ドメイン・ネットワークに配置されるホーム・ドメイン・サーバであって、
前記移動端末が要求するサービスにアクセスするためのサービス要求識別子と前記移動端末の識別子とを含むトンネル開設リクエストメッセージを前記移動端末から受信し、前記サービス要求識別子と前記移動端末の識別子とに基づき、前記移動端末が要求するサービスへアクセスするためのアドレスを割り当てる割り当て部を有するホーム・ドメイン・サーバ。
【請求項２１】
前記割り当て部が、前記トンネル開設リクエストメッセージを受信した後、かつ前記アドレスを割り当てる前に、ユーザの加入者情報に基づいて、前記移動端末が要求するサービスへのアクセスを許可すべきかを決定する決定部を更に有する請求項２０に記載のホーム・ドメイン・サーバ。
【請求項２２】
前記決定部が、前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワーク内のノードへ問い合わせを行う請求項２１に記載のホーム・ドメイン・サーバ。
【請求項２３】
前記問い合わせにより割り当てられた、前記移動端末が要求するサービスへアクセスするためのアドレスを、前記ホーム・ドメイン・ネットワーク内のノード、又は前記サービス・プロバイダ・ネットワーク内のノードから受信するアドレス受信部を有する請求項２２に記載のホーム・ドメイン・サーバ。
【請求項２４】
前記ＷＬＡＮアクセス・ネットワークと前記ホーム・ドメイン・サーバを接続するＷＬＡＮサーバとの間でＱｏＳに関する調整を行う調整部を更に有する請求項２０に記載のホーム・ドメイン・サーバ。
【請求項２５】
前記ＱｏＳに関する調整が、ネットワーク・ドメインのポリシーを制御するポリシー・サーバを経由して行なわれる請求項２４に記載のホーム・ドメイン・サーバ。
【請求項２６】
前記割り当てたアドレスを前記移動端末に送信するアドレス送信部を更に有する請求項２０に記載のホーム・ドメイン・サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線データ通信の分野に関する。また特に、本発明は、他のネットワークから訪れるモバイル・ユーザのための無線ＬＡＮ環境におけるアドレス管理あるいはトンネリングの設定に関し、ＷＬＡＮが、例えば、３Ｇネットワーク又は他の無線技術を使用するＷＬＡＮなどの別の管理ドメイン内に存在する公衆無線ネットワークとの相互接続（inter-networking）を行う際に使用可能なものである。本発明は、移動端末と同様、ＷＬＡＮ及び相互接続ネットワーク（inter-worked network）によって、アドレス割り付け、構成、トンネリングの設定などに使用可能である。その結果、移動端末はＷＬＡＮにおいて加入したサービスにアクセス可能となる。
【背景技術】
【０００２】
ＷＬＡＮ相互接続（WLAN inter-working）では、端末が加入したすべてのサービスにアクセスすることができるように、端末はアドレス付けが可能（addressable）である必要がある。サービスがＩＰを超えて伝送される場合、端末は、あるＩＰアドレスに関連付けられているはずである。モバイルの世界では、端末の接続点が頻繁に変わり、端末があるアクティブなサービス・セッションの間に、いくつかのドメインを渡り歩くことは非常にあり得ることである。端末の移動性の要件を満たすために、アドレス管理のメカニズムには、端末が接続点を変更するごとに、端末のアドレスを形成し更新することが要求される。
【０００３】
モバイルＩＰは、インターネット技術検討委員会（ＩＥＴＦ）で公開されている標準化技術であり（非特許文献１）（非特許文献２）、移動端末のためのアドレス管理とトラフィックのルーティングに対する解決策を提供する。それによって、ユーザは、様々なＩＰネットワーク内を動き回る場合に、同一のアドレスを使用しながら到達可能な状態であることが可能となる。移動性がＩＰレベルで管理されるので、モバイルＩＰは、基礎となるリンク層の技術に束縛されない。したがって、３Ｇのセルラ・ネットワーク、又は無線ＬＡＮ（例えば、８０２．１１のネットワーク）内の端末に対して、同一のプロトコル・スタックが適用可能である。例えば、ＷＬＡＮと３Ｇのセルラ・ネットワークとの相互接続など、アクセス技術の融合で、この種の調和したレベルの解決策は、特に有効である。
【０００４】
モバイルＩＰでは、ＩＰ接続によってアドレス管理が行われ、ＩＰ接続が利用可能でない場合には、動作不能であった。また、さらに、モバイルＩＰでは、端末が、ホーム・アドレスを有し、かつ、そのホーム・エージェントを知っている必要がある。これは、例えば、端末が最初にフォーリンＷＬＡＮで動作を開始する場合など、相互接続の動作過程では得られないかもしれない。
【０００５】
モバイルＩＰｖ６のドラフトでは、移動ノード（mobile node）のホーム・アドレスのセッティング方法が導入されている（非特許文献２）。端末は、例えば、ＤＨＣＰｖ６（非特許文献３）を使って、まず、気付アドレス（Care of address）を最初に生成し、このアドレスを使用してホーム・ネットワークとの通信を行って最終ホーム・アドレスを設定する。しかし、ＷＬＡＮから得られた気付アドレスを使用した場合には、移動ノードのホーム・ネットワークが必ずしも到達可能になるとは限らないので、ＷＬＡＮ相互接続においては、これは動作不可能である。さらに、複数回のやり取りを行うコンフィギュレーション処理は、時間を消費するものであり、ユーザの期待に沿うものではない。
【０００６】
また、ダイアメータ・モバイルＩＰｖ６の適応（非特許文献４）は、モバイルＩＰｖ６のアドレス管理のためのＡＡＡの構成に基づいた解決策を示した。この解決策では、ＡＡＡサーバと移動先及びホーム・ネットワークのクライアントとが利用され、アドレス更新及びエージェント発見が実行される。そのメカニズムでは、移動ノードは、例えば、ルータ・アドバタイズメント・メッセージを聞くことができるなど、メッセージ交換用のローカルＩＰ接続を有することが要求される。しかし、これは、必ずしもフォーリン・ドメインのローカル・ポリシーよって可能であるとは限らない。
【０００７】
さらに、この機構は、移動端末のホーム・ドメインにアドレスが属する状況でのみ提供されるものかもしれないが、ＷＬＡＮ相互接続では、端末がアクセスしているサービスに依存する別のドメインからのアドレスを使用することになる。したがって、端末は、サービス・リクエストの情報を持たないので、これは、この機構ではサポートされ得ない。この機構は、モバイルＩＰｖ６環境のために設計されており、したがってモバイルＩＰスタックのない端末では動作不可能である。
【０００８】
さらに、３ＧＰＰによって解決策、端末のアドレシングとトンネリングとを管理するためのＧＴＰ（非特許文献５）が提供された。ＧＴＰは、コントロール用のＧＴＰＣ、及び、ユーザ・データのトラフィック用のＧＴＰ−Ｕの２つのパートを有している。ＧＴＰは、ＵＤＰ上で動作し、ＵＤＰパケット中のユーザ・データをカプセル化する。ＧＴＰは、ＧＰＲＳ（非特許文献６）ネットワーク用に設計されており、例えば、ＧＧＳＮ、ＳＧＳＮノードなど、極度にＧＰＲＳネットワークの特徴に依存する。これによって、単純な無線のアクセス・ネットワーク（例えば、ＷＬＡＮ）での展開が困難となる。
【非特許文献１】「IP mobility support for IPv4」  http://www.ietf.org/rfc/rfc3344.txt
【非特許文献２】「Mobility support in IPv6」  http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt
【非特許文献３】「Dynamic Host Configuration Protocol for IPv6 (DHCPv6)」  http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt
【非特許文献４】「Diameter Mobile IPv6 Application」  http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt
【非特許文献５】「GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (Release 5)」  3GPP TS 29.060 V5.3.0 (2002-09)  ftp://ftp.3gpp.org/Specs/archive/29_series/
【非特許文献６】「General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)」  3GPP TS 23.060 V5.2.0 (2002-06)  ftp://ftp.3gpp.org/Specs/archive/23_series/
【非特許文献７】「IP Multimedia Subsystem (IMS); Stage 2 (Release 5)」  3GPP TS 23.228 V5.6.0 (2002-09)  ftp://ftp.3gpp.org/Specs/archive/23_series/
【非特許文献８】「Diameter Base Protocol」  http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt
【非特許文献９】「PPP Extensible Authentication Protocol (EAP)」  http://www.ietf.org/rfc/rfc2284.txt
【非特許文献１０】3GPP project  http://www.3gpp.org
【非特許文献１１】3GPP2 project  http://www.3gpp2.org
【非特許文献１２】「The Network Access Identifier」  http://www.ietf.org/rfc/rfc2486.txt
【非特許文献１３】「Numbering, addressing and identification (Release 5)」  3GPP TS 23.003 V5.3.0 (2002-06)  ftp://ftp.3gpp.org/Sepcs/archive/23_series/
【非特許文献１４】「Port-Based Network Access Control」  IEEE Std 802.1X-2001  http://standards.ieee.org/getieee802/
【非特許文献１５】「Diameter Extensible Authentication Protocol (EAP) Application」  http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt
【非特許文献１６】「Diameter NASREQ Application」  http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt
【非特許文献１７】「IPv6 Stateless Address Autoconfiguration」  http://www.ietf.org/rfc/rfc2462.txt
【発明の開示】
【発明が解決しようとする課題】
【０００９】
通常、ＷＬＡＮと相互接続ネットネットワークとは、異なる管理ドメインに存在し、これは、アドレス空間が別々に管理されていることを意味している。したがって、移動端末が、そのホーム・ネットワークとは異なるドメインのＷＬＡＮに動いた場合、何らかのアドレス構成を実行し、端末に連続的なサービス配送を保証しなければならない。このアドレス構成は、例えば、ＩＰアドレス割り付け、アドレス登録、トンネリングの設定などを含み得るものである。
【００１０】
ＷＬＡＮ間において端末に配送される任意のサービスを行うために、アドレス登録が適用される。例えば、ＷＬＡＮから３Ｇネットワーク内のＩＭＳ（非特許文献７）サービスへのアクセスのためには、端末がＩＭＳを提供するネットワークに属するアドレスを有する必要があり、結果的に、異なるサービスへの並列のアクセスを行う移動端末は、複数のＩＰアドレスが割り当てられることが要求される。
【００１１】
ＷＬＡＮでは、認証及びその許可が与えられる前に、端末が、例えば、通常のデータ・パケットを送受信するなど、いかなるリソースを使用することも許されていない。例えば ＭＩＰｖ６の中で示唆されるような通常の機構では、認可処理の成功後にアドレスの構成が起こるかもしれないが、この種のアプローチは遅く、サービスのうちのいくつかの要件を満たすことができない。許可の前にアドレスを割り当てるために、適切な情報がアクセス・コントロール・メッセージに統合される必要がある。アドレス管理は通常、ユーザの加入情報に基づき、したがって、移動端末のホーム・ネットワークによって、管理される必要がある。また、任意の外部サービスのためには、ホーム・ネットワーク以外のドメインから、アドレスを割り当てる必要がある。この場合、ホーム・ネットワークがアドレス割り当てやそのドメインが有する他の情報に関するやり取りを行えるメカニズムが必要となる。
【００１２】
端末がアドレスを変更する場合、その端末に関連した端末間のＱｏＳが影響されることになる。例えば、もしアドレスが変わった場合には、送信元アドレス又は送信先アドレスの情報に基づくトラフィック・フィルタは、流れを正確に分類することは不可能となる。ファイア・ウォールや他のトラフィック・コントロール機能を実施するＷＬＡＮについては、さらに、端末の新しいアドレスが示される必要があり、そうでなければ、トラフィックは妨げられるか、又は、中断され得ることとなる。
【課題を解決するための手段】
【００１３】
端末がＷＬＡＮに入った場合、端末は、認証処理及び許可処理を完結して、リソースへのアクセスを得なければならない。本発明では、アクセス・コントロール・メカニズムに統合されるアドレス管理への解決策が示される。この統合によって、アクセスを許可と同時に、端末のアドレスの割り当てが行われることが可能である。また、端末は、アクセス・コントロール・メカニズムを再使用して拡張し、したがってどんな新しいプロトコルを実施する必要もない。アドレスの構成処理は、アクセス・コントロール処理の固有の暗号化及び保護によって守られ、したがって、余分なセキュリティの設定を必要としない。
【００１４】
また、本発明は、さらに、端末のホーム・ネットワークが端末のサービスを提供するネットワークとアドレス管理の取り決めを行うための手段を提供する。この種のやり取りは、バック・エンド・プロセスであり、移動端末とＷＬＡＮには明らかなもの（transparent）である。やり取りの結果は、サービス許可処理を使用して、ＷＬＡＮ及び移動端末に運ばれる。並列のアクセス・セッションが同一の端末に存在する場合には、複数のアドレスを要求することも可能である。
【００１５】
また、本発明は、きめ細かいサービス認可処理を使用して、端末がセッションに関連するアドレスを取得すべき方法を提供する。各セッションは、それに関連付けられたアドレスを使用して、新しいアドレスへの遷移が許可される。
【００１６】
また、アドレス管理もポリシー・コントロール・メカニズムに統合される。ポリシー・コントロールは、アドレス交替の後に必要な場合に、ＷＬＡＮを構成するための端末及びそのホーム・ネットワークの手段を提供する。ＱｏＳ、又は、トンネリングの情報は、既存のポリシー・コントロール処理で利用可能なチャンネルを使用して、新しいステータスに従って修正され、供給される。これによって、ローミング時間においてスムーズな遷移を達成することが可能となり、ＱｏＳの中断を最小限に抑えることが可能となる。
【発明の効果】
【００１７】
本発明は、ローカルネットワーク相互接続におけるトンネルの設定のコントロール方法を提供する。ここでは、移動端末は、サービス許可と同時にネットワーク及びクライアントに基づくトンネルの設定をサポートする。与えられるインターフェースを用いて、サービス許可、アドレス割り当て、及び、情報をセットするトンネルをポリシー・サーバに伝播することが可能となり、よりよく端末にサービスを配信するために適切な動作を行うことが可能となる。すべての方法において、端末とそのホーム・ネットワーク・サーバとの１回の往復メッセージの交換で、アドレス管理、トンネルの設定及びサービスの許可を達成することが可能である。したがって、貴重なシグナリングの時間や帯域幅が節約される。
【発明を実施するための最良の形態】
【００１８】
本発明は、ＷＬＡＮが他のネットワークと相互接続（inter-work）するために使用されるものである。相互接続されたネットワークとしては、別のＷＬＡＮ又は公衆セルラ・ネットワークが可能であり、この両方の場合に、本発明を容易に展開させることが可能である。本発明は、アドレス管理、及び、アドレスの遷移（つまり、モビリティ・コントロール）に適切なサービス提供を目的として使用されるものである。
【００１９】
提案された機構（スキーム）の適用では、特別なインターフェースやプロトコルを実施する必要はない。この機構は、既存のアクセス・コントロール・メカニズムを再使用し、必要な機能性を支援するために、その属性のうちのいくつかを拡張する。アドレス割り付けでは、その修正がサービス許可手続きに統合される。許可手続きが、認証から得られた信頼によって暗号化され保護されるので、アドレス情報も同一のセキュリティ・レベルで保護され、許可情報の一部として示されて、通常の許可情報と同一の方法で転送可能となる。例えば、ＡＶＰに特有の許可としてダイアメータ（非特許文献８）に含まれたり、許可にＥＡＰ方法が利用可能な場合にはＥＡＰ（非特許文献９）の属性として含まれたりすることが可能である。
【００２０】
端末がＷＬＡＮに入った場合には、サービスを利用することが認められる前に、認証及び許可が行われる。許可手続きでは、端末が、アクセスしようとするサービスを要求し、この情報はＷＬＡＮを通じて端末のホーム・ネットワークに渡される。端末のホーム・ネットワークは、ユーザの加入者プロフィールに基づいてサービスを許可すべきか否かを決定する。要求されたサービスに依存して、端末のホーム・ネットワークは、さらにサービスに使用されるアドレスを決定する。例えば、ＩＭＳサービスについては、アドレスはＩＭＳアドレス空間から割り当てられる必要があり、一方、ローカルＷＬＡＮサービスについては、ローカルで取得されたアドレスで十分である。さらに、アドレス管理に関連するトンネリングの情報が識別される。
【００２１】
アドレス情報は許可情報に含まれ、許可成功メッセージと共に送られる。この情報の一部は、ＷＬＡＮに届き、一部は、通常の許可手続きと同様、端末に届く。例えば、端末が端末自体のアドレス構成を行えるように、アドレスを端末へ送る必要がある。また、もしネットワーク・トンネリングが必要な場合には、ＷＬＡＮによって、トンネリングの情報が使用される。
【００２２】
アドレスの変更が必要な場合には、再許可手続きは、サービス許可の詳細な手続きを行わずに、迅速な更新を使用することが可能である。端末がサービスへのアクセスを開始した場合、ポリシー・コントロールが引き起こされ、アドレス情報は端末のホーム・ネットワークでポリシー・サーバによって利用可能となり、その後、ポリシー・サーバは、ポリシー決定をアドレス情報に基づいて行うことが可能となる。アドレスが変わると、ポリシー・サーバに対して、対応するポリシーを更新するよう通知が行われ、その結果、ＱｏＳ及びサービス提供が保証される。
【００２３】
発明の理解を支援するため、次の定義が使用される。
「ＷＬＡＮ」は、無線のローカル・エリア・ネットワークを指すものであり、無線技術を通じて移動端末にＬＡＮサービスを提供するために、任意の数の装置を含むものである。
「３Ｇネットワーク」は第３世代の公衆アクセス・ネットワークを指すものであり、例えば、３ＧＰＰ（非特許文献１０）や３ＧＰＰ２（非特許文献１１）によって定義されるシステムである。
【００２４】
「移動端末」は、無線技術によってＷＬＡＮ及び他のネットワークによって提供されるサービスへのアクセスに使用される装置を指すものである。
「ホーム・ネットワーク」は、移動端末（ＭＴ）のサービス加入情報が格納されているネットワークを指すものであり、相互接続のシナリオでは、ＭＴが最初に加入したネットワーク、又は、ＭＴの加入情報に完全にアクセスすることが許可されている訪問先のネットワークであり得る。
「サービス・プロバイダ・ネットワーク」は、ＭＴが要求したサービスが提供されるネットワークを指すものであり、例えば、ホーム・ネットワーク、ＷＬＡＮ、外部ネットワークなど、任意のネットワークが可能である。
【００２５】
「ネットワーク・エレメント」は、情報処理を実行することが可能なネットワーク内で機能している任意の装置を指すものである。
「ポリシー・サーバ」は、ネットワーク・ドメインのポリシー・コントロール機能を実行するネットワーク・エレメントを指すものである。ポリシー・コントロール機能は、例えば、ローカルのリソース配分、パケット・フィルタの更新、ルーティングの更新などを含んでいる。「エア・インターフェース」は、移動端末がＷＬＡＮにアクセスするための任意の無線アクセス技術を指すものである。
【００２６】
「ストリーム」は、ある属性を共通に持っているネットワーク内で転送されるパケットの集まりである。
「トラフィック」は、ネットワーク内で転送されるストリームの集まりである。
「フロー」は、データ・パス、及び、ストリームを伝送するために使用されるデータ・パスに必要とされるネットワーク・リソースを指すものである。
「ＱｏＳ」は、データ・ストリーム又はトラフィックのサービス品質（Quality of Service）の用語を指すものである。
「メッセージ」は、相互接続をコントロールする目的で、ネットワーク・エレメント間で交換される情報を指すものである。
【００２７】
「オペレーション・シーケンス」は、相互接続コントロールのために、任意のネットワーク・エレメント間での一連のメッセージ交換を指すものである。
「上位レイヤ」は、現在のエンティティの上に存在し、現在のエンティティから渡されたパケットを処理するすべてのエンティティを指すものである。
「クライアントに基づくトンネル」は、トンネルの終点のうちの１つが移動端末であるトンネリング機構を指すものである。
「ネットワークに基づくトンネル」は、トンネルの終点が移動端末以外のネットワーク・エレメントに存在するトンネリング機構を指すものである。
【００２８】
以下の記述では、本発明を完全に理解するための説明において、具体的な数、時間、構造、プロトコルの名前、その他のパラメータが使用されるが、このような具体的な詳述がなくても、本発明の実施が可能なことは当業者にとって明白である。また、他の事例では、よく知られた構成要素やモジュールが、本発明を不必要に不明瞭なものとしないようブロック図で示される。
【００２９】
端末が高度に移動性を有するという特性により、モビリティ・コントロールは、ＷＬＡＮ相互接続における最も顕著な問題のうちの１つである。端末が移動する場合、接続点に局所的でないアドレスを使用するよう強制することが可能である。例えば、ＷＬＡＮに入り込んだ３Ｇ端末に関しては、そのホーム・ネットワークのサービス（例えば、ＩＭＳサービス）にアクセスするためには、３Ｇドメインのアドレスが必要とされる。端末が、３Ｇネットワーク内にあるサービスを開始した場合、アドレスは、例えば、ＧＰＲＳサービス（非特許文献６）などの３Ｇのスキームに従って割り当てられ、このアドレスは、端末の３Ｇセルラ・インターフェースに結び付けられる。
【００３０】
端末がＷＬＡＮドメインに入る場合、高いスループットを実現することができるので、そのＷＬＡＮインターフェースを使用して通信することが望まれる。例えば、２重のインターフェース（ＧＰＲＳ及びＩＥＥＥ８０２．１１）を備えたＰＤＡは、道路上ではＧＰＲＳインターフェースを使用し、ホット・スポット内ではＩＥＥＥ８０２．１１インターフェースを使用することを要望するであろう。３ＧサービスにアクセスするＷＬＡＮインターフェースを使用する場合、端末は３Ｇインターフェースから得られたものと同一のアドレスを使用し続ける必要がある。そうでなければ、端末はサービス中断に直面し、セッションを再度初期設定しなければならない。これは、ユーザにとって望ましいことではない。使用中のアドレスがＷＬＡＮに局所的ではないので、トンネルは、端末からサービス・プロバイダ・ネットワークまで設定されなくてはならない。
【００３１】
図１には、アドレス割り付けとトンネルのセット・アップのための本発明の実施例が示されている。なお、混乱を避けるため、シグナリングに参加するネットワーク・エンティティのみが図示されている。移動端末（１０１）はネットワークからあるサービスを要求するエンティティである。実世界では、例えば、Bluetoothリンクによってラップトップ・コンピュータに接続されたハンドセットなどのように、いくつかのエンティティを有することが可能であるが、単純化のため、図１には１つのセットとして描かれている。
【００３２】
ＷＬＡＮ機能（WLAN function）（１００１）内において、アクセス・ポイント（１０５）は移動端末（１０１）に対してＷＬＡＮアクセスを提供するエンティティである。それがＷＬＡＮサービスを利用するために許可されるまで、アクセス・ポイント（１０５）は、移動端末（１０１）からのデータ・トラフィックをすべて遮断するが、ある特定のデータ・パケットのみを許可するコントロール・チャンネルは、アクセス・コントロール・シグナリングを行うため開いた状態（open）となる。移動端末（１０１）は、無線リンク（１０１１）を通じてアクセス・ポイント（１０５）と通信を行う。このリンクとして、例えば、ＩＥＥＥ８０２．１１、ＨｉｐｅｒＬＡＮ／２、赤外線などを始め、どのような種類の無線技術を使用することも可能であり、同様のアクセス・コントロール技術が適用可能な場合には、このリンクにおいて、例えば光ファイバなどの他の技術を使用することを排除するものではない。
【００３３】
また、ＷＬＡＮ管理サーバ（ＷＬＡＮサーバ）（１０２）が、ＷＬＡＮ内の別のエンティティとして存在している。このＷＬＡＮサーバ（１０２）は、アドレス空間の管理とＷＬＡＮのリソース管理とを担当しており、ＷＬＡＮのゲートウェイ上に存在するか、単純なＷＬＡＮではアクセス・ポイント（１０５）に共設されている。ＷＬＡＮサーバ（１０２）は、インターフェース（１０１５）を介して、アクセス・ポイント（１０５）と通信を行う。これは、例えばエア・インターフェースを介するＱｏＳの管理など、ＷＬＡＮリソース・コントロールやサービス提供のためのものである。ＷＬＡＮを管理するため、サーバは、例えば、不図示のＷＬＡＮゲートウェイやファイア・ウォールなど、ＷＬＡＮの他のエンティティと相互に作用する。
【００３４】
端末のホーム・ネットワーク（１００２）では、ホーム・ネットワーク・オーソライザ（Home Network Authorizer）（１０３）がサービス許可及びアドレス割り付けの管理を行う。アクセス・ポイント（１０５）及びＷＬＡＮサーバ（１０２）は両方とも、リンク（１０１２）及びリンク（１０１４）を介して、サービス制御情報のためにホーム・ネットワーク・オーソライザ（１０３）とそれぞれ通信を行う。物理的に、リンク（１０１２）及びリンク（１０１４）を同一とすることも可能であり、すなわち、同一のプロトコルを使用し、同一の端末間で、同一のパケットにカプセル化された場合でも、それらは、論理上分離される。
【００３５】
移動端末（１０１）は、それが加入しているすべてのサービスを要求することが可能である。これらのサービスは、ホーム・ネットワーク（１００２）、個別のサービス・プロバイダ・ネットワーク（１００３）、又は、ＷＬＡＮ自体にあるかもしれない。サービスが、ホーム・ネットワーク（１００２）又はＷＬＡＮによって提供される場合、サービス・プロバイダ・ネットワーク（１００３）は、これらのネットワークとオーバラップすることになる。したがって、コントロール機能を両方に結び付けることが可能となる。
【００３６】
サービス・プロバイダ・ネットワーク管理サーバ（サービス・プロバイダ・ネットワーク・サーバ）（１０４）は、サービス許可及びサービス・プロバイダ・ネットワーク（１００３）のアドレス割り付けを管理する。ホーム・ネットワーク・オーソライザ（１０３）は、コントロール・インターフェース（１０１３）を介して、サービス・プロバイダ・ネットワーク・サーバ（１０４）と通信を行う。実際には、サービス・プロバイダ・ネットワーク（１００３）として、ＷＬＡＮ、ホーム・ネットワーク（１００２）又は別のネットワークを用いることが可能である。また、サービスが、ホーム・ネットワーク（１００２）で提供される場合には、このインターフェースは内部インターフェースとなり、正確なフォーマットや、後述の実施例に記述されるものと同一のプロトコルを使用する必要はない。
【００３７】
図２は、上記のフレームワークを使用して、ＷＬＡＮ相互接続のアドレス管理のための動作シーケンスの一例を示すものである。このオペレーションでは、移動端末（ＭＴ）（１０１）がすでに、ＷＬＡＮの関連付け及び認証手続き（２０１）を終了していると仮定する。すなわち、移動端末（１０１）とアクセス・ポイント（１０５）は、相互に認証し合っており、暗号化による保護が、次のメッセージ交換のために、すでに行われている。移動端末（１０１）は、ＷＬＡＮを通じてどのようなサービスにもアクセスしたい場合には、リンク（１０１１）を介して、アクセス・ポイント（１０５）にMT_Request_Aメッセージ（２０２Ａ）を送信し、そのメッセージは、ホーム・ネットワーク・オーソライザ（１０３）に届けられる。このメッセージは、認証手続き（２０１）から生成されたキーによって、終端点間（エンドトゥーエンド）で保護されている。図３は、メッセージMT_Request_Aメッセージ（２０２Ａ）の実施例を示している。
【００３８】
メッセージはMessage_Typeフィールド（３０１）から始まる。このフィールドは、例えば、要求、返答など、どの種類のメッセージがカプセル化されているかを識別する。このフィールドの長さは１オクテットであり、メッセージ・タイプは整数番号によって表わされる。これは、エア・インターフェースを通じたシグナリングに対して制限されたリソースを節約するものである。なお、必要な場合には、このフィールドが他のフォーマットも採用できることは当業者にとっては明白である。
【００３９】
Message_Typeフィールド（３０１）に続いて、Message_Lengthフィールド（３０２）が存在する。それは、Message_Typeフィールド（３０１）を含む全体のメッセージの長さに関する情報を含んでいる。次のフィールドは、Domain_Nameフィールド（３０３）である。このフィールドは、移動端末（１０１）のホーム・ドメインを識別する。なお、ネットワーク・アクセス識別子（Network Access Identifier：ＮＡＩ）（非特許文献１２）を使用することも可能であり、例えば「UserID@home.domain.3gpp.org」の形式となる。ユーザの識別情報を保護するため、「@」記号の前のUserID部分は、例えば「roamed」などのワイルドカード値を使用する。ホーム・ドメイン情報は、移動端末（１０１）のホーム・ネットワーク・オーソライザ（１０３）に対して、メッセージをルーティングするために使用される。
【００４０】
上記の３つのフィールド、Message_Typeフィールド（３０１）、Message_Lengthフィールド（３０２）及びDomain_Nameフィールド（３０３）は、移動端末（１０１）とアクセス・ポイント（１０５）との間のセキュリティの関連付けによって保護される。このセキュリティの関連付けは、エア・インターフェースの保護のために認証手続き（２０１）から得られる。したがって、目的を達成するために、アクセス・ポイント（１０５）が、これらのフィールドに含まれている情報にアクセスすることが可能である。Domain_Nameフィールド（３０３）に続くフィールドは、移動端末（１０１）とホーム・ネットワーク・オーソライザ（１０３）との間のセキュリティの関連付けによって保護される。例えば、それは、ホーム・ネットワーク・オーソライザ（１０３）のパブリック・キーが可能であり、すなわち、認証手続き（２０１）に由来したセッション・キーであり、また、メッセージ保護のために使用されるキーのインデックスを示すために、Domain_Nameフィールド（３０３）のUserID部分を使用することも可能である。
【００４１】
Domain_Nameフィールド（３０３）の後には、MT_IDフィールド（３０４）が存在する。このフィールドは、ホーム・ネットワーク（１００２）のコンテキスト中の移動端末（１０１）を一意に識別するための情報を含んでいる。これは、例えば、移動端末（１０１）のＩＭＳＩ（非特許文献１３）、又は、認証手続きで獲得されたＴＭＳＩ（非特許文献１３）が可能である。ホーム・ネットワーク・オーソライザ（１０３）は、ユーザの加入情報を検索するため、この識別子を利用する。ホーム・ネットワーク・オーソライザ（１０３）が実際のユーザ識別情報にそれをマッピングすることができる限り、このフィールドに他のフォーマットを使用することも可能であることは、当業者にとっては明白である。
【００４２】
次のフィールドはService_Requestフィールド（３０５）である。このフィールドは、ホーム・ネットワーク・オーソライザ（１０３）に対してアクセスすることを望むサービスを示すため、移動端末（１０１）によって使用される。メッセージは、移動端末（１０１）とそのホーム・ネットワーク・オーソライザ（１０３）との間のものなので、これは、特定のオペレータ及びネットワークに特有のものである。例えば、３ＧＰＰネットワークでは、これは、使用するＧＧＳＮ及びアクセスする特別のサービスを識別するためのＡＰＮ（非特許文献１３）であり得る。ホーム・ネットワーク（１００２）が別のタイプである場合には、他のフォーマットを使用することが可能であることは、当業者にとって明白である。
【００４３】
さらに、例えば、帯域幅の要求など、他のサービス・リクエスト情報を追加することも可能である。フィールドに利用可能な値としては、「2M.bandwidth.request.IMS.foo.bar.operator-name.operator-group.gprs」があり得る。「request」の後の部分は、サービスを識別する標準のＡＰＮであり、また、「request」の前の部分は、特定のサービス・リクエストである。実際のリクエスト属性は、サービスに依存しており、また、オペレータによって定義することが可能である。移動端末（１０１）は、ＳＩＭ又はＵＳＩＭカードから、フォーマットに関する情報を獲得することが可能である。
【００４４】
Session_IDフィールド（３０６）はセッション制御情報を提供する。これは、移動端末（１０１）が、このサービスの要求がホーム・ネットワーク・オーソライザ（１０３）に関連するセッションであることを識別するために使用される。セッションの識別子は、移動端末（１０１）内では局所的に一意であるべきであり、移動端末（１０１）は、すべてのサービス・セッションのローカルな記録を維持すべきである。新しいサービス・セッションがスタートする場合は常に、新しいセッション識別子を備えた新しいエントリが作られ、セッションが終了する場合には、そのエントリは削除されて、識別子は解放されて再利用可能となる。
【００４５】
本実施例では、フィールドは２オクテットであり、また、識別子は１６進数の値である。なお、端末にサポートされた他のタイプの識別子の使用が可能なことは、当業者にとっては明白である。MT_IDフィールド（３０４）及びSession_IDフィールド（３０６）は、ホーム・ネットワーク・オーソライザ（１０３）において、サービス・セッションを一意に識別する。
【００４６】
Address_Requestフィールド（３０７）は、移動端末（１０１）からのアドレス割り付けの要求に関する情報を含んでいる。本実施例では、図４に示されるように、複合した構造が使用されている。この構造の第１のパートは、Address_Typeフィールド（４０１）である。これは、どのタイプのアドレスが移動端末（１０１）にサポートされているかを識別する。このフィールドのサイズは１オクテットであり、可能な値は次の通りである。
【００４７】
No_IP::=0x00;
Single_Stack_IPv4::=0x01;
Single_Stack_IPv6_FullAddress::=0x02;
Single_Stack_IPv6_Prefix::=0x03;
Dual_Stack_IPv4_Preferred::=0x04;
Dual_Stack_IPv6_Preferred_FullAddress::=0x05;
Dual_Stack_IPv6_Preferred_Prefix::=0x06
【００４８】
さらなるタイプがサポートされ、他の数が使用され得ることは、当業者にとっては明白である。この構造の第２のパートは、Suggestion_Lengthフィールド（４０２）である。このフィールドは、次のフィールドAddress_Suggestionsフィールド（４０３）の長さを示している。Address_Suggestionsフィールド（４０３）は、移動端末（１０１）が割り当てられることを望むアドレスを列挙する。例えば、進行中のセッションは、あるアドレスを使用しており、そのセッションが中断されないように同一のアドレスが割り当てられることが重要である。
【００４９】
Address_Suggestionsフィールド（４０３）は、アドレスのリストであり得る。リスト内の各エントリは、例えば、ＩＰｖ４やＩＰｖ６などのアドレスのタイプを示す１オクテットのタイプ・フィールドから始まり、実際のアドレスがそれに続く。端末によるアドレス提示の特徴をサポートしないホーム・ネットワーク・オーソライザ（１０３）では、Suggestion_Lengthフィールド（４０２）及びAddress_Suggestionsフィールド（４０３）は、暗黙のうちに無視される。
【００５０】
Address_Requestフィールド（３０７）の後には、Tunnel_Requestフィールド（３０８）が存在する。このフィールドは、どのタイプのトンネルをサポートしているかを示すために、移動端末（１０１）によって使用される。このフィールドの最初のオクテットは、それ自体を含むこのフィールドの長さを示し、このフィールドの内容は、２オクテットを占める各エントリを持つリストとすることが可能である。各エントリの最初のオクテットは、移動端末（１０１）がサポートするトンネル・タイプの識別子を含んでおり、そのオクテットの値は、次のものが可能である。
【００５１】
ネットワーク・トンネル -- 一般的::=0x01;
ネットワーク・トンネル -- モバイルIPv4::=0x02;
クライアント・トンネル -- 一般的::=0x04
クライアント・トンネル -- モバイルIPv4::=0x05;
クライアント・トンネル -- モバイルIPv6::=0x06;
トンネル無し::=0x08
【００５２】
このフィールドで、他のトンネルのタイプを定義して使用することが可能であることは、当業者にとっては明白である。各エントリの２番目のオクテットは、トンネルの方向を示している。このオクテットの可能な値は次の通りものである。
【００５３】
トンネル -- 端末から::=0x01;
トンネル -- 端末に::=0x02;
トンネル -- 双方向::=0x03;
【００５４】
リスト内の最初のエントリは、移動端末（１０１）の好ましいタイプを示している。MT_Request_Aメッセージ（２０２Ａ）内の次のフィールドはWLAN_IDフィールド（３０９）である。これは、ホーム・ネットワーク・オーソライザ（１０３）に対して、ＷＬＡＮを識別する情報を含んでおり、その結果、ホーム・ネットワーク・オーソライザ（１０３）は、位置に基づく決定を行うか、又は、移動端末（１０１）への位置に基づくサービスを提供することが可能となる。
【００５５】
WLAN_IDは、認証手続きや、例えばＩＥＥＥ８０２ネットワークにおけるＳＳＩＤなどのアクセス・ポイント（１０５）からブロードキャストされた情報から取得可能である。移動端末（１０１）のローカルの識別子も含まれており、これは、アクセス・ポイント（１０５）が端末を識別するためのものである。最後のフィールドは、Security_Field（３１０）である。このフィールドは、メッセージを保護するための情報を含んでいる。フィールドのために使用される正確なアルゴリズムは、移動端末（１０１）とそのホーム・ネットワーク・オーソライザ（１０３）との間でやり取りが行われる。これは、ユーザの加入時間で決定され得るもので、端末のＳＩＭ又はＵＳＩＭカードに格納される。また、さらにソフトウェア・モジュールとして実施可能であり、必要な場合には常にダウンロードされるようにすることが可能である。
【００５６】
MT_Request_Aメッセージ（２０２Ａ）内のフィールドは、上述のような正確なシーケンスに従う必要はなく、例えば、実際には、最前部にフィールドの識別子を配置する限り、任意の順にフィールド（３０４）からフィールド（３０９）を配置することが可能である。
【００５７】
実際には、任意の適切なメカニズムを使用して、リンク（１０１１）を通じてメッセージを伝送することが可能である。例えば、ＩＥＥＥ８０２．１１ネットワークでは、ＩＥＥＥ８０２．１ｘに定義されるＥＡＰＯＬを使用して、ＥＡＰメッセージとして、それを実施することが可能である（非特許文献１４）。
【００５８】
アクセス・ポイント（１０５）がこのメッセージを受け取った場合には、Domain_Nameフィールド（３０３）からホーム・ドメイン情報を引き出し、例えば、ＤＮＳの照会を行なうなど、そのドメイン情報を利用して、ホーム・ネットワーク・オーソライザ（１０３）のアドレスを取得することが可能である。アクセス・ポイント（１０５）は、この情報に従って、対応するホーム・ネットワーク・オーソライザ（１０３）にメッセージを転送する。例えば、ＷＬＡＮがセントラルＡＡＡサーバを有し、アクセス・ポイント（１０５）は、ＡＡＡサーバにメッセージを直接転送する。そして、ＷＬＡＮのＡＡＡサーバはドメイン情報を解析し、実際のホーム・ネットワーク・オーソライザ（１０３）にメッセージを転送する。アクセス・ポイント（１０５）とホーム・ネットワーク・オーソライザ（１０３）との間に、安全なリンクが存在することが前提となっている。これは、認証手続き（２０１）での設定で可能となるか、又は、そのプロセスに由来するセキュリティの関連付けを動的に設定することによって可能となる。
【００５９】
アクセス・ポイント（１０５）は、メッセージ処理に参加する必要がなく、したがって、メッセージを解析するためにスタック全体を実施する必要がない。それは、単にメッセージ・タイプを読み、MT_Request_Bメッセージ（２０２Ｂ）のステップとして示される再カプセル化及び転送を行う必要があるだけである。転送のために使用されるプロトコルは、任意の適切なＡＡＡプロトコル（例えば、ダイアメータのためのＥＡＰ適用（非特許文献１５）や、ダイアメータのためのＮＡＳＲＥＱ適用（非特許文献１６））が可能である。それらのプロトコルは、認証の目的として、アクセス・ポイント（１０５）ですでに利用可能である。したがって、メッセージMT_Request_Aメッセージ（２０２Ａ）は、終端点間の認証手続き（２０１）と同様、本質的には、移動端末（１０１）からホーム・ネットワーク・オーソライザ（１０３）に送られる。
【００６０】
図５は、ホーム・ネットワーク・オーソライザ（１０３）の状態マシンの実施例を示すものである。ホーム・ネットワーク・オーソライザ（１０３）は、初期状態（５０１）から始まり、遷移（/intiate()）（５００１）で初期化（）の処理を行ってアイドル状態（５０２）に移る。初期化（）プロセスは、他のバックエンド・サーバとの接続、セキュリティの関連付けなどを確立するために必要なすべてのステップを含んでいる。 実際には、設定に依存して他のプロセスが含まれ得ることは、当業者にとっては明白である。
【００６１】
ホーム・ネットワーク・オーソライザ（１０３）が遷移（５００２）でアクセス・ポイント（１０５）から転送されたMT_Request_Bメッセージ（２０２Ｂ）を受け取った場合には、それは、メッセージ復号状態（５０３）に遷移する。図６は、メッセージ復号状態（５０３）の実施例を示すものである。メッセージ復号状態（５０３）では、ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６００１）でDomain_Nameフィールド（３０３）によって識別されたキーを使用して、MT_Request_Bメッセージ（202B）内のフィールドを復号する。ステップ（６００２）において、メッセージが破損されているか、又は、Security_Field（３１０）を使用して修正されていることを検知した場合、ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６０１３）において、不正なメッセージのフラグをセットし、状態マシンは、遷移（５００４）でサービス却下状態（５０４）に遷移する。
【００６２】
MT_Request_Bメッセージ（２０２Ｂ）から、ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６００３）において、MT_IDフィールド（３０４）から端末の識別情報に関する情報を獲得することが可能である。この識別情報を使用して、ホーム・ネットワーク・オーソライザ（１０３）は、そのデータベースやバックエンド・サーバ（例えば、３ＧＰＰネットワークのＨＳＳ）から、ユーザの加入情報を検索する。ホーム・ネットワーク・オーソライザ（１０３）は、さらにステップ（６００４）でService_Requestフィールド（３０５）から得られたサービス要求情報を解析する。サービス要求は、例えば、帯域幅、遅れ、不安定性など埋め込まれた様々なサービス固有情報を含むことが可能である。
【００６３】
ステップ（６００５）において、ホーム・ネットワーク・オーソライザ（１０３）内では、ユーザ加入情報を使用して、ユーザにサービスを与えないでおくべきかどうかに関する決定が下される。ユーザの加入に基づいて、要求されたサービスが与えられるべきではないとされた場合、ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６０１３）において、サービスを否定するフラグをセットし、状態マシンは、遷移（５００４）でサービス却下状態（５０４）に遷移する。もしサービスが許される場合には、ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６００７）において、Session_IDフィールド（３０６）の中で受け取られたセッション識別子のサービスの端末を求めて、その記録を探索する。
【００６４】
同一セッション識別子を有する記録が存在する場合には、これがハンドオーバの要求であることを意味し、端末には同じアドレスが割り当てられるべきである。その結果、サービス・セッションは中断されることがなくなる。また、記録が存在しない場合、それは新しい要求であることを意味し、ステップ（６００８）において、レコード・エントリが生成され、ホーム・ネットワーク・オーソライザ（１０３）の格納部に格納されるか、例えば、ＨＳＳなどのバックエンド・データベースを更新する。ホーム・ネットワーク・オーソライザ（１０３）は、さらにサービス情報を使用して、サービス・プロバイダ・ネットワーク（１００３）を識別し、サービス・プロバイダ・ネットワーク・サーバ（１０４）との接続がセット・アップされる。
【００６５】
ステップ（６００９）において、Address_Requestフィールド（３０７）から、ホーム・ネットワーク・オーソライザ（１０３）は、移動端末（１０１）が使用を望んでいるアドレスを得る。ホーム・ネットワーク・オーソライザ（１０３）が、オペレータのポリシーやその他によって、この機能をサポートしたくない場合、この情報は暗黙に無視することが可能である。移動端末（１０１）は、ホーム・ネットワーク・オーソライザ（１０３）から割り当てられた最終アドレスを常に使用するべきである。
【００６６】
ホーム・ネットワーク・オーソライザ（１０３）は、要求されたサービスから、アドレスが局所的又はホーム・ネットワーク（１００２）内で割り当てられるべきか、あるいは、サービス・プロバイダ・ネットワーク（１００３）内で割り当てられるべきかを決定する。例えば、ユーザがＷＬＡＮローカル・サービスを利用することしか認められていなければ、アドレスはＷＬＡＮ内で割り当てられ、一方、ＶＰＮサービスに加入するユーザには、そのＶＰＮ内のアドレスを用いて割り当てられるべきである。
【００６７】
ホーム・ネットワーク・オーソライザ（１０３）は、ステップ（６０１０）でTunnel_Requestフィールド（３０８）から、移動端末（１０１）にサポートされたトンネルのタイプを検索する。この情報は、サービス提供のためにトンネルをセット・アップするために用いられる。移動端末（１０１）は、１つ以上のトンネルのタイプを列挙し、リスト中の最初のものを好ましいタイプのものとすることが可能である。ホーム・ネットワーク・オーソライザ（１０３）は、サービス・プロバイダ・ネットワーク・サーバ（１０４）と共にチェックを行って、どのタイプを使用すべきであるか決定する必要がある。また、例えば、トンネルの方向などの余分な情報が含まれてもよい。
【００６８】
ステップ（６０１１）において、ホーム・ネットワーク・オーソライザ（１０３）は、WLAN_IDフィールド（３０９）から、移動端末（１０１）が現在関係している無線ＬＡＮの識別情報を得る。この情報を使用して、ホーム・ネットワーク・オーソライザ（１０３）は、対応するＷＬＡＮ管理サーバ（１０２）を見つける。ローミングの協定の一部として、ホーム・ネットワーク・オーソライザ（１０３）のデータベースにこの情報を格納することが可能であり、また、バックエンド・サーバ（例えばＨＳＳ）からこの情報を引き出せるようにすることも可能である。サーバの情報が得られた後、安全なリンクが確立される。このリンクは、次のサービス・メッセージ・シグナリングのために使用されるものである。すべての情報を取得した後、ホーム・ネットワーク・オーソライザ（１０３）は、Service_Reqeustメッセージ（２０３）及びWLAN_Requestメッセージ（２０５）を作る。ホーム・ネットワーク・オーソライザ（１０３）の状態マシンが待機状態（５０４）に遷移する場合、このメッセージが送り出される。
【００６９】
図７は、Service_Requestメッセージ（２０３）の実施例を示すものである。このメッセージは、Home_Network_IDフィールド（７０１）から始まる。このフィールドは、移動端末（１０１）のホーム・ネットワーク識別子に関する情報を含み、オペレータの名前や大きなネットワークのサブシステムであり得る。識別子はグローバルにユニークでなければならず、例えば「network.operator.3gpp.org」などのネットワークのＤＮＳ名は、この識別子のよい候補である。ホーム・ネットワーク情報の存在によって、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、例えば、ローミングの協定などのネットワーク・ポリシーをサービス要求に適用することが可能となる。
【００７０】
ユーザのプロファイルはホーム・ネットワーク（１００２）によって管理される。したがって、ユーザ情報は、サービス・プロバイダ・ネットワーク・サーバ（１０４）に送られるべきではない。しかしながら、サービスのよりよいコントロールを可能にするため、メッセージにユーザ・プライオリティ／グルーピング情報を付けることも可能である。これは、例えば、「goldmember.network.operator.3gpp.org」などのホーム・ネットワーク識別子と関連付けられることも可能である。サービス・プロバイダ・ネットワーク・サーバ（１０４）は、これを用いて、サービスを与える場合にユーザを区別することが可能となる。
【００７１】
次のフィールドはMT_IDフィールド（７０２）である。このフィールドは、移動端末（１０１）の識別子に関する情報を含んでおり、ホーム・ネットワーク・オーソライザ（１０３）がサービス・トラッキングを行うために使用される。識別子は端末のＩＭＳＩ、又は、ホーム・ネットワーク・オーソライザ（１０３）によって割り当てられ、サービス・セッションに固有の一時的なＩＤであり得る。それは、サービス・セッションが終了するまで一貫しているべきである。
【００７２】
上記のフィールドに続いて、Session_IDフィールド（７０３）が存在する。それは、端末によって割り当てられたセッション識別子である。サービス・プロバイダ・ネットワーク・サーバ（１０４）は、現在行われているすべてのセッション情報の記録を保持すべきであり、したがって、セッション識別子がデータベースに存在する場合には、それは、サービス要求がハンドオーバによって引き起こされることを意味し、また、サービスの中断を避けるために同一のアドレス構成を使用すべきであることを意味する。例えば、セッションが稼動している（アクティブ）場合、サービス・プロバイダ・ネットワーク・サーバ（１０４）は移動端末（１０１）に対して同一のアドレスを割り当てるべきである。その結果、コレスポンデント・ノードとの通信はシグナリングなしで継続することが可能となる。
【００７３】
Address_Requestフィールド（７０４）は、MT_Request_Aメッセージ（２０２Ａ）のものと同一である。この部分は、例えば、ＩＰｖ６などの割り当てるべきアドレスのタイプをサービス・プロバイダ・ネットワーク・サーバ（１０４）に示すものである。さらに、MT_Request_Aメッセージ（２０２Ａ）のAddress_Requestフィールド（３０７）と同様に、移動端末（１０１）によって要求されたアドレスを提供する。サービス・プロバイダ・ネットワーク・サーバ（１０４）がこの機能をサポートしたくない場合には、この情報を無視すればよい。また、ホーム・ネットワーク・オーソライザ（１０３）によってサービス・プロバイダ・ネットワーク（１００３）からアドレスを割り当てられる必要がないと決定された場合には、このフィールドは省略される。
【００７４】
Service_Specフィールド（７０５）は、複合したフィールドであり、ユーザの加入に基づいてホーム・ネットワーク・オーソライザ（１０３）から要求される特定の要件に関する情報を含んでいる。 このフィールドの実施可能なもの（データ構造１）は、以下に示される。
【００７５】
Struct Service_Spec[
u_long  bitrate_avg;
u_long  bitrate_max;
int  deliver_order;
int  MTU_size;
double  delay;
double  jitter;
int  priority;
int  service_direction;
int  QoS_type
struct  timeval  start_time;
struct  timeval  end_time;
];
【００７６】
この属性のうち、bitrate_avgとbitrate_maxとは、要求したサービスを保証する最大のビット・レートである。また、deliver_orderの属性は、配送が順番に行われるかどうかを示すものである。また、MTU_sizeは、サービスのために転送される最大のデータ・ユニット・サイズを特定するものである。delayとjitterのフィールドは、サービスのためのいくつかの基本的なＱｏＳの属性を指定するものである。priorityの属性は、このサービスのためのデータ・トラフィックの取り扱い優先度を示すものである。service_directionの属性は、サービスが一方向か双方向かを示すものである。QoS_typeの属性は、例えばDiffServ、あるいはRSVPなどを備えたInterServサービスなどのサービスを提供するために用いられるＱｏＳのスキームを示すものである。start_time、end_timeは、サービスの開始時間及び終了時間を示すものである。サービス・プロバイダ・ネットワーク・サーバ（１０４）は、この情報を用いて、サービスのためのリソースのスケジュールを決めることが可能である。実際の実施における構造では、サービスに固有の他の属性が含まれてもよいことは、当業者にとっては明白である。
【００７７】
Service_Specフィールド（７０５）の後には、Tunnel_Specフィールド（７０６）が存在する。このフィールドはトンネル情報を含んでおり、MT_Request_Aメッセージ（２０２Ａ）のTunnel_Requestフィールド（３０８）と同様だが、いくつかの特別な情報が付加されている。例えば、ネットワーク・トンネル・エントリに関しては、ＷＬＡＮの終点が提供され、端末のトンネルに関しては、データ暗号化のために、セキュリティ・キーを付加することが可能である。
【００７８】
Service_Requestメッセージ（２０３）の最後のフィールドは、Security_Field（７０７）である。このフィールドは、ホーム・ネットワーク・オーソライザ（１０３）とサービス・プロバイダ・ネットワーク・サーバ（１０４）との間のセキュリティの関連付けを用いて、メッセージ全体を保護するために使用され、このために使用される正確なアルゴリズムは、実施の形態に依存する。
【００７９】
Service_Requestメッセージ（２０３）内のフィールドが記述された順序である必要がないことは、当業者にとっては明白であり、実際には、ホーム・ネットワーク・オーソライザ（１０３）及びサービス・プロバイダ・ネットワーク・サーバ（１０４）は、シグナリングの最適化のためにどのような適切な順序でやり取りを行うことも可能である。
【００８０】
サービス・プロバイダ・ネットワーク・サーバ（１０４）は、Service_Requestメッセージ（２０３）を受け取った後、サービス・アドレス管理（２０４）手続きを行なう。この手続きでは、サービス・プロバイダ・ネットワーク・サーバ（１０４）が、Session_ID（７０３）に含まれていたセッション識別子を求めて、そのデータベースの探索を行う。同一の移動端末（１０１）のセッション識別子が存在する場合、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、例えば、ＭＴのアドレス、サービスの詳細など、その記録内のすべての情報をコピーし、それを返答メッセージとしてホーム・ネットワーク・オーソライザ（１０３）に直接戻す。
【００８１】
セッション識別子が存在しない場合には、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、そのデータベースの指標（インデックス）として、新しいセッション識別子を使用して新しいエントリを作る。サービス・プロバイダ・ネットワーク・サーバ（１０４）は、Address_Requestフィールド（７０４）をチェックし、このフィールドで指定されたアドレスのタイプに基づいて、移動端末（１０１）に適切なアドレスを割り当てる。
【００８２】
サービス・プロバイダ・ネットワーク・サーバ（１０４）は、ホーム・ネットワーク・オーソライザ（１０３）からのService_Specフィールド（７０５）をチェックし、要求されたサービスがサポートされない場合、失敗を示すメッセージが、ホーム・ネットワーク・オーソライザ（１０３）に送られる。失敗の原因を特定するために、あるエラー・コードを使用することも可能である。Service_Specフィールド（７０５）内の所定の属性が、サービス・プロバイダ・ネットワーク（１００３）の現在の能力を超える場合、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、新しいセットの属性で、ホーム・ネットワーク・オーソライザ（１０３）とやり取りを行おうと試みる。これは、サービス・プロバイダ・ネットワーク・サーバ（１０４）によって提案された値に修正されたService_Specフィールド（７０５）を有する同じService_Requestメッセージ（２０３）が、ホーム・ネットワーク・オーソライザ（１０３）に送り返されることによって達成される。
【００８３】
サービス・プロバイダ・ネットワーク・サーバ（１０４）は、Tunnel_Sepcフィールド（７０６）をチェックし、一致するトンネルのタイプを求める。複数の一致があるかもしれないが、サービス・プロバイダ・ネットワーク・サーバ（１０４）は最初に一致したものを選択すべきである。ネットワークに基づくトンネルのタイプに関しては、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、返答メッセージ内にトンネルの終点の情報を用意する必要がある。クライアントに基づくトンネルに関しては、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、トンネルのタイプに固有の情報を用意し、返答情報にそれを含ませる。例えば、モバイルＩＰｖ６のタイプのスキームに関しては、サービス・プロバイダ・ネットワーク・サーバ（１０４）は、移動端末（１０１）にホーム・エージェントを割り当てる必要があり、返答メッセージ内に、あるセキュリティ情報を含ませることも可能である。方向性の情報（例えば、一方向、両方向）もトンネル情報のフィールドに付加される。
【００８４】
サービス・プロバイダ・ネットワーク・サーバ（１０４）は、Service_Replyメッセージ（２０５）で、ホーム・ネットワーク・オーソライザ（１０３）に対して返答する。Service_Replyメッセージ（２０５）は、図７に示されるようなService_Requestメッセージ（２０３）と同様の構造を使用することが可能である。Home_Network_IDフィールド（７０１）、MT_IDフィールド（７０２）、及び、Session_IDフィールド（７０３）の内容は、対応するService_Requestメッセージ（２０３）から直接コピーされる。複数の端末のためにシグナリングのリンクが再利用される場合には、これらのフィールドは、要求及び返答メッセージのペアを一致させるために、ホームネットワークオーソライザ（１０３）によって使用される。
【００８５】
Service_Replyメッセージ（２０５）内のAddress_Requestフィールド（７０４）の内容は、移動端末（１０１）に割り当てられたアドレスを含んでおり、それは、バイトでフィールドの長さを示す最初のオクテットを有するアドレスのエントリのリストであり得る。フィールドの次の部分はアドレスのリストであり、実際のアドレスを伴うアドレスのタイプを示す１オクテットを有している。ワイルドカードのアドレスも許可されており、例えば、アドレス・フィールドがすべて０で満たされる場合には、ＷＬＡＮのローカルのメカニズム（例えばＩＰｖ６自動割り付け（非特許文献１７）やＤＨＣＰを使用して、移動端末（１０１）がアドレスを形成することを示している。
【００８６】
Service_Replyメッセージ（２０５）内のService_Specフィールド（７０５）の内容は、サービス・プロバイダ・ネットワーク・サーバ（１０４）によって同意された属性を含んでいる。すべての属性がサービス・プロバイダ・ネットワーク・サーバ（１０４）によって承認されている場合には、対応するService_Requestメッセージ（２０３）内のService_Specフィールド（７０５）と同一である。一方、そうでなければ、それは、ホーム・ネットワーク・オーソライザ（１０３）に対するサービス・プロバイダ・ネットワーク・サーバ（１０４）の反対の提案である。
【００８７】
Service_Replyメッセージ（２０５）内のTunnel_Specフィールド（７０６）は、サービス・プロバイダ・ネットワーク・サーバ（１０４）によって選ばれたトンネルの設定を含んでいる。このフィールドの正確な内容は、トンネルのタイプの特定であり、クライアントに基づくトンネル・タイプが選ばれた場合には、１つのセッティングのみが必要である。例えば、もしモバイルＩＰｖ６が同意されていれば、このフィールドには、移動端末（１０１）に割り当てられたホーム・エージェントのアドレス及びバインディングアップデート認証のためのセキュリティ・キーなどが含まれることとなる。
【００８８】
Address_Requestフィールド（７０４）内のアドレスは、移動端末（１０１）のホーム・アドレスとして使用される。また、ネットワークに基づくトンネルのタイプが選択される場合、このフィールドには、例えば、終点アドレスやトンネル識別子、サポートされるトンネルのタイプのそれぞれに関して必要となるすべての詳細な情報が含まれることとなる。
【００８９】
Service_Requestメッセージ（２０３）と平行して、ホーム・ネットワーク・オーソライザ（１０３）は、ＷＬＡＮサーバ（１０２）に対して、WLAN_Requestメッセージ（２０６）を送信する。このメッセージは、ＷＬＡＮ内のサービス提供に必要な設定の取り決めを行う。図８には、このメッセージの実施例が示される。
【００９０】
WLAN_Requestメッセージ（２０６）は、Service_Requestメッセージ（２０３）のように、Home_Network_IDフィールド（８０１）及びMT_IDフィールド（８０２）の２つのフィールドを含んでいる。Home_Network_IDフィールド（801）は、加入者のホーム・ネットワークの識別子を含んでおり、あるネットワーク・ポリシーがサービス提供に適用される場合には、ＷＬＡＮサーバ（１０２）に渡される。MT_IDフィールド（８０２）は、移動端末（１０１）の位置を追跡するために使用される。それは、例えば、移動端末（１０１）の下位レイヤの識別子（例えば、ＭＡＣアドレス）と連関するアクセス・ポイントの識別子が可能である。
【００９１】
Address_Allocフィールド（８０３）は、移動端末（１０１）にＷＬＡＮのローカル・アドレスを割り当てる必要があるかどうか示すフラグと、使用されるべきアドレスのタイプである。ホーム・ネットワーク・オーソライザ（１０３）は、選択されたトンネル・スキームに基づいて、ローカル・アドレスが必要か否かを決定する。実施例では、次の定義を用いて、このフィールドの最初のオクテットによって、割り付けが必要あるか否かが示される。
【００９２】
No_Allocation::=0x00;
Single_Stack_IPv4::=0x01;
Single_Stack_IPv6_FullAddress::=0x02;
Single_Stack_IPv6_Prefix::=0x03;
Dual_Stack_IPv4_Preferred::=0x04;
Dual_Stack_IPv6_Preferred_FullAddress::=0x05;
Dual_Stack_IPv6_Preferred_Prefix::=0x06
【００９３】
このメッセージの実際の実施において、他の値が使用可能であることは、当業者にとっては明白である。Service_Supportフィールド（８０４）は、ＷＬＡＮ内でサービス提供をサポートするために必要な属性をすべて含んでいる、複合したフィールドである。実際の内容は、サービスの特定であり、このフィールドの内容の例は、データ構造１に説明されたものである。
【００９４】
Tunnel_Setupフィールド（８０５）も複合したフィールドであり、Service_Requestメッセージ（２０３）内のTunnel_Specフィールド（７０６）と同様のフォーマットが使用される。WLAN_Requestメッセージ（２０６）の最後のフィールドは、Security_Field（８０６）である。このフィールドは、メッセージ全体を完全に保護するために、セキュリティの関連付けが使用される。このフィールドの計算のために使用されるアルゴリズムは、実施の形態に依存している。
【００９５】
WLAN_Requestメッセージ（２０６）を受け取った後、ＷＬＡＮサーバ（１０２）は、ＷＬＡＮサービス・アドレス管理（２０７）を実行する。例えば、ローカルのＩＰｖ６アドレスの割り付けが、ホーム・ネットワーク・オーソライザ（１０３）によって要求された場合には、ＷＬＡＮサーバ（１０２）は、適切なネットワーク・セクションを見つけて、端末にＩＰｖ６アドレスを割り当てる。なお、必要ならば、さらにＷＬＡＮサーバ（１０２）は、ゲートウェイを更新する（すなわち、ＷＬＡＮのファイア・ウォールに新しいアドレスの割り付けを行う）。その結果、移動端末（１０１）は、この割り当てられたローカル・アドレスを使用して、サービスにアクセスすることが可能となる。ＷＬＡＮサーバ（１０２）は、さらにローカルの承認コントロールを実行するために、Service_Supportフィールド（８０４）内の情報を使用する。サービス・プロバイダ・ネットワーク・サーバ（１０４）と同様に、もし任意の属性がＷＬＡＮの現在のキャパシティーを超える場合には、ＷＬＡＮサーバ（１０２）は、ホーム・ネットワーク・オーソライザ（１０３）との間で、例えば、ビット・レートの縮小やサービスの時間間隔の変更など、サービスの詳細の新しいセットの取り決めを試みる。
【００９６】
もし、クライアントに基づくトンネルのスキームが、ホーム・ネットワーク・オーソライザ（１０３）によって選択された場合、ＷＬＡＮサーバ（１０２）は、特別な設定を行う必要がない。また、ネットワークに基づくトンネル・スキームが使用される場合には、ＷＬＡＮサーバ（１０２）は、MT_IDフィールド（８０２）からの情報を用いて、トンネルの終点を識別する必要がある。
【００９７】
ＷＬＡＮサーバ（１０２）は、WLAN_Replyメッセージ（２０８）を用いて、WLAN_Requestメッセージ（２０６）への返答を行う。WLAN_Replyメッセージ（２０８）は、図８に示されるWLAN_Requestメッセージ（２０６）と同様の構造を利用する。Home_Network_IDフィールド（８０１）とMT_IDフィールド（８０２）は、対応するWLAN_Requestメッセージ（２０６）から直接コピーされる。これらのフィールドは、要求及び返答メッセージのペアを一致させるために、ホーム・ネットワーク・オーソライザ（１０３）によって使用される。WLAN_Replyメッセージ（２０８）内のAddress_Allocフィールド（８０３）は、移動端末（１０１）に割り当てられたＷＬＡＮのローカル・アドレスの情報を含んでいる。MT_Request_Aメッセージ（２０２Ａ）内のAddress_Requestフィールド（３０７）に定義されるように、このフィールドの最初のオクテットは、アドレスのタイプを示している。
【００９８】
フィールドの次の部分は、移動端末（１０１）に割り当てられた実際のアドレスを含んでおり、例えば、ＩＰｖ６アドレスが割り当てられる場合には、最初のオクテットは0x02となり、次の３２オクテットには、実際のＩＰｖ６アドレスが含まれる。WLAN_Replyメッセージ（２０８）内のService_Supportフィールド（８０４）は、WLAN_Requestメッセージ（２０６）に定義されるサービスの属性の情報を含んでいる。もし、ＷＬＡＮがこれらのサービスの属性を受け入れた場合には、ＷＬＡＮサーバ（１０２）は、WLAN_Requestメッセージ（２０６）から、それらを直接コピーする。一方、ＷＬＡＮサーバ（１０２）がその属性を受け入れることができなかった場合、WLAN_Replyメッセージ（２０８）内に新しい値をセットした属性を加えて、新たな提案を送信する。
【００９９】
WLAN_Replyメッセージ（２０８）内のTunnel_Setupフィールド（８０５）は、移動端末（１０１）へのトンネルの情報である。それは、最初のオクテット内で使用されるトンネルのタイプ、及び、次のオクテットでトンネルのタイプに固有のデータを示している。例えば、モバイルＩＰｖ６がデータ・トラフィックに対して使用される場合、このフィールド内にはトンネルのタイプのみが存在し、Address_Allocフィールド（８０３）のアドレスが移動端末（１０１）の気付アドレスとして使用される。一方、モバイルＩＰｖ４が使用される場合には、このフィールドには、最初のオクテットにトンネルのタイプが含まれ、移動端末（１０１）に割り当てられたフォーリン・エージェントのアドレスが後続する。
【０１００】
Service_Replyメッセージ（２０５）及びWLAN_Replyメッセージ（２０８）の受信後、ホーム・ネットワーク・オーソライザ（１０３）は、ＷＬＡＮサーバ（１０２）及びサービス・プロバイダ・ネットワーク・サーバ（１０４）からの情報を統合する。もし、Service_Specフィールド（７０５）又はService_Supportフィールド（７０６）がService_Requestメッセージ（２０３）又はWLAN_Requestメッセージ（２０６）内のものとは異なっている属性の値を含んでいる場合には、サービスの詳細を再度取り決める必要がある。ホーム・ネットワーク・オーソライザ（１０３）は、サービス・プロバイダ・ネットワーク・サーバ（１０４）又はＷＬＡＮサーバ（１０２）によって提案された新しい値をチェックし、もし、これらの新しい値を受け入れることが可能ならば、SPN_Configメッセージ（２１０）を用いて、新しい設定、WLAN_Configメッセージ（２１１）を確認する。
【０１０１】
メッセージのペアであるService_Requestメッセージ（２０３）、Service_Replyメッセージ（２０５）やWLAN_Requestメッセージ（２０６）、WLAN_Reply messagge（２０８）は、時間的な相関性を有していない。それらは平行に起こり、すなわち、ホーム・ネットワーク・オーソライザ（１０３）の実施にそれぞれ依存する。例えば、ＷＬＡＮサーバ（１０２）との接続がアイドル状態ならば、ホーム・ネットワーク・オーソライザ（１０３）は、Service_Requestメッセージ（２０３）の代わりにWLAN_Requestメッセージ（２０６）を発送する決定を行うことが可能である。また、再度やり取りが必要な場合に、新しいサービス・パラメータを確認するために、サービス・プロバイダ・ネットワーク・サーバ（１０４）に対して、SPN_Configメッセージ（２１０）が、ホーム・ネットワーク・オーソライザ（１０３）によって送られる。
【０１０２】
SPN_Configメッセージ（２１０）には、Service_Requestメッセージ（２０３）と同一のメッセージ・フォーマットが使用される。もし使用しない場合には、いくつかのフィールド、例えば、Address_Requestなどのいくつかのフィールドが省略される。また、もし必要ならば、トンネリングの情報を付け加えることも可能である。例えば、クライアントに基づくトンネル（例えば、モバイルＩＰ）が使用される場合、ＷＬＡＮサーバ（１０２）によって割り当てられた移動端末（１０１）の気付アドレスは、Tunnel_Requestフィールド（３０８）に挿入される。また、ネットワークに基づくトンネルが使用される場合、ＷＬＡＮのトンネルの終点アドレスやポート番号などが、このメッセージで転送される。
【０１０３】
WLAN_Configメッセージ（２１１）は、同様の目的で機能する。ホーム・ネットワーク・オーソライザ（１０３）は、必要ならば、ＷＬＡＮサーバ（１０２）に新しい設定を確認してもらうために、このメッセージを使用する。さらに、この情報は、トンネルの情報を転送するために用いられることも可能である。例えば、ネットワークに基づくトンネルが使用される場合、サービス・プロバイダ・ネットワーク（１００３）のトンネルの終点アドレスやポート番号など、このメッセージでＷＬＡＮサーバ（１０２）に転送され、その後、ＷＬＡＮサーバ（１０２）は、コレスポンデント・ノードに対して、トンネルをセット・アップするよう命ずる。クライアントに基づくトンネルが使用される場合、端末のアドレスはこのメッセージに含まれ、その結果、ＷＬＡＮはデータ・トラフィックのためにファイア・ウォールを開くことが可能となる。
【０１０４】
サービス・セッションが終わったときに、移動端末（１０１）に割り当てられたリソースを無効にするために、ホーム・ネットワーク・オーソライザ（１０３）によって、これらの2つのメッセージ、SPN_Configメッセージ（２１０）及びWLAN_Configメッセージ（２１１）が使用可能であることは、当業者にとっては明白である。例えば、移動端末（１０１）がもはやＷＬＡＮ内に存在しないことをホーム・ネットワーク・オーソライザ（１０３）が検知した場合、それは、すべて０にセットされたService_Supportフィールド（８０４）を含むWLAN_Configメッセージ（２１１）を出す。この種のメッセージを受け取った後、ＷＬＡＮサーバ（１０２）は、移動端末（１０１）に割り当てられたリソースをすべて解放し、他の適切な動作を実行する。
【０１０５】
ホーム・ネットワーク・オーソライザ（１０３）は、MT_Request_Bメッセージ（２０２Ｂ）に、返答としてMT_Reply_Bメッセージ（２１２Ｂ）を送る。このメッセージは、アクセス・ポイント（１０５）、又は、他の付随した装置によって、メッセージMT_Reply_Aメッセージ（２１２Ａ）として、移動端末（１０１）に転送される。MT_Reply_Aメッセージ（２１２Ａ）及びMT_Reply_Bメッセージ（２１２Ｂ）は同一の内容及びフォーマットを有している。ホーム・ネットワーク・オーソライザ（１０３）と移動端末（１０１）との間のネットワーク・エレメントは、これらのメッセージの内容にアクセスせず、また、アクセス・ポイント（１０５）は、単にメッセージ全体を再カプセル化して、それを転送する。MT_Reply_Aメッセージ（２１２Ａ）又はMT_Reply_Bメッセージ（２１２Ｂ）は、移動端末（１０１）とホーム・ネットワーク・オーソライザ（１０３）との間で共有されるセキュリティの関連付けによって暗号化される。MT_Reply_Aメッセージ（２１２Ａ）は、対応するMT_Request_Aメッセージ（２０２Ａ）への返答であるので、アクセス・ポイント（１０５）は、どの移動端末（１０１）に転送すべきかを知ることができる。
【０１０６】
ＷＬＡＮサーバ（１０２）がMT_Reply_B_message（２１２Ｂ）のパス上にある場合、そのメッセージにWLAN_Configメッセージ（２１１）を乗せて運ぶことが可能である。例えば、ＷＬＡＮサーバ（１０２）が、ＷＬＡＮ内でダイアメータを用いて、移動端末（１０１）にMT_Reply_Bメッセージ（２１２Ｂ）を転送するＡＡＡのサーバだった場合、MT_Reply_Bメッセージ（２１２Ｂ）は、ダイアメータ−ＥＡＰ−Answer ＡＶＰにカプセル化される一方、同じメッセージ内の別のＡＶＰにWLAN_Configメッセージ（２１１）がカプセル化されることも可能である。他の転送プロトコルが利用される場合でも、同じようなスキームが使用可能であることは、当業者にとっては明白である。
【０１０７】
MT_Reply_Aメッセージ（２１２Ａ）は、図３に示されるMT_Request_Aメッセージ（２０２Ａ）と同一の構造を有している。Message_Typeフィールド（３０１）は、MT_Request_Aメッセージ（２０２Ａ）のものと同一のフォーマットを有しており、このメッセージがリクエストの代わりに返答であることを示すための整数が使用される。Message_Lengthフィールド（３０２）は、Message_Typeフィールド（３０１）を含むメッセージの長さの合計を示すものである。MT_Reply_Aメッセージ（２１２Ａ）内のDomain_Nameフィールド（３０３）及びMT_IDフィールド（３０４）は、MT_Request_Aメッセージ（２０２Ａ）内のものと同一である。シグナリングを最適化するため、実際には、これらのフィールドが省略可能であることは、当業者にとっては明白である。
【０１０８】
MT_Reply_Aメッセージ（２１２Ａ）内のService_Requestフィールド（３０５）は、ユーザの加入情報に基づいて、ホーム・ネットワーク・オーソライザ（１０３）によってセットされるサービスに固有の情報を含むように使用される。例えば、もしユーザがＩＭＳサービスを要求した場合には、これは、Ｐ−ＣＳＣＦアドレスが可能である。このフィールドにサービスの提供に必要な他の情報を含ませられることは、当業者にとっては明白である。このフィールドの正確なフォーマットはサービスに依存する。
【０１０９】
MT_Reply_Aメッセージ（２１２Ａ）内のSession_IDフィールド（３０６）は、MT_Request_Aメッセージ（２０２Ａ）から直接コピーされるが、移動端末（１０１）によって要求されない場合には、実際にはそれを省略することが可能である。MT_Reply_Aメッセージ（２１２Ａ）内のAddress_Requestフィールド（３０７）は、移動端末（１０１）に割り当てられたアドレスを含んでいる。それはソース・アドレスとしてサービス適用によって使用されるべきである。このフィールドの最初のオクテットはアドレスのタイプで、実際のアドレスが後続する。例えば、もしＩＰｖ６アドレスのプリフィックスが割り当てられれば、最初のオクテットは0x03となる。また、次の３２オクテットは、実際のIPv6アドレスを形成するために移動端末（１０１）によって使用されるプリフィックス情報を含んでおり、例えば、ＷＬＡＮゲートウェイアドレス、ＤＮＳサーバアドレスなどの他のアドレス情報を含むことも可能である。これらの属性は、上記のアドレス情報に後続する。
【０１１０】
すべて０のワイルドカードの値は、実際の情報を得るために、移動端末（１０１）がローカルのどこにも帰着しない状態（Stateless：ステートレス）のメカニズムを使用すべきであることを示している。MT_Reply_Aメッセージ（２１２Ａ）内のTunnel_Requestフィールド（３０８）は、移動端末（１０１）によって要求されるサービスにアクセスするためのトンネリングの設定を含むものである。それは、トンネルのタイプに依存し、このフィールドの最初のオクテットは、使用されるトンネルのタイプを示している。
【０１１１】
例えば、クライアントに基づくトンネルのタイプにモバイルＩＰｖ６が使用される場合、MT_Request_Aメッセージ（２０２Ａ）でトンネルのタイプが定義されるように、その値は0x06である。タイプの属性に続いて、ＷＬＡＮによって割り当てられた気付アドレス及びホーム・エージェントのアドレス、そして、必要であればセキュリティ・キーが存在する。Address_Requestフィールド（３０７）内のアドレスは、端末に割り当てられたホーム・アドレスとなる。タイプ属性に続いて、ネットワークに基づくトンネルのタイプが使用された場合には、トンネルのローカルの終点アドレスと、移動端末（１０１）が安全に終点と通信を行うためのセキュリティ・キーとが存在する。MT_Reply_Aメッセージ（２１２Ａ）内のWLAN_IDフィールド（３０９）は、MT_Request_Aメッセージ（２０２Ａ）から直接コピーされる。シグナリングを最適化するため、実際には、それを省略することが可能である。
【０１１２】
MT_Reply_Aメッセージ（２１２Ａ）のSecurity_Field（３１０）は、メッセージ全体を完全に保護するために使用される。それは、移動端末（１０１）とホーム・ネットワーク・オーソライザ（１０３）との間のセキュリティの関連付けを使用する。そこでは、MT_Request_Aメッセージ（２０２Ａ）のものと同一のアルゴリズムを使用すべきである。
【０１１３】
MT_Reply_Aメッセージ（２１２Ａ）を受け取った後、移動端末（１０１）はすべての必要な情報を検索して、それに従って構成を行う。移動端末（１０１）はこの設定を使用して、実際のサービス・セッション（２１３）を開始することが可能である。実際には、移動端末（１０１）は、例えば、ビデオストリーミング・セッションと一緒にVoice-over-IPセッションを行うなど、いくつかのサービスを同時に要求することが可能である。これは、シグナリングに、異なるサービス・プロバイダ・ネットワークを含むものである。同一のメッセージ内にいくつかのサービスの要求を集めることにより、このシナリオで、上記と同一のメカニズム及びメッセージの構造を使用することが可能である。
【０１１４】
例えば、MT_Request_Aメッセージ（２０２Ａ）内に、Service_Requestフィールド（３０５）、Session_IDフィールド（３０６）、Address_Requestフィールド（３０７）、Tunnel_Requestフィールド（３０８）の複数のセットを存在させることが可能であり、これらの４つのフィールドはグループ化されて、移動端末（１０１）によって要求された各サービスには、これらの４つのフィールドの１グループが含まれる。例えば、MT_Request_Aメッセージ（２０２Ａ）がVoice-over-IPセッション及びビデオストリーミング・セッションを要求した場合には、リスト化された４つのフィールドの２グループが存在する。
【０１１５】
MT_Request_Aメッセージ（２０２Ａ）と同じ内容を含んでいるMT_Request_Bメッセージ（２０２Ｂ）を受け取った後、ホーム・ネットワーク・オーソライザ（１０３）は、移動端末（１０１）によって要求される１つの特定のサービスに対応した、これらの４つのフィールドの各セットから情報を検索する。ホーム・ネットワーク・オーソライザ（１０３）は、単一のサービスの要求に対して、上記のように要求されたサービスの各々のためのシグナリングを実行する。例えば、ホーム・ネットワーク・オーソライザ（１０３）は、両方のＩＭＳサブシステムにService_Requestメッセージ（２０３）を送る。また、ネットワークは、ストリーミング・サービスを提供する。異なるサービスへのWLAN_Requestメッセージ（２０６）を送る一方、それらは同一のＷＬＡＮに到達する。ホーム・ネットワーク・オーソライザ（１０３）は情報を集めて、メッセージを１つのみ送り出すことが可能である。同一のＷＬＡＮに多数のWLAN_Requestメッセージ（２０６）を送る必要がある場合には、それらのうちの１つだけが、ローカルのアドレスの割り付けの要求を必要とする。
【０１１６】
ホーム・ネットワーク・オーソライザ（１０３）は要求されたサービスの順序に従って、１つのMT_Reply_Bメッセージ（２１２Ｂ）にすべてのサービス情報を統合して、アクセス・ポイント（１０５）を介して、移動端末（１０１）にそれを転送する。その後、移動端末（１０１）は統合されたMT_Reply_Aメッセージ（２１２Ａ）内の情報を用いて、それ自体のアドレス構成を行うことが可能となる。移動端末（１０１）が並行して多数のサービスを要求した場合、異なるサービス・プロバイダ・ネットワークからその端末に異なるアドレスが割り当てられる可能性があり、さらに、異なるサービス・セッションにおいて異なるトンネルが設定される可能性がある。
【０１１７】
このシナリオでは、特別な中間層プロセッサ（mid-layer processer）が必要となる。Session_IDフィールド（３０６）で使用されるようなサービス・セッション識別子が、中間層プロセッサによって使用されて、アドレス及びトンネルの設定を多重化する。移動端末（１０１）内の中間層プロセッサは、異なるサービス・セッションにおけるアドレス及びトンネル情報のローカルのデータベースを維持している。サービス・セッションが移動端末（１０１）で生成された場合、中間層プロセッサはそのための識別子を作成する。これは、MT_Request_Aメッセージ（２０２Ａ）のSession_IDフィールド（３０６）内で使用されるセッション識別子である。アドレス及びトンネル情報をすべて含むMT_Reply_Aメッセージ（２１２Ａ）を受け取った後、中間層プロセッサは、セッション識別子によって指標化（インデックス化）されたすべての情報を含むデータベース内に新しいエントリを作る。
【０１１８】
サービスの適用によって新しい接続セッションが開始される必要がある場合には、中間層プロセッサに対してセッション識別子を備えたリクエストを送り、中間層プロセッサはセッション識別子を用いて、そのデータベースから、対応するアドレス及びトンネル情報を検索する。アドレス及びトンネル情報は、例えば、ＩＰレイヤなどの通常のスタックによって使用され、接続を行うために、ソケットなどの適切な結合が作られる。
【０１１９】
実際には、コントローラ（つまりＷＬＡＮサーバ（102））が存在しないＷＬＡＮが可能であることは、当業者にとっては明白である。この場合、移動端末（１０１）はアドレスの割り付け及びトンネルの設定のために、ＷＬＡＮのローカルのメカニズムを使用しなくてはならない。ホーム・ネットワーク・オーソライザ（１０３）は、MT_Reply_Aメッセージ（２１２Ａ）内のAddress_Requestフィールド（３０７）及びTunnel_Requestフィールド（３０８）をすべて０にセットしなくてはならず、これは、移動端末（１０１）に対して、例えば、ＤＨＣＰｖ６、ＭＩＰｖ６などのＷＬＡＮメカニズムを使用してアドレス構成を行うよう強いることになる。
【０１２０】
ある場合では、移動端末（１０１）が、ＷＬＡＮ内のサービス登録の取り消しを望むことがある。サービスの登録抹消を行う場合でも上記のメカニズムを使用することが可能であることは、当業者にとっては明白である。移動端末（１０１）は、サービスの終了を示す特別の値がService_Requestフィールド（３０５）に設定されたMT_Request_Aメッセージ（２０２Ａ）を送出することが可能である。例えば、Service_Requestフィールド（３０５）は「terminate.request.IMS.foo.bar.operator-name.operatorgroup.gprs」のような値を含むことが可能であり、「request（要求）」キーワードの前の「terminate（終了）」が、「request（要求）」キーワードの後に付けられているＡＰＮによって示されたサービスを終了するためのフラグである。
【０１２１】
MT_Request_Aメッセージ（２０２Ａ）のSession_IDフィールド（３０６）は、終了するサービスのセッション識別子に設定される。このタイプのMT_Request_Aメッセージ（２０２Ａ）のために、Address_Requestフィールド（３０７）及びTunnel_Requestフィールド（３０８）を省略することが可能である。
【０１２２】
通常のように、ホーム・ネットワーク・オーソライザ（１０３）はMT_Request_Aメッセージ（２０２Ａ）を処理し、そのService_Requestフィールド（３０５）内に「終了」のキーワードを見つけて、Session_IDフィールド（３０６）からサービス・セッション識別子を取り戻す。そして、ホーム・ネットワーク・オーソライザ（１０３）は、サービス登録時に作られたセッション・エントリを求めてそのデータベースを探索する。このセッション・エントリは、例えば、割り当てられたアドレス、トンネル設定などのサービスの設定に関する情報を格納している。この情報を用いて、通常と同様に、ホーム・ネットワーク・オーソライザ（１０３）は、サービス・プロバイダ・ネットワーク・サーバ（１０４）にService_Requestメッセージ（２０３）を送り、ＷＬＡＮサーバ（１０２）にWLAN_Requestメッセージ（２０６）を送る。これらのメッセージのうち、Service_Specフィールド（７０５）及びService_Supportフィールド（８０４）は、すべて０にセットされる。
【０１２３】
サービス・プロバイダ・ネットワーク・サーバ（１０４）とＷＬＡＮサーバ（１０２）は、通常通り、メッセージを処理し、Service_Specフィールド（７０５）及びService_Supportフィールド（８０４）がすべて０に設定されているのを読んで、サービス終了の要求であることが判る。これらの２つのサーバは、サービス登録時に作られたサービス・セッション・エントリを求めて、それらのデータベースを検索し、例えば、ＩＰアドレスや予約している帯域幅などのサービス・セッション用の対応するリソースを解放する。
【０１２４】
ホーム・ネットワーク・オーソライザ（１０３）が、サービス・プロバイダ・ネットワーク（１００３）及びＷＬＡＮから通知を受け取った後、MT_Reply_Aメッセージ（２１２Ａ）が移動端末（１０１）に返される。このメッセージは、サービスを終了し、予約されていたリソースが解放されたことを通知するものである。このMT_Reply_Aメッセージ（２１２Ａ）では、Service_Requestフィールド（３０５）に、その結果に関する情報が含まれている。例えば、このフィールドで、次の値を使用することが可能である。「removed.request.IMS.foo.bar.operator-name.operator-group.gprs」。
【０１２５】
ここでは、「request」キーワードの前の「removed」キーワードが、サービスの登録抹消の成功を示している。例えば、「removed」キーワードの後に情報を付加するなど、特別な情報を含ませられることは、当業者にとっては明白である。
【０１２６】
移動端末（１０１）へのサービス提供の過程には、ポリシー・コントロールも含まれる。例えば、ＧＰＲＳインターフェースを使用する端末は、１４９Ｋｂｐｓのアクセス・レートが与えられている。この端末がＷＬＡＮに入った場合、その端末は、同じサービスにアクセスするためにＷＬＡＮインターフェースを使用するよう移行する。ＷＬＡＮは、はるかに高いエア・インターフェース帯域幅を提供するので、端末がより高いアクセス・レート（例えば、１Ｍｂｐｓ）を享受することを切望する。移動端末（１０１）に対して、このより高いサービス・レートを与えるために、ポリシー・コントロール・フレームワークが起動されて、例えば、ゲートウェイ・フィルタなど、対応するポリシー設定を修正する必要がある。上記の例では、例えば、ＧＧＳＮなどの制御点が、ＧＰＲＳインターフェースを使用してサービスを始める場合には、ＧＧＳＮは端末のサービスのために１４９Ｋｂｐｓの帯域幅のみを予約すればよい。また、移動端末（１０１）が、再びＷＬＡＮサービスを利用して、サービス・セッションを登録する場合、ポリシー・サーバはＧＧＳＮの設定を１Ｍｂｐｓに修正すべきである。他の種類の設定やコントロール・ノードがポリシー・コントロールに含まれることは、当業者にとっては明白である。
【０１２７】
この種のポリシー・コントロールは、ユーザの加入情報に従って行われるべきであり、したがって、ホーム・ネットワーク・ドメイン内で行われるべきである。本発明は、サービスの要求及びアドレス（トンネルの設定）を扱うためにホーム・ネットワーク・オーソライザ（１０３）を使用するものである。したがって、それは、ポリシー・コントロール決定のために必要な情報をすべて有しており、ホーム・ネットワーク・ドメインのポリシー・サーバにホーム・ネットワーク・オーソライザ（１０３）から、こうした情報を渡すことが可能である。ポリシー・サーバは、例えば、ＧＧＳＮなどのコレスポンディング・ノードを適宜動作するよう操作するためのポリシー・コントロール・インターフェースを順に利用することが可能である。さらに、ポリシー・サーバは、ポリシー・コントロール・フレームワークを使って、提供するサービスに関連する他のネットワークに通知を行うことも可能であり、例えば、ホーム・ネットワーク・ドメインのポリシー・サーバは、新しいアクセス・レートの制限を持つＷＬＡＮ内のポリシー・サーバに通知を行うことが可能であり、その結果、ＷＬＡＮポリシー・サーバはローカルの承認管理機構を適宜調節することが可能となる。
【０１２８】
図９は、ホーム・ネットワーク・オーソライザ（１０３）とポリシー・サーバとの間で使用されるメッセージの実施例を示すものである。メッセージは、Operationフィールド（９０１）から始まる。このフィールドは、ポリシー・サーバによって行われる動作を示すものであり、可能な値は次の通りである。
【０１２９】
Install           ::=0x01
Remove      ::=0x02
Update      ::=0x03
【０１３０】
ホーム・ネットワーク・オーソライザ（１０３）が移動端末（１０１）から新しいサービス・セッションの要求を受け取った場合、Operationフィールド（９０１）内に「Install」の値を使用する。移動端末（１０１）がサービス・セッションを終了する場合、ホーム・ネットワーク・オーソライザ（１０３）は、Operationフィールド（９０１）内に「Removed」の値を使用する。移動端末（１０１）からのサービスの要求がアクティブなサービス・セッションを参照している場合には、「Update」の値を使用する。実際の実施においては、他のタイプの値の使用が可能であることは、当業者にとっては明白である。
【０１３１】
２番目のフィールドは、MT_IDフィールド（９０２）である。このフィールドは、移動端末（１０１）の識別子を含んでおり、例えば、モバイルのユーザのＩＭＳＩであり得る。
【０１３２】
３番目のフィールドは、MT_Locationフィールド（９０３）である。このフィールドは、例えば、端末が所定のＷＬＡＮに存在する場合には、２倍のアクセス・レートを提供するなど、位置に基づくサービスのポリシーを検索するために、ポリシー・サーバによって使用されるものである。このフィールドは、例えば、MT_Request_Aメッセージ（２０２Ａ）のWLAN_IDフィールド（３０９）からのＷＬＡＮ識別子を含むものである。次のフィールドは、MT_Serviceフィールド（９０４）である。このフィールドは、移動端末（１０１）によって、どのような種類のサービスがアクセスされているかを示すものである。さらに、それは、サービス・セッション情報を含むことも可能である。このフィールドの内容の例としては、ＡＰＮにセッション識別子を加えたものが可能である。
【０１３３】
次のフィールドは、Tunnel_Settingフィールド（９０５）である。このフィールドは、ＷＬＡＮ内で移動端末（１０１）によって使用されるトンネルの設定を示すものである。このフィールドの内容はトンネルのタイプであり、トンネルの終点アドレス、ポート番号などが後続する。正確なフォーマットは、トンネルのタイプの特定である。使用されるトンネルのタイプは、MT_Request_Aメッセージ（２０２Ａ）のTunnel_Requestフィールド（３０８）で定義されたものである。
【０１３４】
メッセージの最後のフィールドは、MT_Addressフィールド（９０６）である。このフィールドは、ＷＬＡＮ内で移動端末（１０１）によって使用されるアドレスを含むものである。これは、ポリシー・サーバによって使用され、サービスにアクセスするフィルタリングの規則を設定することが可能となる。実際には、メッセージ・フィールドが上記ほど正確な順序で続く必要がないことは、当業者にとっては明白である。各フィールドは、さらに、本実施例に記述されない余分な情報を含むことが可能である。
【０１３５】
このように本実施の形態は、ＷＬＡＮを相互接続することで、端末のアドレス割り当てを管理する管理方法を提供する。これにより、移動端末は、それが要求したサービスとその加入情報に基づいてアドレスの割り当てが行われ、ローカル・リソースへのアクセスを必要とせずに、アドレス管理を実行することが可能となる。さらに、本実施の形態は、ＷＬＡＮ相互接続におけるトンネルの設定のコントロール方法を提供する。ここでは、移動端末は、サービス許可と同時にネットワーク及びクライアントに基づくトンネルの設定をサポートする。さらに、本実施の形態は、ポリシー・コントロール・フレームワークでの相互接続の方法を提供する。与えられるインターフェースを用いて、サービス許可、アドレス割り当て、及び、情報をセットするトンネルをポリシー・サーバに伝播することが可能となり、よりよく端末にサービスを配信するために適切な動作を行うことが可能となる。すべての方法において、端末とそのホーム・ドメイン・サーバとの１回の往復メッセージの交換で、アドレス管理、トンネルの設定及びサービスの許可を達成することが可能である。したがって、貴重なシグナリングの時間や帯域幅が節約される。
【産業上の利用可能性】
【０１３６】
本発明は、無線データ通信の分野に関し、特に、他のネットワークから訪れるモバイル・ユーザのためのローカルネットワーク環境におけるアドレス管理あるいはトンネリングの設定に関するもので、無線ネットワーク間の相互接続（inter-networking）を行う際に使用可能なものである。
【図面の簡単な説明】
【０１３７】
【図１】本発明のＷＬＡＮ相互接続における移動端末のアドレスの割り当て、トンネルの設定、サービスの取り決めの管理に使用されるネットワーク構成の一例を示すブロック図
【図２】図１に示される構成で使用される、端末のアドレスの割り当て、トンネルの設定、サービスの取り決めのためのメッセージ・シーケンスの一例を示すシーケンス・チャート
【図３】図２に示されるメッセージ交換で移動端末によって使用されるメッセージの構成の一実施例を示すデータ構造図
【図４】アドレス割り当て要求のために移動端末によって利用されるフォーマットの一例を示すデータ構造図
【図５】ＷＬＡＮ相互接続における移動端末のアドレス割り当て、トンネルの設定、サービスの取り決めのための図１で示されるフレームワークにおけるホーム・ネットワーク・オーソライザの一実施例を示す状態遷移図
【図６】ホーム・ネットワーク・オーソライザで要求メッセージの処理手続きを行うために使用され得るフローチャートの一例を示すフローチャート
【図７】サービス・プロバイダ・ネットワーク・サーバと移動端末のサービスの詳細、アドレス割り当て、トンネル設定の取り決めを行うために、ホーム・ネットワーク・オーソライザによって使用されるメッセージの構造の一実施例を示すデータ構造図
【図８】ＷＬＡＮサーバと移動端末のサービスの詳細、アドレス割り当て、トンネル設定の取り決めを行うために、ホーム・ネットワーク・オーソライザによって使用されるメッセージの構造の一実施例を示すデータ構造図
【図９】ホーム・ネットワーク・ドメイン内のポリシー・サーバの移動端末の状態に関する更新を行うために、ホーム・ネットワーク・オーソライザによって使用されるメッセージの構造の一実施例を示すデータ構造図
【符号の説明】
【０１３８】
１０１  移動端末（ＭＴ）
１０２  ＷＬＡＮ管理サーバ（ＷＬＡＮサーバ）
１０３  ホーム・ネットワーク・オーソライザ
１０４  サービス・プロバイダ・ネットワーク管理サーバ（サービス・プロバイダ・ネットワーク・サーバ）
１０５  アクセス・ポイント
１００１  ＷＬＡＮ機能
１００２  ホーム・ネットワーク
１００３  サービス・プロバイダ・ネットワーク
【図１】
0004802238.tif 000002
【図２】
0004802238.tif 000003
【図３】
0004802238.tif 000004
【図４】
0004802238.tif 000005
【図５】
0004802238.tif 000006
【図６】
0004802238.tif 000007
【図７】
0004802238.tif 000008
【図８】
0004802238.tif 000009
【図９】
0004802238.tif 000010