本发明涉及通信技术领域， 尤其涉及一种业务处理方法、 设备及系统。 背景技术

随着 Interne t的发展, BRAS ( Broadband Remote Acces s Server , 宽 带远程接入服务器）或者 BNG ( Broadband Ne twork Ga teway, 宽带网络网 关）均需要逐渐增强各种增值业务处理能力， 如 0TT ( On the top , 在顶端） 视频处理、 DPI ( Deep Packe t Ins pec t ion, 深度才艮文检测）， 防火墙， 杀 毒等。 目前这些能力都集中在 BRAS或者 G上扩展， 但由于未来增值业务 种类多， 每扩展一种业务， 都需要对 BRAS或者 G进行软件升级， 甚至硬 件升级。 无论是软件升级还是硬件升级， 运营商都需要将 BRAS或者 G设 备下电， BRAS或者 G上的用户都将中断原有业务。 目前， BRAS或者 BNG 可以支持的用户数量十分庞大， 若进行设备下电则影响面非常大， 极大影 响用户体一险。 发明内容

本发明的实施例提供一种业务处理方法、 设备及系统， 能够在不改变 运营商原有设备的情况下进行业务扩展。

为达到上述目的， 本发明的实施例釆用如下技术方案：

一种业务处理方法， 包括：

获取待处理业务流对应的业务服务信息， 所述业务服务信息包括所述 待处理业务流的业务流标识以及与所述业务流 标识对应的业务标签；

将所述待处理业务流对应的业务服务信息发送 给业务路由器， 以使得 所述业务路由器根据所述业务服务信息处理所 述待处理业务流；

其中， 所述业务标签为经过编码处理的一个业务原子 或者为经过编码 处理的业务原子串。

一种业务处理方法， 包括：

接收控制器发送的业务服务信息， 所述业务服务信息包括第一业务流 的业务流标识和业务标签；

接收所述第一业务流， 并获取业务路由表；

根据所述业务服务信息以及所述业务路由表处 理所述第一业务流； 其中， 所述业务标签为经过编码处理的一个业务原子 或者业务原子串。 一种业务处理设备， 包括：

业务服务信息获取单元， 用于获取待处理业务流对应的业务服务信息， 所述业务服务信息包括所述待处理业务流的业 务流标识以及与所述业务流 标识对应的业务标签；

业务服务信息发送单元， 用于将所述待处理业务流对应的业务服务信 息发送给业务路由器， 以使得所述业务路由器根据所述业务服务信息 处理 所述待处理业务流；

其中， 所述业务标签为经过编码处理的一个业务原子 或者为经过编码 处理的业务原子串。

另一种业务处理设备， 包括：

接收单元， 用于接收控制器发送的业务服务信息， 所述业务服务信息 包括第一业务流的业务流标识和业务标签；

所述接收单元， 还用于接收所述第一业务流；

获取单元， 用于获取业务路由表；

处理单元， 用于根据所述业务服务信息以及所述业务路由 表处理所述 第一业务流。

一种业务处理系统， 其特征在于， 包括上述的两种业务处理设备。 本发明实施例提供的业务处理的方法、 设备及系统， 通过使用业务原 子或业务原子串来标识业务处理顺序， 并生成与业务原子或业务原子串对 应的业务服务信息， 以使得业务路由器以及与所述业务路由器相邻 的业务 服务器根据所述业务服务信息处理待处理的业 务流， 在本实施例提供的业 务处理方式下， 新业务的开发就转变为对已有的业务原子重新 进行组合， 或者添加新的业务原子， 使得运营商仍然可以使用已有的设备继续处理 业 务， 从而能够在不改变运营商原有设备的情况下进 行业务扩展。 附图说明

为了更清楚地说明本发明实施例或现有技术中 的技术方案， 下面将对 实施例或现有技术描述中所需要使用的附图作 简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明的一些实施例 ， 对于本领域普通技术人员 来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附 图。

图 1为本发明实施例 1中的一种业务处理的方法流程图；

图 2为本发明实施例 1中的另一种业务处理的方法流程图；

图 3为本发明实施例 1中的一种业务路由网络架构的组成框图； 图 4为本发明实施例 1中的另一种业务路由网络架构的组成框图； 图 5为本发明实施例 1中的一种业务处流程的信息交互图；

图 6为本发明实施例 1中的另一种业务处理流程的信息交互图； 图 7为本发明实施例 1中的再一种业务处理流程的信息交互图； 图 8为本发明实施例 1中的一种网络连接结构框图；

图 9为本发明实施例 1中的一种业务处理方法的流程图；

图 10为本发明实施例 1中的另一种网络连接结构框图；

图 11为本发明实施例 1中的另一种业务处理方法的流程图； 图 12为本发明实施例 1中的一种业务处理设备的组成框图； 图 13为本发明实施例 2中的另一种业务处理设备的组成框图； 图 14为本发明实施例 2中的另一种业务处理设备的组成框图； 图 15为本发明实施例 2中的另一种业务处理设备的组成框图； 图 16为本发明实施例 2中的另一种业务处理设备的组成框图； 图 17为本发明实施例 2中的另一种业务处理设备的组成框图； 图 18为本发明实施例 2中的另一种业务处理设备的组成框图； 图 19为本发明实施例 2中的另一种业务处理设备的组成框图； 图 20为本发明实施例 2中的另一种业务处理设备的组成框图； 图 21为本发明实施例 2中的另一种业务处理设备的组成框图； 图 22为本发明实施例 1中的一种业务处理系统的组成框图；

图 23为本发明实施例 2中的另一种业务处理系统的组成框图。 具体实施方式

下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实 施例， 都属于本发明保护的 范围。

实施例 1

本发明实施例提供了一种业务处理方法， 该方法例如为控制器侧的方 法， 如图 1所示， 包括：

101、 获取待处理业务流对应的业务服务信息。

其中， 所述业务服务信息包括所述待处理业务流的业 务流标识以及与 所述业务流标识对应的业务标签， 所述业务标签为经过编码处理的一个业 务原子或者业务原子串， 所述业务原子串为至少两个业务原子按照一定 顺 序排列形成的序列。 其中， 所述业务原子用于标识处理所述待处理业务流 需要的一个业务处理步骤。 所述编码指釆用不同的二进制数或多进制数来 表示不同的业务原子或者业务原子串。

举例来说， 如果一个业务流需要一个业务处理步骤， 则对应该业务流 的业务标签为经过编码处理的一个业务原子； 如果一个业务流需要多个业 务处理步骤， 则对应该业务流的业务标签为经过编码处理的 多个业务原子 串。

102、 将所述待处理业务流对应的业务服务信息发送 给业务路由器， 以 使得所述业务路由器根据所述业务服务信息处 理所述待处理业务流。

本发明还提供了一种业务处理的方法， 该方法例如为业务路由器侧的 方法， 如图 1所示， 包括：

201、 接收控制器发送的待处理业务流对应的业务服 务信息。

其中， 所述业务服务信息包括待处理业务流的业务流 标识以及与所述 业务流标识对应的业务标签。 其中， 所述业务标签为经过编码处理的一个 业务原子或者业务原子串， 所述业务原子串为至少两个业务原子按照一定 顺序排列形成的序列。 其中， 所述业务原子用于标识处理所述待处理业务 流需要的一个业务处理步骤。 所述编码指釆用不同的二进制数或多进制数 来表示不同的业务原子或者业务原子串。

202、 接收所述待处理业务流， 并获取业务路由表。

其中， 所述获取业务路由表可以通过以下两种方式实 现， 具体包括： 方式一： 接收控制器发送的业务路由表信息， 并根据所述业务路由表 信息生成业务路由表。

其中， 所述业务路由信息由控制器根据业务处理路径 信息生成， 所述 业务处理路径信息用于指示处理所述待处理业 务流需要的跳数以及每一跳 涉及的业务原子种类和数量。

方式二： 获取业务路由器中已存储的业务路由表。

其中， 所述业务路由表为预先生成并存储在所述业务 路由器中的， 可以为 集中式业务路由表和分布式业务路由表中的任 意一种。

举例来说， 所述集中式业务路由表可以包括业务流标识、 业务流的处 理顺序编号、 处理顺序编号对应的输出端口以及处理顺序编 号对应的下一 跳业务标签； 所述分布式业务路由表可以包括下一跳业务处 理设备对应的 业务原子处理能力、 对应的输出端口和对应的地址信息。

203、 根据所述业务服务信息以及所述业务路由表处 理所述待处理业务 Ί。

本发明实施例提供的业务处理的方法， 通过使用业务原子或业务原子 串来标识业务处理顺序和业务处理类型， 并生成与业务原子或业务原子串 对应的业务服务信息， 以使得业务路由器以及与所述业务路由器相邻 的业 务服务器根据所述业务服务信息处理待处理的 业务流。 在本实施例提供的 业务处理方式下， 新业务的开发转变为对已有的业务原子重新进 行组合， 或者添加新的业务原子， 使得运营商可以使用已有的设备处理新业务， 从 而能够在不改变运营商原有设备的情况下进行 业务扩展。

本发明实施例又提供了一种业务处理方法， 可以应用在如图 3 所示的 业务路由网络架构中，该网络架构包括：控制 器、宽带网络网关（Broadband Network Ga teway, BNG ),业务路由器、业务服务器、第三方业务（ Thi rd Par ty Service )设备。 其中， 业务服务器若包含业务路由功能则转变为业务 路由 器。

其中， 控制器包括： 网络抽象模块， 用于将各种网络设备和服务器， 例如， 业务路由器（Service Router )和业务服务器（Service Server ) 抽象为一个整体，从而对于各种控制模块，例 如接入控制（Acces s Control ) 模块、 业务路由控制 （Service Rout ing Control )模块等， 看到的是一个 抽象的业务路由虚拟网络（即只看到具有业务 路由功能的节点和具有业务 处理能力的节点或服务器）， 实现对底层物理硬件的屏蔽和对诸如接入设 备、 路由器和交换机等设备形态的屏蔽。

业务抽象模块， 用于将控制器内部可编辑的业务或网络处理资 源， 抽 象为对用户可见的业务原子或业务原子串，或 对第三方可开放的 API ( Appl ica t ion Programming Interface , 应用程序编程接口 )。

开放云接口 （Open Cloud Interface ) 用于为第三方提供云管理、 云 控制、 云承载等方面的云协作标准接口， 在本网络架构中可以以开放应用 程序编程接口 （Open API ) 的形式被定义， 例如 Open API可以是业务原子 API , 或者业务路由 API , 所述业务原子 API用于为第三方构建自己的业务 提供接口， 所述业务路由 API 用于为第三方构建自己的虚拟业务路由网络 提供接口。

在上述网络抽象模块和业务抽象模块之间为各 种控制模块， 包括： 接入控制 （Acces s Control )模块， 用于实现接入控制功能， 例如用 户认证、动态主机西己置协议（ Dynamic Hos t Conf igura t ion Protocol, DHCP ) 等功能。 所述接入控制模块还可以用于获取待处理业务 流的业务服务信息。

业务路由控制 （Service Rout ing Cont rol )模块， 用于生成和维护业 务路由表， 并根据业务流对应的业务原子或业务原子串为 业务流生成业务 处理路径信息。

业务原子化（Service Atomiza t ion )模块， 用于注册服务器的业务原 子处理能力。

业务原子串生成（Servi ce Cha in Orches tra t ion )模块， 用于根据业 务服务信息、 业务策略、 用户策略等信息生成业务原子串。

其中， 本实施例中的业务路由器可以用于对业务流中 的报文添加、 更 改或删除业务标签， 并根据业务路由表进行报文转发。 本实施例中的业务 服务器可以用于处理 CT ( Te leCom , 电信） 业务和 IT ( Informa t ion Technology, 信息技术）业务， 并提供相应的业务原子处理机， 如 CT业务 原子处理机， IT业务原子处理机。 业务服务器可以由电信运营商提供， 也 可以由第三方提供。

本实施例中， 控制器实现接入控制和业务路由控制。

举例来说， 如果将业务路由器作为中小规模宽带业务网关 ， 那么控制 器可以内嵌于业务路由器中， 形成如图 4 所示的业务路由网络架构中， 从 而可以进一步减少网络时延、 提高性能并且简化控制。

需要说明的是， 所述控制器可以具有三种控制模式： 用户认证控制模 式、 随路控制模式和信令控制模式。 所述业务路由器处理业务流时可以有 两种处理方式， 包括集中式业务路由处理方式和分布式业务路 由处理方式。

基于上述描述的如图 3 所示的网络框架， 当控制器使用用户认证控制 模式时， 本发明实施例提供了一种业务处理方法， 如图 5 所示， 该方法包 括：

301、 在认证、 授权和计费 ( Authentication, Authorization and Accounting, AAA )服务器中， 预先配置有用户所对应的业务服务信息； 或 者， 由第三方设备调用 Open API, 在 AAA服务器中生成用户所对应的业务 服务信息， 所述业务服务信息包括用户的待处理业务流对 应的业务流标识 和与业务流标识对应的业务标签。

对于一个用户， 可能会拥有多项业务， 每项业务对应的业务流具有各 自的业务服务信息。

302、 Access Control模块作为 AAA客户端或代理与 AAA服务器交互用 户认证消息。 若 Access Control模块接收到 AAA服务器发送的用户认证成 功的消息（如 AAA的接入允许消息）， 则执行步骤 303; 否则执行步骤 312。

其中， 与 AAA服务器交互用户认证消息的具体步骤为本领 域技术人员 公知的技术， 本发明实施例在此不进行详细描述。

303、 Access Control模块从 AAA服务器获取用户所对应的业务服务信 息。

其中， 所述用户所对应的业务服务信息可以携带在所 述用户的用户认 证消息中。举例来说， 可以将用户所对应的业务服务信息携带在扩展 的 AAA 的接入允许消息中， 所述扩展例如可以通过在 AAA 的接入允许消息中增加 新的属性或选项来实现。

304、 Access Control模块将所述业务服务信息发送给 Service Chain Orchestration模块。

305、 Service Chain Orches trat ion模块对所述业务服务信息中的业 务标签进行解码处理得到相应的业务原子或业 务原子串。

306、 Service Chain Orches trat ion模块根据 Service Atomizat ion 模块中注册的业务原子处理能力判断是否能够 处理所述业务原子或业务原 子串， 若能够处理所述业务原子或业务原子串， 则当业务路由器釆用分布 式业务路由处理方式处理待处理业务流， 并且业务路由器中的业务路由表 不需要根据控制器发送的业务路由表信息生成 时， 执行步骤 307, 当业务路 由器釆用集中式业务路由处理方式处理待处理 业务流时， 或者当业务路由 器釆用分布式业务路由处理方式处理待处理业 务流， 并且业务路由器中的 业务路由表需要根据控制器发送的业务路由表 信息生成时， 则执行步骤

309; 若不能够处理所述业务原子或业务原子串， 则执行步骤 312。

307、 Service Chain Orches trat ion模块将所述业务月良务信息发送给 Service Routing Control模块。

308、 Service Routing Control模块下发所述业务服务信息给所述待 处理业务流对应的入口业务路由器， 并结束用户认证控制模式的控制流程。

309、 Service Routing Control模块根据 Service Atomizat ion模块 中注册的业务原子处理能力， 生成所述待处理业务流对应的业务处理路径 信息。

其中， 所述业务处理路径信息用于表示处理待处理业 务流的过程中待 处理业务流需要按顺序经过的业务路由器或业 务服务器以及每一跳业务路 由器或业务服务器分别需要按顺序处理业务原 子串中的哪几个业务原子。

310、 Service Chain Orches trat ion模块将所述业务月良务信息发送给 Service Routing Control模块。

311、 Service Routing Control模块将所述业务服务信息下发给所述 业务处理路径信息对应的业务处理路径上的首 个业务路由器， 生成所述业 务处理路径信息对应的业务处理路径上各个业 务路由器对应的业务路由表 信息， 下发业务路由表信息到相应的业务路由器， 并结束用户认证控制模 式的控制流程。

312. Service Chain Orches trat ion模块通知 Service Routing Control 模块引导业务流进入一个特定的 Web Server (网页服务器 ), 该 Web Server 会向用户解释无法进行相应服务的原因， 并结束用户认证控制模式的控制 流程。 在本实施例中， 控制器通过使用用户认证控制模式， 可以在用户通过 认证之后为用户提供对应的业务处理方式， 使得用户得到了个性化服务， 提高了用户体验。 用户认证控制模式中， 控制与承载分离， 业务路径最优， 该模式能较好兼容现有 Internet业务，较适合动态 IP (Internet Protocol, 互联网协议）地址分配的用户场景。

基于上述描述的如图 3 所示的网络框架， 当控制器使用随路控制模式 (即通过数据报文触发业务路由控制的方法） 时， 本发明实施例提供了一 种业务处理的方法， 如图 6所示， 该方法包括：

401、 业务控制 （Access Control )模块获取待处理业务流对应的业务 服务信息， 并将所述待处理业务流对应的业务服务信息发 送给 Service Chain Orchestration模块。 其中， 所述 Access Control模块获取待处理 业务流对应的业务服务信息具体可以为 Access Control模块获取控制器中 预先设置的业务服务信息， 也可以为 Access Control模块获取第三方通过 调用 Open API在控制器中生成的业务服务信息略。 具体釆用哪种方式， 本 发明实施例对此不进行限制。 其中， 业务服务信息的定义和前述的定义相 同。

402、 业务路由器接收所述待处理业务流， 将所述待处理业务流的第一 个报文或业务路由器不能识别的所述待处理业 务流的报文引导至 Service Chain Orchestration模块。

其中， 业务路由器不能识别的所述待处理业务流的报 文为该业务路由 器的路由表中查找不到该报文对应的路由信息 的报文。

403、 Service Chain Orchestration模块对接收到的所述才艮文对应的 待处理业务流进行业务识别， 根据 Access Control模块获取的该待处理业 务流对应的业务服务信息生成该待处理业务流 对应的业务原子或业务原子 串。

其中， 业务服务信息的有关描述与在前的相关描述相 同。

404、 Service Chain Orches trat ion模块才艮据注册的业务原子处理能 力判断是否能够处理所述业务原子或者业务原 子串， 若能够处理所述业务 原子或业务原子串， 则当业务路由器釆用分布式业务路由处理方式 处理业 务流， 并且业务路由器中的业务路由表不需要根据控 制器发送的业务路由 表信息生成时，执行所述步骤 405; 当业务路由器釆用集中式业务路由处理 方式处理业务流时， 或者当业务路由器釆用分布式业务路由处理方 式处理 业务流， 并且业务路由器中的业务路由表需要根据控制 器发送的业务路由 表信息生成时， 执行步骤 407; 若不能够处理所述业务原子或业务原子串， 则执行步骤 410。

405、 Service Chain Orches trat ion模块将所述业务月良务信息发送给 Service Routing Control模块。

406、 Service Routing Control模块下发所述业务服务信息给所述待 处理业务流对应的入口业务路由器， 并结束随路控制模式的控制流程。

407、 Service Routing Control模块根据 Service Atomizat ion模块 中注册的业务原子处理能力， 生成业务处理路径信息。

其中， 所述业务处理路径信息的有关描述与所述步骤 309 中的有关描 述相同。

408、 Service Chain Orchestration 模块将业务月良务信息发送给 Service Routing Control模块。

409、 Service Routing Control模块根据所述业务处理路径信息确定 业务处理路径上的首个业务路由器， 并下发业务服务信息给该首个业务路 由器， 并根据业务处理路径信息生成业务处理路径上 各个业务路由器对应 的业务路由表信息， 下发业务路由表信息到相应的业务路由器， 然后结束 随路控制模式的控制流程。

410、 业务路由器将所述待处理业务流转发出业务路 由网络， 并结束随 路控制模式的控制流程。

举例来说， 业务路由器也具有普通转发能力， 当不能够处理所述待处 理业务流对应的业务原子或业务原子串时， 对所述待处理业务流进行普通 转发， 并结束随路控制模式的控制流程。 这里所说的普通转发就是基于业 务流 文的包头信息例如 IP地址或其他地址信息进行的转发。 在本实施例中， 控制器通过使用随路控制模式， 可以对没有设置对应 的业务标签的数据进行控制和处理， 实现了对于大部分业务流和特殊的数 据包的业务处理。 该模式能较好兼容现有 Internet业务， 还可支持家庭用 户或者企业用户使用静态 IP地址的场景。

基于上述如图 3 所示的网络框架， 当控制器使用信令控制模式时， 本 发明实施例提供了一种业务处理的方法， 如图 7所示， 该方法包括：

501、 业务信令网关 （Service Signaling Gateway )接收用户发送的 业务请求信令。

502、 Service Signaling Gateway向 Access Control模块发送用户发 送的业务请求信令对应的业务需求。

503、 Access Control模块根据所述业务需求生成相应的业务� �务信息。

504、 Service Chain Orches trat ion模块根据所述业务服务信息生成 相应的业务原子或业务原子串， 根据 Service Atomization模块中注册的 业务原子处理能力判断是否能够处理所述业务 原子或业务原子串， 若能够 处理所述业务原子或业务原子串， 则当业务路由器釆用分布式业务路由处 理方式处理待处理业务流， 并且业务路由器中的业务路由表不需要根据控 制器发送的业务路由表信息生成时，执行步骤 505; 当业务路由器釆用集中 式业务路由处理方式处理待处理业务流时， 或者当业务路由器釆用分布式 业务路由处理方式处理待处理业务流， 并且业务路由器中的业务路由表需 要根据控制器发送的业务路由表信息生成时， 执行步骤 508; 否则执行步骤 510。

505、 Service Chain Orches trat ion模块将所述业务月良务信息发送给 Service Routing Control模块。

506、 Service Routing Control模块下发所述业务服务信息给所述业 务流对应的入口业务路由器， 并结束信令控制模式的控制流程。 507、

Service Rout ing Control模块根据注册的业务原子处理能力， 生成业务处 理路径信息。

其中， 所述业务处理路径信息的有关描述与所述步骤 309 中的有关描 述相同。

508、 Serv ice Cha in Orches tra t ion模块将所述业务月良务信息发送给 Service Rout ing Control模块。

509、 Serv ice Rout ing Contro l模块根据所述业务处理路径确定业务 处理路径上的首个业务路由器， 并下发业务服务信息给该业务路由器， 同 时， 根据业务处理路径信息生成业务处理路径上各 个业务路由器对应的业 务路由表信息， 并下发业务路由表信息到相应的业务路由器， 并结束信令 控制模式的控制流程。

510. Servi ce Cha in Orches tra t ion模块通知 Service Rout ing Control 模块引导业务流进入一个特定的 Web Server , 该 Web Server会向用户解释 无法进行相应服务的原因， 并结束信令控制模式的控制流程。

在本实施例中， 控制器通过使用信令控制模式， 可以对使用信令发起 业务的业务类型， 例如语音业务， 使用业务原子进行处理， 提高了业务原 子的适用性， 降低了运营商的开发成本。 该模式要求用户终端能发起与业 务相关的信令， 比较适合于 VoIP ( Voi ce over Internet Protocol , 基于 互联网协议传输的语音） 业务或其它支持信令的业务 （如端对端 Peer-to-Peer业务）。

举例来说， 本实施例中在控制器结束控制流程之后， 业务路由器可以 根据集中式业务路由处理方式或分布式业务路 由处理方式， 处理所述待处 理业务流。

在如图 3 所示的业务路由网络架构中， 业务路由器与业务服务器之间 以星状拓朴连接时， 可以使用集中式业务路由处理方式。 在如图 8 所示的 网络连接结构中， 控制器可以设置在业务路由器中， 也可以外置于业务路 由器与业务路由器相连， 业务路由器与业务服务器相互独立， 所有业务服 务器与业务路由器相连， 并且可以数据交互， 每个业务服务器之间不进行 连接， 使得业务路由器与业务服务器呈现星状拓朴连 接。

其中， 上游设备和下游设备可以为业务路由器或其他 可发送报文的网 络设备， 本发明实施例在此不——列举。

基于如图 8 所示的网络连接结构， 所述集中式业务路由处理方式的具 体步骤如图 9所示， 包括：

601、 业务路由器接收控制器发送的业务服务信息， 所述业务服务信息 包括待处理业务流的业务流标识以及与所述业 务流标识对应的业务标签。

602、 业务路由器接收待处理业务流， 并获取集中式路由表， 根据所述 集中式业务路由表中与所述待处理业务流的业 务流标识对应的第一个处理 顺序编号， 将与所述第一个处理顺序编号对应的第一下一 跳业务标签添加 到所述待处理业务流的报文中。 其中， 获取业务路由表可以通过接收控制 发送的业务路由表信息， 并根据所述业务路由表信息生成所述业务路由 表； 或者， 可以直接获取业务路由器中配置的业务路由表 。

所述集中式业务路由表如下表 1所示。

表 1 集中式业务路由表

需要说明的是， 表 1仅为单独一个控制器内 Serv i ce Rout ing Cont ro l 模块生成并维护的集中式业务路由表， 不同的控制器需要生成和维护各自 的集中式业务路由表， 表 1 内容仅用于举例， 具体实现需根据实际情况和 需要设置。

其中， 业务标签是通过对业务原子或者业务原子串编 码得到的具体的 编码方式在此不进行限制， 现有技术中可实现的编码方式均可以应用在本 发明实施例中。 举例来说， 表 1中的业务标签 54321、 12345、 11111, 分别 对应三种不同的业务原子 A、 B和 C, 而 k、 B、 C又分别代表三种不同的业 务处理操作， 按照 ABC 的顺序组合起来即为处理该业务流所需要的业 务处 理过程。

下表 2为在伪线（PW, pseduo-wire) 中传输业务流时的一种业务标签 的设置实例。 其中， 流标签用来标识业务流， 可以避免后续节点做流分类， 甚至可免做业务识别。 业务标签和在前定义相同， 为经过编码处理的一个 业务原子或者业务原子串， 所述业务原子串为至少两个业务原子按照一定 顺序排列形成的

表 2 添加业务标签后的伪线中的业务流报文的内部 结构

净荷

PW控制字

业务标签

流标备

PW标签

MPLS隧道标签

序列。 业务标签也可以设置在数据链路层上， 例如在以太网报文内部添加 业务标签， 可以使用一个虚拟局域网 ( virtual local area network, VLAN ) 标识用做业务标签。 其中， MPLS为 Multi- Protocol Label Switching, 多 协议标签交换。

603、 业务路由器将所述添加了第一下一跳业务标签 的待处理业务流的 报文通过与所述第一个处理顺序编号对应的第 一输出端口（输出端口 1 )发 送至与所述第一输出端口对应的业务服务器 1 上， 以使得所述与所述第一 输出端口对应的业务服务器 1 根据所述第一下一跳业务标签处理所述待处 理业务流的报文。

604、 业务路由器接收与所述第一输出端口对应的业 务服务器 1发送的 经过第一次处理的所述待处理业务流的报文， 并判断所述第一个处理顺序 编号是否为一个处理顺序编号。 若确定所述第一个处理顺序编号为最后一 个处理顺序编号， 则执行步骤 605。 否则执行步骤 606。

605、 业务路由器将经过第一次处理的所述待处理业 务流中携带的第一 下一跳业务标签去除， 并将所述去除了第一下一跳业务标签的经过第 一次 处理的业务流的报文从业务路由网络中转发出 去。

606、 业务路由器将携带在经过第一次处理的所述待 处理业务流的报文 中的所述第一下一跳业务标签替换为与所述第 二个处理顺序编号对应的第 二下一跳业务标签。

其中， 所述第二个处理顺序编号为如表 1 所示的集中式业务路由表中 处理顺序编号所在列的第二个处理顺序编号。

607、 业务路由器将携带了所述第二下一跳业务标签 的所述待处理业务 流的报文通过与所述第二个处理顺序编号对应 的第二输出端口发送至与所 述第二输出端口对应的业务服务器 1 上， 以使得所述与所述第二输出端口 对应的业务服务器 1根据所述第二下一跳业务标签处理携带了所� �第二下 一跳业务标签的所述待处理业务流的报文。

608、 业务路由器接收与所述第二输出端口对应的业 务服务器 2发送的 经过第二次处理的携带了所述第二下一跳业务 标签的所述待处理业务流的 报文， 并判断所述第二个处理顺序编号是否为最后一 个处理顺序编号。 若 确定所述第二个处理顺序编号为最后一个处理 顺序编号， 将经过第二次处 理的携带了所述第二下一跳业务标签的所述待 处理业务流的报文中携带的 所述第二下一跳业务标签去除， 并将所述去除了第二下一跳业务标签的经 过第二次处理的待业务流的报文从业务路由网 络中转发出去。

需要说明的是， 在所述步骤 608 中若确定所述第二个处理顺序编号仍 然不是最后一个处理顺序编号， 则继续执行步骤 606至 608中描述的流程 直至所述待处理业务流对应的业务标签中的业 务原子被依次处理完毕。

如果如图 3 所示的业务路由网络架构中的将其中的业务路 由器、 控制 器以及业务服务器各自对应的功能集成在同一 个设备上， 则该设备就成为 业务处理设备。 这种情况下， 业务处理设备之间可以以如图 10所示的网络 连接结构连接在一起， 从而可以应用分布式业务路由处理方式。 在如图 10 所示的网络连接结构中， 每个业务处理设备都可以接收报文或发送报文 ， 业务处理设备可以两两连接， 并且能够进行数据交互。

其中， 图 10中所示的上游设备和下游设备可以为业务路� ��器或其他可 发送报文的网络设备， 并且可以与所有业务处理设备都具有连接关系 以及 数据交互能力， 图 10所示的网络连接结构只是一种示意， 具体的连接方式 本发明实施例对此不作限定。

基于如图 10所示的网络连接结构， 所述分布式业务路由处理方式的具 体步骤如图 11所示， 包括：

701、 第一业务处理设备 (图 10中的业务处理设备 0 )接收控制器发送 的业务服务信息， 所述业务服务信息包括第一业务流的业务流标 识以及与 所述业务流标识对应的业务标签。

其中， 获取分布式业务路由表可通过接收控制器发送 的业务路由表信 息， 并根据所述业务路由表信息生成所述分布式业 务路由表； 或者， 直接 获取业务路由器中配置的业务路由表。 所述第一业务流是待处理业务流。

以第一业务处理设备上的分布式业务路由表为 例， 分布式业务路由表 可以如表 3所示。

其中， 下一跳地址可以是业务处理设备的地址， 也可以是业务处理设 备的虚拟机地址， 可以使用 IP地址， 也可以使用其它具有地址标识功能的 信息， 本发明实施例对此不进行限制。 所述下一跳业务原子处理能力例如 可以使用业务原子或业务原子串进行表示。 其中， 业务处理设备可以虚拟 为多个业务服务器（即虚拟机）。 第一业务处理设备的业务路由表

其中， 需要说明的是， 所述分布式业务路由表可以由业务处理设备通 过接收控制器发送的业务路由表信息得到， 也可以由业务处理设备通过学 习相邻业务处理设备的业务原子或业务原子串 处理能力获取所述分布式业 务路由表， 或者也根据本地配置的相邻节点的业务原子处 理能力， 生成所 述分布式业务路由表。

举例来说， 所述业务处理设备通过学习相邻业务处理设备 的业务原子 或业务原子串处理能力获取所述分布式业务路 由表具体为：

业务处理设备从接收到的相邻的业务处理设备 组播或广播的消息中， 获取相邻的业务处理设备中对应的业务原子处 理能力以及所述相邻的业务 处理设备对应的地址信息；

根据所述相邻的业务处理设备对应的业务原子 处理能力、 所述相邻的 业务处理设备对应的地址信息以及与所述相邻 的业务处理设备连接的输出 端口信息生成分布式业务路由表。

进一步地， 在生成了分布式业务路由表之后， 业务处理设备仍然可以 周期性广播或组播通告其业务原子处理能力， 并接收相邻的业务处理设备 发送的组播或广播消息。 若接收到新的业务处理设备通告的业务原子处 理 能力， 则根据新的业务处理设备对应的业务原子处理 能力以及所述新的业 务处理设备的地址信息在已有分布式业务路由 表中添加新的表项。 若接收 到相邻的业务路由器通告的新的业务原子处理 能力， 则根据新的业务原子 处理能力更新所述分布式业务路由表中的该相 邻的业务处理设备的对应表 项。 可选地， 若在一定的时间内没有接收到相邻的业务处理 设备通告的业 务原子处理能力， 则可以删除该相邻的业务路由器在分布式业务 路由表中 对应的表项。

值得说明的是， 对于根据本地配置的相邻节点的业务原子处理 能力， 生成所述分布式业务路由表， 不需要业务处理设备自己去获取其它业务处 理设备的业务原子处理能力， 而由在业务处理设备本地预先配置的相邻业 务处理设备的业务原子处理能力生成所述分布 式业务路由表。 所述预先配 置的相邻业务处理设备的业务原子处理能力例 如可以由网络维护人员或者 其他工作人员进行配置。

702、 当接收到来自业务路由网络外部的所述第一业 务流时， 第一业务 处理设备根据所述第一业务流对应的业务标签 以及预定业务路由选择策 略， 在所述分布式业务路由表中查找并获得下一跳 业务处理设备对应的的 输出端口以及对应的下一跳地址， 如下一跳地址对应的业务处理设备为第 二业务处理设备 (图 10中的业务处理设备 1；)。

其中， 所述预定业务路由选择策略包括最长前缀匹配 策略和最佳业务 特性匹配策略。

举例来说， 所述最长前缀匹配策略可理解为： 如果待处理业务流对应 的业务原子串为 ABCD, 则按照表 3的分布式业务路由表， 应该选择输出端 口 4对应的业务处理设备， 因为输出端口 4对应的业务处理设备可以处理 业务原子 A; 当业务流对应的业务原子串为 BCAD, 则按照表 3的分布式业 务路由表中显示的内容， 应该选择输出端口 3对应的业务处理设备， 因为 输出端口 3对应的业务处理设备可以处理业务原子组合 BC, 相比于输出端 口为 2对应的业务处理设备， 能够连续多处理一个业务原子 C。

举例来说， 所述最佳业务特性匹配策略可理解为选择路由 费用最低的 路由。 例如， 当业务流对应的业务原子串为 BCAD, 则按照表 3的分布式业 务路由表中显示的内容， 应该选择输出端口为 3的路由， 但如果输出端口 3 对应的业务处理设备的路由费用较高， 例如传输时延较大， 这时可以转而 选择输出端口 2对应的路由费用较低的路由。

703、 第一业务处理设备将所述第一业务流对应的业 务标签添加到所述 第一业务流的报文中， 并将携带有所述对应的业务标签的第一业务流 报文 通过所述获取到的输出端口发送至所述下一跳 地址对应的第二业务处理设 备（图 10中的业务处理设备 1 ), 以使得所述第二业务处理设备根据自身的 业务原子处理能力处理所述业务流报文。

进一步地， 第一业务处理设备还可以接收相邻的业务处理 设备发送的 第二业务流， 获取所述第二业务流中的业务标签并解码为对 应的业务原子 或业务原子串， 根据所述对应的业务原子或业务原子串对所述 第二业务流 进行处理。

可选地， 第二业务处理设备接收第一业务处理设备发送 的业务流报文， 所述业务流报文中携带有所述业务流对应的业 务标签； 第二业务处理设备 根据已注册的业务原子处理能力处理所述业务 流报文； 第二业务处理设备 将已处理的业务原子从所述业务标签对应的业 务原子串中删除， 然后判断 业务原子串中是否存在剩余的业务原子。 若确定存在剩余的业务原子， 则 将所述业务流报文中的业务标签替换为删除了 业务原子的新的业务标签， 并根据所述新的业务标签， 以及可选根据预定业务路由选择策略， 在所述 分布式业务路由表中查找输出端口以及对应的 下一跳地址； 第二业务处理 设备将携带有所述新的业务标签的业务流报文 通过查找到的输出端口发送 至所述下一跳地址对应的第三业务处理设备（ 如业务处理设备 1 ), 以使得 所述第三业务处理设备根据自身的业务原子处 理能力处理所述业务流。 其 中， 所述将已处理的业务原子从所述业务标签对应 的业务原子串中删除， 举例来说， 就是当业务流的业务标签为 ABCD时， 业务处理设备 2处理了业 务原子 A,则将业务标签 ABCD中的业务原子 A删除，生成新的业务标签 BCD。

若确定不存在剩余的业务原子， 第二业务处理设备将所述业务流报文 转发出业务路由网络。

在本实施例中， 提供了两种数据处理的方式， 可以应用于不同的网络 场景中， 增加了本发明实施例的使用范围， 提高了业务可扩展性。

本发明实施例提供的业务处理的方法， 通过使用业务原子或业务原子 串来标识业务处理顺序， 并生成与业务原子或业务原子串对应的业务服 务 信息， 以使得业务路由器以及与所述业务路由器相邻 的业务服务器根据所 述业务服务信息处理待处理的业务流， 在本实施例提供的业务处理方式下， 新业务的开发就转变为对已有的业务原子重新 进行组合， 或者添加新的业 务原子， 使得运营商仍然可以使用已有的设备继续处理 业务， 从而能够在 不改变运营商原有设备的情况下进行业务扩展 。 实施例 2

本发明实施例提供了一种业务处理设备 80 ,该业务处理设备 80例如可 以为实施例 1中的控制器， 如图 12所示， 该设备包括：

业务服务信息获取单元 81 , 用于获取待处理业务流对应的业务服务信 息， 所述业务服务信息包括所述待处理业务流的业 务流标识以及与所述业 务流标识对应的业务标签。

业务服务信息发送单元 82 , 用于将所述待处理业务流对应的业务服务 信息发送给业务路由器， 以使得所述业务路由器根据所述业务服务信息 处 理所述待处理业务流。

其中， 所述业务标签为经过编码处理的一个业务原子 或者为经过编码 处理的业务原子串。

举例来说， 如图 1 3所示， 所述业务服务信息获取单元 81 包括接入控 制模块 811 , 所述接入控制模块 811用于从认证、授权和计费服务器获取所 述待处理业务流对应的业务服务信息。

举例来说， 所述业务服务信息获取单元 81包括接入控制模块 811 , 所 述接入控制模块 811 可以用于获取控制器中预先设置的所述待处理 业务流 对应的业务服务信息。

举例来说， 所述业务服务信息获取单元 81包括接入控制模块 811 , 所 述接入控制模块 811 用于接收业务信令网关发送的业务需求， 所述业务需 求为所述业务信令网关接收的用户发送的业务 请求信令对应的业务需求， 接入控制模块 811 并根据所述业务需求生成所述待处理业务流对 应的业务 服务信息。

举例来说， 如图 14所示， 所述业务服务信息发送单元 82具体包括业 务原子串生成模块 821、 业务原子化模块 822和业务路由控制模块 823; 所 述业务原子串生成模块 821 用于生成所述业务标签对应的业务原子或业务 原子串， 根据所述业务原子化模块 822 中注册的业务原子处理能力判断是 否能够处理所述业务原子或业务原子串， 若能够处理所述业务原子或业务 原子串， 当业务路由器釆用分布式业务路由处理方式处 理待处理业务流， 并且业务路由器中的业务路由表不需要根据控 制器发送的业务路由表信息 生成时， 则所述业务串生成模块将所述业务服务信息发 送给所述业务路由 控制模块 823 ,所述业务路由控制模块 823下发所述业务服务信息给所述待 处理业务流对应的入口业务路由器。

举例来说， 当业务路由器釆用集中式业务路由处理方式处 理待处理业 务流时， 或者当业务路由器釆用分布式业务路由处理方 式处理待处理业务 流， 并且业务路由器中的业务路由表需要根据所述 业务处理设备发送的业 务路由表信息生成时， 所述业务路由控制模块 823根据所述业务原子化模 块 822 中注册的业务原子处理能力， 生成所述待处理业务流对应的业务处 理路径信息； 所述业务串生成模块 821 将所述业务服务信息发送给所述业 务路由控制模块 823 ,所述业务路由控制模块 823将所述业务服务信息下发 给所述业务处理路径信息对应的业务处理路径 上的首个业务路由器， 生成 所述业务处理路径信息对应的业务处理路径上 各个业务路由器对应的业务 路由表信息， 并下发所述业务路由表信息到相应的业务路由 器。

举例来说， 如果确定不能处理所述业务原子或业务原子串 ， 所述业务 原子串生成模块 821 进一步用于将所述待处理业务流发送给一个网 络服务 器， 以使得所述网络服务器通知用户所述待处理业 务流当前不能被处理。

本发明实施例还提供了另外一种业务处理设备 90, 该业务处理设备 90 例如可以是实施例 1中所述的业务处理设备或者业务路由器，如� � 15所示， 该业务处理设备 90包括：

接收单元 91 , 用于接收控制器发送的业务服务信息， 所述业务服务信 息包括第一业务流的业务流标识和业务标签。

所述接收单元 91 , 还用于接收所述第一业务流。

获取单元 92 , 用于获取业务路由表。

处理单元 93 , 用于根据所述业务服务信息以及所述业务路由 表处理所 述第一业务流。

举例来说， 如图 16所示， 所述获取单元 92包括：

接收模块 921 , 用于接收控制器发送的业务路由表信息。

生成模块 922 , 用于根据所述业务路由表信息生成所述业务路 由表。 或者， 如图 17所示， 所述获取单元 92包括获取模块 923 , 用于直接获 取所述业务处理设备中已存储的业务路由表。

或者， 如图 18所示， 所述获取单元 92包括业务路由表学习模块 924 , 用于通过学习相邻业务处理设备的业务原子或 业务原子串处理能力获取所 述分布式业务路由表。

举例来说， 如图 19所示， 所述处理单元 93包括：

标签添加模块 931 ,用于在所述获取单元获取到的业务路由表为� �中式 业务路由表时， 根据所述集中式业务路由表中与所述第一业务 流的业务流 标识对应的第一个处理顺序编号， 将与所述第一个处理顺序编号对应的第 一下一跳业务标签添加到所述第一业务流的报 文中。

第一发送模块 932 ,用于将所述添加了第一下一跳业务标签的第� �业务 流通报文通过与所述第一个处理顺序编号对应 的第一输出端口发送至与所 述第一输出端口对应的业务服务器上， 以使得所述与所述第一输出端口对 应的业务服务器根据所述第一下一跳业务标签 处理所述第一业务流。

第一接收模块 933 ,用于接收与所述第一输出端口对应的业务服� �器发 送的经过第一次处理的所述第一业务流。

判断模块 934 ,用于判断所述第一个处理顺序编号是否为所� �业务路由 表中所述业务流标识对应的最后一个处理顺序 编号。

业务标签去除模块 935 ,用于确定所述第一个处理顺序编号为所述业� � 路由表中所述业务流标识对应的最后一个处理 顺序编号， 将经过处理的所 述第一业务流中的所述第一下一跳业务标签去 除。

所述第一发送模块 932 ,进一步用于将去除了第一下一跳业务标签的� � 述第一业务流的报文从业务路由网络中转发出 去。

业务标签替换模块 936 ,用于确定所述第一个处理顺序编号不为所述� � 务路由表中所述业务流标识对应的最后一个处 理顺序编号， 则将经过处理 的所述第一业务流中的所述第一下一跳业务标 签替换为与所述业务路由表 中所述业务流标识对应的第二个处理顺序编号 对应的第二下一跳业务标 签。

所述第一发送模块 932 ,进一步用于将携带了所述第二下一跳业务标� � 的所述第一业务流的报文通过与所述第二个处 理顺序编号对应的第二输出 端口发送至与所述第二输出端口对应的业务服 务器上， 以使得所述与所述 第二输出端口对应的业务服务器根据所述第二 下一跳业务标签处理携带了 所述第二下一跳业务标签的所述第一业务流的 报文。

所述第一接收模块 933 ,进一步用于接收与所述第二输出端口对应的� � 务服务器发送的经过处理的携带了所述第二下 一跳业务标签的第一业务流 的报文。

所述判断模块 934 ,进一步用于判断所述第二个处理顺序编号是� �为所 述业务路由表中所述业务流标识对应的最后一 个处理顺序编号。

所述业务标签去除模块 935 ,进一步用于若确定所述第二个处理顺序编 号为所述业务路由表中所述业务流标识对应的 最后一个处理顺序编号， 则 将经过处理的携带了所述第二下一跳业务标签 的所述第一业务流的报文中 携带的所述第二下一跳业务标签去除。

所述第一发送模块 932 ,用于将所述去除了第二下一跳业务标签的第� � 业务流的报文从业务路由网络中转发出去。

举例来说， 如图 20所示， 所述处理单元 93还包括：

查找模块 937 , 用于在获取到的业务路由表为分布式业务路由 表时，根 据所述业务标签以及预定业务路由选择策略， 在所述分布式业务路由表中 查找并获得下一跳业务处理设备对应的第三输 出端口以及对应的地址信 息。

携带模块 938 , 用于将所述业务标签携带在所述第一业务流中 。

第二发送模块 939 ,用于将所述第一业务流通过所述第三输出端� �发送 至所述下一跳业务处理设备， 以使得所述下一跳业务处理设备根据自身的 业务原子处理能力处理所述待处理业务流。

举例来说， 如图 21所示， 所述处理单元 93还包括；

第二接收模块 9310 ,用于接收相邻的业务处理设备发送的第二业� �流， 获取所述第二业务流中的业务标签并解码为对 应的业务原子或业务原子 串， 根据所述对应的业务原子或业务原子串对所述 第二业务流进行处理。

本发明实施例还提供了一种业务处理系统 100 , 如图 22所示， 该系统 包括： 前述的业务处理设备 80和业务处理设备 90。

当前述的业务处理设备 80为控制器， 业务处理设备 90由业务路由器 和业务月良务器组成时， 业务处理系统 100的一个实例如图 23所示。

本发明实施例提供的业务处理的设备及系统， 通过使用业务原子或业 务原子串来标识业务处理顺序， 并生成与业务原子或业务原子串对应的业 务服务信息， 以使得业务路由器以及与所述业务路由器相邻 的业务服务器 根据所述业务服务信息处理待处理的业务流， 在本实施例提供的业务处理 方式下， 新业务的开发就转变为对已有的业务原子重新 进行组合， 或者添 加新的业务原子， 使得运营商仍然可以使用已有的设备继续处理 业务， 从 而能够在不改变运营商原有设备的情况下进行 业务扩展。

通过以上的实施方式的描述， 所属领域的技术人员可以清楚地了解到 本发明可借助软件加必需的通用硬件的方式来 实现， 当然也可以通过硬件， 但很多情况下前者是更佳的实施方式。 基于这样的理解， 本发明的技术方 案本质上或者说对现有技术做出贡献的部分可 以以软件产品的形式体现出 来， 该计算机软件产品存储在可读取的存储介质中 ， 如计算机的软盘， 硬 盘或光盘等， 包括若干指令用以使得一台计算机设备（可以 是个人计算机, 服务器， 或者网络设备等）执行本发明各个实施例所述 的方法。

以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局 限于此， 任何熟悉本技术领域的技术人员在本发明揭露 的技术范围内， 可 轻易想到变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明 的保护范围应以所述权利要求的保护范围为准 。