Review

Fusion of Telecommunications and IT Services Boosted by

Application Programming Interfaces
Máté Ákos Tündik 1, * , Zsolt Szabó 1 , Attila Hilt 1,2, * and Gábor Járó 1

1 Nokia, Cloud and Network Services, Bókay János utca 36-42, 1083 Budapest, Hungary
2 HVT, VIK, BME, Department of Broadband Infocommunications and Electromagnetic Theory,
Faculty of Electrical Engineering and Informatics, Budapest University of Technology and Economics,
Műegyetem rakpart 3, 1111 Budapest, Hungary
* Correspondence: [email protected] (M.Á.T.); [email protected] (A.H.)

Abstract: Our long journey on the road of telecommunications is continuously evolving. We have
experienced several technological changes, modernizations, optimizations, and various mergers
in the past decades. Virtualization and ‘cloudification’ of legacy telecommunication equipment
has made communication networks not only more flexible, but also opened new doors. Brand
new types of services have become available thanks to the ongoing fusion of the two domains
of telecommunications and IT (Information Technology). This overview paper first discusses the
evolution of services with an enhanced focus on mobile networks. Then, the possibilities offered by
IT are shown. Finally, some examples are given of how Communication Service Providers and end
users can benefit from these recent changes.

Keywords: communication services; cloud; API; CAMEL; INAP; IT; TAS; VoLTE; IMS data channel

1. Introduction
The landscape of fixed and wireless telecommunications has changed extremely
quickly over the past three decades. Communication Service Providers (CSPs) contin-
uously face challenges when operating various hardware (HW) and software (SW) from
different equipment manufacturers in their multi-functional and multi-layered networks.
Citation: Tündik, M.Á.; Szabó, Z.; On the one hand, the introduction of innovative technologies and new services has
Hilt, A.; Járó, G. Fusion of
transformed legacy systems into a more and more sophisticated network architecture.
Telecommunications and IT Services
As an example, and without completeness, an evolving network scenario is shown in
Boosted by Application Programming
Figure 1. The network contains fixed and mobile subscriber access technologies and
Interfaces. Signals 2024, 5, 756–773.
different core network types. Such a CSP network environment can simultaneously serve
https://doi.org/10.3390/
consumer, industrial, and enterprise subscribers requiring various wired and wireless
signals5040042
services. In several countries, including Hungary, third-generation (3G) mobile sunset
Received: 17 July 2024 projects have already started to switch off 3G NodeBs (NBs) completely. Similarly, the Plain
Revised: 14 September 2024 Old Telephone Service (POTS) fixed lines of legacy Public Switched Telephone Networks
Accepted: 28 October 2024 (PSTNs) are in practice being continuously replaced by mobile or fixed VoIP (Voice over
Published: 12 November 2024
IP) solutions. The complex meshed network of Figure 1 can be divided into three main
parts: subscriber access; cell sites, controller nodes, and backhauling; and, finally, the core
network (horizontal scale). The various subscriber access methods are fixed, nomadic, or
Copyright: © 2024 by the authors.
mobile (vertical scale in Figure 1).
Licensee MDPI, Basel, Switzerland. Since the appearance of smart devices and with the growing demand for the IoT
This article is an open access article (Internet of Things) and machine-to-machine communications (M2M), subscriptions are
distributed under the terms and growing enormously [1,2]. Subscribers are not any longer only human users using the
conditions of the Creative Commons network for simple telephone voice calls. Industry, transportation, modern agriculture,
Attribution (CC BY) license (https:// education, medicine, robotics, etc. all require data connections [3–6]. The User Equipment
creativecommons.org/licenses/by/ (UE, either fixed or mobile) at the end of the data links can be sensors, machines, metering
4.0/). devices, cameras, vehicles, robots, or any other remote-controlled equipment. A massive

Signals 2024, 5, 756–773. https://doi.org/10.3390/signals5040042 https://www.mdpi.com/journal/signals

Signals 2024, 5 757

rollout of 5G (fifth-generation mobile systems, also called New Radio, NR) systems is
Signals 2024, 5, FOR PEER REVIEW already ongoing in several countries to serve these new demands. In Figure 1, 5G core and2
NR are marked in light blue, and phase-out technologies are marked in gray.

Figure 1. The evolving telecommunication network as a mesh of various fixed and mobile access
Figure 1. The evolving telecommunication network as a mesh of various fixed and mobile access
technologies and core networks.
technologies and core networks.
Since
On thethe appearance
other of smart devices
hand, deployments of newandtechnologies
with the growing demandalways
and services for theprovide
IoT (In-
the inherent possibility of optimizing, modernizing, or merging network layers towardsare
ternet of Things) and machine-to-machine communications (M2M), subscriptions a
growing enormously
converged or ‘flattened’[1,2]. Subscribers
architecture. The are not any longer
convergence only humanpossibilities
and simplification users usingarise
the
network
at different forlayers:
simple at telephone
the equipment voicelevel
calls.(either
Industry,
HW or transportation,
SW) and at the modern
Networkagriculture,
Element
education, medicine, robotics, etc. all require data connections [3–6].
(NE) and network levels. Finally, as shown in this paper, convergence has started even at The User Equipment
(UE,
the either fixed
services level.or mobile)
Several at the end
important of thehave
trends datapaved
links can
the be
waysensors, machines,
for service metering
convergence in
devices, cameras, vehicles, robots, or any other remote-controlled
the past years. Without completeness, a few important milestones are listed as follows: equipment. A massive
rollout of 5G (fifth-generation mobile systems, also called New Radio, NR) systems is al-
• Convergence of fixed and mobile networks (FMC, Fixed–Mobile Convergence);
ready ongoing in several countries to serve these new demands. In Figure 1, 5G core and
• Sunset of earlier Radio Access Technologies (RATs), e.g., 3G systems in Europe and 2G
NR are marked in light blue, and phase-out technologies are marked in gray.
(second-generation) and 3G in America and Asia [3];
On the other hand, deployments of new technologies and services always provide
• Introduction of new RATs, i.e., 4G (fourth-generation), LTE-A (Advanced Long-Term
the inherent possibility of optimizing, modernizing, or merging network layers towards a
Evolution), and 5G [4–7];
•converged
Intensive orresearch
‘flattened’and architecture.
standardization The convergence
of 5G and beyondand and simplification possibilities
future 6G (sixth-generation)
arisemobile
at different
systems and Open RAN (Radio Access Network) solutions [4–6,8,9]; Network
layers: at the equipment level (either HW or SW) and at the
•Element (NE) and network
Access-agnostic solutionslevels. Finally, the
expanding as shown in this
coverage paper, convergence
of various has started
‘trusted’ mobile gener-
evenations
at thewith
services
WiFi (Wireless Fidelity) access, which has traditionally been treatedcon-
level. Several important trends have paved the way for service as
vergence in the [10,11];
‘untrusted’ past years. Without completeness, a few important milestones are listed
•as follows:
Continuous introduction of new protocols and interfaces (e.g., Diameter for Ro/Rf to
• Convergence
replace of fixed
the legacy and
Bi/Bc mobile interfaces)
charging networks (FMC,
[7]; Fixed–Mobile Convergence);
•• Sunset of earlier
Replacement Radiotransmission
of legacy Access Technologies (RATs),
and transport e.g., 3G
solutions systems
and legacy in Europe(e.g.,
protocols and
TDM/PDH/SDH/ATM)
2G (second-generation) and in all
3Gsegments,
in Americaincluding
and Asia User
[3]; Plane (UP), Control Plane
• (CP), management
Introduction of newplane,
RATs,and
i.e.,synchronization [3,12,13];LTE-A (Advanced Long-Term
4G (fourth-generation),
Evolution), and 5G [4–7];
• Intensive research and standardization of 5G and beyond and future 6G (sixth-gen-
eration) mobile systems and Open RAN (Radio Access Network) solutions [4–6,8,9];
• Access-agnostic solutions expanding the coverage of various ‘trusted’ mobile gener-
ations with WiFi (Wireless Fidelity) access, which has traditionally been treated as
‘untrusted’ [10,11];
Signals 2024, 5 758

• Modernization projects targeting ‘all-IP’ networks and Software-Defined Networking

(SDN) [13–16];
• Replacement of earlier ‘non-cloud friendly’ interfaces and protocols and introduction
of Service-Based Architecture (SBA) and service discovery instead of rigid ‘fixed
configurations’ that are used in legacy telecommunications [17];
• Protection of network functions and interfaces to achieve more resilient operation and
high availability (from redundancy methods and anti-affinity rules to distribution in a
geo-redundant Telco cloud) [18,19];
• Cloudification: migrating physical network elements and Physical Network Functions
(PNFs) to Virtualized Network Functions (VNFs) and Cloud-native Network Functions
(CNFs) [8–10,17–24];
• Flexible resource management of cloud-based VNFs and CNFs, scaling, and network
slicing [24–30];
• Continuous capacity expansions and upgrades in both access and core network
domains, introducing new business models, such as private and non-public net-
works [3,5,12,23,31,32];
• Convergence of Data Center and IT (Information Technology) with telecommunica-
tions on HW and SW infrastructure and service layers [18–22,33–35].
After this short introduction, in Section 2, the development of legacy telecommuni-
cation services is reviewed. Section 3 shows replacement options for existing Intelligent
Networks (INs) services. Section 4 discusses the fusion of IT and telecommunication do-
mains, which is illustrated with Nokia TAS. Several Open API and IMS Data Channel use
cases are given. Finally, Section 5 concludes this paper, and useful references are listed.

2. Developing Telecommunication Services—From INAP to CAMEL

In legacy PSTN networks, digitalization of telephone exchanges opened the possibility
of implementing various telephone call-related services. Originally, call-related services
were integrated into the code of the digital exchanges, i.e., in the stored program itself.
In the first 2G and 3G systems, the Mobile Switching Center (MSC) played the role of
the digital telephone exchange. With the introduction of Release 4 networks, the MSS
(MSC Server) took over the function of the MSC in combined 2G/3G networks (Figure 1).
Similarly to the fixed networks, at the beginning of mobile telephony, call-related services
were implemented by the switches too. These services were hardcoded to the business
logic (BL) of the 2G/3G switches across the entire network. With the arrival of Intelligent
Networks, services have been centralized to a dedicated platform [36–39]. The service logic
(SL) was decoupled from the business logic of the telephone exchange into an external
entity: the Service Control Function (SCF). As shown in Figure 2, the SCF had access to the
Service Data Function (SDF), a database that could be managed by the Service Management
Function (SMF). The telephone exchanges and Intelligent Networks were communicating
with each other using the SS7 (Signaling System No. 7) stack.
The telephone exchange can report certain call events (e.g., call initiations, call answers,
and call disconnects) to the SCF platform. So, SCF can instruct the switch on the outcome of
the call, e.g., continue, release, or redirect a call. SCF can initiate user interaction, send addi-
tional charging-related data, and can also control the call duration for prepaid subscribers.
Typical telecommunication service use cases include, for example, the following:
• Prepaid services, where payment precedes the use of the service. The purchased credit
is used to pay for communications services when the service is used. When the credit
is almost fully consumed, then the subscriber is warned by a tone within the call, and
when it is fully consumed, further access is denied by the cellular network or by the
Intelligent Network;
• Interactive voice response menus;
• Sequential alerting of devices of a small office;
• Private numbering plans for enterprises.
Signals 2024, 5 759

In the application layer of the interface between the switch and the SCF, two main al-
ternatives have become widespread. The Intelligent Networks Application Part (INAP) has
been standardized for fixed telephony and later adapted also for mobile networks [36–39].
To avoid incompatibility of different vendor-specific implementations and to address roam-
ing and mobility, the ETSI (European Telecommunications Standards Institute) and 3GPP
(3rd Generation Partnership Project) specified a new service invocation interface for mobile
networks. The Customized Applications for Mobile networks Enhanced Logic (CAMEL)
became standardized by 3GPP and ETSI. The CAMEL Application Part (CAP) has evolved
Signals 2024, 5, FORfrom
PEER REVIEW
the INAP to meet the needs of mobile networks and extended the IN framework to 4

GSM and 3G networks, as shown in Figure 3.

management network
relat ionship t o ot her t o ot her boundary
SMF SDFs
IN service SMAF
cont rol t o ot her
SMF SDFs
bearer
SDF
connect ion SCEF
cont rol

call
t o ot her
unrelat ed SCFs
signalling

int er-
net working
SCF t o ot her
relat ionship SCFs

t o IAFs
SRF
CUSF SSF
SCUAF CCF
t o ot her
CCAF CCFs
Signals 2024, 5, FOR PEER REVIEW 5
Figure
Figure 2. General IN2.architecture
General IN architecture with decoupled
with decoupled business business and logic
and service service logic [36].
[36].

The telephone exchange can report certain call events (e.g., call initiations, call an-
swers, and call disconnects) to the SCF platform. So, SCF can instruct the switch on the
outcome of the call, e.g., continue, release, or redirect a call. SCF can initiate user interac-
tion, send additional charging-related data, and can also control the call duration for pre-
paid subscribers. Typical telecommunication service use cases include, for example, the
following:
• Prepaid services, where payment precedes the use of the service. The purchased
credit is used to pay for communications services when the service is used. When the
credit is almost fully consumed, then the subscriber is warned by a tone within the
call, and when it is fully consumed, further access is denied by the cellular network
or by the Intelligent Network;
• Interactive voice response menus;
• Sequential alerting of devices of a small office;
• Private numbering plans for enterprises.
In the application layer of the interface between the switch and the SCF, two main
alternatives have become widespread. The Intelligent Networks Application Part (INAP)
has been standardized for fixed telephony and later adapted also for mobile networks [36–
39]. To avoid incompatibility of different vendor-specific implementations and to address
roaming and mobility, the ETSI (European Telecommunications Standards Institute) and
3GPP (3rd Generation Partnership Project) specified a new service invocation interface for
mobile networks. The Customized Applications for Mobile networks Enhanced Logic
(CAMEL) became standardized by 3GPP and ETSI. The CAMEL Application Part (CAP)
Figure
Figure 3. 2G/3G
has 3. 2G/3G
mobile
evolved mobile
service
from logicservice
over to
the INAP logic
CAMEL
meetover CAMEL
with
the with
decoupled
needs decoupled
business
of mobile business andextended
and service
networks and service logic
the[36].
logic [36]. IN
framework to GSM and 3G networks, as shown in Figure 3.
The CAMEL framework provided tools for Mobile Network Operators (MNOs) to
define additional features for standard GSM/UMTS (Universal Mobile Telecommunica-
tions System) services. The protocols are described in a series of ETSI technical specifica-
tions: CAMEL specifications have been published in four consecutive phases [40–44]. Each
new phase builds upon the capabilities of the previous one. The standards have been is-
sued first for GSM NSS (Network Switching Subsystems). In fact, the first two phases were
Signals 2024, 5 760

The CAMEL framework provided tools for Mobile Network Operators (MNOs) to
define additional features for standard GSM/UMTS (Universal Mobile Telecommunications
System) services. The protocols are described in a series of ETSI technical specifications:
CAMEL specifications have been published in four consecutive phases [40–44]. Each new
phase builds upon the capabilities of the previous one. The standards have been issued first
for GSM NSS (Network Switching Subsystems). In fact, the first two phases were defined
before 3G networks existed. The standards added IN services to GSM networks, but they
were applicable to 2.5G (2G with Enhanced Data rates for GSM Evolution, EDGE) and 3G
networks later too. Then, CAMEL was extended for UMTS core networks: Phase 3 was
defined for 3GPP Release 99 and Release 4 as a common 2G/3G specification. Phase 4 was
defined as part of 3GPP Release 5. Each CAP phase provides the set of operations and
procedures needed to support the corresponding CAMEL phase requirements, as defined
in the specifications [40–44]. In-line with other GSM specifications, the later phases build
new features on top of the previous phases. Many services could be created using CAMEL.
It has been particularly successful in cases when subscribers were roaming outside their
home network. Good examples are prefix-free dialing, when the dialed number is the same
no matter in which country the call is placed by the subscribers, parallel alerting of multiple
devices, and advanced voicemail services. CAMEL has enabled call-unrelated services too,
for example, for mobility or messaging [45,46].

3. Continuation of Existing in Services and Replacement Possibilities

Nowadays, we are witnessing rapid changes in telecommunications. Some Communi-
cation Service Providers are just introducing Voice over LTE (VoLTE) on an IP Multimedia
Subsystem (IMS) architecture besides their existing 2G and/or 3G networks [3,34,47].
Meanwhile, in several countries, the sunset of 2G and/or 3G networks has already started,
forcing MNOs to provide end-user services purely on an IMS and to shut down their 2G
Signals 2024, 5, FOR PEER REVIEW 6
and/or 3G networks, where previously legacy IN-based services were provided. In both
cases the legacy 2G/3G Intelligent Networks services need continuation for subscribers in
the IMS domain. Figure 4 shows the IN-based service evolution, reflecting the continuation
the continuation
possibilities possibilities
of legacy IN-based of services,
legacy IN-based
and theservices, and the
replacement replacement
possibilities possibili-
to enable the
ties to enableofthe
ramp-down theramp-down of the
service control service
point control
(SCP) point
network (SCP) network elements.
elements.

Alternativestotoprovide
Figure 4. Alternatives provideCSCSdomain
domain services
services in in
thethe IMS
IMS domain
domain (A:(A: continue
continue with
with the the
ex-
isting ININ
existing service, B:B:
service, implement
implementthe service
the natively
service nativelyasasananIMS
IMSAS,
AS,C:C:invoke
invokethe
theservice
serviceover
overAPI).
API).

3.1. CAP/INAP-Based Service Invocation

The seamless continuation of CAP/INAP services for IMS subscribers can be enabled
by the IM-SSF role of the IMS Application Server (IMS AS), which can even be integrated
with the MMTEL/SCC AS (Multimedia Telephony/Service Centralization and Continuity
Application Server) roles (Figure 5) [47–49]. Since IMS anchoring of the subscribers is op-
tional during the call, IN services can be invoked from the 2G/3G domain as well.
 Figure 4. Alternatives to provide CS domain services in the IMS domain (A: continue with the ex-
Signals 2024, 5 isting IN service, B: implement the service natively as an IMS AS, C: invoke the service over API).
761

3.1. CAP/INAP-Based Service Invocation

3.1. CAP/INAP-Based Service Invocation
The seamless continuation of CAP/INAP services for IMS subscribers can be enabled
The seamless continuation of CAP/INAP services for IMS subscribers can be enabled
by the IM-SSF role of the IMS Application Server (IMS AS), which can even be integrated
by the IM-SSF role of the IMS Application Server (IMS AS), which can even be integrated
with the MMTEL/SCC AS (Multimedia
with the MMTEL/SCC Telephony/Service
AS (Multimedia Centralization
Telephony/Service andContinuity
Centralization and Continuity
ApplicationApplication
Server) roles (Figure
Server) 5) [47–49].
roles (Figure Since Since
5) [47–49]. IMS anchoring of the
IMS anchoring subscribers
of the subscribers is
is op-
optional during the call, IN services can be invoked from the 2G/3G domain
tional during the call, IN services can be invoked from the 2G/3G domain as well. as well.

Figure 5. Traditional IN-basedIN-based

Figure 5. Traditional servicesservices
executed by the
executed IM-SSF.
by the IM-SSF.

There are
There are some some drawbacks
drawbacks of thisofsolution,
this solution, as follows:
as follows:
• This approach requires the maintenance of the IN platform, and the service develop-
• This approach ment requires the maintenance
needs telecommunication (SS7)of the INThese
experts. platform, and
products are the service
mature develop-
and may be
ment needseven telecommunication (SS7)
close to the end of their lifeexperts.
cycle; These products are mature and may be
even close to the end
• Although 3GPPof has
their life cycle;
specified the IP Multimedia Service Switching Function (IM-SSF),
• Although it3GPP is not has
delivered by all the
specified IMS IP
core vendors. Therefore,
Multimedia Servicecontinuation
SwitchingofFunction
existing IN(IM-
services has become very challenging in many MNO networks;
SSF), it• is not delivered by all IMS core vendors. Therefore, continuation of existing
CAP/INAP services tend to follow the standard protocol specifications strictly; intro-
IN servicesducing
has become
protocol very challenging
extensions may lead in many MNO networks;
to incompatibility.
• CAP/INAP services tend to follow the standard protocol specifications strictly; intro-
ducing3.2. SIP-Based Service Invocation
protocol extensions may lead to incompatibility.
There are IN vendors where the service logic can be invoked on its legacy CAP/INAP
interfaces from the 2G/3G domain, while it can also be invoked on a SIP-based (Session
3.2. SIP-Based Service Invocation
Initiation Protocol) interface from the IMS domain. It requires both maintenance of the
There are IN vendors
existing where theofservice
IN and development logic can
the SIP-based be invocation.
service invoked on its legacy CAP/INAP
Alternatively, IMS AS vendors may decide
interfaces from the 2G/3G domain, while it can also be invoked to implement replacement services.(Session
on a SIP-based Typi-
cally, such implementations are integrated to MMTEL AS in order to enable strong MMTEL
interworking, assuming a microservice architecture. For example, an integrated MM-
TEL/SCC AS may provide parallel alerting of multiple devices with a single subscription,
with shared MMTEL data for all devices and their terminating SIP sessions controlled by
IN services. Furthermore, an IMS native Selective Ringback Tone service may allow the
calling party to hear a customized ringback tone while the called party is alerted. That
is, instead of the existing ringback tone, the calling party hears a melody or a greeting
specified by the called party while waiting for the receiver to respond to the call. The called
party can select a melody or greeting based on the identity of the calling party.

3.3. API-Based Service Invocation

The API (Application Programming Interface) is a way for two (or more) computer
programs to communicate with each other. The API can be considered also as a type of
SW interface, offering service(s) to other pieces of SW. As overviewed in the next section,
APIs have been already used widespread for a long time in telecommunication networks.
First, APIs have been mainly used for internal CSP purposes, for example, to integrate
customer relationship management into charging procedures. Integrating the Information
Technology platform resources to the telecommunication (simply ‘Telco’) platform of the
CSP has become another typical use case. The use of APIs has improved operational
efficiency and reduced OpEx (Operational Expenditure) [17].
Signals 2024, 5 762

APIs in an IMS AS may be also a valid alternative for IN replacement. In this approach,
a standalone IMS AS or an MMTEL AS may expose network functions to API-based
services, which again can decouple service logic from the IMS, enabling a shorter time
to market. Up to now, the fusion of IT and Telco domains has been very challenging
because they required different technologies and different platforms, and traditionally they
had a different developer base. If Telco networks start using APIs instead of legacy Telco
signaling-based services, then a similar platform can host both Telco and IT services [17,50].
To conclude, APIs can be used not only for IN replacement, but APIs also enable fusion of
services in the Telco and IT domains.

4. Fusion of Telco and IT Services

4.1. Evolution Path of API Services in Telecommunications
A brief overview of Application Programming Interface-based services is given in
this section by reviewing several papers. The selected papers cover the evolution path
of APIs over several years. In the same timeframe, the telecommunication landscape has
been evolving too, starting from legacy 2G/3G to actual 4G/5G and future 6G mobile
systems. In an early paper, dating back to 2001, the authors discussed the possibility of
using Open APIs for mobile networks [51]. In those years, content distribution to mobile
terminals became available through the increased data rates offered by EDGE and WCDMA
(Wideband Code Division Multiple Access) technology [3]. One mobile network vendor
(Ericsson) provided a platform that enabled OEM (Original Equipment Manufacturer)
vendors to develop applications and graphical user interfaces on top of their platform.
This way, mobile phone terminal manufacturers gained the possibility to differentiate their
products from other vendors.
In 2003, Lozinski [52] provided an overview of the Parlay/OSA (Open Services Ar-
chitecture) API, an open interface that was created by a consortium of 65 IT and telecom
industry companies. Parlay/OSA APIs have been used to develop services for both mobile
data and fixed networks. Furthermore, the APIs targeted services for the next-generation
converged networks based on the Internet Protocol (IP), as expected at that time. Among
others, the main advantages have been using technology-independent APIs built on open
standards. Developers could use multiple programming languages (e.g., C, C++, or Java).
New value-added services became available, which promised revenue for MNOs and
CSPs. Various domains were targeted by the new services, e.g., mobile location, terminal
capability, connection management, and charging.
In 2008, it was shown by [53] how the convergence of traditional telephone networks
with the Internet started benefiting from the convenient user interface and relatively big
storage size of personal computers, which the usual telephone devices did not have at that
time. SOAP- and REST (Representational State Transfer)-based APIs were shown in that
paper for building call and messaging services in which callers could control their own
calls. It was shown that REST is a good alternative to SOAP when developing Open APIs.
Several services are detailed, such as third-party invitations for mini-conferencing, click to
dial, call recording, short and voice messaging, and playing audio on demand during a call.
Yrjo and Rushil discussed already in 2011 how cloud computing and IT created new
possibilities towards ‘Open Telco’ by changing the legacy telecommunication landscape [12].
Their paper underlined the importance of Open APIs in this evolution. Two steps are dis-
cussed: how operators can consider Open Telco and Networking as a Service (NaaS)
concepts. On the one hand, network operators could use Open APIs to provide network as-
sets to developers for accelerating application development and creating a new application
ecosystem. On the other hand, operators could start to use all kinds of cloud computing
services in their own infrastructure, including Infrastructure (IaaS), Platform (PaaS) and
Software as a Service (SaaS). The IaaS layer offers networking, computation, and storage
services provided by the cloud. The PaaS layer has close links to Business and Operations
Support Systems (BSS/OSS). The SaaS layer matches the service delivery platforms.
Signals 2024, 5 763

In another paper dating back to 2011, Liu et al. [34] concluded that the opening and
sharing of Internet and telecom services was a must to satisfy subscribers. The authors
stated that according to the long tail theory, 20% of the telecom services satisfied 80% of
the subscribers. However, subscribers’ demands were not fully aligned with the operators’
services. To overcome these limitations, IMS could provide multimedia services over
Internet Protocol (using REST APIs or RPC-based methods, e.g., SOAP). Even though
IMS and Internet services have several common features, they differ in some fundamental
points, such as access control or business models. To expose telecom abilities to the Internet
world, the Telco TM Initiative was born with the emergence of the web. Telco 2.0 offered
new telecom business models, and WIMS 2.0 (Web 2.0 & IMS) was proposed as a solution
to enable convergence between the mobile world and the web. The exposure of IMS
capabilities to the outer world was by Open Web APIs, as described in that paper.
In article [1], the authors presented a set of APIs used as part of machine-to-machine
communication as a REST-based web service. With the help of these APIs, e.g., it was
possible to send SMS/e-mail/Twitter messages to devices registered in the M2M network,
showing the early convergence of Telco and IT services already in 2012. As specific use
cases, the authors mentioned smart home applications, whereby the subscribers received
notifications on their phones about the temperature and light conditions in their homes or
when an unauthorized person was intruding, based on inputs from motion sensors.
In 2015, Grabowski et al. [54] reported on two Hackathon events, where new
telecommunication-related applications were implemented using a set of Open APIs,
combined with datasets provided by Open Data APIs. With the help of APIs provided by a
mobile network operator, it was possible to send and receive SMS, MMS, and USSD (Un-
structured Supplementary Service Data) notifications, initiate calls, and manage location-,
charging-, and SIM card-related data as a REST web service. In addition, detailed maps of
several cities (including public transport networks and major institutions, such as hospitals,
etc.) could be accessed via an Open Data API. At these two events, an impressive number
of more than 100 applications was developed, which also demonstrated the attractiveness
of telecommunications services. The Hackathon organizers measured thousands of API
calls during the use of the developed applications. The authors also concluded that it is
very beneficial to work with interdisciplinary teams during API development, in such a
way combining the knowledge of telecommunications and, e.g., the real estate market.
In 2019, the authors of [55] outlined a testing framework used for 5G performance and
use case testing purposes. In the 5G-VINNI project, it was important to utilize the Open
API to access certain elements in the network infrastructure, and this method was also
recommended to manage the life cycle of network slices. The project mentioned specific
APIs discussed in later articles [56,57].
According to [8,17,58], the Open API concept plays an important role in 5G core
networks. The services of different new user groups (called verticals) can be integrated into
mobile networks with standard RESTful API calls via the Northbound Interface provided
by the Network Exposure Function (NEF). The authors of [4] outlined that the efficient
programmability and dynamic shaping of 5G and 6G networks (e.g., management of
network slices) are also possible with the invocation of API services, emphasizing the
principles of a Software-Defined Network and Network Function Virtualization (NFV).
A recent paper from 2021 focused on the security aspect of 5G core networks, empha-
sizing that the APIs themselves must be protected [59]. This is primarily true in relation
to Network Exposure Function, where it is necessary to consider the level of accessibility
to the operator’s network provided to a third-party through an API [8,17]. Access has
three levels: passive, semi-active, and fully active. At the fully active level, the API de-
veloper is authorized to install new network elements within the given network slices.
The article also discussed the security risks related to Network Virtualization and Edge
Computing; in the latter, the Multi-Access Edge Computing (MEC) cloud-based IT service
can also use the Open API, and the authors warn that security risks must also be avoided
Signals 2024, 5 764

at the edge of the network [59–61]. API security considerations are also crucial in mobile
banking applications, whose services are more and more widespread worldwide [31].
In 2022, Kao and Young [6] noted that every generation of wireless systems has its
own representative industries and companies. Network equipment vendors and operators
were at center stage in the 1G era. Feature phones and the corresponding supply chains like
Qualcomm and Nokia became dominant in the 2G era. Smartphones and their suppliers
like Apple started to rise in the 3G era. And the OTT applications riding the mobile
network reaped most benefit in the 4G era. Currently in the 5G era, there are also numerous
opportunities open for new players. In general, 5G introduces many IT technologies,
and that helps openness and network disaggregation for preventing vendor lock-in (i.e.,
locking in one vendor’s proprietary solutions). In this way, more players can join the
supply chain to increase flexibility and diversification. More specifically, 5G involves
the combination of Communication Technology, IT (Information Technology) and OT
(Operation Technology). Therefore, in addition to the communication network itself, plus all
possible new applications, 5G brings many new industry opportunities [2–6]. The industrial
cooperation aspects of Open APIs have been discussed for years [8,48]. Simultaneously,
there has been a significant focus on standardization issues too [1,16,62–64].
The reviewed papers are summarized in Table 1. As shown, the selected API related
papers cover various domains of IT and telecommunications. The most intensively dis-
cussed topics within the list of the reviewed papers are 4G, 5G, and cloud core. IT and
Telco convergence is clearly observed. Notably, in the majority of the papers, various new
business models, resource management issues, and security and standardization aspects
received significant focus too.

Table 1. The various Telco and IT areas discussed in the reviewed works.

Telco and IT Domains References

2G, GSM [2,3,6–8,10,11,33–35,45–48,51–54]
3G, UMTS [2,3,6–8,10,11,14,17,22,33–35,45–54,59]
4G, LTE [2–12,14,17,20,22,23,32,33,35,47,49,50,56,59,61,62,65–67]
5G, NR [2–12,14,15,17,19,22–28,32,35,55–61,63,66–68]
6G [3,4,12,24,61,63]
Open RAN [6,8,9,61]
SDN [2,8,13–15,19,22–25,55,57,61]
M2M, IoT [1,2,4,5,12,15,17,24,32,55,59,61,63]
IMS, core network [1–3,8,10,11,14,17–19,21,23,27,28,33–35,45–49,58,59,61,62,65–69]
Cloud, VNF, CNF [2,3,5,8,10,11,16–18,20–26,28–30,33–35,55–61,63,65,67]
Resource management,
[2,4,8,11,16–18,20–22,24–27,29,30,56–58]
scaling, slicing
Security [2,5,8,10,11,14,15,17,22,27,31,55,57,59,61,63]
IN, INAP, CAMEL [7,10,11,20,23,45,46,48,52,53,63,64]
Parlay / OSA, SOAP [10,11,16,23,34,45,46,52–54,62–64,67]
API, REST API, Open API [1,4,9–12,14–17,20,24,25,30,31,34,35,50–59,61,63–67]
Data Channel (DC) [49,65–69]
Standards, standardization [2,7–11,22,31,36–44,48,49,54–56,59,61–69]
(New) business models,
[2,4–6,8,16,19,20,22,28,31,32,51,52,54,55,64,65]
opportunities

4.2. Nokia TAS Open APIs

A robust, easy to use set of APIs is the key to unlocking innovation and exciting
developers. Nokia’s API-enabled 5G core product functions can be exposed securely to
the public domain over the Nokia Network Exposure Function (NEF), which also acts as
the API Gateway. The Nokia Telephony Application Server (NTAS) provides OMA-based
RESTful Network Open APIs as future-proof functionality. The API-based solution of
Nokia TAS can be seen in Figure 6.
 A robust, easy to use set of APIs is the key to unlocking innovation and exciting de-
velopers. Nokia’s API-enabled 5G core product functions can be exposed securely to the
public domain over the Nokia Network Exposure Function (NEF), which also acts as the
API Gateway. The Nokia Telephony Application Server (NTAS) provides OMA-based
Signals 2024, 5
RESTful Network Open APIs as future-proof functionality. The API-based solution of765
Nokia TAS can be seen in Figure 6.

Figure
Figure6. 6.
Application programming
Application programminginterface-based
interface-basedsolution
solutionininNokia
NokiaTelephony
TelephonyApplication
Application Server.
Server.
The API functionality is enabled for 2G, 3G, 4G, 5G, VoWiFi, and fixed networks;
Signals 2024, 5, FOR PEER REVIEW The itAPI
hence, functionality
is seamlessly is enabled
available for 2G, 3G,
for operators with4G, 5G, VoWiFi,
Fixed–Mobile and fixed networks;
Convergence efforts. It11
is
hence, it iskey
also the seamlessly available
enabler of for operators
the Telco-IT fusion, aswith Fixed–Mobile
can be Convergence
seen in Figure 7. efforts. It
is also the key enabler of the Telco-IT fusion, as can be seen in Figure 7.

Figure 7.
Figure Fusionof
7. Fusion ofIT
ITand
andtelco
telcoworlds.
worlds.

Benefits of the API Framework

Benefits of the API Framework
With their solution principles, the API-based services provide benefits, such as the following:
With their solution principles, the API-based services provide benefits, such as the
• Faster time to market is possible for complex services compared to the traditional
following:
approaches; quick development is feasible with a large third-party developer base,
• Faster time to market is possible for complex services compared to the traditional
using feature-rich APIs and libraries (they also unlock the Internet of Things and
approaches;
social media); quick development is feasible with a large third-party developer base,
• using
Openingfeature-rich APIs and
the IT domain libraries
for Telco (they also
can allow IMS unlock
servicesthe Internetmore
to become of Things and so-
sophisticated.
cial media);
The services are delivered with orchestrated service execution in a cloud-native fashion;
• Opening
serverlessthe IT domainand
technologies for service
Telco canmesh allow
modeIMSareservices to become more sophisti-
also feasible;
cated. The services are delivered with orchestrated
• The 3GPP IMS AS interworking is ensured on Southbound Interfaces; service execution in a cloud-na-
• A rich catalog of Open and RESTful Northbound Interfaces isare
tive fashion; serverless technologies and service mesh mode also feasible;
available. For instance,
• The 3GPP IMS
the Nokia TASAShasinterworking
detailed Open is ensured
API Swaggeron Southbound Interfaces;
Documentation for third-party de-
• A rich catalog
velopers. of Open
Swagger andused
is also RESTful Northbound
by 3GPP Interfaces
to describe the 5Gisinterfaces.
available. The
For instance,
Swagger
the Nokia TAS has detailed Open API Swagger Documentation for
definition text file describes the complete interface. Both sides of the interfaces third-party devel-
can
opers. Swagger is also used by 3GPP to describe the 5G interfaces.
be tested easily based on the Swagger definition. Public testing tools for functionalThe Swagger def-
inition
and load texttests
file are
describes the complete
available, interface.
and it enables Both sidesAPI
collaborative of the interfaces
design can be
(via GitHub).
tested easilydocumentation
Automatic based on the Swagger
and code definition.
generation Public testing
are also tools for
possible. Allfunctional
in all, this and
API
load
yieldstests areefforts
lower available, andoperators
for the it enablesandcollaborative API design (via GitHub). Auto-
Nokia as well;
• matic documentation
The OpEx saving is alsoandimportant
code generation are alsoreuse,
with software possible. All in lower
including all, this API yields
maintenance
lower efforts for the operators and Nokia as well;
costs [17].
• The OpEx saving is also important with software reuse, including lower maintenance
costs [17].

4.3. Nokia TAS Open API Use Cases

With the usage of Telco APIs, the traditional telecommunication service domain can
easily be enriched with IT API-based services, as shown in Figure 8.
Signals 2024, 5 766

4.3. Nokia TAS Open API Use Cases

Signals 2024, 5, FOR PEER REVIEW 12
With the usage of Telco APIs, the traditional telecommunication service domain can
easily be enriched with IT API-based services, as shown in Figure 8.

Figure 8. Use cases after IT–Telco fusions.

Figure 8. Use cases after IT–Telco fusions.

Besides the
Besides examples shown
the examples shown in in Figure
Figure 8, 8, hereby
hereby some some examples
examples are listed of
are listed of what
what
kind of
kind of possibilities
possibilities areare provided
provided for for the
the operators
operators utilizing
utilizing various
various APIs
APIs (when
(when changing
changing
from Telco-only
from Telco-only services):
services):
•• Call Direction
Call Direction API: API: This
This suspends
suspends the the call and triggers
call and triggers the
the application
application to take the
to take the
appropriate route decision or change the calling line ID. The operator can develop
applications such as the following:
o Nuisance
# Nuisance callcall
blocking,
blocking, which
which recognizes
recognizesand andblocks
blocksrobocalls
robocallsor or telemarketing
telemarketing
calls in the
calls network
in the network according
according to call blocking
to call blocking application
application settings;
settings;
o Blocking
# Blocking all all
calls to children
calls to children during
during school
schooltime;time;
o Mashing
# Mashing upup connected
connected carcar
data
datatotochange
changethe thecalling
callingpattern
patternwhile
whiledriving
driving (i.e.,
(i.e.,
callcall
blocking
blocking with a personal
with a personal exception
exception list);
list);
o Calendar-based
# Calendar-based callcall
forwarding
forwarding that
thatextends
extendsend endusers’
users’reachability
reachability conditions
with a personal/office calendar application
with a personal/office calendar application (e.g., Google Calendar); (e.g., Google Calendar);
o Caller
# Caller ID enrichment
ID enrichment withwith the name
the name of theofcalling
the calling
party,party,
which which can enable
can enable com-
companies
panies to reachtoout reach out to
to their their customers
customers with anwith an increased
increased successsuccess
rate; rate;
#
o Posting
Posting automatic
automatic social
social mediaadvertisements
media advertisementsby bythe
theapplication
application forfor personal
benefits
benefits (e.g.,
(e.g., when whenuseruser calls
calls a restaurant
a restaurant for for booking,
booking, the the
APIAPI service
service can can
ad-
advertise the restaurant on a personal Facebook page
vertise the restaurant on a personal Facebook page in return for a discount); in return for a discount);
# Temporary
o Temporary callcall ID that
ID that enables
enables twotwo parties
parties to callto each
call each
otherother without
without sharingsharing
their
their personal phone numbers and therefore
personal phone numbers and therefore increases communication privacy;increases communication privacy;
#
o Basic Basic parental/elder
parental/elder carecare
is is alsopossible
also possibleby bynotifying
notifying parents/caregivers
parents/caregivers about about
calls
calls from from children/older
children/older people.
people.
•• Call
Call Event Notification API:
Event Notification This notifies
API: This notifies call
call events
events without
without having
having the
the possibility
possibility of
of
influencing the call. The operators may develop services like the following:
influencing the call. The operators may develop services like the following:
#
o Integration
Integration with
with Over-the-Top
Over-the-Top (OTT)
(OTT) phone
phone applications;
applications; for for example,
example, based
based on
on the network notification of an incoming call, the service may
the network notification of an incoming call, the service may send a push notifi- send a push
notification
cation to the
to the OTT OTT application
application that canthat can include
include the user’sthe user’s
previousprevious personal
personal notes
notes on
on the caller; the caller;
#
o It can
It can alsoalso help
help to build
to build a smart
a smart home:
home: e.g.,e.g., blinking
blinking a lamp
a lamp couldcould notify
notify the
the sub-
subscriber about incoming
scriber about incoming calls; calls;
o Notification of missed calls to IT/social media services (e.g., callback reminder to
Google Calendar or a Twitter personal message) to increase the notification space
of the end user;
o Building a personal server-based call history database that can be accessed on a
web portal.
Signals 2024, 5 767

# Notification of missed calls to IT/social media services (e.g., callback reminder

to Google Calendar or a Twitter personal message) to increase the notification
space of the end user;
# Building a personal server-based call history database that can be accessed on
a web portal.
• Call Control API: Third-party call control functions, which can initiate a call and
manage call participants (e.g., add or drop participants), such as the following:
# Service center call management: monitoring of agent availabilities and provid-
ing customer callback when an agent becomes available for a call;
# Ordered call conference: A service initiated or a scheduled call conference
between two or more parties.
• SMS API: This sends an SMS to a user and notifies service logic on a received SMS,
including the following:
# Two-factor authentication with SMS;
# SMS notification of a missed incoming call;
# SMS televoting;
# SMS chatbot (ChatGPT [70] service reservation and support center);
# SMS-based advertisement.

4.4. IMS Data Channel

The 3GPP has recently introduced a new concept that enables the usage of a data
channel in IMS (IP Multimedia Subsystem) call sessions to enrich the end user call ex-
perience [49]. It enhances the native dialer application of mobile devices with browser
capabilities, which could receive HTML and JavaScript content over the IMS Data Channel,
which is yet another channel/media type besides regular voice and video. It allows MNOs
to provide in-call web applications without the need to install OTT apps from the Google
Play Store or the Apple App Store. An IMS Data Channel (DC) can be established between
the device and the network, between the device and an application server, or between
devices, and can be used for sending or receiving any kind of data (for example the HTML
page itself, Augmented Reality- or Virtual Reality-related data, database queries, or content
sharing). Different applications may have different bandwidth requirements; therefore, the
guaranteed bandwidth of an IMS Data Channel may be controlled by the network.
Like API-based services, IMS Data Channel applications may also be easily integrated
with IT services. However, they provide different services. API-based services are more
telecommunications-oriented: At certain call events, they can affect routing and charging,
and they may implement interaction with the end user using network announcements.
On the other hand, an IMS Data Channel extends the phone capabilities with a browser
that can deliver interactive solutions to the end user during calls without any effect on
the routing or charging but opening the door towards augmented communication [65–69].
Therefore API-based services are device-agnostic, while an IMS Data Channel requires
special capabilities from the device(s).
The GSMA proposes an initial list of use cases, which can be extended with even more
exciting ones [66,67], including the following:
• A visual menu for the support center;
• Call queue information;
• An interactive catalog;
• Content sharing;
• Online gaming;
• Personalized targeted advertisements;
• Real-time speech transcription and translation [35].
Signals 2024, 5 768

5. Conclusions
Telecommunication networks have gone through a drastic evolution whereby the
business logic and the service logic have been separated, as we can see through the Nokia
Signals 2024, 5, FOR PEER REVIEW 14
TAS API service examples. The originally developed INAP and CAMEL services are
reaching their end of life and are being replaced with native services implemented as an
IMS AS or with API-based services. Moreover, the IN replacement, API-based services,
also enable faster time to market thanks to a bigger developer
developer base,
base, and
and the
the non-Telco-
non-Telco-
specific service environment unlocks the possibility of easily integrating the Telco and IT
domains. However,
However, future
future trends
trends are moving to device- and access-agnostic
access-agnostic directions,
directions,
where services are orchestrated as shown in Figure 9. Future services may be connected
IT/IoT services
to IT/IoT services and
and are
are getting
getting more
more and
and more interactive, as we illustrated with IMS
DC-related examples.

Figure 9. Convergence of telco services.

Author Contributions:
Author Contributions: Conceptualization,
Conceptualization, M.Á.T.
M.Á.T. and
and Z.S.;
Z.S.; methodology,
methodology, M.Á.T.,
M.Á.T., Z.S.
Z.S. and
and A.H.;
A.H.;
writing—original draft
writing—original draft preparation,
preparation, M.Á.T.,
M.Á.T., Z.S.
Z.S. and
and A.H.;
A.H.; visualization,
visualization, Z.S.
Z.S. and
and A.H.;
A.H.; supervision,
supervision,
A.H. and
A.H. and G.J.
G.J.;All
Allauthors
authorshave
haveread
readand
andagreed
agreedto tothe
thepublished
publishedversion
versionofofthe
themanuscript.
manuscript.
Funding: This
Funding: This research received no
research received no external
external funding.
funding.
Data Availability
Data Availability Statement:
Statement: NoNo new
new data
data were
were created
created or
or analyzed
analyzed in
in this
this study. Data sharing
study. Data sharing is
is
not applicable to this article.
not applicable to this article.
Acknowledgments: The
Acknowledgments: Theauthors
authors acknowledge
acknowledge the valuable
the valuable discussions
discussions with Gyányi,
with Zoltán Zoltán Michelle
Gyányi,
Michelle Hein, Alexander Milinski, Attila Molnár, Katja Silvennoinen, and Norbert Andrási
Hein, Alexander Milinski, Attila Molnár, Katja Silvennoinen, and Norbert Andrási (at Nokia CNS), (at
Nokia CNS), and with Ákos Leiter, Csaba Rotter and József Varga (at Nokia Bell Labs), and their
and with Ákos Leiter, Csaba Rotter and József Varga (at Nokia Bell Labs), and their useful comments.
useful comments.
Conflicts of Interest: The authors declare no conflicts of interest.
Conflicts of Interest: The authors declare no conflicts of interest.
Abbreviations
Abbreviations
API Application Programming Interface
API Application Programming Interface
AS Application Server
AS
ATM Application Server
Asynchronous Transfer Mode
ATM
BL Asynchronous
Business Logic Transfer Mode
BL
BTS Business
Base LogicStation
Transceiver
BTS
CAMEL Base Transceiver
Customized Station
Applications for Mobile network Enhanced Logic
CAP
CAMEL CAMEL Application
Customized Part
Applications for Mobile network Enhanced Logic
CAP CAMEL Application Part
CNF Cloud-native Network Function
CS Circuit Switched
CSCF Call Session Control Function
CSP Communication Service Provider
Signals 2024, 5 769

CNF Cloud-native Network Function

CS Circuit Switched
CSCF Call Session Control Function
CSP Communication Service Provider
CP Control Plane
DC Data Channel
EDGE Enhanced Data rates for GSM Evolution
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
FMC Fixed–Mobile Convergence
GSM Global System for Mobile Communications
HLR Home Location Register
HSS Home Subscriber Server
HW hardware
IaaS Infrastructure as a Service
IMS IP Multimedia Subsystem
IN Intelligent Network
INAP Intelligent Network Application Protocol
IM-SSF IP Multimedia Service Switching Function
IP Internet Protocol
IT Information Technology
IoT Internet of Things
LTE Long-Term Evolution
LTE-A Advanced LTE
MEC Multi-Access Edge Computing
MNO Mobile Network Operator
MMS Multimedia Messaging Service
MMTEL Multimedia Telephony
MSC Mobile Switching Center
MSS MSC Server
M2M Machine-to-Machine
NaaS Networking as a Service
NE Network Element
NR New Radio
NSS Network Switching Subsystem
NW network
OEM Original Equipment Manufacturer
OMA Open Mobile Alliance
OpEx Operational Expenditure
OSA Open Services Architecture
OT Operation Technology
OTT Over-the-Top
PaaS Platform as a Service
PDH Plesiochronous Digital Hierarchy
POTS Plain Old Telephone Service
PNF Physical Network Function
PS Packet Switched
PSTN Public Switched Telephone Networks
REST Representational State Transfer
RAN Radio Access Network
RAT Radio Access Technology
SaaS Software as a Service
SBA Service-Based Architecture
SBC Session Border Controller
SCC AS Service Centralization and Continuity Application Server
SCF Service Control Function
SCP Service Control Point
Signals 2024, 5 770

SDF Service Data Function

SDH Synchronous Digital Hierarchy
SDN Software-Defined Network
SEE Service Execution Environment
SIP Session Initiation Protocol
SL Service Logic
SMF Service Management Function
SMS Short Message Services
SMSC SMS Center
SS7 Signaling System No.7
SW software
TAS Telephony (or Telecommunications) Application Server
TDM Time-Division Multiplexing
UE User Equipment
UMTS Universal Mobile Telecommunications System
UP User Plane
USSD Unstructured Supplementary Service Data
VNF Virtualized Network Function
VoIP Voice over IP
VoLTE Voice over LTE
VoWiFi Voice over WiFi
WCDMA Wideband Code Division Multiple Access
WiFi Wireless Fidelity
1G First-Generation (early analog mobile systems)
2G Second-Generation (mobile systems), also known as GSM
2.5G 2G systems with EDGE
3G Third Generation (mobile systems), also known as UMTS
3GPP Third-Generation Partnership Project
4G Fourth Generation (mobile systems), also known as LTE
5G Fifth Generation (mobile systems), also known as NR
6G Sixth Generation (mobile systems)

References
1. Elmangoush, A.; Magedanz, T.; Blotny, A.; Blum, N. Design of RESTful APIs for M2M services. In Proceedings of the 16th IEEE
International Conference on Intelligence in Next Generation Networks, ICIN, Berlin, Germany, 8–11 October 2012. [CrossRef]
2. Varga, P.; Pető, J.; Frankó, A.; Balla, D.; Haja, D.; Janky, F.; Soós, G.; Ficzere, D.; Maliosz, M.; Toka, L. 5G support for Industrial IoT
Applications–Challenges, Solutions, and Research Gaps. Sensors 2020, 20, 828. [CrossRef] [PubMed]
3. Hilt, A. Gbit Radios for the Mobile Anyhaul. In Proceedings of the 25th Seminar on Radio Communications, SRK, Ljubljana,
Slovenia, 2–4 February 2022; pp. 505–515.
4. Petrov, I.; Janevski, T. 5G mobile technologies and early 6G viewpoints. Eur. J. Eng. Technol. Res. 2020, 5, 1240–1246. [CrossRef]
5. Apruzzese, M.; Bruni, M.E.; Musso, S.; Perboli, G. 5G and Companion Technologies as a Boost in New Business Models for
Logistics and Supply Chain. Sustainability 2023, 15, 11846. [CrossRef]
6. Kao, C.-C.; Young, H.-C. Opportunities, Challenges, and Solutions in the 5G Era. IEICE Trans. Commun. 2022, E105, 1291–1298.
[CrossRef]
7. ETSI TS 129 272 V17.2.0 (2022-05); Technical Specification, Universal Mobile Telecommunications System (UMTS), LTE, 5G.,
Evolved Packet System (EPS), Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) Related Interfaces
Based on Diameter Protocol (3GPP TS 29.272 Version 17.2.0 Release 16). ETSI: Sophia Antipolis, France, 2001. Available
online: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1690 (accessed on
14 July 2024).
8. NGMN Alliance. Cloud Native Enabling Future Telco Platforms; Version: 5.2; NGMN Alliance e.V: Düsseldorf, Germany, 2021.
9. Mlinar, T.; Batagelj, B. Open RAN-What does an open architecture of the radio access network enable. J. Electr. Eng. Comput. Sci.
2023, 90, 265–271. (In Slovenian)
10. Nokia. Nokia TAS Product Description (VNF). Release 24.7, Nokia Telecom Application Server (VNF); Issue 21-1, DN09247738; Nokia:
Espoo, Finland, 2024.
11. Nokia. Nokia TAS Product Description (CNF). Release 23.11, Nokia Telecom Application Server (CNF); Issue 14-1, DN1000051709;
Nokia: Espoo, Finland, 2024.
12. Hilt, A.; Varga, J.; Járó, G. Availability-Aware E-band Wireless Extension of Fiber-Access. In Proceedings of the IEEE/IFIP
Network Operations and Management Symposium, NOMS, Budapest, Hungary, 25–29 April 2022; pp. 1–5. [CrossRef]
Signals 2024, 5 771

13. Chalk, Z.; Fojtu, J. Migration of TDM services from ATM to IP environment using ALE OmniPCX Enterprise technology. In
Proceedings of the IEEE International Conference on Military Technologies, ICMT, Brno, Czech Republic, 23–26 May 2023; pp. 1–6.
[CrossRef]
14. Leiter, Á.; Salah, M.S.; Pap, L.; Bokor, L. Survey on PMIPv6-based Mobility Management Architectures for Software-Defined
Networking. Infocommunications J. 2022, 14, 2–18. [CrossRef]
15. Ali, J.; Lee, G.; Roh, B.; Ryu, D.K.; Park, G. Software-Defined Networking Approaches for Link Failure Recovery: A Survey.
Sustainability 2020, 12, 4255. [CrossRef]
16. Lane, K. The API-First Transformation; Postman: San Francisco, CA, USA, 2022; ISBN 979-8-9869518-0-5.
17. NOKIA. Telco Network Exposure, The Route to 5G Core Open APIs and beyond; White Paper, SR2003042473EN; Nokia: Espoo, Finland,
2020; pp. 1–13.
18. Hilt, A.; Bakos, I.; Járó, G. Reliability and Availability Modelling of Telecommunication Servers on Cloud, paper Tu.A6.1.
In Proceedings of the 17th IEEE International Conference on Transparent Optical Networks, ICTON, Budapest, Hungary,
5–9 July 2015; pp. 1–4. [CrossRef]
19. Varga, J.; Hilt, A.; Rotter, C.; Járó, G. Providing Ultra-Reliable Low Latency Services for 5G with Unattended Datacenters. In
Proceedings of the 11th IEEE/IET International Symposium on Communication Systems, Networks & Digital Signal Processing,
CSNDSP, Budapest, Hungary, 18–20 July 2018; pp. 1–4. [CrossRef]
20. Yrjo, R.; Rushil, D. Cloud Computing in Mobile Networks–Case MVNO. In Proceedings of the 15th IEEE International Conference
on Intelligence in Next Generation Networks, ICIN, Berlin, Germany, 4–7 October 2011; pp. 253–258. [CrossRef]
21. Járó, G.; Hilt, A.; Nagy, L.; Tündik, Á.M.; Varga, J. Evolution towards Telco-Cloud: Reflections on Dimensioning, Availability and
Operability. In Proceedings of the 42nd IEEE Telecommunications and Signal Processing Conference, TSP, Budapest, Hungary,
1–3 July 2019; pp. 1–8. [CrossRef]
22. GSMA. Migration from Physical to Virtual Network Functions–Best Practices and Lessons Learned, Version 0.1; GSM Association:
London, UK, 2018.
23. Hilt, A.; Varga, J.; Járó, G. Capacity Expansion and Modernization of Core Network Elements Running on ATCA Platform. In
Proceedings of the IEEE/IFIP Network Management and Operations Symposium, NOMS, Budapest, Hungary, 20–24 April 2020;
pp. 1–5. [CrossRef]
24. Rotter, C. Performance Analysis of Cloud Resource Management Algorithms. Ph.D. Thesis, Budapest University of Technology
and Economics, Budapest, Hungary, 2023. Available online: http://hdl.handle.net/10890/41022 (accessed on 30 October 2024).
25. Esmaeily, A.; Kralevska, K. Orchestrating Isolated Network Slices in 5G Networks. Electronics 2024, 13, 1548. [CrossRef]
26. Rotter, C.; Van Do, T. A Queueing Model for Threshold-based Scaling of UPF Instances in 5G Core. IEEE Access 2021, 9,
81443–81453. [CrossRef]
27. Dayot, R.V.J.; Ra, I.H.; Kim, H.J. A Deep Contextual Bandit-Based End-to-End Slice Provisioning Approach for Efficient Allocation
of 5G Network Resources. Network 2022, 2, 370–388. [CrossRef]
28. Varga, J.; Hilt, A.; Bíró, J.; Rotter, C.; Járó, G. Reducing operational costs of ultra-reliable low latency services in 5G. Infocommunica-
tions J. 2018, 10, 37–45. [CrossRef]
29. Mebarkia, K.; Zsóka, Z. QoS Impacts of Slice Traffic Limitation. Infocommunications J. 2021, 13, 24–32. [CrossRef]
30. Simon, C.; Maliosz, M.; Máté, M.; Balla, D.; Toma, K. Sidecar based resource estimation method for virtualized environments.
Infocommunications J. 2020, 12, 4–11. [CrossRef]
31. Oh, S.; Chung, G.; Cho, K. New Sustainable Fintech Business Models Created by Open Application Programming Interface
Technology: A Case Study of Korea’s Open Banking Application Programming Interface Platform. Sustainability 2024, 16, 7187.
[CrossRef]
32. Soós, G.; Ficzere, D.; Seres, T.; Veress, S.; Németh, I. Business opportunities and evaluation of non-public 5G cellular networks–A
survey. Infocommunications J. 2020, 12, 31–38. [CrossRef]
33. Hilt, A.; Járó, G. Licensing Options for Virtual Network Functions in Telecommunications Cloud Environment. In Proceedings
of the 11th IEEE/IET International Symposium on Communication Systems, Networks & Digital Signal Processing, CSNDSP,
Budapest, Hungary, 18–20 July 2018; pp. 1–6. [CrossRef]
34. Liu, L.; Haihong, E.; Ke, X. A Cloud Telecom Open Platform for Converging IMS and Web 2.0. In Proceedings of the 13th
International Conference on Enterprise Information Systems, ICEIS, Beijing, China, 8–11 June 2011; pp. 545–549. [CrossRef]
35. Tündik, M.Á.; Hilt, A.; Nagy, L.; Bóta, G.; Luukkanen, K. Access-independent Cloud-based Real-Time Translation Service for
Voice Calls in Mobile Networks. In Proceedings of the 11th IEEE/IET International Symposium on Communication Systems,
Networks & Digital Signal Processing, CSNDSP, Budapest, Hungary, 18–20 July 2018; pp. 1–6. [CrossRef]
36. ETSI EN 301 931-1 V1.1.2 (2001-09); European Standard (Telecommunications Series), Intelligent Network (IN), Intelligent
Network Capability Set 3 (CS3), Intelligent Network Application Protocol (INAP), Protocol Specification, Part 1: Common
Aspects. ETSI: Sophia Antipolis, France, 2001. Available online: https://www.etsi.org/deliver/etsi_en/301900_301999/30193101
/01.01.02_60/en_30193101v010102p.pdf (accessed on 14 July 2024).
37. ETSI EN 301 931-2, V1.1.2 (2001-09); European Standard (Telecommunications Series), Intelligent Network (IN), Intelligent
Network Capability Set 3 (CS3), Intelligent Network Application Protocol (INAP), Protocol Specification, Part 2: SCF-SSF
Interface. ETSI: Sophia Antipolis, France, 2001. Available online: https://www.etsi.org/deliver/etsi_en/301900_301999/301931
02/01.01.02_60/en_30193102v010102p.pdf (accessed on 14 July 2024).
Signals 2024, 5 772

38. ETSI EN 301 931-3, V1.1.2 (2001-09); European Standard (Telecommunications Series), Intelligent Network (IN), Intelligent
Network Capability Set 3 (CS3), Intelligent Network Application Protocol (INAP), Protocol Specification, Part 3: SCF-SRF
Interface. ETSI: Sophia Antipolis, France, 2001. Available online: https://www.etsi.org/deliver/etsi_en/301900_301999/301931
03/01.01.02_60/en_30193103v010102p.pdf (accessed on 14 July 2024).
39. ETSI EN 301 931-4, V1.1.2 (2001-09); European Standard (Telecommunications Series), Intelligent Network (IN), Intelligent
Network Capability Set 3 (CS3), Intelligent Network Application Protocol (INAP), Protocol Specification, Part 4: SDLs for SCF-SSF
Interface. ETSI: Sophia Antipolis, France, 2001. Available online: https://www.etsi.org/deliver/etsi_en/301900_301999/301931
04/01.01.02_60/en_30193104v010102p.pdf (accessed on 14 July 2024).
40. 3GPP TS 22.078 V17.0.0 (2022-03); Technical Specification, Customised Applications for Mobile Network Enhanced Logic
(CAMEL), Service Description, Stage 1, Release 17. ETSI: Sophia Antipolis, France, 2001. Available online: https://portal.3gpp.
org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=587 (accessed on 14 July 2024).
41. 3GPP TS 23.078 V17.0.0 (2022-03); Technical Specification, Customised Applications for Mobile Network Enhanced Logic (CAMEL)
Phase 4, Stage 2, Release 17. ETSI: Sophia Antipolis, France, 2001. Available online: https://portal.3gpp.org/desktopmodules/
Specifications/SpecificationDetails.aspx?specificationId=766 (accessed on 14 July 2024).
42. 3GPP TS 29.078 V17.0.0 (2022-03); Technical Specification, Customised Applications for Mobile Network Enhanced Logic
(CAMEL) Phase 4, CAMEL Application Part (CAP) Specification, Release 17. ETSI: Sophia Antipolis, France, 2001. Available
online: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1597 (accessed on
14 July 2024).
43. 3GPP TS 23.278 V17.0.0 (2022-03); Technical Specification, Customised Applications for Mobile Network Enhanced Logic
(CAMEL) Phase 4, Stage 2, IM CN Interworking, Release 17. ETSI: Sophia Antipolis, France, 2001. Available online: https:
//portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=836 (accessed on 14 July 2024).
44. 3GPP TS 29.278; Technical Specification, Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4, CAMEL
Application Part (CAP) specification for IP Multimedia Subsystems (IMS). ETSI: Sophia Antipolis, France, 2001. Available
online: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1696 (accessed on
14 July 2024).
45. Jánosi, L.; Molnár, A.; Pásztor, A. Method, Apparatus and Computer Program Product for Relaying CAMEL Related
Messages in a Telecommunications Network. European Patent No. EP2353268 (B1), 7 September 2016. Available online:
https://worldwide.espacenet.com/publicationDetails/originalDocument?FT=D&date=20160907&DB=&locale=en_EP&CC=
EP&NR=2353268B1&KC=B1&ND=4 (accessed on 11 September 2024).
46. Bokor, F.; Szabó, Z. Method and computer program product for handling mobility management event notifications in a
telecommunications network. International Patent Publication No. WO2010/127695 A1, 11 November 2010. Available online:
https://patents.google.com/patent/WO2010127695A1 (accessed on 11 September 2024).
47. Jánosi, L.; Pásztor, A.; Molnár, A.; Jankó, A.; Csatári, G.; Szemán, A. Service Continuity in Centralized Service Network System.
US Patent Publication No. US 2016/150497 A1, 26 May 2016. Available online: https://patents.google.com/patent/US201601504
97A1 (accessed on 11 September 2024).
48. GSMA. IMS Service Centralization and Continuity Guidelines. GSM Association Official Document IR.64, Version 14.0; GSM Association:
London, UK, 2016.
49. 3GPP TS 26.114 V18.7.0 (2024-06); 3rd Generation Partnership Project, Technical Specification Group, Services and System
Aspects, IP Multimedia Subsystem (IMS), Multimedia Telephony, Media Handling and Interaction, Release 18. ETSI: Sophia
Antipolis, France, 2001. Available online: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?
specificationId=1404 (accessed on 13 September 2024).
50. CAMARA. The Telco Global API Alliance. APIs Enabling Seamless Access to Telco Network Capabilities, August 2024. Available
online: https://camaraproject.org/ (accessed on 30 October 2024).
51. Ekudden, E.; Horn, U.; Melander, M.; Olin, J. On-demand mobile media–A rich service experience for mobile users. Ericsson Rev.
2001, 78, 168–177.
52. Lozinski, Z. Parlay/OSA—A New Way to Create Wireless Services. In Proceedings of the IEC Mobile Wireless Data, 1 June 2003.
pp. 1–14. Available online: https://citeseerx.ist.psu.edu/document?&doi=58a9012498f0537b312d3841fef31f2da7c446e6 (accessed
on 6 November 2024).
53. Jung, S.; Kang, M.-K.; Choi, D.-W. Call/messaging open API for telecommunication services. In Proceedings of the 10th IEEE
International Conference on Advanced Communication Technology, ICACT, Gangwon, Republic of Korea, 17–20 February 2008;
pp. 1139–1143. [CrossRef]
54. Grabowski, S.; Grzenda, M.; Legierski, J. The adoption of open data and open API telecommunication functions by software
developers. In Proceedings of the International Conference on Business Information Systems, Poznań, Poland, 24–26 June 2015;
Springer: Cham, Switzerland, 2015. [CrossRef]
55. Mahmood, K.; Grønsund, P.; Gavras, A.; Weiss, M.B.; Warren, D.; Tranoris, C.; Cattoni, A.F.; Muschamp, P. Design of 5G
end-to-end facility for performance evaluation and use case trials. In Proceedings of the 2nd IEEE 5G World Forum, 5GWF,
Dresden, Germany, 30 September–2 October 2019; pp. 341–346. [CrossRef]
Signals 2024, 5 773

56. Ordonez-Lucena, J.; Tranoris, C.; Rodrigues, J. Modeling Network Slice as a Service in a Multi-Vendor 5G Experimentation
Ecosystem. In Proceedings of the IEEE International Conference on Communications Workshops, ICC, Online, 7–11 June 2020;
pp. 1–6. [CrossRef]
57. Ordonez-Lucena, J.; Tranoris, C.; Rodrigues, J.; Contreras, L.M. Cross-Domain Slice Orchestration for Advanced Vertical Trials
in a Multi-Vendor 5G Facility. In Proceedings of the IEEE European Conference on Networks and Communications, EuCNC,
Dubrovnik, Croatia, 15–18 June 2020; pp. 40–45. [CrossRef]
58. Mayer, G. RESTful APIs for the 5G Service Based Architecture. J. ICT Stand. 2018, 6, 101–116. [CrossRef]
59. Settembre, M. A 5G Core Network Challenge: Combining Flexibility and Security. In Proceedings of the IEEE International
Annual Conference, AEIT, Milan, Italy, 4–8 October 2021; pp. 1–6. [CrossRef]
60. Leiter, Á.; Lami, E.; Bokor, L. Towards Cross-domain Mobility Management in the Edge. In Proceedings of the 20th ACM
International Symposium on Mobility Management and Wireless Access, MobiWac’22, Montreal, QB, Canada, 24–28 October
2022; pp. 119–122. [CrossRef]
61. IEEE INGR. Edge Services. International Network Generations Roadmap, 2023 Editions; IEEE Future Networks: Baltimore, MD, USA, 2023.
62. Mulligan, C.E.A. Open API Standardization for the NGN Platform. IEEE Commun. Mag. 2009, 47, 108–113. [CrossRef]
63. Sneps-Sneppe, M.; Namiot, D. On Open Gateway from GSMA–Is It a Revolutionary or Too Little and Too Late Deal? In
Proceedings of the 33rd Conference of Open Innovations Association, FRUCT, Zilina, Slovakia, 24–26 May 2023; pp. 283–289.
[CrossRef]
64. Jakobsson, S.; Mulligan, C.; Unmehopa, M. Research and reality: The evolution of Open Network API standards. In Proceedings
of the 2012 IEEE International Conference on Communications, ICC, Ottawa, ON, Canada, 10–15 June 2012; pp. 6901–6905.
[CrossRef]
65. Nokia. Monetizing 5G Voice, Enriched Calling with IMS Data Channel; eBook; Nokia: Espoo, Finland, 2023; Available online:
https://www.nokia.com/networks/core-networks/voice-over-5g-vo5g-core/ (accessed on 13 September 2024).
66. GSMA. PRD NG.134 IMS Data Channel. Version 3.0, June 2024; GSM Association: London, UK, 2018; pp. 1–50. Available online:
https://www.gsma.com/newsroom/wp-content/uploads//NG.134-v3.0-1.pdf (accessed on 13 September 2024).
67. GSMA. IMS Data Channel White Paper. Version 1.0, December 2021; GSM Association: London, UK, 2018; pp. 1–105. Available
online: https://www.gsma.com/newsroom/wp-content/uploads//NG.129-v1.0-1.pdf (accessed on 13 September 2024).
68. ETSI TS 124 186 V18.0.0 (2024-05); 5G.; IMS Data Channel Applications, Protocol Specification (3GPP TS 24.186 Version 18.0.0
Release 18). ETSI: Sophia Antipolis, France, 2001. Available online: https://www.etsi.org/deliver/etsi_ts/124100_124199/1241
86/18.00.00_60/ts_124186v180000p.pdf (accessed on 13 September 2024).
69. Inoue, Y.; Suzuki, R. Standardization Trends in Real-time Communications at 3GPP. NTT Tech. Rev. 2023, 21, 34–38. [CrossRef]
70. OpenAI. ChatGPT. Available online: https://chat.openai.com (accessed on 13 September 2024).

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.