Capacitacion VE Arquitectura 2017

Session 3
INDEX
 LOGICAL ARCHITECTURE
 MAIN SYSTEM PROCESSES
 TASK COMMUNICATION
MECHANISM
 MAIN BATCH PROCESSES
ADVANCED | Ericsson | 2014-03-25 | Page 2

Logical Architecture
OCS Logical Architecture
OCS Management System
The OCS Management System consists of the following key components:
 Provision
 Service query
 Service password management
 Graphic interfaces (GUIs)
 Interface converters
 Introduction
 AltamirA servers
 Customer Management (PPGA)
 Prepaid Operator (OPGE)
 Balance Control (PPCS)
 Scratch Cards Top Up Manager (RASCA)
 Annexes

› Target and audience

– Get necessary knowledge to understand Management System basic
operations.
› Training node map
– Introduction.
– Processes Architecture.
– External systems interfaces.

Logical architecture of Management System

PROVISION
› Systems in charge of managing the subscribers’ data. It consists of two nodes:
PPGA: Customer Manager

– Provides the basic services through the life cycle as well as the advanced
services
– Node responsible of the promotion and operation cost management.
– It is also in charge of logistics and line numbering provision.
– Furthermore, PPGA is responsible for storing and extracting not only the
information about the business (such as customer profiles, statistics and
information about the incomes and expenses associated to the operation), but
also about the subscribers themselves. This information can be broken down
for a later presentation.

PROVISION
OPGE: Provisioning operator

– Mediation between the services provision system and the network. Designed
to work on real-time.
– It receives requests to be implemented on the network. These requests
include, for example, sending SMS to the Short Message Service Centre
(SMSC).
– It also receives and manages requests for top-ups and operations and
transfers them to OCS-REW, if necessary. Moreover, it receives events from
OCS-RE and processes them.
– Another of its functions is to manage the subscribers life cycle.

PROVISION
OPGE: Provisioning operator

The following are mediation and provision actions with the network:
– Promotional top-ups / promotional top-ups cancellation.
– Timers expiry date.
– Sending of short message notifications CIMA
– Profile changes in the OCS-RE triggered by the user through network
elements.
– Top-ups and top-up cancellations from different origins (scratch cards, cash
machines, etc.).
– Events originated in the OCS-RE, activations and zero balance.
– User profile change.

PROVISION
RASC: Recharge Card Validation System

– System that receives top-up requests made through vouchers. It validates
these top-ups taking into account the top-up amount, the voucher validity, the
top-up itself and the possible promotions associated to it. This is carried out
through a request to OPGE.
– Top-up codes generation.
– Top-up code administration including top-up codes life cycle management.
– Online top-up execution (which involves sending a request to OPGE to
increase the user’s balance and changing the voucher status).
– Cancellations through top-up codes.
– It controls the fraud attempts made by subscribers who, repeatedly, enter
incorrect codes to get top-ups.

SERVICES QUERY
PPCS: Balance control

– It is the node in charge of controlling and storing subscribers’ traffic data.
– It receives the CDRs from the OCS-RE. These CDRs are filtered and
processed by PPCS who stores the final information in its database. The
registered information is shown in the call detail to the user who requests it, as
well as to the application’s managers. This information is also used for
statistics and economic audit.

SERVICE PASSWORD MANAGEMENT
System in charge of the keys management:
GECL: Access Keys Manager

– System that receives requests for the generation of access keys which come
from the external IVRs. It generates the anonymous key to access the web
server and transfers it to the user via a short message or a registered letter.
– It creates, stores, modifies, validates and controls the users’ access keys. It
allows defining different types of keys with different behaviours depending on
expiry date, time spent in a given status or total number of failed attempts,
among others.
– GECL also controls the life cycle of these subscriber’s passwords.

GRAPHICAL INTERFACES (GUIs)
Group of graphic applications that enables the access to the Altamira functionalities
from user-friendly environment:
BOWEB: Back Office Web

– It is a graphic interface that allows the administrators to carry out, from their
PCs, management operations over the customers subscribed to the Altamira
platform.
– From this application, many operations can be performed, such as:
› managing top-ups,
› configuring profiles of provisioned subscribers,
› querying subscribers’ characteristics, calls and operations,
› obtaining statistics and reports, etc.

BOWEB: Back Office Web

– BOWEb uses a web browser as interface.
– Altamira’s web server (Weblogic) interacts with Tuxedos to execute the users’
requests. Users have to log in to the corporate LDAP, and when they do so
successfully, the system obtains their user profile.
– Depending on this profile, the user (typically a customer care agent) may or
may not perform certain operations. The functionalities offered by BoWeb are
classified into two categories:
› Operations: The user can perform balance adjustments, top-ups, top-up
cancellations, etc.
› Queries: Current and archived operations, calls made over a period of
time, etc.

CPS: Products and Services Centre.

– Interface for configuring and parameterizing the system functionalities.
– It allows configuration administrators of the network provider (with enough
privileges) to load the configuration parameters via a user-friendly and simple
interface.
– Furthermore, there is a register of the operations made through the interface to
control the changes carried out in the configuration by the configuration
administrator.

AVS: Altamira Validation System.

– This module allows managing the users directories tree of the applications,
that is, their roles and functionalities.
– It allows inserting users into the LDAP tree, deleting a user from the LDAP
tree, changing users' password, managing profiles, etc.

Self-care web
– This application is a service offered to the subscribers in which, from a PC or a
mobile phone with access to the Internet, they will be able to manage their
services once he has validated his number with an access key.
– Internet Explorer or Firefox can be used to access the Self-care web from the
graphic interface.
– Customer can carry out in this web most of the operations defined for them,
such as query their call details or manage their lists.

INTERFACE CONVERTERS
This is a group of systems that allow converting the incoming technology into
a different outgoing one:
S2T: SOAP to Tuxedo converter.

– Account management.
– Balance management. It allows top-up operations, balance adjustments and
balance queries.
– Package management. It includes subscription/unsubscription to/from
packages, subscribers’ packages query, configuration of communication
settings and definition of promotion target.
– Usage control counter management. To control the amount of money that
subscribers spend on different traffics and services.

SNC: SOAP Notification Center.
› SNC (SOAP Notification Center) is the AltamirA element that is in charge of
providing the AltamirA ASN.1 interface for provisioning to external IT Systems.
› With the addition of SNC node inside OCS-MS architecture, AltamirA is able to
offer a synchronous interface to IT System.
› That means that SNC as well as being a node that acts as a ASN.1 to SOAP
gateway (responsible for mapping from ASN.1 to SOAP and vice versa), it also
offers a synchronous interface to external system.
› SNC is in charge of processing the ASN.1 external notification sent by AltamirA
once the action operation is completely performed in the system, and composing
and sending the SOAP response to the IT System that sent the request.
› Additionally, SNC has the mechanism to map any AltamirA internal error to a
concrete SOAP.

Service Provision
Tuxedo service call or SOAP
operation, in which case the
SOAP operation will be
converted in a tuxedo service
by S2T.
The tuxedo service contacts
PPGA (1,1b) to make the
request
Once the petition has been
carried out, a request task is
sent to OPGE (2).
The OPGE manager executes
the corresponding order script
to communicate with the
network (3) and carry out the
corresponding modifications.

Service Provision
Once the subscriber’s data
are updated in OCS-RE, an
answer is sent back to OPGE
(4).
After that, OPGE confirms the
operation execution (or the
error occurred if failure) to
PPGA (6)
). Depending on the action
that has been just confirmed,
an external notification can be
sent (7 or 7a, 7b) and/or a
promotion can be granted.
Finally, PPGA sends to OPGE
a request to send a SMS to
the subscriber (8). OPGE
takes this request and sends it
to CIMA (9).
Service Query
Like service provisions, queries can
be launched through calls to tuxedo
services (1) as well as through SOAP
operations (1a), in which case the
SOAP operation will be converted in
a tuxedo service by S2T (1b).
The tuxedo service queries the
requested information in the PPGA
databases.
If necessary, a tuxedo service is
called in OPGE (2) with a series of
parameters that have to be obtained.
When OPGE has these parameters,
it sends back in the query the value
of the requested parameters (3).
All the information is sent back to the
client who requested it (4 or 4a, 4b).

Storage of information related to the PPCS is in charge of the CDRs
service use storage.
OCS-RE sends the traffic data
records to PPCS (1), which stores
them in its databases for a later use.

Query of information related to the PPCS also manages balance control
service use information that can be queried from
corporate systems.
Tuxedo services (1) or SOAP
operations (1a), which are converted
in tuxedo services by S2T (1b), allow
making petitions to PPCS. The most
common type of petition is the call
detail.
The petition is generated from a
corporate system and it is sent to
PPCS. PPCS obtains the requested
information from its databases and
send it back to the corporate system
(2 or 2a, 2b).
A corporate system is an application
of the operator that connects with
Altamira.

OCS MS Prepay Card Life
Cycle

Cycle
› The operator logistics department provides the prepaid data (IMSI,

ICC, MSISDN) and reports to the management system platform the
batchs to subscribe.
› During the manufacturing time, before the cards are associated to the
MSISDN, the new lines are in initial state, e. i. not registered in the
network neither in the AltamirA platform.
› Subscription begins when the provider sends the physical SIM cards to
the operator and the states changes to preactive.

Cycle
› The state changes to preactive when it is provisioned in the HLR,
starting the activation process.
› Preactive blocked
› The MSISDN is registered in the HLR and in the AltamirA platform.
› Customer can not receive or send calls or SMS, as it is restricted in the
HLR.
› Preactive unblocked
› Account is subscribed in the SDP and HLR restrictions are updated.
› Unblocking process can be requested automatically by configuration or
manually.
› Customer can make voice calls and send SMS, but can not receive
them.

Cycle
› If the operator wishes to have control over the sales department, it should
use the "Preactive blocked" state, requiring to the dealers or sales points to
'unblock' the line at the moment of the sale, to avoid fraud.
› An expiration time before activation can be configured, so the lines that are
not sold shall be released or freed.
› All restrictions for each state can be configured and customized to fit the
operator specific needs.

Cycle
› The normal line state that can perform all traffic cases.
› Line can be activated by a voice call, SMS, top up or by any specific

operation.
› At activation, customer receives a welcome SMS reporting current

balance and expiration date.
› In this state, the customer has all functions available.
› The line will remain active for a configurable period of time. This
period is refreshed after a top up.

Cycle
› Trasition to outstanding can be configured to be triggered by
expiration of customer's balance, by exhaustion or both.
› Customers can lose the remaining balance, keep it or add it to later

top ups ("Grace Period" functionality)
› Outgoing calls and SMS are restricted, but still can receive them.
› A top up in this state changes the line to active state.

Cycle
› After a configured period of time, customers in outstanding state
that do not perform a top up, will move to outstanding 1.
› Neither outgoing and incoming calls or SMS can be made.
› State previous to 'freed/released' state.
› A top up in this state changes the line to active.

Cycle
› In this state, the customer lose control over the line.
› Unsubscription operation can be reverted during a configurable

period of time, restoring all the line original features (depending on
how the subscription was requested).
› After a configurable period of time, the number can be reused in a

new line. Former customer data is logged in database.

Cycle
› In this state, line services are suspended. All counters are 'freezed', not
consuming balances, timers, losing promotions, etc.
› Reasons to change to suspended state:

› Suspension for lost or thief.
› Voluntary suspension for holidays or absence.
› Due to 'Save plan' customers' morosity.
› Due to fraud in case of cloned terminals.
› The line can be a configurable maximum amount of days in this state before
being automatically released and changed to 'freed/released' state. In case
the suspension was requested by the customer, its original state is restored.
› The recovering process will recover the line's information and can be used
normally, keeping previous conditions before suspension: state, promotions,
timers, etc.

AltamirA servers

Main System Processes
PPGA
Customer Management
(PPGA)
Introduction
› Provides basic and advanced services through the

customer lifecycle
› Stores most of customers data, operation costs and
provides statistical information.
› Executes system operations and promotions

Customer Management
(PPGA)
Introduction
It is responsible for the implementation of the Promotion functional

module.
It collaborates with OPGE in the following modules, taking over the
back-end responsibilities of the following functional modules:
› Account Management
› Provisioning
› Refill/adjustment
It collaborates with PPCS taking over subscriber management data.

Customer Management
(PPGA)
Process Architecture
› pp_startprocess / pp_stopprocess
– Is in charge of the boot and halt of the processes in a certain order and a
configurable parameterization (PP_PROCESOS y PP_PROCPARAMS
tables). It checks the correct operation of the processes and launches them
if they are down.
– PPGA_INSTANCE variable in PPGA_CONFIGURACION
– The process generates a file, named pp_startprocess.up, in the /tmp
directory. This file is deleted when the application is stopped.
– In the PP_PROCESOS table, there is a record per each process, with the
process code, the binary name, the path where it is located, the number of
instances it
– In the PP_PROCPARAMS there are recorded all parameters to launch
each process

Customer Management
(PPGA)
› Request processes
– Process pending request operations inserted by tuxedo services, starts
operations in the system and generates a request task to the system.
– They are named starting with pp_ga_sol*.
– Each request process reads constantly the tasks table indicated in

PP_PROCTABTAR in order to process those request tasks in
PP_TARPROC in pending status.
– These processes make the corresponding checks in DB, for each request
task, and send a message with this information to OPGE through the
pp_if_envio sending process.

Customer Management
(PPGA)
› Request processes
– They are launched by the pp_startprocess process. Therefore, they must
be configured in the PP_PROCESOS and PP_PROCPARAMS tables.
– For example, the pp_ga_solrec (SREC) process knows which table it has
to read to process the tasks by querying the PP_PROCTABTAR table. At
the same time it knows which tasks it must process by querying the
PP_TARPROC table.

Customer Management
(PPGA)
– Sending processes
› PPGA sending processes check the database for pending operations
and process it when found.
› Process sends operation data to OPGE coded in ASN.1 using TCP/IP

and changes task state to 'executed'.
› PPGA sending processes' name begins with “pp_if_envio…”
› OPGE will return operation status with another ASN.1 message. A

listener process will receive it and create a pending confirmation task.
› They are launched by the pp_startprocess process. Therefore,
they must be configured in the PP_PROCESOS and
PP_PROCPARAMS tables.

Customer Management
(PPGA)
– Listening processes
› Process incoming confirmation/notification from OPGE node.
› PPGA listening processes' name begins with “pp_if_listener…”

Customer Management
(PPGA)
› Confirmation processes
– Process pending confirmation/notification operations and end the
operations in the system.
› They are named starting with pp_ga_conf*.
› Analyze returned data from OPGE and update all necessary tables in
PPGA database. The pending operation in the main operations table
inserted by the request process updates its status.
› Each request process reads constantly the tasks table indicated in

PP_PROCTABTAR in order to process those confirmation or notification
tasks in PP_TARPROC in pending status.

Customer Management
(PPGA)
› They are launched by the pp_startprocess process. Therefore, they must
be configured in the PP_PROCESOS and PP_PROCPARAMS tables.

Customer Management
(PPGA)
Operation default life cicle
› A notification is an event sent to the system without a
direct request (e.i. expiration notifications, first call events,
scratch card tops ups, etc)
› Notification task (Nxxx)

› PPGA confirmation processes check the database for pending
notifications tasks and process it when found.
› Analyze the data sent from OPGE and update all necessary
tables in PPGA database. An record is created in main
operations table with its final status.

Customer Management
(PPGA)
External notification
› The External Notification is a system to inform about executed
confirmations or notifications (in ‘Executed’, ‘Rejected’ or ‘Erroneous’
status) to an external system.
› The External Notification processes are pp_if_envio_externo type.

They are launched by the pp_startprocess process.
› The external notification processes read the external notification

request tasks from the corresponding tasks table and process them
for their sending. Once sent, the external notification request tasks
are marked as ‘Executed’.

Customer Management
(PPGA)
External notification
› The following actions trigger external notifications:
› • Top-ups
› • Purchase of bolt-on
› • Subscription to periodic actions and
› • Quality of service control

Customer Management
(PPGA)

Customer Management
(PPGA)
› Operation request
– Tuxedo service call
› A valid client connects to tuxedo
JSL/WSL to request an operation
execution.
› Tuxedo server parses the requests and

performs some checks in the database.
› A pending request is inserted in the

database, in order to be processed by a
request process.

Customer Management
(PPGA)
› Operation request
– Petition insertion
› Tuxedo will enter a petition task (‘P---’) in
pending status in the corresponding tasks
table Tasks tables are easily identified by
their name: PPGA_TAR*.
› They store all the tasks involved in
the same operation. They also
indicate the status of the tasks.
Therefore, querying these tables is a
means to view the stage of the
operation processing.
› Petitions are left in pending status,
until they are processed by the
corresponding request process.

Customer Management
(PPGA)
› Requesting processes
– Request processes (pp_ga_sol*)
constantly read tables containing tasks
associated with them and process.
– The expression “task processing” refers
to checks made in the DB and entering or
updating operations in the tables
associated with each petition (detail
tables, actions tables).
– If the process executes the petition task
successfully, it is set to ‘Executed’ and a
commit is made in the DB. Otherwise, it is
set to ‘Erroneous’ and a rollback is made.
– It then enters in the tasks table a request
task (‘S----‘) in pending status.
Customer Management
(PPGA)
› Requesting process
– After it, it records the action in pending status until it is completely
executed in the PPGA_ACTABOPRE table for the subscriber in
particular.
– In the PPGA_ACTUTAR table, the request task sequence, which will
be sent to the OPGE node afterwards, is associated with the
sequence of the action that has been requested. This way, the
confirmation of the operation is identified when the PPGA node
receives the confirmation task from the OPGE node.

Customer Management
(PPGA)
› Request encoding and sending
– The request task, which is in pending status,
is taken by an instance of the sending
interface, the pp_if_envio process.
– The request task is then executed and the

interface sends the needed information to the
OPGE node through TCP/IP by encoding the
information in ASN.1.

Customer Management
(PPGA)
› Incoming response from OPGE
– At a given time, a message identified as
a confirmation task arrives to the listening
ports (pp_if_listener) from the OPGE
node.
– The interface then inserts the
confirmation task in the tasks table in
pending status.

Customer Management
(PPGA)
› Finally, a confirmation process starting with
pp_ga_conf* reads the PPGA_TAR* table and
processes a confirmation from OPGE
› After updating the tables associated with it, both,
the confirmation task and the action are set to
‘Executed’. The operation is eventually finished.
› The PPGA node checks the PPGA_ACTUTAR
and PPGA_ACTABOPRE tables to relate the
confirmation with a particular action for a
particular subscriber. In the PPGA_ACTUTAR
table there is a record until the action is set to
‘Executed’ in PPGA_ACTABOPRE.

Customer Management
(PPGA)
› Notifications from OPGE
– Operations that were not started in the PPGA node: the OPGE node or any
other AltamirA node did it.
– As a result, when a notification arrives, there is no action related to it (if it
were a confirmation it would actually exist). The confirmation process then
inserts the action directly in ‘Executed’ status.
– Detail tables (i.e. PPGA_RECARGAS) related to the operation must be
completed with the data received from OPGE.
– As for notifications, the PPGA node only stores the received information,
but it does not check anything, as it does for Tuxedo petitions. The reason
is that a petition received in a Tuxedo service can be rejected if it does not
meet certain conditions. However, notifications cannot be rejected, since
they inform of operations already executed.

Customer Management
(PPGA)
› External notification sending and EDRs generation
Once executed a confirmation or a notification, it is possible to
generate an external notification and/or an EDR file.
The sending may be configured per action, status of the action, user,
tariff plan… (PPGA_CONFNOTEXT for external notifications and
PPGA_CONFEDR for EDRs).
The process in charge of external notifications generations is

pp_if_envio_externo and the process in charge of EDRs
generation is pp_ga_soledr.

Customer Management
(PPGA)
› In case of error
– If the task being processed in the PPGA node causes a failure, its
status is changed from ‘Processed’ to ‘Erroneous’. It may be re-
processed exceptionally if the status is changed manually and a
search reference is entered, so that it can be taken by the sending
process.
– If OPGE founds an error while processing a task its behaviour
depends on the type of error which is found:
› A rejectable error occurs. For example, the subscriber does not
have enough balance to perform the operation. In this case,
OPGE returns an error code different from zero in the
confirmation task.
› A non-rejectable error occurs. For example, OCS-RE is busy at
this moment. The execution of the operation is rescheduled and
no confirmation task is returned.
Customer Management
(PPGA)
EDRs
› The EDRs are text files that, as well as the External Notification,
inform about executed confirmations or notifications (in ‘Executed’,
‘Rejected’ or ‘Erroneous’ status).
› The EDRs text files are left in a configured path.
› The EDRs generation processes are pp_ga_soledr type. They are

launched by the pp_startprocess process.
› The EDRs generation processes read the EDRs generation request

tasks from the corresponding tasks table and process them for their
generation. Once generated, the EDRs generation request tasks are
marked as ‘Executed’.

Customer Management
(PPGA)
Data model
› Customer data tables
› Contains information on the customers and acquired benefits
› Configuration data tables
› Task configuration
› Processes configuration
› Environment variables configuration
› Operations configuration
› Promotions configuration

Customer Management
(PPGA)
Relationships with other
nodes
› Relationships with other nodes
› PPGAOPGE: PPGA sends operation requests to the OPGE and
receives their confirmations and notifications. There exists a dialogue
between both nodes that enables to carry out the service management.
› PPGA  GUIs: PPGA provides all the necessary information,
required by the GUIs, to manage the customers.
› PPGA  Commercial Systems: The commercial system
communicate with PPGA to request operations and information about
subscribers.
› PPGA PPCS: PPGA communicates the subscribers
subscription/unsubscription to PPCS. It also sends subscriber detail
information to PPCS when it is required.
› PPGA  External Notifications/EDRs: PPGA communicates the
confirmation or a notification execution to generate an external
notification
ADVANCED and/or
| Ericsson | 2014-03-25 | Page 61 an EDR file.
Customer Management
(PPGA)
Subscriber tables
› Actions: PPGA_ACTABOPRE, PPGA_ACTPROMO

› Top-ups: PPGA_RECARGAS
› Bolt ons: PPGA_ADQUISICIONES, PPGA_BONOPRE.
› Subscriptions: PPGA_SUSCRIPCIONES
› Status change: PPGA_CAMBEST
› Tasks: PPGA_TAR%

OPGE
Prepaid Operator (OPGE)
Introduction
OPGE is a system of provision and mediation of events

between the Back End and the PLMN (Public Land Mobile
Network) that works on real-time. It receives requests that
are implemented online.
Prepaid operator has three main responsibilities:

– It is responsible for the mediation with the OCS-RE and other external network
elements.
– It receives requests to be implemented on the network. It also receives and manages
requests for refill/adjustments and operations and transfers the appropriate
commands to the OCS-RE if required.
– It is also in charge of the account lifecycle management.

Processes in OPGE
CMC - Creation process of shared memory and semaphores.
MAS - Start and stop process of the system.
CNF - Shared memory and semaphore configuration process.
MAC - Connection start module: module used to communicate with
RASCA.
CAP - Process Activation Controller.
Listening processes (EXX): listener type processes.
Answering processes (RXX): processes that decode the messages
received by the system and send them to the corresponding managing
process by means of IPC queues.

Processes in OPGE
Managing processes GXX: processes that manage the operations.
Controlling processes CXX: processes that deliver the operations to the
Handlers.
Handling processes MXX: processes that communicate with the network
nodes.
Ordering processes OXX: processes in charge opening the connection
with the station and sending the orders.
Interfaces with Remote Systems: processes in charge of translating the
message into the language of the remote system.
Scheduling processes: processes in charge of executing the scheduled
operations.
PIA processes.
Tuxedo.


› Semaphores and shared memory creation processes (CMC)
› po_co_cremencon: first process to boot, it loads shared memory zones and
semaphores
› The configuration of the memory areas and the semaphores that are to be
created are located in the table POCO_CONFIPC.
› System start and stop process (MAS)

› po_co_modarrsis: Boots applications and checks all processes keep running in
memory
- Processes boot order matters and it is the inverse for stopping
- If any of the processes is killed, it would be started again a certain number of

times
- The configuration of the start and stop of the application is made by means of
the following tables: POCO_ARRANQUE, POCO_PARADA and
POCO_PROCESOS.
› Shared memory configuration process and semaphores (CNF)

› po_co_conmemcom: Loads into memory all needed configuration data to avoid
database access.
› Connections boot module (MAC)

› po_co_modarrcon: Boots MEM modules in charge to communicate with RASCA
› Processes activation controller (CAP)

› po_co_conactpro: boots batch process when requested manually, via crontab or
with a tuxedo call.
› The CAP starts the batch process when a scheduler or a Tuxedo service
requests it. This process admits an undefined number of parameters.

› Listening processes (EXX)
› po_co_proesctcp : identified as EXX with a designated port.
› When a message is received, a reponder process is started to manage

it.
› Responder processes (RXX)
› Always named as "po_co_res…" and "po_ge_res…"
› Decode the received frame (usually in ASN.1) and send it to the

corresponding manager using IPC message queues.

› Manager process (GXX)
› Always named as "po_ge_ges…" and containts service logic.
› Two behaviours:
1. After some internal checking and updating the system answers to

the requesting system using the corresponding interface.
2. After some internal checking and updating the system, if needed

to communicate with some external network node, it sends a
message to the corresponding controller.
› These processes can schedule operations.

› Controller process (CXX)
› Always named "po_co_con…" and manage the number of running manager
instances.
› These are the processes in charge of controlling the number of handlers that are
running performing operations and releasing the managers from this control task
(so they can perform more important tasks).
› This happens this way because the connections with the network nodes are
always waiting for an answer and, if controllers did not exist, the performance of
the managers would be lower.
› Depending on which node connects, there are:
› CCS: Communicates with the SDP
› CCH: Communicates with the HLR
› CEM: Communicates with the CMC
› CSR: Communicates with external nodes, remote systems controller

› Handler process (MXX)
› Process and manage communications against nodes external to OPGE.
› The handlers transform the operations to be done into orders against the
stations. Once a message has been received from the controller, they encode it
depending on the destination node and establish a dialogue with it by means of
commands.
› Besides, in case of problems (for instance, network problems), the handler
communicates them to the controller for it to schedule the traffic to the
corresponding station.
› Depending which node it manages, there are:
› MPS: SDP handler
› MPX: HLR handler
› MMT: Short messages module
› ERG: Generic handler

› Ordering Processes (OXX)

– They are in charge of opening the connection with the station, coding the
order in the protocol used by the station, send the order, and receive the
station response.
› There are different ordering processes:
– ORI: po_co_ordiog (it sends orders to the HLR AXE).
– ORS, OSA, OSB, OSC: po_co_ordsdp (it sends orders to the OCS-RE
stations).

› Remote systems interface (IXX)

– The interfaces are normally Ixx type (xx will be the letters identifying the
process). These processes are in charge of answering to the origin node.
That is to say, the one that made the request to the operator.
› There are different Remote System Interfaces:
– IGE: po_co_intgensis. Generic Interface that answers to the Provider.
– IRR: po_ge_intrecras. Interface that answers to RASCA.
– IRB: po_ge_intrecban. Interface of Top-ups from Bank Networks.
– ISE: po_ge_intsalexp. Interface of Notifications to Express Balance

› Scheduling process (PLA)

› It is in charge of processing the scheduled operations (by sending a
message to certain process), as well as receiving messages to schedule
operations.
› Among others, it manages the next execution date, process that will
receive the request, process that originated it, info of the request, etc
› This process is po_co_plaprosis (system process scheduler).
› It is supported by the tables POCO_PLANIFICA (PLA),
POCO_PLANIFHLR (PLH), POCO_PLANIFSDP (PLD),
POCO_PLANIFSMS (PLS), where the following is stored

› Maintenance processes
Card Expiries: po_ge_mancadtar
Promotion Expiries: po_ge_mancadpro
Card Expiry Warnings po_ge_manavicad
Promotion Expiry Warnings: po_ge_manavipro
– PIA processes
› The PIA processes (IGE insertion processes) receive the messages
from the answerers and, according to the PPGA petition received, they
insert a record in the table POCO_OPERAxxx corresponding to the
answer to be sent.
› Besides, they store the input parameters received. Once the record has
been inserted, it sent the petition to the corresponding managing
process.

› Tuxedo services
› The Tuxedo services operate in the same way as in other nodes: They
are used to make certain type of calls to the operator. Ex.: Balance
query, management of lists from SIPS, etc.
› Most of the OPGE tuxedos are query ones.

› MES process:
› Allow to follow operation steps by showing the events on the screen:
› View modes:
› Mode 1: All events are displayed (green, yellow and red)
› Mode 2: Only warning and error events are displayed (yellow and red)
› Mode 3: Only error events are displayed (red)

Operation default life cycle

Data model
› Customer data and state changes tables
› Contains information of customers, status and validity period.
› Top up tables
› Contains information of top ups and its reference code
› Wallet status tables
› Contains information of the customer wallets and its validity periods
› Configuration tables
› Contains the system configuration

Interfaces
› Relation with other nodes:

› OPGE Client Interface: Queries.
› OPGE  HLR and OCS-RE: Provision.
› OPGE PPGA: Continuous management dialogue.
› OPGE RASCA: Top-up and cancellation requests.
› OPGE GEAC: Message sending requests.
› OPGE  External Systems: Bank connection, top-up and
cancellation

PPCS
Balance control (PPCS)
Introduction
› Controls and stores traffic data of prepaid customers.
› PPCS receives the files with all the information of the voice calls, SMSs and
any traffic case the customer can perform.
› Receive the files from the SDP, processes and stores them in the database.
› Provides details on the call records, statistical and financial audits.
› Generates EDR files from incoming CDRs

› Generic interface
› Processes in charge to receive the CDRs (Call Data Record) and

communicate with other SG nodes
– pp_if_listener: for incoming TCP/IP connections. It receives tasks

or CDRs.
-- pp_if_respondedor, started up by the pp_if_listener process

when a connection that has been received is accepted. It receives
tasks sent by the customer application through the generic interface
protocol.

– pp_if_envio: it sends tasks queued to the destination, through the

generic interface protocol for tasks.
– pp_if_respficheros, launched by the pp_if_listener when a

connection that has been received is accepted. It receives the file
sent by the customer application through the RTP protocol.

› The listener receives as parameter the listening port when it is launched.
› Depending on this port, the listener knows whether it has to receive call
CDRs or short message CDRs.
› Once the petition has been received, it launches a child process –

pp_if_respficheros–, which is the one who really receives the CDR.
› CDRs are sent every 15 minutes or every two Mb.

› CDR files distribution and processing
› Two processes take part in file reception processing in PPCS. One receives
files and distributes their processing. The other one (launched by the previous
one) processes these files. Both need to be configured so that their deployment
is established
– The pp_cs_distficheros_perm process explores an input directory and
orders one of its permanent processors, which are pre-started, to process
the file.
– Several entry directories can be configured, but only one distributor process
for each one.
– The pp_cs_procficheros_perm, launched by pp_cs_distficheros_perm,
processes the file indicated by distficheros_perm and notifies to it the
result.
– It is in charge of the processing of the assignated CDR file and the
generation of the corresponding EDR (event data record) if configured.

› Distribution and processing of CDR files
› The following directories need to be configured:
› A temporal directory to receive the file till its download has been
completed.
› An input directory where the responder process will move the file once
fully downloaded.
› An output directory where files will be moved once processed.
› An error directory to move the CDRs with problems or errors during the
processing.
› These directories are configured in the

PPCS_CONFIGURACION_GENERAL table

CDR processing

CDR processing
› The listening process (pp_if_listener) answers connection petitions in the port

entered as parameter.
› As soon as it receives a connection petition, it launches a child process, which
answers the connection (pp_if_respficheros_perm) when receiving the file
with the CDRs.
› The answering process dumps the file to a temporal directory. The directory is
defined in the PPCS_CONFIGURACION_GENERAL table.
› Once the file has been received, the answering process moves it to an input
directory. The directory is also defined in the
PPCS_CONFIGURACION_GENERAL table. This is made this way to avoid
the distribution process from taking the files before they have been completely
downloaded.
› The distribution process examines the directory searching for new files. It must
have run a file for each directory to avoid that the same file is doubly
processed.

CDR processing
› After this, the distribution process sends a message to a processor informing of

a file existing. The processor queues the message if it cannot process it right
away.
› The processor, according to the file name, invokes the corresponding library
function. The processor knows which library is to be invoked thanks to the file
name. The library function decodes the ASN1.
› The information contained in the CDR, once translated, it is entered in the
corresponding table. Dump tables (for CDRs) contain a field called
tip_llamada. The type of call is registered here, according to some rules
established by the network provider (please see 2.2.4 Content classification
tables).
› Later on, the file of processed CDRs is sent to an output directory (if everything
has been correctly executed) or errors directory. To determine if a file has or
has not been correctly executed, there is a parameter in the
PPCS_CONFIGURACION_GENERAL table of the distribution process
indicating the error percentage allowed while the file processing.
CDR processing
› Finally, tables where the processed files are controlled are updated:
PPCS_ARCHIVOS (information about files coming from the OCS-RE) and
PPCS_ARCH_DET (detailed information per type of records of the files coming
from the OCS-RE).

CDR error processing

CDR error processing
› When processing a CDR, the following values can be returned:
› SIN_ERRORES: 0 errors
› DUPLICADO: Duplicated file, already processed
› COMMIT: Processed with errors under the acceptable error threshold
› ROLLBACK: Processed with errors over the acceptable error threshold
› ERROR_SIST: System error
› MAX_REINTENTOS: Maximum number of retries reached
› NOMAX_REINTENTOS: Maximum number of retries not reached yet

Data model
› Customer data tables
› Financial reports tables
› File control tables
› Content clasificación tables
› CDR files storing tables

Interfaces
› Relationships with other nodes:

› PPCS   PPGA: PPGA may query PPCS Tuxedos and vice versa.
› PPCS   CPS: this relation allows configuring several commercial

rules, such as XML trees, tariff plans, bolt-ons, lists, etc.
› PPCS   Self-care Web and BoWeb: PPCS provides all the

information requested about the call detail and statistics information.
› PPCS  OCS-RE: PPCS receives the CDRs sent by the OCS-RE.

RASC
Scratch Cards Top Up
Manager (RASC)
Introduction
› RASCA main functionatilies are:
› Top up codes generation
› Top up code life cycle management
› Online top up codes validation and execution or cancelation of the

top up
› Fraud control
› Top up codes and operations query detail
› Wholesalers management

Manager (RASC)
Introduction
› RASCA manages top up scratch cards. Scratch cards allows the customer to
perform a top up by introducing the code printed in the card. The top up will be
executed taking into account the amount, the card validity and the promotions
associated to it (if any)
› Top up codes are made of the following sequences:
› Administrative code:
› Identifies the card (control digit)
› Not encrypted
› Top up PIN code
› Code the customer must introduce to perform the top up

Manager (RASC)

Manager (RASC)
› Shared memory creation processes and semaphores (CMC)
› First to boot as it loads necesary shared memory zones and

semaphores
› System start/stop processes (MAS)
› Boots applications and checks all processes keep running in memory
› Processes boot order matters and it is the inverse for stopping.

(ARRANQUE, PROCESOS)
› If a MAS direct child dies, the MAS process will try to respawn it.
› Tuxedo boots after application and it also must be stopped before.

Manager (RASC)
› Connection boot module (MAC)
› Boots the MEM modules for connecting to OPGE
› Scheduling processes (PLA)
› Processes scheduled processes (PLANIFICA)
› Listening processes (MRM and PEI)
› External system messages reception module that starts the corresponding

responder
› MRM: Receives messages from OPGE and starts the responder RRM
› PEI: Receives messages from SIP and starts the responder PRI

Manager (RASC)
› Responding processes:
› Decodes messages received in the system and send them to the

corresponding manager process
› RRM: OPGE responder (MRM)
› PRI: SIP responder (PEI)
› MEM : Send messages to OPGE
› Top Up manager process (GTR)
› Receives top up requests and process them
› Fraud control lists manager process (GML)
› Fraud control. In charge of the management of the fraud control lists

(LISTANEGRA,
ADVANCED | Ericsson | 2014-03-25 | Page 104 LISTAGRIS y FALLORECAR)
Manager (RASC)
› Processes activation controller (CAP)
› Manages batch processes (database maintenance, scratch cards

expirations, etc)
› Maintenance processes
› MRT: Scratch cards database tables maintenance
› CCT: Scratch cards expirations
› MRL: Fraud control lists maintenance
› Tuxedo
› Tuxedo is managed the same way the other nodes

Manager (RASC)
› Automatic top up codes generation (GCA)
› Generates automatically top up codes on demand
› Generates the codes waiting to be associated to a request reference
› Top up codes generation
› In charge of cards generation
› Generates top up cards in 'initial' state with a request reference .
› If there are not enough cards, GCA process is spawned to generate

more
› Only one instance can be running simultaneously

Manager (RASC)
› Monitoring
› MES process: Allow to follow operation steps by showing the events on the
screen.
› View modes
› Mode 1: All events are displayed (green, yellow and red)
› Mode 2: Only warning and error events are displayed (yellow and red)
› Mode 3: Only error events are displayed (red)

Manager (RASC)
Scratch Cards Generation

Manager (RASC)
Scratch Cards Generation
› From the interface a tuxedo will be invoked, requesting GCC the generation of
the cards (it associates to each top up PIN an administrative code and inserts
the generated data in the database)
› Each generation request administrative code identifies it and allow to query for
the request status
› The generated codes are stored in the system for further use and query. The
system also generates an encypted file containing the codes for distributing to
the cards manufacturers
› Once the cards are made they are sent to the sales channel

Manager (RASC)
Scratch Cards Life Cycle
Diagram

Manager (RASC)
› Initial
› The voucher is generated by the voucher generation system and included in
the database of the top-ups manager. Vouchers are sent to the printing
company to be created.
› Pre-active
› Once the voucher is printed and ready to be sold, it is changed to this state.
› Active
› When the vouchers are in the channel of sale they are changed to active state,
so they can be used.
› Cancelled
› The state of the vouchers may be changed to Cancelled at any moment of the
process to avoid fraud.

Manager (RASC)
› Topping-Up
› State between the Active and the Used states. The top-up voucher will be in
this temporal state while the systems carry out the required checks and
increase the customer's balance.
› Used
› The voucher reaches this state when it is correctly used to make a top-up.

Manager (RASC)
› Reusing
› This state is reached when a top-up cancellation is requested, and the
voucher is changed from used to active state. This is the temporal state
of the voucher while the systems perform the required operations and
checks to change the voucher to Active state.
› Expired
› This state is reached by those vouchers that have not been used when
their expiry dates are reached. This is the only automatic state
transition made in the system that is performed through a top-up codes
expiry process. In case of the electronic code sending with security,
there exists an automatic process that changes the transition of the
electronic codes to Active when the wholesaler sends back the
confirmed bulk load file.

Manager (RASC)
Scratch Card Top Up

Manager (RASC)
Scratch Card Top Up
› A customer request a top up through a terminal by introducing the code
obtained in the card.
› SIP connects to the RASCA node in AltamirA and sends the top up request
› The listener process PEI receives the connection and spawns a responder PRI.
PRI receives the request data and sends it to a top up manager GTR. The
manager will check:
› The code inserted by the customer is associated to a card that exists in the
system
› The card is in active state
› The customer is not in any fraud list

Manager (RASC)
Scratch Card Top Up
› If all the checks are successful, RASCA will request the top up to
OPGE through the MEM sending messages module
› OPGE will validate the customer and report back to RASCA the
operation is been processed. A request to the SDP is sent to increase
customer balance
› Once OPGE receives from SDP the top up confirmation, it notifies

RASCA to update the card status.
› OPGE will also report to SIP the final status of its original top up
request. It will also notify to PPGA a top up has been made to apply
later top up logic (e.g. promotions)

Manager (RASC)
Data model
› Configuration tables
› Contains system configuration
› Top up data tables
› Contains the scratch cards data
› Fraud control tables
› Tables related to the fraud control
› Others
› Tuxedo services errors descriptions
› Wholesalers data tables

Manager (RASC)
Interfaces
Relaciones con otros nodos:
› RASCA - Client Interface: Tuxedo Services
› RASCA - OPGE: TCP/IP (ASN.1)

S2T
SOAP to TUXEDO S2T
INTRODUCTION
› SOAP interface of the OCS Service Management layer for To2 DE
provides to external IT Systems a collection of services covering the
following functional areas:
– Account management
– Balance management
– Package management
– Usage control counter management
– Cyclic actions management
– List and tribe management
– Product configuration management
– Common
› Since management actions actually take place in the OCS_MS external
system as a collection of TUXEDO services, there must be a node that
maps both interfaces. This network element has been called SOAP To
TUXEDO (S2T) Converter.

SOAP to TUXEDO S2T

1
SOAP to TUXEDO S2T
External interfaces
SOAP
If several major versions of the SOAP Interface must be offered following
the backward compatibility policy S2T will expose all of them through
different SOAP EndPoints.
In the context of WSDL versioning, major-minor versioning can be used
to distinguish between changes to a service contract that maintain
backwards on-the-wire compatibility with existing service consumers
(minor changes), and those that break this compatibility and force a re-
write of service consumer code (major changes).

1
SOAP to TUXEDO S2T
Internal
OCS-MS proprietary interface
At the present S2T uses two E/// proprietary communication interfaces
with the OCS-MS:
Tuxedo interface (using the PPGA, PPCS and RASCA Tuxedo services
catalogue).
External notifications ASN.1 over TCP/IP.
SNMP
SNMP interface provides the capability to send SNMP traps from S2T to
the OCS-ME. SNMP MIB is E/// proprietary.
Counters files
Counter files with an E/// proprietary format are sent to OCS-ME element
for statistical purposes.

1
SOAP to TUXEDO S2T
INTRODUCTION
› There are two types of SOAP requests:
› Query request (correspond to idempotent services): These request do

not change the internal state of the system. They are queries that are
process synchronously.
› Action request (correspond to non-idempotent services): These request

changes the internal state of the system and are processed
asynchronously by OCS-MS nodes.

SOAP to TUXEDO S2T
QUERY REQUEST

SOAP to TUXEDO S2T
ACTION REQUEST
For certain SOAP operations,

S2T has to concatenate
several calls to different
Tuxedo services, and when
responses are received it
combine all of them for
generating the final response.
In these scenarios the flow to
execute is the shown in the
figure above but after the
processing of the first request,
S2T continues sending a new
Tuxedo request to other
service.

SOAP to TUXEDO S2T
Mapping
SOAP to TUXEDO mapping process

S2T for each SOAP operation supported implements a particular SOAP to
TUXEDO mapping parameters rule. It is responsible to fill each TUXEDO
parameter with a concrete value result of this mapping process.
TUXEDO to SOAP mapping process
S2T for each query operation supported implements a particular TUXEDO to
SOAP mapping parameters rule. It is responsible to fill each external SOAP
parameter of the response with a concrete value result of this mapping process.
ASN.1 to SOAP mapping process
S2T for each action operation supported implements a particular ASN.1 to SOAP
parameters mapping. It is responsible to fill each external SOAP parameter of
the response with a concrete value result of this mapping process.

SOAP to TUXEDO S2T
Counters
O&M. Counters
System behavior and usage is logged in the form of counters that reflect what is
demanded to S2T and what is the statistical outcome of the system. This
component is responsible for generating counter files and save them, it also
controls if there is enough disk space to generate the counter or in other case
arises the proper alarm.
Finally, it is responsible for sending counter files using TCP sockets to OCS-ME
periodically. When the file is sent it is removed from S2T machine.

SNC
SNC – SOAP Notification
Center
INTRODUCTION
› SNC (SOAP Notification Center) is the AltamirA element that is in
charge of providing the AltamirA ASN.1 interface for provisioning to
external IT Systems.
› Provision and Management operations in AltamirA really take place in
other OCS-MS nodes, SNC for example. That node offers connection
with a collection of Tuxedo services that can be distinguished for being
query operations or actions operations that performs changes in the
system. IT Systems has the capability to register to external
notifications and to be informed when certain actions are performed in
the system.
› With the addition of SNC node inside OCS-MS architecture, AltamirA is
able to offer a synchronous interface to IT System.

Center
INTRODUCTION
› SNC as being a node that acts as a ASN.1 to SOAP gateway
(responsible for mapping from ASN.1 to SOAP and vice versa), it also
offers a synchronous interface to external system.
› That means that SNC is in charge of processing the ASN.1 external
notification sent by AltamirA once the action operation is completely
performed in the system, and composing and sending the SOAP
response to the IT System that sent the request.
› Additionally, SNC has the mechanism to map any AltamirA internal
error to a concrete SOAP Exception with the corresponding error code.
› SNC is a webservice what is deployed on the OCS-MS platform. So,
the hardware architecture consists of:
– Web Service level: it will take place the processing of different services
deployed throughout the platform will take place at this level.
– Database level: it provides a database for storing information such as
platform configuration, services or subscribers.

Center
INTRODUCTION
PPGA
OCS-MS
ASN.1 ASN.1
External Notification A External Notification B
TCP Port X TCP Port X+1
SOAP Notification
Center
SOAP SOAP
ExternalNotification A ExternalNotification B
IT System IT System
Notication Notication
consumer 1 consumer N
Center
INTRODUCTION
› Examples of the events that can generate external notifications are:
– Top-Ups
– Adjustment
– Automatic changes in the lifecycle of the subscriber
– First usage: first call/sms/mms/data traffic/sertacon charge
– Promotions launched by Altamira
– Multiple recharge autocancelled
– Cyclic actions. For example, for a cyclic charge, every time there is a
change of status, an external notification has to be generated.
– With regard to wallets, when the balance has decreased below a configured
threshold or a wallet is close to its expiry date, a notification can be sent to
the subscriber.
– In connection with bolt ons, it is possible to configure the generation of an
external notification in case of:
› Bolt On subscription
› Bolt On unsubscription
Center
INTRODUCTION
› Examples of the events that can generate external notifications are:
› Bolt On expiration
› Bolt On threshold reached
› Bolt On renewal
› Last Bolt on renewal
› Reminder: X days before each renewal
› Last Reminder: X days before the end of the last cycle
– End of the last cycle: End of the cyclic action

Center
Execution flow
Sequence diagram,
interaction between PPGA,
SNC and IT System.

Center
Execution flow
•PPGA sends an external notification to a certain IP and port. The IP has to be
one of the available SNC IPs. The dispatch algorithm used by PPGA to select the
IP is Round Robin between all the machines in which SNC is deployed.
•The client (SNC) receives the external notification ASN.1 and decodes it. If a
decoding error occurs a NACK must be sent to PPGA.
•If no decoding error occurs SNC maps the ASN.1 request to a SOAP request.
This mapping process depends on the kind of notification and the parameters
received. If an error mapping occurs a NACK must be sent to PPGA
•If no mapping error occurs the SOAP message is sent to the server (IT
Notification Consumer) while the client (SNC) blocks waiting for the response.

Center
Execution flow
•If a connection error occurs when SNC sends the SOAP request, SNC must
close the socket for which it receives the PPGA request for this IT Notification
Consumer. This indicates PPGA that an TCP error occurs and it would try to
reconnect to SNC (certain time will be left between each connection attempt) and
to finally resend External Notifications.
•At the other end, the server (IT Notification Consumer) decodes the message
carrying the request, ff a decoding error occurs a NACK must be sent by the
server (IT Notification Consumer) to client (SNC).
•If no decoding error occurs the server (IT Notification Consumer) sends an ACK
to SNC.
•On the receipt of the response, the client (SNC) unpacks the SOAP response,
composes an ASN.1 response doing a mapping process and sends it to PPGA.
The ASN.1 response will be a ACK or NACK depending on the SOAP response
received.

Center
Execution flow
PPGA error handling:
•When PPGA receives the ACK message with error code 0, the sending of the
External Notification is considered as successful. In case the received error code
is 1, the sending of the External Notification is considered erroneous and an
analysis of the error cause is performed. Based on that result further actions are
executed by AltamirA, such as:
•If the error is a TCP connection error, PPGA tries to reconnect to the SNC
(certain time will be left between each connection attempt) and to finally resend
External Notifications.
•If it is any other kind of error, the sending process is stopped and PPGA marks
the sending of the External Notification as erroneous.

Center
Summary
Affected Nodes:
•SNC
•PPGA
•CPS
Counters Handling
SNC shall store statistical information into physical files. The information to store
should be relevant to the business and to the operation and maintenance of the
service..
SNC must send this files using FTP or SFTP to an external system responsible of
processing and accumulating them for statistical and monitoring purposes.
The generation of counter files and the sending of them to an external system are
features that must be configurable in the SNC

Annexes
GECL – Access Keys Manager
› System that receives requests for the generation of access keys which
come from the external IVRs. It generates the anonymous key to
access the web server and transfers it to the user via a short message
or a registered letter.
› It creates, stores, modifies, validates and controls the users’ access

keys. It allows defining different types of keys with different behaviours
depending on expiry date, time spent in a given status or total number
of failed attempts, among others.
› GECL also controls the life cycle of these subscriber’s passwords.

Annexes
CPS
› The Products and Services Centre (called CPS, for its initials in Spanish) is the
interface for configuring and parameterizing the system functionalities. It
allows the network operator’s personnel (those with the necessary privileges)
to load the configuration parameters via a user-friendly and simple interface. A
browser (Internet Explorer, Mozilla Firefox, etc.) can be used to access CPS
from the graphical interface.
› The objective of the CPS is to provide an interface for the end users that allows
them to modify, without having to make requests for development, some
configuration parameters concerning the platform behaviour, especially those
related to the commercial offer that the network operator makes to their end
customers.
Annexes
CPS Features
› CPS’s main features are:

› It is a Web interface designed to configure AltamirA operations.
› It has a user-friendly interface for the client.
› By using this tool, the DB team will maintain control over the changes
performed by the network operators.
› The user will be able to save existing configurations and recover them later.
› This system configuration application, developed in Java, has been designed to

provide any future extension including new functionalities and improvements.

Annexes
CPS Functionalities
CPS was developed as a tool to facilitate the network operator’s tasks of

commercial definition and configuration of the AltamirA platform.
CPS includes the following functionalities:
› Configuration of tariffs
› Association of functionalities / restrictions to tariff types
› Configuration of bulk load files
› Promotions management
› Bonuses and bonus types
› Periodic actions
› Lists of frequent numbers
› Operations
› Tribes
› Top Up sources
› Bank top ups

Annexes
CPS Functionalities
› Bank top ups
› Consumption controls
› Global parameterization
› Rateable services
› Other configuration functionalities performed via CPS are:

– Technology switching management
– SOS top-ups by tariff
– Nested accounts creation and management
– Balance transfer configuration
– Language options
– Management of users and profiles with access control
CPS can also perform backups of these functionalities.

Annexes
Back office web (BOWEB)
› This client application is a graphic interface that allows the administrators to

carry out, from their PCs, management operations over the customers
subscribed to the Altamira platform.
› From this application, many operations can be performed, such as: managing
top-ups, configuring profiles of provisioned subscribers, querying subscribers’
characteristics, calls and operations, obtaining statistics and reports, etc.
› Deployed on the classical web based server/client model
› Web browser
› Web server: the web application communicates with AltamirA using

middleware tuxedo

Annexes
SIMA
› The AltamirA Monitoring Integral System (SIMA) monitores the platform

on real time
› Displays the events of the system
› Sends alarms to external systems
› Displays information about the physical status of the hosts
› Displays platform patch level


Capacitacion VE Arquitectura 2017

Uploaded by

Copyright:

Available Formats

Capacitacion VE Arquitectura 2017

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capacitacion VE Arquitectura 2017

Uploaded by

Copyright:

Available Formats

Session 3

 MAIN SYSTEM PROCESSES

 MAIN BATCH PROCESSES

ADVANCED | Ericsson | 2014-03-25 | Page 2

ADVANCED | Ericsson | 2014-03-25 | Page 4

› Target and audience

ADVANCED | Ericsson | 2014-03-25 | Page 5

ADVANCED | Ericsson | 2014-03-25 | Page 6

PPGA: Customer Manager

ADVANCED | Ericsson | 2014-03-25 | Page 7

OPGE: Provisioning operator

ADVANCED | Ericsson | 2014-03-25 | Page 8

OPGE: Provisioning operator

ADVANCED | Ericsson | 2014-03-25 | Page 9

RASC: Recharge Card Validation System

ADVANCED | Ericsson | 2014-03-25 | Page 10

PPCS: Balance control

ADVANCED | Ericsson | 2014-03-25 | Page 11

GECL: Access Keys Manager

ADVANCED | Ericsson | 2014-03-25 | Page 12

BOWEB: Back Office Web

ADVANCED | Ericsson | 2014-03-25 | Page 13

BOWEB: Back Office Web

ADVANCED | Ericsson | 2014-03-25 | Page 14

CPS: Products and Services Centre.

ADVANCED | Ericsson | 2014-03-25 | Page 15

AVS: Altamira Validation System.

ADVANCED | Ericsson | 2014-03-25 | Page 16

ADVANCED | Ericsson | 2014-03-25 | Page 17

S2T: SOAP to Tuxedo converter.

ADVANCED | Ericsson | 2014-03-25 | Page 18

ADVANCED | Ericsson | 2014-03-25 | Page 19

ADVANCED | Ericsson | 2014-03-25 | Page 20

ADVANCED | Ericsson | 2014-03-25 | Page 22

ADVANCED | Ericsson | 2014-03-25 | Page 23

ADVANCED | Ericsson | 2014-03-25 | Page 24

ADVANCED | Ericsson | 2014-03-25 | Page 25

› The operator logistics department provides the prepaid data (IMSI,

ADVANCED | Ericsson | 2014-03-25 | Page 26

ADVANCED | Ericsson | 2014-03-25 | Page 27

ADVANCED | Ericsson | 2014-03-25 | Page 28

› Line can be activated by a voice call, SMS, top up or by any specific

› At activation, customer receives a welcome SMS reporting current

› In this state, the customer has all functions available.

ADVANCED | Ericsson | 2014-03-25 | Page 29

› Customers can lose the remaining balance, keep it or add it to later

› A top up in this state changes the line to active state.

ADVANCED | Ericsson | 2014-03-25 | Page 30

› Neither outgoing and incoming calls or SMS can be made.

› State previous to 'freed/released' state.

› A top up in this state changes the line to active.

ADVANCED | Ericsson | 2014-03-25 | Page 31

› In this state, the customer lose control over the line.

› Unsubscription operation can be reverted during a configurable

› After a configurable period of time, the number can be reused in a

ADVANCED | Ericsson | 2014-03-25 | Page 32

› Reasons to change to suspended state:

ADVANCED | Ericsson | 2014-03-25 | Page 33

ADVANCED | Ericsson | 2014-03-25 | Page 34