DISH Proprietary & Confidential - Not to be shared without NDA

Requireme Requirement
nt Id
K_OSS_1.1 The solution shall support Design and Runtime separation
Design module shall support open modeling languages (e.g., YANG,
K_OSS_1.2 TOSCA) and follow open modeling standards
The solution shall come with Service and Network design environment
allowing for easy creation of network, network slice and service
K_OSS_1.3 templates compliant with 3GPP SBA 28.533
The solution shall support catalog-driven orchestration with dynamic flow
K_OSS_1.4 composition

The solution shall support orchestrating and managing multiple network

K_OSS_1.5 domains with a cross-domain service orchestration functionality

Service Orchestration component shall be built on modern architectural

standards and shall have open industry standard APIs; TMF Open API on
K_OSS_1.6 northbound side ,MEF Presto, ETSI SOL 003/005, NETCONF
The Service Orchestration shall be policy-driven with policy management
K_OSS_1.7 and enforcement functionalities included.

The vendor shall have a vendor-neutral MANO (NFV-O and VNF-M)

application available as a part of the solution or a standalone product.
The MANO architecture and standards shall be aligned with ETSI MANO
K_OSS_1.8 set of standards

The solution shall come with active and assignable inventory supporting
inventory models from various network domains (i.e., physical facilities,
physical network functions, virtual network functions, containers,
applications, numeric resources, etc). The inventory shall support YANG
as a primary modeling language. The 5G NR part of the inventory shall be
K_OSS_1.9 compliant with 3GPP 28.541

The solution shall come with fault management functionality allowing

exporting all service topologies enriched with alarms to external
assurance systems. The fault management functionality shall be
K_OSS_1.10 compatible with ETSI SOL002
The vendor shall present a list of supported 4G and 5G network functions
K_OSS_1.11 and applications

The solution shall come with RAN rollout set of functionalities supporting
K_OSS_1.12 site acquisitions, cellsite rollouts, landlord and contract management

The solution shall come with dynamic Network Design & Planning
functionality that supports modeling of 5G RAN taking into account data
K_OSS_1.13 coming from RF planning, geo-information systems and network analytics
 The solution shall be built on modern architectural principles using open
technologies and open source software and support high availability,
K_OSS_1.14 disaster recovery, elasticity and zero downtime upgrades
without NDA
Vendor Response Vendor Comment
DISH Proprietary & Confidential - Not to be shared without NDA
Requirem Requirement
ent Id
K_BSS_1.1 The solution shall be pre-integrated end-to-end
All components of the solution (channels, fulfilment, billing,
K_BSS_1.2 etc.) shall be driven from the single catalog
The centralized catalog shall contain offers, products and
K_BSS_1.3 services

K_BSS_1.4 The solution shall provide digital customer interaction channels

The solution shall provide omni-channel customer experience
K_BSS_1.5 driven by data analytics

All components of the solution shall be convergent across B2C

K_BSS_1.6 and B2B, fixed, wireless and cloud services, 4G and 5G networks
The solution shall enable partner onboarding, billing and
K_BSS_1.7 management
The solution shall be able to charge for traditional and new
K_BSS_1.8 services
The solution shall be able to charge for services based on
K_BSS_1.9 network performance metrics and service priority
The solution shall be able to take 5G network SLAs into account
K_BSS_1.10 when charging for services

The solution shall be able to charge for services based on

K_BSS_1.11 network slice, as well as charge for network slice management
The solution shall be able to charge for services based on
K_BSS_1.12 supported 5G network architecture
The solution shall be able to integrate to and support 4G LTE
K_BSS_1.13 and 5G networks
K_BSS_1.14 The solution shall be able to charge for partner services
shared without NDA
Vendor Response Vendor Comment
DISH Proprietary & Confidential - Not to be shared without NDA
Requirement Id
BOSS_FL_1.1

BOSS_FL_1.2

BOSS_FL_1.3

BOSS_CMD_1.1

BOSS_CMD_1.2

BOSS_CMD_1.3

BOSS_CMD_1.4

BOSS_E2ESED_1.1

BOSS_E2ESED_1.2

BOSS_E2ESED_1.3

BOSS_E2ESED_1.4

BOSS_E2ESED_1.5

BOSS_PSC_1.1

BOSS_PSC_1.2
BOSS_PSC_1.3
BOSS_PSC_1.4

BOSS_PSC_1.5

BOSS_PSC_1.6

BOSS_PSC_1.7
BOSS_PSC_1.8

BOSS_PSC_1.9

BOSS_PSC_1.10
BOSS_PSC_1.11

BOSS_PSC_1.12

BOSS_INV_1.1

BOSS_INV_1.2

BOSS_INV_1.3

BOSS_INV_1.4

BOSS_INV_1.5

BOSS_INV_1.6
BOSS_INV_1.7
BOSS_INV_1.8
BOSS_INV_1.9

BOSS_BPM_1.1
BOSS_BPM_1.2
BOSS_TTM_1.1
BOSS_POBM_1.1
BOSS_SSP_1.1
BOSS_SSP_1.2
BOSS_SSP_1.3
BOSS_SSP_1.4

BOSS_SSP_1.5

BOSS_SSP_1.6

BOSS_SSP_1.7
BOSS_SSP_1.8

BOSS_SSP_1.9

BOSS_SSP_1.10

BOSS_SSP_1.11

BOSS_SSP_1.12
BOSS_SSP_1.13

BOSS_SSP_1.14

BOSS_SSP_1.15

BOSS_SLM_1.1
BOSS_WF_1.1

BOSS_WF_1.2
BOSS_WF_1.3
BOSS_WF_1.4
BOSS_WF_1.5
BOSS_WF_1.6

BOSS_WF_1.7
BOSS_CBS_1.1
BOSS_CBS_1.2
BOSS_CBS_1.3

BOSS_CBS_1.4

BOSS_CBS_1.5

BOSS_CBS_1.6

BOSS_CBS_1.7

BOSS_CBS_1.8

BOSS_CBS_1.9

BOSS_CBS_1.10

BOSS_CBS_1.11

BOSS_CBS_1.12

BOSS_CBS_1.13
BOSS_CBS_1.14

BOSS_CBS_1.15

BOSS_CBS_1.16
BOSS_CBS_1.17
BOSS_CDR_1.1
BOSS_CPS_1.1
BOSS_CRM_1.1
BOSS_CRM_1.2
BOSS_CRM_1.3
BOSS_CRM_1.4
BOSS_CRM_1.5
BOSS_CRM_1.6
BOSS_CRM_1.7

BOSS_DW_1.1

BOSS_PP_1.1

BOSS_PP_1.2

BOSS_RA_1.1

BOSS_RA_1.2
BOSS_RA_1.3

BOSS_RA_1.4

BOSS_RA_1.5
BOSS_RA_1.6
BOSS_RA_1.7
BOSS_BES_1.1

BOSS_BES_1.2

BOSS_BES_1.3

BOSS_BES_1.4

BOSS_BES_1.5

BOSS_BES_1.6

BOSS_BES_1.7
BOSS_OECW_1.1
BOSS_OECW_1.2

BOSS_OECW_1.3
BOSS_OECW_1.4
BOSS_OECW_1.5

BOSS_BIG_1.1

BOSS_BIG_1.2
BOSS_TMF_1.1
BOSS_OSSArch_1.1

BOSS_OSSArch_1.2

BOSS_OSSArch_1.3

BOSS_OSSArch_1.4
BOSS_OSSArch_1.5

BOSS_OSSArch_1.6

BOSS_OSSArch_1.7

BOSS_OSSArch_1.8
BOSS_OSSArch_1.9

BOSS_OSSArch_1.10

BOSS_Operatio_1.1

BOSS_Operatio_1.2
BOSS_Operatio_1.3
BOSS_Operatio_1.4
BOSS_DEP_1.1
BOSS_DEP_1.2
BOSS_DEP_1.3

BOSS_GL_1.1

BOSS_GL_1.2

BOSS_GL_1.3
BOSS_GL_1.4

BOSS_DR_1.1

BOSS_DR_1.2

BOSS_DR_1.3

BOSS_DR_1.4
BOSS_DR_1.5

BOSS_DR_1.6
BOSS_DR_1.7
BOSS_DR_1.8

BOSS_DR_1.9

BOSS_DR_1.10

BOSS_DR_1.11

BOSS_DR_1.12

BOSS_DR_1.13
BOSS_DR_1.14

BOSS_DR_1.15

BOSS_DR_1.16

BOSS_DR_1.17

BOSS_DR_1.18

BOSS_DR_1.19

BOSS_DR_1.20

BOSS_DR_1.21
BOSS_DR_1.22

BOSS_DR_1.23

BOSS_RI_1.1

BOSS_RI_1.2

BOSS_RI_1.3

BOSS_RI_1.4

BOSS_RI_1.5

BOSS_RI_1.6

BOSS_RI_1.7
BOSS_RI_1.8

BOSS_RI_1.9

BOSS_RI_1.10

BOSS_RI_1.11

BOSS_RI_1.12

BOSS_NI_1.13

BOSS_NI_1.14

BOSS_NI_1.15
BOSS_VZ_1.1

BOSS_VZ_1.2

BOSS_VZ_1.3
BOSS_VZ_1.4

BOSS_AU_1.1
BOSS_AU_1.2

BOSS_AU_1.3

BOSS_AU_1.4

BOSS_NBI_1.1

BOSS_NBI_1.2

BOSS_NBI_1.3

BOSS_NBI_1.4
BOSS_NBI_1.5

BOSS_NBI_1.6

BOSS_NBI_1.7

BOSS_NBI_1.8

BOSS_SED_1.1

BOSS_SED_1.2

BOSS_SED_1.3

BOSS_SED_1.4

BOSS_SED_1.5
BOSS_SED_1.6

BOSS_SED_1.7

BOSS_SED_1.8

BOSS_SED_1.9

BOSS_SED_1.10

BOSS_SED_1.11

BOSS_SED_1.12

BOSS_SED_1.13

BOSS_SED_1.14

BOSS_SED_1.15

BOSS_SED_1.16

BOSS_SED_1.17

BOSS_SED_1.18
BOSS_CIDT_1.1

BOSS_CIDT_1.2

BOSS_CIDT_1.3
BOSS_CIDT_1.4

BOSS_CIDT_1.5
BOSS_CIDT_1.6
BOSS_CIDT_1.7

BOSS_SED_1.19

BOSS_SED_1.20

BOSS_SED_1.21

BOSS_SED_1.22

BOSS_SRC_1.1

BOSS_SRC_1.2

BOSS_SRC_1.3

BOSS_SRC_1.4
BOSS_SRC_1.5

BOSS_SRC_1.6

BOSS_SRC_1.7

BOSS_SRC_1.8

BOSS_SRC_1.9

BOSS_SRC_1.10

BOSS_SRC_1.11

BOSS_SRC_1.12

BOSS_SRC_1.13

BOSS_SRC_1.14

BOSS_SRC_1.15

BOSS_SRC_1.16
BOSS_SRC_1.17

BOSS_SRC_1.18

BOSS_SRC_1.19

BOSS_ConAct_1.1

BOSS_ConAct_1.2

BOSS_ConAct_1.3

BOSS_ConAct_1.4

BOSS_ConAct_1.5

BOSS_ConAct_1.6
BOSS_SDAct_1.1

BOSS_SDAct_1.2

BOSS_SDAct_1.3

BOSS_SDAct_1.4

BOSS_SDAct_1.5

BOSS_SDAct_1.6

BOSS_SDAct_1.7
BOSS_SDAct_1.8

BOSS_SDAct_1.9

BOSS_SDAct_1.10

BOSS_ServMod_1.1

BOSS_ServMod_1.2

BOSS_ServMod_1.3

BOSS_ServMod_1.4

BOSS_SOM_1.1

BOSS_SOM_1.2

BOSS_SOM_1.3
BOSS_SOM_1.4

BOSS_SOM_1.5

BOSS_SOM_1.6

BOSS_SOM_1.7

BOSS_SOM_1.8

BOSS_SOM_1.9

BOSS_SOM_1.10

BOSS_DCA_1.1

BOSS_DCA_1.2

BOSS_DCA_1.3

BOSS_DCA_1.4
BOSS_DCA_1.5
BOSS_DCA_1.6

BOSS_DCA_1.7

BOSS_DCA_1.8
BOSS_DCA_1.9

BOSS_DCA_1.10

BOSS_DCA_1.11

BOSS_DCA_1.12

BOSS_DCA_1.13

BOSS_DCA_1.14

BOSS_DCA_1.15

BOSS_DCA_1.16
BOSS_Corr_1.1
BOSS_Corr_1.2
BOSS_Corr_1.3

BOSS_Corr_1.4

BOSS_Corr_1.5

BOSS_Corr_1.6

BOSS_Corr_1.7

BOSS_Corr_1.8
BOSS_Corr_1.9

BOSS_Corr_1.10
BOSS_RCA_1.1
BOSS_RCA_1.2
BOSS_RCA_1.3

BOSS_RCA_1.4

BOSS_RCA_1.5
BOSS_RCA_1.6

BOSS_RCA_1.7

BOSS_SIA_1.1

BOSS_SIA_1.2

BOSS_SIA_1.3
BOSS_SIA_1.4

BOSS_SIA_1.5

BOSS_SIA_1.6

BOSS_SIA_1.7

BOSS_SIA_1.8
BOSS_SIA_1.9

BOSS_SIA_1.10

BOSS_ASS_1.1
BOSS_ASS_1.2

BOSS_ASS_1.3
BOSS_ASS_1.4
BOSS_ASS_1.5

BOSS_ASS_1.6
BOSS_ASS_1.7
BOSS_ASS_1.8
BOSS_ASS_1.9

BOSS_ASSMisc_1.1

BOSS_ASSMisc_1.2

BOSS_ASSMisc_1.3
BOSS_ASSMisc_1.4

BOSS_ASSMisc_1.5

BOSS_ASSMisc_1.6

BOSS_ASSMisc_1.7
roprietary & Confidential - Not to be shared without NDA
Requirement
Shall support Fulfilment and Assurance Closed Loop Automation
The OSS Fulfilment component shall support 'Network Abstraction' that simplifies the Service
Design/Orchestration layer
OSS Fulfilment Application should support the following TMF Open APIs TMF640, TMF623,TR
527,TMF 638, TMF 652
The solution delivered shall be highly reliable with no single point of failure causing unplanned
system downtime
Shall provide resilience and data integrity against any single failure, including interfaces, VMs,
VNFs, Data Centres, without any impact to functionality of the application
The solution shall ensure capacity levels are maintained in the event of any single outage including
physical infrastructure and connectivity thus ensuring resilience
The solution shall be able to restore itself to its fully resilient state without manual intervention
once the cause of the failure has been rectified
Shall provide a system that supports the creation of new order types or modify existing with GUI as
required for ordering, design, catalog, inventory, and implementation of products
Shall provide an interface to all necessary systems to establish effective ordering formats and flows
and establish the system dependency requirements.
Shall provide the ability to retire existing products and services based on DISH or DISH partner
decisions
Shall provide a GUI interface with tools for modeling network configurations, routing and traffic
simulation data coming from RF planning, GIS systems and network analytic
The OSS solution shall have the functionality to enable the modelling of service components and
resources. The vendor shall elaborate on how this is achieved.B2:B5

The Catalog shall allow definition in a TMF compliant format Customer Facing Service Specification

The Catalog shall allow definition in a TMF compliant format Resource Facing Service Specification
The Catalog shall allow definition in a TMF compliant format Logical Resource Specification
The Catalog shall allow definition in a TMF compliant format Physical Resource Specification
The Catalog shall support Service specification modeling approach based on open modeling
standards (e.g., YANG, TOSCA) with the use of open modeling languages (YAML, JSON) where
possible.
Vendor solution shall support intituive GUI to define the CFS/RFS specifications in Industry
Standard (eg: SID/TOSCA/YANG/HEAT etc).
Vendor solution shall have the ability to connect to the version contol repo (i.e.
GitHub/SVN/Nexus). T
The catalog editor tool shall be able to checkout the files from the repository
Vendor solution shall have the ability to Import / Export Service Specifications via Catalogue editor
(UI & API).

Vendor solution shall have the ability to define assurance capabilities/specifications at the service
or product level, so that when a service or product is ordered/activated, those assurance
capabilities and specifications can be used to build the assurance service wrap appropriately?
Shall have ability to Indicate to the user, the impacted service instances in case of change to
existing catalogue definitions using catalogue editor
Catalog solution should have the ability store repeatable solution templates to reuse after
succesful completion of complex change /service requests. It should also be possible to update
these templates for specific customers.
Shall be able to provide the ability to create / modify / delete resource attributes in the topology
such as link capacity, sector info, a PSTN/Mobile numeric resource, VLAN-ID and interface IP
address. It should also be able to perform validation before committing changes.
Shall have the ability to put a resource (physical or logical) within the topology into maintenance
mode with a configurable maintenance window via an external system.
Inventory module shall support Physical (Resource), Logical (Service) and Virtual (NFV) Inventory of
elements
Physical elements Inventory should include 5G RAN (Antena, RU, DU), Edge and Core Data Center
Physical Infrustructure, Transport underly network
Logical elements Inventory shall include 5G Network Slices, Logical connectivity (e.g. VLANs, IP
Addresses)
Virtual elements Inventory shall include 5G VNFs (e.g. RAN CU, RIC, 5G Core functions) and Virtual
Network Services
Shall support TMF Open APIs for Inventory - TMF 638, 639, 645
Shall support Cloud-native Hybrid Resource-Service-Virtual Inventory system
Shall provide Centralized access to network and service information via rich consolidated UI
Shall have the ability to provide graphical view the business processes using BPMN standard with
automation diagrams to track and ensure that the technical implementation process are executed
dynamically.
Workflow in SOMshall be standard BPMN 2.0 engine with the ability to import BPMN 2.0 XML
Shall support TMF 621 - Trouble Ticket
Shall support the capibility of partner on boarding management
The self-service portal solution shall support Multi-tenancy.
The self-service portal solution shall support differentiated access/instance per DISH partner
The self-service portal shall have reporting capabilities for DISH specific to partners/tenants
The self-service portal shall have reporting capabilities for DISH specific to partners/tenants
The self-service portal shall provide capabilities on per tenant basis to the tenant, with
configurability capability by DISH
Self-service portal to include for fulfillment purposes Listing of product catalog, allowing user to
order services and product on the network
Self-service portal to include for fulfillment purposes Publish promotions and special offers for their
customers
Self-service portal to include for fulfillment purposes User registration/user login functionalities
Self-service portal to include for fulfillment purposes Ordering of commercial services and creation
of services from the product catalog
The Self-service portal for management, customer, and management of existing services shall
support the following capabilities
The Self-service portal for management, customer, and management of existing services shall
suppor Services modification
The Self-service portal for management, customer, and management of existing services shall
suppor Services configurations
The Self-service portal for management, customer, and management of existing services shall
suppor KPI Monitoring and SLA reports
The Self-service portal for management, customer, and management of existing services shall
suppor Performance Management queries and functions
The Self-service portal for management, customer, and management of existing services shall
suppor Trouble Ticketing Management
Solution must support proactive assurance recovery automations not only based on alarms from
EMS, but also KPI triggers Analytics sources such as Big Data Stacks or Internet of Things (IoT)
sources, or other sources
Workflow capability shall be provided as part of the solution.
Product solution shall offer dynamic workflow generation based on the intent model defined on
the catalogue.
Workflow shall support new network service (e.g., PDN access, etc)
Workflow shall support Modify of existing service
Workflow shall support Cease of existing service
Workflow shall support Move of existing service from one site to another
Workflow shall support Ability to express in flight change to the above and pass down suitable
instructions to the OSS.
The charging function shall support PDU session charging as specified in 3GPP 32.255
The charging function shall support Flow Based Charging (FBC) as specified in 3GPP 32.255
The charging function shall support QoS flow Based Charging (QBC) as specified in 3GPP 32.255

The charging function shall support Roaming QoS flow Based charging as specified in 3GPP 32.255

The charging function shall support PDU session charging SSC Mode 1 as specified in 3GPP 32.255

The charging function shall support PDU session charging SSC Mode 2 as specified in 3GPP 32.255

The charging function shall support PDU session charging SSC Mode 3 as specified in 3GPP 32.255
The charging function shall support PDU session Charging SSC Mode 3 IPv6 Multi Homed as
specified in 3GPP 32.255
The charging function shall support PDU session charging for interworking with EPC as specified in
3GPP 32.255
The charging function shall support PDU session charging for roaming in Home routed scenario as
specified in 3GPP 32.255
The charging function shall support PDU session charging - non-3GPP access as specified in 3GPP
32.255
The charging function shall support Simultaneous change of Branching Point or UL CL and
additional PSA for a PDU Session as specified in 3GPP 32.255
The charging function shall support Addition of additional PDU Session Anchor and Branching Point
or UL CLas specified in 3GPP 32.255
The charging function shall support online and offline charging
The charging function shall support interfacing with a charging gateways in the BSS/OSS, or in the
network
The charging function shall support interfacing with a prepaid mediation server supporting hot
lining and other account mangement capabilities
The curging and billing function shall suport rating, reconcilattion, and all necessary function to
generate bills
Shall suport the formats specfied in 32.255
The system shall support customer provisioning from BOSS into network
The CRM shall support customer interface management
The CRM shall support loyalty and retention programs for DISH and DISH partners
CRM shall be the database of record for customer management
The CRM shall support selling
The CRM shall manage the sales prospects
The CRM shall support acquisition of customer data
The CRM shall enable up selling and cross selling
BSS, OSS, and Network Management data shall be stored in a shared repository (the Data
Warehouse) capable of handling all data needs.
Provide automated interface into business analysis and forecasting for DISH partners, so that
product and price mix initiatives are reported with accuracy and timeliness
Provide automated interface into billing, customer service, acquisition and retention channels of
DISH partners and into DISH so that existing and future offers are communicated to all channels for
quality assurance, this includes all activities related from sales to customer care
Shall provide reports that feeds acquisition and retention activities for DISH internal use and
federated to DISH partners for their use
Shall provide tools to report on channel profitability for analysis by DISH to a very detailed level,
include within it acquisition and retention activities
Shall support the ability for trend analysis of revenue and sales data by promotion.
Shall support the ability to perform ad-hoc reporting on any available field within the BSS domain
or other domains that have data in the data warehouse
Shall support analysis of revenue and sales data by customer segment or DISH partner down to the
individual customer.
Shall support trend analysis of revenue and sales data by DISH partner or geographical area.
Shall support the trend analysis of network trouble data and service quality
Shall provide support in the billing systems for complex account hierarchies
Shall allow DISH partner to define account hierarchy for pricing, discounts, and minimum billing
requirements
Shall allow for web-based customer service functionalities, where DISH or DISH partner can set 
Billing period
Shall allow for web-based customer service functionalities, where DISH or DISH partner can set
New account setup
Shall allow for web-based customer service functionalities, where DISH or DISH partner can set
Calling plan selection
Shall allow for web-based customer service functionalities, where DISH or DISH partner can set
Calling features selection and product additions.
Shall allow for DISH or DISH partner customer define their billing method, as in credit card of
choice, direct debit for both one-time payments and perpetual automatic payments
Shall support the use of credit thresholds established by DISH and each DISH partner policy
Shall support use of partner defined scripts for collection of credit information
Shall maintain internal historical credit risk database for DISH direct customers including
information on credit denials, poor payment history, and disconnection due to non-payment.
Shall support qualification of customer for contract
Shall support the generation of contract
Shall support the creation and maintenance of customer specific invoice, including Paper,
Electronic Formatted Bill, SMS, email
Shall support the creation and maintenance of attributes, look, and design for all available invoice
customer communication
Shall be compliant to all TMForumn NB,SB, and other OpenAPIs
The solution has to have a microservices based architecture implemented using good software
engineering practices.
The supplier shall provide an architectural overview the application showing the various
independently deployable physical and logical components and the interactions between them as
well as details of the software engineering process followed.
• Is the architecture truly micro-services based? List and describe your microservices
• Is the architecture cloud native? Can the various microservices be deployed to containers e.g.
docker in a public cloud envoronment.
• What are the components of the architecture?
• Do the components communicate entirely through APIs? Or is there some direct database
access required for integration with other components?
• Does each micro-services component own its data?
• Can the components be independently scaled?
• What are the main scaling points of the solution?
• Can the components be scaled on demand dynamically without service interruption?
• Do components share a common database?
• How do you manage versions of your software and how can we pilot new vendor product
versions if a non-backward compatible change has been made?

Interoperability with other vendor products and solutions:

• Are the vendor APIs technology agnostic? E.g. Does the vendor product present RESTFul APIs
over HTTPS?
• Does the vendor product have full exposure of its capability via its public APIs?
• Do the vendor product APIs support HATEOS?
• Does the vendor product support a publish and subscribe model for its APIs? Which ones?
• Does the vendor product support a dynamic API documentation?
• Does the vendor product support monitoring feeds from all of its components into an external
monitoring system?
What tools are available to help integration with other components.

• What  UI and tools are available  in addition addition to the API? Do the UI and tools use the
same underlying APIs as are exposed from the application?
• Describe extensibility of your UI - can custom forms and controls be introduced?
• Presentation Layer - Is the architecture independent of its presentation to users/other systems?
i.e. is any GUI layer built on top of the same APIs as can be accessed by other applications?

Does the solution offer Northbound APIs?

Please list the NBIs and indicate which standards they're in conformance with
The solution needs to be able to integrate with resources and services from multiple vendors using
open standards where possible.It is expected that solution will have pluggable integration adapters
and also that it will be easy and quick to develop new plug ins as needed. This applies to various
southbound integration options like VIMs, network controllers (SD-WAN, NMS, etc) as well as
individual network elements accessible via CLI or NETCONF

Describe your multi-vendor support - which vendors products have you integrated with both on
NBI and SBI side?
Describe how an extension to the existing data models can be made? Does the solution or product
offer a data model editing?

Can the vendor product or solution handle multiple time zones?

Does the solution support Single Sign On authentication and authorization? List which protocols
the solution supports (LDAP, TACACS, SAML2, etc)
Does the solution or product support multi-tenancy, i.e. accommodate more than one
organization?
How is data segregation achieved?

Describe how the operational state and current performance of the solution can be monitored. Is
there a centralized logging component?
Describe how the solution can be assess and notify about the impact in case of servcie disruption
(e.g., unplanned outage of compute platforms running the solution, unavailability of a northbound
or southbound system, etc)

What is your Recovery Time Objective?

What is your Recovery Point Objective?
What is the scale of the largest deployments you have supported?
Does the technology lend itself to agile e.g rapid deployment, automated testing.
Deployment Models:
• What deployment models does the vendor’s product support?
• Can the solution be deployed in public clouds? List PaaS environments (including public clouds)
that your solution can support.
What is l the deployment architecture of the solution.
• The separate processes / applications that constitute the overall solution, for example databases,
message bus, event handlers etc.
• How the solution is architected to scale to y large numbers of devices under management, for
example, which processes / applications can be deployed in parallel across multiple physical nodes.
• What non-provided components are required to deploy the solution, e.g. external databases,
IPAM, LDAP / Authentication servers, TLS Proxy.
• How the solution is best deployed on a virtualised / containerised infrastructure.
• How the solution can be deployed in a highly available manner.
• How the solution can be deployed in a geographically distributed manner, with particular
emphasis on any latency requirements between system components that might impact on
placement.
• How multiple instances / domains of the solution can be deployed.

The proposed solution shall be capable of managing inventory & topology of resources & services
that reside in any of the technology domains forming a multi-service mobile operatos
infrastructure, which domains include, but are not limited to: (virtual) mobile core, optical & IP
transport, wireline & wireless access, voice/data/video cores, OSP & ISP, cloud fabric & workloads
(including OS flavour, version, & patch status, and workload type, function, & version). The Bidder
shall list the technology domains supported by the proposed solution, and shall describe in detail
the various types of supported resources & services falling within each of the supported
technology domains, emphasizing the readiness of the proposed solution to support hybrid cloud
setups and the upcoming 5G deployments.

The proposed solution should include a native graph database as the underlying storage
technology for logical topology data, which shall be optimized for transactional processing of graph
data. This is in contrast with a solution that serializes graph data into a relational database or other
NoSQL technologies such as key-value stores, column family stores, or document stores, whether
or not based on HDFS. The Bidder shall provide details of this underlying storage technology and its
constraints, including stating the graph data model employed, the use of index-free adjacency in
graph traversals (or otherwise), limits on data store size, support for a distributed architecture, and
whether or not the graph database is based on open-source technologies.

The proposed solution shall have the capability to consume data abstraction models in the form of
YANG, which would enable the proposed solution to automatically recognize new resource &
service element types and to automatically adjust its behaviour as far as discovery and lifecycle
management of such elements, all in its prescribed role as an solution. Such abstraction models
shall be persisted in a suitable repository that follows an open data architecture, for which the
Bidder shall describe in detail the repository structure and the underlying data storage
technologies. The Bidder shall further describe in detail the manner with which such abstraction
models are uploaded into the repository, the manner with which the proposed solution consumes
such models, and the behavioural adjustments that ensue. Additionally, the Bidder shall highlight
any limitations of YANG that may affect the capabilities of the proposed solution or its functional
behaviour, discussing the manner with which the proposed solution overcomes such limitations, if
at all.
In addition to consuming YANG abstraction models, should the proposed solution support
additional modelling abstractions/techniques, which may be standard or proprietary, then the
Bidder shall describe such modelling abstraction methodologies. Moreover, the Bidder shall
describe the structure of the repository persisting such abstraction models, the underlying data
storage technologies, and the mechanics of exporting these models to YANG.

The proposed solution shall have the capability to automatically discover the different types and
instances of active resources & services comprising the CSP infrastructure. The Bidder shall
describe in detail the mechanics of the discovery process for each of the supported technology
domains, including the use of the data abstraction models, the communication protocols
employed, and supported EMS/NMS and SDN-C integrations. The Bidder shall further highlight any
constraints that may be applicable to any or all technology domains within a multi-service CSP
infrastructure.
Vendor solution should support scheduled discovery of cross domain multi vendor network that
could be considered a generic well defined experience regradless of product, services, bundled and
unbundled.

During the discovery process, the proposed solution shall have the capability to discover
relationships between the identified instances of active resources & services, this to construct
topology in real-time. The Bidder shall describe in detail the mechanics of discovering and
constructing topology, shall state the constraints on automated topology construction that may be
applicable to any or all technology domains within a multi-service CSP infrastructure, and shall
express, as a percentage of the full topology of a CSP infrastructure, the expected effort required
to complete topology construction through manual stitching.
Vendor solution should support On demand discovery over customer network estate

The proposed solution shall have the capability to periodically reconcile the inventory of resources
& services and the associated topology, such that the current state of the solution accurately
reflects the state of the CSP infrastructure. The Bidder shall describe in detail the mechanics of
inventory and topology reconciliation, shall discuss the degree to which the reconciliation process
may be customised through the administrative interfaces, and shall highlight any constraints that
may be applicable to any or all technology domains within a multi-service CSP infrastructure.
Vendor solution should support event based / rule based discovery capability.
Vendor solution should provide white listing through descrepancy check capability.
Vendor solution should have the capability to pre-define simple and complex descrepancy check
rules and reconcliation rules.
Vendor Solution should support automated reconciliation based on pre-defined descrepancy and
reconciliation rules.
Vendor solution should support roll back capability and amend manual reconciliation over
incorrectly reconciled data.
Vendor solution should support full network scanning capability with the support of
publish/subscribe methodology.
Vendor solution should support reconciliation of failed polls, polling errors and polling issues
caused by index shifts and inventory changes.
Ability to do optimized polling so as not to poll for repeated / already polled / unchanged
information.
Vendor solution should support dicovery based on event / trap notification receved from Domain
controllers for the changes over hybrid networks. Ability to discover customer provisioned new
resources using 3rd party or native tools and systems and identify such infrastructure and add
relevant management services automatically
Shall be able to import topology information from an external system via an API and enrich its own
topology with this information.

Shall be able to discover resources using an IP address range and populate / build the topology
accordingly. The discovered data should contain, but shouldn't be limited to physical and logical
data, such as device / card / SFP serial number, firmware version, source and destination
connectivity, services and base configurations.
Shall be able to discover resources (including links and devices) using discovery protocols and / or
APIs and add them to the network topology. Protocols including BGP-LS, PCEP, and Secure LLDP
shall be supported.
Shall be able to retrieve information via 5G NFMFs and network controllers (e.g., RAN Controller
like SON or OpenRAN RIC, T-SDN, etc)
The vendor shall enumerate all protocols supported by the proposed framework for resource and
topology discovery. If any of the listed protocols are not supported, the vendor shall state how the
proposal supports the functionality provided by any unsupported protocol.
Shall be able to provide the status of discovered resources (logical and physical) in the physical /
logical topology e.g. port status is up, down or under maintenance.
Shall be able to trigger on-demand discovery through an API.
For assignable inventory, shall be able to maintain an up-to-date view of network topology, using
periodic polling which should be configurable.
Shall have the ability to be able to discover physical and logical attributes of a resource e.g. port
speed and RSVP-TE bandwidth.
Logical resources - the resource inventory shall contain all the logical abstractions of physical
resources or a network functionality that are available or can be provisioned in the network. These
include but are not limited to IP addresses, VLANs, LSPs, sub-interfaces on a port etc.
Physical Resources - the resource inventory shall contain all physical components that are active
and available to use in the network. These include but are not limited to cards, chassis, ports,
devices, physical links, access circuits etc.
Assigned Resources - the resource inventory shall contain details of all resources that have been
assigned to existing resources via an external system or a resource pool e.g. IP addresses assigned
to a management port by an external IPAM system.
Planned Resources - the resource inventory shall contain details of all resources that have been
planned and are in the process of being delivered in the network. This information shall be
provided to the resource inventory by an external Plan and Build system.

The resource inventory shall maintain the details of mappings / linkages between resources and
the hierarchical relationship between resources e.g. the resource inventory shall be aware of the
devices in a site, which cards are present in those devices, how many ports are in each card, how
many logical resources have been configured on each port etc.

The solution shall maintain a multi-dimensional relationship, dependencies and hierarchy between
resources, services, products and customers. The vendor shall elaborate how this can be achieved
in their framework, detailing any constraints in defining and maintaining these relationships.
The resource inventory shall maintain the state of a resource, in certain circumstances, in
conjunction with input from external systems.
Shall be able to identify discrepancies between Planned Inventory versus Actual Inventory versus
Gold Inventory (meaning the designed state of network).

Shall be able to define a workflow for adding a resource (physical and / or logical) to the topology.
For example, once the device is discovered, it should move into a staging area / under-test. It is
only moved into In-Service status once a set of tests have been successfully completed. The trigger
to change status can be manual or automated via an external trigger or API call.
Shall be able to provide the ability to create / modify / delete resource attributes in the topology
such as link capacity, sector info, a PSTN/Mobile numeric resource, VLAN-ID and interface IP
address. It should also be able to perform validation before committing changes.
Shall have the ability to put a resource (physical or logical) within the topology into maintenance
mode with a configurable maintenance window via an external system.
Any changes made to any resource in the topology shall percolate to appropriate changes to the
resource inventory and vice versa.
Solution should have the ability to integrate with multi-tenant NFVI Platform to extract utilisation
data specific to the tenant which is responsible to manage the life cycle of VNFs in the respective
tenant.
Cloud provider, OS, Server Specification, Hypervisor, Applications, Services, tagging, DHCP scope,
AV status, patch status, backup status, IP adresses should be stored in the inventory.
Ability to extract inventory data from other platforms like NFVI
The vendor should provide a UI for the resource inventory which can be used by operations for
visualising and searching resources and the relationships / hierarchies between products, services,
resources and customers.

Solution should include the ability for Inventory Visualisation - geo-spatial, 3D Schematic, topology
and “images” (photos, CAD diagrams and video) on top of the usual “text” based screens.
Shall be able to present a graphical view of the end-to-end topology.
Shall be able to define device groups, locations / sites and regions within the topology so that you
can have a graphical view of the topology based on these filters e.g. topology by device type,
topology by region etc.
Ability to provide audit logs / history across inventory estate to be offered via API and the GUI.
Vendor solution should support audit log to know what/when was the changed/reconcilied based
on what descrepancy identified, which rule has been applied and how it was applied with
exception logs.
The resource inventory shall provide a history of resources that have been created / available /
modified / decommissioned. This shall be available for a configurable period of time.

Shall have the ability to maintain a history of topology changes for a configurable period of time.
APIs shall be provided to allow external components to view, add, delete and update the resource
inventory itself.
CRUD REST API endpoints shall be provided for each and every entity that is held within the
resource inventory
CRUD REST API endpoints shall be provided for relationships, dependencies or hierarchies of
resources and their association to services, products and customers.
The capabilities and details available via the API shall be determined by the associated user roles
and access rights.
The resource inventory shall provide a set of APIs to enable queries from various clients. Queries
shall be supported for a specific resource or a collection of resources, with the ability to filter
queries on any attribute associated to that resource.
The orchestrator shall present the capability to query and retrieve detailed information around any
dependent / linked products, service and customers from resources.
Shall be able to present topology information to northbound systems via an API. The solution
should be able to define a level of details of the topology being exported
Shall be able to be filter and present the topology data based on a range of parameters, including
but not limited to topology per tenant, topology for a specific service and topology for specific
device types over an API.
The OSS solution shall have the functionality to enable the modelling of service components and
resources. The vendor shall elaborate on how this is achieved.
The vendor shall elaborate on the design philosophy behind choosing the proposed modelling
language and what benefits it brings to Dish.
The design time for service templates (e.g., Network Slice Templates) should be separated from
runtime. In other words, the product should allow modeling of the templates and required artifacts
without a necessity to access the OSS
The OSS solution shall allow services to be modelled in standards-based open modelling language.
The preference is for service components and resources to be modelled in YANG .
The modeling tool has to provide both GUI and IDE interfaces for modeling
Any modelling language and tools provided in the OSS solution framework shall be backwards
compatible.
The vendor shall provide any user guides, best-practice documentation available to create a model
using the modelling language of choice.
The modeling tool has to have flexible user experience adaptable for various user groups - DevOps,
Network Designers, Cloud/NFVI engineering, MANO engineering, etc
The vendor shall enumerate all modelling languages that are supported in the proposed
framework.
If modelling is done in YANG, the vendor shall provide details of the conformance of Service
Component and Resource YANG models in the proposed solution to IETF RFC 6020 / 7950.
The vendor shall provide details of the standards used (if not YANG-based) and the degree of
conformance with those standards in the modelling of services and resources.
If not using standards-based open modelling language, the vendor shall elaborate and justify the
reasoning behind this.

Service Component modelling for customer services (CFS) shall be carried out using TMF standards.

Service Component modelling for network services shall be carried out using IETF standard models.
The vendor shall provide the capability and a mechanism to normalise vendor specific resources
and present them northbound in a vendor-agnostic format.
The OSS solution shall present the ability to expose service components and resource models to
the orchestrator via standardised and open APIs.

The vendor shall elaborate how this modelling language will be supported, upgraded or replaced.
The vendor should support ETSI modeling standards, specifically IFA011 for packaging format and
IFA013 and IFA015 for information model
The vendor shall describe the version control mechanism available for the service component and
device models and associated mappings. This shall allow to work with multiple versions running in
the network at any one time.

The OSS solution shall provide the capability to map service component models to the device
models. This requirement allows the translation of a service component request into low level
atomic device configurations / payloads that need to be pushed to individual devices to realise this
service. It should also be possible to test this mapping and then deploy it in a short timescale.
The vendor shall describe this process and the tools available to support this mapping.
The vendor shall explain how this process and the tools available allow us to create new services,
test them and deploy in a short timescale.
The mapping tool shall be open to use by DIsh and configurable by Dish.
The mapping tool shall allow for:
The vendor shall provide version control of different releases of this modelling language and shall
provide the modelling tool which allows Dish to Create, Read, Update and Delete models.
Models used shall be extensible and configurable i.e. attributes / artifacts in the model can be
added, updated and deleted as per Dish requirements.
The vendor shall describe in detail how constraints, hierarchies, sequencing and dependencies are
defined in the modelling language of choice. The vendor shall provide any user guides or best
practice documentation around this.
The vendor shall elaborate how the OSS gets the model and implements the dependencies /
hierarchies / constraints defined in the resource model.

Dynamic Mapping - where a Mapping Logic Engine (code / tool that maps the service to device
model) shall be able to:
Make API calls.
Read responses to these API calls and populate the payload where appropriate
Query databases and populate the payload with results / response where appropriate.
Validate the service component payload it receives from the orchestrator with the service
component models.

Ability to provide catalogue driven fulfilment ensuring Service and resource specifications are
described in a catalogue.
The Catalog should allow definition of the following entities in a TMF compliant format.
o Customer Facing Service Specification?
o Resource Facing Service Specification?
o Logical Resource Specification?
o Physical Resource Specification?

Service specification modeling approach should be based on open modeling standards (e.g., YANG,
TOSCA) with the use of open modeling languages (YAML, JSON) where possible.
Vendor solution should support intituive GUI to define the CFS/RFS specifications in Industry
Standard (eg: SID/TOSCA/YANG/HEAT etc).

Vendor solution should have the ability to connect to the version contol repo (i.e.
GitHub/SVN/Nexus). The catalogue editor tool should be able to checkout the files from the repo.
Vendor solution should have the ability to Import / Export Service Specifications via Catalogue
editor (UI & API). In case the imported file specification is not compliant to the supported standard
then the editor should have the ability to translate the specification from one standard to other
(eg: if the domain controller support AWS specifications and vendor solution support only TOSCA;
then the tool should have the provision to convert the standards automatically without manual
intervention).
Vendor solution should have the ability to Import Resource specifications in Industry standard
format (Eg-CSAR). Please explain the supported format by the product & maturity of the same.

Vendor solution should have the ability to define assurance capabilities/specifications at the
service or product level, so that when a service or product is ordered/activated, those assurance
capabilities and specifications can be used to build the assurance service wrap appropriately?

Ability to automate the assurance capabilities agreed to at the point of contract commitment by
flowing it down to external assurance solutions automatically, ensuring that what has been
contractually agreed regarding assurance, is being delivered and realised through the assurance
capabilities?
Ability to on the fly deploy Catalogue Files supporting hot deployment on the envoirnment without
a need to restart the application and add any additional mappings for publishing the catalogue files
on envoirnment.

It should be possible to create orchestration recipes for lifecycle management of the various
entities defined in the catalogue. These recipes could take the form of Mistral or BPMN workflows
or scripts ( Shell, Ansible) and can be executed corresponding to a certain intent lifecycle.

Vendor solution should have the ability to support multiple versions of the catalogue files. The
solution should be able to support following features:
1. Perform diff across the catalogue versions.
2. Show the diff across the files support user friendly options to merge the changes.
3. Should show the associated service instances to the associated catalogue items. 4. ability to
control versions and release configs 5. Solution should support Release and deployment
managemen
Vendor sholution should be able to support comon & local CI/CD pipeline with VNF vendors .
Solution should provide ability to create and execute test cases and integrate the same with CI
suite.
Ability to Indicate to the user, the impacted service instances in case of change to existing
catalogue definitions using catalogue editor

The service specification should be define milestones and set KPIs parameters for the milestones,
define notifications in terms of early warnings, time lapsed, etc for the plan and delivery
milestones.
Solution should have the ability store repeatable solution templates to reuse after succesful
completion of complex change /service requests. It should also be possible to update these
templates for specific customers.
Catalog models should have the ability to define composite network services.  Catalogue models
should also be able to capture the FM/PM collection policies and should offer hooks to instantiate
'closed loop' remediation journey.
Catalog models should have the ability to define composite network services.  Catalogue models
should also be able to capture the FM/PM collection policies and should offer hooks to instantiate
'closed loop' remediation journey.
Catalog models should have the ability to define composite network services.  Catalogue models
should also be able to capture the FM/PM collection policies and should offer hooks to instantiate
'closed loop' remediation journey.
Should support domain, application, customer and component specific configurations to be auto
applied during service activation (OR service provisioning)

Resources and services should be modelled in YANG based on IETF RFC 6241. The OSS Fulfilment
component should be able to offer configuration and activation capability based on YANG models. 
The OSS Fulfilment component should be able to support 'Network Abstraction' that simplifies the
Service Design/Orchestration layer and allows it to create Services in a common way no matter
what network resource technology implements them. This abstraction layer would also be needed
for runtime & discrepancy checks between the network and the OSS inventory.
Ability to discover existing configuration and deploy the new configuration on the fly through
automated workflow & API call supporting customer API and declarative API integration.
The solution should have the ability to amend configuration and policy of network functions (5GC
NFs, non-3GPP NFs like ). This could be through EMS systems or directly on the VNF.
Ability of the system to deploy changes to NFV, containerised applications, SaaS services and
physical devices located either on private networks or via the Internet. Ability to address the
managed device via a NAT'd IP address.
Ability to view a change history log that records commands issued / changes made and allows for
rollback of changes.
Solution should be able easily onboard and adopt device data models from 3rd parties.
The solution should allow me to easily integrate with tools like IPAM (IP Address Management) as
part of the service design and assign process.
Solution should have the ability to create dynamic e2e service activation workflows based on logic
stored in the catalog and taking existing network topology in to consideration.
The solution should allow me to easily integrate with tools like IPAM (IP Address Management) as
part of the service design and assign process.
The solution should provide service design/assign journey based on the min diff (i.e. support delta
change to the service only) without changing physical mods or ceasing and provide.
Vendor solution should provide service Design/Assign taking consideration of the status,
performance, capacity and utilisation of the applicable resources.
The solution should allow easy integration with Dish queue management system create tasks
where required.

Once activation and provision has been completed, can the solution automatically set up
monitoring (and verify initial correct operation) of all virtual assets deployed to:
- Health monitoring
- Performance monitoring
- Threat monitoring or analytics
- Start to flow logs (DHCP, Netflow, Syslog, IPS/IDS, events and config) into a Data Lake or Cross-
domain assurance tool via Structured data streaming
The solution should be able to support modification requests for Service and Resource instances .
For e.g. it should be able to support automated modification of a firewall if a customer ceases a
web proxy thereby altering the configuration & policy rules (e.g set means to forward traffic (IPSEC,
GRE tunnel, PAC file), set source-based bypass (Skype for Business), user auth mechanism for
browser/cloud access policing, web filtration, proxy policy, O365 policy)
 
Solution should support cease requests on service and resource instances. This should be reflected
in the inventory.
Solution should have the ability to provide cloud based services over an existing customer WAN
that may have been procured from another provider.
Solution should be able to support 'Network Abstraction' that simplifies the Service
Design/Orchestration layer and allows it to create Services in a common way no matter what
network resource technology implements them
Supports cookbooks,scripts, blueprints; including the capability to use bash, Ansible, Openstack
Mistral
Support for non standard network interfaces: The OSS Fulfilment component should have the
ability to configure network components using other protocols like CLI, REST, NETCONF/RESTCONF.

Support for pluggable integration adapters on SBI side to integrate with 3rd party network
controllers or NEs directly

Vendor solution should contain automatic jeopardy management, requesting agent intervention
when (before) jeopardy flags are breached.

Service Order Management WF should be separated from Service Provisioning and Activation WF.
Service Order Management Workflow capability should be provided as part of the solution.
• Workflow should be standard BPMN 2.0 engine with the ability to import BPMN 2.0 XML?
• Availability of clear, simple extensions to the BPMN allowing data to be manipulated?
• Ability for workflows be jeopardy managed v customer promised date?
• Ability for workflows tasks to be jeopardy managed v expected task durations?
• Availability for distinct separation between workflow and orchestration.
• Product solution should offer dynamic workflow generation based on the intent model defined
on the catalogue.
• What technology adapters are supported by the workflow solution to facilitate south bound
integration?
• Can the workflow support the following scenarios:
o New provide
o Modify of existing service
o Cease of existing service
o Move of existing service from one site to another
o Takeover of existing equipment from customer or third party and adoption into a new Dish
service
o Ability to express in flight change to the above and pass down suitable instructions to the OSS.

Vendor solution should provide the feature to enable cross-service monitoring and management of
end-to-end processes without violating the core paradigms behind microservices through graphical
representation of business process making it easy-to-understand according to their logical
sequence and modelled based events from running processes
Ability to check whether the tasks have been completed in the expected order and within defined
SLA limits (for example, data retrieval time via API within workflow).

Abiity to provide graphical view the business processes using BPMN standard with automation
diagrams to track and ensure that the technical implementation process are executed dynamically.

Ability to model human activity with set of instructions as special cases within business process
model and workflows having prefilled UI exposed for the human to complete the task and update.
Solution should provide Fulfilment Workflow Status (based on API + GUI) minimum information to
be displayed like Current State, Previous State and the corresponding input/output, in case of
manual task person working on the task. .

Ability to program a workflow with both parallel, serial and conditional tasks in any combination.
Solution should have the ability to recover / resume a workflow that has previously failed. Please
provide details of how this can be achieved.
Ability to see and filter system activity, changes and interactions with end systems to assist with
audit trail and problem diagnosis with workflows.
Does the solution have the capability to aggregate and store all types of real time events, whether
they are informational, warning or exception, across all components?
Does the solution have the capability to aggregate and store both availability and performance
type real time events, across all components?
Does the solution have the capability to aggregate and store real time events from resource layer
sources that directly poll and remotely monitor (telemetry) across all components (NPM, ITPM,
APM, SPM and EUPM)?
Does the solution have the capability to aggregate and store real time log files?
Does the solution have the capability to aggregate and store all types of real time events?
Does the solution have the capability to aggregate and store both availability and performance
type real time events?
Does the solution have the capability to aggregate and store real time events from resource layer
sources that directly poll or remotely monitor (telemetry)?
Does the solution have the capability to aggregate the real time topology data?
Does the solution have the capability to aggregate real time component status and performance
data from the resource layer?
Does the solution make all of the data aggregated from the resource layer available to other
systems through the use of API's?
Does the aggregation solution support connecting new monitoring sources with minimal effort to
enable the aggregation of data via standard API's?
Does the solution allow the aggregation of service and resource inventory along with the KPIs
defined in the service specifications to determine if the service is working or not working?
Does the solution have the capability to gather, receive and store pre-correlated events from
external systems?
Does the solution have the ability to gather, receive and store monitoring data from cloud
applications and infrastructure?
Does the solution integrate with 3rd party infrastructure monitoring and management tools and
components via APIs in real time?
Does the solution integrate with cloud provider infrastructure monitoring and management tools
and components via APIs in real time?
Does the solution provide real time correlation for service availability impacts?
Does the solution provide real time correlation for service performance impacts?
Does the solution enable the pre-emptive identification of capacity issues, through trend analysis
aligned with historical understanding and evidence?
Does the solution support real time correlation across all domain (physical, virtual, network,
application, etc.)?
Does the solution provide the capability to correlate across many different types of source data,
including but not limited to events, logs, traps and topology?
Does the solution support the ability to detect event re-occurrences at the cross domain
monitoring level as opposed to relying on historic event analysis?
Anomaly Detection - Does the solution proactively monitor all components and process through
correlation any anomalous behavior to automatically trigger investigation by operations or
automatic remedial actions?
Can the solution correlate fault management data with performance management data?
Does the solution have the ability to gather End of Life data from sources across the components,
for the purpose of using this within the correlation output.
Does the solution have the ability to allow manual configuration of the correlation rules?
Does the solution define the root cause of the impact (availability or performance)?
Does the solution clearly explain the root cause of the symptoms being experienced?
Does the solution define clearly the symptoms that are being experienced, and ensure that these
symptoms are all linked to the single root cause incident?
Once the identification of root cause has occurred through correlation can the solution if required
trigger corrective action (through orchestrated resolution)?
Can the solution learn from previous experience to improve root cause identification?
Can the solution produce useful inferences with low false positives out of the box that also
improves over time?
Can the solution self learn and take feeds from guided learning to improve the root cause analysis
capability over time?
Does the solution ensure that customer service impact is the primary way that the level of impact
is determined?
Does the solution allow the determination of the customer service impact, in representing it in true
terms to the customer, that resonates with the customer in terms of their SLA's?
Does the solution present impacts in the form of End User experience? 
In the event of ANY major customer service disruption can the system  automatically assess and
report the scale of the disruption. E.g. Start / End time , volume of customers disconnected, reject
volumes, services unavailable etc.
Does the solution gather service related inventory and use this to define the impact to that service
when raising the incident?
Can the solution make determinations that go beyond the assessment of basic 'Is the service
working?' by answering 'Is the service working well' or 'Is the service working optimally'?

Does the solution have the capability to create problem records to the service desk when potential
impacts that are not currently causing an impact but will do if not actioned are identified?
Does the solution have the capability to manually and dynamically set rules to determine the
actions that are carried out based against specific events or traps being processed?
Does the solution have the capability to pass the required data to the service desk for the purpose
of providing reports and visualization of performance indicators for diagnostics in the form of real
time data analysis?
Does your solution (potentially via Service Orchestration) allow exporting abstracted data on KPIs
and alarms to be shown on customer technical portal?
The solution shall integrate with cloud provider infrastructure monitoring and management tools
and components via APIs in real time?
The solution shall support standards based interfaces for APIs and GUIs.
The solution shall support Closed Loop Operation, healing and scaling of 5G virtual network
functions and Network Slices
The solution shall support Anomaly Detection
The solution shall support SLA / KQI Calculation
The solution shall support service impact analysis and quantification based on Service KPIs and
Service Paths
The solution shall support Root Cause Analysis and Recommendations
The solution shall support Policy-based decision for manual or auto healing
The solution shall support AI/ML Predictive Analysis for network failures

Vendor must provide solution with flexible, modular approach and with loosely coupled components.

Solution must benefit from open platform based on open components like following examples.
KAFKA, DROOLs, React etc.

It should be possible to integrate the solution with OpenStack platforms.

Solution must include roadmap towards true micro-service based architecture and separate data
from logic.

Vendor must include within the solution self-analytical functionality (Machine Learning capabilities)
which analyze, optimize and improve automation workflows.

Vendor must explain what machine learning capabilities are provided within the solution and exactly
how the solution benefits from these. Examples:
• Pattern recognition, consolidation and validation
• Fix and Flexible rules proposition and generation
• Fix and Flexible automation workflow generation
• Evaluation of automation execution patterns
• Moving these rules to production
• Reactive and Predictive Use Cases
Vendor must explain how the solution architecture is ready to evolve to incorporate use cases for
5G, NFV (Network Function Virtualization) and SDN (Software Defined Networks). Vendor should
explain how the solution architecture will achieve and implement this.
Solution must implement automation workflows across all relevant alarms, so that no manual Alarm
Monitoring actions are required.

Ticket Lifecycle Management (LCM) functionality must include more advanced features than
standard legacy systems, which open, modify and close tickets with limited alarm data. Examples
• Collection of Troubleshooting commands and information
• Collection and Correlation of Log file information
• Validations against network layer
• Validations with Customer Care Data

Vendor must clearly explain and demonstrate the Automation Alarm Monitoring capabilities that its
solution uses. Example
• Automatic Troubleshooting mechanisms
• Automatic Recovery mechanisms
• Vendor should include 5 detailed examples of each mechanism in their response.
• Vendor should also explain how their automation workflows use these afore-mentioned
mechanisms.

Productized Automation Workflows must be capable of identifying and resolving False Positives
when alarms are received from Event Collection sources.

Please describe all types of supported alarm correlation types and provide examples.

Solution must include a mechanism, which monitors all Clear Events and cross references and
correlates these with the status of associated Tickets.

Solution must include a mechanism, which monitors all Closed Ticket Status and cross references
and correlates these with the associated Clear Alarms from the Network.

It must be possible to modify and configure the existing alarm correlation rules in the solution GUI, in
an easy and agile way

Solution must automatically manage Maintenance Window alarms (Planned Works etc.).
Vendor must explain how the solution handles & manages External Alarms (Power Supply, Air
Conditioning Failure).
Solution must support proactive assurance recovery automations not only based on alarms from
EMS. It must cover at least processing of following systems:
• KPI triggers from other Analytics sources such as Big Data Stacks or Internet of Things (IoT)
sources.
Vendor Response Vendor Comment