文档章节

ITU-T Technical Paper: QoS 的参数(非常的全,共计88个)

abcijkxyz
 abcijkxyz
发布于 2016/08/06 11:59
字数 6157
阅读 1
收藏 0

本文翻译自ITU-T的Technical Paper:《How to increase QoS/QoE of IP-based platform(s) to regionally agreed standards》(2013/3/1)。这是其第四章的一部分,给出了QoS的参数。PS:在此感谢一位师弟的翻译。

 

QoS 参数 (也被称为 QoS指标、 QoS 决定因素等) 指明了一项服务的质量水平,以及用户的满意度水平。它用数字(量化值)代表用户感知到的主观的、抽象的“质量”。服务和网络供应商可以利用它来管理所提供的服务,终端用户和供应商合作伙伴也可以用它来确保得到的服务达到了应有的质量。
QoS 参数可以通过主观或客观的测量方法得到。客观的QoS 参数往往用作服务质量特性描述和改善的内部指标,是通过测量电路的物理属性、网络、信号而得到的。主观的 QoS 参数是通过用户意见调查得到的,而且往往用作外部指标,比如用来进行客户关系管理。 [9]
ITU-T I.350 建议将 QoS参数分为三个功能 (接入、用户信息传输以及分离) 和三个性能标准(速度、准确性和可靠性)。这形成了9种可能的组合,如下图8中以3 x 3矩阵所示。在这个通用框架之下,可以确定特定的QoS指标以用于不同的应用和服务类型,例如:

    • 用于不同信号类型的QoS指标,例如语音、传真、视频。
    • 用于一种信号类型(如语音),但是不同服务类型的QoS指标,例如电话语音、语音信箱和流式音频,它们有着不同的延迟要求。
    • 用于同种信号和服务类型,但是不同的商业级别的QoS指标,例如高价的高品质电话语音服务和免费的尽全力交付的且带有广告的电话服务。

 


图 8 – 3x3 矩阵法与可用状态的确定


进行有效的QoS管理的先决条件是拥有QoS参数或指标,这些参数应当易用、准确表达用户感知并且被广泛接受而成为标准。图9向我们展示了QoS参数之间的关系。确定网络因素的一些参数可以影响到应用参数。相似的,属于应用因素的一些参数也可以影响关系到QoE的QoS服务水平。所以我们期望在确定QoS时将这种参数之间的关系考虑在内。


 

图 9 –QoS参数之间的相互关系


下面定义的QoS参数可以用来比较服务供应商的性能水平。 [b- ITU-T E.803]

 

 

ICT 服务的初步信息
[参数 1]初步信息的完整性:用对服务供应商提供给潜在客户的ICT服务的真实而公平的观点表示,这一参数用“意见评级”衡量。
[参数 2] 定价透明度:表现为每个价格体系的清晰性和简洁性,适用于供应商提供的所有服务的所有使用环境。这一参数用 “意见评级”衡量。
[参数 3] PI (初步信息)的可用性:在预定时间间隔内潜在用户或客户发出并得到交付的PI请求数与发出的总请求数的比率。这一参数用“分数或百分比”衡量。
[参数 4]提供PI的响应时间:从一个PI请求发送到SP的瞬间至所有被要求的信息交付到客户的瞬间之间的时间。这一参数用“时间”衡量。

ICT 服务提供商与用户之间的合同问题
[参数 5]合同信息的完整性:有关于服务供应商所提供通信服务的供应、维护和中止相关信息的真实而公正的观点。这一参数用“意见评级”衡量。
注 1 –一个描述SP提供的通信服务的供应、维护和中止相关信息的合同文件应是清晰、准确、完整而且易于理解的。
注 2 –所选择的语言、措辞和表达方式应致力于让目标客户市场获得最好的理解。
[参数 6]合同条款与初步信息之间的符合性:合同文件的内容与PI之间的一致程度。这种一致性的比较应基于在合同期内有效的PI。PI中隐含的信息可以在合同条款中得到详细的阐述,如果只是提供了额外的、不矛盾的信息,就不用被当做是错误。这一参数用“比率或百分比”衡量。
[参数 7] 合同签署之前的定制灵活性:在正式签署合同之前,接受个人客户对于服务功能、服务性能等合同条款的特殊要求的范围和界限。这一参数用“意见评级”来衡量。
注 –这些特殊要求可以偏离服务供应商所提供的标准的服务特性、性能等合同条款。
[参数 8] 正式签署合同后修改条款的简易性和灵活性:为满足客户而对合同条款进行修订的可容许范围和边界。不包括已经被供应商明确表示不考虑修订的合同。这一参数用“意见评级”衡量。

服务供应
[参数 9]达到承诺的服务提供时间:成功按照合同中所承诺时间提供的服务与承诺要提供的服务总数之比。这一参数用“比率或百分比”衡量。
[参数 10] 提供服务的时间:预定的提供时间与实际的提供时间之间的时间差。这一参数用“时间”衡量。
[参数 11]在特定时间段内成功实现的服务:在预定时间段内成功提供的服务与期望的总数之比。这一参数用“比率或百分比”衡量。
[参数 12] 因未能履行而取消的合同:在给定评估期限内,由于持续的不履行而取消的合同数与签订的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 13]服务提供期间合同规定的实现程度:在提供后实现了所有指定的网络和/或服务功能的合同与被认为实现了供应的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 14]服务供应的准时性: 服务的实际提供时间与合同中所指定时间之间的时间差。这一参数用“时间”衡量。
[参数 15]服务供应设备交付的准时性:实际的设备交付时间与预定的交付时间之间的时间差。这一参数用“时间”衡量。
[参数 16]未完成或出现错误的首次供应:在首次尝试中未能完全实现或正确实现的服务供应与可被视为完成供应的合同数之比。这一参数用“比率或百分比”衡量
注 – 这一指标显示了SP在首次尝试中完整并正确实现供应的能力。

服务变更
[参数 17] 服务变更用时:变更通知到达用户的瞬间和变更完成瞬间之间的时间差。这一参数用“时间”衡量。
[参数 18] 特定时间内成功完成的服务变更: 在合同制定的时间段内,成功完成变更的合同(或服务)数与宣布要进行变更的合同(或服务)总数之比。这一参数用“比率或百分比”衡量。
[参数 19]服务变更时实现合同规定的完整性:在进行服务变更时,所有包含达到的或完成的、合同约定的质量标准的合同,与服务变更所要求更改的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 20] 服务变更约定的准时性:实际的服务变更时间与服务供应商宣布的预定变更时间之间的时间差。这一参数用“时间”衡量。
[参数 21] 服务变更设备交付的准时性:实际的设备交付时间与服务供应商宣布的预定交付时间之间的时间差。这一参数用“时间”衡量
[参数 22]未完整或未正确实现的首次服务变更:在首次尝试中未完整或未正确执行的服务变更与要求变更的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 23] 服务变更的合格率与成功率: 服务变更未按规定执行而需要返工或再次变更的合同数与需要变更的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 24]变更后约定期限内服务的技术可靠性:服务变更后无限制的观察阶段数与执行的服务变更总数之比。这一参数用“比率或百分比”衡量。
[参数 25]服务供应商执行服务变更时的组织效率:为达到客户需求或合同承诺而执行服务变更时的组织和硬件资源的可用性。这一参数用“意见评级”衡量。

ICT服务的技术升级
[参数 26] 执行服务技术升级的用时:用户被告知技术升级的瞬间与执行技术升级的瞬间之间的时间差。这一参数用“时间”衡量。
[参数 27]特定时间段内成功的技术升级:在特定时间段内成功执行的技术升级数与同样时间内的总技术升级数目之比。这一参数用“比率或百分比”衡量
[参数 28]服务技术升级时实现规定的完整性:在指定期间内,达到所有规范要求的成功的技术升级数与包含升级内容的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 29] 约定的技术升级的准时性:实际的技术升级时间和服务提供商宣布的技术升级时间之间的时间差。这一参数用“时间”衡量。
[参数 30] 因技术升级而产生的停机时间:因技术升级而导致无法使用服务的全部或部分功能的持续时间。这一参数用“时间”衡量。
[参数 31]未完整或未正确实现的首次技术升级: 在首次尝试中未完整或未正确实现技术升级的合同数与总合同数目之比。这一参数用“比率或百分比”衡量。
注 –这一指标显示了SP在首次尝试中完整并正确实现技术升级的能力。
[参数 32]技术升级的成功率和合格率:未按规定执行而需要返工或再次升级或需要其他资源来进行纠正的技术升级数与需要升级的合同总数之比。这一参数用“比率或百分比”衡量。
[参数 33]技术升级后约定期限内服务的技术可靠性:技术升级后特定时间内表现令人满意的升级数与执行的升级总数之比。这一参数用“比率或百分比”衡量。
[参数 34]服务供应商执行技术升级时的组织效率: 为达到客户需求或合同承诺而执行技术升级时的组织和硬件资源的可用性。这一参数用“意见评级”衡量。
[参数 35]服务供应商进行技术升级时的竞争力和准备的充分程度:为用户利益而进行服务相关技术升级时的能力水平(竞争力)和主动程度(准备的充分程度)。这一参数用“意见评级”衡量。

服务文档(操作说明)
[参数 36]文档的交付时间:服务供应的瞬间与调试文档和服务使用说明交付到客户的瞬间之间的时间差。这一参数用“时间”衡量。
注 –在指定超时期限内未交付的文档将被认为是未及时交付的。
[参数 37]特定时间段内文档的可用性:在特定时间段内,已提供文档的合同数和预计要提供文档的合同数之比。这一参数用“比率或百分比”衡量。
[参数 38]文档的完整性和准确性:与所有服务功能使用和维护有关的信息的准确性、完整性和对用户的友好性。这一参数用“意见评级”衡量。
[参数 39]文档模式:提供给客户或服务用户的文档的模式数。这一参数用“数字”衡量。
[参数 40]文档的易读性:信息呈现时的视觉清晰度、语言易读性和布局美观性,都是平均而言的。这一参数用“意见评级”衡量。
[参数 41]文档服务的整体可靠性:对于一个给定的服务,由SP提供的文档和相关的支持活动的持续的可靠性、完整性和速度。这一参数用“意见评级”衡量。

服务供应商提供的技术支持
[参数 42]技术支持的可达性:成功获取技术支持的尝试数和总尝试数的比例。这一参数用“比率或百分比”衡量
[参数 43]在特定时间段内实现的技术解决方案:在特定时间段内成功应用了技术解决方案的合同数和相同时间段寻求并应用解决方案的合同总数。 这一参数用“比率或百分比”衡量。
[参数 44]解决方案成功之前的尝试数:技术要求得到成功解决之前的尝试次数。 这一参数用“数目”衡量。
[参数 45]技术解决方案的完整性:在特定时间段内,成功的解决方案数目和总的技术请求数之间的比例。这一参数用“意见评级”衡量。
[参数 46]实现的技术解决方案的可靠性:技术解决方案实行后特定时间段内不出错服务数与要求并应用了技术支持的总服务数。这一参数用“比率或百分比”衡量。
[参数 47]技术支持的模式:提供给客户或服务用户的技术支持的模式数。这一参数用“数字”衡量。

服务供应商提供的商业支持
[参数 48]商业支持的可达性:成功获取商业支持的尝试数和总尝试数的比例。这一参数用“比率或百分比”衡量。
[参数 49]商业解决方案的交付时间:客户提出商业支持的瞬间到实现解决方案的瞬间之间的时间差。这一参数用“时间”衡量。
[参数 50]在特定时间段内实现的商业解决方案:在特定时间段内成功应用了商业解决方案的合同数和相同时间段寻求并应用解决方案的合同总数。 这一参数用“比率或百分比”衡量。
[参数 51]服务供应商实现的商业解决方案的完整性:在特定时间段内,成功的解决方案数目和总的商业支持请求数之间的比例。这一参数用“意见评级”衡量。
[参数 52]商业支持的模式:提供给客户或服务用户的商业支持的模式数。这一参数用“数字”衡量。
[参数 53] 商业支持的组织效率:为满足客户的商业支持所需的组织资源的可用性。这一参数用“意见评级”衡量。

投诉管理
[参数 54] 投诉管理的可访问性:在特定时间段内成功达到投诉管理(CM)的尝试数与总尝试数之比。这一参数用“比率或百分比”衡量。
[参数 55] 用户投诉的识别:被SP视为真正的投诉数与潜在的投诉总数之比。这一参数用“比率或百分比”衡量。
[参数 56]未完整或未正确实现的首次投诉解决方案:在首次尝试中未完整或未正确解决的投诉数与服务供应商收到的投诉总数之比。这一参数用“比率或百分比”衡量。
注 –这一指标显示了SP在首次尝试中完整并正确处理客户投诉的能力。
[参数 57]投诉解决方案的完整性: 针对投诉成因的完整而专业的解决方案数与接收到的总投诉数目之比。这一参数用“比率或百分比”衡量。
[参数 58]投诉管理的客户感知:服务供应商在从收到投诉到给出圆满的解决方案的过程中所展现出的信心、同情心和响应能力。这一参数用“意见评级”衡量。
[参数 59]投诉管理流程的整体质量:投诉管理服务的可访问性的综合效果,包括在首次尝试时成功的解决方案、解决方案提供的速度以及执行这些服务时的组织能力。这一参数用“意见评级”衡量。
[参数 60]投诉管理系统的组织效率: 解决客户投诉时所表现出的组织和硬件资源的可用性及部署能力。这一参数用“意见评级”衡量。

维修服务
[参数 61]维修服务的可达性:将服务(及其功能)恢复到特定的性能水平时所需的软硬件以及人力资源的可达性。这一参数用“比率或百分比”衡量。
[参数 62] 在特定时间段内成功执行的维修: 在特定时间段内,成功执行的维修数与SP接受的维修请求总数之比。这一参数用“比率或百分比”衡量。
[参数 63]未完整或未正确实现的首次维修数:特定时间段内,未在首次尝试中成功实现的维修数与同时间段内的维修总数之比。这一参数用“比率或百分比”衡量
[参数 64]预约维修的准时性: SP代理人在指定时间(如果有必要的话,可以设定一个迟到期限)进行维修的出勤记录,也可以通过客户的评价等级来表达。这一参数用“意见评级”和/或“时间”衡量。
[参数 65] 维修服务的效率:一个服务供应商的“维修服务效率”(主要是技术角度上的)是由以下几个因素综合影响的:
 *可达性,
 *特定时间段内的维修数目,
 *成功执行的首次尝试,
 *准时性
这一参数用“意见评级”衡量。
[参数 66] 维修服务的组织效率: “维修服务的组织(或操作)效率”是由以下几个因素共同影响的:
 *准时性
 *维修用时
 *(人力、软硬件)资源的提供
 *提供高效维修服务的组织后勤
这一参数用“意见评级”衡量。
[参数 67] 供应中断的根本原因的告知:将根本原因告知客户的维修数与所执行的维修总数之比。这一参数用“意见评级”衡量。

计费和收费
[参数 68] 收费信息的“可达性”:成功达到这一设施的尝试数与总尝试数之比,设施的位置在合同或规定中指明(这一设施的接入细节由服务供应商提供)。这一参数用“比率或百分比”衡量。
[参数 69] 成功执行的预算透支通知: SP成功执行的有关于客户预算透支的通知数与客户预算透支事件总数之比。这一参数用“比率或百分比”衡量。
[参数 70] 预算透支信息的通知延迟时间:预算透支的瞬间与客户收到服务供应商相应通知的瞬间之间的时间差。这一参数用“时间”衡量。
[参数 71]账户管理的可达性: 成功达到账户管理的尝试数与总尝试数之比。这一参数用“比率或百分比”衡量。
[参数 72] 更新收费信息所用的时间:开始使用服务的瞬间与可以在账户上获得相关收费信息的瞬间之间的时间差。这一参数用“时间”衡量。
[参数 73] 账单交付的及时性:在特定的观察期间内,在预期时间内交付的账单数与预期要交付的账单总数之比。这一参数用“比率或百分比”衡量。
[参数 74] 账单交付的延时:账单的预期交付时间和客户实际收到账单的时间之间的延迟。这一参数用“时间”衡量。
[参数 75] 逾期欠款通知:在从客户账户扣款之前未向其建议“直接付款”量的账单数与“直接付款”付款安排总数之比。这一参数用“比率或百分比”衡量。
[参数 76] 计费信息的传输模式数: SP与客户交流计费信息的模式数。这一参数用“数字”衡量。
[参数 77] 账单服务的的组织效率:服务供应商的“账单服务的组织效率”是通过使用执行账单时的硬件和组织资源的可用性来进行描述和衡量的。这一参数用“意见评级”衡量。

客户网络/服务管理
[参数 78] 服务中断的持续时间:在指定时间段内,一个网络/服务管理设施不可被用户访问的总时间。这一参数用“时间”衡量。
[参数 79] 服务中断的频率:在特定时间段内,网络/服务管理设施不可被客户访问的次数。这一参数用“数字”衡量。
[参数 80]回复请求的响应时间:用户请求访问网络/服务管理设施的瞬间与这一响应被执行瞬间之间的时间差。这一参数用“时间”衡量。
[参数 81] 成功的请求相应:在观察期间内,成功得到处理的客户请求与总请求数之比。这一参数用“比率或百分比”衡量。
[参数 82] 网络/业务管理服务的整体可靠性:在客户的网络/服务管理设施请求的处理和实现过程中的可用性、响应时间、响应率、正确性和完整性等性能的综合表现。这一参数用“意见评级”衡量。
[参数 83] 网络/业务管理服务的组织效率:在24/7的基础上,用SP处理和实现客户的网络/服务管理设施请求时的人力、网络等相关资源的可用性的综合影响来描述。这一参数用“意见评级”衡量。
[参数 84] 计划停运通知的可靠性:服务供应商事先告知客户的计划停运数与执行的计划停运总数之比。这一参数用“比率或百分比”衡量。
停止服务
[参数 85] 确认服务中断用时:客户发出服务中断请求的瞬间到客户收到供应商确认信息瞬间之间的时间差。这一参数用“时间”衡量。
[参数 86] 确认服务中断请求:在特定时间段内,得到确认的终端请求数与总请求数之比。这一参数用“比率或百分比”衡量。
[参数 87] 服务中断设施的可达性:成功达到服务中断设施的尝试数与总尝试数之比。 这一参数用“比率或百分比”衡量。
[参数 88] 约定的终端的实现:在特定时间段内约定的中断请求数与总请求数之比。这一参数用“比率或百分比”衡量。

 

本文转载自:http://blog.csdn.net/leixiaohua1020/article/details/13507747

abcijkxyz
粉丝 64
博文 6421
码字总数 1876
作品 0
深圳
项目经理
私信 提问

暂无文章

3_数组

3_数组

行者终成事
20分钟前
3
0
经典系统设计面试题解析:如何设计TinyURL(二)

原文链接:https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR 编者注:本文以一道经典的系统设计面试题:《如何设计TinyURL》的参考答案和解析为例,帮助...

APEMESH
今天
7
0
使用logstash同步MySQL数据到ES

概述   在生成业务常有将MySQL数据同步到ES的需求,如果需要很高的定制化,往往需要开发同步程序用于处理数据。但没有特殊业务需求,官方提供的logstash就很有优势了。   在使用logstas...

zxiaofan666
今天
10
0
X-MSG-IM-分布式信令跟踪能力

经过一周多的鏖战, X-MSG-IM的分布式信令跟踪能力已基本具备, 特点是: 实时. 只有要RX/TX就会实时产生信令跟踪事件, 先入kafka, 再入influxdb待查. 同时提供实时sub/pub接口. 完备. 可以完整...

dev5
今天
7
0
OpenJDK之CyclicBarrier

OpenJDK8,本人看的是openJDK。以前就看过,只是经常忘记,所以记录下 图1 CyclicBarrier是Doug Lea在JDK1.5中引入的,作用就不详细描述了,主要有如下俩个方法使用: await()方法,如果当前线...

克虏伯
今天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部