To ensure that SMEs have a front-row seat to telecoms standards making, our Standards Champion, Andy Reid, attends key standards meetings to observe, participate in conversations and report back on key themes and discussion points.
Here, Reid shares his reflections on the recent LNF meeting in San Jose.
What to find out more about LNF and open source projects? Read Reid’s last article here.
What were the hot topics in San Jose?
Relationship between open source and standards
Not surprisingly, the relationship between LFN and standards was a major item of discussion, especially the relationship between LFN and 3GPP mobile standards as refined by O-RAN Alliance. There was a full session explicitly devoted to this developing relationship and explaining the O-RAN organisation for the benefit of the open source community.
This session highlighted some of the difficulties associated with the increasingly complex standards of 3GPP for 5G and beyond. O-RAN exists because many of these standards are not always precise enough (options exist) or complete enough to assure interoperability. O-RAN is a) adding precision to the 3GPP standards and, b) setting up interoperability testing facilities to actively demonstrate interoperability between different implementations.
However, for some functions, even adding precision to the 3GPP specifications is not as good as having a common reference implementation of the function, which is why the tie up with LNF has been initiated. Significantly, the open source reference implementation allows the overall industry process to be iterative and phased; the precise interface standard does not need to complete and correct first time.
Relationship between open source, SMEs, and academia
This was another significant item on the agenda: the role of open source in academia, and extending to smaller industrial players.
The basic message from many of those presenting their experience and views was that “open source gives us the opportunity to play in the game”. Commercial closed source software has a number drawbacks for both academic projects and smaller companies:
- does not normally allow experimental changes to the functionality and/or its interfaces;
- the packaging of the software may not allow access to the particular components of interest;
- the owner of the commercial product may deem the SME or academic project to be a competitive threat and not wish to cooperate with them;
- licence costs may simply be beyond allowable budgets.
Conversely, while open source has it own set of challenges - steeper learning curve, variable quality documentation, volunteer support – the above issues, which are more likely to be fundamental show-stoppers for these communities – are not present.
Commercial models for open source projects in telecoms
The fact this is still widely discussed after so many years of open source software, including at this meeting, is probably an indication that is not straightforward. Put simply, how do you make money out of something that’s freely available? The discussion did not necessarily add anything new, and seemed more about reassuring new attendees that answers do exist, with examples including:
- adding proprietary user interfaces and other support functionality to the core open source functionality;
- adding support services and levels of service assurance;
- creating an open source ‘community edition’ of otherwise commercial software to allow experimenting and testing of new features;
- donating an older proprietary software system as open source to save the cost of maintenance. The software is offered to the ‘community’ on the basis that ‘community’ will maintain it, while the original company retains the goodwill of customers still using the software by not simply withdrawing it.
- the functionality is a means to an end (i.e. for a business whose income arises elsewhere) and they wish to build a community and ecosystem around the software;
- government funded project.
- charity funded project.
Many projects contain a mixture of the above.
Role of government in open source
Across the Wednesday of the meeting, a stream was devoted to US government activities and interests. While there were several government departments and agencies represented giving a range of views, it was interesting to note that the primary thread was about using open source within their purchasing to leverage greater competition in their supply chain.
It was much less clear from the government representatives how they expected the open source software to arise in the first place. Clearly some people thought that the US government should be a significant sponsor of open source and not just looking to gain benefits of supplier diversification. These views do have good historic precedent: the Internet arose directly from a project fully funded through the US Defence Advanced Research Projects Agency (DARPA).
Specific hot projects in LFN
The main projects in LFN include:
- Nephio: this project has started with a fresh approach to the orchestration of virtualised network services running on cloud native infrastructure controlled by Kubernetes. The project is seeking to develop the complete orchestration system, including its interfaces, within the Kubernetes framework.
- ONAP: this ‘Open Network Automation Platform’ is a large set of systems for the design, creation, and lifecycle management of network services built by orchestrating and linking virtual network functions (VNFs).
- OpenDayLight: a software defined networking (SDN) controller.
- FD.io: this software give a secure and very fast data plane to run on standard CPU compute hardware but can also exploit hardware accelerators if available.
- Anuket: this is a more mature project covering network functions virtualisation (NFV) infrastructure (part of Anuket was originally called OPNFV for ‘open platform for NFV’). It is more unusual as it is more than simply a set of software modules, also covering reference architecture, interface specifications and conformance testing.
The latter four are all used by O-RAN.
Why Get Involved?
One of the great things about open source is that it is possible to get involved gradually and at different levels. Simply downloading the software, installing it, and getting a basic configuration running is already a level of involvement. At a minimum, this reassures the developers that what they are doing is useful! Further, if you allow automatic bug/performance reporting, you are automatically helping to maintain and improve the software. So if your product needs other components to support or interact with it, and you use choose open source components for some of these, you are already involved.
The use of open source components to support, develop, and test your product can have big advantages. First, there are no licence costs or other restrictions to experimenting with different systems. Second, the systems are normally highly configurable to your needs. Third, you have the opportunity to get enhancements to the system in line with your requirements. At this third point, you move up the levels of involvement and becoming an active member of the community.
As an active member, what you get out from the community is directly correlated to what you put in. If you would like a new feature and just propose it, the developers will consider what’s in it for them, but if you offer code which implements it, it will very likely be accepted.
At the other end, you may decide that creating your own open source project is the right strategy for your business. With the way open source runs, it is normally possible to retain leadership and control of a project you create. This can be a very good way creating an ecosystem and momentum around your product, especially in software markets where there is a tendency for the ‘winner to take all’.
