JP2011530956A

JP2011530956A - Ｉｐベース・マルチメディア・セッションのベアラ損失の検出

Info

Publication number: JP2011530956A
Application number: JP2011522990A
Authority: JP
Inventors: リウ，チュン−ジン; マタイ，スティンソン，サムエル
Original assignee: アルカテル−ルーセントユーエスエーインコーポレーテッド
Priority date: 2008-08-13
Filing date: 2009-08-12
Publication date: 2011-12-22
Also published as: EP2335389B1; KR20110030675A; EP2335389A2; CN102124716A; WO2010019230A2; WO2010019230A3

Abstract

本発明は、ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法を提供する。マルチメディア・セッションが、アクセス端末によって開始される。ポリシー課金規則機能（ＰＣＲＦ）が、セッション設定情報およびベアラ特性をシグナリング・ゲートウェイ（ＳＧＷ）に伝える。ＳＧＷは、この情報を使用して、呼設定の間、発信元アクセス・リンクがアクティブのままになるように発信側の休止タイマを調整する。

Description

本発明は、一般には、通信システムに関し、より詳細には、ベアラ損失検出に関する。

ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ：インターネット・プロトコル）を用いたマルチメディア・サービスは、サービス・プロバイダにとって極めて重要なサービスであり、サービス・プロバイダは、ＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ：ボイス・オーバー・インターネット・プロトコル）を、このリアルタイム・サービスを使用するための第１の主要アプリケーションと見なしている。ＶｏＩＰは、主にＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ：ＩＰマルチメディア・サブシステム）コア・ネットワークおよび様々なアクセス・ネットワークを使用して構築され、これらのネットワークは、ケーブル、ＤＳＬ（ＤｉｇｉｔａｌＳｕｂｓｃｒｉｂｅｒＬｉｎｅ：デジタル加入者回線）、ファイバなどの広帯域接続を、またＤＯＲＡ、ＷｉＭＡＸ（ＷｏｒｌｄｗｉｄｅＩｎｔｅｒｏｐｅｒａｂｉｌｉｔｙｆｏｒＭｉｃｒｏｗａｖｅＡｃｃｅｓｓ：マイクロ波アクセス世界規模相互運用性）、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ：ロング・ターム・エボリューション）などの様々な無線アクセス・ネットワークをも含む。

通信システム内の音声サービスは、不可欠なサービスである。したがって、音声サービスのすべての側面が、非常にうまく働かなければならない。１つの関心領域は、ベアラ損失検出の領域である。呼の間のベアラ損失の検出は、シグナリングとベアラ・レベルの両方の多くのネットワーク要素に、接続が失われたことを検出するよう求めるので、これは些細なプロセスではない。

これは一般に、こうしたネットワークの設計が本質的にシグナリングとベアラのネットワーク要素を適度に分離するという事実によってさらに複雑になる。この分離によって、検出および検出の伝達がさらに一層複雑になる。ベアラ損失または接続損失は、ＭＧＷ（ＭｅｄｉａＧａｔｅＷａｙ：メディア・ゲートウェイ）またはＭＲＦ（ＭｅｄｉａＲｅｓｏｕｒｃｅＦｕｎｃｔｉｏｎ：メディア・リソース機能）などのコア・ネットワーク要素内で生じていることがある。ベアラ損失または接続損失は、ＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）、ＧＷ、さらにはアクセス端末としても知られているモバイル装置などのアクセス・ネットワーク要素自体で生じていることもある。

遭遇する第１の問題は、通信システムがコア・ネットワーク内のベアラ損失をどのように検出できるかということである。

遭遇する第２の問題は、通信システムがアクセス・ネットワーク内のベアラ損失をどのように検出できるかということである。

遭遇する第３の問題は、様々な無線アクセス・ネットワークについて、被呼側に到達し／被呼側が警告を受け、最終的に応答する間、セッションの発信側がパケット・アクセス・チャネルで休止状態に入り得ることである。これは、発信元のアクセス接続上にパケット・データ活動がないために発生する。この問題は、音声クリッピングおよび呼設定遅延を引き起こすことがある。

ベアラ損失を検出する助けとするために使用できる１つの既存の機構は、ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ：リアルタイム・トランスポート制御プロトコル）を使用することである。ＲＴＣＰは、主としてネットワーク性能およびベアラ接続の他の様々な側面を決定するように設計されるが、接続損失もまた、ＲＴＣＰパケットから収集できる。この種類のプロトコルは、主としてエンドツーエンド・プロトコルであり、終端装置（モバイル装置など）がその問題を有するものである場合には、このプロトコルはあまり有効でないことに留意されたい。さらに、ＲＴＣＰの有効利用に付随する帯域幅コストのせいで、このプロトコルは一般に、サポートまたは使用されない。

したがって、通信システム内でベアラ損失がいつ存在するか決定するやり方が求められている。さらに、この決定は、真のベアラ損失と、呼の当事者のうちの１つからのパケット・データ活動が正当な理由で（ｌｅｇｉｔｉｍａｔｅ）欠如していることとを区別する必要がある。

本発明は、ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法を提供する。セッションがアクセス端末（ＡＴ：ＡｃｃｅｓｓＴｅｒｍｉｎａｌ）と別のユーザＢの間のＶｏＩＰ呼として設定される場合、このセッションは、トラフィックが両方向に流れると期待される双方向セッションである。セッション設定のプロセスの間に、セッションのシグナリングに関与するネットワーク要素は、セッションを確立する。すなわち、ＩＭＳコアに関連するＡＴは、ＶｏＩＰセッションを確立する。ＶｏＩＰセッション確立の一貫として、ＩＭＳコアおよびＡＴは、セッションのメディア・タイプ、したがって帯域幅をネゴシエートし、またベアラ・エンティティのＩＰアドレスおよびポートなどの接続点をもネゴシエートする。このネゴシエートされたメディア情報は、コーデック情報と呼ばれる。

このセッションのコーデックもネゴシエートされ、それによってＳＧＷなどのアクセス・ネットワーク内のベアラ・ノードに、いくらの１秒当たりパケット数が期待されるか伝えることができる。たとえば、ポリシー課金規則機能（ＰＣＲＦ：ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＲｕｌｅｓＦｕｎｃｔｉｏｎ）は、ＳＧＷに、セッションの送信元および宛先ＩＰアドレスを、またコーデックが拡張可変レートＣＯＤＥＣ（ＥＶＲＣ：ＥｎｈａｎｃｅｄＶａｒｉａｂｌｅＲａｔｅＣＯＤＥＣ）であり、ペイロード・タイプ＃が９６であり、パケットの期待レートが５０パケット／秒であることをも伝えることができる。ＳＧＷは、この情報を使用して、各方向のトラフィックの流れを評価することができる。

ＩＭＳコアは、ポリシー実施およびゲート制御のためにＰＣＲＦにコーデック情報を通信する。次に、ＰＣＲＦは、シグナリング・ゲートウェイ（ＳＧＷ：ＳｉｇｎａｌｉｎｇＧａｔｅｗａｙ）およびパケット・データ網ゲートウェイ（ＰＧＷ：ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ）にこのコーデック情報を送る。コーデック情報は、接続情報と、コア・ネットワークに対するトラフィック・フローの方向を含む。

この時点で、ＳＧＷは、コア・ネットワーク側からは何を期待すべきか、またアクセス・ネットワーク側からは何を期待すべきか分かる。ＳＧＷは、この時点でトラフィック・フローを監視し、トラフィック・フローに矛盾点があるかどうか判断し、この矛盾点をＰＣＲＦに報告することができる。

本発明の例示的な一実施形態による、ＩＭＳシステムを示す図である。本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れを示す図である。

本発明は、図１および図２を参照してよりよく理解することができる。図１は、本発明の例示的な一実施形態による無線ＩＭＳシステム１００を示している。無線ＩＭＳシステム１００は、アクセス端末（ＡＴ：ＡｃｃｅｓｓＴｅｒｍｉｎａｌ）１０１と、基地局（ＢＴＳ：ＢａｓｅＳｔａｔｉｏｎ）１０３と、無線ネットワーク制御装置（ＲＮＣ：ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）１０５と、サービング・ゲートウェイ（ＳＧＷ：ＳｅｒｖｉｎｇＧａｔｅｗａｙ）１０７と、パケット・ゲートウェイ（ＰＧＷ：ＰａｃｋｅｔＧａｔｅｗａｙ）１０９と、ポリシー制御レポジトリ機能（ＰＣＲＦ：ＰｏｌｉｃｙＣｏｎｔｒｏｌａｎｄＲｅｐｏｓｉｔｏｒｙＦｕｎｃｔｉｏｎ）１１１と、ＩＭＳコア１１３と、ＩＰネットワーク１１５と、メディア・ゲートウェイ制御機能（ＭＧＣＦ：ＭｅｄｉａＧａｔｅｗａｙＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）１１７と、メディア・ゲートウェイ（ＭＧＷ：ＭｅｄｉａＧａｔｅｗａｙ）１１９とを備える。

ＡＴ１０１は、このシナリオでは、ＶｏＩＰ対応モバイル装置である。

基地局（ＢＴＳ）１０３は、エアー信号を介してＡＴ１０１と送受信する。

無線ネットワーク制御装置（ＲＮＣ）１０５は、ＢＴＳ１０３を制御し、ＳＧＷ１０７に接続する。

ＳＧＷ１０７は、ＰＧＷ１０９を介してアクセス・ネットワークとコア・ネットワークからの接続をブリッジするネットワーク要素である。ポリシー実施は、ＳＧＷ１０７内で行うことができ、ＳＧＷ１０７は、ＰＣＲＦ１１１に対して接続される。

ＰＧＷ１０９は好ましくは、ＩＰコア・ネットワーク１１５に接続するように、ＳＧＷ１０７と連携して働く。ポリシー実施は、ＰＧＷ１０９内で行うことができ、ＰＣＲＦ１１１に信号が送られる。

ＰＣＲＦ１１１は、ネットワーク１００内の主要のポリシー・エンジンである。ＰＣＲＦ１１１は、好ましくはシグナリング専用の要素である。例示的な実施形態では、ＰＣＲＦ１１１を通過するベアラはない。

ＩＭＳコア１１３は、アプリケーション・コアであり、好ましくはＰ−ＣＳＣＦとＳ−ＣＳＣＦとを含む。ＩＭＳコア１１３は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＩＭＳコア１１３を通過するベアラはない。

ＩＰネットワーク１１５は、パケット交換網である。

ＭＧＣＦ１１７は、ＭＧＷ１１９を制御する。ＭＧＣＦ１１７は、好ましくはシグナリング専用の要素である。例示的な一実施形態では、ＭＧＣＦ１１７を通過するベアラはない。

ＭＧＷ１１９は、ＩＰベアラをＴＤＭベアラに接続する。

図２は、本発明の例示的な一実施形態による、ベアラ損失を検出するための方法の呼の流れ２００を示している。ＡＴ１０１がＰ−ＣＳＣＦにＩｎｖｉｔｅメッセージ２０１を送るとき、マルチメディア・セッションがＡＴ１０１によって開始される。Ｉｎｖｉｔｅメッセージ２０１は好ましくは、接続アドレス、コーデック情報、トラフィック方向などを含む様々なメディア特性を含む。例示的な一実施形態では、Ｉｎｖｉｔｅメッセージ２０１は、送信者情報、受信者情報、ＳＤＰ情報、ポート、およびトラフィックの流れが送信方向か、受信方向か、それとも両方向かを含む。

Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１を受け取り、このメッセージをＩｎｄｉｃａｔｅＳｅｓｓｉｏｎＳｅｔｕｐメッセージ２０２としてＰＣＲＦ１１１に転送する。ＩｎｄｉｃａｔｅＳｅｓｓｉｏｎＳｅｔｕｐメッセージ２０２は好ましくは、近接エンドポイント情報と、アプリケーション・タイプとトラフィック方向とを含む。例示的な一実施形態では、ＰＣＲＦ１１１は、ポリシーを確立し、ＳＧＷ１０７にこの情報を伝える。

ＰＣＲＦ１１１は、ＩｎｄｉｃａｔｅＳｅｓｓｉｏｎＳｅｔｕｐメッセージ２０３を送ることによってＳＧＷ１０７にＳｅｓｓｉｏｎｓｅｔｕｐ情報およびベアラ特性を伝える。ＳＧＷ１０７は好ましくは、この情報を使用して、呼設定の間、発信元アクセス・リンクがアクティブのままになるように発信側の休止タイマを調整する。

呼設定の間、ＩＭＳコア１１３および／またはＰＣＲＦ１１１は、ＳＧＷ１０７にセッションの状態を伝えることができる。発信側のケースでは、ＰＣＲＦ１１１は、セッション確立が試みられていることを発信元ＳＧＷ１０７に伝えることができる。これは、ＳＧＷ１０７が発信側の休止タイマを無視しまたは延長し、それによってクリッピングおよび他のエンドユーザ問題を回避するように促す。アクセス・ネットワーク接続に関して決定を知的に行うこの能力は、被呼者に到達し／被呼側が警告を受け、被呼者が最終的に応答する間、セッションの発信側がパケット・データ活動の欠如を誤って休眠状態と認識することによる音声クリッピングおよび呼設定遅延の問題を解決する。これは、発信元アクセス接続上にパケット・データ活動がないために生じる。

Ｐ−ＣＳＣＦは、Ｉｎｖｉｔｅメッセージ２０１をＩｎｖｉｔｅメッセージ２０４としてＳ−ＣＳＣＦに渡す。

Ｓ−ＣＳＣＦは、ＥＮＵＭまたはＤＮＳルックアップによってこの呼のための経路を決定し、ＰＳＴＮ内への送達のためにこの呼をＩｎｖｉｔｅメッセージ２０５によってＭＧＣＦ１１７に送る。

Ｉｎｖｉｔｅメッセージ２０５を受け取ると、ＭＧＣＦ１１７は、ＧｅｔＢｅａｒｅｒＡｄｄｒｅｓｓメッセージ２０６をＭＧＷ１１９に送る。ＭＧＷ１１７は、この呼のためのベアラ接続を設定し、ＭＧＣＦ１１７にベアラ・アドレスを返す。

ＭＧＣＦ１１７は、ＭＧＷ１１９からベアラ・アドレスを受け取り、ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２０７によってこのメディア情報をＳ−ＣＳＣＦに渡す。

Ｓ−ＣＳＣＦは、ＭＧＣＦ１１７からＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２０７を受け取る。Ｓ−ＣＳＣＦは、ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２０７からのメディア情報をＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２０８によってＰ−ＣＳＣＦに渡す。

Ｐ−ＣＳＣＦは、ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２０８を受け取り、Ｉｎｄｉｃａｔｅメッセージ２０９によってこの情報をＰＣＲＦ１１１に送る。ＰＣＲＦ１１１は好ましくは、ポリシーを確立し、この情報をＳＧＷ１０７に伝える。

ＰＣＲＦ１１１は、セッション設定情報およびベアラ特性をＩｎｄｉｃａｔｅメッセージ２１０によってＳＧＷ１０７に伝える。ＳＧＷ１０７は好ましくは、この情報を使用して、発信側のベアラ損失タイマを調整する。ＳＧＷ１０７は、この時点でＭＧＷ１１９を介してコア・ネットワークからの期待トラフィック特性を知っているので、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間（ベアラ損失タイマ）の間にこのトラフィック・パターンから逸脱すると、ＳＧＷ１０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。

ＳＧＷ１０７は、特定の時間量の間、コア・ネットワークからアクセス側に流れるパケットがなかったことを検出する場合、ベアラ損失の問題があり得ることについてＰＣＲＦ１１１に警告するメッセージをＰＣＲＦ１１１に送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめ、またはユーザにこの問題について警告することによって、これに従って行動することができる。これによって、コア・ネットワーク内のベアラ損失の検出が可能となる。

Ｐ−ＣＳＣＦは、ＭＧＷ１１９からのメディア情報をＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓメッセージ２１１によってＡＴ１０１に渡す。

被呼側が呼に応答するとき、ＭＧＣＦ１１７は、ＯＫメッセージ２１２をＳ−ＣＳＣＦに送る。

Ｓ−ＣＳＣＦは、被呼側が呼要求に応答することを示すＯＫメッセージ２１３をＰ−ＣＳＣＦに送る。

Ｐ−ＣＳＣＦは、この情報をＩｎｄｉｃａｔｅメッセージ２１４によってＰＣＲＦ１１１に送る。Ｉｎｄｉｃａｔｅメッセージ２１４は好ましくは、遠端ポート情報、ならびにトラフィック方向および特性を含む。ＰＣＲＦは好ましくは、ポリシーを確立し、この情報をＳＧＷ１０７に伝える。

ＰＣＲＦ１１１は、メディア特性のどんな変更をもＩｎｄｉｃａｔｅメッセージ２１５によってＳＧＷ１０７に送ることができる。その時点以降、ＳＧＷ１０７は、ＭＧＷ１１９からの、またアクセス・ネットワークからの期待されるトラフィック特性がここでは分かっており、ＳＧＷ１０７は、受送信されたベアラ・トラフィックを追跡することができる。構成可能な期間、たとえばベアラ損失タイマの間にこのトラフィック・パターンから逸脱すると、ＳＧＷ１０７が、ベアラ損失があり得ることについて呼制御層に知らせることになる。

この知識を得てＳＧＷ１０７が、所定の時間量の間、アクセス側から流れるパケットがなかったことを検出し、またはアクセス側が休止状態に入ったことを検出するとき、ＳＧＷ１０７は、ＰＣＲＦ１１１に、ベアラ損失があり得ることについてそれに警告するメッセージを送ることができる。シグナリング・ネットワーク要素は、シグナリング接続が依然として休止しているかどうか確かめることによって、またはこの問題についてユーザに警告することによって、これに従って行動することができる。アクセス側では、セッション中にＡＴ１０１のバッテリが抜き取られる場合、またはＡＴ１０１がＲＦホールに入る場合、アクセス側は、接続を休眠状態にし、他には何も行われないことに留意されたい。このシナリオでは、ＳＧＷ１０７は、現在の振舞いと期待された振舞いとの矛盾点を認識し、シグナリング・エンティティに処置を講ずるように知らせる。これによって、通信システムは、アクセス・ネットワーク内のベアラ損失を検出することができる。

Ｐ−ＣＳＣＦは、ＡＴ１０１に、呼応答メッセージに２１６を送る。

本発明は、その特定の実施例について述べられているが、それは上記説明に限定されるのではなく、添付の特許請求の範囲に記載された範囲に限定されるものにすぎない。

Claims

ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
セッションの確立が試みられていることのメッセージを受け取るステップと、
前記メッセージを受け取ると前記休止タイマを延長するステップとを備える方法。
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
休止タイマを設定するステップと、
前記休止タイマの終了に基づいて、パケットが期待されるときに受け取られていないと決定するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップと、
前記呼要求を完了するステップとを備える方法。
前記シグナリング専用の要素がポリシー課金規則機能（ＰＣＲＦ）である、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
前記警告の受信に基づいてベアラが失われたかどうか決定するステップをさらに備える、請求項２に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
ベアラが失われたかどうか決定するステップが、前記シグナリング接続が依然として休止状態かどうか確かめるステップを備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
前記アクセス端末に警告するステップをさらに備える、請求項４に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
ＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法であって、
アクセス端末から呼要求メッセージを受け取るステップと、
トラフィック・パターンを決定するために受送信されたベアラ・トラフィックを監視するステップと、
前記トラフィック・パターンからの逸脱を検出するステップと、
ベアラ損失があり得ることについてネットワーク要素に警告するステップとを備える方法。
前記トラフィック・パターンからの逸脱を検出するステップが、タイマを終了するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末のバッテリを切断するステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。
前記トラフィック・パターンからの逸脱を検出するステップが、前記アクセス端末がＲＦホールに入るステップを備える、請求項７に記載のＩＰベースのマルチメディア・セッションのベアラ損失を検出するための方法。