ＩＰベース・マルチメディア・セッションのベアラ損失の検出
本発明は、ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法を提供する。マルチメディア・セッションが、アクセス端末によって開始される。ポリシー課金規則機能（ＰＣＲＦ）が、セッション設定情報およびベアラ特性をシグナリング・ゲートウェイ（ＳＧＷ）に伝える。ＳＧＷは、この情報を使用して、呼設定の間、発信元アクセス・リンクがアクティブのままになるように発信側の休止タイマを調整する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、通信システムに関し、より詳細には、ベアラ損失検出に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネット・プロトコル）を用いたマルチメディア・サービスは、サービス・プロバイダにとって極めて重要なサービスであり、サービス・プロバイダは、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ボイス・オーバー・インターネット・プロトコル）を、このリアルタイム・サービスを使用するための第１の主要アプリケーションと見なしている。ＶｏＩＰは、主にＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＰマルチメディア・サブシステム）コア・ネットワークおよび様々なアクセス・ネットワークを使用して構築され、これらのネットワークは、ケーブル、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ：デジタル加入者回線）、ファイバなどの広帯域接続を、またＤＯＲＡ、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ：マイクロ波アクセス世界規模相互運用性）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ロング・ターム・エボリューション）などの様々な無線アクセス・ネットワークをも含む。
【０００３】
通信システム内の音声サービスは、不可欠なサービスである。したがって、音声サービスのすべての側面が、非常にうまく働かなければならない。１つの関心領域は、ベアラ損失検出の領域である。呼の間のベアラ損失の検出は、シグナリングとベアラ・レベルの両方の多くのネットワーク要素に、接続が失われたことを検出するよう求めるので、これは些細なプロセスではない。
【０００４】
これは一般に、こうしたネットワークの設計が本質的にシグナリングとベアラのネットワーク要素を適度に分離するという事実によってさらに複雑になる。この分離によって、検出および検出の伝達がさらに一層複雑になる。ベアラ損失または接続損失は、ＭＧＷ（Ｍｅｄｉａ ＧａｔｅＷａｙ：メディア・ゲートウェイ）またはＭＲＦ（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ：メディア・リソース機能）などのコア・ネットワーク要素内で生じていることがある。ベアラ損失または接続損失は、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）、ＧＷ、さらにはアクセス端末としても知られているモバイル装置などのアクセス・ネットワーク要素自体で生じていることもある。
【０００５】
遭遇する第１の問題は、通信システムがコア・ネットワーク内のベアラ損失をどのように検出できるかということである。
【０００６】
遭遇する第２の問題は、通信システムがアクセス・ネットワーク内のベアラ損失をどのように検出できるかということである。
【０００７】
遭遇する第３の問題は、様々な無線アクセス・ネットワークについて、被呼側に到達し／被呼側が警告を受け、最終的に応答する間、セッションの発信側がパケット・アクセス・チャネルで休止状態に入り得ることである。これは、発信元のアクセス接続上にパケット・データ活動がないために発生する。この問題は、音声クリッピングおよび呼設定遅延を引き起こすことがある。
【０００８】
ベアラ損失を検出する助けとするために使用できる１つの既存の機構は、ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：リアルタイム・トランスポート制御プロトコル）を使用することである。ＲＴＣＰは、主としてネットワーク性能およびベアラ接続の他の様々な側面を決定するように設計されるが、接続損失もまた、ＲＴＣＰパケットから収集できる。この種類のプロトコルは、主としてエンドツーエンド・プロトコルであり、終端装置（モバイル装置など）がその問題を有するものである場合には、このプロトコルはあまり有効でないことに留意されたい。さらに、ＲＴＣＰの有効利用に付随する帯域幅コストのせいで、このプロトコルは一般に、サポートまたは使用されない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、通信システム内でベアラ損失がいつ存在するか決定するやり方が求められている。さらに、この決定は、真のベアラ損失と、呼の当事者のうちの１つからのパケット・データ活動が正当な理由で（ｌｅｇｉｔｉｍａｔｅ）欠如していることとを区別する必要がある。
【課題を解決するための手段】
【００１０】
本発明は、ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法を提供する。セッションがアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）と別のユーザＢの間のＶｏＩＰ呼として設定される場合、このセッションは、トラフィックが両方向に流れると期待される双方向セッションである。セッション設定のプロセスの間に、セッションのシグナリングに関与するネットワーク要素は、セッションを確立する。すなわち、ＩＭＳコアに関連するＡＴは、ＶｏＩＰセッションを確立する。ＶｏＩＰセッション確立の一貫として、ＩＭＳコアおよびＡＴは、セッションのメディア・タイプ、したがって帯域幅をネゴシエートし、またベアラ・エンティティのＩＰアドレスおよびポートなどの接続点をもネゴシエートする。このネゴシエートされたメディア情報は、コーデック情報と呼ばれる。
【００１１】
このセッションのコーデックもネゴシエートされ、それによってＳＧＷなどのアクセス・ネットワーク内のベアラ・ノードに、いくらの１秒当たりパケット数が期待されるか伝えることができる。たとえば、ポリシー課金規則機能（ＰＣＲＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）は、ＳＧＷに、セッションの送信元および宛先ＩＰアドレスを、またコーデックが拡張可変レートＣＯＤＥＣ（ＥＶＲＣ：Ｅｎｈａｎｃｅｄ Ｖａｒｉａｂｌｅ Ｒａｔｅ ＣＯＤＥＣ）であり、ペイロード・タイプ＃が９６であり、パケットの期待レートが５０パケット／秒であることをも伝えることができる。ＳＧＷは、この情報を使用して、各方向のトラフィックの流れを評価することができる。
【００１２】
ＩＭＳコアは、ポリシー実施およびゲート制御のためにＰＣＲＦにコーデック情報を通信する。次に、ＰＣＲＦは、シグナリング・ゲートウェイ（ＳＧＷ：Ｓｉｇｎａｌｉｎｇ Ｇａｔｅｗａｙ）およびパケット・データ網ゲートウェイ（ＰＧＷ：Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）にこのコーデック情報を送る。コーデック情報は、接続情報と、コア・ネットワークに対するトラフィック・フローの方向を含む。
【００１３】
この時点で、ＳＧＷは、コア・ネットワーク側からは何を期待すべきか、またアクセス・ネットワーク側からは何を期待すべきか分かる。ＳＧＷは、この時点でトラフィック・フローを監視し、トラフィック・フローに矛盾点があるかどうか判断し、この矛盾点をＰＣＲＦに報告することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の例示的な一実施形態による、ＩＭＳシステムを示す図である。
【図２】本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れを示す図である。
【発明を実施するための形態】
【００１５】
本発明は、図１および図２を参照してよりよく理解することができる。図１は、本発明の例示的な一実施形態による無線ＩＭＳシステム１００を示している。無線ＩＭＳシステム１００は、アクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）１０１と、基地局（ＢＴＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）１０３と、無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）１０５と、サービング・ゲートウェイ（ＳＧＷ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）１０７と、パケット・ゲートウェイ（ＰＧＷ：Ｐａｃｋｅｔ Ｇａｔｅｗａｙ）１０９と、ポリシー制御レポジトリ機能（ＰＣＲＦ：Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ）１１１と、ＩＭＳコア１１３と、ＩＰネットワーク１１５と、メディア・ゲートウェイ制御機能（ＭＧＣＦ：Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）１１７と、メディア・ゲートウェイ（ＭＧＷ：Ｍｅｄｉａ Ｇａｔｅｗａｙ）１１９とを備える。
【００１６】
ＡＴ １０１は、このシナリオでは、ＶｏＩＰ対応モバイル装置である。
【００１７】
基地局（ＢＴＳ）１０３は、エアー信号を介してＡＴ １０１と送受信する。
【００１８】
無線ネットワーク制御装置（ＲＮＣ）１０５は、ＢＴＳ １０３を制御し、ＳＧＷ １０７に接続する。
【００１９】
ＳＧＷ １０７は、ＰＧＷ １０９を介してアクセス・ネットワークとコア・ネットワークからの接続をブリッジするネットワーク要素である。ポリシー実施は、ＳＧＷ １０７内で行うことができ、ＳＧＷ １０７は、ＰＣＲＦ １１１に対して接続される。
【００２０】
ＰＧＷ １０９は好ましくは、ＩＰコア・ネットワーク１１５に接続するように、ＳＧＷ １０７と連携して働く。ポリシー実施は、ＰＧＷ １０９内で行うことができ、ＰＣＲＦ １１１に信号が送られる。
【００２１】
ＰＣＲＦ １１１は、ネットワーク１００内の主要のポリシー・エンジンである。ＰＣＲＦ １１１は、好ましくはシグナリング専用の要素である。例示的な実施形態では、ＰＣＲＦ １１１を通過するベアラはない。
【００２２】
ＩＭＳコア１１３は、アプリケーション・コアであり、好ましくはＰ−ＣＳＣＦとＳ−ＣＳＣＦとを含む。ＩＭＳコア１１３は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＩＭＳコア１１３を通過するベアラはない。
【００２３】
ＩＰネットワーク１１５は、パケット交換網である。
【００２４】
ＭＧＣＦ １１７は、ＭＧＷ １１９を制御する。ＭＧＣＦ １１７は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＭＧＣＦ １１７を通過するベアラはない。
【００２５】
ＭＧＷ １１９は、ＩＰベアラをＴＤＭベアラに接続する。
【００２６】
図２は、本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れ２００を示している。ＡＴ １０１がＰ−ＣＳＣＦにＩｎｖｉｔｅメッセージ２０１を送るとき、マルチメディア・セッションがＡＴ １０１によって開始される。Ｉｎｖｉｔｅメッセージ２０１は好ましくは、接続アドレス、コーデック情報、トラフィック方向などを含む様々なメディア特性を含む。例示的な一実施形態では、Ｉｎｖｉｔｅメッセージ２０１は、送信者情報、受信者情報、ＳＤＰ情報、ポート、およびトラフィックの流れが送信方向か、受信方向か、それとも両方向かを含む。
【００２７】
Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１を受け取り、このメッセージをＩｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０２としてＰＣＲＦ １１１に転送する。Ｉｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０２は好ましくは、近接エンドポイント情報と、アプリケーション・タイプとトラフィック方向とを含む。例示的な一実施形態では、ＰＣＲＦ １１１は、ポリシーを確立し、ＳＧＷ １０７にこの情報を伝える。
【００２８】
ＰＣＲＦ １１１は、Ｉｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０３を送ることによってＳＧＷ １０７にＳｅｓｓｉｏｎ ｓｅｔｕｐ情報およびベアラ特性を伝える。ＳＧＷ １０７は好ましくは、この情報を使用して、呼設定の間、発信元アクセス・リンクがアクティブのままになるように発信側の休止タイマを調整する。
【００２９】
呼設定の間、ＩＭＳコア１１３および／またはＰＣＲＦ １１１は、ＳＧＷ １０７にセッションの状態を伝えることができる。発信側のケースでは、ＰＣＲＦ １１１は、セッション確立が試みられていることを発信元ＳＧＷ １０７に伝えることができる。これは、ＳＧＷ １０７が発信側の休止タイマを無視しまたは延長し、それによってクリッピングおよび他のエンドユーザ問題を回避するように促す。アクセス・ネットワーク接続に関して決定を知的に行うこの能力は、被呼者に到達し／被呼側が警告を受け、被呼者が最終的に応答する間、セッションの発信側がパケット・データ活動の欠如を誤って休眠状態と認識することによる音声クリッピングおよび呼設定遅延の問題を解決する。これは、発信元アクセス接続上にパケット・データ活動がないために生じる。
【００３０】
Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１をＩｎｖｉｔｅメッセージ２０４としてＳ−ＣＳＣＦに渡す。
【００３１】
Ｓ−ＣＳＣＦは、ＥＮＵＭまたはＤＮＳルックアップによってこの呼のための経路を決定し、ＰＳＴＮ内への送達のためにこの呼をＩｎｖｉｔｅメッセージ２０５によってＭＧＣＦ １１７に送る。
【００３２】
Ｉｎｖｉｔｅメッセージ２０５を受け取ると、ＭＧＣＦ １１７は、Ｇｅｔ Ｂｅａｒｅｒ Ａｄｄｒｅｓｓメッセージ２０６をＭＧＷ １１９に送る。ＭＧＷ １１７は、この呼のためのベアラ接続を設定し、ＭＧＣＦ １１７にベアラ・アドレスを返す。
【００３３】
ＭＧＣＦ １１７は、ＭＧＷ １１９からベアラ・アドレスを受け取り、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７によってこのメディア情報をＳ−ＣＳＣＦに渡す。
【００３４】
Ｓ−ＣＳＣＦは、ＭＧＣＦ １１７からＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７を受け取る。Ｓ−ＣＳＣＦは、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７からのメディア情報をＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０８によってＰ−ＣＳＣＦに渡す。
【００３５】
Ｐ−ＣＳＣＦは、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０８を受け取り、Ｉｎｄｉｃａｔｅメッセージ２０９によってこの情報をＰＣＲＦ １１１に送る。ＰＣＲＦ １１１は好ましくは、ポリシーを確立し、この情報をＳＧＷ １０７に伝える。
【００３６】
ＰＣＲＦ １１１は、セッション設定情報およびベアラ特性をＩｎｄｉｃａｔｅメッセージ２１０によってＳＧＷ １０７に伝える。ＳＧＷ １０７は好ましくは、この情報を使用して、発信側のベアラ損失タイマを調整する。ＳＧＷ １０７は、この時点でＭＧＷ １１９を介してコア・ネットワークからの期待トラフィック特性を知っているので、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間（ベアラ損失タイマ）の間にこのトラフィック・パターンから逸脱すると、ＳＧＷ １０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。
【００３７】
ＳＧＷ １０７は、特定の時間量の間、コア・ネットワークからアクセス側に流れるパケットがなかったことを検出する場合、ベアラ損失の問題があり得ることについてＰＣＲＦ １１１に警告するメッセージをＰＣＲＦ １１１に送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめ、またはユーザにこの問題について警告することによって、これに従って行動することができる。これによって、コア・ネットワーク内のベアラ損失の検出が可能となる。
【００３８】
Ｐ−ＣＳＣＦは、ＭＧＷ １１９からのメディア情報をＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２１１によってＡＴ １０１に渡す。
【００３９】
被呼側が呼に応答するとき、ＭＧＣＦ １１７は、ＯＫメッセージ２１２をＳ−ＣＳＣＦに送る。
【００４０】
Ｓ−ＣＳＣＦは、被呼側が呼要求に応答することを示すＯＫメッセージ２１３をＰ−ＣＳＣＦに送る。
【００４１】
Ｐ−ＣＳＣＦは、この情報をＩｎｄｉｃａｔｅメッセージ２１４によってＰＣＲＦ １１１に送る。Ｉｎｄｉｃａｔｅメッセージ２１４は好ましくは、遠端ポート情報、ならびにトラフィック方向および特性を含む。ＰＣＲＦは好ましくは、ポリシーを確立し、この情報をＳＧＷ １０７に伝える。
【００４２】
ＰＣＲＦ １１１は、メディア特性のどんな変更をもＩｎｄｉｃａｔｅメッセージ２１５によってＳＧＷ １０７に送ることができる。その時点以降、ＳＧＷ １０７は、ＭＧＷ １１９からの、またアクセス・ネットワークからの期待されるトラフィック特性がここでは分かっており、ＳＧＷ １０７は、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間、たとえばベアラ損失タイマの間にこのトラフィック・パターンから逸脱すると、ＳＧＷ １０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。
【００４３】
この知識を得てＳＧＷ１０７が、所定の時間量の間、アクセス側から流れるパケットがなかったことを検出し、またはアクセス側が休止状態に入ったことを検出するとき、ＳＧＷ１０７は、ＰＣＲＦ １１１に、ベアラ損失があり得ることについてそれに警告するメッセージを送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめることによって、またはこの問題についてユーザに警告することによって、これに従って行動することができる。アクセス側では、セッション中にＡＴ １０１のバッテリが抜き取られる場合、またはＡＴ １０１がＲＦホールに入る場合、アクセス側は、接続を休眠状態にし、他には何も行われないことに留意されたい。このシナリオでは、ＳＧＷ １０７は、現在の振舞いと期待された振舞いとの矛盾点を認識し、シグナリング・エンティティに処置を講ずるように知らせる。これによって、通信システムは、アクセス・ネットワーク内のベアラ損失を検出することができる。
【００４４】
Ｐ−ＣＳＣＦは、ＡＴ １０１に、呼応答メッセージに２１６を送る。
【００４５】
本発明は、その特定の実施例について述べられているが、それは上記説明に限定されるのではなく、添付の特許請求の範囲に記載された範囲に限定されるものにすぎない。
【技術分野】
【０００１】
本発明は、一般には、通信システムに関し、より詳細には、ベアラ損失検出に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネット・プロトコル）を用いたマルチメディア・サービスは、サービス・プロバイダにとって極めて重要なサービスであり、サービス・プロバイダは、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ボイス・オーバー・インターネット・プロトコル）を、このリアルタイム・サービスを使用するための第１の主要アプリケーションと見なしている。ＶｏＩＰは、主にＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＰマルチメディア・サブシステム）コア・ネットワークおよび様々なアクセス・ネットワークを使用して構築され、これらのネットワークは、ケーブル、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ：デジタル加入者回線）、ファイバなどの広帯域接続を、またＤＯＲＡ、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ：マイクロ波アクセス世界規模相互運用性）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ロング・ターム・エボリューション）などの様々な無線アクセス・ネットワークをも含む。
【０００３】
通信システム内の音声サービスは、不可欠なサービスである。したがって、音声サービスのすべての側面が、非常にうまく働かなければならない。１つの関心領域は、ベアラ損失検出の領域である。呼の間のベアラ損失の検出は、シグナリングとベアラ・レベルの両方の多くのネットワーク要素に、接続が失われたことを検出するよう求めるので、これは些細なプロセスではない。
【０００４】
これは一般に、こうしたネットワークの設計が本質的にシグナリングとベアラのネットワーク要素を適度に分離するという事実によってさらに複雑になる。この分離によって、検出および検出の伝達がさらに一層複雑になる。ベアラ損失または接続損失は、ＭＧＷ（Ｍｅｄｉａ ＧａｔｅＷａｙ：メディア・ゲートウェイ）またはＭＲＦ（Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ：メディア・リソース機能）などのコア・ネットワーク要素内で生じていることがある。ベアラ損失または接続損失は、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）、ＧＷ、さらにはアクセス端末としても知られているモバイル装置などのアクセス・ネットワーク要素自体で生じていることもある。
【０００５】
遭遇する第１の問題は、通信システムがコア・ネットワーク内のベアラ損失をどのように検出できるかということである。
【０００６】
遭遇する第２の問題は、通信システムがアクセス・ネットワーク内のベアラ損失をどのように検出できるかということである。
【０００７】
遭遇する第３の問題は、様々な無線アクセス・ネットワークについて、被呼側に到達し／被呼側が警告を受け、最終的に応答する間、セッションの発信側がパケット・アクセス・チャネルで休止状態に入り得ることである。これは、発信元のアクセス接続上にパケット・データ活動がないために発生する。この問題は、音声クリッピングおよび呼設定遅延を引き起こすことがある。
【０００８】
ベアラ損失を検出する助けとするために使用できる１つの既存の機構は、ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：リアルタイム・トランスポート制御プロトコル）を使用することである。ＲＴＣＰは、主としてネットワーク性能およびベアラ接続の他の様々な側面を決定するように設計されるが、接続損失もまた、ＲＴＣＰパケットから収集できる。この種類のプロトコルは、主としてエンドツーエンド・プロトコルであり、終端装置（モバイル装置など）がその問題を有するものである場合には、このプロトコルはあまり有効でないことに留意されたい。さらに、ＲＴＣＰの有効利用に付随する帯域幅コストのせいで、このプロトコルは一般に、サポートまたは使用されない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、通信システム内でベアラ損失がいつ存在するか決定するやり方が求められている。さらに、この決定は、真のベアラ損失と、呼の当事者のうちの１つからのパケット・データ活動が正当な理由で（ｌｅｇｉｔｉｍａｔｅ）欠如していることとを区別する必要がある。
【課題を解決するための手段】
【００１０】
本発明は、ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法を提供する。セッションがアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）と別のユーザＢの間のＶｏＩＰ呼として設定される場合、このセッションは、トラフィックが両方向に流れると期待される双方向セッションである。セッション設定のプロセスの間に、セッションのシグナリングに関与するネットワーク要素は、セッションを確立する。すなわち、ＩＭＳコアに関連するＡＴは、ＶｏＩＰセッションを確立する。ＶｏＩＰセッション確立の一貫として、ＩＭＳコアおよびＡＴは、セッションのメディア・タイプ、したがって帯域幅をネゴシエートし、またベアラ・エンティティのＩＰアドレスおよびポートなどの接続点をもネゴシエートする。このネゴシエートされたメディア情報は、コーデック情報と呼ばれる。
【００１１】
このセッションのコーデックもネゴシエートされ、それによってＳＧＷなどのアクセス・ネットワーク内のベアラ・ノードに、いくらの１秒当たりパケット数が期待されるか伝えることができる。たとえば、ポリシー課金規則機能（ＰＣＲＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）は、ＳＧＷに、セッションの送信元および宛先ＩＰアドレスを、またコーデックが拡張可変レートＣＯＤＥＣ（ＥＶＲＣ：Ｅｎｈａｎｃｅｄ Ｖａｒｉａｂｌｅ Ｒａｔｅ ＣＯＤＥＣ）であり、ペイロード・タイプ＃が９６であり、パケットの期待レートが５０パケット／秒であることをも伝えることができる。ＳＧＷは、この情報を使用して、各方向のトラフィックの流れを評価することができる。
【００１２】
ＩＭＳコアは、ポリシー実施およびゲート制御のためにＰＣＲＦにコーデック情報を通信する。次に、ＰＣＲＦは、シグナリング・ゲートウェイ（ＳＧＷ：Ｓｉｇｎａｌｉｎｇ Ｇａｔｅｗａｙ）およびパケット・データ網ゲートウェイ（ＰＧＷ：Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）にこのコーデック情報を送る。コーデック情報は、接続情報と、コア・ネットワークに対するトラフィック・フローの方向を含む。
【００１３】
この時点で、ＳＧＷは、コア・ネットワーク側からは何を期待すべきか、またアクセス・ネットワーク側からは何を期待すべきか分かる。ＳＧＷは、この時点でトラフィック・フローを監視し、トラフィック・フローに矛盾点があるかどうか判断し、この矛盾点をＰＣＲＦに報告することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の例示的な一実施形態による、ＩＭＳシステムを示す図である。
【図２】本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れを示す図である。
【発明を実施するための形態】
【００１５】
本発明は、図１および図２を参照してよりよく理解することができる。図１は、本発明の例示的な一実施形態による無線ＩＭＳシステム１００を示している。無線ＩＭＳシステム１００は、アクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）１０１と、基地局（ＢＴＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）１０３と、無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）１０５と、サービング・ゲートウェイ（ＳＧＷ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）１０７と、パケット・ゲートウェイ（ＰＧＷ：Ｐａｃｋｅｔ Ｇａｔｅｗａｙ）１０９と、ポリシー制御レポジトリ機能（ＰＣＲＦ：Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ）１１１と、ＩＭＳコア１１３と、ＩＰネットワーク１１５と、メディア・ゲートウェイ制御機能（ＭＧＣＦ：Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）１１７と、メディア・ゲートウェイ（ＭＧＷ：Ｍｅｄｉａ Ｇａｔｅｗａｙ）１１９とを備える。
【００１６】
ＡＴ １０１は、このシナリオでは、ＶｏＩＰ対応モバイル装置である。
【００１７】
基地局（ＢＴＳ）１０３は、エアー信号を介してＡＴ １０１と送受信する。
【００１８】
無線ネットワーク制御装置（ＲＮＣ）１０５は、ＢＴＳ １０３を制御し、ＳＧＷ １０７に接続する。
【００１９】
ＳＧＷ １０７は、ＰＧＷ １０９を介してアクセス・ネットワークとコア・ネットワークからの接続をブリッジするネットワーク要素である。ポリシー実施は、ＳＧＷ １０７内で行うことができ、ＳＧＷ １０７は、ＰＣＲＦ １１１に対して接続される。
【００２０】
ＰＧＷ １０９は好ましくは、ＩＰコア・ネットワーク１１５に接続するように、ＳＧＷ １０７と連携して働く。ポリシー実施は、ＰＧＷ １０９内で行うことができ、ＰＣＲＦ １１１に信号が送られる。
【００２１】
ＰＣＲＦ １１１は、ネットワーク１００内の主要のポリシー・エンジンである。ＰＣＲＦ １１１は、好ましくはシグナリング専用の要素である。例示的な実施形態では、ＰＣＲＦ １１１を通過するベアラはない。
【００２２】
ＩＭＳコア１１３は、アプリケーション・コアであり、好ましくはＰ−ＣＳＣＦとＳ−ＣＳＣＦとを含む。ＩＭＳコア１１３は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＩＭＳコア１１３を通過するベアラはない。
【００２３】
ＩＰネットワーク１１５は、パケット交換網である。
【００２４】
ＭＧＣＦ １１７は、ＭＧＷ １１９を制御する。ＭＧＣＦ １１７は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＭＧＣＦ １１７を通過するベアラはない。
【００２５】
ＭＧＷ １１９は、ＩＰベアラをＴＤＭベアラに接続する。
【００２６】
図２は、本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れ２００を示している。ＡＴ １０１がＰ−ＣＳＣＦにＩｎｖｉｔｅメッセージ２０１を送るとき、マルチメディア・セッションがＡＴ １０１によって開始される。Ｉｎｖｉｔｅメッセージ２０１は好ましくは、接続アドレス、コーデック情報、トラフィック方向などを含む様々なメディア特性を含む。例示的な一実施形態では、Ｉｎｖｉｔｅメッセージ２０１は、送信者情報、受信者情報、ＳＤＰ情報、ポート、およびトラフィックの流れが送信方向か、受信方向か、それとも両方向かを含む。
【００２７】
Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１を受け取り、このメッセージをＩｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０２としてＰＣＲＦ １１１に転送する。Ｉｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０２は好ましくは、近接エンドポイント情報と、アプリケーション・タイプとトラフィック方向とを含む。例示的な一実施形態では、ＰＣＲＦ １１１は、ポリシーを確立し、ＳＧＷ １０７にこの情報を伝える。
【００２８】
ＰＣＲＦ １１１は、Ｉｎｄｉｃａｔｅ Ｓｅｓｓｉｏｎ Ｓｅｔｕｐメッセージ２０３を送ることによってＳＧＷ １０７にＳｅｓｓｉｏｎ ｓｅｔｕｐ情報およびベアラ特性を伝える。ＳＧＷ １０７は好ましくは、この情報を使用して、呼設定の間、発信元アクセス・リンクがアクティブのままになるように発信側の休止タイマを調整する。
【００２９】
呼設定の間、ＩＭＳコア１１３および／またはＰＣＲＦ １１１は、ＳＧＷ １０７にセッションの状態を伝えることができる。発信側のケースでは、ＰＣＲＦ １１１は、セッション確立が試みられていることを発信元ＳＧＷ １０７に伝えることができる。これは、ＳＧＷ １０７が発信側の休止タイマを無視しまたは延長し、それによってクリッピングおよび他のエンドユーザ問題を回避するように促す。アクセス・ネットワーク接続に関して決定を知的に行うこの能力は、被呼者に到達し／被呼側が警告を受け、被呼者が最終的に応答する間、セッションの発信側がパケット・データ活動の欠如を誤って休眠状態と認識することによる音声クリッピングおよび呼設定遅延の問題を解決する。これは、発信元アクセス接続上にパケット・データ活動がないために生じる。
【００３０】
Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１をＩｎｖｉｔｅメッセージ２０４としてＳ−ＣＳＣＦに渡す。
【００３１】
Ｓ−ＣＳＣＦは、ＥＮＵＭまたはＤＮＳルックアップによってこの呼のための経路を決定し、ＰＳＴＮ内への送達のためにこの呼をＩｎｖｉｔｅメッセージ２０５によってＭＧＣＦ １１７に送る。
【００３２】
Ｉｎｖｉｔｅメッセージ２０５を受け取ると、ＭＧＣＦ １１７は、Ｇｅｔ Ｂｅａｒｅｒ Ａｄｄｒｅｓｓメッセージ２０６をＭＧＷ １１９に送る。ＭＧＷ １１７は、この呼のためのベアラ接続を設定し、ＭＧＣＦ １１７にベアラ・アドレスを返す。
【００３３】
ＭＧＣＦ １１７は、ＭＧＷ １１９からベアラ・アドレスを受け取り、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７によってこのメディア情報をＳ−ＣＳＣＦに渡す。
【００３４】
Ｓ−ＣＳＣＦは、ＭＧＣＦ １１７からＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７を受け取る。Ｓ−ＣＳＣＦは、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０７からのメディア情報をＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０８によってＰ−ＣＳＣＦに渡す。
【００３５】
Ｐ−ＣＳＣＦは、Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２０８を受け取り、Ｉｎｄｉｃａｔｅメッセージ２０９によってこの情報をＰＣＲＦ １１１に送る。ＰＣＲＦ １１１は好ましくは、ポリシーを確立し、この情報をＳＧＷ １０７に伝える。
【００３６】
ＰＣＲＦ １１１は、セッション設定情報およびベアラ特性をＩｎｄｉｃａｔｅメッセージ２１０によってＳＧＷ １０７に伝える。ＳＧＷ １０７は好ましくは、この情報を使用して、発信側のベアラ損失タイマを調整する。ＳＧＷ １０７は、この時点でＭＧＷ １１９を介してコア・ネットワークからの期待トラフィック特性を知っているので、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間（ベアラ損失タイマ）の間にこのトラフィック・パターンから逸脱すると、ＳＧＷ １０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。
【００３７】
ＳＧＷ １０７は、特定の時間量の間、コア・ネットワークからアクセス側に流れるパケットがなかったことを検出する場合、ベアラ損失の問題があり得ることについてＰＣＲＦ １１１に警告するメッセージをＰＣＲＦ １１１に送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめ、またはユーザにこの問題について警告することによって、これに従って行動することができる。これによって、コア・ネットワーク内のベアラ損失の検出が可能となる。
【００３８】
Ｐ−ＣＳＣＦは、ＭＧＷ １１９からのメディア情報をＳｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓメッセージ２１１によってＡＴ １０１に渡す。
【００３９】
被呼側が呼に応答するとき、ＭＧＣＦ １１７は、ＯＫメッセージ２１２をＳ−ＣＳＣＦに送る。
【００４０】
Ｓ−ＣＳＣＦは、被呼側が呼要求に応答することを示すＯＫメッセージ２１３をＰ−ＣＳＣＦに送る。
【００４１】
Ｐ−ＣＳＣＦは、この情報をＩｎｄｉｃａｔｅメッセージ２１４によってＰＣＲＦ １１１に送る。Ｉｎｄｉｃａｔｅメッセージ２１４は好ましくは、遠端ポート情報、ならびにトラフィック方向および特性を含む。ＰＣＲＦは好ましくは、ポリシーを確立し、この情報をＳＧＷ １０７に伝える。
【００４２】
ＰＣＲＦ １１１は、メディア特性のどんな変更をもＩｎｄｉｃａｔｅメッセージ２１５によってＳＧＷ １０７に送ることができる。その時点以降、ＳＧＷ １０７は、ＭＧＷ １１９からの、またアクセス・ネットワークからの期待されるトラフィック特性がここでは分かっており、ＳＧＷ １０７は、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間、たとえばベアラ損失タイマの間にこのトラフィック・パターンから逸脱すると、ＳＧＷ １０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。
【００４３】
この知識を得てＳＧＷ１０７が、所定の時間量の間、アクセス側から流れるパケットがなかったことを検出し、またはアクセス側が休止状態に入ったことを検出するとき、ＳＧＷ１０７は、ＰＣＲＦ １１１に、ベアラ損失があり得ることについてそれに警告するメッセージを送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめることによって、またはこの問題についてユーザに警告することによって、これに従って行動することができる。アクセス側では、セッション中にＡＴ １０１のバッテリが抜き取られる場合、またはＡＴ １０１がＲＦホールに入る場合、アクセス側は、接続を休眠状態にし、他には何も行われないことに留意されたい。このシナリオでは、ＳＧＷ １０７は、現在の振舞いと期待された振舞いとの矛盾点を認識し、シグナリング・エンティティに処置を講ずるように知らせる。これによって、通信システムは、アクセス・ネットワーク内のベアラ損失を検出することができる。
【００４４】
Ｐ−ＣＳＣＦは、ＡＴ １０１に、呼応答メッセージに２１６を送る。
【００４５】
本発明は、その特定の実施例について述べられているが、それは上記説明に限定されるのではなく、添付の特許請求の範囲に記載された範囲に限定されるものにすぎない。
【特許請求の範囲】
【請求項１】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
セッションの確立が試みられていることのメッセージを受け取るステップと、
前記メッセージを受け取ると前記休止タイマを延長するステップとを備える方法。
【請求項２】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
前記休止タイマの終了に基づいて、パケットが期待されるときに受け取られていないと決定するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップと、
前記呼要求を完了するステップとを備える方法。
【請求項３】
前記シグナリング専用の要素がポリシー課金規則機能（ＰＣＲＦ）である、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項４】
前記警告の受信に基づいてベアラが失われたかどうか決定するステップをさらに備える、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項５】
ベアラが失われたかどうか決定するステップが、前記シグナリング接続が依然として休止状態かどうか確かめるステップを備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項６】
前記アクセス端末に警告するステップをさらに備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項７】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
トラフィック・パターンを決定するために受送信されたベアラ・トラフィックを監視するステップと、
前記トラフィック・パターンからの逸脱を検出するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップとを備える方法。
【請求項８】
前記トラフィック・パターンからの逸脱を検出するステップが、タイマを終了するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項９】
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末のバッテリを切断するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項１０】
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末がＲＦホールに入るステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項１】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
セッションの確立が試みられていることのメッセージを受け取るステップと、
前記メッセージを受け取ると前記休止タイマを延長するステップとを備える方法。
【請求項２】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
前記休止タイマの終了に基づいて、パケットが期待されるときに受け取られていないと決定するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップと、
前記呼要求を完了するステップとを備える方法。
【請求項３】
前記シグナリング専用の要素がポリシー課金規則機能（ＰＣＲＦ）である、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項４】
前記警告の受信に基づいてベアラが失われたかどうか決定するステップをさらに備える、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項５】
ベアラが失われたかどうか決定するステップが、前記シグナリング接続が依然として休止状態かどうか確かめるステップを備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項６】
前記アクセス端末に警告するステップをさらに備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項７】
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
トラフィック・パターンを決定するために受送信されたベアラ・トラフィックを監視するステップと、
前記トラフィック・パターンからの逸脱を検出するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップとを備える方法。
【請求項８】
前記トラフィック・パターンからの逸脱を検出するステップが、タイマを終了するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項９】
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末のバッテリを切断するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【請求項１０】
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末がＲＦホールに入るステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
【図１】
【図２】
【図２】
【公表番号】特表２０１１−５３０９５６（Ｐ２０１１−５３０９５６Ａ）
【公表日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願番号】特願２０１１−５２２９９０（Ｐ２０１１−５２２９９０）
【出願日】平成２１年８月１２日（２００９．８．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００４６１１
【国際公開番号】ＷＯ２０１０／０１９２３０
【国際公開日】平成２２年２月１８日（２０１０．２．１８）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
【公表日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願日】平成２１年８月１２日（２００９．８．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００４６１１
【国際公開番号】ＷＯ２０１０／０１９２３０
【国際公開日】平成２２年２月１８日（２０１０．２．１８）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
[ Back to top ]