WO2012142978A1 - Procédé, proxy de contrôle de ressource et système pour un contrôle de politique dans un réseau de pair à pair - Google Patents
Procédé, proxy de contrôle de ressource et système pour un contrôle de politique dans un réseau de pair à pair Download PDFInfo
- Publication number
- WO2012142978A1 WO2012142978A1 PCT/CN2012/074562 CN2012074562W WO2012142978A1 WO 2012142978 A1 WO2012142978 A1 WO 2012142978A1 CN 2012074562 W CN2012074562 W CN 2012074562W WO 2012142978 A1 WO2012142978 A1 WO 2012142978A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- proxy
- address information
- scf node
- node
- scf
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/20—Traffic policing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0025—Provisions for signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
Definitions
- the present invention relates to peer-to-peer (P2P, Peer-to-Peer) network technology, and in particular to a method for implementing policy control, a resource control proxy (RC-proxy) and a system in a P2P network.
- P2P peer-to-peer
- RC-proxy resource control proxy
- a P2P network is a distributed network. Participants in a P2P network share resources and services owned by the entire network. These shared resources and services can be directly accessed by other nodes in the network without being relayed by a special intermediate entity.
- each participant is both a resource and a service provider (server) and a resource and service acquirer (client).
- the P2P network adopts the overlay network technology, that is, the nodes are added to the self-organized overlay network, and the distributed hash table (DHT, Distributed Hash Table) algorithm can be used to quickly find and locate the resources.
- DHT Distributed Hash Table
- the protocols of the P2P network mainly include: RELOAD, REsource LOcation And Discovery, defined by the Internet Engineering Task Force (IETF).
- RELOAD protocol is detailed in draft-ietf-p2psip-base-00.
- the RELOAD protocol provides basic services for an ad hoc network, including: routing of messages between nodes, storage and searching of data.
- the RELOAD protocol further defines a node registration server (Enrollment Server), wherein the Enrollment Server is configured to divide the node number, the security certificate, and the configuration information of the overlay network for the node, where the configuration information includes: What kind of DHT algorithm, etc.
- the RELOAD protocol divides the nodes in the overlay network into two categories, namely: Peer node and client.
- the Peer node has the functions of P2P message routing, storage, and lookup.
- the client can send a P2P message to the Peer node, and the peer node performs the cancellation.
- FIG. 1 shows a typical networking mode of a telecommunication network introduced into a P2P network.
- the device of the network includes: a Service Control Function (SCF) entity and a User Entity (UE).
- SCF Service Control Function
- UE User Entity
- the SCF entity is added to the Overlay network as a Peer node, and all SCF entities form a homogeneous P2P core network to jointly complete the control function of the P2P core network service.
- each SCF entity has the same function and is responsible for user access, session control, and service triggering.
- the UE accesses the P2P core network as a client.
- the UE in the Overlay network has the function of the UE in the traditional network, and also has the client side function of the P2P network.
- an SCF entity is referred to as an SCF node.
- each UE has an SCF node responsible for processing UE services, also referred to as a responsible node.
- the traffic model of the basic call is as shown in FIG.
- the call process between the UE 1 and the UE 2 is: After the call service of the UE 1 is processed by the SCF 1 , it is sent to the SCF 2 , and the SCF 2 processes the received service and sends it to the UE 2 .
- the service signaling interaction between the UE and the SCF node and between the SCF node and the SCF node uses Session Initiation Protocol (SIP), between the UE and the SCF node, and between the SCF node and the SCF node.
- SIP Session Initiation Protocol
- the policy control system mainly includes: Resource and Admission Control Subsystem (RTS) of International Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TIACS), International Telecommunications Union (ITU, International Telecommunications Union), the Resource and Admission Control Function (RACF), and the 3rd Generation Partnership Project (PCC, Policy and Charging Control),
- RTS Resource and Admission Control Subsystem
- TIACS International Telecommunications and Internet Converged Services and Protocols for Advanced Networking
- ITU International Telecommunications Union
- RCF Resource and Admission Control Function
- PCC 3rd Generation Partnership Project
- the above-mentioned policy control system as shown in FIG. 3, mainly includes: an application function (AF, Application Function) entity 31, a policy control function entity 32, and a policy execution function entity 33.
- AF Application Function
- the function of the AF entity 31 is: abstracting the service layer and implementing the first layer mapping of the QoS (Quality of Service) mapping, that is, after obtaining the service description protocol (SDP, Session description Protocol) information.
- SDP service description protocol
- Session description Protocol Session description Protocol
- the information in the SDP is mapped to the service QoS information, and is encapsulated in the Diameter message and sent to the policy control function entity 32.
- the functions of the policy control function entity 32 are: based on the operator policy, the service QoS request, and the user subscription information.
- a corresponding resource control policy is formulated and sent to the policy execution function entity 33 for installation and execution.
- the function of the policy enforcement function entity 33 is: under the guidance of the policy control function entity 33, performing QoS policy enforcement, gating, and information reporting.
- an existing policy control system is directly applied to a telecommunications network that introduces P2P network technology, routing problems will arise. Specifically, when an existing policy control system is applied to a telecommunication network that introduces a P2P network technology, the SCF node is required to have the function of the AF entity and interface with the policy control function entity. Due to the high dynamics of the SCF node, in a policy control process, after the SCF node fails or data migration occurs, the policy control function entity needs to route subsequent related messages to the new SCF node, but in the existing system. The policy control function entity is not aware of the dynamic changes of the SCF node, and therefore, the subsequent related messages cannot be routed to the correct target node. Summary of the invention
- the main object of the present invention is to provide a policy control in a P2P network.
- the method, RC-proxy and system can effectively implement policy control in P2P networks.
- the present invention provides a method for implementing policy control in a P2P network, the method includes: after receiving an application layer service information message sent by an SCF node in a P2P network, the RC-proxy obtains a policy control entity (PCE, Address information of the Policy Control Entity, and then sending an application layer QoS request message to the PCE; and/or, after receiving the Diameter message sent by the PCE, the RC-proxy obtains the address information of the corresponding SCF node, and then sends the address information to the SCF.
- PCE Policy control entity
- the node sends a policy control related message.
- the method further includes:
- the SCF node When the SCF node sends a message to the RC-proxy for the first time in the call, the SCF node acquires the address information of the RC-proxy, and then establishes a connection with the RC-proxy.
- the obtaining the address information of the RC-proxy is:
- the Enrollment Server sends a configuration file containing the address information of the RC-proxy to the SCF node;
- the SCF node queries the tracker server in the P2P network to obtain the address information of the RC-proxy; or
- the SCF node obtains address information of the RC-proxy by using a DHT algorithm.
- the address information of the RC-proxy is: an IP address, or a domain name, or a Node number (ID, Identity).
- the obtaining the address information of the PCE in the P2P network is:
- the RC-proxy queries a Diameter Routing Agent (DRA) to obtain address information of the PCE; or
- DRA Diameter Routing Agent
- the RC-proxy obtains the address letter of the PCE from locally stored address information.
- the PCE is different. Before sending the application layer QoS request message, the method further includes:
- the RC-proxy performs protocol conversion processing on the received application layer QoS request message.
- the method further includes:
- the RC-proxy performs protocol conversion on the received policy control related message.
- the method further includes:
- the SCF node maps application layer SDP information into application layer QoS information, and then sends an application layer service information message including application layer QoS information to the RC-proxy;
- the RC-proxy maps the application layer SDP information in the received application layer service information message to the application layer QoS information.
- the obtaining the address information of the corresponding SCF node is:
- the RC-proxy When the RC-proxy locally stores the address information of the corresponding SCF node in advance, the address information of the corresponding SCF node is directly obtained locally;
- the address information of the corresponding SCF node is not stored locally by the RC-proxy, the address information of the corresponding SCF node is queried from the P2P network according to the DHT algorithm.
- the RC-proxy learns that the corresponding SCF node is invalid, and the method further Includes:
- the method further includes:
- the RC-proxy establishes a connection with the backup SCF node.
- the method further includes:
- the SCF node returns an error response message to the RC-proxy
- the RC-proxy After receiving the error response message, the RC-proxy updates the address of the stored SCF node to the target SCF to which the data is migrated according to the address of the target SCF node to which the data is migrated from the P2P network according to the DHT algorithm. The address information of the node is then sent to the target SCF node to which the data is migrated to send a policy control related message.
- the method before sending the policy control related message to the target SCF node that migrates the data, the method further includes:
- the RC-proxy establishes a connection with a target SCF node to which the data is migrated.
- the present invention also provides a resource control agent for implementing policy control in a P2P network, where the resource control agent includes: an ear module and a sending module;
- the acquiring module is configured to: after receiving the application layer service information message sent by the SCF node, obtain the address information of the PCE, and send the obtained PCE address information to the sending module; and/or, after receiving the Diameter message sent by the PCE, Obtaining address information of the corresponding SCF node, and sending the obtained address information of the SCF node to the sending module;
- the sending module is configured to: after receiving the address information of the PCE sent by the acquiring module, send an application layer QoS request message to the PCE; and/or, after receiving the address information of the SCF node sent by the acquiring module, send the policy control related to the SCF node. Message.
- the acquiring module when acquiring the address information of the PCE, is specifically configured to: Querying the DRA to obtain the address information of the PCE; or obtaining the address information of the PCE from the local carrier policy configuration; or obtaining the address information of the PCE from the locally pre-stored address information.
- the acquiring module when acquiring the address information of the corresponding SCF node, is specifically configured to: when locally storing the address information of the corresponding SCF node in advance, directly acquiring the address information of the corresponding SCF node from the local; When the address information of the corresponding SCF node is not stored locally, the address information of the corresponding SCF node is queried from the P2P network according to the DHT algorithm.
- the acquiring module is further used according to the DHT algorithm. Querying the address information of the backup SCF node of the failed SCF node from the P2P network, updating the address information of the stored failed SCF node to the address information of the backup SCF node, and sending the address information of the backup SCF node to Sending module
- the sending module is further configured to: after receiving the address information of the backup node sent by the acquiring module, send a policy control related message to the backup SCF node.
- the obtaining module is further configured to query from the P2P network according to the DHT algorithm.
- the address of the target SCF node to which the data is migrated, the address information of the stored corresponding SCF node is updated to the address information of the target SCF node to which the data is migrated, and the address information of the target SCF node to which the data is migrated is sent to Sending module
- the sending module is further configured to: after receiving the address information of the target SCF node to which the data sent by the acquiring module is migrated, send a policy control related message to the target SCF node to which the data is migrated.
- the sending module is further configured to perform protocol conversion processing on the received application layer QoS request message and/or policy control related information, and The application layer QoS request message and/or the policy control related information after the protocol conversion process are respectively sent to the PCE and/or the SCF node.
- the resource control agent further includes: a storage module, configured to store address information of the PCE, and/or address information of the SCF node.
- the resource control agent further includes: establishing a connection module, configured to establish a connection with the SCF node.
- the present invention also provides a system for implementing policy control in a P2P network, the system comprising: a first SCF node, an RC-proxy, and a PCE;
- the first SCF node is configured to send an application layer service information message to the RC-proxy during the call, and/or receive a policy control related message sent by the RC-proxy;
- the RC-proxy is configured to: after receiving the application layer service information message sent by the first SCF node, obtain the address information of the PCE, and send an application layer QoS request message to the PCE; and/or, after receiving the Diameter message sent by the PCE, Obtaining address information of the corresponding SCF node, and sending a policy control related message to the first SCF node;
- the PCE is configured to receive an application layer QoS request message sent by the RC-proxy, and/or send a Diameter message to the RC-proxy.
- the first SCF node is used to obtain the address information of the RC-proxy when the message is sent to the RC-proxy for the first time in the call, and establish a connection with the RC-proxy;
- the RC-proxy is further configured to establish a connection with the first SCF node.
- the system further includes a second SCF node, which is a backup SCF node of the first SCF node, and is configured to receive a policy control related message sent by the RC-proxy;
- the RC-proxy is further configured to query the address information of the second SCF node from the P2P network according to the DHT algorithm, and store the first SCF node.
- the address information is updated to the address information of the second SCF node, and the policy control related message is sent to the second SCF node.
- the RC-proxy is further configured to establish a connection with the second SCF node, and the second SCF node is further configured to establish a connection with the RC-proxy.
- system further includes: a third SCF node, configured to receive a policy control related message sent by the RC-proxy;
- the RC-proxy When the RC-proxy locally stores the address information of the corresponding SCF node in advance, and the RC-proxy determines that the data corresponding to the received policy control related message has been migrated, the first SCF node is also used to the RC-proxy. Return an error response message;
- the RC-proxy is further configured to: after receiving the error response message returned by the first SCF node, query the address of the third SCF node from the P2P network according to the DHT algorithm, and update the address information of the stored first SCF node. It is the address information of the third SCF node, and sends a policy control related message to the third SCF node.
- the RC-proxy is further configured to establish a connection with the third SCF node
- the third SCF node is further configured to establish a connection with the RC-proxy
- the method for implementing policy control, the RC-proxy and the system in the P2P network provided by the present invention, after receiving the application layer service information message sent by the SCF node in the P2P network, the RC-proxy obtains the address information of the PCE, and then obtains the address information of the PCE. Sending an application layer QoS request message to the PCE; and/or, after receiving the Diameter message sent by the PCE, the RC-proxy obtains the address information of the corresponding SCF node, and then sends a policy control related message to the SCF node, so Effectively implement policy control in a P2P network.
- the policy control related message is sent to the SCF node, so that the policy can be used when the current SCF node that processes the service fails or data migration occurs. Control related news It is routed to the corresponding SCF node.
- FIG. 1 is a schematic diagram of a networking manner of a telecommunication network introduced into a P2P network in the prior art
- FIG. 2 is a schematic diagram of a basic call traffic model of a typical telecommunication network introduced into a P2P network
- FIG. 3 is a schematic diagram of a conventional policy control system Schematic diagram of structural composition
- FIG. 4 is a schematic flowchart of a method for implementing policy control in a P2P network according to the present invention
- FIG. 5 is a schematic flowchart of a method for implementing policy control in Embodiment 1;
- FIG. 6 is a schematic flowchart of a method for implementing policy control in Embodiment 2;
- FIG. 7 is a schematic flowchart of a method for implementing policy control in Embodiment 3.
- FIG. 8 is a schematic flowchart of a method for implementing policy control in Embodiment 4.
- FIG. 9 is a schematic structural diagram of a system for implementing policy control in a P2P network according to the present invention.
- FIG. 10 is a schematic structural diagram of a resource control agent implementing policy control in a P2P network according to the present invention. detailed description
- the RC-proxy receives the application layer service information message sent by the SCF node in the P2P network, obtains the address information of the PCE, and then sends an application layer QoS request message to the PCE; and/or After receiving the Diameter message sent by the PCE, the RC-proxy obtains the address information of the corresponding SCF node, and then sends a policy control related message to the SCF node.
- Step 401 When a call needs to be made, the SCF node obtains the address information of the RC-proxy, and then establishes a connection with the RC-proxy;
- the SCF node is a Peer node in a P2P network, and the functions implemented by the SCF node are: responsible for user access, session control, and service triggering;
- the SCF node sends a message to the RC-proxy for the first time, the SCF node needs to perform step 401.
- the SCF node does not need to perform step 401 to send a message to the RC-proxy. ;
- the RC-proxy accesses the P2P network through the client of the P2P.
- the specific access process is the same as the prior art, and is not described here.
- the RELOAD protocol is adopted between the SCF node and the RC-proxy. Routing, so, can be fully integrated with the existing network; RC-proxy and SCF nodes do not limit the protocol used to transmit application layer QoS request messages and policy control related information, between RC-proxy and SCF nodes
- the protocol used by the application layer QoS request message and the policy control related information may specifically be a RELOAD protocol, or a Diameter protocol, or other suitable application layer protocol;
- the obtaining the address information of the RC-proxy is specifically:
- the Enrollment Server sends the configuration file containing the address information of the RC-proxy to the SCF node, and the SCF node obtains the address information of the RC-proxy according to this;
- the SCF node queries the tracker server in the P2P network to obtain the address information of the RC-proxy; or
- the SCF node finds the address information of the RC-proxy through the DHT algorithm.
- the tracker server After the RC-proxy joins the P2P network, it registers with the tracker server.
- the tracker server stores the RC-proxy address information and other related information.
- the related information is stored on a specific node in the P2P network, and the SCF node can find the address information of the RC-proxy through the DHT algorithm;
- the address information may be specifically: an IP address, or a domain name, or a Node ID, etc.; if the protocol used to transmit the application layer QoS request message and the policy control related information between the RC-proxy and the SCF node is not the RELOAD protocol, then When establishing a connection with the RC-proxy, the method may further include: The SCF node establishes an application layer connection with the RC-proxy;
- RC-Proxy can be deployed as a logical unit, or it can be set up with other network element devices.
- RC-Proxy can be deployed on PCE.
- Step 402 After receiving the application layer service information message sent by the SCF node, the RC-proxy obtains the address information of the PCE, and then sends an application layer QoS request message to the PCE; and/or, after receiving the Diameter message sent by the PCE, the RC-proxy receives the Diameter message sent by the PCE. Obtaining address information of the corresponding SCF node, and then sending a policy control related message to the SCF node;
- the application layer service information message includes: address information of the SCF node, user identifier, application layer service information, and a session identifier of a session between the SCF and the RC-proxy (SR, SCF-RC-proxy);
- the application layer service message is: application layer SDP information or application layer QoS information; specifically, if the function of the AF entity is deployed on the SCF node, the SCF node maps the application layer SDP information to the application layer QoS information, and then carries the application layer QoS information.
- the service information message is sent to the RC-proxy.
- the application layer service information sent by the SCF node to the RC-proxy is the application layer SDP information, and the RC-proxy receives the application layer SDP information.
- the specific mapping manner of the application layer SDP information and the application layer QoS information is the prior art;
- the protocol used to transmit the application layer QoS request message and policy control information between the RC-proxy and the PCE is adopted as the Diameter protocol.
- the protocol used to transmit the application layer QoS request message and the policy control related information between the RC-proxy and the SCF node and between the RC-proxy and the PCE is different, the RC-proxy will receive the application layer QoS request message and policy.
- the control information is processed by the protocol conversion, it is sent to the PCE or the SCF node; wherein the specific process of performing the protocol conversion may adopt an existing protocol conversion process;
- the PCE has the same function as the policy control function entity in the prior art.
- the PCE may be: a Policy and Charging Rules Function (PCRF) entity in the 3GPP PCC, or a RACS of TISPAN.
- PCF Policy and Charging Rules Function
- SPDF Service-based Policy Decision Function
- x-RACF ITU General Purpose RACF
- the diameter message may specifically be an acknowledgement message, or a time report message, or other policy control related message;
- the obtaining the address information of the PCE is specifically:
- RC-proxy queries the DRA to obtain the address information of the PCE;
- the RC-proxy obtains the address information of the PCE from the local carrier policy configuration.
- the RC-proxy obtains the address information of the PCE from the locally stored address information.
- the PC-proxy queries the DRA to obtain the address information of the PCE, and
- the process of obtaining the address information of the PCE from the local carrier policy configuration is the same as that of the prior art, and is not described here.
- the RC-proxy when it does not store the address information of the PCE in advance, it can query the DRA. Obtain the address information of the PCE, or obtain the address information of the PCE from the local carrier policy configuration.
- the RC-proxy After the RC-proxy obtains the address information of the PCE through the DRA query or the local carrier policy configuration, the RC-proxy can be locally The address information of the PCE is stored for use in the subsequent sending of the message.
- the specific implementation of the local storage PCE address information may be: establishing a binding relationship between the session identifier of the session between the SR and the address information of the PCE, that is, : Correspondence relationship, after the RC-proxy receives the application layer service information message, according to the message PCE address information corresponding to the session identifier session between the SR, to find; obtaining address information of the node corresponding to the SCF, in particular:
- the RC-proxy When the RC-proxy locally stores the address information of the corresponding SCF node in advance, the address information of the corresponding SCF node is directly obtained from the local device;
- the address information of the corresponding SCF node is queried from the P2P network according to the DHT algorithm;
- the implementation of the address information of the corresponding SCF node in the RC-proxy may be: establishing the address information of the PCE, the session identifier of the session between the SRs, and the user identifier, And the binding relationship between the information such as the address information of the SCF node, that is, the correspondence relationship, after the RC-proxy receives the Diameter message, and according to the binding relationship, the address information of the corresponding SCF node can be found;
- the RC-proxy locally stores the address information of the corresponding SCF node, the address information of the corresponding SCF node is directly obtained from the local device, and then the policy control related message is sent to the SCF node. Migration, and/or non-failed SCF nodes;
- the method may further include:
- the method may further include: before sending the policy control related message to the backup SCF node:
- RC-proxy establishes a connection with the backup SCF node
- the method may further include:
- the SCF node returns an error response message to the RC-proxy
- the RC-proxy After receiving the error response message, the RC-proxy updates the address information of the stored corresponding SCF node to the target SCF node to which the data is migrated according to the address of the target SCF node to which the data is migrated from the P2P network according to the DHT algorithm. Address information, and then sending a policy control related message to the target SCF node to which the data is migrated;
- the SCF node determines that the session identifier of the session between the SRs carried in the policy control related message does not exist locally, and then returns an error response message to the RC-proxy; the RC-proxy receives the error. After the message is answered, according to the error reason value in the message, it can be determined that the data corresponding to the received policy control related message has been migrated;
- the method may further include: before sending the policy control related message to the target SCF node that migrates the data, the method further includes:
- the RC-proxy establishes a connection with the target SCF node to which the data is migrated.
- Embodiment 1 is a diagrammatic representation of Embodiment 1:
- the application scenario of this embodiment is as follows: In the P2P core network, the SCF node sends the application layer service information to the PCE, and the implementation process of the PCE reporting the policy control related event to the SCF node.
- the method used by the RC-proxy and the SCF node to transmit the application layer QoS message and the policy control related information between the RC-proxy and the PCE is the same.
- the method for implementing the policy control in this embodiment is as shown in FIG. Includes the following steps:
- Step 501 The SCF node obtains the address information of the RC-proxy when the call needs to be performed.
- the SCF node obtains the address information of the RC-proxy, which is specifically:
- the Enrollment Server sends the configuration file containing the address information of the RC-proxy to the SCF node, and the SCF node obtains the address information of the RC-proxy according to this;
- the SCF node queries the tracker server in the P2P network to obtain the address information of the RC-proxy; or
- the SCF node finds the address information of the RC-proxy through the DHT algorithm.
- the tracker server After the RC-proxy joins the P2P network, it registers with the tracker server.
- the tracker server stores the RC-proxy address information and other related information.
- the related information is stored on a specific node in the P2P network, and the SCF node can find the address information of the RC-proxy through the DHT algorithm;
- the address information may specifically be: an IP address, or a domain name, or a Node ID; the following description
- the address information is a Node ID.
- Step 502 After obtaining the Node ID of the RC-proxy, the SCF node sends an attach request message to the RC-proxy.
- the Attach request message is routed in the P2P network according to the Node ID of the RC-proxy, and finally reaches the RC-proxy.
- Step 503 After receiving the Attach request message, the RC-proxy returns a Connection Request Response (AttachReqAns) message to the SCF node.
- AttachReqAns Connection Request Response
- the RC-proxy After the RC-proxy returns the AttachReqAns message to the SCF node, it indicates that the SCF node establishes an IP connection with the RC-proxy.
- Step 504 After receiving the AttachReqAns message, the SCF node sends an application layer connection request (AppAttach) message to the RC-proxy.
- AppAttach application layer connection request
- Step 505 After receiving the AppAttach request message, the RC-proxy returns an application layer connection request response (AppAttachAns) message to the SCF node.
- AppAttachAns application layer connection request response
- the RC-proxy After the RC-proxy returns the AppAttachAns message to the SCF node, it indicates that the SCF node establishes an application layer connection with the RC-proxy;
- the specific implementation of the steps 502-505 is the same as the prior art, and is not described here.
- the purpose of the steps 504-505 is as follows:
- the SCF node obtains the application layer IP address of the RC-proxy, and establishes an application layer connection. Applicable to the case where an application layer protocol such as the diameter protocol is used between the SCF node and the RC-Proxy.
- an application layer protocol such as the diameter protocol
- steps 504 to 505 is applicable to an application layer IP that requires an upper layer protocol such as a diameter protocol and an unknown RC-proxy.
- the situation of the address If the RELOAD protocol is used between the SCF node and the RC-Proxy, steps 504-505 may not be performed;
- Step 506 After receiving the AppAttachAns message, the SCF node sends an application layer service information message to the RC-proxy.
- the application layer service information message includes: address information of the SCF node, user identity, application layer service information, and a session identifier of the session between the SRs;
- the session identifier of the session between the SRs is a string generated by the SCF node, and is used to identify a session between the SCF node and the RC-proxy.
- the application layer service information refers to: application layer SDP information or application layer QoS information; where, whether the application layer service information is the application layer SDP information or the application layer QoS information is determined by the deployment of the function of the AF entity, specifically, If the function of the AF entity is deployed on the SCF node, the SCF node maps the application layer SDP information to the application layer QoS information, and carries the information in the application layer service information message to the RC-proxy, if the function of the AF entity is deployed in the RC- On the Proxy, the application layer service information sent by the SCF node to the RC-proxy is the application layer SDP information. After receiving the application layer SDP information, the RC-proxy maps the application layer SDP information to the application layer QoS information.
- the specific mapping manner of information and application layer QoS information is prior art;
- the specific protocol used between the SCF node and the RC-proxy is not limited, and the RELOAD protocol or the upper layer application protocol such as the Diameter protocol may be used.
- Step 507 ⁇ 508 After receiving the application layer service information message, the RC-proxy obtains the address information of the PCE; and then sends an application layer QoS request message to the PCE;
- the method for obtaining the address information of the PCE by the RC-proxy may be the same as the prior art, and the method for obtaining the address information of the PCE by the PC-proxy is the same as that of the prior art. , no longer repeat them here;
- the PCE sends an application layer QoS request message, specifically:
- the application layer service information received by the RC-proxy is the application layer SDP information
- the RC-proxy maps the application layer SDP information into the application layer QoS information, and then applies the layer QoS information.
- the bearer is sent to the PCE in the application layer QoS request message; If the function of the AF entity is deployed on the SCF node, the application layer service information received by the RC-proxy is the application layer QoS information, and the RC-proxy directly sends the application layer QoS information in the application layer QoS request message to the PCE.
- the application layer QoS request message sent by the RC-proxy to the PCE is carried in a diameter message, where the diameter message includes application layer QoS information, session-ID of the diameter session, and RC-proxy address information;
- the RC-proxy After obtaining the address information of the PCE, the RC-proxy stores the session identifier of the session between the SRs, the address information of the SCF node, the user identifier, the diameter session-ID, and the address information of the PCE.
- the binding relationship is performed, that is, the subsequent RC-proxy can obtain the PCE address information and the address information of the SCF node according to the binding relationship.
- Step 509 After receiving the application layer QoS request message, the PCE stores the service information, and returns a Diameter confirmation message to the RC-proxy.
- the Diameter confirmation message described here contains the session-ID.
- Step 510 ⁇ 511 After receiving the Diameter confirmation message, the RC-proxy obtains the address information of the SCF node; and then sends an acknowledgement message to the SCF node;
- the acknowledgment message sent to the SCF node carries the session identifier of the session between the SRs;
- the RC-proxy obtains the address information of the SCF node, which is specifically as follows:
- the locally stored binding relationship is queried, so that the address information of the SCF node is obtained.
- Step 512 When the PCE needs to report the event to the RC-proxy, the PCE sends a Diameter event report message to the RC-proxy.
- the Diameter event report message carries information such as a report event, a user identifier, and a diameter session-ID.
- Steps 513-514 After receiving the Diameter event report message, the RC-proxy obtains the SCF. Address information of the node; then sending an event report message to the SCF node;
- the event report message sent to the SCF node carries a session identifier of the session between the SRs, and a notification event;
- the RC-proxy obtains the address information of the SCF node, which is specifically:
- the local storage binding relationship is queried according to the session-ID in the Diameter event report message, so that the address information of the SCF node is obtained.
- Step 515 After receiving the event report message, the SCF node sends an acknowledgment message to the RC-proxy.
- the acknowledgment message carries the session identifier of the session between the SRs.
- Step 516 After receiving the acknowledgment message, the RC-proxy queries the locally stored binding relationship according to the session identifier of the session between the SRs, obtains the address information of the PCE, and then sends an acknowledgement to the PCE.
- the application scenario of this embodiment is as follows: In the core network of the ⁇ 2 ⁇ , the SCF node that processes the service fails in the policy control process of one session, that is, the SCF node is down or exits the core network, where the RC-proxy has been previously
- the session identifier of the session between the SRs, the address information of the SCF node, the user identifier, the diameter session-ID, and the binding information of the PCE address information are stored, where the RC-proxy and the SCF node, and the RC-proxy
- the protocol used to transfer application layer QoS messages and policy control related information to the PCE is the same.
- the backup SCF node of the failed SCF node takes over the failed SCF node to process the service.
- the method for implementing policy control in this embodiment, as shown in FIG. 6, includes the following steps:
- Step 601 When the PCE needs to report the event to the RC-proxy, the PCE sends a Diameter event report message to the RC-proxy.
- the Diameter event report message carries information such as a report event, a user identifier, and a diameter session-ID.
- Step 602 The RC-proxy receives the Diameter event report message, and learns the processing service.
- the DHT algorithm is used to query the address information of the backup SCF node of the failed SCF node from the P2P network, and the address information of the backup SCF node is used instead of the pre-stored binding. Address information of the failed SCF node in the relationship
- the method for the RC-proxy to learn that the SCF node that handles the service is invalid can use the existing technology, and details are not described herein again.
- Step 603 The RC-proxy sends an Attach request message to the backup SCF node.
- the backup SCF node can learn that the SCF node that processes the service fails by using the prior art.
- the backup SCF node sends an Attach request message to the RC-proxy, so as to be associated with the RC-proxy. Establishing an IP connection and an application layer connection, thereby replacing the failed SCF node processing service; wherein, the backup SCF node can obtain the address information of the RC-proxy through the backup information of the invalid SCF node;
- the Attach request message is routed in the P2P network according to the Node ID of the RC-proxy, and finally reaches the RC-proxy.
- Step 604 After receiving the Attach request message, the backup SCF node returns an AttachReqAns message to the RC-proxy.
- the backup SCF node After the backup SCF node returns the AttachReqAns message to the RC-proxy, it indicates that the backup SCF node establishes a connection with the RC-proxy.
- Step 605 After receiving the AttachReqAns message, the RC-proxy sends the message to the backup SCF node.
- Step 606 After receiving the AppAttach request message, the backup SCF node returns an AppAttachAns message to the RC-proxy.
- the backup SCF node After the backup SCF node returns the AppAttachAns message to the RC-proxy, it indicates that the backup SCF node establishes an application layer connection with the RC-proxy;
- the specific implementation of the steps 603-606 is the same as the prior art, and is not described here.
- the purpose of the steps 605-606 is as follows: The RC-proxy obtains the application layer IP address of the backup SCF node, and establishes an application layer connection. The situation is applicable to the case where the application layer protocol such as the diameter protocol is used between the backup SCF node and the RC-Proxy. In other words, the implementation of steps 605-606 applies to the upper layer protocol such as the diameter protocol, and the application layer of the backup SCF node is unknown.
- steps 605-606 may not be performed.
- Step 607 Send an event report message to the backup SCF node.
- Step 608 After receiving the event report message, the backup SCF node sends an acknowledgement message to the RC-proxy.
- the acknowledgement message carries the session identifier of the session between the SRs.
- Step 609 After receiving the acknowledgement message, the RC-proxy queries the local storage binding relationship according to the session identifier of the session between the SRs, obtains the address information of the PCE, and then sends an acknowledgement message to the PCE.
- Embodiment 3 is a diagrammatic representation of Embodiment 3
- the application scenario of this embodiment is as follows: In the P2P core network, the SCF node processing the service data migration occurs during the policy control process of one session, that is, part of the user data and service information processed by the SCF node handling the service are migrated to another An SCF node, wherein the RC-proxy has previously stored the session identifier of the session between the SRs, the address information of the SCF node, the user identifier, the diameter session-ID, and the binding relationship of the PCE address information, RC-proxy and The protocols used to transfer application layer QoS messages and policy control related information between SCF nodes and between RC-proxy and PCE are the same.
- SCF 1 the SCF node that handles the service
- SCF 2 the target SCF node that migrates the data
- Step 701 When the PCE needs to report an event to the RC-proxy, the PCE sends the RC-proxy Diameter event reporting message;
- the Diameter event report message carries information such as a report event, a user identifier, and a diameter session-ID.
- Steps 702 ⁇ 703 After receiving the Diameter event report message, the RC-proxy obtains the address information of the SCF1; and then sends an event report message to the SCF1;
- the event report message sent to the SCF 1 carries a session identifier of the session between the SRs, and a notification event;
- the RC-proxy obtains the address information of the SCF 1, which is specifically:
- the local storage binding relationship is queried according to the session-ID in the Diameter event report message, so that the address information of the SCF 1 is obtained.
- Step 704 After receiving the event report message, and determining that the session identifier of the session between the SRs carried in the message does not exist locally, the SCF 1 returns an error response message to the RC-proxy.
- the SCF 1 will not have any information of the migrated data locally, and accordingly, the SCF 1 determines that the session identifier of the session between the SRs carried in the message does not exist locally; the error response message carries The cause of the error, ie: The session ID of the session between the SRs does not exist.
- Step 705 After receiving the error response message, the RC-proxy re-acquires the address information of the new SCF node from the P2P network according to the hash value of the user identifier, and obtains the address information of the SCF 1 in the binding relationship.
- the address information of the new SCF node, that is, the SCF 2 is updated.
- the RC-proxy can learn that the related user data and service information in the SCF 1 have been migrated according to the error.
- Step 706 The RC-proxy sends an Attach request message to the SCF 2.
- Step 707 After receiving the Attach request message, the SCF 2 returns an AttachReqAns message to the RC-proxy.
- Step 708 After receiving the AttachReqAns message, the RC-proxy sends an AppAttach message to the SCF 2.
- Step 709 After receiving the AppAttach request message, the SCF 2 returns to the RC-proxy.
- the SCF 2 After the SCF 2 returns the AppAttachAns message to the RC-proxy, it indicates that the SCF 2 establishes an application layer connection with the RC-proxy;
- the specific implementation of the steps 706-709 is the same as the prior art, and is not described here.
- the purpose of the steps 708-709 is as follows:
- the RC-proxy obtains the application layer IP address of the SCF 2, and establishes an application layer connection. Applicable to the case where the application layer protocol such as the diameter protocol is used between the SCF 2 and the RC-Proxy. In other words, the case of performing steps 708 to 709 is applicable to the upper layer protocol such as the use of the diameter protocol, and the application layer IP address of the SCF2 is unknown. happening. If the RELOAD protocol is used between SCF 2 and RC-Proxy, no steps can be performed.
- Step 710 Then send an event report message to the SCF 2.
- Step 711 After receiving the event report message, the SCF 2 sends an acknowledgement message to the RC-proxy.
- the acknowledgement message carries the session identifier of the session between the SRs.
- Step 712 After receiving the acknowledgement message, the RC-proxy queries the locally stored binding relationship according to the session identifier of the session between the SRs, obtains the address information of the PCE, and then sends an acknowledgement message to the PCE.
- Embodiment 4 is a diagrammatic representation of Embodiment 4:
- the application scenario of this embodiment is as follows: In the P2P core network, the SCF node sends the application layer service information to the PCE, and the implementation process of the PCE reporting the policy control related event to the SCF node.
- the RC-proxy does not store the binding relationship locally, that is, does not store the address information of the SCF node, and transmits the application layer QoS message and the policy control related information between the RC-proxy and the SCF node, and between the RC-proxy and the PCE.
- the adopted protocol is the same, and the method for implementing the policy control is implemented in this embodiment. As shown in Figure 8, the following steps are included:
- Step 801 The SCF node acquires the address information of the RC-proxy when the call needs to be performed.
- the SCF node obtains the address information of the RC-proxy, which is specifically:
- the Enrollment Server sends the configuration file containing the address information of the RC-proxy to the SCF node, and the SCF node obtains the address information of the RC-proxy according to this;
- the SCF node queries the tracker server in the P2P network to obtain the address information of the RC-proxy; or
- the SCF node finds the address information of the RC-proxy through the DHT algorithm.
- the tracker server After the RC-proxy joins the P2P network, it registers with the tracker server.
- the tracker server stores the RC-proxy address information and other related information.
- the related information is stored on a specific node in the P2P network, and the SCF node can find the address information of the RC-proxy through the DHT algorithm;
- the address information may be specifically: an IP address, or a domain name, or a Node ID. In the following description, the address information is a Node ID.
- Step 802 After obtaining the Node ID of the RC-proxy, the SCF node sends an Attach request message to the RC-proxy.
- the Attach request message is routed in the P2P network according to the Node ID of the RC-proxy, and finally reaches the RC-proxy.
- Step 803 After receiving the Attach request message, the RC-proxy returns to the SCF node.
- the RC-proxy After the RC-proxy returns the AttachReqAns message to the SCF node, it indicates that the SCF node establishes a connection with the RC-proxy.
- Step 804 After receiving the AttachReqAns message, the SCF node sends an AppAttach message to the RC-proxy.
- Step 805 After receiving the AppAttach request message, the RC-proxy returns an AppAttachAns message to the SCF node.
- the RC-proxy After the RC-proxy returns the AppAttachAns message to the SCF node, it indicates that the SCF node establishes an application layer connection with the RC-proxy;
- the specific implementation of the steps 802-805 is the same as the prior art, and is not described here.
- the purpose of the steps 804-805 is as follows:
- the SCF node obtains the application layer IP address of the RC-proxy, and establishes an application layer connection. Applicable to the application layer protocol such as the diameter protocol between the SCF node and the RC-Proxy.
- the implementation of steps 804-805 is applicable to the application layer IP of the upper layer protocol, such as the diagnostic protocol, and the unknown RC-proxy. The situation of the address. If the RELOAD protocol is used between the SCF node and the RC-Proxy, steps 804-805 may not be performed;
- the SCF node When the SCF node sends a message to the RC-proxy for the first time in the call, it needs to perform steps 801-805. After the connection is established, the SCF node does not need to perform steps 801-805 to send the message to the RC-proxy. -proxy sends a message.
- Step 806 After receiving the AppAttachAns message, the SCF node sends an application layer service information message to the RC-proxy.
- the application layer service information message includes address information of the SCF node, a user identifier, application layer service information, and a session identifier of a session between the SRs;
- the session identifier of the session between the SRs is a string generated by the SCF node, and is used to identify a session between the SCF node and the RC-proxy.
- the application layer service information refers to: application layer SDP information or application layer QoS information; where, whether the application layer service information is the application layer SDP information or the application layer QoS information is determined by the deployment of the function of the AF entity, specifically, If the function of the AF entity is deployed on the SCF node, the SCF node maps the application layer SDP information to the application layer QoS information and sends the information to the RC-proxy. If the function of the AF entity is deployed on the RC-Proxy, the SCF node goes to the RC. -proxy sent The application layer service information is the application layer SDP information. After receiving the application layer SDP information, the RC-proxy maps the application layer SDP information to the application layer QoS information.
- the specific mapping mode of the application layer SDP information and the application layer QoS information is Have technology;
- the specific protocol used between the SCF node and the RC-proxy is not limited, and the RELOAD protocol or the upper layer application protocol such as the Diameter protocol may be used.
- Steps 807-808 After receiving the application layer service information message, the RC-proxy obtains the address information of the PCE; and then sends an application layer QoS request message to the PCE;
- the method for obtaining the address information of the PCE by the RC-proxy may be the same as the prior art, and the method for obtaining the address information of the PCE by the PC-proxy is the same as that of the prior art. , no longer repeat them here;
- the PCE sends an application layer QoS request message, specifically:
- the application layer service information received by the RC-proxy is the application layer SDP information, and the RC-proxy maps the application layer SDP information into the application layer QoS information, and then applies the layer QoS information.
- the bearer is sent to the PCE in the application layer QoS request;
- the application layer service information received by the RC-proxy is an application layer QoS message, and the RC-proxy directly sends the bearer in the application layer QoS request to the PCE.
- the application layer QoS request sent by the RC-proxy to the PCE is carried in the diameter message, where the diameter message includes application layer QoS information, session-ID of the diameter session, and RC-proxy address information;
- the binding relationship between the session identifier of the session and the address information of the PCE is saved.
- Step 809 After receiving the application layer QoS request message, the PCE stores the service information, and returns a Diameter confirmation message to the RC-proxy.
- the Diameter confirmation message includes: a session-ID, a user identifier, and the like.
- the acknowledgment message sent to the SCF node carries the session identifier of the session between the SRs.
- Step 812 When the PCE needs to report the event to the RC-proxy, the PCE sends a Diameter event report message to the RC-proxy.
- the Diameter event report message carries information such as a report event, a user identifier, and a diameter session-ID.
- Steps 813-814 After receiving the Diameter event report message, the RC-proxy uses the DHT algorithm to query the address information of the corresponding SCF node from the P2P network according to the hash value of the user identifier, and then sends an event report message to the SCF node.
- the event report message sent to the SCF node carries a session identifier of the session between the SRs, and a notification event.
- Step 815 After receiving the event report message, the SCF node sends an acknowledgement message to the RC-proxy.
- the acknowledgement message carries the session identifier of the session between the SRs.
- Steps 816 ⁇ 817 After receiving the acknowledgment message, the RC-proxy queries the locally stored binding relationship according to the session identification query of the session between the SRs, obtains the address information of the PCE, and then sends a confirmation message to the PCE.
- the present invention further provides a system for implementing policy control in a P2P network.
- the system includes: a first SCF node 91, an RC-proxy 92, and a PCE 93;
- the first SCF node 91 is configured to send an application layer service information message to the RC-proxy 92 during the call; and/or receive a policy control related message sent by the RC-proxy 92;
- the RC-proxy 92 is configured to receive the application layer service information message sent by the first SCF node 91. Then, the address information of the PCE 93 is obtained, and the application layer QoS request message is sent to the PCE 93; and/or, after receiving the Diameter message sent by the PCE 93, the address information of the corresponding SCF node is obtained, and the information is sent to the first SCF node 91. Send a policy control related message;
- the PCE 93 is configured to receive an application layer QoS request message sent by the RC-proxy 92, and/or send a Diameter message to the RC-proxy 92.
- the first SCF node 91 is further configured to: when sending a message to the RC-proxy for the first time in a call, obtain the address information of the RC-proxy 92, and establish a connection with the RC-proxy 92; the RC-proxy 92. Also used to establish a connection with the first SCF node 91.
- the protocol for transmitting the application layer QoS request message and the policy control related information between the RC-proxy 92 and the first SCF node 91 is not the RELOAD protocol, when establishing a connection with the RC-proxy 92, the first SCF node 91.
- the RC-proxy 92 is further configured to establish an application layer connection with the first SCF node 91.
- the system may further include a second SCF node, which is a backup SCF node of the first SCF node 91, and is configured to receive a policy control related message sent by the RC-proxy 92;
- the RC-proxy 92 When the address information of the corresponding SCF node is obtained, and when the RC-proxy 92 locally stores the address information of the first SCF node 91, if the RC-proxy 92 learns that the first SCF node 91 has failed, the RC-proxy 92 And for querying the address information of the second SCF node from the P2P network according to the DHT algorithm, updating the stored address information of the first SCF node 91 to the address information of the second SCF node, and sending the policy control to the second SCF node.
- the RC-proxy 92 is further configured to establish a connection with the second SCF node before sending the policy control related message to the second SCF node.
- the second SCF node is further configured to establish a connection with the RC-proxy 92.
- the system may further include: a third SCF node, a target SCF node for data migration, configured to receive a policy control related message sent by the RC-proxy 92;
- the RC-proxy 92 When the RC-proxy 92 locally stores the address information of the corresponding SCF node in advance, and When the RC-proxy 92 determines that the data corresponding to the received policy control related message has been migrated, the first SCF node is further used to return an error response message to the RC-proxy 92.
- the RC-proxy 92 is further configured to: after receiving the error response message returned by the first SCF node 91, query the address of the third SCF node from the P2P network according to the DHT algorithm, and store the corresponding first SCF node 91.
- the address information is updated to the address information of the third SCF node, and the policy control related message is sent to the third SCF node.
- the RC-proxy 92 is further configured to establish a connection with the third SCF node before sending the policy control related message to the third SCF node.
- the third SCF node is further configured to establish a connection with the RC-proxy 92.
- the present invention further provides an RC-proxy for implementing policy control in a P2P network.
- the RC-proxy includes: an obtaining module 101 and a sending module 102;
- the obtaining module 101 is configured to: after receiving the application layer service information message sent by the SCF node, obtain the address information of the PCE, and send the obtained address information of the PCE to the sending module 102; and/or receive the Diameter message sent by the PCE. After obtaining the address information of the corresponding SCF node, and sending the obtained address information of the SCF node to the sending module 102;
- the sending module 102 is configured to: after receiving the address information of the PCE sent by the obtaining module 101, send an application layer QoS request message to the PCE; and/or, after receiving the address information of the SCF node sent by the obtaining module 101, send the address information to the SCF node. Policy control related messages.
- the obtaining module 101 is configured to: query the DRA to obtain the address information of the PCE; or obtain the address information of the PCE from the local operator policy configuration; or The address information of the PCE is obtained from the stored address information.
- the obtaining module 101 is specifically configured to: when locally storing the address information of the corresponding SCF node, directly obtain the address information of the corresponding SCF node locally; When the address information of the corresponding SCF node is stored, the address information of the corresponding SCF node is queried from the P2P network according to the DHT algorithm.
- the obtaining module 101 is further configured to use the PHT network according to the DHT algorithm.
- the address information of the backup SCF node of the failed SCF node is updated, the address information of the stored failed SCF node is updated to the address information of the backup SCF node, and the address information of the backup SCF node is sent to the sending module 102.
- the sending module 102 is further configured to: after receiving the address information of the backup node sent by the obtaining module 101, send a policy control related message to the backup SCF node.
- the obtaining module 101 is further configured to migrate data from the P2P network to the query according to the DHT algorithm.
- the address of the target SCF node is updated, the address information of the stored corresponding SCF node is updated to the address information of the target SCF node to which the data is migrated, and the address information of the target SCF node to which the data is migrated is sent to the sending module 102.
- the sending module 102 is further configured to: after receiving the address information of the target SCF node to which the data sent by the acquiring module 101 is migrated, send a policy control related message to the target SCF node to which the data is migrated.
- the transmitting module 102 is further configured to receive the received application layer when the protocol used to transmit the application layer QoS request message and the policy control related information between the RC-proxy and the SCF node and between the RC-proxy and the PCE is different.
- the QoS request message, and/or the policy control related information is subjected to protocol conversion processing, and the application layer QoS request message and/or the policy control related information processed by the protocol conversion are respectively sent to the PCE and/or the SCF node;
- the RC-proxy may further include a storage module for storing address information of the PCE, And/or address information of the SCF node.
- the RC-proxy may further include: establishing a connection module, configured to establish a connection with the SCF node.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
La présente invention se rapporte à un procédé de contrôle de politique dans un réseau de pair à pair (P2P, peer-to-peer). Le procédé selon l'invention comprend les étapes suivantes : durant un appel, un proxy de contrôle de ressource (RC-proxy) obtient les informations d'adresse d'une entité de contrôle de politique (PCE, Policy Control Entity) après réception d'un message de données de service de couche application envoyé par un nœud de fonction de contrôle de service (SCF, Service Control Function) dans un réseau P2P, et il envoie ensuite un message de demande de qualité de service (QoS, Quality of Service) de couche application à la PCE ; ou bien, le RC-proxy obtient les informations d'adresse du nœud SCF correspondant après réception d'un message Diameter envoyé par la PCE, et il envoie ensuite un message relatif à un contrôle de politique au nœud SCF. La présente invention se rapporte d'autre part à un système et à un proxy de contrôle de ressource pour un contrôle de politique dans un réseau P2P. La solution technique de la présente invention permet de réaliser efficacement un contrôle de politique dans un réseau P2P.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110100727.3 | 2011-04-21 | ||
CN201110100727.3A CN102752331B (zh) | 2011-04-21 | 2011-04-21 | 对等网络中实现策略控制的方法、资源控制代理及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2012142978A1 true WO2012142978A1 (fr) | 2012-10-26 |
Family
ID=47032230
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2012/074562 WO2012142978A1 (fr) | 2011-04-21 | 2012-04-23 | Procédé, proxy de contrôle de ressource et système pour un contrôle de politique dans un réseau de pair à pair |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN102752331B (fr) |
WO (1) | WO2012142978A1 (fr) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105208654B (zh) * | 2014-06-20 | 2020-09-01 | 中兴通讯股份有限公司 | 一种通知消息发送方法及装置 |
CN108282525B (zh) * | 2018-01-22 | 2021-03-30 | 浙江省公众信息产业有限公司 | 基于对等网络的视频资源管理系统和方法 |
CN109815294B (zh) * | 2019-02-14 | 2019-12-20 | 北京谷数科技有限公司 | 一种无主节点分布并行数据存储方法和系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101465920A (zh) * | 2007-12-17 | 2009-06-24 | 华为技术有限公司 | 一种资源控制代理方法、系统和装置 |
CN101720110A (zh) * | 2009-01-14 | 2010-06-02 | 中兴通讯股份有限公司 | 一种ngn家庭网络资源接纳控制方法及系统 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB0508847D0 (en) * | 2005-04-29 | 2005-06-08 | Nokia Corp | A network |
US20080049648A1 (en) * | 2006-08-28 | 2008-02-28 | Motorola, Inc. | Method and apparatus for policy management for an internet protocol multimedia subsystem based wireless communication system |
CN101222453B (zh) * | 2008-01-22 | 2014-07-02 | 中兴通讯股份有限公司 | 一种家庭网关策略控制方法及系统 |
-
2011
- 2011-04-21 CN CN201110100727.3A patent/CN102752331B/zh not_active Expired - Fee Related
-
2012
- 2012-04-23 WO PCT/CN2012/074562 patent/WO2012142978A1/fr active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101465920A (zh) * | 2007-12-17 | 2009-06-24 | 华为技术有限公司 | 一种资源控制代理方法、系统和装置 |
CN101720110A (zh) * | 2009-01-14 | 2010-06-02 | 中兴通讯股份有限公司 | 一种ngn家庭网络资源接纳控制方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN102752331A (zh) | 2012-10-24 |
CN102752331B (zh) | 2017-11-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8914486B2 (en) | Method, system and device for implementing identity identifier and location separation | |
JP5349580B2 (ja) | サービスノード、その制御方法、ユーザノード、及びその制御方法 | |
JP2012511846A (ja) | Nat経由のデータセッションのポリシー及び課金制御のための制御セッションのトークンベースの相関 | |
WO2007093124A1 (fr) | Procédé et système d'ordonnancement de ressources multimédia | |
WO2014173252A1 (fr) | Procédé de gestion de sessions, entité fonctionnelle d'application, serveur de politiques et convertisseur de protocole | |
WO2008148320A1 (fr) | Procédé, dispositif et système pour un contrôle d'autorisation d'un service de multidiffusion | |
WO2013040970A1 (fr) | Procédé et dispositif de sélection de nœud de relais | |
WO2011038637A1 (fr) | Procédé permettant d'établir un appel de bout en bout, terminal d'appel de bout en bout et système | |
WO2009000181A1 (fr) | Procédé servant à acquérir des ressources transversales, un nœud pair à pair et un système pair à pair | |
WO2011006320A1 (fr) | Procédé et système de connexion avec dédoublement didentifiant et demplacement dans un réseau de nouvelle génération | |
WO2011032426A1 (fr) | Procédé, dispositif et système de mise en œuvre de service de priorité d'appel d'urgence | |
WO2014114088A1 (fr) | Procédé et plate-forme de services pour mise en œuvre d'une fonction de services à haut débit dans un réseau de prochaine génération (ngn) | |
CN102857536B (zh) | 对等网络中实现数据备份及迁移的方法及系统 | |
WO2012142978A1 (fr) | Procédé, proxy de contrôle de ressource et système pour un contrôle de politique dans un réseau de pair à pair | |
US20140330905A1 (en) | Apparatus and method for setting up active networking of smart devices for providing converged service | |
WO2010075721A1 (fr) | Procédé et système pour une régulation de niveau d'utilisateur ims en fonction des données d'abonnement | |
WO2008080341A1 (fr) | Procédé, système et dispositif d'identification d'un terminal d'utilisateur | |
WO2011120365A1 (fr) | Procédé et système d'établissement de connexion entre terminaux multiconnectés | |
WO2009079843A1 (fr) | Procédé pour réaliser une gestion d'accès aux ressources en mode du pousser en situation de nomadisme de réseau de prochaine génération | |
CN102624759B (zh) | 一种实现会话中数据迁移的方法和节点 | |
WO2009043289A1 (fr) | Procédé pour déterminer la relation de trajet de flux multimédia et système de commande d'appel | |
WO2011120276A1 (fr) | Procédé et système permettant d'établir une connexion entre des terminaux | |
WO2008154850A1 (fr) | Procédé, entité et système pour effectuer un transfert d'adresse de réseau | |
WO2021204292A1 (fr) | Procédé, appareil et système de découverte d'application, et support de stockage informatique | |
WO2008055448A1 (fr) | Procédé, appareil et système d'acquisition d'informations d'accès d'un terminal utilisateur |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12773854 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 12773854 Country of ref document: EP Kind code of ref document: A1 |