1 背景介绍
DASH具有分散性和client-pull的特性-->service providers控制较少=>无法提供高质量服务
DASH基本的分散和客户驱动的特性也有一些缺点。服务提供商不一定能控制客户端的行为。因此，很难提供一致或优质的服务。有许多情况下，体验质量会受到影响。在网络故障或重新配置后，MPD中公布的资源可能会过时，从而导致客户机错误地请求DASH段，并且不成功。当a mobile hand-over或缓存未命中被解释为带宽减少时，DASH客户端可能会错误地切换到质量较低的段。在内容交付网络（CDN）中，大量的实时数据流可能导致缓存未命中的级联。A DASH client可能不必要地启动较低质量segments的视频流，并且只有在获得了基于多个初始段的带宽信息后，才可以增加带宽。多个DASH客户端可能会争夺一个共享带宽，从而导致不必要的交互和可能的振荡。因此，服务提供商可能无法保证DASH的预服务质量，即使在 managed networks中，常规DASH客户端也无法充分利用所提供的服务质量特性。
DASH中QoE退化的主要原因及解决思路
- 流启动期间向最佳质量的缓慢收敛
客户端不仅会等待开始播放，直到其缓冲区达到一定的大小，而且还会从最低的视频质量开始，慢慢地向上倾斜，以找到最优的点。 - 当用户切换到不同的流（例如，信道更改)或同一流中的另一个点(例如，seeking)时，都会导致流会话重启动）
解决
讨论阻碍传递DASH内容的HTTP服务器与DASH客户端之间合作的主要问题。
专家们得出的结论是，通过网络交换客户端和服务器端的信息将减轻MPEG-DASH的客户端驱动理念中固有的一些问题。
例如，服务提供商对DASH客户端的决策几乎没有控制权。让DASH客户端了解服务器故障转移或其他类型的交付相关事件，可以减轻它们对最终用户体验质量的负面影响。另一方面，DASH客户端对网络工作条件知之甚少，必须不断估计网络状况（例如，可用带宽），而网络监控元件可以提供准确的第一手信息（例如，在管理的网络中）
- SAND的主要特点是与客户机的异步网络通信和与质量相关的辅助信息的网络到网络通信
- 让server向client发出有关连接的性能 or QoS信号
这使客户端能够就初始质量作出更详细的选择，从而更快地收敛到最优。
2 SAND结构
2.1 要素
DASH Clients
DASH-assisting network elements（DANE）:识别并解析MPD文件和DASH段以对其进行区分或修改，即对DASH智能性最低的网络元件；例如，他们可能知道传送的对象是DASH格式的对象，他们可能能够解析DASH MPD，或者可能根据其传输的DASH格式对象具有不同的行为
regular network elements： 存在于DASH基础结构中，但对DASH格式的对象没有任何了解，
并将DASH传送对象视为任何其他对象
eg.Transparent cachesDASH metrics server，
负责从客户端收集DASH metrics
2.2 接口（carry各种类型的消息）
- Client-to-DANE (C2D) Interface: Metrics messages and status messages
- DANE-to-DANE (D2D) Interface: Parameters Enhancing Delivery (PED) messages
- DANE-to-Client (D2C) Interface: Parameters
Enhancing Reception (PER)messages
2.3 SAND messages
PED, PER and status messages
-
SAND status messages
- 度量和状态消息具有相同的结构；
- 重要的是要区分它们，因为这些消息携带不同性质的信息
- 从DASH客户端发送到DANEs的状态消息
- 从DASH客户端发送到度量服务器的度量消息。
-
PED
- PED消息可以由第三方分析服务器发送到 a media origin、打包机或边缘路由器/服务器，以增强传递。
- 发送PED消息到第三方分析服务器是没有意义的，因为这样的服务器只消化传入的度量/状态消息并生成PED/PER消息。
-
PER
2.4 流程
- 异步的
network-to-client
network-to-network- 以不延迟或干扰流媒体内容的交付方式进行质量相关的辅助信息的交换
消息信道
通信信道
-
SAND Status messages
预期的请求AnticipatedRequests
组成： the desired segments的URL列表（包含字节范围信息）、DASH客户端期望请求资源的目标时间DASH客户端希望向缓存服务器发送提示，从缓存服务器接收 media segments，说明它计划请求的particular representation(s)。具体eg.
DASH 客户端可以用SAND状态消息通知缓存服务器，它计划从电影K的第5个representation中请求segments41、42和43。
如果缓存服务器是理解这样一条消息的DANE元素，它可以尝试提前预取这些特定段，以便它们可能在收到来自DASH客户端的请求时可以直接用。 这有助于提高服务器上的缓存命中率以及客户端感知到的流质量。
如果存在上游带宽或存储不足，或者有太多这样的消息都请求不同的set of segments，接收缓存服务器可能无法及时处理这些消息 。在这种情况下，需要对消息进行适当的优先排序，并且可能需要调整缓存算法以进行适当的缓存填充和删除。-
SAND PER Messages
考虑一个实时流场景，其中缓存服务于大量DASH客户端。这些DASH客户端在连接方面可能具有不同的能力。
[6]中说明，当客户端无法计算出它们的公平共享带宽并继续从不同的representations中请求段（即频繁的上移和下移）时，共享相同网络资源的流媒体客户端可能会遇到比特率振荡问题。
[7]中研究说明，即使在某些情况下存在缓存服务器，由于缺乏预取所有可能需要的潜在段的能力，用户端的流体验也会迅速恶化。解决方法
缓存服务器向客户端发送一个SAND PER消息，称为 ResourceStatus，该消息列出缓存服务器上的哪些段可用，以及它们将在多长时间内可用。 这为DASH客户端的未来请求提供了一个提示，以保持更稳定的流体验。-
SAND PER Messages
考虑一个现场体育活动，其中实时捕获的内容被编码和打包成许多 representations
假设平均representation bitrates为1、3和5Mbps，所有representation都可用于流客户端。 直播事件开始后的一段时间，分析服务器将开始接收来自客户的度量消息，提供关于其接收质量的详细信息。
如果大部分反馈表明大多数客户端在3到5Mbps表示之间振荡，处理分析数据的决策引擎可以推测新的4Mbps表示将缓解这个问题。
这一决定(PED Messages)可以传达给DANE-enabled transcoders and packagers。
在这样的更改之后，必须修改清单，DASH客户端通过通常的方法获取新的清单文件，这可能是由PER消息刺激的。-
The SAND Transport Protocol
为了传输SAND消息，需要适当的消息格式以及传输协议。
两种类型的下行链路场景
辅助：提供消息作为客户端辅助信息的场景，但即使客户端忽略消息，服务也将继续。
强制执行/错误：一种场景，要求客户采取行动，否则服务被中断。 DANE不能或不愿意用有效的资源响应请求，但提供可行的替代方案
3 性能对比
参考文献：
[1]Thomas E, Van Deventer M O, Stockhammer T, et al. Enhancing MPEG DASH performance via server and network assistance[J]. 2015.
[2]Thomas E, van Deventer M O, Stockhammer T, et al. Application of SAND Technology in DASH-Enabled Content Delivery Networks and Server Environments[J]. SMPTE Motion Imaging Journal, 2018, 127(1): 48-54.
[3]Mehrabi A, Siekkinen M, Ylä-Jääski A. Edge computing assisted adaptive mobile video streaming[J]. IEEE Transactions on Mobile Computing, 2018, 18(4): 787-800.
[4]Kleinrouweler J W. Using DASH Assisting Network Elements for Optimizing Video Streaming Quality[C]//Proceedings of the 25th ACM international conference on Multimedia. 2017: 821-825.
[5]Li Z, Zhao S, Medhi D, et al. Wireless video traffic bottleneck coordination with a DASH SAND framework[C]//2016 Visual Communications and Image Processing (VCIP). IEEE, 2016: 1-4.
