Study Paper ON Telephony Application Server
Study Paper ON Telephony Application Server
Study Paper ON Telephony Application Server
ON
Telephony Application Server
1. Introduction................................................................................................................4
2. Telephony Application Server ...................................................................................4
3. Internal Working of a Telephony Application Server................................................7
4. Location of a TAS in IMS Architecture……….........................................................8
5. TAS Requirents………………………......................................................................9
6. TAS’s Application in a different way………….......................................................11
7. Call Flow with TAS..................................................................................................13
8. Conclusion…………………………………………………………………………15
9. Abbreviations ...........................................................................................................16
10. References.................................................................................................................17
For last few years, the telecom industry is seeing a transformation, where the
boundary between fixed & mobile broadband service providers are mixing. Inthe past,
subscribers had multiple service provider relationships, and these are now able to get most
of services by a single service provider. In today’s era, mobile phones have various
multimedia capabilities & multi-purpose utilization which ultimately demanding rich-media,
interactive services. For this purpose, the traditional issues of network infrastructure are
giving way to new issues of service delivery and execution infrastructure, which requires
standards, based services across multiple platforms, networks, and applications.
One of the most viable options is to transform their network using an IP Multimedia
System. The IMS supports multiple Application Server for telephony services. The
Telephony Application Server (TAS) is a back-to-back SIP user agent in IMS that maintains
the call state.
The TAS contains the service logic which provides the basic call processing services
including digit analysis, routing, call setup, call waiting, call forwarding, conferencing,
etc. The TAS provides the service logic for invoking the media servers to support the
appropriate call progress tones and announcements in various stages of call.
Basically IMS has three main layers. These are transport, control, and
service/Application layer. The IMS supports multiple application servers for telephony
services in its Service/Application layer. An IMS application provides a specific service to
the end user. IMS end-user services include multiparty gaming, videoconferencing,
messaging, community services, presence, and content sharing. Depending on its
implementation, a telephony application server is required that can host one or many
different applications.
(a) It runs all application logic that manages the workflow associated with routing
incoming calls so that they are always routed to the preferred device.
(b) It initiates all call related events to the client.
(c) It provides personal call history records of all calls that user makes and receives.
(d) It handles all call and flow control for audio conferences.
(e) It manages all user and configuration data.
(f) Some data is provisioned into the system as part of the initial configuration, while other
data is managed by the user.
(g) Together with Media Server component provides limited audio conferencing capability.
Primary use case is for small ad-hoc meetings. This capacity is configurable.
(h) Provides ability to provision remote administrative features.
(i) Provides SIP Registrar and Proxy service for the embedded soft phones.
All above three servers may be combined in one unit which can also be called as
Telephony Application Server. The IMS architecture enables an IMS service provider to
deploy multiple application servers in the same domain. Different application servers can be
deployed for different applications. TAS integrates voice, video, instant messaging,
presence, mobility, conferencing and collaboration over any network and any device.
SIP application servers are generally B2BUA (back-to-back user agents). It can act
as redirect servers, proxy servers, originating user agents or terminating user agents. This
has SIP signalling capabilities and are directly involved in the call’s signalling flow. This
receive SIP messages from the S-CSCF (Serving Call Session Control Function) and parse
them. Similarly, they generate SIP messages and send them to the S-CSCF.
There may be a chance in which, SIP-AS is co-located on the CSCF and this may be
useful for simple services. Doing this, may be beneficial for the Service Availability and the
Service Performance.
OSA application servers can provide the same services as the SIP application server
but have no signalling capabilities and aren’t directly involved in the SIP calls’ signalling
flow. They communicate with the S-CSCF through the OSA-SCS(service capability Server),
which maps SIP messages into invocations of the OSA API (also called Parlay) and back.
OSA SCS provides access and resource control.
From an S-CSCF perspective, the SIP application server and the OSA SCS exhibit
the same behaviour. The OSA application server also has access to the HSS data, but only
through the SCS. The SCS implements the Diameter protocol, so it can read and update data
records based on the OSA application server’s requests. The OSA application server mainly
implements external services that could be located in a visited network or a third-party
platform.
The IM-SSF provides the interworking of the SIP message to the corresponding
CAMEL, ANSI-41, Capabilities Application Part(CAP) or Transaction Capabilities
Application Part (TCAP) messages. The number portability is done through ENUM server,
that populates the Number portability data(NPDB), and when ENUM server is queried for
the terminating call it prepends the LRN number if any.
The Telephony Application Server uses filter rules to decide which of the many
services deployed on the server should handle the session. During the service logic’s
execution, the application server can communicate with the HSS to get additional
information about a subscriber or to learn about changes in the subscriber’s profile. The
application server uses the Diameter protocol to communicate with the HSS.
A functional model showing interaction between the S-CSCF and the TAS is in Fig.
2. Every UE-originating incoming request, from the S-CSCF, is handled by the AS-ILCM;
this interacts with the application logic to report the call state information. Depending on the
service that is being provided, the application logic may instruct the AS-OLCM to modify
the request if needed. After processing the request, the AS-OLCM may send this request
back to the S-CSCF.
In both cases, the TAS handles and interprets the SIP messages forwarded by the S-
CSCF and translates end-user service logic into sequences of SIP messages, which it sends
to the parties involved, again through the S-CSCF. The S-CSCF decides whether it should
forward an incoming initial SIP request to a given application server. The decision it makes
is based on filter information received from the HSS.
IMS (IP Multimedia Subsystem) provides services in a standardized & proper way. It
provides a future-proof architecture that simplifies and speeds up the service creation and
provisioning process, while enabling legacy interworking. In a broader term, it enables a
secure migration path to all-IP architecture that meet end-user demands for new enriched
services. The IMS standard is based upon the widely adopted Internet standard technology
called “Session Initiation Protocol” (SIP). SIP is at the heart of the IMS network
architecture, providing the real-time, peer-to-peer, multiparty and multi-media capabilities.
The IMS architecture and SIP signaling is flexible enough to support a variety of
telephony and non-telephony application servers. Application servers host and execute the
services and provide the interface with the control layer using the SIP protocol.
/Application
Layer
Transport layer. It is the network-access layer. It connects different IMS devices and user
equipment. The transport layer enables the IMS devices for placing and receiving calls to
and from the PSTN or other circuit-switched networks through the media gateway. The
transport layer establishes the IP connectivity of user equipment.
The P-CSCF is a SIP proxy entity which is used as first entry point of contact for the
IMS terminal. IMS terminals discover their corresponding P-CSCF as part of their network
connectivity procedure. It sits on the path of all signalling messages of the IMS terminal and
passes SIP registration to the correct home network and SIP session messages to the correct
S-CSCF after registration.
The I-CSCF is a SIP proxy which is located at the administrative IMS domain’s
edge. Its IP address is published in the domain’s DNS server, so remote servers (such as a P-
CSCF in a visited domain or an S-CSCF in a foreign domain) can find it and use it as an
entry point for all SIP transactions to this domain.
The S-CSCF is the central node for signalling plane. It registers users and provides
services to them. It routes SIP requests, provides billing information to mediation systems,
maintains session timers, and interrogates the HSS to retrieve authorization, service-
triggering information, and user profiles.
The HSS contains the database of users. It supports the IMS network entities that
handle the calls or sessions. It contains subscription-related information (user profiles),
authenticates and authorizes users, and can provide information about users’ locations.
The Media Resource Function provides media functions in the IMS architecture
(such as playing announcements or recording voicemails). The IMS standard decomposes
the function of this into two elements. The media resource function controller interprets
information from the S-CSCF. MRFC control the media resource function processor
(MRFP).
The breakout gateway control function(BGCF)determines the next hop for routing
SIP messages that can’t be routed by the S-CSCF. It selects a media gateway control
function (MGCF)that will route the call to the PSTN through a media gateway.
Service layer. The transport and control layers provide an integrated and standardized
network platform to let service provider’s offer various multimedia services in the service
layer. The service layer contains the telephony application servers for various applications,
which provide the end-user service logic.
5. TAS Requirements
Service providers must be able to change the service logic rapidly and efficiently.
Users/ Customers also demand control of their own services to meet their individual needs.
The application server should support services, software, and hardware components
from different vendors while maintaining interoperability. Application Server should
support interconnection with S-CSCF for service triggering through standard ISC interface
compliant with TS 24229-870. Application Server should support interconnection with User
Data Centre for retrieving/updating the subscriber service data through Sh interface.
Application Server should support non-transparent data in Sh interface defined in
3GPP Rel-8 TS 29.364. The non-transparent data is understood both syntactically and
semantically by the HSS and AS. The non-transparent and standard format facilitates
interoperation among AS supplied by the same, or different, vendors. It also enables the
service consistency when user roams between CS and LTE domain and change the service
setting from different domain.
Application Server should support standard SOAP to integrate the 3rd party
application. Application Server shall support highly efficient downloading on Sh interface
and IVR announcement control on Sr interface.
When a subscriber roams & want to access in the CS network, then with the ‘anchor’
service enabled, the Telephony application server allocates IM routing numbers (IMRNS) to
their calls and routes the calls to the IMS network for processing. This allows the subscriber
to experience IMS services while on the IMS network.
The principles for centralization and continuity of services in the IMS in order to
provide consistent services to the user regardless of the attached access type. In order to
support this principle, originated and terminated sessions via the CS or PS domains need to
be anchored in the Service Centralization and Continuity Application Server (SCC AS) in
the IMS.
The limitation of 3GPP standard (24.390) is that it defines only UE Initiated USSD.
For Network Initiated USSD, it only defined an AS can send USSD (INVITE) to UE, but
not define USSDC to UE (the domain selection is not defined). In this case, other service
providers/ operators use SMS to replace network initiated USSD. Inherit existing USSD
related services in bank, stock exchange and etc.
There are two solutions of location information retrieval i.e. PCRF based NPLI and
TAS based NPLI (Network Provided Location Information). When an INVITE is received,
SBC (P-CSCF may have SBC capability generally) can use the Rx interface to PCRF for
location information with the bearer establish. This procedure can be used for both
originating call and terminating call.
When TAS receives a INVITE, if there is location based services (such as IM-SSF
for IN triggering, or Call Barring based on location), it will send the UDR to HSS for 4G
location information (PS domain) and 2G/3G location information (CS domain).
Figure 7
Stage 2
11. The UE calculates the credentials, includes them into the REGISTER request, and sends
it to the P-CSCF.
12. The P-CSCF finds, with the help of DNS, the home network entry points (I-CSCF). The
P-CSCF forwards the REGISTER request to that I-CSCF.
13. The I-CSCF queries the HSS to find out if there is an already allocated S-CSCF to this
user.
14. The HSS returns the address of the S-CSCF allocated to this user.
15. The I-CSCF forwards the REGISTER request to that S-CSCF.
16. The S-CSCF informs the HSS that this S-CSCF is taking care of the user.
17.The HSS returns the user profile containing the filter criteria.
18. The S-CSCF evaluates the filter criteria, and may contact, if needed, one or more
application server. In this example, the filter criteria indicate that an application server
has to be informed about the user’s registration. The S-CSCF creates a new REGISTER
requests and sends to an application server.
19. The AS acknowledges the reception of the REGISTER request.
Figure 8
8. Conclusion
Though IMS was defined by the 3rd Generation Partnership Project (3GPP) in
Release 5 & 6, originally for 3G/UMTS mobile networks in a decade ago, but is now
becoming a reality with the rollout of IMS based LTE network. Recently Voice over LTE
(VoLTE) services has been launched by operators in India. The IMS network supports
multiple access type’s including GSM, WCDMA, CDMA2000, Wireline broadband access
and WLAN.
The capability of IMS to deliver faster transmission of voice & data, including
standard calling features, messaging as well as various enriched services, ensures more
deployment of the technology in future. The IMS is already considered a foundation for LTE
deployment.
In the IMS architecture, Telephony Application Servers host and execute the IMS
service logic. These servers can be SIP application servers, open services architecture(OSA)
application servers, or a Camel service environment. Some technologies used in telephony
and voice-over-IP (VoIP) application servers are also applicable to IMS application servers,
but such servers have some unique requirements that could limit the extent to which these
technologies can meet them. There is no standard based internal architecture of Telephony
Application Server. The different technologies have different versions. The SIP servlet
approach is currently the most popular application server technology.
(1) A study Paper on “IMS Application Servers, Roles, Requirements, and Implementation
Technologies” by IEEE Internet Computing
(2) A study paper “A Study on IP Multimedia Subsystem Architecture & its Application
Servers”, link is http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.457.6364
&rep=rep1&type=pdf.
(3) A white paper on “Introduction to IMS” http://cse.iitkgp.ac.in/~pallab/mob_com/
Ericsson_Intro_to_IMS.pdf
(4) A SPIRENT white paper on “IMS Architecture, The LTE User Equipment Perspective”
(www.spirent.com)
(5) https://www.ibm.com/support/knowledgecenter/SSKTXQ_8.5.1/com.ibm.help.sametim
e.v8512.sut.doc/overview/sut_inst_ovr_tas.html
(6) https://www.ericsson.com/ourportfolio/products/multimedia-telephony-application-
server?nav=productcategory002%7Cfgb_101_432
(7) https://en.wikipedia.org/wiki/Telephony_application_server
(8) https://www.itu.int/dms_pub/itu-t/oth/06/5B/T065B0000140013PDFE.pdf
(9) http://ipv6.com/articles/general/IP_IMS.htm
(10) M/s Huawei’s “Request for Proposal” on “VoLTE Tech Reqs and Specs”