JP4758066B2 - 移動式通信網における呼処理 - Google Patents

Description

本発明は、携帯電話ネットワークに関し、特に、そのようなネットワークにおける呼出し、または他の加入者イベントもしくはセッションの処理に関する。

このような呼出し、イベントおよびセッションは、例えば、メッセージ送受信（ＳＭＳ)、汎用パケット無線システム（ＧＰＲＳ）イベント、インターネットおよびイントラネット・セッション、および、マルチメディアサービスの提供などを含む。

以下において、「呼出し(call)」という用語は、このような呼出し、イベントまたはセッションのいずれか、またはすべてについて言及する場合に使用される。呼処理は、ユーザーによる呼出しの開始に応答して、ネットワークにより実行され、またはネットワーク内でサポートされるサービスにより実行される操作である。呼処理は、コールハンドリングおよびサービスハンドリングのいずれかまたは双方を含むと考えられ、前者はネットワーク上での呼出しの実行に関連する操作であり、後者はその呼出しの一部としてのサービス配信に関連する操作である。

移動体通信網は、ある電話（移動式または地上ライン式）から別の電話（移動式または地上ライン式）に対し通信経路を単純に確立した場合よりも、より多くのサービスを提供できる。例えば、ネットワークへの加入者には音声メールのようなサービスが提供され、またネットワークオペレータが、呼出し禁止、呼出し転送、メッセージ送信機能（ＳＭＳ）、ボイスメール、ＷＡＰ、インターネットアクセス、ロケーションに基づくサービスやコンテンツサービスなどといった機能を提供することもできる。更なる課題としては、移動体通信網は一般に、地上ネットワークよりも複雑な課金体系を有し、呼出しのための前払機能があるので、移動体通信網は、使用されている携帯電話が動作が許可されたものであるかを決定できなければならないことを意味する。

これを達成するために、移動体通信網は、一連のコールハンドリングおよび/またはサービスハンドリングのプラットフォームを有し、その各々は、少なくとも一つの特定機能を実行できるようにする。

ある呼出しに関する処理は、複数のプラットフォームに係わり、この呼び出し処理の各パーツは、この複数のプラットフォームの各々で行われ、この呼出しは、その処理において、異なるステージに存在する一つのプラットフォームから他のプラットフォームへと渡される。従って、例えば、前払い加入者が音声メールにアクセスしたい場合、この加入者がこのサービスを使用するに十分な信用限度を有するか否かを査定する操作と、その音声メール自体を供与する動作とを、異なるプラットフォームにおいて実行することが可能である。

ここでプラットフォームとは論理構造である。すなわち、このプラットフォームにより提供される機能を実行するために必要とされるハードウェア／ソフトウェアは、ネットワークの周りに分散させることができる。

現状の装置構成では、各プラットフォームは、相対的に自己内蔵型ユニットとして動作しなければならないものがあり、よって、各ユーザーに関する情報にアクセスしなければならない。このように、周知の装置構成においては、呼処理のプラットフォームは、適切なデータベースを有し、または、適切なデータベースにアクセスできなければならず、さらに起こり得る指示（すなわち、加入者またはネットワークからの処理コマンド）すべてを理解することができなければならない。

以上により、三つの問題点が生じる。第一に、各呼処理のプラットフォームが複雑になる。第二に、異なるプラットフォームが異なるプロトコルに対して作用する場合があるので、例えば、コールハンドリングにおいて、一つのプラットフォームから異なるステージの他のプラットフォームに呼出しが渡されたときに、非互換が生じる可能性がある。第三に、ある携帯電話通信ネットワークへの加入者が、異なるネットワークへ移動（roam:加入区域外移動）する場合、例えば、ある国から別の国へ移動する場合、ホームネットワークにより提供されるサービスは、新たなネットワークによっては提供されない。従って、加入者は移動（roam）したときにこれらの機能を提供してもらうことができない。この第三の問題は、前払い加入者にとっては特に深刻である。つまり、前払い加入者の信用状態は、ホームネットワーク上に格納されているが、移動先のネットワークはその信用状態にアクセスができない。従って現状の装置構成では、前払いユーザーに対しては、他の加入者のように広範囲にわたって移動（roam）することを許可していない。

本発明の第一の態様
本発明は、これらの問題に対処することを目的としており、概して、本発明の第一の態様は、ネットワークが、管理機能または「ブローカー」機能を提供し、呼出しがどのように処理されるべきかを決定するために、呼出し処理の間、その機能がプラットフォーム(コールハンドリングおよびサービスハンドリングプラットフォームのいずれかまたは双方を含む）と対話できるようにすることを提案する。このように、例えば、ユーザーがコールハンドリングのためのプラットフォームで受信される呼出しを開始する場合、そのプラットフォームは、その呼出しに関する情報とその呼出しにより要求される機能をブローカー機能に渡し、ブローカー機能がその呼出しをどのようにハンドリングするかを決定できるようにする。

このブローカー機能は、以下の働きのいずれかまたはすべてを実行することができる。
１．呼出しおよび/または呼出しが必要とするコールハンドリング操作に適用されるサービスを決定する。
２．現在呼出しを処理しているプラットフォームがその呼出しによって必要とされる機能を実行できるかどうか決定する。現在呼出しを処理しているプラットフォームがその呼出しによって必要とされる機能を実行することができない場合、そのプラットフォームから、適切な機能を提供できる、異なるプラットフォームにその呼出しを渡すようにする、または、サービスハンドリングプラットフォームがその呼出しに作用するようにし、サービスハンドリングの一部として、その呼出しにより要求されるサービスを提供するためにどのサービスプラットフォームが必要とされるかを決定する。３．その呼出しを処理するために必要とされたプラットフォームまたは各プラットフォームが要求するデータを照合する。これによって、そのプラットフォームに適切なデータを提供できる。これは、呼出しが二つ以上のプラットフォームにより処理される場合は特に重要である。というのは、同じデータが複数のプラットフォームにより使用されるからである。また、これによって、異なるプロトコルにデータを適合させることも可能になる。４．呼出しを処理するために必要とされるプラットフォームまたは各プラットフォームが正しく動作することを保証するために必要とされるいかなるプロトコル変換も実行する。
５.呼出しを処理するためにステップのシーケンスが必要とされる場合は、これらのステップが正しい順序で行われることを保証する。

実際問題として、少なくとも上記の働き１および２は、いかなる呼出しのためにも必要とされ、ブローカー機能は、上記働き４において、プラットフォームが呼出しを正しく処理できることを少なくとも保証しなければならない。働き３および５は、呼出しよって必要とされるが、常時必須というわけではない。

ブローカー機能が、呼出しを処理するために必要とされるデータを照合することは、各プラットフォームが簡略化されることを意味する。というのは、各プラットフォームがユーザー情報に関する完全なデータベースを備える必要がないからである。その代わり、呼出しをハンドリングする際に、ブローカー機能によって、その情報を提供することが可能である。第二に、このブローカー機能は、呼出しが必要とする処理を決定し、それゆえ、どのプラットフォームがその処理に係わるかを決定するので、相互に非互換のプラットフォーム間で呼出しを手渡すことを可能にするためのプロトコル変換情報を提供することが可能である。第三に、一つのプラットフォームが別のプラットフォームに呼出しを渡すよう起動させることができるので、第一のプラットフォームが呼出しにより要求される機能を実行することができない場合、ローミング中に、ユーザーが移動先ネットワーク内のプラットフォームの呼出し処理を他のプラットフォーム、例えばホームネットワークに渡すことにより、ホームネットワークで利用可能なすべての機能をユーザーに提供することを可能とする。この移動先ネットワークが異なる能力のプラットフォームを有する場合に、ホームネットワークにおいてもこの機能を使用できる。

この操作を実行するために、ブローカー機能は、ネットワークの一つ以上のデータベースに提供される適切なユーザー情報にアクセスすることが可能でなければならず、呼出しのためのハンドリングシーケンスおよび/または要求されるサービスのシーケンスを確立することが可能でなければならない。

上記のように、ブローカー機能は、以下の働きのうちのいくつかまたは全てを実行することが可能である。

識別：
呼出しの処理における第一のステージは、サービスブローカーが、その呼出しおよび/またはその呼出しが要求するコールハンドリング操作に適用されるサービスを識別することである。サービスハンドリングおよびコールハンドリング操作は、主にその呼出しの性質により定められるが、識別を実行するために、サービスブローカーは他のデータベースに対する問合せを送信することが必要であり、および／または内部データを検査する必要がある。

ネゴーシエーション：
呼出しの処理における第二のステージは、サービスブローカーが、プラットフォーム（特にプラットフォームのサービス・スイッチング機能）が、識別された全てのサービスおよびハンドリング操作を実行できるかどうか決定することである。実行することができない場合には、適切な他のプラットフォームに、そのサービスおよび／またはコールハンドリング、または、少なくともそのうちのいくつかを実行させる。

コリレーション（相関）：
前述のように、サービスブローカーは、プラットフォームが必要としたデータを照合する（相関させる）ことができる。この相関（コリレーション）は、呼出しが、このように複数のプラットフォームを必要とする場合、異なるプラットフォームからのデータをマージさせることに係わり、それによって、サービスブローカーは、この呼出しの処理のための単一のデータセットを確立する。

メディエーション(仲介)：
呼出しを処理する際に係わるプラットフォームのプロトコルが異なる場合、サービスブローカーが必要なプロトコル変換を実行することが望ましい。これにより、サービスブローカーは、呼出し処理の間、関連するプロトコルおよびプロシージャが適合していることを保証することができる。

シーケンシング（順序制御）：
呼出しの処理が複数のステップに係わる場合、サービスブローカーは、これらのステップが正しい順序で実行されることを保証する。
複数のサービスが提供される場合は、それらも順序付けされる。

本発明の第二態様
本発明の第二態様は、呼出しがマルチメディアメッセージ（Multi Media Message）である状況に関連する。マルチメディアメッセージは、画像、ビデオ、テキストおよび／または音声もしくは他の音声データ、またはこれらのメディアの組合せを含むものである。以下の議論において、このような呼出しは、ＭＭＳコールと呼ぶ。

ＭＭＳコール専用に設計された装置に対する呼出しまたはその装置からの呼出しを可能にするという意味において、単一のメーカーから、独自開発であるＭＭＳコールの処理のための構成を考案することが可能である。しかし、大規模な携帯電話ネットワークにおいて、ＭＭＳコールは、外部のネットワーク（例えば他のネットワーク）を起点とする場合や、または、異なるメーカーからの発生装置を使用する場合もある。従って、より一般的に適用可能なＭＭＳコールを処理するための構成を開発する必要がある。

その最も一般的なものとして、本発明の第二態様は、その呼出しを表すデータの少なくとも一部を標準プロトコルに変換するプロトコル変換ユニットによって、呼出しを最初に処理することを提案する。結果として生じる信号は、その後、切替装置に送信され、ここでこの信号は、呼出しを処理するためのトリガーとして使用される。この呼出しが、他のネットワークに向けられている場合、この信号は、標準プロトコルからそのネットワークのプロトコルに変換するための別の変換ユニットへ切替装置から送信される。または、そのネットワーク内でのオンワード・ディストリビューション(onward distribution)のために、発信元ネットワークの同じ変換ユニットまたは同等の変換ユニットへと、この切替装置によってその信号を戻すことも可能である。いずれの場合においても、呼出しの処理は、共通のプロトコルにおけるトリガーに応答して対処される。

この本発明の第二態様は、ＭＭＳコールを処理するために開発されたが、この第二態様は、このような呼出しの処理に限られないことに留意すべきである。上記の第二の態様の原理は、例えば電子メール、他のテキストメッセージまたはワールドワイド・ウェブ（ＷＷＷ）信号およびアドレスをハンドリングする、他の種類の呼出しに適用できる。しかし、以下の議論においては用語を簡潔にするため、第二の態様について論じる際には、以下ＭＭＳコールとのみ言及する。

トリガーに応答するために、ＭＭＳコールを一時的に格納する適切な装置が必要とされ、それによってＭＭＳコールを今後どのように処理する必要があるかを決定するために、適切な分析を行うことができる。この分析は、本発明の第一態様によるブローカー機能により行われ、そこにおいて、ブローカー機能は、ＭＭＳコールに対して適切な機能を提供するためにどのプラットフォームが必要とされるかを決定する。

トリガーとして使用される共通のプロトコルにおけるデータを使用することは、メッセージサイズに基づいて課金を行う呼出しの起点を基礎として課金を準備することが可能であることを意味する。ＭＭＳメッセージは、送信される音声および/または画像のようなメディアの複雑さによっては、大量のデータから成り、トリガーの使用によって、ネットワークオペレータは、ＭＭＳコールがネットワークに課す負荷に基づいて課金するようにできる。さらに、これによって前払課金構成との一体化が可能となる。

（図面の簡単な説明）
以下、添付の図面を参照し、本発明の実施例について詳細に例証として説明する。
図１は、移動体通信網のブローカー機能を他の機能にリンクさせるところを示す概略ブロック図である。
図２は、図１のブローカー機能により実行される操作を示すフローチャートである。
図３は、本発明の第一の態様を使用するコールハンドリングの第一の実施例を示す図である。
図４は、本発明の第一の態様を使用するコールハンドリングの第二の実施例を示す図である。
図５は、本発明の第一の態様を使用するコールハンドリングの第三の実施例を示す図である。
図６は、本発明の第一態様の実施例を示す図である。
図７は、本発明の第二態様のさらなる実施例を示す図である。
図８は、図７の実施例における処理を示すフローチャートである。

第一実施例
本発明の第一実施例は、本発明の第一の態様、すなわち、管理または「ブローカー」機能の提供、を具体化する移動体通信網に関する。最初に図１を参照すると、移動体通信網は多数の機能を実行し、これらは複数のプラットフォームの中で分割されると考えることができる。これらのプラットフォームのうちのいくつかは、ネットワークの内部動作と、ネットワークのあるポイントから他のポイントへ通信リンクを確立することに関連し、他の部分は、サービス操作を行うプラットフォームである。

図１は、４つのネットワーク（またはサービスハンドリング）プラットフォームを特定している。すなわち、前払い制御機能（Prepaid Control Function）であるであるＰＣＦ１０、ロケーションレジスタ（サービスロケーションレジスタ：Service Location Register）であるＳＬＲ１２（これは、ＷＯ/ＧＢ９５/０２３５２において記載されるレジスタに対応するものであり、これはネットワークの複数のホームロケーションレジスタ（ＨＬＲｓ）の、対応する一つのレジスタに各電話番号を関連づける情報を含む。図１には図示せず）、ホームロケーションレジスタ制御機能（Home Location Register Control Function）であるＨＣＦ１３、呼出しに対応付けられる他のサービスを実行するための一般的なサービスプラットフォームを示すＳＣＦ１４、である。

ＰＣＦ１０、ＳＬＲ１２およびＨＣＦ１３の各々は、ＳＣＦの具体的な種類であると考えられる。

図１に示されるコールハンドリングプラットフォームは、
呼出しに対して適切な通信ルートを提供するための移動体切替センターであるＭＳＣ２０（実際には、通信網はこのようなＭＳＣ２０を多数有する）、
サービング・ＧＰＲＳサポートノードである、ＳＧＳＮ２１、
ショート・メッセージ・センターであるＳＭＣ２３、
音声メールを受信するための音声処理システムであるＶＰＳ２４、
音声起動ボイスメールおよびパーソナルアシスタントサービスであるＷｉｌｄｆｉｒｅ２５、
サービスコントロール、サービス内容および特定リソース機能を移動させるエンティティ（装置および/または機能）である、サービスノード２６、
携帯電話に配信できるフォーマットのウェブページに対応できるウェブサーバである、ＷＡＰサーバ２７、を含む。

本発明の第一の態様によれば、これらのプラットフォームはすべて、ブローカー機能３０によってリンクされ、ブローカー機能３０は、呼出しとサービスが対処されるべき方法に従って、プラットフォーム１０から１４および２０から２７の動作を制御する。このブローカー機能は、ネットワーク機能１０から１４およびコールハンドリングプラットフォーム２０から２７にリンクし、さらに、データベース３１にリンクする。このデータベース３１は、ＷＯ９９/３５８６７に記載されるような分散型データベースであってもよい。

図２は、図１のブローカー機能３０により実行されるメイン操作を示したものである。ある呼出しが、プラットフォーム１０から１４および／または２０から２７のうちの一つと係わる場合、ブローカー機能３０は、呼出しが受信されたプラットフォームとやりとりするメディエーション操作４０を確立し、その呼出しの性質によって、他のプラットフォームともやりとりする。

ブローカー機能３０がそのメディエーション操作を実行できるように、ブローカー機能３０は、その呼出しによって必要とされるサービスを識別し、サービスハンドリングを可能とするために必要とされるデータを集め、コールハンドリングに必要なデータを集める識別操作４１を実行する。これを実行するために、ブローカー機能３０は、その呼出しおよび/または加入者に関係する、関連データを決定するために、データベース３１にアクセスしてもよい。

オペレーション４１により識別された呼出しによって要求されるサービスの性質により、ブローカー機能３０は、その呼出しを受信したプラットフォームが呼出しに対処できるかどうか、かつ、その呼出しによって、どのサービスが必要とされるかを定めなければならない。したがって、プローカー機能３０は、適切なプラットフォーム２０から２７のサービス・スイッチング機能（ＳＳＦ）の能力を判断するために、ＳＳＦにリンクする能力操作４１を実行する。プラットフォーム２０から２７が、適切な操作を提供することができない場合、ブローカー機能３０は、これらのサービスを実行できる他のプラットフォームに対するリンクを確立し、他のプラットフォームのこれらの機能を完了するよう操作できる。サービス・スイッチング機能（ＳＳＦ）は、ポインツ・イン・コール(ＰＩＣｓ)に達したコールハンドリングプラットフォームから、指示を受け取る機能である。ＳＳＦは、サービス制御機能（ＳＣＦ）からの命令を要求する。このＳＣＦは、サービス・ロジックを実施し、呼出し指示の修正、セルレポートの供給および呼出し時間の測定というような他の操作を続行、拒絶および/または実行するようＳＳＦに指示を与える。ＳＳＦは、そこで予め定義された状態の機器を介して指示を受けて手配を行い、コールハンドリングソフトウェアおよびＳＣＦに、適宜、指示と情報を戻し渡す。ＳＳＦは、サービススイッチングポイント（ＳＳＰ）と呼ばれる物理的モードにおいて司られ、ＳＣＦは、サービスコントロールポイント（ＳＣＰ）と呼ばれる物理的モードにおいて司られる。

このように、呼出しが複数のサービスを必要とする場合、プラットフォーム１０から１４および２０から２７のいずれが適切な操作(コールハンドリング、サービスハンドリング)を提供するにしても、それにより要求される情報を相関させるために、ブローカー機能３０が、コリレーション操作４３を実行しなければならない。このコリレーションは、通常、さまざまなプラットフォームと係わり、ブローカー機能は、データベース３１から、ブローカー機能３０と要求される操作を実行するための適切なプラットフォーム１０から１４および２０から２７によって使用可能な、呼出しのための単一のデータセットを引き出す。このように、ブローカー機能は、一般に、プラットフォーム２０から２７と係わる能力ネゴーシエーションのためのコリレーションと、一般に、プラットフォーム１０から１４と係わる複数のサービス・コリレーションとを実行できる。

このように複数のプラットフォームが係わる場合、ブローカー機能３０は、複数の操作が提供される際の順序、つまり、プラットフォーム１０から１４および２０から２７がこれらの操作を提供すべき順序、を決定するシーケンシング操作４４を実行しなければならない。このシーケンシング操作４４は、複数のプラットフォームが必要でない場合でも、必要とされ、よって、複数のサービスが単一のプラットフォームで提供される場合には、コリレーション操作４３は実行されない。

ここで、図３から図５を参照して、図１で示された機能に関するネットワーク操作の三つの例を説明する。これらの図において、丸で囲まれた数字は、呼出しをハンドリングする際のステージを示す。

第一実施例の例示１
この例では、ある呼出しが複数のサービスを要求すると仮定する。

着信呼は、その呼出しが受信されたプラットフォームのＳＳＰ４０において受信され、それがトリガーとなって、ブローカー機能３０に対する信号が起動され、ブローカー機能３０は、実行されるべき操作を確立するためにデータベース３１にアクセスする。このトリガーは、呼出しに応答して実行される操作を示すデータを含む。図３の実施例において、この操作がＳＣＰ４１、４２へのアクセスを必要とすると仮定する。しかしながら、これらＳＣＰ４１、４２に信号を送る前に、ブローカー機能３０は、コールおよび／またはサービスハンドリングプラットフォームにより実行されるべき全てのサービスのために必要なデータを集めるためにデータベース３１に信号を送る。ブローカー機能３０は、ＳＣＰ４１、４２に順に問い合わせを行ってその各々を起動させ、ブローカー機能により照合される適切な情報を生成し、そのレスポンスはＳＣＰ４０に渡され、呼出しの続行を可能にする。

場合によって、ＳＣＰ４１、４２の各々により実行される動作は独立している。従って、例えば、ＳＣＰ４１、４２のうちの一つは、単に、呼出し番号を他の番号に変換することもあり、このような場合は、ブローカー機能３０は、単にこのような操作を集合体に組み合わせるのみである。しかし、場合によっては、ＳＣＰ４１、４２のうちの1つは、呼出しの全体にわたって係わることを必要とする。
例えば、ＳＣＰのうちの一つが、前払い呼出しに係わるＳＣＦ１４にリンクする場合、ブローカー機能３０は、ＳＳＰ４０のために総計結果を作成する必要がある。

第一実施例の例示２
図４は、最初に呼出しを受信するＳＳＰが、要求される全ての操作を実行することができない例を示す。

このように、ある呼出しが、要求される操作を実行する十分な能力を有しないプラットフォームの第一ＳＣＰ５０で受信される場合、ＳＳＰ５０はブローカー機能３０に信号を送る。例１のように、ブローカー機能３０は、呼出しをハンドリングするために必要なデータをすべて得るためにデータベース３１にアクセスし、その呼出しに対する一時的なコリレーション・アイデンティティを割り当てる。このコリレーション・アイデンティティは、ＳＳＰ５０に戻し渡される。このコリレーション・アイデンティティにより、ＳＳＰ５０は、呼出しにより要求されるオペレータを提供できるプラットフォームの第二ＳＳＰ５１にこの呼出しを渡すことができ、ＳＳＰ５１による呼出しの受信により、ブローカー機能３０に対してトリガーを生成する。このブローカー機能３０は、対応するＳＣＰ５２にアクセスし、ＳＳＰ５１に渡される適切なレスポンス情報を取得し、これによって、呼出しをハンドリングしているプラットフォーム内でこの呼出しを続行させることが可能となる。

このように、ブローカー機能３０は、呼出しに対処するために実行する必要がある操作を基にして、第二ＳＳＰ５０を選択し、その呼出しを処理するためにデータベース３１からデータを識別し、ＳＳＰ５０に渡されるコリレーション・アイデンティティを生成する前に、しかるべきＳＳＰ５１がその呼出しを処理する。

例２においては、呼出しは、ただ一つのＳＣＰ５２にアクセスすることを要求していると仮定する。場合によっては、例１のように、複数のＳＣＰが問い合わせを受ける必要があり、一旦呼出しがＳＳＰ２に渡されれば、このような問い合わせを例１と同様に発生させることは可能である。ただし、そのときまでにブローカー機能３０はすでにデータベース３１にアクセス済みであることにも留意すべきである。

第１実施例の例示３
第三の例は、呼出しのハンドリングが異なるプロトコルに係わる場合に関連する。図５を参照すると、呼出しは、ＳＳＰ６０において受信され、これは必要とされるサービスを示している信号をブローカー機能３０に対して生成する。この例では、ＳＳＰ６０と今後それが作成する信号は、第一プロトコルＡで作動すると仮定する。ネットワークからのトリガーが十分な情報をそれ自体に備えていない場合、ブローカー機能３０は、上記のようにデータベース３１にアクセスし、コールハンドリングのためのデータを取得する。そして、この呼出しに対応するための情報を取得するために、しかるべきＳＣＰ６１に問い合わせを行う。ＳＣＰ６１およびそれが送受信すべき信号が第二プロトコルＢに従って作動する場合、ブローカー機能３０は、図５に示すように異なるプロトコル間で仲介を行う。

ブローカー機能３０は、データベース３１とＳＣＰ６１からの呼出しを処理するためのすべての情報を組合せたならば、ブローカー機能３０は、ＳＳＰ６０に適合するプロトコルＡにおいて、ＳＳＰ６０にレスポンスを渡す。

上記の三つの実施例から分かるように、ブローカー機能３０は、コールハンドリングプラットフォームの一つが呼出しを受信したことを認識するたびに、データベース３１にアクセスし、すべてのタイプの呼出しに対してブローカー機能３０は識別を行い、この呼出しを処理するために必要とされるデータを収集する。それゆえに、コールハンドリングプラットフォームは、最低限のデータを格納するだけで、比較的簡易なものにすることができる。呼出しの処理に特定する必要があるデータであればいかなるデータであっても、ブローカー機能３０から転送することが可能である。このデータはブローカー機能自体がデータベース３１から受信したものである。

第二の実施例
ここで、本発明の第二の実施例を説明する。この第二の実施例は、本発明の第一態様の実施例の一つである。

図６を参照すると、マルチメディアメッセージ（ＭＭＳ）である呼出しは、例えば加入者の携帯電話機１００において生成され、ここから、メッセージ（呼出しのマルチメディアコンテンツ）が、マルチメディアメッセージサービスセンター（ＭＭＳＣ）１１０に送信される。発信側携帯電話機１００は、ＧＰＲＳ１４０およびＷＡＰゲートウェイ１１８を介して、ＭＭＳＣ１１０にＭＭＳコールを送信する。ＭＭＳＣは、ＭＭＳＣコールの一時的な記憶装置として動作し、この目的のために、ＭＭＳＣは、それと関連するメッセージ記憶装置１１２を有してもよい。

ＭＭＳＣ１１０は、それが位置するネットワークで決定されるプロトコルに従って作動する。本実施例において、ＭＭＳＣ１１０は、ミドルウェアインターフェース１３１を介して、サービスブローカーユニット１１４と通信を行う。サービスブローカーユニット１１４は、図１から５を参照して上記で説明された、本発明の第一態様のブローカー機能を実行する。このように、サービスブローカーユニット１１４は、呼出しに必要な処理を決定する。

図６は、ＭＭＳコールが発信側ネットワーク自体の範囲内を送り先としている実施例を例示する。このように、一旦サービスブローカー１１４が呼出しのために必要な処理を決定した場合、この呼出しの処理はＭＭＳＣ１１０に戻される。特に、ＭＭＳＣは、プッシュプロキシゲートウェイ１１５にＷＡＰメッセージを送信することも可能であり、このプッシュプロキシゲートウェイ１１５は、ＳＭＳＣ１１６にＷＡＰメッセージを送信し、またＭＭＳコールのメッセージを表示できる、しかるべき携帯電話機１１７上に送信する。

これは、図６の矢印５および６により図示されている。このプッシュプロキシゲートウェイ１１５は、ＭＭＳＣ１１０から発信される信号をフォーマットし、ＳＭＳＣ１１６を形成するショートメッセージサービス（ＳＭＳ）構造へのオンワードデリバリーのために転送するよう動作し、適切な転送を生じさせることができる。

プッシュプロキシゲートウェイ１１５およびＷＡＰゲートウェイ１１８は、ＷＡＰゲートウェイの使用によって達成できる。というのは、このようなゲートウェイは両方の構成要素のために必要な機能を含むことができるからである。一つはＷＡＰゲートウェイとして動作し、他の一つはプッシュプロキシゲートウェイとして動作する、このような二つのゲートウェイを使用することは、負荷バランス構成において好ましい。しかしながら、各ゲートウェイが両方の機能性を有するので、例えば一つのゲートウェイに障害があった場合などに、もう一つのこのようなＷＡＰゲートウェイを使用して、両方の機能を実行することが可能である。

図１に示したように、サービスブローカーは、ＰＣＴ ＷＯ９９／３５８６７において、より詳細に示されているようなサービスデータ機能（ＳＤＦ）ユニット１２０と、ＷＯ９６／１１５５７において、より詳細に示されているようなレジスタユニット（ＳＬＲユニット）１２１に接続することも可能である。このようにして、ＳＤＦユニット１２０は、ＭＭＳＣ１１０により要求されるＭＭＳ加入者データを格納することも可能である。その機能を実行する際に、サービスブローカーユニット１１４は、ＳＤＦユニット１２０から情報を取得して、どのように呼出しを処理するかを決定する。同様に、サービスブローカー装置１１４は、ＳＬＲユニット１２１から関連する情報を抽出して、発信側および相手先のＭＳＩＳＤＮナンバーを取得してもよい。

ここで、二つの可能性がある。第一は、発信側携帯電話機１００が、ＭＭＳＣ１１０を操作しているネットワークプロバイダーと提携した後払い構成を有する場合である。この場合、しかるべき請求のための構成を準備することができる。しかし、発信側携帯電話機１００が、前払い構成で作動している場合、ＭＭＳコールが送信される前に適切な信用があることを確認しなければならない。このため、サービスブローカーユニット１１０は、前払い制御機能（ＰＣＦ）１２２に対し信号を送る。この信号は、発信者を示し、またＭＭＳコールのメッセージの種類とサイズを示すものである。前払い制御機能１２２は、参照番号１２３で概略的に示されるネットワークの請求オペレーションに対し適切な信号を送り出す。それらの請求オペレーションは、レーティングおよび請求機能１２５、１２６を実行可能とする信号を生成する、ネットワークメディエーションシステム（ＮＭＳ）ユニット１２４を含む。図６はまた、ＮＭＳユニット１２４が、ＭＭＳＣ１１０自体からトリガー信号を受信するところを示す。

ＭＭＳＣ１１０は、加入者データベースインターフェースユニット（図６では図示せず）を含み、これは、ＭＭＳＣ１１０により生成される問い合わせを、ミドルウェアインターフェース１３１を介して、サービスブローカーユニット１１４に渡すものである。このようにして、サービスブローカーユニット１１４は、ＭＭＳＣ１１０による呼出しの次の処理を制御できる。

ここで、図６において、ＭＭＳコールが携帯電話機１００により生成されたが、相手先の端末である携帯電話機１１７がマルチメディア機能に対応していない場合を想定する。この場合、ＭＭＳＣ１１０は、レガシーハンドセットゲートウェイ１４１に呼出しを送り、そこでＭＭＳコールを格納する。さらに、ＭＭＳＣ１１０は、ＳＭＳ形式のメッセージをＳＭＳＣ１１６に対して生成し、ここでこのメッセージは、携帯電話１１７に送られ、マルチメディアメッセージが格納されていることを携帯電話１１７のユーザーに知らせる。従って、携帯電話１１７に対する信号は、標準メッセージであってもよい。例えば携帯電話１１７のユーザーは、レガシーハンドセットゲートウェイ１４１に接続するために、インターネット１１５を介して適切なコンピュータ１４４を使用し、マルチメディアメッセージを取り出せるようにしてもよい。レガシーハンドセットゲートウェイ１４１は、適切なアクセスを提供するためのウェブサーバを含んでもよい。さらに、マルチメディアメッセージは、電子メールアドレスに送信されることも可能である。これは、ＭＭＳＣ１１０から呼出しを受信してそれを電子メールに変換する、メールトランスファーエージェント１４６により実行される。この電子メールは、インターネット１４５を介して適合するコンピュータ１４４、１４７に送信される。

本実施例については多くの変更が可能である。例えば、図６では、発信側携帯電話１００および相手先携帯電話１１７が同じネットワークの利用者であり、双方ともそのホームネットワーク内にいると仮定している。しかしながら、それぞれ異なるネットワークの利用者である場合もあり、そのような場合は、発信側ネットワークのＭＭＳＣ１１０から相手先ネットワークにある同等のＭＭＳＣへと呼出しを転送する必要がある。このような場合、サービスブローカー１１４の動作がとりわけ重要である。

特に、サービスブローカー１１４は、メッセージが正しいネットワークに到達することを保証するために、どのネットワークが相手先携帯電話１１７のナンバーを所有するかについて決定し、よってＭＭＳをどこへ送信するか、どのようにしてメッセージのアドレスを適切に変更するかを決定しなければならない。

相手先ナンバーを所有しているネットワークが、ＭＭＳＣ１１０のオペレータと相互接続契約をしていない可能性もあり、そのような場合、サービスブローカー１１４は、レガシーハンドセットゲートウェイ１４１にメッセージを送信することにしてもよい。

サービスブローカーはまた、ＭＭＳを送り出すときに、どのネットワークに発信側携帯電話が位置しているかを識別する。これは、料金設定（tarrifing）を適宜変更するために使用できる。

相手先携帯電話機１１７がそのホームネットワークから移動しているとき、ＭＭＳＣは、その相手先携帯電話機１１７にメッセージ（例えばＳＭＳメッセージ）を送信し、ホームネットワークからＭＭＳメッセージを拾うために、ホームネットワークのＭＭＳＣ１１０とコンタクトするようユーザーに告げる。

発信側携帯電話機１００がそのホームネットワークから移動しているとき、ＭＭＳメッセージはホームネットワークのＭＭＳＣ１１０に送られる。そして、ＭＭＳＣ１１０は図６を参照して説明された方法でＭＭＳメッセージを処理する。このような操作は、ＭＭＳメッセージを送受信できる適切なネットワーク能力をサポートしている、訪れた（移動先の）ネットワークに依存する。

一つのネットワークから他のネットワークまで送信されるいかなるマルチメディアメッセージも、単一の受信者に向けられると仮定するならば、配信アドレスはそのメッセージが送信される前に決定されている必要があり、それによって、メッセージが直接、正しいネットワークに送られるようになっている。相手先携帯電話機が位置するネットワークは、このメッセージが、発信側ネットワーク内の有効な発信側携帯電話機から受信されたものであるという何らかの肯定的な確認を必要とする。これは、不正行為のリスクまたは他の問題を除去するために必要とされるものである。ＭＭＳコールが正常に受信され適切な受入チェックを通過した後、相手先ネットワークのオペレータが、しかるべき課金情報を生成することが必要となる。これらの受入チェックには、例えば、相手先ネットワークのオペレータまたは相手先携帯電話の利用者のいずれかに適用された、コンテンツタイプおよびサイズ基準、メッセージサイズ、スパン・プロテクションおよびブロッキングルールに準拠しているか、を確認することを含むことができる。

ＭＭＳコールをハンドリングするために論じられた構成部品のいくつかについて、その詳細なアーキテクチャは、当業者にとって周知の３ＧＰＰ（第三世代パートナーシップ・プロダクト）の仕様書、特に仕様書２３．１４０に記載されている。

第三の実施例
以下、図７を参照して、本発明の第三実施例について説明する。
この第三の実施例は、本発明の第一および第二の態様の双方についての実施例である。この実施例の多くの特徴は、図６の第２の実施例と同様であり、対応する部分を示すために同じ参照番号が使用される。

本発明の第二態様において、呼出しは、所定の共通プロトコルに変換され、その共通プロトコルにおいて、イベント・トリガーが生成され、このイベント・トリガーは、この呼処理を開始するために使用される。これを達成するために、ＭＳＣコールは、シンプルメールトランスファープロトコル（ＳＭＴＰ）というような標準プロトコルに変換され、ＳＭＴＰプロキシエージェント１１３に渡される。そのＳＭＴＰプロキシエージェント１１３は、呼出しの処理を起動する。

本実施例において、ＳＭＴＰプロキシエージェント１１３は、図１から５および図６を参照して上記で論じられた本発明の第一態様のブローカー機能を実行するサービスブローカー１１４と接続される。サービスブローカー１１４は、ＳＭＴＰプロキシエージェント１１３からのトリガーを基礎として、全体に必要な処理を決定する。ＳＭＴＰプロキシエージェント１１３は、周知の所有権が主張されないプロトコルにおいて作動しているので、ＭＭＳＣ１１０のプロトコルから独立しているこのようなトリガーを生成するように設計することは比較的単純である。

ＳＭＴＰプロキシエージェント１１３は、メッセージ内のデータから、メッセージのサイズを識別する情報を引き出し、また、メッセージ内のデータから、メッセージ内に含まれるクラス、タイプまたはメディアを識別する情報を引き出す。その後、適切な信号がサービスブローカー装置１１４に送信される。さらに、ＳＭＴＰプロキシエージェント１１３は、ＭＭ４インターフェースを介してＭＭＳＣ１１０に対してレスポンスを送信し、サービスブローカーユニット１１４により指示されたように発信側アドレスと受信側アドレスを変換する（メッセージは同じＭＭＳＣ１１０に送り戻され（ループバック）、または同じネットワーク内の別のＭＭＳＣ、もしくは異なるネットワーク内の別のＭＭＳＣに送り戻される）。

このように、上記の実施例において、ＳＭＴＰプロキシエージェント１１３において、イベント・トリガーは、例えばＳＭＴＰというプロトコルで作られる。このプロトコルは、ＭＭＳコールが元々生成され、ＭＭＳＣ１１０により受信されたときのプロトコルと同じものではない。

ＳＭＴＰプロキシエージェント１１３は、このトリガーを作成するために、一時的にＭＭＳメッセージを格納するように構成される標準的な電子メールサーバであってもよい。これらのトリガーは、呼出しの発信元と送信先、メッセージタイプ、メッセージサイズなどの関連する情報を含むライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）の拡張リクエストの形式であってもよい。この情報は、サービスブローカー１１４に渡され、サービスブローカー１１４は、呼出しがどのように処理されるべきかを決定する。

図７において、インターフェース１３１は、加入者データベースユニット１３０を介してＭＭＳＣ１１０に接続される。加入者データベースユニット１３０は、図６を参照して言及したように、ＭＭＳＣ１１０により作成された問い合わせを、インターフェース１３１を介してサービスブローカーユニット１１４に渡す。

図７はまた、ＭＭＳコールが、ＭＭＳＣ１１０のネットワークとは異なるネットワーク上の送信先に送られる状況を示している。その場合、ＳＭＴＰプロキシエージェント１１３は、ＳＭＴＰ形式の呼出しを異なるオペレータのＭＭＳＣ１５０に転送し、ここで、この呼出しは、上記に説明した方法と全く同じように処理される。このように、ＭＭＳコールは、ＭＭＳＣ１１０に到着する呼出しのプロトコルまたはＭＭＳＣ１５０から送信される呼出しのプロトコルのいずれかとは異なるプロトコルで、ＳＭＴＰプロキシエージェント１１３を介して、ＭＭＳＣ１１０からＭＭＳＣ１５０へと渡される。このように、共通のプロトコルにおいて操作することによって、ＳＭＴＰプロキシエージェント１１３により作成されるイベント・トリガーが、異なるネットワーク内で操作されるプロトコルにかかわりなく確実に生成される。ＭＭＳＣ１５０がＭＭＳＣ１１０と同じオペレータにより操作されることが可能である。ここでこのオペレータは複数のＭＭＳＣを有する。

以下、図８を参照して、図７の実施例における信号の流れについて説明する。図８において、番号１〜９は信号を送る際のステージを示す。ただし、ステップ７ａ、７ｂ、７ｃにおいては選択肢がある。このように、信号は、携帯電話機１００におけるソフトウェアであるＭＭＳクライアント２００を発信元とし、ゲートウェイ２０１を介して、ＭＭＳＣ２０２に渡される。ＭＭＳＣ２０２は、トランスファーエージェント１１３に対応するトランスファーエージェント２０３に信号を渡し、このトランスファーエージェント２０３は、ステップ４においてサービスブローカー２０４に問い合わせを行う。サービスブローカー２０４自体は、図７におけるＳＬＲユニット１２１に対応するＳＬＲ２０５、または前払い制御機能１２２に対応するＰＣＦ２０６に問い合わせを行うことも可能である。サービスブローカーが、この呼出しを送信できないと決定した場合、障害メッセージ７ｃを、発信側２００に対して発信してもよい。あるいは、サービスブローカー２０４が、この呼出しはハンドリング可能であると決定した場合、信号は、トランスファーエージェント２０３に渡され、トランスファーエージェント２０３は、ステップ７ａにより、ＭＭＳＣ２０２と同じネットワークのＭＭＳＣ２０７（実際にはこれらは同じＭＭＳＣである可能性もある）、またはステップ７ｂにより、別のネットワークのＭＭＳＣ２０８に呼出しを渡す。その後、ＭＭＳＣ２０７は、ステップ８により、ＭＭＳＣ２０９を介して、対応するＳＭＳＣ１１６に呼出しを渡し、ステップ９において、送信先２１０に呼出しを渡す。

（図１）図１は、移動体通信網のブローカー機能を他の機能にリンクさせるところを示す概略ブロック図である。

（図２）図２は、図１のブローカー機能により実行される操作を示すフローチャートである。

（図３）図３は、本発明の第一の態様を使用するコールハンドリングの第一の実施例を示す図である。

（図４）図４は、本発明の第一の態様を使用するコールハンドリングの第二の実施例を示す図である。

（図５）図５は、本発明の第一の態様を使用するコールハンドリングの第三の実施例を示す図である。

（図６）図６は、本発明の第一態様の実施例を示す図である。

（図７）図７は、本発明の第二態様のさらなる実施例を示す図である。

（図８）図８は、図７の実施例における処理を示すフローチャートである。

Claims (4)

1. 携帯電話ネットワークを動作させる方法であって、
   前記ネットワークには、
   当該ネットワークの少なくとも一つの携帯電話に対するまたはそのために作成される、呼出し、イベントまたはセッションを処理するためのプラットフォームと、
   前記処理を決定するために前記プラットフォームとやりとりを行う機能と
   が設けられ、
   それぞれの前記呼出し、イベントまたはセッションを処理するためには、複数のサービスおよび／またはコールハンドリング操作が必要であり、
   前記サービスハンドリング操作は、呼出しの一部としてのサービス配信に関連する操作であり、
   前記コールハンドリング操作は、ネットワーク上での呼出しの実行に関連する操作であり、
   前記プラットフォームは、複数のサービスおよび／またはコールハンドリング操作を実行することができ、
   前記機能は、
   ａ）前記呼出し、イベントまたはセッションに適用されるサービスおよび／またはコールハンドリング操作を決定するステップと、
   ｂ）前記プラットフォームが、前記呼出し、イベント、セッションにより要求される前記サービスおよび／またはコールハンドリング操作を行うことができるか否かを判断するステップと、
   ｃ）前記プラットフォームが、前記呼出し、イベントまたはセッションにより要求される前記サービスおよび／またはコールハンドリング操作の少なくともいくつかを実行できる場合に、前記サービスおよび／またはコールハンドリング操作の少なくともいくつかを実行するために要求されるデータを決定するとともに、前記プラットフォームが前記呼出し、イベントまたはセッションを処理できるよう前記サービスおよび／またはコールハンドリング操作の少なくともいくつかの処理ステップのシーケンスを決定するステップと、
   ｄ）前記決定したデータを収集するステップと、
   ｅ）前記プラットフォームに、前記収集したデータを使用させて、前記サービスおよび／またはコールハンドリング操作を前記シーケンスの順序に従って実行させることにより、前記呼出し、イベントまたはセッションを処理させるステップと
   を実行することを特徴とする携帯電話ネットワークを動作させる方法。
2. 請求項１に記載の携帯電話ネットワークを動作させる方法であって、
   前記機能はさらに、
   ｆ）前記呼出し、イベント、セッション、または、プラットフォームのプロトコルを、当該プロトコルが前記プラットフォームにより処理可能なように変換するステップ
   を実行することを特徴とする携帯電話ネットワークを動作させる方法。
3. 請求項１または２に記載の携帯電話ネットワークを動作させる方法であって、
   前記呼出し、イベントまたはセッションは、マルチメディアメッセージであることを特徴とする携帯電話ネットワークを動作させる方法。
4. 携帯電話のネットワークであって、
   当該ネットワークの少なくとも一つの携帯電話に対するまたはそのために作成される、呼出し、イベントまたはセッションを処理するためのプラットフォームと、
   前記処理を決定するために前記プラットフォームとやりとりを行う機能と
   を有し、
   それぞれの前記呼出し、イベントまたはセッションを処理するためには、複数のサービスおよび／またはコールハンドリング操作が必要であり、
   前記サービスハンドリング操作は、呼出しの一部としてのサービス配信に関連する操作であり、
   前記コールハンドリング操作は、ネットワーク上での呼出しの実行に関連する操作であり、
   前記プラットフォームは、複数のサービスおよび／またはコールハンドリング操作を実行することができ、
   前記機能は、
   ａ）前記呼出し、イベントまたはセッションに適用されるサービスおよび／またはコールハンドリング操作を決定するステップと、
   ｂ）前記プラットフォームが、前記呼出し、イベントまたはセッションにより要求される前記サービスおよび／またはコールハンドリング操作を行うことができるか否かを判断するステップと、
   ｃ）前記プラットフォームが、前記呼出し、イベントまたはセッションにより要求される前記サービスおよび／またはコールハンドリング操作の少なくともいくつかを実行できる場合に、前記サービスおよび／またはコールハンドリング操作の少なくともいくつかを実行するために要求されるデータを決定するとともに、前記プラットフォームが前記呼出し、イベントまたはセッションを処理できるよう前記サービスおよび／またはコールハンドリング操作の少なくともいくつかの処理ステップのシーケンスを決定するステップと、
   ｄ）前記決定したデータを収集するステップと、
   ｅ）前記プラットフォームに、前記収集したデータを使用させて、前記サービスおよび／またはコールハンドリング操作を前記シーケンスの順序に従って実行させることにより、前記呼出し、イベントまたはセッションを処理させるステップと
   を実行することを特徴とする携帯電話のネットワーク。

Images