Special Feature

Service Activation System: IP ServiceActivator
Saburo Seto†, Kenichi Yamane, and Souhei Majima
Abstract
In this article, we introduce our service activation system called IP Service Activator. It is divided into
a service module part, which consists of three kinds of scripts, and a platform part. It can handle a newservice flexibly simply through the addition of a new service module. This minimizes the range of codethat must be modified when service specifications change.

1. Service activation system
With the Internet being so popular not only in business environments but also with home users, telecommunication carriers and service providers are preparing various ranges of services such as VPN (virtualprivate network), VLAN/VMAN (virtual local areanetwork, virtual metropolitan area network), Internetaccess service, and VoIP (voice over Internet protocol). Telecommunication carriers must set up appropriate configurations of network elements (routers,switches, servers etc.) to provide these services. To
provide services on network elements (NEs), several
kinds of operations support systems (OSSs) are needed, such as a customer relations management system(CRM) and network resource management system(RMS). Among the OSSs, a system that accesses NEs
and sets up appropriate configurations of services iscalled a service activation system. In this article, we
introduce the service activation system called IP Service Activator, which NTT Network Service Systems
Laboratories has developed as a general service activation system.
2. Requirements for service activation systems
A service activation system accepts service orders(SOs), which contain service request information,from upper-layer OSSs such as CRM and RMS and† NTT Network Service Systems Laboratories
Musashino-shi, 180-8585 JapanE-mail: seto.saburo@lab.ntt.co.jp

Vol. 3 No. 10 Oct. 2005

provides services on the network (Fig. 1). The service
activation system must process numerous SOs andmust provide services to numerous NEs.
With the number of services provided by telecommunication carriers increasing day by day, service
activation systems must keep up with the expanding
service menus and provide service provisioning
methods. It needs to be easy to add a new provisioning method for a new service to the service activation
system. After a new service has started, the service
specifications and the commands of NEs will change
when the carrier starts a value-added service or when
the firmware of NEs is upgraded. To keep up withthese changes, the activation methods of service activation systems must be easy to change.
3. System architecture of IP Service Activator
The provisioning methods depend on the network
topology, service specifications, and know-how possessed by carriers. Once the code of the provisioning
methods has been embedded in the system, it cannot
be modified easily. Thus, the time required to develop new provisioning methods and modify current
methods tends to be long when a new service starts ora current service changes. To overcome these problems, the architecture of IP Service Activator consistsof two parts (Fig. 2): a service module part that
depends on the service specifications and a platform
module part that is independent of service specifications and provides common functions. The service
module part is a module-oriented architecture: service modules can be added and removed freely51

Special Feature

Customer relations management system

1) Receives application
for service

Network resource management system

2) Reserves network
resources

Wants to connect
Sites A and B
by a VPN.

SO
3) Acquires SO info.
Service activation system(IP Service Activator)

4) Processes SO5) Activates SO

Sets up the service’s
configuration on thenetwork

Site A
Site B

Fig. 1. Service activation system.

IP Service Activator

New service module isadded for a new service.

Service module part
VPN service
ScriptScriptVoIP service
ScriptScriptFTTH service
ScriptScriptPlatform partFig. 2. System architecture of IP Service Activator.

according to the service being provided. When a newservice starts, a new service module is added to the IP
Service Activator. As the specifications of the interface between the service module and platform parts
are defined, and these two parts are completely independent of each other, a provider can start a new service just by preparing a new service module. We
chose to use lightweight languages such as Python
and Perl for coding the service modules, so programmers can develop service modules in any environment in which scripts can run, such as on a personalcomputer. Our system reduces the development period and can handle changes to service specifications in52

a highly flexible manner because of the good characteristics of script languages, such as being easy tocode and easy to debug. In our typical cases, a service
module can be prepared within about two months.
The platform part supports SO operations andimproves their efficiency. It supports the flow of SO
operations from SO information acquisition fromupper-layer OSSs to NE provisioning. It provides
functions for parallel processing of SOs and exclusive access control to enhance performance and prevent interference to SOs. The operators can monitor
the status of SO processing via a Web client.

NTT Technical Review

Special Feature

4. Service module partThe service module part is divided into three partsand consists of three kinds of scripts to enable various
kinds of provisioning methods (Fig. 3). This divisionminimizes code changes when the service specifications, network environment, or NE command specifications change. The role of each script is described
below.
4.1 Type-Judge script
This script gets SO files containing application
information, analyzes the file formats, and judges thetypes of services and types of SO. That is, it judges
whether each SO is for a VPN or VoIP service andwhether it is a new contract, a change to current settings, an application for additional services, or contract cancellation, and so on. It registers SOs in the IP
Service Activator database.
As IP Service Activator can handle multiple TypeJudge scripts, these scripts absorb the differences in
SO file formats. Even if there are multiple upperlayer OSSs and each of them outputs files with different formats, IP Service Activator can prepare corresponding Type-Judge scripts.

4.2 SO script
An SO script accepts SOs that have been registeredby Type-judge scripts, divides them into parameters
for each setting target (e.g., routers, switches, andservers), and defines their setting execution order.
4.3 NE script
An NE script accesses an NE, issues configurationcommands, and activates a certain service. Generally,multiple NEs must be provided to activate one service, so multiple NE scripts must be executed. Theexecution order among the NE scripts is defined by
the SO script, and the platform part calls NE scripts
in execution order. When the service-providing network consists of multiple kinds of NEs, their settingcommands are different, so IP Service Activator canselect an NE script appropriate for the kind of NE.
5. Platform part
The platform part provides the functions that arecommon to all types of SOs. As described above, theservice module part consists of three types of scripts.
The platform part calls each script of the service modules sequentially and automatically. And to increase
the efficiency of SO operations and avoid interfer-

IP Service Activator
Service module part
VPN service
ScriptScript

SOService module

VoIPservice
Type-Judge script
ScriptScriptAnalyzes SO files, extracts
SOs, and registers themwith the system.

Platform part

SOID Service-Type Order-Type UserID
0001 VPN_basic
adduser001
0002 VPN_basic
adduser100

SO script

Divides an SO into parameters
for each NE.
Defines the execution orderof each NE script.
NE script
NE script
NE script

SOID Service (Type)
0001 VPN_basic(add)0001 VPN_basic(add)0002 VPN_basic(add)0002 VPN_basic(add)hostnamerouter-arouter-b
router-x
router-yseq.no12
1
2

Executes an NE script.

Fig. 3. Three scripts of a service module.

Vol. 3 No. 10 Oct. 2005

53

Special Featureence among SOs, it has parallel execution and exclusive access control functions.

ing, there is a big improvement in the number of SOs
that can be processed.

5.1 Exclusive access control of NE scripts
If NE scripts of two SOs try to access to the same
NE simultaneously, one or both of the SOs might be
set up incorrectly, depending on whether the NE supports multiple access and the issuing of simultaneous
setting commands. The platform part controls each
NE script so that it does not access an NE while
another NE script is accessing it. The platform parthas a queue for each NE, and NE scripts that provide
the same NE use the same queue and are executed infirst-in-first-out (FIFO) style (Fig. 4).
On the other hand, NE scripts that access different
NEs are executed simultaneously to enhance thethroughput of the entire SO processing. As in theexclusive access control mentioned above, the platform part has queues for each NE, so the platform
part places NE scripts in the queues and each queue
executes NE scripts in FIFO style independently.
This exclusive access control function can prevent
interference among SOs as well as NE scripts,
enabling IP Service Activator to process multiple
SOs in parallel. Compared with sequential process-5.2 Execution order control of NE scripts
When multiple NEs are needed to activate one service, we might have to keep a certain order in theirprovisioning. In IP Service Activator, this execution
order is created by SO scripts. The platform part calls
NE scripts according to the order in which SO scripts
were created. If an NE script fails to set up the configuration, the execution of the following NE scripts
must be canceled, so the platform part has a function
for canceling the following NE scripts.
6. Future work
IP Service Activator provides the functions thatcontrol service modules, in other words, scripts. We
think it is also applicable to fields other than SO operations, for example, to an NE testing system. However, for a testing system, realtime performance will berequired. Therefore, we are adding realtime features
to IP Service Activator.

IP Service Activator
NE scripts of SO-a
Service Platform
module part
part
VPN service
ScriptScriptVoIP service
ScriptScript
2 32NE scripts of SO-b
NE scripts of SO-c243Platform part
Execution order control

1

The SO with the lowest
number is executed. Others
wait until the preceding script
has terminated.
2 3 wait until 1 ends
NE scripts for different hosts
are executed simultaneously.

1
1

Numbers are the execution
order of each SO.

2
NE scripts for the same hostare executed one by one(in FIFO style).
An NE script accesses a hostand sets up a configuration.

Host A

Host B

Host C

Fig. 4. Parallel execution and exclusive access control.

54

NTT Technical Review

Special Feature

References
Saburo Seto
[1]

[2]

A. Ohizumi, T. Furukawa, M. Ogawa, and K. Yamane, “A Method ofProcessing Service Ordering Data for Various IP-Network Services,”
APNOMS2002, pp. 148-159, Sep. 2002, Jeju, Korea.
A. Yamada, S. Seto, M. Fujiwara, K. Yamane, H. Taniguchi, T. Sugai,and S. Imai, “The Execution Method and Issue of Service Activation
System,” IEICE Telecommunication Management 2003.

Engineer, Network Management Development
Project, Second Promotion Project, NTT Network Service Systems Laboratories.
He received the B.S. and M.S. degrees in information science from the University of Tokyo, in
1996 and 1998, respectively. He joined NTT
Network Service Systems Laboratories, Tokyoin 1998. Since then, he has been engaged indeveloping operations support systems.

Kenichi Yamane
Senior Research Engineer, Network Management Development Project, Second Promotion
Project, NTT Network Service Systems Laboratories.
He received the B.E. and M.E. degrees inmathematics from Nagoya University, Nagoya in
1986 and 1988, respectively. Since joining NTTin 1988, he has engaged in R&D of a CTRONbased realtime operating system and operations
support systems for the legacy PSTN. In 2001, hejoined the next-generation network management
systems development project. Currently, he isactively involved with IP communication management systems including VoIP. He is a member of the Institute of Electronics, Information,and Communication Engineers of Japan.

Souhei Majima
Senior Research Engineer, Supervisor, Network Management Development Project, Second
Promotion Project, NTT Network Service Systems Laboratories.
He received the B.E. and M.E. degrees from
Fukui University, Fukui Japan, in 1982 and1984, respectively. He joined Nippon Telegraphand Telephone Public Corporation (now NTT)
Laboratories in 1984. He has been involved in
the development of a computer-aided softwaredevelopment environment (CASE) system and aswitching equipment management system forlarge-scale networks. He is currently engaged inresearch on the operations support architecture
for the next-generation network.

Vol. 3 No. 10 Oct. 2005

55