By: Mark Cummings, Ph.D.

There has been a lot attention directed to future OSS (Operation Support Systems) and Network and Service Orchestration Systems.  Some argue that OSS will evolve to encompass the orchestration function, while others argue that orchestration will take over the functions now performed by OSS.  We will examine the current situation with OSS in Telcos and how orchestration interacts with them.  The analysis will show that, most likely, neither of these extreme positions is correct.  The way the human body works is a good model that shows the synergistic relationship between them.

OSS

The first problem is what is an OSS.  For this discussion we will use the classical definition of an OSS.  That is, a computer system in a data center that attaches to the north bound interface of one or more EMS (Element Management Systems).  Generally, there are separate OSS for separate functions such as Inventory Management, Configuration Management, Alarm Management, etc.  These systems have operator consoles in the NOC (Network Operations Center) where operation staff interact with the OSS.  These consoles are the primary (but not only) way that operations staff and others interact with Network Elements (NEs).  It is the intent of the OSS to be to be the authoritative source of information about the current state of the NE’s that compose the network.  OSS tend to be based on the assumption that they are also the only way that NEs are provisioned, monitored, and changed.  When OSS evolved, this was a powerful vision.  Over time, the vision and reality have diverged.

Today, there are many ways other than through OSS that people interact with the operation of NEs.  This results in changes that may not be visible to the OSS.  These include Local Maintenance Terminal (LMT) interactions by Telco operations staff members, third party service providers, and vendor staff members.  In many cases, vendors also have special vendor only accessible interfaces that they use to make configuration changes, software updates, etc.  Also, Telco operations staff members, third party service providers, and vendor staff members may make hardware changes such as replacing boards, or even whole systems.  These kinds of changes are often not visible to the OSS.  Thus, some Telcos have a standard process of periodically interrogating all NE’s to update themselves.  This resembles a common practice in the financial industry.

Many banks, etc. use a “system of record” / “memo post” system.  In this approach, each night an updated version of the system of record is loaded into a separate memo post system.  During the day, transactions are made based on the information in the memo post system and it is updated accordingly. At the end of the transaction day, the system of record is updated from that day’s memo post system and a new system of record is created. In one European Telco, the status of all base stations is interrogated each night and the OSS are updated accordingly. In another European Telco this is done once per week.  As networks become bigger and more complex (2G base stations had 50 software settable parameters; 3G had 500; 4G 6,000; and 5G?) it is becoming more and more difficult to complete an interrogation run in the quiet period between 2:00 and 6:00 a.m.

In addition to multiple uncoordinated entry points for data, there is a process of summary and delay that affects the data in OSS.  To understand this, it is helpful to think in terms of layers.  The layering of data plane and control plane has been discussed for some time.  However, it is more useful to think of several planes above the data plane.  There is the control plane that is involved in packet routing, etc.  Above that is the orchestration layer that we will discuss later in this article.  Then comes a relatively fast management plane with functions performed by EMS.  Then, a slow management plane with functions performed by OSS. Then, finally, there is the Big Data plane.  As information moves up the layers, it is summarized and since the movement takes time, somewhat “stale”.  As a result of all of these affects, OSS do not have complete and timely information.

From the outside, there is a tendency to talk about OSS as if there is a single OSS system for each function.  Unfortunately, this appears not to be the situation.  One of the U.S. majors tells me that they have over 200 Inventory Management Systems.  It is interesting to note that they didn’t say 242 Inventory Management Systems.  This suggests two things: first, they are not sure how many they actually have; and second, there is some volatility with Inventory Management Systems coming and going.  Also, it appears that a similar situation exists for the other OSS functions.  That is, that there are approximately 200 Configuration Management Systems, Alarm Management Systems, etc.  Operators in Europe tell me that the situation with numbers of support systems is the same in Europe.  In some countries that have gone through recent development or with highly-centralized government-owned Telcos, the situation may be a little different, but the general Telco situation is large numbers of OSS.