本出願は、メディアストリーム切り替え遅延が低減されるように、端末デバイスによって送信された切り替え要求内のライブメディアストリームの特性情報に基づいて、特性情報に対応するライブメディアストリームを決定し、ライブメディアストリームを端末デバイスに適時に配信するためのメディアストリーム切り替え方法および装置を提供する。
第1の態様によれば、本出願の一実施形態は、通信方法を提供する。方法は、アクセスネットワークデバイスに適用可能であり、以下を含む。
アクセスネットワークデバイスは、切り替え要求に含まれる第1のライブメディアストリームの特性情報を端末デバイスから受信する。アクセスネットワークデバイスは、特性情報に基づいて、第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定する。したがって、アクセスネットワークデバイスは、端末デバイスに送信されたメディアストリームを切り替え、具体的には、端末デバイスに送信されたライブメディアストリームを第2のライブメディアストリームから第1のライブメディアに切り替え、第2のライブメディアストリームおよび第1のライブメディアストリームの両方がアクセスネットワークデバイスに対応する。
本出願のこの実施形態では、同じアクセスネットワークデバイスによってサービス提供される複数のユーザが同じライブメディアストリームにアクセスする場合、この方法の実施形態におけるアクセスネットワークデバイスは、メディアストリームを適時に切り替えるのを助け、メディアストリーム切り替え遅延を低減するために、切り替えを実行する資格がある。
可能な設計では、方式1:アクセスネットワークデバイスは、第1のライブメディアストリームに対応する第1のアドレス情報を決定する。次いで、アクセスネットワークデバイスは、第1のアドレス情報を端末デバイスに送信し、第1のアドレス情報は、第2のライブメディアストリームに対応する第2のアドレス情報にバインドするために使用される。方式2:アクセスネットワークデバイスは、第1のライブメディアストリームに対応する第1のアドレス情報および第2のライブメディアストリームに対応する第2のアドレス情報を決定する。アクセスネットワークデバイスは、第1のライブメディアストリームを搬送するデータパケット内の第1のアドレス情報を第2のアドレス情報と置き換える。アドレス情報は、IPおよびポート情報のうちの少なくとも1つを指し得ることに留意されたい。
本出願のこの実施形態において、アクセスネットワークデバイスは、端末デバイスによって要求された特性情報に対応するIP/ポート情報を端末デバイス側に送信して、端末デバイス側がIP/ポート情報を元のIP/ポート情報にバインドし、対応するデータを受信した後に対応するデータを解析して適用できることを保証する。
可能な設計では、アクセスネットワークデバイスは、セッション管理機能ネットワーク要素またはユーザプレーン機能ネットワーク要素からメッセージを受信し、メッセージは、第1のライブメディアストリームに対応する第1のアドレス情報を含む。アクセスネットワークデバイスは、メッセージに基づいて、第1のライブメディアストリームに対応する第1のアドレス情報および第2のアドレス情報を決定する。
本出願のこの実施形態では、セッション管理機能ネットワーク要素は、対応するアドレス情報をアクセスネットワークデバイスに送信するか、またはユーザプレーン管理機能ネットワーク要素は、アドレス情報をアクセスネットワークデバイスに直接送信する。
可能な設計では、アクセスネットワークデバイスが第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定する方式は、以下の通りであり得る。アクセスネットワークデバイスは、第1のライブメディアストリームの特性情報に基づいて、アクセスネットワークデバイスによってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を含む第2のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと決定する。アクセスネットワークデバイスは、監視されたライブメディアストリームにおいて、第1のライブメディアストリームの特性情報を搬送する第1のライブメディアストリームを決定する。
本出願のこの実施形態において、アクセスネットワークデバイスは、現在のアクセスネットワークデバイスのサービス範囲内の端末デバイスによってアクセスされているメディアストリームを決定するために、アクセスネットワークデバイスによってサービス提供されるメディアストリームを監視することができる。したがって、対応する第1のライブメディアストリームは、特性情報に基づいて決定され得る。
可能な設計では、アクセスネットワークデバイスは、第1のライブメディアストリームの特性情報に基づいて、第2のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。したがって、アクセスネットワークデバイスは、応答情報を端末デバイスに送信し、応答メッセージは、ライブメディアストリーム切り替えが失敗したことを端末デバイスに通知するためのものである。このようにして、応答メッセージを受信した後、端末デバイスは、切り替え要求をアプリケーションサーバに再送信する。可能な設計では、アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、アクセスネットワークデバイスは、応答メッセージを端末デバイスに適時に送信して、切り替え障害によって引き起こされる端末デバイス上の長時間のフリーズを回避することができる。
可能な設計では、アクセスネットワークデバイスは、第1のライブメディアストリームの特性情報に基づいて、第2のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。したがって、アクセスネットワークデバイスは、ユーザプレーン機能ネットワーク要素を介して第1のライブメディアストリームの特性情報をアプリケーションサーバに送信し、すなわち、アプリケーションサーバに第1のライブメディアストリームを要求する。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、アクセスネットワークデバイスは、第1のライブメディアストリームをアプリケーションサーバに適時に要求して、切り替え障害によって引き起こされる端末デバイス上の長時間のフリーズを回避することができる。
可能な設計では、第2のアクティブ特性情報は、以下の方式で生成され得る。アクセスネットワークデバイスは、端末デバイスのライブセッションの確立要求メッセージをセッション管理機能ネットワーク要素に送信する。アクセスネットワークデバイスは、セッション管理機能ネットワーク要素から、ライブセッションの確立完了メッセージおよび第2の指示情報を受信する。アクセスネットワークデバイスは、第2の指示情報に基づいて、アクセスネットワークデバイスによってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームを監視し、第2のアクティブ特性情報セットを作成する。
可能な設計では、アクセスネットワークデバイスは、第2のアクティブ特性情報セットを端末デバイスにさらに送信することができる。したがって、端末デバイスは、切り替え要求を送信する前に、切り替えられるように要求された第1のライブメディアストリームの特性情報が第2のアクティブ特性情報セット内に存在するかどうかを最初に決定することができる。第1のライブメディアストリームの特性情報が第2のアクティブ特性情報セット内に存在する場合、端末デバイスは、切り替え要求をアクセスネットワークデバイスに送信する。第1のライブメディアストリームの特性情報が第2のアクティブ特性情報セットに存在しない場合、端末デバイスは、切り替え要求をアプリケーションサーバに送信する。
本出願のこの実施形態において、アクセスネットワークデバイスは、GTP層指示に基づいて第2のアクティブ特性情報セットを生成し、RRCメッセージまたはPDCP層拡張識別子を介して第2のアクティブ特性情報セットを端末デバイスに送信することができる。端末デバイス側がメディアストリーム切り替えを実行するとき、アクセスネットワークデバイス側は、特性情報に対応するメディアストリームを端末デバイスに対応するDRBに直接複製/転送して、メディアストリーム切り替えを完了する。
可能な設計では、第1のライブメディアストリームの特性情報は、第1のライブメディアストリームのメディアストリームパラメータ値、または第1のライブメディアストリームに一意に対応するインデックス値であり、メディアストリームパラメータ値は、ビットレート、解像度、フレームレート、または視野のうちの少なくとも1つのタイプのパラメータの値を含む。
第2の態様によれば、本出願の一実施形態は、メディアストリーム切り替え方法を提供する。方法は、端末デバイスに適用可能である。端末デバイスは、第1のライブメディアストリームの特性情報をアクセスネットワークデバイスに送信する。端末デバイスは、アクセスネットワークデバイスから受信されたライブメディアストリームを第2のライブメディアストリームから第1のライブメディアストリームに切り替え、第1のライブメディアストリームは第1のライブメディアストリームの特性情報に対応し、第2のライブメディアストリームと第1のライブメディアストリームの両方はアクセスネットワークデバイスに対応する。
本出願のこの実施形態では、同じアクセスネットワークデバイスまたは同じユーザプレーン機能ネットワーク要素によってサービス提供される複数のユーザが同じライブメディアストリームにアクセスする場合、この方法実施形態のアクセスネットワークデバイスまたはユーザプレーン機能ネットワーク要素は、メディアストリームを適時に切り替えるのを助け、メディアストリーム切り替え遅延を低減するために、切り替えを実行する資格がある。
可能な設計では、端末デバイスが第1のライブメディアストリームの特性情報をアクセスネットワークデバイスに送信する前に、方法は、端末デバイスが、ライブセッションの確立要求メッセージを、アクセスネットワークデバイスを介してセッション管理機能ネットワーク要素に送信することをさらに含む。端末デバイスは、セッション管理機能ネットワーク要素からアクセスネットワークデバイスを介して、確立要求完了メッセージと、ライブサービスのための初期特性情報セットとを受信し、初期特性情報セットは、種々のメディアストリームパラメータに対応するライブメディアストリームの特性情報を含む。端末デバイスは、初期特性情報セットにおいて、現在のメディアストリームパラメータ情報に対応する第1のライブメディアストリームの特性情報を決定する。
本出願のこの実施形態では、PDUセッションを確立するプロセスにおいて、メディアストリーム切り替えを保証するために、ライブメディアストリームの特性情報の配信が完了される。
可能な設計では、端末デバイスが第1のライブメディアストリームの特性情報をアクセスネットワークデバイスに送信する前に、方法は、端末デバイスが第2のアクティブ特性情報セットをアクセスネットワークデバイスから受信することをさらに含む。端末デバイスは、第2のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと決定する。第2のアクティブ特性情報セットは、アクセスネットワークデバイスによってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を含む。
本出願のこの実施形態において、端末デバイスは、第2のアクティブ特性情報セットを閲覧する。要求されたメディアストリームに対応する特性情報が第2のアクティブ特性情報セット内にない場合、端末デバイスは、既存のアプリケーション層対話プロセスを介して、特性情報に対応するライブメディアストリームを要求する。要求されたメディアストリームに対応する特性情報が第2のアクティブ特性情報セット内にある場合、端末デバイスは、特性情報に対応するライブメディアストリーム要求をアクセスネットワークデバイスに直接送信する。
可能な設計では、端末デバイスは、ユーザプレーン機能ネットワーク要素から第1のアクティブ特性情報セットをさらに受信する。第1のアクティブ特性情報セットは、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報セットを含む。第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと端末デバイスが決定したとき、端末デバイスは、アクセスネットワークデバイスを介してユーザプレーン機能ネットワーク要素に切り替え要求を送信する。第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと端末デバイスが決定したとき、端末デバイスは、切り替え要求をアプリケーションサーバに送信する。可能な設計では、アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。
本出願のこの実施形態において、端末デバイスは、第1のアクティブ特性情報セットを閲覧する。要求されたメディアストリームに対応する特性情報が第2のアクティブ特性情報セット内にない場合、端末デバイスは、既存のアプリケーション層対話プロセスを介して、特性情報に対応するライブメディアストリームを要求する。要求されたメディアストリームに対応する特性情報が第1のアクティブ特性情報セット内にある場合、端末デバイスは、特性情報に対応するライブメディアストリーム要求をユーザプレーン機能ネットワーク要素に直接送信する。
可能な設計では、端末デバイスは、第1のライブメディアストリームに対応する第1のアドレス情報をさらに受信する。端末デバイスは、第1のライブメディアストリームに対応する第1のアドレス情報を第2のライブメディアストリームに対応する第2のアドレス情報にバインドし、バインディング関係に基づいて第1のライブメディアストリームを解析する。
本出願のこの実施形態において、アクセスネットワークデバイスは、端末デバイスによって要求された特性情報に対応するIP/ポート情報を端末デバイス側に送信して、端末デバイス側がIP/ポート情報を元のIP/ポート情報にバインドし、対応するデータを受信した後に対応するデータを解析して適用できることを保証する。
第3の態様によれば、本出願の一実施形態は、メディアストリーム切り替え方法をさらに提供する。方法は、ユーザプレーン機能ネットワーク要素に適用可能である。本方法には、以下が含まれる。
ユーザプレーン機能ネットワーク要素は、端末デバイスから第1のライブメディアストリームの特性情報を受信する。ユーザプレーン機能ネットワーク要素は、第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定する。ユーザプレーン機能ネットワーク要素は、端末デバイスに送信されたライブメディアストリームを第2のライブメディアストリームから第1のライブメディアストリームに切り替え、第2のライブメディアストリームおよび第1のライブメディアストリームの両方がユーザプレーン機能ネットワーク要素に対応する。
本出願のこの実施形態では、同じユーザプレーン機能ネットワーク要素によってサービス提供される複数のユーザが同じライブメディアストリームにアクセスする場合、この方法実施形態のユーザプレーン機能ネットワーク要素は、メディアストリームを適時に切り替えるのを助け、メディアストリーム切り替え遅延を低減するために、切り替えを実行する資格がある。
可能な設計では、ユーザプレーン機能ネットワーク要素が、端末デバイスに送信されるライブメディアストリームを第2のライブメディアストリームから第1のライブメディアストリームに切り替える前に、ユーザプレーン機能ネットワーク要素は、第1のライブメディアストリームに対応する第1のアドレス情報および第2のライブメディアストリームに対応する第2のアドレス情報を決定する。ユーザプレーン機能ネットワーク要素は、第1のライブメディアストリームを搬送するデータパケット内の第1のアドレス情報を第2のアドレス情報と置き換える。
本出願のこの実施形態では、端末デバイス側が、元のIP/ポート情報を使用することによって対応するデータを解析し適用することができることが保証される。
可能な設計では、ユーザプレーン機能ネットワーク要素は、第1のライブメディアストリームに対応する第1のアドレス情報を決定する。ユーザプレーン機能ネットワーク要素は、第1のアドレス情報を端末デバイスに送信し、第1のアドレス情報は、第2のライブメディアストリームに対応する第2のアドレス情報にバインドするために使用される。
本出願のこの実施形態において、ユーザプレーン機能ネットワーク要素は、端末デバイスによって要求された特性情報に対応するIP/ポート情報を端末デバイス側に送信して、端末デバイス側がIP/ポート情報を元のIP/ポート情報にバインドし、対応するデータを受信した後に対応するデータを解析して適用できることを保証する。
可能な設計では、ユーザプレーン機能ネットワーク要素が第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定することは、ユーザプレーン機能ネットワーク要素が、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと決定することを含む。ユーザプレーン機能ネットワーク要素は、現在監視されているライブメディアストリームにおいて、第1のライブメディアストリームの特性情報を搬送する第1のライブメディアストリームを決定する。第1のアクティブ特性情報セットは、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を含む。
本出願のこの実施形態では、ユーザプレーン機能ネットワーク要素は、現在のユーザプレーン機能ネットワーク要素のサービス範囲内の端末デバイスによってアクセスされているメディアストリームを決定するために、ユーザプレーン機能ネットワーク要素によってサービス提供されるメディアストリームを監視することができる。したがって、対応する第1のライブメディアストリームは、特性情報に基づいて決定され得る。
可能な設計では、ユーザプレーン機能ネットワーク要素は、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。この場合、ユーザプレーン機能ネットワーク要素は、要求メッセージをアプリケーションサーバに送信し、要求メッセージは、第1のライブメディアストリームの特性情報を含み、要求メッセージは、端末デバイスに送信されるライブメディアストリームを第1のライブメディアストリームに切り替えることを要求するためのものである。可能な設計では、アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、ユーザプレーン機能ネットワーク要素は、対応するメディア要求情報をアプリケーションサーバに適時に送信して、アプリケーションサーバが端末デバイスによって要求されたメディア切り替えに応答することを保証する。
可能な設計では、ユーザプレーン機能ネットワーク要素は、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。ユーザプレーン機能ネットワーク要素は、アクセスネットワークデバイスを介して応答メッセージを端末デバイスに送信し、応答メッセージは、ライブメディアストリーム切り替えが失敗したことを端末デバイスに通知するためのものである。このようにして、応答メッセージを受信した後、端末デバイスは、切り替え要求をアプリケーションサーバに再送信する。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、ユーザプレーン機能ネットワーク要素は、応答メッセージを端末デバイスに適時に送信して、切り替え障害によって引き起こされる端末デバイス上の長時間のフリーズを回避することができる。
可能な設計では、ユーザプレーン機能ネットワーク要素が端末デバイスから第1のライブメディアストリームの特性情報を受信する前に、方法は、ユーザプレーン機能ネットワーク要素が、セッション管理機能ネットワーク要素からライブセッションの確立完了メッセージおよび第1の指示情報を受信することをさらに含む。ユーザプレーン機能ネットワーク要素は、第1の指示情報に基づいて、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を監視し、第1のアクティブ特性情報セットを作成する。
本出願のこの実施形態では、PDUセッションが確立された後、ユーザプレーン機能ネットワーク要素は、ライブメディアストリームの特性情報を監視し、第1のアクティブ特性情報セットを作成して、後続のメディアストリーム切り替えを保証する。
可能な設計では、端末デバイスがライブストリーミングサービスにアクセスしていることを検出した後、ユーザプレーン機能ネットワーク要素は、セッション管理ネットワーク要素がユーザプレーン機能ネットワーク要素および端末デバイスの識別情報をアプリケーションサーバに通知するように、指示情報をセッション管理ネットワーク要素に送信し、アプリケーションサーバは、第1のアクティブ特性情報セットを取得し、第1のアクティブ特性情報セットを端末デバイスに送信する。代替として、別の可能な設計では、ユーザプレーン機能ネットワーク要素は、第1のアクティブ特性情報セットを端末デバイスに送信する。
本出願のこの実施形態では、前述の方式で、ユーザプレーン機能ネットワーク要素は、アプリケーションサーバが第1のアクティブ特性情報セットを取得することを可能にすることができ、その結果、アプリケーションサーバは、第1のアクティブ特性情報セットを端末デバイスに送信する。このようにして、端末デバイスは、第1のアクティブ特性情報セットを閲覧することによって、メディアストリーム切り替え方式を決定することができる。
可能な設計では、ユーザプレーン機能ネットワーク要素が、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも2つの端末デバイスのライブメディアストリームの特性情報が同じであり、ライブメディアストリームが同じアクセスネットワークデバイスに送信されるべきであることを検出した場合、ユーザプレーン機能ネットワーク要素は、ライブメディアストリームを重複排除する。ユーザプレーン機能ネットワーク要素は、重複排除を通じて取得されたライブメディアストリームをアクセスネットワークデバイスに送信し、重複排除を通じて取得されたライブメディアストリーム内の異なるライブメディアストリームの特性情報は互いに異なる。
本出願のこの実施形態では、ユーザプレーン機能ネットワーク要素は、第1のアクティブ特性情報セットおよびメディアストリームに対応するアクセスネットワークデバイスに基づいて、ユーザプレーン機能ネットワーク要素とアクセスネットワークデバイスとの間で重複排除されたメディアストリームを伝送して、伝送ネットワーク上の負担を低減し、ユーザのメディア視聴体験を効果的に保証する。
可能な設計では、端末デバイスがライブストリーミングサービスにアクセスしていることを検出した後、ユーザプレーン機能ネットワーク要素は、端末デバイスの指示情報およびアドレス情報をセッション管理機能ネットワーク要素に送信し、その結果、セッション管理機能ネットワーク要素は、端末デバイスの指示情報およびアドレス情報をアクセスネットワークデバイスに送信する。アドレス情報は、IPおよびポート情報のうちの少なくとも1つを指し得ることに留意されたい。
本出願のこの実施形態では、セッション管理機能ネットワーク要素は、IP/ポート情報をアクセスネットワークデバイスに送信し、その結果、アクセスネットワークデバイスは、IP/ポート情報を端末デバイス側に送信して、端末デバイス側がIP/ポート情報を元のIP/ポート情報にバインドし、対応するデータを受信した後に対応するデータを解析し適用することができることを保証する。
第4の態様によれば、本出願の一実施形態は、メディアストリーム切り替え方法をさらに提供する。方法は、セッション管理機能ネットワーク要素に適用可能である。方法は、端末デバイスのライブセッションを確立するとき、セッション管理機能ネットワーク要素が、ポリシー管理機能ネットワーク要素から初期特性情報セットを取得することを含む。初期特性情報セットは、種々のメディアストリームパラメータに対応するライブメディアストリームの特性情報を含む。ライブセッションを確立した後、セッション管理機能ネットワーク要素は、第1の指示情報をユーザプレーン機能ネットワーク要素に送信し、初期特性情報セットを端末デバイスに送信する。第1の指示情報は、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を監視するように指示する。
可能な設計では、セッション管理機能ネットワーク要素は、第3の指示情報を端末デバイスにさらに送信することができる。第3の指示情報を受信すると、端末デバイスは、前述の方法に従って第1のライブメディアストリームを含む特性情報を送信する。
本出願のこの実施形態では、PDUセッションを確立するプロセスにおいて、メディアストリーム切り替えを保証するために、ライブメディアストリームの特性情報の配信が完了される。
可能な設計では、ユーザプレーン機能ネットワーク要素から指示情報を受信した後、セッション管理機能ネットワーク要素は、端末デバイスの識別情報およびユーザプレーン機能ネットワーク要素の識別情報をアプリケーションサーバに送信し、その結果、アプリケーションサーバは、第1のアクティブ特性情報セットを取得し、第1のアクティブ特性情報セットを端末デバイスに送信する。可能な設計では、アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。
本出願のこの実施形態において、端末デバイスは、受信された第1のアクティブ特性情報セットを使用することによって、要求されたメディアストリームの特性情報が第1のアクティブ特性情報セット内に存在するかどうかを決定することができる。要求されたメディアストリームに対応する特性情報が第1のアクティブ特性情報セット内にない場合、端末デバイスは、既存のアプリケーション層対話プロセスを介して、特性情報に対応するライブメディアストリームを要求する。要求されたメディアストリームに対応する特性情報が第1のアクティブ特性情報セット内にある場合、端末デバイスは、特性情報に対応するライブメディアストリーム要求をユーザプレーン機能ネットワーク要素に直接送信する。
第5の態様によれば、本出願の一実施形態は、メディアストリーム切り替え方法をさらに提供する。方法は、アプリケーションサーバに適用可能である。方法は、アプリケーションサーバが、異なるメディアストリームパラメータに対応するライブメディアストリームの特性情報を決定することを含む。アプリケーションサーバは、初期特性情報セットを端末に送信し、初期特性情報セットは、種々のメディアストリームパラメータに対応するライブメディアストリームの特性情報を含む。可能な方法では、アプリケーションサーバは、アプリケーション層メッセージを介して初期特性情報セットを端末デバイスに送信することができる。別の可能な方法では、アプリケーションサーバは、初期特性情報セットをポリシー制御機能ネットワーク要素に送信することができる。セッション確立プロセスにおいて、セッション管理機能ネットワーク要素は、ポリシー制御機能ネットワーク要素から初期特性情報セットを取得し、ユーザプレーン機能ネットワーク要素またはアクセスネットワークデバイスを介して端末デバイスに初期特性情報セットを送信する。
本出願のこの実施形態では、アプリケーションサーバは、異なるメディアストリームパラメータに対応するライブメディアストリームの特性情報をポリシー制御機能ネットワーク要素に通知することによって、ライブメディアストリームをマーキングする。
可能な設計では、アプリケーションサーバが、第1のアクティブ特性情報セットに基づいて、少なくとも2つの端末デバイスのライブメディアストリームの特性情報が同じであることを検出すると、アプリケーションサーバは、ライブメディアストリームを重複排除する。アプリケーションサーバは、重複排除を通じて取得されたライブメディアストリームをユーザプレーン機能ネットワーク要素に送信し、重複排除を通じて取得されたライブメディアストリーム内の異なるライブメディアストリームの特性情報は互いに異なる。
本出願のこの実施形態では、バックボーンネットワークおよび伝送ネットワーク上の負担を低減し、ユーザのメディア視聴体験を効果的に保証するために、重複排除されたメディアストリームが、アプリケーションサーバとユーザプレーン機能ネットワーク要素との間で伝送される。
可能な設計では、アプリケーションサーバは、セッション管理ネットワーク要素からユーザプレーン機能ネットワーク要素および端末デバイスの識別情報を受信し、情報に基づいて、対応するユーザプレーン機能ネットワーク要素によってサービス提供される対応する端末デバイスによってアクセスされるライブメディアストリームに関する情報を決定し、ユーザプレーン機能ネットワーク要素上の第1のアクティブ特性情報セットを決定することができる。
可能な設計では、アプリケーションサーバは、ユーザプレーン機能ネットワーク要素から第1のアクティブ特性情報セットを取得する。アプリケーションサーバは、第1のアクティブ特性情報セットを端末デバイスに送信する。第1のアクティブ特性情報セットは、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報セットを含む。したがって、端末デバイスは、第1のアクティブ特性情報セットに基づいて、切り替えられるべき第1のライブメディアストリームの特性情報を決定することができる。
本出願のこの実施形態において、端末デバイスはさらに、第1のアクティブ特性情報セットをアプリケーションサーバから受信する。第1のアクティブ特性情報セットは、ユーザプレーン機能ネットワーク要素によってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報セットを含む。第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと端末デバイスが決定したとき、端末デバイスは、切り替え要求をアクセスネットワークデバイスに送信する。第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと端末デバイスが決定したとき、端末デバイスは、切り替え要求をアプリケーションサーバに送信する。
可能な設計では、アプリケーションサーバは、フロー記述情報およびメディアインジケータ情報をポリシー制御機能ネットワーク要素に送信する。フロー記述情報は、ライブサービスに対応するライブメディアストリームデータ特徴を記述し、メディアインジケータ情報は、メディアサービスに対して対応する最適化を実行するためのコアネットワークを示す。
可能な設計では、アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。
第6の態様によれば、本出願の一実施形態は、メディアストリーム切り替え方法をさらに提供する。方法はエッジアプリケーションサーバに適用可能であり、エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近いサーバである。本方法には、以下が含まれる。
エッジアプリケーションサーバは、端末デバイスから第1のライブメディアストリームの特性情報を受信する。エッジアプリケーションサーバは、第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定する。エッジアプリケーションサーバは、端末デバイスに送信されたライブメディアストリームを第2のライブメディアストリームから第1のライブメディアストリームに切り替え、第2のライブメディアストリームおよび第1のライブメディアストリームの両方がエッジアプリケーションサーバに対応する。
本出願のこの実施形態では、同じエッジアプリケーションサーバによってサービス提供される複数のユーザが同じライブメディアストリームにアクセスする場合、この方法実施形態のエッジアプリケーションサーバは、メディアストリームを適時に切り替えるのを助け、メディアストリーム切り替え遅延を低減するために、切り替えを実行する資格がある。
可能な設計では、エッジアプリケーションサーバが端末デバイスに送信されるライブメディアストリームを第2のライブメディアストリームから第1のライブメディアストリームに切り替える前に、エッジアプリケーションサーバは、第1のライブメディアストリームに対応する第1のアドレス情報および第2のライブメディアストリームに対応する第2のアドレス情報を決定する。エッジアプリケーションサーバは、第1のライブメディアストリームを搬送するデータパケット内の第1のアドレス情報を第2のアドレス情報と置き換える。
本出願のこの実施形態では、端末デバイス側が、元のIP/ポート情報を使用することによって対応するデータを解析し適用することができることが保証される。
可能な設計では、エッジアプリケーションサーバが第1のライブメディアストリームの特性情報に対応する第1のライブメディアストリームを決定することは、エッジアプリケーションサーバが、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含むと決定することを含む。エッジアプリケーションサーバは、現在監視されているライブメディアストリームにおいて、第1のライブメディアストリームの特性情報を搬送する第1のライブメディアストリームを決定する。第1のアクティブ特性情報セットは、エッジアプリケーションサーバによってサービス提供される少なくとも1つの端末デバイスのライブメディアストリームの特性情報を含む。
本出願のこの実施形態では、エッジアプリケーションサーバは、現在のエッジアプリケーションサーバのサービス範囲内の端末デバイスによってアクセスされているメディアストリームを決定するために、エッジアプリケーションサーバによってサービス提供されるメディアストリームを監視することができる。したがって、対応する第1のライブメディアストリームは、特性情報に基づいて決定され得る。
可能な設計では、エッジアプリケーションサーバは、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。この場合、エッジアプリケーションサーバは、要求メッセージを中央アプリケーションサーバに送信し、要求メッセージは、第1のライブメディアストリームの特性情報を含み、要求メッセージは、端末デバイスに送信されるライブメディアストリームを第1のライブメディアストリームに切り替えることを要求するためのものである。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、エッジアプリケーションサーバは、対応するメディア要求情報を中央アプリケーションサーバに適時に送信して、中央アプリケーションサーバが端末デバイスによって要求されたメディア切り替えに応答することを保証する。
可能な設計では、エッジアプリケーションサーバは、第1のアクティブ特性情報セットが第1のライブメディアストリームの特性情報を含まないと決定する。エッジアプリケーションサーバは、アクセスネットワークデバイスを介して応答メッセージを端末デバイスに送信し、応答メッセージは、ライブメディアストリーム切り替えが失敗したことを端末デバイスに通知するためのものである。このようにして、応答メッセージを受信した後、端末デバイスは、切り替え要求を中央アプリケーションサーバに再送信する。
本出願のこの実施形態では、第1のライブメディアストリームが現在存在しないと決定したとき、エッジアプリケーションサーバは、応答メッセージを端末デバイスに適時に送信して、切り替え障害によって引き起こされる端末デバイス上の長時間のフリーズを回避することができる。
第7の態様によれば、本出願は通信装置を提供する。通信装置は、アクセスネットワークデバイスまたはアクセスネットワークデバイス内に配置されたチップであってもよい。通信装置は、第1の態様を実装する機能を有する。例えば、通信装置は、第1の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、端末デバイスから切り替え要求を受信する。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第1の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第1の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第1の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を介して別の装置と通信し、第1の態様における可能な設計または実装形態のうちのいずれか1つによるアクセスネットワークデバイスによって実行される方法を実行するように構成される。
第8の態様によれば、本出願は通信装置を提供する。通信装置は、端末デバイスまたは端末デバイス内に配置されたチップであり得る。通信装置は、第2の態様を実装する機能を有する。例えば、通信装置は、第2の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、アクセスネットワークによって送信された第1のライブメディアストリームを受信するように構成される。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第2の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第2の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第2の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を介して別の装置と通信し、第2の態様における可能な設計または実装形態のうちのいずれか1つに従って端末デバイスによって実行される方法を実行するように構成される。
第9の態様によれば、本出願は通信装置を提供する。通信装置は、ユーザプレーン機能ネットワーク要素またはユーザプレーン機能ネットワーク要素内に配置されたチップであり得る。通信装置は、第3の態様を実装する機能を有する。例えば、通信装置は、第3の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、端末デバイスによって送信された切り替え要求を受信するように構成される。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第3の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第3の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第3の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を介して別の装置と通信し、第3の態様における可能な設計または実装形態のうちのいずれか1つによるユーザプレーン機能ネットワーク要素によって実行される方法を実行するように構成される。
第10の態様によれば、本出願は通信装置を提供する。通信装置は、セッション管理機能ネットワーク要素またはセッション管理機能ネットワーク要素内に配置されたチップであり得る。通信装置は、第4の態様を実装する機能を有する。例えば、通信装置は、第4の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、端末デバイスによって送信されたセッション確立要求を受信するように構成される。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第4の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第4の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第4の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を通して別の装置と通信し、第4の態様における可能な設計または実装形態のうちのいずれか1つによるセッション管理機能ネットワーク要素によって実行される方法を実行するように構成される。
第11の態様によれば、本出願は通信装置を提供する。通信装置は、アプリケーションサーバまたはアプリケーションサーバに配置されたチップであり得る。通信装置は、第5の態様を実装する機能を有する。例えば、通信装置は、第5の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、アプリケーションサーバによって送信されたセッション確立要求を受信するように構成される。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第5の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第5の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第5の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を通して別の装置と通信し、第5の態様における可能な設計または実装形態のうちのいずれか1つに従ってアプリケーションサーバによって実行される方法を実行するように構成される。
第12の態様によれば、本出願は通信装置を提供する。通信装置は、エッジアプリケーションサーバまたはエッジアプリケーションサーバに配置されたチップであり得る。通信装置は、第6の態様を実装する機能を有する。例えば、通信装置は、第6の態様におけるステップを実行するための対応するモジュール、ユニット、または手段(means)を含む。機能、ユニット、または手段は、ソフトウェアまたはハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。
可能な設計では、通信装置は、処理ユニットと通信ユニットとを含む。通信ユニットは、通信装置と別の装置との間の通信を実装するために、信号を受信および送信するように構成され得る。例えば、通信ユニットは、エッジアプリケーションサーバによって送信されたセッション確立要求を受信するように構成される。処理ユニットは、通信装置の一部の内部動作を実行するように構成され得る。処理ユニットおよび通信ユニットによって実行される機能は、前述の態様においてアクセスネットワークデバイスによって実行されるステップに対応し得る。
可能な設計では、通信装置はプロセッサを含み、トランシーバをさらに含み得る。トランシーバは、信号を受信および送信するように構成され、プロセッサは、第6の態様の可能な設計または実装形態のうちのいずれか1つによる方法を完了するためのプログラム命令を実行する。通信装置は、1つ以上のメモリをさらに含み得る。メモリは、プロセッサに結合される。1つ以上のメモリは、プロセッサと一体化されてもよく、またはプロセッサから独立して配置されてもよい。これは本出願では限定されない。メモリは、第6の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、プロセッサおよびメモリを含む。メモリは、第6の態様における機能を実装するために必要なコンピュータプログラムまたは命令を記憶することができる。プロセッサは、メモリに記憶されたコンピュータプログラムまたは命令を実行することができる。コンピュータプログラムまたは命令が実行されると、通信装置は、前述の態様におけるアクセスネットワークデバイスの可能な設計または実装形態のうちのいずれか1つによる方法を実装する。
可能な設計では、通信装置は、少なくとも1つのプロセッサとインターフェース回路とを含む。少なくとも1つのプロセッサは、インターフェース回路を通して別の装置と通信し、第6の態様における可能な設計または実装形態のうちのいずれか1つに従ってエッジアプリケーションサーバによって実行される方法を実行するように構成される。
第13の態様によれば、本出願は、前述の方法の実施形態または装置の実施形態におけるアクセスネットワークデバイス、ユーザプレーン機能ネットワーク要素、アプリケーションサーバ、セッション管理機能ネットワーク要素、および端末デバイスを含むシステムを提供する。任意選択で、システムは、統一データ管理機能ネットワーク要素と、ポリシー制御機能ネットワーク要素とをさらに含む。
第14の態様によれば、本出願は、前述の方法の実施形態または装置の実施形態におけるアクセスネットワークデバイス、エッジアプリケーションサーバ、中央アプリケーションサーバ、セッション管理機能ネットワーク要素、および端末デバイスを含むシステムを提供する。任意選択で、システムは、統一データ管理機能ネットワーク要素と、ポリシー制御機能ネットワーク要素とをさらに含む。
第15の態様によれば、本出願は、コンピュータ可読記憶媒体を提供する。コンピュータ記憶媒体は、コンピュータ可読命令を記憶する。コンピュータ可読命令がコンピュータ上で読み取られて実行されると、コンピュータは、前述の態様における可能な設計のうちのいずれか1つによる方法を実行する。
第16の態様によれば、本出願は、コンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で読み取られて実行されると、コンピュータは、前述の態様における可能な設計のうちのいずれか1つによる方法を実行する。
第17の態様によれば、本出願はチップを提供する。チップは、プロセッサを含む。プロセッサは、メモリに結合され、前述の態様における可能な設計のうちのいずれか1つによる方法を実装するために、メモリに記憶されたソフトウェアプログラムを読み取って実行するように構成される。
本出願の実施形態では、「少なくとも1つ」は1つ以上を意味し、「複数」は2つ以上を意味することを理解されたい。「および/または」という用語は、関連付けられたオブジェクト間の関連付け関係を説明し、3つの関係が存在し得ることを表す。例えば、Aおよび/またはBは、Aのみが存在する場合、AとBの両方が存在する場合、およびBのみが存在する場合を表すことができる。AおよびBは、単数であっても複数であってもよい。文字「/」は、通常、関連するオブジェクト間の「または」の関係を示す。以下の部分(項目)またはその類似表現の少なくとも1つは、単一の項目(部分)または複数の項目(部分)の任意の組み合わせを含む、これらの項目の任意の組み合わせを示す。例えば、a、b、またはcのうちの少なくとも1つ(1個)は、a、b、c、aおよびb、aおよびc、bおよびc、またはa、b、およびcを表してもよく、a、b、およびcの各々は、要素であってもよく、または1つ以上の要素を含むセットであってもよい。
本出願の実施形態では、「例」、「一部の実施形態では」、「別の実施形態では」などは、例、例示、または説明を与えることを表すために使用される。本出願において「例」として説明される任意の実施形態または設計スキームは、別の実施形態または設計スキームよりも好ましいまたはより多くの利点を有するものとして説明されるべきではない。正確には、「例」という用語は、特定の方法で概念を提示するために使用される。
本出願の実施形態では、「~の(of)」、「対応する(corresponding、relevant)」、および「対応する(corresponding)」は、交換可能に使用されることがある。用語によって表される意味は、差異が強調されない場合には一貫していることに留意されたい。本出願の実施形態では、通信および伝送は、時には交換可能に使用され得る。用語によって表される意味は、差異が強調されない場合には一貫していることに留意されたい。例えば、伝送することは、送信することおよび/または受信することを含むことができ、名詞形または動詞形であってもよい。
本出願の実施形態では、「第1の」および「第2の」などの用語は、説明における区別の目的で使用されるにすぎず、相対的な重要性の指示もしくは含意または順序の指示もしくは含意として理解されるべきではないことに留意されたい。
本出願の実施形態における「ネットワーク要素」は、「デバイス」と称されることもある。これは限定されない。ネットワーク要素は、ハードウェアであってよく、または機能分割を通じて取得されたソフトウェアであってよく、またはそれらの組み合わせの構造であってよい。ネットワーク要素は、コアネットワーク要素、アクセスネットワーク要素(アクセスネットワークデバイスとも称される)などを含み得る。コアネットワーク要素は、例えば、セッション管理ネットワーク要素またはユーザプレーンネットワーク要素を含む。
背景技術で提起された問題に対して、本出願の実施形態は、メディアストリーム切り替え方法を提供する。アクセスネットワークデバイスは、端末デバイスによって送信された切り替え要求内のライブメディアストリームの特性情報に基づいて、特性情報に対応するライブメディアストリームを適時に決定し、特性情報に対応するライブメディアストリームを端末デバイスに配信して、メディアストリーム切り替え遅延を低減する。従来技術と比較して、アクセスネットワークデバイスが切り替え要求を受信した後、特性情報に対応するライブメディアストリームが存在する場合、ライブメディアストリームは、メディアストリーム切り替え遅延を低減するために、コアネットワーク要素を介してアプリケーションサーバから取得される必要がない。切り替えを通じて取得されたメディアストリームは、ネットワーク状態の変化に適応することができる。したがって、ネットワーク状況が良好な場合には、ユーザは端末上でリアルタイムに高画質の映像を視聴することができる。ネットワーク状況が悪化すると、低ビットレートのストリーミングメディアデータが伝送される。このようにして、ユーザが端末上でリアルタイムでビデオを見るとき、ビデオフリーズの可能性が低減され、それによって、ユーザ体験を改善するのに役立つ。
以下、当業者の理解を深める一助とすべく、本出願の実施形態における一部の用語が説明される。
1.メディアストリーム:メディアストリームは、本出願の実施形態においてビデオストリームとして理解されることができ、ビデオストリームは、1つ以上のビデオフレームを含むことができる。
2.メディアストリームパラメータ:本出願の実施形態におけるメディアストリームパラメータは、ビデオフレーム画質または視野の定義を示すことができる。例えば、メディアストリームパラメータは、視野、ビットレート、解像度、および/またはフレームレートであってもよい。例えば、ビットレートは、解像度およびフレームレートに依存する。例えば、ビットレート=フレームレート*ビデオフレームのサイズでありビデオフレームのサイズは、ビデオフレームの解像度および使用されるメディア符号化技術に依存する。したがって、通常、ビットレートとフレームレートと解像度との間には対応関係がある。例えば、メディアストリームパラメータがビットレートである場合、フレームレートおよび解像度は、ビットレートの適応ネットワーク調整の後にそれに応じて調整される。
より高いビットレートは、より高いビデオ品質を示す。例えば、ビットレートが10 Mbpsの映像の画質は、ビットレートが5 Mbpsの映像の画質よりも高い。通常、より高いビットレートは、ストリーミングメディアデータを伝送するためのネットワーク帯域幅に対するより高い要件を示す。例えば、10 Mbpsのビットレートでストリーミングメディアデータを伝送するために必要とされるネットワーク帯域幅は、5 Mbpsのビットレートでストリーミングメディアデータを伝送するために必要とされるネットワーク帯域幅よりも大きい。
本出願の実施形態では、メディアストリームパラメータ識別子は、メディアストリームパラメータのサイズを示すために使用され、換言すれば、異なるサイズを有するメディアストリームパラメータの識別子は異なることを理解されたい。メディアストリームパラメータがビットレートであるとき、メディアストリームパラメータ識別子はビットレート識別子とも称され得ることに留意されたい。同様に、メディアストリームパラメータが解像度である場合、メディアストリームパラメータ識別子は、解像度識別子とも称され得る。メディアストリームパラメータがフレームレートであるとき、メディアストリームパラメータ識別子はフレームレート識別子と称されることもある。例えば、メディアストリームパラメータは、解像度である。例えば、360Pの解像度識別子は000であり、720Pの解像度識別子は001であり、1080Pの解像度識別子は010である。
アクセスネットワークデバイス、モビリティ管理ネットワーク要素、セッション管理ネットワーク要素、ユーザプレーンネットワーク要素、およびポリシー制御ネットワーク要素が、本出願で提供されるメディアストリーム切り替え方法を実行する際にネットワーク側に関与することに留意されたい。アクセスネットワークデバイスは、アクセスネットワーク要素である。モビリティ管理ネットワーク要素、セッション管理ネットワーク要素、ユーザプレーンネットワーク要素、およびポリシー制御ネットワーク要素は、コアネットワーク要素である。例えば、アクセスネットワークデバイスは、端末に無線通信機能を提供するように構成される。例えば、アクセスネットワークデバイスは、無線アクセスネットワーク(radio access network、RAN)要素である。モビリティ管理ネットワーク要素は、端末のモビリティ管理を担当する。例えば、モビリティ管理ネットワーク要素は、モビリティ管理エンティティ(mobility management entity、MME)またはアクセスおよびモビリティ管理機能(access and mobility management function、AMF)エンティティである。セッション管理ネットワーク要素は、パケットデータユニット(packet data unit、PDU)セッションの確立、変更、および削除を制御するように構成される。例えば、セッション管理ネットワーク要素は、セッション管理機能(session management function、SMF)エンティティである。ユーザプレーンネットワーク要素は、外部ネットワーク(例えば、データネットワーク(data network、DN))に接続することを担当する。例えば、ユーザプレーンネットワーク要素は、ユーザプレーン機能(user plane function、UPF)エンティティである。ポリシー制御ネットワーク要素は、ポリシー制御を担当し、例えば、サービス品質(quality of service、QoS)パラメータセットを生成する。例えば、ポリシー制御ネットワーク要素は、ポリシー制御機能(policy control function、PCF)エンティティである。
端末およびアプリケーションサーバは、本出願で提供されるメディアストリーム切り替え方法を実行することに関与される。本出願の実施形態では、端末は、端末デバイス、ユーザ機器(user equipment)、モバイル端末、メディアクライアントなどと称されることもあることを理解されたい。これらに限定されるものではない。アプリケーションサーバは、メディアストリームサーバなどと称されることもある。これらに限定されるものではない。アプリケーションサーバは、エッジアプリケーションサーバまたは中央アプリケーションサーバであり得る。エッジアプリケーションサーバは、中央アプリケーションサーバよりも端末デバイスに近い。エッジアプリケーションサーバは、ローカルアプリケーションサーバと称されることもある。中央アプリケーションサーバは、リモートアプリケーションサーバと称されることもある。以下では、UEおよびアプリケーションサーバを例として使用することによって、本出願の実施形態を説明する。
例えば、図1は、本出願の一実施形態が適用可能なネットワークアーキテクチャの概略図である。ネットワークアーキテクチャは、第5世代移動通信技術(5th generation mobile communication technology、5G)ネットワークアーキテクチャである。ネットワークアーキテクチャは、無線アクセスネットワーク(radio access network、RAN)、AMFネットワーク要素、SMFネットワーク要素、UPFネットワーク要素、PCFネットワーク要素、DNなどを含む。一部の実施形態では、ネットワークアーキテクチャは、統一データ管理機能(unified data management、UDM)エンティティ、認証サーバ機能(authentication server function、AUSF)エンティティ、アプリケーション機能(application function、AF)エンティティ、ネットワークエクスポージャ機能(network exposure function、NEF)エンティティ、ネットワークデータ解析機能(network data analytics function、NWDAF)エンティティなどをさらに含む。
RAN(アクセスネットワーク(access network、AN)とも称され得る)の主な機能は、移動通信ネットワークに無線でアクセスするようにUEを制御することである。RANは、移動通信システムの一部である。RANは、無線アクセス技術を実装する。例えば、RANは、RANネットワーク要素を介して、移動通信ネットワークに無線でアクセスするようにUEを制御し、RANは、UEとコアネットワーク要素との間に位置される。アクセスネットワークデバイスとも称されるRANネットワーク要素は、5GにおけるgノードB(g nodeB、gNB)、進化型ノードB(evolved node B、eNB)、無線ネットワークコントローラ(radio network controller、RNC)、ノードB(node B、NB)、基地局コントローラ(base station controller、BSC)、送受信基地局(base transceiver station、BTS)、ホーム基地局(例えば、home evolved nodeBまたはhome node B、HNB)、ベースバンドユニット(base band unit、BBU)、送受信ポイント(transmitting and receiving point、TRP)、伝送ポイント(transmitting point、TP)、モバイル切り替えセンタなどを含むが、これらに限定されない。加えて、RANデバイスは、ワイヤレスフィデリティ(wireless fidelity、wifi)アクセスポイント(access point、AP)などをさらに含み得る。
AMFネットワーク要素は、ユーザ登録管理、到達可能性検出、SMFネットワーク要素選択、モビリティステータス切り替え管理などを含む、UEアクセス管理およびモビリティ管理を担当する。
SMFネットワーク要素は、PDUセッション確立、修正、および削除、UPFネットワーク要素選択などを制御することを主に担当する。
UPFネットワーク要素は、データパケットのルーティングおよび転送を主に担当し、モビリティアンカーポイントおよびアップリンク分類器を介してデータネットワークにサービスフローをルーティングする際のサポートを提供し、分岐点を介してマルチホームPDUセッションのサポートなどを行う。
PCFネットワーク要素は、ポリシー決定ポイントとして機能し、サービスデータフローおよびアプリケーション検出ルール、ゲーティング制御ルール、QoSルール、およびフローベースの課金制御ルールなどのルールを提供することを主に担当する。
UDMエンティティは、ユーザサブスクリプションデータを記憶することを主に担当する。
AUSFエンティティは、認証サービスを提供するように主に構成される。
AFエンティティは、第3世代パートナーシッププロジェクト(3rd generation partnership project、3GPP(登録商標))コアネットワークと対話してサービスを提供し、サービスフロールーティング、アクセスネットワーク能力公開、ポリシー制御などに影響を与えるように主に構成される。
NEFエンティティは、サードパーティ、エッジコンピューティング、またはAFなどの3GPP(登録商標)ネットワーク機能によって提供されるサービスおよび能力を安全に公開するように主に構成される。
DNは、オペレータサービス、インターネットアクセス、またはサードパーティサービスなどのネットワークサービスをUEに提供する。
NWDAFエンティティは、ビッグデータおよび人工知能などの技術に基づいて、ネットワークデータの収集および解析などの機能を提供するように主に構成される。
また、説明の簡潔にするために、以降の説明では、各機能エンティティにおける「エンティティ」は省略される。例えば、AMFネットワーク要素は、略してAMFと称され、UPFネットワーク要素は、略してUPFと称される。これは、他のエンティティについても同様であり、1つずつ列挙されない。
図1では、NWDAF、NEF、NRF、PCF、UDM、AF、AUSF、AMF、およびSMFのうちの任意の2つのネットワーク要素が、互いにサービス指向通信を実行することができる。例えば、NEFとAUSFとの間の通信に使用されるインターフェースNnefおよびNausfは、サービス指向インターフェースである。同様に、インターフェースNnwdaf、Nnrf、Npcf、Nudm、Naf、Namf、およびNsmfは、サービス指向インターフェースである。また、AMFはN1インターフェースを介してUEと通信し得、AMFはN2インターフェースを介してRANネットワーク要素と通信し得、RANネットワーク要素はN3インターフェースを介してUPFと通信し得、SMFはN4インターフェースを介してUPFと通信し得、UEはエアインターフェースを介してRANネットワーク要素と通信し、UPFはN6インターフェースを介してDNと通信し、UPFはN9インターフェースを介して互いに通信得る。図1のネットワーク要素間のサービス指向インターフェースは、ポイントツーポイントインターフェースと代替的に置き換えられてもよいことに留意されたい。
図1に示されるネットワークアーキテクチャでは、本出願に関連するネットワーク要素は、主に、RANネットワーク要素、AMFネットワーク要素、SMFネットワーク要素、UPFネットワーク要素、およびPCFネットワーク要素である。
本出願のこの実施形態におけるUEは、無線トランシーバ機能を有するデバイスであることを理解されたい。デバイスは、陸上に配置されてもよく、屋内デバイス、屋外デバイス、ハンドヘルドデバイス、または車載デバイスを含み、または水面上(例えば、船上)に配置されてもよく、または空中(例えば、飛行機、気球、または衛星上)に配置されてもよい。例えば、UEは、携帯電話(mobile phone)、タブレットコンピュータ(pad)、スマートスクリーン、無線送受信機能を有するコンピュータ、仮想現実(virtual reality、VR)端末デバイス、拡張現実(augmented reality、AR)端末、産業制御(industrial control)における無線端末、自動運転(self driving)における無線端末、遠隔医療(remote medical)における無線端末、スマートグリッド(smart grid)における無線端末、交通安全(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマートホーム(smart home)における無線端末などであってよい。
図1は、本出願の一実施形態が適用可能なネットワークアーキテクチャの一例にすぎず、本出願の実施形態に対するいかなる限定も構成しないことに留意されたい。本出願の実施形態は、別のネットワークアーキテクチャ、例えば、将来のモバイル通信ネットワークアーキテクチャ(例えば、6Gネットワークアーキテクチャ)に代替として適用されてもよい。
図2Aは、本出願の一実施形態によるライブストリーミングシステムの概略図である。ライブストリーミングは、複数のユーザが同じライブコンテンツを同時に視聴することができるソーシャルネットワーキングの新しい方法である。
具体的には、ソーシャルネットワーキングの新しい方法として、ライブストリーミングは以下の特徴を有する。ユーザは端末上で操作を実行してもよく、端末はライブストリーミング要求をサーバに送信してもよい。サーバは、ユーザのためのライブストリーミングルームを作成し、ここでライブストリーミングルームは、オンスクリーンコメントとともにライブオーディオおよびビデオストリーミングを提供するオンライン仮想ルームである。ユーザは、ライブストリーミングルームのイニシエータ、すなわち、ライブストリーマである。ライブストリーマは、ライブストリーミングルーム内の歌、ゲーム、映画、およびTVシリーズなどのオーディオおよびビデオコンテンツを表示してもよい。視聴者としての別のユーザも、別の端末を介してライブストリーミングルームに入り、ライブストリーミングルーム内のライブストリーマによって表示されるコンテンツを視聴してもよく、またはライブストリーマと対話してもよく、例えば、ライブストリーマのように、ライブストリーマにギフトを贈ってもよく、ライブストリーマをフォローもしくは共有してもよく、またはライブストリーマとチャットしてもよい。
図1に示されるように、ライブストリーミングシステムは、複数の端末とコンテンツ配信ネットワークとを含むことができる。複数の端末は、ライブストリーマの端末およびn人の視聴者の端末を含んでもよい。コンテンツ配信ネットワークは、複数の端末にオーディオおよびビデオサービスを提供するように構成される。ライブストリーマの端末は、ライブストリーマのライブストリーミングプロセスにおいてオーディオおよびビデオデータを収集し、オーディオおよびビデオデータに基づいてライブメディアストリームを取得し、ライブメディアストリームをコンテンツ配信ネットワークに送信してよい。コンテンツ配信ネットワークは、ライブメディアストリームをn人の視聴者の端末に転送する。この場合、視聴者の端末は、ライブメディアストリームを復号して再生することができ、その結果、視聴者は、ライブストリーマのライブコンテンツを視聴することができる。
ライブストリーマの端末は、端末上のライブストリーミングアプリケーションクライアント上でライブストリーミングを実行してもよく、またはポータルウェブサイト上でライブストリーミングを実行してもよい。同様に、n人の視聴者の端末は、ライブストリーミングアプリケーションまたはポータルサイトを介してライブメディアストリームを取得してもよい。これは、本発明の実施形態において限定されない。
なお、ライブストリーミングシステムは、メッセージ配信サーバをさらに含み得ることに留意されたい。メッセージ中継配信サーバは、端末が視聴者の端末であるか、ライブストリーマの端末であるかを区別しない。メッセージ中継配信サーバは、任意の端末によって送信されたメッセージを他の端末にブロードキャストすることができる。このようにして、ライブストリーミングルーム内の全ての端末がメッセージを見ることができ、メッセージは通常、視聴者とライブストリーマとの間のインタラクティブコンテンツを含む。本発明のこの実施形態は、本明細書ではさらなる詳細を提供しない。
加えて、本出願の実施形態で使用されるライブストリーミングシナリオは、ライブストリーミングに限定されず、スポーツゲームのライブブロードキャスト、主要なニュースイベントのライブブロードキャストなどにさらに適用可能であることに留意されたい。本明細書では例は1つずつ記載されない。
図2Bは、現在のライブストリーミングシステムに対応するネットワークアーキテクチャの概略図である。ネットワークアーキテクチャは、図1に示される無線アクセスネットワーク(radio access network、RAN)、AMFネットワーク要素、SMFネットワーク要素、UPFネットワーク要素、PCFネットワーク要素、DNなどを含む。各ネットワーク要素の具体的な実行機能については、図1を参照されたい。詳細は、ここでは再び説明されない。
図2Bにおいて、各UEは、ライブメディアストリームのアプリケーションサーバとデータ伝送チャネルを別々に確立し、ライブメディアストリームデータを独立して要求し伝送する。例えば、図2Bでは、6つのUE(UE1、UE2、UE3、UE4、UE5、およびUE6)がそれぞれ、ライブメディアストリームのアプリケーションサーバとの6つのデータ伝送チャネルを確立する。同じライブメディアストリームが、UE1およびUE6に対応するデータ伝送チャネルを通して伝送される。同じライブメディアストリームが、UE2およびUE3に対応するデータ伝送チャネルを通して伝送される。同じライブメディアストリームが、UE4およびUE5に対応するデータ伝送チャネルを通して伝送される。現在、同じコンテンツを有するライブメディアストリームが、コアネットワーク要素およびアクセスネットワーク要素を介して繰り返し伝送されることが知見され得る。これにより、リソース利用率を大幅に低減する。
加えて、現在、ライブメディアストリーム伝送では、UEが視野またはビットレートを切り替えるとき、UEは、切り替えられた視野またはビットレートを有するライブメディアストリームをアプリケーションサーバ側に要求する必要がある。要求を受信した後、アプリケーションサーバは、切り替えられたライブメディアストリームをUEに送信する。現在、このプロセスにおけるネットワーク遅延に起因して、メディアストリーム切り替え遅延が過度に長く、ライブビデオがフリーズし、これは、ユーザのリアルタイムライブビデオ視聴体験に深刻な影響を及ぼしている。
したがって、本出願は、メディアストリーム切り替え方法を提供する。本方法によれば、アクセスネットワーク要素またはユーザプレーンネットワーク要素は、端末デバイスからのライブメディアストリームの特性情報に基づいて、複数の現在伝送されているライブメディアストリーム内のライブメディアストリームに対応するライブメディアストリームを決定し、複製されたライブメディアストリームを端末デバイスに配信して、メディアストリームを適時に切り替え、メディアストリーム切り替え遅延を改善することができる。加えて、本方法によれば、アプリケーションサーバとアクセスネットワーク要素との間のライブメディアストリームの重複排除伝送も実装され、それによって、コアネットワーク要素とアクセスネットワーク要素との間の伝送負担を低減し、リソース利用率を改善する。
本出願において提供される以下の実施形態では、本出願の実施形態において提供される方法は、図1に示されるネットワークアーキテクチャを参照して主に詳細に説明される。以下では、メディアストリームパラメータが視野であることが主に仮定される。メディアストリームパラメータがビットレート、解像度、またはフレームレートなどの別のパラメータである場合、セッション確立方法、データ伝送方法、およびメディアストリーム切り替え方法に関して、メディアストリームパラメータが視野である方法を参照されたい。
実施形態1
この実施形態は、ライブサービスに対応するセッションを確立するプロセスである。このプロセスは、セッション確立プロセスにおいてライブメディアストリームの特性情報の配信を完了することを目的とする。
図3は、本出願の一実施形態によるセッション確立方法を示している。具体的には、この方法は以下のステップを含む。
ステップ301:アプリケーションサーバが、ライブメディアストリームの特性情報をマーキングし、初期特性情報セットをPCFに送信する。初期特性情報セットは、各ライブメディアストリームに対応する特性情報を含む。
具体的には、アプリケーションサーバは、異なるライブメディアストリームデータパケットに特性情報をカプセル化する。通常、特性情報は、ライブメディアストリームデータパケットのIP層でカプセル化される。特性情報は、特定のメディアストリームパラメータ値またはインデックス値であり得る。
ケース1:ライブメディアストリームの特性情報は、メディアストリームパラメータ値であり得る。
例えば、メディアストリームパラメータが視野であるパノラマライブメディアストリームが一例として使用される。アプリケーションサーバによってマーキングされたパノラマライブメディアストリームの特性情報は、視野度値であってもよい。例えば、視野が0度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化された特性情報は、0度である。視野が90度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化された特性情報は90度である。視野が360度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化された特性情報は360度である。残りは、類推によって推定されることができる。アプリケーションサーバは、対応する視野度値を、(0度、360度)に対応する各ライブメディアストリームデータパケットにカプセル化することができる。ここで、初期特性情報セットは、0度~180度を含む視野度リストであってもよい。
ケース2:ライブメディアストリームの特性情報は、各ライブメディアストリームに一意に対応するインデックス値であり得る。
例えば、メディアストリームパラメータが視野であるパノラマライブメディアストリームは、依然として一例として使用される。アプリケーションサーバによってマーキングされたパノラマライブメディアストリームの特性情報は、インデックス値であり得る。例えば、視野が0度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は、0X00である。視野が90度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は、0X5Aである。視野が360度であるとき、アプリケーションサーバによってライブメディアストリームデータパケットにカプセル化されたインデックス値は0168である。残りは、類推によって推定されることができる。アプリケーションサーバは、対応するインデックス値を(0度、360度)に対応する各ライブメディアストリームデータパケットにカプセル化することができる。この例では、初期特性情報セットは、0X00~0168を含むインデックスリスト(英文:index list)であってよい。
別の例では、ライブメディアストリームのメディアストリームパラメータはビットレートである。アプリケーションサーバによってサポートされるビットレートが、10 Mbps、5 Mbps、および2 Mbpsであると仮定される。アプリケーションサーバは、10 Mbpsのビットレートを有するライブメディアストリーム、5 Mbpsのビットレートを有するライブメディアストリーム、および2 Mbpsのビットレートを有するライブメディアストリームに別々に番号を付ける。例えば、ビットレートが10 Mbpsであるとき、アプリケーションサーバによってライブメディアストリームデータパケットにカプセル化されたインデックス値は000である。ビットレートが5 Mbpsであるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は001である。ビットレートが2 Mbpsであるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は010である。ここで、初期特性情報セットは、000、001、010を含むインデックスリストであってもよい。
このステップにおいて、アプリケーションサーバは、アプリケーション要求(AF Request)メッセージを使用することによって、メディアインジケータ情報およびフロー記述情報をPCFにさらに送信することができる。具体的には、メディアインジケータ情報は、メディアサービスに対して対応する最適化を実行するコアネットワークを示す。フロー記述情報は、ライブサービスに対応するライブメディアストリームデータ特性を記述する。例えば、ライブメディアストリームデータ特徴は、AS側のライブメディアストリームのIP 3タプル情報(ターゲットIPアドレス、ターゲットポート、およびトランスポート層プロトコル)を含むことができる。UPFは、データ内のヘッダ情報を確認することによって、サービスがライブメディアサービスであるか否かを決定することができる。
一部の実施形態では、アプリケーションサーバは、AFを介して初期特性情報セットをPCFに送信することができる。特に、アプリケーションサーバから初期特性情報セットを受信した後に、AFは、Nnef_AFsessionWithQoS_Createサービスを使用することによって、初期特性情報セットをNEFに送信することができる。認証後、NEFは、Npcf_PolicyAuthorization_Createサービスを使用することによって、初期特性情報セットをPCFに送信する。
ステップ302:UE1は、セッション確立要求メッセージをSMFネットワーク要素に送信する。
具体的には、セッション確立要求メッセージはNASメッセージである。セッション確立要求メッセージは、PDUセッション確立要求メッセージまたはPDUセッション修正要求メッセージであり得る。
ステップ303:セッション確立要求メッセージを受信した後、SMFネットワーク要素は、PCFから初期特性情報セットを取得する。
例えば、SMFネットワーク要素は、PCFへの要求を開始する。要求を受信した後、PCFは、初期特性情報セットを搬送するNpcf_SMPolicyControl_Update/CreateをSMFに送信する。別の例では、PCFは、初期特性情報セットを搬送する新たに定義された情報をSMFに代替として送信してもよい。
可能な実施形態では、SMFネットワーク要素は、PCFからメディアインジケータ情報およびデータフロールールをさらに取得することができる。
ステップ304:SMFネットワーク要素が、第1の指示情報をUPFネットワーク要素に送信する。
第1の指示情報は、N4セッション確立メッセージ内で搬送され得る。換言すれば、SMFネットワーク要素とPCFとの間のセッション管理ポリシー関連付けを作成した後、SMFネットワーク要素は、N4の、第1の指示情報を搬送するセッション確立要求をUPFに送信する。第1の指示情報は、端末デバイスのダウンリンクライブメディアストリームを監視するようにUPFに指示する。
可能な実施形態では、SMFネットワーク要素は、パケット検出規則(packet detection rule、PDR)をUPFにさらに送信することができる。PDRは、現在のサービスが該当のライブサービスであるか否かを監視し、ダウンリンクメディアストリーム内の識別情報を監視するため用いられることができる。
ステップ305:SMFネットワーク要素は、第2の指示情報をRANにさらに送信し、第3の指示情報をUE1に送信する。
第2の指示情報は、端末デバイスのダウンリンクライブメディアストリームを監視するようにRANに指示する。
第3の指示情報は、初期特性情報セットおよびRAN側からの後続の指示に基づいて、メディアストリームを要求および受信することを示す。
可能な場合には、SMFネットワーク要素は、初期特性情報セットをUE1にさらに送信することができる。
例えば、SMFネットワーク要素は、Namf_Communication_N1N2MessageTransferサービスメッセージを使用することによって、第2の指示情報(Indicator2)をRAN側に送信し、第3の指示情報(Indicator3)および初期特性情報セットをRAN側およびUE側に送信することができる。
ステップ306:セッション確立が完了された後、UPFは、第1の指示情報に基づいて、UE1に送信されたダウンリンクライブメディアストリームを監視し、ダウンリンクライブメディアストリームデータパケット内の特性情報を取得し、特性情報を第1のアクティブ特性情報セットに記憶する。具体的に、特性情報は、データパケットのIP/トランスポート/アプリケーション層ヘッダに含まれてもよい。これは限定されない。例えば、UPFは、UE1に送信されたダウンリンクライブメディアストリームデータパケット内の特性情報が90度であることを監視を通じて取得し、したがって、90度を第1のアクティブ特性情報セットに記憶する。別の例では、UPFは、UE1に送信されたダウンリンクライブメディアストリームデータパケット内の特性情報が001であることを監視を通じて取得し、したがって、第1のアクティブ特性情報セットに001を記憶する。
ステップ307:UPFは、ライブメディアストリームデータパケットのGTP層(具体的には、GTP-U層)において特性情報をさらにカプセル化する。
例えば、UPFは、N3リンク上の「90度」に対応するライブメディアストリームデータパケットのGTP層において特性情報「90度」をカプセル化する。
ステップ308:SMFネットワーク要素から第2の指示情報を受信した後、RANは、UPFからのダウンリンクライブメディアストリームデータパケットのGTP層を監視し、ダウンリンクライブメディアストリーム内の特性情報を取得し、特性情報を第2のアクティブ特性情報セットに記憶する。
例えば、RANは、監視を通じて、ダウンリンクライブメディアストリームデータパケット内の特性情報が90度であることを取得し、したがって、90度を第2のアクティブ特性情報セットに記憶する。別の例では、RANは、監視を通じて、ダウンリンクライブメディアストリームデータパケット内の特性情報が001であることを取得し、したがって、001を第2のアクティブ特性情報セットに記憶する。
可能な実施形態では、RANは、特性情報とUE1との間のマッピング関係をさらに作成してもよい。例えば、RANは、特性情報「90度」とUE1との間のマッピング関係を作成する。このようにして、複数のUEがRANにアクセスするとき、RANは、RANによってサービス提供される各UEに対応するライブメディアストリームを決定することができる。
別の可能な実施形態では、RANは、SMFネットワーク要素からUE1に対応するQFIおよび第1のアドレス情報をさらに取得することができる。QFIは、UE1に送信されるダウンリンクライブメディアストリームを示す。第1のアドレス情報は、IPアドレスおよび/またはポート番号(port range)を含み得る。具体的には、RANは、SMFネットワーク要素からN2 SMメッセージを受信し、N2 SMメッセージからQFIおよび第1のアドレス情報を取得することができる。したがって、RANは、UE1と第1のアドレス情報との間のマッピング関係を確立することができる。
ステップ309:UE1は、SMFネットワーク要素から第3の指示情報を受信し、第3の指示情報を記憶する。
第3の指示情報は、初期特性情報セットおよびRAN側からの後続の指示に基づいて、メディアストリームを要求および受信することを示す。
可能な実施形態では、UE1はさらに、SMFネットワーク要素から初期特性情報セットを受信し得る。別の可能な実施形態では、前述の方法は、ステップ310をさらに含むことができ、UE1は、アプリケーションサーバのアプリケーション層と対話することによって初期特性情報セットを代替的に知ることができる。
以下では、前述のセッション確立プロセスを説明するため具体的な例を提供する。
図2Bを参照すると、UE1~UE6はそれぞれ、ステップ301~ステップ309に示される方法に従って、UE1~UE6に対応するセッションを確立することができる。UE1~UE6が同じライブストリーミングルーム内にある場合、UE1~UE6が全て同じRANおよび同じUPFネットワーク要素にアクセスするか、またはUE1~UE6が全て同じUPFネットワーク要素にアクセスする可能性が非常に高い。UE1~UE6は全て、同じRANおよび同じUPFネットワーク要素にアクセスすると仮定される。この場合、UPFネットワーク要素は、6つのUEにそれぞれ送信される6つのダウンリンクライブメディアストリームを監視する。したがって、UPFネットワーク要素によって記憶された第1のアクティブ特性情報セットは、6つのダウンリンクライブメディアストリームの特性情報を含む。加えて、RANによって記憶された第2のアクティブ特性情報セットも、6つのダウンリンクライブメディアストリームの特性情報を含む。可能な場合には、RANは、6つのダウンリンクライブメディアストリームの特性情報を含む第2のアクティブ特性情報セットを、RANのサービス範囲内にあるUE1~UE6にさらに送信することができ、その結果、ライブメディアストリームが切り替えられる必要があると決定したとき、UE1~UE6は、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて第2のアクティブ特性情報セットを検索する。
例えば、図2Bに示されるように、UE1およびUE6は、同一コンテンツを伴うダウンリンクライブメディアストリームに対応し、UE2およびUE3は、同一コンテンツを伴うダウンリンクライブメディアストリームに対応し、UE4およびUE5は、同一コンテンツを伴うダウンリンクライブメディアストリームに対応する。したがって、UPFネットワーク要素によって記憶された第1のアクティブ特性情報セットは、001、002、および003を含む。UE1~UE6も同じRANにアクセスするので、RANによって記憶された第2のアクティブ特性情報セットも001、002、および003を含む。
UE1~UE6が全て同じUPFネットワーク要素にアクセスするが、UE2~UE4がRAN1にアクセスし、UE1およびUE6がRAN2にアクセスする場合、RAN1によって記憶された第2のアクティブ特性情報セットは002および003も含み、RAN1によって記憶された第2のアクティブ特性情報セットは001も含むことに留意されたい。
加えて、第1のアクティブ特性情報セットおよび第2の特性情報セットは固定されず、リアルタイムで更新されることに留意されたい。新たな視聴者のUEがライブメディアサービスにアクセスすると、新たなPDUセッションが確立される可能性が高い。新しく確立されたPDUセッションによって伝送されるダウンリンクライブメディアストリームの特性情報が004である場合、第1のアクティブ特性情報セットは、001、002、003、および004を含む。反対に、UE1およびUE6がライブサービスから離脱する場合、UE1に対応するPDUセッションおよびUE6に対応するPDUセッションが解除される。この場合、第1のアクティブ特性情報セットは、002および003を含む。
さらに、図2Bを参照すると、UE1~UE6が全て同じRANネットワーク要素にアクセスする場合、UE1~UE6のセッションが確立された後、RANは、ステップ208に示される方法に従って、各UEの識別子と、アドレス情報と、ライブメディアストリームの特性情報との間のマッピング関係を確立することができる。例えば、マッピング関係が表1に示される。
表1から、各UEのライブメディアストリームが位置されるセッションは、対応するIPおよびポート番号を有することが知見され得る。
本出願のこの実施形態では、ユーザのPDUセッション確立プロセスにおいて、SMFネットワーク要素は、セッション確立中に対応する指示情報をUE/RAN/UPFに配信して、UE/RAN/UPFが、AFによって提供されるライブメディアストリームの特性情報に基づいて、後続のデータ伝送プロセスにおいて切り替え処理を迅速に実行できることを保証し、その結果、適時のメディアストリーム切り替えが保証される。
実施形態2
実施形態1のセッション確立プロセスにおけるライブメディアストリームの特性情報の配信に基づいて、アプリケーションサーバ、コアネットワーク要素、およびアクセスネットワーク要素は、ライブメディアストリームの特性情報を識別することによって、ASとUPFネットワーク要素との間、およびUPFネットワーク要素とRANとの間の複製されたメディアストリームを除去することができる。加えて、本方法によれば、ASとRANとの間のライブメディアストリームの重複排除伝送が実装され、それによって、コアネットワーク要素とアクセスネットワーク要素との間の伝送負担を低減し、リソース利用率を改善する。
図4Aは、本出願の一実施形態によるデータ伝送方法を示している。具体的には、この方法は以下のステップを含む。
ステップ401:SMFネットワーク要素から受信された第1の指示情報に基づいて、少なくとも1つのUEがライブストリーミングサービスにアクセスしていることを検出した後、UPFネットワーク要素が、通知情報をSMFネットワーク要素に送信する。通知情報は、少なくとも1つのUEによってアクセスされているライブメディアストリームの特性情報をSMFネットワーク要素に通知するためのものである。
例えば、図2Bを参照すると、UPFネットワーク要素は、UE1~UE6がライブストリーミングサービスにアクセスしていることを検出する。したがって、UPFネットワーク要素は、N4セッション報告手順を使用することによって、通知情報をSMFネットワーク要素に送信する。通知情報は、UE1~UE6によってアクセスされているライブメディアストリームの特性情報が001、002、および003であることをSMFネットワーク要素に通知するためのものである。
ステップ402:SMFネットワーク要素が、通知情報をPCF側に転送する。
具体的には、SMFネットワーク要素は、セッション管理ポリシー管理修正手順を使用することによって、通知情報をPCF側に送信することができ、対応する通知情報は、UEの識別情報および対応するUPFの識別情報を含むことができる。
ステップ403:PCFは、通知情報をAF/AS側に通知する。
具体的には、PCFは、能力エクスポージャ情報Npcf_EventExposure_Notifyメッセージを使用することによって、通知情報をAF/AS側に通知してもよく、またはNpcf_EventExposure_Notifyメッセージを使用することによって、通知情報をNEFに通知し、次いで、NEFは、Nnef_EventExposure_Notifyメッセージを使用することによって、通知情報をAF/AS側に通知してもよい。
ステップ404:AF/AS側は、受信された通知情報に基づいて、UPFによってサービス提供される端末によってアクセスされるライブメディアストリームの特性情報セットを決定することができる。UPFによってサービス提供される端末によってアクセスされるライブメディアストリームの特性情報セット内に複製された特性情報が存在すると決定されたとき、AF/AS側は、UPFネットワーク要素に送信された複製されたダウンリンクライブメディアストリームを除去する。
ステップ405:AS/AFは、重複排除されたダウンリンクライブメディアストリームをUPFネットワーク要素に送信する。
ステップ406:UPFネットワーク要素はまた、監視結果に基づいて、同じRANに到達するライブメディアストリームの特性情報が複製されているかどうかを決定する。複製された特性情報が存在する場合、UPFネットワーク要素は、複製されたダウンリンクライブメディアストリームを除去する。
具体的には、UPFは、GTPトンネルのダウンリンクターゲットIPアドレスに基づいて、RANが同じRANであるかどうかを決定することができる。
ステップ407:UPFネットワーク要素は、重複排除されたダウンリンクライブメディアストリームをRANに送信する。
ステップ408:UPFネットワーク要素は、各重複排除されたダウンリンクライブメディアストリームの特性情報に対応するアドレス情報をRANにさらに送信することができる。
具体的には、可能な実施形態では、UPFネットワーク要素は、N4セッション変更情報を使用することによって、各セッションに対応するアドレス情報をSMFネットワーク要素に送信することができ、次いで、SMFネットワーク要素は、N2 SMメッセージを使用することによって、アドレス情報をRAN側に送信する。
別の可能な実施形態では、UPFネットワーク要素は、ダウンリンクライブメディアストリームデータパケットのGTP層にライブメディアストリームのアドレス情報をカプセル化し、カプセル化されたダウンリンクライブメディアストリームデータをRAN側に送信することができる。
ステップ409:ライブメディアストリームを受信した後、RANは、各UEの識別子と、アドレス情報と、ライブメディアストリームの特性情報との間のマッピング関係(表1に示される)に基づいて、対応するライブメディアストリームデータと、ライブメディアストリームに対応するアドレス情報とを、サービス提供されるUEに送信して、UEがこれらのダウンリンクライブメディアストリームデータパケットを受信し、解析できることを保証する。
以下は、前述のデータ伝送プロセスを説明するための具体的な例を提供する。
図2Bを参照すると、UE1~UE6は、同じライブストリーミングルーム内にある。UE1~UE6は全て、同じRANおよび同じUPFネットワーク要素にアクセスすると仮定される。この場合、UPFネットワーク要素は、6つのUEにそれぞれ送信される6つのダウンリンクライブメディアストリームを監視する。したがって、UPFネットワーク要素は、6つのダウンリンクライブメディアストリームの特性情報を取得することができる。6つのダウンリンクライブメディアストリームの特性情報が1に示されていると仮定される。UPFネットワーク要素は、通知情報をSMFネットワーク要素に送信し、通知情報は、6つのダウンリンクライブメディアストリームの特性情報を含む。SMFネットワーク要素は、PCFネットワーク要素を介してAF/ASに通知情報を送信する。AF/AS側は、受信された通知情報に基づいて、UE1およびUE6が同じコンテンツを有するダウンリンクライブメディアストリームに対応し、UE2およびUE3が同じコンテンツを有するダウンリンクライブメディアストリームに対応し、UE4およびUE5が同じコンテンツを有するダウンリンクライブメディアストリームに対応すると決定する。したがって、AS/AFは、複製されたダウンリンクライブメディアストリームを除去する。具体的には、図4Bに示されるように、3つのサービス品質フロー(QoSフロー)のみがAS/AFとUPFネットワーク要素との間で伝送され、それらはそれぞれ、特性情報001を搬送するダウンリンクライブメディアストリーム、特性情報002を搬送するダウンリンクライブメディアストリーム、および特性情報003を搬送するダウンリンクライブメディアストリームである。UPFネットワーク要素は、重複排除されたダウンリンクライブメディアストリームをRANに送信し、各ダウンリンクライブメディアストリームの特性情報に対応するアドレス情報をRANにさらに送信する。ライブメディアストリームを受信した後、RANは、(表1に示されるような)各UEの識別子と、アドレス情報と、ライブメディアストリームの特性情報との間のマッピング関係に基づいて、対応するライブメディアストリームデータと、ライブメディアストリームに対応するアドレス情報とを、サービス提供されるUE1~UE6に送信して、UEがこれらのダウンリンクライブメディアストリームデータパケットを受信し、解析できることを保証する。
本出願のこの実施形態では、UPFネットワーク要素は、ASとUPFネットワーク要素との間およびUPFネットワーク要素とRANとの間の複製されたメディアストリームを決定するために、各ライブメディアストリームの特性情報を監視および識別し、ASとUPFとの間およびUPFとRANとの間の重複排除伝送が実装され、それによって、バックボーンネットワークおよび伝送ネットワーク上のライブメディアストリームの負担を低減する。加えて、UPFは、制御プレーンまたはユーザプレーンを介して、ダウンリンクライブメディアストリームに対応するアドレス情報をRAN側に通知し、RANは、アドレス情報を対応するUEに通知して、重複排除伝送が実行された後にUEが依然として正常にライブメディアデータを受信および解析できることを保証する。
実施形態3
この実施形態は、ライブメディアストリーム切り替えプロセスである。実施形態1のセッション確立プロセスにおけるライブメディアストリームの特性情報の配信に基づいて、RANは、UEの切り替え要求内の特性情報に基づいて、現在伝送されているライブメディアストリーム内の特性情報を搬送するライブメディアストリームを直接決定し、ライブメディアストリームを複製し、複製されたライブメディアストリームをUEに送信することができ、その結果、迅速なメディアストリーム切り替えが実装される。
図5は、本出願の一実施形態によるセッション確立方法を示している。具体的には、この方法は以下のステップを含む。
ステップ501:UEは、切り替え要求メッセージをRANに送信し、切り替え要求メッセージは、ライブメディアストリームの特性情報を含む。
具体的には、UEは、RRCメッセージまたはアップリンクデータのPDCP層拡張で、切り替えられるように要求されたライブメディアストリームの特性情報を搬送し、ライブメディアストリームの特性情報をRAN側に送信することができる。
可能な実施形態では、切り替えられるように要求されたライブメディアストリームの特性情報は、メディアストリームパラメータ値、例えば、視野であると仮定される。第1の可能なケースでは、ステップ501を実行する前に、UEは、現在のメディアストリームパラメータ値、例えば、視野度値を取得し、メディアストリームパラメータ値に対応する特性情報をRRCメッセージまたはアップリンクデータのPDCP層拡張で搬送し、特性情報をRAN側に送信することができる。例えば、UEがVRグラスである場合、VRグラスを装着しているユーザの頭部が回転すると、VRグラスは、ユーザの現在の視野度値を取得し、現在の視野度値を搬送するRRCメッセージをRAN側に送信してよい。第2の可能なケースでは、UEがSMFネットワーク要素から初期特性情報セットを事前に受信した場合、ステップ501を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて初期特性情報セットを検索することができる。第3の可能なケースでは、UEは、事前にRANネットワーク要素から第2のアクティブ特性情報セットを受信する。この場合、ステップ501を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて第2のアクティブ特性情報セットを検索することができる。ライブメディアストリームに対応する特性情報が存在する場合、ステップ501が実行され、または、ライブメディアストリームに対応する特性情報が存在しない場合、UEは、アプリケーション層対話プロセスを介して、アプリケーションサーバに、切り替えられるべきライブメディアストリームを要求する。
別の可能な実施形態では、切り替えられるように要求されたライブメディアストリームの特性情報はインデックス値であると仮定される。例えば、視野が0度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は、0X00である。第1の可能なケースでは、UEが事前にSMFネットワーク要素から初期特性情報セットを受信した場合、ステップ501を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報(例えば、0X00)を求めて初期特性情報セットを最初に検索することができる。第2の可能なケースでは、UEは、RANネットワーク要素から第2のアクティブ特性情報セットを受信する。この場合、ステップ501を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて第2のアクティブ特性情報セットを検索することができる。ライブメディアストリームに対応する特性情報が存在する場合、ステップ501が実行され、または、ライブメディアストリームに対応する特性情報が存在しない場合、UEは、アプリケーション層対話プロセスを介して、アプリケーションサーバに、切り替えられるべきライブメディアストリームを要求する。
可能な実施形態では、UEがメディアストリームパラメータの動的適応ネットワーク調整の技術をサポートするとき、端末は、ネットワーク状態に基づいて、調整されたライブメディアストリームパラメータをRANに送信する。例えば、ライブストリーミングアプリケーションクライアント上でユーザによって設定されたストリーミングメディアデータの解像度が適応型であるとき、端末は、ストリーミングメディアデータのパケット損失率およびネットワークスループットなどのネットワーク状態情報に基づいてストリーミングメディアデータのビットレートを動的に調整し、次いで、UEは、ストリーミングメディアデータの調整されたビットレートに対応する特性情報をRANに送信する。
ケース1
ステップ502:UEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在するかどうかを決定し、特性情報が存在する場合、特性情報を搬送するライブメディアストリームを複製する。
ステップ503:RANは、複製されたライブメディアストリームをUEに送信する。加えて、このステップの前に、RANは、特性情報とアドレス情報との間のマッピング関係に基づいて、特性情報に対応する第1のアドレス情報(例えば、IPアドレスおよびポート番号)をさらに決定し、第1のアドレス情報をUEに送信することができる。
具体的には、RANは、特性情報を搬送するライブメディアデータフローをUEのQoSフロー、具体的には、UEのQoSフローに対応するDRBに転送し、QoSフローに送信され、元のインターフェース上の元の特性情報を搬送するメディアストリームデータを破棄する。
ステップ504:UEは、RANからライブメディアストリームデータおよび第1のアドレス情報を受信し、UEは、第1のアドレス情報と最初に使用された第2のアドレス情報との間のバインディング関係を確立して、バインディング関係に基づいて受信されたライブメディアストリームを解析および適用する。
具体的には、UEは、受信されたIP/ポート情報と元のIP/ポート情報との間のバインディング関係を確立し、ライブメディアストリームデータパケットを受信した後、バインディング関係に基づいてデータパケットを解析し、受信されたIP/ポート内のメディアストリームデータを元のIP/ポートに対応する上位層アプリケーションに伝送する。
ケース2
ステップ505:UEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在しないと決定し、RANは、要求応答メッセージをUEに送信し、要求応答メッセージは、切り替えが失敗したことをUEに通知するためのものである。
例えば、UE側は、RANから第2のアクティブ特性情報セットを受信せず、RANは、第2のアクティブ特性情報セット内の特性情報を発見しない。あるいは、RANは、特性情報を含むライブメディアストリームが現在存在していないと決定する。この場合、RANは、要求応答メッセージをUEに送信する。
ステップ506:UEは、アプリケーション層相互作用プロセスを介して、アプリケーションサーバから、切り替えられるべきライブメディアストリームを要求する。
言い換えると、UEは、既存のアプリケーション層相互作用プロセスを介して、アプリケーションサーバからライブメディアストリームを要求する。
ケース3
ステップ507:RAN側がUEから切り替え要求を受信した後、RAN側が、特性情報が第2のアクティブ特性情報セット内に存在しないと決定した場合、RAN側は、UEの切り替え要求内にある特性情報をアップリンクユーザプレーンデータ内で搬送し、アップリンクユーザプレーンデータをUPFネットワーク要素に送信する。
具体的には、RANは、アップリンクデータのGTP層においてUEの切り替え要求内にある特性情報を搬送し、次いで、アップリンクデータをUPFネットワーク要素に送信することができる。
ステップ508:UPFネットワーク要素がRAN側からアップリンクユーザプレーンデータを受信した後、UPFは、ユーザプレーンデータのIP/トランスポート/アプリケーション層(全ての層が可能であり、これは特に限定されない)において特性情報をカプセル化し、次いで、アップリンクユーザプレーンデータをアプリケーションサーバ側に送信する。
ステップ509:特性情報を搬送するアップリンクユーザプレーンデータを受信した後、AS側は、UEに送信されるライブメディアストリームを調整し、次いで、特性情報を搬送し、特性情報に対応するダウンリンクライブメディアストリームをUEに送信する。
ケース4
ステップ510:RAN側がUEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セットに存在しないと決定する。この場合、RAN側は、UEの切り替え要求内の特性情報を含むN2 SMメッセージをSMFネットワーク要素に送信する。
ステップ511:SMFネットワーク要素は、RAN側からN2 SMメッセージを受信した後、セッション管理ポリシー関連付け修正手順を開始し、UEの切り替え要求内の特性情報をPCFに送信する。
ステップ512:PCFは、能力公開メッセージを使用することによって(例えば、Npcf_EventExposure_Notifyサービスを使用することによって)、UEの切り替え要求内の特性情報をアプリケーションサーバ側に送信する。
ステップ513:制御プレーン能力公開メッセージを受信した後、アプリケーションサーバ側は、UEに送信されたQoSフローを調整し、次いで、特性情報を搬送するダウンリンクライブメディアストリームをUEに送信する。
以下は、前述のメディアストリーム切り替えプロセスを説明するための具体的な例を提供する。
図2Aを参照すると、UE1~UE6はVRグラスであると仮定される。サッカーの試合のライブストリーミングルームには6人の視聴者がいる。ライブストリーミングルームで再生されるサッカーの試合のビデオは、360度パノラマVRビデオである。UE1を使用する視聴者の頭部が回転すると、UE1の視野が変化し、視野が第1の視野から第2の視野に変化すると仮定される。UE1が第2のアクティブ特性情報セットを記憶する場合、UE1は、第2の視野のライブメディアストリームに対応するインデックス値002を求めて初期特性情報セットを最初に検索し、次いで、インデックス値002を求めて第2のアクティブ特性情報セットを検索する。インデックス値002が存在する場合、UE1は、切り替え要求をRANに送信し、切り替え要求は、インデックス値002を含み、切り替え要求は、第2の視野のライブメディアストリームを要求するためのものである。切り替え要求を受信した後、RANは、第2のアクティブ特性情報セットを最初に検索して、インデックス値002が存在するかどうかを決定する。第2のアクティブ特性情報セットが002を含むと仮定される。この場合、RANは、インデックス値002を搬送するライブメディアストリームを複製し、複製されたライブメディアストリームをUE1に送信し、元のインターフェース上でUE1に送信されたライブメディアストリームデータパケットを破棄する。本方法によれば、UE1は、第2の視野に対応するダウンリンクライブメディアストリームをRANから適時に取得して、メディアストリーム切り替え遅延を効果的に低減することができることが知見され得る。
本出願のこの実施形態において、UPFは、サービス範囲内の端末のライブメディアストリームを監視することができ、RANはまた、RANカバレッジ内のライブメディアストリームにアクセスするための第2のアクティブ特性情報セットと、アクセスされているライブメディアストリームと、メディアストリームに対応するアドレス情報との間のマッピング関係を確立する。したがって、UE側がライブメディアストリームに切り替えることを要求するとき、RANは、ユーザのライブメディア視聴体験を保証するために、UEの切り替え要求メッセージ内のローカルマッピング関係および特性情報に基づいて、ライブメディアストリームに適時に切り替えて配信することができる。
実施形態4
本出願のこの実施形態は、ライブメディアストリーム切り替えプロセスである。実施形態1のセッション確立プロセスにおけるライブメディアストリームの特性情報の配信に基づいて、UPFネットワーク要素は、UEの切り替え要求内の特性情報に基づいて、現在伝送されているライブメディアストリーム内の特性情報を搬送するライブメディアストリームを直接決定し、ライブメディアストリームを複製し、複製されたライブメディアストリームをUEに送信することができ、その結果、迅速なメディアストリーム切り替えが実装される。
図6Aは、本出願の一実施形態によるライブメディアストリーム切り替え方法を示している。具体的には、この方法は以下のステップを含む。
ステップ601:UEは、切り替え要求メッセージをRANに送信し、切り替え要求メッセージは、ライブメディアストリームの特性情報を含む。
具体的には、UEは、RRCメッセージまたはアップリンクデータのPDCP層において、切り替えられることを要求されたライブメディアストリームの特性情報を搬送し、ライブメディアストリームの特性情報をRAN側に送信することができる。
可能な実施形態では、切り替えられるように要求されたライブメディアストリームの特性情報は、メディアストリームパラメータ値、例えば、視野であると仮定される。第1の可能なケースでは、ステップ601を実行する前に、UEは、現在のメディアストリームパラメータ値、例えば、視野度値を取得し、RRCメッセージまたはアップリンクデータのPDCP層拡張でメディアストリームパラメータ値を搬送し、メディアストリームパラメータ値をRAN側に送信してもよい。例えば、UEがVRグラスである場合、VRグラスを装着しているユーザの頭部が回転すると、VRグラスは、ユーザの現在の視野度値を取得し、現在の視野度値を搬送するRRCメッセージをRAN側に送信してよい。第2の可能なケースでは、UEがSMFネットワーク要素から初期特性情報セットを事前に受信した場合、ステップ601を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて初期特性情報セットを検索することができる。第3の可能なケースでは、UEは、事前にRANネットワーク要素またはアプリケーションサーバから第2のアクティブ特性情報セットを受信する。この場合、ステップ601を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて第2のアクティブ特性情報セットを検索することができる。ライブメディアストリームに対応する特性情報が存在する場合、ステップ601が実行され、または、ライブメディアストリームに対応する特性情報が存在しない場合、UEは、アプリケーション層対話プロセスを介して、アプリケーションサーバに、切り替えられるべきライブメディアストリームを要求する。
具体的には、UE1は、以下のステップを通じてアプリケーションサーバから第2のアクティブ特性情報セットを取得することができる。
ステップa:UEに対応するライブメディアストリームが存在することを検出した後に、UPFネットワーク要素が、N4セッション報告手順を介して、UEに対応するライブメディアストリームが存在することをSMFに通知するための指示情報を送信する。
ステップb:SMFは、セッション管理ポリシー管理修正手順を介してPCF側に通知情報を送信し、通知情報は、UPFの識別情報およびUEの識別情報を含み得る。
ステップc:PCFは、能力エクスポージャ情報Npcf_EventExposure_Notifyメッセージを使用することによって、指示情報をAF/AS側に通知するか、またはNpcf_EventExposure_Notifyメッセージを使用することによって、通知情報をNEFに通知し、次いで、NEFは、Nnef_EventExposure_Notifyメッセージを使用することによって、通知情報をAF/AS側に通知する。
ステップd:コアネットワークから通知情報を受信した後、ASは、UPFに対応する第1のアクティブ特性情報セットを知ることができる。
代替的に、ASは、UPFから第1のアクティブ特性情報セットを受信してもよい。
ステップe:AS/AFは、アプリケーション層情報を使用することによって、第1のアクティブ特性情報セットをUE側に送信する。
別の可能な実施形態では、切り替えられるように要求されたライブメディアストリームの特性情報はインデックス値であると仮定される。例えば、視野が0度であるとき、アプリケーションサーバによってライブメディアストリームデータパケット内にカプセル化されたインデックス値は、0X00である。第1の可能なケースでは、UEが事前にSMFネットワーク要素から初期特性情報セットを受信した場合、ステップ601を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報(例えば、0X00)を求めて初期特性情報セットを最初に検索することができる。第2の可能なケースでは、UEは、事前にRANネットワーク要素またはアプリケーションサーバから第2のアクティブ特性情報セットを受信する。この場合、ステップ601を実行する前に、UEは、切り替えられるように要求されたライブメディアストリームに対応する特性情報を求めて第2のアクティブ特性情報セットを検索することができる。ライブメディアストリームに対応する特性情報が存在する場合、ステップ601が実行され、または、ライブメディアストリームに対応する特性情報が存在しない場合、UEは、アプリケーション層対話プロセスを介して、アプリケーションサーバに、切り替えられるべきライブメディアストリームを要求する。
可能な実施形態では、UEがメディアストリームパラメータの動的適応ネットワーク調整の技術をサポートするとき、端末は、ネットワーク状態に基づいて、調整されたライブメディアストリームパラメータに対応する特性情報をRANに送信する。例えば、ライブストリーミングアプリケーションクライアント上でユーザによって設定されたストリーミングメディアデータの解像度が適応型であるとき、端末は、ストリーミングメディアデータのパケット損失率およびネットワークスループットなどのネットワーク状態情報に基づいてストリーミングメディアデータのビットレートを動的に調整し、次いで、UEは、ストリーミングメディアデータの調整されたビットレートに対応する特性情報をRANに送信する。
ケース1
ステップ602:UEから切り替え要求を受信した後、RAN側は、切り替え要求内の特性情報をUPFネットワーク要素に転送する。
具体的には、RANは、RRCメッセージまたはPDCP層拡張ビットを有するアップリンクデータパケットをUEから受信し、RRCメッセージは、特性情報を搬送し、またはアップリンクデータパケットのPDCP層は、特性情報を搬送する。RANは、アップリンクデータパケットのGTP-U層において特性情報をカプセル化し、次いで、カプセル化されたアップリンクデータパケットをUPFネットワーク要素に送信する。
ステップ603:アップリンクデータパケットを受信した後、UPFは、アップリンクデータパケット内の特性情報が第1のアクティブ特性情報セット内にあるかどうかを決定し、特性情報が第1のアクティブ特性情報セット内にある場合、特性情報を搬送するライブメディアデータフローを複製する。
ステップ604:UPFは、複製されたライブメディアデータフローを対応するUEの対応するQoSフローに転送し、QoSフロー内にあり、元のN6インターフェースを介してUEに送信され、元の特性情報を搬送するメディアストリームデータパケットを破棄する。
可能な実施形態では、UPFは、ライブメディアストリーム内のアドレス情報を修正し、具体的には、第1のライブメディアストリームのデータパケット内の元の第2のアドレス情報を第1のアドレス情報で置き換え、次いで、ライブメディアストリームの修正されたデータパケットをUEに送信する。
別の可能な実施形態では、UPFは、ライブメディアストリームデータパケット内の元の宛先アドレス情報をUEのアドレス情報に代替的に変更して、UEがデータパケットを正しく受信できることを保証することができる。
ケース2
ステップ605:UEから切り替え要求を受信した後、UPF側は、特性情報が第1のアクティブ特性情報セット内に存在しないと決定し、UPFは、RANを介してUEに要求応答メッセージを送信し、要求応答メッセージは、切り替えが失敗したことをUEに通知するためのものである。
例えば、UPFは、第1のアクティブ特性情報セット内の特性情報を発見しない。あるいは、UPFは、特性情報を含むライブメディアストリームが現在存在しないと決定する。この場合、UPFは、要求応答メッセージをUEに送信する。
ステップ606:UEは、アプリケーション層相互作用プロセスを介して、アプリケーションサーバから、切り替えられるべきライブメディアストリームを要求する。
言い換えると、UEは、既存のアプリケーション層相互作用プロセスを介して、アプリケーションサーバからライブメディアストリームを要求する。
ケース3
ステップ607:特性情報を受信した後、UPFは、特性情報が第1のアクティブ特性情報セット内に存在しないと決定し、次いで、UPFは、アップリンクユーザプレーンデータのIP/トランスポート/アプリケーション層(これは特に限定されない)において特性情報をカプセル化し、カプセル化されたアップリンクデータをAF/AS側に送信する。
ステップ608:特性情報を搬送するアップリンクユーザプレーンデータを受信した後、AF/AS側は、UEに送信されるライブメディアデータフローを調整し、次いで、特性情報を搬送し、特性情報に対応するダウンリンクライブメディアストリームをUEに送信する。
以下は、前述のメディアストリーム切り替えプロセスを説明するための具体的な例を提供する。
UE1~UE6はVRメガネであると仮定される。サッカーの試合のライブストリーミングルームには6人の視聴者がいる。ライブストリーミングルームで再生されるサッカーの試合のビデオは、360度パノラマVRビデオである。図6Bに示されるように、UE1およびUE2はRAN1にアクセスし、UE2からUE6はRAN2にアクセスし、UE1からUE6は全て同じUPFネットワーク要素にアクセスする。UE1を使用する視聴者の頭部が回転すると、UE1の視野が変化し、視野が第1の視野から第2の視野に変化すると仮定される。UE1が第2のアクティブ特性情報セットを記憶する場合、UE1は、第2の視野のライブメディアストリームに対応するインデックス値002を求めて初期特性情報セットを最初に検索する。UE1は、切り替え要求をRAN1に送信し、切り替え要求は、インデックス値002を含み、切り替え要求は、第2の視野のライブメディアストリームを要求するためのものである。切り替え要求を受信した後、RAN1は、GTP指示を使用することによって要求をUPFネットワーク要素に通知し、UPFネットワーク要素は、ライブメディアストリームを調整する。具体的には、UPFネットワーク要素は第1のアクティブ特性情報セット内のインデックス値002を、最初に検索してもよい。第1のアクティブ特性情報セットが002を含むと仮定される。この場合、UPFは、インデックス値002を搬送するライブメディアストリームを複製し、ライブメディアストリームデータパケット内のアドレス情報を修正し、修正されたライブメディアストリームをRANに送信する。RANは、修正されたライブメディアストリームをUE1に転送し、元のインターフェース上でUE1に送信されたライブメディアストリームデータパケットを破棄する。本方法によれば、UE1は、RAN側から第2の視野に対応するダウンリンクライブメディアストリームを適時に受信および解析して、メディアストリーム切り替え遅延を効果的に低減することができることが知見され得る。
本出願のこの実施形態では、UPF側は、ユーザと、アクセスされているライブメディアストリームと、特性情報との間のマッピング関係を確立する。UE側がライブメディアストリーム切り替え要求を開始すると、UPFは、メディアストリームを切り替えて配信し、要求内の特性情報およびマッピング関係に基づいてIP/ポート情報を修正する。このようにして、ライブメディアストリーム切り替えが実装され、メディアストリーム切り替え遅延が効果的に低減される。
実施形態5
本出願のこの実施形態は、ライブメディアストリーム切り替えプロセスである。実施形態1のセッション確立プロセスにおけるライブメディアストリームの特性情報の配信に基づいて、RANは、UEの切り替え要求内の特性情報に基づいて、現在伝送されているライブメディアストリーム内の特性情報を搬送するライブメディアストリームを直接決定し、ライブメディアストリームを複製し、複製されたライブメディアストリームをUEに送信することができ、その結果、迅速なライブメディアストリーム切り替えが実装される。RANが、UEの切り替え要求内の特性情報に基づいて、特性情報を搬送するライブメディアストリームが現在伝送されているライブメディアストリーム内に存在しないと決定したとき、RANは、特性情報をUPFネットワーク要素に送信することができる。次いで、UPFネットワーク要素は、UEの切り替え要求内の特性情報に基づいて、現在伝送されているライブメディアストリーム内の特性情報を搬送するライブメディアストリームを直接決定し、ライブメディアストリームを複製し、複製されたライブメディアストリームをUEに送信することができ、その結果、迅速なメディアストリーム切り替えが実装される。
図7Aおよび図7Bは、本出願の一実施形態によるライブメディアストリーム切り替え方法を示している。具体的には、この方法は以下のステップを含む。
ステップ701:UEは、切り替え要求メッセージをRANに送信し、切り替え要求メッセージは、ライブメディアストリームの特性情報を含む。
具体的には、UEは、RRCメッセージまたはアップリンクデータのPDCP層拡張で、切り替えられるように要求されたライブメディアストリームの特性情報を搬送し、ライブメディアストリームの特性情報をRAN側に送信することができる。ライブメディアストリームの特性情報の具体的な内容、およびUEが送信前にライブメディアストリームの特性情報を決定する方法のプロセスについては、ステップ501を参照されたい。詳細は、ここでは再び説明されない。
ケース1
ステップ702:UEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在するかどうかを決定し、特性情報が存在する場合、特性情報を搬送するライブメディアストリームを複製する。
ステップ703:RANは、複製されたライブメディアストリームをUEに送信する。加えて、このステップの前に、RANは、特性情報とアドレス情報との間のマッピング関係に基づいて、特性情報に対応する第1のアドレス情報(例えば、IPアドレスおよびポート番号)をさらに決定し、第1のアドレス情報をUEに送信することができる。
具体的には、RANは、特性情報を搬送するライブメディアデータフローをUEのQoSフロー、具体的には、UEのQoSフローに対応するDRBに転送し、元のインターフェース上でQoSフローに送信されたデータを破棄する。
ステップ704:UEは、RANからライブメディアストリームデータおよび第1のアドレス情報を受信し、UEは、第1のアドレス情報と最初に使用された第2のアドレス情報との間のバインディング関係を確立して、バインディング関係に基づいて受信されたライブメディアストリームを解析および適用する。
具体的には、UEは、受信されたIP/ポート情報と元のIP/ポート情報との間のバインディング関係を確立し、ライブメディアストリームデータパケットを受信した後、バインディング関係に基づいてデータパケットを解析し、受信されたIP/ポート内のメディアストリームデータを元のIP/ポートに対応する上位層アプリケーションに伝送する。
ケース2
ステップ705:RAN側がUEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在しないと決定し、切り替え要求内の特性情報をUPFネットワーク要素に転送する。
具体的には、RANは、UEからRRCメッセージまたはアップリンクデータパケットを受信し、RRCメッセージは特性情報を搬送し、またはアップリンクデータパケットのPDCP層拡張は特性情報を搬送する。RANは、アップリンクデータパケットのGTP層において特性情報をカプセル化し、次いで、カプセル化されたアップリンクデータパケットをUPFネットワーク要素に送信する。
ステップ706:対応するアップリンクデータパケットを受信した後、UPFは、GTP層特性情報に基づいて、特性情報が第1のアクティブ特性情報セット内にあるかどうかを決定し、特性情報が第1のアクティブ特性情報セット内にある場合、特性情報を搬送するライブメディアデータフローを複製する。
ステップ707:UPFネットワーク要素は、複製されたライブメディアデータフローを対応するUEのQoSフローに転送し、QoSフロー内にあり、元のN6インターフェースを介してUEに送信され、元の特性情報を搬送するメディアストリームデータパケットを破棄する。
可能な実施形態では、UPFは、ライブメディアストリーム内のアドレス情報を修正し、具体的には、第1のライブメディアストリームのデータパケット内の元の第2のアドレス情報を第1のアドレス情報で置き換え、次いで、ライブメディアストリームの修正されたデータパケットをUEに送信する。
別の可能な実施形態では、UPFは、ライブメディアストリームデータパケット内の元の宛先アドレス情報をUEのアドレス情報に代替的に変更して、UEがデータパケットを正しく受信できることを保証することができる。
ケース3
ステップ708:RAN側がUEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在しないと決定し、切り替え要求内の特性情報をUPFネットワーク要素に転送する。
具体的には、RANは、RRCメッセージまたはアップリンクデータパケットをUEから受信し、RRCメッセージは特性情報を搬送し、またはアップリンクデータパケットのPDCP層は特性情報を搬送する。RANは、アップリンクデータパケットのGTP層において特性情報をカプセル化し、次いで、カプセル化されたアップリンクデータパケットをUPFネットワーク要素に送信する。
ステップ709:UEから切り替え要求を受信した後、UPF側は、特性情報が第1のアクティブ特性情報セット内に存在しないと決定し、UPFは、RANを介してUEに要求応答メッセージを送信し、要求応答メッセージは、切り替えが失敗したことをUEに通知するためのものである。
例えば、UPFは、第1のアクティブ特性情報セット内の特性情報を発見しない。あるいは、UPFは、特性情報を含むライブメディアストリームが現在存在しないと決定する。この場合、UPFは、要求応答メッセージをUEに送信する。
ステップ710:UEは、アプリケーション層相互作用プロセスを介して、アプリケーションサーバから切り替え対象のライブメディアストリームを要求する。
言い換えると、UEは、既存のアプリケーション層相互作用プロセスを介して、アプリケーションサーバからライブメディアストリームを要求する。
ケース4
ステップ711:RAN側がUEから切り替え要求を受信した後、RAN側は、特性情報が第2のアクティブ特性情報セット内に存在しないと決定し、切り替え要求内の特性情報をUPFネットワーク要素に転送する。
具体的には、RANは、RRCメッセージまたはアップリンクデータパケットをUEから受信し、RRCメッセージは特性情報を搬送し、またはアップリンクデータパケットのPDCP層は特性情報を搬送する。RANは、アップリンクデータパケットのGTP層において特性情報をカプセル化し、次いで、カプセル化されたアップリンクデータパケットをUPFネットワーク要素に送信する。
ステップ712:特性情報を受信した後、UPFは、特性情報が第1のアクティブ特性情報セット内に存在しないと決定し、次いで、UPFは、アップリンクユーザプレーンデータのIP/トランスポート/アプリケーション層(これは特に限定されない)において特性情報をカプセル化し、カプセル化されたアップリンクデータをAF/AS側に送信する。
ステップ713:特性情報を搬送するアップリンクユーザプレーンデータを受信した後、AF/AS側は、UEに送信されるライブメディアストリームを調整し、次いで、特性情報を搬送し、特性情報に対応するダウンリンクライブメディアストリームをUEに送信する。
以下は、前述のメディアストリーム切り替えプロセスを説明するための具体的な例を提供する。
UE1~UE6はVRメガネであると仮定される。サッカーの試合のライブストリーミングルームには6人の視聴者がいる。ライブストリーミングルームで再生されるサッカーの試合のビデオは、360度パノラマVRビデオである。図6Bに示されるように、UE1およびUE2はRAN1にアクセスし、UE3からUE6はRAN2にアクセスし、UE1からUE6は全て同じUPFネットワーク要素にアクセスする。UE1を使用する視聴者の頭部が回転すると、UE1の視野が変化し、視野が第1の視野から第2の視野に変化すると仮定される。UE1が第2のアクティブ特性情報セットを記憶する場合、UE1は、第2の視野のライブメディアストリームに対応するインデックス値002を求めて初期特性情報セットを最初に検索する。UE1は、切り替え要求をRAN1に送信し、切り替え要求は、インデックス値002を含み、切り替え要求は、第2の視野のライブメディアストリームを要求するためのものである。切り替え要求を受信した後、RANは、第2のアクティブ特性情報セットを最初に検索して、インデックス値002が存在するかどうかを決定する。第2のアクティブ特性情報セットが002を含むと仮定される。この場合、RANは、インデックス値002を搬送するライブメディアストリームを複製し、複製されたライブメディアストリームをUE1に送信し、元のインターフェース上でUE1に送信されたライブメディアストリームデータパケットを破棄する。RAN1が、インデックス値002が第2のアクティブ特性情報セット内に存在しないことを発見した場合、RAN1は、GTP指示を使用することによってUPFネットワーク要素に要求を通知し、UPFネットワーク要素は、ライブメディアストリームを調整する。具体的には、UPFネットワーク要素は第1のアクティブ特性情報セット内のインデックス値002を、最初に検索してもよい。第1のアクティブ特性情報セットが002を含むと仮定される。この場合、UPFは、インデックス値002を搬送するライブメディアストリームを複製し、ライブメディアストリームデータパケット内のアドレス情報を修正し、修正されたライブメディアストリームをRANに送信する。RANは、修正されたライブメディアストリームをUE1に転送し、元のインターフェース上でUE1に送信されたライブメディアストリームデータパケットを破棄する。本方法によれば、UE1は、RAN側から第2の視野に対応するダウンリンクライブメディアストリームを適時に受信および解析して、メディアストリーム切り替え遅延を効果的に低減することができることが知見され得る。
本出願のこの実施形態では、RANおよびUPF側は、ユーザと、アクセスされているライブメディアストリームと、特性情報との間のマッピング関係を確立する。UE側がライブメディアストリーム切り替え要求を開始すると、RANおよび/またはUPFは、メディアストリームを切り替えて配信し、要求内の特性情報およびマッピング関係に基づいてIP/ポート情報を修正する。このようにして、ライブメディアストリーム切り替えが実装され、メディアストリーム切り替え遅延が効果的に低減される。
実施形態1から実施形態5について、以下が留意されるべきである:(1)実施形態2および実施形態3は、異なるシナリオで別々に実装されてよく、または同じシナリオで組み合わせて実装されてよい。実施形態2および実施形態4は、異なるシナリオで別々に実装されてもよく、または同じシナリオで組み合わせて実装されてもよい。実施形態2および実施形態5は、異なるシナリオで別々に実装されてもよく、または同じシナリオで組み合わせて実装されてもよい。これは特に限定されない。
(2)本出願の実施形態において説明されるフローチャートにおけるステップ番号は、実行手順の例にすぎず、ステップの実行順序に対する限定を構成するものではない。本出願の実施形態では、互いに時間シーケンス依存関係を有さないステップ間に厳密な実行シーケンスは存在しない。
実施形態1から実施形態5に関して、UPFによって実行され得る前述のアクションは、エッジアプリケーションサーバによって代替として実行され得、エッジアプリケーションサーバは、伝送ネットワーク上の応答時間および負担を低減するために、ユーザ側のより近くに配備されるアプリケーションサーバとして理解され得ることにさらに留意されたい。したがって、前述の実施形態におけるアプリケーションサーバは、中央アプリケーションサーバであってよい。実施形態1から実施形態5において、メディアストリーム切り替え方法を実装するために、UPFはエッジアプリケーションサーバと置き換えられてよく、アプリケーションサーバは中央アプリケーションサーバと置き換えられてよいことも理解され得る。
上記は、ネットワークデバイスと端末デバイスとの間の相互作用の観点から、本出願の実施形態において提供される解決策を主に説明している。前述の機能を実装するために、ネットワークデバイスまたは端末デバイスは、各機能を実行するための対応するハードウェア構造および/またはソフトウェアモジュールを含み得ることが理解され得る。当業者は、本明細書で開示される実施形態で説明された例のユニットおよびアルゴリズムステップと、組み合わせて、本出願の実施形態がハードウェアまたはハードウェアとコンピュータソフトウェアの組み合わせによって実装され得ることを容易に認識すべきである。機能がハードウェアによって実行されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的解決策の特定の用途および設計制約に依存する。当業者は、特定のアプリケーションごとに説明された機能を実装するために異なる方法を使用し得るが、実装形態が本出願の範囲を超えると考えられるべきではない。
本出願の実施形態では、機能ユニットへの分割は、前述の方法例に基づいて、端末デバイスおよびネットワークデバイス上で実行され得る。例えば、各機能ユニットへの分割は、各対応する機能に基づいてもよく、または2つ以上の機能が1つのユニットに統合されてもよい。統合されたユニットは、ハードウェアの形態で実装されてよく、またはソフトウェア機能ユニットの形態で実装されてよい。
統合されたユニットが使用されるとき、図8は、本出願の一実施形態による装置の可能な例示的なブロック図である。図8に示されるように、装置800は、処理ユニット802および通信ユニット803を含むことができる。処理ユニット802は、装置800の動作を制御および管理するように構成される。通信ユニット803は、装置800と別のデバイスとの間の通信をサポートするように構成される。任意選択で、通信ユニット803は、トランシーバユニットとも称され、受信動作および送信動作を実行するようにそれぞれ構成された受信ユニットおよび/または送信ユニットを含むことができる。装置800は、装置800のプログラムコードおよび/またはデータを記憶するように構成された記憶ユニット801をさらに含むことができる。
装置800は、前述の実施形態のうちのいずれか1つにおける端末デバイスであってもよく、または端末デバイス内に配置されたチップであってもよい。処理ユニット802は、前述の方法例における端末デバイスの動作を実行する際に装置800をサポートすることができる。代替として、処理ユニット802は、方法実施例における端末デバイスの内部動作を主に行い、通信ユニット803は、装置800とネットワークデバイスとの間の通信をサポートしてもよい。
装置800は、前述の実施形態のうちのいずれか1つにおけるネットワークデバイスであってよく、またはネットワークデバイス内に配置されたチップであってよい。ネットワークデバイスは、前述のアクセスネットワークデバイス、ユーザプレーン機能ネットワーク要素、セッション管理機能ネットワーク要素、アプリケーションサーバなどを指すことがある。処理ユニット802は、前述の方法の例におけるネットワークデバイスの動作を実行する際に装置800をサポートすることができる。代替として、処理ユニット802は、方法実施例におけるネットワークデバイスの内部動作を主に行い、通信ユニット803は、装置800とネットワークデバイスとの間の通信をサポートしてもよい。例えば、処理ユニット802は、方法の例におけるネットワークデバイスの内部動作を実行するように構成されてもよく、通信ユニット803は、装置800と端末デバイスとの間の通信をサポートするように構成されてもよい。
装置内のユニットの分割は、単に論理的な機能の分割であることを理解されたい。実際の実装形態では、ユニットの全てまたは一部は、1つの物理的エンティティに統合されてもよく、または物理的に分離されてもよい。加えて、装置内の全てのユニットは、処理要素がソフトウェアを呼び出す形態で実装されてもよく、またはハードウェアの形態で実装されてもよく、あるいは、一部のユニットは、処理要素がソフトウェアを呼び出す形態で実装されてもよく、一部のユニットはハードウェアの形態で実装される。例えば、ユニットは、別個に配置された処理要素であってもよく、または実装形態のために装置のチップに統合されてもよい。加えて、ユニットは、プログラム形式でメモリに記憶されてよく、ユニットの機能を実行するために装置の処理要素によって呼び出される。加えて、かかるユニットは、一緒に統合されてもよく、または個々に実装されてもよい。本明細書における処理要素は、プロセッサと称されることもあり、信号処理能力を有する集積回路であり得る。実装形態のプロセスでは、前述の方法のステップまたは前述のユニットは、処理要素内のハードウェア集積論理回路を使用することによって実装されてもよく、または処理要素がソフトウェアを呼び出す形態で実装されてもよい。
一例では、装置内の前述のユニットのうちのいずれか1つは、前述の方法を実装するように構成された1つ以上の集積回路、例えば、1つ以上の特定用途向け集積回路(Application Specific Integrated Circuit、ASIC)、1つ以上のマイクロプロセッサ(digital signal processor、DSP)、1つ以上のフィールドプログラマブルゲートアレイ(Field Programmable Gate Array、FPGA)、またはこれらの集積回路形態のうちの少なくとも2つの組み合わせであってもよい。別の例では、装置内のユニットが、処理要素がプログラムをスケジューリングする形態で実装され得るとき、処理要素は、プロセッサ、例えば、汎用中央処理装置(central processing unit、CPU)、またはプログラムを呼び出すことができる別のプロセッサであり得る。さらに別の例では、ユニットは、システムオンチップ(system-on-a-chip、SOC)の形態で統合され、実装されてよい。
受信するように構成された前述のユニットは、装置のインターフェース回路であり、別の装置から信号を受信するように構成される。例えば、装置がチップの方式で実装されるとき、受信ユニットは、チップのものであり、別のチップまたは装置から信号を受信するように構成されたインターフェース回路である。送信するように構成された前述のユニットは、装置のインターフェース回路であり、信号を別の装置に送信するように構成される。例えば、装置がチップの方式で実装されるとき、送信ユニットは、チップのものであり、別のチップまたは装置に信号を送信するように構成されたインターフェース回路である。
図9は、本出願の一実施形態による端末デバイスの構造の概略図である。端末デバイスは、前述の実施形態における端末デバイスであってよく、前述の実施形態における端末デバイスの動作を実装するように構成されてよい。図9に示されるように、端末デバイスは、アンテナ910と、高周波部920と、信号処理部930とを有する。アンテナ910は、高周波部920に接続されている。ダウンリンク方向では、高周波部920は、アンテナ910を介して、ネットワークデバイスによって送信された情報を受信し、処理のために信号処理部930に、ネットワークデバイスによって送信された情報を送信する。アップリンク方向では、信号処理部930は、端末デバイスの情報を処理し、その情報を高周波部920に送信する。高周波部920は、端末デバイスの情報を処理し、次いで、処理された情報を、アンテナ910を介してネットワークデバイスに送信する。
信号処理部930は、各通信プロトコル層でデータ処理を実装するように構成されたモデムサブシステムを含むことができ、端末デバイスのオペレーティングシステムおよびアプリケーション層を処理するように構成された中央処理サブシステムをさらに含むことができる。
モデムサブシステムは、1つ以上の処理要素931を含むことができ、例えば、1つの主制御CPUおよび別の集積回路を含むことができる。加えて、モデムサブシステムは、記憶要素932およびインターフェース回路933をさらに含み得る。記憶要素932は、データおよびプログラムを記憶するように構成される。しかしながら、前述の方法において端末デバイスによって実行される方法を実行するために使用されるプログラムは、記憶要素932に記憶されなくてもよく、モデムサブシステムの外部のメモリに記憶され、使用のためにモデムサブシステムによってロードされる。インターフェース回路933は、別のサブシステムと通信するように構成される。
モデムサブシステムは、チップを使用することによって実装され得る。チップは、少なくとも1つの処理要素とインターフェース回路とを含む。処理要素は、端末デバイスによって実行される任意の方法のステップを実行するように構成される。インターフェース回路は、他の装置と通信するように構成される。一実施形態では、前述の方法のステップを実装するための端末デバイス内のユニットは、処理要素によってスケジューリングされるプログラムによって実装されてもよい。例えば、端末デバイスで使用される装置は、処理要素および記憶要素を含む。処理要素は、前述の方法の実施形態において端末デバイスによって実行される方法を実行するために、記憶要素に記憶されたプログラムを呼び出す。記憶要素は、処理要素と同じチップ上に配置された記憶要素、すなわちオンチップ記憶要素であってもよい。
別の実装形態では、前述の方法において端末デバイスによって実行される方法を実行するために使用されるプログラムは、処理要素とは異なるチップ上に位置される記憶要素、すなわち、オフチップ記憶要素内にあってもよい。この場合、処理要素は、前述の方法の実施形態において端末デバイスによって実行される方法を呼び出して実行するために、オフチップ記憶要素からオンチップ記憶要素にプログラムを呼び出すかまたはロードする。
さらに別の実装形態では、前述の方法におけるステップを実装するための端末デバイス内のユニットは、1つ以上の処理要素として構成され得る。処理要素はモデムサブシステム内に配置される。本明細書の処理要素は、集積回路、例えば、1つ以上のASIC、1つ以上のDSP、1つ以上のFPGA、または集積回路のタイプの組み合わせであってよい。これらの集積回路は、一緒に統合されてチップを形成してもよい。
前述の方法におけるステップを実装するための端末デバイス内のユニットは、一緒に統合され、SOCの形態で実装されてもよい。SOCチップは、前述の方法を実装するように構成される。少なくとも1つの処理要素および記憶要素がチップに統合されてよく、処理要素は、記憶要素に記憶されたプログラムを呼び出して、端末デバイスによって実行される前述の方法を実装する。代替的に、端末デバイスによって実行される前述の方法を実装するために、少なくとも1つの集積回路がチップに組み込まれてもよい。代替として、前述の実装形態を参照すると、一部のユニットの機能は、処理要素によって呼び出されるプログラムによって実装されてよく、一部のユニットの機能は、集積回路によって実装される。
端末デバイスで使用される前述の装置は、少なくとも1つの処理要素およびインターフェース回路を含むことができることが知見され得る。少なくとも1つの処理要素は、端末デバイスによって実行され、前述の方法の実施形態において提供される方法のうちのいずれか1つを実行するように構成される。処理要素は、第1の方式で、具体的には、記憶要素に記憶されたプログラムを呼び出すことによって、端末デバイスによって実行されるステップの一部または全部を実行してもよく、または第2の方式で、具体的には、命令と組み合わせて処理要素内のハードウェア集積論理回路を使用することによって、端末デバイスによって実行されるステップの一部または全部を実行してもよく、または第1の方式と第2の方式とを組み合わせることによって、端末デバイスによって実行されるステップの一部または全部を確実に実行してもよい。
ここでの処理要素は、上述されたものと同じであり、プロセッサを使用することによって実装され得る。処理要素の機能は、図8で説明した処理ユニットの機能と同一であってよい。例えば、処理要素は、汎用プロセッサ、例えばCPUであってもよく、または前述の方法を実装するように構成された1つ以上の集積回路、例えば、1つ以上のASIC、1つ以上のマイクロプロセッサDSP、1つ以上のFPGA、またはこれらのタイプの集積回路のうちの少なくとも2つの組み合わせであってもよい。記憶要素は、メモリを使用することによって実装され得る。記憶要素の機能は、図8で説明した記憶部の機能と同様であってよい。記憶要素は、メモリを使用することによって実装され得る。記憶要素の機能は、図8で説明した記憶部の機能と同様であってよい。記憶要素は、1つのメモリであってもよいし、複数のメモリの包括語であってもよい。
図9に示される端末デバイスは、図3、図4A、図5、図6A、または図7Aおよび図7Bに示される方法の実施形態における端末デバイスに関連するプロセスを実装することができる。図9に示される端末デバイス内のモジュールの動作および/または機能は、前述の方法の実施形態における対応する手順を実装することが意図される。詳細については、前述の方法の実施形態における説明を参照されたい。繰り返しを避けるために、詳細な説明はここでは適切に省略される。
図10は、本出願の一実施形態によるネットワークデバイスの構造の概略図である。ネットワークデバイスは、前述の実施形態におけるネットワークデバイスの動作を実装するように構成される。図10に示されるように、ネットワークデバイスは、アンテナ1001と、無線周波数装置1002と、ベースバンド装置1003とを含む。アンテナ1001は、無線周波数装置1002に接続されている。アップリンク方向では、無線周波数装置1002は、アンテナ1001を介して、端末デバイスによって送信された情報を受信し、処理のためにベースバンド装置1003に、端末デバイスによって送信された情報を送信する。ダウンリンク方向では、ベースバンド装置1003は、端末デバイスの情報を処理し、情報を無線周波数装置1002に送信する。無線周波数装置1002は、端末デバイスの情報を処理し、次いで、処理された情報をアンテナ1001を介して端末デバイスに送信する。
ベースバンド装置1003は、1つ以上の処理要素10031を含むことができ、例えば、主制御CPUおよび別の集積回路を含むことができる。加えて、ベースバンド装置1003は、記憶要素10032およびインターフェース10033をさらに含み得る。記憶要素10032は、プログラムおよびデータを記憶するように構成されている。インターフェース10033は、無線周波数装置1002と情報を交換するように構成され、インターフェースは、例えば、共通公衆無線インターフェース(common public radio interface、CPRI)である。ネットワークデバイスで使用される前述の装置は、ベースバンド装置1003に配置されてよい。例えば、ネットワークデバイスで使用される前述の装置は、ベースバンド装置1003内のチップであってよい。チップは、少なくとも1つの処理要素とインターフェース回路とを含む。処理要素は、ネットワークデバイスによって実行される任意の方法のステップを実行するように構成される。インターフェース回路は、他の装置と通信するように構成される。一実装形態では、前述の方法のステップを実装するためのネットワークデバイス内のユニットは、処理要素によってスケジューリングされたプログラムによって実装され得る。例えば、ネットワークデバイスで使用される装置は、処理要素および記憶要素を含む。処理要素は、前述の方法の実施形態においてネットワークデバイスによって実行される方法を実行するために、記憶要素に記憶されたプログラムを呼び出す。記憶要素は、処理要素と同じチップ上に位置される記憶要素、すなわち、オンチップ記憶要素であってもよく、または処理要素とは異なるチップ上に位置される記憶要素、すなわち、オフチップ記憶要素であってもよい。
別の実装形態では、前述の方法におけるステップを実装するためのネットワークデバイス内のユニットは、1つ以上の処理要素として構成され得る。処理要素は、ベースバンド装置内に配置される。本明細書の処理要素は、集積回路、例えば、1つ以上のASIC、1つ以上のDSP、1つ以上のFPGA、または集積回路のタイプの組み合わせであってよい。これらの集積回路は、一緒に統合されてチップを形成してもよい。
前述の方法におけるステップを実装するためのネットワークデバイス内のユニットは、一緒に統合され、システムオンチップ(system-on-a-chip、SOC)の形態で実装され得る。例えば、ベースバンド装置は、SOCチップを含み、前述の方法を実装するように構成される。少なくとも1つの処理要素および記憶要素がチップに統合されてよく、処理要素は、ネットワークデバイスによって実行される前述の方法を実装するために、記憶要素に記憶されたプログラムを呼び出す。代替的に、ネットワークデバイスによって実行される前述の方法を実装するために、少なくとも1つの集積回路がチップに組み込まれてもよい。代替として、前述の実装形態を参照すると、一部のユニットの機能は、処理要素によって呼び出されるプログラムによって実装されてよく、一部のユニットの機能は、集積回路によって実装される。
ネットワークデバイスで使用される前述の装置は、少なくとも1つの処理要素とインターフェース回路とを含み得ることが知見され得る。少なくとも1つの処理要素は、ネットワークデバイスによって実行され、前述の方法の実施形態において提供される方法のうちのいずれか1つを実行するように構成される。処理要素は、第1の方式で、具体的には、記憶要素に記憶されたプログラムを呼び出すことによって、ネットワークデバイスによって実行されるステップの一部または全部を実行してもよく、または第2の方式で、具体的には、命令と組み合わせて処理要素内のハードウェア集積論理回路を使用することによって、ネットワークデバイスによって実行されるステップの一部または全部を実行してもよく、または第1の方式と第2の方式とを組み合わせることによって、ネットワークデバイスによって実行されるステップの一部または全部を確実に実行してもよい。
ここでの処理要素は、上述されたものと同じであり、プロセッサを使用することによって実装され得る。処理要素の機能は、図10で説明した処理ユニットの機能と同一であってよい。例えば、処理要素は、汎用プロセッサ、例えばCPUであってもよく、または前述の方法を実装するように構成された1つ以上の集積回路、例えば、1つ以上のASIC、1つ以上のマイクロプロセッサDSP、1つ以上のFPGA、またはこれらのタイプの集積回路のうちの少なくとも2つの組み合わせであってもよい。記憶要素は、メモリを使用することによって実装され得る。記憶要素の機能は、図8で説明した記憶部の機能と同様であってよい。記憶要素は、メモリを使用することによって実装され得る。記憶要素の機能は、図8で説明した記憶部の機能と同様であってよい。記憶要素は、1つのメモリであってもよいし、複数のメモリの包括語であってもよい。
図10に示されるネットワークデバイスは、前述の方法の実施形態におけるネットワークデバイスに関連するプロセスを実装することができる。図10に示されるネットワークデバイス内のモジュールの動作および/または機能は、前述の方法の実施形態における対応する手順を実装することが意図される。詳細については、前述の方法の実施形態における説明を参照されたい。繰り返しを避けるために、詳細な説明はここでは適切に省略される。
当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、本出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組み合わせを有する実施形態の形態を使用することができる。加えて、本出願は、コンピュータ使用可能プログラムコードを含む1つ以上のコンピュータ使用可能記憶媒体(ディスクメモリ、CD-ROM、光メモリなどを含むが、これらに限定されない)上に実装されるコンピュータプログラム製品の形態を使用することができる。
本出願は、本出願による方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明される。コンピュータプログラム命令は、フローチャートおよび/またはブロック図における各プロセスおよび/または各ブロック、ならびにフローチャートおよび/またはブロック図におけるプロセスおよび/またはブロックの組み合わせを実装するために使用され得ることを理解されたい。これらのコンピュータプログラム命令は、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供されてよく、その結果、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の1つ以上のプロセスおよび/またはブロック図内の1つ以上のブロックにおける特定の機能を実装するための装置を生成する。
これらのコンピュータプログラム命令は、コンピュータ可読メモリに記憶された命令が命令装置を含むアーティファクトを生成するように、特定の方法で動作するようにコンピュータまたは別のプログラム可能データ処理デバイスに指示することができるコンピュータ可読メモリに代替的に記憶され得る。命令装置は、フローチャート内の1つ以上のプロセスおよび/またはブロック図内の1つ以上のブロックにおける特定の機能を実装する。
これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイス上に代替的にロードされてもよく、その結果、一連の動作およびステップは、コンピュータまたは別のプログラマブルデバイス上で行われ、その結果、コンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャート内の1つ以上のプロセスおよび/またはブロック図内の1つ以上のブロックにおける特定の機能を実装するためのステップを提供する。
当業者が、本出願の趣旨および範囲から逸脱することなく、本出願に対して種々の修正および変形を行うことができることは明らかである。本出願は、本出願の以下の特許請求の範囲形態が本出願の以下の特許請求の範囲およびそれらの等価な技術によって定義される保護の範囲内に入るという条件で、本出願のこれらの修正形態および変形形態を包含することが意図される。