OSS Line

OSS Intelligence

Last week I spoke at a small workshop about how artificial intelligence can be used in multi-layer network planning, optimisation and fulfilment. Multi-layer networks are causing service providers a bit of a headache at the moment. Typically they comprise MPLS or Ethernet over a DWDM optical transport network. On paper it looks quite neat: Very high capacity transport that can carry pretty much any traffic type, and super-flexible IP services on top.

It is generally agreed that the effort is worth-while in order to offer high bandwidth services and provide a platform for rapid introduction of new types of service. But the PowerPoint diagrams don’t translate to the real world so easily.

A few of the problems service providers face are:

• Migrating legacy services is complex.
• There’s a wide choice of DWDM deployment options, each with their own pros and cons.
• Most established planning systems are unable to design services across more than one network layer at once.

Most of the presenters at the workshop were addressing the last point. I had thought, by talking about artificial intelligence, I would be providing a unique ‘intellectually rigorous’ approach to solving the problem.

Wrong.

While I was the only one talking about A.I. in general, all but one of the OSS vendors attending were pitching ‘intelligent’ solution. And all of those were start-ups, including Aria Networks who I was representing.

So it seems intelligent planning is an emerging solution in OSS. Certainly amongst this group of hardware & software vendors and service providers, there was a clear expectation that intelligence is essential to enable effective, optimal planning. But few approaches are actually well understood, and certainly no one approach has emerged as a clear leader. 

What do I mean by intelligent? In researching my presentation I found no established definition that satisfied the problems and needs of telco. So, to quote myself:

“Applying better algorithms and better analysis to out-perform the capabilities of scripted, procedural, and BPEL approaches.” – Me (Last Week)

For network planning, the core requirement is optimal routing (or re-routing) of large numbers of circuits and services. Procedural approaches don’t scale simply because the search space is too big: Too many services; too many devices; too many links; to many network layers; too many parameters; too many constraints. You can’t crack this with brute force.

Intelligent planning has to find a way to reduce the search-space, balance all the requirements, while still being sure that the optimum solution is found. Various technologies, algorithms and approaches exist, such as:

• Neural nets
• Multiple integer programming and linear programming
• Genetic evolution
• Heuristic-driven path finding

The challenge facing OSS vendors and service providers is a lack of understanding of non-deterministic A.I. techniques. Much A.I. is well proven in other fields, yet use in OSS has been limited until recently. There’s a huge gap between peoples understanding of a procedural solution (a number of tasks processed from start to finish) and a non-deterministic approach which is beyond the understanding of most users (me included usually). Yet it is only non-deterministic intelligent solutions that will be able to continue to optimally manage capital expenditure in multi-layer next-generation networks.

So, we have some work to do. Like inventory ten years ago, and service catalogs three years ago, it turns out that OSS marketing is all about education again.

Designing a Standards-Based Application

There are a number of ‘standards’ out there that, as a system integrator or product vendor, you may want to use within your OSS solution. Stuff like MTOSI, OSS/J, SID, 3GPP all look like useful starting points for inventory-like data models and their  integration points.

It is important to appreciate the difference between a standard’s published specification and an implementation of a useable database model and business logic.

Let’s consider TeleManagement’s MTOSI as an example, as it is the most popular standard for network data exchange right now. The MTOSI specification is not concerned with implementation of an inventory model, or how it is maintained by a database and operated against by an application. Nor does MTOSI define ‘metadata’; the definitions of what are valid models, e.g. what equipment comprises a specific type of Cisco router. MTOSI just provides a means of describing network elements. MTOSI arose out of a need for a standard way of pushing up the data held by network element managers in to network management systems or cross-technology OSS platforms. So, it’s main focus is in defining a data format and a number of operations around retrieving or modifying the data.

Here’s a very high level picture of the MTOSI physical model. There are many other entities that can be modelled, and much more detail in the actual specification, available from the TeleManagement website.

above. Simplified MTOSI Physical Model. Click to Enlarge.

Looks good. If I’m developing any application that needs its own internal record of network equipment, this would be a great place to start.

MTOSI’s physical equipment model is quite straight forward. It allows hierarchies of objects to define the common device-shelf-slot-card-interface model of telco equipment.

To some extent the MTOSI model looks like a database model, as if it could be mapped directly in to tables to create a useful inventory. This is not the case, for a technical and design reasons.

Object-Relational Mapping. The MTOSI model is an object oriented model. Databases are usually relational model. It’s the old ‘object-relational impedance mismatch’ that requires applications to do apply business logic to an object model but persist those objects in a relational database, such as Oracle or MySQL.

There are also OSS and application-specific design considerations that will mean the MTOSI model may be best implemented in a particular way. These three factors normally have to be balanced depending on the OSS application’s requirements. For example one might have to sacrifice some performance in favour of flexibility.

Design for Performance. Response times, concurrency and scalability all combine in some acceptable compromise to deliver an application that 'performs well'. In OSS, raw single-thread performance is usually traded-in for good concurrency (multiple process/user threads) and scalability (effective use of additional hardware). Overall performance is usually best when building data schema and code to a static design, i.e one that does not rely on introspection and data-driven code. A static design allows for  assumptions to be made, reducing checks, queries, lookups, error handling and process roll-back overhead.

Design for Flexibility. Some applications work to an original,  fixed design. Rarely is this true of OSS applications. In OSS flexibility must be offered to allow customers to deploy their own inventory objects, provisioning processes and activation scripts. If done well, flexibility is enabled through data-driven configuration and clearly defined APIs. Architecting these features requires extra layers of abstraction and checks which inevitably result in reduced performance.

Design for Maintainability. While the end customer needs application flexibility to make changes to their deployed product version, the software developer needs to be able to maintain the application as requirements change between product versions. For example, an inventory product based on the MTOSI 2.0 standard will one day need to be upgraded to support MTOSI 3.0. This could either require a redesign of the data scheme, possibly impacting backwards compatibility, or it could be achieved through metadata and limited schema changes supported by clever 'introspection' by the system's public APIs.

At one extreme, systems that have critical performance requirements, such as data migration or bulk update processes, would be designed for high performance at the expense of flexibility and maintenance: assumptions might be hard-coded in the process, integrity constraints disabled, layers of system architecture replaced by transaction scripts. A multi-purpose OSS inventory, that needs to support several applications and business functions, would expect to sacrifice performance in favour of flexibility: Layers of system abstraction, configuration, metadata and integrity constraints would be implemented.

above. Design Requirements for OSS Applications. Click to Enlarge.

When implementing a standard, designing database schema and coding business processes, one has to start by establishing what the priorities are that will drive the system architecture design.

> The standard’s specification itself does not dictate how you implement it, only what data and services it should support.

> There’s many, many possible ways of coding a database and Java application for any one given standard, such as MTOSI.

> An implementation of a standard will vary depending on the type of application that is using it.

>The first question to answer is, how important is performance, flexibility and maintainability? They can’t all be high priority!

Coming soon! Part two will look at options for mapping an MTOSI-like standard to a relational database such as Oracle, considering common architecture options and their suitability for particular OSS applications.

Comptel Real-Time OSS Benchmark with IBM

Comptel this week issued a PR about their recent benchmark results with IBM. It's a bit different from the Cramer OSS benchmark I wrote about a few weeks back when looking at a new BSS benchmark, also on IBM kit. For starters, Comptel's transactions are more billing and mediation than service design and provisioning. Secondly, the transaction volumes are huge! Billions of transactions per hour rather than thousands/millions one would expect in 'traditional' service provisioning.

The reason for this difference is Comptel's focus on serving large numbers of customer-initiated real-time transactions. This usage pattern, they claim, reflects the trend in 'lifestyle' services. I assume what they mean is that if you're offering, say, quad-play, there's going to be a lot of stuff to do in terms of billing and activation to get it all up and running. Then you also hope to sell lots of little add-ons or on-demand services which results in lots of little configuration and charging changes. Same situation if you allow users to regrade their services on-demand. And at any one time all those services/add-ons/subscriptions will require more billing and mediation, whether on not the service configuration is actually changing.

Comptel and IBM have achieved these figures using an in-memory database. Most popular, modern, system architectures with layers of web, Java and database components just can't deliver real-time transactions. I use the term real-time loosely to mean a transaction with latency acceptable to an inpatient end-customer. 'Acceptable' will vary depending on the transaction, but let's assume less than 10 seconds to do something like issuing an order for an on-demand service and that service becoming available to the customer.  Sure, a classic J2EE stack can turn-around a transaction, like a dynamic web page, in less than 10 seconds, but it's just one system. Service provisioning from order to activation requires several systems to complete their jobs (order management, billing, service management, activation, as a minimum set of distinct systems). This means any one system has to deliver their results consistently, while under load, in less than 2 seconds. Latency like this will only be achieved by minimizing calls between 'layers' inside the system, and minimizing or eliminating disk I/O by using in-memory databases or some very clever caching.

With the trend in lifestyle services I expect their to be a complimentary trend in OSS. Near-real-time inventory and design/assign transactions will still be needed, offering data resilience and transaction management for long-running processes. In parallel there will be real-time OSS processes that offer low-latency transactions. Today we are seeing OSS vendors promoting separate architectures for 'service management' solutions that can offer fast-track processes. However, there's no reason why these should be physically distinct applications that require integrating and synchronizing with OSS inventory. In the future, new OSS architectures will deliver more than one path from order to activation in a single system, depending on the transaction's latency requirements.