report - Light Reading

EDITORIAL
After 24 months of architecture, planning and design,
Telecom New Zealand recently announced how, in relatively
short order, we will replace the entire PSTN and be delivering
all our services for customers over the IP network. The first
residential customers will migrate onto the new network by early
2007 and eventually all of New Zealand’s 2.2 million customer lines
will be transitioned to the new platform in 2012.
One of the key objectives is to provide customers with more
control and flexibility whether they are at home, at work or on
the move. At the same time, we need to get new services to market
more quickly, and ensure that those services are more compelling
than other choices our customers may have. To do all that
while containing operating costs obviously means not only
changes in our operating model, but also some significant
changes in the technology architecture that underpins our
business.
Since it supports our fixed, mobile and on-line businesses,
that technology architecture obviously incorporates a wide variety
of different elements and systems. However, in simple terms
we could divide the technology into three main areas – the network,
service delivery and support systems (in which I include
what the industry traditionally calls OSS, BSS and network management).
If I were to arrange those three categories by how much we
spend, it would be the network first, followed by support systems,
and then service delivery a distant third. Now, since customers
buy services, which are largely driven by service
delivery applications, that third place means that service delivery
is arguably our most highly leveraged area of investment.
However, it is not just the revenue side of the equation that
service delivery impacts – it can also have a big impact on
reducing overall operational complexity and therefore cost.
That doesn’t have too much impact on our network spend, but
it can have a dramatic impact on reducing our other large technology
spend – support systems.
As an aside, it is interesting to observe the blurring of the
lines between service delivery and support systems. There are
many functions that were traditionally part of “support systems”
that are now also an integral part of “service delivery”. To take
an obvious example, rating (i.e. the application of pricing rules
to usage records to determine service charges) is simply a “support
system” in the case of the legacy PSTN, but is an active
part of “service delivery” for mobile prepay. This blurring will
itself become an increasingly important consideration that I’ll
come back to shortly.
Greg Patchell
A SERVICE DELIVERY
TRANSFORMATION PROGRAM
FOR TELECOM NEW ZEALAND
Before that, let me talk about some of the key principles we
adopted in the creation of our service delivery architecture.
Firstly, we emphasize common service enablers across our different
service delivery applications. As our architecture develops
those common service enablers will include presence, location
and “reachability” to enable services like advanced collaboration,
geographic promotions, and sophisticated mobility
services respectively.
Our initial emphasis has been focused on the most important
of common service enablers – an integrated profile. We
have invested significantly over the last three years to build a
common meta-directory for user and device information
across our entire range of next-generation fixed and mobile
services. This “meta-directory” has brought together many separate
user databases from disparate service delivery environments.
The results of this effort have included not only the ability
to bring brand new services to market much more quickly,
but also to significantly simplify the integration between the
service delivery environment and support systems. As we
approach PSTN migration, this profile capability is critical to
the practical implementation.
In effect, profile becomes the primary connection between
service delivery and support systems. This is because all new
service delivery applications are profile-driven. In other
words, to change the user’s service characteristics, you just
change the profile.
A very good example of this profile-based service delivery
is in the IMS (IP Multimedia Subsystem) architecture that is
being supported by an increasing number of standards bodies
including TISPAN for wired networks. In this architecture, the
HSS (Home Subscriber Server) contains all the profile information
required to determine the IMS user experience. In our
architecture, the HSS is synchronized with our meta-directory,
so as we move our “IMS-ready” applications to full IMS compliance
with separate HSS, there won’t be any significant
change required to support systems or service enablers.
IMS itself provides another opportunity to reduce complexity
of the application environment by sharing applications
and/or service enablers between fixed and mobile users.
Obviously this also offers the potential to deliver some converged
fixed/mobile services that are not practical with today’s
separate fixed and mobile control planes.
On the subject of IMS, I would also emphasize that IMS is
not the “be all and end all” of service delivery applications. It
is important to realize that IMS is primarily focused on next gen-
258 - Alcatel Telecommunications Review - 4 th Quarter 2005 www.alcatel.com/atr