"回線交換型制御領域CSに位置する回線交換型制御のユーザ端末MSのためにパケットベースのマルチメディアシステムIMS領域における呼を処理するように構成されたアクセスゲートウェイノードMAGCFであって、前記回線交換型制御のユーザ端末MSから直接、或いは、回線交換型の呼を当該アクセスゲートウェイノードMAGCFへルーティングするために使用されるルーティング番号を用いて移動回線交換型機能にサービス提供する在圏移動回線交換型機能から、発信の回線交換型の呼を受信するように構成された発信側回線交換型ロジックOrgCSと、当該アクセスゲートウェイノードMAGCFの一部であるプロキシ呼制御機能P-CSCFを介して発信のパケットベースのマルチメディア呼を前記パケットベースのマルチメディア領域IMSへ送信するように構成された発信側パケットベースマルチメディアロジックOrgPSと、前記パケットベースのマルチメディア領域IMSから、当該アクセスゲートウェイノードMAGCFの一部であるプロキシ呼制御機能P-CSCFへ宛てられた着信のパケットベースのマルチメディア呼を受信するように構成された着信側パケットベースマルチメディアロジックTermPSと、前記回線交換型制御のユーザ端末へ、着信の回線交換型の呼を送信するように構成された着信側回線交換型ロジックTermCSと、前記発信の回線交換型の呼を前記発信のパケットベースのマルチメディア呼に変換し、前記着信のパケットベースのマルチメディア呼を前記着信の回線交換型の呼に変換するように構成された変換機能Convと、を備えることを特徴とするアクセスゲートウェイノードMAGCF。前記ルーティング番号は、前記ユーザにサービス提供している当該アクセスゲートウェイノードへ呼をルーティングするためのルーティング情報によって修正された、ダイヤルされたユーザのアドレスであることを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。前記ルーティング番号は、前記ユーザにサービス提供している当該アクセスゲートウェイノードへ呼をルーティングするために当該呼に割当てられた一時的なローミングアドレスであることを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。前記ルーティング番号は、前記回線交換型領域に位置するユーザのディレクトリから受信された、前記ユーザにサービス提供している当該アクセスゲートウェイノードに関する指標に従って割当てられることを特徴とする請求項2又は3に記載のアクセスゲートウェイノードMAGCF。前記着信側回線交換型ロジックは、在圏回線交換型ノードが前記回線交換型機能の一部である場合に前記着信の回線交換型の呼を前記ユーザへ送信するか、或いは、前記在圏回線交換型ノードが前記回線交換型機能の一部でない場合に前記在圏回線交換型ノードへ送信するように、構成されることを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。前記回線交換型制御のユーザの前記パケットベースのマルチメディア領域への登録手順を実行するように構成された登録ロジックを備え、前記登録手順は、在圏パケットベースマルチメディアノードのアドレスを当該アクセスゲートウェイノードに格納し、当該アクセスゲートウェイノードのアドレスを前記在圏パケットベースマルチメディアノードに提供するという結果をもたらすことを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。当該アクセスゲートウェイノードの前記アドレスの前記提供は、前記プロキシ呼制御機能の提供であることを特徴とする請求項6に記載のアクセスゲートウェイノードMAGCF。前記受信された発信の回線交換型の呼が前記回線交換型領域において処理されることを抑制するように構成された抑制機能を備えることを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。前記受信された着信のパケットベースのマルチメディア呼を着信するように構成された着信機能を備えることを特徴とする請求項1に記載のアクセスゲートウェイノードMAGCF。回線交換型制御領域CSに位置する回線交換型制御のユーザ端末MSのために呼を処理する方法であって、当該呼は前記アクセスゲートウェイノードMAGCFが実行する複数のステップによってパケットベースのマルチメディア領域IMSにおいて処理され、当該複数のステップは、呼の発信手順を実行するステップであって、前記回線交換型制御のユーザ端末から直接、或いは、回線交換型の呼を前記アクセスゲートウェイノードMAGCFへルーティングするために使用されるルーティング番号を用いて在圏移動回線交換型機能から、発信の回線交換型の呼を受信するステップ20,21と、前記発信の回線交換型の呼を発信のパケットベースのマルチメディア呼に変換するステップ22と、統合されたプロキシ呼制御機能を介して前記発信のパケットベースのマルチメディア呼を前記パケットベースのマルチメディア領域へ送信するステップ23と、を含むステップと、呼の着信手順を実行するステップであって、前記パケットベースのマルチメディア領域から、前記統合されたプロキシ呼制御機能へ宛てられた着信のパケットベースのマルチメディア呼を受信するステップ30,31と、前記着信のパケットベースのマルチメディア呼を着信の回線交換型の呼に変換するステップ32と、前記回線交換型制御のユーザ端末へ、前記着信の回線交換型の呼を送信するステップ33と、を含むステップと、を備えることを特徴とする方法。前記ルーティング番号は、前記ユーザにサービス提供している前記アクセスゲートウェイノードへ呼をルーティングするためのルーティング情報によって修正された、ダイヤルされたユーザのアドレスであることを特徴とする請求項10に記載の方法。前記ルーティング番号は、前記ユーザにサービス提供している前記アクセスゲートウェイノードへ呼をルーティングするために当該呼に割当てられた一時的なローミングアドレスであることを特徴とする請求項10に記載の方法。前記ルーティング番号は、前記回線交換型領域に位置するユーザのディレクトリから受信された、前記ユーザにサービス提供している前記アクセスゲートウェイノードに関する指標に従って割当てられることを特徴とする請求項11又は12に記載の方法。前記受信された発信の回線交換型の呼が前記回線交換型領域において処理されることが、前記アクセスゲートウェイノードにおいて抑制されることを特徴とする請求項10に記載の方法。前記受信された着信のパケットベースのマルチメディア呼が前記アクセスゲートウェイノードにおいて着信されることを特徴とする請求項10に記載の方法。このように、IMSは、適用されるシグナリングプロトコルとしてSIPを使うパケット交換技術を用いたサービス提供を目的として、3Gネットワークのために展開されてきた。しかし、大半のユーザ装置は現在、音声サービスのシグナリングプロトコルとしてSIPを使うIMS技術をサポートしないが、それは、前記ユーザ装置が回線交換型制御の領域用に構成されているからである。従って、IMSへアクセスするためには、ユーザ装置を適合させることが必要であり、それは、末端の端末を交換するという問題につながる。発生するさらなる問題は、会話サービスの提供である。IMSではリアルタイムベアラが提供されているが、それは音声サービスについては効率的に可能なわけではない。GSMもしくはWCDMAアクセスを介して発話サービスを効率的に提供するには、回線交換型アクセスを用いる必要がある。従って、本発明の目的は、回線交換型制御の領域内で動作するユーザ装置にパケット交換型マルチメディアサービスを提供するためのソリューションを提供することである。本発明は、独立クレームの中で開示される。有利な諸実施形態が、明細書の対応部分の中で開示される従属クレームの中に記述されている。本発明は、回線交換型制御の領域内に位置する回線交換型制御のユーザ端末のために、パケットベースのマルチメディアシステム領域内で呼を処理するように構成されたアクセスゲートウェイノードMAGCFであって、前記アクセスゲートウェイノードが、発信側の回線交換型呼を回線交換型制御のユーザ端末から直接か、または、回線交換型呼をアクセスゲートウェイノードへルーティングするのに用いられるルーティング番号を使って、移動回線交換機能にサービス提供する在圏移動回線交換機能からか、いずれか一方で受信するように構成された発信側の回線交換ロジックを備えることを特徴とする、アクセスゲートウェイノードMAGCFを開示する。さらに、アクセスゲートウェイノードは、アクセスゲートウェイノードの一部分であるプロキシ呼制御機能を介して発信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域へ送信するように構成された、発信側のパケットベースのマルチメディアロジックを備える。さらに、プロキシ呼制御機能にアドレス指定された宛てられた着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するように構成された着信側のパケットベースのマルチメディアロジックと、着信側の回線交換型呼を回線交換型制御のユーザ端末へ送信するように構成された着信側の回線交換型ロジックとを備えた着呼機能が、含まれる。さらに、発信側の回線交換型呼を発信側のパケットベースのマルチメディア呼に変換し、着信側のパケットベースのマルチメディア呼を着信側の回線交換型呼に変換するように構成された、変換機能がある。さらに、本発明は、回線交換型制御領域内に位置する回線交換型制御のユーザ端末のためにパケットベースのマルチメディア領域において呼を処理する方法を開示する。前記方法は、以下のステップを備える。以下を備える、呼の発信手順を実行するステップ-発信側の回線交換型呼を回線交換型制御のユーザ端末から直接か、または、回線交換型呼をアクセスゲートウェイノードMAGCFへルーティングするのに用いられるルーティング番号を使って、在圏移動回線交換機能からか、いずれか一方で受信するステップ、そして、-発信側の回線交換型呼を発信側のパケットベースのマルチメディア呼に変換するステップ、そして、-統合されたプロキシ呼制御機能を介して発信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域へ送信すること、そして、以下を備える、呼の着信手順を実行するステップ-統合されたプロキシ呼制御機能にアドレス指定された着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するステップ、そして、-着信側のパケットベースのマルチメディア呼を着信側の回線交換型呼に変換するステップ、そして、-着信側の回線交換型呼を回線交換型制御のユーザ端末へ送信するステップ。さらなる有利な諸実施形態が、従属クレームの中に記述されている。下記において、当業者に本発明の十分かつ完全な理解を提供することを目的として、本発明の好適な例を詳細に記述するが、これらの詳細な実施形態は、本発明の例としてのみ機能するのであって、限定的であることを意図していない。下記の記述は、添付の図面を参照する。ここで留意されるべきだが、本発明の文脈においてエンティティ、ノード、モジュール、ロジックという用語は、通信ネットワーク内で所定の機能を提供するためのハードウェアおよびソフトウェアの適切な組み合わせであればいかなるものであってもそのように呼ぶ。このように、前記用語は一般に、複数の物理的エンティティにまたがって拡がりうる論理的エンティティのことを意味するが、明示的な定義が与えられていない場合は1つの物理的位置に所在する1つの物理的エンティティのことを意味すしてもよい。ここで留意されるべきだが、本発明の文脈においてユーザという用語は、回線交換型制御のユーザ装置のことを言い、ここで前記ユーザ装置は、ハードウェアとソフトウェアの組み合わせである。しかし、以下の記述において、ユーザとユーザ端末という用語は、違う記述のない限り、同じ意味を有すると考えられるべきである。通信ネットワークは、移動通信ネットワークであること、例えば、GSM、GPRS汎用パケット無線サービスまたはUMTS汎用移動電話システム、あるいは例えばEDGE、CDMA2000のようないずれかの3Gシステムに従って動作する無線通信ネットワークであることが望ましい。そして、パケット交換型マルチメディア領域は、IPマルチメディアサブシステムIMSであることが望ましい。本発明によって、IMSが呼およびサービスを完全に制御できるようにすることを目的として、アクセスゲートウェイノード内でセルラ通信交換局の論理機能とIMSの論理機能とを結合することが提案され、それを以下でMAGCFと呼ぶ。特に、この新たなMAGCFノードが、例えばMSCや、ローミングユーザ向けにサービスを提供しているMSCであるMSC-S、あるいはMAGCF機能のないネットワーク内でのローミングユーザへの着呼のためのGMSC-Sのような、在圏回線交換型機能を備え、そして任意で、ローミングユーザ向けの発呼のためのgsmSCFを備えることが提案される。さらに、MAGCFが、特に、例えばSIPメッセージをユーザからIMSへそしてIMSからユーザへ転送するためのP-CSCFのようなプロキシ呼制御機能である、パケット交換型マルチメディア機能を有することが提案される。一般に、MAGCFは、パケット交換型マルチメディア領域において回線交換型端末を持つユーザに代わって処理すると言ってもよいだろう。さらに、MAGCFが、セルラ呼制御プロトコルとIMSプロトコルとの間のプロトコル変換を実行することが提案される。統合型ユーザエージェントのタスクは、IMS機能を充足し、ユーザに代わって処理することである。基本概念は、MAGCFがすべての発呼および着呼を処理することを保証することであり、言い換えると、MAGCFがIMSへのセルラアクセスのためのアンカーポイントであることが保証されるということである。本発明は、ユーザの呼を確立することと処理することに重点を置く。しかし、パケット交換型マルチメディアセッションを確立する前に、ユーザは、回線交換領域とIMS領域とに前記ユーザの位置を知らせることを目的として登録手順を実行する必要がある。この登録は、SIPプロトコルを使って行われ、MAGCFの一部であってユーザに代わって処理するユーザエージェントが、登録を行う。以下に、アンカーポイントとしてのMAGCFに対する登録について記述する。例えば、ある在圏ネットワークにローミングする間にサービスMSC-Sを変更することについて記述する実施形態をあげる。MAGCFをサポートしない在圏ネットワークへローミングする場合、最後に責任を持っていたMAGCFが、アンカーポイントとして維持される。本発明によると、前記MAGCFノードは、MSC-SのようなMSCの機能と、ユーザエージェントUAおよび統合型P-CSCFの形態のIMS機能とを有する。従ってMAGCFは、HLRおよびIMSと通信する能力を有し、そして、少なくとも1つのMAGCFが、ホームネットワーク内でユーザのために予測される。通常、1つのネットワークには複数のMSCが提供され、その場合、MSCは、そのMSCに割当てられた位置エリア内に位置するユーザに責任を持つ。ユーザの移動に起因して責任を持つMSCが変わることは、対応する諸ノードにおいてそれに関するすべての必要な更新を行うことによって、ユーザを新たなMSCに登録し、古いMSCから登録解除することを目指すローミング手順を開始することを意味する。新たな位置エリアに進入した後、端末は、位置更新要求を新たなMSCへ送信する。このメッセージを受信すると、MSCは、加入者がその責任において新規であることを識別し、従って、位置情報を更新するため、HLRにコンタクトする。位置更新メッセージを受信すると、HLRは、加入者が新たなMSCエリアにローミングで進入したことを旧MSCに通知する。本発明によると、ユーザにサービス提供するMSCは、MAGCFの一部であるか、あるいはユーザが在圏ネットワークにローミングで進入する場合には、前記在圏ネットワーク内に位置してMAGCFの回線交換部分と通信する通常のMSCであるかのいずれか一方であってもよいだろう。いずれの場合も、MSCはもはや加入者にサービス提供しないというメッセージが、HLRから送信される。MSCがMAGCFの一部である場合、この場合には新たなMAGCFがユーザに割当てられ、その結果、S-CSCFにおいて在圏MAGCFのアドレスが変更され、加えてS-CSCFのアドレスが、MAGCF内に記憶される。在圏MSCがMAGCFの一部ではない場合、例えば、ユーザが在圏ネットワークにローミングする場合、この場合には、在圏MSCは変わるがMAGCFは同じままであるというようなことが起こるかもしれない。IMSシステムに登録する目的で、HLRは、位置更新を受信すると、MSCがMAGCFの一部であるか否かをチェックする。さらにHLRは、要求している加入者をチェックする。IMSの機能をユーザに提供することを目的として、前記ユーザは、IMSシステムに連れて行かれる必要がある。言い換えると、ユーザは、IMSシステムへの変更を積極的に宣言する必要があるか、あるいはシステムが、セルラユーザをIMSシステムに連れて行くことを決定してもよいかいずれか一方である。ユーザについての対応する通知が、HLRの中で述べられることになる。ユーザが連れて行かれない場合、すでに知られているようにセルラユーザのための標準動作を適用することが提案される。ユーザがIMSに連れて行かれる場合、一般にユーザ装置の中のSIMカードに記憶されるすべてのパラメータを、HLRがMAGCFに送信することが提案される。パラメータを受信すると、加入者を登録してIMSシステムに加入させることを目的として、ユーザエージェントへのコンタクトが行われる。登録および加入の目的で適用されるプロトコルは、SIPプロトコルであることが望ましく、この場合、ユーザエージェントもSIP機能を実装される。IMS登録の間、ユーザエージェントは、加入者に代わって動作する。登録に必要なすべてのステップは、MAGCFの中に統合されたIMSエンティティを使って行われる。ステップには、例えば、認証されることになるユーザの認証が含まれてもよいだろう。しかし、本ソリューションは、回線交換アクセスの一部としてユーザがすでに認証されているという事実に依拠しているかもしれず、さらに、MAGCFが信頼できるVPNに接続していると想定されるかもしれないことから、認証は強制ではないことが述べられるべきである。登録の結果は、MAGCFがS-CSCFアドレスを記憶するということであり、登録についてのIMS規則に従って、S-CSCFは、登録加入者に到達できるようなMAGCFアドレスを記憶するが、できれば、MAGCF内に統合されるようなP-CSCFアドレスが記憶されることが望ましい。ユーザがMAGCF機能のない在圏ネットワークにローミングする場合には、MSCへのローミングの場合、現行のMAGCFがユーザのために責任を持ち続けることが提案される。MAGCFがまだユーザに割当てられない場合、デフォルトのMAGCFを利用することが提案される。したがって、位置更新手順は、ユーザが在圏ネットワーク内に留まる限り、責任を持つMAGCFではなくHLR内のMSCの更新に限定される。登録が終了した後、IMS呼設定手順を含めてセッション確立手順が開始される。従って、登録が成功した後では、MAGCFはS-CSCFを知っていて、S-CSCFはMAGCFアドレスを有しており、特に、その機能が提案されたMAGCFの一部であるP-CSCFアドレスを有する。以下に、本発明によって、呼処理が在圏MAGCFによって行われることをいかにして実行させるかという手順について記述する。この状況は、例えば、MAGCFの機能が利用できないようなリモートの在圏ネットワークにローミングする場合に起きることがありうる。この場合、最後の在圏MAGCFをローミングのアンカーとして用いることが提案される。呼処理手順について、ユーザの回線交換型制御の端末MSを含む回線交換型CSネットワークとパケット交換型マルチメディアネットワークPSとの間のアンカーポイントであるMAGCFの構造を概略的に示す図1に従って記述する。発信側回線交換型の呼を受信するように構成された発信側回線交換型ロジックOrigCSがある。前記呼は、在圏MSCがMAGCFの一部である場合、回線交換型制御のユーザ端末から直接受信されてもよいだろう。この状況は、ユーザがホームネットワーク内にいて、在圏MSCがMAGCF内に含まれることが定義される場合に起きる。あるいは、例えばユーザを処理する在圏ネットワーク内のMSC/VLRかもしれない在圏移動回線交換型機能から、MAGCFが発呼を受信するかもしれない。この場合、発信ユーザは、よく知られたかたちで、例えばB番号を用いて、MSC/VLRにコンタクトし、そして、本発明によると、MSC/VLRは、そのユーザに責任を持つMAGCFへ呼をルーティングする必要がある。これは、ルーティング番号を割当てることによって保証される。さらなる記述において、ルーティング番号を割当てる2つの方法を示すが、1つは、呼に割当てられるローミング番号に基づくもので、呼がルーティングされることになるMAGCFを一意のかたちで識別する。番号を割当てる目的で、インテリジェントネットワークIN-機能が適用される。第2の方法では、B番号をMAGCFへどのようにルーティングするかを定義するプレフィックスでB番号が強化される。また、両方の方法によって記述されるように、ルーティング番号は、例えばHLRのような、ユーザのディレクトリから受信した、ユーザにサービス提供するアクセスゲートウェイノードについての指標に従って割当てられる。発信側CS呼がユーザ端末から直接受信されるかMSC/VLRを経由して受信されるかに関わらず、次のステップにおいて、MAGCFは、発信側CS呼を変換部Convにおいて発信側パケットベースマルチメディア呼に変換し、それは、発信側パケットベースマルチメディア呼をパケットベースのマルチメディア領域に送信するように構成された発信側パケットベースマルチメディアロジックOrigPSに渡される。本発明によって、アクセスゲートウェイノードの一部であるプロキシ呼制御機能P-CSCFを有することが提案される。プロキシCSCFP-CSCFは、IMSネットワークにおける最初のコンタクトポイントであり、ユーザから受信したSIPメッセージをS-CSCFへ転送するが、P-CSCFは、S-CSCFの名前を登録手順の結果としてすでに受信している。反対方向においては、P-CSCFはSIP要求またはSIP応答をUEへ転送する。また前記P-CSCFは、呼の着信のためMAGCFに到達するのにも用いられる。従って、着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するように構成される着信側パケットベースのマルチメディアロジックTermPSが、提案される。前記呼は、プロキシ呼制御機能すなわちP-CSCFのアドレスを使ってMAGCFへルーティングされる。前記呼は、交換機能Convにおいて着信側の回線交換型呼に変換され、着信側の回線交換型ロジックTermCSを使って回線交換型制御のユーザ端末へ送信される。着呼は、在圏回線交換型ノードが回線交換型機能の一部である場合には回線交換型制御のユーザ端末へ直接送信され、また、前記在圏回線交換型ノードが回線交換型機能の一部でない場合には在圏回線交換型ノードへルーティングされることになるであろう。さらに、MAGCFは、受信された発信側回線交換型呼を回線交換型領域において処理することから抑制するように構成される、抑制機能を有することが提案される。これによって、発呼が本当にIMS領域内で処理されることが保証される。回線交換型呼をユーザに配信するためには、受信された着信側のパケットベースのマルチメディア呼がMAGCFに着信することが保証されるべきである。以下に、本発明による方法について、図2および図3に関して記述する。図2は、呼を発信する事例を示す。第1のステップ21で、MAGCFは、発信側の回線交換型呼を受信する。前記呼は、在圏移動回線交換型機能MSCがMAGCFと統合されている場合、回線交換型制御のユーザ端末から直接受信されてもよい。別個の在圏移動回線交換型機能によってユーザが処理される場合、呼は、ルーティング番号を使って在圏MAGCFへ転送されることになる。ルーティング番号の割当てについて、さらに記述する。ステップ22で、回線交換型呼は、発信側のパケットベースのマルチメディア呼に変換され、ステップ23で、パケットベースのマルチメディア領域24へ送信される。パケット交換型マルチメディア部分において、プロキシ呼制御機能P-CSCFが、呼の転送に関与する。図3は、着呼の実施形態を示す図である。ステップ31で、着信側のterminating着信しているパケットベースのマルチメディア呼が、パケットベースのマルチメディア領域から受信される。呼のルーティングが、プロキシ呼制御機能P-CSCFによって行われる。ステップ32で、呼は、着信側回線交換型呼に変換され、上述したように直接または在圏MSC/VLRを介して回線交換型制御のユーザ端末へ送信される。以下に本発明の諸実施形態を示す。以下に、ユーザが在圏ネットワークへローミングして在圏MAGCFの一部ではないMSC/VLRによってサービス提供される場合の、ルーティング番号の割当てを示す実施形態について記述する。在圏MSC/VLRからのすべての発信側の呼をローミングのアンカーであるMAGCFにルーティングすることを目的として、CAMELメカニズムが一例として用いられる。CAMELアプローチは、一例として採用するのであって、本発明を限定するものではない。以下に、本発明の一実施形態で用いられるCAMELネットワークのいくつかの本質的特徴について述べる。CAMELは、移動加入者がホームネットワーク外でローミングしているときでも、ネットワークオペレータが移動加入者にオペレータ固有のサービスを提供できるようにするネットワーク機能である。CAMELのアーキテクチャによると、CAMELサービス制御機能gsmSCFの機能は、オペレータ固有のサービスを実装するのに必要なCAMELサービスロジックを含む、加入者のホームPLMNに備えられることになる。さらにまた、gsmSCFから与えられた命令を処理して実行するトランザクションに参加するCAMELサービス交換機能gsmSSFもある。CAMELアーキテクチャにおいてノード間の通信用によく用いられるプロトコルは、CAMELアプリケーションパートCAPプロトコルである。CAMELの枠組みにおいて、いわゆるトリガ検出ポイントTDPが定義され、トリガ検出ポイントは、トランザクション処理の中でgsmSCFがコンタクトされるべき時点を指定する。TDPに合致すると、gsmSSFは、gsmSCFとの対話を開始する。gsmSCFについては複数の機能が定義されており、なかでも、gsmSCFには、例えば宛先アドレスやトランザクションの持続時間など、進行中のトランザクションについての情報が提供されうる。すべての呼が在圏MAGCFによって処理されることを保証するための本発明の実施形態に戻ると、これを目的とした2つの可能性のある手法を以下に提示する。第1のソリューションでは、在圏MSC/VLRから在圏MAGCFへルーティングする目的で呼に動的に割当てられるローミング番号が用いられ、第2は、実際にダイヤルされたB番号にプレフィックスを追加することによってB番号を修正する。第1のアプローチは、一時的なローミング番号の使用という考え方に基づく。このソリューションについて、図4に関して記述する。図4にMSC/VLRが提示されるが、MSC/VLRは、そのサービス提供エリアすなわちA在圏ネットワークの中に位置しているユーザにサービス提供する。本発明によると、MSC/VLRは、ホームネットワークすなわちAホームの中に位置していて、gsmSCF機能も備えているMAGCFと通信する。したがって、MAGCFは、回線交換型領域への接続性を提供する。他方、MAGCFは、IMS特にS-CSCFへのシグナリング通信を提供する。S-CSCFは、IMS領域内でユーザにサービス提供するノードである。S-CSCFは、呼サーバとして動作し、呼のシグナリングを処理する。さらに、図4によると、ユーザが要求したサービスをホストして実行するIMSASも存在する。ASは例えば呼のフローおよびユーザインタフェースの加入者との対話に責任を持つ。IMSASは、プッシュトゥトーク、リングバックトーン、プリペイド発信カード、マルチメディア会議、およびマルチメディアメッセージングサービスロジックのようなサービスをIMSへ配信する。さらに、回線交換型ネットワーク内に位置するユーザデータベースであるHLRも存在する。本発明の好適実施形態によって、2つの独立したレイヤ上でユーザプレーンとユーザシグナリングとの送信を行うことが提案される。ユーザプレーンにおいて、IPベースのメディアストリームをしかるべく変換するには、相互作用する要素が必要である。メディアゲートウェイMGWノードは、この機能に責任を持つ。マルチメディアリソース機能プロセッサMRFPは、アプリケーションレイヤのための補助的なメディア処理、例えば、音声ミキシング、コンテンツ録音再生、コーデックのトランスコーディング、統計の取得などを提供し、そして、MGWに接続される。MRFPは、単一のアプリケーション専用ではなく、複数のアプリケーションに対する共有リソースとしてメディア処理を提供する。メディアリソース機能制御装置MRFCは、IMS内でASとMRFPリソースとの間のメディアリソース仲介機能を提供し、そして、アプリケーションサーバの一部または別個のネットワーク要素として実装されてもよい。図4では、シグナリング情報のフローが点線で描かれ、実線は、ユーザプレーンのフローを表す。図4に関して、MAGCFに呼処理を配信することを目的として、以下のステップが提案される。ユーザが在圏ネットワークへ移動すると、ユーザの新たな位置についてHLRに通知することを目的として、最初に位置更新手順が行われることになる。MSC/VLRとHLRとの間の通信が、MAPプロトコルによって実現される。従って、HLRは、更新位置UpdateLocationに関するMAPメッセージを受信し、HLRは、送信側ノードがMAGCFの機能をサポートするかどうか判断する。これは、MAGCFの機能がサポートされているという送信側ノードからの指標を含むことによって達成されてもよい。あるいは、HLRは、HLRの中で管理される所定のリストの中でチェックすることができる。HLRが、更新位置を送信するノードによってMAGCF機能がサポートされていないと判断した場合、HLRがMAP動作加入者データを挿入するInsertSubscriberDataにより、送信されたデータにCAMELデータを追加することが提案される。このCAMELデータは、情報を収集するCollect_InfoのCAMELトリガ検出ポイントを強化し、それによって、ホームネットワーク内のユーザの呼の処理に責任を持つgsmSCFへの接続を確立するよう、MSC/VLRへの指示が行われる。コンタクトすべきgsmSCFのアドレスとして、HLRは、現在サービス提供しているMAGCFのアドレスを含めるステップ41。HLRの中で在圏MAGCFが知られていない場合、HLRは、所定のデフォルトMAGCFを用いてもよい。位置手順の結果として、MSC/VLRは、MAGCFのコンタクトアドレスを有する。ステップ42において、MSC/VLRは、呼ばれたB番号を含む呼設定要求を受信する。呼の要求を受信すると即座にCAMELトリガ検出ポイント情報を収集するCollect_Infoがトリガされ、その結果、MSC/VLRは、呼設定処理を中止して、HLRから受信したCAMEL加入データによってアドレス指定されたようにgsmSCFにコンタクトする。CAPメッセージInitialDPが、B番号を含めてgsmSCFへ送信される。HLRは、在圏MAGCFのアドレスをgsmSCFアドレスとして提供したのだから、MAGCFはステップ43で実際にコンタクトされる。次のステップ44において、MAGCFが、呼をこのMAGCFにルーティングするのに用いられることになる一時的なローミング番号を割当てる。MAGCFは、着信するローミング番号の呼を後で正しいB番号と合致させられるように、受信したB番号を記憶する。ステップ45において、MAGCFは、MSC/VLRに指示して、発信呼をそのローミング番号にルーティングさせる。CAPメッセージ接続ConnectがMAGCFからMSC/VLRへ送信される。受信されたローミング番号を使って、在圏MSC/VLRは、保留していた呼をステップ46でMAGCFへルーティングする。ステップ47において、MAGCFは、ローミング番号と共に着信する呼を受信する。次いでMAGCFは、ローミング番号を割当てる時に記憶された、発信時にダイヤルされたB番号を調べる。ステップ48において、発信側サービスを実行する目的のためにA加入者にサービス提供する責任を持つS-CSCFに呼をルーティングするため、着信先としてB番号が用いられる。従って、記述したアプローチは、在圏ネットワーク内で開始された発信呼が、IMS領域で処理されることを目的としてMAGCFへ転送されることを保証する。呼の処理について、さらに記述する。下記で、ローミングのアンカーポイントであるMAGCFノードへすべての発信呼をルーティングするための第2のアプローチを提示する。このソリューションは、B番号に対してプレフィックスを用いるという概念に基づいており、図5に関してこれを記述する。図5は、図4に関して開示したすべてのノードを備えているが、違う点は、gsmSCFが別のノードとして描かれていることである。しかし、これは、本発明の保護範囲に関する何らかの制限とみなされるべきではない。本実施形態によると、gsmSCFは、特有のプレフィックスをB番号に追加するためのデータベースとして用いられることになり、このプレフィックスは、選択されたMAGCFにとって特有である必要があり、そして、別の選択されたMAGCFノードには別のプレフィックスが用いられることが望ましい。従って、gsmSCFは、プレフィックスを追加する中心点であることから、別個のノードとして示されているけれども、gsmSCFは他のいずれかのノードと同じ場所に配置されてもよいだろう。図5に戻ると、第1のアプローチと同様に、ステップ51で、HLRは、位置更新を送信しているノードがMAGCF機能をサポートするかどうか判断する。この判断は、第1のアプローチで開示されたように、好適であればいずれの方法で行われてもよいだろう。位置更新UpdateLocationを送信しているノードはMAGCF機能をサポートしていないとHLRが判断した場合、HLRはステップ51で、現在どのMAGCFがユーザにサービス提供しているかという指標と、在圏gsmSCFのアドレスとを添えて、情報を収集するCollect_InfoのCAMELトリガ検出ポイントを送信する。あるいは、在圏gsmSCFのアドレスは送信されず、この場合、ホームネットワーク内のいかなるgsmSCFがコンタクトされてもよい。すでに述べたとおり、HLRにおいて知られている在圏MAGCFが存在しない場合、HLRは所定のデフォルトMAGCFを用いることができる。ステップ52で、被呼B番号を搬送する在圏MSC/VLRにおいて、呼設定要求が受信される。前記要求を受信すると、CAMELトリガ検出ポイント情報を収集するCollect_Infoが即座にトリガされ、その結果、MSC/VLRは、呼設定処理を停止し、HLRから受信したCAMEL加入データによってアドレス指定されるgsmSCFにコンタクトする。ステップ53において、B番号と在圏MAGCFの指標とを含めて、CAPメッセージInitialDPが、gsmSCFへ送信される。gsmSCFは、どのMAGCFが加入者に現在サービスを提供しているのかを、受信した指標から認識する。次いで、gsmSCFは、その在圏MAGCFに特有のプレフィックスをB番号に追加する。プレフィックスは、gsmSCFにおいて事前定義されることが望ましい。次いでgsmSCFは、この修正されたB番号をMSC/VLRへ返信し、そして、この新規番号への呼設定を続けるように要求する。ステップ54で、この目的でCAPメッセージ接続するConnectが、gsmSCFからMSC/VLRへ送信される。ステップ55で、受信したプレフィックスのついたB番号を使って、在圏MSC/VLRが、呼をMAGCFへルーティングする。MAGCFは、プレフィックスのついたB番号と共に着信する呼を受信して、プレフィックスを削除する。ここで言及しておくべきだが、正しくサービス提供される加入者をMAGCFが識別できるようにする目的で、A番号もMSC/VLRによって提供されることが望ましい。ステップ56で、発信側サービスを実行する目的で、A加入者のS-CSCFに呼がルーティングされる。ここで、B番号は、再び着信先として用いられる。このように、第2のアプローチも、すべての発信呼が、ユーザにサービス提供するMAGCFに提供されることを保証する。どちらのアプローチにおいても、MAGCF機能をサポートしないネットワークにローミングする場合、最後にサービス提供したMAGCFが、ローミングのアンカーとして用いられる。しかし、IMSASはすべてのサービスの処理に責任を持つことから、MSC/VLRにおけるサービスの実行は抑制されるべきである。できれば、MSC/VLRがあらゆるサービスを処理することを防止する目的で、加入者データをフィルタリングするメカニズムが提案されることが望ましい。HLRは、加入者が、リモートの在圏ネットワーク内でローミングしていることを知っている。従って、MAP動作加入者データを挿入するInsertSubscriberdataを送信する場合、HLRは、データをMSC/VLRへ送信する前に、すべての補助的なサービス加入登録をフィルタで除去する。さらに、ホームネットワーク内でローミングする場合、加入者データがフィルタにかけられないで、いずれのサービス呼び出しであってもその抑制をMAGCFが管理することが提案される。もう1つの選択肢は、加入者データがホームネットワーク内でMAGCFに送信される場合にも、加入者データをフィルタリングすることである。以下に、ホームネットワーク内で発呼を実行するための基本的アーキテクチャを、図6に関して提示する。図6は、呼を発信するユーザであるユーザAを示す。前記ユーザは、例えばUTRANまたはGERANのような無線アクセスネットワーク上でMAGCFに接続する。ユーザは、ホームネットワーク内で呼を実行するのだから、MAGCFノードのMSC-S部分に直接接続される。MAGCFノードのIMS部分は、SIPプロトコルによってS-CSCFへの接続を伝達する。特に、統合されているP-CSCFは、S-CSCFのアドレスを知っている。また、S-CSCFと通信するIMSASノードもある。点線は、シグナリングメッセージのフローを示す。また図6では、MGWノードおよびMRFPノードが描かれており、それらは、実線で示すユーザプレーンの送信に関与する。図6によると、ステップ61でMAGCFにおいて端末から呼の要求が受信されると、MAGCFは、いかなる発信側サービスをも呼出さず、また、受信したB番号を見ることもない。MAGCFは、サービス提供される加入者のIMSに呼をルーティングする。MAGCF内のP-CSCFは、やはりIMS登録からS-CSCFを知っていることから、呼は、ステップ62で一直線にS-CSCFへルーティングされる。ステップ63において、S-CSCFは、発信側サービスとダイヤルされたB番号の分析とを呼出すために、IMSASを関与させる。発信側サービスをチェックすることには、例えば、すべての発信呼の補助的サービスを禁止することが含まれてもよく、それは、例えば第三者に電話をかける場合に用いられてもよいだろうし、その場合、ユーザがすべての着信呼について依然として到達可能とする一方で、前記ユーザが呼を発信することを禁止することを目的として、禁止サービスが起動されてもよいだろう。さらに、MAGCFは、ユーザプレーンを処理するため、MGWを選択する。IMSASは、ユーザプレーンを処理するため、MRFPを関与させる。MGWとMRFPとは、別のノードであることが望ましい。以下に、ホームネットワーク内の発信呼に関するメッセージフローのシーケンスについて、図7に関して記述する。図7には、被呼ユーザB:IMSへの呼を発信する発信ユーザUEAが描かれている。ユーザは、MAGCFノードに統合されたMSC-S機能にコンタクトすることによってホームネットワーク内で呼を実行するのであるから、従って、MSC-S機能を持つMAGCFノードが描かれている。さらに、発信ユーザにとっては在圏S-CSCFであるA:S-CSCFと、ユーザに責任を持つA:IMSASとがある。2つのエンティティ間の線は、メッセージのフローを示し、矢印は、メッセージ交換の方向を示す。呼発信手順の第1のステップにおいて、発信側ユーザUEAは、24.0008:CSServiceRequestをMAGCF、特にMSC-Sへ送信する。前記ノードは、既に知られているように、最初に発信側ユーザのための回線交換型ユーザ認証を実行し、次のステップで、前記ユーザは24.008:Setupメッセージを送信し、それは、24.008:CallProceedingメッセージによって確認される。前述のように、MAGCFはユーザに責任を持つS-CSCFのアドレスを知っており、従って、IMS呼設定手順を開始するのに、前記アドレスが用いられる。特に、統合されているP-CSCFは、S-CSCFのアドレスを知っている。最初のステップで、SIP:Inviteが、発呼ユーザAにサービス提供するS-CSCFへ送信される。前記メッセージは、パラメータとして、被呼ユーザBの電話番号と、tel-URLと、ユーザAのセッション記述プロトコルパラメータSDPAとを含む。SDPパラメータは、通信エンティティ間で、すなわち発信側ユーザと着信側ユーザの間で、SDP交渉手順の枠組みの中で交換される。交渉手順の間、例えばメディアフローの数やコーデックのようなメディア特性が交渉される。図7に戻る。A:S-CSCFは、発信側サービスを呼出すため、そして、ダイヤルされたB番号を分析するため、ISC:InviteTel-URL、SDPAをA:IMSASへ送信する。A:IMSASから応答を受信すると、A:S-CSCFは、SIP:InviteSIP-URL、SDPAメッセージを着信側ユーザB:IMSへ送信する。次のステップで、提案されるSDPパラメータを搬送するSIP:183SessionProgressSDPBを着信側ユーザから送信することによって、SDP交渉手順が開始される。提案されたSDPパラメータがサポートされているかどうかチェックすることを目的として、そして、交渉されたセッションパラメータに必要なリソースを予約することを目的として、責任を持つRAN無線アクセスネットワークにMAGCFがコンタクトした後で、前記メッセージは、MAGCFへ転送される。これは、AssignmentRequestとAssignmentCompleteというメッセージによって行われる。次のステップで、MAGCFは、SIP:UpdateメッセージをA:S-CSCFを介してB:IMSへ送信し、B:IMSは、SIP:200OKUpdateメッセージを送信することによって新規パラメータに同意する。被呼ユーザがフリーであって呼を受信できる場合、対応する指標、すなわちSIP:180RingingがMAGCFへ送信され、MAGCFは、それを回線交換型プロトコルベースのメッセージ、すなわち24.008:Alertingへと変換する。被呼ユーザB:IMSからSIP:200OKInviteメッセージを受信した後、確立手順を完了することを目的として、24.008:Connectメッセージが、発信側ユーザであるUEAへ送信される。呼設定手順の実行が成功したという確認が、24.008:ConnectAckメッセージおよびSIP:Ackメッセージによって着信側ユーザへ送信される。呼設定手順の実行が成功した後、音声呼が実行されてもよいだろう。以下に、MAGCFの機能をサポートしないリモートの在圏ネットワーク内で発呼を実行するための一実施形態を提示する。このシナリオにおいて、このネットワーク内でローミングするユーザのために、最後の在圏MAGCFが、ローミングのアンカーポイントとして用いられる。前の実施形態において記述したように、HLRは、呼処理がアンカーMAGCF内で実行されるように仕向けることを目的として、加入者データをMSC/VLRに挿入する際にCAMELデータを加入者データに追加する。従って、呼の要求が受信されると、MSC/VLRは、CAMELデータに気付き、それによって、呼は、ローミングのアンカーであるMAGCFへルーティングされる。呼がMAGCFに到達した後、呼設定は、ホームネットワークの場合について続く、すなわち、呼が発信側サービスの実行のためにS-CSCFへ転送される。以下に、メッセージのフローを示す図9に関して、発信呼についてより詳細に提示する。図9は、図7に対応するが、違う点は、図9には、在圏ネットワークに位置するMSC/VLRがさらに描かれていることである。さらに、図9では、MAGCFは、gsmSCF機能も共に描かれている。しかし、これは制限であるとみなされるべきではない。代案として、gsmSCFが別個のノードとして提供されてもよいだろう。最初のステップで、ユーザUEは、24.0008:CMServiceRequestメッセージをMSC/VLRへ送信し、続いて24.008:SetupB番号を送信し、それが、メッセージ24.008:CallProcessingによって確認される。これらのメッセージの受信は、MSC/VLRにとって、ユーザがB番号を持つユーザへの接続を確立したいと望んでいることを意味する。しかし、前の実施形態で記述したように、登録手順の間にMSC/VLRは、ユーザがgsmSCFによって処理されることになると通知するCAMELメッセージを、HLRからすでに受信している。この情報に基づいて、MSC/VLRは呼をgsmSCF上でMAGCFへルーティングする。前の実施形態では、呼をどのようにしてMAGCFへルーティングするかについて論じている。この特定の実施形態では、ローミング番号を用いたルーティングを示す。このアプローチによると、MSC/VLRはgsmSCFのアドレスを有しており、このアドレスはMAGCFのアドレスでもある。このアドレスを使って、MAGCFがコンタクトされるCAP:InitialDPB番号。このメッセージを受信すると、MAGCFは、ルーティング番号を提供するための手順を行い、それには、ローミング番号を割当てることと、割当てられるローミング番号をB番号に関連して配置することとが含まれる。前記ローミング番号は、ローミング番号を使って呼をルーティングすることISUP:IAMローミング番号を目的として、CAP:Connectローミング番号メッセージによってMSC/VLRへ送信される。残りの手順は、呼を発信する手順を伝えることにつながる図7に関して記述したステップと同様である。以下に、ホームネットワーク内に着信する呼について記述する実施形態について、図10に関して記述する。図10の構造は、図6の構造に対応する。ステップ101において、S-CSCFは、ユーザBに着信することになる呼を受信する。S-SCCFは、ステップ102および103で、着信側サービスを実行するためにIMSASを関与させる。ここで、発信側の場合と同様の方法で、着信側加入者のサービスがチェックされる。例えば、国際ローミングの際にすべての着信呼の禁止が起動されてもよいだろう。この例においては、ユーザがこのサービスに加入しているかどうかIMSがチェックし、前記ユーザが国際ローミングしている場合、呼がブロックされる。S-CSCFは、上記の実施形態において記述したように、IMS登録から、在圏MAGCFのアドレスを知っている。特に、統合されているP-CSCFのアドレスは、S-CSCFに知られている。SIPプロトコルを使って、104で、呼はMAGCFへ転送され、特に、MAGCFの中に位置するプロキシゲートウェイであるP-CSCFへ転送される。MAGCFは、呼を端末へ着信させるが、ただし、いかなるサービスも呼出さない。着信とは、IMS呼がMAGCFに着信してCS呼に変換され、それが、次いで、例えば24.0008プロトコルを使って、例えばUTRANまたはGERANのようなアクセスネットワーク上でBユーザへ転送されることを意味する105。記述された呼の着信側ルーティングは、シグナリング情報のルーティングに限定されることが望ましい。ペイロード情報は、図6で実線を使って描かれたように、MRFPおよびMGWを介して直接アクセスネットワークへ転送されることが提案される。以下に、呼の着信手順のためのメッセージのフローを、図11に関して提示する。図11は、ユーザBすなわちUEBに接続されることを望んでいるIMSユーザすなわちA:IMSを示す。第1のステップにおいて、I-CSCFがコンタクトされるが、I-CSCFは、オペレータのネットワーク内でそのネットワークオペレータの加入者またはそのネットワークオペレータのサービスエリア内に現在位置するローミングユーザに宛てられた、すべての接続に責任を持つ。コンタクトすることは、SIP:InviteSIPURL、SDPAによって行われる。オペレータのネットワーク内の複数のI-CSCFが、利用可能であってもよいだろう。I-CSCFによって行われる主な機能は、SIP登録を行っているユーザにS-CSCFを割当てることである。本発明によると、S-CSCFは、MAGCFのアドレスを知っており、特に、MAGCFに統合されたP-CSCFのアドレスを知っており、従って、SIP:InviteがMAGCFに転送されてもよいだろう。図11に関して、メッセージをMAGCFに転送する前に、IMSサービスを着信することを目的として、B:IMSASがISC:Inviteメッセージを使ってコンタクトされる。SIP:InviteSIP-URL、SDPAを受信すると、IMS呼がMAGCFに着信し、24.008:Pagingメッセージを被呼ユーザすなわちUEBへ送信することと、回線交換型認証を行うことと、24.008:CallSetupメッセージおよび24.008:CallConfirmedメッセージを使ってUEBへの呼を確立することとを含んだ、回線交換型処理が開始される。残りの手順は、図7に関して記述した手順と同様である。これは、MAGCF内に位置するIMS部分、即ちP-CSCFが、SIP:183SessionProgressSDPBを、提案されたパラメータと共にA:IMSユーザへ送信することを意味する。図11によると、両方の通信側におけるパラメータの更新は、SIP:UpdateメッセージおよびSIP:200OKメッセージを使って行われる。パラメータが割当てられると、呼び出し信号である24.008:AlertingおよびSIP:180Ringingが発生し、そして、接続手順である24.008:ConnectおよびSIP:200OKinviteが、確認メッセージであるSIP:ACKおよび24.008:ConnectACKと共に行われる。もちろん、発呼ユーザが、MAGCF機能のない在圏ネットワークB在圏の中に位置することもあるだろう。以下に、このシナリオについて、ユーザBに対する着呼を示す図12に関して記述する。この場合、呼のIMS部分は、ユーザに責任を持ち、ローミングのアンカーとして動作するMAGCF内に着信することになる。従って、着呼は、S-CSCFへ121でルーティングされ、次いでS-CSCFは、着信側サービスを実行するため、122および123でIMSASを関与させる。すでに述べたように、S-CSCFは、IMS登録から在圏MAGCFのアドレスを知っている。従って、124で、呼は好適にはSIPプロトコルを使ってMAGCFへ送信される。前記MAGCFは、自分がローミングのアンカーとして動作することを認識し、従って、着呼がMAGCF内で受信される場合、MAGCFは、自分がその呼を直接着信させられずに在圏MSC/VLRを関与させる必要があることを認識する。従って、MAGCFは、GSMCとして動作して、HLRにルーティング情報を求める。HLRは、126で、在圏MSC/VLRからローミング番号を取ってきて、それを125でMAGCFに返信する。次いで127で、呼は、そのローミング番号を用いてMAGCFからMSC/VLRへルーティングされる。ここで留意すべきだが、サービスの実行にはIMSASが責任を持つことから、HLRでは前記サービスが実行されない。シグナリングのシーケンスは、図11に関して記述したシーケンスと同様であるが、違う点は、対応するシグナリング、好適にはMAPベースのシグナリングが、MAGCF、HLR、およびMSC/VLRの間で交換され、前記MSC/VLRが、ユーザBへの接続を確立することに責任を持つことである。上記の諸実施形態は、GSMやGPRSなどにおいて提供されるもののようなセルラ交換型制御のユーザ装置を、UMTSに関連して開発されたIMSサービスと統合することに基づくものである。しかし、本発明は、これらのネットワークだけに限定されない。さらなる例をあげるとすれば、GPRSまたはUMTS内に存在するノードと対応するノードを提供する、CDMA2000であってもよいだろう。"