JP2021513274A - データ処理方法、サーバ、およびデータ収集デバイス - Google Patents

Abstract

本出願の実施形態は、データ処理方法、サーバ、およびデータ収集デバイスを開示し、その結果、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算し、それによってSTBの負荷が軽減される。本出願の実施形態の方法は、サーバにより、第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のセットトップボックスSTBのパフォーマンスデータを取得するステップであって、第1のネットワークKPIデータが第1のビデオサービスストリームのネットワークKPIデータであり、第1のSTBが第1のビデオサービスストリームを受信するSTBである、ステップと、サーバにより、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算するステップであって、関連モデルが履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルがネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される、ステップとを含む。

Description

関連出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、2018年2月9日に中国特許庁に出願され、「DATA PROCESSING METHOD，SERVER，AND DATA COLLECTION DEVICE」と題する中国特許出願第201810136559．5号の優先権を主張する。

本出願は、通信技術の分野に関し、詳細には、データ処理方法、サーバ、およびデータ収集デバイスに関する。

より高品質のサービスをユーザに提供する方法を研究するために、研究者は、増加するネットワークサービスに対するユーザ中心の体験品質（quality of experience、QoE）評価指標を提案する。QoEは、サービスがユーザの主観的な認識の観点からユーザによって認識される、サービスの評価基準である。QoEはビデオQoEを含む。ビデオサービスの継続的な発展により、ビデオ体験品質に対するユーザの要件がますます高くなっている。したがって、ネットワーク動作状況を正確に識別し、ネットワーク動作ポリシーをさらに誘導し、ネットワークデバイスを最適化するために、ビデオQoEを効果的に取得する方法は、ネットワーク管理の分野で研究の焦点となっている。

現在、ビデオ監視センターサーバは、ユーザ側のセットトップボックス（set top box、STB）に組み込まれたプローブを使用してビデオQoEを取得する。プローブは、STBのパフォーマンスデータ、およびビデオサービスストリームのビデオ停止持続時間比率を検出する。STBは、特定のアルゴリズム、STBのパフォーマンスデータ、およびビデオサービスストリームのビデオ停止持続時間比率に基づいて、ビデオサービスストリームのビデオQoEを計算し、次いで、ビデオ監視センターサーバにビデオQoEを報告する。

しかしながら、STBに組み込まれたプローブは、ビデオサービスストリームのビデオ停止持続時間比率を継続的に検出し、STBは、STBのパフォーマンスデータおよびビデオサービスストリームのビデオ停止持続時間比率に基づいて、ビデオサービスストリームのビデオQoEを計算し、次いで、ビデオ監視センターサーバにビデオQoEを報告する。この場合、STBは過度に高いさらなる負荷を負う。その結果、STBのパフォーマンスは影響を受ける。

本出願の実施形態は、データ処理方法、サーバ、およびデータ収集デバイスを提供し、その結果、サーバは、第1のネットワークキーパフォーマンスインジケータ（key performance indicator、KPI）データおよび第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算し、それによってSTBの負荷が軽減される。

本出願の実施形態の第1の態様は、以下を含むデータ処理方法を提供する。

伝送制御プロトコル（transmission control protocol、TCP）ネットワークにおいて、ユーザ側のSTBがビデオサービスを要求し、インターネットプロトコルテレビジョンサーバ（internet protocol television server、IPTV Server）が第1のビデオサービスストリームを送信し、第1のビデオサービスストリームは、TCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスを通過する。この場合、ネットワークデバイスに配置されるか、またはバイパスモードで配置されたデータ収集デバイスは、第1のビデオサービスストリームの第1のネットワークKPIデータを収集することができ、データ収集デバイスは第1のネットワークKPIデータをサーバに送信し、サーバは第1のビデオサービスストリームの第1のネットワークKPIデータを取得することができる。第1のネットワークKPIデータを取得した後、サーバは、第1のネットワークKPIデータに基づいて、第1のビデオサービスストリームを受信する第1のSTBを特定することができる。次いで、サーバは第1のSTBのパフォーマンスデータを取得することができる。第1のビデオサービスストリームの第1のネットワークKPIデータ、および第1のビデオサービスストリームを受信する第1のSTBのパフォーマンスデータを取得した後、サーバは、第1のビデオサービスストリームのビデオQoEを取得するために、計算用の関連モデルにデータを入力することができる。関連モデルは、履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルは、ネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される。

本出願のこの実施形態では、サーバは、第1のビデオサービスストリームの第1のネットワークKPIデータ、および第1のビデオサービスストリームを受信する第1のSTBのパフォーマンスデータを取得し、次いで、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームのビデオQoEを計算する。このようにして、STBはビデオ停止持続時間比率を収集するためにこれ以上使用されず、ビデオ停止持続時間比率に基づいてビデオQoEをこれ以上計算せず、それによってSTBの負荷が大幅に軽減される。加えて、すべてのユーザ側のSTBにプローブを組み込む必要がない。その結果、配置規模が縮小され、ユーザ側のSTBのコストが削減される。

可能な実装形態では、サーバが、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算する前に、方法は、TCPネットワークにおいて、ビデオサービスを要求する複数のSTBが存在するとき、IPTVサーバが複数のビデオサービスストリームを送信することをさらに含んでよい。この場合、データ収集デバイスは、複数のビデオサービスストリームの履歴ネットワークKPIデータを収集することができる。複数のビデオサービスストリームを受信するSTBは、複数のビデオサービスストリームのリアルタイム情報に基づいて複数のビデオサービスストリームのビデオQoEを計算し、ビデオQoEをサーバに送信し、サーバは、複数のビデオサービスストリームの履歴ネットワークKPIデータおよび複数のビデオサービスストリームの履歴ビデオQoEを取得することができる。次いで、サーバは、複数のビデオサービスストリームを受信するSTBのパフォーマンスデータを特定することができ、サーバは、複数のビデオサービスストリームの履歴ネットワークKPIデータ、複数のビデオサービスストリームの履歴ビデオQoE、および複数のビデオサービスストリームを受信するSTBのパフォーマンスデータに基づいて、関連モデルを確立する。

本出願のこの実施形態では、サーバは、複数のビデオサービスストリームの取得された履歴ネットワークKPIデータ、複数のビデオサービスストリームの取得されたビデオQoE、および複数のビデオサービスストリームを受信するSTBの取得されたパフォーマンスデータに基づいて、関連モデルを確立する。関連モデルを確立するための具体的な方法が提供される。その結果、実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、履歴パフォーマンスデータは、複数のビデオサービスストリームを受信するSTBの初期バッファサイズを含んでよく、履歴ネットワークKPIデータは、複数のビデオサービスストリームのビデオパケット損失率（packet loss rate、PLR）、複数のビデオサービスストリームの往復時間（round trip time、RTT）、および複数のビデオサービスストリームのビデオビットレートを含んでよい。

本出願のこの実施形態では、履歴パフォーマンスデータは、複数のビデオサービスストリームを受信するSTBの初期バッファサイズを含んでよく、履歴ネットワークKPIデータは、複数のビデオサービスストリームのビデオPLR、複数のビデオサービスストリームのRTT、および複数のビデオサービスストリームのビデオビットレートを含んでよい。実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、第1のSTBのパフォーマンスデータは、第1のSTBの初期バッファサイズを含んでよく、第1のネットワークKPIデータは、第1のビデオサービスストリームのビデオPLR、第1のビデオサービスストリームのRTT、および第1のビデオサービスのビデオビットレートを含んでよい。

本出願のこの実施形態では、第1のSTBのパフォーマンスデータは、第1のSTBの初期バッファサイズを含んでよく、第1のネットワークKPIデータは、第1のビデオサービスストリームのビデオPLR、第1のビデオサービスストリームのRTT、および第1のビデオサービスのビデオビットレートを含んでよい。実際の適用例では、解決策の実現可能性が向上する。

本出願の実施形態の第2の態様は、以下を含むデータ処理方法を提供する。

TCPネットワークにおいて、ユーザ側のSTBがビデオサービスを要求し、IPTV Serverがターゲットサービスストリームを送信し、送信プロセスでは、ターゲットサービスストリームは、TCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスを通過する。この場合、ネットワークデバイスに配置されるか、またはバイパスモードで配置されたデータ収集デバイスは、ターゲットサービスストリームのタイプを検出することができ、次いで、サーバは、ターゲットサービスストリームのサービスタイプに対応するターゲット計算規則を特定し、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。

本出願のこの実施形態では、データ収集デバイスは、ターゲットサービスストリームのタイプを検出し、次いで、サービスタイプに対応するターゲット計算規則を特定する。次いで、サーバは、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。ターゲットサービスストリームのビデオビットレートを計算するための具体的な方法が提供される。その結果、解決策の実現可能性が向上する。本出願において提供される方法によれば、ビデオビットレートが計算されるとき、ターゲットサービスストリームのパケットは構文解析される必要がない。したがって、本出願の方法は、暗号化されたターゲットサービスストリームのビデオビットレートの計算に適用可能である。

可能な実装形態では、ターゲットサービスストリームのタイプは、ビデオストリームおよびオーディオストリームのシングルストリームであってよく、ターゲット計算規則は第1の事前設定計算規則であってよい。

本出願のこの実施形態では、ターゲットサービスストリームのタイプは、ビデオストリームおよびオーディオストリームのシングルストリームであってよく、ターゲット計算規則は第1の事前設定計算規則であってよい。実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、第1の事前設定規則は、データ収集デバイスがターゲットサービスストリームの累積ダウンロード持続時間およびターゲットサービスストリームの累積ダウンロード量を取得し、次いで、データ収集デバイスが累積ダウンロード持続時間および累積ダウンロード量に基づいてターゲットサービスストリームのビデオビットレートを計算できることを含んでよい。

本出願のこの実施形態では、データ収集デバイスは、ターゲットサービスストリームの累積ダウンロード量およびターゲットサービスストリームの累積ダウンロード持続時間に基づいて、ターゲットサービスストリームのビデオビットレートを計算する。シングルストリームタイプのターゲットサービスストリームのビデオビットレートを計算するための具体的な方法が提供される。実際の適用例では、解決策の実現可能性および完全性が向上する。

別の可能な実装形態では、ターゲットサービスストリームのタイプは、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであってよく、ターゲット計算規則は第2の事前設定規則である。

本出願のこの実施形態では、ターゲットサービスストリームのタイプは、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであってよく、ターゲット計算規則は第2の事前設定規則であってよい。実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、第2の事前設定規則は、最初に、データ収集デバイスが、ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームが同じサービスのサービスストリームであると判断することができ、次いで、データ収集デバイスが、オーディオストリームのオーディオビットレートを決定することができ、最後に、データ収集デバイスが、計算されたオーディオビットレートに基づいてビデオストリームのビデオビットレートを計算することができることを含んでよい。

本出願のこの実施形態では、データ収集デバイスは、オーディオストリームのオーディオビットレートに基づいて、ビデオストリームのビデオビットレートを計算することができる。実際の適用例では、デュアルストリームタイプのターゲットサービスストリームのビデオビットレートを計算するための具体的な方法が提供される。その結果、解決策の実現可能性および完全性が向上する。

別の可能な実装形態では、データ収集デバイスがオーディオストリームのオーディオビットレートを決定することは、データ収集デバイスが、データ収集デバイスによって取得された単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード持続時間および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量に基づいて、オーディオストリームのオーディオビットレートを計算できることである。

本出願のこの実施形態では、データ収集デバイスは、単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード持続時間および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量に基づいて、オーディオストリームのオーディオビットレートを計算することができる。したがって、オーディオストリームのオーディオビットレートを計算するための具体的な方法が提供される。実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、データ収集デバイスがオーディオビットレートに基づいてターゲットサービスストリームのビデオビットレートを計算することは、データ収集デバイスが、最初に、オーディオストリームのオーディオビットレート、および事前設定持続時間内のオーディオストリームの取得された累積ダウンロード量に基づいて、オーディオストリームの累積ダウンロード持続時間を計算することができ、次いで、データ収集デバイスが、オーディオストリームの計算された累積ダウンロード持続時間、および事前設定持続時間内のビデオストリームの累積ダウンロード量に基づいて、ビデオストリームのビデオビットレートを計算することができることであってよい。

本出願のこの実施形態では、データ収集デバイスは、オーディオストリームの累積ダウンロード持続時間およびビデオストリームの累積ダウンロード量に基づいて、ビデオストリームのビデオビットレートを計算することができる。したがって、ビデオストリームのビデオビットレートを計算するための具体的な方法が提供される。実際の適用例では、解決策の実現可能性が向上する。

別の可能な実装形態では、データ収集デバイスがターゲットサービスストリームのタイプを検出する前に、方法は、データ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームであると判断できることをさらに含んでよい。

本出願のこの実施形態では、データ収集デバイスは、ターゲットサービスストリームが暗号化されたストリームであると判断することができる。したがって、本出願において提供されたビデオストリームのビデオビットレートを計算するための方法が使用される前に、データ収集デバイスは、最初に、ターゲットサービスストリームが暗号化されたストリームであると判断することができる。ターゲットサービスストリームが暗号化されたストリームである場合、データ収集デバイスは、本出願において提供されたビデオビットレートを計算するための方法を使用することにより、ターゲットサービスストリームのビデオビットレートを計算することができる。ターゲットサービスストリームが暗号化されていないストリームである場合、データ収集デバイスは、ディープパケットインスペクション（deep packet inspection、DPI）方式でターゲットサービスストリームのビデオビットレートを優先的に取得することができる。確かに、本出願において提供されたビデオビットレートを計算するための方法も使用されてよい。その結果、実際の適用例では、解決策の完全性が向上する。

別の可能な実装形態では、データ収集デバイスがターゲットサービスストリームのタイプを検出することは、データ収集デバイスが、最初に、単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出し、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、データ収集デバイスが、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断することができ、または単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多い場合、データ収集デバイスが、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断することができることを含んでよい。

本出願のこの実施形態では、データ収集デバイスは、単位時間内に送信されたターゲットサービスストリームのデータパケットの数に基づいて、ターゲットサービスストリームのタイプを特定することができる。実際の適用例では、ターゲットサービスストリームのタイプを特定するための具体的な方法が提供される。その結果、解決策の実現可能性が向上する。

本出願の実施形態の第3の態様はサーバを提供する。サーバは、第1の態様におけるサーバの挙動を実現する機能を有する。機能は、ハードウェアによって実現されてもよく、ハードウェアが対応するソフトウェアを実行することによって実現されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。

本出願の実施形態の第4の態様はデータ収集デバイスを提供する。データ収集デバイスは、第2の態様におけるデータ収集デバイスの挙動を実現する機能を有する。機能は、ハードウェアによって実現されてもよく、ハードウェアが対応するソフトウェアを実行することによって実現されてもよい。ハードウェアまたはソフトウェアは、機能に対応する1つまたは複数のモジュールを含む。

本出願の実施形態の第5の態様はサーバを提供する。サーバは、プロセッサ、メモリ、入出力デバイス、およびバスを含む。プロセッサ、メモリ、および入出力デバイスは、バスに個別に接続される。メモリはコンピュータ命令を記憶する。プロセッサは、メモリ内のコンピュータ命令を実行して、第1の態様の任意の実装形態を実現する。

本出願の実施形態の第6の態様はデータ収集デバイスを提供する。データ収集デバイスは、プロセッサ、メモリ、入出力デバイス、およびバスを含む。プロセッサ、メモリ、および入出力デバイスは、バスに個別に接続される。メモリはコンピュータ命令を記憶する。プロセッサは、メモリ内のコンピュータ命令を実行して、第2の態様の任意の実装形態を実現する。

本出願の実施形態の第7の態様はチップシステムを提供する。チップシステムは、第1の態様に記載された機能を実現する、たとえば、前述の方法においてデータおよび／または情報を送信または処理する際にネットワークデバイスをサポートするように構成されたプロセッサを含む。可能な設計では、チップシステムはメモリをさらに含む。メモリは、ネットワークデバイスに必要なプログラム命令およびデータを記憶するように構成される。チップシステムは、チップを含んでもよく、チップおよび別の個別デバイスを含んでもよい。

本出願の実施形態の第8の態様はチップシステムを提供する。チップシステムは、第2の態様に記載された機能を実現する、たとえば、前述の方法においてデータおよび／または情報を送信または処理する際にネットワークデバイスをサポートするように構成されたプロセッサを含む。可能な設計では、チップシステムはメモリをさらに含む。メモリは、ネットワークデバイスに必要なプログラム命令およびデータを記憶するように構成される。チップシステムは、チップを含んでもよく、チップおよび別の個別デバイスを含んでもよい。

本出願の実施形態の第9の態様は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは、第1の態様または第2の態様の任意の実装形態を実行することが可能になる。

本出願の実施形態の第10の態様は、命令を含むコンピュータ可読記憶媒体を提供する。命令がコンピュータ上で実行されると、コンピュータは、第1の態様または第2の態様の任意の実装形態を実行することが可能になる。

本出願の一実施形態による、データ処理方法のシステムフレームワーク図である。 本出願の一実施形態による、データ処理方法の一実施形態の概略図である。 本出願の一実施形態による、データ処理方法の別の実施形態の概略図である。 本出願の一実施形態による、データ処理方法の別の実施形態の概略図である。 本出願の一実施形態による、データ処理方法のシナリオの概略図である。 本出願の一実施形態による、データ処理方法の別のシナリオの概略図である。 本出願の一実施形態による、データ処理方法の別の実施形態の概略図である。 本出願の一実施形態による、データ処理方法の別のシナリオの概略図である。 本出願の一実施形態による、データ処理方法の別のシナリオの概略図である。 本出願の一実施形態による、サーバの概略構造図である。 本出願の一実施形態による、データ収集デバイスの概略構造図である。 本出願の一実施形態による、サーバの別の概略構造図である。 本出願の一実施形態による、データ収集デバイスの別の概略構造図である。

本出願の実施形態は、データ処理方法を提供し、その結果、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算し、それによってSTBの負荷が軽減される。

図1を参照すると、TCPネットワークにおける送信プロセスでは、ビデオサービスストリームは、TCPネットワーク内のすべてのレイヤにあるネットワークデバイスを通過する。たとえば、図1では、IPTV Serverがビデオサービスストリームを送信し、ビデオサービスストリームはコアルータ（core route、CR）、ブロードバンドリモートアクセスサーバ（broadband remote access server、BRAS）、および光回線終端装置（optical line terminal、OLT）を通過する。次いで、ユーザ側のSTBがビデオサービスストリームを受信する。ビデオサービスストリームを処理した後、STBはビデオを再生することができる。したがって、TCPネットワークでは、送信されたビデオサービスストリームがすべてのレイヤに配置されたネットワークデバイスを通過することが分かる。ビデオサービスストリームのネットワークKPIデータは、すべてのレイヤに配置されたネットワークデバイスを通過するビデオサービスストリームに基づいて収集されてよい。ネットワークKPIデータは、ビデオサービスストリームのパケット損失率（packet loss rate、PLR）、ビデオサービスストリームの往復時間（round−trip time、RTT）、ビデオサービスストリームのビデオビットレートなどのビデオサービスストリームの特徴を含み、デバイスの負荷率などの特徴をさらに含んでよい。デバイスが位置するエンドツーエンドトポロジのリンクパフォーマンスは、ネットワークKPIデータに大きく依存する。リンクパフォーマンスが不十分なら、ユーザ側のデバイスでビデオの異常再生が発生しやすい。その結果、ビデオQoEが影響を受ける。これを考慮して、本出願は、シングルノードモードで配置された収集デバイスがTCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスのいずれか1つであるか、または収集デバイスがネットワークデバイスにマルチノードモードもしくはバイパスモードで配置される解決策を提案する。データ収集デバイスは、ビデオサービスストリームのネットワークKPIデータを収集するように構成される。本出願では、プローブはいくつかの異なるタイプのユーザ側のSTBに組み込まれる。STBのビデオリアルタイム情報およびパフォーマンスデータがプローブを使用して取得され、ビデオQoEが計算される。次いで、ビデオQoEおよびSTBのパフォーマンスデータがサーバに送信される。サーバは、ネットワークKPIデータ、ビデオQoEなどに基づいて、ビデオQoEの関連モデルを確立することができる。サーバは、データを取得し、データを分析および処理し、ビデオQoEの関連モデルを確立した後、ネットワークKPIデータおよびSTBのパフォーマンスデータを取得して、ビデオQoEを計算するように構成される。本出願では、サーバは、ビデオQoEを計算する機能を有するビデオ監視センターサーバであってもよく、ビデオQoEを計算する機能を有する独立したサーバであってもよい。このことは本明細書では具体的に限定されない。TCPネットワークにおいて、ビデオサービスストリームが送信されると、サーバは、ネットワークデバイスによって送信されたビデオサービスストリームのネットワークKPIデータであり、ネットワークデバイス（たとえば、BRASまたはOLT）に配置されるか、またはバイパスモードで配置されたデータ収集デバイスによって収集されたネットワークKPIデータを取得する。

以下で、本出願の一実施形態におけるデータ処理方法をサーバの観点から記載する。図2を参照すると、本出願のこの実施形態におけるデータ処理方法の一実施形態は、以下のステップを含む。

201．サーバが、第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のセットトップボックスSTBのパフォーマンスデータを取得する。

TCPネットワークにおいて、ユーザ側のSTBがビデオサービスを要求し、IPTV Serverが第1のビデオサービスストリームを送信し、第1のビデオサービスストリームは、TCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスを通過する。この場合、ネットワークデバイスに配置されたデータ収集デバイスは、第1のビデオサービスストリームの第1のネットワークKPIデータを収集することができ、データ収集デバイスは、第1のビデオサービスストリームの収集された第1のネットワークKPIデータをサーバに送信することができ、サーバは第1のネットワークKPIデータを取得することができる。第1のネットワークKPIデータを取得した後、サーバは、宛先インターネットプロトコル（internet protocol、IP）アドレス、または第1のビデオサービスストリームの宛先ポート番号であり、第1のネットワークKPIデータ内で搬送された宛先ポート番号に基づいて、第1のビデオサービスストリームを受信する第1のSTBを特定することができる。次いで、サーバは第1のSTBのパフォーマンスデータを取得することができる。第1のビデオサービスストリームは第1のSTBに関連付けられる、言い換えれば、第1のSTBは第1のビデオサービスストリームを受信するSTBである。第1のSTBのパフォーマンスデータは、第1のSTBの初期バッファサイズを含む。場合によっては、第1のSTBのパフォーマンスデータは、第1のSTBの中央処理装置（central processing unit、CPU）のクロックレートをさらに含んでよい。

サーバがビデオ監視センターサーバであるとき、サーバは、第1のSTBがビデオサービスを要求するために第1のSTBによってサーバに送信されたメッセージから第1のSTBのパフォーマンスデータを取得するか、または様々なタイプのSTBのパフォーマンスデータを記憶するためのローカルデータベースから第1のSTBのパフォーマンスデータを取得することができることに留意されたい。サーバがビデオQoEを計算する機能を有する独立したサーバであるとき、サーバはビデオ監視センターから第1のSTBのパフォーマンスデータを取得するか、または様々なタイプのSTBのパフォーマンスデータを記憶するためのローカルデータベースから第1のSTBのパフォーマンスデータを取得することができる。このことは本明細書では具体的に限定されない。

202．サーバが、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算する。

第1のビデオサービスストリームの第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得した後、サーバは、第1のビデオサービスストリームの第1のビデオQoEを取得するために、計算用の関連モデルに第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを入力する。関連モデルは、履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルは、ネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される。

関連モデルは、履歴データに基づくトレーニングを介してサーバによって取得されたモデルであってもよく、履歴データに基づくトレーニングを介して別の端末または別のサーバによって取得されたモデルであってもよい。このことは本明細書では具体的に限定されない。

本出願のこの実施形態では、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、第1のネットワークKPIデータは第1のビデオサービスストリームのネットワークKPIデータであり、第1のビデオサービスストリームは第1のSTBと関連付けられる。次いで、サーバは、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算する。関連モデルは、履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルは、ネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される。したがって、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームのビデオQoEを計算することができる。このようにして、STBはビデオ停止持続時間比率を収集するためにこれ以上使用されず、ビデオ停止持続時間比率に基づいてビデオQoEをこれ以上計算せず、それによってSTBの負荷が大幅に軽減される。

上記は、本出願の実施形態におけるデータ処理方法をサーバの観点から記載した。以下で、本出願の実施形態におけるデータ処理方法をデータ収集デバイスの観点から記載する。図3を参照すると、本出願のこの実施形態におけるデータ処理方法の別の実施形態は、以下のステップを含む。

301．データ収集デバイスがターゲットサービスストリームのタイプを検出する。

TCPネットワークにおいて、ユーザ側のSTBがビデオサービスを要求し、IPTV Serverがターゲットサービスストリームをユーザ側のSTBに送信する。ターゲットサービスストリームが送信され、すべてのレイヤに配置されたネットワークデバイスを通過すると、ネットワークデバイスのいずれか1つに配置されるか、またはバイパスモードで配置された収集デバイスは、ターゲットサービスストリームのタイプを検出することができる。具体的には、データ収集デバイスは、単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出し、単位時間内に送信されたターゲットサービスストリームのデータパケットの数に基づいて、ターゲットサービスストリームのタイプを特定することができる。あるいは、データ収集デバイスは、ターゲットサービスストリームのトリプレットを使用することにより、ターゲットサービスストリームのタイプを特定することができる。このことは本明細書では具体的に限定されない。

ターゲットサービスストリームは、暗号化されたストリームであってもよく、暗号化されていないストリームであってもよいことに留意されたい。このことは本明細書では具体的に限定されない。

302．データ収集デバイスがターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定する。

データ収集デバイスがターゲットサービスストリームのタイプを検出し、ターゲットサービスストリームのタイプを特定した後、データ収集デバイスは、ターゲットサービスストリームのタイプに基づいて対応するターゲット計算規則を特定することができる。たとえば、データ収集デバイスが、検出を介して、ターゲットサービスストリームのタイプがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断した場合、データ収集デバイスは、シングルストリームタイプに対応するターゲット計算規則が第1の事前設定計算規則であると判断することができる。ターゲットサービスストリームはシングルストリームであり、ターゲット計算規則は、第1の事前設定計算規則であってもよく、別の計算規則であってもよいことに留意されたい。このことは本明細書では具体的に限定されない。たとえば、データ収集デバイスが、ターゲットサービスストリームのタイプが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断した場合、データ収集デバイスは、デュアルストリームタイプに対応するターゲット計算規則が第2の事前設定計算規則であると判断することができる。ターゲットサービスストリームはデュアルストリームであり、ターゲット計算規則は、第2の事前設定計算規則であってもよく、別の計算規則であってもよいことに留意されたい。このことは本明細書では具体的に限定されない。

303．データ収集デバイスがターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。

ターゲットサービスストリームのタイプを特定した後、データ収集デバイスは、ターゲットサービスストリームのタイプに対応するターゲット計算規則を特定する。次いで、データ収集デバイスは、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。たとえば、ステップ302において、データ収集デバイスが、シングルストリームタイプに対応するターゲット計算規則が第1の事前設定計算規則であると判断した場合、データ収集デバイスは、第1の事前設定計算規則に従ってターゲットサービスストリームのビデオビットレートを計算することができる。したがって、本出願では、データ収集デバイスは、ターゲットサービスストリームのサービスタイプに基づいてターゲット計算規則を特定し、次いで、データ収集デバイスは、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算し、ターゲットサービスストリームのパケットを構文解析する必要がない。したがって、本出願において提供され、データ収集デバイスがターゲットサービスストリームのビデオビットレートを計算する解決策は、暗号化シナリオにおける暗号化されたストリームのビデオビットレートの計算に適用可能である。

本出願のこの実施形態では、データ収集デバイスはターゲットサービスストリームのタイプを検出し、データ収集デバイスはターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定し、データ収集デバイスはターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算することができる。したがって、ターゲットサービスストリームのタイプが検出され、次いで、ターゲットサービスストリームのタイプに対応するターゲット計算規則が特定され、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートが計算される。このようにして、ビデオサービスストリームのビデオビットレートが収集され、データ収集デバイスは、ビデオサービスストリームのビデオビットレートを含むビデオサービスストリームのネットワークKPIデータをサーバに提供することができる。

本出願のこの実施形態では、サーバは、関連モデル、第1のネットワークKPIデータ、および第1のSTBの第1のパフォーマンスデータに基づいて、第1のビデオサービスストリームのビデオQoEを計算する。関連モデルは、履歴データに基づくトレーニングを介してサーバによって取得されたモデルであってよい。図4の実施形態において、詳細な説明が以下に提供される。

図4を参照すると、図4の実施形態では、サーバは、第2のネットワークKPIデータ、第2のビデオQoE、および第2のパフォーマンスデータを取得して、関連モデルを確立する。本出願のこの実施形態におけるデータ処理方法の別の実施形態は、以下のステップを含む。

401．データ収集デバイスが第2のネットワークKPIデータを収集する。

TCPネットワークにおいて、ビデオサービスストリームが送信されると、ビデオサービスストリームはすべてのレイヤに配置されたネットワークデバイスを通過する。データ収集デバイスは、ネットワークデバイスのいずれか1つにシングルノードモードまたはバイパスモードで配置される。すべてのレイヤに配置されたネットワークデバイスは、ビデオサービスストリームをデータ収集デバイスに転送するか、またはビデオサービスストリームをミラーリング方式で複製し、次いで、ビデオサービスストリームをデータ収集デバイスに送信する。次いで、データ収集デバイスは、ビデオサービスストリームを分析して、ビデオサービスストリームのネットワークKPIデータを抽出することができる。第2のネットワークKPIデータは、複数のビデオサービスストリームのネットワークKPIデータの複数のグループを含み、複数のビデオサービスストリームは、サーバが関連モデルを確立するための初期段階で収集されるデータとして使用され、その後、ネットワークKPIデータとビデオQoEとの間の関連付け関係を分析するためにサーバによって使用される。

具体的には、データ収集デバイスは、事前設定持続時間に基づいて1回ネットワークKPIデータを収集することができる。たとえば、データ収集デバイスは、5分ごとに1回ネットワークKPIデータを収集する。具体的には、TCPネットワーク内のすべてのレイヤにあるネットワークデバイスがビデオサービスストリームに対して転送またはミラーリング動作を実行した後、データ収集デバイスは、サービスストリームのタイプに基づいて対応する計算規則を特定し、次いで、計算規則に従ってサービスストリームのビデオビットレートを計算することができる。加えて、ビデオサービスストリームが暗号化されていないストリームであるとき、データ収集デバイスはさらに、DPI方式でパケットのフィールドからビデオサービスストリームのリアルタイムビットレートを読み取ることができる。データ収集デバイスは、ビデオサービスストリームのパケットのタイムスタンプに基づいて、ビデオサービスストリームの往復時間RTTを特定する。TCPネットワークでは、ビデオサービスストリームはパケットの形式で送信され、各パケットは対応するシーケンス番号を有する。したがって、データ収集デバイスは、パケットのシーケンス番号に基づいて現在のノード上のパケット損失率を取得することができ、データ収集デバイスは、パケットを構文解析することにより、パケットの最大セグメントサイズ（maximum segment size、MSS）などのデータを取得することができる。図5を参照すると、Serverはサーバであり、Clientはクライアントであり、データ収集デバイスは、上流ネットワークにおけるビデオサービスストリームのネットワークKPIデータ、および下流ネットワークにおけるビデオサービスストリームのネットワークKPIデータを収集することができる。図5から、データ収集デバイスは、上流ネットワークにおけるビデオサービスストリームの上流パケット損失率（（up packet loss rate、UPLR）、上流往復時間（up round−trip time、URTT）、および上流ネットワークにおけるビデオサービスストリームのリアルタイムビデオビットレートを取得できることが分かる。次いで、データ収集デバイスは、下流ネットワークにおける下流パケット損失率（down packet loss r
ate、DPLR）、下流往復時間（down round−trip time、DRTT）、および下流ネットワークにおけるビデオサービスストリームのリアルタイムビットレートなどのデータを取得することができる。詳細については、表1を参照されたい。

表1は、事前設定持続時間に基づいてデータ収集デバイスによって収集されたビデオサービスストリームのネットワークKPIデータの複数のグループを示し、ネットワークKPIデータの各グループは、ビデオサービスストリームのアカウント（Account）、タイムスタンプ（timestamp）、ビデオソース情報（VideoID）、累積ダウンロード量（DownloadQctets）、ダウンロード持続時間（DownloadTime）、ビットレート（Rate）、RTT、およびビデオサービスストリームのPLRを含む。データ収集デバイスは、複数のビデオサービスストリームのネットワークKPIデータの複数のグループを収集し、次いで、複数のビデオサービスストリームのネットワークKPIデータの複数のグループをサーバに送信する。

402．データ収集デバイスが第2のネットワークKPIデータをサーバに送信する。

第2のネットワークKPIデータを取得した後、データ収集デバイスは第2のネットワークKPIデータをサーバに送信し、第2のネットワークKPIデータは複数のビデオサービスストリームのネットワークKPIデータの複数のグループを含み、複数のビデオサービスストリームは、その後、第2のビデオQoEと第2のネットワークKPIデータとの間の関係を分析し、関連モデルを確立するためにサーバによって使用される。

403．サーバがSTBによって送信された第2のビデオQoEおよび第2のパフォーマンスデータを受信する。

TCPネットワークにおいて、ビデオサービスストリームがユーザ側のSTBに送信された後、STBがビデオサービスを再生する。本出願では、サーバは、関連モデルを確立するために、初期段階で複数のビデオサービスストリームのビデオQoEを収集する必要がある。したがって、最初に、複数のタイプのSTBが配置され、複数のタイプのSTBにプローブが組み込まれ、プローブがリアルタイムビデオ情報およびSTBのパフォーマンスデータを検出し、次いで、STBは、ビデオリアルタイム情報およびSTBのパフォーマンスデータに基づいて、ビデオサービスストリームのビデオQoEを計算し、ビデオQoEおよびSTBのパフォーマンスデータをサーバに報告し、サーバは、第2のビデオQoEおよび第2のパフォーマンスデータを受信することができる。第2のビデオQoEは複数のビデオサービスストリームのビデオQoEを含み、第2のパフォーマンスデータは、表2に示されたように複数の異なるタイプのSTBの初期バッファ情報を含む。

表2は、異なる時間にビデオサービスストリームに基づいてHuawei−xxxタイプのSTBによって計算されたビデオQoEを示す。表2は、アカウント、STB、タイムスタンプ、ビデオソース情報、ビデオQoEを含む。本出願では、サーバが関連モデルを確立する前に、プローブが組み込まれた特定の数のSTBが配置される。STBは様々なタイプをもち、様々なタイプのSTBによって送信されたビデオサービスストリームのビデオQoEを後で収集するように構成される。したがって、本出願では、サーバが、関連モデル、ネットワークKPIデータ、およびSTBのパフォーマンスデータに基づいて、ビデオサービスストリームのビデオQoEを計算し、サーバが関連モデルを確立した後、STBはビデオQoEを計算するためにこれ以上使用されず、それによってSTBの負荷が軽減される。加えて、すべてのユーザ側のSTBにプローブを組み込む必要はない。その結果、配置規模が縮小され、ユーザ側のSTBのコストが削減される。

サーバがSTBによって送信されたパフォーマンスデータを受信した後、サーバは様々なタイプのSTBによって報告されたパフォーマンスデータを統合して、初期バッファ情報テーブルを生成することに留意されたい。表3は、様々なタイプのSTBに対応する初期バッファ情報テーブルであり、サーバに記憶されている。表3は、STBのタイプ（Type）および初期バッファ（initBuf）サイズを含む。

404．サーバが、第2のネットワークKPIデータ、第2のパフォーマンスデータ、および第2のビデオQoEに基づいて、関連モデルを確立する。

ビデオQoEは、主に、STBによって再生されたビデオサービスの停止状態に基づいて決定され、再生されたビデオサービスの停止状態は、ビデオ停止持続時間比率によって表される。ビデオ停止持続時間比率は、ビデオ再生持続時間に対するビデオ停止持続時間の比率である。しかしながら、STBがビデオサービスを再生するときに発生する停止は、通常、STB内のプレーヤ用のバッファデータが使い果たされたために発生する。図6は、STBがビデオサービスを再生するときの停止の発生およびビデオサービスの停止の排除の原理の概略図である。STB内のバッファデータが使い果たされると、STBがビデオサービスを再生する場合、停止が発生する。したがって、ビデオQoEは、ビデオサービスを再生するSTB内のプレーヤ用のリアルタイムバッファデータ量に関係する。STB内のリアルタイムバッファデータ量は、初期バッファサイズおよびSTBで使用されるバッファデータ量に基づいて決定される。STBで使用されるバッファデータ量は、ビデオサービスを再生する使用要件と現在のネットワークのダウンロードパフォーマンスとの間の差に基づいて決定される。ビデオサービスを再生する使用要件は、ビデオサービスストリームのビデオビットレートによって表される。現在のネットワークのダウンロードパフォーマンスは、TCPベアラネットワークのネットワークスループットパフォーマンスに基づいて測定される。たとえば、式1．1はネットワークスループットを計算するための式である。TCPベアラネットワークでは、STBで使用されるバッファデータ量が、ビデオサービスストリームのビデオビットレートおよびネットワークスループットによって影響されることが分かる。ネットワークスループットがビデオサービスストリームのビデオビットレートより低い場合、継続的なビデオ再生をサポートするために、STBはプレーヤ用のバッファビデオデータを使用する。ネットワークスループットがビデオサービスストリームのビデオビットレートよりも低い状態が続く場合、STB内のバッファデータがすぐに使用されてよい。その結果、STB内のバッファデータが使い果たされ、ビデオサービスが再生されるときに停止が発生する。加えて、STBは、再生されないビデオコンテンツの一部を格納するために固定された初期バッファサイズをもつので、初期バ
ッファサイズはSTB内のバッファデータの使用速度に影響する。

式（1．1）において、Throughput（t）はネットワークスループットであり、MSSはビデオサービスストリームを送信するためのパケットの最大セグメントサイズであり、RTTはビデオサービスストリームの往復時間であり、PLRはビデオサービスストリームのパケット損失率である。式（1．1）から、TCPネットワークでは、ネットワークスループットはビデオサービスストリームのネットワークKPIデータ内のRTT、ビデオサービスストリームのネットワークKPIデータ内のPLR、およびビデオサービスストリームのネットワークKPIデータ内のMSSに基づいて共同で決定されることが分かり、MSSは、通常、固定値である。したがって、ネットワークスループットレートは、ネットワークKPIデータ内のRTTおよびネットワークKPIデータ内のPLRに基づいて共同で決定される。したがって、第2のビデオQoEの中の各ビデオサービスストリームのビデオQoEは、それに対応して、第2のネットワークKPIデータ内にあるビデオサービスストリームのPLR、ビデオサービスストリームのRTT、およびビデオサービスストリームのビデオビットレート、ならびにビデオサービスストリームを受信するSTBの初期バッファサイズに関係する。

したがって、TCPネットワークでは、ビデオQoEは、STBの初期バッファサイズ、ビデオサービスストリームのPLR、ビデオサービスストリームのRTT、およびビデオサービスストリームのビデオビットレートに関係する。ネットワークKPIデータは、ビデオサービスストリームのPLR、ビデオサービスストリームのRTT、およびビデオサービスストリームのビデオビットレートを含む。したがって、ビデオQoEに関係するデータは、データ収集デバイスによって送信されたネットワークKPIデータに基づいて取得することができる。したがって、関連モデルの入力パラメータは、第2のネットワークKPIデータ内にある複数のビデオサービスストリームのPLR、複数のビデオサービスストリームのRTT、複数のビデオサービスストリームのビデオビットレート、および第2のパフォーマンスデータであり、第2のパフォーマンスデータは複数のSTBの初期バッファ情報を含む。この場合、ビデオQoEの関連モデルは式（1．2）として表される。

QoE（t）＝F（Buffer_init，Rate（t），Rtt（t），Plr（t）） （1．2）

式（1．2）において、QoEはビデオサービスストリームのビデオ体験品質であり、Buffer_initはSTBの初期バッファサイズであり、Rate（t）はビデオサービスストリームのビデオビットレートであり、RTT（t）はビデオサービスストリームの往復時間であり、Plr（t）はビデオサービスストリームのパケット損失率であり、F（t）はQoEを計算するための関数であり、tはビデオサービスストリームのネットワークKPIデータをサンプリングするための時間である。

サーバは、取得された第2のネットワークKPIデータ、第2のパフォーマンスデータ、および第2のビデオQoEデータを統合してデータセットを生成する。次いで、サーバは、生成されたデータセットに基づいて関連モデルを確立し、関連モデルは、第2のビデオQoEと第2のネットワークKPIデータとの間の関連モデルである。具体的には、サーバは、アカウント、タイムスタンプ、およびビデオソース情報に基づいて、表1のネットワークKPIデータと表2のビデオQoEデータを関連付け、表2のビデオQoEに対応するSTBのタイプを、サーバに記憶され、様々なタイプのSTBの初期バッファ情報を示す表3にマッピングすることによってデータセットを生成する。たとえば、表1および表2のデータは、アカウント「151916877458」に対応するタイムスタンプおよびビデオソース情報「2777429071」のデータに基づいて統合され、表4が取得され得る。表4は関連モデルのデータセットである。

サーバは、生成されたデータセットに基づいて関連モデルを確立する。たとえば、一例として指数近似と多項式近似の組合せを使用することにより、サーバが関連モデルを確立するプロセスが記載される。サーバは、表3の完全な関連データセットおよび関連モデルの所定の入力パラメータに基づいて関連モデルを確立し、式（1．2）から、入力パラメータはビデオサービスストリームのビデオビットレート、ビデオサービスストリームのPLR、ビデオサービスストリームのRTT、およびSTBの初期バッファサイズ、たとえば、式（1．3）であることが分かる。

ここで、f（t）＝λ₁＊Rtt（t）＋λ₂＊Plr（t）＋λ₃＊rate（t）＋λ₄＊Buffer_init＋λ₅である。

式（1．3）において、α1、α2、β1、β2、λ1、λ2、λ3、λ4、およびλ5は関連モデルの近似係数であり、f（t）は計算関数である。サーバによって生成されたデータセットに基づいて、サンプリング時間t、ビデオサービスストリームのパケット損失率、ビデオサービスストリームの往復時間、およびビデオサービスストリームのビデオビットレートが変数として使用され、ビデオQoEは従属変数として使用されて、指数近似と多項式近似を組み合わせる方式で近似を実行する。近似係数は勾配降下アルゴリズムを使用して取得される。たとえば、関連モデルの近似係数のグループは手動で事前に決定されてよく、次いで、関連モデルを使用してビデオQoEが計算される。次いで、エラー値を取得するために、計算されたビデオQoEがビデオサービスストリームの実際のビデオQoEと比較され、エラー値に基づいて近似係数が決定される。たとえば、表5は、この近似方式で取得された近似係数を示す。言い換えれば、関連モデルの近似係数が表5に示される。

405．データ収集デバイスが第1のネットワークKPIデータを収集する。

サーバが関連モデルを確立した後、TCPネットワークにおいて、第1のビデオサービスストリームが送信されると、収集デバイスは第1のビデオサービスストリームの第1のネットワークKPIデータを収集することができる。第1のネットワークKPIデータは、第1のビデオサービスストリームのPLR、第1のビデオサービスストリームのRTT、および第1のビデオサービスストリームのビデオビットレートを含む。

データ収集デバイスは、TCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスのいずれか1つにシングルノードモードで配置されてよく、またはデータ収集デバイスは、TCPネットワーク内のすべてのレイヤに配置されたネットワークデバイスのいずれか1つにマルチノードモードで配置されてよい。いくつかのデータ収集デバイス上で計算またはアップロードの障害が発生した場合でも、他のデータ収集デバイスはビデオサービスストリームのネットワークKPIデータをまだ提供することができる。これにより、ユーザ側のビデオQoEが効果的に監視されることが保証され、ユーザ側のSTBがビデオQoEを正常に計算またはアップロードできなくなると、ユーザ側のSTBによってアップロードされたビデオQoEがビデオ監視センターサーバによって永続的に取得および監視できないという従来技術の問題が解決される。

406．データ収集デバイスが第1のネットワークKPIデータをサーバに送信する。

第1のビデオサービスストリームの第1のネットワークKPIデータを収集した後、データ収集デバイスは第1のネットワークKPIデータをサーバに送信する。

407．サーバが第1のパフォーマンスデータを取得する。

サーバは、第1のビデオサービスストリームのビデオサービスを再生する第1のSTBのパフォーマンスデータを取得することができる。具体的には、サーバは、様々なタイプのSTBの初期バッファ情報の、ステップ403で記憶された表から第1のSTBのパフォーマンスデータを取得することができるか、またはビデオ監視センターサーバを使用して第1のSTBのパフォーマンスデータを取得することができる。このことは本明細書では具体的に限定されない。

408．サーバが、関連モデル、第1のネットワークKPIデータ、および第1のパフォーマンスデータに基づいて、第1のビデオQoEを計算する。

サーバは、第1のネットワークKPIデータ内にある第1のビデオサービスストリームのPLR、第1のビデオサービスストリームのRTT、第1のビデオサービスストリームのビデオビットレート、および第1のSTBのパフォーマンスデータを関連モデルに入力し、次いで、関連モデルを使用して第1のビデオサービスストリームの第1のビデオQoEを計算する。したがって、関連モデルを使用してビデオQoEを計算するとき、サーバは、ビデオサービスストリームのネットワークKPIデータであり、データ収集デバイスによって収集されたネットワークKPIデータ、および第1のSTBのパフォーマンスデータのみを使用する必要がある。ユーザ側のSTBはデータ処理プロセスに参加する必要はなく、それによってSTBの負荷が軽減される。加えて、すべてのユーザ側のSTBにプローブを組み込む必要はなく、サーバが関連モデルを確立する段階でごくわずかのユーザ側のSTBしかビデオQoEを提供しない。モデルが確立された後、ビデオサービスストリームのネットワークKPIデータであり、データ収集デバイスによって収集されたネットワークKPIデータのみに応じて、ユーザ側のビデオQoEをすばやく識別することができる。

本出願のこの実施形態では、ターゲットサービスストリームは、暗号化されたストリームであってもよく、暗号化されていないストリームであってもよい。このことは本明細書では具体的に限定される。後続の実施形態では、ターゲットサービスストリームが暗号化されたストリームであるとき、データ収集デバイスは、ターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定する。次いで、データ収集デバイスがターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する一例が説明に使用される。

本出願のこの実施形態では、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、第1のネットワークKPIデータは第1のビデオサービスストリームのネットワークKPIデータであり、第1のビデオサービスストリームは第1のSTBと関連付けられる。次いで、サーバは、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算し、関連モデルは履歴データに基づくトレーニングを介して取得されたモデルである。したがって、サーバは、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームのビデオQoEを計算することができる。このようにして、STBはビデオ停止持続時間比率を収集するためにこれ以上使用されず、STBのパフォーマンスデータに基づいてビデオQoEを計算し、それによってSTBの負荷が大幅に軽減される。

本出願のこの実施形態では、ターゲットサービスストリームが暗号化されたストリームであるとき、データ収集デバイスはターゲットサービスストリームのタイプを検出する。次いで、データ収集デバイスは、ターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定し、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。データ収集デバイスがターゲットサービスストリームのタイプを検出することは、データ収集デバイスが、単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出することにより、ターゲットサービスストリームのタイプを特定するか、またはデータ収集デバイスが、ターゲットサービスストリームのトリプレットを検出することにより、ターゲットサービスストリームのタイプを特定することであってよい。ターゲットサービスストリームのトリプレットは、ターゲットサービスストリームのソースIPアドレス、ターゲットサービスストリームの宛先IPアドレス、およびターゲットサービスストリームを送信するためのトランスポートレイヤプロトコルを含む。このことは本明細書では具体的に限定されない。後続の実施形態では、データ収集デバイスが、単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出することにより、ターゲットサービスストリームのタイプを特定することは、単に説明用の一例として使用される。

本出願のこの実施形態では、ターゲットサービスストリームが暗号化されたストリームであり、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームである場合、データ収集デバイスは、シングルストリームタイプのサービスストリームに基づいて第1の事前設定計算規則を特定することができ、データ収集デバイスは、第1の事前設定計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。第1の事前設定計算規則は、データ収集デバイスが、ターゲットサービスストリームの収集された累積ダウンロード持続時間およびターゲットサービスストリームの収集された累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算することであってよく、または別の計算方法が使用されてよい。このことは本明細書では具体的に限定されない。後続の実施形態では、第1の事前設定計算規則が、データ収集デバイスが、ターゲットサービスストリームの収集された累積ダウンロード持続時間およびターゲットサービスストリームの収集された累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算することであることは、単に説明用の一例として使用される。

本出願のこの実施形態では、ターゲットサービスストリームが暗号化されたストリームであり、ターゲットサービスストリームが、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームである場合、データ収集デバイスは、デュアルストリームタイプのサービスストリームに基づいて第2の事前設定計算規則を特定することができ、データ収集デバイスは、第2の事前設定計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。第2の事前設定計算規則は、データ収集デバイスがオーディオビットレートに基づいてターゲットサービスストリームのビデオビットレートを計算することであってよく、または別の計算方法が使用されてよい。このことは本明細書では具体的に限定されない。データ収集デバイスがオーディオビットレートに基づいてターゲットサービスストリームのビデオビットレートを計算することは、データ収集デバイスが、オーディオビットレート、および事前設定持続時間内のオーディオストリームの累積ダウンロード量に基づいて、オーディオストリームの累積ダウンロード持続時間を計算し、次いで、オーディオストリームの累積ダウンロード持続時間、および事前設定持続時間内のビデオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算することであってよく、またはビデオビットレートを計算するために別の方式が使用されてよい。このことは本明細書では具体的に限定されない。後続の実施形態では、データ収集デバイスがオーディオビットレートに基づいてターゲットサービスストリームのビデオビットレートを計算することは、データ収集デバイスが、オーディオビットレート、および事前設定持続時間内のオーディオストリームの累積ダウンロード量に基づいて、オーディオストリームの累積ダウンロード持続時間を計算し、次いで、オーディオストリームの累積ダウンロード持続時間、および事前設定持続時間内のビデオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算することであると単に記載される。

本出願のこの実施形態では、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであるとき、データ収集デバイスが、ビデオストリームおよびオーディオストリームが同じサービスのサービスストリームであると判断することは、データ収集デバイスが、ターゲットサービスストリームのトリプレットおよびターゲットサービスストリームのタイムスタンプに基づいて、ビデオストリームおよびオーディオストリームが同じサービスのサービスストリームであると判断することであってよく、または判断するために別の方式が使用されてよい。このことは本明細書では具体的に限定されない。後続の実施形態では、データ収集デバイスが、ターゲットサービスストリームのトリプレットおよびターゲットサービスストリームのタイムスタンプに基づいて、ビデオストリームおよびオーディオストリームが同じサービスのサービスストリームであると判断することは、単に説明用の一例として使用される。

本出願のこの実施形態では、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであるとき、データ収集デバイスがオーディオストリームのオーディオビットレートを決定することは、データ収集デバイスが、単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量に基づいて、オーディオストリームのオーディオビットレートを計算することであってよく、またはオーディオビットレートを計算するために別の方式が使用されてよい。このことは本明細書では具体的に限定されない。後続の実施形態では、データ収集デバイスが、単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量に基づいて、オーディオストリームのオーディオビットレートを計算することは、単に説明用の一例として使用される。

本出願のこの実施形態では、ターゲットサービスストリームが暗号化されたストリームであると判断した後、データ収集デバイスは、ターゲットサービスストリームのタイプを特定することにより、ターゲットサービスストリームのビデオビットレートを計算するための計算規則を特定することができる。以下で、図7の実施形態を使用して詳細説明を提供する。

図7を参照すると、図7の実施形態では、データ収集デバイスは、単位時間内に送信されたターゲットサービスストリームのデータパケットの数を特定することによってターゲットサービスストリームのタイプを特定し、ターゲットサービスストリームのタイプに基づいて対応する事前設定計算規則を特定し、次いで、計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。本出願のこの実施形態におけるデータ処理方法の別の実施形態は、以下のステップを含む。

701．データ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームであるかどうかを検出し、データ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームであることを検出した場合、データ収集デバイスがステップ702を実行し、またはデータ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームでないことを検出した場合、データ収集デバイスがステップ714を実行する。

TCPネットワークにおいて、ユーザ側のSTBがビデオサービスを要求し、IPTVサーバがターゲットサービスストリームをユーザ側のSTBに送信する。ターゲットサービスストリームが送信され、すべてのレイヤに配置されたネットワークデバイスを通過するとき、データ収集デバイスは、ネットワークデバイスのいずれか1つに配置されるか、またはバイパスモードで配置されたデータ収集デバイスである。データ収集デバイスは、ターゲットサービスストリームを分析することにより、ターゲットサービスストリームが暗号化されたストリームであるかどうかを判定することができる。データ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームであると判定した場合、データ収集デバイスはステップ702を実行し、またはデータ収集デバイスが、ターゲットサービスストリームが暗号化されたストリームでないと判定した場合、データ収集デバイスはステップ714を実行する。具体的には、暗号化されたストリームの送信中にTCP接続が実行されると、ハンドシェイクを実行して鍵を交換するために特定のプロトコルが使用される。この場合、データ収集デバイスは、暗号化されたストリームの送信中に鍵を交換するために使用されたモードを識別することにより、ターゲットサービスストリームが暗号化されたストリームであると判定することができる。ビデオサービスストリームの送信プロセスでは、暗号化されていないビデオサービスストリームの場合、データ収集デバイスは、ビデオサービスストリームの送信パケットのパケットヘッダをDPI方式でパケット化解除し、パケットヘッダ内のフィールドからビデオサービスストリームのビデオビットレートを読み取ることができる。しかしながら、ビデオサービスストリームが暗号化方式で送信されると、データ収集デバイスは、ビデオサービスストリームのパケットヘッダをパケット化解除することができず、したがって、ビデオサービスストリームのビデオビットレートをDPI方式で読み取ることができない。したがって、本出願では、ターゲットサービスストリームが暗号化されたストリームであるとき、ターゲットサービスストリームのビデオビットレートを取得するための方法が提案される。確かに、ターゲットサービスストリームが暗号化されていないストリームであるときも、ビデオビットレートはこの方法を使用して取得されてよい。

702．データ収集デバイスが、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ないかどうかを判定し、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、データ収集デバイスがステップ703を実行し、または単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少なくない場合、データ収集デバイスがステップ705を実行する。

データ収集デバイスは、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ないかどうかを判定する。単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、データ収集デバイスはステップ703を実行し、または単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多い場合、データ収集デバイスはステップ705を実行する。ネットワークが理想的に良好な状態にあるとき、シングルストリームタイプのサービスストリームの場合、データパケットは、通常、10msごとに送信される。この場合、デュアルストリームタイプのサービスストリームの送信データパケットの数は、シングルストリームタイプのサービスストリームの送信データパケットの数の2倍でなければならない。データ収集デバイスは、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ないかどうかを判定することができる。単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、データ収集デバイスは、ターゲットサービスストリームがシングルストリームであると判断することができる。単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多い場合、データ収集デバイスは、ターゲットサービスストリームがデュアルストリームであると判断することができる。

703．データ収集デバイスが、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断する。

データ収集デバイスが、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ないと判定した場合、データ収集デバイスは、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断することができる。

704．データ収集デバイスが、ターゲットサービスストリームの収集された累積ダウンロード持続時間およびターゲットサービスストリームの収集された累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算する。

オーディオビットレートは、通常、ビデオビットレートよりも低いので、データ収集デバイスが、ターゲットサービスストリームがシングルストリームであると判断した後、データ収集デバイスは、ターゲットサービスストリームの収集された累積ダウンロード量を、ターゲットサービスストリームの累積ダウンロード時間で直接割って、ターゲットサービスストリームの平均ダウンロードレートを計算し、ターゲットサービスストリームの平均ダウンロードレートを、ターゲットサービスストリームのビデオビットレートとして近似することができ、ここで、累積ダウンロード量および累積ダウンロード持続時間はネットワークKPIデータ内にある。たとえば、表6は、ネットワークKPIデータに対応するターゲットサービスストリームのダウンロード状況を示す。表6において、累積ダウンロード時間は、ダウンロード終了時間からダウンロード開始時間を減算することによって得られ、累積ダウンロード量は、ダウンロード終了時間に対応するダウンロード量からダウンロード開始時間に対応するダウンロード量を減算することによって得られる。

表6は、ビデオソース情報、ビデオソースシーケンス（VideoSeq）、累積ビデオダウンロード量（VideoDownOctets）、ダウンロード開始時間（StartTimeSec）、およびダウンロード終了時間（EndTimeSec）を含む。表6に基づいて、図8に示された統計チャートを取得するために、すべての時間期間におけるターゲットサービスストリームのダウンロード量に関する統計収集が実行されてよい。この場合、各時間期間内のターゲットサービスストリームの平均ダウンロードレートを計算することにより、ターゲットサービスストリームのビデオビットレートが近似されてよい。たとえば、T0からT1までの時間期間内のターゲットサービスストリームのビデオビットレート＝平均ダウンロードレートMR1＝（B1＋B2＋B3）／（T1−T0）であり、T1からT2までの時間期間内のターゲットサービスストリームのビデオビットレート＝平均ダウンロードレートMR2＝（B4＋B5）／（T2−T1）であり、T2からT3までの時間期間内のターゲットサービスストリームのビデオビットレート＝平均ダウンロードレートMR3＝（B6＋B7）／（T3−T2）である。したがって、データ収集デバイスは、ネットワークKPIデータから取得されたターゲットサービスストリームの累積ダウンロード持続時間および累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算することができ、データ収集デバイスは、暗号化シナリオにおけるサービスストリームのビデオビットレートを収集することができる。したがって、暗号化されたシングルストリームタイプのターゲットサービスストリームの場合、データ収集デバイスは、ターゲットサービスストリームのビデオビットレートを含むターゲットサービスストリームの完全なネットワークKPIデータをサーバに報告することができる。したがって、この解決策は暗号化シナリオにも適用可能であり、解決策の完全性が向上する。

705．データ収集デバイスが、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断する。

データ収集デバイスが、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多いと判定した場合、データ収集デバイスは、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断することができる。

706．データ収集デバイスが、ターゲットサービスストリームのトリプレットおよびターゲットサービスストリームのタイムスタンプに基づいて、ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームが同じサービスのサービスストリームであると判断する。

データ収集デバイスが、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断した後、データ収集デバイスは、ビデオストリームのトリプレットがオーディオストリームのトリプレットと一致するかどうかを判定する。ビデオストリームのトリプレットは、ビデオストリームのソースIPアドレスおよび宛先IPアドレス、ならびにビデオストリームを送信するためのトランスポートプロトコルを含む。オーディオストリームのトリプレットは、オーディオストリームのソースIPアドレスおよび宛先IPアドレス、ならびにオーディオストリームを送信するためのトランスポートプロトコルを含む。次いで、データ収集デバイスは、TCPネットワーク内のビデオストリーム用のリンク確立のタイムスタンプが、TCPネットワーク内のオーディオストリーム用のリンク確立のタイムスタンプと一致するかどうかを判定する。データ収集デバイスが、ビデオストリームのトリプレットがオーディオストリームのトリプレットと一致し、ビデオストリームのタイムスタンプがオーディオストリームのタイムスタンプと一致すると判定した場合、データ収集デバイスは、ビデオストリームおよびオーディオストリームが同じサービスのサービスストリームであると判断することができる。

707．データ収集デバイスが、ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームにマークを付ける。

データ収集デバイスが、ターゲットサービスストリーム内のオーディオストリームおよびターゲットサービスストリーム内のビデオストリームが同じサービスのサービスストリームであると判断した後、データ収集デバイスは、ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームにマークを付ける。具体的には、オーディオストリームを送信するためのデータパケットのサイズは、ビデオストリームを送信するためのデータパケットのサイズよりはるかに小さい場合がある。したがって、データ収集デバイスは、ターゲットサービスストリームの送信データパケットのサイズに基づいて、ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームを識別しマークを付けることができる。比較的大きい送信データパケットを有するサービスストリームはビデオストリームであり、比較的小さいデータパケットを有するサービスストリームはオーディオストリームである。データ収集デバイスはさらに、別の方式でターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームを識別することができる。このことは本明細書では具体的に限定されない。

708．データ収集デバイスが、単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量を取得する。

データ収集デバイスは、ネットワークKPIデータから、単一のオーディオフラグメント内の、ステップ707でマークを付けられたオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード量を取得する。たとえば、図9は、ビデオストリーム（video）の水平座標およびオーディオストリーム（audio）の水平座標を含む。単一のオーディオフラグメント内のオーディオストリームのダウンロード持続時間はT_chunkであり、単一のオーディオフラグメント内のオーディオストリームのダウンロード量はOctets_chunkであり、初期時間はt₀である。

709．データ収集デバイスが、ダウンロード持続時間およびダウンロード量に基づいて、ターゲットサービスストリーム内のオーディオストリームのオーディオビットレートを計算する。

オーディオは、通常、一定のビットレートでコーディングされる。したがって、データ収集デバイスは、単一のオーディオフラグメント内のオーディオデータのダウンロード持続時間で単一のオーディオフラグメント内のオーディオデータのダウンロード量を割って、ターゲットサービスストリームのオーディオビットレートを取得することができる。計算式（1．4）は以下の通りである。

Ratio_audio＝Octets_chunk／T_chunk （1．4）

式（1．4）において、Ratio_audioはオーディオストリームのオーディオビットレートであり、Octets_chunkは単一のオーディオフラグメント内のオーディオストリームのダウンロード量であり、T_chunkは単一のオーディオフラグメント内のオーディオストリームのオーディオデータのダウンロード時間である。

710．データ収集デバイスが、事前設定持続時間内のオーディオストリームの累積ダウンロード量を取得する。

データ収集デバイスは、ターゲットサービスストリームのネットワークKPIデータから、事前設定持続時間内のマークを付けられたオーディオストリームの累積ダウンロード量を取得する。図9に示されたように、事前設定持続時間は時間Tとして指定され、データ収集デバイスは、時間T内のオーディオストリームの累積ダウンロード量Octets_chunkを収集する。

711．データ収集デバイスが、オーディオビットレート、および事前設定持続時間内のオーディオストリームの累積ダウンロード量に基づいて、オーディオストリームの累積ダウンロード持続時間を計算する。

データ収集デバイスは、事前設定持続時間内のオーディオストリームの累積ダウンロード量をオーディオビットレートで割って、オーディオストリームの累積ダウンロード持続時間を取得する。具体的には、オーディオストリームの累積ダウンロード持続時間は、オーディオストリームの再生時間と見なされてよい。たとえば、図9において、データ収集デバイスは、時間T内のオーディオストリームの累積ダウンロード量を時間Tで割って、オーディオストリームの再生時間を取得する。式（1．5）は以下の通りである。

T_play＝Octets_audio（t₀，T）／Ratio_audio （1．5）

式（1．5）において、T_playはオーディオストリームの累積ダウンロード持続時間であり、Octets_audio（t₀，T）は事前設定持続時間T内のオーディオストリームの累積ダウンロード量であり、Ratio_audioはオーディオストリームのオーディオビットレートである。

712．データ収集デバイスが、事前設定持続時間内のビデオストリームの累積ダウンロード量を取得する。

データ収集デバイスは、ターゲットサービスストリーム内のマークを付けられたビデオストリームのネットワークKPIデータから、事前設定持続時間内の累積ダウンロード量を取得する。たとえば、図9では、データ収集デバイスは、時間T内のビデオストリームの累積ダウンロード量Octets_video（t₀，T）を取得する。

713．データ収集デバイスが、オーディオストリームの累積ダウンロード持続時間、および事前設定持続時間内のビデオストリームの累積ダウンロード量に基づいて、ビデオストリームのビデオビットレートを計算する。

データ収集デバイスは、事前設定持続時間内のビデオストリームの累積ダウンロード量をオーディオストリームの累積ダウンロード持続時間で割って、ビデオストリームのビデオビットレートを取得する。計算式（1．6）は以下の通りである。

式（1．6）において、Ratio_video（t₀，T）はビデオストリームのビデオビットレートであり、Octets_video（t₀，T）は事前設定持続時間T内のビデオストリームの累積ダウンロード量であり、T_playはオーディオストリームの累積ダウンロード持続時間である。したがって、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであるターゲットサービスストリームの場合、データ収集デバイスは、オーディオストリームのオーディオビットレートを計算し、次いで、オーディオビットレートに基づいてビデオストリームのビデオビットレートを関節的に計算する。したがって、データ収集デバイスは、暗号化されたデュアルストリームタイプのサービスストリームのビデオビットレートを取得することができる。言い換えれば、データ収集デバイスは、ターゲットサービスストリームのビデオビットレートを含むターゲットサービスストリームの完全なネットワークKPIデータをサーバに報告することができる。その後、サーバ側は、ネットワークKPIデータに基づいてターゲットサービスストリームのビデオQoEを計算することができる。したがって、この解決策は、暗号化シナリオで互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであるサービスストリームのビデオビットレートの計算にも適用可能である。その結果、解決策の完全性が向上する。

714．データ収集デバイスが別の動作を実行する。

データ収集デバイスが、ターゲットサービスストリームが暗号化されていないストリームであると判断した後、データ収集デバイスは別の動作を実行する。具体的には、データ収集デバイスは、DPI方式でターゲットサービスストリームのビデオビットレートを取得することができる。

本出願のこの実施形態では、データ収集デバイスはターゲットサービスストリームが暗号化されたストリームであると判断し、次いで、データ収集デバイスはターゲットサービスストリームのタイプを検出し、データ収集デバイスはターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定し、データ収集デバイスはターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算することができる。具体的には、データ収集デバイスは、暗号化されたターゲットサービスストリームを識別し、ターゲットサービスストリームのタイプを検出し、ターゲットサービスストリームのタイプに対応するターゲット計算規則を特定し、次いで、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。このようにして、暗号化されたサービスストリームのビデオビットレートが収集される。データ収集デバイスは、サービスストリームのビデオビットレートを含む暗号化されたサービスストリームのネットワークKPIデータをサーバに提供することができ、その結果、本出願のサーバは、その後、暗号化されたビデオサービスストリームのビデオQoEを計算することもでき、それによって解決策の完全性が向上する。

上記は、本出願の実施形態におけるデータ処理方法を記載した。以下で、本出願の実施形態におけるサーバを記載する。図10を参照すると、第2の取得ユニット1003および確立ユニット1004はオプションのユニットである。本出願の実施形態におけるサーバの一実施形態は、
第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のSTBのパフォーマンスデータを取得するように構成された第1の取得ユニット1001であって、第1のネットワークKPIデータが第1のビデオサービスストリームのネットワークKPIデータであり、第1のSTBが第1のビデオサービスストリームを受信するSTBである、第1の取得ユニット1001と、
関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算するように構成された計算ユニット1002であって、関連モデルが履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルがネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される、計算ユニット1002と
を含む。

この実施形態では、サーバは、
履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEを取得するように構成された第2の取得ユニット1003であって、履歴ネットワークKPIデータが複数のビデオサービスストリームのネットワークKPIデータを含み、履歴パフォーマンスデータが複数のビデオサービスストリームを受信するSTBのパフォーマンスデータを含み、履歴ビデオQoEが複数のビデオサービスストリームのビデオQoEを含む、第2の取得ユニット1003と、
履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEに基づいて、関連モデルを確立するように構成された確立ユニット1004と
をさらに含む。

この実施形態では、履歴パフォーマンスデータは、複数のビデオサービスストリームを受信するSTBの初期バッファサイズを含み、履歴ネットワークKPIデータは、複数のビデオサービスストリームのPLR、複数のビデオサービスストリームのRTT、および複数のビデオサービスストリームのビデオビットレートを含む。

この実施形態では、第1のSTBのパフォーマンスデータは、第1のSTBの初期バッファサイズを含み、第1のネットワークKPIデータは、第1のビデオサービスストリームのPLR、第1のビデオサービスストリームのRTT、および第1のビデオサービスのビデオビットレートを含む。

本出願のこの実施形態では、第1の取得ユニット1001は、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、第1のネットワークKPIデータは第1のビデオサービスストリームのネットワークKPIデータであり、第1のビデオサービスストリームは第1のSTBと関連付けられる。

次いで、計算ユニット1002は、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオQoEを計算する。

関連モデルは、履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルは、ネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するために、計算ユニット1002によって使用される。

したがって、第1の取得ユニット1001は、第1のネットワークKPIデータおよび第1のSTBのパフォーマンスデータを取得し、計算ユニット1002は、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームのビデオQoEを計算することができる。

このようにして、STBはビデオ停止持続時間比率を収集するためにこれ以上使用されず、ビデオ停止持続時間比率に基づいてビデオQoEをこれ以上計算せず、それによってSTBの負荷が大幅に軽減される。

上記は、本出願の実施形態におけるデータ処理方法を記載した。以下で、本出願の実施形態におけるデータ収集デバイスを記載する。図11を参照すると、第2の特定ユニット1104はオプションのユニットである。本出願の実施形態におけるデータ収集デバイスの一実施形態は、
ターゲットサービスストリームのタイプを検出するように構成された検出ユニット1101と、
ターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定するように構成された第1の特定ユニット1102と、
ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算するように構成された計算ユニット1103と
を含む。

この実施形態では、ターゲットサービスストリームのタイプは、ビデオストリームおよびオーディオストリームの混合のシングルストリームであり、ターゲット計算規則は第1の事前設定計算規則である。

この実施形態では、計算ユニット1103は、具体的に、
データ収集デバイスによって取得されたターゲットサービスストリームの累積ダウンロード持続時間およびターゲットサービスストリームの累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算する
ように構成される。

この実施形態では、ターゲットサービスストリームのタイプは、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであり、ターゲット計算規則は第2の事前設定規則である。

この実施形態では、計算ユニット1103は、具体的に、
ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームが同じサービスのサービスストリームであると判断し、ターゲットサービスストリーム内のオーディオストリームのオーディオビットレートを決定し、オーディオビットレートに基づいてターゲットサービスストリーム内のビデオストリームのビデオビットレートを計算する
ように構成される。

この実施形態では、計算ユニット1103は、具体的に、
単一のオーディオフラグメント内のターゲットサービスストリーム内のオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のターゲットサービスストリーム内のオーディオストリームのオーディオデータのダウンロード量に基づいて、ターゲットサービスストリーム内のオーディオストリームのオーディオビットレートを計算する
ように構成される。

この実施形態では、計算ユニット1103は、具体的に、
ターゲットサービスストリーム内のオーディオストリームのオーディオビットレート、および事前設定持続時間内のターゲットサービスストリーム内のオーディオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリーム内のオーディオストリームの累積ダウンロード持続時間を計算し、ターゲットサービスストリーム内のオーディオストリームの累積ダウンロード持続時間、および事前設定持続時間内のターゲットサービスストリーム内のビデオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリーム内のビデオストリームのビデオビットレートを計算する
ように構成される。

この実施形態では、データ収集デバイスは、
ターゲットサービスストリームが暗号化されたストリームであると判断するように構成された第2の特定ユニット1104
をさらに含む。

この実施形態では、第2の特定ユニット1104は、具体的に、
単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出し、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断し、または単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多い場合、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断する
ように構成される。

本出願のこの実施形態では、検出ユニット1101がターゲットサービスストリームのタイプを検出し、第1の特定ユニット1102がターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定し、計算ユニット1103がターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算することができる。したがって、検出ユニット1101がターゲットサービスストリームのタイプを検出し、第1の特定ユニット1102がターゲットサービスストリームのタイプに対応するターゲット計算規則を特定し、次いで、計算ユニット1103がターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算する。このようにして、ビデオサービスストリームのビデオビットレートが収集される。データ収集デバイスは、ビデオサービスストリームのビデオビットレートを含むビデオサービスストリームのネットワークKPIデータをサーバに提供することができる。

本出願はサーバ1200をさらに提供する。図12を参照すると、本出願の一実施形態におけるサーバの一実施形態は、
プロセッサ1201、メモリ1202、入出力デバイス1203、およびバス1204
を含む。

プロセッサ1201、メモリ1202、および入出力デバイス1203はバス1204に個別に接続され、メモリはコンピュータ命令を記憶する。

入出力デバイス1203は、第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のSTBのパフォーマンスデータを取得するように構成され、第1のネットワークKPIデータは第1のビデオサービスストリームのネットワークKPIデータであり、第1のSTBは第1のビデオサービスストリームを受信するSTBである。

プロセッサ1201は、関連モデル、第1のネットワークKPIデータ、および第1のSTBのパフォーマンスデータに基づいて、第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算するように構成され、関連モデルは、履歴データに基づくトレーニングを介して取得されたモデルであり、関連モデルは、ネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するためにサーバによって使用される。

可能な実装形態では、プロセッサ1201は、
履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEを取得し、履歴ネットワークKPIデータが複数のビデオサービスストリームのネットワークKPIデータを含み、履歴パフォーマンスデータが複数のビデオサービスストリームを受信するSTBのパフォーマンスデータを含み、履歴ビデオQoEが複数のビデオサービスストリームのビデオQoEを含み、履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEに基づいて、関連モデルを確立する
ようにさらに構成される。

別の可能な実装形態では、履歴パフォーマンスデータは、複数のビデオサービスストリームを受信するSTBの初期バッファサイズを含み、履歴ネットワークKPIデータは、複数のビデオサービスストリームのPLR、複数のビデオサービスストリームのRTT、および複数のビデオサービスストリームのビデオビットレートを含む。

別の可能な実装形態では、第1のSTBのパフォーマンスデータは、第1のSTBの初期バッファサイズを含み、第1のネットワークKPIデータは、第1のビデオサービスストリームのPLR、第1のビデオサービスストリームのRTT、および第1のビデオサービスのビデオビットレートを含む。

本出願はデータ収集デバイス1300をさらに提供する。図13を参照すると、本出願の一実施形態におけるサーバの一実施形態は、
プロセッサ1301、メモリ1302、入出力デバイス1303、およびバス1304
を含む。

プロセッサ1301、メモリ1302、および入出力デバイス1303はバス1304に個別に接続され、メモリ1302はコンピュータ命令を記憶する。

プロセッサ1301は、ターゲットサービスストリームのタイプを検出し、ターゲットサービスストリームのタイプに基づいてターゲット計算規則を特定し、ターゲット計算規則に従ってターゲットサービスストリームのビデオビットレートを計算するように構成される。

可能な実装形態では、ターゲットサービスストリームのタイプは、ビデオストリームおよびオーディオストリームの混合のシングルストリームであり、ターゲット計算規則は第1の事前設定計算規則である。

別の可能な実装形態では、プロセッサ1301は、具体的に、
データ収集デバイスによって取得されたターゲットサービスストリームの累積ダウンロード持続時間およびターゲットサービスストリームの累積ダウンロード量に基づいて、ターゲットサービスストリームのビデオビットレートを計算する
ように構成される。

別の可能な実装形態では、ターゲットサービスストリームのタイプは、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであり、ターゲット計算規則は第2の事前設定規則である。

別の可能な実装形態では、プロセッサ1301は、具体的に、
ターゲットサービスストリーム内のビデオストリームおよびターゲットサービスストリーム内のオーディオストリームが同じサービスのサービスストリームであると判断し、ターゲットサービスストリーム内のオーディオストリームのオーディオビットレートを決定し、オーディオビットレートに基づいてターゲットサービスストリーム内のビデオストリームのビデオビットレートを計算する
ように構成される。

別の可能な実装形態では、プロセッサ1301は、具体的に、
単一のオーディオフラグメント内のターゲットサービスストリーム内のオーディオストリームのオーディオデータのダウンロード持続時間、および単一のオーディオフラグメント内のターゲットサービスストリーム内のオーディオストリームのオーディオデータのダウンロード量に基づいて、ターゲットサービスストリーム内のオーディオストリームのオーディオビットレートを計算する
ように構成される。

別の可能な実装形態では、プロセッサ1301は、具体的に、
ターゲットサービスストリーム内のオーディオストリームのオーディオビットレート、および事前設定持続時間内のターゲットサービスストリーム内のオーディオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリーム内のオーディオストリームの累積ダウンロード持続時間を計算し、ターゲットサービスストリーム内のオーディオストリームの累積ダウンロード持続時間、および事前設定持続時間内のターゲットサービスストリーム内のビデオストリームの累積ダウンロード量に基づいて、ターゲットサービスストリーム内のビデオストリームのビデオビットレートを計算する
ように構成される。

別の可能な実装形態では、プロセッサ1301は、
ターゲットサービスストリームが暗号化されたストリームであると判断する
ようにさらに構成される。

別の可能な実装形態では、プロセッサ1301は、具体的に、
単位時間内に送信されたターゲットサービスストリームのデータパケットの数を検出し、単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より少ない場合、ターゲットサービスストリームがビデオストリームおよびオーディオストリームの混合のシングルストリームであると判断し、または単位時間内に送信されたターゲットサービスストリームのデータパケットの数が事前設定値より多い場合、ターゲットサービスストリームが互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであると判断する
ように構成される。

便利で簡潔な説明のために、記載されたシステム、装置、およびユニットの詳細な動作プロセスについては、前述の方法実施形態における対応するプロセスを参照されたく、本明細書では詳細は再び記載されないことを当業者なら明確に理解されよう。

別の可能な設計では、サーバまたはデータ収集デバイスが端末内のチップであるとき、チップは処理ユニットおよび通信ユニットを含む。処理ユニットは、たとえば、プロセッサであってよい。通信ユニットは、たとえば、入出力インターフェース、ピン、または回路であってよい。処理ユニットは、記憶ユニットに記憶されたコンピュータ実行可能命令を実行することができ、その結果、端末内のチップは、第1の態様または第2の態様のいずれか1つにおけるデータ処理方法を実行する。場合によっては、記憶ユニットは、レジスタもしくはバッファなどのチップ内の記憶ユニットであってよく、または記憶ユニットは、読取り専用メモリ（read−only memory、ROM）、静的な情報および命令を記憶することが可能な別のタイプの静的ストレージデバイス、またはランダムアクセスメモリ（random access memory、RAM））などの、端末内にあるがチップの外側にある記憶ユニットであってよい。

前述されたプロセッサのいずれか1つは、汎用中央処理装置（CPU）、マイクロプロセッサ、特定用途向け集積回路（application−specific integrated circuit、ASIC）、または第1の態様もしくは第2の態様のいずれか1つのデータ処理方法用のプログラムの実行を制御するように構成された1つもしくは複数の集積回路であってよい。

前述の実施形態のすべてまたはいくつかは、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せを使用して実装されてよい。実施形態がソフトウェアを使用して実装される場合、実施形態のすべてまたはいくつかは、コンピュータプログラム製品の形態で実装されてよい。

コンピュータプログラム製品は1つまたは複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ実行されると、本発明の実施形態による手順または機能のすべてまたはいくつかが生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラム可能な装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよく、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてもよい。たとえば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから、別のウェブサイト、コンピュータ、サーバ、またはデータセンタに、有線（たとえば、同軸ケーブル、光ファイバ、もしくはデジタル加入者回線（DSL））、またはワイヤレス（たとえば、赤外線、無線、もしくはマイクロ波）で送信されてよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能媒体、または1つもしくは複数の使用可能媒体を含むサーバもしくはデータセンタなどのデータストレージデバイスであってよい。使用可能媒体は、磁気媒体（たとえば、フロッピーディスク、ハードディスク、または磁気ディスク）、光学媒体（たとえば、DVD）、半導体媒体（たとえば、ソリッドステートドライブ（Solid State Disk、SSD））などであってよい。

本出願で提供されたいくつかの実施形態では、開示されたシステム、装置、および方法は他の方式で実装されてよいことを理解されたい。たとえば、記載された装置実施形態は例にすぎない。たとえば、ユニットへの分割は論理的な機能分割にすぎず、実際の実装形態では他の分割であってよい。たとえば、複数のユニットまたは構成要素は組み合わされるか、もしくは別のシステムに統合されてよく、または、いくつかの機能は無視されるか、もしくは実行されなくてよい。加えて、表示または説明された相互結合または直接結合または通信接続は、いくつかのインターフェースを介して実装されてよい。装置間またはユニット間の間接結合または通信接続は、電気、機械、または別の形態で実装されてよい。

別個の構成要素として記載されたユニットは、物理的に分離していてもしていなくてもよく、ユニットとして表示された構成要素は、物理的なユニットであってもなくてもよい。具体的には、構成要素は、1つの場所に配置されてもよく、複数のネットワークユニットに分散されてもよい。ユニットのいくつかまたはすべては、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてよい。

加えて、本出願の実施形態における機能ユニットは1つの処理ユニットに統合されてよく、またはユニットの各々は物理的に単独で存在してよく、または2つ以上のユニットが1つのユニットに統合されてよい。統合ユニットは、ハードウェアの形態で実装されてもよく、ソフトウェア機能ユニットの形態で実装されてもよい。

統合ユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用されるとき、統合ユニットはコンピュータ可読記憶媒体に記憶されてよい。そのような理解に基づいて、本出願の技術的解決策は本質的に、または従来技術に寄与する部分は、または技術的解決策のうちのすべてもしくはいくつかは、ソフトウェア製品の形態で実装されてよい。コンピュータソフトウェア製品は、記憶媒体に記憶され、本出願の実施形態に記載された方法のステップのうちのすべてまたはいくつかを実行するように、（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってよい）コンピュータデバイスに命令するためのいくつかの命令を含む。前述の記憶媒体には、USBフラッシュドライブ、リムーバブルハードディスク、読取り専用メモリ（ROM、Read−Only Memory）、ランダムアクセスメモリ（RAM、Random Access Memory）、磁気ディスク、および光ディスクなどの、プログラムコードを記憶することができる任意の媒体が含まれる。

前述の実施形態は、本出願の技術的解決策を記載することのみを意図しており、本出願を限定することを意図していない。前述の実施形態を参照して本出願が詳細に記載されたが、当業者は、本出願の実施形態の技術的解決策の趣旨および範囲から逸脱することなく、前述の実施形態に記載された技術的解決策に対して修正をさらに行うか、またはそれらのいくつかの技術的特徴に同等の置換を行うことができることを理解するべきである。

1001 第1の取得ユニット
1002 計算ユニット
1003 第2の取得ユニット
1004 確立ユニット
1101 検出ユニット
1102 第1の特定ユニット
1103 計算ユニット
1104 第2の特定ユニット
1200 サーバ
1201 プロセッサ
1202 メモリ
1203 入出力デバイス
1204 バス
1300 データ収集デバイス
1301 プロセッサ
1302 メモリ
1303 入出力デバイス
1304 バス

Claims (30)

1. データ処理方法であって、
   サーバにより、第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のセットトップボックスSTBのパフォーマンスデータを取得するステップであって、前記第1のネットワークKPIデータが第1のビデオサービスストリームのネットワークKPIデータであり、前記第1のSTBが前記第1のビデオサービスストリームを受信するSTBである、ステップと、
   前記サーバにより、関連モデル、前記第1のネットワークKPIデータ、および前記第1のSTBの前記パフォーマンスデータに基づいて、前記第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算するステップであって、前記関連モデルが履歴データに基づくトレーニングを介して取得されたモデルであり、前記関連モデルがネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するために前記サーバによって使用される、ステップと
   を含む、方法。
2. 前記サーバにより、関連モデル、前記第1のネットワークKPIデータ、および前記第1のSTBの前記パフォーマンスデータに基づいて、前記第1のビデオサービスストリームの第1のビデオQoEを計算する前記ステップの前に、前記方法が、
   前記サーバにより、履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEを取得するステップであって、前記履歴ネットワークKPIデータが複数のビデオサービスストリームのネットワークKPIデータを備え、前記履歴パフォーマンスデータが前記複数のビデオサービスストリームを受信するSTBのパフォーマンスデータを備え、前記履歴ビデオQoEが前記複数のビデオサービスストリームのビデオQoEを備える、ステップと、
   前記サーバにより、前記履歴ネットワークKPIデータ、前記履歴パフォーマンスデータ、および前記履歴ビデオQoEに基づいて、前記関連モデルを確立するステップと
   をさらに含む、請求項1に記載の方法。
3. 前記履歴パフォーマンスデータが、前記複数のビデオサービスストリームを受信する前記STBの初期バッファサイズを備え、前記履歴ネットワークKPIデータが、前記複数のビデオサービスストリームのビデオパケット損失率PLR、前記複数のビデオサービスストリームの往復時間RTT、および前記複数のビデオサービスストリームのビデオビットレートを備える、請求項2に記載の方法。
4. 前記第1のSTBの前記パフォーマンスデータが、前記第1のSTBの初期バッファサイズを備え、前記第1のネットワークKPIデータが、前記第1のビデオサービスストリームのビデオパケット損失率PLR、前記第1のビデオサービスストリームの往復時間RTT、および前記第1のビデオサービスのビデオビットレートを備える、請求項1から3のいずれか一項に記載の方法。
5. データ処理方法であって、
   データ収集デバイスにより、ターゲットサービスストリームのタイプを検出するステップと、
   前記データ収集デバイスにより、前記ターゲットサービスストリームの前記タイプに基づいてターゲット計算規則を特定するステップと、
   前記データ収集デバイスにより、前記ターゲット計算規則に従って前記ターゲットサービスストリームのビデオビットレートを計算するステップと
   を含む、方法。
6. 前記ターゲットサービスストリームの前記タイプが、ビデオストリームおよびオーディオストリームの混合のシングルストリームであり、前記ターゲット計算規則が第1の事前設定計算規則である、請求項5に記載の方法。
7. 前記第1の事前設定計算規則が、
   前記データ収集デバイスが、前記データ収集デバイスによって取得された前記ターゲットサービスストリームの累積ダウンロード持続時間および前記ターゲットサービスストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリームの前記ビデオビットレートを計算すること
   を含む、請求項6に記載の方法。
8. 前記ターゲットサービスストリームの前記タイプが、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであり、前記ターゲット計算規則が第2の事前設定規則である、請求項5に記載の方法。
9. 前記第2の事前設定規則が、
   前記データ収集デバイスが、前記ターゲットサービスストリーム内の前記ビデオストリームおよび前記ターゲットサービスストリーム内の前記オーディオストリームが同じサービスのサービスストリームであると判断し、
   前記データ収集デバイスが、前記ターゲットサービスストリーム内の前記オーディオストリームのオーディオビットレートを決定し、
   前記データ収集デバイスが、前記オーディオビットレートに基づいて前記ターゲットサービスストリーム内の前記ビデオストリームのビデオビットレートを計算すること
   を含む、請求項8に記載の方法。
10. 前記データ収集デバイスが、前記ターゲットサービスストリーム内の前記オーディオストリームのオーディオビットレートを決定することが、
    前記データ収集デバイスが、単一のオーディオフラグメント内の前記ターゲットサービスストリーム内の前記オーディオストリームのオーディオデータのダウンロード持続時間、および前記単一のオーディオフラグメント内の前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオデータのダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオビットレートを計算すること
    を含む、請求項9に記載の方法。
11. 前記データ収集デバイスが、前記オーディオビットレートに基づいて、前記ターゲットサービスストリーム内の前記ビデオストリームのビデオビットレートを計算することが、
    前記データ収集デバイスが、前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオビットレート、および事前設定持続時間内の前記ターゲットサービスストリーム内の前記オーディオストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記オーディオストリームの累積ダウンロード持続時間を計算し、
    前記データ収集デバイスが、前記ターゲットサービスストリーム内の前記オーディオストリームの前記累積ダウンロード持続時間、および前記事前設定持続時間内の前記ターゲットサービスストリーム内の前記ビデオストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記ビデオストリームの前記ビデオビットレートを計算すること
    を含む、請求項9に記載の方法。
12. データ収集デバイスにより、ターゲットサービスストリームのタイプを検出する前記ステップの前に、前記方法が、
    前記データ収集デバイスにより、前記ターゲットサービスストリームが暗号化されたストリームであると判断するステップ
    をさらに含む、請求項5から11のいずれか一項に記載の方法。
13. データ収集デバイスにより、ターゲットサービスストリームのタイプを検出する前記ステップが、
    前記データ収集デバイスにより、単位時間内に送信された前記ターゲットサービスストリームのデータパケットの数を検出するステップと、
    前記単位時間内に送信された前記ターゲットサービスストリームのデータパケットの前記数が事前設定値より少ない場合、前記データ収集デバイスにより、前記ターゲットサービスストリームが前記ビデオストリームおよび前記オーディオストリームの前記混合の前記シングルストリームであると判断するステップ、または
    前記単位時間内に送信された前記ターゲットサービスストリームのデータパケットの前記数が前記事前設定値より多い場合、前記データ収集デバイスにより、前記ターゲットサービスストリームが互いに分離する前記ビデオストリームおよび前記オーディオストリームの前記デュアルストリームであると判断するステップと
    を含む、請求項5から11のいずれか一項に記載の方法。
14. サーバであって、
    第1のネットワークキーパフォーマンスインジケータKPIデータおよび第1のセットトップボックスSTBのパフォーマンスデータを取得するように構成された第1の取得ユニットであって、前記第1のネットワークKPIデータが第1のビデオサービスストリームのネットワークKPIデータであり、前記第1のSTBが前記第1のビデオサービスストリームを受信するSTBである、第1の取得ユニットと、
    関連モデル、前記第1のネットワークKPIデータ、および前記第1のSTBの前記パフォーマンスデータに基づいて、前記第1のビデオサービスストリームの第1のビデオ体験品質QoEを計算するように構成された計算ユニットであって、前記関連モデルが履歴データに基づくトレーニングを介して取得されたモデルであり、前記関連モデルがネットワークKPIデータおよびSTBのパフォーマンスデータに基づいてビデオQoEを計算するために前記サーバによって使用される、計算ユニットと
    を備える、サーバ。
15. 前記サーバが、
    履歴ネットワークKPIデータ、履歴パフォーマンスデータ、および履歴ビデオQoEを取得するように構成された第2の取得ユニットであって、前記履歴ネットワークKPIデータが複数のビデオサービスストリームのネットワークKPIデータを備え、前記履歴パフォーマンスデータが前記複数のビデオサービスストリームを受信するSTBのパフォーマンスデータを備え、前記履歴ビデオQoEが前記複数のビデオサービスストリームのビデオQoEを備える、第2の取得ユニットと、
    前記履歴ネットワークKPIデータ、前記履歴パフォーマンスデータ、および前記履歴ビデオQoEに基づいて、前記関連モデルを確立するように構成された確立ユニットと
    をさらに備える、請求項14に記載のサーバ。
16. 前記履歴パフォーマンスデータが、前記複数のビデオサービスストリームを受信する前記STBの初期バッファサイズを備え、前記履歴ネットワークKPIデータが、前記複数のビデオサービスストリームのビデオパケット損失率PLR、前記複数のビデオサービスストリームの往復時間RTT、および前記複数のビデオサービスストリームのビデオビットレートを備える、請求項15に記載のサーバ。
17. 前記第1のSTBの前記パフォーマンスデータが、前記第1のSTBの初期バッファサイズを備え、前記第1のネットワークKPIデータが、前記第1のビデオサービスストリームのビデオパケット損失率PLR、前記第1のビデオサービスストリームの往復時間RTT、および前記第1のビデオサービスのビデオビットレートを備える、請求項14から16のいずれか一項に記載のサーバ。
18. データ収集デバイスであって、
    ターゲットサービスストリームのタイプを検出するように構成された検出ユニットと、
    前記ターゲットサービスストリームの前記タイプに基づいてターゲット計算規則を特定するように構成された第1の特定ユニットと、
    前記ターゲット計算規則に従って前記ターゲットサービスストリームのビデオビットレートを計算するように構成された計算ユニットと
    を備える、データ収集デバイス。
19. 前記ターゲットサービスストリームの前記タイプが、ビデオストリームおよびオーディオストリームの混合のシングルストリームであり、前記ターゲット計算規則が第1の事前設定計算規則である、請求項18に記載のデータ収集デバイス。
20. 前記計算ユニットが、具体的に、
    前記データ収集デバイスによって取得された前記ターゲットサービスストリームの累積ダウンロード持続時間および前記ターゲットサービスストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリームの前記ビデオビットレートを計算する
    ように構成される、請求項19に記載のデータ収集デバイス。
21. 前記ターゲットサービスストリームの前記タイプが、互いに分離するビデオストリームおよびオーディオストリームのデュアルストリームであり、前記ターゲット計算規則が第2の事前設定規則である、請求項18に記載のデータ収集デバイス。
22. 前記計算ユニットが、具体的に、
    前記ターゲットサービスストリーム内の前記ビデオストリームおよび前記ターゲットサービスストリーム内の前記オーディオストリームが同じサービスのサービスストリームであると判断し、
    前記ターゲットサービスストリーム内の前記オーディオストリームのオーディオビットレートを決定し、
    前記オーディオビットレートに基づいて前記ターゲットサービスストリーム内の前記ビデオストリームのビデオビットレートを計算する
    ように構成される、請求項21に記載のデータ収集デバイス。
23. 前記計算ユニットが、具体的に、
    単一のオーディオフラグメント内の前記ターゲットサービスストリーム内の前記オーディオストリームのオーディオデータのダウンロード持続時間、および前記単一のオーディオフラグメント内の前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオデータのダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオビットレートを計算する
    ように構成される、請求項22に記載のデータ収集デバイス。
24. 前記計算ユニットが、具体的に、
    前記ターゲットサービスストリーム内の前記オーディオストリームの前記オーディオビットレート、および事前設定持続時間内の前記ターゲットサービスストリーム内の前記オーディオストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記オーディオストリームの累積ダウンロード持続時間を計算し、
    前記ターゲットサービスストリーム内の前記オーディオストリームの前記累積ダウンロード持続時間、および前記事前設定持続時間内の前記ターゲットサービスストリーム内の前記ビデオストリームの累積ダウンロード量に基づいて、前記ターゲットサービスストリーム内の前記ビデオストリームの前記ビデオビットレートを計算する
    ように構成される、請求項22に記載のデータ収集デバイス。
25. 前記データ収集デバイスが、
    前記ターゲットサービスストリームが暗号化されたストリームであると判断するように構成された第2の特定ユニット
    をさらに備える、請求項18から24のいずれか一項に記載のデータ収集デバイス。
26. 前記検出ユニットが、具体的に、
    単位時間内に送信された前記ターゲットサービスストリームのデータパケットの数を検出し、
    前記単位時間内に送信された前記ターゲットサービスストリームのデータパケットの前記数が事前設定値より少ない場合、前記ターゲットサービスストリームが前記ビデオストリームおよび前記オーディオストリームの前記混合の前記シングルストリームであると判断するか、または
    前記単位時間内に送信された前記ターゲットサービスストリームのデータパケットの前記数が前記事前設定値より多い場合、前記ターゲットサービスストリームが互いに分離する前記ビデオストリームおよび前記オーディオストリームの前記デュアルストリームであると判断する
    ように構成される、請求項18から24のいずれか一項に記載のデータ収集デバイス。
27. サーバであって、前記サーバが、プロセッサ、メモリ、およびトランシーバを備え、前記プロセッサ、前記メモリ、および前記トランシーバがバスを使用して接続され、前記メモリがコンピュータ命令を記憶し、前記プロセッサが前記コンピュータ命令を実行して、請求項1から4のいずれか一項に記載の前記データ処理方法を実施する、サーバ。
28. データ収集デバイスであって、前記データ収集デバイスが、プロセッサ、メモリ、およびトランシーバを備え、前記プロセッサ、前記メモリ、および前記トランシーバがバスを使用して接続され、前記メモリがコンピュータ命令を記憶し、前記プロセッサが前記コンピュータ命令を実行して、請求項5から13のいずれか一項に記載の前記データ処理方法を実施する、データ収集デバイス。
29. 命令を備えるコンピュータプログラム製品であって、前記コンピュータプログラム製品がコンピュータ上で実行されると、前記コンピュータが請求項1から13のいずれか一項に記載の前記方法を実行することが可能になる、コンピュータプログラム製品。
30. 命令を備えるコンピュータ可読記憶媒体であって、前記命令がコンピュータ上で実行されると、前記コンピュータが請求項1から13のいずれか一項に記載の前記方法を実行することが可能になる、コンピュータ可読記憶媒体。

Images