特表 2024-542620 サービスＸＤＲの取得方法、装置及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-15

(54)【発明の名称】サービスＸＤＲの取得方法、装置及び記憶媒体

(51)【国際特許分類】

   H04L 43/20 20220101AFI20241108BHJP

【ＦＩ】

H04L43/20

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024531634

(86)(22)【出願日】2022-10-25

(85)【翻訳文提出日】2024-05-28

(86)【国際出願番号】 CN2022127473

(87)【国際公開番号】W WO2023179015

(87)【国際公開日】2023-09-28

(31)【優先権主張番号】202210287606.2

(32)【優先日】2022-03-22

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】艾紅芳

(72)【発明者】

【氏名】張海涛

(72)【発明者】

【氏名】燕曉

(57)【要約】

本願は、サービスＸＤＲの取得方法、装置及び記憶媒体を開示する。第１の装置に適用される、サービスＸＤＲの取得方法は、第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するステップ（４０１）と、前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するステップ（４０２）と、前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するステップと、を含む。これにより、制御プレーンとユーザプレーンとが分離している状態においても、完全で正確なサービスＸＤＲ（４０３）を取得することができる。

【特許請求の範囲】

【請求項1】

第１の装置に適用される、サービスＸＤＲの取得方法であって、
第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するステップ（４０１）と、
前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するステップ（４０２）と、
前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するステップ（４０３）と、
を含むサービスＸＤＲの取得方法。

【請求項2】

前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新する前記ステップ（４０３）は、
前記サービスＸＤＲ内の欠落フィールドを特定するステップと、
前記ターゲットシグナリングＸＤＲから前記欠落フィールドに関する情報を検索し、見つかった情報に基づいて充填フィールドを生成するステップと、
前記充填フィールドを前記サービスＸＤＲに充填するステップと、
を含む請求項１に記載のサービスＸＤＲの取得方法。

【請求項3】

前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新する前記ステップ（４０３）は、
前記ターゲットシグナリングＸＤＲと前記サービスＸＤＲとの間に、前記シグナリングＸＤＲ及び前記サービスＸＤＲ内で同じ対象を記述するフィールドである関連フィールドの不一致が検出された場合、前記サービスＸＤＲ内の対応する前記関連フィールドを修正するステップ
を含む請求項１に記載のサービスＸＤＲの取得方法。

【請求項4】

前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索する前記ステップ（４０２）の前に、前記方法は、
前記第３の装置により送信された前記シグナリングＸＤＲを受信するステップと、
受信した前記シグナリングＸＤＲをローカルキャッシュにキャッシュするステップと、をさらに含み、
前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索する前記ステップは、
前記サービスＸＤＲと、前記サービスとシグナリングとの事前設定された関連付けとに基づいて、ローカルキャッシュの中から前記ターゲットシグナリングＸＤＲを検索するステップ
を含む請求項１から３の何れか一項に記載のサービスＸＤＲの取得方法。

【請求項5】

前記サービスＸＤＲに対応するサービスの終了が検出された場合、前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新する前記ステップは、
前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新し、更新された前記サービスＸＤＲに、サービスの終了を示す情報を追加するステップ、を含み、
前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新する前記ステップの後に、前記方法は、
前記サービスＸＤＲに対応する前記シグナリングＸＤＲを維持するのに用いられるリソースを解放するステップを、さらに含む
請求項１から３の何れか一項に記載のサービスＸＤＲの取得方法。

【請求項6】

第２の装置に適用される、サービスＸＤＲの取得方法であって、
ユーザプレーンからサービスデータを収集するステップ（６０１）と、
前記サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成するステップ（６０２）と、
前記サービスＸＤＲを第１の装置に送信するステップ（６０３）と、
を含むサービスＸＤＲの取得方法。

【請求項7】

第３の装置に適用される、サービスＸＤＲの取得方法であって、
制御プレーンからシグナリングを収集するステップ（７０１）と、
前記シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成するステップ（７０２）と、
前記シグナリングＸＤＲを第１の装置に送信するステップ（７０３）と、
を含むサービスＸＤＲの取得方法。

【請求項8】

第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するのに用いられる受信モジュール（９０１）と、
前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するのに用いられる検索モジュール（９０２）と、
前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するのに用いられる更新モジュール（９０３）と、
を備える装置。

【請求項9】

ユーザプレーンからサービスデータを収集するのに用いられる第１の収集モジュール（１００１）と、
前記サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成するのに用いられる第１の生成モジュール（１００２）と、
前記サービスＸＤＲを第１の装置に送信するのに用いられる第１の送信モジュール（１００３）と、
を備える装置。

【請求項10】

制御プレーンからシグナリングを収集するのに用いられる第２の収集モジュール（１１０１）と、
前記シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成するのに用いられる第２の生成モジュール（１１０２）と、
前記シグナリングＸＤＲを第１の装置に送信するのに用いられる第２の送信モジュール（１１０３）と、
を備える装置。

【請求項11】

少なくとも１つのプロセッサ（１２０１）と、前記少なくとも１つのプロセッサ（１２０１）と通信可能に接続されたメモリ（１２０２）とを備える電子装置であって、
前記メモリ（１２０２）には前記少なくとも１つのプロセッサ（１２０１）により実行できる命令が記憶されており、前記命令が前記少なくとも１つのプロセッサ（１２０１）により実行されることで、前記少なくとも１つのプロセッサ（１２０１）は、請求項１から５の何れか一項に記載のサービスＸＤＲの取得方法を実行すること、又は、請求項６に記載のサービスＸＤＲの取得方法を実行すること、又は、請求項７に記載のサービスＸＤＲの取得方法を実行すること、ができるようにする
電子装置。

【請求項12】

コンピュータプログラムを記憶しているコンピュータ可読記憶媒体であって、
前記コンピュータプログラムがプロセッサにより実行された場合、請求項１から５の何れか一項に記載のサービスＸＤＲの取得方法を実行するか、又は、請求項６に記載のサービスＸＤＲの取得方法を実行するか、又は、請求項７に記載のサービスＸＤＲの取得方法を実行する
コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本願は２０２２年０３月２２日に出願された、出願番号が２０２２１０２８７６０６．２である中国特許出願の優先権を主張し、その全ての内容を引用により本願に組み入れる。

【0002】

本願の実施例は、通信技術の分野に関し、特に、サービスＸＤＲの取得方法、装置及び記憶媒体に関する。

【背景技術】

【0003】

ネットワーク内のネットワーク要素に対してより良く監視及び管理するために、通常では、ネットワーク要素からのデータに基づいてＸ詳細レコード（ｘ （Ａｐｐｌｉｃａｔｉｏｎ） Ｄｅｔａｉｌ Ｒｅｃｏｒｄ，ＸＤＲ）を生成する方式が採用され、ＸＤＲは、ネットワーク要素間のシグナリング伝送プロセス及びシグナリング内容を記録するのに用いられるシグナリングＸＤＲと、ユーザに関する情報を記録するのに用いられるサービスＸＤＲと、の２つの種類にさらに分類されてもよい。セッション境界コントローラ（ＳＢＣ：Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ）を例として、制御プレーン上のセッション開始プロトコル（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）シグナリングと、メディアプレーン上のリアルタイム伝送プロトコル（ＲＴＰ：Ｒｅａｌ－Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）リアルタイム伝送制御プロトコル（ＲＴＣＰ：Ｒｅａｌ－Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）データパケットとが同時に収集されて同じ収集解析装置に振り分けられ、それから、収集解析装置は、ＳＩＰシグナリングとＲＴＰ／ＲＴＣＰデータパケットとから、関連フィールドを抽出及び記入してシグナリングＸＤＲとサービスＸＤＲとを生成する。

【0004】

しかしながら、上記のプロセスは、制御プレーンとユーザプレーンとが分離していない場合に、シグナリングとサービスデータとが同じ収集解析装置により処理されるときにのみ有効である。制御プレーンとユーザプレーンとを分離させる構想が適用されたネットワーク要素については、そのシグナリングとサービスデータとがもはや同じ収集解析装置により処理されないため、サービスＸＤＲ内の、制御プレーン情報に依存してはじめて記入できるフィールドが欠落し、完全で有効なサービスＸＤＲを得ることができない。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本願の実施例の主な目的は、制御プレーンとユーザプレーンとが分離している場合にも完全で正確なサービスＸＤＲを取得することができるようにするために、サービスＸＤＲの取得方法、装置及び記憶媒体を提案することにある。

【課題を解決するための手段】

【0006】

上記目的を達成するために、本願の実施例は、第１の装置に適用される、サービスＸＤＲの取得方法を提供し、この方法は、第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するステップと、前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するステップと、前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するステップと、を含む。

【0007】

上記目的を達成するために、本願の実施例は、第２の装置に適用される、サービスＸＤＲの取得方法をさらに提供し、この方法は、ユーザプレーンからサービスデータを収集するステップと、前記サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成するステップと、前記サービスＸＤＲを第１の装置に送信するステップと、を含む。

【0008】

上記目的を達成するために、本願の実施例は、第３の装置に適用される、サービスＸＤＲの取得方法をさらに提供し、この方法は、制御プレーンからシグナリングを収集するステップと、前記シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成するステップと、前記シグナリングＸＤＲを第１の装置に送信するステップと、を含む。

【0009】

上記目的を達成するために、本願の実施例は、装置をさらに提案し、この装置は、第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するのに用いられる受信モジュールと、前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するのに用いられる検索モジュールと、前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するのに用いられる更新モジュールと、を備える。

【0010】

上記目的を達成するために、本願の実施例は、装置をさらに提案し、この装置は、ユーザプレーンからサービスデータを収集するのに用いられる第１の収集モジュールと、前記サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成するのに用いられる第１の生成モジュールと、前記サービスＸＤＲを第１の装置に送信するのに用いられる第１の送信モジュールと、を備える。

【0011】

上記目的を達成するために、本願の実施例は、装置をさらに提案し、この装置は、制御プレーンからシグナリングを収集するのに用いられる第２の収集モジュールと、前記シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成するのに用いられる第２の生成モジュールと、前記シグナリングＸＤＲを第１の装置に送信するのに用いられる第２の送信モジュールと、を備える。

【0012】

上記目的を達成するために、本願の実施例は、電子機器をさらに提案し、前記電子機器は、少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサと通信可能に接続されたメモリとを含み、前記メモリには前記少なくとも１つのプロセッサにより実行できる命令が記憶されており、前記命令が前記少なくとも１つのプロセッサにより実行されることで、前記少なくとも１つのプロセッサが上記の何れか一項に記載のサービスＸＤＲの取得方法を実行できるようにする。

【0013】

上記目的を達成するために、本願の実施例は、コンピュータ可読記憶媒体をさらに提案し、前記コンピュータ可読記憶媒体は、プロセッサにより実行された場合に上記の何れか一項に記載のサービスＸＤＲの取得方法を実現するコンピュータプログラムを記憶している。

【0014】

（有益な効果）
本願が提案するサービスＸＤＲの取得方法は、従来の、シグナリングに基づいてシグナリングインタラクションのプロセスを完全に記録するシグナリングＸＤＲを生成することに加えて、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成される別の種類のシグナリングＸＤＲをさらに追加した。この種類のシグナリングＸＤＲは、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成されるため、シグナリング内の、サービスに関する情報を記録している。こうして、第１の装置は、第２の装置により送信されたサービスＸＤＲと第３の装置により送信されたシグナリングＸＤＲとを受信した後に、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索し、そして、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新することができるため、サービスＸＤＲ内の、制御プレーン情報に依存してはじめて記入できるフィールドを、ターゲットシグナリングＸＤＲに従って記入することができるようにし、これにより、制御プレーンとユーザプレーンとが分離している状態であるとしても、完全なサービスＸＤＲを得ることができる。

【0015】

一つ又は複数の実施形態をそれに対応する添付図面中の画像によって例示的に示し、これらの例示的な説明は、実施形態に対する限定を構成するわけではない。

【図面の簡単な説明】

【0016】

【図1】本願の関連技術における、制御プレーンとユーザプレーンとが分離していないときのＳＢＣネットワークアーキテクチャの模式図である。

【図2】本願の関連技術における、制御プレーンとユーザプレーンとが分離していないときのサービスＸＤＲとシグナリングＸＤＲとの生成の模式図である。

【図3】本願の関連技術における、制御プレーンとユーザプレーンとが分離しているときのＳＢＣネットワークアーキテクチャの模式図である。

【図4】本願の一実施例において提供される、第１の装置に適用されるサービスＸＤＲの取得方法のフローチャートである。

【図5】本願の一実施例において提供される、制御プレーンとユーザプレーンとが分離していないときのデータ収集の模式図である。

【図6】本願の別の実施例において提供される、第２の装置に適用されるサービスＸＤＲの取得方法のフローチャートである。

【図7】本願の別の実施例において提供される、第３の装置に適用されるサービスＸＤＲの取得方法のフローチャートである。

【図8】本願の別の実施例において提供される、セッション中のシグナリングインタラクションの模式図である。

【図9】本願の別の実施例において提供される装置の構成模式図である。

【図10】本願の別の実施例において提供される装置の構成模式図である。

【図11】本願の別の実施例において提供される装置の構成模式図である。

【図12】本願の別の実施例において提供される電子装置の構成模式図である。

【発明を実施するための形態】

【0017】

背景技術から分かるように、サービスＸＤＲとシグナリングＸＤＲとを生成する従来の方式は、ネットワーク要素の制御プレーンとユーザプレーンとが分離していない場合にのみ有効であり、ネットワークの制御プレーンとユーザプレーンとが分離してもなお完全なサービスＸＤＲを取得できる方法が求められている。

【0018】

分析の結果、上記問題が発生する主な原因は、ボイス・オーバー・ロングタームエボリューション（ＶｏＬＴＥ：Ｖｏｉｃｅ ｏｖｅｒ Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）／ボイス・オーバー・Ｎｅｗ Ｒａｄｉｏ（ＶｏＮＲ：Ｖｏｉｃｅ ｏｖｅｒ Ｎｅｗ Ｒａｄｉｏ）のユーザがＩＰマルチメディアシステム（ＩＭＳ：ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ネットワークのＳＢＣネットワーク要素にアクセスする場合を例として、制御プレーンＳＩＰシグナリングフローとメディアプレーンＲＴＰ／ＲＴＣＰデータフローとを処理する機能を有し、制御プレーンＳＩＰシグナリングフローとメディアプレーンＲＴＰ／ＲＴＣＰメディアフローとを処理することができる。制御プレーンとユーザプレーンとが分離していない場合、図１に示すように、制御プレーン上のＳＩＰシグナリングも、メディアプレーン上のＲＴＰ／ＲＴＣＰデータパケットも、ユーザプレーン機能（ＵＰＦ：Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）とＳＢＣとの間の通信のＧｍインターフェースに基づいてＵＰＦからＳＢＣに入力される。このとき、制御プレーン上のＳＩＰシグナリング、メディアプレーン上のＲＴＰ／ＲＴＣＰデータパケットは同じファイバ上で収集され、また、同一の呼について、２種類のデータのユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）側ＩＰアドレス、ＳＢＣ側ＩＰアドレスも同じである。したがって、サービスＸＤＲとシグナリングＸＤＲとを生成するシナリオにおいては、図２に示すように、ＳＢＣ側では、制御プレーン上のＳＩＰシグナリングとメディアプレーン上のＲＴＰ／ＲＴＣＰデータパケットが同時に収集され、同じ収集解析装置に振り分けられ、これにより、収集解析装置は、サービスＸＤＲを処理する際に、制御プレーン上のＳＩＰシグナリングから情報を直接抽出して、サービスＸＤＲ内の、制御プレーン情報に依存してはじめて記入できるフィールドに埋めることができる。一方、制御プレーンとユーザプレーンとが分離している場合、図３に示すように、元のＳＢＣネットワーク要素は、制御プレーン上のＳＩＰシグナリングを処理するセッション境界コントローラ制御プレーン（ＳＢＣ－Ｃ：Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ－Ｃｏｎｔｒｏｌ）と、メディアプレーン上のＲＴＰ／ＲＴＣＰデータを処理するセッション境界コントローラユーザプレーン（ＳＢＣ－Ｕ：Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ－Ｕｓｅｒ）と、の２つの物理エンティティに分割される。こうして、制御プレーン上のＳＩＰシグナリングフローは、Ｇｍインターフェースに基づいてＵＰＦからルーティングされてＳＢＣ－Ｃに入力され、ＳＢＣ－Ｃは、仮想ネットワーク要素であり、大区（中国華北、華東などのような行政区画）のネットワーク機能仮想化（ＮＦＶ：Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）リソースプール内にデプロイされ、一方、メディアプレーンＲＴＰ／ＲＴＣＰデータはＵＰＦからルーティングされてＳＢＣ－Ｕに入力され、ＳＢＣ－Ｕは省（中国安徽省、河北省などのような行政区画）内にデプロイされる。このとき、制御プレーンデータ、メディアプレーンデータは、それぞれ大区、省内で収集され、同一の呼について、２種類のデータのＵＥ側ＩＰアドレスは同じであり、ＳＢＣ－Ｃ／ＳＢＣ－Ｕ側ＩＰアドレスは異なる。また、１つのＳＢＣ－Ｃ内のＳＩＰシグナリングに対応するＲＴＰ／ＲＴＣＰデータは複数のＳＢＣ－Ｕ上に分散する可能性があるとともに、１つのＳＢＣ－Ｕ内のＲＴＰ／ＲＴＣＰデータに対応するＳＩＰシグナリングも複数のＳＢＣ－Ｃ上に分散する可能性がある。即ち、ＳＢＣ－ＣとＳＢＣ－Ｕとの間は１つの網状のネットワークであり、単にＳＢＣ－Ｃ／ＳＢＣ－ＵのＩＰアドレス関係によって同一の呼中の２種類のデータが同じ収集解析装置に振り分けられることを保証することができない。したがって、ＶｏＬＴＥ／ＶｏＮＲサービスが、ＳＩＰシグナリングについてＳＩＰ ＸＤＲを出力することに加えて、音声品質を評価するために、メディアプレーン上のＲＴＰ／ＲＴＣＰスライスＸＤＲ、即ちサービスＸＤＲを出力する必要がある場合、サービスＸＤＲ内の一部のフィールドの生成が、制御プレーン上からの情報抽出、又は制御プレーンのパラメータ計算に依存するため、サービスＸＤＲの一部のフィールドが欠落するか、又は完全に正確ではなくなる。ここで、ＲＴＰ／ＲＴＣＰスライスＸＤＲ内の、制御プレーンの情報に依存してはじめて記入できるフィールドは、次の表１に示す。

【表1】

【0019】

上述した課題を解決するために、本願の実施例は、第１の装置に適用される、サービスＸＤＲの取得方法を提供し、この方法は、第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成された前記サービスＸＤＲを受信するステップと、前記サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、前記第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するステップと、前記ターゲットシグナリングＸＤＲに従って前記サービスＸＤＲを更新するステップと、を含む。

【0020】

本願が提案するサービスＸＤＲの取得方法は、従来の、シグナリングに基づいてシグナリングインタラクションのプロセスを完全に記録するシグナリングＸＤＲを生成することに加えて、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成される別の種類のシグナリングＸＤＲをさらに追加した。この種類のシグナリングＸＤＲは、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成されるため、シグナリング内の、サービスに関する情報を記録している。こうして、第１の装置は、第２の装置により送信されたサービスＸＤＲと第３の装置により送信されたシグナリングＸＤＲとを受信した後に、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索し、そして、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新することができるため、サービスＸＤＲ内の、制御プレーン情報に依存してはじめて記入できるフィールドを、ターゲットシグナリングＸＤＲに従って記入することができるようにし、これにより、制御プレーンとユーザプレーンとが分離している状態であるとしても、完全なサービスＸＤＲを得ることができる。

【0021】

本願実施例の目的、技術案及び利点をより明らかにするために、以下では、添付図面を組み合わせて本願の各実施例を詳しく説明する。しかしながら、当業者であれば、本願の各実施例において、読み手に本願をよりよく理解してもらうために多くの技術的詳細が提示されていることを理解することができる。しかしながら、これらの技術的詳細及び以下の各実施例に基づく様々な変更及び修正がなくとも、本願の保護を求める技術案を実現することができる。以下の各実施例の区分は、説明の便宜のためになされており、本願の具体的な実施例にいかなる限定を構成すべきではなく、各実施例は、矛盾しない限り、組み合わせたり互いに参照したりしてもよい。

【0022】

本願の実施例の一態様は、第１の装置に適用されるサービスＸＤＲの取得方法を提供し、この方法のフローは図４に示すようであり、少なくとも以下のようなステップを含んでもよい。

【0023】

ステップ４０１において、第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成されたサービスＸＤＲを受信する。

【0024】

ネットワーク要素のユーザプレーンと制御プレーンとが分離している場合、ユーザプレーンのデータと制御プレーンのデータとはもはや同じ装置では収集されることができなくなるので、図５に示すように、ユーザプレーン上のサービスデータと制御プレーン上のシグナリングとを、２つの装置を用いてそれぞれ収集する必要がある。

【0025】

本実施例において、第２の装置は、ネットワーク要素の分離後のユーザプレーンからサービスデータを収集し、収集したサービスデータに基づいてサービスＸＤＲを生成するのに用いられ、ここで、ネットワーク要素は、ユーザプレーンと制御プレーンとが分離している任意のネットワーク要素、例えば、ＵＰＦ、ＳＢＣ等であってもよい。

【0026】

ステップ４０２において、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索する。

【0027】

本実施例において、サービスとシグナリングとの事前設定された関連付けは、サービスのタイプとシグナリングのタイプとに関連し、ＶｏＬＴＥサービスを例にとると、制御プレーン上で伝送されるシグナリングはＳＩＰシグナリングであり、ユーザプレーン上で伝送されるサービスデータは主にＲＴＰ／ＲＴＣＰデータパケットであるため、サービスとシグナリングとの事前設定された関連付けは、サービスとシグナリングとが同じセッションからのものであることなどであってもよい。

【0028】

なお、本実施例におけるシグナリングＸＤＲは、シグナリングに基づいて生成されるのではなく、シグナリング内の一部の情報、即ちサービスに関する情報に基づいて生成されるのであることも、強調する必要がある。これは、シグナリングには、シグナリングの送受信時間など様々な情報が含まれるが、全ての情報をシグナリングＸＤＲに含める必要があるわけではないことを考慮してのことである。サービスＸＤＲの取得に有利になる情報、即ちサービスに関する情報に関心がもたれるため、既存のシグナリングＸＤＲ生成モードの下で、シグナリング内の、サービスに関する情報に基づいて生成されるシグナリングＸＤＲを１種類新しく追加することができ、それにより、データ量を減らし、実現の難度を低減させ、伝送を容易にすることができる。ＸＤＲは通常、定義されたインターフェースに基づいて実現されるため、シグナリングＸＤＲを１種類新しく追加することは実際にはインターフェースを１つ余分に追加することに相当する。ただし、ＳＤＰ ＸＤＲのサイズは極めて小さく、数も少ないため、このインターフェースを追加することは既存装置の性能にほとんど影響しないと同時に、サービスＸＤＲの受信側などはインターフェースの追加による変化を感知しない。

【0029】

いくつかのシグナリングについては、１回のサービスサービスを提供する間に複数のシグナリングＸＤＲが生成され得ることを、理解すべきである。例えば、ＶｏＬＴＥサービスを実現する間に、シグナリングＸＤＲは、既存のＳＩＰ ＸＤＲを取得することに加えて余分に取得されるＳＤＰ ＸＤＲとして定義され得るため、１つのセッションには、複数回のメディアネゴシエーションにより複数のＳＤＰ ＸＤＲが生成され得る。さらに、１つのサービスＸＤＲは１つよりも多いＳＤＰ ＸＤＲに対応する可能性があり、この場合、第１の装置がサービスＸＤＲを受信したときにそれを更新するために正確且つ十分なシグナリングＸＤＲを得ることができるように、シグナリングＸＤＲの維持を考慮する必要がある。さらに、サービスＸＤＲとシグナリングＸＤＲとは、必ずしも同時に生成されるか、又は第１の装置に送信されるわけではないため、第１の装置がサービスＸＤＲを受信したときにそれを更新するために正確且つ十分なシグナリングＸＤＲを得ることができるように、シグナリングＸＤＲの維持を考慮する必要もある。

【0030】

これに基づいて、いくつかの例において、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するステップの前に、サービスＸＤＲの取得方法は、第３の装置により送信されたシグナリングＸＤＲを受信するステップと、受信したシグナリングＸＤＲをローカルキャッシュにキャッシュするステップと、をさらに含む。したがって、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索することは、サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、ローカルキャッシュの中からターゲットシグナリングＸＤＲを検索することにより、実現されることが可能である。

【0031】

特に、スペースの節約のために、及び過去の情報による最新情報への干渉を回避するために、最新のシグナリングＸＤＲを受信するたびに、過去に受信したシグナリングＸＤＲに基づいて決定されたサービス情報を修正したり、受信した最新のシグナリングＸＤＲを保存したりすることもでき、ここでは説明を省く。

【0032】

ステップ４０３において、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新する。

【0033】

なお、第３の装置により送信されるサービスＸＤＲは、制御プレーンの情報の欠落によりフィールドに欠落が生じる可能性があるため、第２の装置により送信されるシグナリングＸＤＲを用いて、欠落フィールドを記入する必要がある。また、収集した情報を用いて、明確に決定できない関連フィールドについて予測し、予測情報に基づいて記入する可能性もあるため、シグナリングＸＤＲを用いててフィールドが正しいか否かを検証し、修正するなどの必要がある。

【0034】

これに基づいて、いくつかの例において、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新することは、サービスＸＤＲ内の欠落フィールドを特定することと、ターゲットシグナリングＸＤＲから欠落フィールドに関する情報を検索し、検索された情報に基づいて充填フィールドを生成することと、充填フィールドをサービスＸＤＲに充填することと、により実現されることが可能である。ここで、サービスＸＤＲ内の欠落フィールドを特定する前に、まずサービスＸＤＲを検査してフィールド欠落状態が発生している否かを決定し、フィールド欠落状態の発生が検出されたときに、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲにフィールドを埋め戻すことにより、サービスＸＤＲの更新を達成するようにしてもよい。

【0035】

別のいくつかの例において、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新することは、ターゲットシグナリングＸＤＲとサービスＸＤＲとの間に、シグナリングＸＤＲ及びサービスＸＤＲ内で同じ対象を記述するフィールドである関連フィールドの不一致が検出された場合、サービスＸＤＲ内の対応する関連フィールドを修正することにより、実現されることも可能である。

【0036】

なお、上記の例は、それぞれフィールド欠落とフィールド誤りの側面から個別に説明したが、他の例において、フィールド欠落の有無を検出してからフィールド誤りの有無を検出することにより、両者を組み合わせて実施することもできるが、ここでは説明を省く。

【0037】

なお、前述した分析のように、サービスＸＤＲは１つよりも多いシグナリングＸＤＲに対応する可能性があり、シグナリングＸＤＲが失効した場合、それによって占有されているリソースを回収することが考えられる。これに基づいて、サービスＸＤＲに対応するサービスの終了が検出された場合、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新することはさらに、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新し、更新されたサービスＸＤＲに、サービスの終了を示す情報を追加し、ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新した後に、サービスＸＤＲに対応するシグナリングＸＤＲを維持するのに用いられるリソースを解放することにより、実現されることが可能である。例えば、ＳＩＰセッションが終了した後に、第１の装置は、その該ＳＩＰセッションの更新された最後のＲＴＰ／ＲＴＣＰサービスＸＤＲに通話終了タグを付け、シグナリングＸＤＲを記憶するために占有されているリソースを解放する。

【0038】

特に、第１の装置により受信されたシグナリングＸＤＲに含まれる、サービスＸＤＲの記入に有利な情報が空集合である場合、サービスＸＤＲの更新を達成するために、いくつかの数学的処理方法又はアルゴリズムなどを用いて一部のデータを予測してもよい。例えば、ＶｏＬＴＥ／ＶｏＮＲサービスＸＤＲを処理する場合、サービスＸＤＲに基づいて音声ビデオの具体的なタイプに強く関連している一部のジッタ、符号化レートに関連しているフィールド（例えばＲＴＣＰ Ｊｉｔｔｅｒ、Ｃｏｄｅｃ Ｒａｔｅ、Ｆｒａｍｅ Ｒａｔｅ）を特定できなければ、まず不明なＳｅｒｖｉｃｅ Ｔｙｐｅ（表１）を明確にし、そして、予め判断したＳｅｒｖｉｃｅ Ｔｙｐｅの結果に基づいて、他のフィールドについて計算や予測を行ってもよい。音声ビデオ関連の評価アルゴリズムは、ＲＴＰメッセージのｐａｙｌｏａｄの長さ及びｔｉｍｅｓｔａｍｐなどの情報に基づいて仮の評価を行う。さらに、サービスＸＤＲを修正して更新を実現する例においても、類似の方法を用いて、シグナリングＸＤＲ内のＳｅｒｖｉｃｅ Ｔｙｐｅを介して関連フィールドを修正してもよい。

【0039】

本願の実施例の別の態様は、第２の装置に適用されるサービスＸＤＲの取得方法をさらに提供し、この方法のフローは図６に示すようであり、少なくとも以下のようなステップを含んでもよい。

【0040】

ステップ６０１において、ユーザプレーンからサービスデータを収集する。

【0041】

本実施例において、サービスデータは、データパケット、メッセージ等であってもよい。サービスデータの収集は、プローブを設置するなどハードウェア収集の方式を用いて実現されることができる。

【0042】

ステップ６０２において、サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成する。

【0043】

本実施例において、非制御関連フィールドは、制御プレーンのデータに依存する必要がなく、サービスデータから決定可能なフィールドである。

【0044】

いくつかの例において、サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成することは、制御プレーンの情報に依存して決定される必要のないフィールドを特定し、特定されたフィールドに基づいてサービスデータから情報を抽出し対応するフィールドを生成し、生成されたフィールドに基づいてサービスＸＤＲを得ることにより、実現されることが可能である。

【0045】

別のいくつかの例において、サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成することの後に、さらに、サービスデータに基づいて制御プレーン情報に関するフィールドについて計算、予測を行い、サービスＸＤＲに記入し、サービスＸＤＲをさらに補完する。

【0046】

なお、サービスＸＤＲは、制御プレーン情報に関するフィールドの欠落を許容し、制御プレーン情報に関するフィールドの情報の偏りの存在を許容し、それが第２の装置により第１の装置に送信されたとき、第１の装置は、第３の装置により送信されたシグナリングＸＤＲを受信することにより、補足及び修正をすることができる。

【0047】

特に、サービスＸＤＲは、アップリンクサービスとダウンリンクサービスをそれぞれ記録する２つのＸＤＲや２つのサブＸＤＲなど、２つの部分に分けられてもよいが、ここでも説明を省く。

【0048】

ステップ６０３において、サービスＸＤＲを第１の装置に送信する。

【0049】

本願の実施例の別の態様は、第３の装置に適用されるサービスＸＤＲの取得方法をさらに提供し、この方法のフローは図７に示すようであり、少なくとも以下のようなステップを含んでもよい。

【0050】

ステップ７０１において、制御プレーンからシグナリングを収集する。

【0051】

本実施例において、シグナリングの収集は、プローブを設置するなどハードウェア収集の方式を用いて実現されることができる。

【0052】

ステップ７０２において、シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成する。

【0053】

本実施例は、シグナリング内の、サービスに関する情報の表現形式を限定せず、シグナリングＸＤＲにより記録される制御情報の周期性又はサービスにおける段階を限定しない。例えば、サービスがストリーミングメディアサービスである場合、それはＳＤＰメッセージボディ内の、メディアフローに関する情報であってもよく、１つのシグナリングＸＤＲは、１回のセッションにおける関連する複数回のメディアネゴシエーションプロセスで伝送される複数のＳＤＰメッセージボディのレコードであってもよく、１回のメディアネゴシエーションプロセス中のＳＤＰメッセージボディのレコードであってもよい。

【0054】

ＶｏＮＲを例にとると、現在では、ＳＢＣのＳＩＰ ＸＤＲについての記述が既に存在するが、これに加えて、本実施例において、ＳＤＰ ＸＤＲ、即ち、収集された制御プレーンＳＩＰシグナリングに基づいて生成されたＳＤＰネゴシエーションプロセスの詳細なレコードを出力することを新しく追加する。ここで、ＳＩＰ ＸＤＲにおける呼フローの出力タイミングは依然として、初期Ｉｎｖｉｔｅ要求の最終応答の受信時及びセッション終了応答の受信時であり、これは従来のメカニズムと同じであり、変更されていない。一方、ＳＩＰ ＸＤＲが２回しか出力されないのとは異なり、合成サーバがメディアネゴシエーション結果を適時に取得できることを保証するために、ＳＤＰメディアネゴシエーションを行うたびに、終了時に１つのＳＤＰ ＸＤＲを出力する必要がある。ＳＩＰ呼フローが通常複雑であるため、図８は、ＳＤＰ ＸＤＲの作成から出力までのタイミングを概ね反映することができる。図８におけるＳＤＰ ＯｆｆｅｒとＳＤＰ Ａｎｓｗｅｒは即ちＳＤＰの提供／応答モデルであり、ＳＤＰ ＸＤＲは即ち、収集する必要のある、ＳＤＰメッセージボディ内の、メディアフローに関する情報である。図８から分かるように、１回のＳＩＰセッション中に複数回のメディアネゴシエーションがあり、セッション確立後であってもセッションの修正、つまり新たなメディアネゴシエーションが発生し、毎回のメディアネゴシエーションプロセス中に収集されたＳＤＰメッセージボディについて１つのＳＤＰ ＸＤＲを生成することができる。

【0055】

ステップ７０３において、シグナリングＸＤＲを第１の装置に送信する。

【0056】

なお、上述した方法実施例は、第１の装置、第２の装置及び第３の装置の角度から、サービスＸＤＲの取得方法をそれぞれ説明したのは、異なる機能の実現の説明を容易にするためであり、異なる実体装置により実現されなければならないことを意味するわけではない。例えば、第１の装置と第２の装置とが同じ実体装置に統合されてもよく、したがって、関連する送信及び受信は実際には装置内部の通信プロセスであり、ここでは説明を省く。

【0057】

上述した実施例に言及されたサービスＸＤＲの取得方法を当業者がより理解しやすくするために、以下では、シグナリングＸＤＲがＳＤＰ ＸＤＲであり、サービスＸＤＲがＲＴＰ／ＲＴＣＰ ＸＤＲである場合について説明するが、ここでは従来の処理フローとの区別を説明しやすくするために、以下にＳＩＰ ＸＤＲをさらに導入する。

【0058】

まず、第３の装置は、取得したＳＩＰメッセージのＲｅｑｕｅｓｔ－ＵＲＩ内のｍｅｔｈｏｄ＝ＩＮＶＩＴＥにより、呼要求メッセージを認識し、呼フローの処理に必要なリソースを申請し、シグナリングの復号化を行う。そして、第３の装置は、符号化から関連情報要素を抽出して収集規範内の対応するインターフェースフィールドに記入することにより、ＳＩＰ呼のためにＳＩＰ ＩｎｖｉｔｅトランザクションＸＤＲを作成すること、ＳＩＰセッションＸＤＲを作成すること、及びＳＩＰ Ｉｎｖｉｔｅメッセージ内で搬送されるＳＤＰメッセージのために１番目のＳＤＰ ＸＤＲ＿１を作成することを実現する。このＳＤＰ ＸＤＲは、その後ＲＴＰ／ＲＴＣＰ ＸＤＲの更新のために使用される必要があり、ここで、ＳＤＰ ＸＤＲで搬送される情報は同様に、必須フィールドとオプションフィールドとを含み、必須フィールドは、複数のＸＤＲに関連付けられるキーであり、少なくともＳＩＰ ＣａｌｌＩＤ、ＳｅｓｓｉｏｎＩＤ、Ｕｓｅｒ＿Ｔｙｐｅ、発呼者／被呼者番号、ソース及び宛先メディアストリームＩＰアドレスを含む必要がある。一方、オプションフィールドは、ＳＤＰから抽出されるメディアストリームの品質を反映させる関連情報であり、ソースメディアＩＰアドレス、宛先ＩＰアドレス、メディアストリーム数、メディアネゴシエーション結果などを含む。この場合、フィールドの記入はＩｎｖｉｔｅ要求メッセージを受信した時点で行われるため、記入されるのは全て発呼側のメディア情報である。特に、新しく追加されるＳＤＰ＿ＸＤＲインターフェースは『中国移動５Ｇネットワーク接続ログ保存システム技術規範－制御プレーン収集解析装置インターフェース規範２．０．ｄｏｃｘ』内のインターフェース定義規範を参考でき、以下のように設計されている。

【表2】

【0059】

もちろん、他の方式を参考にしたり、自主的にサービスＸＤＲを形成したりしてもよく、上の表は具体的な例を示した説明だけである。

【0060】

次に、第３の装置は、ＳＩＰ １８３などの非１００、非３ＸＸ－６ＸＸ間の非失敗応答メッセージを収集し、この場合、まず、ＳＩＰ関連情報を抽出し、ＳＩＰトランザクションＸＤＲ内の被呼側情報を記入し、ＳＩＰセッションＸＤＲ内の被呼側情報を記入する必要がある。当該メッセージもＳＤＰを搬送している場合、ＳＤＰ情報を解析し、ＳＤＰ ＸＤＲ＿１内の被呼側が搬送している情報を埋めると同時に、ＳＩＰセッション内の一部の制御プレーン情報をＳＤＰ ＸＤＲ＿１内のＳＩＰ関連フィールドに埋める。処理が完了し、ＳＩＰトランザクションＸＤＲ、ＳＤＰ ＸＤＲを出力し、ＩＦ１インターフェースから第１の装置に送信する。ＳＩＰセッション中、メディアネゴシエーションがうまくいかなかった場合、ＳＩＰプロトコルの規定によれば、双方は、ネゴシエーションが成功するまで、対話内の後続メッセージによりメディアネゴシエーションを続ける。最初のネゴシエーションが失敗し、発呼者が開始したＵｐｄａｔｅメッセージが再び受信された場合、第３の装置は、ＳＤＰ ＸＤＲ＿２を新たに作成し、ＳＤＰメッセージを解析し、ＳＤＰ ＸＤＲ＿２内の発呼者側情報を記入する。なお、ネゴシエーション要求があれば必ず応答があるので、２００ＯＫ（Ｕｐｄａｔｅ）のようなネゴシエーション応答を受信すると、第３の装置は、ＳＤＰメッセージを解析し、ＳＤＰ ＸＤＲ＿２に被呼側情報を記入する。そして、このＳＩＰセッション内の関連情報をＳＤＰ ＸＤＲ＿２内のＳＩＰシグナリング関連フィールドに記入し、ＳＤＰ ＸＤＲフィールドの処理を完了させ、直ちにＩＦ１を介して送信する。このように、メディアネゴシエーションを複数回行う場合、そのたびに前述のようにＳＤＰ ＸＤＲが出力される。特に、例えばネットワークの原因で音声／ビデオ通信から音声のみ通信に調整されるために、セッション確立からセッション終了までの間にメディア更新が開始される可能性もあり、この場合も、前述した方式に従ってＳＤＰ ＸＤＲを処理及び出力する。第３の装置がＢｙｅメッセージを受信すると、呼が終了し、または、内部セッションキープアライブタイマが満了すると、呼時間間隔及び呼終了情報などのフィールドをＳＩＰセッションＸＤＲに入力する。

【0061】

なお、ＳＤＰ ＸＤＲ内の、ＳＩＰ関連のフィールドの記入は、前述のようにＳＤＰを先に処理してからＳＩＰを処理するという順番ではなく、ＳＤＰ ＸＤＲの作成時に記入してもよい。なお、ＳＤＰ ＸＤＲに含まれるセッションＩＤ、ＣａｌｌＩＤ、発呼者／被呼者番号などの情報は、ＳＩＰセッションＸＤＲとともに管理されてもよく、ＳＤＰ ＸＤＲの出力時に抽出されてもよい。

【0062】

第２の装置によるＲＴＰ／ＲＴＣＰ ＸＤＲの生成については、その主な原則は、スライス方向、スライス開始時間、スライス終了時間、パケット受信数、パケット損失数、リンク情報など正確で異議のないフィールド情報をできるだけ記入し、その他の制御プレーンにより搬送される関連情報に依存して決定されるフィールドについてはしばらく見合わせることである。

【0063】

特に、ユーザプレーンメディアデータを処理するメディアサブモジュールは、ＳＢＣがＣＵ分離デプロイを採用してＶｏＬＴＥ／ＶｏＮＲメディアＸＤＲを処理する場合、音声／ビデオタイプｂＳｅｒｖｅｒＴｙｐｅフィールドの記入について、まず事前判定を行うことができ、事前判定ルールとして、２つの連続するＲＴＰメッセージのｔｉｍｅｓｔａｍｐが同じである場合、ｂＳｅｒｖｅｒＴｙｐｅフィールドがビデオを示すと判定し、２つの連続するＲＴＰメッセージのｔｉｍｅｓｔａｍｐが異なり、且つ、ｐａｙｌｏａｄ長がいずれも５００バイトより小さい場合、ｂＳｅｒｖｅｒＴｙｐｅフィールドが音声を示すと判定し、２つの連続するＲＴＰメッセージのｔｉｍｅｓｔａｍｐが異なり、且つ、ｐａｙｌｏａｄ長がいずれも５００バイトより大きい場合、ｂＳｅｒｖｅｒＴｙｐｅフィールドがビデオを示すと判定し、また、ｂＳｅｒｖｉｃｅＴｙｐｅが認識されない場合、パケット受信数、パケット損失数などのみをカウントし、ジッタに関するパラメータや符号化レートに関するパラメータを計算しない。

【0064】

一方、第１の装置は、第３の装置により送信されたＳＤＰ＿ＸＤＲ＿１を受信した場合、その中の全ての情報をＳＤＰ Ｉｎｆｏ内にキャッシュする必要があり、その後に同じＳＩＰセッション内のＳＤＰ＿ＸＤＲ＿ｎをまた受信すれば、メディアネゴシエーションに変化があり、新しいＳＤＰ＿ＸＤＲを受信すると、もはや使用されなくなるメディアストリーム情報を削除し、新しく追加されたメディアストリーム情報を追加する必要があり、即ち、キャッシュされた情報を即時にアップデートする必要がある。第２の装置により送信されたＲＴＰ／ＲＴＣＰ ＸＤＲを受信した場合、ＲＴＰ／ＲＴＣＰ ＸＤＲに欠落が発生していれば、キャッシュされたメディアストリーム情報を関連情報を用いて探し、見つからない場合、まずスライス呼レコードを５秒キャッシュし、具体的な時間を設定することができ、タイムアウト後に埋め戻しを再び試行し、関連するメディアストリーム情報が見つかった場合、関連埋め戻しを開始する。具体的には、Ｓｅｓｓｉｏｎ＿ＩＤ、発呼者／被呼者番号、Ｓｔｒｅａｍ １ Ｓｅｒｖｉｃｅ＿Ｔｙｐｅ、Ｒｅｓｏｌｕｔｉｏｎ＿Ｗｉｄｔｈ、Ｒｅｓｏｌｕｔｉｏｎ＿Ｈｅｉｇｈｔなどの静的な情報を関連埋め戻しし、ＲＴＰ／ＲＴＣＰ ＸＤＲとＳＤＰ ＸＤＲとの間に関連フィールドの不一致が発生した場合、ＳＤＰ＿Ｉｎｆｏ内のＳｅｒｖｅｒＴｙｐｅをスライスＸＤＲに更新し、スライスＸＤＲ内のＲＴＰの遅延、ジッタ等のフィールドを新しい値に従って計算して記入する。特に、メディアプロトコルマシンが事前判定時にＲＴＰ遅延、ジッタ等の関連フィールドについて事前判定結果に従って計算している場合、その時点で不一致を発見すれば、元の計算を修正する必要がある。ここで、ＲＴＰ／ＲＴＣＰ ＸＤＲとＳＤＰ ＸＤＲとの間に関連フィールドの不一致が発生しているか否かを判定することは、関連するＳＤＰ＿Ｉｎｆｏ情報を見つけ、ＳｅｒｖｅｒＴｙｐｅフィールドの値を取得した場合、ＳＤＰ ＸＤＲ内のＳｅｒｖｅｒＴｙｐｅとスライス内のＳｅｒｖｅｒＴｙｐｅとが一致しているか否かを比較することができる。

【0065】

特に、Ｃ／Ｕが分離している場合のＲＴＰ／ＲＴＣＰ ＸＤＲ内のフィールドの修正は、ＣＵが統合されたシナリオにも適しており、新しく追加されるＳＤＰ ＸＤＲは、中間のネゴシエーションも記録されるので、ＣＵが統合された場合のＲＴＰ／ＲＴＣＰ ＸＤＲの出力されるデータをより正確にすることができる。

【0066】

なお、上記の各種方法のステップ分けは、単に明確に説明するためになされたものであり、実装時に１つのステップに統合するか、又は一部のステップを複数のステップに再分割することができ、同一の論理的関係が含まれていれば、いずれも本願の保護範囲内に含まれること、アルゴリズム及びプロセスの中核となる設計を変更せずに、そのアルゴリズム又はプロセスに重要でない修正を加えたり、又は重要でない設計を導入したりしたものであれば、いずれも本願の保護範囲内に含まれることを、理解すべきである。

【0067】

本願の実施例の別の態様は装置をさらに提供し、図９に示すように、この装置は、
第２の装置により送信されたサービスＸＤＲであって、ユーザプレーンから収集されたサービスデータに基づいて生成されたサービスＸＤＲを受信するのに用いられる受信モジュール９０１と、
サービスＸＤＲと、サービスとシグナリングとの事前設定された関連付けとに基づいて、第３の装置により送信されたシグナリングＸＤＲであって、制御プレーンから収集されたシグナリング内の、サービスに関する情報に基づいて生成された前記シグナリングＸＤＲの中からターゲットシグナリングＸＤＲを検索するのに用いられる検索モジュール９０２と、
ターゲットシグナリングＸＤＲに従ってサービスＸＤＲを更新するのに用いられる更新モジュール９０３と、を備える。

【0068】

本願の実施例の別の態様は装置をさらに提供し、図１０に示すように、この装置は、
ユーザプレーンからサービスデータを収集するのに用いられる第１の収集モジュール１００１と、
サービスデータに基づいて、非制御関連フィールドに記入してサービスＸＤＲを生成するのに用いられる第１の生成モジュール１００２と、
サービスＸＤＲを第１の装置に送信するのに用いられる第１の送信モジュール１００３と、を含む。

【0069】

本願の実施例の別の態様は装置をさらに提供し、図１１に示すように、この装置は、
制御プレーンからシグナリングを収集するのに用いられる第２の収集モジュール１１０１と、
シグナリング内の、サービスに関する情報に基づいて、シグナリングＸＤＲを生成するのに用いられる第２の生成モジュール１１０２と、
シグナリングＸＤＲを第１の装置に送信するのに用いられる第２の送信モジュール１１０３と、を含む。

【0070】

上記装置実施例は方法実施例に対応しており、上記装置実施例は方法実施例と組み合わせて実施できることは、容易に理解できるであろう。方法実施例で言及された関連する技術的詳細は、上記の装置実施例においても有効であるため、重複を減らすために、ここでは説明を省く。したがって、上記装置実施例で言及された関連の技術的詳細は、方法実施例にも適用可能である。

【0071】

なお、本実施例にかかる各モジュールはいずれも論理モジュールであり、実際の応用において、１つの論理ユニットは１つの物理ユニットであってもよく、１つの物理ユニットの一部であってもよく、さらに、複数の物理ユニットの組み合わせで実現してもよい。また、本願の創造的な部分を際立たせるために、本願で提起された技術的課題の解決にあまり関係のない手段を本実施例には導入していないが、これは本実施例に他の手段が存在しないことを示しているわけではない。

【0072】

本願の実施例の別の態様は電子装置をさらに提供し、この電子装置は、図１２に示すように、少なくとも１つのプロセッサ１２０１と、少なくとも１つのプロセッサ１２０１と通信可能に接続されたメモリ１２０２と、を備え、メモリ１２０２には少なくとも１つのプロセッサ１２０１により実行できる命令が記憶されており、命令が少なくとも１つのプロセッサ１２０１により実行されることで、少なくとも１つのプロセッサ１２０１が上記の何れか１つの方法実施例に記載のサービスＸＤＲの取得方法を実行できるようにする。

【0073】

ここで、メモリ１２０２とプロセッサ１２０１とはバス方式で接続され、バスは任意の数の相互接続されたバス及びブリッジを含んでもよく、バスにより、１つ又は複数のプロセッサ１２０１とメモリ１２０２の様々な回路が一つに接続される。バスはまた、周辺機器、電圧安定器、及びパワーマネジメント回路などの様々な他の回路を一つに接続することができるが、これらは当分野で周知なことであるので、本文ではこれ以上の説明を省く。バスインターフェースは、バスとトランシーバとの間のインターフェースを提供する。トランシーバは、１つの素子であってもよく、複数の受信機及び送信機のような複数の素子であってもよく、伝送媒体上で様々な他の装置と通信するための手段を提供する。プロセッサ１２０１により処理されたデータはアンテナを介して無線媒体で伝送され、さらに、アンテナはまたデータを受信してプロセッサ１２０１にデータを伝送する。

【0074】

プロセッサ１２０１は、バスの管理及び通常の処理を担う以外にも、さらにタイミング、周辺インターフェース、電圧調整、電源管理及びその他の制御機能を含む様々な機能を提供することもできる。一方、メモリ１２０２は、プロセッサ１２０１によって操作を実行するときに使用されるデータを記憶するために使用されてもよい。

【0075】

本願の実施例の別の態様は、コンピュータプログラムを記憶しているコンピュータ可読記憶媒体をさらに提供する。コンピュータプログラムは、プロセッサにより実行された場合、上記何れか一つの方法実施例に記載のサービスＸＤＲの取得方法を実現する。

【0076】

即ち、当業者であれば、上記の実施例の方法における全部又は一部のステップを実施することは、プログラムによって関連するハードウェアに命令することにより実現できることは、理解できるであろう。このプログラムは１つの記憶媒体に記憶され、１つの装置（ワンチップコンピュータ、チップなどであってもよい）又はプロセッサ（ｐｒｏｃｅｓｓｏｒ）に本願の各実施例に記載の方法の全部又は一部のステップを実行させるためのいくつかの命令を含む。一方、上記記憶媒体は、ＵＳＢメモリ、リムーバブルハードディスク、リードオンリーメモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスク等、プログラムコードを記憶可能な種々の媒体を含む。

【0077】

当業者であれば、上記の各実施例は、本出願を実施するための具体的な実施例であり、実際の応用においては、本願の精神及び範囲を逸脱することなく、形式的に及び細部に様々な変更を加えることができることを理解することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【国際調査報告】