QoS 无线数据业务的基础

Quality of Service，简称 QoS，是无线数据业务的基础。手机在需要使用数据业务的时候会首先向网络提出申请并和网络协商手机需要的带宽等一系列参数以便网络预留足够的资源，这些参数就存在 QoS 里。当然，网络是不会随意答应用户提出的“要求”，而是查询用户是不是为此类 QoS 支付了租金，如果用户申请的 QoS 满足于其购买的 QoS 限制，网络就为手机建立通路提供服务。反之，网络会与手机协商 QoS，也就是说，网络会向手机提供一个其能够提供的 QoS，是不是接受协商完全取决于手机。故用户在购买数据业务服务的时候其实就是购买了 QoS，不同的价格对应于不同的 QoS，好比为 1M 的宽带和 2M 的宽带支付不同的租金。这个 QoS 信息存放在 HPLMN 的 HLR 上，上一篇文章中提到的 APN 和 QoS 有一一对应的关系。

网络能够提供什么样的 QoS，不仅和用户购买了什么样的服务有关，而且还和无线接口速率，和核心网所能提供的带宽有关。显然，EDGE 网络与 WCDMA 网络所能提供的无线接口速率相差甚远，如果手机使用 HSDPA 在下载文件的时候漫游到 EDGE 的网络中，网络会主动发起修改 QoS 的协商，其实并不是协商，因为手机没有机会提出自己的异议，只能接受，或者放弃连接。举例说，手机注册在 WCDMA 网络下，用户决定使用流媒体播放器收看电影，为了达到一定的播放质量，软件要求至少使用 384Kbps 的下载速率接收，推荐使用 512Kbps 的下载速率接收，于是要求向网络提起并得到 512Kbps 下载带宽。假设这时，网络端可能发送 cell change order 到使手机切换到 GSM 的网络，切换完毕以后由于 GSM 网络无法支撑 512Kbps 的下载速率，故网络端会发起 QoS 的协商降低带宽。如果手机可以接受，在这个例子中也就是新的下载带宽高于 384Kbps，则用户能够继续收看电影，否则，播放就会终止。

从上面的例子中可以看到 QoS 对无线数据业务的重要性，当然传输速率只是 QoS 众多属性中的一个，下文从我理解的角度来说说重要的属性。顺序按照属性在 QoS 结构中的先后次序。还要声明的是，在 Rel-6 的 QoS 可以分为相互参照的两部分，即 R97/98 QoS 版本和 Rel-6 QoS 版本，这是为了向前兼容，本文要讨论的是 Rel-6 QoS 的属性，其可以对应到 R97/98 QoS，规范有明确表述，这里就不提了。

Traffic Class，其包括五个可选属性，Conversational Class，Streaming Class，Interactive Class ，Background Class 与 Subscribed Traffic Class（代表手机希望网络指派一个值）。这个属性是宏观的表述手机需要是什么类型的数据业务。从字面上也很容易理解 Conversational Class 期望最小的 latency。从速率的方面可以将前四类分为两个组：Conversational Class 和 Streaming Class 是一组，Interactive Class 和 Background Class 是一组，理由在后面讲解 Guaranteed bit rate for uplink/downlink 的时候在细说。这里有一个值得注意的是，根据当前的标准，如果手机选择让网络指派一个值，即选择 Subscribed Traffic Class，网络只能指派 Interactive Class，其目的不是很明确。过去应用程序使用数据业务的时候一般协商结果都是使用 Interactive Class，这是最常见的情况，比如我们浏览网页，接收电子邮件。现在 HSPA 网络出现以后，有网络根据 Traffic Class 是不是设置为 Conversational 或者 Streaming 判断需不需要为其提供 HSPA 的 Radio Bear。

Delivery Order，选择数据包是不是需要顺序收发。在目前的应用里，这个属性似乎多余。因为应用程序几乎都使用拥有顺序收发能力的协议，并不依赖于底层。反而如果设置 Delivery Order 为 Yes，即表示要求顺序收发数据包，数据包有可能会在 RNC 堆积，或者引起 RLC 重发数据包，结果就是降低了性能。故此属性都是设置为 No。

Delivery of Erroneous SDUs，选择错误的 SDU 应该是丢弃，还是继续传送。设置为 No 表示开启错误检测，并丢弃错误的数据包；设置为 Yes 表示开始错误检测，标致错误的数据包，并继续传送；设置为 No Detect 表示放弃检测错误。通常选择为 No。

Maximun SDU Size，选择 SDU 的最大长度。一般设置为 1500 字节。该值的选择和 Traffic Class 有一定联系，举例说，提供 VoIP 的应用程序就不需要设置的很大的 Maximum SDU Size；但对于浏览器而言，则没有理由要使用小于 1500 字节的值。

Maximum bit rate (DL/UL) 选择最大下载/上传速率。应用程序能够达到的速率其实和网络的限制有较大关系，尽管该值能够被设置的大于网络的极限，比如，在支持 GPRS 的网路里，最大上传被设置为 384Kbps。实际中也有这样的情况发生，有人质疑过为什么能够设置一个网络根本不能达到的值，我也有些迷惑，不过，似乎网络承诺不能达到的最大速率并不违反什么规范。毕竟该值和后面要说的 Guaranteed bit rate for uplink/downlink 不同，Maximum bit rate 承诺的是最大值，只要不超过，就合理。目前的网络在提供数据业务服务的时候，都提供力所能及的速率，还没有到需要限制最大速率的时候，不过在可以预见的将来，特别是随着高速无线数据服务的产生，该值会被更广泛的利用起来以限制应用程序使用带宽。

Transfer delay，传输的延迟，该值只有在 Traffic Class 被设置为 Conversational 或 Streaming Class 的时候有效。

Guaranteed bit rate for uplink/downlink，网络承诺其能够保证的上传/下载速率，该值只有在 Traffic Class 被设置为 Conversational 或 Streaming Class 的时候有效。该值区别于前面提到的 Maximum bit rate，因为网络必须保证本传输速率，其意义在于举例说，VoIP 应用程序或者流媒体播放器，很显然，此类应用有最小传输速率的要求，如果传输速率低于最小值，该应用就不能实现。

最后要提的是 Signalling Indication，其表示与本 QoS 相关的 PDP context 是不是用于控制目的。越来越多的应用程序选择建立一个特殊的 Primary PDP Context 用于收发应用程序层的控制信令，而使用 Secondary PDP Context 来实际接收数据，举例说，手机电视应用程序使用 Primary PDP Context 来接收节目单，发送传输质量报告等控制信息，而使用 Secondary PDP Context 来接收电视内容；这样一来，应用程序能够为 Secondary PDP Context 申请很大的带宽和较高的 Guaranteed bit rate for downlink，如果可能网络会使用 HSDPA，而 Primary PDP Context 则申请较低的带宽等参数以节省资源并为使手机漫游的时候提供通畅的控制信令通道。（比如，手机从 WCDMA 漫游到 GSM 网络，Secondary PDP Context 会由于 GSM 不支持 HSDPA 而被释放，但是网络会保留使用低速率连接的 Primary PDP Context 控制信道）