What is OSSii?

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.

Ericsson, Huawei and NSNinitiated OSSii and are currently the only companies who have signed-up to licensing of their APIs.

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.

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.

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 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.

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.

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.