The present invention relates to management of communications networks, in general, and in particular to management of communications networks using adaptive policy.
In operating systems, a policy is essentially an artefact of control for mechanisms provided by the operating system. An interesting example for the use of policies in this context is disclosed in a publication by Jomier (1981) in which static and dynamic policies for memory allocation in a paged system have been introduced. Both policies are based on networks of queues, but the consequences of applying them differ significantly. Thus, the application of a policy changes the behaviour of the governed, underlying system.
Policies appeared in communication networks in the late 1970s, mostly for the management of quality of service. Two examples are Rouse & Rouse (1979) and Kamoun (1981). Rouse & Rouse applied policies to interconnected library networks. Here, a policy is a “set of rules that specifies the ways in which members of the network communicate in terms of sharing resources”. The paper then describes a policy analysis model for sharing resources comprising the probability of a request in gaining access to a resource, average request waiting time and average request cost. Kamoun focuses on the application of policies for network flow control, i.e. to detect and later prevent network congestion. Aspects such as end-to-end control, resource reservations strategies and dropping techniques have been already state of the art in Kamoun's work and policies being used in this area for quite some time. The examples described in the paper are basically IF/THEN constructs, where the IF condition can be a relatively complex statement resulting in a Boolean value and the THEN action defines what should happen next:
IF M=B—Drop the arrived packet
IF M<L—Accept the arrived packet
IF M=B or ni=zi—Drop the arrived packet
IF ni<Ii—Accept the arrived packet
Policy systems, frameworks and models differ in the terminology they use. However, IETF RFC 3198 provides a terminology that is still widely used as a reference when comparing different policy approaches. In this document, the following important definitions are made:
In general terms, a policy is typically described as a principle or rule that guides decisions and helps to achieve rational outcome. Policies are specified, instantiated and enforced. This process of using policies can be described as follows:
Consider a large stadium scenario in which the environment (or context) of management changes. A policy manages resources around the large stadium. Most of the time, there is a normal traffic mix from people in the vicinity of the stadium. Normally, football matches are held at the stadium weekly. However, occasionally, the international team hold public training sessions at the stadium and concerts are held at the stadium once or twice each summer, causing the traffic characteristics in and around the stadium to change. More people use the network resources in the vicinity of the stadium to carry all sorts of services (such as voice call, SMS messaging, video to follow the event, live streaming to stream the event home). With static policies it is difficult and complex to define event and condition specifications to distinguish between these three different possible situations.
There may be another scenario where a policy goal is defined to maintain an equilibrium for a given traffic mix across a Radio Access Network (RAN), an evolved Packet Core (EPC) and transport network. This policy adjusts RAN nodes, packet and service gateways and routing parameters to maintain an optimum usage of resources for a mixed set of services such as voice, video streaming and HTTP traffic. In a situation of an emergency, the goal of the policy is changed to prioritize voice calls from certain users towards the emergency centre (and among certain selected users) as well as SMS services for the same user group. Here, the policy will reconfigure RAN nodes (to only allow access to selected users), packet and service gateway (to ignore any traffic but voice and SMS) and routing in the core network, accordingly. Using traditional policy implementation methods, one must deactivate the old (equilibrium) policies and activate a new set of policies for the emergency situation.
Other documents describing using policies in network management are identified in the References section at the end of this document. However, devices and operations as in the solution to be described in this document are neither disclosed nor suggested in these documents.
The known solutions have some serious drawbacks. They can carry out only static evaluation because the policy logic is fixed at design time and cannot be altered or selected at run time. These existing solutions require extensive authoring because all logic must fit into this single approach to problem solving. A the same time the events to match, the conditions to evaluate, and the action to perform, must all be defined at the same time (i.e. authoring stage), which makes the authoring even more complex, time consuming and error-prone.
Accordingly, the invention seeks to preferably mitigate, alleviate or eliminate one or more of the disadvantages mentioned above singly or in any combination.
According to a first aspect of the present invention there is provided a method of network management using an adaptive policy in which the adaptive policy is defined by a plurality of sets of tasks. The method comprises receiving a trigger event and obtaining information representative of at least one context in which the network operates. The method also comprises performing a first task from a first set of tasks, wherein the first task is selected based on the trigger event and information representative of at least one of the contexts in which the network operates and then performing a subsequent task from a subsequent set of tasks. The subsequent task is selected based on an output produced by performing a preceding task and information representative of at least one of the contexts in which the network operates. The act of performing a subsequent task is repeated until a task from a final set of tasks is selected and performed. The method further comprises producing an action event by performing the task selected from the final set of tasks and forwarding for execution the action event.
According to a second aspect of the present invention there is provided a network management system node. The network management system node comprises a processor and a memory. Said memory contains instructions executable by said processor, whereby said network management system node is operative to use an adaptive policy, wherein the adaptive policy is defined by a plurality of sets of tasks. Said network management system node is further operative to receive a trigger event and to obtain information representative of at least one context in which the network operates. The network management system node is also operative to perform a first task from a first set of tasks, wherein the first task is selected based on the trigger event and information representative of at least one of the contexts in which the network operates and then to perform a subsequent task from a subsequent set of tasks. The subsequent task is selected based on an output produced by performing a preceding task and information representative of at least one of the contexts in which the network operates. The network management system node is operative to repeat the act of performing a subsequent task until a task from a final set of tasks is selected and performed and to produce an action event by performing the task selected from the final set of tasks and to forward for execution the action event.
According to a third aspect of the present invention there is provided a network management system node. The network management system node is operative to use an adaptive policy, wherein the adaptive policy is defined by a plurality of sets of tasks. Said network management system node comprises a receiver for receiving a trigger event and an interface for obtaining information representative of at least one context in which the network operates. The network management system node also comprises a task execution unit for performing a first task from a first set of tasks, wherein the first task is selected based on the trigger event and information representative of at least one of the contexts in which the network operates and for performing a subsequent task from a subsequent set of tasks. The subsequent task is selected based on an output produced by performing a preceding task and information representative of at least one of the contexts in which the network operates. The act of performing a subsequent task is repeated until a task from a final set of tasks is selected and performed. The task execution unit further being for producing an action event by performing the task selected from the final set of tasks. The network management system node further comprises a transmitter for forwarding the action event for execution.
According to a fourth aspect of the present invention there is provided a communications network comprising a network management system node as defined above.
Further features of the present invention are as claimed in the dependent claims.
The present invention provides the benefit of dynamically adapting to changes in goals, its environment, and in incoming event context. Policy logic (tasks) and policies can be incrementally developed using agile approaches, as policies can be evolved from simple implementations to more complex implementations as their deployments mature.
This means that policies can be created as an aggregation of existing tasks, or specialisations of existing tasks, so existing logical elements can be reused and specialised. Policy design in this method is highly suited to tooling using an approach such as, for example, XML-based toolsets and modelling environments such as those, for example, in Eclipse because policies are specified using a Domain Specific Language and the context on which tasks and policies operate is modelled using metadata. Additionally the solution in its embodiments is highly scalable; multiple instances of the same policy can run and can share the load of incoming events of a particular class.
The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:
In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary details.
Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.
This document presents adaptive policies describing how they can be used in management of a communications network. As illustrated in
With reference to
In a preferred embodiment the incoming event also carries associated incoming context information which comprises information indicative of the reason for the trigger event. The reason that triggered the event may be a number of attached users, traffic volume increase, increase of dropped calls, decrease of quality of service, bit error rate increase, or another factor that may have influence on the operation of the communications network.
The method further comprises performing a first task, 106, from a first set of tasks, wherein the first task is selected based on the trigger event and information representative of at least one of the contexts in which the network operates. Then the method comprises performing a subsequent task, 202—branch NO, from a subsequent set of tasks. The subsequent task is selected based on an output produced by performing a preceding task and information representative of at least one of the contexts in which the network operates. The act of performing a subsequent task is repeated until a task from a final set of tasks is selected and performed. This is illustrated in step 202—branch YES. In other words, once the method performs the first task the method enters a loop of performing subsequent tasks and stays in this loop until a task from the final set of tasks is selected and performed.
The method comprises producing 108 an action event. The action event is produced by a task selected from the final set of tasks. The action event is forwarded for execution. The embodiment illustrated in
The embodiment illustrated in
In another embodiment, as illustrated in
Although in
The embodiments illustrated in
In a preferred embodiment an adaptive policy has four active states of execution, which is a variation of a well-known OODA loop (Observe, Orient, Decide, and Act) and is used to achieve separation of the orthogonal aspects of policy execution. In this preferred embodiment a MEDA loop (see
In a preferred embodiment the context in which the network operates may be divided into several more specific contexts. In consequence the information representative of a context in which the network operates may comprise information representative of a global context, a policy context or an incoming context. As mentioned above the information representative of the incoming context comprises information indicative of the reason for the trigger event. The information representative of the global context comprises information describing the environment in which at least part of the network operates. This information may include information about network topology, information on the state of metrics on network entities such as cells, base stations, and switches, information about power outages and even non-network information like for example weather conditions (as they may influence propagation of radio signals) or information about mass events (sport, concerts, etc). The information representative of the policy context in one embodiment comprises information describing how the trigger event should be handled depending on at least one of the global context and the incoming context. Policy context is information that is specific to a particular type of policy but is not specific to a single running instance of that policy. A good example might be a protocol analyser used by a policy for checking the type of traffic users are transmitting. There could be a limit on the number of sessions the protocol analyser could handle. Policy context would be used to keep track of how many sessions are being analysed by the protocol analyser, it can be used to control access to the protocol analyser and to decide how to deal with the situation where the protocol analyser runs out of capacity (block analysis of further sessions, stop analysing the oldest session etc).
The MEDA loop differs from an OODA loop in a number of important ways. In contrast to an OODA loop, which uses direct feedback from Decide and Act back to Observe, the MEDA loop, on the other hand, uses global and policy context for feedback. Whilst an OODA loop uses business logic in its Observe state, the MEDA loop triggers based on its incoming context. The OODA Orient state orients itself using five aspects namely Cultural Traditions, Analysis & Synthesis, Previous Expectations, New
Information, and Genetic Heritage. The MEDA's Establish state does not use these aspects but instead uses the Global and Policy context of the policy in which it is running. An OODA Decide state puts forward a hypothesis and its Act state tests that hypothesis. The MEDA Decide state makes a decision to change configuration and its Act state determines the best way to realize that decision without testing it. In the MEDA loop, D and A implicitly assume that decisions that can be made are tested at design time and are tested outside the MEDA policy and even outside by other systems. An OODA loop has implicit guidance and control as input for Orient and Act, whereas MEDA uses context as input for all states but does not require any implicit guidance to be set. Instead, guidance is made explicit as context so that the behaviour of policies can be analysed. Finally, unlike an OODA loop that has feedback from all states back to Orient, a MEDA loop goes through all states and then back to the Match state unless an error occurs, in which case it t drops from the current state back to Inactive and then to the Match state, see
The policy logic (or task) executed in each state to handle a particular incoming event is adaptable and is selected from a number of possible policy logic definitions based on the business and domain goals of the policy, its environmental context and, of course, the context of the incoming event, all of which can change at run time.
Embodiments of the method described herein allow for adaptable and dynamic changes to policies at run time. Policies themselves, the goals of the policies, and the logic of existing policies running in an APEX can all be modified. The goal of a policy is the action that should be performed in a certain situation, in other words it is the action event the policy should produce. This can change depending on the situation in which the policy is running. For example, if a cell is not congested, it is OK to allow low priority users to watch high definition video, but in a congested situation, such traffic could be blocked.
The method uses a metadata approach for handling conflict identification and resolution. The context that each policy uses and modifies is modelled, allowing conflicts in a set of policies to be identified and resolved at policy deployment time. Further, interference and conflicts between policies can be monitored and mitigated in an APEX because interactions between policy instances and context can be traced. The advantage of using of metadata is that it allows policy instances to be added, modified and removed while the system is running Unlike classic ECA (Event Condition Action) policies, its metadata approach to context enables conflict detection at a per-state of execution level and per task in the task repository.
In a preferred embodiment policies and their policy logic (also referred to in this document as tasks) are specified using a DSL (Domain Specific Language) using technologies such as XML. This means that policy design and deployment toolsets that support this method are easy to develop.
An adaptive policy is represented by policy logic or in other words as a series of tasks that need to be performed in order to produce a desired output (action event) in response to an input (trigger event). In a simple embodiment a simple policy may be represented by a single task.
The method is easy to scale. In one embodiment the goals and context in which policies are executing may be distributed across APEX instances running on multiple physical or virtual machines using technologies such as Distributed Hash Tables. This allows many distributed policy instances to be deployed to handle a large incoming trigger event load.
In the large stadium scenario described in the Background section if adaptive policies are implemented we can take the context from the trigger (number of attached users, traffic volume increase) and combine that with other contextual information (e.g. public event schedules, football association fixtures, etc.) to provide for a very different set of decisions and resulting actions, according to the established context. The context in which the network operates in the area of the stadium changes in time, e.g. empty stadium on Monday morning and full of spectators on Saturday evening, but again empty on Saturday evening when the team plays an away match. In consequence, the contextual information changes as well.
In the traffic mix equilibrium scenario also described in the Background section if adaptive policies are used one only needs to amend the goal of the policy to change the traffic mix in the network. This goal change can be done inside the policy, since it can evaluate the context (emergency situation), understand it and change the related tasks of its Decide state.
As the scenarios above show, adaptive policies allow network management system to be guided by business or network goals as it governs the network it is managing. This method in its various embodiments allows the network to be managed autonomously, ensuring the system achieves what it should and avoids unacceptable situations. The network is managed in a consistent and cohesive way with a coherent and self-adjustable decision making process that adapts as the goals and environment of the management system change.
With reference to
In a preferred embodiment the network management system node 300 is further operative to produce information representative of an outgoing context associated with the action event by performing the task selected from the final set of tasks and to forward, with the action event, the information representative of the outgoing context. In an alternative embodiment the action event and the outgoing context may be forwarded separately (e.g. as separate messages).
The node 300 also comprises an interface 306 for communication with the network.
The network management system node 300 in its various embodiments is adapted to operate in accordance with the embodiments of the method described in this document.
In this apparatus, adaptive policies, 408 (only one is illustrated) run in one or a number of Adaptive Policy Execution Environments (APEXs), 402. Events, 416, are received from a triggering system, 404, which can be any system that forwards events such as an analytics system, a network element, or a fault management system. The apparatus 500, 300 processes the event and forwards a resulting action event 418 to an actioning system 406 (only one is illustrated). An actioning system is any system that takes an event and performs an action based on this event. The actioning system can be a configuration deployment system, a workflow system, a simple script that issues a set of commands towards a network, or even another Adaptive Policy Execution Environment.
Tasks are designed in a task design component, 512 and the tasks are constrained by metadata describing what context is available to the system. Similarly, a policy authoring component 510 is constrained by the context that is defined as being available in the metadata and by the tasks that were designed in the task design component, 510. In one embodiment policy authoring 510 and task design 512 components are not part of the apparatus 500, 300, but there may be alternative embodiments in which one or both of these components is integrated within the apparatus. The entire system is constrained by metadata, that describes what context is available and what way that context can be manipulated. The metadata is used by the APEX 402 as well as the other components.
In alternative embodiments the Adaptive Policy Apparatus 500, 300, may include a context collector 514, context coordinator 516, policy deployment module 518 and an adaptive policy knowledge base 520. These components in various combinations may be part of the apparatus or be external components with which the apparatus communicates in operation.
As discussed earlier, four types of context are considered in embodiments of this invention. Global context Cg is available and modifiable across all policy instances running in a given system. Examples of global context might be the cell or network topology of the management system. Policy context Cp is available and modifiable only across instances of a particular policy. The current web page download time of sessions in a particular cell might be part of the policy context of a policy managing web browsing Quality of Experience. The incoming context Ci of an event is the information carried into a policy by an event such as its fields and the reason the was triggered. The outgoing context Co is the information carried out of a policy by an actioning event and is the fields of the event together with information such as what policy logic caused this action event to be emitted.
Preferably, the task logic that is executed in each active state is selected dynamically based on the context in which an adaptive policy instance is running so these states and, by extension, the policy itself is adaptable (i.e. adaptive policy). Preferably, each adaptive policy executes four states; Match, Establish, Decide, and Act, each of which is adaptive. Preferably, in each of these states the global context, policy context, and incoming context are examined to determine which policy logic should be executed from a set of policy logic available in each state.
Context, or to be more precise information representative of the context, may be collected from many sources and may be in many forms. The context collector 514 is used to collect information representative of a context of a particular type from a particular source. For example, the context collector 514 might read topology information from an underlying network management system or other network management system using a context collector that implements the API (Application Programming Interface) towards the network management system. Another context collector, 514, may read context information in Resource Description Framework (RDF) format from a weather or news service. When context is collected, it is forwarded to the context coordinator, 516, which determines if the context is a global context or a policy context and forwards it to the appropriate context store in the APEX, 402.
Preferably, business goals, 410, or domain goals, 412, are considered as global and policy contexts and are handled in the system in the same manner as all other context. The policy logic in policies is developed to ensure that the system converges towards the business or domain goals specified in global and policy contexts.
The apparatus 500, 300 may consider many types of context. Business and domain goals may be specified. An adaptive policy may consider information from social networks, internet-connected devices such as security cameras or smart meters, quality of experience indications from end user devices, or information from retail, meteorological, news, or sporting event sources. Information obtained from social networks and the other sources mentioned here above, when taken on its own, represents the global context (i.e. environment in which the network operates). Policies may define specific behaviour of the network that depends on the global context. For example if rainfall intensity is below 2.5 mm/hour transmit power in the cell should be 1×P, if the rainfall intensity is between 2.5 mm/hour and 10 mm/hour then transmit power in the cell should be 1.2×P, etc. These policies define the policy context in which the network operates.
The task design component 512 shown in
In one embodiment of the present invention, context is modelled as shown in
In a preferred embodiment all information representative of context used in the solution disclosed in this document is modelled as metadata 602. This metadata describes the structure, constraints, and relationships that context may have. Metadata may be defined using UML (Universal Modelling Language), semantically using an ontology language such as OWL (Web Ontology Language) or using some other modelling method. Preferably, metadata is made available to all components in the apparatus 500 using a library mechanism. The metadata is defined during task design, 512, and policy authoring, 524. The designer of a task or policy describes the global and policy contexts that a task or policy uses and the task design component and policy authoring component generate the metadata for the global context and policy context and store it in the Adaptive Policy Knowledge Base, 520. When policy authoring component, 510, is used to compose a policy from its states, the metadata for the incoming context of the trigger event, the outgoing context of the action event, and the intermediate incoming and outgoing context is stored by policy authoring, 510, in the Adaptive Policy Knowledge Base, 520.
The following types of metadata are defined:
In a preferred embodiment the apparatus 500 holds a model of its current context as an Adaptive Policy Knowledge Base 520. The Adaptive Policy Knowledge Base 520 is distributed across APEX instances and may be held by means such as a semantic model, as objects in a programming language such as Java or C++, or in a database. The last embodiment is illustrated in
An adaptive policy may be represented as a state machine. One representation of an adaptive policy instance running in an APEX as a state machine is shown in
In one embodiment, an adaptive policy 408 instance runs as a thread in an APEX 402, which runs as a process on a computing device 500, 300. At start-up, the adaptive policy 408 instance enters the Inactive state 702. When it has initialized its policy context, it is ready to be activated, at which point it enters the Match 502 state and waits for an incoming trigger event 416. On reception of an event, it recognizes the incoming event and its context and transforms to the Establish state 504. In the Establish state 504, it determines the situation that generated the incoming event and transforms to the Decide state 506. In that state, the adaptive policy instance resolves the correct course of action to take and enters the Act state 508. In the Act state 508, it determines the best way to realize that course of action and issues an appropriate action event 418. It then transforms back to the Match state 502 and awaits another trigger event.
If the adaptive policy instance 408 is inactivated or if an error occurs in any of the four active states or if the logic of the adaptive policy instance is to be updated, the adaptive policy transforms to the Inactive state 702. From the Inactive state 702, it can be re-initialized and restarted handling events in the Match state 502. Alternatively, the adaptive policy instance can exit, 704.
The diagram in
A policy is adaptive because the manner of execution in each state as shown in
Given an incoming event q and an adaptive policy instance s, the selection function of the task selection logic 806 of an active state of the adaptive policy may be expressed using the equation below:
Task=fselect(Ciq,Cps,Cg)
The selection function uses the incoming context of the incoming event q (i.e. Ciq), the policy context 810 of the adaptive policy instance s (i.e. Cps), 408, and the global context 812 to select the task 808 to execute (i.e. Cg). The task selection logic 806 is specified in a means that allows it to execute on the APEX, which may be a set of rules, a list of parameters such as priority, time or location, a script in a scripting language such as Perl or Python, a programmatic object injected into the active state of the adaptive policy at run time, or may be statically defined.
Once a task has been selected, the logic, 816, of that task is executed. Given a selected task, 808, and its parameters, 814, an incoming event q and an adaptive policy instance s, 408, the function of the task logic, 816, of an active state of the adaptive policy may be expressed using the equation below:
Eventr[Cor]=fTask(ParTask,Ciq,Cps,Cg)
The task logic, 816, uses the incoming context of the incoming event q, the policy context, 810, of the adaptive policy instance s, 408, the global context, 812, and the task parameters, 814, to execute and to generate an event r with outgoing context Cor. In a preferred embodiment task parameters are configuration parameters for a task. For example a task might have to be configured to expect date values in YYYY-MM-DD or DD/MM/YY or MM/DD/YY format or in one installation a task may be configured to issue alarms at 90% load and another installation at 85% load. The mechanism described above is carried out in each one of the four active states 502-508 and an output of one active state is an input of the following active state in the series. The event or events emitted by the Act state, 508, or an adaptive policy is the action event, 418, that is output. The task logic is specified in a means that allows it to execute on the APEX, which may be a set of rules, a script in a scripting language such as Python or Perl, or a programmatic object injected at run time into the implementation of the active state of the adaptive policy.
The flowchart in
When an adaptive policy is in the Match state, 902, it is ready and awaits a trigger event with its associated incoming context 904. When the trigger event and incoming context are received they are forwarded to task selection logic 806 of the Match state 502 for handling. The outcome of the handling is an output event with an output context of the Match state, 906. If the handling of the trigger event failed, 908 (branch “No”), the MEDA loop stops. If the handling of the trigger event was successful, 908 (branch “Yes”), the method proceeds to check if the current active state is the Act state. Since the method only started and the current active state is Match the answer in step 910 is “No” and the method proceeds to increment the active state to the next one in the MEDA loop, 912. The outcome of step 912 in this instance is transition to the Establish state. In the following step the output of the preceding active state is taken as the input for the next active state (i.e. the output event and output context produced in step 906 are now input) 914. Then the method loops back to step 906 and the same steps 906-910 are performed until the answer to the question in step 910 (Is the current active state “Act”?) is “Yes”. Answer “Yes” means that it was the last active state in the MEDA loop and the output of this active state is an action event with an outgoing context which is forwarded to an actioning system, 916. After this operation the method loops back to the Match active state and waits for another trigger event.
The flowchart in
When an adaptive policy is in the Match state, the Match task selector must examine the context of the trigger event and select a task that can deal with the incoming event context. If a trigger event enters the system with context x, an adaptive policy in Match state selects and executes a task that can deal with context x.
Consider an adaptive policy with a trigger event UE_STRANGE_TRAFFIC in its Match state. The adaptive policy has three tasks that may be selected in its Match state: UE_STRANGE_TRAFFIC, UE_STRANGE_TRAFFIC_WITH_PATTERN, or UE_STRANGE_TRAFFIC_WITH_DPI, where DPI stands for Deep Packet Inspection. If the UE_STRANGE_TRAFFIC event enters the APEX with context {ue list} the first task is selected, 1002. If the event enters with the context {ue list+traffic pattern}, the second event is selected, 1002. If the event enters with the context {ue list+L7 dpi}, the adaptive policy selects the third task, 1002, where L7 refers to layer 7 classification of network traffic in Deep Packet Inspection. When a task is selected, be that UE_STRANGE_TRAFFIC, UE_STRANGE_TRAFFIC_WITH_PATTERN, or UE_STRANGE_TRAFFIC_WITH_DPI, the task logic 1226 of that task is executed, 1004. For example, if the task UE_STRANGE_TRAFFIC_WITH_DPI is selected, 1002, the task logic 1226 of task UE_STRANGE_TRAFFIC_WITH_DPI is executed in step 1004, where the task may check, for example, that the inspection information returned is indeed for the UE in question. When execution of the task, 1004, completes, APEX, 402, reads the metadata for the task from the task definition (see
In the Establish state, a situation is defined; the task determines how to process the event forwarded from the Match state together with its lifted context while considering the policy context of the adaptive policy as well as global context. An Establish task may consider the UE_STRANGE_TRAFFIC forwarded event and its context with one of the following Policy or Global context sets: {UE location}, {UE time}, {UE location and time}, {UE location, time, and UE traffic analysis}, 1002, and selects a UE_STRANGE_TRAFFIC_ESTABLISH task. The task logic 1226 of the UE_STRANGE_TRAFFIC_ESTABLISH task is executed in step 1004, with that task, for example, examining the DPI information returned to see if it indicates that malicious traffic is present. When execution of the task, 1004, completes, APEX, 402, reads the metadata for the task from the task definition (see
In the Decide state the adaptive policy must arrive at a decision; determine what possible actions are available and select the best option based on the situation described in the context received in the event forwarded from the Establish state. Possible options might be {move UE to GSM}, {move UE to new MME plus start this MME}, {move UE to LTE} or {move UE to SDN}, where MME stands for Mobility Management Entity, UE for User Equipment and SDN for Software Defined Networking, 1002, and selects a UE_STRANGE_TRAFFIC_DECIDE task. The task logic 1226 of the UE_STRANGE_TRAFFIC_DECIDE task is executed in step 1004. With that task, for example, deciding to deal with malicious traffic by deactivating the UE or informing customer care. When execution of the task, 1004, completes, APEX, 402, reads the metadata for the task from the task definition (see
The Act state must infer functional and non-functional properties for the option selected and forwarded from the Decide state. Examples of functional and non-functional properties are {requires security considerations}, {requires access control considerations}, {requires cost of execution considerations}, or {requires real-time of execution consideration}. For example, the Task Selection Logic 1002 will use the incoming context from the Decide task to see that Customer Care should be notified of malicious traffic. It may use, for example, select a NOTIFY_CUSTOMER_CARE_EMAIL, NOTIFY_CUSTOMER_CARE_SMS, or NOTIFY_CUSTOMER_CARE_IM task to notify customer care. A global context variable such as NOTIFICATION_MECHANISM may be used to select the appropriate task, 1002. If, for example the NOTIFICATION_MECHANISM is set to SMS, the NOTIFY_CUSTOMER_CARE_SMS task is selected, 1002. The task logic 1226 of the NOTIFY_CUSTOMER_CARE_SMS task is executed in step 1004. The execution of the task in step 1004 results, for example, in putting a message describing the malicious traffic in a SMS message and packing it in the outgoing context of an action event for the SMS system. When execution of the task, 1004, completes, APEX, 402, reads the metadata for the task from the task definition (see
The following three examples illustrate the execution of adaptive policies.
With reference to
The table in
The flowchart in
Preferably each adaptive policy has a unique Policy ID, 1302, and a policy description, 1304. The set of possible triggering events is deduced by examining the incoming events specified on the tasks in the task set of the Match state, 1306. Likewise, the set of possible action events is deduced by examining the outgoing events specified on the tasks in the task set of the Act state, 1308. The policy authoring component, 510, uses the metadata definitions shown in
Steps 1310-1316 are described below with reference to
As a result of performing the steps illustrated in
In a preferred embodiment adaptive policy instances are deployed into APEX, 402, using the policy deployment component 518, as shown in
The flowchart shown in
In a preferred embodiment the policy deployment component, 518, then fetches, 1808, a list of currently running adaptive policy instances from each APEX and compares that list to the required adaptive policy instance list. This comparison results in a list of new policy instances to be created, 1810, a list of policy instances to be updated, 1812, and a list of policy instances to be deleted, 1814.
Also preferably the policy deployment component, 518, uses the global context attributes in each impacted policy to deduce, 1816, the changes that will occur to global context. This results in a further list of adaptive policy instances that, although not modified or deleted, are affected by changes to global context.
The final step of the deployment phase carries out a consistency check, 1818, of the new Incoming, Outgoing, Policy, and Global context for each APEX against the existing Incoming, Outgoing, Policy, and Global context to ensure that the policy deployment operation does not result in inconsistencies. If the consistency check returns OK, 1820—branch YES, the policy is ready to be deployed, otherwise a failure is reported, 1820—branch NO.
The flowchart shown in
New policy instances are then deployed 1908. Changes to existing policy instances are deployed such as changes to task selection logic or task logic, specification of new tasks in MEDA states, or changes to task parameter values, 1910. Policy instances to be removed are deleted, 1912. Finally, all adaptive policy instances are started or restarted, 1914.
The flowchart in
When a context collector, 514, receives, 2102, a list of context items from its source, it forwards them to the context coordinator, 516. The context coordinator, 516, checks each, 2104, item of context in turn by examining the metadata and knowledge base, 520, of the APEX (see
Because context information may be collected from many sources and may be in many forms, each context collector, 514, implements a particular mechanism to collect context from its source. All context collectors accept orders from and deliver context to the context coordinator component, 516, using a common interface. That interface may be implemented as an Application Programming Interface (API), using files, or using any other appropriate communication mechanism.
Match sub-unit, 2302, for understanding the trigger event and the information representative of at least one context in which the network operates, an Establish sub-unit, 2304, for determining the situation that gave rise to the trigger event, a Decide sub-unit, 2306, for deciding on configuration change; and an Act sub-unit, 2308, for determining how to realise the configuration change.
In this embodiment the task execution unit, 2206, corresponds to the Adaptive Policy Execution Environment (APEX), 402, and the four sub-units, 2302-2308, correspond to the four active MEDA states: Match, 502, Establish, 504, Decide, 506 and Act, 502 discussed earlier.
The node 2200 uses the interface 2204 also for communication with the network.
The network management system node, 2200, in its various embodiments is adapted to operate in accordance with the embodiments of the method described in this document.
A method of network management using an adaptive policy, wherein the adaptive policy is defined by a plurality of sets of tasks, the method comprising:
One embodiment of the method is illustrated in
The order of acts 102 and 104 is not important for the invention. In alternative embodiments the order of acts 102 and 104 may be reversed or both acts may be performed at the same time.
In one embodiment the policy and global contexts are bundled together in an external aggregator and delivered in this aggregated form for processing. Alternatively the information representative of the policy and global contexts is delivered separately.
A network management system node comprising a processor and a memory, said memory containing instructions executable by said processor, whereby said network management system node is operative to use an adaptive policy, wherein the adaptive policy is defined by a plurality of sets of tasks, and said network management system node is further operative to:
One embodiment of the network management system node 300 is illustrated in
XACML . . . eXtensible Access Control Markup Language
XML . . . eXtensible Markup Language
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2015/073925 | 10/15/2015 | WO | 00 |
Number | Date | Country | |
---|---|---|---|
62073702 | Oct 2014 | US |