A METHOD AND SYSTEM FOR POLICY-BASED CONTROL IN A DISTRIBUTED NETWORK

Description

BACKGROUND OF THE INVENTION

Technical Field of the invention

[0001] The present invention relates generally to a method for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication.

Description of Related Art

[0002] In an open services market, network operators will have to provide highly secure, open, standard interfaces to their networks. Policy-based control of a network is a recent approach to meet these requirements by distribution of functionality among network components and simplifying linking the distributed functionality to one another by employing policies. Policies are statements that dictate what policy enforcements and behaviours are permitted and on which events (hereinafter called Events) in a computer- or telecommunications network. A network administrator may define a set of policies governing the network.

[0003] According to the state of the art there are methods and systems developed for policy enforcement and policy management. Patent application EP1091526A, discloses a system defining the role of routers and exchanged information as policy enforcement points (PEPs) as clients in conjunction with policy decision points (PDPs) as servers, according to the COPS protocol defined by IETF. Additionally, policies are spread among domains with the help of interconnected PDPs. A negotiation protocol is used to exchange policies between the different PDPs.

[0004] Policy management and policy evaluation is e.g. currently drafted by a Parlay Policy Management Working Group of the Parlay Group, which is a multi-vendor consortium formed to enable the development of applications that operate across multiple, networking-platform environments by developing open, technology-independent application programming interfaces (APIs). The Parlay Policy Management Working Group (PPMWG) is set up to maintain and enhance the Parlay Policy Management and -Evaluation APIs that enable management of policy domains within the network which domains are firstly independent of network architectures and secondly independent of transport/application protocols. The draft of the PPMWG on policy management covers the composition of policies and the latest contributions also describe policy evaluation.

[0005] One example of policies being applied is that currently, networks may provide different services to clients by employing the aforementioned policy management methods. These networks rely on traffic handling mechanisms of the network elements that are transferring data. These elements are mostly switches, routers, proxies and protocol gateways. Such protocol gateways have for instance been defined in Parlay. Also examples of these elements are "Common Service Enablers" and "Other Service Enablers" as defined by OMA. An enabler (Enabler), in this context, is a logical entity that offers certain services. Its services may typically be invoked by means of an interface.

[0006] The traffic handling mechanisms include mechanisms that determine to which flow traffic belongs, and queuing mechanisms by which resources may be assigned to a particular flow. Network elements that support traffic handling mechanisms are also referred to as Policy Enforcement Points (PEPs) because they are able to apply policies to the traffic transferred by them. In addition, network elements must support mechanisms by which their traffic handling functionality can be executed or configured. Typically, PEPs are associated with some form of Policy Server, also known as a Policy Decision Point (PDP). Typically, a PDP supports one or more commonly known configuration protocols, such as Common Open Policy Services (COPS), which is a protocol between a PEP and a PDP, where the PEP requests a decision from the PDP. For top-down provisioning, a PDP may use COPS-PR to push top-down configuration information to associated PEPs. COPS-PR is an extension to COPS where the PDP contacts a PEP.

[0007] Some PEPs may include PDP functionality locally. Others may invoke the PDP functionality from a separate Policy Server. In this way PEPs and PDPs work together to apply policies, acting on policy data related to e.g. business to business configuration, privacy, security and authorisation, that are typically stored in some form of register database (hereinafter called Register).

[0008] The described state of the art specifications consider the PEP a client and the PDP a server. An example of this approach is the aforementioned COPS protocol. The Internet Engineering Task Force (IETF) is further developing COPS. COPS may be applied in a client/server model for supporting policy control over quality of service signaling protocols, but may in general be applied to any other situation with distributed control. The policy framework illustrated in the COPS specification describes the entities PEP and PDP and the mechanism for the PEP to initiate a relation establishment with a PDP. It also describes messages for the interaction between the PEP and the PDP. The model is based on the server returning decisions to policy requests, wherein the PEP sends a request to the PDP to become its client and wherein the PDP as server decides whether or not to accept the PEP client.

[0009] Other models that refer to policy management are described in e.g. the Policy Core Information Model (RFC3060), which defines in Unified Modeling Language notation, the classes that a policy may be composed of (policy, policy rule, policy rule Event, policy rule Action); and Radius (RFC2138) and Diameter, which may be used to request decisions regarding network access.
Systems according to the current art comprise a PEP sending out a decision request to a PDP when a specific Event occurs at the entity implementing the PEP. The PEP sends information about the Event or a pointer to such information to the PDP. The PDP evaluates the Events against policy and decides the appropriate policy enforcement. Subsequently the PDP returns its decision on how the PEP must act on the Event to the PEP and the PEP carries out (enforces) the decision taken by the PDP.

[0010] Other standards like Radius do not cover the establishment of the Client/Server relationship or the PEP/PDP relationship or do not cover the exchange of Event notification and policy enforcement capabilities of the PEP. Event notification Capability in this context means the capability to notify Events that are occurring, such as a request for access to the network, a request for resource usage or a request for any other service. Policy enforcement capability in this context means modification by the PEP of such service request, (partial) refusal of such service request and/or performing other policy enforcements by the PEP that can be suggested by the PDP.

[0011] The current approach by systems, policy models, framework and standards, which considers the PEP a client of the PDP server has inherent limitations, and especially lack:

• Possibility for Multiple Stakeholders (hereinafter called Stakeholders) such as operators, application developers, vendors, governmental organizations, end-users or service providers, to subscribe to PEP capabilities outside their service domain; and
• An easy way for defining policies to be enforced by PEPs without having to first register the capabilities of the PEP.

DISCLOSURE OF THE INVENTION

[0012] In order to overcome the disadvantages of existing solutions, there is a need for methods and systems that efficiently enable stakeholders by their selves or in groups to determine their own policy enforcement upon Events and therefore fully control the PDP in their own domain.

[0013] The invention deals with this problem by providing the PEP with a server capability and turn the PDPs into clients of the PEP, being a server, in order to make more possibilities to solve the aforementioned disadvantages available.

[0014] The invention provides in a first aspect thereof a method and a system for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication network comprising messaging between network elements, comprising at least one PEP, one or more PDPs, which network elements provide for registering events, sending notifications of the occurrence of events and enforcing a policy upon said events if certain conditions are met, wherein the at least one PEP serves as a server towards at least one PDP, being a client.

[0015] In a second aspect of the invention, the PEP where the Events are occurring are being kept outside the Stakeholder's domain and therefore outside the domain where the PDP is located, which could be a third party domain.

[0016] In a third aspect of the invention, the Stakeholder registers its own PDP to the PEP to be able to suggest its decision to the PEP domain.

[0017] The invention furthermore provides for the PEP to report to registered PDPs, specific Events that are of third party interest. The PDP initiates a registration procedure to the PEP. This PDP may be a third party PDP but is not restricted to third party PDPs only. In this procedure the PDP specifies the Events that the PDP is interested in. The PEP registers a reference (hereinafter called Reference) related to the PEP service that can be used by a PDP to contact the PEP. In a later stage when PDP wishes to receive notifications of Events at the PEP, the PDP sends a Reference to the PEP in a request for notification. The PEP sends its notifications to these References.

[0018] If such an Event occurs at the PEP, it notifies the PDPs that subscribed to that Event on the registered Reference, after which the PEP awaits the decision of the PDP.

[0019] Multiple PDPs may subscribe to the same Event. If multiple PDPs have subscribed to an Event, then the PEP notifies the PDPs one at the time, according to a certain priority scheme. If multiple suggested Decisions of multiple PDPs are received by the PEP, the PEP may carry out a policy enforcement or multiple consecutive Actions according to a certain priority scheme.

[0020] New aspects of this Invention are:

• The concept of the PEP acting as a server, providing a PEP service.
• The concept of a PDP acting as a client of the PEP.
• The message to a Register, which may originate directly from a PEP, to register the Event notification capabilities and the enforcement capabilities of the PEP Service.
• A message from a PDP to a PEP to request to be notified when certain Events happen.
• The message from PEP to PDP that reports to the PDP that an Event has occurred or a set of Events has occurred, containing a Reference to all the relevant Event data.
• The message from PDP to PEP that indicates which Event related data must be retrieved from the PEP.
• The message from PDP to PEP that indicates the Action to be taken by the PDP and to be enforced by the PEP.

[0021] The Invention may preferably be applied in the area of Web Services, Open Services Access (OSA), Single Sign On for multiple vendors, or any other application with distributed functionality, as these standards and standardization bodies include in their scope the service consumer and the service provider.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In the following section, the Invention will be described by way of examples of its embodiments with reference to the attached drawing, in which:

FIG. 1 shows the prior art solution with a basic overview of Stakeholders and their representation via their own PDPs.

FIG. 2 shows a sequence diagram of the preferred embodiment of the invention.

FIG. 3 shows a first method of registration of a policy to synchronous messaging.

FIG. 4 shows a second method of registration of a policy to asynchronously carrying out of a policy enforcement.

FIG. 5 shows an embodiment wherein the service domains are involved in the Open Mobile Alliance (OMA).

FIG. 6 shows an overview of the preferred embodiment of the system with the means that are part of the invention.

DETAILED DECRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

[0023] The innovative teachings of the present Invention will be described with particular reference to the presently preferred exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many uses of the innovative teachings herein. In general, statements made in the specification of the present Invention do not necessarily delimit any of the claimed Invention.

[0024] With reference to FIG. 1 of the drawings, a general overview, according to the current art, is showing the relationship between PEP, PDP and Stakeholders, wherein the Stakeholders are represented via their own PDPs. The current approach by systems, policy models, framework and standards, which considers the PEP a client and the PDP a server has disadvantages such as a lack of possibility for Stakeholders to subscribe to PEP capabilities outside their service domain. Furthermore there is no easy way for defining policies to be enforced by PEPs without having to first register the capabilities of the PEP.

[0025] FIG. 2 shows one embodiment of the invention, which represents the invented method for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication network comprising messaging between network elements, comprising at least one PEP, one or more PDPs, which network elements provide for registering events, sending notifications of the occurrence of events and enforcing a policy upon said events if certain conditions are met, wherein the at least one PEP serves as a server towards at least one PDP, being a client. The figure shows next steps:

201: register Events that PDPs 607, being clients, can subscribe to and register Policy enforcements that PDPs 607 can suggest to the PEP 604, being a server;

202: PDPs 607 obtain the capabilities of Event notification and policy enforcement to be carried out by PEP 604;

203: establish service agreement;

204: request notification of specified Events and request possibility to return policy enforcements;

205: an Event occurs;

206: notify that an Event has occurred;

207: evaluate Event and determine policy enforcement;

208: suggest policy enforcement;

209: enforce policy

[0026] These steps are explained in more detail in the following. The PEP 604 announces 201 its capabilities for Event Notification Capabilities at the Register 601 and its policy enforcements at the Register 601. The Events and policy enforcements are typical to an instance of a PEP 604. The Events represent actual Events that may occur at the PEP 604, and the policy enforcements represent actual policy enforcements that may be carried out by the PEP 604. The PDP 607 may access the Register 601 by means of the PEP Reference to investigate the PEP 604's Events, that may be notified 202 to the PDP 607 and policy enforcements that the PDP 607 may suggest. The PDP 607 and the PEP 604 establish 203 a service agreement, part of this is determining which (subset of) the registered PEP service Events and policy enforcements may be requested by the PDP 607. The PDP 607 may request to be notified of specified Events. The PDP 607 subscribes 204 to specific PEP 604 Events. Whenever such an Event occurs 205 at the PEP 604 it notifies 206 the PDPs 607 that have subscribed to this Event. Typically the PEP 604 would notify the PDPs 607 one by one. The PDPs 607 evaluate and decide 207 for the appropriate policy enforcement upon reception of the Event notification and return 208 their suggestion for the policy enforcements to be taken back to the PEP 604. Subsequently, the PEP 604 determines 209 which of these policy enforcements to carry out and carries them out.

[0027] In case of multiple PDPs having registered to the same event, a preference- or priority scheme is applied by the PEP for sending the notifications to one or more of said multiple PDPs.

[0028] In case of a PEP receiving from multiple PDPs, multiple suggestions to enforce a policy, a preference- or priority scheme is applied by said PEP for selecting such a suggestion to enforce a policy upon.

[0029] FIGS. 3 and 4 describe preferred embodiments for the method of providing the PDP with specific Events related data.

[0030] FIG. 3 shows a first method, in the format of Unified Modeling Language, of a communication between a PEP 604, being a server, a PDP 607, being a client and a Register 601, in which next steps are shown:

301 : register (PEP events, PEP PolicyEnforcements);

302a: find();

302b: reference to PEP service();

303a: establishServiceAgreement();

303b: establishServiceAgreement();

304 : requestEventNotification(events);

305 : EventOccurrance();

306 : EventNotification(eventRelatedData);

307: EvaluateEvent(eventRelatedData);

308 : result (PolicyEnforcement);

309 : CarryOutPolicyEnforcement(PolicyEnforcement).

[0031] The method is carried out by means of serialization of all the Event related data and shows an Event occurrence 305 at the PEP 604, as an Event that may be subscribed to by the PDP 607. The data describing the Event is gathered and sent in a message (event notification 306 to the PDP 607. In this option a message comprises:

• The message from PEP 604 to PDP 607 reporting to the PDP 607 that an Event has occurred or a set of Events has occurred, where this message 306 contains all of the relevant Event data.
• Its return message 308 to the PEP 604 that contains the policy enforcement to be enforced.

In the service agreement establishment 303 it is agreed which Events the specific PDP 607 may be notified of and which policy enforcements may be proposed by the PDP 607 to the PEP 604.

[0032] The Events of which a notification is requested at 304 may be a subset of the Events agreed upon in 303. The notification request 304 may also contain a callback Reference to the PDP 607. The callback Reference of the PDP 607 may also be exchanged when establishing the service agreement 303.

[0033] The notification of the Event in this embodiment is done by submitting to the PDP 607 all Event related data in the notification message 306. The PDP 607 evaluates at 307 this data and determines a policy enforcement that must be carried out by the PEP 604. The notification result message 308 carries the policy enforcement.

[0034] FIG. 4 shows a second embodiment of the method, in the format of Unified Modeling Language, of a communication between a PEP 604, being a server, a PDP 607, being a client and a Register 601, in which next steps are shown:

401 : register(PEP events, PEP PolicyEnforcements);

402a: find();

402b: reference to PEP service();

403a: establishServiceAgreement();

403b: establishServiceAgreement();

404 : requestEventNotification(events);

405 : EventOccurrance();

406 : EventNotification(reference to eventRelatedData);

407a: getEventData(reference to eventRelatedData);

407b: EvaluateEvent (eventRelatedData) ;

407c: setPolicyEnforcementData(reference to eventRelatedData);

409 : CarryOutPolicyEnforcement (PolicyEnforcement).

[0035] This method is carried out by means of asynchronous messaging, wherein the PDP 607 gets the Event related data upon request.
Typical for this embodiment is that the notification of the Event in this method is done by putting a Reference 406 to the Event related data in the notification message. The PDP 607 obtains 407a through this Reference the Event data that it is going to evaluate. The PDP 607 evaluates 407b this data and determines a policy enforcement that must be carried out by the PEP 604. A separate asynchronous message 407c is sent by the PDP 607 to let the PEP 604 know, which suggested policy enforcement should be enforced by the PEP 604.

[0036] The Events and policy enforcements that the PEP 604 registers at the Register 601 may be considered capabilities of a PEP service. The service may therefore be implemented as a web service. The Register 601 may be implemented as a Discovery web service.

[0037] FIG. 5 shows the service domains that are involved, as to show that the Invention may be applied in possibly any other field that involves multiple Stakeholders that are interested in or would like to influence an atomic Event and who are willing to determine a policy enforcement upon that Event. The lines that connect the various elements show possible service agreements (Relations). In the showed example next parties are involved:

[0038] A host network operator 501 hosting a service provider (SP) 502. An SP 502 providing services to a mobile virtual network enabler (MVNE) 503 and having a Relation with an application service provider (ASP) 504. A Content Provider 506 providing content data to a MVNE 503, which passes the content data to a mobile virtual network operator (MVNO) 507. An ASP 504 providing application services to an MVNE 503 and an SP 502. And finally, a MVNO 507 having a Relation with an End-User 508.

[0039] An example of a field involving multiple Stakeholders is defined in the upcoming OMA. OMA is a standards body that provides specifications to make the mobile Internet work by means of a standardized architecture and open APIs that enable interoperability. OMA addresses the generation of a layered service model with multiple service domains involved.

[0040] In this case a PEP would typically be located in an Enabler in the Service Provider (SP) domain. The other service domains are interested in the Events occurring in the Mobile Virtual Network Enabler (MVNE), such as a specific method being called with a specific set of parameters on the MVNE.

[0041] Each of these service domains could have in place its own PDP to be able to influence the decision to be carried out at the PEP/MVNE. E.g. the Mobile Virtual Network Operator (MVNO) domain PDP represents the end-user when end-user specific settings must be evaluated, when a service is requested from the SP domain, which has the PEP.

[0042] Other examples of implementation of the Invention relate to e.g. governmental domains with PDPs that are involved in for example lawful interception legislations.

[0043] The present Invention provides several (additional) advantages with regard to existing solutions such as the:

• The invention provides possibilities to dynamically associate additional functionality, which may also comprise other functionalities than PDP, as long as these functionalities interface in a similar way as a PDP.
• Interoperability: One PEP Server is able to link-up with multiple PDP clients without obstructions caused by differences in manufacturer's software and hardware.
• Multiple Stakeholders have their say and may suggest policy enforcements to be enforced by the PEP.

[0044] Fig. 6 Shows an embodiment of a system for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication network comprising messaging between network elements, comprising at least one PEP 604, one or more PDPs 607, which network elements provide for registering events, sending notifications of the occurrence of events and enforcing a policy upon said events if certain conditions are met, wherein the at least one PEP 604 is arranged as a server towards at least one PDP 607, being a client.

[0045] The system furthermore comprises next means:

• access means 602 for making the policies of a PEP 604 available to the one or more PDPs 607;
• subscribing means 603 for the one or more PDPs 607 to subscribe to one or more PEP 604 policy enforcement capabilities outside the domain of a PDP 607;
• prioritizing means 605 for applying a preference- or priority scheme by the PEP 604 for sending the notifications to one or more of the multiple PDPs 607, in case of multiple PDPs 607 having registered to the same event;
• selecting means 606 for applying a preference- or priority scheme by the PEP 604 for selecting a suggestion to enforce a policy upon, in case of a PEP 604 receiving multiple suggestions to enforce a policy from multiple PDPs 607;
• Messaging means which comprise either:
  • synchronous messaging means 608a and 609a to enable, after the occurrence of the event, synchronous messaging, wherein event data are sent together with the notifications from the PEP 604 to the PDP 607; or
  • asynchronous messaging means 608b and 609b to enable, after occurrence of the event, asynchronous messaging, wherein event data are sent from the PEP 604 to the PDP 607 after a request by the PDP for sending said event data;
  • a register 601 arranged for:
    • a PEP 604 to register events that a PDP 607 can subscribe to;
    • the PEP 604 to register policy enforcements that the PDP 607 may suggest to the PEP 604;
    • the PDP 607 to obtain the registered events;
    • the PDP 607 to obtain the registered policy enforcements.
  
  PDPs 607 may comprise stakeholders such as operators, application developers, vendors, governmental organizations, end-users or service providers.

Claims

1. A method for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication network comprising messaging between network elements, comprising at least one policy enforcement point (PEP) (604), one or more policy decision points (PCPs) (607), which network elements provide for registering events, sending notifications of the occurrence of events and enforcing a policy upon said events if certain conditions are met,
characterized in that said at least one PEP (604) serves as a server towards at least one PDP (607), being a client.

2. A method for policy-based control of a communication network according to claim 1, wherein the policies of a PEP (604) are available to the one or more PDPs (607).

3. A method for policy-based control of a communication network according to any one of the claims 1-2, wherein the one or more PDPs (607) subscribe to one or more PEP (604) policy enforcement capabilities outside the service domain of a PDP (607) .

4. A method for policy-based control of a communication network according to any one of the preceding claims, where, in case of multiple PDPs (607) having registered to the same event, a preference- or priority scheme is applied by the PEP (604) for sending the notifications to one or more of said multiple PDPs (607).

5. A method for policy-based control of a communication network according to any one of the preceding claims, where, in case of a PEP (604) receiving from multiple PDPs (607), multiple suggestions to enforce a policy, a preference- or priority scheme is applied by said PEP (604) for selecting such a suggestion to enforce a policy upon.

6. A method for policy-based control of a communication network according to any one of the preceding claims, wherein, after the occurrence of the event, said messaging is synchronous, wherein event data are sent together with the notifications from the PEP (604) to the PDP (607).

7. A method for policy-based control of a communication network according to any one of the claims 1-5, wherein, after occurrence of the event, said messaging is asynchronous, wherein event data are sent from the PEP (604) to the POP (607) after a request by the PDP (607) for sending said event data.

8. A method for policy-based control of a communication network according to any one of the preceding claims, wherein the method comprises the steps of:

- a PEP (604) registering events that a PDPs (607) can subscribe to;

- the PEP (604) registering policy enforcements that the PDP may suggest to the PEP (604);

- the PDP (607) obtaining said registered events;

- the PDP (607) obtaining said registered policy enforcements;

9. A method for policy-based control of a communication network according claim 8, wherein the method further comprises the steps of:

- The PDP (607) requesting a PEP (604) to be notified of a specified event;

- The PDP (607) requesting a PEP (604) for a possibility to enforce a policy;

- The PEP (604) notifying a PDP (607) that the specified event has occurred;

- The PDP (607) suggesting to said PEP (604) a policy enforcement appropriate for said specified event; and

- The PEP (604) enforcing said policy enforcement.

10. A system for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication network comprising messaging between network elements, comprising at least one policy enforcement point (PEP) (604), one or more policy decision points (PDPs) (607), which network elements provide for registering events, sending notifications of the occurrence of events and enforcing a policy upon said events if certain conditions are met,
characterized in that said at least one PEP (604) is arranged as a server towards at least one PDP (607), being a client.

11. A system for policy-based control of a communication network according to claim 10, having access means (602) for making the policies of a PEP (604) available to the one or more PDPs (607).

12. A system for policy-based control of a communication network according to any one of the claims 10-11, having subscribing means (603) for the one or more PDPs (607) to subscribe to one or more PEP policy enforcement capabilities outside their own service domain.

13. A system for policy-based control of a communication network according to any one of the claims 10-12, where, in case of multiple PDPs (607) having registered to the same event, prioritizing means (605) are provided for applying a preference- or priority scheme by the PEP (604) for sending the notifications to one or more of said multiple PDPs (607).

14. A system for policy-based control of a communication network according to any one of the claims 10-13, where, in case of a PEP (604) receiving multiple suggestions from multiple PDPs (607), selecting means (606) are provided for applying a preference- or priority scheme by said PEP (604) for selecting a suggestion to enforce a policy upon.

15. A system for policy-based control of a communication network according to any one of the claims 10-14, wherein synchronous messaging means (608b, 609a) are provided to enable, after the occurrence of the event, synchronous messaging, wherein event data are sent together with the notifications from the PEP (604) to the PDP (607).

16. A system for policy-based control of a communication network according to any one of the claims 10-14, wherein asynchronous messaging means (608a, 609b) are provided to enable, after occurrence of the event, asynchronous messaging, wherein event data are sent from the PEP (604) to the PDP (607) after a request by the PDP (607) for sending said event data.

17. A system for policy-based control of a communication network according to any one of the claims 10-16, having a register (601) arranged for:

- a PEP (604) to register events that a PDP (607) can subscribe to;

- the PEP (604) to register policy enforcements that the PDP (607) may suggest to the PEP (604);

- the PDP (607) to obtain said registered events;

- the PDP (607) to obtain said registered policy enforcements.

18. A system for policy-based control of a communication network according to any one of the claims 10-17, wherein PDPs (607) comprise stakeholders such as operators (501, 507), application developers, vendors, governmental organizations, end-users (508) or service providers (502).

Ansprüche

1. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes mit einer verteilten Architektur, mit mindestens einem heterogenen Kommunikationsnetz mit Nachrichtenübermittlung zwischen Netzelementen, mit mindestens einem Policy-Zwangsdurchführungspunkt (PEP - policy enforcement point) (604), einem oder mehreren Policy-Entscheidungspunkten (PDP - policy decision points) (607), wobei die Netzelemente die Registrierung von Ereignissen, das Senden von Benachrichtigungen des Auftretens von Ereignissen und die Zwangsdurchführung einer Policy bei diesen Ereignissen, wenn gewisse Bedingungen erfüllt werden, ermöglichen, dadurch gekennzeichnet, daß mindestens ein PEP (604) als ein Server für mindestens einen PDP (607) als Client dient.

2. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach Anspruch 1, wobei die Policies eines PEP (604) für den einen oder die mehreren PDP (607) zur Verfügung stehen.

3. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 1-2, wobei der eine oder die mehreren PDP (607) an einer oder mehreren PEP- (604) Policy-Zwangsdurchführungsfähigkeiten außerhalb des Dienstbereichs eines PDP (607) teilnehmen.

4. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der vorhergehenden Ansprüche, wobei im Fall, daß mehrere PDP (607) das gleiche Ereignis registriert haben, ein Bevorzugungs- oder Prioritätsschema durch den PEP (604) zum Senden der Benachrichtigungen an eine oder mehrere der mehreren PDP (607) angewandt wird.

5. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der vorhergehenden Ansprüche, wobei in dem Fall, daß ein PEP (604) von mehreren PDP (607) mehrere Vorschläge zur Zwangsdurchführung einer Policy empfängt, ein Bevorzugungs- oder Prioritätsschema durch diesen PEP (604) zum Auswählen eines solchen Vorschlags zur Zwangsdurchführung einer Policy darauf angewandt wird.

6. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der vorhergehenden Ansprüche, wobei nach Auftreten des Ereignisses die Nachrichtenübermittlung synchron stattfindet, wobei Ereignisdaten zusammen mit der Benachrichtigung vom PEP (604) zum PDP (607) gesendet werden.

7. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 1-5, wobei nach Auftreten des Ereignisses die Nachrichtenübermittlung asynchron stattfindet, wobei Ereignisdaten vom PEP (604) zum PDP (607) nach Anforderung durch den PDP (607) zum Senden dieser Ereignisdaten gesendet werden.

8. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der vorhergehenden Ansprüche, wobei das Verfahren folgende Schritte umfaßt:

- Registrieren durch einen PEP (604) von Ereignissen, an denen ein PDP (607) teilnehmen kann;

- Registrieren durch den PEP (604) von Policy-Zwangsdurchführungen, die der PDP dem PEP (604) vorschlagen kann;

- Erhalten der registrierten Ereignisse durch den PDP (607);

- Erhalten der registrierten Policy-Zwangsdurchführungen durch den PDP (607).

9. Verfahren zur policybasierten Steuerung eines Kommunikationsnetzes nach Anspruch 8, wobei das Verfahren weiterhin folgende Schritte umfaßt:

- Anfordern durch den PDP (607), das ein PEP (604) über ein angegebenes Ereignis benachrichtigt wird;

- Anfordern durch den PDP (607) eines PEP (604) für eine Möglichkeit zur Zwangsdurchführung einer Policy;

- Benachrichtigen eines PDP (607) durch den PEP (604), daß das angegebene Ereignis aufgetreten ist;

- Vorschlagen durch den PDP (607) eine für das angegebene Ereignis geeigneten Policy-Zwangsdurchführung für den PEP (604); und

- Erzwingen der Policy-Zwangsdurchführung durch den PEP (604).

10. System zur policybasierten Steuerung eines Kommunikationsnetzes mit einer verteilten Architektur, mit mindestens einem heterogenen Kommunikationsnetz mit Nachrichtenübermittlung zwischen Netzelementen, mit mindestens einem Policy-Zwangsdurchführungpunkt (PEP - policy enforcement point) (604), einem oder mehreren Policy-Entscheidungspunkten (PDP - policy decicion points) (607), wobei die Netzelemente die Registrierung von Ereignissen, das Senden von Benachrichtigungen des Auftretens von Ereignissen und die Zwangsdurchführung einer Policy bei diesen Ereignissen, wenn gewisse Bedingungen erfüllt werden, ermöglichen, dadurch gekennzeichnet, daß der mindestens eine PEP (604) als ein Server für mindestens einen PDP (607) als Client angeordnet ist.

11. System zur policybasierten Steuerung eines Kommunikationsnetzes nach Anspruch 10, mit Zugriffsmitteln (602) zum Verfügbarmachen der Policies eines PEP (604) für den einen oder die mehreren PDP (607).

12. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-11, mit Teilnahmemitteln (603) für den einen oder die mehreren PDP (604) zum Teilnehmen an einer oder mehreren PEP-Policy-Zwangsdurchführungsfähigkeiten außerhalb ihres eigenen Dienstbereichs.

13. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-12, wo im Fall, daß mehrere PDP (607) am gleichen Ereignis registriert worden sind, Priorisierungsmittel (605) zum Anwenden eines Bevorzugungs- oder Prioritätsschemas durch den PEP (604) zum Senden der Benachrichtigungen zu einem oder mehreren der mehrfachen PDP (607) bereitgestellt sind.

14. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-13, wobei im Fall, daß ein PEP (604) mehrere Vorschläge von mehreren PDP (607) empfängt, Auswählmittel (606) zum Anwenden eines Bevorzugungs- oder Prioritätsschemas durch den PEP (604) zum Auswählen eines Vorschlags zur Zwangsdurchführung einer Policy daran bereitgestellt sind.

15. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-14, wobei synchrone Nachrichtenübermittlungsmittel (608b, 609a) zum Ermöglichen von synchroner Nachrichtenübermittlung nach Auftreten des Ereignisses bereitgestellt sind, wobei Ereignisdaten zusammen mit den Benachrichtigungen vom PEP (604) zum PDP (607) gesendet werden.

16. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-14, wobei asynchrone Nachrichtenübermittlung (608a, 609b) zum Ermöglichen von asynchroner Nachrichtenübermittlung nach Auftreten des Ereignisses bereitgestellt sind, wobei Ereignisdaten vom PEP (604) zum PDP (607) nach einer Anforderung durch den PDP (607) zum Senden dieser Ereignisdaten gesendet werden.

17. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-16 mit, einem Register (601), das für folgendes angeordnet ist:

- einen PEP (604) zum Registrieren von Ereignissen, an denen ein PDP (607) teilnehmen kann;

- zum Registrieren durch den PEP (604) von Policy-Zwangsdurchführungen, die der PDP (607) dem PEP (604) vorschlagen könnte;

- Erhalten der registrierten Ereignisse durch den PDP (607);

- Erhalten der registrierten Policy-Zwangsdurchführungen durch den PDP (607).

18. System zur policybasierten Steuerung eines Kommunikationsnetzes nach einem der Ansprüche 10-17, wobei PDP (607) Interessenvertreter wie beispielsweise Betreiber (501, 507), Anwendungsentwickler, Lieferanten, Regierungsorganisationen, Endbenutzer (508) oder Diensteanbieter (502) umfassen.

Revendications

1. Procédé de commande à base de règles d'un réseau de communication ayant une architecture distribuée, comportant au moins un réseau de communication hétérogène comprenant un transfert de messages entre des éléments de réseau, comprenant au moins un client de serveur de règles (PEP) (604), un ou plusieurs serveurs de règles (PDP) (607), lesquels éléments de réseau assurent l'enregistrement d'événements, l'envoi de notifications de l'occurrence d'événements et l'application d'une règle lors desdits événements si certaines conditions sont satisfaites,
caractérisé en ce que ledit au moins un PEP (604) sert de serveur pour au moins un PDP (607), étant un client.

2. Procédé de commande à base de règles d'un réseau de communication selon la revendication 1, dans lequel les règles d'un PEP (604) sont à la disposition d'un ou de plusieurs PDP (607).

3. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 1 à 2, dans lequel les un ou plusieurs PDP (607) souscrivent à une ou plusieurs capabilités d'application de règles de PEP (604) en dehors du domaine de service d'un PDP (607).

4. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications précédentes, dans lequel dans le cas de l'enregistrement de PDP multiples (607) pour le même événement, un mécanisme de préférence ou de priorité est appliqué par le PEP (604) pour l'envoi des notifications à un ou plusieurs desdits PDP multiples (607).

5. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications précédentes, dans lequel, en cas de réception par un PEP (604) depuis de multiples PDP (607), de multiples suggestions d'application d'une règle, un mécanisme de préférence ou de priorité est appliqué par ledit PEP (604) pour la sélection d'une telle suggestion d'application d'une règle.

6. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications précédentes, dans lequel, après l'occurrence de l'événement, ledit transfert de messages est synchrone, dans lequel des données d'événement sont envoyées avec les notifications depuis le PEP (604) au PDP (607).

7. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 1 à 5, dans lequel, après l'occurrence de l'événement, ledit transfert de messages est asynchrone, dans lequel des données d'événement sont envoyées par le PEP (604) au PDP (607) après une demande par le PDP (607) d'envoi desdites données d'événement.

8. Procédé de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications précédentes, dans lequel le réseau comprend les étapes consistant en :

- l'enregistrement par un PEP (604) d'événements auxquels un PDP (607) peut souscrire ;

- l'enregistrement par le PEP (604) d'applications de règles que le PDP peut suggérer au PEP (604) ;

- l'obtention par le PDP (607) desdits événements enregistrés ;

- l'obtention par le PDP (607) desdites applications de règles enregistrées.

9. Procédé de commande à base de règles d'un réseau de communication selon la revendication 8, dans lequel le procédé comprend en outre les étapes consistant en :

- la demande par le PDP (607) à être notifié d'un événement spécifié par un PEP (604) ;

- la demande par le PDP (607) à un PEP (604) d'avoir la possibilité d'appliquer d'une règle ;

- la notification par le PEP (604) à un PDP (607) que l'événement spécifié s'est produit

- la suggestion par le PDP (607) audit PEP (604) qu'une règle appropriée soit appliquée pour ledit événement spécifié ; et

- la mise en application par le PEP(604) de ladite règle.

10. Système de commande à base de règles d'un réseau de communication ayant une architecture distribuée, comportant au moins un réseau de communication hétérogène comprenant un transfert de messages entre des éléments de réseau, comprenant au moins un client de serveur de règles (PEP) (604), un ou plusieurs serveurs de règles (PDP) (607), lesquels éléments de réseau assurent l'enregistrement d'événements, l'envoi de notifications d'occurrences d'événements et l'application d'une règle lors desdits événements si certaines conditions sont satisfaites,
caractérisé en ce que ledit au moins un PEP (604) est agencé en tant que serveur pour au moins un PDP (607), étant un client.

11. Système de commande à base de règles d'un réseau de communication selon la revendication 10, ayant des moyens d'accès (602) pour mettre les règles d'un PEP (604) à la disposition des un ou plusieurs PDP (607).

12. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 11, ayant des moyens de souscription (603) pour que les un ou plusieurs PDP (607) souscrivent à une ou plusieurs capabilités d'application de règles en dehors de leur propre domaine de service.

13. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 12, dans lequel, dans le cas d'un enregistrement de multiples PDP (607) pour le même événement, des moyens d'affectation de priorité (605) sont fournis pour que le PEP (604) applique un mécanisme de préférence ou de priorité pour l'envoi des notifications à un ou plusieurs desdits multiples PDP (607).

14. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 13, dans lequel, en cas de réception par un PEP (604) de multiples suggestions depuis de multiples PDP (607), des moyens de sélection (606) sont fournis pour que le PEP (604) applique un mécanisme de préférence ou de priorité pour la sélection d'une suggestion d'application d'une règle.

15. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 14, dans lequel, dans lequel des moyens de transfert de messages synchrone (608b, 609a) sont fournis pour permettre, après l'occurrence de l'événement, un transfert de messages synchrone, dans lequel des données d'événement sont envoyées avec les notifications par le PEP (604) au PDP (607).

16. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 14, dans lequel des moyens de transfert de messages asynchrone (608a, 609b) sont fournis pour permettre, après l'occurrence de l'événement, un transfert de messages asynchrone, dans lequel des données d'événement sont envoyées par le PEP (604) au PDP (607) après une demande par le PDP (607) d'envoi desdites données d'événement.

17. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 16, ayant un registre (601) agencé pour :

- l'enregistrement par un PEP (604) d'événements auxquels un PDP (607) peut souscrire;

- l'enregistrement par le PEP (604) d'applications de règles que le PDP (607) peut suggérer au PEP (604) ;

- l'obtention par le PDP (607) desdits événements enregistrés ;

- l'obtention par le PDP (607) desdites applications de règles enregistrées.

18. Système de commande à base de règles d'un réseau de communication selon l'une quelconque des revendications 10 à 17, dans lequel les PDP (607) comprennent des participants tels que des opérateurs (501, 507), des développeurs d'applications, des vendeurs, des organisations gouvernementales, des utilisateurs finals (508) ou des fournisseurs de services (502).

Drawing