Feedback loops and closed loop control

Closed loop network control is much hyped at the moment, and with good reason; the potential operational savings and service improvements from using the output of analytics to trigger orchestration and control functions to react to problems dynamically, or to automatically optimise the deployed infrastructure and services, are significant.  We’ve previously discussed this in ETSI NFV and Big Data Analytics with PNDA; see also: Knowledge Defined Networking.

As an industry, we’ve still got some way to go to realise this potential.

Something which has become apparent to us is that it seems common to refer to “a feedback loop” between analytics and orchestration / control, whereas, in practice, it seems more likely that there will be multiple feedback loops.  We’ve come up with the following model to describe this:

Screen Shot 2017-06-05 at 16.11.39

  1. Let’s start with a function to design a service (middle left), including determining where the service will be placed.
  2. Next orchestration/control functions are used to instantiate the service.
  3. That service is monitored, together with the infrastructure it’s running on
  4. The resulting data is analysed and the results can be used to close a number of possible feedback loops:
  5. Real-time feedback loop. This is used to trigger rapid reactions to conditions which are or will imminently be service impacting.  Example use cases:
    1. Service assurance: detect a service is down and trigger remedial action, e.g. VNF not responding and instantiate new VNF; see An analytics-based approach to service assurance: Part 2 – Is analytics the answer?
    2. Security threat mitigation: e.g. detect device is untrusted or compromised and quarantine; see ML-based Security Analytics with Apache SPOT on PNDA
  6. Near real-time feedback loop. This is used to optimise the state of the current services or the infrastructure they are running on, e.g. to preserve/improve the user experience or to delay the point when new capacity is required.  Example use cases:
    1. Traffic engineering: moving traffic flows to more effectively use the deployed infrastructure; see [https://arxiv.org/pdf/1608.03770.pdf]
    2. Demand engineering: siting traffic demands to more effectively use the deployed infrastructure; see [https://arxiv.org/pdf/1606.04720.pdf]
    3. Workload engineering: siting workloads to more effectively use the deployed infrastructure; see [https://arxiv.org/pdf/1703.06967.pdf]
  7. Offline feedback loop: this is used to forecast how the service or infrastructure should adapt in future. Example use cases:
    1. Capacity planning: what capacity will be needed where to support forecasted traffic demands
    2. Cache placement: where to place caches to best serve forecasted demands
    3. Peering planning: who to peer with to optimally serve forecasted traffic demands.

Hence, in practice, there will probably be multiple analytics applications, whose outputs can be used to trigger orchestration and control functions and realise close loop network control.

No models are perfect; I’m sure this one can do with improvement.  Feedback welcomed!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s