移动网络中流媒体业务适配承载带宽的解决方案研究

王勇强

（中国移动通信集团上海有限公司 上海200060）

1 引言

当今网络技术高速发展，特别是有线宽带和互联网技术的广泛应用，使得流媒体业务能在广域网上开展服务。基于流媒体技术可以提供电视/电台直播、影视/音乐点播、音频/视频分享等业务。目前提供流媒体业务的热门网站应用有YouTube、优酷、迅雷看看等，这些流媒体业务极大地丰富了人们的生活，并改变着人们娱乐、学习和交流的方式。

近年来，移动通信技术得到了飞速的发展和普及，其与互联网技术的结合，诞生了移动互联网。现在移动网络的无线信道带宽已足以承载轻量级的流媒体业务，而移动终端随身携带的特点也更方便地为现代人提供快餐文化，因此YouTube、优酷等有线宽带互联网上的流媒体业务也就自然地迁移到了移动互联网上。据国内某家移动运营商2011年6月统计，现网流媒体业务所产生的流量已占所有数据流量的5%，流媒体业务已经成为推动移动网络发展的不可忽视的一股新生力量。

然而，由于移动终端用户位置的不确定性，带来了无线信道环境的复杂性（如：信号传播路径变化、阻挡情况变化、干扰情况变化）。移动网络需要根据无线信道服务质量的变化情况，相应地改变无线信道的承载速率，以控制所传输业务的服务质量，从而达到有效利用移动网络资源的目的。移动网络的这个特点意味着它无法像有线网络一样保持用户接入侧稳定的信道带宽（若两者在网络侧都采用有线传输方式，业务信道稳定程度相同）。

流媒体业务采用一定的编码速率进行业务编码，如果业务使用过程中，无线信道的带宽发生变化，则无法保证业务编码速率与信道带宽匹配。如果将高编码速率的业务内容发送给低带宽的网络，就会造成业务播放时的停顿现象，从而影响用户的业务感受；而将低编码速率的业务发送给高带宽的网络，就不能充分利用网络资源提升用户业务感受，造成浪费。流媒体业务采用的缓存技术，可以一定程度上平滑网络的时延和抖动，但不能较好地应对移动网络中信道带宽的等级变化，而信道带宽等级变化在3G移动网络中是常见，如PS 128 kbit/s降级为PS 64 kbit/s。

目前的标准和技术都无法确保移动网络用户在一次业务会话中获取稳定的信道带宽，也不能让流媒体业务平台及时、准确地知晓移动网络的信道带宽。本文在研究流媒体的业务特征和相关通信标准之后，提出了一种新的解决方案。

2 现有技术分析

流媒体业务（packet-switched streaming service,PSS）是指把连续的影像和声音信息经过压缩处理后放到网络服务器上，使用户终端可以边下载边播放。流媒体业务的关键技术是流传输技术，即首先对影像和声音进行传输压缩编码，经过几秒到几十秒的缓存即可在用户终端开始播放；后续的影像和声音将由用户终端继续在后台下载到缓存中，并保证影像和声音的时序性和准确性。

流媒体业务传输协议根据IETFRFC3550、RFC2326的定义，主要有实时传输协议 （real-time transport protocol,RTP）、实时传输控制协议（real-time transport control protocol,RTCP）、实时流协议（real-timestreaming protocol,RTSP）。

RTP协议负责流媒体内容的传输。

RTCP协议负责反馈RTP会话质量并传递RTP同步时间戳。为了反馈RTP会话质量，RTCP协议中定义了周期性发送的报文SR（sender report）和RR（receiver report）。SR中 包 含 了sender’s octet count、sender’s packet count、fraction lost等字段，字段说明参见表1。

表1 SR字段说明

RR中包含了fraction lost、cumulative number of packets lost、interarrival jitter、last SR和delay since last SR字段，定义和SR中相同。RR包的接收方可以结合last SR和delay since last SR用于估算包传输时延。

RTSP协议负责流媒体播放的控制，如播放、暂停、快进、快退等。在RTSP协议中定义了bandwidth头消息，bandwidth用于说明发送方估计的网络带宽。bandwidth可以作为请求头消息应用于RTSP所有的方法中 （如：describe、setup、set_parameter等），协议规定接受 方对于bandwidth头消息的支持是可选的。

3GPP根据移动网络的特点在TS26.234规范中对RTSP协议进行了补充，在setup、play、options和set_parameter方法的请求消息中可以增加3GPP-Link-Char头消息，3GPP-Link-Char包含3个重要的参数：GBW、MBW和MTD。GBW用于说明无线链路（一条无线链路可以由一个或多个无线信道组成）的保证速率；MBW用于说明无线链路的最大速率；MTD用于说明无线链路的最大传输时延。setup或play方法中的3GPP-Link-Char用于表示初始无线链路的质量，options或set_parameter方法中的3GPP-Link-Char用于表示更新的无线链路质量。3GPP-Link-Char头消息起到了替代bandwidth头消息的作用，并丰富了内容。

此外，3GPP还在setup、play、options和set_parameter方法的请求和应答消息中增加了3GPP-Adaptation头消息，3GPP-Adaptation包含2个重要的参数：buffer-size-def和target-time-def。buffer-size-def表示用户终端分配给流媒体播放器用于数据缓存的内存容量，它的作用是去除网络抖动；target-time-def表示用户终端的流媒体播放器需要保持的最短连续播放时间。

为了得到更详细的流媒体业务质量，3GPP定义了QoE协议用于测量和报告流媒体业务质量。QoE协议基于RTSP和会议描述协议（session description protocol，SDP）的扩展，需要流媒体服务器和用户终端的支持。QoE测量协商的需求在RTSP的describe或setup方法的响应消息中提出，在play方法中完成协商，在set_parameter方法中报告测量结果。QoE协议定义了针对媒体的测量指标corruption duration、successive loss of RTPpackets、frame-rate deviation、jitter duration；针对会话的测量指标content switch time、initial buffering duration、rebuffering duration。这些指标的用途参见表2。

从以上协议的分析可以了解到，当流媒体服务器和用户终端都能支持上述协议时，流媒体服务器就能很好地掌握流媒体业务的播放质量和网络质量，就能够根据这些信息调整媒体编码速率以适配网络和终端的具体情况。流媒体服务器实现以上这些协议和能力并不难，然而对于移动网络中的用户终端，它们对协议的遵从度和设备能力可谓千差万别。对于3层以上协议（如QoE协议）的统计测量，用户终端流媒体播放器可以做到，但对于二层协议的信息，如RTSP中的bandwidth、GBW、MBW和MTD，需要用户终端操作系统开放给应用程序。但从目前主流的几个手机操作系统来看，都没有提供这么一种方法或函数来获取网络带宽方面的信息。

表2 3GPP QoE协议定义的测量指标用途说明

Symbian操作系统S60第5版的rconnmon.h文件提供了API方法GetUintAttribute，能获取无线接入网类型TConnMonMobilePhoneNetworkMode，能告知应用程序无 线 接入网类型，如GSM、CDMA、cdma2000、WCDMA、TD-CDMA。虽然rconnmon.h文件定义了最大上行速率KMaximumBitrateUplink、最大下行速率KMaximumBitrate Downlink、保证上行速率KGuaranteedBitrateUplink、保证下行速率KGuaranteedBitrateDownlink，这样的网络带宽信息常量，但也明确表明实际并不支持。

Android操作系统第8版的android.telephony文件的TelephonyManager类提供了API方法getNetworkType获取无线接入网类型，类型包含GPRS、EDGE、UMTS、HSUPA、HSDPA、CDMA、EVDO等。但Android没有提供获取网络带宽的方法。

Windows Mobile 6.5系统2010年版的ril.h文件提供了API函数RIL_GetCurrentSystemType获取无线接入网类型 ，类 型 包 含GSM、GPRS、GSM EDGE、UMTS、HSDPA、cdma2000、cdma2000 1x EV-DO、cdma2000 1x EV-DV等。但Windows Mobile 6.5也没有提供获取网络带宽的方法。

根据以上分析可以得出，由于手机操作系统没有提供获取网络带宽的方法，因此流媒体应用程序也就无法获取网络带宽，更无法将网络带宽信息告知给流媒体服务器。所以在现有的应用中，大都是通过3层协议的统计测量来推测网络带宽，最常用的是基于RTCP的SR、RR报告的方案。通过测量各项传输指标的恶化情况，来判断流媒体业务编码速率与网络带宽的适配程度。即如果传输指标测量值较好，则说明网络带宽可以满足当前的流媒体业务编码速率，反之，则不满足。3GPP定义的QoE协议可以获取更精确的传输质量信息，但对于网络带宽也只能是采用和RTCP相同的推测方案。对于传输信道切换频繁的移动网络来说，要及时地获取最新的网络带宽，采用RTCP的SR、RR报告或3GPPQoE协议就必须进行密集的测量，这对于传输信道带宽较窄的移动网络来说是额外的负荷；另外，用户终端有限的处理能力也不适合在播放流媒体的同时提供这种密集的测量和报告，这样流媒体服务器也就无法及时地调整流媒体内容的编码速率来适配网络带宽的变化。综上分析可以得出，现有技术不能很好地解决移动网络中流媒体业务适配承载速率的问题。

3 基于无线承载情况通报的业务适配方案

通过分析3GPPTS23.060标准可以知道，在建立分组数据业务时，移动网络会以PDPcontext的形式表示一个业务会话，服务GPRS支持节点 （serving GPRSsupport node，SGSN）会使用create PDP context消息告诉网关GPRS支持节点（gateway GPRSsupport node，GGSN）当前网络为用户分配的QoSprofile。在无线承载建立后，SSGN会用update PDPcontext消息告诉GGSN当前无线接入网与核心网协商后的QoSprofile。

在分组数据业务使用过程中，无论是发生用户终端发起的PDPcontext修改，还是网络侧SGSN或GGSN发起的PDPcontext修改；无论修改原因是移动性管理的切换还是O&M，都由SGSN初始PDPcontext修改流程。在修改流程中，SGSN会先向GGSN发起update PDP context消息，然后再向用户终端发起modify PDP context消息。因此，GGSN会在用户终端之前知道网络分配和修改的PDP context内容。GGSN在PDP context建立后，保存PDP context的 相 关 数 据QoS profile negotiated，QoS profile negotiated是当前无线接入网与核心网协商后的QoS profile，包含了当前移动网络内该PDPcontext承载速率的配置信息，包含最大承载速率(maximum bit rate)、保证承载速率(guaranteed bit rate)、传输时延(transfer delay)。如果由GGSN将这些无线链路带宽信息告知流媒体服务器，那么就可以解决现有技术的问题。

建议的方案为：GGSN与业务平台服务器建立TCP或UDP的连接，用于QoS信息的实时传送。GGSN一旦收到SGSN发出的update PDPcontext消息，就使用任何一种公开接口的通信协议，通过已经建立的TCP或UDP连接告知业务平台服务器当前连接的QoS信息即无线链路带宽信息。

该方案与现有技术相比较，优点如下。

·核心网SGSN、GGSN较用户终端先知晓PDP上下文的QoS参数，即无线链路带宽。GGSN可以第一时间将QoS的变化情况告知业务平台服务器，实时性较好。

·SGSN发给GGSN的QoS参数包含了网络分配的无线链路带宽，业务平台服务器无需再作估计，准确度高，效果好。

·对用户终端无附加的软硬件要求，满足相关业务普及的需求。

·不针对特定业务平台，适用范围广。

·无线链路无需传输附加信息，为业务的传输增加了资源。

方案实现原理如下所述。

在PDPcontext建立后，用户终端会进入初始业务请求流程，见图1。

用户终端通过上行链路PDU流程将业务数据经SGSN转发给GGSN，由GGSN进行业务数据的转发。上行链路PDU流程采用GTP-U协议，GTP-U协议分为控制面消息和用户面消息。SGSN使用用户面消息GTP-U-UNITDATA请求向GGSN上传上行链路PDU中的业务数据。根据3GPP TS23.060定义的协议栈结构，GGSN会对GTP-U的业务数据进行解析，获取业务数据的Destination IP Address，即业务平台应用服务器的IP地址。这个IP地址和GTP-U消息中的TEID（tunnel endpoint identifier）是本方案的两个重要参数。TEID在一次PDPcontext中是惟一的，即可以用TEID将同一PDP context的GTP-C和GTP-U消息关联起来。

GGSN收到首条GTP-U-UNIT-DATA请求消息后，启动QoS初始报告程序。QoS初始报告程序判断GTP-UUNIT-DATA请求消息的业务数据中destination IP address是否属于签约流媒体业务应用服务器（AS）。如果是，则根据GTP-U-UNIT-DATA请求消息的TEID找到对应的PDP context，并将destination IPaddress对应的应用服务器地址(application server address)添加到对应PDP context的application server address（为本方案新增）中，然后建立GGSN与AS的QoS报告链路并向AS发送QoS报告，将GTP-C类消息create PDPcontext中的QoSprofile negotiated通过QoS报告的方式告诉业务平台。

在已经建立QoS报告链路的情况下，当无线链路需要更新时，则GGSN会收到SGSN发来的GTP-C类消息update PDPcontext。GGSN启动QoS更新报告程序，QoS更新报告程序根据TEID找到PDPcontext，查找application server address。通过QoS报告链路向业务平台的应用服务器发送QoS报告。以上QoS报告的流程示意见图2。

通过以上方案，就可以在无线链路更新的第一时间将最大承载速率、保证承载速率、传输时延这些网络二层信息告诉流媒体业务应用服务器，这样应用服务器就可以根据无线链路的QoS来调整业务的编码速率，对于流媒体业务来说就可以方便地根据无线链路的QoS来调整音、视频内容的编码速率了。

4 结束语

本文通过对流媒体相关标准和智能手机操作系统的分析，得出目前3GPP所定义的流媒体编码速率适配承载链路带宽的机制在实际应用中存在一定的缺陷，并在此基础上结合3GPP的核心网标准提出了创新的解决方案。该方案可以有效解决流媒体业务适配承载链路带宽的问题，并在华为公司的研发环境中得到了功能的验证。该方案已申请发明专利，专利名称为《UMTS或GRPS通信网络告知业务平台当前无线承载信息的方法》，申请号为200710043755.X，目前该专利正处于公开阶段。该方案更详细的机制和流程描述可参阅专利文件。

1 3GPP，TS 26.234 V9.3.0.Transparent end-to-end packet-switched streaming service(PSS)protocols and codecs，June，2010

2 3GPP，TS 23.060 V9.5.0.General packet radio service(GPRS)service description stage 2，June，2010

3 IETF，RFC 2326.Real time streaming protocol(RTSP)，April，1998

4 IETF，RFC 3550.RTP:A transport protocol for real-time applications，July，2003

5 Nokia Corporation.S60 5th edition API reference，2009

6 Google Inc.Android SDK reference API level 8，May，2010

7 Microsoft Corporation.Windows mobile 6.5 MSDN library，April，2010