The left-hand panel of the triptych below shows the current state of interactions with most OSS. There are hundreds of variants inbound via external sources (ie multi-channel) and even internal sources (eg different service types). Similarly, there are dozens of networks (and downstream systems), each with different interface models. Each needs different formatting and integration costs escalate.
The intent model of network provisioning standardises the network interface, drastically simplifying the task of the OSS and the variants required for it to handle. This becomes particularly relevant in a world of NFVs, where it doesn’t matter which vendor’s device type (router say) can be handled via a single command intent rather than having separate interfaces to each different vendor’s device / EMS northbound interface. The unique aspects of each vendor’s implementation are abstracted from the OSS.
The next step would be in standardising the interface / data model upstream of the OSS. That’s a more challenging task!!
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
