JP5779259B2 - 構成可能なダイアメータアドレス解決のための方法、システムおよびコンピュータ読取可能媒体 - Google Patents

Description

優先権主張
この出願は、２０１１年３月１８日に提出された米国仮特許出願連続番号第６１／４５４，４６２号の恩恵を主張し、その開示全体をここに引用により援用する。

技術分野
ここに記載される主題は、ダイアメータメッセージをルーティングすることに関し、より特定的には、構成可能なダイアメータアドレス解決のための方法、システムおよびコンピュータ読取可能媒体に関する。

背景
ダイアメータネットワークにおいては、ネットワークオペレータにとっては、特定の加入者または加入者グループのためのダイアメータシグナリングメッセージを、それら加入者または加入者のグループに割り当てられたノードに向けることが、望ましいかもしれない。例えば、ネットワークオペレータは、１つより多いホーム加入者サーバ（ＨＳＳ）、ポリシーおよび課金ルール機能（ＰＣＲＦ）、またはオンライン課金方式（ＯＣＳ）を有してもよい。ネットワークオペレータは、特定の加入者または加入者グループに関係するメッセージが特定のノードに向けられるように、１つ以上のモビリティ管理エンティティ（ＭＭＥ）、サービングＧＰＲＳサポートノード（ＳＧＳＮ）、またはＨＳＳ、ＰＣＲＦもしくはＯＣＳへの他のノードからの末端間ルーティングを規定することを所望するかもしれない。メッセージのための最終宛先ホストまたは領域を指定することをメッセージ発信側に要求する従来のダイアメータルーティングは、スケーラブルではないかもしれない。加えて、異なるダイアメータシグナリングメッセージが、加入者または加入者装置を識別し、ダイアメータシグナリングメッセージの異なる属性値ペアに位置する、異なるパラメータを含むかもしれない。ルーティングまたはルーティングアドレス解決のためにこれらのパラメータのいくつか用いることは、望ましいかもしれない。したがって、構成可能なダイアメータアドレス解決に対するニーズが存在する。

概要
構成可能なダイアメータアドレス解決のための方法、システムおよびコンピュータ読取可能媒体が開示される。１つの方法は、ダイアメータシグナリングルータ（ＤＳＲ）で、ネットワークにおいてダイアメータシグナリングエンティティとのダイアメータシグナリングメッセージの送受信を行なうことを含む。この方法は、さらに、複数個のルーティングエンティティ識別情報の構成、およびダイアメータアドレス解決においてルーティングエンティティ識別情報を優先的に用いるための順序の構成を設けることを含む。この方法は、さらに、ダイアメータルーティングアドレス解決において判断されるダイアメータアドレス情報を用いてダイアメータシグナリングメッセージをルーティングすることを含む。

ここに用いられるとおりでは、用語「ルーティングエンティティ識別情報」は、宛先ホスト、宛先領域またはその両方のような、ダイアメータアドレス情報に分解することができる、加入者、加入者装置または他のエンティティを識別するダイアメータシグナリングメッセージにおける識別子を指す。

ここに記載される主題は、コンピュータのプロセッサによって実行されると、コンピュータを制御してステップを実行させる実行可能な命令を記憶する非一時的なコンピュータ読取可能媒体を用いて実現されてもよい。１つの実現例においては、ここに記載される主題は、コンピュータ読取可能媒体において実施され、プロセッサによって実行可能であるソフトウェアにおいて実現されてもよい。ここに記載される主題で好適に用いられる例示的なコンピュータ読取可能媒体は、ディスクメモリ装置、チップメモリ装置、プログラマブル論理装置、および特定用途向け集積回路を含む。加えて、ここに記載される主題を実現するコンピュータ読取可能媒体は、単一の装置もしくはコンピューティングプラットフォームに位置してもよいし、または複数の装置もしくはコンピューティングプラットフォームにわたって分散してもよい。

図面の簡単な説明
ここに記載される主題の好ましい実施例を、ここで、添付の図面を参照して説明する。

ここに記載される主題の実施例に従ってダイアメータアドレス解決を実行することができるＤＳＲを示すネットワーク図である。 ここに記載される主題の実施例に従って異なるダイアメータノードタイプとして同時に現われるＤＳＲを示すネットワーク図である。 ここに記載される主題の実施例に従ってダイアメータアドレス解決のために用いられるテーブルの階層を示すブロック図である。 ここに記載される主題の実施例に従ってダイアメータアドレス解決を実行するように構成されたＤＳＲのための例示的な内部のアーキテクチャを示すブロック図である。 ここに記載される主題の実施例に従って個別のアドレス解決オーバーライドでダイアメータアドレス解決を実行することができるＤＳＲの階層を示すネットワーク図である。 ここに記載される主題の実施例に従ってダイアメータアドレス解決とともに構成された複数のＤＳＲによる同一のアドレス解決の防止を示すネットワーク図である。 ここに記載される主題の実施例に従う構成可能なダイアメータアドレス解決のための例示的なプロセスのフローチャートである。

詳細な記載
ここに記載される主題は、構成可能なダイアメータアドレス解決のための方法、システムおよびコンピュータ読取可能媒体を含む。１つの例示的な実現例においては、ダイアメータアドレス解決はＤＳＲにおいてプロビジョニングされてもよい。図１は、ここに記載される主題の実施例に従ってダイアメータアドレス解決を伴うダイアメータシグナリングルータを示すネットワーク図である。図１を参照して、ＤＳＲ１００は、ダイアメータメッセージをさまざまなネットワークノードとの間で送受信するためのネットワークインターフェイス１０２と、メッセージにおけるパラメータに基づいてダイアメータアドレスを解決するためのダイアメータアドレス解決モジュール１０４と、ルーティングモジュール（ＲＭ）１０５とを含む。

ここに記載される主題の局面によれば、ダイアメータアドレス解決モジュール１０４は、受け取られたダイアメータシグナリングメッセージを検索するように用いられ、見つけられた場合にはダイアメータアドレス解決において用いられる、ルーティングエンティティ識別情報の構成を設けてもよい。例えば、ダイアメータアドレス解決モジュール１０４は、ＤＳＲ１００に局在する端末を介して、および／または、ルーティングエンティティ識別子、メッセージコマンドコード、ルーティングエンティティ識別情報識別子間の選好、ルーティングエンティティ識別子を探索するための属性値ペア、ルーティング例外規則、およびダイアメータアドレス解決に関連付けられる他のパラメータをデータ構造に設定することを製造業者またはネットワークオペレータのようなユーザに可能にさせるネットワークを介して、アクセス可能な構成インターフェイスを含んでもよい。ユーザによって設定されてもよい例示的なデータ構造は以下に詳細に記載される。

図１に示されるネットワークにおいては、ＤＳＲ１００は、１つ以上のＭＭＥノード１０６、１つ以上の通話セッション制御機能（ＣＳＣＦ）ノード１０８、１つ以上のＳＧＳＮ１１０、１つ以上のＨＳＳ１１２、１つ以上のＰＣＲＦノード１１４、および１つ以上のオンラインまたはオフライン課金方式（ＯＣＳまたはＯＦＣＳ）ノード１１６に接続される。ネットワークオペレータが加入者レコードをそのようなノードの間で柔軟にプロビジョニングすることができるようにするために、構成可能なアドレス解決が必要であってもよい。１つの実現例においては、ダイアメータアドレス解決モジュール１０４は、受け取られたダイアメータシグナリングメッセージに適用されるべきアドレス解決規則の好ましい階層の構成を設ける。例えば、国際移動局識別子（ＩＭＳＩ）、移動体加入者ＩＳＤＮ番号（ＭＳＩＳＤＮ）およびＩＰマルチメディアパブリック識別情報（ＩＭＰＵ）のようなダイアメータユーザ識別情報は、受け取られたメッセージを検索して好ましいユーザ識別情報がいつ存在するかを判断するように、選好順序を割り当てられ得る。その識別情報が存在する場合には、ダイアメータアドレス解決モジュール１０４はその識別情報をアドレス解決探索において用いてもよい。その識別情報が存在しない場合には、ダイアメータアドレス解決モジュール１０４は、次の最も好まれる識別情報を用いてアドレス解決探索を実行してもよい。１つの例示的な実現例においては、ダイアメータアドレス解決は、ネットワークオペレータ構成を介して任意のダイアメータノードへのダイアメータアプリケーションメッセージのユーザ識別情報ルーティングをサポートするように、ダイアメータアプリケーションから独立していてもよい。例えば、特定のユーザ識別情報を有するダイアメータシグナリングメッセージは、そのメッセージにおけるダイアメータアプリケーション識別情報から独立して、そのユーザ識別情報のためにプロビジョニングされるダイアメータノードにルーティングされてもよい。

ダイアメータアドレス解決をサポートするＤＳＲは、同じＤＳＲ上においてダイアメータプロキシエージェントおよびダイアメータリダイレクトエージェントの役割を同時にサポートしてもよい。図２はこの能力を示す。図２においては、ＤＳＲ１００は、アプリケーションＩＤまたはインターフェイスに依って、ダイアメータプロキシエージェントの役割およびダイアメータリダイレクトエージェントの役割を同時にサポートする。例えば、Ｓ６ａインターフェイスに対しては、ＤＳＲ１００はダイアメータプロキシエージェントとして機能する。Ｓ６ａインターフェイスはＭＭＥとＨＳＳとの間のインターフェイスである。したがって、ＭＭＥ１０６とＨＳＳ１１２との間のダイアメータシグナリングメッセージに対しては、ＤＳＲ１００はプロキシエージェントとして機能してもよい。同様に、Ｃｘインターフェイスにおいては、ＤＳＲ１００はリダイレクトエージェントとして機能してもよい。ＣｘインターフェイスはＣＳＣＦとＨＳＳとの間のインターフェイスである。したがって、ＣＳＣＦ１０８とＨＳＳ１１２との間のメッセージに対しては、ＤＳＲ１００はリダイレクトエージェントとして機能してもよい。残りのインターフェイスは、テーブル２００において具体的に示され、ＤＳＲ１００実現される。

ＤＳＲ１００によって実現され得るダイアメータアドレス解決は、好ましくはメッセージパラメータを宛先アドレスに分解する。ネットワークオペレータは、各宛先アドレス毎に以下のパラメータの少なくとも１つを構成することができてもよい：
■宛先アドレス名
■プロキシエージェントアドレス指定に対しては：
●領域
●ホスト（完全修飾ドメイン名（ＦＱＤＮ）
■リダイレクトされたアドレス指定に対しては：
●ダイアメータＵＲＩ
●注：リダイレクトエージェントは、宛先アドレスのＦＱＤＮおよび他の任意パラメータを含むダイアメータＵＲＩで応答する。

■後のアドレス解決を可能にする：
●後のアドレス解決、つまり異なるＤＳＲによる同じダイアメータシグナリングメッセージに対する複数のアドレス解決は、ネットワークオペレータの選好に依って、許可されてもされなくてもよい。例えば、アドレス解決階層が実現されつつある場合には、後のアドレス解決を可能にすることが望ましいかもしれない。しかしながら、各ＤＳＲが少なくともいくつかの重複するアドレス解決データベースエントリとともに構成される場合には、同じメッセージに対する同じダイアメータアドレス解決の複数の呼出しを防ぐために、ステップが取られてもよい。例示的なステップを以下に詳細に記載する。

■アドレス解決は以下のメッセージ内容に基づいてもよい：
●アプリケーションＩＤ
●コマンドコード
●ユーザ識別情報
ＤＳＲ１００は、異なるタイプのノードからアドレス解決に対するさまざまな異なるタイプのユーザ識別情報を得てもよい。以下のタイプのユーザ識別情報は対応するノードから得られてもよい：
■以下のレファレンスの各々の使用によるＨＳＳからの特定のＭＳに関係がある加入者データ：ＩＭＳＩ、ＭＳＩＳＤＮ
■ＨＳＳからの特定のＩＭＳ加入を含む加入者ＩＰマルチメディアサービスデータ：プライベートユーザ識別情報、パブリックユーザ識別情報
■ＨＳＳからのＰＳＩ ＩＰマルチメディアサービスデータ：パブリックサービス識別情報
■ＶＬＲからの特定のＭＳに関する加入者データ：ＩＭＳＩ、Ｐ−ＴＭＳＩ
■ＳＧＳＮからの特定のＭＳに関する加入者データ：ＩＭＳＩ、Ｐ−ＴＭＳＩ、ＩＭＥＩ
■ＧＧＳＮからの特定のＭＳに関する加入者データ：ＩＭＳＩ、ＩＭＥＩ
■ＭＭＥからの特定のＭＳに関する加入者データ：ＩＭＳＩ
３ＧＰＰ ＴＳ ２３．００８は、ユーザまたは加入者に関連付けられ得る異なるタイプの識別情報を定義する。異なるタイプの識別情報は異なるドメインにおいて用いられてもよい。用いられてもよい回路交換およびパケット交換ドメインユーザ識別情報は、以下を含む：
■３ＧＧＰ ＴＳ ２３．００３定義されるＩＭＳＩ。ＩＭＳＩは永久的な加入者データである。ＩＭＳＩは、ＨＬＲ、ＨＳＳ、ＶＬＲ、ＳＧＳＮ、Ｓ４−ＳＧＳＮ、ＧＧＳＮ、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ、およびＳＭＬＣにおいて記憶されてもよい。

■ＭＳＩＳＤＮ。ＭＳＩＳＤＮは、ＨＬＲ、ＶＬＲおよびＧＮ／ＧＰ−ＳＧＳＮにおいて記憶される永久的な加入者データである。

ダイアメータアドレス解決を実行するのにＤＳＲ１００によって用いられてもよい他のタイプのユーザ識別情報は、３ＧＰＰ ＴＳ ２３．００８セクション３において明記されるようなＩＰマルチメディアドメインユーザ識別情報である。ＩＭＳユーザ識別情報の例は以下のとおりである：
■プライベートユーザ識別情報
●ＩＭＳ加入者にのみ適用可能
●ＲＦＣ ４２８２において定義されるように、「ユーザ名＠領域」という形式において、３ＧＰＰ ＴＳ ２３．００２において定義されるように、ネットワークアクセス識別子（ＮＡＩ）の形式をとる
●注：３ＧＰＰ ＴＳ ２３．００８セクション３．１において定義されるように、プライベートユーザ識別情報は、認証データがＩＭドメインから来る場合には、ＩＭＰＩ（ＩＰマルチメディアプライベート識別情報）になり得るか、または認証データがＣＳ／ＰＳドメインから来る場合には、それはＩＭＳＩから導出され得る
●ＨＳＳおよびＳ−ＣＳＣＦに記憶される永久的な加入者データ
■パブリックユーザ識別情報
●ＩＭＳ加入者はパブリックユーザ識別情報またはワイルドカード付きのパブリックユーザ識別情報の１つまたはいくつかのインスタンスを有することができる
●３ＧＰＰ ＴＳ ２３．００２において定義されるように、ＳＩＰまたはＴＥＬ ＵＲＩの形式をとる
●ＨＳＳ、Ｓ−ＣＳＣＦおよびＢＳＦに記憶される永久的な加入者データ
●仮定：これは常にＩＭＰＵ（ＩＰマルチメディアパブリック識別情報）を指す
■プライベートサービス識別情報
●ＰＳＩユーザに適用可能
●ＮＡＩの形式のプライベートユーザ識別情報と同様
●ＨＳＳおよびＳ−ＣＳＣＦに記憶される永久的なデータ
■パブリックサービス識別情報（ＰＳＩ）
●サービス、またはアプリケーションサービスにおいてサービスに対して作成される特定の資源を識別する
●ＨＳＳにおいて記憶される別個のＰＳＩまたはワイルドカード付きのＰＳＩのいずれかに一致してもよい
●３ＧＰＰ ＴＳ ２３．００２において定義されるように、ＳＩＰまたはＴＥＬ ＵＲＩの形式をとる
●ＨＳＳまたはＳ−ＣＳＣＦに記憶される永久的なデータ
以下に示される表１は、ダイアメータアドレス解決を実行する際にＤＳＲ１００によって用いられ得るユーザ識別情報の例を示す。

表１においては、以下のキャプションがあてはまる：
＊ 複数インスタンスがあり得る
＊＊ ＲＦＣ４００６で定義されるダイアメータクレジット管理アプリケーション（ＤＣＣＡ）
＊＊＊ ＲＦＣ３５８８で定義されるダイアメータベースアカウンティングアプリケーション
＊＊＊＊ Ｒｏに含まれるＧｙ機能性
（Ｍ）必須情報要素（ＩＥ）
（Ｃ）条件付きＩＥ
（Ｏ）任意ＩＥ
ここに記載される主題の局面によれば、ＤＳＲ１００、および具体的には、ダイアメータアドレス解決モジュール１０４は、メッセージが特定のルーティングエンティティ識別情報に関して検索され、ルーティング規則がルーティングエンティティ識別情報間の選好に従って適用されるルーティングエンティティ識別情報選好リストを実施してもよい。表１に示されるように、ダイアメータメッセージは１つ以上のルーティングエンティティ識別情報を有してもよい。ユーザ識別情報は条件付きおよび任意であってもよく、それは、メッセージは、時にはＩＭＳＩのみを、時にはＩＭＰＵのみを、時にはＭＳＩＳＤＮのみを、および時にはこれらのパラメータの組み合わせを有することを意味する。ダイアメータアドレス解決モジュール１０４は、包括的なフレームワークを提供して、オペレータが、ユーザ構成を介して、各メッセージにおけるどのルーティングエンティティ識別情報タイプをアドレス解決のために使用するかを判断することを可能にしてもよい。ルーティングエンティティ識別情報選好は、ＤＳＲ１００において実現されたルーティングエンティティ識別情報選好リストによってサポートされてもよく、それはネットワークオペレータによって構成可能である。ルーティングエンティティ識別情報選好リストは、各アプリケーションＩＤ、コマンドコード順序付けされたペア毎にネットワークオペレータの選好に従って順序付けられた複数の識別情報を含んでもよい。ルーティングエンティティ識別情報選好リストは、アドレス解決のために用いることができるルーティングエンティティ識別情報、およびアドレス解決がメッセージにおいてユーザ識別情報を探すべき順序を定義してもよい。例えば、表１におけるＣｘインターフェイスの場合、順序付けされたペア（Ｃｘインターフェイス（１６７７７２１６）、＊）に対するルーティングエンティティ識別情報選好リストは、以下のようであってもよい：
１．ＩＭＰＵ−まずＩＭＰＵを探す；そして
２．ＩＭＳＩ−有効なＩＭＰＵが見出されない場合は、ＩＭＳＩを探す
各タイプのルーティングエンティティ識別情報は、メッセージ属性値ペア（ＡＶＰ）の有限集合において担持されてもよい。表１においてリスト化された３ＧＰＰアプリケーションにおいては、アドレス解決がサポートしてもよいルーティングエンティティ識別情報は、下の表２において明記されるＡＶＰにおいて見つけ出すことができる。

表２は、ダイアメータシグナリングメッセージにあり、アドレス解決モジュール１０４によって用いられてもよい、ルーティングエンティティ識別情報およびＡＶＰの組み合わせをリスト化する。しかしながら、ここに記載される主題は、表２における例に限定されない。任意のルーティングエンティティ識別情報およびＡＶＰの組み合わせを用いて、受け取られたダイアメータシグナリングメッセージを検索し、アドレス解決を実行することが、ここに記載される主題の範囲内にあるように意図される。

１つの実現例は、包括的なフレームワークを提供して任意のダイアメータアプリケーションをサポートするために、ダイアメータアドレス解決モジュール１０４は、受け取られたメッセージにおけるアプリケーションＩＤまたはコマンドコードにかかわらず、表２に示されるＡＶＰの組においてルーティングエンティティ識別情報タイプを探すことになる。アドレス解決モジュール１０４は、まず、メッセージを検索し、オペレータが定義した最優先ルーティングエンティティ識別情報タイプを含むかもしれないＡＶＰのそれを探すことになる。表２に示されるように、ルーティングエンティティ識別情報タイプは、１つより多いＡＶＰに見つけ出されてもよい。これについては、以下により詳細に記載する。ルーティングエンティティ識別情報は、さらに、「グループ化された」というタイプのＡＶＰに埋め込まれてもよい。

アドレス解決モジュール１０４は、それが検索している所望のルーティングエンティティ識別情報タイプを含んでいるかもしれないＡＶＰに遭遇すると、以下を実行してもよい：
ルーティングエンティティ識別情報タイプが実際にＡＶＰにあるかどうかを判断し（これは、主にグループ化されたＡＶＰにあてはまる）；そして、
所望のルーティングエンティティ識別情報タイプが見出される場合には、アドレス内容を確認してもよい（例えば、どのような無効アドレス文字も含まない）。アドレス正規化を実行して、そのような文字を除去してもよい。アドレス正規化については以下により詳細に記載する。

所望のルーティングエンティティ識別情報が候補ＡＶＰにおいて見出されない場合、またはＡＶＰが所望のルーティングエンティティ識別情報を含むが、その内容がアドレス解決モジュール１０４によってサポートされない場合には、アドレス解決モジュール１０４は別の候補ＡＶＰについてメッセージを検索し続けてもよい。同じメッセージにＡＶＰの複数のインスタンスが存在し得るため、アドレス解決モジュール１０４は、有効なアドレスが見出されるまで、メッセージにおいて所望のルーティングエンティティ識別情報を含んでいるかもしれないすべてのＡＶＰおよびＡＶＰインスタンスを通して検索してもよい。

有効なルーティングエンティティ識別情報が最優先ルーティングエンティティ識別情報選好について見出されず、次に最も高いルーティングエンティティ識別情報選好が定義される場合には、アドレス解決モジュール１０４は、上記の手順を繰り返して、定義された次の最優先ルーティングエンティティ識別情報についてメッセージを検索することになる。有効なルーティングエンティティ識別情報が見出されるか、選好リストがすべて試されるまで、その手順を繰り返してもよい。ルーティングエンティティ識別情報が見出されない場合には、ルーティング例外取扱いが実行されてもよい。ルーティング例外取扱いについては以下により詳細に記載する。有効なアドレスが見出される場合には、ルーティングエンティティ識別情報検索は完了する。アドレス解決モジュール１０４は、一致を探して、アドレス桁数をとり、アプリケーションＩＤ、コマンドコードおよびルーティングエンティティ識別情報タイプに関連付けられる桁範囲テーブル（ＤＲＴ）と呼ばれるデータ構造を検索してもよい。ＤＲＴ検索が失敗した（一致がない）場合には、ルーティングは失敗し、それ以上の入来メッセージのアドレス解決処理は生じない。次いで、ルーティング例外取扱いが実行されることになる。ＤＲＴ検索が成功した場合には、一致するエントリに関連付けられる宛先アドレスを、メッセージのルーティングに対して用いる。以下により詳細に記載されるように、個別のアドレスオーバーライドも実行されてもよい。

前の段落においては、アドレス解決モジュール１０４は、有効なルーティングエンティティ識別情報が見出されるまで、受け取られたメッセージを連続的に検索することが示されている。しかしながら、ここに記載される主題は、そのような実施例に限定されない。代替の実施例においては、アドレス解決モジュール１０４は、受け取られたメッセージを、すべての考えられ得るルーティングエンティティについて検索し、次いで、探索が成功するまで、ユーザによって構成された優先順位順序でエンティティ上においてＤＲＴ探索を実行してもよい。

ＤＲＴは、サーバタイプ（例えばＩＭＳ−ＨＳＳ、ＬＴＥ−ＨＳＳ、ＰＣＲＦ、ＯＣＳ、ＯＦＣＳ）によってサービスされる、ユーザまたはルーティングエンティティ識別情報タイプについてのアドレスの集合である。ＤＲＴにおける各エントリは、サーバの１つ（例えばＬＴＥ−ＨＳＳ１）によってサービスされるアドレスの連続的なブロックまたは範囲であってもよい。ＤＲＴは、典型的にはＦＱＤＮを割り当てられる特定のダイアメータノードである宛先アドレスに関連付けられてもよい。図３は、ダイアメータアドレス解決モジュール１０４によって用いられ得るＤＲＴのためのデータ構造の例である。図３を参照して、ダイアメータアドレス解決モジュール１０４によって受け取られる入来メッセージは、その最も好ましいルーティングエンティティ識別情報について検索される。その識別情報が、もし存在する場合には、それを用いて、図３に示される階層を用いながら、宛先アドレスを見つけ出す。最も好ましい識別情報が存在しない場合には、図３に示される階層を用いるアドレス解決は、次の最も好ましいルーティングエンティティ識別情報を用いて実行される。

一旦、図３に示される階層を用いて、アドレスが解決されると、最終ルーティングが実行される。最終ルーティングは図１に示されるルーティングモジュール１０５によって実行されてもよい。実行される最終ルーティングは、図２に示されるように、入来アプリケーションＩＤに対するダイアメータノードタイプに依存してもよい。

＞入来アプリケーションＩＤに対するユーザ構成可能なダイアメータノードタイプがプロキシエージェントである場合には、最終ルーティングは以下のように実行されてもよい：
■宛先アドレスが領域とともに構成されている場合：
●アドレス解決モジュール１０４は、入来メッセージにおける宛先領域および宛先ホストＡＶＰを宛先―領域と置換し、宛先アドレスがＦＱＤＮを有する場合には、さらに、ヘッダの直後に単一の宛先ホストＡＶＰを挿入する
■そうでなければ（宛先アドレスはＦＱＤＮのみとともに構成されている）：
●アドレス解決は、入来メッセージにおける宛先ホストＡＶＰを、ヘッダの後の単一の宛先ホストＡＶＰと置換する
＞入来アプリケーションＩＤに対するユーザ構成可能なダイアメータノードタイプがリダイレクトエージェントである場合には、最終ルーティングは以下のように実行されてもよい：
■宛先アドレスがダイアメータＵＲＩとともに構成されている場合：
●正常リダイレクトエージェント回答応答を、Ｅビット＝１、リザルトコード値＝３００６（ＤＩＡＭＥＴＥＲ＿ＲＥＤＩＲＥＣＴ＿ＩＮＤＩＣＡＴＩＯＮ）（ダイアメータリダイレクト表示子）、および単一のリダイレクトホストＡＶＰが解決された宛先アドレスダイアメータＵＲＩを伴う状態で、送る
●注：ダイアメータは、リダイレクトエージェントが宛先（リダイレクトホストＡＶＰの複数のインスタンス）の優先順位付けされたリストで応答する能力をサポートする。しかしながら、この能力は任意である。

■そうでなければ（宛先アドレスはリダイレクト応答を送ることに対して誤って構成されている）：
●異常リダイレクトエージェント回答応答をリザルトコード＝５０１２（ＤＩＡＭＥＴＥＲ＿ＵＮＡＢＬＥ＿ＴＯ＿ＣＯＭＰＬＹ）（ダイアメータ応じることができない）とともに送る
●ＯＡＭイベントを生成する
一旦最終アドレスが解決されると、メッセージはダイアメータルーティング層に転送され、そこで、メッセージは、入来ダイアメータメッセージ処理モジュールから、宛先に関連付けられる出口ダイアメータ処理モジュールにルーティングされる。図４は、ＤＳＲ１００に対する例示的なアーキテクチャを示す。図４においては、ＤＳＲ１００は、バス４０２を介して互いに接続された複数個のメッセージプロセッサ４００を含む。各メッセージプロセッサは、アドレス解決モジュール１０４およびルーティングモジュール１０５を含む。入来メッセージに対しては、受け取るアドレス解決モジュール１０４は、ダイアメータルーティングアドレスを判断し、ルーティングモジュール１０５は、そのアドレスへのネクストホップに関連付けられるメッセージプロセッサ４００にメッセージを転送する。出口メッセージプロセッサ４００は、ダイアメータルーティング層メッセージキューを維持してもよい。これらのキューは、それらがいっぱいである場合にルーティングをアボートし、それによって、特定の宛先ノードに向けられるメッセージの流れを制御するように、用いられてもよい。

ここに記載される主題の別の局面によると、アドレス解決モジュール１０４は、メッセージに対するダイアメータ宛先アドレスを見出すことができない場合には、ルーティング例外処理を実行してもよい。ルーティング例外処理は構成可能であってもよく、以下のように実行されてもよい：
＞アドレス解決モジュール１０４は、それがメッセージに対する宛先アドレスを成功裏に見出すのを妨げる問題に遭遇する：
（１）入来メッセージにおけるアプリケーションＩＤはアドレス解決に対してプロビジョニングされない
（２）アプリケーションＩＤは有効であるが、メッセージにおけるコマンドコードはアドレス解決についてプロビジョニングされない
（３）メッセージは、順序付けされたペア（アプリケーションＩＤ、コマンドコード）に対するルーティングエンティティ識別情報において指定されたルーティングエンティティを含まない
（４）有効なルーティングエンティティ識別情報が見出されたが、ＤＲＴエントリと一致しなかった
＞アプリケーションＩＤが（ユーザ構成から判断されるように）アドレス解決によってサポートされない場合には、（アドレス解決が実行されることになるアプリケーション識別情報を定義する）ダイアメータルーティング層アドレス解決テーブルは、アドレス解決の構成と最も誤整列されそうである。

■アプリケーションに特有の応答を送ることができない
■アドレス解決は、リザルトコードＡＶＰ値が３００７（ＤＩＡＭＥＴＥＲ＿ＡＰＰＬＩＣＡＴＩＯＮ＿ＵＮＳＵＰＰＯＲＴＥＤ）（ダイアメータアプリケーションサポートされない）にセットされた状態で、回答応答を送ってもよい
＞アドレス解決によってサポートされるアプリケーションＩＤに関連付けられるルーティング例外（上記の例外２−４）に対しては、アドレス解決モジュール１０４は、以下のユーザ構成可能なＡＣＴＩＯＮ（アクション）選択肢を提供してもよい：
■メッセージを変更なく転送ルーティングする（デフォルト）
■メッセージをデフォルト宛先で転送ルーティングする
■回答応答を、ユーザ構成可能なリザルトコードまたは実験リザルトコード値とともに送る
＞ルーティング例外ＡＣＴＩＯＮは、「例外タイプにつき」および「アプリケーションＩＤ^＊”につき」ユーザ構成可能になる
■注：図２に示されるダイアメータインターフェイスについては、同じダイアメータアプリケーション内に、異なるデフォルト宛先タイプ（例えばＨＳＳ対ＰＣＲＦ）にルーティングされ得るコマンドコードはあるようには見えない。これが必要な場合には、ルーティング例外アクション「デフォルト宛先」選択肢は、（アプリケーションＩＤ、コマンドコード）につき構成可能であるべきである
アドレス範囲およびアドレス正規化
図３に述べられるように、ダイアメータ宛先アドレスを解決するように用いられるテーブル３０２、３０４および３０６は、受け取られたメッセージにおいて識別される好ましいユーザ識別情報と比較されるアドレスの範囲を含んでもよい。アドレス範囲は、９１９５５５００００〜９１９５５５９９９９のような桁の範囲を含んでもよい。範囲は異なるサイズのものであってもよい。例えば、範囲３０３２００〜３０３２９９９は前述の９１９の範囲と共存してもよい。等しい開始値および終値を有する範囲がサポートされてもよい。さまざまなアドレス範囲が、ＩＰｖ４アドレスおよびＩＰｖ６アドレスを含むすべてのユーザ識別情報タイプに対してサポートされてもよい。

ＡＶＰに存在する多くの文字は、図３に示される範囲テーブルを検索するように用いられるユーザ識別情報の一部でなくてもよい。そのような識別情報に対しては、アドレス解決モジュール１０４はアドレス正規化を実行してもよい。アドレス正規化は、メッセージにおけるＳＩＰおよびｔｅｌ ＵＲＩから「ＳＩＰ：」「およびＴＥＬ：＋」のようなプレフィックスを除去することを含んでもよい。同様に、ＵＲＩおよびＮＡＩにおける「＠ドメイン」のようなサフィックスも無視されなければならない。ＵＲＩにおいて一般に見出される「．」、「−」、および「／」のような視覚的な分離文字は、無視されなければならない。ダイアメータアドレス解決モジュール１０４によって実行されてもよいアドレス正規化の例として、未処理のＡＶＰアドレス：「ｔｅｌ：＋１−９１９−４４４−１２１２」は、正規化の後、「９１９４４４１２１２」に変換されてもよい。

ユーザ識別情報を含むＡＶＰ
上に述べられたように、アドレス解決モジュール１０４は、ユーザ識別情報アドレス情報を含む以下のＡＶＰの任意の１つ以上に基づいたアドレス解決を実行してもよい。

■ユーザ-識別情報
■パブリック-識別情報
■ＭＳＩＳＤＮ
■加入-ＩＤ
■サービス-情報
■フレーミングされた-ＩＰ-アドレス
■フレーミングされた-ＩＰｖ６-プレフィックス
ユーザ識別情報ＡＶＰは、ＩＭＰＵまたはＭＳＩＳＤＮのいずれかを含む。ＩＭＰＵはパブリック識別情報値ペアに埋め込まれる。ＭＳＩＳＤＮはＭＳＩＳＤＮ ＡＶＰに埋め込まれる。

パブリック識別情報ＡＶＰはＩＭＰＵを含む。ＩＭＰＵは、タイプＵＴＦ−８ストリングであってもよく、ＳＩＰ ＵＲＩまたはｔｅｌ ＵＲＩの形式であってもよい。

ＭＳＩＳＤＮ ＡＶＰはＭＳＩＳＤＮを国際的なフォーマットにおいて含む。ＭＳＩＳＤＮは１オクテット当たり２つの桁を有するＴＢＣＤストリングとしてエンコードされてもよい。ＭＳＩＳＤＮ ＡＶＰはＩＭＰＩまたはＩＭＳＩを含む。ユーザ識別情報アドレスはＮＡＩのユーザ名部分において記憶されることになる。ＮＡＩにおいてエンコードされてもよいＩＭＳＩの一例は、IMSI@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.orgである。ＮＡＩにおいてエンコードされてもよいＩＭＰＩの一例は9194441212@vzw.comである。

加入ＩＤ ＡＶＰは、埋め込まれた加入ＩＤタイプＡＶＰによって定義されるような５つのユーザ識別情報タイプの１つを含んでもよい。含まれてもよいタイプは、エンドユーザＥ．１６４番号、エンドユーザＩＭＳＩ、エンドユーザＳＩＰ ＵＲＩ、エンドユーザＮＡＩ、またはエンドユーザプライベートアドレスである。

サービス情報ＡＶＰは１つ以上の加入ＩＤ ＡＶＰを含んでもよい。加入ＩＤ ＡＶＰおよびサービス情報ＡＶＰは、上に記載された識別情報を含んでもよい。フレーミングされたＩＰアドレスＡＶＰは、加入者のＩＰｖ４アドレスを含んでもよい。同様に、フレーミングされたＩＰｖ６プレフィックスＡＶＰは、加入者のＩＰｖ６アドレスのＩＰｖ６プレフィックスを含んでもよい。プレフィックスはＩＰｖ６アドレスのルーティング可能部分である。

パブリック識別情報および加入ＩＤ ＡＶＰは、ＳＩＰおよび／またはｔｅｌ ＵＲＩを含んでもよい。ＳＩＰおよびｔｅｌ ＵＲＩはＩＭＳユーザのＩＭＰＵを含む。ＳＩＰおよびｔｅｌ ＵＲＩは標準形を有するため、アドレス解決モジュール１０４は、アドレス解決を実行するために用いられるＥ．１６４番号のような適切なデータを抽出してもよい。

個別のアドレス解決オーバーライド
図３に示される例においては、識別情報を用いてアドレスの範囲を検索する。範囲に基づいたアドレス解決は、あるタイプ（例えばＩＭＳＩ）のアドレスのすべてが宛先に割り当てられる範囲に分割されることを仮定する。個別のアドレスに対して、範囲に基づいたアドレス解決のオーバーライドを行なうことが、望ましいかもしれない。例えば、図５に示されるように、複数のＤＳＲ１００を階層的ネットワークにおいて展開してもよい。メッセージがゲートウェイＤＳＲ１００_Ａに到着すると、そのアドレス解決モジュールは、１つ以上の区域ＤＳＲ１００_Ｂ、１００_Ｃまたは１００_Ｄにメッセージをルーティングするようにプロビジョニングされてもよい。各区域ＤＳＲは最終アドレス解決および最終ルーティングを実行してもよい。ゲートウェイＤＳＲ１００_Ａでのアドレス解決は最終宛先に対してであってもなくてもよい。例えば、最終宛先ルーティング判断が区域で生じることをオペレータが望む場合には、オペレータは、区域ＤＳＲへのアドレスを解決するようにゲートウェイＤＳＲ１００_Ａを構成してもよい。

各区域ＤＳＲ１００_Ｂ、１００_Ｃまたは１００_Ｄでは、オペレータは、加入者を透過的に移動させる（つまり加入者に対して彼らの電話番号または加入者識別情報を変更することを強要することなく）柔軟性を欲してもよい。この例においては、ゲートウェイＤＳＲ１００_Ａは、ＨＳＳアドレス解決を区域ＤＳＲ１００_Ｂ、１００_Ｃまたは１００_Ｄのいずれかに対して実行することになる。ゲートウェイＤＳＲ１００_Ａがメッセージを区域ＤＳＲ１００_Ｂに転送すると、区域ＤＳＲ１００_Ｂは２回目のアドレス解決を実行して最終宛先アドレスを判断してもよい。しかしながら、区域１における加入者の何人かは、区域２に移動されてもよい。区域１００_Ｂ上のアドレス解決が成功して宛先アドレスになった後、区域ＤＳＲ１００_Ｂは、区域ＤＳＲ１００_ＢにおいてＤＲＴに関連付けられる個別のオーバーライドテーブルを見直して、ユーザ識別情報アドレスが移動されたかどうかを確かめてもよい。ユーザ識別情報アドレスが見出される場合には、ＩＯＴ解決がＤＲＴ解決に優先する。

アドレス解決オーバーライドがサポートされる各ＤＲＴに対しては、別個のＩＯＴが必要となる。ＩＯＴは以下の属性とともに構成されてもよい：
■ＩＯＴ名
■ＤＲＴ名（このＩＯＴと関連付けられる）
■アドレスストリング
■プロキシエージェントアドレス指定に対しては：
●領域
●ホスト（ＦＱＤＮ）
■リダイレクトエージェントアドレス指定に対しては：
●ダイアメータＵＲＩ
■後のアドレス解決を可能にする：ノー（デフォルト）、イエス
●このトピックについて後のスライドを参照する
図３に示される宛先アドレステーブルにおける同じ属性と同一としてのＩＯＴにおける領域、ホストおよびダイアメータＵＲＩ値の使用。

同じアドレス解決アプリケーションの複数呼出しを防止する
ここに記載される主題の別の局面によれば、ここに記載されるようなアドレス解決でプロビジョニングされるＤＳＲは、同じメッセージ上で実行される複数の同一のアドレス解決を防ぐ能力を含んでもよい。この問題が生じるかもしれないのは、図６に示されるように、重複するアドレス解決データを伴う１つより多いＤＳＲが顧客のネットワークにおいて展開される場合である。図６においては、ＤＳＲ１００_１および１００_２が顧客のネットワークにおいて展開される。ＤＳＲ１００_１がアドレス解決を実行する場合には、ＤＳＲ１００_２が同じメッセージ上で同じアドレス解決を実行しないことを保証することが望ましい。１つの実現例においては、複数アドレス解決防止を、ＤＲＴエントリ毎およびＩＯＴエントリ毎ベースで構成してもよい。例えば、個別のアドレス解決オーバーライド使用例では、ゲートウェイＤＳＲ１００_ＡにおけるＨＳＳ ＤＲＴエントリのすべてを、後のアドレス解決が区域ＤＳＲで生じることを可能にするように構成してもよい。しかしながら、ゲートウェイＤＳＲ ＨＳＳ−ＤＲＴがＩＯＴをサポートする場合には、解が最終宛先アドレスになる、ＩＯＴにおけるどのようなエントリも、好ましくは、後のアドレス解決が生じることを可能にするようには構成されない。一旦アドレス解決がメッセージ上で実行されると、そのメッセージをＤＲＴまたはＩＯＴエントリに基づいてマーキングして、そのアドレス解決が実行されたことを示してもよい。後のアドレス解決が同じメッセージ上で試みられる場合には、前のアドレス解決からのマーキングは、そのアドレス解決が実行されるのを妨げてもよい。さらに、システムにわたるユーザ構成可能なパラメータを用いて、防止解決策を不能化してもよい。

図７は、ここに記載される主題の実施例に従ってダイアメータアドレス解決に対する例示的な全体的なステップを示すフローチャートである。図７を参照して、ステップ７００において、ダイアメータシグナリングメッセージが受け取られる。例えば、メッセージは図１に示されるＤＳＲ１００によって受け取られてもよい。ステップ７０２において、ダイアメータアドレス解決がメッセージにあてはまるかどうかが判断される。特定のアプリケーションＩＤがダイアメータアドレス解決に対してプロビジョニングされ、他のものはルーティングのみに対して構成されるように、ＤＳＲ１００は構成されてもよい。上に示される表１は、アドレス解決が構成されてもよい例示的なアプリケーション識別子を示す。

ステップ７０２において、ダイアメータアドレス解決はあてはまらないと判断される場合には、制御はステップ７０４に進み そこで、作動中のオペレータ構成可能なルーティング例外処理が実行される。例えば、ＤＳＲ１００は、メッセージを変えないままでルーティングするか、メッセージをデフォルト宛先にルーティングするか、またはユーザ構成可能なリザルトコード値もしくは実験リザルトコード値で返答を送るように構成されてもよい。

ステップ７０２に戻って、ダイアメータアドレス解決があてはまると判断される場合には、制御はステップ７０６に進み、メッセージが、オペレータ構成可能な好ましいルーティングエンティティ識別情報について検索される。上に述べられたように、ネットワークオペレータは、識別情報が受け取られたメッセージを検索する際に用いられるべく見つけ出される好ましいルーティングエンティティ識別情報および属性値ペアのリストをプロビジョニングしてもよい。ステップ７０８において、好ましい識別情報がメッセージにあると判断される場合には、制御はステップ７１０に進み、その好ましい識別情報を用いて、１つ以上のダイアメータアドレス解決探索が実行される。探索は、図３に示されるようなデータ構造において実行されてもよい。

ステップ７１２において、探索が成功したかどうかが判断される。探索が一致するエントリを見つけ出すのに成功した場合には、制御はステップ７１４に進み、ダイアメータルーティングパラメータのオペレータ構成可能な置換または挿入および最終ルーティングが実行される。上に述べられたように、受け取られたメッセージがルーティングされつつある場合には、宛先領域および／または宛先ホストのような受け取られたメッセージにおけるパラメータのオペレータ構成可能な置換が実行されてもよい。次いで、メッセージはルーティングされてもよい。受け取られたダイアメータ要求への回答のような新しいメッセージが形成されつつある場合には、探索において見つけ出されるダイアメータルーティングパラメータは回答メッセージに挿入されてもよく、メッセージはダイアメータ要求の発信側に送られてもよい。

ステップ７０８に戻って、好ましいルーティングエンティティ識別情報が受け取られたメッセージに存在しないと判断される場合には、制御はステップ７１６に進み、識別情報は好ましい識別情報リストにおける最後の識別情報であるかどうかが判断される。識別情報が最後の識別情報である場合には、制御はステップ７０４に進み、オペレータ構成可能なルーティング例外処理が、上に述べられたように、実行される。識別情報が好ましい識別情報リストにおける最後の識別情報ではない場合には、制御はステップ７１８に進み、次の識別情報が検索され、次いでステップ７０６に進み、メッセージを次の識別情報について検索する。同様に、ステップ７１２において、ダイアメータアドレス解決探索が成功しない場合には、制御はステップ７１６に進み、ダイアメータアドレス解決探索が実行された識別情報は好ましい識別情報リストにおける最後の識別情報であるかどうかが判断される。識別情報が最後の識別情報である場合には、制御はステップ７０４に進み、オペレータ構成可能なルーティング例外処理が実行される。ステップ７１６において、識別情報が最後の識別情報でない場合には、次の識別情報がステップ７１８においてメッセージから抽出され、制御はステップ７０６に戻り、メッセージは、次のオペレータ構成可能な好ましいルーティングエンティティ識別情報について検索される。このプロセスは、アドレス解決が実行されるか、またはルーティング例外が生じるまで、継続してもよい。このプロセスは、各受け取られるダイアメータシグナリングメッセージ毎に繰り返されてもよい。

ここに開示される主題のさまざまな詳細はここに開示される主題の範囲から逸脱せずに変更されてもよいことが理解される。さらに、前述の記載は、限定の目的のためではなく、例示のためのみにある。

Claims (15)

1. 構成可能なダイアメータアドレス解決のためのシステムであって、
   ダイアメータシグナリングルータ（ＤＳＲ）を備え、前記ＤＳＲは、
   ネットワークにおいてダイアメータシグナリングエンティティとのダイアメータシグナリングメッセージの送受信を行なうためのネットワークインターフェイスと、
   複数個のルーティングエンティティ識別情報の構成、およびダイアメータアドレス解決の実行において前記ルーティングエンティティ識別情報を優先的に用いるための順序の構成を設けるように構成されたダイアメータアドレス解決モジュールと、
   前記ダイアメータアドレス解決において判断されるダイアメータアドレス情報を用いてダイアメータシグナリングメッセージをルーティングするように構成されたダイアメータルーティングモジュールとを含む、システム。
2. 前記ダイアメータアドレス解決モジュールは、受け取られたダイアメータシグナリングメッセージを、前記順序で指定される最も好ましいルーティングエンティティ識別情報について検索し、前記最も好ましいルーティングエンティティ識別情報を見つけ出すことに失敗したことに応答して、次の最も好ましいルーティングエンティティ識別情報を検索し、見つけ出された場合には、前記ダイアメータアドレス解決の実行において前記次の最も好ましいルーティングエンティティ識別情報を用いるように構成される、請求項１に記載のシステム。
3. 前記ダイアメータアドレス解決モジュールは、受け取られたダイアメータシグナリングメッセージを、考えられ得るルーティングエンティティ識別情報について検索し、前記ダイアメータシグナリングメッセージに見つけ出されるルーティングエンティティ識別情報を前記順序で用いて、前記ダイアメータアドレス解決のインスタンスが成功するまで、前記ダイアメータアドレス解決を実行するように構成される、請求項１に記載のシステム。
4. 前記ダイアメータアドレス解決モジュールは、前記ダイアメータアドレス解決が失敗するダイアメータシグナリングメッセージに対するルーティング例外の構成を設けるように構成される、請求項１〜３のいずれか１項に記載のシステム。
5. 前記ダイアメータアドレス解決モジュールは、ルーティングされるべき受け取られたダイアメータシグナリングメッセージにおいてダイアメータアドレス情報を置換するか、または受け取られたダイアメータ要求メッセージに応答して生成されたダイアメータ応答メッセージ内に前記ダイアメータアドレス解決において判断された前記ダイアメータアドレス情報を挿入するように構成される、請求項１〜４のいずれか１項に記載のシステム。
6. 前記ダイアメータアドレス解決モジュールは、個別のアドレスオーバーライド探索をルーティングエンティティ識別情報について実行し、成功した場合には、範囲に基づいたダイアメータアドレス解決探索をバイパスするように構成される、請求項１〜５のいずれか１項に記載のシステム。
7. 前記個別のアドレスオーバーライド探索は、個別の加入者のためのレコードがダイアメータサービスノードの間で移動されることを可能にする、請求項６に記載のシステム。
8. 構成可能なダイアメータアドレス解決のための方法であって、
   ダイアメータシグナリングルータ（ＤＳＲ）において、
   ネットワークにおいてダイアメータシグナリングエンティティとのダイアメータシグナリングメッセージの送受信を行なうステップと、
   複数個のルーティングエンティティ識別情報の構成、およびダイアメータアドレス解決の実行において前記ルーティングエンティティ識別情報を優先的に用いるための順序の構成を設けるステップと、
   前記ダイアメータアドレス解決において判断されるダイアメータアドレス情報を用いてダイアメータシグナリングメッセージをルーティングするステップとを含む、方法。
9. 前記ルーティングエンティティ識別情報を用いるための前記順序の構成を設けるステップは、前記ＤＳＲが、受け取られたダイアメータシグナリングメッセージを、前記順序で指定された最も好ましいルーティングエンティティ識別情報について検索し、前記最も好ましいルーティングエンティティ識別情報を見つけ出すことに失敗したことに応答して、次の最も好ましいルーティングエンティティ識別情報を検索し、見つけ出された場合には、前記ダイアメータアドレス解決の実行において前記次の最も好ましいルーティングエンティティ識別情報を用いるステップを含む、請求項８に記載の方法。
10. 前記ルーティングエンティティ識別情報を用いるための前記順序の構成を設けるステップは、前記ＤＳＲが、受け取られたダイアメータシグナリングメッセージを、考えられ得るルーティングエンティティ識別情報について検索し、前記ダイアメータシグナリングメッセージに見つけ出されるルーティングエンティティ識別情報を前記順序で用いて、前記ダイアメータアドレス解決を実行するステップを含む、請求項８に記載の方法。
11. 前記ダイアメータアドレス解決を実行するステップは、個別のアドレスオーバーライドテーブルにおいて探索を実行するステップを含み、前記個別のアドレスオーバーライドテーブルにおける前記探索が失敗した場合には、範囲に基づいたテーブルにおける探索が続く、請求項１０に記載の方法。
12. 前記ダイアメータアドレス解決が失敗するダイアメータシグナリングメッセージに対するルーティング例外の構成を設けるステップを含む、請求項８〜１１のいずれか１項に記載の方法。
13. ルーティングされるべき受け取られたメッセージにおいてダイアメータ宛先パラメータを置換するステップ、またはダイアメータ要求メッセージに応答して送信されるべきダイアメータ応答メッセージ内に前記ダイアメータアドレス解決において判断されたダイアメータアドレス情報を挿入するステップを含む、請求項８〜１２のいずれか１項に記載の方法。
14. 前記個別のアドレスオーバーライドテーブルは、レコードがダイアメータサービスノードに移動された加入者に対応するルーティングエンティティ識別情報をプロビジョニングされる、請求項１３に記載の方法。
15. コンピュータのプロセッサによって実行され、前記コンピュータを制御して、
    ダイアメータシグナリングルータ（ＤＳＲ）において、
    ネットワークにおいてダイアメータシグナリングエンティティとのダイアメータシグナリングメッセージの送受信を行なうステップと、
    複数個のルーティングエンティティ識別情報の構成、およびダイアメータアドレス解決の実行において前記ルーティングエンティティ識別情報を優先的に用いるための順序の構成を設けるステップと、
    前記ダイアメータアドレス解決において判断されるダイアメータアドレス情報を用いてダイアメータシグナリングメッセージをルーティングするステップとを実行させる実行可能命令を含む、コンピュータプログラム。