ホーム > 特許ランキング > ソニーグループ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-08
(45)【発行日】2024-07-17
(54)【発明の名称】端末デバイス、インフラストラクチャ機器および方法
(51)【国際特許分類】
H04W 24/08 20090101AFI20240709BHJP
H04W 88/18 20090101ALI20240709BHJP
【ＦＩ】
H04W24/08
H04W88/18
【請求項の数】
15
(21)【出願番号】P 2023507886
(86)(22)【出願日】2021-07-15
(65)【公表番号】
(43)【公表日】2023-09-04
(86)【国際出願番号】 GB2021051818
(87)【国際公開番号】W WO2022034281
(87)【国際公開日】2022-02-17
【審査請求日】2023-03-30
(31)【優先権主張番号】2012677.7
(32)【優先日】2020-08-13
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】110003339
【氏名又は名称】弁理士法人南青山国際特許事務所
(72)【発明者】
【氏名】スーチュ，ポール
【審査官】横田 有光
(56)【参考文献】
【文献】BBC, Tencent, Sony, Ericsson LM, Qualcomm Incorporated, Enensys，Consolidated changes from SA4#108-e and SA4#109-e [online]，3GPP TSG-SA WG4 Meeting #109-e S4-200882，2020年06月01日，[検索日2024.1.30]，インターネット <URL:https://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_109-e/Docs/S4-200882.zip>
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－ ７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングの方法であって、メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するステップであって、前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義する、前記提供するステップと、
メトリクス・レポーティング・データを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるフォーマットに変換するステップ
を含む
方法。
【請求項2】
前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である請求項１に記載の方法。
【請求項3】
前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい請求項２に記載の方法。
【請求項4】
前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである請求項２又は３に記載の方法。
【請求項5】
前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む請求項１～４のいずれか1つに記載の方法。
【請求項6】
前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある請求項５に記載の方法。
【請求項7】
アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するステップを含む請求項１～６のいずれか1つに記載の方法。
【請求項8】
コンピュータにロードされると、請求項１～７のいずれか1つに記載の方法を実行するように前記コンピュータを設定するコンピュータプログラム。
【請求項9】
サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングのためのインフラストラクチャ機器であって、メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するように構成された回路
を具備し、
前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義し、
前記回路は、メトリクス・レポーティング・データを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるフォーマットに変換するように構成されている、
インフラストラクチャ機器。
【請求項10】
前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である請求項９に記載のインフラストラクチャ機器。
【請求項11】
前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい請求項１０に記載のインフラストラクチャ機器。
【請求項12】
前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである請求項１０又は１１に記載のインフラストラクチャ機器。
【請求項13】
前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む請求項９～１２のいずれか1つに記載のインフラストラクチャ機器。
【請求項14】
前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある請求項１３に記載のインフラストラクチャ機器。
【請求項15】
前記回路は、アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するように構成されている、
請求項９～１４のいずれか1つに記載のインフラストラクチャ機器。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、端末デバイス、インフラストラクチャ機器および方法に関するものである。
【背景技術】
【0002】
本明細書で提供される「背景技術」の説明は、本開示の背景を一般的に提示するためのものである。現在指名されている発明者の研究は、この背景技術の項に記載されている限りにおいて、出願時に先行技術として見なされない明細書の態様と同様に、本発明に対する先行技術として明示的にも暗示的にも認められない。
【0003】
3GPP（登録商標）定義のUMTSおよびLTE(Long Term Evolution)アーキテクチャに基づくものなどの第３世代および第4世代の移動体通信システムは、以前の世代の移動体通信システムによって提供された単純な音声およびメッセージングサービスよりも高度なサービスをサポートすることができる。例えば、LTEシステムによって提供される改善された無線インターフェースおよび拡張されたデータレートを用いて、ユーザは、以前は固定回線データ接続を介してのみ利用可能であったモバイルビデオストリーミングおよびモバイルビデオ会議などの高データレートアプリケーションを享受することができる。したがって、このようなネットワークを配備する要求は強く、これらのネットワークのカバレージエリア、すなわち、ネットワークへのアクセスが可能な地理的場所は、ますます急速に拡大することが予想される。
【0004】
将来の無線通信ネットワークは、現在のシステムがサポートするように最適化されるよりも、より広範囲のデータトラフィックプロファイルおよびタイプに関連する、より広範囲のデバイスとの通信を日常的かつ効率的にサポートすることが期待される。例えば、将来の無線通信ネットワークは、複雑さが低減されたデバイス、マシンタイプ通信(MTC)デバイス、高解像度ビデオディスプレイ、仮想現実ヘッドセットなどを含むデバイスとの通信を効率的にサポートすることが期待される。これらの異なるタイプのデバイスのうちのいくつかは、非常に多数の、例えば、「物のインターネット」をサポートするための低複雑度のデバイスに、配備されてもよく、典型的には比較的高いレイテンシ耐性を有する比較的少量のデータの伝送に関連付けられてもよい。
【0005】
例えば、高精細度ビデオストリーミングをサポートする他のタイプのデバイスは、比較的低遅延耐性を有する比較的大量のデータの送信に関連してもよい。しかし、他のタイプのデバイスは、例えば自律車両通信に使用されるが、遅延がとても少なく信頼性がとても高いネットワークを介して伝送されるべきデータによって特徴付けられる。単一のデバイスタイプは、実行しているアプリケーションに応じて、異なるデータ交通プロファイル/特性に関連付けられる場合もある。例えば、ビデオストリーミングアプリケーション(高ダウンリンクデータ)を実行している場合と、インターネットブラウジングアプリケーション(散発的なアップリンクおよびダウンリンクデータ)を実行している場合とでは、スマートフォンとのデータ交換を効率的にサポートするために、異なる考慮事項が適用されてもよい。また、緊急シナリオで緊急応答者による音声通信に使用される場合もある。
【0006】
これを踏まえて、例えば、5Gまたは新しい無線(NR)システム/新しい無線アクセス技術(RAT)システム、および、既存のシステムの将来のバージョン/リリースと呼ばれてもよいものなど、将来の無線通信ネットワークが、異なるアプリケーションおよび異なる特性データトラフィックプロファイルに関連付けられた広範囲のデバイスのための接続性を効率的にサポートすることが望まれることが予想される。
【0007】
この点に関して現在関心がある分野の一例として、いわゆる「5Gメディアサービスアーキテクチャ」(5GMSA)がある。これは、非特許文献１に記述されている。5GSMAは、より単純でよりモジュール化された設計を提供するように設計されており、サードパーティのコンテンツとサービスプロバイダ、放送局などとの間の異なる協力の度合いを持つサービスを可能にする。このアーキテクチャは、技術的には、サービスベースのアーキテクチャメディアストリーミングネットワークと呼ばれる。このモジュラーシステムは、消費者にメディアコンテンツを配信する機構において非常に規範的な他のシステムとは異なる。これらの規範的なシステムは、エンドツーエンドのサービスアーキテクチャの多くの態様、その完全な一連の機能、およびサービスを容易にする方法(メディア形式、メタデータ形式、配信プロトコル、パフォーマンスを設定、監視、サービスを維持する方法など)を規定する。従って、より柔軟なサービスベースのアーキテクチャメディアストリーミングネットワークを採用することが望まれ、これにより、メディアストリーミングサービスプロバイダは、メディア・フォーマット、メタデータ・フォーマット、一連のサービス機能などに関して、自身の嗜好に応じて、それらのサービスをよりよく実施することができる。本開示は、このより柔軟なアーキテクチャに関する。
【0008】
このアーキテクチャでは、メトリック・レポーティング（メトリクス・レポーティング）は非特許文献１の5.5節で言及されている。具体的には、メトリック・レポーティングの2つの形態について言及する。1つ目はいわゆる「帯域内」メカニズムを使用し、2つ目はいわゆる「帯域外」メカニズムを使用する。帯域内メカニズムは、コンテンツ・マニフェストでメトリックの報告が行われる場所であり、5.5.3条項で説明されている。帯域外メカニズムは、コンテンツ・マニフェストとは別にメトリックの報告が行われる場所であり、5.5.2条項で説明されている。これらの記述されたメカニズムは両方とも、ここで記述される欠点を持っている。
【0009】
帯域内メカニズムはアプリケーションサーバ(AS)を介して実行されるため、ユーザプレーンにある。これは、(メトリック・レポーティングで提供される)体験品質(QoE)測定量を獲得するための事象のシーケンスが、5GMSにおけるメディア・サービス提供の全体的なフレームワークに関して複雑であることを意味する。特に、メディア・プレーヤがアプリケーションサーバにメタデータを要求し、メトリック構成が、返されるメタデータに含まれることは非論理的である。そのため、メトリック構成は、メディア・プレーヤからメディア・セッション・ハンドラ（Media Session Handler）に渡され、渡された構成に従ってメディア・プレーヤでメトリックジョブの作成を要求する。
【0010】
さらに、非特許文献１の図4.2.2-2には、UEのメディア・セッション・ハンドラと5GMSdアプリケーション機能との間でメトリック・レポーティング機能が通信されるという不一致がある。しかしながら、これは、メトリック・レポーティング構成の帯域内方法が、インターフェースM4dを介して、UE内の5GMSdアプリケーションサーバとメディア・プレーヤの間に、構成データを提供することを含むことを含むことがきわめて明白である場合の説明と矛盾する。
【0011】
メトリック・レポーティングが帯域内メカニズムを使って実行される複雑さと柔軟性の欠如は、サービスプロバイダがそれを利用する可能性が低いことを意味する。さらに、この複雑さは、ネットワークとUEが必要とするシグナリングと処理の量を増加させる。
【0012】
しかし、4.7.5条項の最新の作業原案(執筆時点)である非特許文献３で使用されている帯域内メカニズムでは、メトリック・レポーティングは、その目的のためにプロビジョニングされ、5GMSアーキテクチャで識別可能なエンティティではないあらゆる種類のサーバである「運用、管理、保守」サーバによって制御されると述べている。さらに、4.9.2条項では、メトリック・レポーティングは帯域内でUEに送られ、さらに、その特定のフォーマットで定義されたメトリクス(すなわち、それ自体がMPEG-DASHに基づいている非特許文献２で述べられているTS26.247に準拠している)に対してのみ機能する。(帯域内メトリック・レポーティングで要求されている)このメトリック・レポーティングのコンテンツのフォーマットへのリンクは、非特許文献１で説明されているシステムの柔軟性に反する。
【0013】
帯域外メトリック・レポーティングに関しては、ネットワーク制御プレーンでメトリック・レポーティングが行われる。具体的には、非特許文献２に記述されているように、メトリック・レポーティングはRRCメッセージとして発生する。これには少なくとも1つの欠点がある。多くの場合、メトリック・レポーティングが適用されるメディアストリームまたはコンテンツを配信するサービスプロバイダは、QoEメトリック・レポーティングを直接送信しない。これにより、関係者(サービスプロバイダ)にQoEメトリック・レポーティングを中継するために追加の情報（インテリジェンス）が必要になるため、システムの複雑さが増す。
【0014】
従って、サービスプロバイダが直接QoEメトリック・レポーティングを受信することを可能にする一方で、サービスベースのアーキテクチャメディアストリーミングネットワークの柔軟性を維持するメトリック・レポーティング・メカニズムを提供することが、本開示の目的である。
【先行技術文献】
【非特許文献】
【0015】
【文献】3GPP TS 26.501 V16.3.0 "5G Media Streaming (5GMS) General Description and Architecture".
【文献】3GPP TS 26.247 V16.3.0 "Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)".
【文献】Holma H. and Toskala A, "LTE for UMTS OFDMA and SC-FDMA based radio access", John Wiley and Sons, 2009.
【文献】3GPP TS 23.501 V16.4.0 "System Architecture for the 5G System".
【文献】3GPP TS 26.512 VI.2.0 "5G Media Streaming (5GMS) Protocols".
【文献】3GPP TS 26.247 V16.3.0 "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)".
【文献】CTA 2066: CTA Standard; Streaming Quality of Experience Events, Properties and Metrics (March 2020).
【文献】IETF RFC 7230: "Hypertext-Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
【文献】IETF RFC 7231: "Hypertext-Transfer Protocol (HTTP/1.1): Semantics and Content".
【発明の概要】
【0016】
本開示は、特許請求の範囲で定義されているように、上記で議論された問題の少なくとも一部を解決または緩和するのに役立つ。
【0017】
本開示の実施形態によれば、サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングの方法であって、上記方法は、メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するステップを含み、上記メトリクス収集およびレポーティング構成フレームワークは、上記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される上記メトリクスを定義する。他の特徴および実施形態は、特許請求の範囲に記載される。
【0018】
前述の一般的な説明および以下の詳細な説明の両方が、本技術の例示ではあるが、本技術を限定するものではないことを理解されたい。説明される本実施形態は、さらなる利点とともに、添付の図面と併せて以下の詳細な説明を参照することによって最もよく理解される。
【図面の簡単な説明】
【0019】
いくつかの図を通して同じ参照番号が同一または対応する部品を示すので、以下の詳細な説明を、添付の図面と併せて考察すると、本開示およびそれに付随する多くの利点が、以下の詳細な説明を参照することによってよりよく理解される。
【図1】本開示の特定の実施形態に従って動作するように構成されたLTEタイプまたは5Gタイプのワイヤレス電気通信システムのいくつかの態様を概略的に表したものである。
【図2】本開示の特定の実施形態に従って動作するように構成された新しい無線アクセス技術(RAT)無線電気通信システムのいくつかの例示的な態様を概略的に表したものである。
【図4】本開示の実施形態による媒体アーキテクチャを概略的に示したものである。
【図5】本開示の実施形態に従って、メディア・ストリーミング・プロビジョニング・インターフェースを説明するメディア・アーキテクチャを示す。
【図6A】本開示の実施形態に係る1つのフローチャートを示す。
【図6B】本開示の実施形態に係る1つのシーケンス図を示す。
【図7】2つのメディア・コンテンツ・プロバイダが存在する場合の、本開示の実施形態に係るメディア・アーキテクチャを概略的に示す。
【図8】AおよびBは、インフラストラクチャ機器11において実行される2つのプロセスを示す。
【図9】UE 14で実行されるプロセスを示す。
【発明を実施するための形態】
【0020】
（Long Term Evolution(LTE)無線通信システム）
図1は、一般にLTE原理に従って動作するが、他の無線アクセス技術もサポートすることができ、本明細書で説明されるような本開示の実施形態を実装するように適合させることができる、モバイル遠隔通信ネットワーク/システム10のいくつかの基本的な機能を示す概略図を提供する。図1の様々な要素およびそれらのそれぞれの動作モードの特定の態様は、3GPP(RTM)機関によって管理される、関連する規格において周知であり、定義もされており、また、その議題に関する多くの書籍、例えば、Holma H.およびToskala Aの非特許文献３にも記載されている。本明細書で特に記載されていない電気通信ネットワークの動作態様(例えば、異なる要素間で通信するための特定の通信プロトコルおよび物理チャネルに関して)は、例えば、関連する規格およびその関連する規格に対する既知の提案された修正および追加に従った、任意の既知の技法に従って実装され得ることが理解される。
図1は、一般にLTE原理に従って動作するが、他の無線アクセス技術もサポートすることができ、本明細書で説明されるような本開示の実施形態を実装するように適合させることができる、モバイル遠隔通信ネットワーク/システム10のいくつかの基本的な機能を示す概略図を提供する。図1の様々な要素およびそれらのそれぞれの動作モードの特定の態様は、3GPP(RTM)機関によって管理される、関連する規格において周知であり、定義もされており、また、その議題に関する多くの書籍、例えば、Holma H.およびToskala Aの非特許文献３にも記載されている。本明細書で特に記載されていない電気通信ネットワークの動作態様(例えば、異なる要素間で通信するための特定の通信プロトコルおよび物理チャネルに関して)は、例えば、関連する規格およびその関連する規格に対する既知の提案された修正および追加に従った、任意の既知の技法に従って実装され得ることが理解される。
【0021】
ネットワーク10は、コアネットワーク部12に接続された複数の基地局11を含む。各基地局は、通信デバイス14との間でデータを通信することができるカバレージエリア13(例えば、セル)を提供する。データは、基地局11から、それぞれのカバレージエリア13内の通信デバイス14に、無線ダウンリンクを介して送信される。通信デバイス14から基地局11へは、無線アップリンクを介してデータが送信される。コアネットワーク部12は、各基地局11を介して通信デバイス14との間でデータの送受信を行うものであり、認証、モビリティ管理、課金等の機能を提供する。通信デバイスは、移動局、ユーザ機器(UE)、ユーザ端末、モバイル無線、端末デバイスなどと呼ばれることもある。ネットワークインフラストラクチャ機器／ネットワークアクセスノードの一例である基地局は、トランシーバ局、ノードB、 eノードB、eNB、gノードB、gNBなどと呼ばれることもある。この点で、異なる用語は、広く同等の機能性を提供する要素のための異なる世代の無線電気通信システムに、しばしば関連する。しかしながら、本開示の例示的な実施形態は、異なる世代の無線電気通信システムにおいて同等に実装されてもよく、簡潔にするために、基礎となるネットワークアーキテクチャにかかわらず、特定の用語が使用されてもよい。すなわち、特定の実施例に関連する特定の用語の使用は、これらの実施例がその特定の用語に最も関連する可能性のある特定の世代のネットワークに限定されることを示すことを意図していない。
【0022】
（新しい無線アクセス技術（5G））
上述したように、本発明の実施形態は、5GまたはNR(新しい無線)無線アクセス技術と称されるもののような高度な無線通信システムを用いてアプリケーションを見出すことができる。NRで考慮されるユースケースには、次のものがある。
・ 拡張モバイルブロードバンド(eMBB);
・ 大規模マシンタイプ通信(mMTC);
・ 超高信頼低遅延(Ultra Reliable & Low Latency Communications (URLLC));
・ 拡張超高信頼低遅延(Enhanced Ultra Reliable & Low Latency Communications (eURLLC))
上述したように、本発明の実施形態は、5GまたはNR(新しい無線)無線アクセス技術と称されるもののような高度な無線通信システムを用いてアプリケーションを見出すことができる。NRで考慮されるユースケースには、次のものがある。
・ 拡張モバイルブロードバンド(eMBB);
・ 大規模マシンタイプ通信(mMTC);
・ 超高信頼低遅延(Ultra Reliable & Low Latency Communications (URLLC));
・ 拡張超高信頼低遅延(Enhanced Ultra Reliable & Low Latency Communications (eURLLC))
【0023】
eMBB サービスは、最大20Gb/sをサポートする要件を持つ大容量が特徴である。URLLC サービスでは、レイヤ2のパケットが1ミリ秒未満または0.5 ミリ秒(信頼度は99.999%～99.9999%)のレイテンシで送信される必要がある。
【0024】
図1に示される無線アクセスネットワークの要素は、用語の変更が上述のように適用され得ることを除いて、5Gの新しいRAT構成に等しく適用され得る。
【0025】
図2は、本明細書で説明される本開示の実施形態による機能を提供するようにも適合され得る、以前に提案されたアプローチに基づく、新しいRAT無線移動電気通信ネットワーク/システム30のためのネットワークアーキテクチャを示す模式図である。図2に示される新しいRATネットワーク30は、第1の通信セル21と第2の通信セル22とを備える。各通信セル21、22は、それぞれの有線または無線リンク36, 38を介してコアネットワーク要素31と通信する制御ノード(集中型ユニット、CU)26, 28を含む。また、各制御ノード26, 28は、それぞれのセル内の複数の分散ユニット(無線アクセスノード/遠隔送受信ポイント(TRP))22, 24とも通信している。この場合も、これらの通信は、それぞれの有線または無線リンクを介して行うことができる。分散ユニット22, 24は、ネットワークに接続された端末デバイスのための無線アクセスインターフェースを提供する責任を負う。各分散ユニット22, 24は、それぞれの通信セル20, 21のカバレッジを共に定義するカバレージエリア(無線アクセスフットプリント)32, 34を有する。各分散ユニット22, 24は、無線信号の送受信のための送受信機回路(トランシーバ回路)22a, 24aと、それぞれの分散ユニット22, 24を制御するように構成されたプロセッサ回路（コントローラ回路）22b, 24bとを含む。
【0026】
広大なトップレベルの機能性の観点から、図2に表されるNew RAT電気通信ネットワークシステムのコアネットワーク要素31は、図1に表されるコアネットワーク12に対応すると広く考慮することができる。そして、それぞれの制御ノード26, 28およびそれらの関連する分散ユニット/TRP22, 24は、図1の基地局11に対応する機能を提供すると広く考慮することができ、したがって、これらの用語(実際にはeNodeB, eNB, gNodeB, gNBなど)は互いに代替できる。ネットワークインフラストラクチャ機器/アクセスノードという用語は、これらの構成要件および無線電気通信システムのより従来の基地局型の構成要件を包含するために使用されてもよい。手元のアプリケーションに応じて、それぞれの分散ユニットと端末デバイスとの間の無線インターフェース上でスケジュールされる伝送をスケジュールする義務は、制御ノード/中央ユニット、および/または、分散ユニット/TRPにあるといってもよい。
【0027】
図2には、第１の通信セル20のカバレージエリア内にある端末デバイス40が示されている。したがって、この端末デバイス40は、第１の通信セル20に関連する分散ユニット22のうちの1つを介して、第１の通信セル20内の第１の制御ノード26と信号を交換することができる。場合によっては、所与の端末デバイスに対する通信は、分散ユニットのうちの1つだけを経由してルーティングされるが、所与の端末デバイスに関連する他の何らかの実装通信においては、例えばソフトハンドオーバシナリオおよび他のシナリオにおいて、複数の分散ユニットを経由してルーティングされてもよいことが理解される。
【0028】
端末デバイスが関連する制御ノードを介して現在接続されている特定の(複数の)分散ユニットは、端末デバイス用の活性分散ユニットと呼ばれることがある。従って、端末デバイス用の分散ユニットのアクティブサブセットは、1つ以上の分散ユニット(DU/TRP)を含んでもよい。制御ノード26は、第1の通信セル20にまたがっている分散ユニット22のうちのどれが、端末デバイス14との無線通信に、任意の時点で責任を負っているか(すなわち、分散ユニットのどれが、端末デバイスに対して現在活性分散ユニットであるか)を判定する責任を負う。通常、これは、端末デバイス14と分散ユニット22のそれぞれとの間の無線チャネル条件の測定に基づくことになる。この点で、端末デバイスに対して現在アクティブであるセル内の分散ユニットのサブセットは、少なくとも部分的に、セル内の端末デバイスの位置に依存することが理解されよう(これは、端末デバイスと分散ユニットのそれぞれのものとの間に存在する無線チャネル条件に大きく寄与するので)。
【0029】
少なくともいくつかの実装では、端末デバイスから制御ノード(制御ユニット)へのルーティング通信における分散ユニットの関与は、端末デバイス14に対してトランスペアレントである。すなわち、分散ユニットが、端末デバイス14と、その端末デバイスが現在動作している通信セル20の制御ノード26との間の通信のルーティングを担当しているのか、あるいは、何らかの分散ユニット22が制御ノード26に接続されていて、通信のルーティングに関与しているのかを全く認識していない場合がある。このような場合、端末デバイスに関する限り、単に制御ノード26にアップリンクデータを送信し、制御ノード26からダウンリンクデータを受信するだけであり、端末デバイスは分散ユニット22の関与を認識しないが、分散ユニット22によって送信される無線構成を認識してもよい。しかしながら、他の実施形態では、端末デバイスが、どの(複数の)分散ユニットがその通信に関与しているかを認識してもよい。1つ以上の分散ユニットのスイッチングおよびスケジューリングは、端末デバイスアップリンク信号の分散ユニットによる測定または端末デバイスによって取得され、1つ以上の分散ユニットを介して制御ノードに報告される測定に基づいて、ネットワーク制御ノードで行われてもよい。
【0030】
図2の例では簡略化のために、2つの通信セル20、21および1つの端末デバイス14が示されているが、実際にはシステムは、(それぞれの制御ノードおよび複数の分散ユニットによってサポートされる)より多数の端末デバイスにサービスを提供する、より多数の通信セルを備えることができることが理解される。
【0031】
さらに、図2は、本明細書に記載する原理に従ったアプローチが採用され、本明細書に開示する機能性が異なるアーキテクチャを有する無線電気通信システムに関しても適用され得る、新しいRAT電気通信システムのための提案されたアーキテクチャの単なる一例を表すに過ぎないことが理解される。
【0032】
したがって、本明細書で説明する本開示の特定の実施形態は、図1および2に示す例示のアーキテクチャのような様々な異なるアーキテクチャに従って、無線電気通信システム/ネットワークで実施することができる。
【0033】
したがって、任意の所定の実装における特定の無線電気通信アーキテクチャは、本明細書に記載する原理にとって主要な重要性がないことが理解される。この点に関して、本開示の特定の実施形態は一般に、ネットワークインフラストラクチャ機器/アクセスノードおよび端末デバイスとの間の通信状況で説明することができ、ネットワークインフラストラクチャ機器/アクセスノードおよび端末デバイスの特定の性質は、目前の実装形態のためのネットワークインフラストラクチャに依存する。例えば、いくつかのシナリオでは、ネットワークインフラストラクチャ機器/アクセスノードは、本明細書に記載する原則に従って機能性を提供するように構成された図1に示されるようなLTE型基地局11のような基地局を備えることができ、他の例では、ネットワークインフラストラクチャ機器は、本明細書に記載する原則に従って機能性を提供するように構成された図2に示される種類の制御部/制御ノード26、28および/またはTRP 22、24を備えることができる。
【0034】
図3は、図1の端末デバイス14およびインフラストラクチャ機器11を概略的に示す。端末デバイス14は、インフラストラクチャ機器11と無線で通信する送受信機（トランシーバ）14-1を含む。トランシーバ14-1は、端末デバイス14内に配置された処理回路（プロセッサ回路）14-2によって制御される。処理回路14-2は、特定用途向け集積回路などの任意の種類の回路として具現化することができ、マイクロプロセッサとして具現化してもよい。処理回路14-2自体は、記憶装置14-3に記憶されるソフトウェア・コードによって制御される。記憶装置14-3は、典型的には、プログラムコードを記憶するように設計されたソリッドステート回路として具現化される。
【0035】
同様に、インフラストラクチャ機器11は、端末デバイス14と無線で通信するトランシーバ（送受信機）11-1を含む。トランシーバ11-1は、インフラストラクチャ機器11内に配置された処理回路（プロセッサ回路）11-2によって制御される。処理回路11-2は、特定用途向け集積回路などの任意の種類の回路として具現化することもできるし、マイクロプロセッサとしてもよい。処理回路11-2自体は、記憶装置11-3に記憶されるソフトウェア・コードによって制御される。記憶装置11-3は、典型的には、プログラムコードを記憶するように設計されたソリッドステート回路として具現化される。
【0036】
図4は、本開示の実施形態による媒体アーキテクチャを概略的に示す。アプリケーション14Aおよびメディア・ストリーミング・クライアント14Bは、端末デバイス14内の処理回路14-2上で実行される。無線アクセスネットワークモデム/ドライバ14Eは、トランシーバ14-1上に具現化される。5GMSクライアントは、ダウンリンク・メディア・ストリーミング・サービスを受信し、定義されたインターフェース/アプリケーション・プログラム・インターフェイス(API)を介してアクセスできるアップリンク・メディア・サービスを提供する。メディア・ストリーミング・クライアント14Bは、端末デバイス14内の処理回路14-2上で実行される2つのサブ機能を含む。2つのサブ機能は、メディア・セッション・ハンドラ14Cおよびメディア・プレーヤ14Dである。メディア・セッション・ハンドラ14Cは、端末デバイス14内のメディア・セッションを確立し、制御し、サポートする機能であり、インフラストラクチャ機器11内の処理回路11-2上で実行されるメディア・アプリケーション機能メディアAF11Aと通信する。メディアAF 11Aは、非特許文献４の条項6.2.10で定義されるものと類似しており、メディア・セッション・ハンドラ14Cに様々な制御機能を提供する。メディア・プレーヤ14Dは、端末デバイス14上にメディアコンテンツをストリーミングし、インフラストラクチャ機器11内の処理回路11-2上で動作するメディア・アプリケーション・サーバ11Bと通信し、5Gメディア機能をホストする機能である。メディアAF 11AおよびメディアAS 11Bは、インフラストラクチャ機器11上で動作するように示されているが、これは便宜上のものであり、典型的には、データネットワーク機能であることに留意されたい。さらに、ユーザプレーン機能12および無線アクセスネットワーク13を示す。これらは、理解されるように、インフラストラクチャ機器11内の各レイヤである。
【0037】
さらに、図4に示すのは、メディア・アプリケーション・サービス・プロバイダ110である。これは、ネットワーク経由でストリーミングされるメディアコンテンツのプロバイダである。図4に示すように、本開示の実施形態では、メディア・アプリケーション・サービス・プロバイダは、メディアAF 11Aと通信するメトリック管理レイヤ110Aと、メディアAS 11Bにストリームされるコンテンツを通信するコンテンツ・プロビジョニング / サービングレイヤ110Bとを含む。メトリック管理レイヤ110AがメディアAF 11Aと通信するように記述されている一方で、本実施形態では、メトリック管理レイヤ110Aは、メトリック構成およびレポーティングサーバAFと通信し、このAFは、メディアAF 11への別個のエンティティであってもよく、したがって、メディアAF 11への別個のIPアドレス上に配置されてもよい。しかしながら、本実施形態では、メトリック構成およびレポーティングサーバAFは、メディアAF 11と同じサーバ上にあってもよい。メトリック構成およびレポーティングサーバAFは、モバイルネットワークオペレータ(MNO)によって提供されてもよく、MNOネットワークで信頼されたエンティティとして動作するか、または、アプリケーションサービスプロバイダによって提供される。MNOネットワークでは、MNOとアプリケーションサービスプロバイダの関係に応じて、信頼できるエンティティまたは信頼できない外部エンティティとして動作する。
【0038】
メトリック管理レイヤ110Aは、メディア・ストリーミング・ネットワークを介してメディアAF 11Aにメディア・セッションについて収集かつ報告されるメトリックを定義するメトリック収集およびレポーティング構成フレームワークを通信する。言い換えると、メトリック管理レイヤ110Aは、メディア・コンテンツ・プロバイダがメディア・セッションの間または後に収集することを望むメトリックを定義するフレームワークを提供する。本実施形態に係るフレームワークについては、後述する。理解されるように、ストリームされるメディアコンテンツにメトリック収集およびレポーティング設定フレームワークを別々に提供することは、メトリック報告が帯域外メカニズムを使用して実行されることを意味する。ただし、現在の帯域外メカニズムとは異なり、メトリックはサービスプロバイダによって定義され、現在説明されているとおり、サービスプロバイダに直接提供される。これにより、前に説明したように、システムの複雑さが軽減される。
【0039】
メディア・ストリーミング・セッションの開始時に、メディア・アプリケーション・サービス・プロバイダはメディア・ストリーミング・プロビジョニング・インターフェースを開始する。本開示の実施形態では、本開示はそれに限定されないが、メディア・ストリーミング・プロビジョニング・インターフェースは、非特許文献５で定義されているM1d (5GMSプロビジョニング)インターフェースである。特に、図4に示すように、メトリック管理レイヤ110Aは、メディア・ストリーミング・プロビジョニング・インターフェースを介してメディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集および報告されるメトリックを定義するフレームワークを提供する。これは、メディアAF 11Aに提供される。
【0040】
メディアAF 11Aは、本実施形態では、メトリック収集およびレポーティング構成フレームワークを、本実施形態では非特許文献４のM5dであるメディア・セッション処理インターフェースを介してUE14に送る。具体的には、メトリック収集およびレポーティング構成フレームワークは、UE14内のメディア・ストリーミング・クライアント14B内のメディア・セッション・ハンドラ14Cに送られる。
【0041】
ここで、メディア・ストリーミング・プロビジョニング・インターフェースは、図5を参照して説明する。メディア・ストリーミング(5GMS)サービスでは、メディア・アプリケーション・サービスプロバイダ(ASP)110は、第三者によって運用されるエンティティであり、つまりMNOではない。
【0042】
この場合、メディア・ストリーミング・プロビジョニング・インタフェース(M1d)を使用して、メディアAF 11Aにメディア・ストリーミング・セッションをプロビジョニングする。このプロビジョニングには、ASP110で必要な場合、メディアAFに構成を報告するメトリックのプロビジョニングが含まれる。
【0043】
理解されるように、M1dインターフェースは、MNO自体がASPとして動作するときにも使用することができるが、この場合、MNOは、メディアAF 11Aに様々なプロビジョニング機能を統合することによって、または、プロビジョニングを報告するメトリックを含むサービスプロビジョニングを実行するために独自のシステムおよびインターフェースを使用することによって、メディア・ストリーミング・サービス・オペレーションを合理化することができる。しかし、この場合も、本実施形態では、M4dおよびM5dインターフェースの仕様に従って、UE14との通信が依然として実行される。
【0044】
上述したように、本開示の実施形態によれば、メトリクス・レポーティング・プロビジョニング・インターフェースは、必要に応じて、関連するメディア・ストリーミングおよびコンテンツ・プロビジョン・サービス・セッションのためのメトリック・レポーティング操作をセットアップするために、ASPによって使用される。
【0045】
対応するメトリクス・レポーティング・プロビジョニングAPIは、メトリクス・レポーティング・プロビジョニング・インターフェースの機能を実現するために定義される。
【0046】
対応するメトリクス・レポーティング・プロビジョニングAPIは、本実施形態に従って、REST APIとして定義される。従って、メトリクス・レポーティング・プロビジョニングAPIは、メトリクス・レポーティング・プロビジョニング用に、ASP機能エンティティとメディアAF 11Aとの間でメッセージを交換するために、HTTP（非特許文献８）プロトコル構成を使用する。
【0047】
メトリクス・レポーティング・プロビジョニングAPIは、本実施形態では、既に非特許文献５で定義されている5GMS APIの一般的なフレームワークに従って構築されたURI経路を介してアクセス可能であり、以下のURIベース経路定義は、メトリクス・レポーティング・プロビジョニングAPI用のURI経路の1つの可能なモデルである。
【0048】
{apiRoot}/3gpp-mld/vl/provisioning-sessions/{provisioningSessionId}/metrics-reporting-provisioning
【0049】
文字列「metrics-reporting-provisioning」は、バージョン「v1」の定義において、インターフェースM1dの「provisioning sessions」APIのいわゆるサブリソースパスである。このサブリソースパスは、この場合、メトリクス・レポーティング・プロビジョニング用の、M1dプロビジョニング・インターフェース内の機能エンティティを識別する。「apiRoot」は、通常、5GMS APIの配備（デプロイメント）に設定される。
【0050】
「provisioingSessionId」は、メトリクス・レポーティング・プロビジョニングが実行されるプロビジョニングセッションを意味する。
【0051】
リソース、サブリソース、およびその他のURIパスコンポーネントの正確な名前は異なる選択が可能であるが、URLパスの必要な要素であるメトリクス・レポーティング・プロビジョニングAPIを特定するために、いくつかの固有の名前が使用されることが望ましい。
【0052】
共通のREST API定義に沿って、特定のHTTP方法を使用してRESTオペレーションを呼び出し、メトリクス・レポーティング・プロビジョニングを処理する。ASP機能エンティティは、例えば、メトリック管理層110Aは、メディアAF 11Aでメトリクス・レポーティングを提供するために、メディアAF 11Aに、このようなHTTP方法メッセージを発行し、これは、後述するように、メディアAF 11Aとのメディア・ストリーミング・セッションを確立することによって、関連するメディア・ストリーミング・サービスにアクセスするすべてのUEにおいて、状況に応じてメトリクス・レポーティングを構成する。
【0053】
メトリクス・レポーティング・プロビジョニングAPIで使用されるHTTP方法を、以下の表１に示す。このテーブルには、メトリクス・レポーティング・構成に関連する各方法の意図された意味が記載されている。
【0054】
メディアAF 11Aが、メトリクス・レポーティング・プロビジョニングAPI HTTPメッセージのいずれかを受信すると、それらを処理し、IETF RFC 7231（非特許文献９）で定義され、場合によっては非特許文献５で5GMS用にさらに詳細化された既知のHTTP応答を使用して、ASPエンティティに適切に応答する。
【0055】
メトリクス・レポーティング・プロビジョニングAPI用のすべてのHTTP方法は、特定の既存のメディア・ストリーミング・セッションに適用される。
【0056】
表１ - メトリクス・レポーティング・プロビジョニング API用のHTTP方法の使用状況．
【表1】
【0057】
いわゆるメトリクス構成リソースは、特定のメディア・ストリーミング・セッション内のメトリクス・レポーティング機能の構成設定を含むデータ構造として定義される。メトリクス構成リソースの構造と内容を表２に示す。メトリクス構成リソースのこの定義は、その構造とコンテンツの一例である。本実施形態では、メトリクス・レポーティング・プロビジョニングの全体的な機能のために、必要に応じて追加の要素が追加される。さらに、各要素の詳細なセマンティクスは、より一般的な規約に従って変更してもよいが、技術的効果は保存するべきである。
【0058】
UE位置は、必要とされる可能性があるが、今のところ必要とされない要素の1つである。
【0059】
本実施形態で提供される1つのさらなる機能は、それぞれのメトリック・レポートを収集し、評価する異なるエンティティである場合があるので、周期的レポートおよび集約レポートのために別々のメトリクス・レポーティング・サーバ・アドレスを可能にすることである。この可能性は、当業者には明らかであろうが、表２に示された例示的なメトリクス・レポーティング構成リソースでは、明示的に描かれていない。
【0060】
要素型の正式な定義は、5GMS仕様から既知である。
表２ - メトリクス・レポーティング・構成リソース．
表２ - メトリクス・レポーティング・構成リソース．
【表2】
【0061】
ここで、本開示の実施形態に係るメディア・セッション処理インターフェースについて説明する。
【0062】
現在、非特許文献５に従って、データモデルの11.2.3節では、サービス・アクセス・リソースタイプに"ClientMetricsReportingConfiguration"を指定するオブジェクト要素が含まれている。"ClientMetricsReportingConfiguration"は、必要なメトリクス・レポーティングを定義するUE 14の指示である。本開示の実施形態では、このオブジェクトの内容および構造が改善される。
【0063】
第一に、現在のセマンティクスは、メトリクスの定期的なレポーティングか、セッションの終わりにおけるメトリクスの集約された報告のどちらかを許容するが、両方は許容しない。特定の状況では、サービスプロバイダまたは他の関係者および認可された関係者が両方の種類のレポートを入手することが有益である。これは、両方の種類のレポートが役立つメディア・ストリーミング・サービスに特に関連する。具体的には、定期報告により、ストリーミング・セッション性能のほぼリアルタイムの監視が可能になる。これにより、メトリクスの低下により、サービス・プロバイダは、意図したレベルの性能を復元するための緩和アクションを実行できる。集約されたメトリック報告は、ストリーミングサービス性能の統計量の長期収集に役立つ。従って、任意の個々のストリーミング・セッションに対して、両方の種類のレポート(すなわち、周期的および集約的)のUE 14による提供を可能にすることは有益である。
【0064】
表３に示す変更されたセマンティクスは、要素aggregatedReportを追加することで、ストリーミング・セッションで両方の種類のメトリクス・レポートのプロビジョニングを要求する設定を可能にする。これは"Boolean"タイプの要素で、"True"に設定すると、UE 14に、定期的なメトリクス・レポート用の個別の構成要素とは独立して、セッションの終了時に集約されたメトリクス・レポートを配信するように指示する。言い換えれば、要素aggregatedReport(以下では「第2の要素」と呼ぶ)は、定期的なメトリック・レポートが提供されているかどうかにかかわらず、集約されたレポートを提供するメカニズムを提供する。これにより、メトリック・レポーティング(メディア・ストリーミング・サービスで非常に有用な定期的なレポートと集約されたレポートの両方)をさらに組み合わせることができる。さらに、要素aggregatedReportをブーリアン要素として指定すると、追加される要素のサイズが非常に小さくなる。
【0065】
要素reportingInterval(以下では「第1の要素」と呼ぶ)のセマンティクスを変更して、全体的なセマンティクスの冗長性を回避するには、いくつかの方法がある。例えば、新しい要素aggregatedReportが含まれている場合、レポーティング間隔をゼロ秒に設定して集約レポートの必要性を通知する現在のメソッドは削除される。新しい要素を追加すると、両方の種類のレポートを提供できるというメリットがある。この可能性は、以下の表３で条件式の態様として示される。
【0066】
言い換えると、メディア・ストリーミング・セッションに関連するメトリクスの定期的な報告と集約された報告の両方を可能にするために、メディア・セッション制御インターフェースを使用してメトリクス・レポーティングを定義する命令は、定期的なメトリック報告のための間隔を定義する第1の要素と、第1の要素とは異なり、集約されたメトリック報告が必要かどうかを定義する第2の要素を含む命令である。
【0067】
さらに、ClientMetricsReportingConfigurationオブジェクトには要素"メトリクス（metrics）"が含まれている。これは、報告される個々のメトリクス要素を示す文字列属性の配列である。これは、UE 14内のメディア・セッション・ハンドラ14Cに報告されるべきメトリクスのリストを伝達する有効な方法であるが、ここでは、メトリクス・レポートに使用されるメトリクス・システム・フォーマットを通知するための追加のレベルの方法を開示する。特定のメトリクス・システム・フォーマットが、本開示の実施形態に従ってメトリクス・レポーティング構成で示される場合、示されたメトリクス・システム・フォーマットに応じて、報告される個々のメトリクス要素のリストが含まれても、または、省略されてもよい。いくつかのメトリクス・システム・フォーマットは簡潔であり、そのシステムのためのすべての定義された要素を一般的に含んでいるシステムを使用している報告書である。したがって、この場合、報告すべき個々のメトリクス要素を示す必要はない。他のより広範なメトリクス・システム・フォーマットでは、必要な各メトリクス要素の報告を示すことが望ましいかもしれない。この場合、報告されるメトリクス要素のリストは、メトリクス・システム・フォーマット要素の識別後に示される。
【0068】
本開示の実施形態によるClientMetricsReportingConfigurationオブジェクトの構造は、以下の表３に示すように定義することができる。
【0069】
本実施形態では、構成およびレポートに示された単一のメトリクス・システム・フォーマットがあるが、一部のサービスは、同じメトリクス・レポートに複数のフォーマットを報告する必要がある可能性があるため、これを許可することができる。
【0070】
報告用に単一のメトリクス・システム・フォーマットが予測される場合、表３のメトリクス・オブジェクトのカーディナリティは「1」になる。複数のメトリクス・システム・フォーマットが許可されている場合、表３のメトリクス・オブジェクトのカーディナリティは"1,,,N"になる。
【0071】
表３ - 修正されたClientMetricsReportingConfigurationオブジェクト構造.
【表3】
【0072】
新しい要素の命名は説明全体を通して示されているが、本開示はそれほど限定しない。さらに、metricsSystemIdentifierの構文は、意図された機能を実現するためにいくつかの形式のいずれかを取ることができるが、最初にメトリクス・システム形式を識別してから、そのシステムに従ってメトリクスのリストを追加するというセマンティクスは、適用可能である場合、ClientMetricsReportingConfigurationオブジェクトの新しい構造の基礎となる目的である。
【0073】
metricsSystemIdentifier要素は文字列として定義できる。UE、ネットワーク要素(例えばMCRS-AF)、サービス間の相互運用性を保証するために、この要素の可能なコンテンツを定義しなければならない。
【0074】
metricsSystemIdentifier要素は、相互運用性とバージョニングのようなさらなる利益とを可能にする構造を提供するための、いくつかの要素を持つObject（オブジェクト）であってもよい。
【0075】
そのような可能性のあるmetricsSystemIdentifierオブジェクト構造を以下の表4に示す。この例では、要素の仕様とバージョンが定義されている。この仕様は、メトリクス・システム・フォーマットを指定するエンティティを示す文字列またはURIの位置にすることができる。バージョン番号を使用すると、メトリクス・システム・フォーマットの異なる発行済みバージョンを参照できる。
【0076】
表４ - MetricsSystemIdentifierオブジェクト.
【表4】
【0077】
本実施形態では、メディアAF 11Aは、メトリクス収集およびレポーティング構成フレームワークを、適応なしに、UE 14に直接送信してもよい。しかしながら、他の実施形態では、メディアAF 11Aは、UE14のユーザ、プリセットの観点でUE14自体などによって好まれるか、もしくは、その中に存在するターゲット形式のデータ要素にも従うか、または、ソース・フォーマットから派生できるメディア・コンテンツ・プロバイダによって好まれる、メディア・フォーマットと互換性があるメトリクス収集およびレポーティング構成フレームワークに、メトリクス収集およびレポーティング構成フレームワークを、変換することができる。言い換えれば、MPEG DASHのようないくつかのメディア・フォーマットは、他のメディア・フォーマットに必要とされないパラメータについてのメトリック・レポーティングを必要とする。例えば、MPEG DASHのためのメトリック・レポーティングは、非特許文献６の第10.6.2条項で規定されているが、その一方で、RTPベースのストリーミングを使用するサービスのためのメトリック・レポーティングは、例えば、RTPベースのストリーミングのためのPSS仕様書(TS 26.234)の第5.3.2.3条項で規定されているように、いくつかの異なる要件を持つ。
【0078】
本実施形態では、メディアAF 11Aは、インライン・メカニズムのメディア・マニフェスト内に含まれるメトリクス・レポートを抽出し、このメトリクス・レポートを、メディア・セッション処理インターフェース内のUE 14のメディア・セッション・ハンドラに送信してもよい。
【0079】
本実施形態では、メディアAF 11Aは、メディア・コンテンツ・プロバイダが、どのメトリクス・レポーティング・フォーマットまたは方式がサポートされているかを発見できるように構成してもよい。メディア・ストリーミング・セッションをプロビジョニングする場合、コンテンツ・プロバイダは、メディアAF 11Aがサポート可能な、特定のメトリクス・レポーティング・データ構造およびフォーマットから、好適なメトリック・フォーマットまたは方式を選択し、これにより、メディアAF 11Aを使用することを望むコンテンツ・プロバイダは、メディアAF 11Aによってサポートされるその構造およびフォーマットに基づいて、メトリクス・レポートまたは集約されたメトリクス・レポート・データを受け入れる。メディア・コンテンツ・プロバイダがサポートされていないフォーマットを選択することが想定される。これが拒否された場合、メディアAF 11Aは、より適宜またはサポートされるフォーマットをメディア・コンテンツ・プロバイダに通知する。
【0080】
さらに、本実施形態では、メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポーティングがいつ行われるべきかを定義する。これは、メディア・ストリーミング・セッション中に定期的に行われる場合もあれば、メディア・ストリーミング・セッションの終了時に行われる場合もあれば、これらの両方を組み合わせた場合もある。例えば、メトリクス・レポーティングは、メディア・ストリーミング・セッション中、または、UE14内のバッファイベントなどの発生時に1分ごとに発生してもよい。本実施形態において、メディアAF 11Aは、UE14が定期的メトリクス・レポートまたは集約されたメトリクス・レポートのいずれかまたは両方をメトリック管理レイヤ110Aに直接送信することを可能にするメトリック管理レイヤ110Aの場所(IPアドレスなど)を含むことができる。これについては、図5を参照して説明する。本実施形態では、この場所はメトリック管理レイヤ110Aであってもよいが、本開示はそれに限定されず、MNOの領域外のいかなるエンティティも想定される。このロケーションは、メトリクス収集およびレポーティング構成フレームワークによって、メディアAF 11Aに提供される。
【0081】
メディア・セッション・ハンドラ14Cは、メトリクス収集およびレポーティング構成フレームワークによって定義されると、メトリクス・レポートをメディアAF 11Aに返す。必要に応じて、メディアAF 11 Aは、UE 14から受信したメトリクス・レポートを、メディア・アプリケーション・サービス・プロバイダ110に適したフォーマットに変換し、そのメトリクス・レポートをメトリック管理レイヤ110Aに返すことができる。これは、元のメトリクス・フレームワークが、ターゲット・メトリクス・フォーマットに必要なすべてのメトリクスを何らかの形式で含んでいるか、または、ソース・フォーマットのメトリック・データからそれらを導出することができる限りのことである。
【0082】
本実施形態では、サービス・プロバイダは、メディア・ストリーミング・セッションの最後に、集約されたメトリクス・レポートを提供してもよい。集約されたメトリクス・レポートは、UE 14によって提供される場合もあれば、UE 14によって提供される個々のメトリクス・レポートからメディアAF 11Aによって提供される場合もある。
【0083】
メトリクス収集およびレポーティング構成フレームワークがメディアAF 11Aに提供されている間、メディアASは、コンテンツ・プロビジョニング/サービングレイヤ110BからUE 14にストリームされるコンテンツを受信していることが理解されるであろう。したがって、メディア・コンテンツとメトリクス・レポーティング情報は、UE 14に別途提供されるか、非特許文献１の用語で「帯域外」が提供されている。
【0084】
理解されるように、上記は、メディア・アプリケーション・サービス・プロバイダにメトリクス・レポーティングを返すことを説明する。言い換えれば、上記は、ストリーミング用のメディアコンテンツを提供するサービスプロバイダにメトリクス・レポーティングを返すことを説明する。しかしながら、本実施形態では、例えば、MNOがメトリクス・レポーティング・システムを実装し、メディア配信サービス自体を運用する場合に、ネットワーク事業者(時にはMNOと呼ばれる)にメトリクス・レポーティングを返すことが可能である。
【0085】
フレームワークは、MPEG DASHについて非特許文献６で定義されているような現在のメトリクス・レポーティング・データ・フォーマットであってもよい。代わりに、フレームワークは、メトリクス・レポーティング・データ・フォーマット識別子を含んでもよい。このメトリクス・レポーティング・データ・フォーマット識別子は、メトリクス・レポーティングで使用されるメトリック・データ・フォーマットを識別する。これにより、メディアAF 11Aは、メトリクス・レポーティング・データ・フォーマット識別子が、記憶されたメトリック・データ・フォーマットのいずれがメトリクス・レポーティングにおいて使用されるべきかをメディアAF 11Aに示すルックアップテーブルを記憶することができる。本実施形態では、メトリクス・レポーティング・データ・フォーマット識別子のサイズは、メトリクス・データ・フォーマット識別子文字列またはオブジェクトよりも小さいため、メディア・ストリーミング・プロビジョニング・インターフェースを介して送信されるデータの量が減少する。
【0086】
一例として、メトリクス・レポーティング・データ・フォーマット識別子は、非特許文献６の条項10.6.2で規定されたメトリクス・データに対応する番号1であってもよい。いくつかの例では、メトリクス・レポーティング・データ・フォーマット識別子は、非特許文献６で指定されたメトリクス・データを示すフリー・フォーマットのテキスト文字列であってもよい。この例では、集中型データベースを維持する必要がないかもしれず、各システムは、独自の仕様の中でバリアント、バージョン、およびオプションデータを管理することができる。
【0087】
他の適切なメトリクス・レポーティング・データ形式は、CTA-2066、または、TS 26.234で規定されたRTPベースのストリーミング用のメトリクス、もしくは、他の任意の既知のメトリクス・レポーティング・データ形式を含む。
【0088】
さらに、例えば「gzip」圧縮法を使用して、非特許文献２に含まれているメトリクス定義で許可されているように、メトリクス・データが圧縮されることを要求されてもよい。
【0089】
図6Aは、フローチャート500を使用して、メディア・セッション・ハンドラ14C内のメトリクス・レポーティング・プロトコルを示す。
【0090】
ストリーミング・セッションが開始される前に、UE 14、および本実施形態では、UE 14内のメディア・セッション・ハンドラ14Cは、表３のように、サービス・アクセス情報リソースがClientMetricsReportingConfigurationオブジェクトを含むかどうかを確認する。これは、ステップ504および506で、このような構成オブジェクトが存在する場合、「はい」の経路に従い、UE 14(例えば、メディア・セッション・ハンドラ14C)は、現在のストリーミング・セッションに対するこの構成に基づいてメトリクス・レポーティングを開始する準備を行う。そうでない場合、経路はたどられず、プロセスはステップ520で終了する。
【0091】
その後、処理500はステップ508に進む。UE 14(例えば、UE 14内のメディア・セッション・ハンドラ14C)は、最初に、メトリクス・レポーティング構成で指定されたsamplePercentage属性に従って、メトリクス・レポーティングをそのセッションに対してアクティブにするかどうかを判定する。samplePercentageが存在しないか、その値が100.0の場合、どのような場合でもメトリクス・レポーティングが要求されるため、UE 14によるメトリクス・レポーティングがそのセッションに対してアクティブ化される。ステップ514までは、経路がない。
【0092】
しかしながら、samplePercentage要素が提供され、100.0未満の場合、プロセスはステップ512に移行し、UE 14は0～100の範囲の一様分布内から乱数を生成する。生成された乱数がClientMetricsReportingConfiguration オブジェクトのsamplePercentage値よりも小さい場合、「はい」のパスがステップ514に従い、UE 14はそのセッションのメトリクス・レポーティングをアクティブ化する。ただし、生成された乱数がClientMetricsReportingConfigurationオブジェクトのsamplePercentage値より大きい場合、ステップ520まで経路はなく、UE 14はそのセッションのメトリクス・レポーティングの開始を中止し、セッションのそのメトリクス収集をアクティブにしない。
【0093】
ステップ514において、UE 14は、フィルタ基準が提供されているかどうかをチェックし、これは、メトリクスの選択的レポーティングのためのさらなる基準を与える。現在、5GMSアーキテクチャおよびドラフト仕様では、urlFilters要素を使用すると、このような条件を選択的メトリック・レポーティングに使用できる。ただし、フィルタが適用されるパラメータは明確ではない。本開示の実施形態では、異なる種類のフィルタリングパラメータが収容される。図６Ａは、フィルタがメディア・プレーヤ・エントリURL（mediaPlayerEntry URL）に適用される例を想定している。フィルタリングの別の有効な方法は、sessionId上にある場合があり、これにより、ASPで起動されるセッションのセット全体内のセッションのサンプルに基づいて、メトリック・レポーティングのような機能を規制できるように、ASPはsessionId割り当てを管理する。
後者のタイプのフィルタは本開示に従って許容されるが、図６Ａには明示的には描かれていない。
後者のタイプのフィルタは本開示に従って許容されるが、図６Ａには明示的には描かれていない。
【0094】
一部のフィルタ基準は、プロビジョニング・リソースに対しては有効であるが、UEメトリック・レポーティング構成リソースに対しては有効ではない。
【0095】
また、メディアAF 11Aは、フィルタに作用し、M5d内のメトリック・レポーティング構成インターフェースを介して、UE 14上のメトリック・レポーティングの条件を課すことが予期される。
【0096】
フィルタ基準が提供される場合には、ステップ516において、UEは、現在のストリーミング・セッションのパラメータについてマッチングが存在するか否かを確認する。
【0097】
ステップ514においてこのセッションに対するメトリック・レポーティングがアクティブである場合、UE 14は、例えば、メディア・セッション・ハンドラ14Cを使用して、M7d UE内部インターフェースを介して、メディア・プレーヤ14Dから必要なメトリック・レポーティングパラメータ値を定期的に要求し、ClientMetricsReportingConfigurationオブジェクトで指定されたreportingInterval要素値に従って、これらの値をメディアAF 11 Aに定期的に報告するかを判定する。
【0098】
メディアAF 11Aは、例えばURL(文字列)のようなネットワークアドレスによって識別される。1つのメディアAFアドレスは、ClientMetricsReportingConfigurationオブジェクト内の要素のserverAddresses（サーバアドレス）配列の1つのインスタンスに対応する。要求されたフォーマットで、かつ、要求されたメトリックコンテンツを含むメトリック・レポートは、ClientMetricsReportingConfigurationオブジェクト内の要素serverAddressesによって示されるように、1つのメディアAF 11Aまたは複数のメディアAFのいずれかに、UE 14によってメディアAF 11Aに送信される。
【0099】
図６Ａのフロー図は、上の表３に示されている ClientMetricsReportingConfiguration オブジェクトの定義に対して有効であることに注意する。明らかに、オブジェクト構造が引用された要素のいずれかを省略する場合、そのシーケンスは異なるが、残りのステップの一般的な原則は依然として適用される。同様に、このホールドされた追加要素は構造体内に存在し、UE 14がメトリクス・レポートを提供するための要件の検証シーケンスで追加される。
【0100】
図6Bは、UE 14とメディアAF 11Aとメトリック管理機能110Aとの間のメトリクス・レポーティング構成およびメトリクス・レポーティング・プロトコルのシーケンス図を示す。
【0101】
メトリクス・レポートは、周期的であるか集約されたレポートであるかにかかわらず、本実施形態では、HTTP POSTメッセージのペイロードとしてメディアAF 11Aおよび/またはメトリック管理機能110Aに送られる。本開示のメディアネットワークでは、メトリック・レポーティング・プロトコルが、UE 14とメディアAF 11Aとの間の通信に基づいて設計されるのに十分に単純であり、かつ/または、メトリック管理機能110Aが、いずれかの方向で、すなわち、集約されたサービス・アクセス情報の提供とは別に行われる場合に、メトリクス・レポーティング構成のためと、メトリクス・レポートのためとのいずれかの方向で、HTTP POSTメッセージを介して実現される場合、多くの場合にRESTfulプロトコルが使用される。
【0102】
メトリック・レポーティング構成とメトリック・レポーティングAPIのためのフレームワークは、本実施形態では、以下のように定義される。
【0103】
UE 14、例えばUE 14内のメディア・セッション・ハンドラ14Cのようなメトリック・レポーティング・データリソースは、メトリック・レポーティングがメディア・ストリーミング・セッションに対してアクティブになっている場合に、メトリクス・レポート・データを送信できるように定義されている。
【0104】
このリソースは、リソースURIで次のように定義される。
{apiRoot}/3gpp-5gms-metrics-reporting/vl/{aspId}/session/{sessionId}.
{apiRoot}/3gpp-5gms-metrics-reporting/vl/{aspId}/session/{sessionId}.
【0105】
このリソースは、下の表５で定義されるリソースURI変数をサポートする。
【0106】
表５ - リソース「MetricsReportingData」のリソースURI変数.
【表5】
【0107】
POSTメソッドにより、UE 14は、例えばメディア・セッション・ハンドラ14Cから、メトリクス・データを送信することができる。UE 14によって開始され、メディアAF 11Aおよび/またはメトリック管理機能110Aによって適宜確認される。
【0108】
この方法は、リクエストおよびレスポンスのデータ構造、ならびにレスポンスコードをサポートする(下の表６を参照)。
【0109】
表６ - リソースによってPOST要求/応答でサポートされるデータ構造.
【表6】
【0110】
図７は、2つのコンテンツ・プロバイダを持つ図4のシステムを示している。図７から明らかなように、UE 14は2つの異なるコンテンツ・プロバイダ(メディア・サービス1およびメディア・サービス2)からの2つの異なるフォーマットでコンテンツを受信することが可能である。メディア・サービス1 の例では、メディア・アセット1の形式でストリーミング・コンテンツを提供し、メディア・アセット1の対応するメトリック・レポーティング構成をメトリクス形式Aとして提供する。
【0111】
具体的には、メディア・サービス1は、メトリック・レポーティング構成をメディアAF 11Aに提供する。これは、メトリック・レポーティング・データ形式識別子である場合もあれば、メトリック・レポーティング・データ形式である場合もある、メトリクス収集およびレポーティング構成フレームワークとして提供されるメディア・サービス1は、メディアAS 11Bにメディア・アセット(メディア・アセット1)を提供する。明確さのために特に示されていないが、メディアAF 11Aは、メディア・アセット1のためのメトリクス構成をメディア・セッション・ハンドラ14Cに送り、メディア・セッション・ハンドラ14Cからのメトリクス報告を定期的にまたは集約して受信する。次に、メディア・サービス1は、メトリクス収集およびレポーティング構成フレームワークによって要求されるように、メディアAF 11Aからメトリクスを受信する。
【0112】
メディア・サービス2に関しては、メディア・アセット2の形式でストリーミング・コンテンツを提供し、メディア・アセット2の対応するメトリック・レポーティング構成をメトリクス形式Bとして提供する。具体的には、メディア・サービス2は、メディアAF 11Aにメトリック・レポーティング構成を提供する。これは、メトリック・レポーティング・データ形式識別子である場合もあれば、メトリック・レポーティング・データ形式である場合もある、メトリクス収集およびレポーティング構成フレームワークとして提供される。メディア・サービス2は、メディア・アセット(メディア・アセット2)をメディアAS 11Bに提供する。上述したメカニズムと同様に、メディアAF 11Aは、メディア・アセット2のメトリクス構成をメディア・セッション・ハンドラ14Cに送信し、メディア・セッション・ハンドラ14Cからメトリクス・レポートを定期的に受信する。しかしながら、この例では、メディア・セッション・ハンドラ14Cはまた、メトリクス・レポートを、メディア・サービス2のメトリック管理レイヤ2110Aに周期的に送る。この実施形態では、集約されたメトリクス・レポートは、次に、メディアAF 11Aによって作成され、メトリクス管理レイヤ2110Aに送られる。換言すれば、本実施形態のメディア・サービス2では、個々のメトリクス・レポートはUE 14によってメトリクス管理レイヤ2110Aに送られ、集約されたメトリクス・レポートはメディアAF 11Aを介して送信される。
【0113】
図8Aおよび8Bは、インフラストラクチャ11における2つのプロセスのフローチャートを示す。
【0114】
図8Aを参照すると、処理700は、ステップ705から開始する。処理回路11-2が、メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能にメトリクス収集およびレポーティング構成フレームワークを提供し、ここで、メトリクス収集およびレポーティング構成フレームワークは、メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告されるメトリクスを定義するようにトランシーバ回路11-1を制御するように構成されるステップ710に、この処理は移行する。
【0115】
次いで、処理700はステップ715に移動し、そこで処理は終了する。
【0116】
他の実施形態では、第2の処理720が提供される。これを図8Bに示す。この第2のプロセスでは、プロセスはステップ725から開始する。処理回路11-2が、メディア・セッション制御インターフェースを使用してメトリクス・レポーティングを定義する命令を送信し、ここで、この命令は、周期的なメトリクス・レポーティング用の間隔を定義する第1の要素と、第1の要素とは異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含むようにトランシーバ回路11-1を制御するように構成されるステップ730に、この処理は移行する。
【0117】
次いで、処理720はステップ735に移動し、そこで処理は終了する。
【0118】
図9は、UE 14における処理のフローチャートを示す。
【0119】
図9を参照すると、処理800は、ステップ805から開始する。
処理回路14-2が、
メディア・セッション制御インターフェースを使用してメトリクス・レポーティングを定義する命令を受信し、ここで、この命令は、周期的なメトリクス・レポーティングの間隔を定義する第1の要素と、第1の要素とは異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含むようにトランシーバ回路14-1を制御するように構成されるステップ810に、この処理は進む。
処理回路14-2が、
メディア・セッション制御インターフェースを使用してメトリクス・レポーティングを定義する命令を受信し、ここで、この命令は、周期的なメトリクス・レポーティングの間隔を定義する第1の要素と、第1の要素とは異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含むようにトランシーバ回路14-1を制御するように構成されるステップ810に、この処理は進む。
【0120】
次いで、処理800はステップ815に移動し、そこで処理は終了する。
【0121】
当業者は、同図に示す方法は、本技術の実施形態に従って適用することができることを理解するであろう。例えば、本明細書に記載する他の予備ステップ、中間ステップ、または後続ステップを本方法に含めることができ、または、ステップを任意の論理的順序で実行することができる。
【0122】
本技術の実施形態は、同図に示されている通信システムの例によって大きく説明されてきたが、本明細書に記載されているものに他のシステムにも等しく適用できることは、当業者には明らかであろう。さらに、本明細書に記載する様々な構成が個別に記載される範囲で、これらは、本明細書に記載する任意の他の構成と組み合わせることができ、この2つは互いに矛盾しない。
【0123】
当業者は、本明細書で定義されるインフラストラクチャ機器および/または通信デバイスが、前の段落で議論された様々な構成および実施形態に従ってさらに定義されてもよいことをさらに理解する。本明細書に定義され、説明されるインフラストラクチャ機器および通信デバイスは、本明細書によって定義されるもの以外の通信システムの一部を構成してもよいことが、当業者にさらに理解される。
【0124】
以下の番号付けされた段落は、本技術のさらなる例示的な態様および特徴を提供する。
1. サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングの方法であって、前記方法は、
メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するステップ
を含み、
前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義する
方法。
2. 前記メトリクス収集およびレポーティング構成フレームワークを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるメトリクス・レポーティング・データ・フォーマットに変換するステップを含む
1に記載の方法。
3. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である
1または2に記載の方法。
4. 前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい
3に記載の方法。
5. 前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである
3または4に記載の方法。
6. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む
1～5のいずれか1つに記載の方法。
7. 前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある
6に記載の方法。
8. アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するステップを含む
1～7のいずれか1つに記載の方法。
9. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するようにユーザ装置に指示する方法であって、前記方法は、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する命令を送信するステップ
を含み、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
方法。
10. 前記第2の要素はブーリアン要素型である
9に記載の方法。
11. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
9または10に記載の方法。
方法。
12. 前記命令は、
の形式であり、
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
9～11のいずれか1つに記載の方法。
13. metricsSystemIdentifier要素は、
の形式である
12に記載の方法。
14. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するようにユーザ装置における命令を受信する方法であって、前記方法は、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する前記命令を受信するステップ
を含み、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
方法。
15. 前記第2の要素はブーリアン要素型である
14に記載の方法。
16. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
14または15に記載の方法。
17. 前記命令は、
の形式であり、
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
14～16のいずれか1つに記載の方法。
18. metricsSystemIdentifier要素は、
の形式である
17に記載の方法。
19. コンピュータにロードされると、1～18のいずれか1つに記載の方法を実行するように前記コンピュータを設定するコンピュータプログラム製品。
20. サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングのためのインフラストラクチャ機器であって、
メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するように構成された回路
を具備し、
前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義する
インフラストラクチャ機器。
21. 前記回路は、前記メトリクス収集およびレポーティング構成フレームワークを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるメトリクス・レポーティング・データ・フォーマットに変換するように構成されている
20に記載のインフラストラクチャ機器。
22. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である
20または21に記載のインフラストラクチャ機器。
23. 前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい
22に記載のインフラストラクチャ機器。
24. 前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである
22または23に記載のインフラストラクチャ機器。
25. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む
20～24のいずれか1つに記載のインフラストラクチャ機器。
26. 前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある
25に記載のインフラストラクチャ機器。
27. アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するステップを含む
20～26のいずれか1つに記載のインフラストラクチャ機器。
28. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するためのインフラストラクチャ機器であって、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する命令を送信するように構成された回路
を具備し、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
インフラストラクチャ機器。
29. 前記第2の要素はブーリアン要素型である
28に記載のインフラストラクチャ機器。
30. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
28または29に記載のインフラストラクチャ機器。
31. 前記命令は、
の形式であり、
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
28～30のいずれか1つに記載のインフラストラクチャ機器。
32. metricsSystemIdentifier要素は、
の形式である
31に記載のインフラストラクチャ機器。
33. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するように命令を受信する端末デバイスであって、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する前記命令を受信する回路
を具備し、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
端末デバイス。
34. 前記第2の要素はブーリアン要素型である
33に記載の端末デバイス。
35. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
33または34に記載の端末デバイス。
36. 前記命令は、
の形式であり、
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
33～35のいずれか1つに記載の端末デバイス。
37. metricsSystemIdentifier要素は、
の形式である
36に記載の端末デバイス。
1. サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングの方法であって、前記方法は、
メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するステップ
を含み、
前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義する
方法。
2. 前記メトリクス収集およびレポーティング構成フレームワークを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるメトリクス・レポーティング・データ・フォーマットに変換するステップを含む
1に記載の方法。
3. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である
1または2に記載の方法。
4. 前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい
3に記載の方法。
5. 前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである
3または4に記載の方法。
6. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む
1～5のいずれか1つに記載の方法。
7. 前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある
6に記載の方法。
8. アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するステップを含む
1～7のいずれか1つに記載の方法。
9. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するようにユーザ装置に指示する方法であって、前記方法は、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する命令を送信するステップ
を含み、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
方法。
10. 前記第2の要素はブーリアン要素型である
9に記載の方法。
11. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
9または10に記載の方法。
方法。
12. 前記命令は、
【表7】
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
9～11のいずれか1つに記載の方法。
13. metricsSystemIdentifier要素は、
【表8】
12に記載の方法。
14. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するようにユーザ装置における命令を受信する方法であって、前記方法は、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する前記命令を受信するステップ
を含み、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
方法。
15. 前記第2の要素はブーリアン要素型である
14に記載の方法。
16. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
14または15に記載の方法。
17. 前記命令は、
【表9】
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
14～16のいずれか1つに記載の方法。
18. metricsSystemIdentifier要素は、
【表10】
17に記載の方法。
19. コンピュータにロードされると、1～18のいずれか1つに記載の方法を実行するように前記コンピュータを設定するコンピュータプログラム製品。
20. サービスベースのアーキテクチャ・メディア・ストリーミング・ネットワークにおけるメトリクス収集およびレポーティングのためのインフラストラクチャ機器であって、
メディア・ストリーミング・プロビジョニング・インターフェースを使用してアプリケーション機能に、メトリクス収集およびレポーティング構成フレームワークを提供するように構成された回路
を具備し、
前記メトリクス収集およびレポーティング構成フレームワークは、前記メディア・ストリーミング・ネットワークを介してメディア・セッションに対して収集かつ報告される前記メトリクスを定義する
インフラストラクチャ機器。
21. 前記回路は、前記メトリクス収集およびレポーティング構成フレームワークを、メディア・フォーマットと互換性があり、かつ、前記メトリクス収集およびレポーティング構成フレームワークとは異なるメトリクス・レポーティング・データ・フォーマットに変換するように構成されている
20に記載のインフラストラクチャ機器。
22. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス収集およびレポーティングで使用されるメトリクス・データ・フォーマットを識別するメトリクス・レポーティング・データ・フォーマット識別子である
20または21に記載のインフラストラクチャ機器。
23. 前記メトリクス・レポーティング・データ・フォーマット識別子は、識別するメトリクス・データ・フォーマットよりもサイズが小さい
22に記載のインフラストラクチャ機器。
24. 前記メトリクス・レポーティング・データ・フォーマットは、数字またはフリー・フォーマットのテキスト文字列または構造化されたデータ・オブジェクトのいずれかである
22または23に記載のインフラストラクチャ機器。
25. 前記メトリクス収集およびレポーティング構成フレームワークは、メトリクス・レポートが提供されるべき位置を示すことを含む
20～24のいずれか1つに記載のインフラストラクチャ機器。
26. 前記位置は、前記メディア・ストリーミング・ネットワークを動作させるモバイルネットワーク事業者のネットワークドメインの外部にある
25に記載のインフラストラクチャ機器。
27. アプリケーション機能からユーザ端末へ、メトリクスを収集し報告するために使用されるメトリクス・システム・フォーマットを含むメトリクス・レポーティング・オブジェクトを送信するステップを含む
20～26のいずれか1つに記載のインフラストラクチャ機器。
28. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するためのインフラストラクチャ機器であって、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する命令を送信するように構成された回路
を具備し、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
インフラストラクチャ機器。
29. 前記第2の要素はブーリアン要素型である
28に記載のインフラストラクチャ機器。
30. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
28または29に記載のインフラストラクチャ機器。
31. 前記命令は、
【表11】
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
28～30のいずれか1つに記載のインフラストラクチャ機器。
32. metricsSystemIdentifier要素は、
【表12】
31に記載のインフラストラクチャ機器。
33. メディア・ストリーミング・セッションに関連付けられたメトリクス・レポーティングを提供するように命令を受信する端末デバイスであって、
メディア・セッション制御インターフェースを使用して、前記メトリクス・レポーティングを定義する前記命令を受信する回路
を具備し、
前記命令は、定期的なメトリクス・レポーティングのための間隔を定義する第1の要素と、前記第1の要素と異なり、集約されたメトリクス・レポーティングが必要かどうかを定義する第2の要素とを含む
端末デバイス。
34. 前記第2の要素はブーリアン要素型である
33に記載の端末デバイス。
35. 前記命令は、選択的なメトリクス・レポーティングを可能にするフィルタを含む
33または34に記載の端末デバイス。
36. 前記命令は、
【表13】
前記第1の要素はreportinglnterval要素であり、前記第2の要素はaggregatedReport要素である
33～35のいずれか1つに記載の端末デバイス。
37. metricsSystemIdentifier要素は、
【表14】
36に記載の端末デバイス。
【0125】
本明細書で説明された実施形態は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の適切な形態で実装される。本明細書で記載された実施形態は、任意選択で、1つ以上のデータプロセッサおよび/またはデジタル信号プロセッサ上で実行されるコンピュータソフトウェアとして少なくとも部分的に実装され得る。任意の実施形態における部品および構成要件が、任意の適切な方法で物理的に、機能的に、及び、論理的に実装される。実際、機能は、単一のユニットで、複数のユニットで、または他の機能ユニットの一部として実装され得る。したがって、本開示の実施形態は、単一のユニットで実装されてもよく、または異なるユニット、回路、および/またはプロセッサの間で物理的及び機能的に分散されてもよい。
【0126】
本開示は、いくつかの実施形態に関連して説明されたが、本明細書に記載された特定の形態に限定されることは意図されていない。さらに、本開示の特徴は、特定の実施形態に関連して説明されているように見えるが、当業者は、説明された実施形態の種々の特徴が、本技法を実施するのに適した任意の方法で組み合わされ得ることを認識する。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6A】
【図6B】
【図7】
【図8】
【図9】