Revolution of IT in Telecommunications

The role of Software in Telecommunications Giancarlo Sabajno g.sabajno@tiscali.it

The old networks Up to few decades ago Information Technology hadn t entered the Telecommunication world yet. The switches were only HW based and IT devices didn t need to communicate with each other As IT developed, it began to be employed in the design of the network nodes, in order to take advantage of the enormous benefits that software could provide, e.g.: extended the capabilities of the switches (both the performance and the service number and complexity) enabled simpler, cheaper and quicker service extension, normally without any need for hardware modifications, thus speeding up and simplifying the productive process provided for quicker and simpler error and malfunction correction extended the flexibility of the Network Elements, e.g.: easier customization process better adaptability to the different network contexts easier paramenter configurability enabled the implementation of more effective redundancy techniques (e.g. micro-synchronous duplication) thus increasing the system reliability

Adoption of IT technology in TLC Computers began being gradually adopted as the basic elements upon which the network nodes were designed, and the switches became complex ensembles of cooperating microprocessors Languages, real time operating systems, software structures (e.g. the automatas , based on SDL) started to spread out, optimized for the real time event management Dedicated I/O devices, handled via interrupt routines and often working with DMA, began to be employed, especially for protocol handling (e.g. for the signaling SS7 protocols) A dramatic change happened both in the manufacturer companies and the telecom operators, since the know how requested for technical people moved towards the computer world (even if with characteristics that were deeply different from those of the commercial computers)

Employment of IT at the network level The adoption of IT in the TLC world grew even more extensive as the requested services started to become more and more complex Some new services were too complex to be effecively provided by each individual node, and some required service logic and data to be shared among all the nodes of the network The network architecture started to include specialized, centralized servers to provide such services The Intelligent Network (IN) was developed complex services are realized by means of pure software applications in a dedicated node (SCP: Service Control Point) SCP is invoked by any switch of the network after recognizing that the user has requested an IN service

Example: Green Number SCE Customer control SMS Service Manager Swithced Network SCP SDP SCP: Service Control Point SDP: Service Data Point SCE: Service Creation Environment SMS: Service Management System SSP: Service Switching Point 2 3 1 SS7 Network SSP SSP 4 5 1): The calling user dials the green number 2): The SSP function triggers a query to SCP for number translation 3): SCP, after realizing it was a green number service request, answers back with the translated number 4): The switch forwards the call request to the destination switch 5): The called telephone rings

A few examples of IN services Televoting Number Portability Green Number Reverse Charging VPN Calling card Personal Number Universal Number Call distribution (location / time based - proportional - ) . . .

IN Flexibility IN is a clear example of how the great flexibility of SW made possible the provision of services otherwise too complex to be realized Adding new services or modifying existing ones only requires to act at the SCP/SDP level; at the switch level just adding triggers in SSP is enough In the SCE (Service Creation Environment) dedicated SW applications provides for easy, quick, flexible and user friendly inplementation of the service logic Dedicated software applications also provide for easy and user friendly service management (management of Users profile, service Data Base, etc.)

Computers evolution towards communication Meanwhile also the computers began evolving from stand-alone machines to systems open to the communication with the external world, especially after PCs started to spread out (one example for all: the e-mail service) This thrusted a big effort that developed in two directions: 1) Integration in the telephone switches, especially the private ones (PABXs), of devices communication capabilities for the data equipment, besides the voice ones; and features providing 2) The birth of the data networks, both local (LAN, IBM SNA, etc.) and geographical (e.g. the Italian Itapac public packet network)

Data communication through the data networks (1) A big acceleration occurred in the definition process of the computer communication standards, both for geographical networks (e.g. X.25) and the LANs The ISO-OSI seven layer model was defined. It is a clear example of the ultimate importance got by software development to implement data communication functions Developing the entire stack in the endpoint host computers was quite a complicate matter and it was typically developed by specialized SW companies which also helped integrating it within the customers machines The SW characteristics in the network nodes (which handled only the three lowest levels) were significantly different, since the needs for processing speed and real time process management were predominant

Data communication through the data networks (2) Further improvement brought to the diffusion of more efficient protocols (Frame switching, frame relaying, ATM, ) The continuous technological evolution enabled the realization of more and more powerful, fast, cheap and reliable nodes; as a consequence: Final replacement of X.25 with the more efficient connectionless Internet Protocol (IP) Abandonment of the traditional Network and Transport protocols of the OSI stack in favor of TCP/UDP over IP with the Application Layer directly above The long process of evolution of the data networks, in particular the geographical ones, brought to the birth of the Internet, based on the TCP/IP protocols

Convergence between voice and data services In the same way as the telephone networks evolved towards including data communication, the data networks began including voice and, in a later step, video communication (the Internet is an example of this). This brought to the definition of the VoIP protocols VoIP was initially conceived just to transport voice packets through the Internet, without providing any of the actual typical telephone services (e.g. Call Forwarding on busy / on no answer, Call Park, etc.) The full provision of the telephone services will be accomplished later as the NGN networks will provide the real ToIP (Telephony over IP)

Factors that triggered voice/data convergence The quick technological development of the network nodes and the consequent cost reduction and improvement in terms of speed, reliability and bandwidith The predominance of the packet switching technique over circuit switching even for the voice and video services as one of the consequences of the technological improvement. This brought to a situation where all the information types shared the same switching technique The bigger and bigger demand for new services by the users

Further networks evolution (1) Technological development Increase of the demand of new and more sophisticated services by the users Urgency of the providers to conquer market areas with the provision of new and better services requiring further technological improvement

Further networks evolution (2) The consequences were: Possibility to integrate the different types of media to provide multimedia services due to the capability of the IP network to transport all types of information The availability of a much wider bandwidth than needed by the traditional phone calls and the possibility to flexibly allocate it depending on the service needs Independence from the user s device (fixed or cellular phone, smartphone, tablet, PC, ) Loss of the traditional distinction between voice and data networks: only one type of network (packet switched, IP based) for all stream types: voice, video, data.

Further networks evolution (3) The transport and switching networks, IP based, became more and more service independent ( Networkneutrality ) The provision of all the services (including, in almost all the implementations, the classic telephone call as a particular case) moved to a higher layer where the service logic was performed by Application Servers that used the transport and switching network just as an enabler (bandwidth and QoS provider) Multimedia services began to spread out, integrated with users data such as Presence information Birth of the NGN (New Generation Network)

NGN Architecture (1) Application Layer . . . SIP SSW IAD IP SG SBC MG TDM legacy networks (PSTN / PLMN) IP phone IP SBC IP phone IAD IP IP phone IAD IAD Legacy phone SSW: Softswitch SBC: Session Boarder Controller SG: Signaling Gateway MG: Media Gateway IAD: Integrated Access Device Legacy phones

NGN Architecture (2) All the calls within the NGN are managed by the Softswitch that: acts as network controller regulates the users access to the network doesn t provide any service directly: it examines the service that the user has invoked by means of an INVITE message depending on the requested service, it selects the appropriate Application Server and delivers the user s request to it The Application Servers are triggered by the softswitch on the basis of the service requested by the user run the service logic command, if needed, the establishment of new sessions with other users devices by sending the relative commands to the Softswitch Different Application Servers may be involved simultaneously in the same service (e.g. an IP Centrex user that invokes also a videoconference)

NGN Architecture (3) Adding new services can simply be accomplished by employing further Application Servers in the Service Layer: no new releases (or patches) anymore required in the Network Elements (mainly the telephone switches) Interoperability tests between a new Application Server and the Softswitch are always necessary before activating a new service in the network AS are realized by SW applications developed upon state-of-the- art computer HW and SW (Operating Systems, Data Bases, Graphical Interfaces, Communication platforms, etc.)

Example: NGN Conference service Conference Application Server WEB Server XML JDBC, OCI SCE Application Servers IP Media Server HTML, SOAP Service & System Administr. SIP RTP SSW IP

Example: NGN IP-Centrex service IP- Centrex Application Server WEB Server XML Application Servers Element Manager SCE User DB IP Service & System Administr. SIP SSW SIP SIP Enterprise 1 RTP Enterprise 1 IP Enterprise 2 Enterprise 2 Enterprise 3

Example: NGN IP-Centrex / Conference service IP-Centrex AS Conference AS Application Servers Application Servers Media Server User DB SSW Enterprise 1 IP Enterprise 2 Enterprise 2 Enterprise 1 Enterprise 3 SIP messages RTP flow

Examples of traditional services provided by existing NGN implementations Telephone and video calls Multiple Ringing MRBT (Multimedia Ring Back Tone) Unified Messaging Voice / video mailing Multimedia conferencing Presence oriented services Telepresence IP-Centrex IVR applications Fixed-Mobile Convergence (VCC: Voice Call Continuity) Content sharing Virtual switchboard Multiparty interactive games IPTV Pre / Postpaid calling cards Mass Calling Televoting . . .

NGN : Application Layer Both HW (server class, number of servers, number of processors per server, memory size, HD space, etc.) and SW (e.g. in terms of number of required third party SW licensees) are dimensioned through an engineering process according to the estimated load (e.g. the number of users and the estimated access ratio) Normally the HW platform is modular so that system upgrades can easily be accomplished by adding new elements (e.g. new servers, new CPUs, ); replacing them with more performing ones is needed only for big upgrades The HW platform is always redunded: the high availability configuration (typically 2 X N or N + 1) guarantees: service continuity even in the presence of faults upgrades or release changes without any service interruption

NGN: Characteristics summarization Possibility to access any service in an uniform mode, regardless of the user s device type Network neutrality: the switching / transport network is totally independent from the service; it is just a serviceenabling platform Multimedia services provided by allocating the needed bandwidth, with the Quality of Service (QoS) on a per service request basis Vendor independence: Telecom Operators not bound to any particular provider anymore Change in the way how new services are developed and deployed: New services no more exclusively dependent on specific requests by the Telecom Operators No new release (or patch) anymore required in the Network Elements (mainly the telephone switches) for the addition of a new service

IMS (1) IMS (IP Multimedia Subsystem) is the 3GPP architectural standardization evolution for the NGN networks It is a set of specifications for an unified service architecture It defines a complete framework for enabling the convergence of voice, video, and data communications over an IP-based infrastructure using SIP (Session Initiation Protocol) Provides interoperability with any network, both legacy and new generation, thus granting access to any user regardless of the network he/she is connected to It is independent of the user s device (fixed or mobile telephone, smartphone, PC, Tablet; etc.) and the access technology (DSL, Ethernet, GPRS, WCDMA, etc.) Every IP terminal working with SIP can access the IMS services Legacy terminals, connected to legacy networks, can still access IMS services through gateway functions

IMS (2) Rigorous distinction between the lower layers (Access / Transport and Control), still under the competence of the TLC manufacturers, and the Service layer, mainly prerogative of the IT companies: The Access/Transport layer is based on IP protocol; SIP (Session Initiation Protocol) is used as signaling protocol for service requests and call routing The Control layer contains the main users Data Base (HSS: Home Subscriber Server) and the CSCF functions (Call Session Control Functions) which are responsible for analyzing the users service requests and determining which Application Server will be in charge of managing the requested service The Service layer includes all the Application Servers providing all the services to the users.

Simplified IMS Architecture Application Layer SIP-AS CSE OSA-AS OSA API CAP SIP IM-SSF OSA-SCS Control Layer CSCF S-CSCF I-CSCF BGCF MGCF SGW HSS P-CSCF MRFC PSTN / PLMN MRFP MGW IP network Access / Transport Layer

IMS: the Service Layer AS interact with the control layer by means of SIP protocol Legacy servers working with different interfaces can interact with the Control layer by means of protocol conversion function (OSA-SCS) Services provided by customized applications for mobile networks using Camel can be provided to IMS users by means of the IM-SSF function

Manufacturer competence splitting Coherently with the IMS architecture, a revolutionary scenario occurred in the TLC world also as far as the role of the main actors is concerned: The traditional network manufacturers are more and more confined within the Switching and Transport Layer The Service Layer is realized by pure software applications running on commercial servers and has become almost entirely prerogative of specialized IT companies (OTT: Over The Top) Architectural modularity allows for integration of systems by different vendors within the same solution, thus achieving vendor independence

Service independence from the network Due to the nework neutrality, different network architectures can support OTT services: IMS is not the only architecture feasible to it Most of the current implementations of many new services have been deployed simply using the Internet as switching and transport network, i.e. without any control / responsibility, from any Telecom operator, such as: Skype Whatsapp Facebook Music / TV content delivery Cloud computing IoT (Internet of Things): Smart grids, Smart home, Smart cities, Smart Enterprise, . . . . . .

Actors role change Change in the role of TLC Operators: from Communication Providers to Digitallife s service enablers The business of the services has moved from the Telecom Operators to the OTT world The Networkneutrality has triggered the development of a huge number of new applications that with the old architectures were simply inconceivable Many services aren t even TLC ones, but use the communication network just as a means to create a new smartworld that includes: The house The vehicles The buildings The companies The cities The transportation systems The utilities . . .

Voice and messaging services Monthly active users (MLN) 1,600 1,400 1,200 1,000 Facebook Whatsapp 800 Skype Twitter 600 TLC Operators 400 200 0 1Q 2012 2Q 2012 3Q 2012 4Q 2012 1Q 2013 2Q 2013 3Q 2013 4Q 2013 1Q 2014 2Q 2014 3Q 2014 4Q 2014

Video services: number of users (MLN) 45.0 40.0 35.0 30.0 Netflix USA 25.0 Netflix outside USA AT&T 20.0 Verizon Deutsche Telekom 15.0 10.0 5.0 0.0 1Q 2012 2Q 2012 3Q 2012 4Q 2012 1Q 2013 2Q 2013 3Q 2013 4Q 2013 1Q 2014 2Q 2014 3Q 2014 4Q 2014

Fortune 500 classification (in terms of capitalization) 1996 2015 General Motors Ford Exxon Wal Mart AT&T IBM Apple (725 Billion $) Google (380 B$) Microsoft (335 B$) Facebook (230 B$) Verizon (198 B$) Amazon (173 B$) AT&T (170 B$)

IMS: Service integration (1) Despite most new OTT services being deployed on the Internet, studies and debates are on progress about the opportunity for Telecom Operators to integrate them in an IMS like architecture to take advantage of a number of benefits such as: Service availability QoS (Internet is based on simple besteffort strategy) Negotiable Service Level Agreement (SLA) Authentication Uniform charging procedure Integrability between services by different providers Possibility forthe services to benefit of some common ones (e.g. Presence , Group Management, . . .) made available by IMS . . .

IMS: Service integration (2) The ability of IMS to provide access to any user regardless from: The device type and technology The network the user is connected to makes it fit to integrate similar services by different providers, such as IOT, characterized by: great variety of access (Wi-Fi, Bluetooth, ) connected to different networks (G5, LTE, traditional IP, ) Service integration requires standardization, not completely accomplished yet: IMS can represent a strong push for speeding up the standardization process Cloud Computing integration Current implementations realized as standalone clouds Big problem still mainly represented by lack of data presentaion uniformity Strong push towards clouds integration for: Resource optimization, especially in case of critical conditions Possibility for the users to select and change providers in order to better meet their business target

IOT integration in an IMS architecture Application Layer IOT Application Servers . . . . . . Control Layer CSCF S-CSCF I-CSCF BGCF MGCF SGW HSS P-CSCF MRFC IOT area IOT area IAD IP IP G5 IOT area TDM legacy networks (PSTN / PLMN) IOT area IOT area IOT area

Application Servers Main characteristics Must allow quick development and deployment of new services Must provide quick service customization XML based languages Voice XML CCXML . . . Should provide the customers with control possibilities over their preference settings WEB interfaces IVR CPL (XML based Call Processing Language) . . .

New network requirements Need to support the deployment of more and more new services at an ever growing rate still remaining service independent (need to minimize service dependence upon network constraints) both technological (e.g. G5) and traffic volume handling capability improvements Many highly demanding services in terms of network resources and performance (processing and storing capability) that can stress the network capacity (e.g. cloud computing, big data, . . .) Service impact on the network traffic not always predictable - High data traffic variability Weakness points continuously changing (sometimes even on a day/time basis) need for continuous upgrades or configuration changes Need to react as quickly as possible to traffic peaks, congestions, faults, etc. (theoretically in real time) control policies even more critical than before need for traffic surveillance and

Network complexity So far, reacting to those requirements has meant the adoption of an ever growing number of Network Elements, with different functions, by different providers (sometimes even for the same features), with different behaviors and different management capabilities, with consequent: Enormous grow of the network complexity High costs of HW and SW release updating High maintenance costs (many different maintenance procedures, big maintenance and problem solving organizations, . . .) Complex and expensive spare parts management Highly complex network management procedures Fault management (detection, localization and trouble ticketing) Configuration management (different configuration data, procedures, commands) NEs by different providers often present heterogeneous configuration data which makes hard having an uniform view of the overall network configuration (e.g. routing data) Traffic management (especially real time): Different types of measurements to monitor traffic conditions Different types of traffic control commands allowed High operational costs and low efficiency

Consequent new network needs Elasticity / flexibility Capability to move network resources where / when they are needed to cope with: Deployment of new services Users number increase Critical traffic situations Prompt adaptability to new requirements without the need to deploy new HW (especially new HW types) Reduction of the network complexity (less HW types and SW releases) Scalability Cheaper and quicker introduction of new services (better time to market) Better and more uniform management procedures Network Softwarization

Network Softwarization Extension of the software flexibility to the Network and the Network Elements: So far OTT services had been the climax of a long process within the TLC world through which SW gained a more and more predominant role up to the point where the services have become pure SW applications running on commercial state-of-the-art HW and Operating Systems Only the transport and switching network nodes had remained based on dedicated HW running specific, proprietary SW Now even the Network and the individual Network Elements become entities whose behavior and features are SW applications centrally managed Main areas: Software Defined Networking (SDN) Network Function Virtualization (NFV)

SDN: Software Defined Networking Based on the separation and centralization of the Control Plane, where the rules about traffic routing are defined, from the Transport Plane, that in the Network Elements handles the traffic flow Any decision about traffic routing is made by the centralized Control without any more need, for the Network Elements, to exchange control data among themselves Centralized control provides a global network view, instead of an on per individual NE basis Transport plane virtualization allows for managing the network as a whole, without caring about individual vendor-specific protocols, data format and even semantic management data Central controller s northbound APIs allow either network managers or external applications to perform flow and traffic management

SDN: benefits Easier and quicker realization of the modifications to the network configuration needed to support the introduction of new services or the increased number of users; Quick activation of the routing rules modifications due to critical situations (service degradation trends, bottlenecks, etc.) e.g. detected by performance management systems through off-line analysis of statistical traffic measurements; Real time modifications of the routing rules in front of critical situations (traffic peaks, congestions, physical resource failures, etc.) such as those detected by traffic surveillance systems No more need for the routers to exchange control data between each other to determine the routing paths No more need for the routers to implement any loop prevention policy

NFV: Network Function Virtualization NFV is a virtualization process of the network equipment Network nodes features are no longer performed by specialized HW equipment, but by SW applications running on standard, general purpose, state-of-the-are HW and Operating Systems Node functions are defined as Virtualized Network Functions (VNF) which consist of ensembles of buildingblocks connected to each other, running on one or more Virtual Machines (VM) VMs represent an abstraction level of the physical HW infrastructure obtained by a Hypervisor function Network flexibility and reliability by means of virtualization (moving VNFs among different physical servers and using the network resources regardless of their physical location) Possibility to quickly re-define the network architecture to meet changing requirements as well as to react to failures and traffic congestions

NFV Reference model . . . VNF VNF VNF VNF VM . . . VM VM VM VM HYPERVISOR Computing Storage Networking Physical Hardware

ETSI NFV Reference Architecture ETSI has been active in the NFV standardization process since 2012 through the ETSI ISG NFV More than 290 Telecom and IT companies joined ISG NFV activities, among the others: AT&T British Telecom Century LInk China Mobile Colt Deutsche Telekom KDDI NTT Orange Telecom Italia Telefonica de Espa a Telstra Verizon

ETSI NFV reference architecture By Telecom Italia

NFV standard architecture (1) Includes three domains: 1) Virtual Network Functions (VNF); it includes: all the VNFs; different VNFs can be chained to provide a complex service VNF Element Mangers (EM); each EM performs the usual management functions over the VNF it is associated with 2) VNF Infrastructure (VNFI); it includes: the physical environment where the VNFs run, i.e. the physical computing, storage and network HW The computing, storage and network virtualized HW and SW obtained from the physical ones through a virtualization layer

NFV standard architecture (2) 3) Management and Orchestration (MANO): provides the network service management over the virtualized infrastructure. It includes: Virtualized Infrastructure Manager (VIM): Allocates the resources needed to run the VNFs Collects the infrastructure performance and fault indications and notifies them to the relevant management systems VNF Manager (VNFM): manages the entire life-cycle of a VNF (instance, scaling, modification and termination) Orchestrator: provides for Network service life-cycle management (instance, scaling, modification and termination) Orchestration of the available resources in the infrastructure through one or more VIMs, according to the actual resource availability