Annex 3 to Request for Proposal
May-2012
Annex 3: Technical Specifications
VivaCell-MTS requires network and service convergence solutions separated into 3
different lots:
LOT 1: PCRF solution
LOT 2: DPI solution
LOT 3: CPS solution
Important Notes to All Lots:




The same Applicant is able to bid for any or all of the lots.
The Applicant should provide a separate proposal for each lot.
The Applicant should provide Statement of Compliance of each item of this
Annex 3.
Further technical details including network diagrams, software
versions, hardware versions, current architecture can be provided
upon request to the procurement and after signing of NDA (NonDisclosure Agreement).
1
Annex 3 to Request for Proposal
May-2012
LOT 1: PCRF SOLUTION
1. PCRF Solution
1.1. Overview and Business Objectives
VivaCell-MTS requires a PCRF (Policy Charging Rules Function) solution:









To align business requirements with PCRF functionalities.
To create policy-based services based on usage, application, location,
device, network type etc.
To integrate the PCRF with billing and CRM systems.
To integrate with the current DPI platform.
To implement the possible scenarios of network and service convergence.
To maximize the functionality of Ericsson OCS (Online Charging
Systems).
To centralize rating, charging and bundle functionalities on the Ericsson
OCS.
To pave the way for possibilities of implementing E2E policy management.
To migrate the current subscribers and policies to the new solution.
1.2. Modules Specification
1.2.1. Provisioning of policy-based services
The proposed solution should support provisioning of policy-based services based
on the combination of various parameters, including:











Time,
Data Volume,
Subscriber’s location,
Device Type,
Network Resource Availability,
Subscriber Roaming,
Network Type,
Protocol/Application used by the subscriber,
Content Type,
Service,
Web Address (URL-based),
2
Annex 3 to Request for Proposal
May-2012









Location-based,
Subscriber’s Profile,
QoS.
Tariff plan
Amount of used traffic (per hour, day, month)
Time of service usage (day/night, period of time)
Equipment type
ANY combination of the parameters enumerated above.
Policies should be applied both individually for each subscriber and for the
group of subscribers.
1.2.2. Networks
The proposed solution will be bearer network agnostic, being able to fully interface
with any type of carrier network, including but not limited to:






LTE,
GSM,
UMTS,
WiFi
DSL
FTTx
1.2.3. Deep Packet Inspection
The proposed solution should be compatible with any of the below DPI:



Sandvine PTS switches
Ericsson SASN
Cisco SCE
1.2.4. Migration
The proposed solution should include policies, rules, price plan migration from the
current system.
1.2.5. Statistics
The proposed solution should support collection of statistics based on the below
attributes:
 Network protocols
 Amount of the used traffic (per hour, day, and month) according to the type
of network protocols.
3
Annex 3 to Request for Proposal
May-2012


Tariff plans and services
Subscriber’s location
1.2.6. Customer self-care
The proposed solution should support self-care APIs which will be integrated with
the current self-care channels. The API should support web service such as
SOAP.











Self-registration
Account Maintenance
Change account details, such as address and other contact information
Quota usage
Usage History
Parental Control configuration
Ability to purchase other services
Other invoice details.
User dashboards
Subscriber notification over SMS and/or Web Page redirect
Solution should support the notification of the subscriber on the cost of
access to services in case of excess of various threshold values (80 %, 90
% etc.) before using service.
1.2.7. GUI interfaces and dashboards
The proposed solution should support user-friendly web GUI interfaces and user
dashboards.
 User-friendly GUI enabling to define ad-hoc policies without the intervention of
the vendor
 Web GUI which allows the administrator to access and manage all customers’
contact data and consumption information
1.2.8. Solution Trial
The proposed solution should be provided as a trial Proof of Concept (POC) for a
period of 1 month from the trial acceptance date. This trial must be Free of
Charge (FOC) and Free of any commitment or financial obligations.
 The scope of the trial will be limited to the use-cases defined in point 1.2.8
 All hardware related for the trial period will be provided by the Applicant
unless agreed otherwise
 All software related for the trial period should be provided FOC basis.
4
Annex 3 to Request for Proposal
May-2012





Basic training should be provided by the Applicant to ensure proper trialing of
the solution.
The trial scope is non-negotiable
The trial will demonstrate the technical functionalities of the solution
The trial solution upon can have live traffic for load testing, only after showing
satisfactory results and VivaCell-MTS’s approval
The current DPI system used is Sandvine PTS switches. The Applicant can
propose a different DPI system as long as it is FOC basis.
1.2.9. Use-cases for the trial
The proposed solution should support the below use-cases:












Usage-based: Unlimited 1 month with fair usage policy set at 1 GB. First 1
GB best effort and above 1 GB to downgrade to 256 kbps
Usage-based: 100 MB Bundle additional 1 MB to be charged at x AMD / MB.
Usage-based: Convergent bundle of voice and data based on units. Bundle
is x units. Onnet voice calls rated at 1 unit per second and data calls rated 1
unit per MB.
Location-based: Unlimited best effort usage in all cells, except few defined
cells. This will be the cells on the roof top of VivaCell-MTS HQ.
Application-based: Email 100 MB bundle (yahoo, gmail, msn). Other
protocols are charged per MB.
Family plans: One parent account to have a quota 100 MB bundle, the
available quota can be transferred to the child accounts having 10 MB bundle,
upon receiving a command from the self-care.
URL-based: All traffic to vivacell.am to be charged free. Other URLs will be
charged at x AMD per MB.
Usage-based with peak/off-peak hours: Unlimited usage during the day
8:00 AM to 6:00 PM, limited usage during the night 6:00 PM to 8:00 AM.
Device-based charging: iPad traffic to be charged x AMD per MB, while
other devices y AMD per MB. There will be a single IMEI defined as iPad
device.
Bearer network: 4G traffic to be charged at x AMD per MB, while 2G/3G to
be charged at y AMD per MB. (Identification of bearer network is based on
GGSN and GW IPs which is present as RADIUS NAS-Identifier attribute)
Turbo Button: Low bandwidth subscribers who occasionally need high-speed
access (eg. for gaming, streaming, downloading, etc.) upon fee payment will
be granted a premium high bandwidth for a specified period of time or traffic
volume.
Content Filtering: The platform must support the ability to apply usage
limitations based on URL address/application type/content type and/or time
constrains.
5
Annex 3 to Request for Proposal
May-2012

Roaming Cost Control: The platform must enable the operator to set default
or personalized maximum charging limits and notify subscribers when
approaching / reaching quota threshold. Must be “Bill Shock – proof”.
1.2.10. Compliance
The proposed solution should support the below standards:






3GPP R9 compatible Support for Gx, Gy, Sp, Rx, S9
Act as a Gy DCCA proxy
Should support 10G optical interfaces scalable up to 40G traffic
Should support 100,000 simultaneous sessions scalable up to 500,000
sessions
Must support IPV4 and IPv6
Carrier-grade
1.2.11. Alerts
The proposed solution should provide an administration and monitoring system by
generating system alarms and alerts. This can be using technologies such as SNMP
agents and SNMP traps.
1.2.12. CDR Management
The proposed solution should generate CDR files which should include: MSISDN,
IMSI, source IP, Destination IP, APN, duration, charging information and other data,
received as a result of the analysis and an estimation of the traffic.
1.2.13. Integration
The proposed solution should support the below integrations:








Access servers:
o Ericsson GGSN
o PGW (Packet Gateway)
RADIUS servers
DPI (Deep Packet Inspection)
Ericsson OCS (Online Charging System)
Billing and CRM systems
MMSC and WAP gateway
MS BizTalk Server working as ESB (Enterprise Service Bus)
ADMS (via online or offline)
6
Annex 3 to Request for Proposal
May-2012

Congestion Management System
The solution should support web services API and/or SDK for future addition of new
module and/or extending the current functionality
The proposed solution should provide the necessary tools to develop connectors to
integrate with undefined systems
1.2.14. Reporting
The proposed solution should provide a full-functional report-design environment
enabling the easy creation of tabular and graphical reports fed by the operational
data of the solution.
 Export to external files such as text, CSV, Excel, XML and PDF
 Reports generation based on multiple criteria
 Ability to design and generate reports
 Ability to schedule of sending report to multiple recipients by email
 Repository of readily available, off-the-shelf report templates designed
in advance to cover the most frequently addressed reporting needs.
1.2.15. Security hierarchy
The proposed solution should support granular and advanced security access
model. In other words, all unauthorized menu item, reports, dashboard items, views,
etc will be hidden from the user.
-
Ability to define very granular privileges
Support of built-in user groups or roles based on best practices
Ability for users to change their passwords and profile
All user profiles and passwords are encrypted in the database
Ability to generate audit trail logs of all actions performed including the
administrator role
1.2.16. Technical Requirements





Web-based using SSL technologies
Fast, easy and secure access to the application
Preferable to have minimal administration
Operating system: Linux or Solaris preferred
The system should have open architecture, use open interfaces of the
system’s functional blocks interaction.
7
Annex 3 to Request for Proposal
May-2012
1.2.17. Hardware Requirements
The solution should specify the minimum and recommended hardware configuration.
The hardware fee should be quoted separately and can be procured by VivaCellMTS from the local market.
The Applicant should provide evidence that the proposed hardware will guarantee
performance. In case if the hardware provided did not meet the performance criteria,
then the Applicant will take full responsibility by replacing the hardware with no
additional cost.


The hardware solution should comply with the 1+1 or N+1 protection
principles
The hardware solution should incorporate a load balancing and failover
mechanisms
1.2.18. Training
The solution should include training to the users and administrators. The trainings
should be conducted onsite.
The training should include basic and advanced trainings. In addition, training is
required for development of new data sources using SDKs.
1.2.19. Manuals and documentation
The solution should include user guides, operation manuals and deployment guides
in electronic format. Printed manuals are optional.
1.2.20. Project Management
The solution should include project management and professional services to
implement the project.
The Applicant should provide a project schedule plan for the project implementation.
1.2.21. Technical support and maintenance
The proposed solution should include the staffing details for normal operations of the
system. In addition to define roles based on best practices and standards.
The solution should include technical support and maintenance with 24x7 hot line
and online ticketing system. The first 3 years technical support will need to be part of
the solution or the commercial proposal.
8
Annex 3 to Request for Proposal
May-2012
LOT 2: DPI SOLUTION
2. DPI (Data Package Inspection) Solution
2.1 Overview and Business Objectives
VivaCell-MTS requests a complete traffic management solution that includes the
development of network design, equipment supply, installation, system integration.
The functional "Traffic Management" in terms of equipment and use of traffic
analysis/ definition of policies should include:










Ability to analyze Internet traffic (level protocols/ applications)
The possibility of charging user data based on the traffic analysis to
support prepaid/ postpaid service models
The possibility of imposing restrictions on the use of individual subscribers
of network protocols
The possibility of limiting the speed of Internet access
Ability to prioritize network protocols
Ability to restrict subscriber access to the WEB-resources (blocking
access, partial blocking by time of day, volume of traffic generated from
this resource)
To align business requirements with the DPI functionalities
To create policy-based services based on usage, application, location,
device, network type etc
To create policy enforcement policies
To create advanced analytical reports of network, subscriber, protocol
usage
The solution should work with any vendor's equipment, GGSN, the standards of
3GPP R8 and at the stage of further development of the system to maintain the
functionality of PDN - Gateway to the terms of the System Architecture Evolution
(SAE)
2.2 Modules Specification
2.2.1 Provisioning of policy-based services
The proposed solution should support provisioning of policy-based services based
on the combination of various parameters, including:
9
Annex 3 to Request for Proposal
May-2012
























Time,
Data Volume,
Subscriber’s location,
Device Type,
Network Resource Availability,
Subscriber Roaming,
Network Type,
Protocol/Application used by the subscriber,
Content Type,
Service,
Web Address (URL-based),
Location-based,
Equipment type
ANY combination of the parameters enumerated above.
Policies should be applied both individually for each subscriber and for the
group of subscribers.
The solution should support packet inspection and analysis WAP1.x/2.0. The
following parameters should be determined by the decision: MSISDN, URL,
Uplink Traffic, Downlink Traffic, Status Code, and Content-Type.
The solution must support the inspection and analysis of the HTTP protocol
packet HTTP1.0 and HTTP1.1.
The following parameters should be
determined by the decision: MSISDN, URL, Uplink Traffic, Downlink Traffic,
Status Code, and Content-Type.
The solution must inspect and analyze signaling and media protocols such as
RTSP and RTP / RTCP based on RFC 2326 (RTSP). The following
parameters should be determined by the decision: MSISDN, URL, Uplink
traffic, Downlink traffic, Start time, Stop time, Valid duration.
The solution must support the transfer of MMS over WAP1.X (WSP) and
WAP2.0 (HTTP1.1). The following Options have determined Decision:
Recipient type / ID, Content - Type / MIME type, Error Code, Attachment
Type.
The solution must inspect and analyze protocols IMAP, SMTP/POP3. The
following parameters should be determined by the decision: MSISDN, URL,
Uplink traffic, Downlink traffic, and Error code.
The solution must inspect and analyze P2P and VOIP protocols, based on
signature services.
The solution must support the use of masks and regular expressions in all the
URL fields, such as domain, path and parameters.
The solution must provide the function of bandwidth management in downlink,
and in the uplink.
The solution must provide the following functions for managing bandwidth:
10
Annex 3 to Request for Proposal
May-2012




Gx interface can be used to query the PCRF about the redefinition of the
bandwidth.
The solution should provide ability to enable / disable the summation of the
unspent amount of traffic within one billing cycle to the volume of traffic in the
new cycle.
Access rules should be based on dynamic and static information about the
user, the destination URL, the service record, time. Access rules should have
priority, which can be taken into account when applying these rules.
The solution must support the billing in real time, using the protocol
DIAMETER.
2.2.2 Networks
The proposed solution will be bearer network agnostic, being able to fully interface
with any type of carrier network, including but not limited to:






LTE,
GSM,
UMTS,
WiFi
DSL
FTTx
 Regularly update the list of protocols (protocol signatures) that are subject to
restrictions, as well as adding operational modifications of existing protocols
 Ability to permit subscribers to use separate network protocols (P2P, VoIP, IM,
FTP, etc.) on a commercial basis, implemented as a plug-periodic service
 Ability to connect the subscriber services, including the use of a specific
protocol or include packaged offers (for example: VoIP only, VoIP + P2P).
 Limiting the bandwidth must be applied individually for each subscriber, as well
as for the group
 Informing you of the introduction / removal of limiting the bandwidth in the
provision of subscriber service data packet
 Ability to disable / enable the service to inform you of the introduction of limiting
the data rate
 Ability to cancel this limitation rate for a certain period of time or for a certain
amount of traffic based on the connected services.
 Reducing the bandwidth for certain types of traffic (e.g. P2P) when the
threshold is configurable bandwidth of the total traffic.
2.2.3 Statistics
The proposed solution should support collection of statistics based on the below
attributes:
11
Annex 3 to Request for Proposal
May-2012




Network protocols
Amount of the used traffic (per hour, day, and month) according to the type
of network protocols.
Tariff plans and services
Subscriber’s location
2.2.4 GUI interfaces and dashboards
The proposed solution should support user-friendly web GUI interfaces and user
dashboards.
 User-friendly GUI enabling to define ad-hoc policies without the intervention of
the vendor
 Web GUI which allows the administrator to access and manage all policies
and statistical reporting
2.2.5 Migration
The proposed solution should include policies and rules migration from the current
system.
2.2.6 Compliance
The proposed solution should support the below standards:












3GPP R9 compatible Support for Gx, Gy
To support DPI of MMS based on destination number, sender, content type,
content size, number of recipients
To support DPI of WAP v1 and WAPv2 based on destination URL and useragent type.
Should support 10G optical interfaces scalable up to 40G traffic
Should support 100,000 simultaneous sessions scalable up to 500,000
sessions
Must support IPV4 and IPv6
Carrier-grade solution
3GPP TS 23.401: "GPRS Enhancements for E-UTRAN Access".
3GPP TS 23.234: "3GPP System to Wireless Local Area Network (WLAN)
Interworking; System Description".
IETF RFC 3344, "Mobility Support for IPv4".
3GPP TS 23.002: Technical Specification Group Services and System
Aspects; Network Architecture.
3GPP TS 23.003: "Numbering, addressing and identification".
12
Annex 3 to Request for Proposal
May-2012




















3GPP TS 23.203: "Policy and Charging Control Architecture".
3GPP
TS
22.278: "Service requirements for evolution of the system
architecture".
3GPP TS 23.060: "GPRS Tunneling Protocol (GTP) across the Gn and
Gp interface".
3GPP TS 29.212: "Policy and charging control over Gx reference point".
IETF RFC 2794: "Mobile IP Network Access Identifier Extension for IPv4".
3GPP TS 33.402: "3GPP System Architecture Evolution: Security aspects
of non-3GPP accesses".
3GPP
TS
March 2. April 2: "Architecture enhancements for non-3GPP
accesses".
RFC 3588 - Diameter Base Protocol;
RFC 3589 - Diameter Command Codes for Third Generation Partnership
Project (3GPP) Release;
RFC 4004 - Diameter Mobile IPv4 Application;
RFC 4005 - Diameter Network Access Server Application;
RFC 4006 - Diameter Credit-Control Application;
RFC 4072 - Diameter Extensible Authentication Protocol (EAP) Application
(optional);
RFC 4740 - Diameter Session Initiation Protocol (SIP) Application (optional);
RFC 5224 - Diameter Policy Processing Application;
RFC 5431 - Diameter ITU-T Rw Policy Enforcement Interface Application;
RFC 5516 - Diameter Command Code Registration for the Third Generation
Partnership Project (3GPP) Evolved Packet System (EPS);
3GPP R7 TS 29.230: Diameter applications; 3GPP specific codes and
identifiers.
RFC 1945 (HTTP 1.0)
RFC 2616, 2817 (HTTP 1.1)
2.2.7 Alerts
The proposed solution should provide an administration and monitoring system by
generating system alarms and alerts. This can be using technologies such as SNMP
agents and SNMP traps.
2.2.8 Integration
The proposed solution should support the below integrations:

Access servers:
13
Annex 3 to Request for Proposal
May-2012

o Ericsson GGSN
o PGW (Packet Gateway)
RADIUS servers
The solution should support web services API and/or SDK for future addition of new
module and/or extending the current functionality
The proposed solution should provide the necessary tools to develop connectors to
integrate with undefined systems
2.2.9 Reporting
The proposed solution should provide a full-functional report-design environment
enabling the easy creation of tabular and graphical reports fed by the operational
data of the solution.
 Export to external files such as text, CSV, Excel, XML and PDF
 Reports generation based on multiple criteria
 Ability to design and generate reports
 Ability to schedule of sending report to multiple recipients by email
 Repository of readily available, off-the-shelf report templates designed
in advance to cover the most frequently addressed reporting needs.
2.2.10 Security hierarchy
The proposed solution should support granular and advanced security access
model. In other words, all unauthorized menu item, reports, dashboard items, views,
etc will be hidden from the user.
-
Ability to define very granular privileges
Support of built-in user groups or roles based on best practices
Ability for users to change their passwords and profile
All user profiles and passwords are encrypted in the database
Ability to generate audit trail logs of all actions performed including the
administrator role
2.2.11 Technical Requirements




Web-based using SSL technologies
Fast, easy and secure access to the application
Preferable to have minimal administration
Operating system: Linux or Solaris preferred
14
Annex 3 to Request for Proposal
May-2012












The system should have open architecture, use open interfaces of the
system’s functional blocks interaction.
All hardware must conform to the principles or 1 +1 N +1, ie stop the
operation of a network element should not be a reason for stopping the
service.
The solution must conform to the principle of 99.999% (five 9-s)
available.
All important data (such as system configuration files and personal user
settings, database, etc.) must be backed up on an external device at
least once a day.
After a forced / restart and uncontrolled systems, network elements s
restoration of full functioning of the complex should occur automatically
The databases used in the system should be based on the clustering
solution to avoid a single point of failure.
The whole system should also not be a single point of failure, and its
failure should not affect the provision of services to subscribers that are
active at the time of failure.
Failure of any component of the solutions must be "transparent" to the
subscriber, i.e. not require further action.
In the event of failure of any system components should be included
mode "workaround."
The system should support mechanisms for remote disaster recovery.
The system should have as architecture, providing a growing number of
subscribers, traffic volume, etc.
The solution must provide for the existence of mechanisms for load
balancing and failover occurring in the case of system overload.
2.2.12 Hardware Requirements
The solution should specify the minimum and recommended hardware configuration.
The hardware fee should be quoted separately and can be procured by VivaCellMTS from the local market.
The Applicant should provide evidence that the proposed hardware will guarantee
performance. In case if the hardware provided did not meet the performance criteria,
then the Applicant will take full responsibility by replacing the hardware with no
additional cost.

The hardware solution should comply with the 1+1 or N+1 protection
principles
15
Annex 3 to Request for Proposal
May-2012

The hardware solution should incorporate a load balancing and failover
mechanisms
2.2.13 Training
The solution should include training to the users and administrators. The trainings
should be conducted onsite.
The training should include basic and advanced trainings. In addition, training is
required for development of new data sources using SDKs.
2.2.14 Manuals and documentation
The solution should include user guides, operation manuals and deployment guides
in electronic format. Printed manuals are optional.
2.2.15 Project Management
The solution should include project management and professional services to
implement the project.
The Applicant should provide a project schedule plan for the project implementation.
2.2.16 Technical support and maintenance
The proposed solution should include the staffing details for normal operations of the
system. In addition to define roles based on best practices and standards.
The solution should include technical support and maintenance with 24x7 hot line
and online ticketing system. The first 3 year technical support will need to be part of
the solution or the commercial proposal.
16
Annex 3 to Request for Proposal
May-2012
LOT 3: CENTRALIZED PROVISIONING SOLUTION
3. Centralized Provisioning Solution
3.1 Overview and Business Objectives
VivaCell-MTS requires a CPS (Centralized Provisioning Solution):





To align business requirements with the CPS functionalities
To create consolidate and centralize all provisioning systems
To create provisioning rules based on business processes
To converge network commends
To create advanced analytical reports of network, subscriber, protocol
usage
3.2 Modules Specification
3.2.1 Provisioning services
The proposed solution should support Service Oriented Architecture based on
Enterprise Service Bus (ESB) construct. The platform must support convergent
service provisioning capability. It should be capable to provision services across at
least the following type of networks:








GSM,
xDSL,
WiMAX,
NGN
IMS,
Digital Exchanges
IP TV
The platform must support two major environments. One including the runtime
environment, while the second one, shall include a fully interoperable and
platform in-depended Design and Development environment enabling the
development of new business services and network adapters.
17
Annex 3 to Request for Proposal
May-2012

New Business Services should being modeled and designed using a standard
BPEL Service workflow graphical tool. This tool must enable the fast
introduction and maintenance of business services. Every function of a
business service should be modeled on a workflow basis that maps the steps
required to provision these services as workflow nodes.

The platform shall support the decomposition of service orders to
transactional atomic actions or sets of atomic actions (NE commands) that
communicate with external network elements/IT systems. They should be
designed with a network adapter designer tool that must support a wide range
of communication protocols and interfaces with network elements.

The platform shall support modular architecture. Business services should be
the higher level layer; network adapter shall be used as parts of the services,
undertaking the communication with networks elements and external
databases/network inventory systems respectively.

The platform shall support invocations (such as selection, addition, deletion,
queries) either to the platform’s embedded database or to external databases,
data warehouse and inventory system in order to extract information for
capturing, validation and enrichment of complex provisioning orders

Each service workflow node shall be able to model single or bundle services
using graphical environment.

The platform shall supports any possible combination of provisioning
commands, on any number of Network Elements.

Any arbitrary logic shall be able to be modeled and orchestrated inside a
service workflow using a graphical environment. Both synchronous and
asynchronous command execution should be supported through the use of
the appropriate service workflow.

Network adapter designer should support a user-friendly GUI supporting the
creation of an adapter according to a generic adapter model. This generic
should be customizable by template-based code generators that are specific
to particular underlying technologies. Rollback support functionality, at
adapter lever, shall be supported.

The system shall support hot-deployment upon existing business service and
network adapter modification or removal.
18
Annex 3 to Request for Proposal
May-2012

Any change in deployed services or network adapter shall not affect platform
operation.
3.2.2 Alerts
The proposed solution should provide an administration and monitoring system by
generating system alarms and alerts. This can be using technologies such as SNMP
agents and SNMP traps.
3.2.3 Integration
The proposed solution should support the below integrations:
For communication with OSS/BSS systems and NEs, the platform shall support the
following technologies:
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
http
tcp
FTP/File Based
sftp
FTAM
J2EE and/or JEE
TL1
ssh
rsh
telnet
MML
Java RMI
Corba TMF-814
Socket
JDBC
EAI Message Queues
XML over JMS
OSS/J
Web Service
SOAP
EJB
For communication with OSS/BSS systems and NEs, the platform shall support the
following built-in adapters:
o Ericsson Multi-Activation
o Cisco routers
19
Annex 3 to Request for Proposal
May-2012
o Cisco switches
o Microsoft Active Directory
o Microsoft Exchange Server

The platform should support reception of CSV files (through local or ftp filesystem) for bulk provisioning

The platform should support “plug-and-play” integration via web-services with
upstream downstream systems.

The platform should have the ability to connect to an external database or
network inventory system in order to enrich activation request with external
data.

The platform should enable the automatic transfer via ftp or sftp of ‘bulk’
provisioning files including service activation orders, parse the ‘bulk’
provisioning file, execute activation commands in multithreaded fashion and
return execution results to upstream system.

The system shall support graphically configured scheduler component
supporting the scheduled execution of batch processes

The platform should support reception of incoming requests

From several upstream systems (i.e. Self Care Portal, Order Entry system)
simultaneously

Using several upstream interfaces as XML over JMS, OSS/J, EAI
simultaneously.

The proposed solution should provide the necessary tools to develop
connectors to integrate with undefined systems
3.2.4 Migration
The proposed solution should include migration from the current system.
3.2.5 Service Activation Process
20
Annex 3 to Request for Proposal
May-2012
 Support for fully transactional activation including configurable rollback when
errors in activation process occur.
 There should be configuration on the network adapter level concerning if
commands can be executed synchronously or asynchronously in the
elements.
 The system shall support workflow decomposition to independent individual
workflows, as well as the composition of a workflow from existing individual
workflows.
 There should be configuration capability on the network adapter level
concerning timeout and retry to establish connection mechanisms in case of
connectivity problems with NEs.
 The proposed platform shall employ a WEB-based GUI providing advanced
monitoring and reporting capabilities for both system operation and deployed
services. More specifically the WEB-Based GUI shall allow to:
o Monitor deployed Services
o Monitor the status of service activation requests
o View service request statistics per provisioning domain, service
request type, management domain, time period
o Generate aggregated reports
o Auditing of failed activation requests
o Test new services and activation adapters
o Set configuration parameters
 The system shall support functionality for log file housekeeping.
 The system shall support prioritization of incoming service requests. The
priorities shall be configurable via the system GUI.
 The system shall support capability to select and retry failed activation
requests via the GUI.
 The system should support internal traffic shaping mechanisms according to
configurable rules safeguarding the system performance.
3.2.6 Security hierarchy
21
Annex 3 to Request for Proposal
May-2012
The proposed solution should support granular and advanced security access
model. In other words, all unauthorized menu item, reports, dashboard items, views,
etc will be hidden from the user.
-
Ability to define very granular privileges
Support of built-in user groups or roles based on best practices
Ability for users to change their passwords and profile
All user profiles and passwords are encrypted in the database
Ability to generate audit trail logs of all actions performed including the
administrator role
3.2.7 Technical Requirements





Web-based using SSL technologies
Fast, easy and secure access to the application
Preferable to have minimal administration
Operating system: Linux or Solaris preferred
The system should have open architecture, use open interfaces of the
system’s functional blocks interaction.
 Must support IPV4 and IPv6
3.2.8 Hardware Requirements
The solution should specify the minimum and recommended hardware configuration.
The hardware fee should be quoted separately and can be procured by VivaCellMTS from the local market.
The Applicant should provide evidence that the proposed hardware will guarantee
performance. In case if the hardware provided did not meet the performance criteria,
then the Applicant will take full responsibility by replacing the hardware with no
additional cost.


The hardware solution should comply with the 1+1 or N+1 protection
principles
The hardware solution should incorporate a load balancing and failover
mechanisms
3.2.9 Training
The solution should include training to the users and administrators. The trainings
should be conducted onsite.
22
Annex 3 to Request for Proposal
May-2012
The training should include basic and advanced trainings. In addition, training is
required for development of new data sources using SDKs.
3.2.10 Manuals and documentation
The solution should include user guides, operation manuals and deployment guides
in electronic format. Printed manuals are optional.
3.2.11 Project Management
The solution should include project management and professional services to
implement the project.
The Applicant should provide a project schedule plan for the project implementation.
3.2.12 Technical support and maintenance
The proposed solution should include the staffing details for normal operations of the
system. In addition to define roles based on best practices and standards.
The solution should include technical support and maintenance with 24x7 hot line
and online ticketing system. The first 3 year technical support will need to be part of
the solution or the commercial proposal.
23