 |
|||||||||||||||||||||
|
|
|||||||||||||||||||||
        |
Regular Articles Vol. 14, No. 1, pp. 69–72, Jan. 2016. https://doi.org/10.53829/ntr201601ra3 Utilization of APIs for B2B2X Business ModelAbstractThe NetroSphere concept proposed by NTT laboratories aims to divide network functions into small modular components and to flexibly assemble those components. This makes it possible to quickly form proportional networks that can offer required functionality according to user needs. As a result, carrier networks will achieve enhanced flexibility and elasticity while also drastically reducing costs. This article introduces the architecture to provide network functions and resources via APIs (application programming interfaces) to collaboration partners such as service developers. Keywords: API, collaboration, NetroSphere
1. IntroductionThe NetroSphere concept is a future network vision proposed by NTT laboratories [1]. The concept enables network functions to be divided into small modular components, which can then be flexibly assembled. This makes it possible to quickly form proportional networks that can offer required functionality in accordance with the user’s needs for B2B2X (business-to-business-to-X) business models where various service partners and communication providers collaborate to provide services. This will increase the flexibility and elasticity of carrier networks while also drastically reducing costs. Web-API*1 (API) is considered to be one of the key technologies to achieve the NetroSphere concept. In this article, the architecture that provides network functions and resources via APIs and design rules for the APIs are explained.
2. Trends in usage of APIs for collaboration2.1 Trends of service providers and overseas telecom operatorsWell-known service providers such as Twitter, Facebook, and Amazon Web Service expose APIs in order to provide their own functions and information. Some large overseas telecom operators have also started providing network functions such as call control and payment services and have organized promotional programs such as ideathons and hackathons to bring business ideas into shape [2, 3]. Our view is that providing network functions via APIs will bring two advantages to these service providers and telecom operators: 1) Growth in revenue: When they provide functions and resources via APIs, collaboration partners can create new services with those functions and resources. Service providers and telecom operators can earn revenue by charging for the use of functions and resources that are provided via APIs. 2) Reduction in operating expenses (OPEX): Providing operational functions via APIs simplifies operational cooperation with collaboration companies. It permits business process automation and reduces OPEX. 2.2 Trends in standardizationMobile telecom operators provide network functions via APIs to their collaboration partners. The specifications of these APIs differ from operator to operator. This forces collaboration partners to write operator-specific programs. OneAPI is a set of APIs supported by the GSM Association (GSMA)*2 that defines API specifications for elements such as SMS (Short Messaging Service)/MMS (Multimedia Messaging Service), device capabilities, and payments [4]. AT&T provides some APIs according to these specifications. The TeleManagement Forum (TM Forum)*3 has started to define API specifications for the interface between these business processes in order to facilitate the automation of business processes of telecom operators. TM Forum published some operational specifications such as those for trouble tickets and product ordering. Further, in the Open Digital Project, one of TM Forum’s strategic programs, discussions have been initiated on the reference architecture called the Digital Service Reference Architecture (DSRA), which allows collaboration partners to create applications with a number of digital services provided via APIs [5]. As previously mentioned, some standardization organizations have defined the specifications of APIs, but their scope is limited. Thus, most operators provide APIs designed according to their own rules.
3. Technical considerations in providing network functions via APIsWe consider that APIs represent one of the key technologies to achieve the NetroSphere concept and that they will be effective in providing the architecture for NetroSphere. 3.1 API-providing architectureThe architecture being studied to provide network functions via APIs is shown in Fig. 1. This architecture consists of three functional units: the mediator unit for protocol transformation, the API orchestrator unit for scenario control and API mash-up, and the API-GW (gateway) unit for authorization and traffic control. The details of these functions are described here and shown in Fig. 2.
(1) Mediator unit Many existing operational systems have a unique interface to enable interconnection with other such systems. Our view is that it would be advantageous for network functions to be provided via representational state transfer (REST) APIs because the REST API style is familiar to service developers. Thus, we introduced the mediator unit to transform the unique interface into the REST API style. (2) API orchestrator unit Telecom operators do not want to directly expose their own backend systems such as their customer management and billing systems from the viewpoint of protecting the security of their systems and avoiding unnecessary complexity. The API orchestrator unit provides API abstraction and scenario control functions, which meet telecom operator requirements. (3) API-GW unit Service developers ordinarily have to call each end-point that differs from system to system when they use network functions provided by different systems. Moreover, each system may provide different API specifications such as those for the data format. This is not helpful to service providers. Thus, we introduced the API-GW unit to centralize end-points and absorb differences in API specifications. In addition, the API-GW provides a common function to expose APIs such as those for traffic control and authorization. The API-GW unit is divided into three functional units that have specific functions. 1) API broker: API broker provides a security protection function, authentication and authorization function (API-key, OAuth), and a traffic control function in accordance with the terms of agreement and system state, and an interface transformation function in accordance with design rules described in section 3.2. 2) Developer portal: The developer portal provides service developers with a management function and documents such as manuals and sample code. 3) System operation/maintenance: The system operation/maintenance function unit provides operational functions for the API-GW operator to manage enablers, APIs, and applications developed by service developers and also to manage the state of the API-GW. 3.2 API design rulesThe design rules of REST APIs such as the API naming rule and data format description rule are flexible. Thus, specifications of APIs provided by telecom operators may differ from operator to operator. In addition, APIs may differ from vendor to vendor even if the functions are the same because these APIs are designed according to vendor-specific design rules. This may cause difficulties when telecom operators renew their equipment. To simplify things for service developers, we believe that telecom operators should provide APIs designed according to a unified design rule based on one of the two rules below. 1) Function-independent rules: These rules define common rules that apply regardless of the type of functions; they include naming rules of URLs, rules for determining data format, and authentication methods of APIs. 2) Function-dependent rules: These rules define functions themselves such as those for call control, service orders, and trouble tickets. Our first step will be to focus on function-independent rules. 4. Future prospectsThis article reviewed the API-related trends followed by overseas telecom operators. An architecture that provides network functions via APIs was also discussed along with API design rules. Our aim is to standardize the proposed architecture and describe the API design rules at a TM Forum event. We will define the aforementioned architecture that allows service developers to create applications with multiple functions provided by telecom operators. In parallel, we will start providing an API testbed called Atelier N [6], which is positioned as a collaborative program. We would like to use this program to discuss issues related to creating services and providing functions with our collaboration partners such as service developers and function providers. We also plan to evaluate the proposed architecture and design rules with our collaboration partners. References
|
||||||||||||||||||||
