Download Overview - LIA - Laboratory of Advanced Research on Computer

The role of software in
Telecommunications
0
Table of contents
1
Introduction .............................................................................................. 2
2
Initial employment of IT in TLC ................................................................. 3
3
Increase in the demand of new services: the Intelligent Network ............. 5
4
Evolution of the computers towards TLC .................................................. 7
4.1 Integration of IT communication in the telephone switches ................. 7
4.2 The birth of the data networks ............................................................ 9
5
Convergence between voice and data networks .................................... 11
5.1 The "New Generation Network" architecture..................................... 12
5.2 The Application Layer ....................................................................... 16
5.3 The IMS architecture ........................................................................ 17
6
Management systems ............................................................................ 22
7
Software development process in the TLC manufacturer companies .... 27
1
1 Introduction
What follows is a short overview of how software has entered the Telecommunication
world, gaining more and more importance as the technological improvement of the
networks pushed towards a convergence between TLC and IT, up to assuming the largely
predominant role in the development of any device, node, system of the
Telecommunication networks.
It is an attempt to make a historical outline of how this phenomenon has gradually
developed through the years, by means of a few examples for which some TLC systems
and network architectures have been considered particularly significative, on the basis of
my personal experience. Of course they are just a few examples, and this doesn't claim to
be an exhaustive overview. Also, they are just mentioned with the scope of giving a
perception of the importance of software in their realization and not with the claim of
providing a real description of them, which is well beyond the scope of this document.
2
2 Initial employment of IT in TLC
Up to few decades ago the telecommunication networks, and in particular the switching
ones, didn't take information technology into account, neither as development technique,
nor in terms of making computers communicate with each other:

the switching networks, both public and private, were required to provide the voice
services only, since the computers were used to working only as stand-alone machines
and didn't need any communication service;

information technology was not employed in the design of the network elements: the
telephone switches didn't need great flexibility, since the services required by the users
were limited. The development of the telephone switches was hardware based; in fact,
at the very beginning, they were realized in electromechanical technique (relays) and
their features were based on automatisms rigidly defined during the design phase.
As Information Technology developed, it began to enter the Telecommunication world as
the basis upon which the main organs of the network elements (mainly the telephone
switches, both public and private) were designed, when the enormous benefits that the
employment of SW could bring to their development became evident, like, for example:

it enormously extended the capabilities of the switches, both in terms of performance
and service complexity;

it allowed for simpler, cheaper and quicker service extension, both in terms of addition
of new services and of upgrade of the existing ones, without any modifications to the
hardware design, thus speeding up and simplifying the productive process;

it made the error and malfunction correction process quicker and simpler;

it extended the flexibility of the network elements, for example by allowing for an easier
customization, a better adaptability to different network contexts, an easier parameter
configurability, etc.;

it allowed for the implementation of more effective redundancy techniques (e.g. micro
synchronous duplication) thus increasing the system reliability;

...
The process of acquisition of information technology within the telecommunication world
experiences a further significative thrust with the diffusion of the microprocessors'
technology: at the beginning the main organs of the network elements started to be
designed as computers that each company used to develop by itself, based on discreet
logic (both the CPU and the I/O devices were realized with the employment of the
3
integrated circuits and the discrete logic that semiconductor manufacturers were making
available in those years); later, as microprocessors began spreading out, hardware and
software development became quicker, easier, the computer boards became much more
powerful.
Of course this caused dramatic changes both in the manufacturers and in the telecom
operators, since the know how required by the R&D labs, and in general by all the
technical departments, moved towards the computer world, even if the characteristics of
such types of computers were deeply different from those of the commercial ones.
The availability of more and more powerful and cheap microprocessors led to their
employment for the realization of the majority of the functional blocks of the network
elements, including the peripheral organs, and the and the network nodes (in particular the
telephone switches) became a complex ensemble of cooperating microprocessors.
Languages, real time operating systems, finite state software structures (based on SDL:
functional Specification and Description Language: a symbolic language defined by ITU in
order to specify and describe the behavior of the TLC systems), development and
debugging systems, as well as I/O devices expressly realized for being employed in the
telecommunications world started to spread out.
4
3 Increase in the demand of new services: the
Intelligent Network
The adoption of Information Technology in the Telecommunication world grew even more
extensive when the services requested by the users started to become more and more
complex and affected also the general architecture of the network. Some new services
were too complex to be effectively realized within each switch, or needed access to data
that were common to the whole network. Therefore, to provide those special services, the
network architectures started to include specialized computers and Data Bases,
centralized at the network level. The most typical example is the "Intelligent Network" (IN).
Fig. 1 - Intelligent Network architecture
IN is a clear example of how the great flexibility provided by software has been decisive in
making possible the provision of services otherwise much more complex or even too
complex to be realized. Besides the common telephone services directly provided by the
switches, additional "Intelligent" services were provided by the Service Control Point
(SCP), a functional block centralized at the network level, which hosted the Service logic
and accessed user data and account information stored in the Service Data Point (SDP).
Every time a user invoked one of the "Intelligent" services, the "Service Switching Point"
(SSP: an IN function hosted by the originating switch), after detecting that it was an IN
5
service, triggered the SCP. Depending on the implemented service logic and the user and
account information stored in SDP, the SCP node would replay with indications on how the
service should be exploited.
In this architecture, adding a new service in the network only requires acting at the SCP
and the SDP level through dedicated software applications (SCE: Service Creation
Environment) that allow for easy, quick, flexible and user friendly implementation of the
service logic and data, while the only information required by each individual switch is just
that related to the presence of the new service in order to make the SSP function able to
trigger SCP every time a user invokes it.
Televoting, Number Portability, Green Number, Reverse Charging, VPN, Calling card,
Personal Number, Universal Number, Call distribution (location and/or time based,
proportional, etc.) are a few examples of IN services. In the figure below an example of call
flow involving access to SCP/SDP for the "green number" service is reported.
Fig. 2 - Example of IN call flow: Green Number service
6
4 Evolution of the computers towards TLC
Meanwhile also the computer world started evolving towards Telecommunications: the
computers, initially acting as stand-alone machines, started showing more and more the
need to open towards the external world and to communicate with other equipment
through the telecommunication networks (e.g. to allow remote terminals to access a host
or other resources, or a given terminal equipment to access different hosts, to allow for
resources concentration, such as printers, in centralized pools to be shared by all the
users of the same organization, to let users access centralized Data Bases, to perform file
transfer between computers, etc.). As Personal Computers spread, of course, all of that
underwent a strong, further thrust, given the enormous diffusion of services requiring
access to the communication functions (one example for all: the electronic mail service).
The consequence was e big effort that developed in two directions, initially antithetic:
1) The integration in the telephone switches of features providing communication
capabilities also to IT equipment, besides the voice ones;
2) The birth of the data networks: LAN, IBM SNA, geographical packet networks (e.g.
Itapac), etc.
4.1 Integration of IT communication in the telephone
switches
This was realized through the adoption of devices, the "Terminal Adaptors" (TAs), that
interfaced the data equipment on one side and the telephone switch on the other. TAs
managed the signaling protocols with the switch in the same way as the traditional
telephone sets in order to establish the communication link between the data devices at
the two endpoints. After the link was set up, they provided for "rate adaption" between the
data flows at the IT device interfaces and the bearer channel in order to allow for reliable
data transfer between the two endpoints.
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 through the external telephone network
PAD (Packet Assembler Disassembler) to access external packet networks
SNA emulators to access the IBM SNA networks
…
7
The ISDN standards were defined with the goal of providing voice and data services
through one network interface enabling both voice and data equipment to access the
communication services in the same way. ISDN was an example of the push towards the
integration among different types of service within a unique switching device, even though
the accessed services were still quite distinct: on a per call basis either a voice or a data
communication service was invoked.
Above all they were the PABXs, more than the public exchanges, that gave the strongest
thrust towards this convergence and the unification of the procedures to access the
services; the reason for this is that in the private context users were much more
demanding and the request for TLC services was much bigger: PABX services had to
support the working activities in the companies and such advanced services as, for
example, videoconferencing, were, at the beginning, typically requested only in the private
market.
About the employment of the microprocessor's technology in the design of the switching
equipment, as mentioned in chapter 1, perhaps it may by worthy mentioning how the
realization of the interfaces with the IT devices represented a particular case of software
development. Real time management requirements were very strong and dedicated
operating systems were used, performing a limited set of features, but optimized for
concurrent processes management. Software was typically written in low level languages
to optimize the execution time and the memory use: for example in the equipment
developed in Telettra a structured macroassembler was adopted, i.e. an assembler
language enriched with the possibility to define macros and especially with primitives that
allowed for writing software in a structured way and that were converted into assembler
instructions by the compiler.
Software structures oriented to the management of finite state machines (e.g. SDL) were
frequently adopted for protocol management: protocols can be typically described as finite
state machines where in each state only a defined set of events is allowed (e.g. reception
of a frame or of an errored one, reception of a flow control message, a time-out elapsing,
etc.) and the action consequent to an event depends on the state (e.g. received frame
acceptance or not depending on whether the receiving edge was in an active flow control
status or in a free one)
The wide spread of the level 2 and 3 communication protocols (e.g. LAPB, SDLC SNA,
LAPD ISDN, X.25 Packet level, DMI mode 2 e 3) that were to be managed by
microprocessor boards, induced the integrated circuit manufacturers to produce chips
dedicated to autonomously handling the low level functions of the protocols. In the
consequent software architecture, the main CPU could therefore be relieved of those low
level functions (those that presented the most pressing requirements in terms of execution
time, such as bit stuffing/de-stuffing, frame start / end detection, length detection,
redundancy code check, etc.) thus attending only to such functions as processing the
protocol formalisms (e.g. sequence numbering, flow control management, retransmission
requests, timeout processing, etc.), managing the buffer queues, etc.
8
DMA was often used as well for buffers management in conjunction with the
transmitting/receiving devices. In this case, for example in reception, the CPU had only to
provide the initial address of the receiving buffer and the DMA provided to read every byte
from the protocol handling device, and to write it into the reception buffer (and vice versa in
the transmitting process). But there were also very powerful devices, based on
microcomputers much more powerful than the main processor of the equipment, that were
able to autonomously handle the complete formalism of the level 2 (data link) protocol,
letting the main CPU cope only with higher layer protocols.
To conclude this short overview on the data communication features provided by the
telephone switching networks, in particular by the PABXs, it should be noted that such
systems were all circuit switching based and, consequently, also data communication was
accomplished through the circuit switching technique.
However, since packet switching was in the meantime gaining more and more success in
the data communication field (as mentioned in next paragraph) some implementations for
allowing data equipment to communicate in this way even in the PABX world were done.
In particular within the Telettra's TAU-SDN system a "Frame switching/Frame Relaying"
technique was adopted by means of the realization of a "Frame Handler" (FH), a
centralized resource to which the IT devices requesting to communicate in this mode
gained access through the TAU-SDN circuit switched internal network, allowing for setting
up virtual circuits using the same outband ISDN signaling protocols with the Telephone
Processors as for all the other call types.
To access the Frame Handler the Terminal Adaptors had to use DMI mode 3, instead of
mode 2, as internal protocol. 1 Actually the TAU-SDN TAs were able to switch from one
method to the other depending on the required type of connection.
4.2 The birth of the data networks
As computers opened towards communication a big acceleration occurred in the definition
process of the communication standards in the computer world, both in the local premises
(the Local Area Networks, with the definition of standards like CSMA/CD, Token Bus,
Token Ring, LLC protocol, etc.) and in the geographical networks with packet switching (in
1
DMI Mode 2 was a "Rate Adaption" protocol used in circuit switched connections: it was adopted by the Terminal Adaptors as a
means to transfer, through the 64 Kbps channels of the internal switching matrix of the PABX, the data exchanged through the interface
(e.g. RS-232) with its own IT device. Essentially it consisted in inserting the received data into HDLC like frames.
DMI mode 3 was similar to mode 2, but its frame structure was the same as the LAPD one, and had been defined for frame switching
and relaying: the address field of the frames (not significative in mode 2 was) was used to identify the "Logical Links"; many different
Logical Links could be established simultaneously within the same equipment.
9
both the connection oriented, or virtual circuit, and the connectionless, or datagram,
versions) prevailing over circuit switching and with the success of X.25. Later, the
definition of the seven layer ISO-OSI model represented the apex of this process.
Under the implementation point of view, the ISO-OSI model represents a significative
example of the highly predominant role gained by software in the development of the
communication features, and of how software absorbed a significant part of the
development costs of the entire communication projects.
Naturally, the characteristics of the communication software in the nodes of the network
and in the endpoint computers were deeply different, and required different skills: in
general in the network equipment, where only the three lowest layers of the model were
used, the needs for processing speed and real time process management were
predominant, while in the network endpoints, hosting the whole stack, prevailed the need
for the communication packages to be integrated in the software environment of the host
computers, based on higher level operating systems and languages. The realization of the
whole OSI stack required highly specialist skill that only a few IT companies possessed, so
its development was normally left to specialized software companies which, after agreeing
with the customers all the details in terms of protocol configurations, communicating
applications, operating systems configuration, computer environment, etc. provided for the
development and delivery of the protocol stack, including its integration with the host
environment and the complete exploitation of the tests, and even periodical software
updates (through maintenance contracts) as the international protocol specifications
evolved.
In the meanwhile, the continuous technological development allowed for more and more
power, fast and cheap network nodes, and the consequent evolution of the networks and
protocols brought to the definition of more efficient standards (Frame Switching, Frame
Relaying, ATM, ...) and the final replacement of X.25 with the more efficient connectionless
Internet Protocol (IP) at the Network Level and, in the endpoints, the abandonment of the
OSI stack in favor of the Transport TCP/UDP protocols with the Application Layer directly
above them.
The birth of the Internet, that took origin from Arpanet and is conceived as a packet
network initially devoted only to the data traffic in a restricted environment, is an outcome
of this process.
10
5 Convergence
networks
between
voice
and
data
Also in the data network field, similarly to what happened for the voice ones, a strong need
arose to achieve the convergence between data and voice services, including also, in a
second step, the video ones. The birth of the VoIP protocols is consistent with that. Initially
VoIP was conceived just to transport voice packets (packetized voice as one of the many
types of data streams) through the data networks, but still without a real provision of the
usual telephone services (e.g. call forwarding, call waiting, etc.); later, with the introduction
of the "NGN" (New Generation Network) standards, the real ToIP (Telephony over IP)
services will be provided over the IP networks.
Two more factors triggered a further big thrust towards a more complete integration
between voice and data:
1) on one side the quick technological development of the data network nodes and the
consequent improvements of the performance of the nodes in terms of speed, reliability
and effectiveness, that brought to a considerable cost reduction of communication and
a significative service improvement, and of the transmission technology, with the
consequent increase of available bandwidth, factors that made possible services that
before could not be provided. In this context, decisive importance was assumed by the
definitive predominance, for all the information types (voice, data, images, video) of
packet switching over circuit switching, and of the IP protocol, which proved being the
most effective technique for the actual convergence of the different types of multimedia
services. Many Telecom operators around the world have adopted the IP networks to
provide multimedia services to their customers, including the traditional telephone
services (ToIP). Just as an example, the whole telephone transit network and the
international network of Telecom Italia are entirely based on IP.
2) on the other side the bigger and bigger demand of new services by the users. It was a
self-sustaining phenomenon, since the users, in front of the great opportunities
provided by the development of technology and computer science, pushed to obtain
more and better services, integrated with the existing ones, thus triggering those
market opportunities that urged the providers to act to satisfy the new demands and
conquer new market areas; the provision of new services, on turn, triggered the
development of better technologies, and so on.
Summarizing, convergence occurred between the information technology and the
telecommunications worlds: on one side the opening of the computers to communicate
with the other systems, on the other side the acquisition of the techniques proper to the
information technology world for the realization of the modern telecommunication systems.
Such convergence was mainly sustained by the technological progress that led to the
increase of the processing and the storage capacity of the systems, together with their
11
miniaturization and the fall of their costs, with the consequent spread of more and more
powerful users' devices in the homes and the offices, and the possibility to access more
and more sophisticated services.
5.1 The "New Generation Network" architecture
Perhaps the most important innovation in the direction of the convergence among different
media is the "New Generation Network" (NGN) architecture. The capability of the IP
network to transport and integrate all types of information (voice, data, video) to provide
multimedia services, together with the technological evolution and the availability of a
much wider bandwidth than that strictly needed for the traditional telephone calls, brought
to the loss of the traditional distinction between voice and data networks and to the
availability of one type of network (packet switched, IP based) able to transport all types of
information (voice, data, video).
The transport and switching networks became more and more service independent, and
therefore the provision of the actual services began moving to a different layer that used
the underlying network just as a bandwidth and QoS provider. In this way multimedia
services incorporating voice, data, images and video streams began to spread out,
integrated with other users' data such as, for example, Messaging or Presence
information.
The current trend is a unique IP based switching and transport network infrastructure, that
all what makes available to the users, on a per service basis, are the bandwidth and the
QoS, while the services, the added value, are provided by software applications running
on servers connected to the network: the Application Servers (ASs). In such a context, the
voice call is just one among many other available services.
In an NGN architecture, the softswitch acts as network controller and regulates the users'
access to the network, but doesn't provide any service by its own: it receives all the service
requests by the invoking users (through "INVITE" SIP messages) and, after checking the
request type, selects the appropriate Application Server to which the user's request must
be delivered. It is the Application Server, then, that executes the service logic, including, if
needed, the establishment of all the required sessions among users' devices by sending
the relative commands to the softswitch that, on turn, will establish the required sessions
exchanging the appropriate SIP messages with the involved users.
12
Fig. 3 - NGN architecture
The following are just examples of services that, in the NGN architecture, are provided by
Application Servers:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Telephone calls
Multiple Ringing
MRBT (Multimedia Ring Back Tone)
Unified Messaging
Voice / video mailing
Multimedia conferencing
Presence oriented services (e.g. conferencing)
Telepresence
IP-Centrex
IVR applications
Fixed-Mobile Convergence (VCC: Voice Call Continuity)
Content sharing
Virtual switchboard
Multiparty interactive games
Domotics
13
•
•
•
•
•
IPTV
Pre / Postpaid calling cards
Mass Calling
Televoting
...
A typical example of multimedia service which is commonly used in the business world,
where different media are integrated together to provide the global service, is the schedule
and realization (based on Presence information) of multimedia conferences in which the
attendants, each remaining in his/her own office or at home, besides seeing and listening
to the other attendants, can simultaneously share texts, slides, video clips or real time
made drawings, in order to submit them to the discussion and giving the other attendants
the possibility to make modifications, include them in other documents, etc.
The figure below shows a Conference server as an example of AS and of its structure.
Conference
Application Server
WEB Server
XML
JDBC, OCI
SCE
Application
Servers
HTML, SOAP
SIP
Service &
System Administr.
Media Server
RTP
SSW
IP
Fig. 4 - Conference AS architecture
If needed, different Application Servers can be simultaneously involved in the same
service; an example is an IP Centrex user that asks for a conference to be established
14
with other users; in this case the first AS to be involved is the IP Centrex one (since the
user is characterized in the network Data Base an IP Centrex user, all his/her calls will
always be managed by it); if the IP Centrex AS doesn't have conferencing capabilities by
its own, a further AS must be involved, this time on request of the IP Centrex AS itself that,
after examining the user's service request, asks the softswitch to establish sessions
among the involved users and the conference AS.
Summarizing NGN foresees a clear separation between:

Switching and Transport Layer, which is service independent and grants access to
any type of user's equipment (fixed or cellular phone, smartphone, PC, tablet, etc.)
through, if needed, different types of gateway. It provides the required bandwidth and
QoS for the realization of multimedia services according to the requests of the Service
Layer;

Service Layer, whose task is to realize all the services using the capability of the
underlying layer to provide the required bandwidth and QoS; it consists of a number of
software applications running on commercial servers, normally in high availability
configuration, with standard Operating Systems like Unix, Linux, etc.
It is a highly flexible network architecture characterized by the easiness of introduction of
new services (since any new service can be introduced just by adding one or more new
servers, or new software applications in the existing ones, and by recording the related
information in the network Data Base), by the possibility to access any service regardless
of the type of user's device, by the capability to provide multimedia data flows allocating
the required bandwidth on a per service basis, and to grant the requested level of QoS.
Of course, this evolution, that brought to the rigid distinction between the Access/Transport
and Control layers on one side and the Service layer on the other, didn't affect only the
architectural aspects of the networks, but had a big impact also on the playing actors, in a
scenario seeing the traditional TLC manufacturers remaining mainly focused on the first
two layers, while service development became more and more a prerogative of the
software companies, with the consequent shift of importance and business from the former
sector to the latter one. Furthermore, the need for more and more sophisticated services
has determined the tendency towards a high degree of specialization so that each service
development company tends to specialize in a particular type of service, thus, for example
some companies specialized in developing text, voice and video messaging application
servers, other in the conference servers, others in the centrex applications, etc.
Also, this architectural model entailed a complete vendor independence at the service
layer: it is a quite different situation from the traditional network architectures where any
new service had to be requested to the same vendors as the manufacturers of the network
elements. The modularity of the service layer, where the different services are performed
by different application servers independent from each other, enables the development of
new services by any software company, regardless of the vendors already present in the
network.
15
5.2 The Application Layer
Each Application Server is realized by software applications developed by specialized
companies, running on state-of-the-art computers with standard Operating Systems.
Compared to the traditional network architectures, the NGN, as well as the IMS one (as
summarized in the following paragraph), makes the development and the deployment of
new services much easier and quicker; of course, interoperability tests between any new
application server and the softswitch must be carried out before its deployment in the
network.
Among the characteristics normally representing the main requirements for the application
servers, the following can be mentioned:

should be realized by means of developing techniques allowing for quick service
development and easy modification;

should provide quick service customization, in order to allow network operators to
easily fine tune the general characteristics of the services to better meet the customers'
requirements; XML based languages, voice XML, CCXML, etc. are commonly adopted
for this scope;

should provide the customers with control possibilities over their preference settings, by
means of such tools like WEB interfaces, IVR, CPL (XML based Call Processing
Language), etc.
Hardware typically consists of a number of commercial servers running in different
configurations, depending on the system architecture. Normally the HW platform is
modular so that system upgrades can easily be accomplished by adding new elements
(e.g. additional servers, processors, RAM, etc.) or replacing them with more performing
ones.
For infrastructural elements like Data Base managers, Object Oriented platforms,
communication protocol stack platforms, etc., third party SW packages by specialized
companies are often included.
The systems are dimensioned on the basis of the size of the actual networks where they
are to be deployed, through a delicate engineering process that, taking into account a
number of parameters such as the number of users potentially accessing the services, the
estimated access ratio, etc., defines such items like the server class, the number of
servers, the processor type and number, the RAM size, the HD space, the number of
communication links, as well as the number and type of third party software licensees.
16
The HW platform is always redounded in high availability configuration in order to
guarantee service continuity even in the presence of faults.
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; the two servers
of each couple work in load sharing, but each server is dimensioned to handle the
entire network load by itself; should one server fail, the remaining one takes over all the
functionalities.
2 X N redundancy is most used when the system is made of different servers
specialized to run different applications and can therefore be dimensioned in different
ways or even belong to different classes;
2 X N System redundancy allows for upgrades or release changes to be performed
without any service interruption; normally the procedure consists in:
– disabling one server of the couple that must be upgraded;
– performing the required changes (e.g. release change) on the disabled server(s)
while the other one(s) are still running;
– switching the operativeness between the servers of the couple so that the new one
is operative and the old release is inactive;
– should the new software present malfunctions, operativeness is moved back to the
inactive server(s) running the old one;
– after checking the good performance of the new software it is loaded also on the
inactive server(s) and the complete configuration is then restored.

N + 1 con*figuration 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 redounded as well.
5.3 The IMS architecture
IMS (IP Multimedia Subsystem) is the 3GPP architectural model standardization for the
NGN networks and represents the current state of the art of its standardization process. It
is a set of specifications for an unified service architecture and defines a complete
framework whose goal is that of enabling:
17

convergence of voice, video and data communications to provide multimedia services
through one service independent network based on an IP-based infrastructure using
SIP (Session Initiation Protocol) as session control protocol;

interoperability with any network (new generation or legacy) in order to enable the
delivery of multimedia services to any user regardless of the actual network he or she
is connected to. In other words, IMS provides a unified service architecture for all the
networks;

independency of the type of user's device (fixed or cellular phone, smartphone, PC,
tablet, etc.) regardless of the access technology (DSL, Ethernet, GPRS, WCDMA,
etc.). Besides granting direct access to SIP terminals, it allows for legacy ones
connected to legacy networks to still access IMS services through standardized
gateway functions.
The IMS standard foresees the splitting of the network into a number of functional blocks,
and includes the detailed definition of the functional behavior of each block, its
relationship, cooperation and information flow with the other blocks by means of which the
multimedia services are provided.
As usual, the IMS architectural model is to be considered just a conceptual one: nothing is
said about its physical implementation, so that even the NGN architecture as we have
seen before, with the softswitch as access controller and AS trigger, can be adapted to be
compliant with this model. In other words, some existing equipment can be seen as
performing all, or part of the jobs of more than one blocks, or, conversely, each conceptual
block can be split and its features can be distributed among different physical equipment,
and so on.
As far as the functional blocks are concerned, only the main ones are shown in fig. 5
above, of which a non exhaustive list of the main features is given at the end of this
paragraph; naturally, a detailed description of the IMS architecture and of the whole set of
its functional blocks is well beyond the scope of this brief overview, which is focused on
the importance gained by software in the TLC world, but it is referred to, here, as a further
evidence of the definitively consolidated evolution of the TLC networks based on their
splitting into different layers:

Access and Transport Layer, based on the IP network, providing interfaces with the
other networks, including the legacy ones, through the relative gateway functions; SIP
is used as “signaling” protocol to ask for service requests and call routing;

Control Layer, providing for user access control, call routing, bandwidth allocation and
QoS target matching; it 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;
18

Application Layer, consisting of a number of Application Servers, providing all the
services to the users.
Fig. 5 - Simplified IMS architecture
In the same way as performed by the Softswitch in the NGN architecture, in the IMS one it
is up to the CSCF (Call Session Control Function) triggering the Application Layer.
Besides user authentication and call routing, the CSCF functional block determines which
application, within the Application Layer, must be invoked, depending on the user's service
request and the user's data stored in the network Data Base (HSS: Home Subscriber
Server).
Actually, under a theoretical point of view, the Application Layer doesn't properly belong to
the IMS itself, but it interacts with the control layer by means of SIP protocol and is
triggered by the CSCF function when a service must be invoked on the basis of the user's
request and the "Initial Filter Criteria" (sort of service specific parameters associated to the
user's profile)
In the figure above three types of servers are reported; as a matter of fact, besides the
new types of Application Servers (SIP AS), developed with the goal of being directly
integrated in the IMS network and therefore provided with the SIP interface, also legacy
systems can be integrated through the employment of interface adaptors:
19

The OSA-AS are Application Servers compatible with the OSA (Open Services
Architecture) standard. They are accessed by CSCF through the OSA-SCS function
(OSA Service Capability Server) which provides a standardized and secured access to
IMS by SIP protocol and uses an OSA Application Program Interface (API) for its
communication with the OSA servers.

Services provided according to the CAMEL (Customized Applications for Mobile
networks Enhanced Logic) standards can be provided to IMS users by means of “IMSSF” (IP Multimedia Service Switching Function).
A short summary of the main functions exploited by the functional blocks shown in the
figure above is reported below:

P-CSCF: Proxy Call Session Control Function: it is the first contact point of the
users within IMS. It is crossed by every SIP message to or from the users. It is
assigned to an IMS terminal during registration, and is the first point of contact for the
IMS terminal; its main features are:
– user authentication
– forwarding to I-CSCF of the registration requests received from the user
– the SIP messages forwarding to the S-CSCF that has been associated to the user
during the registration
– requests and answers forwarding to the user

I-CSCF: Interrogating Call Session Control Function: it is located at the
administrative domain edge:
– Its IP address is published in the DNS of the domain, in order to be located by
remote servers and use it as a forwarding point (e.g. registering) for SIP packets to
this domain.
– It retrieves the user location from the HSS and then routes the SIP request to its
assigned S-CSCF.

S-CSCF: Serving Call Session Control Function
– Interfaces to the HSS to download and upload user profiles
– Makes the correspondence between the user location (e.g. the IP address of the
terminal) and the SIP address
– Selects the application server(s) to which the SIP message are to be forwarded,
depending on the invoked services
– Provides routing services

HSS: Home Subscriber Server: is the network Data Base of the users' profiles and
the service data
20
–
–
–
–

Contains the user profiles
Contains the subscription information used by the service layer
Provides data used to perform user authentication and authorization
Provides information about the physical location of user
MRF: Media Resource Function: it supports bearer related services
–
–
–
–
–
Supports conferencing services by mixing audio streams
Provides for text-to-speech conversion (TTS) and speech recognition.
Performs transcoding (codec conversion) over multimedia data
Plays announcements (audio/video)
It consists of two functional blocks :
o MRFC: Media Resource Function Controller: controls MRFP (by means of
a H.248 interface) upon indications from S-CSCF
o MRFP: Media Resource Function Processor: realizes all media-related
functions.
The following functional blocks are used to manage the interworking with calls to traditional
circuit switched networks (PSTN, GSM, etc.).

BGCF: Break Out Gateway Control Function: selects the network in which PSTN
breakout has to occur and forwards the signaling messages to it through a selected
MGCF block that will manage the interworking process with the TDM network.

SGW (Signaling Gateway): provides for signaling conversion between IMS and the
TDM network at the transport layer.

MGCF (Media Gateway Controller Function): performs signaling protocol conversion
between SIP and SS7 / ISUP:
– Performs call control protocol conversion between SIP and ISUP
– Controls the MGW resources with a H.248 interface.

MGW (Media Gateway): performs RTP to PCM (and vice versa) media conversion
between IMS and the TDM network. It also performs codec conversion when required.
21
6 Management systems
Within an overview on the importance of software in Telecommunications, a subject of
crucial importance regards the Management Systems, or OSS (Operation Support
Systems). No Telecom Operator would ever introduce a new network element, equipment,
service or application into the network without the guarantee, properly tested, that it can be
fully managed. The Management Systems represent the only interface through which the
operators can "see" the network, and can monitor the behavior of both the individual
equipment and the network as a whole, as well as the services provided to the customers
and the relative Quality of Service.
Through the OSS the 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. QoS can have
many different meanings, depending on the type of service: it can refer to the packet
loss ratio, the round trip delay, the bit error rate; as far as voice calls are concerned, it
can refer to the call success ratio; service QoS can deal with the service provision
delay, or the service success vs access ratio, etc.)

collect statistical performance data to identify critical points or as support to network
upgrade policies; for example such statistics can be provided as to identify which is the
traffic relationship (source-destination) with the highest packet loss, or the lowest call
success ratio, in the presence of which events, what is the most recurring cause, what
is the time distribution of a given network problem during the day. Statistics are much
used by network managers to identify the most affecting problems of the network and
to plan upgrades (e.g. addition of new links between particularly congestioned nodes,
increase of the capacity of a node, etc.)

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 (e.g. statistics about the QoS provided to particular
customers, such as the frequency and the severity levels of faults affecting it. QoS is
often a contractual issue between the customer and the TLC operator: it often consists
of parameters to be monitored on a given period time, specified in the contract, that
can be of a great number of types: even the packet loss ratio could be a QoS
parameter to be monitored for a customer, and it must be accurately measured and
reported).
22

collect accounting information and provide billing data

...
The management systems are normally placed at four levels: at the Network Element, the
Network, the Service and the Business levels.

At the Network Element level the management operations are performed directly onto
the Network Elements as individual nodes. Operations performed at this level can be
very detailed and the operators must have deep knowledge of the detailed structure of
the node.
The main management areas of the Network Element level are the “FCAPS” ones, as
specified by the ISO TMN Model:
–
–
–
–
–
Fault
Configuration
Accounting
Performance
Security
Each individual node is managed by a proprietary "Element Manager" that, for
complex Network Elements (like the traditional telephone switches, the softswitches,
etc.) consists of a computer connected to all the components of the node, with which it
can exchange data through either proprietary or standard protocols. It is normally
based on state-of-the-art computers, redounded in high availability configuration, with
standard operating systems and proprietary applications running above. For simpler
Network Elements (like, for example, a router of an IP network) the element
management features are normally realized by a software application directly residing
in the equipment itself to which the operator can access from a PC connected directly
or through the communication network.
Normally the Element Management systems are equipped with a graphical user
interface (GUI) based on standard graphical tools, from which a local operator can
perform the complete set of management operations in a user friendly way (old
element managers provided only complicate MML interfaces that could be used only by
a restricted number of specialists).
The Element Managers are interfaced with the Network Management Systems through
standard protocols. They collect alarms, traffic and performance measurements,
configuration data and accounting information from all the components of the nodes,
and assemble them into standard interfaces towards the higher level Management
Systems (normally, especially for older equipment, different protocols can be used for
different types of management information, e.g. SNMP for alarms, FTP for traffic
measurements and accounting information, SQL-Net for the configuration data); they
23
also receive commands form the Management Systems above (e.g. configuration
commands, traffic and routing related commands, etc.) and forward them to the
appropriate block of the network element for their execution.

At the Network Level the network is managed as a whole, and the actions performed
over the individual nodes are consequent to the general network management strategy.
Operators at the network level don't need a detailed knowledge of the internal structure
of the network nodes, as required to local operators, but have a general view of the
network and its performance.
The Network Management systems 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 Management systems typically cover the same areas as the Element
Manager, but under a global network perspective, for which purpose they must perform
such activities over the information gathered from the element managers 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;
– ...
The main management features performed at the network levels are:
– Fault Management
o Fault detection
o Fault localization
o Trouble Ticketing (workflow over the whole lifecycle of the alarm, from its rising
up to its resolution)
– Configuration Management
o Users’ configuration
o Network configuration
24
For both users and network:
o Configuration setting (Provisioning)
o Configuration Data acquisition and storage (Inventory)
– Traffic and Performance Management
o Real time Traffic Management
 Traffic surveillance (near real time detection of critical situations)
 Traffic control (action performed to minimize traffic losses and QoS
reductions)
o 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.)
o Accounting data are sent to Billing systems at the Business Level to bill the
customers
o 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

The Service Level deals with all the activities related with the service provisioning and
monitoring, and covers areas such as:





Service planning and development
Service configuration
Service problem management
Service Quality management
The Business Level deals with commercial and customer management issues, such
as:
 Sales
 Order handling
 Customers' problem handling
 Customer QoS management
 Invoicing
The distinction above is mainly a theoretical one, since some management features
belonging to different levels can actually be implemented within the same system. Just as
an example, customer QoS monitoring is a business level issue, but such QoS parameters
like the packet loss ratio or the round trip delay in an IP network are often evaluated by the
same system that monitors the IP traffic at the network level; in the same way, how a fault
in a network node can affect the service provided to a given customer is often evaluated
by the Network Fault management system, etc. In other words, some of the Service and
25
Business Management features are often realized as applications within the Network
Management ones.
In general, such systems are realized by software applications running on commercial
state-of-the-art servers, redounded in high availability configuration, adopting standard
Operating Systems. Often, but not necessarily, Object Oriented languages and platforms
are adopted.
One peculiarity of the management systems is the importance of the Graphical User's
Interface (GUI) since it is the only means for the operators to monitor the behavior of the
network. The GUI must provide an as complete as possible view of the network at a
glance, allowing for quick and easy problem detection and providing user friendly
assistance to the operators to make quick problem solving decisions.
Another typical characteristic is that they must provide the operators with a uniform view of
the network, regardless of the possible presence of nodes by different manufacturers.
Despite the high standardization, the behavior can vary substantially in some
circumstances, and realizing a harmonization layer between the interfaces with the
network nodes and the actual management applications could be required; this could
sometimes be very complicate to be realized and could raise significantly the development
costs.
An important phase of the design of a management system at the network level is also its
dimensioning: the server class, he number of processors, the RAM size, the HD size, the
number of communication links, the number of licensees of third party software, etc. must
carefully evaluated depending on the size of the network, essentially in terms of number of
managed nodes and traffic volumes. Great flexibility is required in order to face future
network size changes just by means of servers upgrades, that must be possibly realized
with no (or minimum) system out of service time.
26
7 Software development process in
manufacturer companies
the TLC
At the end of this short overview on the role of software in Telecommunications, it can
perhaps be of some interest a general overview about the software development process
adopted by the TLC manufacturers. Of course it changes from company to company and
can differ significantly depending on the type of project, the conditions, how the company
is structured, etc. What follows is just a list of general steps, derived from my personal
experience made in the companies with which I have cooperated.

after deciding to take into consideration the development of a given feature, or a set of
features, or even an entire new system (such decisions can be made after an explicit
request by a customer, or by tender or following strategic and marketing policies) the
first phase is the definition of the high level specifications; if the features are to be
developed for a specific customer, normally this phase requires long meetings with him
to fine tune the high level specifications with the goal to reach a satisfactory
compromise between satisfying as much as possible the customer's needs on one side
and maintaining the development costs and the development time within reasonable
limits on the other;

a feasibility analysis follows, during which the general aspects of the activities are
evaluated, such as the estimated development costs, the resource allocation (including
the opportunity to involve internal or external resources) taking into account the
technological means of the company, the know how level required for the designers,
the availability of the necessary internal resources, the time of delivery requested by
the customer or by the market, the opportunity to split the project into different software
releases, etc.

after the project has been approved by the company management, it is assigned to one
or more development teams and the management team is designated: it varies from
one company to another and, even within the same company, can change significantly
after any reorganization; normally it includes a Program Manager, responsible for the
global coordination of all the activities, and the functional managers of the various
teams attending respectively to the definition of the detailed specifications, the software
development, the lab tests, the global integration tests, the deployment and the tests
with the customer (acceptance tests);

the detailed specification phase of all the features follows;
27

starting from the detailed specifications (i.e. what the features "must do" exactly) the
design specifications are defined, including the system architecture, the hardware
requirements, the software environment, the software architecture, its splitting in
functional blocks and in software modules, the way how the different modules
exchange information, etc.

at this point the actual software development phase begins;

after the development, the individual software modules are tested in the lab by the
developers;

after all the features have been developed and individually tested, the integration tests
are performed (i.e. the global test of the system) by the integration team on the basis of
a "test book" (list of tests) previously defined in cooperation with the system team;

The final product is delivered to the customer who performs the "Acceptance tests",
based on "Test Books" normally, but not always, proposed to the customer by the
manufacturer itself, apart from integrations and modifications that the customer could
want to make. The acceptance tests are normally performed in two steps:
– in the first step they are performed on a test plant normally, but not necessarily,
belonging to the customer, situated at the customer premises;
– in the second step the product is tested in the actual environment, i.e. after its
deployment in the network. This is a very critical phase since any still undetected
malfunction could affect even seriously the network service, and therefore such
phase starts only after reaching reasonable confidence that the product is
sufficiently steady and doesn't present serious malfunctions anymore.
Since only the tests in the actual network are performed in the presence of real traffic,
they represent the only phase when the system is actually tested in its correct
dimensioning and in its capability to handle the real traffic volumes. If the software is to
be installed on a plurality of systems (e.g. a new release of the routers of an IP network
or of the switches of a traditional telephone network) the network tests are first
performed on a very limited number of nodes and the release is then gradually spread
throughout the network only after making sure that the already deployed systems work
correctly.
Since then on, the behavior of the system will be monitored through the OSS (of course
its manageability by the management systems is always part of the tests of the
system). After this phase, any modification, patch, or new release follows about the
same process as summarized above.
28