Software and Service Platform Requirements

There is a whole range of service platforms required in modern networks. They
include platforms for value-added services (VAS), such as voicemail, Short Message
Service SMS), and Multimedia Message Service (MMS). They also include
mobility databases, including home and visitor location registers (both of which
play an important role in service provision for GSM, GPRS, and UMTS); generic
service platforms, such as service control points (used in Intelligent Networks) and
service nodes. Finally, they include content servers, which provide access to basic
and advanced information, graphics, pictures, music, and video.

With the reduction in the cost of a voice call, the service platforms are assuming
greater significance as a way of providing value-added services in an attempt to
maintain and increase the average revenue per user (ARPU). In networks that are
optimized for data, such as ADSL, GPRS, and UMTS/3G, they provide the main
mechanism to grow the number of subscribers and to increase revenue.

The user would either be using these advanced data networks as a bearer to
access content and services from an independent provider, or be directed by network
resources (network-provided service platforms) to a point in the network where the
service can be accessed (network-provided service platforms or third-party service
provider platforms).

Network operators would like their customers to access the operator-provided
content and services so that they can capture the ensuing revenue, but increasingly,
third-party service providers are seen as an integral part of the overall system. In
fact, work has been done within industry and standards bodies to provide standard
ways of connecting third-party providers to the network so they can be accessed by
customers. Examples of third-party content and services include information such
as movie schedules, restaurant opening times and locations, credit card payment for
calls, navigation system updates (traffic updates), etc.

Vendors
Provision of service platforms of whatever sort is considered big business. For some
vendors, it is seen as a secondary function, helping to make the core product (often
telephone exchanges and routers) more attractive in that an integrated solution
can be provided, with the subsequent reduction in administration, testing, and
required employee knowledge base. Some vendors are seen as specialists in the area,
relying on reputation, and above all on an excellent product (or product range).
Example equipment vendors include, but are not limited to:

Alcatel
Ericsson
LogicaCMG
Lucent
Nokia
Nortel
Telcordia
Capacity

Capacity issues for service platforms can be quite complex, with huge variations
in usage throughout the day (which can be expected and predicted), and in addition,
variations occurring as a result of specific applications. These variations in
demand could be triggered by advertising campaigns for certain content, televoting
(by standard circuit-switched call, or messaging, for example), or perhaps by world
events dictating mass network usage (New Year’s celebrations, as an example).
In all cases, the service must be effectively managed. This includes the service and
application handling itself, as well as any congestion condition. Any request for service
that is not satisfied directly results in lost revenue. In addition, if congestion is encountered,
and appropriate announcements or responses are not given to the customer,
they will be dissatisfied and reluctant to try later, again resulting in lost revenue.
One of the main requirements therefore is to balance the cost of equipment
against potential usage, taking into account lost revenue through congestion.
This is easier to achieve for some platforms than for others. For example, platforms
that primarily provide database applications (such as a home location register
in GSM) can be planned, with forecasts of subscriber growth allowing a steady
scale-up of network resources. A known history of usage patterns for the HLR on a
daily and seasonal basis can be catered for.

Other platforms are not so easy to plan. These are generally the service platforms
that support a range of services (or a single service) that are influenced by less
predictable variables. For example, a service control point (explained later) handling
a televoting service will hit congestion levels early (and remain there) if a vote that
had forecast to receive two million votes actually receives three million. Although
mechanisms do exist within the technology to handle the congestion, the lost revenue
is still a huge problem. In any case, scalability is a big factor in service platform
provision.

Upgrading the network must also be transparent to the customer, leading to
the requirement for a flexible architecture. This would allow one to view a single
functional entity in terms of access to the service, but with the functionality actually
provided by a number of physical entities (servers), as shown in Figure 3.31.
This gives the required flexibility and scalability, allowing the network to grow at a
planned rate, while ensuring that spare capacity is calculated to cater for peaks, but
not be so great that it is wasted investment.

Redundancy
Some services and applications may be more critical than others. The high revenue
services should be protected from congestion when a mass service scenario is
expected. In addition, services and applications can be very different, with widely
varying requirements.

For both of these reasons, it is usual for a network operator to implement a number
of different service and content platforms. Even when the platform is generic
(such as an Intelligent Network service control point), it would generally be the case
that different platforms would support different services. There may be a platform
for prepaid billing, one for dialed network services, one for fraud control, one for
mass calling type services, etc.

In reality, all of these chosen examples could be provided by a single platform but
common sense dictates otherwise. Having a single platform implemented for each
service would not be ideal either. First, capacity requirements may require more than
one platform, but the other compelling reason is that of resilience and redundancy.
Continued availability of any service, even under platform failure, is extremely
important; hence, it makes sense for a service to be available for use by the required
customers in at least two platforms. The platforms would ideally be sited in different
geographical locations