业务承载的处理、 检测方法以及装置 技术领域 本发明涉及通信领域， 具体而言， 涉及一种业务承载的处理、检测方法以及装置 。 背景技术 演进基站 （E-UTRAN Node B， 简称为 eNB) 和服务网关 （Serving-Gate Way, 简 称为 S-GW)之间的 S1接口属于有线连接，现有技术中，为了保证� ��端业务的连续性， 需要对 S1接口的链路进行路径保活检测， 如图 1所示。 以 eNB主动发起路径保活流 程为例， 具体为： eNB的用户面 （U-Plane) 周期性向 S-GW发送路径保活请求报文， eNB 的用户面在发出路径保活请求消息 （Echo Request) 以后会启动等待响应消息定 时器 （T3-Response Timer) , 如果在定时器超时之前收到路径保活响应消息 （Echo Response), 则认为路径可用， 如果在定时器超时以后仍未收到 Echo Response, 则立 刻重发 Echo Request消息，按照以上流程进行，在重发 N次之后仍未收到 Echo Response 消息， 则认为路径不可用， 此时， eNB的用户面会将路径不可用的消息通知给 eNB的 控制面 （C-Plane), eNB的控制面释放该路径下的所有业务承载。 由于 S1链路的传输是用户数据报协议 （User Data Protocol, 简称为 UDP) 方式， 如果在大流量或者经过多跳路由器的情况下， 路径保活请求或者路径保活响应消息很 容易在传输中丢失， 导致了路径保活检测失败， 这种情况下如果将该路径下的业务释 放， 则会给正在做业务的用户带来数据中断或者掉 话等不良体验。 针对相关技术中的上述问题， 目前尚未提出有效的解决方案。 发明内容 针对相关技术中，由于路径保活检测消息的丢 失而导致数据中断或者掉话等问题， 本发明提供了一种业务承载的处理、 检测方法以及装置， 以至少解决上述问题。 根据本发明的一个实施例， 提供了一种业务承载的处理方法， 包括： 在接收到路 径不可用消息时， 基站的控制面获取与所述路径不可用消息对应 的路径的业务承载状 态； 所述控制面根据获取的所述业务承载状态对所 述路径下的业务承载进行处理。 上述基站的控制面获取与所述路径不可用消息 对应的路径的业务承载状态，包括: 所述控制面接收基站的用户面上报的所有业务 承载的状态； 所述控制面从所述所有业 务承载的状态中获取所述路径的业务承载状态 。 当所述业务承载状态指示所述路径下有活动的 业务承载时， 上述控制面根据获取 的所述业务承载状态对所述路径下的业务承载 进行处理， 包括： 所述控制面不释放所 述路径下的业务承载。 当所述业务承载状态指示所述路径下无活动的 业务承载时， 上述控制面根据获取 的所述业务承载状态对所述路径下的业务承载 进行处理， 包括： 所述控制面释放所述 路径下的业务承载。 根据本发明的又一个实施例， 提供了一种业务承载的检测方法， 包括： 基站的用 户面检测所有的业务承载状态； 所述用户面向基站的控制面上报检测到的所述 业务承 载状态。 根据本发明的又一个实施例， 提供了一种业务承载的处理装置， 位于基站的控制 面， 包括： 接收模块， 设置为接收路径不可用消息； 获取模块， 设置为获取与所述路 径不可用消息对应的路径的业务承载状态； 处理模块， 设置为根据获取的所述业务承 载状态对所述路径下的业务承载进行处理。 上述获取模块， 包括： 接收单元， 设置为接收基站的用户面上报的所有业务承载 的状态； 获取单元， 设置为从所述所有业务承载的状态中获取所述 路径的业务承载状 态。 上述处理模块， 还设置为在所述业务承载状态指示所述路径下 有活动的业务承载 时， 不释放所述路径下的业务承载。 上述处理模块， 还设置为在所述业务承载状态指示所述路径下 无活动的业务承载 时， 释放所述路径下的业务承载。 根据本发明的再一个实施例， 提供了一种业务承载的检测装置， 位于基站的用户 面， 包括： 检测模块， 设置为检测所有的业务承载状态； 发送模块， 设置为向基站的 控制面上报检测到的所述业务承载状态。 通过本发明， 采用在接收到路径不可用消息时， 基站的控制面根据获取的当前路 径的业务承载状态对该路径下的业务承载进行 处理的技术手段， 解决了相关技术中， 由于路径保活检测消息的丢失而导致数据中断 或者掉话等问题， 进而达到了路径保活 检测消息 （例如路径保活请求或者路径保活响应消息） 的丢失时， 避免数据中断或者 掉话的效果。 附图说明 此处所说明的附图用来提供对本发明的进一步 理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中- 图 1为根据相关技术的路径保护检测的流程示意� �； 图 2为根据本发明实施例的业务承载的处理方法� �程图； 图 3为根据本发明实施例的业务承载的检测方法� �程图； 图 4为根据本发明实施例的业务承载的处理装置� �结构框图； 图 5为根据本发明优选实施例的业务承载的处理� �置的结构示意图； 图 6为根据本发明实施例的业务承载的检测装置� �结构框图； 图 7为根据本发明优选实施例的在当前路径下无� �务承载时的业务承载的处理方 法示意图； 图 8为根据本发明优选实施例的在当前路径下有� �务承载时的业务承载的处理方 法示意图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本 发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互 组合。 实施例 1 本实施例提供一种业务承载的处理方法。 图 2为根据本发明实施例的业务承载的 处理方法流程图。 如图 2所示， 该方法包括： 步骤 S202， 在接收到路径不可用消息时， 基站的控制面获取与所述路径不可用消 息对应的路径的业务承载状态； 步骤 S204，上述控制面根据获取的所述业务承载状� �对所述路径下的业务承载进 行处理。 无论路径保活检测消息 （例如路径保活请求或者路径保活响应消息） 是否丢失， 均可以采用上述处理过程对当前路径下的业务 承载进行处理， 由于基站的控制面根据 当前路径的业务承载状态对该路径下的业务承 载进行处理， 因此在路径保活检测消息 (例如路径保活请求或者路径保活响应消息） 的丢失时， 避免了数据中断或者掉话。 在步骤 S202中，上述基站的控制面获取与所述路径不� �用消息对应的路径的业务 承载状态可以采用多种实现方式， 例如可以直接通知用户面检测上述路径的业务 承载 状态， 并将检测结果上报给上述控制面， 也可以使用户面一直持续检测所有业务承载 的状态并上报给控制面， 并进行以下处理过程： 上述控制面接收基站的用户面上报的 所有业务承载的状态； 所述控制面从所述所有业务承载的状态中获取 所述路径的业务 承载状态。 对于后一种处理方式， 在具体实施时， 可以采用以下处理过程： eNB的用户面会 检测所有的业务承载的状态， 并向控制面上报各承载的活动 （User Active) 和不活动 (User Inactive)状态。 eNB的控制面收到用户面上报的路径不可用消息 以后， 判断在 当前的路径下是否有活动的承载， 即有业务进行的承载， 如果有则不理会该路径不可 用的消息， 若没有则对该消息进行处理， 对该路径下的所有业务承载释放。 正如上面所述， 当上述业务承载状态指示所述路径下有活动的 业务承载时， 上述 控制面不释放所述路径下的业务承载。 当上述业务承载状态指示所述路径下无活动的 业务承载时， 上述控制面释放所述路径下的业务承载。 实施例 2 上述实施例 （实施例 1 ) 是在基站的控制面的处理过程， 为了与控制面的处理过 程相适应， 在用户面也需要作相应的功能改进， 因此， 本实施例提供一种业务承载的 检测方法。 图 3为根据本发明实施例的业务承载的检测方法� �程图。 如图 3所示， 该 方法包括： 步骤 S302， 基站的用户面检测所有的业务承载状态； 步骤 S304， 上述用户面向基站的控制面上报检测到的所述 业务承载状态。 利用上述技术方案， 可以为基站的控制面提供获取业务承载状态的 一个基础， 为 基站的控制面获取与上述路径不可用消息对应 的路径的业务承载状态提供一种较优的 实现方式。 实施例 3 在本实施例中提供了一种业务承载的处理装置 ， 该装置用于实现上述业务承载的 处理方法， 已经进行过说明的不再赘述， 下面对该装置中涉及到模块进行说明。 如以 下所使用的， 术语 "模块"可以实现预定功能的软件和 /或硬件的组合。 尽管以下实施 例所描述的装置较佳地以软件来实现， 但是硬件， 或者软件和硬件的组合的实现也是 可能并被构想的。 图 4为根据本发明实施例的业务承载的处理装置� �结构框图。 该装 置位于基站的控制面， 如图 4所示， 包括： 接收模块 40， 连接至获取模块 42， 设置为接收路径不可用消息； 获取模块 42， 连接至处理模块 44， 设置为在所述接收模块 40接收到路径不可用 消息时， 获取与所述路径不可用消息对应的路径的业务 承载状态； 处理模块 44， 设置为根据获取模块 42获取的所述业务承载状态对所述路径下的 业务承载进行处理。 在本发明的一个优选实施方式中， 如图 5所示， 上述获取模块 42， 包括： 接收单 元 420， 连接至获取单元 422， 设置为接收基站的用户面上报的所有业务承载 的状态； 获取单元 422， 设置为从所述所有业务承载的状态中获取所述 路径的业务承载状态。 在本发明的一个优选实施方式中， 上述处理模块 44， 还设置为在所述业务承载状 态指示所述路径下有活动的业务承载时， 不释放所述路径下的业务承载； 以及在所述 业务承载状态指示所述路径下无活动的业务承 载时， 释放所述路径下的业务承载。 正如上面所述， 上述装置可以用于实现上述业务承载的处理方 法（实施例 1 )。 无 论路径保活检测消息 （例如路径保活请求或者路径保活响应消息） 是否丢失， 均可以 采用上述处理装置对当前路径下的业务承载进 行处理， 由于基站的控制面根据当前路 径的业务承载状态对该路径下的业务承载进行 处理， 因此在路径保活检测消息 （例如 路径保活请求或者路径保活响应消息） 的丢失时， 避免了数据中断或者掉话。 实施例 4 在本实施例中提供了一种业务承载的检测装置 ， 该装置用于实现上述业务承载的 检测方法。 图 6为根据本发明实施例的业务承载的检测装置� �结构框图。 该装置位于 基站的用户面， 如图 6所示， 包括： 检测模块 60， 连接至发送模块 62， 设置为检测所有的业务承载状态； 发送模块 62， 设置为向基站的控制面上报检测到的所述业务 承载状态。 利用上述检测装置， 与上述实施例中的业务承载的处理装置相对应 ， 可以为基站 的控制面提供获取业务承载状态的一个基础， 为基站的控制面获取与上述路径不可用 消息对应的路径的业务承载状态提供一种较优 的实现方式。 实施例 5 本实施例涉及基站和服务网关之间的路径检测 ， 提供一种业务承载的处理方法， 具体如下： eNB的用户面会检测所有的业务承载的状态，并 向控制面上报各承载的活动（User Active) 禾口不活云力 (User Inactive) 状态。 如图 7所示， 在当前路径下无业务承载时， 可以采用以下处理过程： 步骤 S702， eNB的控制面收到 eNB的用户面上报的路径不可用消息。 步骤 S704， eNB的控制面判断在当前的路径下有活动的业务 承载。 步骤 S706， eNB的控制面不理会该路径不可用的消息。 如图 8所示， 在当前路径下有业务承载时， 可以采用以下处理过程： 步骤 S802， eNB的控制面收到 eNB的用户面上报的路径不可用消息。 步骤 S804， eNB的控制面判断在当前的路径下没有活动的业 务承载。 步骤 S806， eNB的控制面将该路径下的所有业务承载释放。 在另外一个实施例中， 还提供了一种软件， 该软件用于执行上述实施例及优选实 施方式中描述的技术方案。 在另外一个实施例中， 还提供了一种存储介质， 该存储介质中存储有上述软件， 该存储介质包括但不限于： 光盘、 软盘、 硬盘、 可擦写存储器等。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现 ， 从而， 可以 将它们存储在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处 的顺序执行所示出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将 它们中的多个模块或步骤制作成单个集成电路 模块来实现。 这样， 本发明不限制于任 何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。