NGN学习笔记7——NGN的服务质量

川长思鸟来 2024-04-19 13:39 2阅读 0赞

**1.基本定义**

服务质量(Quality of Service, QoS)体现了消费者对服务提供者所提供的服务的满意程度，是对服务提供者所提供的服务的一种度量和评价，很多组织都对QoS进行了大量的研究  
ISO  
ITU-T  
IETF  
ATM Forum

**2.NGN中的QoS问题**

1）问题背景：

NGN以分组网络作为其传送网，QoS是非常重要的内容。NGN是多网、多业务融合的网络，端到端QoS是其研究重点：多种QoS机制共存，各有优缺点，各运营商部署的QoS机制不尽相同，成为端到端，QoS无法得到保证的主要障碍。

2）相关标准：

*ITU-T*

Y.1291, An architectural framework for supporting of QoS in packet networks  
提出了在分组网络中支持QoS的体系结构框架  
该框架结构由三个逻辑平面的QoS构建模块组成  
Y.2111 (draft), Resource and Admission control Functions in Next Generation Networks  
Y.2112, A QoS Control Architecture for Ethernet-based IP access networks  
Y.2113 (draft), Ethernet QoS Control for Next Generation Networks  
Y.2121, Requirements for the support of flow state aware transport technology in an NGN  
Y.2173, Management of performance measurement for NGN  
Y.2174, Distributed RACF architecture for MPLS networks

*3GPP*

3GPP TS 23.107, QoS concept and architecture  
3GPP TS 23.207, End-to-end QoS concept and  
architecture  
3GPP TS 23.802, Architectural enhancements for  
end-to-end Quality of Service

3）QoS/NP/QoE的定义：

QoS (E.800)：决定业务用户的满意程度的业务性能的总体印象

NP (I.350)：NP由一些对网络提供者有意义的参数来度量，这些参数通常用于系统设计、配置、运营和维护。NP的定义与终端性能和用户行为无关。

QoE：对一个业务或应用的可接受程度的总体描述，是端用户的主观感受，包括完全的端到端系统效果（客户、终端、网络、业务基础结构等）总的可接受程度受用户期望值和环境的影响。

[![image][]][image 1]

三者区别：

*  QoS为网络提供商提供了一种有价值的框架
 *  NP决定了用户最终观察到的QoS
 *  QoE是一种纯主观的评测标准，依赖于用户的行为和主观意见
 *  QoS、NP和QoE之间不存在简单的一对一的映射关系

[![image][image 2]][image_image 2]

NGN QoS 和NP的分层模型

[![image][image 3]][image_image 3]

**3.IP  QoS**

1）定义：

IETF对IP QoS的定义--QoS是网络在传输数据流时要求满足的一系列服务请求，具体可以量化为带宽、延迟、抖动、分组丢失率和吞吐量等性能指标,强调网络传输服务性能。

QoS是IP网支持实时应用应考虑的最重要因素，IP网固有的无连接特征（分组丢失、时延抖动），使得端到端的QoS保证并非轻而易举。IP QoS的目的是控制分组流，使某些分组流  
能够得到比“尽力而为”更好的待遇。

2）指标：

分组传送时延：从发送方发出分组的第一个比特到接收方接收到分组的最后一个比特所持续的时间，节点处理时延＋链路传输时延

分组传送时延抖动：同一路径上发送的数据流中一组分组之间的时延差异

分组丢失率（丢包率）：在网络中传输数据分组时丢弃数据分组的最高比率

获取的带宽（吞吐量）：网络发送数据包的速率(平均速率或峰值速率)

3）技术：

*  公平排队——FQ
    
     *  传统IP路由器在每个输出端口都采用FIFO排队规则。缺点：
        
         *  对高优先级或时延敏感业务流无特殊照顾
         *  长分组得到的服务会更好
         *  贪婪的TCP连接会挤掉其他连接
     *  公平排队则是在路由器每个输出端口维护多个(每业务流)队列，每个分组放入合适的队列，对队列轮流服务，在流之间提供了负载均衡。

*  加权公平排队——WFQ
    
     *  FQ的缺点：短分组受到惩罚，每次传送的分组都很短
     *  WFQ则通过分组长度和流标识等对不同队列中分组的传送提供不同的传送权重
 *  综合服务（IntServ）
    
     *  最早由MIT在1993年提出，IETF标准化，基本思想是为用户提供多种服务类型，按照用户的质量要求提供不同的服务，并相应地收取费用，是基于数据流提供精确的服务，在提供服务之前需进行资源预留。
     *  IntServ服务在两个级别上定义
        
         *  通用的服务类型
         *  针对每种服务类型的业务量规范TSpec（具体参数）
     *  IntServ定义了三种通用服务类型
        
         *  保证型服务(GS)：提供时延、带宽和丢包率保证
         *  负载受控型服务(CLS)：提供可靠的和改进的尽力而为服务，相当于网络在轻负载下的尽力而为服务，能提供较小的传送时延，绝大多数分组被成功交付
         *  尽力而为型服务(BS)——传统IP网的服务
     *  模型：  
        接->分类->调度  
        [![image][image 4]][image_image 4]
    
    设置协议 (Setup Protocol)——RSVP，使主机或路由器能够动态地保留网络资源，以满足特殊业务流的QoS要求。
    
    业务流规范 (Flow Specification)：用于定义一个特定业务流的QoS，业务流 (flow) 是指具有相同QoS的、从某个源到某个目的端的一个分组序列。
    
    流量控制：接纳控制 (Admission Control)、分类器 (Classifier)、调度器 (Scheduler)。
 *  RSVP协议：
    
     *  终端主机：用RSVP协议向网络申请资源
     *  路由器(网络节点)：通过RSVP协议建立和保持资源预留状态，并将资源预留请求转发给数据流经过的其它路由器，最终实现资源预留。
    
     *  RSVP的特点：
     *  适用于单播和多播预留
     *  单向预留——只预留从发送方到接受方的资源
     *  接收方发起预留——在多播通信中，允许不同的接收方要求不同的QoS
     *  软状态——在分组途经的路由器中建立资源预留“软”状态。需不断刷新，否则会过时
     *  提供不同的预留风格
     *  透明通过非RSVP路由器

在Internet中实现QoS的信令协议，是利用现有的Internet网络结构和路由协议将业务流的QoS要求传递给通路上的主机或路由器，协商进行资源预留。支持组播业务。

资源预留过程：  
[![image][image 5]][image_image 5]

•PATH消息内容包括预留资源、会话类型、数据分组的格式和流量特性等

•RESV消息确定了资源的预留方式和对应的发送方式

区分服务(DiffServ)

DiffServ体系最早由Nichols于1997底提出，IETF成立了一个专门的DiffServ工作组。DiffServ与InterServ的本质区别在于它不是针对每一个业务流进行网络资源的分配和QoS  
参数的设置，而是将用户的业务流汇聚成少数几类，为不同的业务类提供优先级服务。与InterServ不同，DiffServ只提供相对的服务质量保障。

[![image][image 6]][image_image 6]

网络结构：

[![image][image 7]][image_image 7]

DS结构=QoS策略或资源管理器+边缘业务量调节器+ 核心PHB处理

PHB：

[![image][image 8]][image_image 8]

DS边缘路由器和核心路由器：

[![image][image 9]][image_image 9]

QoS路由

*  链路状态信息的发布：路由器需要拓扑和资源信息以计算路由
 *  路由计算
 *  路由表存储

*  源端路由：源端节点根据全局信息计算可行路径
 *  分布式路由：每个节点通过距离矢量计算每一跳路由
 *  层次路由：网络中的节点形成一个多级的层次结构，分层递归选路

传统的Internet路由协议 (OSPF，RIP) 是采用单个参度 (如跳数、成本) 计算最短路由，没有考虑多个QoS参数的要求。QoS路由可以根据多个QoS参数进行路由，对应用提供QoS保证。度量参数包括带宽、成本、每一跳开销、 时延、可靠性等，其目标是要尽量满足每个连接的QoS请求，同时优化网络资源利用率。

QoS路由的三个核心功能

QoS路由策略

优点：满足各类业务的QoS要求，提高网络的利用率。  
缺点：增加开销：计算开销和协议开销，实现复杂。

MPLS概述

IETF的MPLS工作组提出，主要思想是要开发一种综合选路和交换的标准，将路由选择功能转移到网络边缘，将效率更高、结构更简单的交换功能放在核心网络，通过提供虚电路 (LSP) 的方式来提供QoS保证，可以与资源预留进行结合提供QoS保证。

LSR (标签交换路由器)：支持第三层分组转发和第二层标签交换

FEC (转发等价类)：在同一路径上以相同的方式被处理和转发的一组IP包，可以被映射为单一的标签

LSP (标签交换路径)：由一系列LSR建立的从入口到出口的交换路径，通过标签转发分组

LDP (标签分发协议)：在LSR之间交换FEC/标签绑定信息的MPLS控制协议

LIB (标签信息库)：保存在LSR中的连接表

MPLS转发和传统的IP转发：

[![image][image 10]][image_image 10]

过程：

[![image][image 11]][image_image 11]

**4.分组网的通用QoS框架**

1）基本定义：

QoS框架由一组与网络能力、DiffServ、IntServ、MPLS等实现QoS的具体方式无关的QoS构建模块组成。按照三个逻辑平面组 织：控制、数据、管理，通过这些构建模块的不同组合，为各种应用提供满意的业务性能，并最终帮助电信运营商提供决定业务用户满意度的综合服务性能。

[![image][image 12]][image_image 12]

2）控制平面的机制：

a）接纳控制——控制业务流量是否被允许进入网络。接纳控制通常由策略驱动，业务流是否被接纳取决于预先确定的SLA及可用网络资源接纳控制可以采用基于参数的方法或基于测量的方法来保证业务的QoS。

*  基于参数的方法：根据最坏情况下的边界值(分组丢失、时延和抖动等)，对实时业务提供“硬”QoS，通常需要进行资源预留
 *  基于测量的方法：通过测量现有的流量来进行接纳决策。不能保证吞吐量、分组丢失、时延和时延抖动的“硬”指标，只能提供“软”的或相对的QoS
 *  基于测量的方法具有更高的网络资源利用率

b）QoS选路——QoS选路就是找到一条满足一个或多个QoS条件的路径，实际的QoS选路方案一般只考虑一个或两个QoS参数。几种可以减少计 算复杂性的路由策略：源路由、分布式路由、分级路由。为了保证QoS路径的性能，QoS选路通常需要与资源预留机制一起来为该路径预留必要的网络资源。

c）资源预留——拥塞避免通过采用有效手段保证网络负载在其容量之下，从而使网络运行在可接受的性能水平。典型的网络拥塞避免方案是在网络拥塞指示 (分组丢失或定时器超时)出现时由发端减少进入网络的流量。业务源如何减少进入网络的流量取决于传输协议。如TCP的成倍减小窗口尺寸，一般来说，先削减 准入优先级不高的用户的业务量。 ECN(显示拥塞通知，对遭遇拥塞的分组进行标记)可避免由于分组丢失后的重传导致额外延时的可能。

d）排队和调度——排队和调度机制用来控制将哪些分组发送到输出链路上。输入业务流被保存在由多重队列构成的排队系统中。管理队列系统就是应用排队和调度规则

e）分组标记——可以根据分组在网络中的特定服务类别对分组进行标记。分组标记就是为分组的特定头域指定一个值，通常由边缘节点来完成，如果由主机来完成，边缘节点必须对其进行必要的检查和变换，网络可以通过改变标记对分组进行升级或降级。

f）流分类、流量监管——流量分类可以针对流或分组进行，在网络边缘，负责流量分类的实体通过察看分组的多个字段来决定该分组属于哪个集合及相应的服务等级协议 (SLA)。而流量监管以逐跳转发为基础，根据预定的策略或协议来决定某一流量是否被提供。

g）流量整形——用来控制进入网络的流量的速率和容量。通常在出节点和入节点之间完成。

3）管理平面机制

a）SLA——SLA是客户与服务提供者就一项业务在可用性等级、适用性、性能、操作和其它业务属性等方面达成的协议，SLA的技术部分称为业务等级规范(SLS)，包括一组参数和值，它们一起规定了网络提供给客户的服务。管理SLA主要是管理SLA协商的服务质量。

b）流量测量——测量（Metering）主要是根据协商的流量描述来监视业务流的临时特性（如速率），包括在一个给定的网络点观察业务流特性，并 收集和存储流量信息，以便分析和进行进一步的处理。根据协商的等级，测量器可以调用相应的机制，对分组进行处理，如丢弃分组或对分组流整形。

c）流量恢复——流量恢复广义的定义是，在故障条件下尽量减轻流量丢失。流量恢复应从多个层次上来考虑：光网络层、SONET/SDH层、IP 层……不同层次可以通过不同的方式来进行流量恢复，有两种类型的故障：链路故障和节点故障，衡量业务恢复能力的参数有两个：恢复时间、恢复百分比。

d）策略——策略是一组用于管理和控制对网络资源的访问的规则，可以是为了满足业务提供者的需要，或者反映客户与业务提供者之间的协议。业务提供者可以根据策略实现控制平面和数据平面的机制。

4）不同构建块之间的交互

一个全面的QoS解决方案通常需要协同使用控制平面、数据平面和管理平面的多个构建块。因此，需要在不同的平面、不同的构建块之间交换QoS参数，包括分组级的传输性能（如时  
延和丢包率）、服务的有效性和可靠性指标、服务等级参数等。不同构建块之间QoS参数的传递和交换可以通过信令和数据库查找等机制完成。

**5.NGN的端到端QoS**

1）目标**：** 为各种业务和应用提供要求的质量，能够保证具有不同QoS体系结构的不同管理域之间的互通，以获取端到端的QoS。因此，端到端QoS的设计目标应该是一种体系结构框架，该框架可以提供满足用户 (包括端用户和其它应用提供商以及网络提供商等)的综合需求。

2）需求：

考虑NGN的一般约束：支持不同的商业模型、不同的业务类型、不同的接入和传送技术……

*  支持业务生命周期相关的过程：业务的订购、调用、售后处理等
 *  支持不同的QoS控制粒度：基于流、基于会话、基于业务类，支持动态QoS
 *  QoS互通：不同提供商、不同域
 *  QoS信令：用户发起/网络发起，通道解耦/通道耦合

3）体系结构模型:

[![image][image 13]][image_image 13]

4)业务订购过程

*  业务提供层：负责管理业务订购。它提供一个正式的业务合同，在客户与提供者之间进行协商
 *  业务执行层：激活QoS合同，并订购 (order)资源协调层
 *  资源协调层：管理端到端资源性能相关的信息 (连接、接入网等)，将QoS特性与网络资源性能进行绑定
 *  网络资源处理层：对网络资源配置进行管理，按微观方式 (接口、缓冲区等)将QoS约束条件考虑进行
 *  网络元素资源管理层：负责对网络元素配置参数进行管理，并将资源标为临时占用状态

5）业务调用过程

*  业务提供层：将客户订购的QoS和客户请求的QoS进行对照
 *  业务执行层：处理适合客户的请求的QoS
 *  数据资源协调层：选择满足上述QoS约束的端到端QoS资源 (接入网、核心网、子网等)
 *  网络资源处理层：根据QoS约束进行包括接纳控制在内的控制
 *  网络元素资源处理层：根据每个节点的实际资源状态进行接纳控制
 *  资源层：业务流按照业务合同的规定进行交换和转发

6）业务售后过程

基于网络测量，得到估算的业务实际占用的资源信息，与事前订购的业务合同进行比较，据此向用户计费。

7）通用参考模型

[![image][image 14]][image_image 14] [![image][image 15]][image_image 15]

8）资源控制方式

a）集中的接纳和资源控制

[![image][image 16]][image_image 16]

b）接纳和资源控制在边缘完成

[![image][image 17]][image_image 17]

c）混合控制

[![image][image 18]][image_image 18]

9）资源接纳控制功能

RACF（资源接纳控制功能）通过接入网和核心传送网，提供QoS控制（包括资源预留和接纳控制）、网络地址端口转换（NAPT）/防火墙控制、NAT穿越控制功能。RACF在业务控制功能和传送功能之间进行资源协商和分配的协调。

**6.UMTS网络的端到端QoS**

1）模型**：**

[![image][image 19]][image_image 19]

2）UMTS端到端服务的提供

*  一个本地TE/MT本地承载服务
 *  一个UMTS承载服务
 *  一个外部承载服务(可能是另一个UMTS承载服务)

3）UMTS 承载服务

UMTS承载服务负责提供UMTS QoS。UMTS承载服务包含无线接入承载服务和核心网承载服务，两种服务构成了实现UMTS承载服务的最优路径，即基于各自的网络拓扑考虑了如移动性和移动用户配置等各个方面的实现。

*  无线接入承载服务为MT和CN边缘节点之间的信令传输和用户数据传输提供符合UMTS承载服务协商的QoS或默认的QoS  
    无线接入承载服务由一个无线承载服务和一个RAN接入承载服务来实现。无线接入承载服务包括了无线接口传输的所有方面，此承载服务由UTRAN FDD/TDD或GERAN提供。RAN接入承载服务及其物理承载服务负责在RAN和CN之间提供传输服务。传输分组流的RAN接入承载服务应该根据不同 的QoS来支持不同的承载服务。RAN接入承载服务由Iu或Gb接口上的承载服务提供。
 *  UMTS核心承载服务利用CN网关连接到UMTS CN边缘节点，最后连到外部网络。核心承载服务负责有效性控制并利用骨干网络来提供约定的UMTS承载服务。  
    核心网承载服务利用一般骨干网服务来实现，骨干网服务包括Layer1/Layer2的功能实体，由运营商策略选择所需的骨干网服务来满足核心网承载服务的QoS需求。  
    [![image][image 20]][image_image 20]

IMS端到端QoS架构

[![image][image 21]][image_image 21][ ][image_image 21]

转载于:https://my.oschina.net/alphajay/blog/4950

[image]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a15e0421b9204848adcce9c30b1b8971.png
[image 1]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_2_633985634913637500.png
[image 2]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_1_633985640855825000.png
[image_image 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/93911047adf74a98af53f0e3a96180f4.png
[image 3]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_2_633985640900981250.png
[image_image 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f076836e1bbf45a5970fb4393326c52f.png
[image 4]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_3_633985640906450000.png
[image_image 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a84679b31d424af9bb34804814ca5881.png
[image 5]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_4_633985640957856250.png
[image_image 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/4afe99cb0e3e4f4dab9a19d90c4b5789.png
[image 6]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_5_633985640995512500.png
[image_image 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/186d0b29e8104cac8c7f5d976708936b.png
[image 7]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_6_633985641032856250.png
[image_image 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/93e76e2e0224480c95f8187b3d9a9eb1.png
[image 8]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_7_633985641051762500.png
[image_image 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/31c12129e25f4786a6505ed34fe207f7.png
[image 9]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_8_633985641103168750.png
[image_image 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/192f910d7d774d388fa61d3645a06230.png
[image 10]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_9_633985641135200000.png
[image_image 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/db2a6b2c99db4c8cbf98df281082ce37.png
[image 11]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_10_633985641171606250.png
[image_image 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/74457dfa8e5c41d98a8bc053ad5c54c2.png
[image 12]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_11_633985641277231250.png
[image_image 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/2964c2ebb8b64b2583d06eaaf6678cfd.png
[image 13]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_12_633985641407700000.png
[image_image 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/29adf7373c2d4bb78be53a3269ed0ce8.png
[image 14]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_13_633985641501137500.png
[image_image 14]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_28_633985641435200000.png
[image 15]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_14_633985641591450000.png
[image_image 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/08aa53a459aa4a1681de90cea008e861.png
[image 16]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_15_633985641597075000.png
[image_image 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/77ea0da294e849878de734765d3084c9.png
[image 17]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_16_633985641663793750.png
[image_image 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5b8655e0ab9c4acdbe858b4a8336a275.png
[image 18]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_17_633985641671293750.png
[image_image 18]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/458f63fb79404145ad379ae5916ed7b7.png
[image 19]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_18_633985641685825000.png
[image_image 19]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/88e1ce00e5d54b999b102c9694efc378.png
[image 20]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_19_633985641706293750.png
[image_image 20]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1dc394301dae4b4da7d451c2983787b6.png
[image 21]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_20_633985641786293750.png
[image_image 21]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_42_633985641730200000.png