(57)【特許請求の範囲】
【請求項１】
マルチ無線アクセス技術ＲＡＴおよび／またはマルチ・ドメイン・モバイル・ネットワークを通じたモバイル着信サービス配信をサポートするための方法であって、ユーザ機器ＵＥが複数のサービング・コア・ネットワークＣＮノードに登録され得、前記方法が、前記ＵＥに向けたモバイル着信サービス配信の試みにとって好ましいサービングＣＮノードおよび／または好ましいドメインの表示を含む、着信選択情報と称される情報を使用し、前記好ましいサービングＣＮノードおよび／または前記好ましいドメインが、前記複数のサービングＣＮノードから取り出された、着信選択サポート情報と称される情報に基づき、現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインとして決定され、前記方法が、現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定のために、ＵＥのＲＡＴごとのキャンピング確率についての情報を含む着信選択サポート情報を使用し、前記サービングＣＮノードによって制御されるサービング無線アクセス・ネットワークＲＡＮノードが、前記サービングＣＮノードに対し、ＵＥのＲＡＴごとのキャンピング確率の表示をシグナリングする、方法。
【請求項２】
現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベース（ＨＳＳ／ＨＬＲ）が、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、複数のモードのうちの１つを動的に選択するステップであって、前記動的な選択はモバイル・ネットワーク申込者データベースによるＵＥ挙動の観察に基づき、前記複数のモードは、
前記申込者データベースが複数のサービングＣＮノードから情報をプルする、プルに基づくモード、
前記モバイル・ネットワーク申込者データベースからの要求の後に、複数のサービングＣＮノードが情報変更に際して、前記申込者データベースに通知する、プッシュに基づくモード、および
ＵＥ申し込み情報、および／または複数のサービングＣＮノードから受信された最後の位置更新要求の時刻に依拠する、パッシブなモード、
の内の１つであるステップ
を含む、請求項１に記載の方法。
【請求項３】
現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定のために、ならびに／あるいは複数のサービングＣＮノードから着信選択サポート情報を取り出す複数のモードのうちの１つの動的な選択のために、前記ＵＥについてのユーザ申し込みを使用するステップ
を含む、請求項１または２に記載の方法。
【請求項４】
サービングＣＮノードが、現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースに対し、ＵＥのＲＡＴごとのキャンピング確率についての情報を含む着信選択サポート情報をシグナリングするステップ
を含む、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
サービングＣＮノードが、現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースに対し、ＵＥ能力および／または訪問先ネットワーク能力および／または前記ＵＥについてのキャンピング・ポリシーについての情報を含む着信選択サポート情報をシグナリングするステップ
を含む、請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
サービングＣＮノードによって制御されるサービング無線アクセス・ネットワークＲＡＮノードが、
前記サービングＣＮノードによって前記ＲＡＮノードに送信された、ＲＡＴ／周波数優先度についての申込者プロファイルＩＤ  ＳＰＩＤパラメータ、
ＵＥ無線能力、
ＲＡＮ上の構内構成
のうちの少なくとも１つを含む情報から、ＵＥのＲＡＴごとのキャンピング確率の表示を特定するステップ
を含む、請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
サービングＣＮノードが、モバイル・ネットワーク申込者データベースに対し、ＵＥのＲＡＴごとのキャンピング確率についての情報を包含する位置更新要求を送信するステップ
を含む、請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベース（ＨＳＳ／ＨＬＲ）が、前記ＵＥについて前記モバイル・ネットワーク申込者データベースにおいて構成され、ＲＡＴ／周波数選択優先度ＲＦＳＰインデックス・パラメータを含む申し込み情報に基づき、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、複数のモードのうちの１つを動的に選択するステップ
を含む、請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
現時点で最も高い確率で前記ＵＥに到達することの可能な前記サービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、サービングＣＮノードに対してＵＥのＲＡＴごとのキャンピング確率の変更の通知を申し込むステップ、またはサービングＣＮノードに対してＵＥとの無線連絡の通知を申し込むステップ
を含む、請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベース（ＨＳＳ／ＨＬＲ）が、前記サービングＣＮノードに対し、前記ＵＥのデタッチに際してこのＵＥをパージするように、したがって、前記サービングＣＮノードが前記ＵＥをデタッチしたときに、前記モバイル・ネットワーク申込者データベースに通知するように、求めるステップ
を含む、請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベース（ＨＳＳ／ＨＬＲ）が、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、
前記ＵＥに対するモバイル着信サービスが、稀であって、かつ遅延耐性であるとき、または
サービングＣＮノードが、ＲＡＴを通じたキャンピング確率が高いことを表示し、前記ＵＥに対する前記モバイル着信サービスが遅延耐性であるとき、
ユーザ申し込み情報に、および／またはサービングＣＮノードから受信された最後の位置更新要求の時刻に依拠する、パッシブなモードを選択するステップ
を含む、請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
モバイル・ネットワーク申込者データベース（ＨＳＳ／ＨＬＲ）による、ＵＥに対するモバイル着信サービス配信用の着信選択情報を得る要求の受信の際に、
前記モバイル・ネットワーク申込者データベースが、
前記モバイル・ネットワーク申込者データベースに格納された、前記複数のサービングＣＮノードによって前記ＵＥが検出された最後の時刻、
現時点で最も高い確率で前記ＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインを決定するために、前記モバイル・ネットワーク申込者データベースによって選択された現在のモード、
をチェックするステップと、
前記現在のモードが、前記申込者データベースが複数のサービングＣＮノードから情報をプルする、プルに基づくモードである場合、または前記申込者データベースに格納された前記最後の時刻が、前記モバイル着信サービスにしてはあまりにも古いと考えられる場合に、前記申込者データベースが複数のサービングＣＮノードから情報をプルするステップと、
さもなければ、前記申込者データベースが、前記申込者データベースに格納された前記最後の時刻についての、構内で格納された情報を考慮するステップと
を含む、請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
請求項１乃至１２のいずれか１項に記載の方法を実施する手段を含むモバイル・ネットワーク・エンティティ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、モバイル・ネットワークおよびシステムに関し、このようなネットワークおよびシステムにおけるモバイル着信サービス配信に関する。
【背景技術】
【０００２】
モバイル・ネットワークおよびシステムの詳細な説明は、たとえば３ＧＰＰ（第三世代パートナーシップ・プロジェクト）などの標準化機関によって発行された、たとえば技術仕様書などの文献に見出され得る。（たとえば）３ＧＰＰによって明記されたモバイル・システムの例には、ＧＳＭ／ＧＰＲＳ、ＵＭＴＳ、およびＥＰＳ（進化したパケット・システム）が含まれる。
【０００３】
このようなシステムにおいて、端末（ユーザ機器ＵＥとも呼ばれる）は、ＰＬＭＮ（公衆地上モバイル・ネットワーク）とも呼ばれるモバイル・ネットワークを介してサービスにアクセスする。
【０００４】
モバイル・ネットワークは一般に、無線アクセス・ネットワーク（ＲＡＮ）によってアクセスされるコア・ネットワーク（ＣＮ）を備える。モバイル・ネットワークは、１つまたは複数の無線アクセス技術（ＲＡＴ）によってアクセスされる、特にＣＳ（回線交換）ドメインおよび／またはＰＳ（パケット交換）ドメインなどの１つまたは複数のＣＮドメインを備え得る。たとえば、ＣＳコア・ネットワークおよびＧＰＲＳコア・ネットワークは、ＧＥＲＡＮ／ＵＴＲＡＮを介してアクセスされる、ＣＳドメインおよびＰＳドメインをそれぞれ備え、その一方で、高度化されたパケット・コアは、ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮを介してアクセスされるＰＳドメインを備える。モバイル・ネットワークは、ＰＳドメインによってアクセスされるＩＭＳ（ＩＰマルチメディア・サブシステム）ドメインも備え得る。
【０００５】
所与のドメインからサービスにアクセスするために、ＵＥは、このドメインにアタッチされていなければならず、すなわち、（ＣＳドメイン内の）ＭＳＣ／ＶＬＲ、（ＧＰＲＳ／ＵＭＴＳ  ＰＳドメイン内、またはＧＥＲＡＮ／ＵＴＲＡＮによってアクセスされるＥＰＣ内の）ＳＧＳＮ、（Ｅ−ＵＴＲＡＮによってアクセスされるＥＰＣ内の）ＭＭＥなどの、このドメイン内のサービングＣＮノードにおいて登録されていなければならない。サービングＣＮノードのアイデンティティまたはアドレスの形をとったルーティング情報は、ＨＬＲ／ＨＳＳなどのモバイル・ネットワーク申込者データベースに格納される。たとえば、ＣＳドメイン内では、サービングＭＳＣ／ＶＬＲにおいてＵＥが登録され、ＰＳドメイン内では、サービングＳＧＳＮおよび／またはサービングＭＭＥにおいてＵＥが登録され得る。
【０００６】
このようなネットワークおよびシステムにおけるサービス配信の例が、特に３ＧＰＰ  ＴＳ  ２３．０４０に明記されたショート・メッセージ・サービスＳＭＳを特に使用した、ショート・メッセージの配信である。３ＧＰＰ  ＴＳ  ２３．０４０から採用した図１は、ＧＳＭ／ＵＭＴＳを通じたモバイル着信ＳＭＳ配信の例を例示する。ＳＭＳ−ＧＭＳＣは、ＳＭＳ配信用のルーティング情報を取り出すために、ＳＭ用ルーティング情報送信（Ｓｅｎｄ−Ｒｏｕｔｉｎｇ−Ｉｎｆｏ−Ｆｏｒ−ＳＭ）メッセージを送信することによって、ＨＬＲに問い合わせる。ＨＬＲから獲得されたルーティング情報を使用して、ショート・メッセージは、次いで、ＭＳＣ／ＶＬＲまたはＳＧＳＮに転送される。ＨＬＲから２つのアドレス（ＳＧＳＮおよびＭＳＣ／ＶＬＲ）が受信される場合において、ＳＭＳ−ＧＭＳＣは、どちらのノード（ＳＧＳＮまたはＭＳＣ／ＶＬＲ）を介してＳＭＳが最初に送信されるべきであるかを（事業者に依存して）選び得る。図１に例示された例において、ショート・メッセージ転送の試みは、第１の経路（たとえばＳＧＳＮ）を通じては失敗しており、第２の経路（たとえばＭＳＣ／ＶＬＲ）を通じては成功している。
【０００７】
このようなネットワークおよびシステムにおけるサービス配信の別の例が、特に３ＧＰＰ  ＴＳ  ２３．２９２に明記されたＩＭＳ集中型サービス（ＩＣＳ）を特に使用する、ＩＭＳ音声／ビデオ呼サービス配信である。特に３ＧＰＰ  ＴＳ  ２３．２９２、３ＧＰＰ  ＴＳ  ２３．２２１、および３ＧＰＰ  ＴＳ  ２９．３２８に明記されるように、ＳＣＣ  ＡＳ（サービス集中および継続アプリケーション・サーバ）と呼ばれるアプリケーション・サーバにおいて実装される着信アクセス・ドメイン選択（Ｔ−ＡＤＳ）機能は、サービス配信用にＣＳまたはＰＳドメインのいずれかを選択するために、ＨＳＳにＴ−ＡＤＳ情報を要求する。
【０００８】
たとえば３ＧＰＰ  ２３．６８２などにおいて規定された、たとえば入信デバイス・トリガの配信などの、同様の機構またはプロシージャを使用したモバイル着信サービス配信の他の例が、当然ながら可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
発明者らによって認識されるように、およびより詳細に後で解説されるように、このようなモバイル着信サービス配信の機構またはプロシージャによって誘発されるシグナリング負荷および／または遅延を減じる必要性が存在する。より概括的には、このようなネットワークおよびシステムにおいて、モバイル着信サービス配信を改善する必要性が存在する。
【課題を解決するための手段】
【００１０】
本発明の諸実施形態は、特に、このような必要性に対処する。
【００１１】
これらのおよび他の目的は、一態様において、マルチ無線アクセス技術ＲＡＴおよび／またはマルチ・ドメイン・モバイル・ネットワークを通じたモバイル着信サービス配信をサポートするための方法によって達成され、ここでは、ユーザ機器ＵＥが複数のサービング・コア・ネットワークＣＮノードに登録され得る。
【００１２】
一実施形態において、前記方法は、前記ＵＥに向けたモバイル着信サービス配信の試みにとって好ましいサービングＣＮノードおよび／または好ましいドメインの表示を含む、着信選択情報と称される情報を使用し、前記好ましいサービングＣＮノードおよび／または前記好ましいドメインは、前記複数のサービングＣＮノードから取り出された、着信選択サポート情報と称される情報に基づき、現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインとして決定される。
【００１３】
着信選択情報の例には、モバイル着信ＳＭＳ配信用にＨＳＳ／ＨＬＲによってＳＭＳ−ＧＭＳＣに送信されるルーティング情報、モバイル着信トリガリング用にＨＳＳ／ＨＬＲによってデバイス・トリガ・ゲートウェイに送信されるルーティング情報、ＩＣＳを使用したＩＭＳ音声／ビデオ呼サービス配信用にＨＳＳ／ＨＬＲによってＳＣＣに送信されたＴ−ＡＤＳ情報などが含まれる。
【００１４】
着信選択サポート情報の例には、ＳＧＳＮまたはＭＭＥによってＨＬＲ／ＨＳＳに送信された、ＲＡＴおよびＵＥとの最後の無線連絡のタイム・スタンプなどが含まれる。
【００１５】
一実施形態において、前記方法は、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定のために、ＵＥのＲＡＴごとのキャンピング確率についての情報を含む着信選択サポート情報を使用するステップ
を含む。
【００１６】
これらのおよび他の目的は、他の態様において、このような方法および／またはこのような方法の個々のステップ（複数可）を実施するためのモバイル・ネットワーク・エンティティによって達成され、前記エンティティは、特に（ただし、限定するものではないが）、モバイル・ネットワーク・データベース（たとえばＨＬＲ／ＨＳＳなど）、およびモバイル・ネットワーク・ノード（たとえばＭＭＥ、ＳＧＳＮ、その他など）を含む。
【００１７】
本発明の諸実施形態による装置および／または方法のいくつかの実施形態について、例としてのみ、および以下の図を含む添付の図面を参照して、これから説明する。
【図面の簡単な説明】
【００１８】
【図１】ＧＳＭ／ＵＭＴＳを通じた、モバイル着信ＳＭＳ配信用のプロシージャの例を想起することが意図される図である。
【図２】本発明の諸実施形態による、モバイル・ネットワーク申込者データベースにおける、直近のサービングＣＮノードの決定を例示することが意図される図である。
【発明を実施するための形態】
【００１９】
入信ＳＭＳがモバイル・ユーザに送信されるとき、あるいは入信／着信の音声／ビデオ呼または任意の他の着信サービス（位置特定サービスもしくはデバイス・トリガ要求など）がモバイルＵＥをターゲットにしているとき、ＵＥに到達して着信サービスを実行するために、ＵＥに応対する複数の（ＣＮ）ノード（たとえばＭＳＣ／ＶＬＲ、ＳＧＳＮ、ＭＭＥ）、および／またはＲＡＴ（たとえばＧＥＲＡＮ、ＵＴＲＡＮ、ＥＵＴＲＡＮ、ＷＬＡＮなど）、および／またはドメイン（ＣＳ、ＰＳ、ＩＭＳ）を使用することが、往々にして可能である。それでもなお、最初の試行においてターゲット端末に到達する見込みを最適化するために、およびシグナリング負荷を最小化するために、ＵＥに応対するどのＣＮノードに（最初の）要求を送信するかを適切に決定することが望ましい。
【００２０】
ＳＭＳの場合について、端末は、ＭＳＣ／ＶＬＲを介して、および／またはＳＧＳＮを介して、および／または（ネイティブＳＭＳ配信がＭＭＥによってサポートされているときには）ＭＭＥを介して、到達され得る。音声／ビデオ呼について、端末は、回線交換ドメインを介して、またはパケット交換ドメインを通じてＩＭＳを介して、のいずれかにおいて到達され得る。
【００２１】
ＵＥへの着信サービス配信の責任を負うネットワーク・エンティティ（ＳＭＳの場合には、たとえばＳＭＳ−ＧＭＳＣもしくはＳＭＳルータ、またはデバイス・トリガリングの場合には、デバイス・トリガ・ゲートウェイ、または入信ＩＭＳ音声／ビデオ呼の場合には、ＳＣＣ１  ＡＳ）は、成功の見込みを最適化し、かつネットワーク・シグナリング負荷および遅延を最小化して、着信サービスを実行するために、どのサービングＣＮノード、および／またはＲＡＴ（たとえばＧＥＲＡＮ、ＵＴＲＡＮ、ＥＵＴＲＡＮ、ＷＬＡＮなど）、および／またはドメイン（ＣＳ、ＰＳ、ＩＭＳ）に最初の要求を送信するかを決断することを担当する。（１：３ｇｐｐ  ＴＳ  ２３．２３７において規定されたものなどのＳＣＣアプリケーション・サーバ。）
【００２２】
この（ＵＥへの着信サービス配信の責任を負う）ネットワーク・エンティティは、ＵＥに着信サービスを配信するために連絡する候補サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのリストと共に、これらの候補サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのうちのどれが好ましいものであるかの表示とをＨＳＳ／ＨＬＲから得るために、ＨＳＳ／ＨＬＲを調べる。
【００２３】
本発明の実施形態は、これらの候補サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのうちのどれが好ましいものであるか、たとえば、ＵＥと無線連絡をとった最後のものであるかを、ＨＳＳ／ＨＬＲがどのようにして決定するのかに関する。
【００２４】
背景
ＳＭＳ用の既存の３ＧＰＰ機構
既存の３ＧＰＰネットワーク（ＧＳＭ、ＧＰＲＳ、ＵＭＴＳ、ＬＴＥ）において、ＳＭＳは、３ＧＰＰ  ＴＳ  ２３．０４０に明記されるものに準拠して、配信される。この仕様において、ＳＭＳ−ＧＭＳＣは、ＳＭ用ルーティング情報送信メッセージ（条項１２．１を参照）を送信することによってＨＬＲに問い合わせ、ＳＭＳデータが送信される必要のあるＣＮノード（複数可）のアドレスを含む情報を取り出す。ＳＭＳルータ・ノードが存在するとき、ＨＬＲは、同じ、ＳＭ用ルーティング情報送信プロシージャをＳＭＳルータに向けて使用し、ＳＭＳルータは、ＳＭＳ−ＧＭＳＣに応答を送信する。その結果は、ＭＳＣ、ＳＧＳＮ、ＭＳＣおよびＳＧＳＮの両方のアドレス、またはＳＭＳルータのアドレスを包含し得る。ＳＭＳ−ＧＭＳＣ（またはＳＭＳルータ）は、アドレスに表示されたＣＮノードにＳＭＳデータを送信するが、条項１０．１の図１５−ｇ）に表示されるように、交互にのみ送信し、すなわち、ＳＭＳ−ＧＭＳＣは、第１のＣＮノードからの配信報告を待ち、その後、必要であれば第２のＣＮノードにＳＭＳデータを送信することを決断する（第２の経路に向けたＳＭＳ転送は、下位条項８．１．１に記載されるように、第１の経路上における何らかのＭＡＰエラーの受信によってのみトリガされる）。
【００２５】
ＳＭＳデータが送信されるべき第１のＣＮノードは、ＳＭＳ−ＧＭＳＣ内またはＳＭＳルータ内で構成されており、この構成は、所与の時刻において最も効率の良いものではないことが考えられ、たとえば、ＵＥは、ＭＳＣ／ＶＬＲを介してのみ到達可能であり得るにも関わらず、その一方で、第１のＣＮノードとしてＳＧＳＮが構成されている。ＣＮノード（ＭＳＣ、ＳＧＳＮ、ＭＭＥ）間において構成された優先度の代わりに、たとえば、最初に連絡すべきＣＮノードのタイプ−または無線アクセス技術（ＧＳＭ、ＵＭＴＳ、ＬＴＥなど）およびドメイン（回線、パケット）−を動的な態様で）用いて、ＳＭ用ルーティング情報送信メッセージを高度化することが可能であろう。
【００２６】
音声呼用の既存の３ＧＰＰ機構
３ＧＰＰネットワークにおいて、ユーザがボイス・オーバーＩＭＳ（ＶｏＩＭＳ）に申し込んでいる場合、入信音声呼は、回線交換（ＣＳ）ドメインまたはパケット交換（ＰＳ）ドメインのいずれかを使用して、被呼側に向けてセット・アップされ得る（被呼端末が、ＣＳ音声およびＶｏＩＭＳの両方が可能であるとき、ＣＳドメインまたはＰＳドメインのいずれを介して端末を呼び出すのかという決断は、３ＧＰＰ標準（ＴＳ  ２３．２２１、ＴＳ２３．２９２を参照）において、ＳＣＣ  ＡＳが、音声通話をセット・アップするために試行する最初のドメインについての表示をＨＳＳ／ＨＬＲに要求することによって、実施される。このことは、動的であるが、その理由は、ＴＳ  ２９．２７２に明記されているように、ＳＣＣ  ＡＳからの要求に際し、ＨＳＳ／ＨＬＲが、申込者データ挿入（Ｉｎｓｅｒｔ  Ｓｕｂｓｃｒｉｂｅｒ  Ｄａｔａ）プロシージャを介してＭＭＥおよび／またはＳＧＳＮに対し、ＵＥとの最後の無線連絡の最後の無線アクセス技術のタイプ（ＧＥＲＡＮ、ＵＴＲＡＮ、ＥＵＴＲＡＮなど）およびタイム・スタンプを提供するように要求するためである。
【００２７】
これらの候補サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのうちのどれが好ましいものであるかを決定するために、ＨＳＳ／ＨＬＲが現時点で使用し得る、考えられる機構
ＨＳＳ／ＨＬＲは、これらの候補サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのうちのどれが、ＵＥと無線連絡をとった最後のものであるかを決定するために、以下の機構を現時点で使用し得る。
【００２８】
プル：ＳＭＳルータ、ＳＣＣ  ＡＳ、または任意のアプリケーションからの要求に際し、ＨＳＳ／ＨＬＲは、端末に応対するＣＮノード（たとえばＳＧＳＮまたはＭＭＥ）に対し、《「ＩＭＳボイス・オーバーＰＳセッション」のサポート・ステータス、ＵＥとの最後の無線連絡のＲＡＴのタイプおよびタイム・スタンプ》などを返すように要求する。
プル機構は、それを介してＵＥが極めて高い確率で到達され得るＣＮノードを決定して、いかなる着信呼損をも回避するために、入信音声呼において使用される：ＳＭＳとは異なり、サービス配信の成功は、サービスを提供するために使用される遅延に関連する。
【００２９】
プッシュ／通知：ＵＥに応対するＣＮノード（ＭＳＣ／ＶＬＲ、ＳＧＳＮ、ＭＭＥ）は、ＵＥとの次の無線連絡が検出されたときに、ＨＳＳ／ＨＬＲにより、ＨＳＳ／ＨＬＲに通知するように要求されたことが考えられる。この通知機構は、ワン・ショットであり、すなわち、サービングＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮ）は、ＨＳＳ／ＨＬＲに通知すると、３ｇｐｐ  ＴＳ  ２９．２７２によって求められているように、ＨＳＳ／ＨＬＲの、通知への申し込みを消去する：
ＭＭＥが通知要求を送信して、ＵＥが再度到達可能になったことをＨＳＳ／ＨＬＲに知らせる場合、ＭＭＥは、ＵＥについての対応するＵＲＲＰ−ＭＭＥを消去するものとする。
ＳＧＳＮが通知要求を送信して、ＵＥが再度到達可能になったことをＨＳＳ／ＨＬＲに知らせる場合、ＳＧＳＮは、ＵＥについての対応するＵＲＲＰ−ＳＧＳＮを消去するものとする。
【００３０】
このことは、現行の仕様を用いた場合、ＨＳＳ／ＨＬＲは、通知を一旦受信すると、他の通知をさらに受信することを望む場合、申し込みを再度行わなければならないことを意味する。
【００３１】
「パッシブ」な方法：サービングＣＮノード、および／またはドメイン、および／またはＲＡＴのうちのどれが、ＵＥとの無線連絡をとった最後のものであるかを決定するために、ＨＳＳ／ＨＬＲは、そのクライアントのうちの１つの要求に際して情報をプルすることも、ＵＥとの無線連絡についてサービング・ノードからの通知を申し込むことも行わない。この方法は、現時点で、申し込みデータ、またはＵＥに応対するＣＮノード（たとえばＭＭＥおよび／もしくはＳＧＳＮ）から受信された最後の更新位置の時刻にのみ依拠し得る。
【００３２】
現行の機構は、（どのサービングＣＮノードがＵＥに応対した最後のものであり、したがって、着信サービス配信にとって好ましいものであるかについての知識をＨＳＳ／ＨＬＲがリアル・タイムで有するために、）ＵＥがどこに存在するかについての最新のビューをＨＳＳ／ＨＬＲが保持する目的のためには、使用され得ない。
【００３３】
発明者らによって認識される、上述の機構についての課題
これらの２つの機構（プッシュ／プル）は、ユーザのモビリティと、そのトラフィック混在とに依存して、コア・ネットワーク内で異なるシグナリング負荷を誘発する。たとえば、無線接続された販売機は全く移動しないが、一方で、車内のデバイスは、使用されるとすぐに移動し、すなわち、或る端末は、１カ月当たりに極めて少ない数の着信サービス（たとえばＳＭＳ）を受信するに過ぎないことが考えられ、一方で、或る端末は、１日に多くの着信サービス（たとえば呼）を受信することが考えられる。その帰結は以下の通りである：
−  端末が移動しないか、または限定されたモビリティで移動する場合、端末が移動したときにＨＳＳ／ＨＬＲに通知することは、この端末に対する着信サービスが存在する度ごとにサービングＣＮノードをプルすることよりも、シグナリング消費（ｓｉｇｎａｌｉｎｇ  ｃｏｎｓｕｍｉｎｇ）が少ない。
−  たとえば不良なカバレージのために、端末がＥ−ＵＴＲＡＮとＧＳＭ／ＧＰＲＳとの間を頻繁に移動する（したがって、サービングＣＮノードおよび／またはドメインを変更する）場合、ならびに、この端末が着信サービスをそれほど頻繁には受信しない場合、サービングＣＮノードをプルすることは、ＵＥがサービングＣＮノード／ドメインを変更する度ごとにＨＳＳ／ＨＬＲに通知することよりも、シグナリング消費が少ない。
−  端末が着信サービス（たとえばＳＭＳまたは音声／ビデオ呼）を極めて頻繁に受信するものの、それほど移動しない場合、プル・モードが最良の解決手段ではないことが考えられる。
【００３４】
ＴＳ  ２３．２９２、ＴＳ  ２９．２７２、ＴＳ  ２９．３２８において明記された、モバイル着信音声／ビデオ呼に対する既存の解決手段は、ＨＳＳ／ＨＬＲがプル解決手段を使用すること、すなわち、ＳＧＳＮまたはＭＭＥから上述の情報を取り出すことを義務付けている。モバイル着信ＳＭＳ配信に対する既存の解決手段は、ＳＭＳ−ＧＭＳＣまたはＳＭＳルータにおいて構成された優先順位を常に使用することである。
【００３５】
どのＣＮノードまたは／およびドメイン（ＣＳ、ＰＳ、ＩＭＳ）に対し、最初の要求が送信されるかを決定するために、３ＧＰＰ標準は、以下のものを考慮しない：
ＨＳＳ／ＨＬＲにおいて構成された、モビリティ・プロファイル（たとえば固定端末、移動端末）、および（たとえば音声／ビデオ、ＳＭＳ、デバイス・トリガリング、ＬＣＳ、その他などのサービスの各タイプについての）端末のトラフィック混在プロファイル、または
ＵＥおよび／もしくはネットワークの能力（ＵＥの、およびＶＰＬＭＮのキャンピング戦略）、または
実際のサービス使用の観察から導出された情報。このことは、ネットワークにおける重大なシグナリング負荷を招き得る。
【００３６】
特に「パッシブ」なモードにおいて、ＨＳＳ／ＨＬＲは、ユーザ申し込みデータと、サービング・ノードから受信された最後の更新位置とにのみ依拠し得るが、ＵＥ能力および無線（またはＶＰＬＭＮ）のキャンピング・ポリシーを考慮し得ない。
【００３７】
本発明の実施形態
本発明の諸実施形態は、種々の態様を含む。
【００３８】
第１の態様において、サービングＣＮノード（たとえばＭＭＥまたはＳＧＳＮ）は、サービングＣＮノードによってＨＳＳ／ＨＬＲに送信される、ＵＥについてのＲＡＴごとのキャンピング確率の表示に存する、「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての表示を、ＨＳＳ／ＨＬＲに提供する。
【００３９】
別の態様において、ＵＥについてのＲＡＴごとのキャンピング確率の表示の特定は、実際に、ＲＡＮによって行われ、可能性として以下のものを考慮する：
ＵＥのサービング・ノード（たとえばＭＭＥおよび／またはＳＧＳＮ）によってＲＡＮに送信された、ＲＡＴ／周波数優先度についての申込者プロファイルＩＤ（ＳＰＩＤ）パラメータ。ＳＰＩＤは、ＵＥに具体的なキャンピング・ポリシーを構成する（たとえばＲＲＣ＿ＩＤＬＥモード優先度を規定する）ために、およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにおけるＲＡＴ間／周波数間ハンドオーバーを制御するために、ＲＡＮによって使用される。ＳＰＩＤは、ＧＥＲＡＮについてはＴＳ  ４８．０１８、ＵＴＲＡＮについてはＴＳ  ２５．４１３、ＥＵＴＲＡＮについてはＴＳ  ３６．４１３において規定されている。
ＵＥ無線能力
ＲＡＮ上の構内構成、たとえば、エリア内における様々なＲＡＴの配備の特質
【００４０】
別の態様において、ＨＳＳ／ＨＬＲは、どのサービングＣＮノードがＵＥと最後の無線連絡を（および可能性としてどのＲＡＴ上で）とったかに気付かされるために使用される（プッシュ、またはプル、または「パッシブ」な）方法を動的に選択する。
【００４１】
別の態様において、ＨＳＳ／ＨＬＲの決断（どのサービングＣＮノードがＵＥと最後の無線連絡を（および可能性としてどのＲＡＴ上で）とったかに気付かされるためのプル、またはプッシュ、または「パッシブ」な方法）は、以下のものを考慮し得る：
ＨＳＳ／ＨＬＲにおいて構成されたユーザ申し込み情報
「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての、サービングＣＮノードからの表示
ＵＥに応対するＣＮノードが、高度化されたプッシュ方法をＣＮノードがサポートしていることを表示したかどうか
（ＶＰＬＭＮ内に配備されており、ＵＥによってサポートされている場合に、）ＩＳＲがＵＥに適用され得るかどうかについての、サービングＣＮノードからの表示
ＨＳＳ／ＨＬＲの、ＵＥ挙動の観察から導出された、ＵＥの、観察されたモビリティ＆入信トラフィック・プロファイル（たとえば、ＵＥについてのモビリティ・イベントの数および／または着信サービス要求の数との間の比率）
【００４２】
別の態様では、ＨＳＳ／ＨＬＲにおいて構成されたユーザ申し込み情報の一部として、既存の「ＲＦＳＰインデックス」が使用され、これは、申込者がたとえば移動端末、販売機などであるかどうかを構成するために使用される、ＨＳＳ／ＨＬＲにおける申し込みプロファイルの一部である。「ＲＦＳＰインデックス」は、ＴＳ  ２３．４０１およびＴＳ  ２３．０６０において規定されており、ＴＳ  ２３．００８においては、「申し込まれたＲＡＴ周波数選択優先度ＩＤ（Ｓｕｂｓｃｒｉｂｅｄ−ＲＡＴ−Ｆｒｅｑｕｅｎｃｙ−Ｓｅｌｅｃｔｉｏｎ−Ｐｒｉｏｒｉｔｙ−ＩＤ）」とも命名されている。
【００４３】
別の態様において、ＨＳＳ／ＨＬＲは、ＵＥとの無線連絡の永続的な通知（高度化されたプッシュ方法）を求めて、ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮおよび／またはＭＳＣ／ＶＬＲ）に対して通知を申し込むことが可能である。
（すなわち、ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮおよび／またはＭＳＣ／ＶＬＲ）からの最初の通知後に除去されない通知への申し込み）。
この通知への申し込みは、関連付けられた通知のフローをＨＳＳ／ＨＬＲが制限することを助ける、トリガ条件に関連付けられ得る。
【００４４】
これらの種々の態様は、特に、最初の試行においてＵＥに到達する見込みを最大化しながらも、シグナリング負荷を最小化することを可能にする。
【００４５】
機能エンティティ間の情報交換の観点において、本発明の実施形態は、以下のものを追加する。
【００４６】
ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮおよび／またはＭＳＣ／ＶＬＲ）が、ＨＳＳに対し、「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての情報を提供する能力
この情報は、Ｓ６ａ／Ｓ６ｄ位置更新要求（Ｕｐｄａｔｅ−Ｌｏｃａｔｉｏｎ−Ｒｅｑｕｅｓｔ、ＵＬＲ）によって搬送され得る。
この情報は、ＲＡＴごとのキャンピング確率（たとえば高、中程度、低）の形をとり得る。
【００４７】
ＲＡＮ２ノードが、ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮおよび／またはＭＳＣ／ＶＬＲ）に対し、「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての情報を提供する能力（２：無線アクセス・ネットワーク）
この情報は、Ｓ１（ＬＴＥ  ＲＡＮ）および／またはＩｕ（ＵＴＲＡＮ）および／またはＡ／Ｇｂ（ＧＥＲＡＮ）を通じて搬送される。
この情報は、ＲＡＴごとのキャンピング確率（たとえば高、中程度、低）の形をとり得る。
この情報は、以下のものに基づき、ＲＡＮによって特定される。
ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮ）によってＲＡＮに送信された、ＲＡＴ／周波数優先度についての申込者プロファイルＩＤ（ＳＰＩＤ）パラメータ。このインデックスは、ＵＥに具体的なキャンピング・ポリシーを構成するため（たとえばＲＲＣ＿ＩＤＬＥモード優先度を規定するため）、およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにおいてＲＡＴ間／周波数間ハンドオーバーを制御するために、ＲＡＮによって使用される。このインデックスは、ＧＥＲＡＮについてはＴＳ  ４８．０１８、ＵＴＲＡＮについてはＴＳ  ２５．４１３、ＥＵＴＲＡＮについてはＴＳ  ３６．４１３において規定されている。
ＵＥ無線能力
ＲＡＮ上の構内構成、たとえばエリア内における様々なＲＡＴの配備の特質
【００４８】
ＨＳＳが、ＵＥとの無線連絡の永続的な通知（プッシュ方法）か、または「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」の変更の永続的な通知を求めて、ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮおよび／またはＭＳＣ／ＶＬＲ）に対して通知を申し込む能力
この通知への申し込みは、関連付けられた通知のフローをＨＳＳ／ＨＬＲが制限することを助ける、トリガ条件に関連付けられ得る。それらのトリガ条件は、以下のものを含み得る。
ＵＥについて送信された２つの通知間の最小遅延
既に接続モードにあるＵＥについてのサービス・エリア更新は除外するが、ＵＥのアタッチまたはサービス・エリアの更新に際してのみ、ＵＥとの無線連絡の通知を受信する要求
ルーティング・エリアか、またはトラッキング・エリアの組に対応するサービス・エリア
申し込み要求は、Ｓ６ａ／Ｓ６ｄ位置更新回答（Ｕｐｄａｔｅ−Ｌｏｃａｔｉｏｎ−Ａｎｓｗｅｒ、ＵＬＡ）または申込者データ挿入要求（Ｉｎｓｅｒｔ−Ｓｕｂｓｃｒｉｂｅｒ−Ｄａｔａ−Ｒｅｑｕｅｓｔ）メッセージによって（可能性として、ＩＤＲフラグに加え、トリガ条件についての新たな情報要素を使用して）、搬送され得る。
関連付けられた通知は、Ｓ６ａ／Ｓ６ｄ通知要求（Ｎｏｔｉｆｙ−Ｒｅｑｕｅｓｔ、ＮＯＲ）によって搬送され得る。
【００４９】
サービングＣＮノードがデタッチに際してモバイルをパージし、したがって、サービングＣＮノードがＵＥをデタッチしたときにＨＳＳ／ＨＬＲに通知することを、ＨＳＳ／ＨＬＲが要求する能力
【００５０】
ＵＥに応対するＣＮノード（たとえばＭＭＥおよび／またはＳＧＳＮ）が、ＨＳＳに対し、ＣＮノードがＵＥとの無線連絡の永続的な通知（プッシュ方法）を通知することをサポートしているかどうかを表示する能力
これは、Ｓ６ａ／Ｓ６ｄ位置更新要求（ＵＬＲ）によって搬送されるべきである。
その目的のために、ＵＬＲフラグ内の新たな値（ＵＥに応対するＣＮノードが、複数のスロットリング条件のサポートを表示することが可能であるときには、２つ以上の値）が使用され得る。
【００５１】
Ｓ６ａ／Ｓ６ｄは、３ＧＰＰ  ＴＳ  ２９．２７２において規定されている。これらは、ＨＳＳと、それぞれＭＭＥおよびＳＧＳＮとの間のインターフェイスに対応する。
【００５２】
本発明の他の実施形態について、図２に例示される以下のステップにおいて説明する。
【００５３】
１．ユーザ申し込みが作成もしくは修正され、および／または１’ＨＳＳ／ＨＬＲには、ユーザが新たなサービングＣＮノード（そのノードから受信された更新位置）を経由して、今到達可能である旨が通知される。
更新位置は、「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての、サービングＣＮノードからの表示を包含し得る。
【００５４】
２．（１および／または１’に基づき）ＨＳＳ／ＨＬＲは、ＵＥと無線連絡をとった最後のサービングＣＮノード（可能性としてどのＲＡＴにおいてか）を決定するための動作モード（プッシュ／プル／「パッシブ」）を選択する。
この決定は、以下のものを考慮し得る。
たとえば以下のものについての表示を包含する、ＨＳＳ／ＨＬＲにおいて構成されたユーザ申し込み情報。
ＵＥ（たとえば固定端末、移動端末）の予測されるモビリティ。
これは、ＨＳＳ／ＨＬＲ内のユーザ申し込み情報の一部である、「ＲＦＳＰインデックス」内に格納され得る。
および／または
ＵＥの、予測されるサービス・セット、すなわち、（たとえば、音声／ビデオ、ＳＭＳ、位置特定、デバイス・トリガ、その他などのサービスの各タイプに関しての）ＵＥのトラフィック混在プロファイル（たとえば、ＰＣデータ・ドングルは、入信呼を受信することが想定されておらず、多くの入信ＳＭＳを受信することが想定されていない）
「ＵＥ能力および訪問先ネットワーク能力およびキャンピング・ポリシー」についての、ならびに、ＶｏＩＭＳサポート能力についての、サービングＣＮノードからの表示
ＵＥに応対するＣＮノードが、高度化されたプッシュ方法をＣＮノードがサポートしていることを表示したかどうか
（ＶＰＬＭＮに配備されており、ＵＥによってサポートされている場合、）ＩＳＲがＵＥに適用され得るかどうかについての、サービングＣＮノードからの表示
【００５５】
３．ＵＥおよびサービングＣＮノードに対して高度化されたプッシュ（または通知）の動作モードが選ばれたとき、ＨＳＳ／ＨＬＲは、このサービングＣＮノードに対し、ＵＥとの無線連絡の通知を申し込む。
この通知への申し込みは、関連付けられた通知のフローをＨＳＳ／ＨＬＲが制限することを助ける、トリガ条件に関連付けられ得る。
【００５６】
４．ＵＥに対して使用された動作モードは、ＨＳＳ／ＨＬＲの、ＵＥ挙動（ＵＥについてのモビリティ・イベントの数と着信サービス要求の数との間の比率）の観察に基づき、動的に変更され得る。
【００５７】
ＵＥに対して着信要求が存在するとき
５．ＨＳＳ／ＨＬＲは、（ＵＥへの着信サービス配信の責任を負うネットワーク・エンティティから）入信サービス配信用に、どの候補サービングＣＮノード、および／またはＲＡＴ、および／またはドメインを使用すべきか、ならびに、これらの候補ＣＮノードのうちのどれが好ましいもの（それを介することでＵＥに到達する最高の見込みが存在するようになるサービングＣＮノード）であるか、についての情報を得る要求を受信する。この要求は、以下のものに対応し得る。
着信サービスが入信ＳＭＳの配信である場合、ＳＭＳ−ＧＭＳＣ（もしくはＳＭＳルータ）からのＳＭ用ルーティング情報送信メッセージ、または
着信サービスが入信デバイス・トリガの配信である場合、デバイス・トリガ要求、または
着信サービスが入信呼の配信である場合、ＳＣＣ  ＡＳからのデータ・プル、
その他。
【００５８】
６．ＨＳＳ／ＨＬＲは、ＵＥに現時点で応対するＣＮノード（たとえばＭＭＥ、ＳＧＳＮ、ＭＳＣ／ＶＬＲ）のうちのどれが、入信要求（候補サービングＣＮノードのリスト）に応対し得るか、およびそれらの候補サービングＣＮノードについて、どれがＵＥと無線連絡したはずである最後のもの（このサービングＣＮノードは、それを経由して入信サービス要求をルーティングする、好ましいサービングＣＮノードである）であるのかを決定する。
そのことを行うために、ＨＳＳ／ＨＬＲは以下のものをチェックする。
ＨＳＳ／ＨＬＲ上に格納された、ＵＥが登録されている各候補ＣＮエンティティによって、ＵＥが検出された最後の時刻、および
ＵＥと無線連絡をとった最後のサービングＣＮノードを決定するための現在の動作モード（プッシュ／プル／「パッシブ」）。
現在の動作モードが「プル」である場合、またはＨＳＳ／ＨＬＲ上に格納された最後の時刻が入信要求のタイプにしてはあまりにも古いと考えられる場合、ＨＳＳ／ＨＬＲは、候補サービングＣＮノードから、最後の無線連絡についての情報をプルする。
さもなければ、ＨＳＳ／ＨＬＲは、サービングＣＮノードの、ＵＥとの最後の無線連絡についての、構内で格納された情報を考慮する。
【００５９】
７．ＨＳＳ／ＨＬＲは、そのクライアント（ＵＥへの着信サービス配信の責任を負うネットワーク・エンティティ）に対し、候補サービングＣＮノードのリストと、ＵＥと無線連絡をとったはずである最後のものの表示とを用いて回答する。
【００６０】
ＵＥと無線連絡をとった最後のサービングＣＮノード（可能性として、どのＲＡＴにおいてか）を決定するための動作モード（プッシュ／プル／「パッシブ」）についての選択肢の例（＊）
パッシブな方法は、たとえば、以下のときに選ばれ得る。
ＵＥに対する入信サービスが、稀であって、かつ遅延耐性であるとき、すなわち、或るサービングＣＮノードを介した試みが失敗したことと、後に続く、別のサービングＣＮノードを介した再試行とによって被る、何らかの遅延がもたらされ得るとき（たとえばＳＭＳ）。
または
ＵＥに応対するＣＮノードが、ＲＡＴを通じたキャンピング確率が高いことを表示し、ＵＥに対する入信サービスが遅延耐性であるとき。
高度化されたプッシュ方法は、たとえば、ＩＳＲがＵＥに適用され得ず、かつ高度化されたプッシュ方法がサービングＣＮノードによってサポートされており、かつ
申し込みが、モビリティが制限されているか、もしくはモビリティを有さないＵＥを表示するか、
または
ＨＳＳが、ＵＥについての入信サービスの数とモビリティ・イベントの数との間に高い比率を観察した
ときに、選ばれ得る。
（＊）これらの例は単なる例示である。
【００６１】
一態様において、マルチ無線アクセス技術ＲＡＴおよび／またはマルチ・ドメイン・モバイル・ネットワークを通じたモバイル着信サービス配信をサポートするための方法が提供され、ここでは、ユーザ機器ＵＥが複数のサービング・コア・ネットワークＣＮノードに登録され得る。
【００６２】
様々な組合せにより、単独で、または組み合わせて使用され得る様々な実施形態が提供される。
【００６３】
一実施形態において、前記方法は、前記ＵＥに向けたモバイル着信サービス配信の試みにとって好ましいサービングＣＮノードおよび／または好ましいドメインの表示を含む、着信選択情報と称される情報を使用し、前記好ましいサービングＣＮノードおよび／または前記好ましいドメインは、前記複数のサービングＣＮノードから取り出された、着信選択サポート情報と称される情報に基づき、現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインとして決定される。
【００６４】
一実施形態において、前記方法は、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定のために、ＵＥのＲＡＴごとのキャンピング確率についての情報を含む着信選択サポート情報を使用するステップ
を含む。
【００６５】
一実施形態において、前記方法は、
−  複数のサービングＣＮノードから着信選択サポート情報を取り出す複数のモードのうちの１つを動的に選択するステップ
を含む。
【００６６】
一実施形態において、前記方法は、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定のために、ならびに／あるいはサービングＣＮノードから着信選択サポート情報を取り出す複数のモードのうちの１つの動的選択のために、前記ＵＥについてのユーザ申し込みを使用するステップ
を含む。
【００６７】
一実施形態において、前記方法は、
−  １つのサービングＣＮノードに対して前記情報の変更の通知を申し込むことに基づき、１つのサービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである申し込みによって、複数のサービングＣＮノードから着信選択サポート情報を取り出すモードを高度化するステップ
を含む。
【００６８】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードが、現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースに対し、ＵＥのＲＡＴごとのキャンピング確率についての情報を含む着信選択サポート情報をシグナリングするステップ
を含む。
【００６９】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードが、現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースに対し、ＵＥ能力および／または訪問先ネットワーク能力および／または前記ＵＥについてのキャンピング・ポリシーについての情報を含む着信選択サポート情報をシグナリングするステップ
を含む。
【００７０】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードによって制御されるサービング無線アクセス・ネットワークＲＡＮノードが、前記サービングＣＮノードに対し、ＵＥのＲＡＴごとのキャンピング確率の表示をシグナリングするステップ
を含む。
【００７１】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードによって制御されるサービング無線アクセス・ネットワークＲＡＮノードが、
前記サービングＣＮノードによって前記ＲＡＮノードに送信された、ＲＡＴ／周波数優先度についての申込者プロファイルＩＤ  ＳＰＩＤパラメータ、
ＵＥ無線能力、
ＲＡＮ上の構内構成、
のうちの少なくとも１つを含む情報から、ＵＥのＲＡＴごとのキャンピング確率の表示を特定するステップ
を含む。
【００７２】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードが、モバイル・ネットワーク申込者データベースに対し、ＵＥのＲＡＴごとのキャンピング確率についての情報を包含する位置更新要求を送信するステップ
を含む。
【００７３】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、
前記ＵＥについてモバイル・ネットワーク申込者データベースにおいて構成された申し込み情報、
ＵＥのＲＡＴごとのキャンピング確率についての、サービングＣＮノードからの表示、
複数のサービングＣＮノードが、前記複数のサービングＣＮノードに対する前記情報の変更の通知への申し込みに基づき、前記複数のサービングＣＮノードから着信選択サポート情報を取り出すモードを前記サービングＣＮノードがサポートしていることを表示したかどうかであって、通知への申し込みが、サービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである、
アイドル・モード・シグナリング削減ＩＳＲが、訪問先ネットワークにおいて配備されており、かつＵＥによってサポートされているかどうかについての、複数のサービングＣＮノードからの表示、
申込者データベースによるＵＥ挙動の観察から導出された、ＵＥの、観察されたモビリティおよび入信トラフィック・プロファイル、
のうちの少なくとも１つに基づき、サービングＣＮノードから着信選択サポート情報を取り出す複数のモードのうちの１つを動的に選択するステップ
を含む。
【００７４】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、
申込者データベースが複数のサービングＣＮノードから情報をプルする、プルに基づくモード、
モバイル・ネットワーク申込者データベースからの要求の後に、複数のサービングＣＮノードが情報変更に際して、申込者データベースに通知する、プッシュに基づくモード、
ＵＥ申し込み情報に、および／または複数のサービングＣＮノードから受信された最後の位置更新要求の時刻に依拠する、パッシブなモード、
を含む複数のモードのうちの１つを動的に選択するステップ
を含む。
【００７５】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、前記ＵＥについて前記モバイル・ネットワーク申込者データベースにおいて構成された申し込み情報であって、前記申し込み情報が、ＲＡＴ／周波数選択優先度ＲＦＳＰインデックス・パラメータを含む、申し込み情報に基づき、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、複数のモードのうちの１つを動的に選択するステップ
を含む。
【００７６】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、１つのサービング・ノードに対して前記情報の変更の通知を申し込むことに基づき、モードを選択するステップであって、通知への申し込みが、１つのサービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである、モードを選択するステップ
を含む。
【００７７】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、サービングＣＮノードに対してＵＥのＲＡＴごとのキャンピング確率の変更の通知を申し込むステップ、またはサービングＣＮノードに対してＵＥとの無線連絡の通知を申し込むステップ
を含む。
【００７８】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、サービングＣＮノードに対し、ＵＥのデタッチに際してこのＵＥをパージするように、したがって、サービングＣＮノードがＵＥをデタッチしたときに、モバイル・ネットワーク申込者データベースに通知するように、求めるステップ
を含む。
【００７９】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、１つのサービングＣＮノードに対して前記情報の変更の通知を申し込むことに基づき、モードを選択するステップであって、アイドル・モード・シグナリング削減ＩＳＲがＵＥに適用され得ず、かつ前記モードがサービングＣＮノードによってサポートされており、かつ
ＵＥ申し込み情報が、モビリティが制限されているか、もしくはモビリティを有さないＵＥを表示するか、
または
申込者データベースが、ＵＥについての入信サービスの数とモビリティ・イベントの数との間に高い比率を観察した
場合に、通知への申し込みが、１つのサービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである、モードを選択するステップ
を含む。
【００８０】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、１つのサービングＣＮノードに対して前記サービングＣＮノードによる前記情報の変更の通知を申し込むことに基づき、モードを選択するステップであって、通知への申し込みが、
ＵＥについて送信された２つの通知間の最小遅延、
既に接続モードにあるＵＥについてのサービス・エリア更新は除外するが、ＵＥのアタッチまたはサービス・エリアの更新に際してのみ、ＵＥとの無線連絡の通知を受信する要求であって、サービス・エリアが、ルーティング・エリアか、またはトラッキング・エリアの組に対応する、要求、
のうちの少なくとも１つを含むトリガ条件に従って、サービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである、モードを選択するステップ
を含む。
【００８１】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  サービングＣＮノードが、現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースに対し、ネットワーク申込者データベースが１つのサービングＣＮノードに対して前記情報の変更の通知を申し込むことに基づき、前記サービングＣＮノードが複数のサービングＣＮノードから着信選択サポート情報を取り出すモードをサポートしているかどうかを表示するステップであって、通知への申し込みが、1つのサービングＣＮノードからの最初の通知の後に、このサービングＣＮノードにおいてアクティブなままである、前記サービングＣＮノードが複数のサービングＣＮノードから着信選択サポート情報を取り出すモードをサポートしているかどうかを表示するステップ
を含む。
【００８２】
一実施形態において、前記方法は、以下のステップ、すなわち、
−  現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインの前記決定の責任を負うモバイル・ネットワーク申込者データベースが、複数のサービングＣＮノードから着信選択サポート情報を取り出すために、
ＵＥに対するモバイル着信サービスが、稀であって、かつ遅延耐性であるとき、または
サービングＣＮノードが、ＲＡＴを通じたキャンピング確率が高いことを表示し、ＵＥに対するモバイル着信サービスが遅延耐性であるとき
に、ユーザ申し込み情報に、および／または1つのサービングＣＮノードから受信された最後の位置更新要求の時刻に依拠する、パッシブなモードを選択するステップ
を含む。
【００８３】
一実施形態において、前記方法は、以下のステップ、すなわち、モバイル・ネットワーク申込者データベースによる、ＵＥに対するモバイル着信サービス配信用の着信選択情報を得る要求の受信の際に、
−  モバイル・ネットワーク申込者データベースが、
モバイル・ネットワーク申込者データベースに格納された、複数のサービングＣＮノードによってＵＥが検出された最後の時刻、
現時点で最も高い確率でＵＥに到達することの可能なサービングＣＮノードおよび／またはドメインを決定するために、前記モバイル・ネットワーク申込者データベースによって選択された現在のモード、
をチェックするステップと、
−  現在のモードが、申込者データベースが複数のサービングＣＮノードから情報をプルする、プルに基づくモードである場合、または申込者データベースに格納された最後の時刻が、モバイル着信サービスにしてはあまりにも古いと考えられる場合に、申込者データベースが複数のサービングＣＮノードから情報をプルするステップと、
−  さもなければ、申込者データベースが、申込者データベースに格納された最後の時刻についての、構内で格納された情報を考慮するステップと
を含む。
【００８４】
他の態様および実施形態は、このような方法および／またはこのような方法の個々のステップ（複数可）を実施するために構成されたモバイル・ネットワーク・エンティティであって、前記エンティティが、特に（ただし、限定するものではないが）、モバイル・ネットワーク・データベース（たとえばＨＬＲ／ＨＳＳなど）、およびモバイル・ネットワーク・ノード（たとえばＭＭＥ、ＳＧＳＮ、その他など）を含む、モバイル・ネットワーク・エンティティに関する。
【００８５】
当業者は、様々な上記の方法のステップが、プログラミングされたコンピュータによって実施され得ることを容易に認識するであろう。本明細書において、いくつかの実施形態は、機械またはコンピュータ可読であって、かつ命令の、機械実行可能またはコンピュータ実行可能なプログラムを符号化する、プログラム記憶デバイス、たとえば、デジタル・データ記憶媒体であって、前記命令が、前記上記の方法のステップのいくつかまたは全てを実施する、プログラム記憶デバイスを内包することも意図される。プログラム記憶デバイスは、たとえば、デジタル・メモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハード・ドライブ、または光学的に可読なデジタル・データ記憶媒体であり得る。実施形態は、上記の方法の前記ステップを実施するようにプログラミングされたコンピュータを内包することも意図される。
【図１】
0006008987.tif 000002
【図２】
0006008987.tif 000003