After a flurry of announcements from NSN, Ericsson and Huawei, the question I’ve been asked most is, “what is OSSii”? It’s not what most people think it is…
OSSii. It’s got an acronym. A website. Even a sort-of logo.
But what is it? Reading the rather formally-written memos, press releases and FAQ on the OSSii website requires you to understand a bit about how OSS and equipment vendors work and partner to fully appreciate what they mean.
Allow me to interpret as best I can.
OSSii stands for:Operations Support System Interoperability Initiative
So, it’s an initiative by its members to enable greater interoperability between their OSS systems.
As the current OSSii members are hardware vendors, the focus is on the interoperability of ‘north-bound’ network management system APIs with OSS management functions.
Who is involved in OSSii?
Ericsson, Huawei and NSNinitiated OSSii and are currently the only companies who have signed-up to licensing of their APIs.
Which OSS APIs are covered by the OSSii agreement?
Right now it’s OSS APIs relating to the mobile RAN and mobile core networks.
The agreement states:
OSS north bound RAN (including GRAN (GSM), UTRAN (WCDMA) and E-UTRAN (LTE) / CN (Circuit/Packet Core and Evolved Packet Core Networks) FM – PM – CM
Translating, that means the ‘north bound’ APIs from network vendors’ element managers or network management systems for 2G/GSM, 3G and 4G/LTE networks, including elements from the cell-site in to the mobile core.
Functionally, it covers those north bound APIs relating to Fault Management, Performance Management and Configuration Management.
So, in practice, it means the NMS/NEM APIs are licensed so that each member (and third-parties) can test their own OSS applications for interoperability with the network-facing systems. Note that fault, performance and configuration management APIs can cover a lot of other OSS functions; I would expect it to benefit fulfilment, planning, discovery, inventory OSS functions too.
Why does OSSii only cover mobile networks?
No reason has been given, but we can take a guess:
- Mobile is where the action is right now. It’s a growth area, both in terms of more network being rolled out (for LTE and small-cells) and its management is more dynamic than, say, the optical layer which is more like a relatively static high-capacity ‘trunk’.
- IP access and core have reasonably standardised (or being-standardised) APIs already: SNMP and flow APIs, for example, cover a lot of Fault and Performance Management functionality. Other work in the world of IP is going on in the SDN domain too.
- Core optical and SDH networks, as well as being less dynamic, have notoriously poor API support. A lot of work would need to be done before it was worth cross licensing their APIs. The business case is therefore simply not there.
So OSSii is a new OSS API standard, right?
Ah! No. It’s more pragmatic than that.
OSSii is an agreement to license each other’s existing OSS APIs and provide the means of testing interoperability between systems.
So,no new common interfaces are being defined. It’s simply licensing vendors to have access to existing API details so they can test their OSS against others’ OSS. That’s quite a big step when you consider that historically these are companies that would consider themselves in fierce competition with one another.
Each member of OSSii must provide a means of supporting interoperability testing for the other members. This would typically involve giving remote access to some sort of test bed or lab environment and some time with their architects or consultants.
OSSii allows for testing, not certification
OSSii does not include formal certification of the use of APIs. This is another difference from most standards organisation approaches.
A certification process would typically involve the owner of the API double-checking how it’s being used and issuing a formal confirmation that the user has tested a certain set of functions or network types.
Instead,OSSii simply allows for testing to take place. The user of the API sets the functional scope of the tests themselves. Of course, the owner of the API will likely provide documentation and guidance as to how the APIs should be used correctly, but there is no formal ‘sign-off’ to the test.
The OSSii license is FRAND
FRAND means Fair, Reasonable, and Non-Discriminatory.
The license that allows each OSSii member to use the others’ OSS APIs is a commercial one, but the point of OSSii is to make it easy and cooperative. Members can not set unreasonably high prices or unfair terms and conditions in order to seek some sort of advantage form their position as an OSSii member. Indeed, the MoU seems to suggest that when one company with an OSS API licenses that of another company, then the ‘costs’ cancel each other out. Or, at least, there’s a sort of ‘part-exchange’ going on that writes-off much of the cost.
Can other companies license APIs under the OSSii terms?
It seems so, yes.
Other vendors with their own OSS APIs can sign-up and trade their APIs for the others with a cross-licensing agreement.
Also, OSS vendors who do not have their own north-bound APIs can get a license, still under the FRAND terms. For example, an service fulfilment OSS vendor won’t have their own north-bound NMS APIs but might want to pull out configuration and performance data from the equipment vendors’ APIs. They can acquire a license to do so, but would likely be subject to a higher (but still ‘fair and reasonable’) cost as they don’t have an API of their own to trade.
Where does that leave TM Forum’s OSS standards?
OSSii appears to be a reaction against the inertia of the industry to set any practical integration standards.
What’s the quickest, simplest way to enable interoperability? Share what we have today. That’s OSSii.
The industry has talked about OSS API standards for over a decade. The result has been sets of principals, ideas, common terms, and complicated diagrams. But no standards that actual define an implementation.
Now, that’s not to say that the likes of OSS/J, MTOSI and so-on aren’t useful. They at least provide general guidance on scope and purpose of various APIs. And perhaps NSN, Huawei and Ericsson’s APIs have been designed to follow that advice. So, well done TM Forum. It’s just, the OSS standards body really isn’t a completer-finisher personality-type, is it?