当前网络技术的发展使得在分组网上承载语音成为可能，并且，丰富的、 要求快速推出的业务需求促成了软交换(SoftSwitch)体系结构的出现。同时， 标志着新一代电信网络时代的到来的下一代网络(NGN)是开放的、基于IP 的网络，其中，传统的电信交换设备的功能被分离，形成独立发展的各个部 件，并且各个部件之间通过标准的协议进行配合。而在IP网络被商用化后， 作为电信业务的基础平台存在问题如下：
1、QoS(服务质量)问题：ISP(互联网服务提供商)/ICP(互联网内容 提供商)没有能力向用户保证服务质量，无法向用户收取足够的费用；且IP 网络暂时不能满足专线用户需求，很难部署实时业务，三网(有线电视网、 移动通信网和互联网)的融合也还很难落实。
2、安全问题：无处不在的黑客使得业务不时受到攻击等等，这些都将导 致无法提高用户体验，特别是使得企业用户顾虑重重。
3、管理问题：传统IP网络没有定义和设计针对公众环境的管理维护体 系，从而当网络发生故障时，无法对故障进行定位或者定位不够迅速。
4、价值链问题：传统IP网络的“免费”模式导致了“网络泡沫经济”，其急 需建立良性的运营模式，从而形成用户、ISP、ICP等的良性价值链。
在此基础上，为解决IP网络QoS、安全、管理等问题，现已提出了一种 IP电信网(IPTN)的概念和架构，对现有IP网络进行了改造。该IP电信网 可以承载传统的PSTN(公共交换电话网)业务和数据专线业务，同时支持电 信级服务质量(QoS)的IP新业务。
图1显示了IPTN的总体框架图。
如图1所示，该IPTN主要包括：业务控制层、承载控制层、逻辑承载 网和基础物理网。其中，
作为呼叫代理的CA位于业务控制层，其完成各种业务控制，该CA可 以是软交换设备、视频点播服务器(VOD Server)、虚拟专用网管理器(VPN Manager)等。
承载控制层中具有RM(资源管理服务器)，该RM的作用为：管理逻辑 承载网的资源；接受来自业务控制层的资源请求，决定是否接纳呼叫，并指 定业务流路径，控制边缘路由器(ER)完成业务感知，从而达到电信级业务 在使用前申请资源、使用中保证资源、使用后释放资源的效果。
逻辑承载网中具有边缘路由器(ER)、汇聚路由器(BR)，该ER接受承 载控制层中RM下发的QoS控制命令，完成流分类，及标签栈压入等工作。 该BR与ER一起组成MPLS(多协议标签交换)网络，通过标签栈把多条 LSP(标签交换路径)连接成一条IPTN路径，保证各种业务流能在一定QoS 保证的情况下到达目的地。
其中，多个MA管理区(域)分别对应多个资源管理器RM(例如，MA1 对应RM1，MA2对应RM2等)。
根据图1所示的IPTN的总体框架，用户可以通过呼叫发出业务请求， 经由CA、RM、ER建立与目标用户的通话。
但是，在NGN电信级IP电话应用中，运营商对于音频和视频数据流的 QoS有不同的要求，比如视频流要求的带宽比音频流大，而对于数据的延迟， 则音频流的要求相对视频流要高。而现有的技术是将视频流和音频流合在一 起作为同一个业务由RM下发，在同一条LSP路径中转发，这样两条流(视 频流和音频流)就有可能会互相影响，比如视频流的带宽会挤占音频流的带 宽，而造成通话质量下降。
由于上述缺点，运营商希望在开展IPTN可视电话业务的一次通话业务 中，能针对语音和视频分别下发流规则，从而分别进行QoS调度和带宽预留， 甚至最好使得音频流和视频流(或多种语言的语言流)分别走不同的物理链 路。
但是在现有技术中，每次RM下发IPTN业务只能有一条规则，对应一 个动作。要实现上面所述的运营商的需求，就必须针对一次通话而下发两次 业务，然而对于RM来说，由于针对一次通话的两个业务彼此是独立的，如 果分别进行流量统计，这就对计费增加了难度；而且，如果其中一个业务所 在的链路失败，而另一个业务不能感知，则会出现用户在打视频电话时只看 到画面而没有声音，或者只有声音而没有画面的情况，这种情况显然不能被 用户接受。但是如果在RM资源管理器这一级，对于上述针对一个通话的两 个业务进行统一管理，这又增加了部署和管理的难度。
因此，有必要设计一种新的流映射技术，从而实现在同一业务下，多条 流独立存在，且可以统一计流量，统一进行管理。

本发明的目的是提供根据多条流映射技术的处理业务的方法。
根据本发明的目的，本发明提供一种业务处理方法，其用于处理源用户 对目标用户的业务请求，包括：根据所述源用户的业务请求，由资源管理服 务器向所述源用户和目标用户对应的路由器分别下发所述业务的多条流映射 消息；所述源用户和目标用户对应的路由器根据所述多条流映射消息，完成 流映射安装，打开并执行策略开关，并针对流进行报文分类、QoS动作和预 留带宽；以及所述源用户和目标用户对应的路由器对所述业务的多条流进行 统一管理和计量。
根据本发明提供的业务处理方法，其中，所述业务的每条流具有不同的 规则，且对应不同的QoS指标和标签交换路径。
根据本发明提供的业务处理方法，其中，所述资源管理服务器根据链路 拓扑和资源信息判断是否接受所述源用户的业务请求。
根据本发明提供的业务处理方法，其中，所述路由器在进行流映射安装 时，如果所述业务的其中一条流安装失败，则所述业务的所有流都不会被安 装。
根据本发明提供的业务处理方法，其中，所述业务的进行过程中，所述 业务的每条流使用同一物理链路或使用不同的物理链路。
根据本发明提供的业务处理方法，其中，所述业务的进行过程中，当所 述业务的一条流对应的物理链路出现问题时，所述路由器向所述资源管理服 务器上报，且在所述资源管理服务器的指令下，删除该条流所属业务的所有 流。
根据本发明提供的业务处理方法，其中，属于同一业务的多条流在源用 户侧完成拆分。
根据本发明提供的业务处理方法，其中，属于同一业务的多条流在所述 资源管理服务器侧完成拆分。
根据本发明提供的业务处理方法，其中，所述资源管理服务器在一次通 话中同时下发属于一个业务的多条流映射。
根据本发明提供的业务处理方法，其中，所述资源管理服务器在一次通 话中多次下发属于一个业务的多条流映射。
本发明的有益效果是：本发明可以在一个IPTN业务中使用多条规则， 执行不同的动作，从而在一次通话中为语音和视频分别预留各自的带宽，保 证各自不同的QoS指标，并且在同一IPTN业务下，多条流是独立存在。另 外本发明也可以实现针对流的统一计量和统一管理。
附图说明
图1显示了IPTN的总体框架图；
图2显示了依照本发明的IPTN业务的处理流程。

图2显示了依照本发明的IPTN业务的处理流程。其中，IPTN业务的呼 叫系统包括NGN业务单元100(呼叫代理100)、多个资源管理服务器(RM1、 RM2、RM3)、对应RM1的MA1(管理区1)、对应RM2的MA2(管理区2)、 对应RM3的MA3(管理区3)、在各个MA中的ER和BR、以及用户终端A 和B。该用户终端A的IP地址属于管理区1，该用户终端B的IP地址属于 管理区3。
如图2所示，本发明的IPTN业务的呼叫建立流程具体如下：
步骤1：用户终端A发起呼叫，触发业务请求。
步骤2：NGN业务单元100对来自用户终端A的业务请求进行分析，获 取通话双方的IP地址(用户终端A和目标通话用户终端B的地址)、以及 TCP/UDP端口号，并且根据该业务请求中音频和视频数据流所需的QoS指 标，向RM1申请资源。
步骤3：RM1搜集链路拓扑和资源信息，分别计算本地所管理的资源情 况，只有满足每一个资源请求(例如QoS音频和视频数据流各自的请求)， 呼叫才会被接纳；如果RM1发现资源不足以建立连接，或者其中某一条请求 的资源不满足，就拒绝用户终端A的呼叫，则RM1向NGN业务单元100返 回呼叫失败；如果用户终端A的呼叫的每一个资源请求都可以被接纳，则继 续建立呼叫连接。
步骤4：RM1在接纳用户终端A的呼叫后，根据通话双方的IP地址，按 照预定的选路策略进行选路，将选路结果向下一个域(对应于MA2)的RM2 发出该资源请求，该RM2收到请求后同样根据资源使用情况确定接纳还是拒 绝用户终端A的呼叫，如果接受则根据选路结果再次向下一个域(对应于 MA3)的RM3发出资源请求，
如果RM3同样接收该资源请求，由于RM3接收的资源请求信息中的目 的IP地址(目标通话用户终端B的地址)属于本域，则用户终端A的呼叫 被接纳。
步骤5：在用户终端A的呼叫被接纳的情况下，RM3通过COPS(通用 开放策略服务)协议，向对应于目的IP地址(目标通话用户终端B的地址) 的ER下发多条流映射请求，其中，RM3将多条数据流(音频流、视频流等) 的请求在同一个业务中下发，每条流具有不同的规则(例如音频流可能使用 UDP的2001端口号，而视频流可能使用UDP的2002端口号)，且各自对应 不同QoS指标以及LSP路径。
步骤6：对应于目标通话用户终端B的ER在接收到RM3下发的流映射 请求消息后，从该流映射请求消息中解析出每一条流的信息，分别安装在本 地，如果其中一条流映射安装失败，则包括多条流的整个业务都不会被安装， 并且该ER向RM3上报流映射安装失败；如果在同一个业务中的所有流映射 都安装成功，则该ER向RM3上报流映射安装成功的响应消息；
其中，ER完成了多条流映射后，将打开并执行策略开关，其用于进行之 后的动作，即，针对流进行报文分类，对于匹配的流给予相应的QoS保证(执 行QoS动作，例如打优先级标记、报文镜像、报文重定向、报文统计、报文 允许、报文过滤等)及带宽预留；如果不打开并执行策略开关，ER将把报文 视为普通的流进行处理，不进行报文分类，则不能进行后续动作。之后ER 向RM3上报QoS资源响应消息，从而开展用户业务，并且ER对归属于同一 业务的多条流的流量进行统一计数。
步骤7：RM3在接收到来自上述步骤6中ER上报的QoS资源响应消息 后，根据源IP，向上一个域的RM2转发QoS资源响应消息。
步骤8：RM2在接收到步骤7中转发的QoS资源响应消息后，判断该消 息中的源IP是否属于本域，由于在本实施例中，该源IP属于对应于RM1的 域，所以RM2向上一个域的RM1转发QoS资源响应消息。
步骤9：；由于LSP(标签交换路径)是单向路径，如要要在终端用户A 和B之间建立通话，则必须在两个方向上都建立LSP路径，因此RM需要向 源IP地址和目的IP地址两者分别对应的ER下发包含内容相同、但方向相反 的业务策略的流映射请求，则此时RM1向源IP地址(终端用户A)对应的 ER下发同一个业务的多条流映射请求。
步骤10：如同步骤6，源IP地址(终端用户A)对应的ER完成多条流 映射后，将执行策略开关，针对流进行报文分类，对于匹配的流给予相应的 QoS保证及带宽预留，向RM1上报流映射安装成功的响应信息，从而开展用 户业务，并且ER对归属于同一业务的多条流的流量进行统一计数。
步骤11：RM1在接收到流映射安装成功的响应信息后，此时通话的双向 路径(用户终端A和目标通话用户终端B之间的路径)已准备就绪，向NGN 业务单元100上报QoS资源响应消息。
步骤12：NGN业务单元100在接收到步骤11中上报的QoS资源响应消 息后，完成连接建立过程，则目标通话用户终端B的振铃响起，用户B可使 用本发明提供的IPTN业务。
其中，在用户终端A请求的业务进行的过程中，根据资源情况和选路结 果，该请求的业务包含的多个流可能使用同一条物理链路，也可能使用不同 的物理链路，如果其中一条流对应的链路出现问题，则ER将向RM上报流 对应的LSP Down的消息，且RM在搜索到该LSP对应的业务后，向ER下 发流映射删除的命令，从而ER会将这条流对应的业务下的所有流全部删除。
例如，如果一业务包括音频流和视频流，且音频流对应的链路出现问题 时(即此时只有图像没有声音)，则ER将向RM上报流对应的LSP Down的 消息，且RM在搜索到该LSP对应的业务后，向ER下发流映射删除的命令， 从而ER会将该业务包括的音频流和视频流全部删除。从而通过统一管理， 避免了只有声音而没有画面的情况的发生。
如上所述，由于本发明中是通过RM向ER下发多条流映射的流安装命 令，所以可以在一个IPTN业务中使用多条规则(例如针对音频和视频的不 同规则)，执行不同的动作(例如针对音频和视频的不同QoS动作)，从而在 一次通话中为语音和视频分别预留各自的带宽，保证各自不同的QoS指标。
值得注意的是，本实施例只示例的显示了3个RM，应理解的是，本实 施例也同样适应于多个RM的环境。
<修改实施例>
在上述实施例中，是在用户终端A完成了对流的拆分，且通过RM在一 次通话中同时下发一个业务的多条流(流的拆分可由现有技术完成)。
而本发明并不局限于此，也可以在RM上完成对流的拆分，从而通过RM 在一次通话中多次下发流映射，并对这多条流统一进行管理，统一计流量来 实现运营商对不同的流的不同QoS需求。
其具体过程与上述步骤1-步骤12相同，只是本实施例可以重复步骤5 以多次下发流映射。
综上所述，由于IPTN业务的应用中，运营商对不同的流有不同的QoS 需求。根据该目的，本发明通过RM向ER下发多条流映射的流安装命令， 所以可以在一个IPTN业务中使用多条规则，执行不同的动作，从而在一次 通话中为语音和视频分别预留各自的带宽，保证各自不同的QoS指标，并且 在同一IPTN业务下，多条流是独立存在。另外本发明也可以实现针对流的 统一计量和统一管理。
对该技术领域的普通技术人员来说，根据以上实施类型可以很容易的联 想到其他的优点和变形。因此，本发明并不局限于上述具体实施例，其仅仅 作为例子对本发明的一种形态进行详细、示范性的说明。在不背离本发明宗 旨的范围内，本领域普通技术人员可以根据上述具体实施例通过各种等同替 换所得到的技术方案，但是这些技术方案均应该包含在本发明的权利要求的 范围及其等同的范围之内。