ISRAELI MOC Spectrum Management System (SMS) Requirement ... RFP … · MOC a holistic end-to-end...
87
1 | Page ISRAELI MOC Spectrum Management System (SMS) Requirement Document 2018 CRG Engineering Author: Ilan Ziv
Transcript of ISRAELI MOC Spectrum Management System (SMS) Requirement ... RFP … · MOC a holistic end-to-end...
1 | P a g e
ISRAELI MOC
Spectrum Management System (SMS)
Requirement Document
2018
CRG Engineering Author: Ilan Ziv
2 | P a g e
Table of content
1. General information ........................................................................................................ 5
1.1 Purpose .................................................................................................................. 5
1.2 Scope ..................................................................................................................... 5
1.3 References ............................................................................................................. 5
1.4 Acronyms and abbreviations ................................................................................. 6
1.5 Project assumptions ............................................................................................... 7
1.6 Project objectives .................................................................................................. 7
2. System’s architecture ...................................................................................................... 7
2.1 General .................................................................................................................. 7
2.2 On premises area ................................................................................................... 7
2.3 Secured area .......................................................................................................... 7
2.4 Cyber Protection layer ........................................................................................... 8
2.5 Non-secured area ................................................................................................... 8
2.6 API’s to external systems: ..................................................................................... 8
2.7 SMS General structure with connections to external systems .............................. 9
2.8 General operational process .................................................................................. 10
3. System’s environment .................................................................................................... 11
4. System’s infrastructure ................................................................................................... 13
5. Functional Requirements ................................................................................................ 14
5.1 Group 1 – Frequency Plan ..................................................................................... 14
5.1.1 Frequency plan workflow diagram ...................................................... 15
5.1.2 Frequency plan module workflow diagram description....................... 16
5.1.3 Frequency plan module requirements .................................................. 17
5.2 Group 2 – Engineering Module ............................................................................. 24
5.2.1 Engineering module workflow diagram............................................... 24
5.2.2 Engineering module workflow diagram description ............................ 25
5.2.3 Engineering Module ............................................................................. 26
5.3 Group 3 – GIS Module .......................................................................................... 30
5.3.1 Workflow diagram of GIS module ...................................................... 31
5.3.2 Workflow description of GIS module .................................................. 32
3 | P a g e
5.3.3 Requirements of GIS module ............................................................... 32
5.4 Group 4 – Licensing module ................................................................................. 37
5.4.1 Workflow diagram of licensing module .............................................. 37
5.4.2 Workflow diagram of licensing module .............................................. 39
5.4.3 Requirements of licensing module ....................................................... 44
5.5 Group 5 – Accounting Management ..................................................................... 49
5.5.1 Workflow diagram of accounting module ........................................... 49
5.5.2 Workflow diagram description of accounting module......................... 50
5.5.3 Requirements of accounting module .................................................... 50
5.6 Group 6 – Requirements for producing reports and prints ................................... 54
5.6.1 Requirements for producing reports .................................................... 54
5.6.2 Requirements for producing prints ...................................................... 57
5.7 Group 7 – History of system’s event and Logs Files ............................................ 57
5.7.1 Requirements for history of system’s events ....................................... 57
5.7.2 Requirements for system’s log files ..................................................... 58
6. Non-Functional Requirements ........................................................................................ 58
6.1 Group 8 – Requirements for configuration management ...................................... 59
6.2 Group 9 – Requirements for system administration ............................................. 60
6.3 Group 10 – System’s Operational Requirements .................................................. 62
6.4 Group 11 – Cyber protection and Data Security ................................................... 63
6.5 Group 12 – Failure Contingencies and DRP for SMS .......................................... 63
6.6 Group 13 – System’s interfaces ........................................................................... 64
6.6.1 MOC web portal to on-premise non-secured area ............................... 65
6.6.2 Remote site to on-premise non-secured area ....................................... 66
6.6.3 MOC Non-secured area to MERKAVA .............................................. 67
6.6.4 MOC non-secured interface with external systems ............................. 70
6.6.5 Monitoring OEM and sensors .............................................................. 76
6.6.6 Secured government systems ............................................................... 79
6.6.7 Secured line of On-premises site to Remote site ................................. 80
6.6.8 The Government Agency for Mapping (GAM) ................................... 81
6.6.9 User’s interface .................................................................................... 82
6.7 Group 14 – System Workflow Mechanism ........................................................... 83
4 | P a g e
6.8 Group 15 – System Customization ....................................................................... 85
6.9 Group 16 – System Performance .......................................................................... 86
6.10 Group 17 – System’s scalability requirements ...................................................... 87
6.11 Data migration ....................................................................................................... 87
List of figures
Figure 1 – General system’s architecture diagram............................................................................... 9
Figure 2 – System’s operational process diagram ............................................................................. 10
Figure 3 System environnement Diagram ........................................................................................ 12
Figure 4 – Frequency plan module – workflow diagram ................................................................... 15
Figure 5 – Engineering module – workflow diagram ........................................................................ 24
Figure 6 – GIS module – workflow diagram ..................................................................................... 31
Figure 7 – Workflow diagram of licensing module ........................................................................... 38
Figure 8 – Workflow diagram of licensing module (Trading and certifications) .............................. 39
Figure 9 – Accounting module – workflow diagram ........................................................................ 49
Figure 10 – MOC portal to on-premise non-secured area ................................................................. 65
Figure 11 – MOC Remote site to on-premise non-secured area ........................................................ 66
Figure 12– Interfaces between on-premise non-secured and MERKAVA ........................................ 69
Figure 13– MOC non-secured area interface with external systems ................................................. 70
Figure 14 – MOC non-secured area interface with MASLUL via E-Government ............................ 71
Figure 15 – MOC on-premise secured area to government systems ................................................. 79
Figure 16 – MOC on-premise secured area to remote site ................................................................ 80
5 | P a g e
1. General information
1.1 Purpose
The purpose of the Functional Requirement Document designated to describe the functional
requirements in MOC operational environment, of a COTS Spectrum Management System (SMS).
The system will be installed on-premises at MOC site and integrates with on-premise infrastructure.
1.2 Scope
The document encompasses the project’s motivation and initiatives, describes existing problems
today and suggests a new solution by implementing a COTS SMS that shall provide the Israeli
MOC a holistic end-to-end solution for spectrum management system with better user experience.
It defines the functional requirements of all system’s components in the working environment, data
elements, structure, constraints and interfaces with associated API’s.
The requirements describe the frequency spectrum management and engineering with associated
workflow requirements and data flow diagrams. In addition, it describes the necessary fee
processing, licensing and billing, report generation etc.
The document covers the requirements for flexible SMS assimilation and integration in the MOC
workplace and support for a long-term service, maintenance and upgradability as further describe in
this document.
1.3 References 1. ITU-R recommendations
2. CEPT recommendations
3. The defined instructions of accountant general in the finance ministry (HASHKAL).
6 | P a g e
1.4 Acronyms and abbreviations
AOA Angle of Arrival
API Application Program Interface
CEPT European Conference of Postal and Telecommunications Administrations
COTS Commercial Off The Shelf
DB Database
DLP Data Loss Prevention
DMZ Demilitarized zone (Isolated Zone)
DRP Disaster recovery plan (remote backup site)
FC Failure Contingency
GAM The Government Agency for Mapping (Survey of Israel)
GUI Graphical User Interface
HA High Availability
HASHKAL Accountant General in the Finance Ministry
IR Interface Requirements
ITU International Telecommunication Union
KPI Key Performance Indicators
(M) Mandatory requirement
MASLUL Licenses and certification status system for importers
MERKAVA ERP management system with accounting system in government offices
MFP Management of Frequency Plan
MOC Ministry of Communication
(O)R Optional Requirement
OEM Original Equipment Manufacturer
SHAAM TAX authority
SSD Solid State Drive
SMS Spectrum Management System
UPS Uninterruptible Power Supply
LAN Local Area Network
TDOA Time Difference Of Arrival
7 | P a g e
1.5 Project assumptions
1. Purchase a proven SMS (COTS) system that widely used around the world.
2. On-premises system’s implementation.
3. High level of maintainability with long-term support.
1.6 Project objectives
1. Flexibility to changes and modifications.
2. Interfaces to external entities; MERKAVA (based on SAP HANA platform), MASLUL, E-
government and other online business services.
3. Physical separation between secured and non-secured zones located at on-premise MOC
site.
4. Continuous updates of ITU-R data.
5. Database migration from existing system to the new one.
2. System’s architecture
All requirements that are listed in this chapter are (M) mandatory.
Interfaces requirements from the on-premise areas to external systems are defined in paragraph 6.6.
2.1 General
(M) The system’s architecture shall be designed as follows:
1. The system shall work on-premise at MOC site.
2. The on-premise area shall be physically separated to secured area and non-secured area.
3. A cyber layer shall protect the system and the data.
2.2 On premises area
(M) The on-premise area shall be separated into two working areas: secured area, non-secured area
and data security layer that protects the system and the data.
In this context, the database shall be physically separated while the master database located in the
secured area contains two DB schemes for the classified and none classified data. A partial database
located in the non-secured area shall contain non-classified data only.
2.3 Secured area
(M) Secured area components shall contain the following modules and components:
1. SMS Frequency module – Shall accepts and keep up to date data from ITU-R and frequency
committee and decisions, processes of frequency plans, frequency assignments etc.
2. SMS Engineering module – Shall provide interference predications per requested service, by
using propagation models and tools for a geo point of interest, allocate unauthorized-
8 | P a g e
unlicensed users etc. This process shall be defined as mandatory step before a frequency is
assigned.
3. SMS GIS module – Shall contain maps in various formats include various map layers that
shall be shared with the engineering module for interference prediction per given geo spot.
4. SMS Master Database - Shall contain updated ITU-R data and committee decisions,
customer’s records, accounting and licenses information, maps, engineering propagation
model’s, engineering tests results, records of reports, operational log files, history and
operational workflows.
5. SMS Administrations – Shall provide user’s authentication and authorization management
of individuals by a suitable security level etc.
6. Report generator – Shall be used by end users - system operator’s administrators for MOC
template generation and more.
7. High Availability server (HA) shall protect the secured working workplace from operation
system crashes, applications failures, network connectivity and database availability issues.
8. Engineering testing server assigned for all off-line testing, experimental tests and examine
engineering models.
2.4 Cyber Protection layer (M) The on-premise site shall contain a data security layer assigned to protect between secured and
non-secured areas from cybernetic attacks, data leaks, data loss from outside into the secured area
and vice versa. (Cyber protection and Data Security)
2.5 Non-secured area (M) Non-secured area shall contain the following modules and components that are responsible for:
1. License request processing
2. Accounting module for fee calculations
3. Data management and report generators
4. DB queries, reports, printings
5. mail server
2.6 API’s to external systems:
Assigned to interfaces between the on premises and external systems, both from the secured area
and the non-secured area as shown in the system’s architecture diagram – Figure 1.
The on-premise area shall interconnect with four external entities via secured interfaces and shall be
accessed via a secured access server.
Interfaces from non-secured area:
1. MOC portal – service portal for customers
2. MERKAVA – Management of debtors (receivables Management) with SMS license and
accounting
3. E-Government (Mimshal Zamin)
4. Other external systems and business services.
9 | P a g e
Interfaces from secured area:
1. Interferences to OEM monitoring tools, sensors, external secured government systems, etc.
2.7 SMS General structure with connections to external systems
Figure 1 describes the system architecture with interconnections and relationships within the system
in the on-premise area, the relationship between the system and the business environment and the
interfaces to external systems.
Figure 1 – General system’s architecture diagram
Cyber Protection Layer
with
Interconnect elements
ITU & Frequency
committee and
decisions
Frequency plan
processes and
assignment
Engineering tools
GIS
Report generator
Eng. Testing server
erver
HA server
(High Availability) Master DB
Accounting
Licensing and fee
calculations
Non-secured Area
None-secured DB
Online
milling
Reports,
prints
Secured Area
Secured
Access
Server
Interfaces to monitoring
tools, sensors, external
secured government
systems, etc.
E-Government
Links to
Registrars of
companies, civil
registry, center
for collection
fines etc.
Payment server
Ministry of
transport
Printing
companies
MOC Non-
Secured system
Israeli Post
MOC
WEB
Merkava
Secured
Access
Server
DRP, Backup
SMS isolated,
located in secured
area MOC - On-Premises site
Cyber protection
elements.
Stand-alone
testing server
at Vendor
premises
FW
system
The SMS non-
Secured area is
located in a
separate area
DRP for non-secured
10 | P a g e
2.8 General operational process
Figure 2 workflow diagram illustrate the SMS environment and its connection with external
systems.
(O) This figure is not a mandatory requirement
Figure 2 – System’s operational process diagram
Pass?
MOC
Website
Approved?
Pass?
Customer
Y
N
Y
Y
Fail N
Operational Process Diagram
Check request
(data format)
New
customer
?
Open new
customer ID
payment
history
ok?
Req. type & freq.
ok?
Send confirmation
N
Send reject
by email
N
Engineering
check & GIS
Assign Freq.
& update DB
Refine
Y Check frequency plan with
ITU & committee decisions
Secured
Server
access server
Pass
Fail
Pass
Y
Send license&
billing
Produce
license
decisions
Produce
billing
Licensing
Accounting module
Frequency
And
engineering management
module
Cyber suite
Engineering & GIS
modules
Merkava
Request to
SMS
SMS multiple
signatories’
workflow
mechanism
Non-
Secured
Area
Secured
Area
MASLUL E- Government
(Mimshal Zamin)
access server
11 | P a g e
3. System’s environment
All requirements that are listed in chapter 3 are mandatory (M).
Several system environments shall be established:
Table 3 – System environment requirements
3.1 (M)
Environment element 1: Development environment at vendor site
The requirements:
This environment shall serve the vendor development process and shall include development
tools, configuration management tool etc.
3.2 (M)
Environment element 2: Testing environment at vendor site
The requirements:
This environment shall duplicate the operational environment at the vendor site to enable testing
prior to installation at MOC site.
3.3 (M)
Environment element 3: Testing environment at MOC site
The requirements:
This environment shall duplicate the operational environment at MOC site to enable testing prior
to installation at operational environment. This environment shall be preserved at MOC site for
long-term support of new updates and new versions testing, including for the engineering team
tests at MOC site.
3.4 (M)
Environment element 4: Operational environment at MOC sites
The requirements:
1. The environment shall support all operational modules as described in figures 1 and 2
2. The system’s secured and non-secured areas shall be separately connected via a cyber
protection layer. (The protection layer described in figure 1 and in a reference, document as
shown in paragraph 6.4 Cyber protection and Data Security)
3. The secured area which is the main MOC operational area and non-secured areas are located
in different geographical sites.
4. The remote site shall host the DRP and backup system. (see details in paragraph 6.5 Failure
Contingencies and DRP )
5. The non-secured area shall host a DRP including for the licensing and accounting modules
3.5(M)
Environment element 5: Backup environment of the secured area at MOC remote site. (The
DRP)
The requirements:
This environment shall duplicate the operational environment. The SMS backup server shall be
ready for emergency mode of operation any time when required. The server shall be installed at
the remote MOC office. (see details in paragraph 6.5 Failure Contingencies and DRP)
3.6 (M) Backup environment for the non-secured site
Backup server for non-secured area will be part of the MOC non-secured area
12 | P a g e
(O) Figure 3 present in general the on premises system modules and the environment with the
associated external systems.
Note: This figure is a very general view of the entire system components and general flow
Figure 3 System environnement Diagram
MOC Non-
secured site
E-Government
(Mimshal zamin)
13 | P a g e
4. System’s infrastructure
1. (M) System’s role owners
The SMS shall support the following estimated role owners
a. Spectrum managers – 18 users
b. GIS capabilities - 15 users
c. Engineering department - 12 users
d. Licenses and accounting departments – 18 users including at the remote site
e. System administrators – 2 users
2. (M) The system shall support upgrading the number of users to 40 users for each module
without degradation in the system performances.
3. (M) The SMS shall operate on MOC premises. The infrastructure shall contain various network
elements, hardware, software and related equipment’s that are defined and updated periodically
upon instructions from accountant general in the finance ministry (HASHKAL).
4. The SMS environment shall support the following elements and technologies:
a. HPE (Hewlett Packard Enterprise) servers
b. Equipped HPE communication network
c. VMWARE virtualization infrastructure
d. Windows operating system
e. SQL database
5. (M) The vendor shall provide with a full list of equipment that is required for operating, testing
and backup site, according to HASHKAL up to date instructions. The equipment list shall
include communication equipment, hardware, software license and other infrastructure layers
and tools.
Note: ALL hardware components that assigned shall be defined, selected and approved by
HASKAL
14 | P a g e
Table 4.1 – System’s hardware components for GIS module
(M) The vendor shall provide with a full list of equipment that is required for the GIS module,
according to HASHKAL up to date instructions. All equipment shall be provided by MOC.
The shall specify at least the following hardware specification for GIS module:
4.1.1
Hardware requirements for GIS module:
1. 2 x GIS servers
2. 2 x external hard-disks support USB3 (disk capacity-10Tera each) for manual updates
of maps from GAM. (Refer to interface with GAM on paragraph 6.6.8 ).
a) One of the external disks shall be a non-secured unit. All updates from GAM
shall be uploaded manually to the disk.
b) The second external disks shall be a secured unit.
5. Functional Requirements
This paragraph describes the functional requirements of the system and are arranged by groups.
Each group represents a different SMS module or functionality requirement:
1. Group 1 – Frequency plan
2. Group 2 – Engineering module
3. Group 3 – GIS module
4. Group 4 – Licensing module
5. Group 5 – Accounting module
6. Group 6 – Report generation and printing
7. Group 7 – Event history and log files
5.1 Group 1 – Frequency Plan
Group 1 – Arranged by three sections as follows:
1. Workflow diagram - paragraph 5.1.1 figure 4
2. Workflow description - paragraph 5.1.2
3. Frequency plan module requirements - paragraph 5.1.3
15 | P a g e
Check request
Assign frequency,
and update DB
Y
N
On-premises – Secured area
update
Other systems
MERKAVA
Service request from
MOC portal
Fix request
by the
customer
MOC portal On-premises – non-secured area
Licensing module
Accounting module
Non-
secured
Database
Engineering Module - Group 2
Frequency plan module - Group 1
Secured server
Engineering module - interference prediction
analysis tools and testing
Secured
Master
Database
MAPS GIS layers GIS
Server
Y N
Refine
GIS module - Group 3
* Note 1
Committee decisions
updates shall be allowed
manually only.
* See note 1
Module input Module output
Bidirectional
data flow
Includes check of ITU,
Committee decisions,
notifications, coordination, etc.
Bidirectional
data flow
5.1.1 Frequency plan workflow diagram
This workflow diagram describes in general the processes in the frequency module and its
interactions with other SMS modules. In addition, it shows a fundamental connection to the
peripheral systems.
Note: The workflow schematic is not a mandatory requirement
z
Figure 4 – Frequency plan module – workflow diagram
Pass?
Licensing module - group 4
Accounting module - group 5
Approved?
Pass?
Frequency
plan module
16 | P a g e
5.1.2 Frequency plan module workflow diagram description
Table 5.1.2 - Frequency plan module workflow diagram description
5.1.2.1 (O) A request for new license, renewal, cancelation or change of an existing license shall
start with upload of a request by the customer via the MOC web portal. The request
shall be pushed to MOC licensing module on-premises non-secured area via the
secured server.
5.1.2.2 (O) System shall validate the customer’s request, according to MOC service request
template, and approve that the form has been filled correctly.
For example:
1. The requested/specified equipment has a valid type approval.
2. Frequency/Channel/service request is specified etc.
3. Etc.
5.1.2.3 (O) If any of these steps fail, a notice should be produced by the system, indicating
problem type and an appropriate notification shall be sent to the customer via the
mail server located in the non-secured area.
5.1.2.4 (O) An inquiry shall be sent to the database to check whether it is a registered customer,
or new customer. In case of registered customer, its record shall be checked for
existing licenses, payments and status.
Note: The flow may be blocked due to customer's pending debt and other
dependencies which are pre-condition for continuing the process. The dependencies
shall be also specific per license type.
5.1.2.5 (O) In case the customer’s request has been approved, the system shall accept the
incoming request and perform the following checks before the frequency is assigned
5.1.2.6
(M)
(O)
(M)
(O)
The requested parameters shown in the customer’s template shall be verified against
the committee decisions, notifications and coordination and related updates of the
ITU-R.
See notes bellow:
1. Data from the frequency committee meeting shall be updated and checked only
manually.
2. All other updates shall be implemented automatically and manually depends on
the operator choice.
3. Notes: Receiving updates from ITU-R/CEPT ERC by several possibilities:
▪ The SMS shall be delivered with the latest frequency allocation tables.
▪ When the regulatory authority (ITU-R/CEPT) published a new version, it
shall be send by the vendor to the MOC, in one of the available formats:
DVD, Printed or PDF depending on the MOC’s choice.
▪ Data from the regulatory authority shall be updated by either manually or
file import. The system shall be able to accept the incoming data from
the regulatory authority directory to a temporary non-secured SMS
database. That is depends on MOC policy.
4. Sending notifications from the MOC to the ITU-R by mail directly to the ITU-R
General Secretariat with short description about the nature of issue.
17 | P a g e
5.1.2.7
(O)
(O)
The requested frequency range/channel shall be checked by the spectrum team for
availability and validity automatically or manually in the frequency plan table,
according to the requested license and service type. The selection
(automatically/manually) will be by the operator choice.
The system shall be able to recommend the best frequency automatically
(in addition the ability to update tables by user’s choice. see paragraph 5.1.3.1.3)
5.1.2.8 (O) Note: in case that refarming is required, the team shall perform the required changes
in the frequency plan manually for optimization of the global frequency scheme.
5.1.2.9 (O) The validity check shall be an automatic process, by seamless functionality of two
major modules: the engineering module analytic tools and GIS module with its map
and associated layers.
5.1.2.10 (O) The final stage at the frequency plan module shall be the frequency assignment:
The assignment shall be acknowledged after the validity process of the engineering
module has successfully been completed.
5.1.2.11 (O) The customer request shall be approved for the next workflow stage after all stages
above were passed successfully and can be saved/updated in the database on
customer’s record.
5.1.2.12 (O) A notification shall be sent to the licensing and fee calculation module and fee costs
to the customer. (In case of debt, debtor and debt details shall be sent to MERKAVA.
(See paragraph 7.6.3 MERKAVA)
5.1.3 Frequency plan module requirements
Paragraph content:
1. Regulation requirements
2. Generation and administration of frequency plans
3. Frequency allocation plan/channel process
4. Radio stations coordination and notifications
5. Spectrum refarming
6. Frequency service assignment
Following are general rules requirements from the module:
1. The process shall be fully automated
2. User intervention shall be allowed at any workflow stage.
3. Change edit and add parameters shall be allowed.
4. A process continuation from any point where it stopped shall be allowed.
5. The process shall allow to making changes that already are defined in the system with or
without vendor’s support.
6. An additional requirement in the process shall be open to MOC as required
18 | P a g e
5.1.3.1 Regulation updates and display capabilities requirements
Table 5.1.3.1 ITU and CEPT Regulation requirements
ITU regulation requirements
5.1.3.1.1 (M) The system shall display the four-yearly updates of the radio regulatory tables
(RR), published by the ITU-R including FN(footnotes), with the ability to link the
note to the appropriate place.
5.1.3.1.2 (O) The system shall be capable to display the three ITU-R regions according to user’s
choice.
5.1.3.1.3 (M) Ability to update tables manually shall be possible by user’s choice.
5.1.3.1.4 (O) The system shall be able to receive new data set each time is published by the
ITU. The data set shall be provided by the franchisee and the system shall be
updated by a suitable interface.
5.1.3.1.5 (O) Display of service shall be relevant while selecting a frequency. The service shall
be displayed as defined by ITU-R. (Primary allocation shall be indicated by capital
letters and secondary allocation shall be indicated by small letters)
CEPT (ECA table) Regulation requirements
5.1.3.1.6 (O) The system shall be capable to display the ERC Report 25 frequency table of
CEPT, in a similar manner the ITU-R frequency table is displayed, while
considering the unique properties of the frequency allocations document (The
European Table of Frequency Allocations and Applications in the Frequency
Range 8.3 kHz to 3000 GHz – ECA Table) that published by the ECO’s EFIS
portal.
(CEPT) European Conference of Postal and Telecommunications Administrations
(EFIS) European Frequency Information System
(ERC) European Communications Office
5.1.3.1.7 (O) The system shall be capable to display the six columns of the ECA table while
filtering the various data in the tables.
5.1.3.1.8 (O) Manual frequency tables updates shall be available for user’s choice.
5.1.3.1.9 (O) The system shall be capable to receive new data set when publishes by the ITU.
The data set shall be provided by the franchisee. The data set shall be fed to the
system by a suitable interface.
19 | P a g e
5.1.3.2 Generation and administration of frequency plan
Table 5.1.3.2 – Generation and administration of frequency plans
5.1.3.2.1 (M) The system shall be capable to manage frequency plans automatically or manually
upon operator’s choice.
5.1.3.2.2 (M) The system shall allow customers to issue a request for a service via MOC portal:
1. Request to open a new license
2. Cancel an existing license
3. Renew an existing license
4. Allow update of an existing license; e.g. change station details, chancel
stations within an existing license, temporarily suspend station activity etc.
5. Request for several types of licenses by the same customer.
The customer requests shall be submitted via a secured government website using
an official template per requested service.
Customer request shall include the customer information:
1. License type
2. Frequency band
3. Time of operation (specific dates or hours)
4. Location and other parameters that will be defined by MOC template
5. Etc.
A notification about the request form acceptance or rejection will be sent to the
customer through email.
5.1.3.2.3 (O) When a request for a license is coming in, the module shall conduct channel/s
calculation to allocate the most efficient frequency band available, according to
ITU-R recommendations and frequency committee decisions, (Simplex links and
duplex links - for mobile and microwave applications).
- Simplex: (Half duplex etc.)
- Duplex: (Simultaneous bidirectional/two way etc.)
5.1.3.2.4 (M) The module shall provide features as frequency pairs (two-way links) in mobile
and microwave applications, service, footnote and channel pairing editors.
5.1.3.2.5 (M) The system shall provide graphical view of the frequency allocations and channel
allotments and advanced display capabilities.
5.1.3.2.6 (M) The system shall provide a map display the of communication equipment followed
by frequencies assignment.
5.1.3.2.7 (O) The system shall enable to administrate multiple frequency plans at the same time
with various validity dates, including channel allotments of a radio frequency or
radio frequency channel etc.
20 | P a g e
5.1.3.2.8 (M) The system shall provide a frequency plan report viewer including export
functions to various file formats as PDF and TEXT, Excel. (refer also to functional
group 6 - detailed reports requirements)
5.1.3.2.9
(M)
(O)
The system shall allow document management for frequency plans, allocations
and channels.
Edit of ITU-R national allocation plan shall be allowed as well.
5.1.3.2.10 (M) The system shall be able to print* on request the frequency assignments for
internal verification and add a notice to the attention of the spectrum manager if
the request is inappropriate. The function shall create appropriate entries in the
SMS for tracking notification progress. *Print – see paragraph 5.6.2 Printings Requirements
5.1.3.3 Frequency allocation plan/channel process
Table 5.1.3.3 - Frequency allocation plan/channel process
5.1.3.3.1 (M) The module shall wait for the necessary validation check and approval conducted
by Engineering and GIS modules before assigning of requested frequency channel.
5.1.3.3.2 (M) The system shall be capable to create and maintain the several frequency
allocation plans (frequency schemes).
5.1.3.3.3 (M) The system shall be capable to maintain channeling plans.
5.1.3.3.4 (M) The system shall be capable to store and retrieve frequency plan footnotes from
the database, automatically as part of a process or by a user query.
5.1.3.3.5 (M) The system shall provide the allocation frequency plan display in detailed textual
table and in geographical map display.
5.1.3.3.6 (O) The module shall investigate the availability of unassigned RF channels related to
the frequency plans. The module shall be able to display the unassigned channels
in formats of tables, on a geographical map or by defining a polygon.
5.1.3.3.7 (M) The system shall keep historical* track records of frequency plans including
configuration management**, their content, time stamp, responsible user and other
parameters that will be define by MOC.
5.1.3.3.8 (O)
The system shall be able to display several data layers simultaneously on the
frequency plan layer for data comparison purposes.
5.1.3.3.9 (O)
The system shall allow display of classified only when working on the system’s
secured area
21 | P a g e
Table 5.1.3.3 - Frequency allocation plan/channel process
5.1.3.3.10
(M)
(O)
(O)
Required functionality and visualization:
The system shall display the frequency range of 9KHz to 300GHz and performing
zoom in-zoom out, vertically and horizontally in the entire range in easy and
intuitive manner.
The system shall be capable to perform filtering manipulation on every one of the
PLANS
The system shall allow associating of colors with various services with capability
to change the colors manually
5.1.3.3.11 (O)
The system shall be able to export a filtered item to a table and provide a tabular
view with a simple transition capability between graphical to tabular view and
vice versa
5.1.3.3.12 (O)
The system shall be able to import an external program from external Excel files
by using an import Wizard.
5.1.3.4 Radio stations coordination and notifications
Table 5.1.3.4 - Radio stations coordination and notifications
5.1.3.4.1 (O) The module shall identify all license requests requiring border coordination and
will offer functions for coordination according to the relevant recommendations
and decision policy.
5.1.3.4.2 (O) The module shall handle both incoming and outgoing coordination requests.
5.1.3.4.3 (O) The system shall support coordination forms to be edited, printed and filed
electronically in a fully automated manner or manually, upon operator’s choice.
5.1.3.4.4 (M) The system shall search for interferences (that shall be acknowledged by the
engineering module) as a pre-service request. Once interference is detected, the
system should check if the area of interference is crossing a border using the SMS
built-in map (GIS module) that should contain all type of geographical data
borders and technical information data. Detected interference shall produce an
automatic notification to the operator.
5.1.3.4.5 (O) The system shall provide the name of the country for specific geographic
coordination including elevation, Lat/Long (by WGS 84 datum), the distance from
a transmitter to the closest border and other parameters that would be defined by
MOC.
5.1.3.4.6 (O) The system shall use all available data to check whether there is overlap with
channels allotted by regional of the international rules*. The mechanism must
generate the ITU-R notification files automatically in accordance with ITU-R
regulations and recommendations.
Note: *The system shall verify whether a reginal allotted channel overlaps with
channel/s of neighbor countries for example.
22 | P a g e
5.1.3.5 Spectrum re-farming
Table 5.1.3.5 – Spectrum re-farming
5.1.3.5.1 (M) The system shall support spectrum refarming and spectrum inventory feature
including measurement data that provides information about the actual spectrum
usage.
5.1.3.5.2 (M) The system shall provide the spectrum inventory to perform the required steps
towards frequency spectrum refarming and make use of it in the most efficient
manner.
5.1.3.5.3
(M)
(O)
The system shall allow all fees and costs factors as well as other implications
whenever a re-farming process is necessary.
The calculations shall be done automatically according to parameters that will be
define by MOC once the formulas are set and approved by the MOC.
5.1.3.5.4 (M) The system shall provide the capability to edit refarming calculation rules when
required.
5.1.3.6 Frequency service assignment
Table 5.1.3.6 – Frequency services assignments
5.1.3.6.1 (M)
The module shall support assignments/allotments for the following services as part
of the frequency plan process:
1. Land mobile and fixed services
2. Broadcasting services as LF/MF, HF, VHF/UHF
3. Microwave links, including millimeter waves (SHF/EHF)
4. Space services as earth stations (fixed satellite services (FSS), direct broadcast
satellite (DBS) etc.
5. Maritime mobile services
6. Aeronautical
7. Radio amateurs
8. etc.
23 | P a g e
5.1.3.6.2 (M) The system shall have a dedicated table containing the following fields of general
technical and administrative information:
The information shall be stored in the database per customer ID.
1. Name of station
2. Date of approval and when become operational
3. Assigned channel
4. Operating frequency
5. Bandwidth
6. Site geographical information
7. Designation of emission
8. Polarization
9. Transmitted power
10. Customer ID and detailed information
11. Approved time of operation (license expiration date and specific hours or week
days operation)
12. Etc.,
5.1.3.6.3 (M) 13. Additional tables containing:
a. Equipment data
b. Antennas, including antenna patterns
c. Additional data that will be defined by MOC
5.1.3.6.4 (M) All fields for each assignment/allotment shall be editable and only for granted
users.
5.1.3.6.5 (M) The system shall save the detailed assignment/allotments data file with all
parameters to the database.
5.1.3.6.6 (M) * The system shall be capable to keep and report all history records according to
customer, location, timeframe or other parameters that will be defined by MOC. *History records – See paragraph 5.7.1 Event History Requirements
24 | P a g e
Check
request
HF Broadcast Microwave VHF/UHF
Approved?
Pass?
Assign frequency,
and update DB
Y
N
Y Y Y Y
Master
Databas
e
N N N N
Refine
On-premises – Secured area
update
Other systems
MERKAVA
Service
request
from
MOC
portal
Fix
request by
the
customer
MOC portal On-premises – non-secured area
Licensing module
Accounting module
Non-secured
Database
Engineering module- Group 2
Frequency plan module - Group 1
Secured server
Testing
server
EMC Analytics
Engineering tools (prop. models) for
service request
Pass? Pass?
Frequency plan module
Includes check of Check
ITU, Committee
decisions, notifications,
coordination’s etc.
Bidirectional
Data flow
Module input
Module
output
Update DB’s
5.2 Group 2 – Engineering Module
Group 2 – Arranged by three sections as follows:
1. Workflow diagram in paragraph 5.2.1 figure 5
2. Workflow description in paragraph 5.2.2
3. Engineering module requirements in paragraph 5.2.3
5.2.1 Engineering module workflow diagram
This workflow diagram describes in general the processes of the engineering module and its
interactions with other SMS modules. In addition, it shows a fundamental connection to the
peripheral systems.
Note: This schematic presents a conceptual model workflow and it considered as an (O) optional
requirement.
Figure 5 – Engineering module – workflow diagram
GIS
Module GIS
server GIS module - Group 3
Licensing module - Group 4
Accounting module - Group 5
Etc.
Pass?
25 | P a g e
5.2.2 Engineering module workflow diagram description
Table 5.2.2 –Engineering module workflow diagram description
5.2.2.1(O) When customer request arrives via a MOC portal through a secured server it is
accepted by the licensing module for data screening. Once the screening is
approved, the request enters the frequency module to verify the type of request as
specified in the frequency module workflow process including checking the
frequency committee decisions and ITU-R decisions etc.
5.2.2.2(O) After the above step is approved, the system shall feed the request information to
the engineering module with all set of service request parameters including the
geo location of the requested service. For that reason, the engineering module
shall work in coordination with the GIS module.
5.2.2.3(O) When the geo location is known, the GIS shall provide the map or selected
polygon from the map and share all map’s data layers with the engineering
module.
The engineering module shall automatically identify the type of service and the
service geo location and select the appropriate tools (choose the proper
propagation model automatically) for the analytic stage per a desired service
type.
The procedure can be stopped at any time and parameters can be edited by an
authorized user
5.2.2.4(O) If the measurements and results of the interference prediction are satisfactory,
the engineering module shall notify the frequency plan module that the
assignment request is approved. The Frequency module then, shall allocate the
frequency properties and save the data into the database
5.2.2.5(O) If the results are unsatisfactory, a detailed procedure shall re-check the
parameters and refine the process until the results are satisfactory.
5.2.2.6(O) The engineering module shall be equipped with additional engineering testing
server that is assigned to perform separate tests, dedicated for off-line tests and
verification purposes. It also may serve the module to examine a specified
service request as required.
5.2.2.7(O) Once the frequency is assigned, the licensing module shall continue its process.
(See group 4 – licensing).
26 | P a g e
5.2.3 Engineering Module requirements
5.2.3.1 Preface
The Israeli Ministry of Communications (MOC) is responsible for setting policy and regulations,
opening up the communications market to competition and developing communications
infrastructures. The ministry is also responsible for supervising and licensing communications
providers, including phone, radio, TV, cable and satellite companies, frequency management and
the use of end devices.
The MOC's Engineering Administration comprises the following units: communications
engineering branch, planning and spectrum engineering branch and the wireless licensing domain.
The communications engineering branch is in charge of establishing engineering recommendations
for determining communication policies and regulation rules, defining technical specifications and
engineering standards for services and communications equipment.
The planning and spectrum engineering branch is in charge of managing Israel’s frequency
spectrum resource and of providing licenses for various users. As such, the branch plans, allocates,
assigns and allotments radio frequencies for civil users and defense entities. The planning and
spectrum engineering branch maintains regular professional contact with international wireless
communications organizations, collects licensing fees and frequency allocations fees.
The wireless licensing domain is in charge of issuing licenses for using frequencies and approving
the use of wireless equipment types – issuing trade licenses to entities, issuing type approvals for
wireless equipment, amateur radio equipment, terrestrial and mobile maritime equipment, TV and
radio terrestrial broadcast stations and satellite services equipment.
Almost every facet of modern life – in business, culture, security or entertainment, at work and at
home – depends on information and communication technologies, utilizing the frequency spectrum.
Thus, the demand for spectrum has grown significantly highlighting the need for efficient
managing, planning and use of all the frequency spectrum in order to avoid scarcity and
interference.
Consequently, the MOC has decided to procure an advanced Spectrum Management System (SMS)
to support its related activities. The SMS will enable the MOC to work in correspondence with the
International Telecommunication Union (ITU) regulations and decisions. Furthermore, to improve
the MOC engineering tools, capabilities and methods.
The required Engineering Module purpose is to assist the engineers in planning and managing the
complete radio frequency spectrum range and provide tools for Electromagnetic Compatibility
Analysis. The management of the radio frequency spectrum range includes various tasks regarding
current, new and future users, systems, links and services. The Engineering Module shall support
common radio services in the frequency spectrum range, based on the latest version of ITU
frequency allocation table (ITU WRC 2015), from 9 KHz to 300 GHz (VLF–EHF).
27 | P a g e
5.2.3.2 Engineering module – General requirements
Table 5.2.3.2 – General requirements of the engineering module
5.2.3.2.1(M) The module shall use a comprehensive collection of wave propagation models,
for the required radio frequency range 200KHz-60GHz, to assist the engineers
in their analysis, calculations, verifications and decision making.
5.2.3.2.2(O) The module shall use a comprehensive collection of wave propagation models,
for the required radio frequency ranges of:
a. 9KHz-200KHz.
b. 60GHz-300GHz.
to assist the engineers in their analysis, calculations, verifications and decision
making.
5.2.3.2.3(M) The module shall provide engineering analytic tools to support the engineers in
frequency assignment and inspection, for new demands and for special
required services.
5.2.3.2.4(M) The module shall be part of the SMS and shall interface and integrate with its
related modules along with the database, the GIS, and the frequency plan for
providing the engineers with the capability to analyze, calculate, display, save
and print reports and results.
5.2.3.2.5(M) The module shall interface with the GIS module to employ GIS layers data for
wave propagation analysis and calculations.
5.2.3.3 Service Support Requirements
Table 5.2.3.3 – Service Support Requirements
5.2.3.3.1(M) The module shall support the following services, as defined by the ITU:
a. TV and radio terrestrial broadcast stations.
b. International Mobile Telecommunications.
c. Terrestrial Fixed and Mobile Services.
d. Fixed Satellite Services (Earth-to-space and space-to-Earth).
e. Broadcasting Satellite Services.
f. Maritime Services (including terrestrial, mobile and satellite).
g. Aeronautical Services.
h. Amateur Radio Services.
5.2.3.3.2(O) The module shall support, at least, the following services as defined by the
ITU:
a. Radiolocation service (including automotive applications).
b. Earth Exploration Satellite Service.
5.2.3.4 Electromagnetic Compatibility Analysis Requirements
28 | P a g e
Table 5.2.3.4 – Electromagnetic Compatibility Analysis Requirements
5.2.3.4.1(M) The module shall provide capabilities to analyze and predict the interference of a
specific transmitter or multiple transmitters on a set of elements, equipment and
links, in a defined area or a polygon and assist the engineers in frequency
allocations and assignments.
5.2.3.4.2(M) The module shall support interference analysis, methodologies and tools to
assess:
a. Carrier to Interference (C/I) ratio
b. Threshold Degradation value
c. Carrier to Noise (Carrier/Noise) ratio
d. Margin potential for harmful interference.
5.2.3.4.3(M) The module shall utilize the necessary wave propagation models in accordance
with the appropriate services and frequency spectrum range to support the
required electromagnetic compatibility analysis.
5.2.3.4.4(M) The module shall have the capability to analyze one way or multiple
communication links within the required radio frequency range in a selected
polygon. Thus, to assist the engineers in optimizing the location of the link's
elements.
5.2.3.4.5(O) The module shall support spectrum analysis function to enable the user to place a
test receiver on the map and present the field strength values that are expected at
this position from the currently loaded transmitters. It shall be possible to move
the test receiver location on the map and the field strength values shall be
recalculated automatically.
5.2.3.4.6(M) The module shall have the capability to perform an intermodulation analysis on
existing or new stations, up to the 2nd order, in order to verify the impact on an
existing or new receiver station, caused by a transmitter or a set of transmitters.
5.2.3.4.7(O) The module shall have the capability to perform an intermodulation analysis on
existing or new stations, up to the 5th order.
5.2.3.4.8(M) The module shall support analysis capabilities for intra-service calculations.
5.2.3.4.9(O) The module shall enable access to the Radiocommunication Bureau International
Frequency Information Circular (BR IFIC) database for terrestrial services and
enable the user to perform queries and to import information.
5.2.3.4.10(O) The module shall support analysis capabilities for inter-service calculations for
different services of shared bands.
5.2.3.4.11(O) The module shall enable to define types of zones, the corresponding field
strength thresholds and frequency validity ranges.
5.2.3.4.12(O) The module shall support co-site calculations.
5.2.3.4.13(O) The module shall support compatibility evaluation between the sound
broadcasting services and the aeronautical services.
5.2.3.5 Modes of Operation Requirements Table 5.2.3.5 – Mode of Operation Requirements
29 | P a g e
Table 5.2.3.5 – Mode of Operation Requirements
5.2.3.5.1(M) The module shall work in automatic and manual modes in regard to user inputs:
a. In automatic mode, the module shall choose the appropriate wave
propagation model and parameters, execute and output the results.
b. In manual mode, the module shall enable the engineer to decide whether
to choose the recommended model and parameters or to analyze with a
different model and/or a different set of input parameters, such as but not
limited to: antenna heights, transmitter and receiver parameters.
5.2.3.5.2(O) The module shall alert whenever an inappropriate propagation model was
selected by the user (an incompatible configuration).
5.2.3.6 Display and Reports Requirements
Table 5.2.3.6 – Display and report Requirements
5.2.3.6.1(M) The module data and results shall be displayed consequently on geographical
maps and graphs, supporting the engineers in analyzing the results when making
their allocation, assignment and allotment decisions. This includes at least the
evaluation of the field strength, the power and the path loss.
5.2.3.6.2(M) The module shall enable the user to adjust and modify the graphical
representation of the power/field strength thresholds of the calculation results
according to the user’s preferences. The user shall be able to define the colors of
the different thresholds values, modify the power/field strength values of the
thresholds, and add/reduce the number of thresholds.
5.2.3.6.3(M) The calculations results shall be displayed in raster maps that can be overlaid on
the available maps.
5.2.3.6.4(M) The module shall support the display of the following, in a selected polygon, in
2D/3D view:
a. One way and multiple ways of communication links and stations.
b. Field strength.
c. Coverage contours based on a user defined threshold.
d. Path loss.
5.2.3.6.5(M) The module shall support graphical display of interference calculations and
allow access to detailed information.
5.2.3.6.6(O) The module shall support the display of overlap between interference contours.
5.2.3.6.7(M) The module shall support the production of the engineering reports to include the
selected parameters, the output of the calculations, the propagation model used
and the assigned frequency.
5.2.3.7 Wave Propagation Models Requirements
30 | P a g e
Table 5.2.3.7 – Wave Propagation Models Requirements
5.2.3.7.1(M) The engineering module shall include wave propagation and coverage analysis
models as follows:
a. Free space.
b. Sky wave.
c. Ground wave.
d. ITU 533.
e. ITU 370.
f. ITU 1546.
g. Okumura-Hata for urban, suburban and open areas.
h. HCM.
i. ITU 452.
j. ITU 530.
k. Aeronautical.
l. Walfisch Ikegami.
m. ITU 1812.
n. ITU 618.
o. Fresnel.
p. Atmospheric loss.
q. Rain loss.
r. Tropospherical.
s. Flat Earth.
5.2.3.7.2(O) The engineering module shall include wave propagation and coverage analysis
models as follows:
a. Modeling of e-band and v-band frequencies.
b. ITU 370.
c. ITU 525/526.
d. ITU 567.
e. ITU 1225.
f. ITU 1546.
g. Egli model.
h. Longley Rice model.
i. 3GPP/Cost model
j. Cost 231.
k. SUI model.
l. Bullington.
m. Delta Bullington.
n. Deygout
5.3 Group 3 – GIS Module
Group 3 – Arranged by three sections as follows:
31 | P a g e
1. Workflow diagram in paragraph 5.3.1 figure 6
2. Table of workflow description
3. Module requirements in paragraph 5.3.2
5.3.1 Workflow diagram of GIS module
This workflow diagram describes in general the processes of the GIS module and its interactions
with other SMS modules. In addition, it shows a fundamental connection to the peripheral systems.
Note: This schematic presents a conceptual model workflow and it considered as an (O) optional.
Figure 6 – GIS module – workflow diagram
and MAPs
pass?
Y
N
On-premises – Secured area
Other systems
MERKAVA
Service request from
MOC portal
Fix request by
the customer
MOC portal On-premises – Non-secured area
Licensing module
Accounting module
Non-
secured
Database
GIS module – Group 3
Licensing module – Group 4
Secured server
Frequency
plan module
Refine Master
Database Engineering module - Group 2
Y N Pass?
GIS Server MAPS and GIS Layers
Start engineering
analysis
Finish analysis
Import and Export Maps
Engineering module - interference prediction
analysis tools
Frequency Assignment
GIS SW: Maps in various formats, maps display functions, maps filtering
function, maps dynamic and static layers, printing options, import and export
maps
DB updates
Update DB Accounting module – Group 5
Frequency module - Group 1 Input Output
Refine
Update DB
32 | P a g e
5.3.2 Workflow description of GIS module
(O) optional
Table 5.3.2 - Workflow description of GIS module
5.3.2.1(O) GIS software contains various maps formats that are stored in the master
database.
The software shall enable various display functions as required by the operator
for example draw and copy a polygon at a special point of interest etc., the
module include map filtering function depend on the operator decision. Printing*
and copy of maps in various formats are available: PDF or as digital image (as
raster data or vector data) etc.
5.3.2.2(O) The GIS server assigned as a channel to import additional maps that shall be feed
to the GIS server by the authorized workers. Additional maps shall be saved to
the master database as well.
5.3.2.3(O) The map and its associated data layers projected on a display and assign to the
engineering module to start the interference prediction calculations on a specified
map geo point of interest.
*Printing – See paragraph 5.6.2 Printings Requirements
5.3.3 Requirements of GIS module
Following are general rules requirements from the module:
1. The process shall be fully automated
2. User intervention shall be allowed at any workflow stage.
3. Change edit and add parameters shall be allowed.
4. A process continuation from any point where it stopped shall be allowed.
5. The process shall allow to making changes that are already defined in the system with or
without vendor’s support.
6. An additional requirement in the process shall be open to MOC as required
GIS Module – List of tables
5.3.3.1 – Operational requirements
5.3.3.2 – Geographic map display requirements
5.3.3.3 – GIS data layers requirements
5.3.3.4 – GIS software characteristics requirements
33 | P a g e
5.3.3.1 Operational requirements of GIS module
Table 5.3.3.1 – Operational requirements of GIS module
5.3.3.1.1 (M) The module shall contain basic capabilities to import and export maps to and
from the system.
5.3.3.1.2 (M) The module shall provide maps format compatibility check:
Error detection feature shall be utilized when misalignments will occur, unless
all data based on the same geodetic datum or when combining topographic data
or mapping data from different sources.
5.3.3.1.3 (M) The system shall enable support of flexible mapping capabilities to allow the
user to choose from either the GIS mapping option that will be provided with
the system and any imported customer GIS mapping files to be provided by
MOC using a standard GIS file.
5.3.3.1.4 (O) The system shall have the appropriated interface to enable import and export of
standard GIS files to or from other GIS servers. The system shall support
uploading new map file and new static layers.
5.3.3.1.5 (M) The system shall support layers definitions and objects naming, symbols and
attributes to be defined by MOC.
5.3.3.1.6 (M) The system shall support GIS mapping coordinate data on the bases of WGS-
84, Universal Transverse Mercator (UTM), new Israel network (ITM) and old
Israel network (ICS).
5.3.3.1.7 (O) The system shall have GIS user interface editing tool/s that will support user
editing, adding or updating the GIS mapping, GIS layers or GIS database
entities relevant for the MOC.
5.3.3.1.8 (M) The system shall provide a map display with filtering option for static and
dynamic layers display.
34 | P a g e
5.3.3.1.9 (M) The GUI map will allow drag and drop, pan and zoom, multiple views, zoom
box, icon filtering and a dynamic legend. The main GUI map module
capabilities shall include the option for displaying different information in
different layers, and the option to select which layers should be displayed. The
system shall include:
1. Interactive map that displays current status of the frequency plan. Detailed
information on specific icon would be displayed with a mouse right click.
2. Map manipulation performance capabilities. Zoom in and out with different
zoom levels using zoom buttons and rectangle/window zoom features. Map
pan in any direction with a smooth seamless transition.
3. Set personal default type of map view and map setup view (e.g. type of
map, location, zoom, layers act.).
4. A capability of drawing a polygon on the map shall enable to get detailed
information of all elements in this specific geographic area, and save
information notes history for further supervision activities.
5. Layers toggle capability shall enable combined display by adding or hiding
selected layers and enabling also device toggle layer for each type of
system device event or layer.
6. Legend to allow viewing of all the system icon types, colors, statuses and
definitions, ability to show or hide the legend.
7. Customizable to allow the creation of new icons and layers
8. Each operator can open several windows for each map display, each
independently controlled.
9. (M)Map displays, information and events shall be updated at a minimum 2
minutes,
(O) via a configurable parameter.
10. Text displayed on the maps and in various pop-up windows and menus
shall be bilingual: selectable, English or Hebrew.
11. The System shall support display of English and Hebrew messages.
5.3.3.1.10
(O)
(O)
(O)
(M)
The system shall support GIS import and export of data to MOC GIS server
maps in various formats and information updates by the following methods:
1. Using MOC direct line between SMS GIS module and optional GIS server
on premises secured use only.
2. Using MOC Local GIS server/s mounted on premise equipped with two
removable disks that updated with new data from GAM. (procedure shall be
performed manually!)
3. MOC Local GIS server/s mounted on premise shall be updated with new
data from GAM by online interface between GAM and MOC on-premise
secured area.
4. SMS shall also support user capability to load manually and update maps
and GIS layers files as part of the system capabilities.
5.3.3.1.11 (O) The system shall enable to define display profile and preferences of each user
as a default view in each login.
35 | P a g e
5.3.3.2 Requirements of geographic map display
Table 5.3.2.2 - Requirements of geographic map display
5.3.3.2.1 (M) The GIS module shall be capable of displaying the radio stations, other field
equipment and links on a map.
5.3.3.2.2 (M) The GIS module shall contain a set of digital maps, on which several objects
can be placed, with various data as stations, microwave links, and subscribers
etc.
(This is required for the engineering models - wave propagation predictions)
5.3.3.2.3 (M) The module shall store the cartographic data layers in the database with
access to authorized users only.
5.3.3.2.4 (O) The system should provide the capability to generate electronic maps files.
5.3.3.3 Requirements of GIS data layers
1. GIS maps data layers shall be used for propagation model’s calculation interface prediction
by the engineering module.
2. The user shall be able to modify these parameters.
3. All digital topographic data for propagation and calculations shall be stored in the database.
Table 5.3.3.3 – Requirements of GIS data layers
5.3.3.3.1 (M) Image data layer:
This layer shall be flexible and allow using of several layers with different
resolutions simultaneously in the same task. for example, a satellite picture
and a road map etc.
5.3.3.3.2 (M) Clutter data layer: shall provide the nature of the terrain; water, forest, urban
zones etc.
5.3.3.3.3
(M)
(O)
Digital Terrain Model: (DTM) shall contain the altitude for each geo-coded
point on the map.
The resolution capability shall be from 10 m, 25 m, 50 m, 100 m etc.
depending on the DTM pixel resolution.
5.3.3.3.4 (O) The system shall support defining and loading new static layers that will be
reflect in the database and the display.
5.3.3.3.5
(M)
(O)
1. Maps data shall be available both for raster and vector formats
2. Supporting standard orthophoto map imaging (See requirements from
GAM in paragraph 5.3.3.5 table 5.3.3.5)
36 | P a g e
5.3.3.4 Requirements of GIS software characteristics
Table 5.3.2.4 – Requirements of GIS software characteristics
5.3.3.4.1 (M) The GIS software module shall contain full topological data structure.
5.3.3.4.2 (M) Capability of layers filtering shall be required as part of map display
capabilities.
5.3.3.4.3 (M) Display of the data associated with a chosen object shown on a map should be
possible (for example by mouse right click).
5.3.3.4.4 (O) The software shall allow to display information in user pre-defined scales and
projections.
5.3.3.4.5 (M) Display positions capabilities of specific points, lines, and areas on the map
background with associated descriptive texts will be available.
5.3.3.4.6 (O) Hard or soft copy of the screen (including graphics) will be available to be
produced by the application modules.
5.3.3.5 Requirements of GAM maps data formats
The GAM (the Government Agency for Mapping) provides a wide range of maps, in raster and
vector formats that shall be compatible with the SMS GIS module operation.
(See the table below)
1. The coordination networks and data formats that shown in the table are commonly known and
used worldwide.
2. The system shall be able to accept the maps in the formats and coordination networks as
specified in the table:
Table 5.3.3.5 – GAM maps data formats requirements The system shall accept the maps in the formats as detailed bellow:
Coordinates
network
File Data
capacity
Format Product
5.3.3.5.1 (M) *ITM/WGS84 Non-compressed 4.32 TB TIF
National
orthophotographs
(Resolution scale of
12.5)
5.3.3.5.2 (M) ITM/WGS84 Non-compressed 232 GB ECW
5.3.3.5.3 (M) ITM/WGS84 Non-compressed 358 GB SID
5.3.3.5.4 (M) ITM/WGS84 Non-compressed 2.04 GB GDB Topographic database
5.3.3.5.5 (M) ITM Non-compressed 6.35 GB TIF (O) Raster map (scale
1:50,000)
5.3.3.5.6 (M) ITM Non-compressed 8.02TB DTM
Maps data formats and coordination networks provided by GAM * ITM – Israeli Transverse Mercator
37 | P a g e
5.4 Group 4 – Licensing module
Group 4 – Arranged by three sections as follows:
1. Workflow diagrams in paragraph 5.4.1 Figures 7 and 8
2. Workflow description in paragraphs 5.4.2 and 5.4.2.1
3. Module requirements in paragraph 5.4.3
5.4.1 Workflow diagram of licensing module
This workflow diagrams (figures 7 and 8) describe in general the end to end process of the licensing
module and its interactions with other SMS modules. In addition, it shows a fundamental
connection to the peripheral systems.
38 | P a g e
Note: This schematic presents a conceptual model workflow and it considered as an (O) optional.
Figure 7 – Workflow diagram of licensing module
* Other systems (figure 7): Refers to banks, payment servers, printing companies, registrars of
companies, civil registry, israeli post, ministry of transportation. See paragraph 6.6 – Interfaces.
Figure 8 describes the management process of citizens requests for certification and confirmation
letters.
Several stages involved in the process: (Figures 7 and 8)
1. Submission of requests manually or via MOC on-line portal.
2. Some of the requests (such as requests for certifications) shall pass through the E-Government
and from E-Government to MASLUL.
3. MASLUL shall validate some incoming requests and send a feedback to E-Government. E-
Government shall send to the SMS licensing module the results as detailed in figure 8.
Note: Requests for trading license doesn’t goes through MASLUL
Validate
information request
Y
N
Open new
customer ID
and add to
non-secured
DB
Check request types: 1. update a license
2. additional license
3. Change service type 4. Cancel a license
5. Renew a license
6. Rrefarming required? 7. Verify customer ID, etc..
send query
to database. Load
customers
ID information
Service request
from MOC
portal
Verify existing or missing
customer general ID info. 1. Type of existing equipment 2. Frequency channel/band 3. GIS Location…
Y
Secured area
MOC portal
Accounting module (Module 5)
Non-secured area
MERKAVA
update
customer
by email
1. Notify – request accepted, in progress or rejected.
2. Send to request more info. 3. Request for certification disapproved
1. Payments
2. Payments due dates 3. Discounts
4. Compensations
5. Adjustments
6. Other…
N
Secured server
*Other Systems
Y
Pass?
Y 1. Notify process competed
2. Send license to customer
3. Send certification to customer
See details (next
in figure 8)
GPS
module
Pass?
New
customer?
P/O Module 1 P/O Module 1 Module 3 Module 2
Update
Update
Input from Licensing module (Module 4)
Non-secured area
Refine request
by the
customer
N Compare
customer
data on DB with
new
request info
Secured Master
DB
Non-secured DB
Daily
Sync
with master
DB
Calculate fee
Verify
required
request
Strat
accounting procedures
N
Refine
E-Government
MASLUL
Issue license
/certification
to customer
request completed
successfully?
certifications
Back from figure 8
- Disapproved
8. Request for trading
license, certifications
(See process - Figure 8)
Go to figure 8
Back from Figure 8
- Approved
Engineering
module Frequency
plan module
Assign
frequency and
update DB
GIS
module
Licensing module (Module 4)
Send start
or change
frequency
plan
39 | P a g e
4. Licensing module shall continue to manage the certification and confirmation approval from that
point and send the status of approvals to the citizens.
Note: The schematic presents a conceptual model workflow and it considered as an (O) optional.
Figure 8 – Workflow diagram of licensing module (Trading and certifications)
5.4.2 Workflow diagram of licensing module
Table 5.4.2 describes the licensing workflow diagram of all licenses requests and procedures,
statuses, and fees calculations until the license is delivered to the customer.
Table 5.4.2.1 describes the customer’s requests for trading licenses, and request for certifications
and confirmation letters etc.
On-line Requests via MOC WEB Portal
E – Government
(Mimshal zamin)
Part of SMS Licensing Module
Feed all type of requests request forms manually
On-line Requests
forms from citizens
Request is
valid? N
Y
Request
for trading
license
Periodic
confirmation One-time
certificate Exempting
of trading
license
Exempting
of
certification
match
Certification
match
Y
Send reject notification to the
customer or authority
MASLUL
Internal
SMS
workflow
Internal
SMS
workflow
Internal
SMS
workflow
Internal
SMS
workflow
Internal
SMS
workflow
Internal
SMS
workflow
Some of the request forms,
are being checked first by
MASLUL
N
No direct connectivity to
MOC on premises
Approved
Disapproved
Go to Figure 7
Go to Figure 7
Internal
SMS
workflow
Exempting
of trading
license
Proceed with the
process according to
the request type
From
figure 8
40 | P a g e
Table 5.4.2 – Workflow diagram description of licensing module
5.4.2.1 (O) Feed of incoming request from customers:
The process starts with a customer request by one of the above options:
1. On-line option opened for non-classified requests and shall be fed by the
customer to MOC portal via a secured server to the licensing module.
2. Manual feed of non-classified requests shall be done by MOC workers.
3. Manual feed of classified requests shall be done by certified MOC workers.
Note:
1. Verify whether the request is trading license or certification requests related.
If it does, please refer to the requirements in paragraph 6.4.3.1.
2. If the request relates to certification or confirmation letter from MOC, please
refer also to paragraph 6.4.3.1.
3. If the request does not require any request for trading license or certification
and confirmations approvals, then continue with the workflow description as
specified in the Table 6.4.2.
5.4.2.2 (O) The first action is a customer’s check in - request validation, whether all fields are
properly filled in accordance to MOC template.
After template validation completed, an email shall be sent to recipient notifying
status of request: (an email shall be send to unregistered and registered recipients)
The notification shall inform:
1. The request received and being processed.
2. The request rejected due missing of information, with instruction to Correct the
request and send again
5.4.2.3 (O) When the above step approved, an inquiry shall be sent to the master database to
verify if the request arrived from new customer or registered customer.
41 | P a g e
5.4.2.4 (O) Workflow description for new customer:
1. Verify the requested type of service/license coming in from MOC portal.
2. Start every customer request with verifying the following, depends of the
license request type.
a. License type requires frequency verifications process?
i. Yes – Proceed to the frequency verification process
ii. No – Bypass frequency verification process and continue directly to
calculate fee. (jump to step 7 below)
2. Next steps shall be performed in the master database:
a. Create customer’s ID with all customer’s personal details.
b. Save frequency required parameters according to customer’s request.
3. The frequency plan shall allocate the appropriate frequency band suitable for the
customer service operation request.
4. If the plan stage succeeded, the information will be send to the engineering
module for interference verification upon the customer service type, equipment
and location.
5. The engineering results shall be sent back to the frequency module and in case
tests where successful, the frequency shall be assigned, and data will be saved in
the database.
6. Customer classification:
a. When customer request is classified, the information will be saved only
in master database.
b. When customer request is unclassified, the information will be saved in
master database and replicated to the non-secured database upon a daily
schedule or as will be defined by MOC.
7. Calculated fees stage:
a. For new customers, proceed directly to calculate fee.
b. For registered customers: any debt should be checked
42 | P a g e
5.4.2.5 (O) Workflow description for registered customer:
1. Verify the requested type of service/license coming in from MOC portal.
2. Calculate fee stage:
Before continuing, any debt should be checked, not dependent on period or
payment method.
3. Start every customer request with verifying the following, depends of the
license request type.
a. License type requires frequency verifications process?
i. Yes – Proceed to the frequency verification process
ii. No – Bypass frequency verification process and continue to calculate
fee. (stage shown at the end of the table)
b. When approved, send notification to the customer by email and continue
the process.
c. When disapproved, send notification to the customer by email that the
process on hold until a correct request is accepted.
4. Start validity check for any type of requests for updates or cancel of licenses.
If the validity check stage approved, continue to next step 5.
When the validity check fails, the customer identity shall be verified by a data
security mechanism that shall be defined by MOC policy.
5. when validity check approved (according to parameters that will be defined by
MOC), the next steps shall be performed in the master database:
a. Extract existing customer card from the database.
b. Check if trading license or certifications are required and valid.
i. If valid – continue to next step and send notification by email to the
customer that the request is in process.
ii. If not valid – send a notification to the customer by email, that the
process on hold until the problem is fixed, and corrected request should
be sent.
c. Send all customer’s information ID card that extracted from the DB to the
frequency module.
d. Send the following queries to the database per each new incoming service
of registered customer.
i. Is it additional license?
ii. List of all existing licenses per same customer ID
iii. Request to change an existing service?
iv. Renew a license?
v. Cancel a license?
vi. Update a license?
Note: Before assignment of any frequency, data shall be sent first to the
engineering module to assure service is free of interference and ready for
assignment.
6. In case a registered customer requests to extend a current license without any
changes, jump directly to calculate fee.
7. The frequency assignment shall allocate the appropriate frequency band/s
suitable for the customer service operation request
8. If the assignment process succeeded, the information will be saved in the master
database together with rest of customer’s information.
9. Customer classification:
a. If customer request is classified, the information will be saved only
in the mater database. (secured area)
b. If customer request is unclassified, the information will be saved in
master database and replicated to the non-secured database upon a
daily schedule that will be defined by MOC.
10. Verify whether one of the below rules should be considered before proceeding
to calculate fee.
a. Request for multiple payment schedules: approved/disapproved of
43 | P a g e
5.4.2.1 WF* diagram of licensing module-trading and certification (WF*) Workflow
This module workflow describes the process of incoming requests from customers and
authorities to approve or update their requests for trading license, requests certifications
and confirmation letters.
For example: Release of radio-telecom equipment from customs upon MOC regulations,
verify and approve the purpose and usage of equipment’s etc.
Table 5.4.2.1 WF* description of licensing module trading and certification
(WF*) workflow
5.4.2.1.1 (O) Trading license is not always required at part of general licensing process.
A trade license is verified when such a license is provided to the trader (when the
trader is also a device operator), or when the license requester purchased the
equipment from the trader. (then, it is required to check if the trader has trading
license)
Trading license though, shall be required in the following cases:
1. Customer or importer that request new trading license
2. Renewal of an existing trading license
3. Update, change or expand an existing trading license
4. Trading license cancelation
5.4.2.1.2 (O) 1. In case a trading license or certification or confirmation letters are required,
the customer shall fill the request according to the MOC procedure and
instructions or via E-Government portal. the request form with trading or
request for certification/conformation letter attached in PDF format.
2. The incoming certification requests shall be transferred from E-Government
to MASLUL for validation and confirmation
3. MASLUL shall send an automatic validation feedback to E-Government.
4. E-Government shall send the feedback results to the MOC licensing module.
5. Results shall be sent a status to the customer by e-mail or SMS-message.
(Refer to workflow shown at figures 8 and 7)
6. It should be noted that a complete list of trading equipment must be
approved by MOC and synchronized with the trading equipment list exists
at MASLUL.
7. When the above steps were confirmed, the process shall continue to
customer’s approval request.
44 | P a g e
5.4.3 Requirements of licensing module
Following are general rules requirements from the module:
1. The process shall be fully automated
2. User intervention shall be allowed at any workflow stage.
3. Change edit and add parameters shall be allowed.
4. A process continuation from any point where it stopped shall be allowed.
5. The process shall allow to making changes that are already defined in the system with or
without vendor’s support.
6. An additional requirement in the process shall be open to MOC as required
This paragraph describes the requirements of the entire licenses types and related fee calculation
and approvals.
The requirements are differentiated between two main process:
1. Licenses requests from new customers and registered customers
2. Requests of approval for trading licenses, request for certification and confirmation letters.
The paragraph contains two tables:
Table 5.4.3.1 – Description of licenses and fee calculation requirements.
Table 5.4.3.2 – Describes of trading licenses and certification letters requirements
5.4.3.1 Requirements of licenses and fee calculation
Table 5.4.3.1 - Requirements of licenses and fee calculations
5.4.3.1.1 (M) 1. Customer’s requests shall be submitted via MOC portal. All requests will
be pushed to a secured access server and forwarded to the non-secured area
licensing module to start the process.
2. It should be noted that manual submission of all requests types shall be allowed
and are mandatory required.
3. The system shall accept incoming requests from customers by the following
possibilities:
On-line requests Via MOC portal for non-classified customers.
Manual feed requests for non-classified customers by MOC workers
Manual feed requests by certified MOC workers for classified customers.
5.4.3.1.2 (M) The module shall manage license holder that has several types of licenses
45 | P a g e
Table 5.4.3.1 - Requirements of licenses and fee calculations
5.4.3.1.3 (M) The module shall be capable to:
1. Issue a new license for a new customer.
2. Automatic renewal of an existing licenses and send notification to
customer.
3. License renewal by customer shall contain the cause for license renewal as:
changes in personal information, update of equipment type, request for
additional equipment or cancellation of license etc.
4. Support of licensing update and cancellation requests.
5. The system shall support a validity check of customer identity by using data
security mechanism according to MOC policy.
6. Modified license, renew an existing license etc.
7. Adjust the fee for an existing license
8. Adjust tariff for fee calculation
9. Terminate a license for non-compliance with the licensing conditions
10. Send a query the database to locate one or a group of licenses
5.4.3.1.4 (M) The SMS should support licensing processes and calculate fees for stations in:
1. Broadcasting service
2. Radio amateur service
3. Land-mobile and fixed services
4. Space services
5. Aeronautical services
6. Maritime mobile services
7. Microwave links services
5.4.3.1.5 (M) Shall enable fee calculation according to licensing type, equipment
characteristic frequency characteristics, and geolocation.
5.4.3.1.6 (O) The system shall be capable to update the calculation fee parameters
5.4.3.1.7 (M) Shall provide a way for printing of licenses
5.4.3.1.8 (M) Shall detect licenses due for renewal, and generate renewal invoices
automatically by email to the customer
5.4.3.1.9 (M) Shall support license cancellation and cancelled license re-instatement and
automatically calculate the appropriate fees
5.4.3.1.10 (M) Shall provide online queries capability to permit high detailed technical and
license information contained in the database
5.4.3.1.11 (M) The system shall enable a different licensing workflow for several licensing
types.
5.4.3.1.12 (M) The system shall support emailing notifications to MOC staff according to
workflow definitions by MOC. Such as renewal notification.
The emailing capability shall be part of the workflow process.
5.4.3.1.13 (M) Shall control and track the processing of license applications to ensure that the
correct applications are available at each stage of the cycle, and it automatically
progressed to the next stage until each process is completed.
5.4.3.1.14 (M) The system shall enable multiple signatures as part of the licensing process
workflow
46 | P a g e
Table 5.4.3.1 - Requirements of licenses and fee calculations
5.4.3.1.15 (M) Shall have facilities to accept prepayment from recipients and, at a later time,
apply the prepaid sum to invoices.
5.4.3.1.16 (M) Shall be capable to produce invoices conforming with specified formats.
1. Invoice amounts: should be automatically calculated by the system based
on fee schedule.
2. Invoice generation and fee calculation: shall be an integral part of the
licensing process.
3. Creation of invoices manually: the module shall support the functionality
that allows an invoice to be created manually, without being integrated to
the licensing process.
5.4.3.1.17 (M) Licenses and fee calculation in the west bank:
1. The requirement concerning the west bank customers is strictly a data
management manner.
2. The differentiation between west bank licenses care and all the rest are:
a. The license shall be titled as west bank related
b. The processes for both shall be the same.
*Invoice query and print – See paragraph 5.6.2 Printings Requirements
**Reporting - See paragraph 5.6.1 Report Generation Requirements
*** System’s interface with MERKAVA – See Interface paragraph 6.6.3
47 | P a g e
5.4.3.2 Requirements of trading license and certification letters
Checking the requirement for trading license and certifications for any radio-telecom equipment is
prerequisite stage, before continuing to license approval and fee calculation.
For some licenses processes, checking for radio-telecom equipment certifications is a prerequisite
stage, before continuing to license approval and fee calculations. Trading license is required for
importing, selling or trading in radio-telecom equipment and may also be checked in some of the
licensing processes before continuing to license approval and fee calculation.
Certification letters for radio telecom equipment mostly processed by MASLUL. This system is a
status system for import licenses and certifications, which links importers, customs brokers,
governmental and customs authorities. The system aims to make the process of submitting the
application to the license or approval of import, and the approval of the process to be simpler and
faster. System users can view the handling status of all requests by a variety of filter options in the
web portal, to be updated with general messages that are added by the MOC and will regularly
receive messages about handling requests.
Table 5.4.3.2 – Requirements of trading licenses and certification letters
5.4.3.2.1 (M) Customer request process shall start with request fed via the MOC portal, E-
Government portal or manually
5.4.3.2.2 (M) MASLUL shall examine the request and E-Government shall return a status
report to the SMS licensing module, notifying with the status of request.
Note: All updated statuses shall be available to customers on E-Government
web portal. (for view only)
5.4.3.2.3 (M)
The customer request process:
The system shall be available to customers for the following type of services:
1. Request for trading licensing forms arrived from citizens/authorities.
2. Periodic conformation
3. One-time certificate
4. Certificate matches
5. Certificate of type approval
6. Exempting from trading license
7. Exempting from the certified matches
48 | P a g e
5.4.3.2.4 (M)
The process of MASLUL - MOC:
The process of MASLUL shall be available and accessible to MOC
continually:
The information and activities that shall be available from MOC to MASLUL
via E-Government are:
1. Issue of citizen’s quires in various data segments and distribution reports.
2. Customers’ requests process
3. Type of customers approvals
4. Status of release from customs
5. View of other available data
6. Perform and advanced search
7. Request for various quires
8. Issue of reports
9. Get feedback from MASLUL via E-Government about customer’s status,
until the end of the process
10. Send status messages to customers that reported by MASLUL about:
a. Status of request
b. Reject notification
c. Approval notification
d. Administrative rejection
e. Partial approval etc.
11. Note: MASLUL MOC records and MOC database (via E-Government)
must keep identical data and should be continuously updated.
5.4.3.2.5 (M)
When trading license or certification are ready:
1. The licensing module shall send a notification to the customer that the
process is successfully completed
2. The module shall produce a trading license or certification and send them to
the customer in PDF format
5.4.3.2.6 (M)
Trading license of secured or government equipment:
This process shall not be performed by MASLUL and must be handled by the
secured area
49 | P a g e
5.5 Group 5 – Accounting Management
Group 5 – Arranged by three sections:
1. Workflow - Paragraph 5.5.1 Figure 9
2. Workflow description - Paragraph 5.5.2
3. Module requirements - Paragraph 5.5.3
5.5.1 Workflow diagram of accounting module
This workflow diagram (figure 9) describe in general the end to end process of the accounting
module and its interactions with other SMS modules. In addition, it shows a fundamental
connection to the peripheral systems.
Note: This schematic presents a conceptual model workflow and it considered as an (O) optional.
Figure 9 – Accounting module – workflow diagram
Accounting module (Modul 4)
Calculated fee
Non-secured area
Licensing module (M0dule 3)
Other
systems
MERKAVA
Service
request from MOC
portal
Service
request
from MOC
portal
MOC portal
Secured
server
Processes in licensing module
(Figures 7,8)
Strat accounting
procedures
Non-
secured
DB
Interfacing channel with MERKAVA
including feedbacks
from MERKAVA to the operational system
Update master DB
Bidirectional data flow
50 | P a g e
5.5.2 Workflow diagram description of accounting module
Table 5.5.2 - Workflow diagram description of accounting module
5.5.2.1 (O) The process starts with incoming push notification sent from the licensing
module to the accounting module to activate a new process.
5.5.2.2 (O) The accounting module shall accept the fee and open a session with
MERKAVA (the session shall be defined at later stage with MOC using a
suitable WEB services).
See table 7.6.3.3 - Interface 2
5.5.2.3 (O) By the end of the session, MERKAVA shall send a feedback of status request
5.5.2.4 (O) In case the payment is approved, the accounting shall update the non-secured
database and notify the licensing that the customer process is completed.
The licensing module will send the license in PDF format by email to the
recipient
In case a printed option license is required in the system, the module shall
send a request to a printing company via the MOC portal that will handle the
delivery to the customer and reply with a feedback when done.
5.5.2.5 (O) Note: Interface channel between MERKAVA and accounting module will be
detailed in the interface paragraph
5.5.3 Requirements of accounting module
Following are general rules requirements from the module:
1. The process shall be fully automated
2. User intervention shall be allowed at any workflow stage.
3. Change edit and add parameters shall be allowed.
4. A process continuation from any point it stopped shall be allowed.
5. The process shall allow to make changes that already defined in the system with or without
vendor’s support.
6. An additional requirement in the process shall be open to MOC as required
Table 5.5.3 – Requirements of accounting module
5.5.3.1 (M) The accounting module process shall be initiated with every request
coming in from the licensing module
51 | P a g e
5.5.3.2 (M) The accounting module shall send to MERKAVA the customer ID
according to MOC customer ID template: The template includes,
customer’s status (new customer or registered customer), customer name,
type of service requested, customer ID number, address and phone
numbers, Bank account number and other fields that shall be defined by
MOC.
The accounting module shall send the calculated fee to MERKAVA to
start fee collection process via a secured server
5.5.3.3 (M) MERKAVA shall acknowledge the incoming information by send a
feedback notification to the accounting module with status of:
All parameters were accepted and process in progress
Process ended successfully
Process rejected and reason for rejection
Missing information
5.5.3.4 (M) The accounting module shall send a status to the licensing module that will
shall the customer by email:
In case the request approved, and payment accepted – the accounting will
forward a request to the licensing to issue the license to the customer.
In case the request rejected, the accounting shall notify the licensing
module that shall send a request status and cause of rejection.
5.5.3.5 (M) All other feedbacks arrived from MERKAVA related to customer’s
payments as updated payments, payments notifications and reminders to
customers, payments due dates, notification status of collections fines from
customers. Module shall put license process on hold, display a full and
comprehensive view of the customer financial status for all costumer’s
licenses before continuing to approve of license.
5.5.3.6 (M) Every request shall be saved in none-secured database during the process
and updated in later stage, after receiving of a feedback from MERKAVA,
notifying that accounting that the process is completed.
All updates, requests and related log files shall be saved on master
database in the secured area on daily basis as scheduled by MOC.
5.5.3.7(M) The system shall enable multiple signatures as part of the accounting
process workflow according to different accounting processes
5.5.3.8 (M) The system shall support file exporting, printing and mailing of invoices
and other accounting documents.
5.5.3.9 (M) The module should have an invoice query and print/reprint* function.
5.5.3.10 (M) Facilities shall be provided to record payment against any number of
invoices. This should be an integrated function of the licensing process.
5.5.3.11 (M) Authorized users should be able to cancel invoice, cancel prepayment,
cancel payment, and perform adjustments.
52 | P a g e
5.5.3.12 (M) The module shall allow a refund of payment by authorized users.
5.5.3.13(O) The system shall support updating and calculations of refunds.
5.5.3.14(O) The system shall enable to update manually payments information in order
to solve mismatches between accounting module and MERKAVA.
5.5.3.15(M) The system shall maintain a financial ledger to record all transactions
within the licensing module.
5.5.3.16 (M) The system shall provide a user-definable chart of accounts and other
financial transaction codes and procedures necessary to maintain an
independent and auditable account book facility related to licensing
activities consistent with the national accounting standards and practices.
5.5.3.17 (M) The module shall provide account book reports and quires including:
Ledger and account summary
Ledger and account detail
Anomalous customer balance
Past due accounts
Invoices
Payment records
Account posting record (Postings the debtor and debt details accounting to
MERKAVA,
Payment voucher detail
Fee collection reconciliation reports
etc.
5.5.3.18 (M) The system shall have extensive management reporting** capabilities.
5.5.3.19 (M) Interest calculations, indexation and late payment fees:
Interest calculation, indexation and late payment fees shall be calculated by
MERKAVA and MERKAVA*** shall reply to the licensing module in the
SMS operational system the amounts and customers status.
The licensing module shall decide to accept or reject the customer request.
Note: In case MERKAVA will not calculate the interest and late payment
fees, the SMS licensing module shall calculate it.
53 | P a g e
5.5.3.20 (M) Additional accounting services:
Support different payments scheduling (yearly and quarterly payment
requests).
Support flexible fee calculation algorithm, based on various licensing
parameters.
Support transitions from one schedule to the other, and support fee
reduction or additional fees as a result.
Display a full and comprehensive view of the customer financial status, for
all customer's licenses
5.5.3.21 (M) The module shall support multiple payment schedules. (yearly or
periodically and quarterly).
5.5.3.22 (M) The module shall calculate the license fees depending on schedule, and
support different fees amounts per schedule.
5.5.3.23 (M) The module shall allow transitions from one payment schedule to the other
and will calculate the addition (or the reduction) in fees as result.
5.5.3.24 (M) The module shall generate separate payment slips per payment request (1
for yearly, 4 separate slips for quarterly payment schedule).
5.5.3.25 (M) The module shall maintain the link between the payment slips and the
license identifier, to support fully automated matching when payments are
booked.
5.5.3.26 (M) When license is updated, the system shall calculate the addition (or the
reduction) in fees and split the addition/reduction equally over the
remaining unpaid payment requests.
5.5.3.27 (M) The system shall support file exporting, printing and mailing of license
issuing.
5.5.3.28 (O) As an optional configuration, the system (the accounting and license
modules) shall be able to connect to a separate module as a replacement to
MERKAVA. This module shall be responsible for payments and debt
collections according to data provided by the SMS (am as descried at the
interface description of MERKAVA – (See Interface in paragraph 6.6.3)
5.5.3.29 (O) The system shall enable full support in accounting and payments
capabilities as an internal module of the SMS in case the interface to
MERKAVA will not be available.
*Invoice query and print – See paragraph 5.6.2 Printings Requirements
**Reporting - See paragraph 5.6.1 Report Generation Requirements
*** System’s interface with MERKAVA – See Interface paragraph 6.6.3
54 | P a g e
5.6 Group 6 – Requirements for producing reports and prints
The system shall support report generation for frequency plan and allocation, engineering reports
and maps in various formats licensing and accounting to support all types of operational and
engineering users in MOC. The system shall support designing new reports and producing reports
tools. The systems shall support screen display as well as, printing and exporting the reports to files
such as PDF and Excel. An automated report regarding notification of upcoming license renewal
procedures shall be produced by the system. The report services shall provide the capability for data
analysis and analytics reports for frequency analysis, engineering prediction analysis reports,
licensing trends, financing analysis etc.
Following are general rules requirements from the module:
1. User intervention shall be allowed at any workflow stage.
2. Change edit and add parameters shall be allowed.
3. A process continuation from any point it stopped shall be allowed.
4. The process shall allow to make changes that already defined in the system with or without
vendor’s support.
5. An additional requirement in the process shall be open to MOC as required
5.6.1 Requirements for producing reports
Table 5.6.1 Requirements for producing reports
5.6.1.1(M) Default template reports:
The system shall provide minimum of:
1. 60 default templates for reports
2. 60 default templates for queries
All the above shall be fully editable according to MOC requirements
Default template licenses:
The system shall provide minimum of 20 licenses types for MOC customers:
(The format shall be defined between MOC and the vendor in later stage)
5.6.1.2(M) The System shall provide the capability for users to create their own text,
graph or diagram reports, and allow them to use the standard reports supplied
with the System.
5.6.1.3(M) The reports are to be based on querying data contained in the System
database.
5.6.1.4(M) The reports will use built-in queries defined by the report module. Text
reports may also be based on SQL queries defined by the user.
55 | P a g e
Table 5.6.1 Requirements for producing reports
5.6.1.5(M) The system shall support a report designer tool to create new reports or update
existing reports.
The report designer tool shall contain also a Query wizard to assist in creation
of customized SQL queries. It shall enable interactive layout of reports, even
when in print preview mode, layout operations shall include moving, resizing
and alignment. The user will be able to create sophisticated report layouts,
including header, footer, text boxes, graphs and pictures.
5.6.1.6
(M)
(O)
The reports shall support all standard paper sizes A4 and A3
And others common standard sizes as A2, A5 etc.
5.6.1.7(M) This tool shall support macros to allow user to include in the report generator
automatically generated text in the header, footer and text boxes. Macros may
include the date, time, page count, page number; report name, average field
value, minimum field value, maximum field value, and sum of a field value.
5.6.1.8(M) All text objects (header, footer, text boxes and text report headings and data)
may have the following attributes assigned: font and size, foreground,
background and border color, indents, justification, border width and position,
and line spacing with unlimited undo and redo of all design functions,
Including copy and paste of text boxes and pictures between reports, graph
report chart types include: 2-D line, bar, area and scatter, 3-D surface, bar, pie
and other chart types that will be defined by MOC.
5.6.1.9(M) The report tool shall support filtering and sorting on one or more fields in text
reports. Filtering operations include equals, between, like, and in, not equal to,
less than, greater than, less than or equal to and greater than or equal to and
other operation logics.
5.6.1.10(M) The report tool shall support a report explorer which allows the user to copy
and paste existing reports, and to create a folder structure to contain reports.
Reports may be exported to the clipboard or to file in RTF textbox, RTF table,
tab delimited, comma separated, or user specified delimiter formats.
5.6.1.11(M) This tool shall include export filters for PDF, HTML, Excel, Text, TIFF, RTF,
and RDF. Page reports also support XML and Word formats.
5.6.1.12(M) This tool shall support fonts from multiple languages including English,
Hebrew with font linking and fallback fonts.
5.6.1.13 (O) The reports shall include data analysis (crystal BI e.g.) tool to provide the
capability for statistics and data analysis and analytics reports for frequency
analysis, licensing trends, financing analysis etc. These reports shall provide
data analysis of historical data and records.
56 | P a g e
5.6.1.14
(M)
The system shall allow to generate any kind of the report or document,
including:
1. Notices
2. Invoices
3. Licenses
4. Correspondence
5. Engineering analytics
6. Required pre-defined reports that will be defined by MOC.
Note: In case invoices will be generated by the SMS, MOC shall
verify the required process that must be approved by the TA (Tax
authority).
5.6.1.15
(O)
(O)
(O)
The requirement: Creation of system reports for all modules: Frequency plan
occupancy, engineering modules, GIS, licensing and accounting that include
incoming updates from MERKAVA.
The user shall generate statistic reports on the database, under the form of
histograms or of printable lists to analyze their data. This shall be provided by
support of BI tools for business analytics e.g. to create customers trend
histograms and more, based on all customer’s data collection stored in the
database.
Creation the above by build in crystal report generation capability is
preferable
5.6.1.16 (O)
The following defines the system ability to send monthly reports
automatically to the relevant MOC office role owners that shall be defined by
the system administrator
The system shall be able to produce the following monthly reports:
1. Number of request opened
2. Number of requests that were processed
3. Number of requests that were processed and approved
4. Number of rejected requests
5. Total number of requests that are in process including requests that
arrived last month and did not completed yet.
Notes:
1. This process shall be defined as part of the system workflow capabilities.
2. Monthly reports listed above shall be automatically sent by e-mail via the
mailing server to the relevant MOC role owners and under the system
administrator approval.
57 | P a g e
5.6.2 Requirements for producing prints
Table 5.6.2 - Requirements for producing prints
5.6.2.1 (M) The system shall support printing of licenses. (Standard format and complex
format as will define by MOC).
5.6.2.2 (M) The system shall be capable to print all reference tables used by the system.
5.6.2.3 (M) System shall support printing of interference analytic results based on the
propagation models part of the engineering module.
5.6.2.4 (M) The system shall support printing of maps in PDF format in different scales that
will be available for the user’s choice
5.6.2.5 (M) The system shall print on request, the frequency assignment for internal
verification purposes.
5.6.2.6 (M) The system shall be capable to print invoice queries.
5.6.2.7 (M) The system shall be able to print list of reminders to customer or for internal
purposes.
5.6.2.8 (M) The system shall be capable to print logs and event history stored in the
database.
5.6.2.9 (M) The system shall be able to print log files when required
5.6.2.10 (M) The system shall be able to print any user’s query from the database, e.g.
customer’s ID cards, customer’s statuses and profiles
5.7 Group 7 – History of system’s event and Logs Files
5.7.1 Requirements for history of system’s events
Table 5.7.1 – Requirements for history of system’s events
5.7.1.1 (M) The system shall offer a complete auditing feature that records the modification
history of all modules tables.
5. 7.1.2 (M) The system shall allow to save every system’s operation action in log file. The
log can be filtered and examined for further action by the operator etc.
5. 7.1.3 (M) Each confirmed user’s action shall be logged in the database. This log can be
evaluated to track user actions and used for future tack, discussions and
investigations etc.
5. 7.1.4 (M) The administrator shall have the possibility to display in each list view when
the records have been modified and by whom:
58 | P a g e
5.7.1.5 (M) Abnormal system health behavior that detected by the built-in system’s
performance monitoring shall be saved as an history event and send an
automatic notification event status to the system administrator for further
actions.
5.7.2 Requirements for system’s log files
Table 5.7.2 – Requirements for system’s log files
5.7.2.1 (M) System shall be capable to capture and save all transactions between the
system and the operator, or data collection that automatically captures the
type, content and time of transactions made by the user.
5.7.2.2 (M) The system shall include logging module that enable to generate, filter, record
and analyses log messages.
5.7.2.3 (M) An event logger shall record all transactions during the execution of the
system, save it on the database for use of data for audit trail, system’s
diagnostic behavior etc.
6. Non-Functional Requirements
This paragraph describes the non-functional requirements and is arranged by the following groups:
Group 8 – Configuration Management
Group 9 – System Administration
Group 10 – Operational Requirements
Group 11 – Cyber protection and data security
Group 12 – Failure contingencies
Group 13 – Interfaces
Group 14 – System’s workflow mechanism
Group 15 – System customization
Group 16 – System performance
59 | P a g e
6.1 Group 8 – Requirements for configuration management
The configuration management shall be provided either as an integrated module of the COTS SMS
or an external configuration management tool that will be installed in the MOC on-premise area and
shall interface with the SMS.
Table 6.1 - Requirements for configuration management
6.1.1(O) The system shall provide software version control:
Stores and follow software versions of the system’s components by:
1. The nature of change/update/upgrade
2. Date of change/update/upgrade
3. Unit/part name
4. Updated by whom
5. Previous version
6. New version
7. Version interface control
6.1.2(O) The system shall provide database maintenance and version control:
1. Maintain database builds numbers by version history
2. Keep content of minimum last three builds
3. Support data migration procedures
4. Support maintenance procedures
a. Description of maintenance
b. Performed by
c. Execution date
d. Related logs when necessary
6.1.3(M) The system shall provide data history and records follow-up:
It may be controlled by either:
1. Configuration management tool as part of the SMS
2. External configuration management application
6.1.4(O) The system shall have a module management for system’s bug report:
The module shall allow to control and follow:
1. Problem description
2. Report date
3. Severity
4. Urgency
5. Follow-up vendor support and expected date for bug fix.
6. Implementation of new feature tested by the vendor and installation in
the operational version
60 | P a g e
6.1.5(O) The system shall allow to manage new features:
1. Date of issue
2. Requirement description
3. Follow-up with vendor: Development, testing, implementation and
installation at the operational customer’s premises.
4. Date for upgrade.
Items 1-4 shall be agreed with the vendor
6.1.6(M) The system shall allow saving of software configuration backups
6.1.7(O) The system shall allow to record software versions for pilot test sessions*:
1. Brief of pilot motivation
2. Start of tests session
3. End of test session
*Indicate the impact on the frequency plan (yes/no) and the demo duration
6.1.8(O) The system shall allow to manage follow-ups of periodic system’s compliance
tests and maintenance procedures.
(Results shall be saved on the database).
6.1.9(O) The system shall allow to save system performance follow up reports
6.1.10(O) The system shall provide quarterly configuration management report with
filtering option.
6.1.11(M) The system shall provide a roll back capability to previous system's version.
6.2 Group 9 – Requirements for system administration
The SMS shall have utilities to perform all necessary user administration as follows:
Table 6.2 – Requirements for system administration
6.2.1* (M) Maintain user management and access control through predefined user’s rolls
and permissions.
6.2.2 (M) Support capabilities of adding constant fields and records such as license type,
license status, region, emailing formats, payment interest etc.
6.2.3 (O) Support capabilities of updating system parameters such as payment due time
duration etc.
6.2.4 (M) Support capabilities of defining system workflow that combines the required
order of system's procedures and manual required activity for each process. The
system's procedures shall support internal module activity or external interface
activity.
6.2.5** (O) Provide capabilities of periodic maintenance procedure table.
6.2.6 (O) Have extensive automatic housekeeping functions, e.g. DB management, file
archive etc.
61 | P a g e
6.2.7 (M) Provide automated procedures for routine backup*, database integrity
validation, and recovery.
* Backup is required:
1. On the backup server, on-premise
2. On the backup server at the remote site
6.2.8 (M) Have query functions for on-line screen viewing of system’s data
administration.
6.2.9*** (M) Have an extensive management report capability.
6.2.10 (M) View system logs and send automatic warning to system admin when severe
malfunction occurs.
6.2.11 (O) Control panel to enable the system administrator module/ system reset,
interfaces reset/ up/ down, maintenance information of system.
* (Item 6.2.1 in the table) The system administrator shall define all security levels rules and user’s
permission profiles.
**Properties are defined at paragraph 6.1, 6.1.9 in the table
***See table - paragraph 5.6.1
62 | P a g e
6.3 Group 10 – System’s Operational Requirements
The operational requirements shall describe on how the users will operate the system, including
interfaces and interoperability with other systems. The requirements establish how well and under
what conditions the system must perform.
The operational requirements should cover the requirements listed in table 6.3.1 and 6.3.2
Table 6.3.1 – System’s operational requirements
6.3.1.1 (O) The system shall be able to interface with external systems and communicate
with them (as specified in the interface requirement paragraph – Group 13).
6.3.1.2 (M) The system shall be installed at MOC on premise and communicate via a
secured line with MOC remote office (see paragraph 7.6 item 2)
6.3.1.3 (M) A full autonomous backup system for secured area backup system for disaster
avoidance DR) shall be installed at the MOC remote office premises.
6.3.1.4 (M) The MOC on-premise system shall be fully operational 24/7 with full
performance capabilities
6.3.1.5 (M) The system shall have a continues system’s functional performance
monitoring to verify critical state with an alert indicator when a function
deviates from its performance boundaries. In such a case an alarm notification
should be sent to the system administrator.
6.3.1.6 (M) System’s backwards and forward compatibility support: The system shall be
flexible to conditions as gradually fade out of old system components while
fade in of new system components etc.
6.3.1.7 (M) User interface: The system shall support bilingual (Hebrew and English)
operational system’s windows and textual capabilities
6.3.1.8 (M) Users access permission level shall be defined and managed by the system
administrator for different roles within the spectrum management system.
See paragraph 7.7 item 3
Table 6.3.2 - System’s built in test requirements
6.3.2.1 (M) The automatic spectrum management system (SMS) shall be capable of
checking and monitoring continuously the SMS performance and general
system’s health as part of the BIT-auto-diagnostics function.
6.3.2.2 (O) The SMS shall include procedures that checks whether all required services
and jobs are operating normally, checks system’s abnormal operational delays
and approve a good system health continuously and alert by notification the
system administrator the suspicious problematic module.
6.3.2.3 (O) The BIT should create log files for exceptional system behavior.
63 | P a g e
6.4 Group 11 – Cyber protection and Data Security
(M) This paragraph is mandatory
The requirements for protection mechanism from cyber-attacks and data leaks is attached with
tender documents in Hebrew.
6.5 Group 12 – Failure Contingencies and DRP for SMS
Table 6.5 - Failure Contingencies and DRP for SMS 6.5.1 (M)
Precautions shall be assessed during the system environment design so that disaster avoidance
and recovery shall be part of the entire system’s topology.
6.5.2 (M) Establish of the recovery path:
At least one database with disaster avoidance mechanism and response procedures shall be
available with hot standby server ready for immediate promotion into operation in the event
of failure.
6.5.3 (M) Conditions of requirements:
The standby autonomous SMS server shall be installed in the remote site for disaster
avoidance (DRP) as described above. (Refer to the system architecture in paragraph 3).
6.5.4 Components:
Shall be recommended and approved by HASHKAL
64 | P a g e
6.6 Group 13 – System’s interfaces
The SMS on-premises system shall be connected to external systems and other entities via the
interfaces listed in the table below:
Note: All figures in this group describe in general the flow of the interfaces components and
their interconnections
Table 6.6 – Summary table of system’s interfaces
Paragraph From To 6.6.1 MOC portal site On-premise non-secured area
6.6.2 MOC remote site On-premise non-secured area
6.6.3 MOC on-premise non-secured area MERKAVA (government accounting system)
6.6.4 MOC on-premise non-secured area External systems
6.6.5 MOC on-premise secured area OEM Monitoring and sensors
6.6.6 MOC on-premise secured area Secured government systems
6.6.7 MOC on-premise secured area Secured line between the on-premises location
and remote site
6.6.8 (1-2)
6.6.8 (3)
The operation procedure is performed
internally on-premise secured area
The government agency for mapping (GAM).
6.6.9 System’s user’s interface
65 | P a g e
6.6.1 MOC web portal to on-premise non-secured area
This interface shall enable sending/ receiving data as follows:
Table 6.6.1.1 – General interface requirements 6.6.1.1 (M) Receiving licensing request from MOC website
6.6.1.2 (M) Send confirmation upon receiving request
Table 6.6.1.2 – MOC web portal to on premise interfaces segments
(M) The MOC web portal shall be connected to on-premises non-secured area via the following
interface segments A through D as listed as follows:
Segment name Segment data flow Interface A Bidirectional Internet – MOC portal
B Bidirectional MOC portal – FW secured system
C Bidirectional FW secured system – MOC secured server
D Bidirectional MOC secured server – non-secured area
Note: Interface continuity: The connections end points A to D shall be kept activated continually.
Figure 10 – MOC portal to on-premise non-secured area
Note: This figure describes in very high-level the entire system components and general flow
Non-secured area
Licensing and accounting etc.
Secured area
On-premises area
Internet access
point for citizens
MOC Secured server
FW secured System
MOC PORTAL
B D C
Interface path segments: A, B, C and D
A
FW system
definition,
described in the
cyber protection
mechanism
66 | P a g e
6.6.2 Remote site to on-premise non-secured area
Table 6.6.2 – Remote site to on premise non-secured area interface
6.6.2.1 (M) A secured connection shall be provided between the non-secured area which is located
on-premise, to the MOC remote site.
6.6.2.2 (M) The connection shall be established with a secured line that connect between the non-
secured area which is equipped with protection system as shown in the figure. The
implementation shall be part of the requirements for protection mechanism from cyber-
attacks and data leaks. See paragraph 7.4 Group 11 in this document.
Figure 11 – MOC Remote site to on-premise non-secured area
Note: This figure describes in very high-level the entire system components and general flow
Secured area
On-premises area
Secured line between on-premise
non-secured secured area to
remote site
MOC remote office
FW system Non-secured area
67 | P a g e
6.6.3 MOC Non-secured area to MERKAVA
General information:
1. MERKAVA is the accounting system in government offices
2. MERKAVA is built on SAP platform
3. MERKAVA’s main responsibilities are:
a. Payments and debt collections according to data provided by the SMS
b. Management interest of delays in transfer of funds
c. Taxes credits and fines (Not in scope of the interface responsibility with the SMS)
Table 6.6.3.1 General Interface requirements
6.6.3.1 (M) The SMS on-premise shall support interface to MERKAVA platform (SAP) with a
suitable web service.
6.6.3.2 (M) The connection between MERKAVA and on-premise non-secured area shall be provided
via the secured server.
6.6.3.3 (M) The Interfaces requirement between MERKAVA and the SMS described in tables
6.6.3.2 -6.6.3.7
Table 6.6.3.2 - Interface1: Customer’s document information
6.6.3.2.1(M) From MOC SMS to
MERKAVA
The purpose shall be to open a new customer card or to
complete missing customer’s fields.
6.6.3.2.2(M) Required feedback
from MERKAVA
Feedback from MERKAVA to SMS shall be sent only in case
of incorrect report:
MERKAVA shall acknowledge the incoming information
by send a feedback notification to the accounting module
with status of:
1. All parameters were accepted and process in progress
2. Process ended successfully
3. Process rejected and reason for rejection
4. Missing information
6.6.3.2.3(M) Data flow Bidirectional
Table 6.6.3.3 - Interface 2: Management of fee collection
6.6.3.3.1 (M) From SMS
accounting
Accounting shall send to MERKAVA fees for collection per
customer’s services request.
MERKAVA shall collect fees via banks, payment server or via the
israeli post
6.6.3.3.2 (M) Performed by
MERKAVA
MERKAVA shall acknowledge that the fee collection shall be
performed including interest and indexation calculation and
collection
6.6.3.3.3 (M) Required
feedback from
When a debt is paid, MERKAVA shall send a notification to
update the SMS accounting to continue the customer’s request
68 | P a g e
MERKAVA approval process.
When the debt stays open, MERKAVA shall notify the SMS
accounting to set the debtor request on hold until the payment is
completed
6.6.3.3.4(M) Data flow Bidirectional
Table 6.6.3.4 - Interface 3: Management of debtors (Receivables)
6.6.3.4.1(M) From the SMS
licensing and
accounting
modules
The data and notifications arrived from the SMS Accounting and
licensing modules shall contain the customer’s data fee collection
by using a required web service.
MERKAVA shall manage debtor’s fee collections, reminders to
debtors, collect customers debt and credit and work with the center
of collection and fines when required etc.
6.6.3.4.2(M) Required
feedback from
MERKAVA
MERKAVA shall send a list of debtors to SMS, notifying the
SMS to postpone the licenses requests until payment will be
approved by MERKAVA. Information shall be stored in SMS
database
6.6.3.4.3(M) Data flow Bidirectional
Table 6.6.3.5 - Interface 4: Management of debt and credit
6.6.3.5.1(M) Performed by
MERKAVA
MERKAVA manage customer’s debt and credit, send reminders
and notifications to follow debtors according to the information
reporting by the SMS. (see 7.6.3.9 above)
6.6.3.5.2(M) Required
feedback from
MERKAVA to
SMS
accounting.
When a debt is paid, MERKAVA shall send a notification to
update the SMS accounting.
6.6.3.5.3(M) Data flow Bidirectional
Table 6.6.3.6 - Interface 5: Additional data interface
6.6.3.6.1(M) From SMS accounting: To MERKAVA
6.6.3.6.2(M) This interface designated for sending any
additional relevant information to
MERKAVA
(Data content shall be defined by MOC)
This interface does not require any
feedback from MERKAVA to SMS
6.6.3.6.3(M) Data flow Unidirectional
69 | P a g e
Table 6.6.3.7 - MERKAVA to SMS non- secured area. (Data history report)
6.6.3.7.1(M) Data history reports:
Shall be part of
interface 1
Data history report shall be kept in MERKAVA and in the
SMS databases.
MERKAVA shall send a monthly* history report to SMS.
* Monthly report or otherwise as required by MOC
Figure 12– Interfaces between on-premise non-secured and MERKAVA
This workflow diagrams (figures 12) describe in general the interfaces between on-premise non-
secured area and MERKAVA.
(O) The figure is an optional illustration
Accounting module Non-secured area
Non-secured area
Licensing module
MOC portal
Service
request
from
MOC
portal
Secured server
secured area
Processes in
licensing module
(see figure 10)
Processes and approval
of frequency assignment Pas
s ? Y
N
Fix/refine issue
MASTER
Database
Strat accounting
procedures
Send
daily
updates
to master
Database
Non-secured
Database
Interfacing channel with
MERKAVA including
feedbacks from MERKAVA to the SMS operational
system
External systems
FW secured system
MERKAVA (SAP HANA)
Connect to
non-secure
modules
Interfaces: On-premise - MERKAVA
1
2
3
4
5
1
2
3
4
5
70 | P a g e
6.6.4 MOC non-secured interface with external systems
The following external systems that described in the table shall have secured connection to the
MOC on-premise non-secured area and to *MERKAVA. (see figure 12, external systems 1,4,5,6).
The system shall support SOAP and REST protocols of web services, XML format and file format.
The system shall enable exporting all types of non-secured information such as licensing,
accounting information and reports.
M 6.6.4.1 Link to E-Government (Mimshal Zamin), MASLUL
M 6.6.4.2 Link to E-Government (Mimshal Zamin) external systems
M 6.6.4.2 Link to Printing companies
O 6.6.4.3 Link to Registrars of companies M 6.6.4.4 Link to civil registry
M 6.6.3 Link to MERKAVA
(M) Mandatory requirement
*External systems 1-7 as shown in the figure already connected to MERKAVA
Figure 13– MOC non-secured area interface with external systems
(O) This figure describes in very high-level the entire system components and general flow
Secured area
On-premises area
Note:
All external
systems 1-7 are
already connected
to MERKAVA
Secured access server
Non-secured area - Accounting
1) E-Government: Israeli post, Ministry of transportation,
& MASLUL
2) Banks
3) Payments server
4) Printing companies
5) Registrars of companies
6) Civil registry
7) Center for collection & fines
8) MOC’s new report management system
MERKAVA
External systems
MOC non-secured area shall be connected
only to external systems 1, 4,5 and 6
71 | P a g e
6.6.4.1 Interface to MASLUL
Figure 14 - Describes the interface with MASLUL via E-government to MOC on premise. This
path shall enable citizens and authorities to communicate indirectly with MASLUL via E-
government interface for feeding and getting on-line statuses and responses for their statuses and
requests such as; trading licensing forms, type of approvals, certification match, exempting of certification
match etc. It should be noted that MASLUL is a transparent entity neither to the citizens/authorities nor to
MOC on-premise systems.
Figure 14 – MOC non-secured area interface with MASLUL via E-Government
(O) This figure describes in very high-level the entire system components and general flow
Non-secured area
Secured Server 1
Secured area
On-premises area
MASLUL
MOC
secured server
MOC WEB Portal E- Government
Licensing
Accounting
(*) Forms types:
See table below – paragraph 7.6.4.1.1 )
(*) On-line forms feed from citizens via E-Government
72 | P a g e
Table 6.6.4.1 - Interface MOC – MASLUL requirements
Requirements: Accessibility
6.6.4.1.1 (M)
The E-Government services
from citizens and other
authorities to MASLUL shall be
provided to MOC on-premise
area non-secured area.
Note:
MOC non-secured area shall
communicate with MASLUL
indirectly via E-Government
(Mimshal Zamin) interface.
There will be no direct access
from MASLUL to the MOC
premises.
The interface shall be responsible of handling the
following approvals:
a. Accept requests of trading licensing forms that
arrived from citizens/authorities.
b. Periodic conformation
c. One-time certificate
d. Certificate matches
e. Exempting of trading license
f. Exempting of certification match
g. Issue of citizen’s quires in various data segments
and distribution reports.
h. Sending statuses to the citizens
6.6.4.1.2 (M) Dataflow Bi-directional data flow is required
6.6.4.2 MOC on-premise to E-Government systems
The E-Government (Mimshal Zamin) objectives are to make government services accessible to
citizens, businesses and the public, and to connect government organizations to internet services.
MOC on-premise shall have three bidirectional connections with E-Government systems (Mimshal
zamin):
1. The Israeli post
2. The ministry of transportation
3. MASLUL (see previous paragraph)
73 | P a g e
Table 6.6.4.2 - MOC on-premise to E-Government – interface requirements
Requirements: Accessibility
6.6.4.2.1 (M)
The E-Government services
from citizens and other
authorities shall be provided to
MOC on-premise area non-
secured area.
This interface shall have three paths:
2) From the Israeli post via a secured server to the
MOC on-premise non-secured area:
The interface is required only for licenses delivery,
letters, non-classified certifications and notifications
to customers.
(Payments and debts shall be performed by
MERKAVA)
3) From the ministry of transportations via a secured
server to the MOC on-premise non-secured area
6.6.4.2.2 (M) Dataflow Bi-directional data flow is required
6.6.4.3 Interface to printing companies
Table 6.6.4.3 - Interface to printing companies
Requirements: Accessibility
6.6.4.3.1 (M)
This interface shall allow the
MOC licensing department to
send to printing companies
licenses for printing or other
letters and notifications to
customers.
The interface to printing
companies shall provide a
connection between the MOC
on-premises and printing
company or list of printing
companies that open to MOC
choice.
A connection shall be established between the MOC
non-secured and printing companies.
The connection path shall be defined through the
secured server which is connected to the MOC secured
server.
6.6.4.3.2 (M) Dataflow Bi-directional data flow is required
74 | P a g e
6.6.4.4 Registrar of companies
Table 6.6.4.4 - Registrar of companies
Requirements: Accessibility
6.6.4.4.1 (M) The MOC on-premise shall have
a secured access to the registrars
of companies.
The required interfaces are:
The interface from the registrars of companies to
MOC’s on-premise non-secured shall be provided via
the MOC secured server.
See figure 13
6.6.4.4.2 (M) Dataflow Bi-directional data flow is required
6.6.4.5 Civil registry
Table 6.6.4.5 – Civil registry
Requirements: Accessibility
6.6.4.5.1 (M) The MOC on-premise shall
have a secured access to the
civil registry system.
The required interface is:
The interface from the civil registry to the MOC on-
premise non-secured shall be provided via the MOC
secured server.
See figure 13
6.6.4.5.2 (M) Dataflow Bi-directional data flow is required
75 | P a g e
6.6.4.6 MOC new report management system
Table.6.4.6 Future interface compatibility with requirements
6.6.4.6.1 (O) MOC new report management system:
The system is CRM-based.
1. The system shall allow all customers and authorities supervised by the MOC
and licenses holders to send periodic reports to which they are committed.
2. The system will upload the reports and saved them to the database for
tracking and control.
3. Some of these reports shall be a prerequisite for licenses to be administered
by the non-classified on-premise SMS.
For example: In case the license owners did not submit a periodic report then
their license will not be renewed etc.
76 | P a g e
6.6.5 Monitoring OEM and sensors
1. The Israel MOC may intend to acquire fixed and mobile OEM monitoring equipment in the
future.
2. The SMS vendor shall indicate whether one or more of the following OEM monitoring
equipment’s as shown in table 6.6.5.3 can be interfaced with the COTS SMS
3. All requirements that are shown in this paragraph are OPTIONAL
6.6.5.1 Mission of tools and sensors
The main purpose of the MOC requirements from the monitoring tools shall be for:
Table 6.6.5.1 -Mission of monitoring OEM and sensors
6.6.5.1.1 (O) Local observations and measurements, specifically for tasks such as violations and
enforcement.
6.6.5.1.2 (O) Measurements on highly populated areas to obtain spectrum usage and occupancy
statistics
6.6.5.1.3 (O) Extended observations over a wide area for general spectrum occupancy statistics to
support spectrum management team’s decisions
6.6.5.1.4 (O) RF monitoring, using geolocation sensors
6.6.5.1.5 (O) Validation of actual spectrum occupancy versus authorized occupancy
6.6.5.1.6 (O) Deviation from authorized transmission parameters
6.6.5.1.7 (O) Location and transmission parameters of legal and illegal transmitters
6.6.5.1.8 (O) Interference from or among transmitters
6.6.5.1.9 (O) Recommendations on eliminating interference etc.
77 | P a g e
6.6.5.2 Monitoring tools requirements
The OEM DF monitoring tools shall include the features, measurement capabilities and product
software and hardware description that can interfaced with the SMS as follows:
Table 6.6.5.2 - Monitoring tools/sensors requirements
6.6.5.2.1 (O) Direction Finding tools properties shall be described by:
1. Antenna types
2. Hardware components
3. Software packages
4. Available API’s to the COTS SMS
6.6.5.2.2 (O) Supported methods and technologies:
1. TDOA
2. AOA
3. Both
6.6.5.2.3 (O) Monitoring capabilities:
1. Geolocation direction
2. Providing azimuth and potentially elevation for accurate localization and
tracking of RF emitters.
6.6.5.2.4 (O) Expected measurement accuracy
6.6.5.2.5 (O) Additional testing capabilities
6.6.5.2.6 (O) Measurement of transmitted power from emitter source
6.6.5.2.7 (O) RF geo-location sensors: For monitoring tools to interface with mobile and fix
monitoring, vehicles, type of antennas, supporting monitoring of station or map
specific location, transmitter power, DF etc.
78 | P a g e
6.6.5.3 SMS interfaces with OEM Monitoring Tools
The SMS vendor shall indicate whether one or more of the following OEM monitoring equipment’s
can be interfaced with the COTS SMS.
All monitoring software applications shall support windows 10.
Table 6.6.5.3 – Interface compatibility of SMS with OEM tools and systems
requirements
6.6.5.3.1 (O) Rohde & Schwarz products:
1. Argus 6: Spectrum monitoring software
2. Recommended hardware for DF sensors
3. Mobile and fixes monitoring capabilities
6.6.5.3.2 (O) Agilent Products:
1. N6841 - A real-time RF emitter geolocation system using RF Sensors.
2. N6854A – A software that estimates position of RF signal using measurements
from the sensor network and calculations using enhanced TDOA and received-
signal-strength (RSS) techniques.
3. Mobile and fixes monitoring capabilities
6.6.5.3.3 (O) CRFS RFeye Products:
1. DF and sensors equipment using geolocation techniques including TDOA and
AOA etc.
2. Supported software
3. Mobile and fixes monitoring capabilities
6.6.5.3.4 (O) Thales: DF sensors
1. Wideband DF family produces (TRC 6200/TRC 6460/or TRC 6500)
2. DF antennas for fixed and tactical applications
3. Mobile and fixes monitoring capabilities
6.6.5.3.5 (O) TCI products:
1. TCI Scorpio: Spectrum monitoring software
2. Wideband DF family (TCI 739/TCI 737/TCI 733/TCI 709)
3. Fixed and mobile antennas
4. Support of AOA/TDOA geolocation etc.
6.6.5.3.6 (O) New data collection system:
The system shall be capable to interface with future OEM system that exploring
locations of stations, collecting external data from different emitters that
geographically located near or far from each other.
The SMS shall be able accept the data and send alerts to the operator in case of rule
exceptions: For example.
1. Stations License exception - expire date etc.
2. End of temporary frequency band assignment agreement.
3. Identification of interference from emitters geographically etc.
79 | P a g e
6.6.6 Secured government systems
The requirement: (O)
A secured connection shall be provided between the SECURED area which is located on-premise to
external secured government systems. The system shall support SOAP and REST protocols of web
services, XML format and file format. The system shall enable exporting all types of secured
information such as frequency plan, frequency interferences, engineering tests results, GIS
information and reports.
Implementation:
The connection shall be established with a secured line that connect between the secured area which
is equipped with protection system as shown in the figure. The implementation shall be a separate
(an additional) part to the requirements for protection mechanism from cyber-attacks and data leaks.
See paragraph 7.4 Group 11 in this document.
Figure 15 – MOC on-premise secured area to government systems
(O) This figure describes in very high-level the entire system components and general flow
* See also system’s architecture – figure 1
Non-secured area
On-premises area
connection between
on-premise secured
area to government
systems
Government systems, monitoring equipment
(Fixed/Mobile), sensors etc.
Protection system Secured area
Secured line
80 | P a g e
6.6.7 Secured line of On-premises site to Remote site
The requirement: (O)
A secured connection shall be provided between the SECURED area which is located on-premise to
the MOC remote site. All secured modules and data shall be hot-lined backup to remote site to
enable its automatic operation if the main system site collapses.
Implementation
For the implementation. a new secured line shall be established, using additional infrastructure to
support hot line between the MOC on-premise and the remote site. see figure 14. It shall be a
separate (additional) part of the requirements for protection mechanism from cyber-attacks and data
leaks that described at paragraph 7.4 Group 11 in this document.
Figure 16 – MOC on-premise secured area to remote site
(O) This figure describes in very high-level the entire system components and general flow
* See also system’s architecture – figure 1
Non-secured area
On-premises area
Secured line between
on-premise secured area to
remote site
MOC remote office
FW system Secured area
81 | P a g e
6.6.8 The Government Agency for Mapping (GAM)
The interface between the MOC on-premise to GAM shall be provided by the following ways:
1. Manual update
2. Online update via an on-line interface to MOC GIS server
Table 6.6.8 - MOC on-premise to GAM – Interface requirements
6.6.8.1 (M) Manual interface:
1. Shall be updated once a year in coordination between MOC and GAM team.
2. Keeping history is not required. (updates of maps from GAM to MOC shall be
scheduled on a yearly basis)
Hardware requirements:
Refer to paragraph 4.1.1 a. (ii) in the table - Infrastructure requirements GIS hardware4
6.6.8.2 (M) User’s interface:
The user shall have access to the GIS data from two main sources:
1. The COTS SMS GIS module
Note: Refer to user’s GIS operational requirements – paragraph 6.3.3.1.10 Table GIS1
items1 and 2
2. The additional GIS server shall contain new maps and updates from GAM.
Notes: Refer to user’s GIS operational requirements – paragraph 6.3.3.1.10 Table GIS1
items1 and 2
3. All equipment be defined and approved by HASHKAL.
6.6.8.3 (O) Online interface:
Online connection between the MOC on-premise and GAM is optional
82 | P a g e
6.6.9 User’s interface
Table 6.6.9 - User’s interface requirements
6.6.9.1 (M) The system shall allow the users to work on several windows simultaneously and each
window shall be independently controlled. e.g. for working with maps and reports etc.
6.6.9.2 (M) The system shall have the capability to allow the individual to define and save its
preferences and setup parameters
6.6.9.3 (M) System’s user’s interface shall be bilingual and selectable between English to Hebrew and
vice versa
6.6.9.4 (O) The system will support advanced display technologies with an emphasis on friendly user
experience and atomization.
83 | P a g e
6.7 Group 14 – System Workflow Mechanism
(SWM) System workflow mechanism
Table 6.7 - SMS workflow mechanism requirements
6.7.1 (M) General workflow mechanism requirement:
The mechanism shall be fully automated. (partial or end-to-end)
The mechanism shall provide the user an option to stop any workflow at any stage
and continue the process manually from the last point it stopped.
The mechanism shall support capabilities of defining system workflow that
combines the required order of system's procedures and manual required activity
for each process. The system's procedures shall support internal module activity or
external interface activity.
6.7.2 (M) Multiple signatories mechanism:
The system shall have a built-in multiple signatories mechanism (for example first
signatory is an engineer, second signatory is the spectrum manager etc.)
The process shall be editable by the system administrator when required.
6.7.3 (M) Mechanism flexibility:
The system’s workflow mechanism shall have the ability to add change or upgrade
workflows (currently used, create new workflow, change an existing w.f. etc.)
6.7.4 (M) Tasks scheduling:
The system shall be capable to define any desired schedule for multiple signatories
related to single process or sequential processes
6.7.5 (M) Users access permission administration:
1. User access level shall be defined and managed by the system administrator for
different roles within the spectrum management system.
2. The system shall be capable to set roles per user or group of users.
3. The user role management shall allow different users to access the system with
different roles assigned.
4. For each possible role, the system shall allow only certain tasks to be carried out by
the user with that role.
84 | P a g e
6.7.6 (M) End-two-End Automatic workflow - Management of incoming request
The system shall have a built-in automatic and semi-automatic workflow
mechanism to guide the user through all the required steps. The underlaying
workflow shall be responsible to take care of all related internal processes from the
customer’s request acceptance till the license is approved:
The following end-to-end workflow requirement summary describe a general
customer’s request that the workflow mechanism shall be cope with:
1. Incoming customer’s request to license module
2. Check nature of request and its validity For example:
a. Validity approved – Request proceed to the spectrum management for
registration
b. Validity failed – Notifying the customer the request on hold until it will be
fixed.
Note: If the customer’s request doesn’t necessarily require an operation of
the frequency and engineering modules 2 (a), the workflow shall allow to
bypass the step and move directly to the licensing and fee calculation step.
(such case for example, shall be defined in the workflow mechanism)
3. Validity check approved 2 (a) – Proceed to engineering analytics per
customer’s requested service to approve that the service request is free of
interference.
4. Notify the frequency module that the request was checked and approved.
5. Proceed to the licensing module to calculate fee according to customer’s
service request.
6. Proceed to the accounting module to prepare all necessary documents,
customers template etc. and accounting data before starting the interface
procedure with MERKAVA.
7. When MERKAVA approved payment, it sends notification to the accounting
8. Accounting transfer payments approval (all types) and transfer it to the
accounting and update in the database.
9. Licensing shall send license to the customer in PDF via email or hard copy via
the israeli post.
Note: Detailed workflow processes are shown in the following paragraphs:
Paragraph 5.1.2 Frequency plan workflow
Paragraph 5.2.2 Engineering analysis workflow
Paragraph 5.3.2 GIS module workflow
Paragraph 5.4.2 Licensing module workflow
Paragraph 5.5.2 Accounting module workflow
85 | P a g e
6.7.7
(M)
(O)
Reports generation:
A workflow shall allow to define certain report generations that will be performed
automatically as part of a certain process (for example by the end of SMS frequency
assignment procedure, define of scheduled reports etc. (This requirement shall be defined
by the MOC).
The system shall have a ‘crystal reports’ tool for generating BI reports from the data
stored in the database
Refer to paragraph 5.6.1
6.7.8
(M)
(M)
(O)
The workflow mechanism shall support notifications capabilities:
Automatic email notifications
System reminders (for scheduled procedures, reminders to customers and external
systems etc.)
System routine checkup
6.7.9 (O) Management workflow process with MERKAVA
6.7.10 (O) Visualization of workflow shall show bottlenecks in the system’s operational processes
6.8 Group 15 – System Customization
The SMS customization shall offer changes in functionalities, workflows, administration and
operational levels as required:
Table 6.8 - System’s customization requirements
6.8.1 (M) License forms and system letter templates
6.8.2 (M) Existing spectrum Plan
6.8.3 (M) Licensing process and procedure workflow
6.8.4 (M) Tariffs and fees calculation.
6.8.5 (M) System flexibility whenever customization and changes are required.
6.8.6 (M) Development of additional capabilities according to the MOC requirements.
6.8.7 (M) System flexibility to modifications and upgrades due to change of industry needs,
regulatory requirements, and technology developments.
6.8.8 (M) System shall be flexible to customization and development changes e.g. create or
change of reports, add new feature, create new workflow, change an existing
workflow etc.
6.8.9 (M) The dependency level of the MOC in vendor shall allow functional customization
when required.
6.8.10 (M) Design capabilities of web services and API’s shall be allowed.
86 | P a g e
6.9 Group 16 – System Performance
The following system’s performance requirements are defined for the on-premises environment
boundary.
* The performance requirements shall be at least as specified in the table or better
Table 6.9 - System’s performance requirements
6.9.1 (M)
Communication latency:
The System’s end to end latency shall not exceed 2 minutes.
Note: System’s end-to-end latency performance refers to the on-premise
workplace only. Including between secured and non-secured areas!
6.9.2 (M) Map and GUI Display
Refresh rate time shall not exceed 20 seconds
6.9.3 (M) Frequency table update time
From user command of frequency table update, until status of operation
acknowledged should not exceed 1 minute
6.9.4 (M) From user command of:
1. Frequency engineering test, until status of operation acknowledge should not
exceed 1 minute
2. Frequency table update, until licensing operation is accomplished should not
exceed 1 minute.
6.9.5 (M) From user request:
1. Until generating any kind of daily data report should not exceed 1 minute.
2. Until generating any kind of monthly or yearly data report should not exceed 5
minutes.
3. For uploading new map or new map layers until operation acknowledge should
not exceed 5 minutes.
6.9.6 (M) System load
No degraded performance from the requirements mentioned above shall be
experienced by users when all users are working simultaneously.
87 | P a g e
6.10 Group 17 – System’s scalability requirements
The system shall be ready to the following scalability dimensions as required:
Table 6.10 - System’s scalability requirements
6.10.1 (M) Administrative scalability:
The SMS shall provide a flexible option to expand the workplace for more users.
6.10.2 (M) Performance scalability:
The SMS shall be flexible to changes, upgrades and improvements in case the
system will becomes reduced in performance.
6.10.3 (M) Capabilities for system’s scalability:
The SMS shall be ready to scale up by using new generation of system’s
components, new modules, connection and adaptation to OEM components as
required.
6.11 Data migration
Table 6.11 - System’s Data migration
A data migration tool shall be offered by the vendor
Data migration process shall be required for migration of an existing data content to the new SMS
database.
6.11.1 (O) The vendor shall develop or propose a database migration tool for the procedure as
described
End
