SCF Releases 5G Functional API to Enable Open Small Cells Ecosystem

The Small Cell Forum (SCF) announced the publication of documents focused on stimulating a competitive ecosystem for vendors of 5G-era small cell hardware, software and equipment. The expanded set of specifications contained in these documents are:

• SCF222 - 5G FAPI: PHY API Specification
• SCF223 - 5G FAPI: RF and Digital Frontend Control API
• SCF224 - 5G FAPI: Network Monitor Mode API

According to the press release:

Expanding upon the 5G Physical Layer API specification, published in July 2019, the new specifications enable small cells to be constructed piece-by-piece using components from different vendors, in order to address the diverse mixture of 5G use cases relatively easily, a common goal to all of the specifications made by Small Cell Forum.

The new release also includes two completely new specifications, SCF223: 5G NR FAPI P19 FrontEnd Interface Specification and SCF224: Network Monitor Mode API for Small Cells.

According to Dr. Prabhakar Chitrapu, Chair of SCF, “FAPI helps Equipment Vendors to mix PHY & MAC Software from different suppliers via this open FAPI interface. So, FAPI is an 'internal' interface.”

“5G-nFAPI (network FAPI) is a 'network' interface and is between a Distributed Unit and Centralised Unit  of a Split RAN/Small Cell network solution. An open specification of this interface (nFAPI) will help network architects by allowing them to mix distributed and central units from different vendors.”

SCF nFAPI is enabling Open RAN ecosystem in its own way by allowing any small cell CU/DU (S-CU / S-DU) to connect to any small cell radio unit (S-RU)

Here is a video playlist from SCF that explains the new API's



Related Posts:

• Telecoms Infrastructure Blog: Small Cell Forum Releases 5G FAPI API Specifications
• The 3G4G Blog: A quick tutorial on Open RAN, vRAN & White Box RAN
• Telecoms Infrastructure Blog: SuperMicro's 5G Pole-Mounted DU Server Solution

From traditional RAN to Open RAN - O-RAN: Goals and Challenges

My Open RAN tutorial has recently gained popularity with recent announcements from Altiostar, Mavenir, Parallel Wireless, Telefonica and Vodafone. With TIP Summit in few weeks time, I am hoping for a lot more curious people to discover that blog post and video.

Olivier Simon, Director, Radio Innovation, Orange spoke about "O-RAN: Goals and Challenges" at Open Networking Summit Europe 2019. In his presentation, he explained how O-RAN will trigger more intelligence and openness in the RAN domain. He talked about which use cases will require this new architecture and why O-RAN is coming at the right time. Major architectural change are necessary in the next years in order to improve E2E latency and benefit from the flexibility of virtualized network functions. O-RAN will provide the right framework in order to perform this transformation in an open manner and keeping at the same time economies of scale thanks to a global adoption.

The presentation also touches on O-RAN Software Community. The O-RAN Alliance recently partnered with the Linux Foundation to establish the O-RAN-Software Community (O-RAN-SC), to provide that open source software application layer to the RAN. O-RAN-SC will foster development of an open source infrastructure platform for running 5G RAN solutions.

The key aspects of ORAN-SC are:

• New Open Community focused on RAN Software in collaboration with O-RAN Alliance
• Set up for collaboration across OPNFV, ONAP, Akraino and other Open Source projects

Here is the video of the conference embedded below:



Related Posts:

• A quick tutorial on Open RAN, vRAN & White Box RAN
• Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO

Telecom API's: The why and what

It felt like with the focus on LTE/4G and Small Cells and everything else in the mobile industry, the API's vanished in the background...or so it seemed. Telco API's are alive and kicking and there is a renewed focus on them.

This is from an AT&T press release not so long back:

AT&T*, already the leading carrier deploying network Application Programming Interfaces (APIs) to developers,1 today announced it has launched an enterprise-focused API program that allows enterprise customers, wholesale collaborators and solution providers to innovate using AT&T network APIs.

Led by industry thought leader Laura Merling, VP of Ecosystem Development and Platform Solutions, AT&T is pursuing a telecommunications industry API opportunity expected to grow to $157 billion in global revenues by 2018.2

APIs are software interfaces that provide access to data and core functions within AT&T’s network. By opening up its APIs to customers, AT&T believes it can help them meet three key challenges: do more without spending more; harness technology to gain competitive advantage; and support their ability to create and deploy applications that can be used on almost any device around the world.

...

Some examples of how enterprises can use AT&T APIs include:

• Content formatting: Using APIs, video content from a company’s video library stored in the cloud can be easily optimized in near real-time for users to watch on almost any device and network.
• Communications services: To bring more efficiency and productivity to business operations, businesses can use APIs to automate voice and video calls, integrating speech and video services into applications.

Sometime back, Martin Geddes (MG) posted his discussion on this topic with Alan Quayle (AQ) here:

I interviewed Alan earlier this week, and here is our joint “state of the telecom API nation” report.

MG: My early telecom API project crashed and burned, and past industry initiatives like ParlayX never took off. What has changed since the early 2000s that is triggering new and rapid growth?

AQ: Both the technology and the market have evolved. Large new developer communities have been created by Apple and Google, delivering value through those ecosystems. The need for such ecosystems and partnerships in telecoms is now driven by business demand, not technology supply, and thus is no longer seen as unusual or controversial.

Ten years ago there were developers, but the developer platforms were not as sophisticated. The technology was complex to consume, so you had to be a hardcore developer to use what was on offer. Today we have a mass developer market of people with Web development skills, and an Independent Software Vendor (ISV) market able to consume telecoms capabilities using their existing skills base.

The whole ICT industry – including ancillary services like consulting and equipment – is around a $5tn annual market. Yet it notably lacks a large-scale profitable developer ecosystem for networked service delivery. Why has it failed? Historically there have been too many silos, and too much friction to engage with them. What we are now seeing are companies like Apidaze, Bandwidth, OpenCloud, Plivo, Telestax, Tropo, and Twilio eliminating both of these. Lots of money is being spent on marketing to developers, creating a new business opportunity that telcos and broader ecosystem can take advantage of.

Notably this ecosystem is about more than just APIs. There's also the whole free and open source software arena too. Tools like FreeSWITCH, OpenCloud, Mobicents and WebRTC are becoming core to service innovation. Platforms like Tropo’s Ameche open up new opportunities for value-added voice services. We will be looking at the whole development stack at the Summit in Bangkok.

Who are the key consumers of telecoms APIs and what for?

Telecoms APIs are generally used by enterprises that are embedding communications into their core processes. The term “Communications Enabled Business Processes” was used in the past, but the name never took off, even if the concept did. As such, there is a quiet enterprise communications revolution going on. (See my recent articlefor more information.)

Lots of businesses are doing cool stuff, often to sell to other enterprises. These projects and platforms may not get much press individually, but collectively they add up to a significant market.

For example, Turkcell are a leader in this area of enterprise API delivery. However, they don’t talk about APIs, because it’s about the end user and the value from a better customer experience. They focus on promoting their enterprise services, all of which are (crucially) backed by sales team with technical support. Example services include FreeURL, where customers surf on your pages for free; customer device model and mobile number to support efficient and effective interaction regardless of end user device type; a “find the nearest store” capability to drive sales; and click to call services to capture leads.

That these telecoms services use APIs is about as interesting as them using electricity. The business value and innovation is in the enhanced customer experiences they enable.

Who makes money from producing telecoms APIs and how?

Everyone can! Telcos, intermediaries who work with the developers, enterprises and systems integrators. To make progress, however, telcos have to accept they can't do everything for themselves. For instance, you have to know what developers want – and that means Web scripting, not REST APIs. We will for the foreseeable future need middlemen who translate the value of telecoms APIs into a consumable form.

The greatest value is in customer interaction APIs. The need to communicate with suppliers and customers is fundamental to the human condition, we have been doing it for millennia, and will not stop any time soon. There are long-established markets like bulk SMS and automated calling, and these are ripe for new growth with new capabilities to interact and transact with customers.

What are the most promising areas for future growth?

The growth is around value-added services, notably around the current voice cash cow. It’s time for telcos to remember their heritage: you're the phone company. The distracting “digital lifestyle” stuff only makes money for the content companies. There are too many adjacent businesses being built where the telco doesn't have enough competence, and are competing against low-end competition (e.g. cheap webcams vs managed CCTV or home monitoring services).

Lots of consultants are selling future billion-dollar markets that don't exist. Telcos need to stick to the basic nuts and bolts of communications services, and do them better.

What are the key challenges facing this space?

The key challenge is that this game is that it requires an ecosystem, and telcos are islands. That doesn't mean they should copy Apple and Android, but instead they need to focus on segments where they have credible value and an advantage. A $5tn industry should be able to do this.

What it requires is a whole offering, including sales, business development and support. API-enablement is just a piece of technology, and this cannot be led from a network or IT function; it’s a line of business. The improvement and value to the customers has to come first, and getting the mindset right is hard. We have proof points that you can make money, thanks to companies like Telestax, Tropo and Twilio, if you build a whole supply chain.

Finally, Alan Quayle has posted his independent review of Telecom API's which is embedded below:

Do you have an opinion on Telecom API's? Feel free to add it in the comments.

Network Interfaces for Applications using Parlay and OneAPI

Here is an old posting on Parlay/OSA that might be useful to put things in context.

An important development related to service evolution is operators making interfaces available to external applications for information and control. Two widely deployed capabilities today include location queries and short message service. With location, mobile devices or external applications (e.g., applications operating on computers outside of the network) can query the location of a user, subject to privacy restrictions. This can significantly enhance many applications including navigation, supplying location of nearby destinations (e.g., restaurants, stores), location of friends for social networking, and worker dispatch. With SMS, external applications can send user requested content such as flight updates.

Until now, the interfaces for such functions have either been proprietary, or specific to that function. However, there are now interfaces that span multiple functions using a consistent set of programming methods. One set is the Parlay X Web Services, a set of functions specified through a joint project of the Parlay Group, the European Telecommunications Standards Institute (ETSI) and 3GPP. The Open Mobile Alliance (OMA) now manages the Parlay X specifications. Parlay X Web Services include support for location and SMS, as well as many other functions with which developers will be able to build innovative applications.

Table 4 (above) summarizes the available Parlay X specifications. Operators are beginning to selectively deploy these functions. The advantage of this approach is that developers can build applications that are compatible with multiple operator networks.

A related project is GSMA OneAPI, a GSM Association project to also define network interfaces, but that prioritizes implementation based on expected market demand. OneAPI defines a simplified Web service for most functions that is essentially a subset of the related Parlay X Web service. It also defines a REST (Representational State Transfer) interface for most functions as an alternative to using the Web service. RESTful interfaces are simpler for developers to work with and experiment with than Web services.

Regardless of whether operators deploy with Parlay X or OneAPI, these are mainstream interfaces that will open wireless networks to thousands of Internet programmers who will be able to build applications that leverage the latent information and capabilities of wireless networks.

Source: 3G Americas Whitepaper '3GPP Broadband Evolution to IMT-Advanced (4G)'

Vodafone (JIL) to release new APIs to third parties

Vodafone is set to announce a standard set of APIs, allowing third parties to create applications integrated with Vodafone servers around the world, including tapping the operator's billing system for micropayments.

It's also worth noting that these new APIs are coming out of the Joint Innovation Lab (JIL), so should be applicable to the other JIL members in time - adding Verizon and China Mobile would put the JIL in charge of applications provided to more than 700 million mobile-phone users.

Vodafone is unveiling a set of standard APIs that will work in every region in which the operator has a presence. This will allow developers to create applications and roll them out around the world, as long as they don't mind their market being limited to Vodafone's 289 million customers.

Operators have long allowed third parties access to internal services, particularly SMSC's for messaging and often with access to billing systems, too. But this has generally been on a case-by-case basis and only sharing limited functionality. Not only does that require developers to work with each operator in turn, but platforms are often fragmented even within the same operator - particularly where international expansion has been managed through acquisition - so developers often have to negotiate, and code, for every operator, in every region.

Not that today's announcement is the first attempt to address this problem: Vodafone makes much of the new API's ability to bill for small transactions, allowing developers to include the "insert coin to continue" functionality they've been hoping for. But Vodafone is also part of the "PayForIt" consortium, which provides the same functionality across multiple networks. PayForIt operates though gateways that take a cut of the money, so developers will have to decide on the value of being cross-network.

Obviously applications will need to be certified to have access to the APIs, something the JIL was already planning along with on-device APIs to allow (suitably signed) widgets with access to local, and network, resources - all of which should be revealed over the summer.

Parlay, OSA, etc

Parlay (as opposed to Parley in 'Pirates of the Carribean') integrates telecom network capabilities with IT applications via a secure, measured, and billable interface. Parlay's open application programming interfaces (APIs) release developers from having to write code for specific networks and environments, reducing risks and costs, and allowing for innovative new services to be delivered via the telco network-operator channel. Enabled by Parlay's network-independent APIs, applications are generating new revenue streams for network operators, application service providers (ASPs), and independent software vendors (ISVs).

Today, where each service interacts individually with different network elements, ParlayAPIs can be useful.

These APIs will allow you to access same services regardless of whether you are using a Mobile phone or a fixed line phone or a PC thereby creating a Virtual Home Environment (VHE).

Many different organisations are part of the Parley group including 3GPP, ETSI, OMA, ITU to name a few.

Finally if you find this interesting then you may want to read "Parlay/OSA: From Standards to Reality".

More:

• The Parlay group
• ETSI 2006 workshop on Parlay OSA

If you have any further pointers explaining relationships between Parlay, OSA, SOA, JAIN, CORBA, TINA-C, IMS, NGN, VHE, etc. Please post a comment and let us know.