DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1

EMS-GT-0

EMS-GT-1

EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1

EMS-GT-0

EMS-GT-1
EMS-GT-0

EMS-GT-1

EMS-GT-0
EMS-GT-1

EMS-GT-0

EMS-GT-1

EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0
EMS-GT-1
EMS-GT-0

EMS-GT-1
EMS-GT-0
EMS-GT-1

EMS-GT-0
EMS-GT-1
EMS-GT-0
#REF!
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS shall manage all DISH network functions supplied by any 3rd party supplier (all PNF and VNFs (RU, DU, CU), Core,
Transport (including Microwave))
Provide information on cases and examples where the EMS vendor has delivered EMS for multi-vendor VNF/PNF.
The EMS shall be virtualized running on the DISH Cloud infrastructure including any commercial off-the-shelf (COTS) HW.
Provide the detailed specification and requirements for the platforms.
The EMS Solution must support the OSSii agreement to ensure integration/interfacing to other OSSii compliant systems.
The EMS Solution shall provide access to all EMS applications using PC/MAC-based clients via web based access (using
established browsers)
No client shall reside on end-user device beyond thin-client. HTML5 compatibility preferred
The EMS Solution shall provide an intuitive graphical user interface (GUI), using menus and dialogue boxes which allow the
operator to easily manage all VNFs/PNFs in the DISH Network.
The EMS Solution shall provide a command line interfaces (CLI) supporting all OAM Tasks.
The EMS Solution shall provide online context sensitive help and support documentations and be accessible on the system
itself, as well as off-line to support system recovery.
Please provide the information and solution for system recovery, in case of the EMS failure/loss.
The EMS Solution shall monitor its own resource usage and availability and raise an alarm if the usage exceeds its limit or the
availability drops below its limit.
The EMS solution shall include automatic cleanup (garbage collection) procedures to prevent the EMS servers from resource
leaks.
In case of communication failure with all defined NTP sources, the EMS solution shall be able to maintain an accurate
timestamp from an internal clock.
Provide information on the accuracy/drift characteristics of the EMS solution and the max number of hrs/days that it can
continue operation until the NTP connection is restored.
The EMS solution shall automatically discover the VNFs/PNFs.
The EMS shall support FQDN
Provide information on scaling-in and scaling-out solutions for the EMS.
Provide information on the EMS load balancing capabilities (of the EMS) when there are multiple virtual instances.
Provide information on interface requirements between the EMS and each supported VNF/PNF.
Provide information on database management requirement for the EMS (single vs. multiple, centralized vs. distributed,
redundancy…)
Provide information on interface requirements between the EMS and the external central database.
Provide information on the EMS availability/reliability.
Provide information on the SW upgrade, including in-service options/support.
Provide information on how the system back-up and recovery is supported for the EMS.
Provide information on naming and identification convention in the EMS and how it will be used for tracking and
troubleshooting.
The EMS shall support NW GUI for visual representation of all the sub-components within a VNF/PNF, interconnections, and
administrative and operational status.
Provide detailed explanation on how the managed VNFs/PNFs, resources, and subcomponents are represented in the GUI of
the EMS.
The EMS shall support On-line help - for all applications and functionalities, accessed from relevant GUI.
The timestamp in all generated events including alarms and status changes, logs, files (performance and configuration), shall
represent as UTC + offset from UTC of NF generating events.
The timestamp shall be of the node (EMS or supported NF) generating the original event.
The EMS shall log and store all the system initiated transactions.
The EMS shall make full backup of all the EMS runtime configuration data including network data, services managed by the
EMS, the user information, and the logs.

The backup shall be complete to ensure that when restored, the EMS will work the way it did when the backup was made.

No information shall have to be manually re-entered to resume the operation of the EMS the way it was when the backup
was made, although the EMS will have to synchronize with the network, in case there have been any changes to the network
since.
Provide information on the backup cycle time (i.e. hourly, daily,….)
Provide information on the EMS database restoration, following a major failure.
The EMS shall provide the option to make a customized backup (i.e., what to include or not).
Incremental or full backup shall not interrupt or interfere the use or operation of the EMS.
Provide information on the EMS dimensioning (processor load, database and memory load, limitation factors like connected
cells, transactions, etc.)…
Provide information on the integration points, available integration interfaces…for NFs managed by the EMS.
Provide information on the license management (the EMS and network licenses administration). Provide information on the
license management capability for multi-vendor NFs.
Provide information on the MOPs process for integration of NFs with the EMS. Will this be provided by NFs supplier or the
EMS supplier. Expand the MOPs process in a multi-vendor network.
Provide information on the Zero Touch process for NFs integration with the EMS.
Provide HB requirement to each NF and what happens when HB is lost and the actions that the EMS will take to make
changes to network or restoring the HB.

Provide detailed explanation on how the automated acceptance test and verification can be performed on the EMS solution.
Provide details on the software delivery process, quality assurance, release Plan, and the life cycle management.
The EMS GUI shall show the cross-layer topology views (hierarchical and modular topology) of the managed NFs (hardware
layout, connection view, and service view,…).
List all the regulatory and standards that the EMS complies to.
 Vendor Response Vendor Response
(Vendor Only Supplied (Vendor VNF/PNF + Vendor Comment
VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-FM-1

EMS-FM-0

EMS-FM-1
EMS-FM-0
EMS-FM-1

EMS-FM-0
EMS-FM-1
EMS-FM-0
EMS-FM-1
EMS-FM-0

EMS-FM-1

EMS-FM-0

EMS-FM-1
EMS-FM-0
EMS-FM-1

EMS-FM-0

EMS-FM-1

EMS-FM-0

EMS-FM-1

EMS-FM-0
EMS-FM-1

EMS-FM-0

EMS-FM-1
EMS-FM-0
EMS-FM-1
EMS-FM-0

EMS-FM-1

EMS-FM-0
EMS-FM-1

EMS-FM-1

EMS-FM-0

EMS-FM-1

EMS-FM-0
EMS-FM-1

EMS-FM-0

EMS-FM-1
EMS-FM-0
EMS-FM-1
EMS-FM-0
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS solution shall provide an Interface toward the operator's fault management systems and shall integrate with it.
The fault location functionality shall be made available to locate the faults within all the managed VNFs/PNFs (EMS , RAN ,
Core and Transport…)
For the faults detected on a managed NF, the corresponding alarm in the EMS shall indicate the location of the faulty NF.

The EMS solution shall classify the alarms into Critical, Major, Minor, and Warning notifications.
The EMS shall support NW GUI for a visual indication of presence of all the alarms (Critical, Major, Minor, Warning) on the
VNF/PNFs and, any sub-component as applicable, including the service impact information.
The EMS solution shall generate an alarm (according to a standard format, (for example: SNMP, CORBA, ASCII,…)) if an error
is detected in the interaction with an NF.
When VNF/PNF capacity is nearing its limits, an alert message shall be triggered.
When VNF/PNF capacity is exceeding its limits, an alarm shall be triggered.
When the VNF/PNF handling resource availability drops below pre-configured level, an alarm to increase resources (or
troubleshooting in case of memory leak) shall be triggered.
The fault tracing capability shall be provided as part of the EMS solution in online and offline operation modes.
Alarm Correlation: The EMS solution shall generate a single alarm and forward it to the upper network management layer in
the situation where a single fault causes a degradation in the operational capabilities of more than one physical or logical
resources within a NF. The EMS shall provide the details of the all impacted NFs in the alarm description.

The EMS solution shall automatically clear the alarm as soon as the fault is recovered and forward the corresponding clear
notifications to the upper network management layer. It shall also clear the alarm as soon as the fault has been
acknowledged/cleared at the upper network management system with synchronization maintained at all management
layers.
The EMS solution shall monitor the O&M connection with the NF and produce an alarm in case of a connectivity failure.
The EMS solution shall produce a heartbeat with configurable duration/interval to all managed VNFs/PNFs to ensure
connectivity. The EMS shall generate an alarm for the VNFs/PNFs without a heartbeat.
Vendor shall provide a list for all supported alarms that can be generated by the EMS solution for every managed NF.
Selected types of alarms must have the ability to be automatically broadcasted by various communication methods e.g.
system fail notifiable by SMS. As a result, severe events can be communicated to key stakeholders in a timely fashion to
support recovery actions.
Provide the list of the means of communications that are supported by EMS (such as SMS, WhatsApp,… ) for emergency
notification.
The EMS Solution shall have a correlation engine to efficiently correlate events and alarms.
It shall provide a single-pane-of-glass for alarm correlation and monitoring across the entire network that it manages.
Alarm type and correlated alarms information (such as but not limited to category) must be included in the standard alarm
format.
The EMS shall provide a probable cause for any fault/issue reported, if possible
The EMS shall support closed-loop operations (where EMS implements fixes or changes automatically without user
interaction). Provide information on supported closed loop operation.
The EMS shall process the occurrence of an alarm and identify the location of the VNF/PNF with associated severity attributes
depending on the nature of the alarm, such as:
Critical - Red Color
Major - Orange Color
Minor - Yellow Color
Warning - Blue Color
Alarm severity shall be configurable by the User/System/Operator request, without higher level technical support from the
EMS supplier.
The time stamp and indication of time zone and time zone source (e.g. NF, EMS) must be included in the standard alarm
format.
The alarm description must be included in the standard alarm format.
The fault localization information (if applicable) must be included in the standard alarm format.
The end-user impact of the alarm shall be described in terms of service impact such as but not limited to loss of coverage,
loss of service accessibility. As a result, the impact of a reported alarm is clearly known.

GUI- access control list (ACL) definition per functionality provided by the same GUI application. Ex. If configuration
management of several parameters are provided within the same GUI, Operator shall have the capability of specifying
privileges to a particular parameter which may not be apply to other parameters. This is to ensure the sensitive network
settings are accessible (read/write) by only selective individuals ( operators/administrators).
All alarms must be logged by the EMS in a log file on a non-volatile medium.
The EMS shall be able to collect the traces and the log files from the NFs (single NF and a group of NFs) and deliver it to the
nodes which handles logs and tracing.
The EMS shall be able to export the alarms via email to specific users. Provide information if other tools are supported for
exporting the alarms.
The EMS fault status report shall contain a list of alarms in the network with acknowledged/unacknowledged and
active/inactive status.
The EMS shall support API for integration with the operator user account management (e.g. a central identity management
system).
The EMS shall support filtering of the alarms. There shall be a flexible way to define fault filtering conditions, including
severity, general problem type, specific problem type, fault status, HW (PNF)/SW/NE type, and date/time.
Alarm documentation shall be available directly from the EMS.
Provide information regarding On-line help- FM : alarm viewer, description, cause, procedure to resolve, actions, severity
change …,

It shall be possible to search the alarm history by filtering on any alarm information.
It shall be possible to filter out alarms at both the system and the user level.
The EMS shall enable the statefull and the stateless event notifications to be delivered in real time.
The EMS shall be able to differentiate and isolate the alarm by service (per NF)
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-CM-1
EMS-CM-0
EMS-CM-1

EMS-CM-0

EMS-CM-1

EMS-CM-0
EMS-CM-1
EMS-CM-0

EMS-CM-1

EMS-CM-0

EMS-CM-1

EMS-CM-0

EMS-CM-1

EMS-CM-0

EMS-CM-1

EMS-CM-0

EMS-CM-1

EMS-CM-0

EMS-CM-1
EMS-CM-0
EMS-CM-1
EMS-CM-0
EMS-CM-1
EMS-CM-0
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS shall have audit capability to ensure consistency between the configuration data in the EMS database and the actual
NF configuration database.
The EMS shall have the capability to verify and ensure parameter consistency among a select group of NFs.
The EMS must be able to configure remotely all the equipment configuration parameters (using Yang, ASN.1, MML, TL1)
script or configuration file. Existing limitations, if any, must be detailed.
The EMS shall have the capability to schedule the execution of a script or loading of configuration file to a VNF/PNF or a
select group of VNFs/PNFs (bulk configuration).
The EMS shall have the capability to execute a script and load a configuration file to a VNF/PNF or a select group of
VNFs/PNFs.
The EMS must warn and require confirmation from the user that a single or a bulk change on a single or a number of
sites/NFs is about to be executed.
The EMS shall maintain a configuration database for all managed NFs.
After the initial manual EMS integration of a VNF/PNF, the EMS shall conduct auto-discovery of the VNF/PNF and insert the
node's configuration and inventory data into the configuration database.
In the event of an EMS restart, the EMS must conduct auto-discovery of NFs and insert the NF's configuration and inventory
data into the configuration database.
Any management activity that can be performed on the NFs must also be possible using the EMS. As a result, any
maintenance activity not requiring physical changes can be performed remotely.
The EMS shall provide the capability to manage the NF SW. This includes but not limited to installation,
modification/configuration changes, patch application, upgrades, and rollback.
The EMS shall allow operators to add, remove, modify, activate, de-activate, configure and view NFs and their relationships
off-line. After the NF becomes on-line, the EMS shall grab the new configuration or database of the NF and sync/update its
database.
Provide information on how the EMS adds and activates features on the NFs, including verifying licenses per feature and how
datafill for the feature is imported (to the EMS) and implemented on the NF.
The EMS shall support On-line help- CM configuration parameters description, range, building sanity/consistency checks,
related "How to" procedures.
The EMS must allow operators to create, modify (reparent), configure and view the transmission connectivity between the
managed NFs.
The EMS shall be able to verify the consistency of the parameter settings (vs. the golden parameter) before activating the
planned changes.

The EMS shall provide a virtual area where the planned configuration changes can be tested before being applied to the NF.

The EMS shall be able to generate the fallback configuration before applying the new configuration changes and be able to
rollback to the previous configuration in case of any provisioning/activation/configuration failures.
The NF configuration management data shall be visible and available on the EMS both via the command line and also in any
export interfaces (e.g. UI, Bulk CM export).
Changes made to an NF shall be propagated to any dependent configurations by the EMS. For example, changes to a cell's
carrier (e.g. due to refarming) shall be propagated recursively to its neighbor cell relations and its neighbor's neighbor cell
relations as per defined configuration management algorithms.
The EMS shall provide the capability to select multiple NFs from the GUI and perform data manipulation.
Provide information on how a feature are activated and deactivated on a NF by the EMS.
Provide information on the role of the EMS when the orchestrator instantiate another NF.
Provide information on the role of the EMS, from the time a slice is created, integrated, configured, through its performance
monitoring and reporting process.
Provide information on the debugging capabilities offered by the EMS for the NFs.
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-PM-1
EMS-PM-0

EMS-PM-1

EMS-PM-0

EMS-PM-1
EMS-PM-0
EMS-PM-1

EMS-PM-0
EMS-PM-1
EMS-PM-0
EMS-PM-1
EMS-PM-0
EMS-PM-1

EMS-PM-0

EMS-PM-1

EMS-PM-0

EMS-PM-1

EMS-PM-0
EMS-PM-1
EMS-PM-0
EMS-PM-1
EMS-PM-0
EMS-PM-1

EMS-PM-0
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS shall provide the functionality to collect all the performance and usage data from all managed NFs.
After the integration of a NF with the EMS, all the PM counters shall be configured and activated and ready to be sent to PM
system or designated External database.
The EMS shall be able to monitor the performance of the NF upon demand, in real time or near real time (near real-time
means as soon as the data is available according to the defined measurement granularity).
The EMS shall provide a function to process and display the real time and near real time performance measurements of NFs
via GUI.

The EMS shall provide an Interface toward the operator's performance management (PM) systems and shall integrate with it.
Provide information on interface requirements between the EMS and a 3rd party PM solution in the Dish network.
The EMS shall have the ability to transfer the performance and usage data to a PM System and a designated external
database.
The EMS vendor shall provide all performance formulas with the detailed description of each count/peg and their range for
all NFs.
All the supported data format and the content shall be made available to the PM system per release for each NF.
External access to the performance measurement files shall be available via the file transfer protocol (FTP) or secure file
transfer (sFTP). Provide information if other means are available.
The EMS shall be able to schedule and configure the performance measurements to be collected from the NF.
Provide information how the data is collected/pulled/stored for time sensitive services (such as URLLC).
If a NF is taken out of service, it shall automatically and immediately be excluded from those measurement processes by the
EMS.
After the SW upgrade for a NF, the EMS shall automatically pull and deliver the data for the upgraded measurements
including the updated PM counters and/or added new PM counters.
The recovery of the collected measurements from the NF shall be performed automatically when the EMS restarts or at the
NF connection restoration.
For the case of the EMS being down or out of service, when it comes back to service, it must collect/retrieve/pull the
available performance data from all NFs for the time that it was down, send the data to the PM solution and store it in the
Dish designated storage data.
For the case of a NF being down or disconnected, when the NF comes back to service or reconnected, the EMS shall
collect/retrieve/pull the available performance data from the impacted NF, send the data to the PM solution and store it in
the Dish designated storage data.
The EMS shall be able to handle daylight saving time so that there are no apparent gaps or duplicates in the PM data
measurements to ensure the correct local time is presented to the users of PM data.
The predefined performance reports shall be accessible via a standard web browser.
The EMS shall provide the capability for the users to create customized performance reports based on the data collected
from NFs.
The EMS shall provide a graphical user interface (GUI) for querying and viewing the performance data.
The EMS shall have the capability for the users to publish the performance reports (Ex; emailing the report to a defined list of
users)
The EMS shall provide the capability to generate performance reports and export it in PDF document, clipboard graphics,
graphics file or text file.
Provide information how the EMS can provide the performance of a slice defined in a NF. Describe the role of the EMS, from
the time the slice is created, integrated, through its performance monitoring and reporting process.
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-AM-1
EMS-AM-0

EMS-AM-1

EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1

EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0

EMS-AM-1

EMS-AM-0

EMS-AM-1

EMS-AM-0

EMS-AM-1
EMS-AM-0

EMS-AM-1
EMS-AM-0
EMS-AM-1

EMS-AM-0

EMS-AM-1

EMS-AM-0
EMS-AM-1

EMS-AM-0

EMS-AM-1

EMS-AM-0
EMS-AM-1

EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
EMS-AM-0
EMS-AM-1
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS shall have features to prevent any unauthorized access.

The authentication authority provided by the EMS shall provide functionality to add, modify and delete the user accounts via
a GUI.
The authentication authority provided by the EMS shall provide functionality to allow an administrator to reset user
passwords via a GUI.
The EMS shall ensure that no access is possible to the EMS without prior authentication against the centralized
authentication authority.
The EMS shall log and store all the user initiated transactions.
The EMS shall provide the option to have single sign on solutions based on security standards solutions.
The EMS shall implement a role based access control concept.
The EMS shall provide the functionality to define roles.
The EMS shall provide the functionality to assign access privileges to the roles.
The EMS shall provide functionality to assign users to roles.
The EMS shall provide functionality to assign access rights based on the role of the user and the NE group that the NE
belongs to.
The EMS shall support different levels of system authorization. The EMS shall provide access control and authorization
management necessary to prevent unauthorized access to sensitive data.
The access privileges and the roles shall be configurable via GUI.
Passwords shall not be echoed to the operator's terminal or GUI.
The EMS shall provide functionality to the users to change their password via the EMS GUI.
The EMS shall provide the possibility to audit user accounts via a graphical user interface to ensure the accounts have been
set up correctly.
The EMS shall provide the possibility to assign each user a dedicated user account with encrypted password.
The EMS shall provide centralized user management.
Provide information on the max number of user accounts by the EMS.
User inactivity timeout periods must be configurable and timeout periods must not impact upgrade or other maintenance
procedures.
Passwords chosen for account log on must follow industry best practices for password complexity criteria, including but not
limited to non-dictionary words and inclusion of non-alphanumeric characters.

The EMS must allow for the third party user access management via interfaces such as RESTful or command line interface.
Access to audit logs must be safeguarded to prevent any possible misuse or compromise (i.e. access limited to authorized
personnel only through specific application or system tools).
The EMS must be able to set the maximum size of audit logs. When the file gets full, it must either switch to a second file or
overwrite itself after proper back-up has taken place.
The EMS shall provide audit trail, recording system logon and all the major activities. The audit trail shall facilitate fast and
efficient access by the system administrator. The audit trail shall include the following items related to each activity (where
applicable): Timestamp, Action, Managed Network Element, Port, User Account, Command, Terminal).
Support of single sign-on (SSO) for all applications within the EMS complex is required.
Once the user is logged on, accessing other applications will not require user's login. However user's credential automatically
will be verified.
The EMS shall be able to detect and record the login attempts by the user.
The EMS shall be configurable for access violations (i.e. disabling access privilege).
Provide documentation showing all the functionalities assigned to each default ACL roles that are defined in the EMS and the
actions granted by each ACL item.
The EMS shall support local account management capabilities (using GUI) for user account and security administration,
including mechanisms for adding, changing, disabling, and deleting accounts (commonly referred to as user account
administration).

The EMS shall support GUI for the ACL definition per functionality provided by the same GUI application. Ex. If configuration
management of several parameters are provided within the same GUI, the operator shall have the capability to specify
privileges to a particular parameter which may not be apply to other parameters. This is to ensure the sensitive network
settings are accessible (read/write) by only selective individuals ( operators/administrators).
The EMS shall support GUI for the ACL definition per created NF accounts to grant and deny access to NF functionality.
The GUI shall support deactivating aging password for individual users and globally.
The EMS Access Management must be designed and implemented in a manner that allows for the use of a privileged account
and regular user account logins to perform two separate functions. At no point must a single user account be able to perform
both privileged and non-privileged roles.

The EMS shall provide a positive and complete response to a user (human and external applications) query or command only
when it has confirmed that the real-time requested operation has been completed. However, if such a response takes longer
than defined set time (duration value is configurable), it shall provide a brief acknowledgement message to indicate that the
requested action is in progress, and the complete response will follow. Vendor shall identify what the positive response is.

Requests that cannot be completed shall return a comprehensive exception explanation.

Whenever a transaction times out, there shall be a message to the application/end-user, and then the request terminated.
There shall be no left over residue from uncompleted tasks.
The execution time (or timer) must not exceed 30 seconds (configurable), for which an accurate execution time shall be
displayed.
The response time to open any GUI and Application must be less than 5 seconds.
The EMS shall support API for integration with the operator user account management. The API requirements are listed
below:
API- Administration Login
API- Fingerprint - query the EMS of its SW version and response

API- Data mining the existing users and their groups (query into the EMS/NF user account database and provide response)
API- Creating new users
API- deleting users
API- modify users
API- Changing a user's password
API- Changing the password of the management credential ( Admin Account)
API- positive response to administration commands once completed.
 Vendor Response Vendor Response
(Vendor Only (Vendor NF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-SW-1
EMS-SW-0

EMS-SW-1

EMS-SW-0

EMS-SW-1

EMS-SW-0

EMS-SW-1

EMS-SW-0
EMS-SW-1
EMS-SW-0
EMS-SW-1
Proprietary & Confidential - Not to be shared without NDA

Description

The EMS shall be able to perform the administration and control functionality for NF's software upgrade.
The EMS shall be able to download functionality for new SW release, update, feature and patch delivery, installation and
activation for all managed NFs.
The EMS shall be able to schedule SW download per the individual NF or subset of NFs (for example: type of NF, via
wildcards, percentage of NF type, and an editable list of NFs).
The EMS shall be able to maintain 3 versions of NF software with a minimum of 2 versions of configuration data per NF per
SW releases and the means to remotely activate a specific version.
The EMS shall be able to report on the current SW status, version number, date of last update, checksum, SW installation
error and status reporting.
The EMS shall be able to maintain a software management library, for all NF types including the EMS accessible by operator's
authorized personnel.
Provide information on the max number of RUs that can be upgraded/updated. Include the time it takes to download SW and
the time it takes to upgrade. State all assumption and dependency for this case.
Provide information on the max number of DUs that can be upgraded/updated. Include the time it takes to download SW
and the time it takes to upgrade. State all assumption and dependency for this case.
The EMS shall be able to support license administration capabilities for the EMS and the NFs.
The EMS shall be able to provide a license admin GUI- control for all available/enabled/optional features.
The EMS shall be able to enumerate all of the 3rd party licenses that are part of each NFs.
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-AC-1
EMS-AC-0
EMS-AC-1
EMS-AC-0
EMS-AC-1
Proprietary & Confidential - Not to be shared without NDA

Description

Provide information describing the tools and the features offered for automation, covering the EMS and all managed
VNFs/PNFs.
Provide information on automated test environment to verify new NF SW upgrade and acceptance.
Provide information on the automated integration for NFs (auto-discovery/plug and play) and the EMS role/function on new
instantiation/expansion/scale-in and scale-out with the orchestrator.
Provide information on implementation, features, capabilities based on machine learning algorithms in the EMS per NF.
Provide information vendors plan for AI and how AI and machine learning algorithm are implemented in EMS resulting in
changes/modifications in a NF configuration or setting and how improvements are measured and reported.
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-cS-1

EMS-cS-0

EMS-cS-1

EMS-cS-0

EMS-cS-1
EMS-cS-0
EMS-cS-1
EMS-cS-0
Proprietary & Confidential - Not to be shared without NDA

Description

Provide information on the role of the cSON in beam management in the 5G network. Provide information how this is
supported in a disaggregated multi-vendors gNB.
The solution shall support 5G CCO (Coverage Capacity Optimization). Provide information how this is supported in a
disaggregated multi-vendors gNB.
The solution shall support 5G mobility load balancing (MLB). Provide information how this is supported and its benefits in a
disaggregated multi-vendors gNB.
The solution shall support 5G ANR (Automatic Neighbor Relation). Provide information how this is supported in a
disaggregated multi-vendors gNB.
The solution shall support 5G CODC (Cell outage Detection and Compensation). Provide information how this is supported
and its benefits in a disaggregated multi-vendors gNB.
The solution shall support 5G SEH (Special Event Handling). Provide information on SHE in a multi-vendor network.
Provide information on cSON support in 5G for Plug and Play and the optimization process. Provide information how this is
supported for each NF.
Provide information on other cSON features supported by the EMS.
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)
DISH Proprietary & Confidential - Not to be shared without NDA

Requirement ID

EMS-TM-1
EMS-TM-0
EMS-TM-1
EMS-TM-0
EMS-TM-1
EMS-TM-0
EMS-TM-1
EMS-TM-0

EMS-TM-1
Proprietary & Confidential - Not to be shared without NDA

Description

The transport nodes are NFs and all the applicable EMS functions (Fault Mgmt, Config Mgmt, PM Mgmt, Access Mgmt, and
automation) will be applicable to transport NFs. The following EMS requirements are specific to transport NFs.
The EMS shall support management of the domain controller for IP/MW for the transport domain.
The EMS shall support management of hierarchical controller for transport domain (to orchestrate multiple transport domain
controllers)
Provide the list of transport nodes (NFs) that are supported and integrated by the vendor's EMS.
The EMS on the southbound of the controller should support standard SDN protocols (but not limited to) BGP-
LS/NETCONF/YANG/PCE-P.
The EMS layer shall present a unified graphical view of the entire network (physical and logical).
The EMS shall support the network path compute based on custom parameters (bandwidth, utilization etc...)
The EMS shall be able to use multiple metrics and provide options for different type of routings (Low latency route, Stable
under-used route etc..)
For the transport NFs, the EMS shall provide functionality to re-route the traffic to alternate path/node where needed
(example: for maintenance windows).
 Vendor Response Vendor Response
(Vendor Only (Vendor VNF/PNF + Vendor Comment
Supplied VNF/PNF) Any 3rd Party Supplied
VNF/PNF)