JP5165075B2 - Ｉｍｓに登録されたユーザのための呼処理 - Google Patents

Description

本発明は、回線交換型制御のユーザ装置を持っていてＩＭＳ領域に連れて行かれるユーザのために呼処理を行うことに関する。

ＵＭＴＳ（ユニバーサル通信ネットワーク）やＣＤＭＡ２０００のような第３世代（３Ｇ）ネットワークは、通信範囲の広い高速ワイヤレスインターネットアクセスを移動ユーザに提供する。電話とマルチメディアサービスとをサポートする目的で、インターネットの諸サービスへの携帯電話によるアクセスを提供するよう、３ＧネットワークのためのＩＰマルチメディア・サブシステムＩＭＳが定義された。ＩＭＳは、パケット交換型技術を使用し、特にＩＰネットワークおよびその他のＩＥＴＦプロトコルを使用してサービスを提供する。ＧＳＭのような第２世代ネットワークは、回線交換型技術に基づいて音声を提供する。ＩＭＳの強みは、高度サービス、例えば、音声とデータとを組み合わせたマルチメディアサービスを提供することである。さらに、基礎を成す単一の標準としてＩＰネットワークを使用することによって、容易でスピーディなサービス展開が可能になる。

ユーザ装置ＵＥとＩＭＳとの間のシグナリング、および、ＩＭＳのコンポーネント間のシグナリングを目的として、ＩＭＳではセッション開始プロトコルＳＩＰが選択された。またＩＭＳは、インターネットにおいて音声呼とマルチメディア呼とを完了するためにもＳＩＰを使用する。ＩＭＳサービスが利用できるようにするためには、通信中のユーザ装置はＩＭＳをサポートする必要があり、それは、ユーザ装置にＳＩＰが実装される必要があることを意味する。

以下に、ＩＭＳの簡単化したネットワークアーキテクチャについて記述する。特に、ＩＭＳアーキテクチャにおけるサービス提供に関与する諸ノードについて述べる。

ＩＭＳシステムのコンポーネントには、呼セッション制御機能（ＣＳＣＦ）、メディアゲートウェイ（ＭＧＷ）／メディアゲートウェイ制御機能（ＭＧＣＦ）、ホーム加入者レジスタ（ＨＳＲ）、アプリケーションサーバ（ＡＳ）がある。

ＣＳＣＦは、呼サーバとして動作して呼のシグナリングを処理し、マルチメディアセッションをサポートして制御し、そして、アドレス変換機能を実行する。ＣＳＣＦは、機能的にＳ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、Ｐ−ＣＳＣＦに分けることができる。プロキシ−ＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＩＭＳネットワークにおける最初のコンタクトポイントであり、ベアラリソースの許可(authorization)を行い、さらに、ユーザ装置ＵＥから受信したＳＩＰ登録要求を、ユーザによって提供されたホームドメイン名を用いて判定されたＩ−ＣＳＣＦへ転送する。反対方向においては、Ｐ−ＣＳＣＦはＳＩＰ要求またはＳＩＰ応答をＵＥへ転送する。さらに、ＣＳＣＦは、ＵＥから受信したＳＩＰメッセージをＳＩＰサーバ（Ｓ−ＣＳＣＦ）へ転送するが、Ｐ−ＣＳＣＦは、Ｓ−ＣＳＣＦの名前を登録手順の結果としてすでに受信している。

インテロゲーティング−ＣＳＣＦ（Ｉ−ＣＳＣＦ）は、オペレータのネットワーク内のコンタクトポイントであって、そのネットワークオペレータの加入者またはそのネットワークオペレータのサービス範囲内に現時点で位置するローミングユーザに宛てたすべての接続のためのコンタクトポイントである。１社のオペレータのネットワークに複数のＩ−ＣＳＣＦが存在してもよい。Ｉ−ＣＳＣＦによって実行される主な機能は、ＳＩＰ登録を実行しているユーザにＳ−ＣＳＣＦを割当てることである。

サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）は、ＩＭＳネットワークのためのセッション管理を行うノードである。ネットワーク内に複数のＳ−ＣＳＣＦがあってもよい。Ｓ−ＣＳＣＦの主な機能には、サービスをサポートするためのサービスプラットフォームと交信しながらＵＥからの登録要求を受理することが含まれる。さらに、（例えば、追加メディアリソースの位置や課金通知を伴う、トーン／アナウンスで行う通知のような）サービスイベント関連情報をエンドポイントに提供する。

ホーム加入者レジスタＨＳＲは、一元化された(centralized)加入者データベースである。ＨＳＲは、Ｉ−ＣＳＣＦおよびＳ−ＣＳＣＦとインタフェースして、加入者の位置についての情報および加入者の加入情報を提供する。ＨＳＲは、以下のユーザ関連情報、すなわち、ユーザの識別情報、番号付けおよびアドレス指定の情報、認証および許可のためのユーザセキュリティ情報を保持することに責任を持つ。ＨＳＲは、ユーザ登録をサポートし、システム間の位置情報を記憶する。

ＩＭＳは、例えばメディアゲートウェイ制御機能（ＭＧＣＦ）のような、旧来（レガシー）のネットワークと相互作用するための複数のノードをサポートする。

ＭＧＣＦは、セルラ呼制御プロトコルとＩＭＳプロトコルとの間のプロトコル変換を行う。例えば、ＭＧＣＦは、ＳＩＰメッセージをＣＳＣＦから受信して、それを適切なＩＳＵＰメッセージに変換する。従って、ＭＧＣＦの基本的な機能は、アップリンク方向およびダウンリンク方向においてシグナリング情報をある形式から別の形式へ変換することである。ＵＭＴＳにおいては、これは、ＰＳＴＮのパルス符号変調（ＰＣＭ）とＩＰベースのフォーマットとの間で行われるものが大半を占めるであろう。

ＩＭＳアクセスサーバは、ユーザが要求したサービスをホストして実行する。

すでに述べたように、ＵＭＴＳシステムは、パケットモードで動作する移動機が、ＳＩＰをシグナリングプロトコルとして用いて音声呼を確立できるようにする。ＳＩＰメッセージは、ＩＭＳにおいて要求を呼セッション制御機能（ＣＳＣＦ）へ伝達するために送信される。この場合、データは、ＵＭＴＳネットワーク全体にわたってパケットとして送信される。

このように、ＩＭＳは、適用されるシグナリングプロトコルとしてＳＩＰを使うパケット交換技術を用いたサービス提供を目的として、３Ｇネットワークのために展開されてきた。しかし、大半のユーザ装置は現在、音声サービスのシグナリングプロトコルとしてＳＩＰを使うＩＭＳ技術をサポートしないが、それは、前記ユーザ装置が回線交換型制御の領域用に構成されているからである。従って、ＩＭＳへアクセスするためには、ユーザ装置を適合させることが必要であり、それは、末端の端末を交換するという問題につながる。

発生するさらなる問題は、会話サービスの提供である。ＩＭＳではリアルタイムベアラが提供されているが、それは音声サービスについては効率的に可能なわけではない。ＧＳＭもしくはＷＣＤＭＡアクセスを介して発話サービスを効率的に提供するには、回線交換型アクセスを用いる必要がある。

従って、本発明の目的は、回線交換型制御の領域内で動作するユーザ装置にパケット交換型マルチメディアサービスを提供するためのソリューションを提供することである。

本発明は、独立クレームの中で開示される。

有利な諸実施形態が、明細書の対応部分の中で開示される従属クレームの中に記述されている。

本発明は、回線交換型制御の領域内に位置する回線交換型制御のユーザ端末のために、パケットベースのマルチメディアシステム領域内で呼を処理するように構成されたアクセスゲートウェイノード（ＭＡＧＣＦ）であって、前記アクセスゲートウェイノードが、発信側の回線交換型呼を回線交換型制御のユーザ端末から直接か、または、回線交換型呼をアクセスゲートウェイノードへルーティングするのに用いられるルーティング番号を使って、移動回線交換機能にサービス提供する在圏移動回線交換機能からか、いずれか一方で受信するように構成された発信側の回線交換ロジックを備えることを特徴とする、アクセスゲートウェイノード（ＭＡＧＣＦ）を開示する。さらに、アクセスゲートウェイノードは、アクセスゲートウェイノードの一部分であるプロキシ呼制御機能を介して発信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域へ送信するように構成された、発信側のパケットベースのマルチメディアロジックを備える。さらに、プロキシ呼制御機能にアドレス指定された（宛てられた）着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するように構成された着信側のパケットベースのマルチメディアロジックと、着信側の回線交換型呼を回線交換型制御のユーザ端末へ送信するように構成された着信側の回線交換型ロジックとを備えた着呼機能が、含まれる。さらに、発信側の回線交換型呼を発信側のパケットベースのマルチメディア呼に変換し、着信側のパケットベースのマルチメディア呼を着信側の回線交換型呼に変換するように構成された、変換機能がある。

さらに、本発明は、回線交換型制御領域内に位置する回線交換型制御のユーザ端末のためにパケットベースのマルチメディア領域において呼を処理する方法を開示する。前記方法は、以下のステップを備える。

・以下を備える、呼の発信手順を実行するステップ
−発信側の回線交換型呼を回線交換型制御のユーザ端末から直接か、または、回線交換型呼をアクセスゲートウェイノード（ＭＡＧＣＦ）へルーティングするのに用いられるルーティング番号を使って、在圏移動回線交換機能からか、いずれか一方で受信するステップ、そして、
−発信側の回線交換型呼を発信側のパケットベースのマルチメディア呼に変換するステップ、そして、
−統合されたプロキシ呼制御機能を介して発信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域へ送信すること、そして、
・以下を備える、呼の着信手順を実行するステップ
−統合されたプロキシ呼制御機能にアドレス指定された着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するステップ、そして、
−着信側のパケットベースのマルチメディア呼を着信側の回線交換型呼に変換するステップ、そして、
−着信側の回線交換型呼を回線交換型制御のユーザ端末へ送信するステップ。

さらなる有利な諸実施形態が、従属クレームの中に記述されている。
下記において、当業者に本発明の十分かつ完全な理解を提供することを目的として、本発明の好適な例を詳細に記述するが、これらの詳細な実施形態は、本発明の例としてのみ機能するのであって、限定的であることを意図していない。下記の記述は、添付の図面を参照する。

本発明によるアクセスゲートウェイノードのアーキテクチャの略図である。 アクセスゲートウェイノード上で実行されることになる呼の発信方法についての、本発明の一実施形態のフローチャートである。 アクセスゲートウェイノード上で実行されることになる呼の着信方法についての、本発明の一実施形態のフローチャートである。 ＭＡＧＣＦをローミングのアンカーポイントとして関与させるための本発明の実施形態を示す図である。 ＭＡＧＣＦをローミングのアンカーポイントとして関与させるための本発明のさらなる実施形態を示す図である。 ホームネットワークでの呼の発信のための概略の実施形態を示す図である。 ホームネットワークでの呼の発信のためのシグナリングシーケンスの実施形態を示す図である。 在圏ネットワークでの呼の発信のための概略の実施形態を示す図である。 在圏ネットワークでの呼の発信のためのシグナリングシーケンスの実施形態を示す図である。 ホームネットワークでの呼の着信のための概略の実施形態を示す図である。 ホームネットワークでの呼の着信のためのシグナリングシーケンスの実施形態を示す図である。 在圏ネットワーク内で呼を着信させるための概略の実施形態を示す図である。

ここで留意されるべきだが、本発明の文脈において「エンティティ」、「ノード」、「モジュール」、「ロジック」という用語は、通信ネットワーク内で所定の機能を提供するためのハードウェアおよびソフトウェアの適切な組み合わせであればいかなるものであってもそのように呼ぶ。このように、前記用語は一般に、複数の物理的エンティティにまたがって拡がりうる論理的エンティティのことを意味するが、明示的な定義が与えられていない場合は１つの物理的位置に所在する１つの物理的エンティティのことを意味すしてもよい。

ここで留意されるべきだが、本発明の文脈において「ユーザ」という用語は、回線交換型制御のユーザ装置のことを言い、ここで前記ユーザ装置は、ハードウェアとソフトウェアの組み合わせである。しかし、以下の記述において、「ユーザ」と「ユーザ端末」という用語は、違う記述のない限り、同じ意味を有すると考えられるべきである。

通信ネットワークは、移動通信ネットワークであること、例えば、ＧＳＭ、ＧＰＲＳ（汎用パケット無線サービス）またはＵＭＴＳ（汎用移動電話システム）、あるいは例えばＥＤＧＥ、ＣＤＭＡ２０００のようないずれかの３Ｇシステムに従って動作する無線通信ネットワークであることが望ましい。そして、パケット交換型マルチメディア領域は、ＩＰマルチメディア・サブシステム（ＩＭＳ）であることが望ましい。

本発明によって、ＩＭＳが呼およびサービスを完全に制御できるようにすることを目的として、アクセスゲートウェイノード内でセルラ通信交換局の論理機能とＩＭＳの論理機能とを結合することが提案され、それを以下でＭＡＧＣＦと呼ぶ。特に、この新たなＭＡＧＣＦノードが、例えばＭＳＣや、ローミングユーザ向けにサービスを提供しているＭＳＣであるＭＳＣ−Ｓ、あるいはＭＡＧＣＦ機能のないネットワーク内でのローミングユーザへの着呼のためのＧＭＳＣ−Ｓのような、在圏回線交換型機能を備え、そして任意で、ローミングユーザ向けの発呼のためのｇｓｍＳＣＦを備えることが提案される。さらに、ＭＡＧＣＦが、特に、例えばＳＩＰメッセージをユーザからＩＭＳへそしてＩＭＳからユーザへ転送するためのＰ−ＣＳＣＦのようなプロキシ呼制御機能である、パケット交換型マルチメディア機能を有することが提案される。 一般に、ＭＡＧＣＦは、パケット交換型マルチメディア領域において回線交換型端末を持つユーザに代わって処理すると言ってもよいだろう。さらに、ＭＡＧＣＦが、セルラ呼制御プロトコルとＩＭＳプロトコルとの間のプロトコル変換を実行することが提案される。統合型ユーザエージェントのタスクは、ＩＭＳ機能を充足し、ユーザに代わって処理することである。

基本概念は、ＭＡＧＣＦがすべての発呼および着呼を処理することを保証することであり、言い換えると、ＭＡＧＣＦがＩＭＳへのセルラアクセスのためのアンカーポイントであることが保証されるということである。

本発明は、ユーザの呼を確立することと処理することに重点を置く。しかし、パケット交換型マルチメディアセッションを確立する前に、ユーザは、回線交換領域とＩＭＳ領域とに前記ユーザの位置を知らせることを目的として登録手順を実行する必要がある。この登録は、ＳＩＰプロトコルを使って行われ、ＭＡＧＣＦの一部であってユーザに代わって処理するユーザエージェントが、登録を行う。

以下に、アンカーポイントとしてのＭＡＧＣＦに対する登録について記述する。例えば、ある在圏ネットワークにローミングする間にサービスＭＳＣ−Ｓを変更することについて記述する実施形態をあげる。ＭＡＧＣＦをサポートしない在圏ネットワークへローミングする場合、最後に責任を持っていたＭＡＧＣＦが、アンカーポイントとして維持される。

本発明によると、前記ＭＡＧＣＦノードは、ＭＳＣ−ＳのようなＭＳＣの機能と、ユーザエージェントＵＡおよび統合型Ｐ−ＣＳＣＦの形態のＩＭＳ機能とを有する。従ってＭＡＧＣＦは、ＨＬＲおよびＩＭＳと通信する能力を有し、そして、少なくとも１つのＭＡＧＣＦが、ホームネットワーク内でユーザのために予測される(foreseen)。通常、１つのネットワークには複数のＭＳＣが提供され、その場合、ＭＳＣは、そのＭＳＣに割当てられた位置エリア内に位置するユーザに責任を持つ。ユーザの移動に起因して責任を持つＭＳＣが変わることは、対応する諸ノードにおいてそれに関するすべての必要な更新を行うことによって、ユーザを新たなＭＳＣに登録し、古いＭＳＣから登録解除することを目指すローミング手順を開始することを意味する。新たな位置エリアに進入した後、端末は、位置更新要求を新たなＭＳＣへ送信する。このメッセージを受信すると、ＭＳＣは、加入者がその責任において新規であることを識別し、従って、位置情報を更新するため、ＨＬＲにコンタクトする。位置更新メッセージを受信すると、ＨＬＲは、加入者が新たなＭＳＣエリアにローミングで進入したことを旧ＭＳＣに通知する。本発明によると、ユーザにサービス提供するＭＳＣは、ＭＡＧＣＦの一部であるか、あるいはユーザが在圏ネットワークにローミングで進入する場合には、前記在圏ネットワーク内に位置してＭＡＧＣＦの回線交換部分と通信する通常のＭＳＣであるかのいずれか一方であってもよいだろう。いずれの場合も、ＭＳＣはもはや加入者にサービス提供しないというメッセージが、ＨＬＲから送信される。ＭＳＣがＭＡＧＣＦの一部である場合、この場合には新たなＭＡＧＣＦがユーザに割当てられ、その結果、Ｓ−ＣＳＣＦにおいて在圏ＭＡＧＣＦのアドレスが変更され、加えてＳ−ＣＳＣＦのアドレスが、ＭＡＧＣＦ内に記憶される。在圏ＭＳＣがＭＡＧＣＦの一部ではない場合、例えば、ユーザが在圏ネットワークにローミングする場合、この場合には、在圏ＭＳＣは変わるがＭＡＧＣＦは同じままであるというようなことが起こるかもしれない。ＩＭＳシステムに登録する目的で、ＨＬＲは、位置更新を受信すると、ＭＳＣがＭＡＧＣＦの一部であるか否かをチェックする。さらにＨＬＲは、要求している加入者をチェックする。ＩＭＳの機能をユーザに提供することを目的として、前記ユーザは、ＩＭＳシステムに連れて行かれる必要がある。言い換えると、ユーザは、ＩＭＳシステムへの変更を積極的に宣言する必要があるか、あるいはシステムが、セルラユーザをＩＭＳシステムに連れて行くことを決定してもよいかいずれか一方である。ユーザについての対応する通知が、ＨＬＲの中で述べられることになる。ユーザが連れて行かれない場合、すでに知られているようにセルラユーザのための標準動作を適用することが提案される。ユーザがＩＭＳに連れて行かれる場合、一般にユーザ装置の中のＳＩＭカードに記憶されるすべてのパラメータを、ＨＬＲがＭＡＧＣＦに送信することが提案される。パラメータを受信すると、加入者を登録してＩＭＳシステムに加入させることを目的として、ユーザエージェントへのコンタクトが行われる。登録および加入の目的で適用されるプロトコルは、ＳＩＰプロトコルであることが望ましく、この場合、ユーザエージェントもＳＩＰ機能を実装される。ＩＭＳ登録の間、ユーザエージェントは、加入者に代わって動作する。登録に必要なすべてのステップは、ＭＡＧＣＦの中に統合されたＩＭＳエンティティを使って行われる。ステップには、例えば、認証されることになるユーザの認証が含まれてもよいだろう。しかし、本ソリューションは、回線交換アクセスの一部としてユーザがすでに認証されているという事実に依拠しているかもしれず、さらに、ＭＡＧＣＦが信頼できるＶＰＮに接続していると想定されるかもしれないことから、認証は強制ではないことが述べられるべきである。登録の結果は、ＭＡＧＣＦがＳ−ＣＳＣＦアドレスを記憶するということであり、登録についてのＩＭＳ規則に従って、Ｓ−ＣＳＣＦは、登録加入者に到達できるようなＭＡＧＣＦアドレスを記憶するが、できれば、ＭＡＧＣＦ内に統合されるようなＰ−ＣＳＣＦアドレスが記憶されることが望ましい。

ユーザがＭＡＧＣＦ機能のない在圏ネットワークにローミングする場合には、ＭＳＣへのローミングの場合、現行のＭＡＧＣＦがユーザのために責任を持ち続けることが提案される。ＭＡＧＣＦがまだユーザに割当てられない場合、デフォルトのＭＡＧＣＦを利用することが提案される。したがって、位置更新手順は、ユーザが在圏ネットワーク内に留まる限り、責任を持つＭＡＧＣＦではなくＨＬＲ内のＭＳＣの更新に限定される。

登録が終了した後、ＩＭＳ呼設定手順を含めてセッション確立手順が開始される。

従って、登録が成功した後では、ＭＡＧＣＦはＳ−ＣＳＣＦを知っていて、Ｓ−ＣＳＣＦはＭＡＧＣＦアドレスを有しており、特に、その機能が提案されたＭＡＧＣＦの一部であるＰ−ＣＳＣＦアドレスを有する。

以下に、本発明によって、呼処理が在圏ＭＡＧＣＦによって行われることをいかにして実行させるかという手順について記述する。この状況は、例えば、ＭＡＧＣＦの機能が利用できないようなリモートの在圏ネットワークにローミングする場合に起きることがありうる。この場合、最後の在圏ＭＡＧＣＦをローミングのアンカーとして用いることが提案される。

呼処理手順について、ユーザの回線交換型制御の端末ＭＳを含む回線交換型ＣＳネットワークとパケット交換型マルチメディアネットワークＰＳとの間のアンカーポイントであるＭＡＧＣＦの構造を概略的に示す図１に従って記述する。発信側回線交換型の呼を受信するように構成された発信側回線交換型ロジックＯｒｉｇ ＣＳがある。前記呼は、在圏ＭＳＣがＭＡＧＣＦの一部である場合、回線交換型制御のユーザ端末から直接受信されてもよいだろう。この状況は、ユーザがホームネットワーク内にいて、在圏ＭＳＣがＭＡＧＣＦ内に含まれることが定義される場合に起きる。あるいは、例えばユーザを処理する在圏ネットワーク内のＭＳＣ／ＶＬＲかもしれない在圏移動回線交換型機能から、ＭＡＧＣＦが発呼を受信するかもしれない。この場合、発信ユーザは、よく知られたかたちで、例えばＢ番号を用いて、ＭＳＣ／ＶＬＲにコンタクトし、そして、本発明によると、ＭＳＣ／ＶＬＲは、そのユーザに責任を持つＭＡＧＣＦへ呼をルーティングする必要がある。これは、ルーティング番号を割当てることによって保証される。さらなる記述において、ルーティング番号を割当てる２つの方法を示すが、１つは、呼に割当てられるローミング番号に基づくもので、呼がルーティングされることになるＭＡＧＣＦを一意のかたちで識別する。番号を割当てる目的で、インテリジェントネットワークＩＮ−機能が適用される。第２の方法では、Ｂ番号をＭＡＧＣＦへどのようにルーティングするかを定義するプレフィックスでＢ番号が強化される。また、両方の方法によって記述されるように、ルーティング番号は、例えばＨＬＲのような、ユーザのディレクトリから受信した、ユーザにサービス提供するアクセスゲートウェイノードについての指標に従って割当てられる。

発信側ＣＳ呼がユーザ端末から直接受信されるかＭＳＣ／ＶＬＲを経由して受信されるかに関わらず、次のステップにおいて、ＭＡＧＣＦは、発信側ＣＳ呼を変換部Ｃｏｎｖにおいて発信側パケットベースマルチメディア呼に変換し、それは、発信側パケットベースマルチメディア呼をパケットベースのマルチメディア領域に送信するように構成された発信側パケットベースマルチメディアロジックＯｒｉｇ ＰＳに渡される。本発明によって、アクセスゲートウェイノードの一部であるプロキシ呼制御機能Ｐ−ＣＳＣＦを有することが提案される。プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＩＭＳネットワークにおける最初のコンタクトポイントであり、ユーザから受信したＳＩＰメッセージをＳ−ＣＳＣＦへ転送するが、Ｐ−ＣＳＣＦは、Ｓ−ＣＳＣＦの名前を登録手順の結果としてすでに受信している。反対方向においては、Ｐ−ＣＳＣＦはＳＩＰ要求またはＳＩＰ応答をＵＥへ転送する。また前記Ｐ−ＣＳＣＦは、呼の着信のためＭＡＧＣＦに到達するのにも用いられる。従って、着信側のパケットベースのマルチメディア呼をパケットベースのマルチメディア領域から受信するように構成される着信側パケットベースのマルチメディアロジックＴｅｒｍ ＰＳが、提案される。前記呼は、プロキシ呼制御機能すなわちＰ−ＣＳＣＦのアドレスを使ってＭＡＧＣＦへルーティングされる。前記呼は、交換機能Ｃｏｎｖにおいて着信側の回線交換型呼に変換され、着信側の回線交換型ロジックＴｅｒｍ ＣＳを使って回線交換型制御のユーザ端末へ送信される。着呼は、在圏回線交換型ノードが回線交換型機能の一部である場合には回線交換型制御のユーザ端末へ直接送信され、また、前記在圏回線交換型ノードが回線交換型機能の一部でない場合には在圏回線交換型ノードへルーティングされることになるであろう。

さらに、ＭＡＧＣＦは、受信された発信側回線交換型呼を回線交換型領域において処理することから抑制するように構成される、抑制機能を有することが提案される。これによって、発呼が本当にＩＭＳ領域内で処理されることが保証される。回線交換型呼をユーザに配信するためには、受信された着信側のパケットベースのマルチメディア呼がＭＡＧＣＦに着信することが保証されるべきである。

以下に、本発明による方法について、図２および図３に関して記述する。図２は、呼を発信する事例を示す。第１のステップ２１で、ＭＡＧＣＦは、発信側の回線交換型呼を受信する。前記呼は、在圏移動回線交換型機能ＭＳＣがＭＡＧＣＦと統合されている場合、回線交換型制御のユーザ端末から直接受信されてもよい。別個の在圏移動回線交換型機能によってユーザが処理される場合、呼は、ルーティング番号を使って在圏ＭＡＧＣＦへ転送されることになる。ルーティング番号の割当てについて、さらに記述する。ステップ２２で、回線交換型呼は、発信側のパケットベースのマルチメディア呼に変換され、ステップ２３で、パケットベースのマルチメディア領域２４へ送信される。パケット交換型マルチメディア部分において、プロキシ呼制御機能Ｐ−ＣＳＣＦが、呼の転送に関与する。

図３は、着呼の実施形態を示す図である。ステップ３１で、着信側の（terminating, 着信している）パケットベースのマルチメディア呼が、パケットベースのマルチメディア領域から受信される。呼のルーティングが、プロキシ呼制御機能Ｐ−ＣＳＣＦによって行われる。ステップ３２で、呼は、着信側回線交換型呼に変換され、上述したように直接または在圏ＭＳＣ／ＶＬＲを介して回線交換型制御のユーザ端末へ送信される。

以下に本発明の諸実施形態を示す。

以下に、ユーザが在圏ネットワークへローミングして在圏ＭＡＧＣＦの一部ではないＭＳＣ／ＶＬＲによってサービス提供される場合の、ルーティング番号の割当てを示す実施形態について記述する。在圏ＭＳＣ／ＶＬＲからのすべての発信側の呼をローミングのアンカーであるＭＡＧＣＦにルーティングすることを目的として、ＣＡＭＥＬメカニズムが一例として用いられる。ＣＡＭＥＬアプローチは、一例として採用するのであって、本発明を限定するものではない。

以下に、本発明の一実施形態で用いられるＣＡＭＥＬネットワークのいくつかの本質的特徴について述べる。ＣＡＭＥＬは、移動加入者がホームネットワーク外でローミングしているときでも、ネットワークオペレータが移動加入者にオペレータ固有のサービスを提供できるようにするネットワーク機能である。ＣＡＭＥＬのアーキテクチャによると、ＣＡＭＥＬサービス制御機能（ｇｓｍＳＣＦ）の機能は、オペレータ固有のサービスを実装するのに必要なＣＡＭＥＬサービスロジックを含む、加入者のホームＰＬＭＮに備えられることになる。さらにまた、ｇｓｍＳＣＦから与えられた命令を処理して実行するトランザクションに参加するＣＡＭＥＬサービス交換機能（ｇｓｍＳＳＦ）もある。ＣＡＭＥＬアーキテクチャにおいてノード間の通信用によく用いられるプロトコルは、ＣＡＭＥＬアプリケーションパート（ＣＡＰ）プロトコルである。ＣＡＭＥＬの枠組みにおいて、いわゆるトリガ検出ポイント（ＴＤＰ）が定義され、トリガ検出ポイントは、トランザクション処理の中でｇｓｍＳＣＦがコンタクトされるべき時点を指定する。ＴＤＰに合致すると、ｇｓｍＳＳＦは、ｇｓｍＳＣＦとの対話を開始する。ｇｓｍＳＣＦについては複数の機能が定義されており、なかでも、ｇｓｍＳＣＦには、例えば宛先アドレスやトランザクションの持続時間など、進行中のトランザクションについての情報が提供されうる。

すべての呼が在圏ＭＡＧＣＦによって処理されることを保証するための本発明の実施形態に戻ると、これを目的とした２つの可能性のある手法を以下に提示する。第１のソリューションでは、在圏ＭＳＣ／ＶＬＲから在圏ＭＡＧＣＦへルーティングする目的で呼に動的に割当てられるローミング番号が用いられ、第２は、実際にダイヤルされたＢ番号にプレフィックスを追加することによってＢ番号を修正する。

第１のアプローチは、一時的なローミング番号の使用という考え方に基づく。このソリューションについて、図４に関して記述する。

図４にＭＳＣ／ＶＬＲが提示されるが、ＭＳＣ／ＶＬＲは、そのサービス提供エリアすなわちＡ在圏ネットワークの中に位置しているユーザにサービス提供する。本発明によると、ＭＳＣ／ＶＬＲは、ホームネットワークすなわちＡホームの中に位置していて、ｇｓｍＳＣＦ機能も備えているＭＡＧＣＦと通信する。したがって、ＭＡＧＣＦは、回線交換型領域への接続性を提供する。他方、ＭＡＧＣＦは、ＩＭＳ特にＳ−ＣＳＣＦへのシグナリング通信を提供する。Ｓ−ＣＳＣＦは、ＩＭＳ領域内でユーザにサービス提供するノードである。Ｓ−ＣＳＣＦは、呼サーバとして動作し、呼のシグナリングを処理する。さらに、図４によると、ユーザが要求したサービスをホストして実行するＩＭＳ ＡＳも存在する。ＡＳは例えば呼のフローおよびユーザインタフェースの加入者との対話に責任を持つ。ＩＭＳ ＡＳは、プッシュトゥトーク、リングバックトーン、プリペイド発信カード、マルチメディア会議、およびマルチメディア・メッセージング・サービス・ロジックのようなサービスをＩＭＳへ配信する。さらに、回線交換型ネットワーク内に位置するユーザデータベースであるＨＬＲも存在する。

本発明の好適実施形態によって、２つの独立したレイヤ上でユーザプレーンとユーザシグナリングとの送信を行うことが提案される。ユーザプレーンにおいて、ＩＰベースのメディアストリームをしかるべく変換するには、相互作用する要素が必要である。メディアゲートウェイ（ＭＧＷ）ノードは、この機能に責任を持つ。マルチメディア・リソース機能プロセッサ（ＭＲＦＰ）は、アプリケーションレイヤのための補助的なメディア処理、例えば、音声ミキシング、コンテンツ録音・再生、コーデックのトランスコーディング、統計の取得などを提供し、そして、ＭＧＷに接続される。ＭＲＦＰは、単一のアプリケーション専用ではなく、複数のアプリケーションに対する共有リソースとしてメディア処理を提供する。メディアリソース機能制御装置（ＭＲＦＣ）は、ＩＭＳ内でＡＳとＭＲＦＰリソースとの間のメディアリソース仲介機能を提供し、そして、アプリケーションサーバの一部または別個のネットワーク要素として実装されてもよい。

図４では、シグナリング情報のフローが点線で描かれ、実線は、ユーザプレーンのフローを表す。

図４に関して、ＭＡＧＣＦに呼処理を配信することを目的として、以下のステップが提案される。

ユーザが在圏ネットワークへ移動すると、ユーザの新たな位置についてＨＬＲに通知することを目的として、最初に位置更新手順が行われることになる。ＭＳＣ／ＶＬＲとＨＬＲとの間の通信が、ＭＡＰプロトコルによって実現される。従って、ＨＬＲは、「更新位置（Ｕｐｄａｔｅ Ｌｏｃａｔｉｏｎ）」に関するＭＡＰメッセージを受信し、ＨＬＲは、送信側ノードがＭＡＧＣＦの機能をサポートするかどうか判断する。これは、ＭＡＧＣＦの機能がサポートされているという送信側ノードからの指標を含むことによって達成されてもよい。あるいは、ＨＬＲは、ＨＬＲの中で管理される所定のリストの中でチェックすることができる。ＨＬＲが、「更新位置」を送信するノードによってＭＡＧＣＦ機能がサポートされていないと判断した場合、ＨＬＲがＭＡＰ動作「加入者データを挿入する（Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ）」により、送信されたデータにＣＡＭＥＬデータを追加することが提案される。このＣＡＭＥＬデータは、「情報を収集する（Ｃｏｌｌｅｃｔ＿Ｉｎｆｏ）」のＣＡＭＥＬトリガ検出ポイントを強化し、それによって、ホームネットワーク内のユーザの呼の処理に責任を持つｇｓｍＳＣＦへの接続を確立するよう、ＭＳＣ／ＶＬＲへの指示が行われる。コンタクトすべきｇｓｍＳＣＦのアドレスとして、ＨＬＲは、現在サービス提供しているＭＡＧＣＦのアドレスを含める（ステップ４１）。ＨＬＲの中で在圏ＭＡＧＣＦが知られていない場合、ＨＬＲは、所定のデフォルトＭＡＧＣＦを用いてもよい。位置手順の結果として、ＭＳＣ／ＶＬＲは、ＭＡＧＣＦのコンタクトアドレスを有する。ステップ４２において、ＭＳＣ／ＶＬＲは、呼ばれたＢ番号を含む呼設定要求を受信する。呼の要求を受信すると即座にＣＡＭＥＬトリガ検出ポイント「情報を収集する（Ｃｏｌｌｅｃｔ＿Ｉｎｆｏ）」がトリガされ、その結果、ＭＳＣ／ＶＬＲは、呼設定処理を中止して、ＨＬＲから受信したＣＡＭＥＬ加入データによってアドレス指定されたようにｇｓｍＳＣＦにコンタクトする。ＣＡＰメッセージＩｎｉｔｉａｌＤＰが、Ｂ番号を含めてｇｓｍＳＣＦへ送信される。ＨＬＲは、在圏ＭＡＧＣＦのアドレスをｇｓｍＳＣＦアドレスとして提供したのだから、ＭＡＧＣＦはステップ４３で実際にコンタクトされる。次のステップ４４において、ＭＡＧＣＦが、呼をこのＭＡＧＣＦにルーティングするのに用いられることになる一時的なローミング番号を割当てる。ＭＡＧＣＦは、着信するローミング番号の呼を後で正しいＢ番号と合致させられるように、受信したＢ番号を記憶する。ステップ４５において、ＭＡＧＣＦは、ＭＳＣ／ＶＬＲに指示して、発信呼をそのローミング番号にルーティングさせる。ＣＡＰメッセージ「接続（Ｃｏｎｎｅｃｔ）」がＭＡＧＣＦからＭＳＣ／ＶＬＲへ送信される。受信されたローミング番号を使って、在圏ＭＳＣ／ＶＬＲは、保留していた呼をステップ４６でＭＡＧＣＦへルーティングする。ステップ４７において、ＭＡＧＣＦは、ローミング番号と共に着信する呼を受信する。次いでＭＡＧＣＦは、ローミング番号を割当てる時に記憶された、発信時にダイヤルされたＢ番号を調べる。ステップ４８において、発信側サービスを実行する目的のためにＡ加入者にサービス提供する責任を持つＳ−ＣＳＣＦに呼をルーティングするため、着信先としてＢ番号が用いられる。

従って、記述したアプローチは、在圏ネットワーク内で開始された発信呼が、ＩＭＳ領域で処理されることを目的としてＭＡＧＣＦへ転送されることを保証する。呼の処理について、さらに記述する。

下記で、ローミングのアンカーポイントであるＭＡＧＣＦノードへすべての発信呼をルーティングするための第２のアプローチを提示する。このソリューションは、Ｂ番号に対してプレフィックスを用いるという概念に基づいており、図５に関してこれを記述する。図５は、図４に関して開示したすべてのノードを備えているが、違う点は、ｇｓｍＳＣＦが別のノードとして描かれていることである。しかし、これは、本発明の保護範囲に関する何らかの制限とみなされるべきではない。本実施形態によると、ｇｓｍＳＣＦは、特有のプレフィックスをＢ番号に追加するためのデータベースとして用いられることになり、このプレフィックスは、選択されたＭＡＧＣＦにとって特有である必要があり、そして、別の選択されたＭＡＧＣＦノードには別のプレフィックスが用いられることが望ましい。従って、ｇｓｍＳＣＦは、プレフィックスを追加する中心点であることから、別個のノードとして示されているけれども、ｇｓｍＳＣＦは他のいずれかのノードと同じ場所に配置されてもよいだろう。図５に戻ると、第１のアプローチと同様に、ステップ５１で、ＨＬＲは、位置更新を送信しているノードがＭＡＧＣＦ機能をサポートするかどうか判断する。この判断は、第１のアプローチで開示されたように、好適であればいずれの方法で行われてもよいだろう。「位置更新（Ｕｐｄａｔｅ Ｌｏｃａｔｉｏｎ）」を送信しているノードはＭＡＧＣＦ機能をサポートしていないとＨＬＲが判断した場合、ＨＬＲはステップ５１で、現在どのＭＡＧＣＦがユーザにサービス提供しているかという指標と、在圏ｇｓｍＳＣＦのアドレスとを添えて、「情報を収集する（Ｃｏｌｌｅｃｔ＿Ｉｎｆｏ）」のＣＡＭＥＬトリガ検出ポイントを送信する。あるいは、在圏ｇｓｍＳＣＦのアドレスは送信されず、この場合、ホームネットワーク内のいかなるｇｓｍＳＣＦがコンタクトされてもよい。すでに述べたとおり、ＨＬＲにおいて知られている在圏ＭＡＧＣＦが存在しない場合、ＨＬＲは所定のデフォルトＭＡＧＣＦを用いることができる。ステップ５２で、被呼Ｂ番号を搬送する在圏ＭＳＣ／ＶＬＲにおいて、呼設定要求が受信される。前記要求を受信すると、ＣＡＭＥＬトリガ検出ポイント「情報を収集する（Ｃｏｌｌｅｃｔ＿Ｉｎｆｏ）」が即座にトリガされ、その結果、ＭＳＣ／ＶＬＲは、呼設定処理を停止し、ＨＬＲから受信したＣＡＭＥＬ加入データによってアドレス指定されるｇｓｍＳＣＦにコンタクトする。ステップ５３において、Ｂ番号と在圏ＭＡＧＣＦの指標とを含めて、ＣＡＰメッセージ「ＩｎｉｔｉａｌＤＰ」が、ｇｓｍＳＣＦへ送信される。ｇｓｍＳＣＦは、どのＭＡＧＣＦが加入者に現在サービスを提供しているのかを、受信した指標から認識する。次いで、ｇｓｍＳＣＦは、その在圏ＭＡＧＣＦに特有のプレフィックスをＢ番号に追加する。プレフィックスは、ｇｓｍＳＣＦにおいて事前定義されることが望ましい。次いでｇｓｍＳＣＦは、この修正されたＢ番号をＭＳＣ／ＶＬＲへ返信し、そして、この新規番号への呼設定を続けるように要求する。ステップ５４で、この目的でＣＡＰメッセージ「接続する（Ｃｏｎｎｅｃｔ）」が、ｇｓｍＳＣＦからＭＳＣ／ＶＬＲへ送信される。ステップ５５で、受信したプレフィックスのついたＢ番号を使って、在圏ＭＳＣ／ＶＬＲが、呼をＭＡＧＣＦへルーティングする。ＭＡＧＣＦは、プレフィックスのついたＢ番号と共に着信する呼を受信して、プレフィックスを削除する。ここで言及しておくべきだが、正しくサービス提供される加入者をＭＡＧＣＦが識別できるようにする目的で、Ａ番号もＭＳＣ／ＶＬＲによって提供されることが望ましい。ステップ５６で、発信側サービスを実行する目的で、Ａ加入者のＳ−ＣＳＣＦに呼がルーティングされる。ここで、Ｂ番号は、再び着信先として用いられる。

このように、第２のアプローチも、すべての発信呼が、ユーザにサービス提供するＭＡＧＣＦに提供されることを保証する。

どちらのアプローチにおいても、ＭＡＧＣＦ機能をサポートしないネットワークにローミングする場合、最後にサービス提供したＭＡＧＣＦが、ローミングのアンカーとして用いられる。しかし、ＩＭＳ ＡＳはすべてのサービスの処理に責任を持つことから、ＭＳＣ／ＶＬＲにおけるサービスの実行は抑制されるべきである。できれば、ＭＳＣ／ＶＬＲがあらゆるサービスを処理することを防止する目的で、加入者データをフィルタリングするメカニズムが提案されることが望ましい。ＨＬＲは、加入者が、リモートの在圏ネットワーク内でローミングしていることを知っている。従って、ＭＡＰ動作「加入者データを挿入する（Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ ｄａｔａ）」を送信する場合、ＨＬＲは、データをＭＳＣ／ＶＬＲへ送信する前に、すべての補助的なサービス加入登録をフィルタで除去する。さらに、ホームネットワーク内でローミングする場合、加入者データがフィルタにかけられないで、いずれのサービス呼び出しであってもその抑制をＭＡＧＣＦが管理することが提案される。もう１つの選択肢は、加入者データがホームネットワーク内でＭＡＧＣＦに送信される場合にも、加入者データをフィルタリングすることである。

以下に、ホームネットワーク内で発呼を実行するための基本的アーキテクチャを、図６に関して提示する。図６は、呼を発信するユーザであるユーザＡを示す。前記ユーザは、例えばＵＴＲＡＮまたはＧＥＲＡＮのような無線アクセスネットワーク上でＭＡＧＣＦに接続する。ユーザは、ホームネットワーク内で呼を実行するのだから、ＭＡＧＣＦノードのＭＳＣ−Ｓ部分に直接接続される。ＭＡＧＣＦノードのＩＭＳ部分は、ＳＩＰプロトコルによってＳ−ＣＳＣＦへの接続を伝達する。特に、統合されているＰ−ＣＳＣＦは、Ｓ−ＣＳＣＦのアドレスを知っている。また、Ｓ−ＣＳＣＦと通信するＩＭＳ ＡＳノードもある。

点線は、シグナリングメッセージのフローを示す。また図６では、ＭＧＷノードおよびＭＲＦＰノードが描かれており、それらは、実線で示すユーザプレーンの送信に関与する。

図６によると、ステップ６１でＭＡＧＣＦにおいて端末から呼の要求が受信されると、ＭＡＧＣＦは、いかなる発信側サービスをも呼出さず、また、受信したＢ番号を見ることもない。ＭＡＧＣＦは、サービス提供される加入者のＩＭＳに呼をルーティングする。ＭＡＧＣＦ内のＰ−ＣＳＣＦは、やはりＩＭＳ登録からＳ−ＣＳＣＦを知っていることから、呼は、ステップ６２で一直線にＳ−ＣＳＣＦへルーティングされる。ステップ６３において、Ｓ−ＣＳＣＦは、発信側サービスとダイヤルされたＢ番号の分析とを呼出すために、ＩＭＳ ＡＳを関与させる。発信側サービスをチェックすることには、例えば、すべての発信呼の補助的サービスを禁止することが含まれてもよく、それは、例えば第三者に電話をかける場合に用いられてもよいだろうし、その場合、ユーザがすべての着信呼について依然として到達可能とする一方で、前記ユーザが呼を発信することを禁止することを目的として、禁止サービスが起動されてもよいだろう。

さらに、ＭＡＧＣＦは、ユーザプレーンを処理するため、ＭＧＷを選択する。ＩＭＳ ＡＳは、ユーザプレーンを処理するため、ＭＲＦＰを関与させる。ＭＧＷとＭＲＦＰとは、別のノードであることが望ましい。

以下に、ホームネットワーク内の発信呼に関するメッセージフローのシーケンスについて、図７に関して記述する。図７には、被呼ユーザＢ：ＩＭＳへの呼を発信する発信ユーザＵＥ Ａが描かれている。ユーザは、ＭＡＧＣＦノードに統合されたＭＳＣ−Ｓ機能にコンタクトすることによってホームネットワーク内で呼を実行するのであるから、従って、ＭＳＣ−Ｓ機能を持つＭＡＧＣＦノードが描かれている。さらに、発信ユーザにとっては在圏Ｓ−ＣＳＣＦであるＡ：Ｓ−ＣＳＣＦと、ユーザに責任を持つＡ：ＩＭＳ ＡＳとがある。２つのエンティティ間の線は、メッセージのフローを示し、矢印は、メッセージ交換の方向を示す。

呼発信手順の第１のステップにおいて、発信側ユーザＵＥ Ａは、２４．０００８：ＣＳ Ｓｅｒｖｉｃｅ ＲｅｑｕｅｓｔをＭＡＧＣＦ、特にＭＳＣ−Ｓへ送信する。前記ノードは、既に知られているように、最初に発信側ユーザのための回線交換型ユーザ認証を実行し、次のステップで、前記ユーザは２４．００８：Ｓｅｔｕｐメッセージを送信し、それは、２４．００８：Ｃａｌｌ Ｐｒｏｃｅｅｄｉｎｇメッセージによって確認される。前述のように、ＭＡＧＣＦはユーザに責任を持つＳ−ＣＳＣＦのアドレスを知っており、従って、ＩＭＳ呼設定手順を開始するのに、前記アドレスが用いられる。特に、統合されているＰ−ＣＳＣＦは、Ｓ−ＣＳＣＦのアドレスを知っている。最初のステップで、ＳＩＰ：Ｉｎｖｉｔｅが、発呼ユーザＡにサービス提供するＳ−ＣＳＣＦへ送信される。前記メッセージは、パラメータとして、被呼ユーザＢの電話番号と、ｔｅｌ−ＵＲＬと、ユーザＡのセッション記述プロトコルパラメータＳＤＰ Ａとを含む。ＳＤＰパラメータは、通信エンティティ間で、すなわち発信側ユーザと着信側ユーザの間で、ＳＤＰ交渉手順の枠組みの中で交換される。交渉手順の間、例えばメディアフローの数やコーデックのようなメディア特性が交渉される。

図７に戻る。Ａ：Ｓ−ＣＳＣＦは、発信側サービスを呼出すため、そして、ダイヤルされたＢ番号を分析するため、ＩＳＣ：Ｉｎｖｉｔｅ（Ｔｅｌ−ＵＲＬ、ＳＤＰ Ａ）をＡ：ＩＭＳ ＡＳへ送信する。Ａ：ＩＭＳ ＡＳから応答を受信すると、Ａ：Ｓ−ＣＳＣＦは、ＳＩＰ：Ｉｎｖｉｔｅ（ＳＩＰ−ＵＲＬ、ＳＤＰ Ａ）メッセージを着信側ユーザＢ：ＩＭＳへ送信する。次のステップで、提案されるＳＤＰパラメータを搬送するＳＩＰ：１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ（ＳＤＰ Ｂ）を着信側ユーザから送信することによって、ＳＤＰ交渉手順が開始される。提案されたＳＤＰパラメータがサポートされているかどうかチェックすることを目的として、そして、交渉されたセッションパラメータに必要なリソースを予約することを目的として、責任を持つＲＡＮ（無線アクセスネットワーク）にＭＡＧＣＦがコンタクトした後で、前記メッセージは、ＭＡＧＣＦへ転送される。これは、Ａｓｓｉｇｎｍｅｎｔ ＲｅｑｕｅｓｔとＡｓｓｉｇｎｍｅｎｔ Ｃｏｍｐｌｅｔｅというメッセージによって行われる。次のステップで、ＭＡＧＣＦは、ＳＩＰ：ＵｐｄａｔｅメッセージをＡ：Ｓ−ＣＳＣＦを介してＢ：ＩＭＳへ送信し、Ｂ：ＩＭＳは、ＳＩＰ：２００ ＯＫ（Ｕｐｄａｔｅ）」メッセージを送信することによって新規パラメータに同意する。被呼ユーザがフリーであって呼を受信できる場合、対応する指標、すなわちＳＩＰ：１８０ ＲｉｎｇｉｎｇがＭＡＧＣＦへ送信され、ＭＡＧＣＦは、それを回線交換型プロトコルベースのメッセージ、すなわち２４．００８：Ａｌｅｒｔｉｎｇへと変換する。被呼ユーザＢ：ＩＭＳからＳＩＰ：２００ ＯＫ（Ｉｎｖｉｔｅ）メッセージを受信した後、確立手順を完了することを目的として、２４．００８：Ｃｏｎｎｅｃｔメッセージが、発信側ユーザであるＵＥ Ａへ送信される。呼設定手順の実行が成功したという確認が、２４．００８：Ｃｏｎｎｅｃｔ ＡｃｋメッセージおよびＳＩＰ：Ａｃｋメッセージによって着信側ユーザへ送信される。呼設定手順の実行が成功した後、音声呼が実行されてもよいだろう。

以下に、ＭＡＧＣＦの機能をサポートしないリモートの在圏ネットワーク内で発呼を実行するための一実施形態を提示する。このシナリオにおいて、このネットワーク内でローミングするユーザのために、最後の在圏ＭＡＧＣＦが、ローミングのアンカーポイントとして用いられる。前の実施形態において記述したように、ＨＬＲは、呼処理がアンカーＭＡＧＣＦ内で実行されるように仕向けることを目的として、加入者データをＭＳＣ／ＶＬＲに挿入する際にＣＡＭＥＬデータを加入者データに追加する。従って、呼の要求が受信されると、ＭＳＣ／ＶＬＲは、ＣＡＭＥＬデータに気付き、それによって、呼は、ローミングのアンカーであるＭＡＧＣＦへルーティングされる。呼がＭＡＧＣＦに到達した後、呼設定は、ホームネットワークの場合について続く、すなわち、呼が発信側サービスの実行のためにＳ−ＣＳＣＦへ転送される。

以下に、メッセージのフローを示す図９に関して、発信呼についてより詳細に提示する。図９は、図７に対応するが、違う点は、図９には、在圏ネットワークに位置するＭＳＣ／ＶＬＲがさらに描かれていることである。さらに、図９では、ＭＡＧＣＦは、ｇｓｍＳＣＦ機能も共に描かれている。しかし、これは制限であるとみなされるべきではない。代案として、ｇｓｍＳＣＦが別個のノードとして提供されてもよいだろう。

最初のステップで、ユーザＵＥは、２４．０００８：ＣＭ Ｓｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージをＭＳＣ／ＶＬＲへ送信し、続いて２４．００８：Ｓｅｔｕｐ（Ｂ番号）を送信し、それが、メッセージ２４．００８：Ｃａｌｌ Ｐｒｏｃｅｓｓｉｎｇによって確認される。これらのメッセージの受信は、ＭＳＣ／ＶＬＲにとって、ユーザがＢ番号を持つユーザへの接続を確立したいと望んでいることを意味する。しかし、前の実施形態で記述したように、登録手順の間にＭＳＣ／ＶＬＲは、ユーザがｇｓｍＳＣＦによって処理されることになると通知するＣＡＭＥＬメッセージを、ＨＬＲからすでに受信している。この情報に基づいて、ＭＳＣ／ＶＬＲは呼をｇｓｍＳＣＦ上でＭＡＧＣＦへルーティングする。前の実施形態では、呼をどのようにしてＭＡＧＣＦへルーティングするかについて論じている。この特定の実施形態では、ローミング番号を用いたルーティングを示す。このアプローチによると、ＭＳＣ／ＶＬＲはｇｓｍＳＣＦのアドレスを有しており、このアドレスはＭＡＧＣＦのアドレスでもある。このアドレスを使って、ＭＡＧＣＦがコンタクトされる（ＣＡＰ：ＩｎｉｔｉａｌＤＰ（Ｂ番号））。このメッセージを受信すると、ＭＡＧＣＦは、ルーティング番号を提供するための手順を行い、それには、ローミング番号を割当てることと、割当てられるローミング番号をＢ番号に関連して配置することとが含まれる。前記ローミング番号は、ローミング番号を使って呼をルーティングすること（ＩＳＵＰ：ＩＡＭ（ローミング番号））を目的として、ＣＡＰ：Ｃｏｎｎｅｃｔ（ローミング番号）メッセージによってＭＳＣ／ＶＬＲへ送信される。残りの手順は、呼を発信する手順を伝えることにつながる図７に関して記述したステップと同様である。

以下に、ホームネットワーク内に着信する呼について記述する実施形態について、図１０に関して記述する。図１０の構造は、図６の構造に対応する。ステップ１０１において、Ｓ−ＣＳＣＦは、ユーザＢに着信することになる呼を受信する。Ｓ−ＳＣＣＦは、ステップ１０２および１０３で、着信側サービスを実行するためにＩＭＳ ＡＳを関与させる。ここで、発信側の場合と同様の方法で、着信側加入者のサービスがチェックされる。例えば、国際ローミングの際にすべての着信呼の禁止が起動されてもよいだろう。この例においては、ユーザがこのサービスに加入しているかどうかＩＭＳがチェックし、前記ユーザが国際ローミングしている場合、呼がブロックされる。

Ｓ−ＣＳＣＦは、上記の実施形態において記述したように、ＩＭＳ登録から、在圏ＭＡＧＣＦのアドレスを知っている。特に、統合されているＰ−ＣＳＣＦのアドレスは、Ｓ−ＣＳＣＦに知られている。ＳＩＰプロトコルを使って、１０４で、呼はＭＡＧＣＦへ転送され、特に、ＭＡＧＣＦの中に位置するプロキシゲートウェイであるＰ−ＣＳＣＦへ転送される。ＭＡＧＣＦは、呼を端末へ着信させるが、ただし、いかなるサービスも呼出さない。着信とは、ＩＭＳ呼がＭＡＧＣＦに着信してＣＳ呼に変換され、それが、次いで、例えば２４．０００８プロトコルを使って、例えばＵＴＲＡＮまたはＧＥＲＡＮのようなアクセスネットワーク上でＢユーザへ転送されることを意味する（１０５）。記述された呼の着信側ルーティングは、シグナリング情報のルーティングに限定されることが望ましい。ペイロード情報は、図６で実線を使って描かれたように、ＭＲＦＰおよびＭＧＷを介して直接アクセスネットワークへ転送されることが提案される。

以下に、呼の着信手順のためのメッセージのフローを、図１１に関して提示する。図１１は、ユーザＢすなわちＵＥ Ｂに接続されることを望んでいるＩＭＳユーザすなわちＡ：ＩＭＳを示す。第１のステップにおいて、Ｉ−ＣＳＣＦがコンタクトされるが、Ｉ−ＣＳＣＦは、オペレータのネットワーク内でそのネットワークオペレータの加入者またはそのネットワークオペレータのサービスエリア内に現在位置するローミングユーザに宛てられた、すべての接続に責任を持つ。コンタクトすることは、ＳＩＰ：Ｉｎｖｉｔｅ（ＳＩＰ ＵＲＬ、ＳＤＰ Ａ）によって行われる。オペレータのネットワーク内の複数のＩ−ＣＳＣＦが、利用可能であってもよいだろう。Ｉ−ＣＳＣＦによって行われる主な機能は、ＳＩＰ登録を行っているユーザにＳ−ＣＳＣＦを割当てることである。本発明によると、Ｓ−ＣＳＣＦは、ＭＡＧＣＦのアドレスを知っており、特に、ＭＡＧＣＦに統合されたＰ−ＣＳＣＦのアドレスを知っており、従って、ＳＩＰ：ＩｎｖｉｔｅがＭＡＧＣＦに転送されてもよいだろう。図１１に関して、メッセージをＭＡＧＣＦに転送する前に、ＩＭＳサービスを着信することを目的として、Ｂ：ＩＭＳ ＡＳがＩＳＣ：Ｉｎｖｉｔｅメッセージを使ってコンタクトされる。ＳＩＰ：Ｉｎｖｉｔｅ（ＳＩＰ−ＵＲＬ、ＳＤＰ Ａ）を受信すると、ＩＭＳ呼がＭＡＧＣＦに着信し、２４．００８：Ｐａｇｉｎｇメッセージを被呼ユーザすなわちＵＥ Ｂへ送信することと、回線交換型認証を行うことと、２４．００８：Ｃａｌｌ Ｓｅｔｕｐメッセージおよび２４．００８：Ｃａｌｌ Ｃｏｎｆｉｒｍｅｄメッセージを使ってＵＥ Ｂへの呼を確立することとを含んだ、回線交換型処理が開始される。残りの手順は、図７に関して記述した手順と同様である。これは、ＭＡＧＣＦ内に位置するＩＭＳ部分、即ちＰ−ＣＳＣＦが、ＳＩＰ：１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ（ＳＤＰ Ｂ）を、提案されたパラメータと共にＡ：ＩＭＳユーザへ送信することを意味する。図１１によると、両方の通信側におけるパラメータの更新は、ＳＩＰ：ＵｐｄａｔｅメッセージおよびＳＩＰ：２００ ＯＫメッセージを使って行われる。パラメータが割当てられると、呼び出し信号である２４．００８：ＡｌｅｒｔｉｎｇおよびＳＩＰ：１８０ Ｒｉｎｇｉｎｇが発生し、そして、接続手順である２４．００８：ＣｏｎｎｅｃｔおよびＳＩＰ：２００ ＯＫ（ｉｎｖｉｔｅ）が、確認メッセージであるＳＩＰ：ＡＣＫおよび２４．００８：Ｃｏｎｎｅｃｔ ＡＣＫと共に行われる。

もちろん、発呼ユーザが、ＭＡＧＣＦ機能のない在圏ネットワークＢ在圏の中に位置することもあるだろう。以下に、このシナリオについて、ユーザＢに対する着呼を示す図１２に関して記述する。この場合、呼のＩＭＳ部分は、ユーザに責任を持ち、ローミングのアンカーとして動作するＭＡＧＣＦ内に着信することになる。従って、着呼は、Ｓ−ＣＳＣＦへ１２１でルーティングされ、次いでＳ−ＣＳＣＦは、着信側サービスを実行するため、１２２および１２３でＩＭＳ ＡＳを関与させる。すでに述べたように、Ｓ−ＣＳＣＦは、ＩＭＳ登録から在圏ＭＡＧＣＦのアドレスを知っている。従って、１２４で、呼は好適にはＳＩＰプロトコルを使ってＭＡＧＣＦへ送信される。前記ＭＡＧＣＦは、自分がローミングのアンカーとして動作することを認識し、従って、着呼がＭＡＧＣＦ内で受信される場合、ＭＡＧＣＦは、自分がその呼を直接着信させられずに在圏ＭＳＣ／ＶＬＲを関与させる必要があることを認識する。従って、ＭＡＧＣＦは、ＧＳＭＣとして動作して、ＨＬＲにルーティング情報を求める。ＨＬＲは、１２６で、在圏ＭＳＣ／ＶＬＲからローミング番号を取ってきて、それを１２５でＭＡＧＣＦに返信する。次いで１２７で、呼は、そのローミング番号を用いてＭＡＧＣＦからＭＳＣ／ＶＬＲへルーティングされる。ここで留意すべきだが、サービスの実行にはＩＭＳ ＡＳが責任を持つことから、ＨＬＲでは前記サービスが実行されない。シグナリングのシーケンスは、図１１に関して記述したシーケンスと同様であるが、違う点は、対応するシグナリング、好適にはＭＡＰベースのシグナリングが、ＭＡＧＣＦ、ＨＬＲ、およびＭＳＣ／ＶＬＲの間で交換され、前記ＭＳＣ／ＶＬＲが、ユーザＢへの接続を確立することに責任を持つことである。

上記の諸実施形態は、ＧＳＭやＧＰＲＳなどにおいて提供されるもののようなセルラ交換型制御のユーザ装置を、ＵＭＴＳに関連して開発されたＩＭＳサービスと統合することに基づくものである。しかし、本発明は、これらのネットワークだけに限定されない。さらなる例をあげるとすれば、ＧＰＲＳまたはＵＭＴＳ内に存在するノードと対応するノードを提供する、ＣＤＭＡ２０００であってもよいだろう。

Claims (9)

1. 回線交換型制御領域（ＣＳ）に位置する回線交換型制御のユーザ端末（ＭＳ）のためにパケットベースのマルチメディアシステム（ＩＭＳ）領域における呼を処理するように構成されたアクセスゲートウェイノード（ＭＡＧＣＦ）であって、
   前記回線交換型制御のユーザ端末（ＭＳ）から、発信の回線交換型の呼を受信するように構成された発信側回線交換型ロジック（Ｏｒｇ ＣＳ）と、
   当該アクセスゲートウェイノード（ＭＡＧＣＦ）の一部であるプロキシ呼制御機能（Ｐ−ＣＳＣＦ）を介して発信のパケットベースのマルチメディア呼を前記パケットベースのマルチメディア領域（ＩＭＳ）へ送信するように構成された発信側パケットベースマルチメディアロジック（Ｏｒｇ ＰＳ）と、
   前記パケットベースのマルチメディア領域（ＩＭＳ）から、当該アクセスゲートウェイノード（ＭＡＧＣＦ）の一部であるプロキシ呼制御機能（Ｐ−ＣＳＣＦ）へ宛てられた着信のパケットベースのマルチメディア呼を受信するように構成された着信側パケットベースマルチメディアロジック（Ｔｅｒｍ ＰＳ）と、
   前記回線交換型制御のユーザ端末へ、着信の回線交換型の呼を送信するように構成された着信側回線交換型ロジック（Ｔｅｒｍ ＣＳ）と、
   前記発信の回線交換型の呼を前記発信のパケットベースのマルチメディア呼に変換し、前記着信のパケットベースのマルチメディア呼を前記着信の回線交換型の呼に変換するように構成された変換機能（Ｃｏｎｖ）と、
   を備えることを特徴とするアクセスゲートウェイノード（ＭＡＧＣＦ）。
2. 前記着信側回線交換型ロジックは、在圏回線交換型ノードが在圏移動回線交換型機能の一部である場合に前記着信の回線交換型の呼を前記回線交換型制御のユーザ端末へ送信するように、構成されることを特徴とする請求項１に記載のアクセスゲートウェイノード（ＭＡＧＣＦ）。
3. 前記回線交換型制御のユーザ端末の前記パケットベースのマルチメディア領域への登録手順を実行するように構成された登録ロジックを備え、
   前記登録手順は、在圏パケットベースマルチメディアノードのアドレスを当該アクセスゲートウェイノードに格納し、当該アクセスゲートウェイノードのアドレスを前記在圏パケットベースマルチメディアノードに提供するという結果をもたらす
   ことを特徴とする請求項１に記載のアクセスゲートウェイノード（ＭＡＧＣＦ）。
4. 当該アクセスゲートウェイノードの前記アドレスの前記提供は、前記プロキシ呼制御機能の提供であることを特徴とする請求項３に記載のアクセスゲートウェイノード（ＭＡＧＣＦ）。
5. 前記受信された発信の回線交換型の呼が前記回線交換型制御領域において処理されることを抑制するように構成された抑制機能を備えることを特徴とする請求項１に記載のアクセスゲートウェイノード（ＭＡＧＣＦ）。
6. 前記受信された着信のパケットベースのマルチメディア呼を着信するように構成された着信機能を備えることを特徴とする請求項１に記載のアクセスゲートウェイノード（ＭＡＧＣＦ）。
7. 回線交換型制御領域（ＣＳ）に位置する回線交換型制御のユーザ端末（ＭＳ）のために呼を処理する方法であって、当該呼はアクセスゲートウェイノード（ＭＡＧＣＦ）が実行する複数のステップによってパケットベースのマルチメディア領域（ＩＭＳ）において処理され、当該複数のステップは、
   呼の発信手順を実行するステップであって、
   前記回線交換型制御のユーザ端末から、発信の回線交換型の呼を受信するステップ（２０，２１）と、
   前記発信の回線交換型の呼を発信のパケットベースのマルチメディア呼に変換するステップ（２２）と、
   統合されたプロキシ呼制御機能を介して前記発信のパケットベースのマルチメディア呼を前記パケットベースのマルチメディア領域へ送信するステップ（２３）と、
   を含むステップと、
   呼の着信手順を実行するステップであって、
   前記パケットベースのマルチメディア領域から、前記統合されたプロキシ呼制御機能へ宛てられた着信のパケットベースのマルチメディア呼を受信するステップ（３０，３１）と、
   前記着信のパケットベースのマルチメディア呼を着信の回線交換型の呼に変換するステップ（３２）と、
   前記回線交換型制御のユーザ端末へ、前記着信の回線交換型の呼を送信するステップ（３３）と、
   を含むステップと、
   を備えることを特徴とする方法。
8. 前記受信された発信の回線交換型の呼が前記回線交換型制御領域において処理されることが、前記アクセスゲートウェイノードにおいて抑制されることを特徴とする請求項７に記載の方法。
9. 前記受信された着信のパケットベースのマルチメディア呼が前記アクセスゲートウェイノードにおいて着信されることを特徴とする請求項７に記載の方法。

Images