Processing

Please wait...

Settings

Settings

Goto Application

1. WO2012142978 - METHOD, RESOURCE CONTROL PROXY AND SYSTEM FOR POLICY CONTROL IN PEER-TO-PEER NETWORK

Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

[ ZH ]
对等网络中实现策略控制的方法、 资源控制代理及系统

技术领域

本发明涉及对等(P2P, Peer-to-Peer ) 网络技术,特别涉及一种 P2P网 络中实现策略控制的方法、 资源控制代理(RC-proxy, Resource Control proxy )及系统。

背景技术

P2P网络是一种分布式网络, P2P网络的参与者共享整个网络所拥有的 资源和服务,这些共享资源和服务能被网络中的其它节点直接访问而无须 经过特殊的中间实体的转发。在 P2P 网络中,每个参与者既是资源和服务 的提供者(server ) , 同时又是资源和服务的获取者 ( client ) 。 P2P网络采 用的是叠加网技术,即:节点加入到自组织的叠加(Overlay ) 网络中,并 可以使用分布式哈希表 ( DHT, Distributed Hash Table )算法实现资源的快 速查找和定位。

P2P 网络的协议主要包括: 因特网工程任务组 (IETF , Internet Engineering Task Force ) 定义的资源定位与发现 ( RELOAD , REsource LOcation And Discovery )协议, RELOAD协议详见 draft-ietf-p2psip-base-00。

RELOAD协议提供了自组织网络的基本业务, 所述基本业务包括:节点间 消息的路由、数据的存储及查找。此外, RELOAD协议还定义了节点登记 月良务器 ( Enrollment Server ) , 所述 Enrollment Server用于为节点分己节点 号、安全证书、以及 overlay网络的配置信息,其中,所述配置信息包括: 采用何种 DHT算法等。 RELOAD协议将 overlay网络中的节点分成两类, 即: Peer节点及 client端。其中, Peer节点具备 P2P消息路由、存储、以及 查找等功能, client端可以向 Peer节点发送 P2P消息,由 Peer节点进行消

息路由和数据存储, client端自身不具备 P2P层的消息路由和数据存储功能。 随着 P2P网络技术及相关协议的发展和成熟,电信网络中也开始引入 P2P网络技术,进行核心网业务的控制和处理,图 1为一种典型的引入 P2P 网络的电信网络的组网方式,如图 1 所示,该网络的设备包含:业务控制 功能( SCF, Service Control Function )实体及用户终端( UE, User Entity ) 。 其中, SCF实体作为 Peer节点加入到 Overlay网络中,所有的 SCF实体组 成一个均质化的 P2P核心网,共同完成 P2P核心网业务的控制功能。在 P2P 核心网中,每个 SCF实体的功能相同,负责用户接入、会话控制、以及业 务触发。 UE作为 client端接入到 P2P核心网中,换句话说, Overlay网络中 的 UE除了具备传统网络中 UE的功能外,还具备 P2P网络的 client端的功 能。在以下的描述中,将 SCF实体称为 SCF节点。在 P2P核心网中,每个 UE都具有负责处理 UE业务的 SCF节点,也称为负责节点。在该组网模式 下,基本呼叫的话务模型如图 2所示,假设 UE 1为主叫, UE 2为被叫, SCF 1为 UE 1的负责节点, SCF 2为 UE 2的负责节点, UE 1与 UE 2之间 的呼叫过程为: UE 1的呼叫业务经过 SCF 1处理后,发送给 SCF 2, SCF 2 将收到的业务进行处理后,发送给 UE 2。会话过程中, UE与 SCF节点之 间、以及 SCF节点与 SCF节点之间的业务信令交互采用会话初始化协议 ( SIP, Session Initiation Protocol ) , UE与 SCF节点之间、以及 SCF节点 与 SCF 节点之间的 P2P 层的交互比如 P2P 层的路由和存储等则采用 RELOAD协议。

为了保证用户通话质量,同时合理利用网络资源,运营商需要对网络 进行策略控制。 目前,策略控制系统主要包括:电信和互联网融合业务及 高级网络十办议( TISPAN , Telecommunications and Internet Converged Services and Protocols for Advanced Networking ) 的资源接纳控制子系统 ( RACS, Resource and Admission Control Subsystem ) 、国际电信联盟 ( ITU ,

International Telecommunications Union )的资源接纳功能 ( RACF, Resource and Admission Control Function )、以及第三代合作伙伴计划(3GPP, the 3rd Generation Partnership Project )的策略与计费控制( PCC, Policy and Charging Control ) ,上述策略控制系统的基本原理类似,上述策略控制系统,如图 3 所示,主要包含:应用功能(AF, Application Function ) 实体 31、策略控 制功能实体 32、以及策略执行功能实体 33。其中, AF实体 31的功能为: 对业务层进行抽象,并实现服务质量(QoS, Quality of Service ) 映射的第 一层映射,即:在获取业务会话描述协议( SDP, Session description Protocol ) 信息后,将 SDP中的信息映射成业务 QoS信息,并封装在 Diameter消息中 下发给策略控制功能实体 32; 策略控制功能实体 32的功能为:基于运营商 策略、业务 QoS请求、以及用户签约等信息制定相应的资源控制策略,并 下发给策略执行功能实体 33安装执行。策略执行功能实体 33的功能为: 在策略控制功能实体 33的指导下,进行 QoS策略实施、门控、信息上报等 操作。

现有的策略控制系统适用于传统的 IP 多媒体子系统 (IMS , IP

Multimedia Subsystem ) 网络。如果将现有的策略控制系统直接应用到引入 P2P网络技术的电信网络中,将会产生路由问题。具体地讲,当现有的策略 控制系统应用到引入 P2P网络技术的电信网络时,要求 SCF节点具备 AF 实体的功能,并和策略控制功能实体对接。由于 SCF节点存在高动态性, 在一个策略控制过程中,当 SCF节点失效或发生数据迁移后,策略控制功 能实体需将后续相关消息路由到新的 SCF节点上,但是,在现有的系统中, 策略控制功能实体对于 SCF节点的动态变化无法感知,因此,会导致后续 相关消息无法路由到正确的目标节点上。

发明内容

有鉴于此,本发明的主要目的在于提供一种 P2P 网络中实现策略控制

的方法、 RC-proxy及系统,能在 P2P网络中有效地实现策略控制。

为达到上述目的,本发明的技术方案是这样实现的:

本发明提供了一种 P2P网络中实现策略控制的方法,该方法包括: 呼叫过程中, RC-proxy收到 P2P网络中的 SCF节点发送的应用层业务 信息消息后,获取策略控制实体(PCE, Policy Control Entity )的地址信息, 之后向 PCE发送应用层 QoS请求消息;和 /或,所述 RC-proxy收到所述 PCE 发送的 Diameter消息后,获取对应的 SCF节点的地址信息,之后向 SCF节 点发送策略控制相关消息。

上述方案中,该方法进一步包括:

呼叫过程中所述 SCF节点首次向所述 RC-proxy发送消息时,所述 SCF 节点获取所述 RC-proxy的地址信息,之后与所述 RC-proxy建立连接。

上述方案中,所述获取所述 RC-proxy的地址信息,为:

所述 SCF节点加入 P2P网络时, Enrollment Server将包含所述 RC-proxy 的地址信息的配置文件下发给所述 SCF节点;或者,

所述 SCF节点从 P2P网络中的跟踪 ( tracker )服务器中查询,获取所 述 RC-proxy的地址信息;或者,

所述 SCF节点通过 DHT算法,获取所述 RC-proxy的地址信息。

上述方案中,所述 RC-proxy的地址信息为: IP地址、或为域名、或为 节点 ( Node )编号(ID, Identity )。

上述方案中,所述获取 P2P网络中的 PCE的地址信息,为:

所述 RC-proxy向 Diameter路由代理 ( DRA, Diameter Routing Agent ) 查询,获取所述 PCE的地址信息;或者,

所述 RC-proxy从本地运营商策略配置中获取所述 PCE的地址信息;或 者,

所述 RC-proxy从本地预先存储的地址信息中获取所述 PCE的地址信

上述方案中, 当所述 RC-proxy 与所述 SCF 节点之间、以及所述 RC-proxy与所述 PCE之间传送应用层 QoS请求消息及策略控制相关信息采 用的协议不同时,在向 PCE发送应用层 QoS请求消息之前,该方法进一步 包括:

所述 RC-proxy将收到的应用层 QoS请求消息进行协议转换处理; 相应的,在向 SCF节点发送策略控制相关消息之前,该方法进一步包 括:

所述 RC-proxy将收到的策略控制相关消息进行协议转换。

上述方案中,该方法进一步包括:

如果 AF实体的功能部署在所述 SCF节点上,所述 SCF节点将应用层 SDP信息映射成应用层 QoS信息,之后向所述 RC-proxy发送包含应用层 QoS信息的应用层业务信息消息;

如果 AF实体的功能部署在所述 RC-Proxy上,所述 RC-proxy将收到的 应用层业务信息消息中的应用层 SDP信息映射成应用层 QoS信息。

上述方案中,所述获取对应的 SCF节点的地址信息,为:

当所述 RC-proxy本地预先已存储对应的 SCF节点的地址信息时,直接 从本地获取对应的 SCF节点的地址信息;

当所述 RC-proxy本地未存储对应的 SCF节点的地址信息时,根据 DHT 算法从 P2P网络中查询对应的 SCF节点的地址信息。

上述方案中,在获取对应的 SCF节点的地址信息,且当所述 RC-proxy 本地预先已存储对应的 SCF节点的地址信息时,所述 RC-proxy获知对应的 SCF节点失效后,该方法进一步包括:

根据 DHT算法从 P2P网络中查询失效的 SCF节点的备份 SCF节点的 地址信息,将存储的失效的 SCF节点的地址信息更新为所述备份 SCF节点 的地址信息,之后向所述备份 SCF节点发送策略控制相关消息。 上述方案中,在向所述备份 SCF节点发送策略控制相关消息之前,该 方法进一步包括:

所述 RC-proxy与所述备份 SCF节点建立连接。

上述方案中,当 RC-proxy本地预先已存储对应的 SCF节点的地址信息, 且 RC-proxy确定收到的策略控制相关消息对应的数据已发生迁移时,该方 法进一步包括:

所述 SCF节点向所述 RC-proxy返回错误应答消息;

所述 RC-proxy收到错误应答消息后,根据 DHT算法从 P2P网络中查 询数据迁移到的目标 SCF节点的地址,将存储的对应的 SCF节点的地址信 息更新为所述数据迁移到的目标 SCF节点的地址信息,之后向所述数据迁 移到的目标 SCF节点发送策略控制相关消息。

上述方案中,在向所述数据迁移的目标 SCF节点发送策略控制相关消 息之前,该方法进一步包括:

所述 RC-proxy与所述数据迁移到的目标 SCF节点建立连接。

本发明还提供了一种 P2P网络中实现策略控制的资源控制代理,该资 源控制代理包括:获耳 4莫块及发送模块;其中,

获取模块,用于收到 SCF节点发送的应用层业务信息消息后,获取 PCE 的地址信息,并将获取的 PCE 的地址信息发送给发送模块;和 /或,收到 PCE发送的 Diameter消息后,获取对应的 SCF节点的地址信息,并将获取 的 SCF节点的地址信息发送给发送模块;

发送模块,用于收到获取模块发送的 PCE的地址信息后,向 PCE发送 应用层 QoS请求消息;和 /或,收到获取模块发送的 SCF节点的地址信息后, 向 SCF节点发送策略控制相关消息。

上述方案中,在获取 PCE的地址信息时,所述获取模块,具体用于: 向 DRA查询,获取 PCE的地址信息;或者,从本地运营商策略配置中获 取 PCE的地址信息;或者,从本地预先存储的地址信息中获取 PCE的地址 信息。

上述方案中,在获取对应的 SCF节点的地址信息时,所述获取模块, 具体用于:当本地预先已存储对应的 SCF节点的地址信息时,直接从本地 获取对应的 SCF节点的地址信息;当本地未存储对应的 SCF节点的地址信 息时,根据 DHT算法从 P2P网络中查询对应的 SCF节点的地址信息。

上述方案中,在获取对应的 SCF节点的地址信息,且当本地预先已存 储对应的 SCF节点的地址信息时,并在获知对应的 SCF节点失效后,所述 获取模块,还用于根据 DHT算法从 P2P网络中查询失效的 SCF节点的备 份 SCF节点的地址信息,将存储的失效的 SCF节点的地址信息更新为所述 备份 SCF节点的地址信息,并将所述备份 SCF节点的地址信息发送给发送 模块;

所述发送模块,还用于收到获取模块发送的所述备份节点的地址信息 后,向所述备份 SCF节点发送策略控制相关消息。

上述方案中, 当本地预先已存储对应的 SCF节点的地址信息,且确定 出到的策略控制相关消息对应的数据已发生迁移时, 所述获取模块,还用 于根据 DHT算法从 P2P网络中查询数据迁移到的目标 SCF节点的地址, 将存储的对应的 SCF节点的地址信息更新为所述数据迁移到的目标 SCF节 点的地址信息并将所述数据迁移到的目标 SCF节点的地址信息发送给发送 模块;

所述发送模块, 还用于收到获取模块发送的所述数据迁移到的目标 SCF节点的地址信息后, 向所述数据迁移到的目标 SCF节点发送策略控制 相关消息。

上述方案中,当 RC-proxy与 SCF节点之间及 RC-proxy与 PCE之间传 送应用层 QoS请求消息及策略控制相关信息所采用的协议不同时,所述发 送模块,还用于将收到的应用层 QoS请求消息、和 /或策略控制相关信息进 行协议转换处理,并将协议转换处理后的应用层 QoS请求消息、和 /或策略 控制相关信息分别发送给 PCE和 /或 SCF节点。

上述方案中,该资源控制代理进一步包括:存储模块,用于存储 PCE 的地址信息、和 /或 SCF节点的地址信息。

上述方案中,该资源控制代理进一步包括:建立连接模块,用于与 SCF 节点建立连接。

本发明还提供了一种 P2P网络中实现策略控制的系统,该系统包括: 第一 SCF节点、 RC-proxy、以及 PCE; 其中,

第一 SCF节点,用于呼叫过程中,向 RC-proxy发送应用层业务信息消 息;和 /或,接收 RC-proxy发送的策略控制相关消息;

RC-proxy, 用于收到第一 SCF节点发送的应用层业务信息消息后,获 取 PCE的地址信息,并向 PCE发送应用层 QoS请求消息;和 /或,收到 PCE 发送的 Diameter消息后,获取对应的 SCF节点的地址信息,并向第一 SCF 节点发送策略控制相关消息;

PCE, 用于接收 RC-proxy发送的应用层 QoS 请求消息;和 /或,向 RC-proxy发送 Diameter消息。

上述方案中, 所述第一 SCF 节点,还用于呼叫过程中首次向所述 RC-proxy发送消息时,获取 RC-proxy的地址信息,并与 RC-proxy建立连 接;

所述 RC-proxy, 还用于与第一 SCF节点建立连接。

上述方案中,该系统进一步包括第二 SCF节点,为第一 SCF节点的备 份 SCF节点,用于接收 RC-proxy发送的策略控制相关消息;

在获取对应的 SCF节点的地址信息,且当 RC-proxy本地预先已存储第 一 SCF 节点的地址信息, RC-proxy 获知第一 SCF 节点失效后,所述 RC-proxy, 还用于根据 DHT算法从 P2P网络中查询第二 SCF节点的地址 信息,将存储的第一 SCF节点的地址信息更新为第二 SCF节点的地址信息, 并向第二 SCF节点发送策略控制相关消息。

上述方案中,所述 RC-proxy, 还用于与第二 SCF节点建立连接; 所述第二 SCF节点,还用于与 RC-proxy建立连接。

上述方案中,该系统进一步包括:第三 SCF节点,用于接收 RC-proxy 发送的策略控制相关消息;

当 RC-proxy本地预先已存储对应的 SCF节点的地址信息,且 RC-proxy 确定收到的策略控制相关消息对应的数据已发生迁移时,所述第一 SCF节 点,还用于向 RC-proxy返回错误应答消息;

所述 RC-proxy, 还用于收到第一 SCF节点返回的错误应答消息后,根 据 DHT算法从 P2P网络中查询第三 SCF节点的地址,将存储的对应的第 一 SCF节点的地址信息更新为第三 SCF节点的地址信息,并向第三 SCF 节点发送策略控制相关消息。

上述方案中,所述 RC-proxy, 还用于与第三 SCF节点建立连接; 第三 SCF节点,还用于与 RC-proxy建立连接。

本发明提供的 P2P网络中实现策略控制的方法、 RC-proxy及系统,呼 叫过程中, RC-proxy收到 P2P网络中的 SCF节点发送的应用层业务信息消 息后,获取 PCE的地址信息,之后向 PCE发送应用层 QoS请求消息;和 / 或 ,所述 RC-proxy收到所述 PCE发送的 Diameter消息后 ,获取对应的 SCF 节点的地址信息,之后向 SCF节点发送策略控制相关消息,如此,能在 P2P 网络中有效地实现策略控制。除此以外,由于 RC-proxy会在获取对应的 SCF 节点的地址信息后,才将策略控制相关消息发送给 SCF节点,如此,在当 前处理业务的 SCF节点失效或发生数据迁移时,能将策略控制相关消息正 确地路由到对应的 SCF节点。

附图说明

图 1为现有技术中典型的引入 P2P网络的电信网络的组网方式示意图; 图 2为典型的引入 P2P网络的电信网络的基本呼叫的话务模型示意图; 图 3为传统的策略控制系统的结构组成示意图;

图 4本发明 P2P网络中实现策略控制的方法流程示意图;

图 5为实施例一实现策略控制的方法流程示意图;

图 6为实施例二实现策略控制的方法流程示意图;

图 7为实施例三实现策略控制的方法流程示意图;

图 8为实施例四实现策略控制的方法流程示意图;

图 9为本发明 P2P网络中实现策略控制的系统结构示意图;

图 10为本发明 P2P网络中实现策略控制的资源控制代理结构示意图。

具体实施方式

本发明的基本思想是:呼叫过程中, RC-proxy收到 P2P网络中的 SCF 节点发送的应用层业务信息消息后,获取 PCE的地址信息,之后向 PCE发 送应用层 QoS 请求消息;和 /或,所述 RC-proxy 收到所述 PCE发送的 Diameter消息后,获取对应的 SCF节点的地址信息,之后向 SCF节点发送 策略控制相关消息。

下面结合附图及具体实施例对本发明再作进一步详细的说明。

本发明 P2P网络中实现策略控制的方法,如图 4所示,包括以下步驟: 步驟 401 : 需要进行呼叫时, SCF节点获取 RC-proxy的地址信息,之 后与 RC-proxy建立连接;

这里,所述 SCF节点为 P2P网络中的 Peer节点,所述 SCF节点实现 的功能为:负责用户接入、会话控制、以及业务触发;

呼叫过程中 SCF节点首次向 RC-proxy发送消息时,才需要执行步驟 401 ; 连接建立后, SCF节点后续向 RC-proxy发送消息时,则不需要执行 步驟 401 , 直接可以向 RC-proxy发送消息;

在实际应用过程中, RC-proxy以 P2P的 client端接入到 P2P网络中, 具体接入过程与现有技术完全相同, 这里不再赘述;其中, SCF 节点与 RC-proxy之间采用 RELOAD协议进行路由,如此,能与现有的网络完全融 合; RC-proxy与 SCF节点之间不限制采用何种协议来传送应用层 QoS请求 消息及策略控制相关信息, RC-proxy与 SCF节点之间传送应用层 QoS请求 消息及策略控制相关信息所采用的协议具体可以是 RELOAD 协议、或 Diameter协议、或其它合适的应用层协议;

所述获取 RC-proxy的地址信息,具体为:

在 SCF节点加入 P2P网络时, Enrollment Server将包含 RC-proxy的地 址信息的配置文件下发给 SCF节点, SCF节点据此得到 RC-proxy的地址信 息;或者,

SCF节点从 P2P网络中的 tracker服务器中进行查询,得到 RC-proxy 的地址信息;或者,

SCF节点通过 DHT算法,查找到 RC-proxy的地址信息;

其中, RC-proxy加入 P2P网络后,会向 tracker服务器发起注册, tracker 服务器会存储 RC-proxy的地址信息等相关信息; RC-proxy加入 P2P网络后, 会根据 DHT算法,将自身的地址信息等相关信息存储在 P2P网络中的特定 节点上, SCF节点通过 DHT算法可以查找到 RC-proxy的地址信息;

所述地址信息具体可以是: IP地址、或域名、或 Node ID等; 如果 RC-proxy与 SCF节点之间传送应用层 QoS请求消息及策略控制 相关信息所采用的协议不为 RELOAD协议,则在与 RC-proxy建立连接时, 该方法还可以进一步包括:

SCF节点与 RC-proxy建立应用层连接;

在实际应用时, RC-Proxy作为逻辑单元,可以单独部署,也可以与其 它网元设备设置在一起,举个例子来说, RC-Proxy可以部署在 PCE上。

步驟 402: RC-proxy收到 SCF节点发送的应用层业务信息消息后,获 取 PCE的地址信息,之后向 PCE发送应用层 QoS请求消息;和 /或, RC-proxy 收到 PCE发送的 Diameter消息后,获取对应的 SCF节点的地址信息,之后 向 SCF节点发送策略控制相关消息;

这里,所述应用层业务信息消息包括: SCF 节点的地址信息、用户标 识、应用层业务信息、以及 SCF与 RC-proxy ( SR, SCF-RC-proxy )之间会 话的会话标识;其中,所述应用层业务消息为:应用层 SDP信息或应用层 QoS信息; 具体地,如果 AF实体的功能部署在 SCF节点上, SCF节点将 应用层 SDP信息映射成应用层 QoS信息,之后携带在应用层业务信息消息 中发送给 RC-proxy,如果 AF实体的功能部署在 RC-Proxy上,则 SCF节点 向 RC-proxy发送的应用层业务信息为应用层 SDP信息, RC-proxy收到应 用层 SDP信息后,将应用层 SDP信息映射成应用层 QoS信息;其中,应 用层 SDP信息和应用层 QoS信息的具体映射方式为现有技术;

在实际应用时, RC-proxy与 PCE之间传送应用层 QoS请求消息及策略 控制相关信息所采用的协议采用为 Diameter协议。当 RC-proxy与 SCF节 点之间、以及 RC-proxy与 PCE之间传送应用层 QoS请求消息及策略控制 相关信息所采用的协议不同时, RC-proxy将收到的应用层 QoS请求消息及 策略控制相关信息进行协议转换处理后,再发送给 PCE或 SCF节点;其中, 进行协议转换的具体处理过程可采用现有的协议转换处理流程;

所述 PCE 的功能与现有技术中的策略控制功能实体完全相同,所述 PCE具体可以是: 3GPP PCC中的策略与计费规则功能(PCRF, Policy and Charging Rules Function ) 实体、或 TISPAN的 RACS中的基于业务的策略 决策功能( SPDF, Service-based Policy Decision Function ), 或 ITU的通用 RACF ( x-RACF );

所述 diameter消息具体可以是确认消息、或时间上报消息、或其它策 略控制相关消息;

所述获取 PCE的地址信息,具体为:

RC-proxy向 DRA查询 , 获取 PCE的地址信息;或者,

RC-proxy从本地运营商策略配置中获取 PCE的地址信息;或者, RC-proxy从本地预先存储的地址信息中获取 PCE的地址信息; 其中, PC-proxy向 DRA查询获取 PCE的地址信息、以及从本地运营 商策略配置中获取 PCE的地址信息的具体处理过程与现有技术相同,这里 不再赘述;在实际应用时,当 RC-proxy事先未存储 PCE的地址信息时,可 以通过向 DRA查询获取 PCE的地址信息,或者,通过从本地运营商策略 配置中获取 PCE的地址信息,当 RC-proxy通过 DRA查询或通过从本地运 营商策略配置中获取到 PCE的地址信息后,则可以在本地存储 PCE的地址 信息,以便后续发送消息时直接使用;这里,本地存储 PCE的地址信息的 具体实现方式可以是:建立 SR之间会话的会话标识与 PCE的地址信息之 间的绑定关系,即:对应关系, RC-proxy收到应用层业务信息消息后,根 据消息中的 SR之间会话的会话标识,即可找到对应的 PCE的地址信息; 所述获取对应的 SCF节点的地址信息,具体为:

当 RC-proxy本地预先已存储对应的 SCF节点的地址信息时,直接从本 地获取对应的 SCF节点的地址信息;

当 RC-proxy本地未存储对应的 SCF节点的地址信息时,根据 DHT算 法从 P2P网络中查询对应的 SCF节点的地址信息;

其中, RC-proxy本地预先已存储对应的 SCF节点的地址信息的具体实 现可以是:建立 PCE的地址信息、 SR之间会话的会话标识、用户标识、以

及 SCF节点的地址信息等信息之间的绑定关系,即:对应关系, RC-proxy 收到 Diameter消息后, ^^据绑定关系,即可找到对应的 SCF节点的地址信 息;这里,当 RC-proxy本地预先已存储对应的 SCF节点的地址信息时,直 接从本地获取对应的 SCF节点的地址信息,之后向 SCF节点发送策略控制 相关消息是指:获取的对应的 SCF节点为未发生数据迁移、和 /或未失效的 SCF节点;

在获取对应的 SCF节点的地址信息,且当 RC-proxy本地预先已存储对 应的 SCF节点的地址信息时,如果 RC-proxy获知对应的 SCF节点失效, 该方法还可以进一步包括:

根据 DHT算法从 P2P网络中查询失效的 SCF节点的备份 SCF节点的 地址信息,将存储的失效的 SCF节点的地址信息更新为所述备份 SCF节点 的地址信息,之后向所述备份 SCF节点发送策略控制相关消息;

在向所述备份 SCF节点发送策略控制相关消息之前,该方法还可以进 一步包括:

RC-proxy与所述备份 SCF节点建立连接;

当 RC-proxy本地预先已存储对应的 SCF节点的地址信息,且 RC-proxy 确定出收到的策略控制相关消息对应的数据已发生迁移时, 该方法还可以 进一步包括:

SCF节点向 RC-proxy返回错误应答消息;

RC-proxy收到错误应答消息后,根据 DHT算法从 P2P网络中查询数 据迁移到的目标 SCF节点的地址,将存储的对应的 SCF节点的地址信息更 新为所述数据迁移到的目标 SCF节点的地址信息,之后向所述数据迁移到 的目标 SCF节点发送策略控制相关消息;

其中, SCF节点确定本地不存在策略控制相关消息中携带的 SR之间会 话的会话标识后,则向 RC-proxy返回错误应答消息; RC-proxy收到错误应 答消息后,根据消息中的错误原因值可以确定收到的策略控制相关消息对 应的数据已发生迁移;

在向所述数据迁移的目标 SCF节点发送策略控制相关消息之前,该方 法还可以进一步包括:

RC-proxy与所述数据迁移到的目标 SCF节点建立连接。

下面结合实施例对本发明再作进一步详细的说明。

实施例一:

本实施例的应用场景为:在 P2P核心网中, SCF节点向 PCE发送应用 层业务信息、以及 PCE向 SCF节点上报策略控制相关事件的实现流程。其 中, RC-proxy与 SCF节点之间、以及 RC-proxy与 PCE之间传送应用层 QoS 消息及策略控制相关信息所采用的协议相同,本实施例实现策略控制的方 法,如图 5所示,包括以下步驟:

步驟 501 : 在需要进行呼叫时, SCF节点获取 RC-proxy的地址信息; 这里,所述 SCF节点获取 RC-proxy的地址信息,具体为:

在 SCF节点加入 P2P网络时, Enrollment Server将包含 RC-proxy的地 址信息的配置文件下发给 SCF节点, SCF节点据此得到 RC-proxy的地址信 息;或者,

SCF节点从 P2P网络中的 tracker服务器中进行查询,得到 RC-proxy 的地址信息;或者,

SCF节点通过 DHT算法,查找到 RC-proxy的地址信息;

其中, RC-proxy加入 P2P网络后,会向 tracker服务器发起注册, tracker 服务器会存储 RC-proxy的地址信息等相关信息; RC-proxy加入 P2P网络后, 会根据 DHT算法,将自身的地址信息等相关信息存储在 P2P网络中的特定 节点上, SCF节点通过 DHT算法可以查找到 RC-proxy的地址信息;

所述地址信息具体可以是: IP地址、或域名、或 Node ID; 以下的描述 中,所述地址信息为 Node ID。

步驟 502: SCF节点获取到 RC-proxy的 Node ID后,向 RC-proxy发送 连接请求 ( Attach request ) 消息;

具体地,所述 Attach request消息根据 RC-proxy的 Node ID在 P2P网络 中进行路由,最终到达 RC-proxy。

步驟 503: RC-proxy收到 Attach request消息后,向 SCF节点返回连接 请求响应 ( AttachReqAns ) 消息;

这里, RC-proxy向 SCF节点返回 AttachReqAns消息后,则表明 SCF 节点与 RC-proxy建立了 IP连接。

步驟 504: SCF节点收到 AttachReqAns消息后,向 RC-proxy发送应用 层连接请求(AppAttach ) 消息。

步驟 505: RC-proxy收到 AppAttach request消息后,向 SCF节点返回 应用层连接请求响应 ( AppAttachAns ) 消息;

这里, RC-proxy向 SCF节点返回 AppAttachAns消息后,则表明 SCF 节点与 RC-proxy建立了应用层连接;

其中, 步驟 502~505的具体实现与现有技术相同,这里不再赘述; 执行步驟 504~505的目的为: SCF节点获取 RC-proxy的应用层 IP地 址,并建立应用层连接,这种情况适用于 SCF节点与 RC-Proxy之间采用 diameter协议等应用层协议的情况,换句话说,执行步驟 504~505的情况适 用于需要使用 diameter协议等上层协议,且未知 RC-proxy的应用层 IP地址 的情况。如果 SCF节点与 RC-Proxy之间采用的是 RELOAD协议,则可以 不执行步驟 504~505;

呼叫过程中 SCF节点首次向 RC-proxy发送消息时,才需要执行步驟 501-505; 连接建立后, SCF节点后续向 RC-proxy发送消息时,则不需要 执行步驟 501~505 , 直接可以向 RC-proxy发送消息。

步驟 506: SCF节点收到 AppAttachAns消息后,向 RC-proxy发送应用 层业务信息消息;

这里,所述应用层业务信息消息包含: SCF 节点的地址信息、用户标 识、应用层业务信息、以及 SR之间会话的会话标识;

其中,所述 SR之间会话的会话标识为 SCF节点产生的一个字符串, 用于标识 SCF节点与 RC-proxy之间的某个会话;

所述应用层业务信息是指:应用层 SDP信息或应用层 QoS信息;这里, 所述应用层业务信息为应用层 SDP信息还是为应用层 QoS信息由 AF实体 的功能的部署决定,具体地,如果 AF实体的功能部署在 SCF节点上,则 SCF节点将应用层 SDP信息映射成应用层 QoS信息,并携带在应用层业务 信息消息中发送给 RC-proxy, 如果 AF实体的功能部署在 RC-Proxy上,则 SCF节点向 RC-proxy发送的应用层业务信息为应用层 SDP信息, RC-proxy 收到应用层 SDP信息后,将应用层 SDP信息映射成应用层 QoS信息;其 中,应用层 SDP信息和应用层 QoS信息的具体映射方式为现有技术;

SCF节点与 RC-proxy之间具体使用的协议不限,可以使用 RELOAD 协议,也可以使用 Diameter协议等上层应用协议。

步驟 507~508: RC-proxy收到应用层业务信息消息后,获取 PCE的地 址信息;之后向 PCE发送应用层 QoS请求消息;

这里, RC-proxy获取 PCE的地址信息的方式可以是向 DRA查询,也 可以是直接从本地运营商策略配置中获取;其中, PC-proxy获取 PCE的地 址信息的具体处理过程与现有技术相同,这里不再赘述;

所述 PCE发送应用层 QoS请求消息,具体为:

如果 AF实体的功能部署在 RC-proxy上,则 RC-proxy收到的应用层业 务信息为应用层 SDP信息, RC-proxy将应用层 SDP信息映射成应用层 QoS 信息,之后将应用层 QoS信息承载在应用层 QoS请求消息中发送给 PCE; 如果 AF实体的功能部署在 SCF节点上,则 RC-proxy收到的应用层业 务信息为应用层 QoS信息, RC-proxy直接将应用层 QoS信息承载在应用层 QoS请求消息中发送给 PCE;

这里, RC-proxy向 PCE发送的应用层 QoS请求消息承载在 diameter 消息中,所述 diameter消息包含应用层 QoS信息、 diameter会话的 session-ID、 以及 RC-proxy地址信息等;

RC-proxy获取到 PCE的地址信息后,会存储 SR之间会话的会话标识、 SCF节点的地址信息、 用户标识、 diameter session-ID、 PCE的地址信息的 绑定关系,后续可根据这个存储的绑定关系进行路由,即:后续 RC-proxy 可根据该绑定关系获取所述 PCE地址信息及所述 SCF节点的地址信息。

步驟 509: PCE收到应用层 QoS请求消息后,存储业务信息,向 RC-proxy 返回 Diameter确认消息;

这里所述 Diameter确认消息包含 session-ID。

步驟 510~511: RC-proxy收到 Diameter确认消息后,获取 SCF节点的 地址信息;之后向 SCF节点发送确认消息;

这里,向 SCF节点发送的确认消息中携带所述 SR之间会话的会话标 识;

RC-proxy获取 SCF节点的地址信息,具体为:

根据 Diameter确认消息中的 session-ID, 查询本地存储的绑定关系,从 而获取到所述 SCF节点的地址信息。

步驟 512: PCE需要向 RC-proxy上报事件时, PCE向 RC-proxy发送 Diameter事件上报消息;

这里,所述 Diameter事件上报消息中携带上报事件、用户标识、以及 diameter session-ID等信息。

步驟 513~514: RC-proxy收到 Diameter事件上报消息后,获取所述 SCF 节点的地址信息;之后向所述 SCF节点发送事件上报消息;

这里,所述向所述 SCF节点发送的事件上报消息中携带所述 SR之间 会话的会话标识、以及通知事件;

其中, RC-proxy获取 SCF节点的地址信息,具体为:

根据 Diameter事件上报消息中的 session-ID,查询本地存储的绑定关系, 从而获取到所述 SCF节点的地址信息。

步驟 515: SCF节点收到事件上报消息后,向 RC-proxy发送确认消息; 这里,所述确认消息中携带 SR之间会话的会话标识。

步驟 516: RC-proxy收到确认消息后,根据 SR之间会话的会话标识查 询本地存储的绑定关系,获取到 PCE的地址信息,之后向 PCE发送确认消

实施例二:

本实施例的应用场景为:在 Ρ2Ρ核心网中,处理业务的 SCF节点在一 个会话的策略控制过程中失效,即:所述 SCF节点宕机或退出 Ρ2Ρ核心网, 其中, RC-proxy已事先存储了 SR之间会话的会话标识、所述 SCF节点的 地址信息、用户标识、 diameter session-ID, PCE的地址信息的绑定关系, 其中, RC-proxy与 SCF节点之间、以及 RC-proxy与 PCE之间传送应用层 QoS消息及策略控制相关信息所采用的协议相同。处理业务的 SCF失效后, 由失效的 SCF节点的备份 SCF节点接替失效的 SCF节点处理业务。本实施 例实现策略控制的方法,如图 6所示,包括以下步驟:

步驟 601 : PCE需要向 RC-proxy上报事件时, PCE向 RC-proxy发送 Diameter事件上报消息;

这里,所述 Diameter事件上报消息中携带上报事件、用户标识、以及 diameter session-ID等信息。

步驟 602: RC-proxy收到 Diameter事件上报消息,且获知处理业务的 SCF节点失效后,根据用户标识的哈希(hash )值,采用 DHT算法从 P2P 网络中查询失效的 SCF节点的备份 SCF节点的地址信息,并采用备份 SCF 节点的地址信息代替预先存储的绑定关系中的失效的 SCF 节点的地址信

这里, RC-proxy获知处理业务的 SCF节点失效的方法可采用现有的技 术,此处不再赘述。

步驟 603: RC-proxy向备份 SCF节点发送 Attach request消息。

这里, 当处理业务的 SCF节点失效后,备份 SCF节点可通过现有技术 获知处理业务的 SCF节点失效,此时,所述备份 SCF节点会向 RC-proxy 发送 Attach request消息,以便与 RC-proxy建立 IP连接及应用层连接,进 而接替失效的 SCF节点处理业务;其中,备份 SCF节点可通过失效的 SCF 节点的备份信息获得 RC-proxy的地址信息;

当所述 RC-proxy的地址信息为 RC-proxy的 Node ID时,所述 Attach request消息根据 RC-proxy的 Node ID在 P2P网络中进行路由,最终到达 RC-proxy

步驟 604:备份 SCF节点收到 Attach request消息后,向 RC-proxy返回 AttachReqAns消息;

这里,备份 SCF节点向 RC-proxy返回 AttachReqAns消息后,则表明 备份 SCF节点与 RC-proxy建立了连接。

步驟 605: RC-proxy收到 AttachReqAns消息后,向备份 SCF节点发送

AppAttach消息。

步驟 606: 备份 SCF节点收到 AppAttach request消息后,向 RC-proxy 返回 AppAttachAns消息;

这里,备份 SCF节点向 RC-proxy返回 AppAttachAns消息后,则表明 备份 SCF节点与 RC-proxy建立了应用层连接;

其中, 步驟 603~606的具体实现与现有技术相同,这里不再赘述; 执行步驟 605~606的目的为: RC-proxy获取备份 SCF节点的应用层 IP 地址,并建立应用层连接,这种情况适用于备份 SCF节点与 RC-Proxy之间 采用 diameter协议等应用层协议的情况,换句话说,执行步驟 605~606的 情况适用于使用 diameter协议等上层协议,且未知备份 SCF节点的应用层

IP地址的情况。如果备份 SCF节点与 RC-Proxy之间采用的是 RELOAD协 议,则可以不执行步驟 605~606。

步驟 607: 向所述备份 SCF节点发送事件上报消息。

步驟 608:所述备份 SCF节点收到事件上报消息后,向 RC-proxy发送 确认消息;

这里, 所述确认消息中携带 SR之间会话的会话标识。

步驟 609: RC-proxy收到确认消息后,根据 SR之间会话的会话标识查 询,查询本地存储的绑定关系,获取到 PCE的地址信息,之后向 PCE发送 确认消息。

实施例三:

本实施例的应用场景为:在 P2P核心网中,处理业务的 SCF节点在一 个会话的策略控制过程中发生数据迁移,即:处理业务的 SCF节点负责处 理的部分用户数据和业务信息迁移到另一个 SCF节点,其中, RC-proxy已 事先存储了 SR之间会话的会话标识、所述 SCF节点的地址信息、用户标 识、 diameter session-ID、 PCE的地址信息的绑定关系, RC-proxy与 SCF节 点之间、以及 RC-proxy与 PCE之间传送应用层 QoS消息及策略控制相关 信息所采用的协议相同。在以下的描述中,将处理业务的 SCF节点称为 SCF 1 ,将数据迁移的目标 SCF节点称为 SCF 2。本实施例实现策略控制的方法, 如图 7所示,包括以下步驟:

步驟 701 : PCE需要向 RC-proxy上报事件时, PCE向 RC-proxy发送 Diameter事件上报消息;

这里, 所述 Diameter事件上报消息中携带上报事件、用户标识、以及 diameter session-ID等信息。

步驟 702~703: RC-proxy收到 Diameter事件上报消息后,获取 SCF 1 的地址信息;之后向 SCF 1发送事件上报消息;

这里,所述向 SCF 1发送的事件上报消息中携带所述 SR之间会话的会 话标识、以及通知事件;

其中, RC-proxy获取 SCF 1的地址信息,具体为:

根据 Diameter事件上报消息中的 session-ID,查询本地存储的绑定关系, 从而获取到 SCF 1的地址信息。

步驟 704: SCF 1收到事件上报消息,且确定本地不存在消息中携带的 SR之间会话的会话标识后, 向 RC-proxy返回错误应答消息;

这里,由于数据迁移后, SCF 1本地将不会有所迁移的数据的任何信息, 据此, SCF 1确定本地不存在消息中携带的 SR之间会话的会话标识;所述 错误应答消息中携带错误原因,即: SR之间会话的会话标识不存在。

步驟 705: RC-proxy收到错误应答消息后,根据用户标识的 hash值, 采用 DHT算法从 P2P网络中重新获取新的 SCF节点的地址信息,并将所 述绑定关系中 SCF 1的地址信息更新为新的 SCF节点即 SCF 2的地址信息; 这里, RC-proxy根据错误原因可知 SCF 1中的相关用户数据和业务信 息发生了迁移。

步驟 706: RC-proxy向 SCF 2发送 Attach request消息。

步驟 707: SCF 2 收到 Attach request 消息后,向 RC-proxy返回 AttachReqAns消息;

这里, SCF 2向 RC-proxy返回 AttachReqAns消息后,则表明 SCF 2与 RC-proxy建立了连接。

步驟 708: RC-proxy收到 AttachReqAns消息后,向 SCF 2发送 AppAttach 消息。

步驟 709: SCF 2收到 AppAttach request消息后,向 RC-proxy返回

AppAttachAns消息;

这里, SCF 2向 RC-proxy返回 AppAttachAns消息后,则表明 SCF 2 与 RC-proxy建立了应用层连接;

其中, 步驟 706~709的具体实现与现有技术相同,这里不再赘述; 执行步驟 708~709的目的为: RC-proxy获取 SCF 2的应用层 IP地址, 并建立应用层连接,这种情况适用于 SCF 2与 RC-Proxy之间采用 diameter 协议等应用层协议的情况,换句话说,执行步驟 708~709的情况适用于需 要使用 diameter协议等上层协议,且未知 SCF2的应用层 IP地址的情况。 如果 SCF 2与 RC-Proxy之间采用的是 RELOAD协议,则可以不执行步驟

708~709。

步驟 710: 之后向 SCF 2发送事件上报消息。

步驟 711 : SCF 2收到事件上报消息后,向 RC-proxy发送确认消息; 这里, 所述确认消息中携带 SR之间会话的会话标识。

步驟 712: RC-proxy收到确认消息后,根据 SR之间会话的会话标识查 询,查询本地存储的绑定关系,获取到 PCE的地址信息,之后向 PCE发送 确认消息。

实施例四:

本实施例的应用场景为:在 P2P核心网中, SCF节点向 PCE发送应用 层业务信息、以及 PCE向 SCF节点上报策略控制相关事件的实现流程。其 中, RC-proxy本地不存储绑定关系,即:不存储 SCF 节点的地址信息, RC-proxy与 SCF节点之间、以及 RC-proxy与 PCE之间传送应用层 QoS消 息及策略控制相关信息所采用的协议相同,本实施例实现策略控制的方法,

如图 8所示,包括以下步驟:

步驟 801 : 在需要进行呼叫时, SCF节点获取 RC-proxy的地址信息; 这里, 所述 SCF节点获取 RC-proxy的地址信息,具体为:

在 SCF节点加入 P2P网络时, Enrollment Server将包含 RC-proxy的地 址信息的配置文件下发给 SCF节点, SCF节点据此得到 RC-proxy的地址信 息;或者,

SCF节点从 P2P网络中的 tracker服务器中进行查询,得到 RC-proxy 的地址信息;或者,

SCF节点通过 DHT算法,查找到 RC-proxy的地址信息;

其中, RC-proxy加入 P2P网络后,会向 tracker服务器发起注册, tracker 服务器会存储 RC-proxy的地址信息等相关信息; RC-proxy加入 P2P网络后, 会根据 DHT算法,将自身的地址信息等相关信息存储在 P2P网络中的特定 节点上, SCF节点通过 DHT算法可以查找到 RC-proxy的地址信息;

所述地址信息具体可以是: IP地址、或域名、或 Node ID; 以下的描 述中,所述地址信息为 Node ID。

步驟 802: SCF节点获取到 RC-proxy的 Node ID后,向 RC-proxy发送 Attach request消息;

具体地,所述 Attach request消息根据 RC-proxy的 Node ID在 P2P网络 中进行路由,最终到达 RC-proxy。

步驟 803: RC-proxy收到 Attach request 消息后,向 SCF 节点返回

AttachReqAns消息;

这里, RC-proxy向 SCF节点返回 AttachReqAns消息后,则表明 SCF 节点与 RC-proxy建立了连接。

步驟 804: SCF 节点收到 AttachReqAns 消息后,向 RC-proxy发送 AppAttach消息。

步驟 805: RC-proxy收到 AppAttach request消息后,向 SCF节点返回 AppAttachAns消息;

这里, RC-proxy向 SCF节点返回 AppAttachAns消息后,则表明 SCF 节点与 RC-proxy建立了应用层连接;

其中, 步驟 802~805的具体实现与现有技术相同,这里不再赘述; 执行步驟 804~805的目的为: SCF节点获取 RC-proxy的应用层 IP地 址,并建立应用层连接,这种情况适用于 SCF节点与 RC-Proxy之间采用 diameter协议等应用层协议的情况,换句话说,执行步驟 804~805的情况适 用于需要使用 diameter协议等上层协议,且未知 RC-proxy的应用层 IP地址 的情况。如果 SCF节点与 RC-Proxy之间采用的是 RELOAD协议,则可以 不执行步驟 804~805;

呼叫过程中 SCF节点首次向 RC-proxy发送消息时,才需要执行步驟 801-805; 连接建立后, SCF节点后续向 RC-proxy发送消息时,则不需要 执行步驟 801~805 , 直接可以向 RC-proxy发送消息。

步驟 806: SCF节点收到 AppAttachAns消息后,向 RC-proxy发送应用 层业务信息消息;

这里,所述应用层业务信息消息包含 SCF节点的地址信息、用户标识、 应用层业务信息、以及 SR之间会话的会话标识;

其中, 所述 SR之间会话的会话标识为 SCF节点产生的一个字符串, 用于标识 SCF节点与 RC-proxy之间的某个会话;

所述应用层业务信息是指:应用层 SDP信息或应用层 QoS信息;这里, 所述应用层业务信息为应用层 SDP信息还是为应用层 QoS信息由 AF实体 的功能的部署决定,具体地,如果 AF实体的功能部署在 SCF节点上,则 SCF节点将应用层 SDP信息映射成应用层 QoS信息,并发送给 RC-proxy, 如果 AF实体的功能部署在 RC-Proxy上,则 SCF节点向 RC-proxy发送的 应用层业务信息为应用层 SDP信息, RC-proxy收到应用层 SDP信息后, 将应用层 SDP信息映射成应用层 QoS信息;其中,应用层 SDP信息和应 用层 QoS信息的具体映射方式为现有技术;

SCF节点与 RC-proxy之间具体使用的协议不限,可以使用 RELOAD 协议,也可以使用 Diameter协议等上层应用协议。

步驟 807~808: RC-proxy收到应用层业务信息消息后,获取 PCE的地 址信息;之后向 PCE发送应用层 QoS请求消息;

这里, RC-proxy获取 PCE的地址信息的方式可以是向 DRA查询,也 可以是直接从本地运营商策略配置中获取;其中, PC-proxy获取 PCE的地 址信息的具体处理过程与现有技术相同,这里不再赘述;

所述 PCE发送应用层 QoS请求消息,具体为:

如果 AF实体的功能部署在 RC-proxy上,则 RC-proxy收到的应用层业 务信息为应用层 SDP信息, RC-proxy将应用层 SDP信息映射成应用层 QoS 信息,之后将应用层 QoS信息承载在应用层 QoS请求中发送给 PCE;

如果 AF实体的功能部署在 SCF节点上,则 RC-proxy收到的应用层业 务信息为应用层 QoS消息, RC-proxy直接将承载在应用层 QoS请求中发送 给 PCE;

这里, RC-proxy向 PCE发送的应用层 QoS请求承载在 diameter消息中, 所述 diameter消息包含应用层 QoS信息、 diameter会话的 session-ID、以及 RC-proxy地址信息等;

RC-proxy查询到 PCE的地址信息后,会保存 SR之间会话的会话标识 及 PCE的地址信息的绑定关系。

步驟 809: PCE收到应用层 QoS请求消息后,存储业务信息,向 RC-proxy 返回 Diameter确认消息;

这里,所述 Diameter确认消息包含: session-ID、及用户标识等信息。 步驟 810~811 : RC-proxy收到 Diameter确认消息后,根据用户标识的 hash值,采用 DHT算法从 P2P网络中查询对应的 SCF节点的地址信息, 之后向 SCF节点发送确认消息;

这里, 向 SCF节点发送的确认消息中携带所述 SR之间会话的会话标 识。

步驟 812: PCE需要向 RC-proxy上报事件时, PCE向 RC-proxy发送 Diameter事件上报消息;

这里, 所述 Diameter事件上报消息中携带上报事件、用户标识、以及 diameter session-ID等信息。

步驟 813~814: RC-proxy收到 Diameter事件上报消息后,根据用户标 识的 hash值,采用 DHT算法从 P2P网络中查询对应的 SCF节点的地址信 息,之后向 SCF节点发送事件上报消息;

这里, 所述向 SCF节点发送的事件上报消息中携带所述 SR之间会话 的会话标识、以及通知事件。

步驟 815: SCF节点收到事件上报消息后,向 RC-proxy发送确认消息; 这里, 所述确认消息中携带 SR之间会话的会话标识。

步驟 816~817: RC-proxy收到确认消息后,根据 SR之间会话的会话标 识查询,查询本地存储的绑定关系,获取 PCE的地址信息,之后向 PCE发 送确认消息。

为实现上述方法,本发明还提供了一种 P2P 网络中实现策略控制的系 统,如图 9所示,该系统包括:第一 SCF节点 91、 RC-proxy 92、以及 PCE 93; 其中,

第一 SCF节点 91 , 用于呼叫过程中,向 RC-proxy 92发送应用层业务 信息消息;和 /或,接收 RC-proxy 92发送的策略控制相关消息;

RC-proxy 92, 用于收到第一 SCF节点 91发送的应用层业务信息消息

后,获取 PCE 93的地址信息,并向 PCE 93发送应用层 QoS请求消息;和 /或,收到 PCE 93发送的 Diameter消息后,获取对应的 SCF节点的地址信 息,并向第一 SCF节点 91发送策略控制相关消息;

PCE 93 , 用于接收 RC-proxy 92发送的应用层 QoS请求消息;和 /或, 向 RC-proxy 92发送 Diameter消息。

其中,所述第一 SCF节点 91 ,还用于呼叫过程中首次向所述 RC-proxy 发送消息时,获取 RC-proxy 92的地址信息,并与 RC-proxy 92建立连接; 所述 RC-proxy 92, 还用于与第一 SCF节点 91建立连接。

当 RC-proxy 92与第一 SCF节点 91之间传送应用层 QoS请求消息及策 略控制相关信息所采用的协议不为 RELOAD协议, 在与 RC-proxy 92建立 连接时,所述第一 SCF节点 91 , 还用于与 RC-proxy 92建立应用层连接; 所述 RC-proxy 92, 还用于与第一 SCF节点 91建立应用层连接。

该系统还可以进一步包括第二 SCF节点,为第一 SCF节点 91的备份 SCF节点, 用于接收 RC-proxy 92发送的策略控制相关消息;

在获取对应的 SCF节点的地址信息,且当 RC-proxy 92本地预先已存 储第一 SCF节点 91的地址信息时,如果 RC-proxy 92获知第一 SCF节点 91失效后,所述 RC-proxy 92 , 还用于根据 DHT算法从 P2P网络中查询第 二 SCF节点的地址信息,将存储的第一 SCF节点 91的地址信息更新为第 二 SCF节点的地址信息,并向第二 SCF节点发送策略控制相关消息。

在向第二 SCF节点发送策略控制相关消息之前,所述 RC-proxy 92,还 用于与第二 SCF节点建立连接;

所述第二 SCF节点,还用于与 RC-proxy 92建立连接。

该系统还可以进一步包括:第三 SCF节点,为数据迁移的目标 SCF节 点,用于接收 RC-proxy 92发送的策略控制相关消息;

当 RC-proxy 92 本地预先已存储对应的 SCF 节点的地址信息,且

RC-proxy 92确定收到的策略控制相关消息对应的数据已发生迁移时,所述 第一 SCF节点,还用于向 RC-proxy 92返回错误应答消息;

所述 RC-proxy 92, 还用于收到第一 SCF节点 91返回的错误应答消息 后,根据 DHT算法从 P2P网络中查询第三 SCF节点的地址,将存储的对 应的第一 SCF节点 91的地址信息更新为第三 SCF节点的地址信息,并向 第三 SCF节点发送策略控制相关消息。

在向第三 SCF节点发送策略控制相关消息之前,所述 RC-proxy 92,还 用于与第三 SCF节点建立连接。

所述第三 SCF节点,还用于与 RC-proxy 92建立连接。

这里,本发明所述系统中的第一 SCF节点及 RC-proxy的具体处理过程 已在上文中详述,不再赘述。

为实现上述方法,本发明还提供了一种 P2P 网络中实现策略控制的 RC-proxy,如图 10所示,该 RC-proxy包括:获取模块 101及发送模块 102; 其中,

获取模块 101 , 用于收到 SCF节点发送的应用层业务信息消息后,获 取 PCE的地址信息,并将获取的 PCE的地址信息发送给发送模块 102; 和 /或,收到 PCE发送的 Diameter消息后,获取对应的 SCF节点的地址信息, 并将获取的 SCF节点的地址信息发送给发送模块 102;

发送模块 102, 用于收到获取模块 101发送的 PCE的地址信息后,向 PCE发送应用层 QoS请求消息;和 /或,收到获取模块 101发送的 SCF节 点的地址信息后,向 SCF节点发送策略控制相关消息。

其中,在获取 PCE的地址信息时,所述获取模块 101 , 具体用于:向 DRA查询, 获取 PCE 的地址信息;或者,从本地运营商策略配置中获取 PCE的地址信息; 或者,从本地预先存储的地址信息中获取 PCE的地址信 息。

在获取对应的 SCF节点的地址信息时,所述获取模块 101 , 具体用于: 当本地预先已存储对应的 SCF节点的地址信息时,直接从本地获取对应的 SCF节点的地址信息; 当本地未存储对应的 SCF节点的地址信息时,才艮据 DHT算法从 P2P网络中查询对应的 SCF节点的地址信息。

在获取对应的 SCF节点的地址信息,且当本地预先已存储对应的 SCF 节点的地址信息时,并在获知对应的 SCF节点失效后,所述获取模块 101 , 还用于根据 DHT算法从 P2P网络中查询失效的 SCF节点的备份 SCF节点 的地址信息,将存储的失效的 SCF节点的地址信息更新为所述备份 SCF节 点的地址信息,并将所述备份 SCF节点的地址信息发送给发送模块 102; 所述发送模块 102 ,还用于收到获取模块 101发送的所述备份节点的地 址信息后,向所述备份 SCF节点发送策略控制相关消息。

当本地预先已存储对应的 SCF节点的地址信息,且确定收到的策略控 制相关消息对应的数据已发生迁移时,所述获取模块 101 ,还用于根据 DHT 算法从 P2P网络中查询数据迁移到的目标 SCF节点的地址,将存储的对应 的 SCF节点的地址信息更新为所述数据迁移到的目标 SCF节点的地址信息 并将所述数据迁移到的目标 SCF节点的地址信息发送给发送模块 102; 所述发送模块 102 ,还用于收到获取模块 101发送的所述数据迁移到的 目标 SCF节点的地址信息后,向所述数据迁移到的目标 SCF节点发送策略 控制相关消息。

当 RC-proxy与 SCF节点之间及 RC-proxy与 PCE之间传送应用层 QoS 请求消息及策略控制相关信息所采用的协议不同时,所述发送模块 102,还 用于将收到的应用层 QoS请求消息、和 /或策略控制相关信息进行协议转换 处理,并将协议转换处理后的应用层 QoS请求消息和 /或策略控制相关信息 分别发送给 PCE和 /或 SCF节点;

该 RC-proxy还可以进一步包括存储模块,用于存储 PCE的地址信息、 和 /或 SCF节点的地址信息。

该 RC-proxy还可以进一步包括:建立连接模块,用于与 SCF节点建立 连接。

以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保 护范围。