账号:
密码:
最新动态
产业快讯
CTIMES / 文章 /
RACF架构优势探讨(下)
RACF真能一统NGN QoS江山?

【作者: 鍾慶豐】2008年01月17日 星期四

浏览人次:【7176】

目前RACF所需面对的问题

不管是RACFs或是后面即将谈到的RACS QoS控制架构,均与3GPP有关。3GPP现有的蜂巢式网络或GSM网络基础,发展了IP多媒体次系统(IMS)来控制IP多媒体服务,包含服务控制、通话区段控制...等等。虽然IMS从GSM网络延伸,但是其概念可应用在任何型态的传送技术,因此IMS架构也曾被推为一种QoS的控制架构。许多标准制订团体所提议的QoS架构中,多少存在一些IMS的影子,就连ITU-T也不例外,因此RACF或RACS能与IMS具有很好的通透性。一个IMS的参考架构如(图四)所示。


《图四 3GPP的IMS参考架构示意图》
《图四 3GPP的IMS参考架构示意图》

除此架构外,封包式(packet-based)网络有数种较为罕见的端点式QoS控制架构,不过仍以ITU-T RACF架构针对核心网络与存取网络,是最具有远大企图心的QoS控制方法。虽然目前RACF的规格中,已指定功能架构与IP层的控制程序,但还有许多开放性的问题需要解决。


一般性控制架构与异质网络环境

一般性QoS架构对异质网络而言,意味着可能需要更多的复杂性,以及面临严格的延展性问题。QoS控制机制可以利用核心网络的效能监控信息加以简化。举例来说,call-by-call的QoS控制机制,可以被控制在只有当网络监控程序侦测到网络的效能出现明显衰退的情况下,才会被启动。目前各家的QoS控制机制多与特殊运作条件有关,因此要让QoS控制机制可以在异质网络上适用,将面临高度的实作复杂度,网络间的通透性也会受到严格考验。再者,因为QoS控制机制建立基础在于建立每通呼叫程序,因此核心网络的QoS控制机制将会成为重担。对QoS实作而言,控制机制的复杂度主要集中在优化的问题,因此为了降低复杂度,最好一部份的控制功能可被嵌入于传送设备中,或者与管理功能结合在一起。


核心网络的安全与可信度

对具备有控制延展性的网络而言,核心网络的流量管理会选择在流量汇集之处,因此如果核心网络无法运作,势必影响网络流量之汇集。封包式网络不比传统电路式传送网络,因为这种IP网络并没有一个封包递送的可信特征。ITU-T在下一代网络,尝试去改善此不可信的情况,而传送MPLS(T-MPLS)与以太网络的运作、管理与维护,也将被定义以改善网络的可信度,并使封包式网络的监控能力发生效用。对诸如IPTV等新式服务而言,行动网络的QoS控制机制,相对也需要被发展。


与传送技术有关的QoS问题

在ITU-T的草案建议中,将为核心MPLS(core MPLS)、流量状态感知技术以及以太网络技术定义一些与传送技术有关的QoS控制机制。从整体网络流量工程观点来看,流量汇集与讯号汇集的一般性架构考虑,对于建立一般架构的QoS控制机制而言,非常关键。这正是目前一般化工作的主要难题所在,因为此两因素在网络之间存有差异性。


RACF的功能与功能体

PD-FE、TRC-FE和PE-FE

在RACF运作架构中有二个很重要的功能体(functional entities;FE),一个是策略决策功能体(policy decision functional entity;PD-FE),另一个则是传送资源控制功能体(transport resource control functional entity;TRC-FE)。PD-FE会依据网络中资源的可用性、用户的相关数据、服务等级同意书(SLA)以及服务优先级等,决定是否接受客户端所提出的要求。TRC-FE则负责监控整个局域网络内的拓朴架构信息以及资源状态,用以执行资源式(resource-based)的加入许可策略。TRC-FE的设计主要是用来控制传送的技术要求,而PD-FE则被用来负责与传送技术相独立的其他部分,不过目前TRC-FE内尚未定义网络层第二层的控制能力。


在RACF现有版本里,将QoS定义在传送独立的部分,例如定义在IP层。如果经过PD-FE和TRC-FE的许可,来自客户端的要求被接受,PD-FE便会传送一个流量控制信息到传送装置,并对网络内的资源进行必要分配。因此PD-FE藉由控制网络中传送装置的方式,也控制网络中的QoS能力。一般PD-FE所控制的传送装置就被称为策略执行功能体(policy enforcement functional entity;PE-FE),策略执行功能体通常位在局域网络的边界或边缘上。在一个真实的网络环境里面,PE-FE可以被实作成各种不同型态的成员存在,例如CMTS或边界路由器。


不同CPE型态的QoS

另外,在RACF中用户端与客户端设备(customer premise equipment;CPE)所定义的QoS脚本,不同的CPE类型有着各种不同的QoS发讯能力,而用户端的CPE型态通常可被归类为以下三种型态中的其中一种:


  • ●第一型(type I):终端设备没有QoS的发讯能力。


  • ●第二型(type II):终端设备可以辨识QoS服务等级。


  • ●第三型(type III):终端设备拥有QoS的发讯、路径方法与能力。



这些不同类型往往也反应其所能使用的QoS策略,对于第一型与第二型的终端设备,以push模式加以控制其QoS。第一型的终端设备的QoS要求,是由SCF所决定,因为该终端设备并不具QoS的发讯能力。如果是第二型的终端设备,因为其存有默认的QoS定义要求,所以并非由SCF来控制QoS等级。至于第三型的终端设备,则会以pull模式加以控制。


push模式或pull模式

因此QoS控制可以用push模式或pull模式,在push模式里面,一旦QoS要求定义已自SCF接收后,PD-FE会送达QoS策略到传送装置(PE-FE)里。在pull模式中,在PE-FE自终端设备享有具有路径嵌合QoS发讯能力的传讯路径收到QoS讯号后,PD-FE会自PE-FE接收到QoS要求,为了同时支持push与pull模式,在PD-FE及PE-FE之间的参考点,应具有双向传递能力。有关push与pull模式的QoS控制脚本,如(图五)所示。



《图五 在push与pull模式的QoS控制脚本示意图》
《图五 在push与pull模式的QoS控制脚本示意图》

push模式流程

在图五(A)的push模式里面,每个步骤的通讯内容如下:


  • ●.CPE先提出服务要求给呼叫发讯服务器(call signaling server;CSS),属于第一型CPE,或许就不会指定QoS参数。此时,SCF会从应用层来侦测可用合适的QoS参数。


  • ●SCF的功能主要是在识别终端CPE的IP位置及传送的服务要求,为了识别目标位置,在此或许需要一部CSS代理服务器(CSS proxy server)。


  • ●终端CPE响应服务要求。


  • ●SCF传送一个资源要求给核心网络PD-FE,资源要求涵盖了QoS需求。在图五中假设SCF可以取得目标CPE的IP位置信息,当SCF传送资源要求给PD-FE时,来源与目标IP位置同时也会被指定在讯息之中。


  • ●当PD-FE收到要求后,会基于网络营运者的营运策略做出加入决定(admission decision)。


  • ●若核心网络接受相关要求,PD-FE会传送一个要求给存取网络PD-FE(当然这),以验证存取网络之决策,前提是两个网络中的PD-FE都属同一网络营运商,或同为一个服务器。


  • ●核心网络与存取网络的PD-FE,会自TRC-FE确认资源可用性。TRC-FE主要功能在于监控局域网络的可用资源状态,并响应资源确认要求(resource check request;RCR)。不过此需注意,完成加入决策主要是由两个功能体来完成,一为PD-FE,另一则为TRC-FE。但这两者的决策依据略有差异,前者主要是由网络营运者策略做出适当加入决策;后者则依现有的资源可用性来做出决策。


  • ●在存取网络内,PD-FE会和NACF确认所需要的QoS并未超过所授权使用之最大带宽,而不需要向NACF确认用户是否有订购行为,因为此信息会在CPE连上网络时,自动push给PD-FE。


  • ●在策略确认、资源确认以及订购确认都完成后,且该要求已被系统允许,PD-FE便会对局域网络内之PE-FE进行适当控管。


  • ●当SCF自PD-FE收到所发出的资源要求响应后,便会对服务要求做出回应。



pull模式流程

如图五(B)所示,在pull模式下讯号过程其与push模式很类似,但有些差异存在,例如PD-FE不对PE-FE指定资源,而是由CPE以路径嵌合之QoS讯号对PE-FE直接要求。此外,在pull模式中,QoS控制可以两阶段完成。第一个阶段称为预授权阶段(pre-authorization),另一个阶段称为资源分配阶段(resource allocation)。


pull模式中的1~9步骤显示,应用层是以与push模式相同的方式完成QoS发讯,在这些步骤中,提出服务要求前必须先经过预先授权。一般而言,CPE可以藉由响应服务要求过程中取得授权标记。在传送者取得响应后,来源与目标CPE便可以在开始利用特定路径传送QoS讯号前,先交换服务要求的确认讯息。而在步骤11中,CPE会先起始化这些结合QoS讯号的路径,在收到QoS讯号后,PE-FE会传送QoS要求给PD-FE,以确认服务是否已被授权。另外,CPE也可能在路径结合的QoS发讯中,传送已取得之授权标记(authorization token)。如此,PD-FE只需简单确认标记值(token value),检查要求是否符合授权即可。


在PD-FE完成授权确认后,会传送门闸控制(gate control)讯号到PE-FE功能体,以开启网关并分配网络资源。在PE-FE中,路径结合式的QoS发讯能力,可被实作成终端式、探索式或是代理伺服模式。为了考虑延展性,在这几种不同形式的实作态样中,终端式与代理模式是较好的选择。不同的模式对CPE型态与能力亦有所要求,例如对CPE而言,push mode只需要应用层的发讯能力,因此控制程序也相对比较简单。当第三型CPE终端装置有路径嵌合发讯能力(path coupled signaling)时,其QoS的控制可采pull mode。


DSL论坛的QoS标准

@内文DSL论坛提出的TR-094技术报告有关多种服务递送骨架之家庭网络基础建设部分,QoS标准主要将焦点放在数字用户线存取网络资源时的一些资源控制策略。DSL网络流量控制是根据上游网络的差异性服务,亦即,家庭门闸与路由门闸(routing gateway)将数据流量分类为具有差异性服务流量或是一般网络流量。当封包送出网络时,便会鉴别流量型态,因此工作重点在于对家庭网络资源的控制,因此家庭网络中的门闸(gateway)以及网络端的多频存取服务器(bRoadband Access Server;BRAS),便成为很重要的网络成员。在DSL网络环境中的QoS,采用集中管理式,而非像Cable网络一样采取按通(call-by-call)的方式来调整QoS。


Cable Lab的QoS标准

与ITU-T所提议之RACFs架构、以及ETSI所提议之RACS不同的QoS控制架构,还有PackerCable与DSL论坛的资源控制架构。这两个均将焦点集中在特定的传送技术,例如HFC网络或DSL网络。


ITU-T与ETSI在处理QoS问题时,已将一般化的概念纳入设计之中,将有助于建立统一QoS标准。亦即,PacketCable多媒体QoS策略,是为了因应在cable网络上提供多媒体服务、所发展而来的一种可信控制策略。此架构定义了一种策略式(policy-based)媒体控制服务递送骨架。控制策略的依据包含按时或按量的数据授权和基本安全架构与资源审计机制(resource auditing mechanism)等等。这种为了光纤与铜缆混合网络(hybrid fiber and coaxial network;HFC network)所定义的动态QoS控制架构,便称为DQoS(dynamic QoS)架构,只针对HFC网络适用。


DQoS定义了呼叫设定讯号与DOCSIS接口的动态QoS控制。建立控制呼叫的呼叫管理服务器(call management server;CMS)与门闸控制器(gateway controller;GC),扮演着重要地位。CM与CMTS之间的带宽保证,由呼叫设定讯号加以动态保留。CMS或GC可以利用触发网络第二层或第三层QoS讯号的方式,藉由发送命令至CM、CMS或是多媒体终端装置(multimedia terminal adapter;MTA)的方式,保留所需要的HFC网络带宽。


后来改版的DQoS,均考虑MTA的型态,不管是嵌入式MTA或是独立式MTA,DQoS架构均有所变动以切合需要。DQoS 2.0特别针对3GPP以SIP-based为基础的呼叫设定、发展IP多媒体次系统(IP multimedia subsystem;IMS)的通透性,量身订作合适的QoS架构。


RACF与RACS的异同点

一般而言RACF与RACS非常类似,除均演变自IMS架构外,这两个团体在制订此标准时也频繁互动,因此在功能上没有太大的歧异。RACS的存取网络资源控制主要发生于第二层,在控制脚本上远比RACF少很多,若将两者比较,看似RACS只是RACF的一个次集合而已。但两个标准还是有些殊异之处,其中便是控制区域(control region)的范围。在RACF的控制区域范围,包含存取网络与核心网络。


所谓的存取网络定义,依据J. Song及M. Y. Chang等人的论述,乃指当网络流量已没有动态路径存在、而被汇集或分散的区域;而核心网络(core network)乃指IP路由开始的区域。RACF亦同时涵盖固定与行动网络,并且比RACS定义有更多可用的控制脚本。而在RACS的控制区域范围里面,包含存取网络(access network)以及核心网络的边界,不过核心网络不在RACS的关心焦点之内,因此并不需要知道核心网络的拓朴信息(topology information),RACS只关心固定网络而不包含行动网络,RACS的架构如(图六)所示。



《图六 ETSI的RACS架构概图》
《图六 ETSI的RACS架构概图》

图六显示了RACS的功能简易架构,在此有两个QoS执行点(enforcement point),一个位在网络层第二层的终点,另一个位在核心网络边界上。RACS架构的QoS机制,被放在网络层的第三层,独立于各种传送技术。当QoS控制单元、例如存取资源、加入控制功能或服务策略决定功能传送一个命令给传送装置时,QoS控制乃以推送模式(push mode)来完成。此外RACS也定义如何控制位在存取网络或核心网络边界上的IP节点,存取资源(access resource)与加入控制功能(admission control function)的功能体,则称为A-RACF,可基于存取网络资源的状态来决定加入与否,并且服务策略决定功能(service-based policy decision function;SPDF)会完成策略式决策,以及有关核心网络边界的控制。


后语

本文着重描述一般化标准的QoS控制架构RACF,学界与业界由于着重的焦点不同,在此QoS控制架构中有多种不同的标准制订主体存在。这些标准制订主体包含DSL论坛(DSL forum)、Cable Lab、ITU-T以及ETSI...等等。


在ITU-T的下一代网络(next generation network;NGN)架构中,提供了一般性的架构骨架,以涵盖这些不同标准制订主体的标准。其他主体标准多着眼于特殊问题,因此,要了解一般化的QoS标准,ITU-T的资源与加入控制功能(resource and admission control functions;RACFs)规范具有很大的参考价值。


以上所谈的QoS控制流程描述,仅是其中一种方法,实务上亦常存在各种不同的QoS控制流程脚本。例如供核心网络与存取网络使用的PD-FE,亦可能采同一模式,不一定要分设两组。而SCF也可以和核心网络与存取网络的多个PD-FE进行通讯,以避免受限于两个网络营运商之间的PD-FE通讯。至于功能体的实体位置应该在哪里,此乃实作问题。这些不同功能体在不同机器中,也可以同设在单一实体内,例如一个区段边界控制器(session border controller)通常会与PD-FE、SCF以及PE-FE等功能体,一同放在一个实体装置内。


另外,代理模式(proxy mode)也可以被用在降低发讯量上,如此PE-FE可以选择是否汇集这些QoS讯号,在pull模式中的资源控制处理比push模式更为复杂。此外,pull模式需要有路径结合的CPE QoS发讯能力,然而在pull模式下,资源控制处理虽然比较复杂一点,但是网络资源的使用却比较有效率,这是因为保留网络资源是在第二阶段才会实行所致。在RACF规范中,也定义了网络地址以及通讯端口的移转(port translation)控制功能,从网络策略角度来看,NAPT会被用在隐藏网络地址的细节,或解决地址空间的不足问题。目前在ITU组织目有关不同的QoS研究主题,分属不同的研究群组负责,如(表三)所示。


(表三) ITU有关不同的QoS研究主题分责群组

功能

次选项

负责单位

动态QoS控制能力

1.资源与加入控制

2.效能需求的发讯能力

3.QoS机制的相互影响

4.不同网络领域间的考虑

5.基础建设与引导手册

SG 11、SG 13

客观效能

1.网络效能类别的建立

2.网络效能之分配

SG 12、SG 16

效能测量与管理

SG 4、SG 12、SG 13

效能的评估

SG 12


效能的评估


相关文章
C-ITS: LTE-V2X与ETSI ITS-G5比较
5G时代加速到来,晶片大厂布局一览
从C-V2X到5G
802.11n稳扎稳打!
网络通讯用IC的设计技巧(下)
comments powered by Disqus
相关讨论
  相关新闻
» 工研院MWC 2024展会直击 5G-A无线通讯、全能助理成下一波AI风潮
» Akamai Connected Cloud打造分散式云,全新Gecko计画结合云端与边缘网路
» 台达推出5G ORAN小型基地台 实现智慧工厂整合AI应用
» 经部「2023玩学5G新视界」 引领台湾网通产业跃上国际舞台
» 取得ISO 14064-1作为净零起手式 鼎新以碳总管助力企业跨步绿色转型


刊登廣告 新聞信箱 读者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 远播信息股份有限公司版权所有 Powered by O3  v3.20.1.HK83SB7KG60STACUKB
地址:台北数位产业园区(digiBlock Taipei) 103台北市大同区承德路三段287-2号A栋204室
电话 (02)2585-5526 #0 转接至总机 /  E-Mail: webmaster@ctimes.com.tw