The role of Software in Telecommunications

The role of Softwarein Telecommunications

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) • allowed for 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 • … • allowed for 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 ensambles 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

Intelligent Network (IN) • In the IN architecture complex services are realized in a dedicated node (SCP: Service Control Point) by means of pure software applications • To exploit the required service, SCP queries SDP (Service Data Point) to get user’s related information (e.g. his/her profile) and invoice information • SCP is invoked by any switch of the network (through the SSP: Service Switching Point function) after recognizing that the user has requested an IN service • SCP performs the service logic and provides the switch with commands relative to how the call is to be managed

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 required to act at the SCP/SDP level; at the switch level just adding triggers in SSP was enough • In the SCE (Service Creation Environment) dedicated SW applications provided for easy, quick, flexible and user friendly inplementation of the service logic • User friendly software applications also provided 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: • Integration in the telephone switches of devices and features providing communication capabilities for the data equipment, besides the voice ones; • 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 telephone switches (1) • The most important role in the integration within the same switching devices of different types of service and equipment was played by the PABXs, and in particular those based on the ISDN standards (ISPBXs) • The ISDN specifications were developed with the goal of integrating voice and data services through one network interface • Access of IT devices to the telephone switches was realized by means of “Terminal Adaptors” (TAs) that presented the same interface to the switch as the telephone sets • Protocol converters were also available as pools of resources to cope with protocol differences between the communicating devices • Access to the external networks (e.g. the public packet ones) was realized through the development of centralized interfaces, e.g. • Modem pools to communicate thorugh the external telephne network • PAD (Packet Assembler Disassembler) to access external packet networks • SNA emulators to access the IBM SNA networks • …

Data communication through the telephone switches (2) Data communication interface boards required a particular type of SW to be developed: • Real time management requirements were very strong • Typically written in structured low level languages for optimizing the execution time and the memory use • Finite state machines (e.g. SDL) were frequently used for protocol management • Often dedicated chips, interrupt driven, were used, able to autonomously handling the lower level parts of the data link protocols (e.g. LAPB, LAPD, etc.) thus relieving the CPU from the most time critical tasks • DMA was also used as well for data unit buffers management in conjunction with the transmitting/receiving devices

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 model was defined. • It is a clear example of the ultimate importance got by software development to implement data communication functions • The SW characteristics were quite different between the network nodes (which handled only the three lowest levels) where the needs for processing speed and real time process management were predominant, and the endpoint host computers where the communication packages needed to be integrated in the host environment normally based on high level operating systems and languages • Developing the entire stack was quite a complicate matter and it was typically developed by specialized SW companies which also helped integrating it within the customers’ machines

Data communication through the data networks (2) • Further improvement brought to the diffusion of more efficent protocols (Frame switching, frame relaying, ATM, …) • The continuous technological evolution allowed for 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 OSI stack in favor of TCP/UDP 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 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 bandwdith • The predominance of the packet switching technique over circuit switching even for the voice services (and for the video ones) 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, images.

Further networks evolution (3) The transport and switching networks, IP based, became more and more service independent The provision of all the services (including, even though not in all the implementations, the classic telephone call as a particular case) moved to a higher layer that used the transport and switching network just as a 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)

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

NGN • 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 asks also for a videoconference)

Manufacturer competence splitting Coherently with the NGN 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 • Architectural modularity allows for integration of systems by different vendors within the same solution, thus achieving vendor independence

NGN : Application Layer (1) • Adding new services can simply be accomplished by employing further Application Servers in the Sevice Layer • Interoperability tests between a new Applications 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.)

NGN : Application Layer (1) • Both SW (e.g. in terms of number of required third party SW licensees) and HW (server class, number of servers, number of processors per server, memory size, HD space, etc.) 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, …) or replacing them with more performing ones • The HW platform is always redunded in high availability configuration in order to guarantee service continuity even in the presence of faults • System redundancy allows for upgrades or release changes without any service interruption

NGN : Application Layer (2) • Two configurations are most used (mainly depending on the number of servers the system is made of): • in a fully duplicated configuration (2 X N) each server is duplicated and the two servers of each couple work in load sharing; should one server fail, the remaining one takes all the functionality, since it is dimensioned to manage the network load alone; 2 X N redundancy is most used when the system is made of servers specialized to run different applications which can even be dimensioned in different ways; • N + 1 configuration is most used when the system consists of N identical servers, all sharing the same applications, whose number only depends on load considerations; a further server is added to the configuration in order to grant the simultaneous presence of N active servers even in case one fails • Communication links and network interface devices are always redunded as well

NGN: examples of services • IP-Centrex • IVR applications • Fixed-Mobile Convergence (VCC: Voice Call Continuity) • VoicePAD / Web-VoicePad • Content sharing • Switchboard • Multiparty interactive games • Domotics • IPTV • Pre / Postpaid calling cards • Mass Calling • Televoting • . . . • Telephone calls • Multiple Ringing • MRBT (Multimedia Ring Back Tone) • Messaging • Voice SMS • Unified Messaging • Voice / video mailing • Multimedia conferencing • Presence oriented services (e.g. conferencing) • Telepresence

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

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 • 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 • Is independent of the user’s device (fixed or mobile telephone, smartphone, PC, Tablet; etc.) regardless of access technology (DSL, Ethernet, GPRS, WCDMA, etc.) • Every IP terminal working with SIP (Session Initiation Protocol) 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 based on IP protocol; SIP (Session Initiation Protocol) is used as “signaling” protocol to ask for service requests and call routing • The Control layer which 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, that includes all the Application Servers providing all the services to the users.

Simplified IMS Architecture Application Layer OSA-AS SIP-AS CSE OSA API CAP SIP OSA-SCS IM-SSF Control Layer CSCF S-CSCF HSS I-CSCF BGCF MGCF SGW 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 • The AS’ perform as Originating / Terminating User Agents, Proxy Servers or Back-to-back User Agents

Application ServersMain 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) • . . .

Management Systems

Management Systems • Management is of crucial importance in all the TLC networks • No node, equipment, service or application is never deployed in a TLC network without the guarantee that it can be properly managed • Management is performed by dedicated systems: the OSS (Operation Support Systems) • OSS are the means through which operators perform such activities as: • monitor the way how the network is behaving, the provided QoS, its traffic handling capabilities, its faults and the way how they affect the services, etc. • collect statistical performance data to identify critical points or as support to network upgrade policies • react to critical situations like traffic congestions, serious faults, configuration errors, etc. • set the configuration of the network nodes and check the current one • deploy and configure the services • perform customer management • collect accounting information and provide billing data • . . .

Management Systems • OSS functionalities are normally placed at different levels • Network Element level (Element Managers) • Network Level • Service Level • Business Level • The main management areas of the Network Element and the Network management levels are the “FCAPS” ones, as specified by the ISO TMN Model: • Fault • Configuration • Accounting • Performance • Security • At the Service Management Level Service Provisioning and Monitoring are performed • The Business Management level is focused on commercial and customer management issues

Management Systems • OSS are implemented as state-of-the-art servers with standard Operationg Systems and proprietary software applications • The splitting of the management functions into four layers is a theoretical one and doesn’t necessarily correspond to actual system implementations: in practical circumstances features belonging to different layers can sometimes coexist within the same system

Element Managers • Every network node is individually managed by its own Element Manager (EM) • EMs allow for the complete set of management operations to be performed directly onto the Network Elements, via a user friendly GUI, by operators for which deep knowledge of the detailed structure of the NE is required • For large nodes (e.g. a softswitch) they are dedicated servers, normally based on redunded commercial HW platform, with standard O.S., running proprietary SW applications each dedicated to a FCAPS function • For smaller nodes (e.g. an IP router) they can consist of a set of SW applications running on the node itself, accessible by the operator via standard PC running dedicated applications (client) • EMs are interfaced with the higher layers management systems through standard or, sometimes, proprietary protocols in order to provide data (e.g. configuration data, performance measurements, call detail records, alarms, etc.) and receive commands to be activated on the NEs (e.g. configuration parameter setting, traffic control commands, etc.)

Network Managers (1) • At the network level the management systems perform the same FCAPS features as the EMs, but with a global network view • They collect configuration data, alarms, measurements and accounting data from the Network Elements, through the respective Element Managers, and integrate them in a global view of the entire network • They act upon the network by sending configuration data and commands to the Network Elements through the interfaces with the Element Managers

Network Managers (2) • To provide network level view from the information gathered from the individual nodes, Network Management System perform such processing activities as: • normalization among data collected from NE by different manufacturers • integration of alarm indications coming from different NEs to identify the “Root cause alarms” • integration of fault indications and traffic measurements to identify possible impacts on the QoS provided to the customers (Service Assurance) • aggregation of the performance measurements of different NEs to identify the traffic loss causes or to anticipate future potentially critical situations, e.g. during the next busy hour • integration of configuration data from different NE to identify possible configuration inconsistencies • network behavior simulation with new configuration parameters before their actual activation on the network nodes • . . .

Main Network Management features (1) • Fault Management • Fault detection • Fault localization • Trouble Ticketing (workflow over the whole lifecycle of the alarm, from its rising up to its resolution) • Configuration Management • Users’ configuration • Network configuration For both users and network: • Configuration setting (Provisioning) • Configuration Data acquisition and storage (Inventory)

Main Network Management features (2) • Traffic and Performance Management • Real time Traffic Management • Traffic surveillance (near real time detection of critical situations) • Traffic control (action performed to minimize traffic losses and QoS reductions) • Off-line Performance Management (mainly statistical reports) • Accounting: collection of users’ related usage data (number and type of placed calls, traffic volume through the IP network, etc.) • Accounting data are sent to Billing systems at the Business Level to bill the customers • Can also be used by the Performance Management systems as detailed data to complete the statistical reports or to support detailed analysis of the network problems

Network Managers main characteristics • Network Management systems are realized by SW applications, developed by the same manufacturers as the Network Elements or by specialized companies, upon state-of-the-art computer HW and SW (Operating Systems, Data Bases, Graphical Interfaces, Object Oriented platforms, Communication platforms, etc.) • Both SW (e.g. in terms of number of licensees of third party SW) and HW (computer class, number of CPUs, RAM and HD size, etc.) are dimensioned through an engineering process according to the size of the network, the traffic volume, the estimated event rate, etc. • The HW platform is always redounded in a high availability configuration, in order to guarantee service continuity even in the presence of serious faults • Redundancy also allows for upgrades or release changes to be performed without any service interruption • Modularity allows for system upgrades, due to network size / traffic or event volume increase, to be easily accomplished by adding new elements (e.g. new CPUs) or replacing them with more performing ones

The role of Software in Telecommunications