Академический Документы
Профессиональный Документы
Культура Документы
May-2012
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).
Time,
Data Volume,
Subscribers location,
Device Type,
Network Resource Availability,
Subscriber Roaming,
Network Type,
Protocol/Application used by the subscriber,
Content Type,
Service,
Web Address (URL-based),
2
Location-based,
Subscribers 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.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
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.
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.
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.
5
1.2.10. Compliance
The proposed solution should support the below standards:
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)
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.
-
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.
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)
Time,
Data Volume,
Subscribers location,
9
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:
Gx interface can be used to query the PCRF about the redefinition of the
bandwidth.
10
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:
Network protocols
11
Amount of the used traffic (per hour, day, and month) according to the type
of network protocols.
Tariff plans and services
Subscribers location
2.2.6 Compliance
The proposed solution should support the below standards:
12
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:
o Ericsson GGSN
o PGW (Packet Gateway)
RADIUS servers
13
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.
-
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.
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
2.2.13 Training
The solution should include training to the users and administrators. The trainings
should be conducted onsite.
15
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.
16
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
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.
Each service workflow node shall be able to model single or bundle services
using graphical environment.
The system shall support hot-deployment upon existing business service and
network adapter modification or removal.
Any change in deployed services or network adapter shall not affect platform
operation.
18
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
o
o
o
o
Ericsson Multi-Activation
Cisco routers
Cisco switches
Microsoft Active Directory
Microsoft Exchange Server
19
The platform should support reception of CSV files (through local or ftp filesystem) for bulk provisioning
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.
From several upstream systems (i.e. Self Care Portal, Order Entry system)
simultaneously
3.2.4 Migration
The proposed solution should include migration from the current system.
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.
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.
23