12 - Ifb Co 14682 CSD Book II Part IV Sow Annex B Srs CSD Isr Streaming Services (Ciss)

NATO CSD
Book II - Part V
SYSTEM REQUIREMENTS SPECIFICATION (SRS)

CSD ISR Streaming Services (CISS)
Version 1.0
04/07/2018
Version 1.0 NATO UNCLASSIFIED CO-14682-CSD
TABLE OF CONTENTS
1 Introduction ......................................................................................................... 1
1.1 Scope ....................................................................................................................... 1
1.2 Conventions.............................................................................................................. 1
1.3 Structure ................................................................................................................... 2
1.4 Applicable documents............................................................................................... 2
1.5 Reference documents............................................................................................... 3
1.6 Background – Envisioned Capability ......................................................................... 3
2 Functional Requirements ................................................................................... 5
2.1 CISS General Requirements .................................................................................... 6
2.1.1 CSD/4559 Bridge Interface not required ........................................................ 8
2.1.2 CSD Stream Notification Interface not required ............................................. 8
2.1.3 Data Model Requirements ............................................................................. 8
2.1.4 Query and Retrieval Requirements .............................................................. 14
2.2 Managing Stream Content ...................................................................................... 17
2.2.1 Recording Live Stream Data Requirements ................................................. 17
2.2.2 Import of recorded streams from file ............................................................ 20
2.2.3 Replication Requirements ............................................................................ 20
2.2.4 Data Exchange over SATCOM Requirements ............................................. 27
2.2.5 Cross-Domain Requirements....................................................................... 28
2.2.6 Joining / Catch-up Requirements ................................................................. 29
2.2.7 Archiving and/ or Stream Data Removal Requirements ............................... 30
2.3 Replaying and Relaying Requirements ................................................................... 30
2.4 Video Conditioning for Web Browser Client Applications ........................................ 32
2.5 User Interface Requirements .................................................................................. 33
2.5.1 Server Configuration and Maintenance ........................................................ 34
2.5.2 Operational Monitoring ................................................................................ 36
2.5.3 Operational Management ............................................................................ 37
2.6 Application Performance Monitoring (APM) Requirements ..................................... 39
3 Non-functional Requirements .......................................................................... 41
3.1 Performance Requirements .................................................................................... 42
3.1.1 Performance Efficiency (quality) Requirements ........................................... 43
3.2 Compatibility ........................................................................................................... 44
3.2.1 Co-existence................................................................................................ 44
3.2.2 Interoperability ............................................................................................. 45
3.3 Usability .................................................................................................................. 46
3.3.1 Learnability Requirements ........................................................................... 46
3.3.2 Operability Requirements ............................................................................ 54
3.4 Reliability ................................................................................................................ 57
3.4.1 Availability ................................................................................................... 57
3.4.2 Fault tolerance ............................................................................................. 58
3.4.3 Recoverability .............................................................................................. 58
3.5 Security .................................................................................................................. 59
3.5.1 Confidentiality .............................................................................................. 60
3.5.2 Integrity........................................................................................................ 60
CISS NATO UNCLASSIFIED Book II, Part IV, SRS

CO-14682-CSD NATO UNCLASSIFIED Version 1.0
ii
3.5.3 Non-repudiation and Accountability ............................................................. 64

3.5.4 Authenticity and Authorisation ..................................................................... 65
3.6 Maintainability ......................................................................................................... 67
3.6.1 Modularity Requirements ............................................................................. 68
3.6.2 Analysability ................................................................................................ 69
3.6.3 Modifiability .................................................................................................. 70
3.7 Portability ................................................................................................................ 72
3.7.1 Adaptability Requirements ........................................................................... 72
3.7.2 Installability Requirements ........................................................................... 74
3.7.3 Replaceability Requirements ....................................................................... 75
INDEX OF FIGURES
Figure 1 Envisioned technical solution for the CISS 4

Figure 2 CISS interfaced to national CSD Stream Servers and with other CISS instances
over SATCOM 5
Figure 3 False negative due to low update rate of coverage areas 16
Figure 4 Example on how false negative query results can be avoided in situation of low
update rate of coverage areas by querying against a convex hull between pairs of
coverage areas 17
Figure 5 Cross-domain exchange through the NATO Release Server and the IEG-C 28
Figure 6 Local and remote stream relay or replay 31
Figure 7 Example metaphors for icons/functions 53
INDEX OF TABLES
Table 1 Applicable documents 2

Table 2 Reference documents 3
Table 3 Applicable XSDs and WSDLs for the CISS 7
Table 4 CSD Stream Metadata Model (subset of the full STANAG 4559 Edition 4 Metadata
Model) from the perspective of a stream server 9
Table 5 Additional capability reported by the CISS through the stream query service
interface 15
Table 6 Mandatory attributes in a replication message 22
Table 7 Mandatory attributes in the last replication message that signals that the stream is
now closed 23
Table 8 Attributes to be collected by querying the source stream server (once) 25
Table 9 Mandatory attributes in the a replication message that signals that the stream has
been removed from the source server 26
Table 10 Recovery Time by Failure Criticality 58
Table 11 Character to HTML encoding 62
Table 12 Maintainability by Failure Criticality 68
Book II, Part IV, SRS NATO UNCLASSIFIED CISS

1 Introduction
[1] This System Requirements Specification (SRS) documents the requirements for the
NATO Coalition Shared Data (CSD) Intelligence, Surveillance and Reconnaissance
(ISR) Streaming Services capability of the NATO CSD, hereafter referred to as the
CISS.
1.1 Scope
[2] This SRS specifies the functional and non-functional requirements for the CISS.
[3] The Functional Requirements of the CISS specify the functions that shall be
implemented by this capability in order to deliver the ISR streaming services described
by the Allied Engineering Documentation Publication (AEDP) 18 of the NATO
Standardization Agreement 4559 (STANAG 4559) Edition 4 [4559-Ed4/AEDP-18].
[4] The Non-Functional Requirements of the CISS specify the standards, quality,
performance, sizing and design constraints that shall be satisfied in the solution design
and implementation.
1.2 Conventions
[5] Within this SRS, the requirements are numbered as [CISS-number], while narrative
text is numbered as [number].
[CISS-1] Numbered lists under a given [CISS-number] requirement shall be understood
as individual requirements. For compliance traceability purposes, these
requirements shall be referenced as [CISS-number].list-number.
Verification Method: Inspection
[CISS-2] Requirements stating a capability to be "supported" shall be understood as

feature or capability that shall be inherently available within the design and the
assets in its full extent, without restrictions; that feature or capability can be
enabled and disabled at any time by the Purchaser.
[CISS-3] Requirements stating a capability to be "implemented" shall be understood as a

feature or capability that shall be available within the design and the assets in its
full extent, without restrictions; that feature or capability shall be delivered
activated and configured for use in the delivered system.
[CISS-4] This SRS, in addition to explicitly specifying requirements, defines a number of

requirements through referencing and adopting requirements from STANAG
4559) Edition 4. In the case that the requirements defined in this SRS partly or
fully contradict requirements in referenced documentation, then the requirements

explicitly defined in this document shall take precedence over the requirements
in the referenced document.
[6] The term "including" is throughout this SRS never meant to be limiting - the list that
follows is always non-exhaustive.
1.3 Structure
[7] Software requirements, applicable to the NATO CSD Streaming Services, are covered
in this SRS.
[8] This SRS is structured as follows:
 Section 1: Introduction;
 Section 2: Functional Requirements for the CISS
 Section 3: Non-functional Requirements for the CISS
1.4 Applicable documents

[9] Applicable documents provide details not explicitly set out through this SRS (other
requirements, architecture, and specifications). They shall be considered by the
Contractor as requirements associated with this SRS.
Table 1 Applicable documents

[AEDP-7 Ed2, AEDP-7, Edition 2, “NATO Ground Moving Target Indicator Format (GMTIF)
2013] STANAG 4607 Implementation Guide”, NATO Standardization Agency, Brussels,
Belgium, May 2013.
[AEDP-8 Ed3, AEDP-8, Edition 3, “NATO Motion Imagery (MI) STANAG 4609 (Edition 3)
2009] Implementation Guide”, NATO Standardization Agency, Brussels, Belgium,
December 2009 (NATO Unclassified).
[4559- NATO STANDARD AEDP-17, NATO STANDARD ISR LIBRARY INTERFACE,
Ed4/AEDP-17] Edition A Version 1, MARCH 2018, NATO STANDARDIZATION OFFICE (NSO)
[4559- NATO STANDARD AEDP-18, NATO STANDARD ISR STREAMING SERVICES,
Ed4/AEDP-18] Edition A Version 1, MARCH 2018, NATO STANDARDIZATION OFFICE (NSO)
[4559- NATO STANDARD AEDP-18, NATO STANDARD ISR WORKFLOW
Ed4/AEDP-19] ARCHITECTURE, Edition A Version 1, MARCH 2018, NATO STANDARDIZATION
OFFICE (NSO)
[CO-12940- Release Server Integration document, v1.0, 1 April, 2012, NATO Unclassified
OPL-RSID]
[IFAS12] Schema for exchanging messages with the NATO Release Server. Target
Namespace=http://www.nato.int/namespace/ifas_message/1.2/20110202
[STANAG 4607 STANAG 4607 Edition 3, “NATO Ground Moving Target Indicator Format (GMTIF)”,
Ed3, 2010] NATO Standardization Agency, Brussels, Belgium, 14 September 2010 (NATO
Unclassified).
[STANAG 4609 STANAG 4609 Edition 3 “NATO Digital Motion Imagery Standard”, NATO
Ed3, 2009] Standardization Agency, Brussels, Belgium, 13 October 2009, (NATO Unclassified).
[W3C WS- World Wide Web Consortium (W3C), "Web Services Transfer (WS-transfer)", 27
transfer, 2006] September 2006.

1.5 Reference documents

[10] Reference documents are documents providing contextual information that is relevant
to this project. They shall be used by the Contractor to support his activity.
Table 2 Reference documents

[AC/35-D/2004- Primary Directive on CIS Security, North Atlantic Council, 15 November 2013
REV3] (NATO Unclassified)
[ISO/IEC ISO/IEC 23270:2006, Information technology -- Programming languages -- C#,
23270:2006] https://www.iso.org/standard/42926.html
[CSD-XDomain] Minutes of Meeting on “CSD Cross Domain using the NATO Release Server”, 9
April 2015
[NDepend] NDepend, https://www.ndepend.com/
[SonarQube] SonarQube, https://www.sonarqube.org/
[SQALE] Software Quality Assessment based on Lifecycle Expectations,
http://www.sqale.org/
[XML XML Documentation Comments, https://docs.microsoft.com/en-
Comments] us/dotnet/csharp/programming-guide/xmldoc/xml-documentation-comments
1.6 Background – Envisioned Capability

[11] With the CISS NATO will acquire a capability for managing streaming data of type
video streams and GMTI streams. This specifically means a capability that:
(1) Record streaming data (video and GMTI) from the network
(2) Catalogue the recorded streams with metadata extracted from the
streaming data
(3) Enable searching into the repository of recorded streams; including fine-
grained spatial searches into the repository of streams
(4) Re-stream recorded streaming data to client applications upon requests
(5) Disseminate and synchronize the stream catalogues across a network of

CISS instances
(6) Is interoperable with STANAG 4559 ed4 / Bravo .1 compliant national

capabilities, and that can exchange stream cataloguing metadata with
national instances of CSD streaming services
(7) Act as a relay when, upon client application request, it is re-streaming data
originating (recorded) in another CSD streaming service (including national
CSD streaming services)
(8) Conditions the streaming data for visualization in Web browsers and support
streaming to Web browser applications (e.g. the NATO INTEL-FS). Note

that this last function is not defined in [4559-Ed4/AEDP-18], and the

requirement for this functionality is included as an option in this SRS.
[12] The technical solution of CISS, as depicted in Figure 1, is envisioned to consists of
six parts:
(1) A core streaming data system.
(2) A resiliency/ redundancy (and even load balancing) mechanism enabling

continued streaming services in the case of network partitioning and/or
system failover in case of hardware failure. This mechanism should be
using IT services provided by the NATO IT Modernization (ITM) capability
for the scope of ITM (NATO Static Command Structure).
(3) A capability for exchanging product metadata and stream file data over a
SATCOM link.
(4) A set of service interfaces as defined by STANAG 4559 edition 4, see [4559-
Ed4/AEDP-18] and also [4559-Ed4/AEDP-17]. Note: Source code for these
STANAG 4559 adaptors as implemented in the NATO CSD Bridging
Solution can be provided to the Contractor as Purchaser Furnished Items
(PFI).
(5) User Interfaces for a CISS Administrator role and for an Operational Support
role.
(6) A separate service for streaming STANAG 4609 videos with metadata to
Web browser client applications. This video conditioning service will
implement Dynamic Adaptive Streaming over HTTP (DASH), i.e. MPEG-
DASH (ISO/IEC 23009-1:2012).
Figure 1 Envisioned technical solution for the CISS

[13] The CISS will, as shown in Figure 2, be interfaced with national CSD Streaming
Servers and will participate in replication of stream Metadata over the Stream
Replication Interface as defined by [4559-Ed4/AEDP-18]. The CISS will also
exchange product metadata and stream file data over SATCOM links with deployed
CISS instances.
Figure 2 CISS interfaced to national CSD Stream Servers and with other CISS instances over
SATCOM
2 Functional Requirements
[14] This paragraph describes the functional requirements of the CISS. The functional
requirements are grouped in:
(1) CISS General Requirements (§ 2.1)

 Data Model Requirements (§ 2.1.3)
 Query and Retrieval Requirements (§ 2.1.4)
(2) Managing Stream Content:

(i) Recording Live Stream Data Requirements (§ 2.2.1)
(ii) Replication Requirements (§ 2.2.3)
(iii) Data Exchange over SATCOM Requirements (§ 2.2.4)
(iv) Cross-Domain Requirements (§ 2.2.5)

(v) Joining / Catch-up Requirements (§ 2.2.6)

(vi) Archiving and/ or Stream Data Removal Requirements (§ 2.2.7)
(3) Replaying and Relaying Requirements (§ 2.3)
(4) Video Conditioning for Web Browser (§ 2.4)
(5) User Interface Requirements (§ 2.5)
(6) Application Performance Monitoring (APM) Requirements (§ 2.6)

[15] The principal functions of the CISS is to provide a query-able repository for ISR stream
data (GMTI and video streams) where the streams can be replayed to client
applications, and to serve as an exchange mechanism for ISR stream data with
compatible national CSD stream servers.
2.1 CISS General Requirements

[16] The CISS will be an implementation of a CSD Stream Server capability. The purpose
of a CSD Stream Server and a high level description on how it will work is described
in [4559-Ed4/AEDP-18].
[CISS-5] The CISS shall implement all mandatory Requirements and Rules as identified
by “MUST” clauses in [4559-Ed4/AEDP-18].
Verification Method: Testing and Inspection
[CISS-6] The CISS shall for all applicable CSD Stream Server XML schema definition
(XSD) files and Web Services Description Language (WSDL) files use the 4.4
versions (see Table 3-1 in [4559-Ed4/AEDP-18]). The applicable files are listed
in Table 3.

Table 3 Applicable XSDs and WSDLs for the CISS

Target Namespace File name Version
urn:nato:majiic:services:catalogentry CatalogEntry.xsd 4.4
urn:nato:majiic:services:commonmessages CommonMessages.xsd 4.4
urn:nato:majiic:common:ccod CountryCode1059.xsd 4.4
http://srvc/nato/majiic/services/CSDStreamServerReplication/CSDStreamServerReplication CSDStreamServerReplicationService. 4.4
Service wsdl
urn:nato:majiic:streamsync CSDStreamServerSync.xsd 4.4
urn:nato:majiic:common:isrcommon isrcommon.xsd 4.4
urn:nato:majiic:notification MAJIICNotification.xsd 4.4
http://srvc/nato/majiic/services/CSDStreamServerReplication majiic-services-replication.wsdl 4.4
http://srvc/nato/majiic/services/CSDStreamServerReplication/CSDStreamServerReplication majiic-services-replication.xsd 4.4
Messages/
http://srvc/nato/majiic/services/ services.wsdl 4.4
http://srvc/nato/majiic/services/StrmCtrlr/StreamControllerMessages/ StreamControllerMessages.xsd 4.4
http://srvc/nato/majiic/services/StrmCtrlr/StreamControllerService/ StreamControllerService.wsdl 4.4
http://srvc/nato/majiic/services/StrmCtrlr/ StrmCtrlr.wsdl 4.4
1Note: Version 4.4 of the XML artefacts has two different WSDL files named “majiic-services-replication.wsdl”, and similarly two different XSD files
named “majiic-services-replication.xsd”; the files applicable to the stream replication are located in the folder
“nato/majiic/services/CSDStreamServerReplication”

2.1.1 CSD/4559 Bridge Interface not required

[17] The CISS will not be required to implement the CSD/4559 Interface (to create proxy
products in the CSD ISR Product Library) as defined in [4559-Ed4/AEDP-18].
2.1.2 CSD Stream Notification Interface not required

[18] The CISS will not be required to implement the CSD Stream Notification Interface (to
inform client applications about broadcast or multicast streams that the CISS will
stream to the network) as defined in [4559-Ed4/AEDP-18].
2.1.3 Data Model Requirements

[19] The CISS will implement a subset of the STANAG 4559 Edition 4 Metadata Model as
defined by [4559-Ed4/AEDP-17].
[CISS-7] The CISS shall as a minimum implement the metadata attributes as defined in
Table 4. Note:
(1) The Metadata Model specification for the CSD stream server also includes
the three additional entities NSIL_APPROVAL, NSIL_RELATED_FILE, and
NSIL_VIDEO, which are to be considered optional for the CISS.
(2) The CISS shall always be able to deliver values for attributes tagged as
mandatory.
(3) The cells in where “Mandatory = YES” and “From stream data = YES”
identifies attributes that are mandatory and where the attribute values must
be extracted from, or in the case of NSIL_STREAM.standard inferred
from, the stream data. As a result the CISS shall only record, and add to its
catalogue, streams data that contain this required information.

Table 4 CSD Stream Metadata Model (subset of the full STANAG 4559 Edition 4 Metadata Model) from the perspective of a stream server
Entity Attribute Sortable Queryable Mandatory From Remark
stream
data
NSIL_CARD identifier YES YES YES NO A stream identifier that shall be automatically
set by the CISS (or national CSD stream
server) that is recording the stream. Combined
this identifier with the sourceLibrary
shall uniquely identify the recorded stream. I.e.
there can only be one recorded stream on the
network that has this combination of
identifier and sourceLibrary.
sourceDateTimeModified YES YES YES NO Shall be updated by the CISS to the current
time each time the stream metadata is updated
during stream recording. Shall also be updated
when the source server removes the stream
(setting status to OBSOLETE).
dateTimeModified YES YES YES NO Shall be updated by the CISS to the current
time whenever it receives updates on a stream
through the stream replication mechanism.
For locally recorded streams this field shall be
set to the same value as the
sourceDateTimeModified attribute.
status YES YES YES NO Depending on the context this attribute is to be
interpreted differently. When reported by the
CISS, the value is to be understood as follows:
‘OBSOLETE‘ – The stream data has been
removed, so it may no longer be replayed/
relayed or downloaded.
‘CHANGED’ – The stream exists and is available.
Note that the CISS shall not use the ‘NEW’
value.

10

stream
data
numberOfParts N/A N/A YES NO Hard-coded to 1 as there will always be one,
and only one, part
publisher YES YES NO NO Name of the organization to which the CISS (or
national CSD stream server) that recorded the
stream belongs. This name shall be
configurable through the CISS Administration
Tool.
sourceLibrary YES YES YES NO String identifying the CISS or national CSD
stream server where this stream was recorded.
For the CISS this name shall be configurable
through the CISS Administration Tool.
NSIL_COMMON descriptionAbstract N/A N/A NO N/A Not expected to be used for stream products.
identifierMission NO YES NO YES Information shall be extracted from the stream
data: /GMTI/PacketHeader/MissionID for
GMTI streams and EpisodeNumber for video
streams
identifierUUID NO YES YES NO If the streaming sensor system provides
notification messages with metadata on the
stream (see section [CISS-8]) the recording
CISS shall use the identifierUUID provided
by the sensor system. If the identifierUUID
value is not provided by the sensor system,
then the recording CISS shall generate a UUID
value for the stream and assign to this attribute.
identifierJC3IEDM N/A N/A N/A N/A Not expected to be used for stream products.
language N/A N/A N/A N/A Not expected to be used for stream products.
source NO YES NO YES Information shall be extracted from the stream
data: /GMTI/PacketHeader/Nationality
+ /GMTI/PacketHeader/PlatformID for

11

stream
data
GMTI streams, and ImageSourceDevice for
video streams
subjectCategoryTarget N/A N/A N/A N/A Not expected to be used for stream products.
targetNumber N/A N/A N/A N/A Not expected to be used for stream products.
type NO YES YES YES Enumeration specifying stream type. The value
(‘GMTI’ or ‘VIDEO’) shall be set by the CCIS
base on the stream type.
NSIL_COVERAGE spatialCountryCode N/A N/A N/A N/A Not expected to be used for stream products.
spatialGeographicReferenceBox NO YES YES YES Shall contain a bounding box calculated by
aggregating all received geo-spatial coverage
information for the stream.
Note that when the CISS send out metadata
replication messages the attribute will have a
different use, which is to report the latest
reported geo-spatial coverage information (see
also Table 6).
temporalEnd NO YES YES (for YES Shall be empty for live streams, and capture the
closed last recorded time in a closed stream.
streams)
temporalStart NO YES YES YES Earliest recorded time in the stream. Shall be
set by the recording CCIS upon receiving the
first timestamp in the stream.
NSIL_ classification YES YES YES NO The CCIS shall set these attributes to mirror the
METADATASECURITY policy YES YES YES NO attribute values in the NSIL_SECURITY, or
releasability YES YES YES NO manually set the attributes through the CISS
Administration Tool
NSIL_PART partIdentifier N/A N/A YES NO Hard-coded to 1 as there will always be one
and only one part
NSIL_SECURITY classification NO YES YES YES The information shall be extracted from the
policy NO YES YES YES stream data

12

stream
data
releasability NO YES YES YES (/GMTI/PacketHeader/Security/ for
GMTI and KLV-encoded security metadata for
video) and mapped onto the CSD security
metadata.
If needed, rules for mapping the security
attributes in the stream to the CISS metadata
shall be provided through the CISS
Administration Tool.
NSIL_STREAM archived YES YES NO NO Default value is ‘NO‘. When a stream is archived
(using the CISS Administration Tool) the value
shall be set to ‘YES‘.
archivalInformation YES YES NO NO When archiving a stream, information on how to
restore the archived stream shall be provided
through using the CISS Administration Tool.
creator YES YES NO NO The entity responsible for providing the stream
(typically the sensor system).
If the streaming sensor system provides
CISS shall use the NSIL_STREAM.creator
value provided by the sensor system in the
notification message.
If the NSIL_STREAM.creator value is not
provided by the sensor system, then this
attribute shall be left empty.
dateTimeDeclared YES YES NO NO If the streaming sensor system provides
CISS shall use the
NSIL_STREAM.dateTimeDeclared value

13

stream
data
provided by the sensor system in the
notification message.
If the NSIL_STREAM.dateTimeDeclared
value is not provided by the sensor system,
then the recording CISS shall set the same
value for this attribute as for
NSIL_COVERAGE.temporalStart.
standard NO YES YES YES Enumeration (‘STANAG4609‘ or ‘STANAG4607‘)
specifying the standard the stream complies
with. The value shall be set by the recording
CISS upon detecting whether the stream is
GMTI or video, and that the format is
recognized and supported.
standardVersion YES YES NO YES For GMTI the value is to be extracted from
(for /GMTI/PacketHeader/VersionID, for
GMTI) video, if the value cannot be found in the KLV
metadata, the attribute will be empty.
sourceURL NO YES NO NO URL allowing the stream contents to be
downloaded. If this configurable feature is
enabled, then the CISS shall set this URL for all
complete recorded streams.
programID N/A N/A N/A N/A Information not expected to be needed for initial
NATO streaming data capabilities.
2 Sensor systems are also using the same metadata model to convey information about the data it is streaming. In this case some of the metadata
attributes have a different interpretation

14
[CISS-8] The CISS shall implement both forward compatibility mechanism as defined in
[4559-Ed4/AEDP-18]:
(1) <extending its metadata model>
(2) <accepting catalogue entries not covered by its metadata model>

[CISS-9] The CISS implementation of Forward Compatibility shall ensure that all
extensions are persisted, forwarded to replication partners (e.g. in Bridgehead
Routing), and delivered to clients as part of query response.
Verification Method: Testing
2.1.4 Query and Retrieval Requirements

[20] The CISS will implement the CSD Stream Query Service Interface that will be used
by exploitation and analysis capabilities to search for live and recorded streaming
data. Live streams are discovered by searching for streams with no value in
NSIL_COVERAGE.temporalEnd;
e.g. not ( NSIL_COVERAGE.temporalEnd exists )
[21] For querying, the CISS implements the Boolean Query Syntax (BQS) as defined by
[4559-Ed4/AEDP-17].
[22] The original STANAG 4559 paradigm has a one-to-one mapping between ISR
products and query results i.e. each product is represented by at most one result. This
means that for a given query, there will be a single search result indicating that a
certain stream satisfies the query, but without any indication of the portion of that
stream which is relevant e.g. a five minute segment within a twelve hour mission.
[23] The CISS will implement an advanced search mechanism that will support fine-
grained searches where query results may return multiple results (sub-streams)
pointing to the same stream.
[CISS-10] The CISS shall implement the CSD Query Service Interface in accordance with
[4559-Ed4/AEDP-18].
[CISS-11] The CISS shall enable clients to query against all queryable stream service
metadata data as defined in Table 4.
[CISS-12] The CISS shall throw a BadQuery exception when receiving a query that queries
against any other metadata attributes beyond the attributes listed as queryable
in Table 4.

15
[CISS-13] The CISS shall implement sorting of query result enabling the query results to be
sorted on any of the sortable metadata attributes as defined in Table 4.
[CISS-14] The CISS shall ignore a sorting request on any attribute that is not listed as
sortable in Table 4. I.e. in this case the CISS shall deliver the query result in an
order as if no sorting request has been made.
[CISS-15] In addition to the getCapabilities mandatory capabilities as defined in [4559-

Ed4/AEDP-17] and the [4559-Ed4/AEDP-18], the CISS’s implementation of the
stream query service shall report on two additional capabilities as shown in Table
5.
Table 5 Additional capability reported by the CISS through the stream query service interface
Name GenericValue Usage and Value
class
query.advanced BooleanValue CISS shall set this value to TRUE to indicate that
the advanced query operation is available.
query.federated BooleanValue CISS shall set this value to FALSE to indicate that
federated queries are not supported.
[CISS-16] The CISS shall implement the advanced search mechanism that identifies one
or many sub-streams with the stream that matches the query result.
[CISS-17] The CISS shall distinguish the different sub-streams with start and end times as
provided in the stream metadata.
[CISS-18] The CISS shall use the urn:majiic:description:local part of the URI returned by
the getQueryResultSegment to encode the time range of the sub-streams.
This shall be done using following syntax for the VersionDescription:
(1) (<start date>T<start time>,<byte offset of the segment within the stream>-
<end date>T<end time>,<end byte offset of the segment within the
stream>).
E.g. (20150716T140110,612880-20150716T140314,181649172)

16
[CISS-19] In case the query results in multiple sub-streams then the dynamic attributes of
the query result shall be fused in accordance with the rules specified in [4559-
Ed4/AEDP-18].
[CISS-20] The CISS shall have support for populating the NSIL_STREAM.sourceURL
attribute with an HTTP URL through which the stream or sub-stream data can be
downloaded. It shall be possible to enable/disable this function.
[CISS-21] The CISS shall, when providing a URL to a client application for it to download
sub stream data, construct a URL that point to the same subset of the stream as
indicated in the sub stream metadata. I.e. if the URL is accessed, the CISS shall
return the portion (e.g. a motion imagery clip) as described by the sub stream
metadata.
Verification Method: Testing and Analysis
[24] It is recognized that for some video streams the KLV metadata update rate is so low
that there are gaps between each catalogued coverage area and as a result queries
could fail to report hits on queries against areas that were actually covered (false
negatives) as depicted in Figure 3.
Figure 3 False negative due to low update rate of coverage areas

17
[CISS-22] The CISS shall implement query algorithms that can to some degree counteract
low update rate of the coverage area (e.g. performing queries on convex hulls
between each pair of recorded coverage areas as depicted in Figure 4). The
query mechanism to address low-update rate coverage area situation shall be
configurable such that:
(1) The query mechanism can be activated and deactivated;
(2) The maximum time gap between two updates for which the mechanism
shall accept (i.e. if the time gap is larger than the specified value the special
query algorithm shall not be applied).
Figure 4 Example on how false negative query results can be avoided in situation of low update rate of
coverage areas by querying against a convex hull between pairs of coverage areas
2.2 Managing Stream Content

2.2.1 Recording Live Stream Data Requirements
2.2.1.1 Detecting Streams through Subscribing to Sensor Events
[25] The CISS may be notified of new streams starting, of stream metadata updates, and
of streams stopping by subscribing to messages posted by sensor capabilities. For
details see [4559-Ed4/AEDP-18].

18
[CISS-23] The CISS shall implement WS-Notification subscription in accordance with

[4559-Ed4/AEDP-19], and subscribe to sensor stream declarations as described
in [4559-Ed4/AEDP-18].
[CISS-24] Upon receiving an STOP STREAM notification message (serialized CSD stream
metadata, see Table 4, where NSIL_CARD.status = OBSOLETE) the CISS shall
identify the corresponding streaming product and close the stream product for
further updates.
2.2.1.2 Manually Configuration of Stream Listeners
[26] It is assumed that many, or even most, sensor capabilities will not have implemented
the WS-Notification publish-subscribe mechanism and the CISS will have to support
manual configuration of stream recording.
[CISS-25] The CISS shall be manually configurable (through the CISS User Interfaces, see
section 2.5) to listen to a set of ports where live streaming may occur.
2.2.1.3 Recording
[CISS-26] The CISS shall implement collecting, recording and cataloguing (this includes
extracting and storing all relevant metadata) stream data of the following types:
(1) Video streams in compliant with STANAG 4609 edition 3 [see [STANAG
4609 Ed3, 2009] and [AEDP-8 Ed3, 2009].
(2) Ground moving target indicator (GMTI) streams compliant with STANAG
4607 edition 3 (see [STANAG 4607 Ed3, 2010] and [AEDP-7 Ed2, 2013]).
[CISS-27] The CISS shall be able to receive streams sent over user datagram protocol
(UDP) unicast, broadcast and multicast.
[CISS-28] Upon receiving a notification message from a sensor system about a new stream
(serialized CSD stream metadata, see Table 4, where NSIL_CARD.status =
NEW, or the NSIL_CARD.status = CHANGED and there is an unknown stream
identifier in the NSIL_COMMON.identifierUUID attribute), or being triggered
by other configurable stream discovery methods (specified through the CISS
Administrator Tool) on the presence of a stream, the CISS shall for any of the
implemented stream type (see [26]):

19
(1) Start recording the streaming data;
(2) Extract information from the stream data to populate the two metadata
attributes NSIL_COVERAGE.spatialGeographicReferenceBox and
NSIL_COVERAGE.temporalStart.
(3) Once the NSIL_COVERAGE.spatialGeographicReferenceBox and

NSIL_COVERAGE.temporalStart attributes can be populated with
information from the stream data the CISS shall create a new product in its
catalogue of streaming data and populate all other mandatory metadata
attributes according to the guidance provided in Table 4. Note that in the
case of receiving a sensor stream notification message, the only attribute
value that shall be extracted from this notification message is the
NSIL_COMMON.identifierUUID; in the case of the CISS has started
recording the stream without the sensor notification message the CISS shall
generate the unique value for the NSIL_COMMON.identifierUUID
attribute itself;
(4) If the CISS is not able to extract information for the two attributes
NSIL_COVERAGE.spatialGeographicReferenceBox and
NSIL_COVERAGE.temporalStart from the stream data, the CISS shall
continue attempting to extract this information from the stream data for a
configurable period of time, before it shall give up, stop the recording, and
remove the recorded files(s). The CISS shall in this case log the event of
not being able to catalogue a stream to a log file.
[CISS-29] The CISS shall be able to detect that a sensor is no longer streaming and close
the stream product. E.g. the CISS could keep track of the time from receiving one
transmission packet of stream data until the next, and use a comparison of the
time since last received stream transmission against the expected maximum time
to declare a stream as closed.
[CISS-30] The CISS shall never re-open a stream that has been declared as stopped/
closed. I.e. if the stream, after a pause, continues again, then the CISS shall treat
this as a new stream. In the case a sensor continues a closed/ stopped stream
with the same NSIL_COMMON.identifierUUID then the CISS shall start a
new stream with a new value in the NSIL-CARD.identifier attribute, but
continue using the NSIL_COMMON.identifierUUID as provided by the sensor
(this means that the NSIL_COMMON.identifierUUID shall only uniquely
identify a stream from the sensor capability’s perspective; it shall not uniquely
identify a stream in the CISS).

20
[CISS-31] The CISS shall, when recording GMTI and video streams, extract and record
sensor footprint geo-spatial information (area covered on the ground) with the
timestamps as part of the stream metadata and the CISS shall use this collected
set of detailed geo-spatial information for fine-grained/ precise search operations.
[27] When inspecting video streams generated by video sensor simulators during MAJIIC
2 test events it was discovered that at times there were flaws in the sensor coverage
area. Issues detected where data with duplicate vertices, self-intersecting polygons,
and concave polygons. The CISS must be able to handle such flaws in the stream
data:
[CISS-32] The CISS shall when decoding the coverage metadata extracted from the data
streams ignore and discard all coverage data that does not comply with the
format rules as defined by STANAG 4609 (for video) and by STANAG 4607 (for
GMTI). I.e. the flawed metadata shall not be catalogued.
2.2.2 Import of recorded streams from file

[28] It is to be expected that streams could be injected into an operational network through
files of recorded streams (e.g. in case of air-gap exchanges). The CISS thus needs to
support a mechanism for importing such recording files.
[CISS-33] The CISS shall support import of streams from files of recorded video streams in
STANAG 4609 format.
[CISS-34] The CISS shall support import of streams from files of recorded GMTI streams in
STANAG 4607 format.
[CISS-35] The CISS file import mechanism shall support single-file import and multiple-file
(“bulk”) import.
[CISS-36] The CISS that imports a stream from a file shall become the source streaming
server for the stream - that means setting its own library name into the
NSIL_CARD.sourceLibrary metadata attribute.
2.2.3 Replication Requirements

[29] To enable discovery of stream products that have been uploaded to other national
CSD stream servers (or other instances of the CISS) the CISS will implement a CSD
stream replication mechanism.

21
[30] The stream replication mechanism uses a similar approach to replication as the simple
persistence as a service (SPS++) as defined by [4559-Ed4/AEDP-19], namely the use
of the “put” operation from WS Transfer [W3C WS-transfer]. As for the SPS++ the
choice of message oriented middleware (MOM) technology is not prescribed.
[31] In the following text, the replicating CISS instances and national CSD stream servers
are referred to as “peers”.
[CISS-37] The CISS shall inform peers any about changes (including a final notification with
status “Obsolete”), as a result of local interactions, to the persisted state of a
replicable streams by sending a replication message to the peers using the “put”
operation from WS Transfer [W3C WS-transfer, 2006].
[CISS-38] The CISS shall implement runtime dynamic configurability of the remote CSD
Stream Server replication peers (outbound and inbound).
[CISS-39] The replication message that the CISS sends to its peers shall be a serialization
of the CSD Stream Metadata Model as defined by Table 4.
[CISS-40] The CISS shall use an outgoing asynchronous pattern i.e. loosely coupled
dispatch of the replication messages outgoing to other CSD stream server
instances. This means that the CISS shall implement outbound replication
queues.
[CISS-41] The CISS outbound replication queues shall be unbounded (unlimited in size)
and durable (e.g. the queues are persisted across restarts of the CISS).
[CISS-42] The CISS usage of outbound replication queues shall be implemented in such a
way that messages are not blocked/ stuck in the queue due to an offline
replication peer. That means that CISS shall implement one separate outgoing
queue per replication peer and in this way achieve message transmissions to all
online replication peers and not be affected by any offline replication peers.
[CISS-43] If a replication peer cannot be reached (e.g. it is temporarily offline or there is a

network outage) the messages to this peer shall accumulate in the queue and
remain in the queue and then transmitted later when the replication peer is again
available.

22
[CISS-44] The CISS shall not remove a message from an outbound queue before the
receiving peer has confirmed that it has successfully received the message and
stored it locally in its inbound queue (if the message is transported over HTTP a
successful transmission is ensured once a HTTP status code of 200 is received
by the sending CISS).
[CISS-45] The CISS shall use an incoming asynchronous pattern i.e. loosely coupled
ingestion of the replication messages incoming from other CSD stream server
instances. This means that the CISS shall implement inbound replication queues.
[CISS-46] The CISS usage of inbound replication queues shall be implemented in such a
way that a burst of messages from one replication partner does not significantly
impact message coming in from other replication peers. That means that CISS
shall implement one separate incoming queue per replication peer.
[CISS-47] The CISS shall upon receiving an incoming replication message store it onto the
inbound queue for the peer sending the message before responding to the
sending peer and acknowledging a successful receipt of the message. I.e. if the
message is received over HTTP the receiving CISS shall respond with a HTTP
200 status code after having stored the message.
[CISS-48] If for some reason the receiving CISS is not able to store the received message
onto the inbound queue then the receiving CISS shall respond with an exception.
I.e. if the message is received over HTTP the receiving CISS shall respond with
a HTTP 500 status code.
[CISS-49] The CISS shall minimize the size of the replication message focussing on the
change (delta) in the metadata since the last replication message for the stream.
The replication messages that the CISS sends when reporting status on live
streams shall as a minimum contain:
Table 6 Mandatory attributes in a replication message

Attribute Remarks
NSIL_CARD.identifier Shall contain the two attributes that
NSIL_CARD.sourceLibrary together uniquely identify the stream at the
source streaming server.

23
Attribute Remarks
NSIL_CARD.sourceDateTimeModified Shall contain information on the last time
of metadata update at the source
streaming server.
NSIL_COMMON.identifierUUID Shall contain a universally unique identifier
for the stream. If set by the sensor system
this identifier can be used to de-conflict
own recorded stream from the same
stream recorded by another CISS or
national CSD streaming server (i.e. avoid
cataloguing the same stream more than
once).
NSIL_COVERAGE.spatialGeographicReferenceBox Shall contain a geospatial bounding box of
all sensor footprint on the ground received
in the stream data since the previous
replication message was sent.
If no previous replication message has
been sent then it shall contain a geospatial
bounding box of all sensor footprint on the
ground received in the stream data up until
the point of sending the first replication
message.
NSIL_COVERAGE.temporalStart Shall contain the first timestamp data
extracted from the stream data since the
previous replication message.
If no previous replication message has
been sent then it shall contain the first
timestamp data for this stream.
[CISS-50] After the CISS detects that the stream is closed the CISS shall send one last
replication message that shall as a minimum contain the attributes listed in Table
7.
Table 7 Mandatory attributes in the last replication message that signals that the stream is now closed
Attribute Remarks
NSIL_CARD.identifier The two attributes together uniquely
NSIL_CARD.sourceLibrary identify the stream at the source streaming
server.
NSIL_CARD.sourceDateTimeModified Carries information on last time of
metadata update at the source streaming
server.
NSIL_COMMON.identifierUUID Shall contain the universally unique
identifier for the stream.
NSIL_COVERAGE.spatialGeographicReferenceBox Shall contain a geospatial bounding box of
all sensor footprint on the ground received
in the stream data since the previous
replication message was sent.

24
Attribute Remarks
NSIL_COVERAGE.temporalStart Shall contain the first timestamp data
extracted from the stream data since the
previous replication message.
NSIL_COVERAGE.temporalEnd Shall contain the latest timestamp data
extracted from the stream data. Presence
of this attribute value signals that the
stream is closed.
NSIL_STREAM.sourceURL Shall contain a URL to the complete and
closed stream that it can be downloaded
at this URL
Presence of this attribute value (also)
signals that the stream is closed.
[CISS-51] The CISS shall be able to send a replication message each time the persisted
value of the NSIL_COVERAGE.spatialGeographicReferenceBox attribute
changes as long as the frequency of the replication messages does not exceed
1 message per second.
[CISS-52] The CISS shall implement configurability of the replication message frequency
where the maximum supported frequency is 1 message per second. The CISS
shall in case the geo-spatial coverage information is provided at a higher
frequency in the stream data, calculate a geospatial bounding box based on all
coverage area reports in the stream since the last replication message, and the
CISS shall for the replication message use the aggregated bounding box value
in the NSIL_COVERAGE.spatialGeographicReferenceBox attribute.
[CISS-53] As the CISS only can expect to receive the dynamic (changing) metadata
attributes through the replication mechanism the CISS shall upon receiving the
first replication message for a (new) stream, query the source streaming server
for additional metadata attribute values. As a minimum the CISS shall attempt to
collect values (through querying) for the attributes in Table 8 from the source
stream server prior to creating an entry in its own stream catalogue. Note that in
the event that any value for any of the mandatory attributes cannot be obtained
then the replicated stream shall be discarded.

25
Table 8 Attributes to be collected by querying the source stream server (once)

Attribute Remarks
NSIL_CARD.publisher If the source server does not provide the information
use an empty string.
NSIL_COMMON.identifierMission If the source server does not provide the information
NSIL_COMMON.identifierUUID If the source server erroneously does not provide
this identification information the CISS shall discard
this replicated stream and not create any entry in its
own catalogue. In the case the CISS is discarding a
stream replication then the CISS shall report on the
event in a log file.
NSIL_COMMON.source If the source server does not provide the information
NSIL_COMMON.type If the source server erroneously does not provide
the information the CISS shall discard this replicated
stream and not create any entry in its own
catalogue. In the case the CISS is discarding a
NSIL_METADATASECURITY.classification If the source server erroneously does not provide
NSIL_METADATASECURITY.policy the information the CISS shall discard this replicated
NSIL_METADATASECURITY.releasability stream and not create any entry in its own
NSIL_SECURITY.classification If the source server erroneously does not provide
NSIL_SECURITY.policy the information the CISS shall discard this replicated
NSIL_SECURITY.releasability stream and not create any entry in its own
NSIL_STREAM.creator If the source server does not provide the information
NSIL_STREAM.dateTimeDeclared If the source server does not provide the information
use the value received for the
NSIL_COVERAGE.temporalStart attribute in the
replication
NSIL_STREAM.standard If the source server erroneously does not provide
the information the CISS shall discard this replicated
stream and not create any entry in its own
NSIL_STREAM.standardVersion If the source server does not provide the information
[CISS-54] When stream locally recorded at the CISS is removed the CISS shall send out a
replication message with the attributes as defined in Table 9.

26
Table 9 Mandatory attributes in the a replication message that signals that the stream has been
removed from the source server
Attribute Remarks
NSIL_CARD.identifier The two attributes together uniquely identify the stream at
NSIL_CARD.sourceLibrary the source streaming server.
NSIL_CARD.sourceDateTimeModified Carries information on last time of metadata update at the
source streaming server.
NSIL_CARD.status Attribute value must be set to OBSOLETE
NSIL_STREAM.sourceURL Must contain an empty string
[CISS-55] If a CISS is receiving replication messages with unknown metadata attributes

(i.e. not defined by Table 4) the CISS shall only extract and use the attributes
defined in Table 6 to update its own cataloguing metadata and ignore all other
attributes, including the unknown attributes.
[CISS-56] When a CISS is located in a replication topology to forward received replication

messages it shall not make any changes to the payload of the received
replication message before forwarding to peer replication CSD stream servers.
That means that if the replication message contains unknown metadata
attributes, the CISS shall forward these even if they are unknown to the CISS.
[CISS-57] If the replication topology is not a full mesh and the CISS is positioned as part of
a chain of replicating peers the CISS shall forward incoming replication
messages to subsequent peer(s) in the replication chain.
[CISS-58] The CISS shall send replication messages pertaining to the same stream (i.e.
having same Catalog Entry identifier) in increasing temporal order. Note the
ordering of replication messages between different streams (i.e. different Catalog
Entry identifiers) is not defined.
[CISS-59] The CISS shall maintain a mapping from library identifier to the CSD stream
controller service interface endpoint (in another CISS or national CSD stream
server) through which streams with that source library identifier value may be
accessed.

27
[CISS-60] When participating in a network of replicating CISS instances and national CSD
stream servers the CISS shall support multiple synchronization topologies
including:
(1) Mesh
(2) Daisy-chained
(3) Star
[CISS-61] The CISS shall implement Bridgehead Routing as defined in [4559-Ed4/AEDP-

18].
[CISS-62] The CISS shall implement a configurable localizing mechanism that downloads
recorded streams belonging to replicated stream metadata from other CISS
instances and national CSD stream servers (for details on the configuration of
this function see section 2.3).
2.2.4 Data Exchange over SATCOM Requirements

[32] The CISS might be deployed to remote sites where it will need to receive and retrieve
data over satellite communication (SATCOM) links and hence need to be able to
handle TCP communication with large round-trip delay times.
[33] The CISS is expected to include a software-based performance-enhancing proxy that
enables and optimizes TCP traffic over SATCOM links.
[CISS-63] The CISS replication mechanism (see requirements in section 2.2.3) shall also
support replication over SATCOM links.
[CISS-64] The CISS shall when downloading a stream from a remote CISS (pending that
the remote CISS exposes the download URL) make use of a SATCOM adapted
communication mechanism to ensure successful retrieval of the file at the
minimum possible download time for the available bandwidth.
[CISS-65] The CISS shall include a mechanism for pushing stream files over a SATCOM
link to a remote CISS using a bandwidth aware service that sends data using idle
bandwidth (e.g. using Microsoft Background Intelligent Transfer Service (BITS)).
The receiving CISS shall add the received steam files to its set of localized
stream files.

28
2.2.5 Cross-Domain Requirements

[34] As depicted in Figure 5, it must be possible to export information from a CISS in one
network domain to a CISS in a different network domain where the two domains are
bridged by an Information Exchange Gateway (IEG), and where the cross-domain
exchange is facilitated by the services of the NATO Release Server.
Figure 5 Cross-domain exchange through the NATO Release Server and the IEG-C
[35] As the performance of the cross-domain exchange mechanism is assumed to be

insufficient to support cross-domain exchange of live streaming data, only recorded
streams and localized replicated streams will be exchanged.
[CISS-66] The CISS shall be able to package up a completed/ closed stream recording with
stream metadata in an IFAS-12 message (see [CO-12940-OPL-RSID], [CSD-
XDomain], and [IFAS12] for details) and push the package to the NATO Release
Server (the Release Server will then manage the cross domain exchange across
the IEG).
[CISS-67] The CISS shall, after fully localizing an entire replicated stream from the source
stream server, be able to package up the localized stream with stream metadata
in a IFAS-12 message (see [CO-12940-OPL-RSID], [CSD-XDomain], and
[IFAS12] for details) and push the package to the NATO Release Server (the
Release Server will then manage the cross domain exchange across the IEG).
[CISS-68] The cross-domain export function in the CISS shall be customizable. At a

minimum it shall be possible to specify:

29
(1) A flexible query on the products to be exported, to enable filtering, e.g. on

stream type (video and/or GMTI).
(2) Whether replicated streams (i.e. not own recordings) can be replicated, and
in that case the list of peer streaming servers to localize from.
(3) Releasability labelling (NSIL_SECURITY.releasability) of the

products to be exported.
(4) The maximum product file size for exportable products.
(5) Endpoint URL for the export to the Release Server.
(6) The IFAS12 property fields (as defined by [IFAS12]).

Verification Method: Demonstration
[CISS-69] The CISS shall be able to receive and import recorded streams delivered by the
NATO Release Server in the IFAS-12 format. After the import the stream shall
be included in the CISS’s stream catalogue as a fully localized stream.
2.2.6 Joining / Catch-up Requirements

[36] When standing up new CISS instances at different locations in a wide area network
(WAN) the new CISS instances will need to be populated with historic stream
metadata. This means that existing CISS instances must be able to export all its
historic stream metadata, and the new CISS instances must be able to import historic
stream metadata.
[CISS-70] The CISS shall enable a System Administrator to export historic stream metadata
for a specified time window into synchronization files in accordance with the
description in [4559-Ed4/AEDP-18].
[CISS-71] The CISS shall be able to import and populate its own catalogue metadata from
historic stream metadata synchronization files in accordance with [4559-
Ed4/AEDP-18].
[CISS-72] The CISS shall upon import check if the stream already exist in its repository and
prevent overwriting or duplication of existing stream data.

30
2.2.7 Archiving and/ or Stream Data Removal Requirements

[37] Over time the accumulated collection of streaming data may grow to a size that is not
sustainable in the storage infrastructure and stored data streams will have to be
archived off to off-line storage media or completely deleted.
[CISS-73] The CISS shall support archiving of any stream. For streams that are archived
the full metadata set shall remain available for querying, and only the stream data
files shall be moved to off-line storage.
[CISS-74] The CISS shall when archiving a stream record the archiving information in the
metadata attributes NSIL_STREAM.archived and
NSIL_STREAM.archiveInformation, and then send a replication message
to its peer streaming servers reporting that the stream has been archived. That
means the replication message shall include the two stream archiving attributes
(NSIL_STREAM.archived and NSIL_STREAM.archiveInformation).
[CISS-76] The CISS shall support re-importing an archived stream from offline storage
media.
2.3 Replaying and Relaying Requirements

[38] The CISS will implement the CSD Stream Controller Service Interface that will be used
by exploitation and analysis capabilities to start and stop replaying of recorded
streaming data, or relaying of live streaming data.
[39] Note: The Stream Controller Interface does not define functions for fast-forwarding or
rewind. Exploitation and analysis tools (client applications) may provide some of these
functions on the client side.
[CISS-77] The CISS shall implement the Stream Controller Interface as defined by [4559-
Ed4/AEDP-18].
[CISS-78] The CISS shall when reporting on the supported replay types for the
system.supportedReplayTypes capability report a comma separated list
that includes all three defined replay types (BROADCAST, MULTICAST,
UNICAST).

31
[CISS-79] The CISS shall when reporting on the supported stream types for the
system.supportedStreams capability report a comma separated list that
includes GMTI and VIDEO.
[40] When receiving a request from a client application to relay or restream a stream to the
client application the CISS will if it already is in the possession of the stream data
directly relay or restream to the client application, or in the case the CISS does not yet
possess the stream data retrieve the stream data from another CISS or national CSD
stream server before it relay or restream to the client application. This process is
shown in Figure 6.
Figure 6 Local and remote stream relay or replay
[CISS-80] When a client application requests the CISS to relay or replay a local stream (i.e.
the CISS is already directly receiving it on the network, or it has already recorded
the stream) the CISS shall:
(1) Return a replay identifier to the client.
(2) Relay or replay the requested stream using the parameters specified by the
client application.
[CISS-81] When a client application requests the CISS to relay or replay a stream that that
is not locally stored at the CISS that CISS shall:
(1) Using the stream library identifier identify the (other) CISS, or national CSD
stream server, from which the stream data is accessible through a CSD
stream controller service interface endpoint. Note that where the stream can

32
be accessed is not necessarily the originating CISS, or national CSD stream

server, where the stream data was initially received and recorded.
(2) Request a relay or replay of the stream from the (other) CISS or national
CSD stream server hosting the stream data.
(3) As the CISS receives the stream from the (other) CISS or national CSD
stream server hosting the stream data the CISS shall provide a replay
identifier, and forward the stream to the client application requesting the
stream and in doing so use the parameters specified by the client
application.
[CISS-82] Upon receiving a stop replay command (containing the replay identifier) the CISS
will stop relaying or replaying the stream.
[CISS-83] The CISS shall when it is receiving a stream from another CISS or a national
CSD stream server (during replay or relay), and local caching mechanism has
been enabled, store a local copy of the received stream. The CISS shall for future
replay-requests of the particular stream use its local copy of the stream.
[CISS-84] The CISS shall be able to replay (or relay) all of its recorded streams (see section
2.1.3). I.e. if the CISS can record a stream, then it shall also be able to replay or
relay it.
2.4 Video Conditioning for Web Browser Client Applications

[41] Most, if not all, Bi-SC AIS user applications are implemented as Web-applications
running in a Web browser. Such applications will not be able to consume video
streams from a CSD Streaming Server that only implements the services as defined
by [4559-Ed4/AEDP-18]. To make the video streams available for Bi-SC AIS user
applications additional services will be required from the CISS that conditions the
STANAG 4609 video streams for replay in a Web browser.
[CISS-85] The CISS shall include a video conditioning service for streaming video using
Dynamic Adaptive Streaming over HTTP (DASH), i.e. MPEG-DASH (ISO/IEC
23009-1:2012) protocol.
[CISS-86] The CISS DASH streams shall be made available in a minimum of three different
bit rates:
(1) At the original bitrate.

33
(2) At 50% of the original bitrate.
(3) At 25% of the original bitrate.

[CISS-87] The CISS video conditioning service shall implement a mechanism that delivers
the video metadata as extracted from the STANAG 4609 KLV metadata in the
stream in a manner that enables a HTML5 enabled Web client application in real
time to synchronize the received stream metadata with the video streams
received over the DASH protocol. This means that the KLV metadata shall be
delivered in a timely manner corresponding to the video stream delivered over
DASH, and where the KLV metadata is timestamped in such a way that
correlation of KLV metadata to the video is possible. The mechanism for how the
KLV metadata is pushed to the HTML5 enabled Web client application is to be
proposed by the Contractor, and approved by the Purchaser.
[CISS-88] The CISS video conditioning service shall be able to use different video sources
as input to its DASH streaming service. Supported inputs to the video
conditioning service shall include:
(1) Video streams stored locally in the CISS.
(2) Video streams received over UDP where unicast, multicast, and broadcast
protocols are all supported.
(3) Streaming from video file identified by a file Uniform Resource Identifier
(URI) or HTTP-based Uniform Resource Locator (URL).
2.5 User Interface Requirements

[42] The CISS is a server application and it will be serving users through dedicated user
applications (client applications of the CISS). Delivery of CSD stream client
applications is outside the scope if the CISS acquisition project.
[43] Even though the CISS does not include client applications that is used by users, it will
include user interfaces (UI) for configuration and maintenance of the CISS servers.
[44] The CISS will support two different user roles:
(1) System Administrator
(2) Operational Support

34
2.5.1 Server Configuration and Maintenance

2.5.1.1 CISS Setup and Configuration
[CISS-89] The CISS capability shall include user interface functionality that shall enable a
System Administrator to:
(1) Configure database settings, including connection endpoint, database

name, and database credentials.
(2) Configure CISS stream storage location.
(3) Configure the CISS instances with unique library identifier in the community-
agreed notation (it will be a string that typically is assembled of hyphen-
separated groups of characters where the groups convey information on
nation or organization, location, and a number).
(4) Specify the security environment that the CISS instance will be operating in
and to define rules for acceptable security attribute values in the security
entities NSIL_METADATASECURITY and NSIL_SECURITY for streams in
its repository.
(5) Configure CISS port usages. (By matching this port configuration with
firewall settings the CISS shall be fully accessible to client application also
when the CISS is deployed behind a firewall that close down all ports except
the ports the CISS has been configured to use.)
(6) Enabling/ disabling support for stream download. When enabled, URLs for
complete recorded streams shall be made available by the CISS through
the NSIL_STREAM.sourceURL metadata attribute. When disabled, the
NSIL_STREAM.sourceURL metadata attribute shall not have any URL.
(7) When replacing a CISS release with a new release, configure the new CISS
installation to connect to, and then continue using, the stream library from
the previous release.
(8) Configure the Application Monitoring (APM) settings. E.g. warning limits for
number of messages in inbound and outbound queues.
(9) Enable/disable the repository purge function (see section 2.5.3.3 Content
Management).
2.5.1.2 User Management
[CISS-90] The CISS shall include user interface functionality enabling a System
Administrator to:

35
(1) Create user accounts for users that will have the Operational Support role.
(2) Delete Operational Support user accounts.
(3) Specify maximum number of consecutive authentication attempts before

locking an Operational Support account.
(4) Specify “timeout” period to be used for automatically log-out any sessions
which have been inactive for that period of time.
(5) Enable/ disable prevention of multiple concurrent authentications from the

same user from different locations (IP addresses).
(6) Unlock Operational Support accounts that has been locked after failed
authentication attempts.
2.5.1.3 Second Level Support – Problem Management
[CISS-91] The CISS shall include user interface functionality enabling a System
Administrator to:
(1) Set/ Change log level for when to log and the log verbosity.
(2) View log files.
(3) Sort and filter entries in the log files by criticality.
(4) Search log files across all fields in the log record format.
2.5.1.4 Configure Replications and Cross-Domain Exchanges
[CISS-92] The CISS shall include user interface functionality enabling System
Administrators to:
(1) Configure which other CISS instances and national CSD streaming servers
the CISS shall replicate to.
(2) Configure the maximum frequency of sending out replication message per
stream (not to exceed 1 message per second). Default value shall be set to
1 message every 10 second.
(3) Configure CISS usage of performance enhancing proxy (PEP) for

connectivity with other CISS over SATCOM links (i.e. for which
communication links the traffic shall be routed through the PEP).

36
(4) Configure which remotely deployed CISS instances the CISS shall replicate
product metadata with over a SATCOM link.
(5) Configure filter (BQS query) for what stream files to be pushed to remote
CISS instances over a SATCOM link (e.g. only stream files within a certain
geographic area, and below a certain file size limit).
(6) Add metadata model extensions for incoming replication messages in

support of the <extending its metadata model> forward compatibility
feature.
(7) Configure the CISS to export recorded streams to the Release Server.
(8) Configure the CISS to import recorded streams from the Release Server.
2.5.2 Operational Monitoring

[CISS-93] The CISS shall include user interface functionality enabling Operational Support
users (and also System Administrators) to:
(1) Use a UI-supported query-builder to construct queries, query for products

in the CISS, and browse through the query results. When browsing the
query results the metadata of the products shall be available for displaying
to the user.
(2) Conduct a UI-supported comparison between query results from own CISS
and other CISS instances (or national CSD stream servers). The same
query shall be submitted to the local CISS and to another CISS (or a
national CSD stream server), and that the two result sets shall be
compared. The comparison shall list the query results in two vertical,
individually sortable, and parallel columns.
2.5.2.1 Video Player Module for Web-browser
[CISS-94] The CISS Operational Monitoring user interface shall, using the video
conditioning service providing DASH streaming to web clients (see section 2.4),
support preview of video streams. This preview shall show the video and
synchronously display the KLV metadata in the video stream.
[CISS-95.a] The CISS video preview module shall adapt to effective network bandwidth and
use the optimal set of DASH files for the available bandwidth.

37
[CISS-95.b] The CISS video preview function shall support the following video playback
controls:
(1) Start (and re-start from any paused position in the video)
(2) Pause
(3) Timeline scrubbing forward and backward
(4) Thumbnail seeking when scrolling over the video timeline

2.5.3 Operational Management

2.5.3.1 Stream Collection and Recording Configuration
(1) Configure CISS to listen to a set of ports where data may be streamed (as
multicast streams, broadcast streams, or unicast streams).
(2) Configure length of timeout period before CISS shall stop attempting to
extract the required metadata from the stream and reject recording of a
stream.
3 An example of such Thumbnail Seeking can be found on the Internet at https://bitmovin.com/html5-

video-thumbnail-seeking/

38
2.5.3.2 Local Cache Management
(1) Enable/ disable caching of streams received from another CISS (or national
CSD stream server) when delivering a product to a client. As part of
enabling the caching, it shall be possibly to specify the cache expiration time
(i.e. for how long the CISS shall hold cached product files before removing
them).
(2) Purge cached (localized) streams originating from another CISS (or national
CSD stream server). That purge function shall support purging of cached
files for individual streams, and for purging a set of streams. The stream
selection/ filtering shall be done by entering BQS queries.
(3) Configure the CISS to download all stream files from an external CISS (or
national CSD stream server) pending that the remote stream files are
available through NSIL_STREAM.sourceURL. The tool shall enable
defining a BQS query as the filter to select the stream files to download and
cache.
2.5.3.3 Content Management
(1) Dynamically configure CISS, and update CISS configuration, to enable

capturing all relevant live streams from the network (streams that are being
sent over multicast, broadcast, and unicast).
(2) Remove individual streams from its repository so that the streams can no
longer be found through the CISS query services. Note that this is a “hard
purge” and is different from the “soft delete” when setting the
NSIL_CARD.status to OBSOLETE.
(3) Purge the CISS repository pending that this functionality has been enabled
(e.g. for exercises).
(4) To import recorded video and GMTI streams from files into the CISS. This
means that the User Interface enables selection of a single or several
recording files and that the CISS reads the each file, extracts the metadata
and add the streams to its catalogue.

39
2.5.3.4 Import / Export
(1) Command the CISS, using BQS queries as filter, to export a filtered
snapshot of its repository (metadata and localized streams) to file storage
(as synchronization files, see [4559-Ed4/AEDP-18]). The file(s) can then be
used to populate joining CISS at other locations.
(2) Command the CISS to import products (metadata and stream files) from
synchronization file(s) exported by another CISS instance.
(3) Command the CISS to archive off selected streams to storage media for
offline storage.
(4) Command the CISS to re-import an archived streams from a storage media.
2.6 Application Performance Monitoring (APM) Requirements

[45] It is important that the CISS operates with high availability and responsiveness. The
CISS quality of services will be affected by faults of the underlying technology stack
(networking, storage and compute) in addition to its intrinsic faults.
[46] While the IT infrastructure services (network-compute-storage) will affect the CISS’s
perceived performance, the monitoring of the IT infrastructure will be handled
externally to the CISS. The CISS will be responsible for monitoring performance
indicators that are mostly application specific.
[CISS-100] The CISS shall, in a low-intrusive way (less than 5% of the CPU load), collect
and provide (make available) statistics on the following Key Performance
Indicators (KPI):
(1) The average query time on the CISS as experienced by a client application.
The query times shall be collected whenever a client application queries the
CISS (i.e. no dedicated queries for the purpose of performance monitoring
shall be used). The average query time shall be computed over a
configurable number of queries (default sample set shall include 10
queries), and reported once per consecutive sample set.
(2) The average product localization download rate (e.g. kB/s) for the CISS to
download and localize stream files from external CISS servers and national
CSD stream servers. The download times shall be collected as part of
normal operation download functions (i.e. no dedicated downloads for the
purpose of performance monitoring shall be used). The average download
rate shall be computed, and reported, separately for each external CISS
and national CSD stream server over a configurable number of downloads

40
(default sample set of shall include 10 downloads). A new report shall be

produced each time an average can be calculated over a full sample set.
[CISS-101] The CISS shall report on the following events:
(1) Size of log file(s) exceeds a configurable percentage of its/their maximum

permitted size(s).
(2) Number of failed log-on attempts to the CISS Administrator Tool exceeds a
predefined limit.
(3) Failure to deliver a service due to capacity constraints (see section 3.1.1.3)
(4) Failure to replicate a message to a replication peer (see [CISS-44]).
(5) An outbound replication queue exceeds a configurable number of

messages (see [CISS-44]).
(6) An inbound replication queue exceeds a configurable number of messages

(see [CISS-47]).
[CISS-102] The CISS shall timestamp each event with date and time of the event occurring.
[CISS-103] The collected CISS performance statistics and recorded events shall be
conveyed to a Service Quality Management (SQM) Application using TM Forum
Service Quality Management REST Specification R16.5.1
(https://www.tmforum.org/resources/specification/tmf657-service-quality-
management-api-rest-specification-r16-5-1/).
[CISS-104] The CISS shall also have support for writing the APM reports defined in this
section to file in a structured format.
[CISS-105] It shall be possible to configure the CISS to either push the APM reports to the
SQM endpoints (see [CISS-103]), or to files (see [CISS-104]), or to both.

41
3 Non-functional Requirements
[47] The Non-Functional Requirements (NFR) categorise the product characteristics which
cannot be defined as "functional". The non-functional requirements are grouped in:
(1) Performance Requirements (§ 3.1)
(2) Compatibility (§ 3.2)
(3) Usability (§ 3.3)
(4) Reliability (§ 3.4)
(5) Security (§3.5)
(6) Maintainability (§ 3.6)
(7) Portability (§ 3.7)

[48] For each category of the non-functional requirement defined in the SRS, a set of
quality requirements will be defined, in accordance with ISO-25010 standard.
[49] The quality of a system is the degree to which the system satisfies the stated and
implied needs of its various stakeholders, and thus provides value. These stated and
implied needs are represented by quality models that categorise product quality into
characteristics, which in some cases are further subdivided into sub-characteristics.
(Some sub-characteristics are divided into sub-sub-characteristics.) This hierarchical
decomposition provides a convenient breakdown of product quality.
[50] Characteristic definitions in this section are based on ISO/IEC 25010:2011(E) -
System and software quality models.
[51] A tailoring of the standard has been made to assure that the Quality Characteristics
necessary for the Platform are correctly selected and defined, in accordance with
chapter 3.5 of the Standard.
[52] For the Monitoring of quality characteristics, the following definitions will be used:
 Error (or Fault): A design or source code or hardware flaw or
malfunction that causes a Failure of one or more Configuration Items. A
mistake made by a person or a faulty Process that affects a CI is also an
Error (human Error). For this System, Human Error is generally not
taken into consideration in measuring the quality Performance.
 Fault: see Error
 Failure: Loss of ability to Operate to Specification, or to deliver the
required output. The term Failure may be used when referring to
Services, Processes, Activities, or Configuration Items.
 Critical Failure: it is a failure that causes an immediate cessation of the
ability to perform the required function/service.

42
 Incident: An unplanned interruption to a service or reduction in the

quality of a service.
 Problem: A cause of one or more Incidents. The cause is not usually
known at the time the Incident happens.
3.1 Performance Requirements

[53] ISO 25010: This characteristic represents the performance relative to the amount of
resources used under stated conditions.
[CISS-106] The CISS, when populated with 1 hour of video and 1 hour of GMTI stream
data that is catalogued with the high resolution geo-reference and timestamp
metadata, shall within 0.5 second respond to any single query using a geo-
spatial element, a temporal element, and stream type element and where the
CISS executes an advanced search (see [CISS-16]) and returns sub-streams.
[CISS-107] The CISS, when populated with 1 hour of video and 1 hour of GMTI stream
data that is catalogued with the high resolution geo-reference and timestamp
metadata, shall be able to process and respond to all of 5 parallel queries within
1.0 second where all queries include a geo-spatial element, a temporal element,
and stream type element and where the CISS execute advanced searches (see
[CISS-16]) and returns sub-streams.
[CISS-108] The CISS, when populated with 500 hours of video and 500 hours of GMTI
stream data that is catalogued with the high resolution geo-reference and
timestamp metadata, shall within 1 second respond to any single query using
a geo-spatial element, a temporal element, and stream type element and where
the CISS executes an advanced search (see [CISS-16]) and returns sub-
streams.
[CISS-109] The CISS, when populated with 500 hours of video and 500 hours of GMTI
stream data that is catalogued with the high resolution geo-reference and
timestamp metadata, shall be able to process and respond to all of 5 parallel
queries within 2 seconds where all queries include a geo-spatial element, a
temporal element, and stream type element and where the CISS execute
advanced searches (see [CISS-16]) and returns sub-streams.
[CISS-110] For situations where the number of concurrent stream recordings is within the
specified CISS capacity (see section 3.1.1.3) the CISS shall, for all of the

43
receiving streams, be able to extract, catalogue, store stream data, and send a
replication message within 1 second of receiving the streaming data.
3.1.1 Performance Efficiency (quality) Requirements

3.1.1.1 Time behaviour
[54] ISO 25010: Time Behaviour is the degree to which the response and processing times
and throughput rates of a product or system, when performing its functions, meet
requirements.
[CISS-111] The CISS shall meet the performance requirements as defined by [CISS-106]
through [CISS-110] for at least 99.5% of its Operational Time.
3.1.1.2 Resource Utilization
[55] ISO 25010: Resource Utilisation. Degree to which the amounts and types of resources
used by a product or system, when performing its functions, meet requirements.
[56] Note that:
(1) Provisioning of sufficient storage is an IT infrastructure responsibility and

storage requirements are handled externally to the CISS.
(2) This SRS only defines the resource utilization requirements for a single
server. In the case that the CISS is upgraded for horizontal scalability the
CISS will be provisioned in accordance with the needs of the scaled out
configuration.
[CISS-112] The CISS shall, when running in a virtualized environment provisioned with 16
GB memory and 12 (2x6) vCPU with up to 500 hour of video and 500 hour of
GMTI catalogued stream data and an average of 5 concurrent users, comply with
the performance requirements as defined by [CISS-106] through [CISS-110] for
99.5% of its Operational time without any Critical Failure.
3.1.1.3 Capacity
[57] ISO 25010: Capacity. Degree to which the maximum limits of a product or system
parameter meet requirements.
[58] Capacity parameters can include the number of items that can be stored, the number
of concurrent users, the communication bandwidth, throughput of transactions, and
size of database.
[CISS-113] The CISS shall with sufficient resource provisioning, and potentially in a scaled-
out configuration, at a minimum be able to manage up to 10,000 hours of video

44
and 10,000 hours of GMTI recorded and catalogued stream data, without any
critical failure for at least 99.5% of its Operational time.
[CISS-114] The CISS shall able to provide a throughput of up to 475,200 replication

messages per day, without any critical failure for at least 99.5% of its Operational
time.
[CISS-115] The CISS shall be able to concurrently record 24 video streams and 8 GMTI
streams where the CISS extracts and catalogues timestamp and geo-spatial
metadata from the streams and send out replication messages in accordance
with requirements in section 2.2.3), without any critical failure for at least 99.5%
of its Operational time.
[CISS-116] The CISS shall be able to concurrently restream 48 video streams and 16 GMTI
streams from its catalogue of recorded streams onto a local network over UDP
(unicast, broadcast, or multicast), without any critical failure for at least 99.5% of
its Operational time..
[CISS-117] The video conditioning service (see section 2.4) shall, when streaming the video
in the original bitrate, as a minimum be able to support DASH streaming to 20
concurrent web client applications, without any critical failure for at least 99.5%
of its Operational time..
[CISS-118] The video conditioning service shall, when it also needs to transcode to another
bitrate, be able to support DASH streaming to two concurrent web client
applications, without any critical failure for at least 99.5% of its Operational time.
3.2 Compatibility
[59] ISO 25010: Compatibility. Degree to which a product, system or component can
exchange information with other products, systems or components, and/or perform its
required functions, while sharing the same hardware or software environment.
3.2.1 Co-existence
[60] ISO 25010: Co-existence. Degree to which a product can perform its required
functions efficiently while sharing a common environment and resources with other
products, without detrimental impact on any other product.

45
[CISS-119] The CISS shall coexist (i.e., work correctly and not adversely impact other
applications) with Bi-SC AIS standard Anti-Virus software without any critical
failure for the 99.5% of its Operational Time.
Inspection and Analysis
[CISS-120] The CISS shall be capable of operating within the NS and MS WAN environment
(including servers, network, services and workstations) in the presence of the
latest approved NATO Security Settings (target version to be provided by the
Purchaser during the Design Stage), without any critical failure for 99.5% of its
operational time.
Inspection and Analysis
3.2.2 Interoperability
[61] ISO 25010: Interoperability. Degree to which two or more systems, products or
components can exchange information and use the information that has been
exchanged.
[CISS-121] The CISS shall be fully interoperable with national CSD stream servers and
stream consumer clients that are compliant with the [4559-Ed4/AEDP-18] such
that the CISS is able to replicate all stream metadata to the national CSD stream
servers, receive replication messages from the national CSD stream servers, and
enable national CSD stream consumer clients to query the CISS and request
streams from the CISS, without any critical failure for at least 99.5% of its
Operational time.
[CISS-122] Any operationally installed version of the CISS shall be interoperable without any
critical failure for at least 99.5% of its Operational time with the following systems
and applications (the systems in the specified versions below will be provided, or
made available, by the Purchaser for the test):
(1) Current NATO CSD (“Bridging Solution”) stream server
(2) BICES CSD stream server
(3) Release Server
(4) National CSD ISR Streaming Servers of Baseline STANAG 4559 Edition 4

46
[CISS-123] All WSDL files exposed by the CISS shall validate without failures against the
respective standard STANAG 4559 edition 4 specified version 4.4 WSDL files
(see Table 3-1 in [4559-Ed4/AEDP-18]), for 99.5% of its operational time.
3.3 Usability
[62] ISO 25010: degree to which a product or system can be used by specified users to
achieve specified goals with effectiveness, efficiency and satisfaction in a specified
context of use
[63] For Usability, only the learnability and operability characteristics have been selected.
3.3.1 Learnability Requirements

[64] ISO/IEC 9126: Learnability. It is the capability of a software product to enable the user
to learn how to use it.
3.3.1.1 Language
[CISS-124] The CISS shall use "UK English" as the default language. This shall apply to all
applications and supporting components, including all user interfaces (e.g. views,
dialogs, help screens, tooltips, etc.), error/notification/warning messages and
documentation.
3.3.1.2 Simple/Intuitive User Interfaces
[CISS-125] The CISS User Interfaces shall work on the principle of "visibility" which means
the application shows users whatever they need for the current task without
distracting or overwhelming them with unrelated tasks or options.
[CISS-126] The CISS User Interfaces shall filter user-accessed information according to the
user's authorisation, so that users can only see what they are allowed to view
and/or change (including both data and functionality).
[CISS-127] The CISS User Interfaces shall be minimised according to what the user can do.
The GUI shall only show entities and attributes (e.g. forms and fields) and
functions (e.g. menus and buttons) that are actually available within the security
authorisation of the user. Disabled functions due to permissions shall not be
shown at all.

47
[CISS-128] The CISS User Interfaces shall only show functionality (e.g. menu items, buttons,
selections) that is appropriate to the situation based on user role and permissions
and object status. The CISS shall hide or clearly disable (e.g. grey out)
functionality not appropriate at the time, including items on second-level and
lower-level menus and dialogue boxes.
[CISS-129] The CISS User Interfaces shall provide Breadcrumbs on the interfaces to reflect
"where I am now in the system".
[CISS-130] The CISS User Interfaces shall keep page size limited on one screen in order to
reduce the need for scrolling to see the submit button.
[CISS-131] In the CISS User Interfaces, scrolling bars (i.e., horizontal and vertical) shall be
available when information does not fit onto one screen.
[CISS-132] Where data entry in the CISS User Interfaces is permitted only in prescribed
areas, a clear visual definition of the entry fields shall be provided.
[CISS-133] The CISS User Interfaces shall for all icons support screen tips that offer added
explanation and assistance.
[CISS-134] The CISS User Interfaces shall use domain terminology consistent with this
System Requirement Specification and other NATO documents.
[CISS-135] Labels in the CISS User Interfaces shall be context-dependent, meaningful and
descriptive to the function or action at hand.
[CISS-136] The CISS User Interfaces shall clearly identify all time values as Zulu (e.g.,
0815Z).
[CISS-137] The CISS User Interfaces shall represent all date/time data according to ISO
8601.

48
[CISS-138] The CISS User Interface shall comply with the following Basic Rules for the Use
of Text:
(1) Speak the user’s language, never use technical jargon.
(2) Avoid large text blocks; too much text discourages the user.
(3) Use headlines and bullets to structure your text.\
(4) Avoid redundancies.
(5) Use bold text only for text that must be read.
(6) Use italic text only for emphasis.
(7) Never use bold italic text.
(8) Never use all capitalised text.
(9) Use underlined text for links only.
(10) Use industry standard terminology.

3.3.1.3 User Interactions
[CISS-139] All CISS User Interface windows shall display a header line showing a
Classification Bar that dynamically is updated to displaying the highest
classification of the information in the window.
[CISS-140] The CISS User Interfaces shall be tolerant to input errors. Users shall be given
guidance and suggestions to help them correct or overcome mistakes they have
already made.
[CISS-141] The CISS User Interfaces shall provide Error Management capability which is
readily distinguishable from other displayed information (e.g. Pop-up Error
Window).
[CISS-142] The CISS User Interfaces shall provide the users with meaningful error
messages and information about the actions they need to take in order to fix or
at least to report the problem.

49
[CISS-143] The CISS User Interfaces shall notify the user who has initiated an action that
processing of the action has started and convey the sense of processing
progress (by means of a progress indicator, dialog boxes).
[CISS-144] The CISS User Interfaces shall, when response time can be expected to deviate
considerably from the response time expected by the user, provide the user with
information on this:
(1) If delay is below 2 seconds an animated mouse cursor or other "busy"

indicator shall be used.
(2) If delay is between 2 and 10 seconds, an animated progress indicator shall

be used.
(3) If delay is above 10 seconds, an animated progress indicator shall be used

and information about the status of the process shall be provided.
[CISS-145] The CISS User Interface control actions shall be simple and direct, whereas
potentially destructive control actions shall require extended user attention such
that they are not easily acted on (e.g., "are you sure" queries).
[CISS-146] The CISS User Interfaces shall support editing of displayed information in a
logical order.
[CISS-147] The CISS User Interfaces forms shall allow navigation using the tab key in a
logical order. Tab order shall represent the same logical order shown on screen.
[CISS-148] The CISS User Interfaces shall support copying and pasting from other
applications via the Clipboard.
[CISS-149] The CISS User Interfaces shall support normal MS Windows Accelerators. This
includes:
(1) CTRL+C (Copy)
(2) CTRL+X (Cut)
(3) CTRL+V (Paste)

50
(4) CTRL+Z (Undo)
(5) DELETE (Delete)

[CISS-150] The CISS User Interfaces shall support text selection by pointing device (click,
drag).
[CISS-151] The CISS User Interfaces shall display the expected input format on all form
fields to the user if the label is not clear enough (e.g. date input format -
ddmmyyyy or dd-mm-yyyy). This may be done via tooltips, greyed-out example
content, additional labels, or some other means.
[CISS-152] The CISS User Interfaces shall be tolerant to the delimiters of input format,
including Date format (e.g. dd-mm-yyyy could also be entered as ddmmyyyy or
d-m-yy without error or picked from a calendar) and Location format (e.g.
latitude/longitude could be entered as degrees-minutes-seconds or
degrees.decimal degrees).
[CISS-153] For all attributes related to geographic coordinates, the CISS User Interfaces
shall allow the user to enter geographic coordinates in a single text field (not
requiring the user to copy/paste more than once to input a geographic value).
Core GIS shall automatically identify and parse the location information entered
as:
(1) Degrees/Minutes/Seconds
(2) Decimal Degrees
(3) Degrees and Decimal Minutes
(4) Degrees, Minutes and Decimal Seconds
(5) Military Grid Reference System (MGRS)
(6) Universal Transverse Mercator (UTM).

[CISS-154] The CISS User Interfaces shall implement a Help function, which shall provide
the type and level of information the user requires to execute a task or solve a

51
problem. The Help function shall provide procedural aids, the assistance to
recover from errors, and advice without requiring the user to exit the application.
[CISS-155] The CISS User Interfaces Help function shall comply with the following rules:
(1) Help shall be easy to access.
(2) Access to Help shall be uniform.
(3) Help shall be available throughout all User Interfaces.
(4) Help shall be easy to understand.
(5) It shall be easy to navigate within Help.
(6) It shall be easy to return to where the user was before activating Help.
[CISS-156] The CISS User Interface shall implement Tool Tips for all controls, which can
benefit from a text description, especially those that do not have a text label.
[CISS-157] The implementation of the Tool Tip shall comply with the following rules:
(1) Tool Tip text shall be concise.
(2) For labelled controls, the Tool Tip can be omitted, or when used an
additional explanation has to be provided in the Tool Tip instead of simply
repeating the control label.
(3) The Tool Tip shall appear automatically after a given time period. 500 ms is
recommended.
(4) The Tool Tip shall stay open as long as the user does not move the mouse
pointer away.
(5) The Tool Tip shall use sentence-style capitalization.
(6) A Tool Tip should preferably not have more than two lines of text.
(7) The Tool Tip shall be placed in such a way that it does not cover the control
the Tool Tip refers to.
[CISS-158] The CISS shall ensure that all User input values are validated before they are
used, including:

52
(1) Data types (e.g., string, integer, real)
(2) Allowed character sets
(3) Minimum and maximum length
(4) Whether null is allowed
(5) Whether the actual parameter is required or not
(6) Whether duplicates are allowed
(7) Numeric range
(8) Specific patterns (e.g., regular expression)

3.3.1.4 Appearance
[CISS-159] The CISS User Interface shall comply with NCI Agency Human Machine
Interface (HMI) Style Guide.
[CISS-160] Visual elements and interaction schemes of the CISS User Interfaces shall be
reused on similar functions and features. Uniformity is created this way, which
helps users to understand where they are and what they can do.
[CISS-161] The CISS User Interfaces shall be based on a single theme where a common
look and feel is carried across all the User Interfaces.
[CISS-162] The CISS User Interfaces shall use a consistent font across all user interfaces.
[CISS-163] The CISS User Interface shall comply with the following font usage rules:
(1) Use font colours that assure a high contrast between text and background.
Dark text on a white background is recommended.
(2) Choose an appropriate font size; do not choose very small font sizes for the
sake of saving screen space.
(3) Avoid using blue text for anything but links.

53
(4) Avoid using white text on a coloured background. This is more difficult to
read.
(5) Avoid too many different font sizes.
(6) Never use all capitalised text.

[CISS-164] The CISS User Interfaces shall always ensure sufficient contrast between
foreground and background colour (e.g. using recommendations from Web
Content Accessibility Guidelines (WCAG)).
[CISS-165] The CISS User Interfaces shall comply with the following colour usage rules:
(1) Colour can be used to draw attention and to highlight important information.
(2) Emphasise connections between related objects by adding the same

colour.
(3) Do not use too many colours. A basis of four to five colours should not be
exceeded.
(4) Do not use highly saturated colours.
(5) Always assure appropriate contrast.
(6) (6) Pay attention to cultural aspects, different colours may have different
meanings in different cultures.
(7) Never use colour as primary or solitary communication channel. Always

provide redundant indicators (e.g. text or graphical symbols).
[CISS-166] The CISS User Interface shall use suitable, intuitive, and whenever possible
commonly used metaphors for the icons/functions, e.g. as shown in Figure 7.
Figure 7 Example metaphors for icons/functions

54
[CISS-167] The CISS User Interface shall not reuse a label/icon metaphor for multiple
actions.
3.3.1.5 Quality of Learnability
[65] ISO 25010: Learnability. Degree to which a product or system can be used by
specified users to achieve specified goals of learning to use the product or system
with effectiveness, efficiency, freedom from risk and satisfaction in a specified context
of use.
[CISS-168] In order to measure learnability, the Contractor shall prepare and propose a set
of maximum 10 Learnability Tasks for the Purchaser to approve. The Learnability
Tasks shall include key tasks for the user roles of the CISS. The learnability tasks
will be performed by a maximum of 10 Purchaser’s designated users.
[CISS-169] The Learnability tasks shall not take more than 2 hours to be executed.
[CISS-170] A minimum of 80% of the Learnability tasks shall be learned by at least 80% of
the designated users within the time allocated for the Learnability tasks (test).
3.3.2 Operability Requirements

3.3.2.1 Logging
[CISS-171] The CISS shall clearly identify time values as Zulu (e.g., 0815Z) in all logs.
[CISS-172] The CISS shall represent all date/time data in all log files according to ISO 8601.

55
[CISS-173] The CISS generate and retain an Audit Log for events that includes:
(1) CISS start-up (including re-starts).
(2) Changes to CISS configurations.
(3) Manual changes to the local caching of products (see section 2.5.3.2)
(4) Manual changes to CISS content (see section 2.5.3.3)
(5) Import to, or export from, CISS (see section 2.5.3.4)

Verification Method: Analysis
[CISS-174] All errors and faults in CISS shall be recorded in an Error Log.
[CISS-175] The CISS shall generate and maintain an Audit Log for each of the following
auditable events, shall associate individual User identities to those events, and
shall include date and time of the event, type of event, User identity, and the
outcome (success or failure) of the event:
(1) System start-up and shutdown
(2) Log-on and log-off of users
(3) Changes to permissions and privileges of users or groups
(4) Changes to security relevant CISS management function
(5) Any access to audit log
(6) Deletion, creation or alteration of the security audit records
(7) All privileged operations
(8) All updates of CISS access rights
(9) All attempts to delete, write or append the Audit files

[CISS-176] The CISS shall log a memory dump of the CISS executable when it crashes.
[CISS-177] In CISS audit tracing shall be permanently effective.


56
[CISS-178] The CISS error and change logs shall contain required information in order to
provide the support staff with interpretable and comprehensive information about
the cause and nature of the error/change.
Verification Method: Inspection and Demonstration
[CISS-179] The CISS shall support at least the following error system events:
(1) Crashing of software components
(2) Unplanned and recovering of a connection with a Release Server
(3) Incorrect received data
(4) Replication failure

[CISS-180] The CISS shall allow an administrator to select the events to be logged.
[CISS-181] The CISS shall allow configuration of logging verbosity, and disabling of various
types of logging.
[CISS-182] CISS Error Log and Audit Log shall contain all required information in order to
provide the support staff with interpretable and comprehensive information about
the cause and nature of the error/change.
[CISS-183] The CISS shall provide a log analysis and reporting tool, to enable browsing,
searching and reporting on logs, based on combinations of search criteria across
all fields in the log record format.
3.3.2.2 Resource Controls
[CISS-184] The CISS shall limit the number of requests (queries and downloads) a client can
have active at any one time.
3.3.2.3 Quality of Operability
[111] ISO 25010: Operability. Degree to which a product or system has attributes that make
it easy to operate and control

57
[CISS-186] In order to measure Operability, the contractor shall prepare and propose a set
of maximum 10 Operability Tasks for the Purchaser to approve. The Operability
Tasks shall be focussed on locating and inspecting log files and inspecting KPIs
(see section 2.6). The Operability Tasks will be performed by a maximum of 10
Purchaser’s designated users.
[CISS-187] The Operability Tasks (test) shall not take more than 2 hours to be executed.
[CISS-188] A minimum of 80% of the Operability Tasks shall be successfully executed by at
least 80% of the designated users within the time allocated for the Operability
Tasks (test).
3.4 Reliability
[66] ISO 25010: Reliability. Degree to which a system, product or component performs
specified functions under specified conditions for a specified period of time.
[67] MTBF (Mean time between Failures) is defined as the mean time between two
consecutive failures.
[68] MTBCF (Mean time between critical failures) is defined as the mean time between two
consecutive CRITICAL failures.
[CISS-189] The CISS system shall exhibit a Mean Time Between Failures (MTBF)
characteristics of 720 Hours as a minimum.
[CISS-190] The CISS system shall exhibit a Mean Time Between Critical Failures (MTBCF)
characteristics of 8760 Hours as a minimum.
3.4.1 Availability
[69] ISO 25010: Availability. Degree to which a system, product or component is
operational and accessible when required for use.
[70] Inherent Availability (Intrinsic) assumes ideal support (i.e., unlimited spares, no
delays, etc.); only design related Failures are considered.
[71] Mission Inherent Availability (Intrinsic) assumes ideal support (i.e., unlimited spares,
no delays, etc.); only design related CRITICAL Failures are considered
[CISS-191] The CISS shall have an Inherent Availability of at least 99.5%
[CISS-192] The CISS shall have a Mission Inherent Availability of at least 99.97%.

58
3.4.2 Fault tolerance

[72] Fault Tolerance is the property that enables a system to continue operating properly
in the event of the failure of some of its components. A fault-tolerant design enables
a system to continue its intended operation, possibly at a reduced level, rather than
failing completely when some part of the system fails.
[73] Graceful Degradation is the ability of a computer, machine, electronic system or
network to maintain limited functionality even when a portion of it has been destroyed
or rendered inoperative (either by a fault or deliberately).
[74] Based on the principle of gracefully degradation the following recovery time have been
defined:
Table 10 Recovery Time by Failure Criticality

Failure Type Recovery Time
Failure 4 hours
Critical Failure 10 minutes
[CISS-193] For 99% of the possible Failure in any of the CISS services, the system shall be
able to recover the service or switch to an alternative service, in no more than
the amount of Recovery Time defined in Table 10, without loss of data.
[CISS-194] The CISS shall support disaster-recovery solutions. Ideally this should be based
on services provided by NATO IT Modernization (ITM) infrastructure as a service
(IaaS) which will provide storage area network (SAN) replication and the
Microsoft SQL Server Always On availability groups feature.
3.4.2.1 Quality of Fault Tolerance
[75] ISO 25010: Degree to which a system, product or component operates as intended
despite the presence of hardware or software faults.
[CISS-195] For 99% of the possible Failure in any of the CISS services, the system shall be
able to recover the service or switch to an alternative service, in no more than
the amount of Recovery Time defined in Table 10, without loss of data.
3.4.3 Recoverability
[76] ISO 25010: Recoverability. Degree to which, in the Event of an interruption or a
Failure, a product or system can recover the data directly affected and re-establish
the desired state of the system.
[77] Following a Failure, a computer system will sometimes be down for a period of time,
the length of which is determined by its Recoverability.

59
[78] The NATO IT Modernization (ITM) will deliver infrastructure as a service (IaaS) will
guarantee a fault-free storage service with SAN replication and fail-over mechanisms
as well as backup services.
[CISS-196] In the event a service is interrupted because of a Failure, the CISS shall, (utilizing
ITM IaaS services) be able to restore the CISS state without loss of any data for
99.5% of the time without any failure in less than the recovery time defined in
Table 10.
[CISS-197] In the event of a user erroneously deleting CISS content, the CISS shall (utilizing
ITM IaaS backup services) be able to recover the deleted CISS content data for
99.5% of the time without any failure.
3.5 Security
[79] ISO 25010: Degree to which a product or system protects information and data so that
persons or other products or systems have the degree of data access appropriate to
their types and levels of authorization.
[80] ISO 27001 (Information Security): Information security is all about protecting and
preserving information. It’s all about protecting and preserving the confidentiality,
integrity, authenticity, availability, and reliability of information.
[81] Security, within the context of Information Technology (IT), is defined as the capability
of the software product to protect information and data so that unauthorised persons
or systems cannot read or modify them and such that authorised persons or systems
are not denied access to them.
[82] For purposes of this SRS, the following definitions are used:
(1) Confidentiality - ensuring that data is not disclosed to unauthorised parties,

usually through the use of encryption
(2) Integrity - ensuring that the data has not been altered in transit
(3) Non-repudiation - ensuring that neither the sender nor the receiver of a
message can deny having sent or received it
(4) Authenticity - verifying the identity of the user or consumer of a service or

application
(5) Accountability - ensuring that there is a permanent record of any

transaction, which can be retrieved and analysed outside the scope of a
transaction
[83] CISS will operate in the "System High" mode of operation (see [AC/35-D/2004-REV3]
for definitions of Security Modes of Operation). That is, all individuals with access to
the system are cleared to the highest classification of the information stored,

60
processed or transmitted within the system, but not all individuals with access to the
system have a common need to know for the information stored, processed or
transmitted within the system.
3.5.1 Confidentiality
[84] ISO 25010: Degree to which a product or system ensures that data are accessible
only to those authorized to have access.
[85] ISO 27001: Confidentiality is a characteristic that applies to information. To protect
and preserve the confidentiality of information means to ensure that it is not made
available or disclosed to unauthorized entities. In this context, entities include both
individuals and processes.
[CISS-198] The CISS shall implement confidentiality protection to all its data.
[CISS-199] The CISS shall not rely on the secrecy of identification information (i.e., IDs) for
protection.
[CISS-200] The CISS shall support Transport Layer Security (TLS) such that the CISS can
run all its communication over cryptographic protocols. Activation/ de-activation
of this security mechanism shall be configurable.
[CISS-201] The CISS shall have support for protection against sharing links (URLs) to
products in the CISS repository through mechanisms like a cookie, or session
token. Activation/ de-activation of this security mechanism shall be configurable.
[CISS-202] If the CISS makes use of temporary folders to serve up data to clients then the
CISS shall have support for protecting this data so that is will only be accessible
for the client requesting the data. Activation/ de-activation of this security
mechanism shall be configurable.
3.5.2 Integrity
[86] ISO 25010: Degree to which a system, product or component prevents unauthorized
access to, or modification of, computer programs or data.
[87] ISO 27001: To preserve the integrity of information means to protect the accuracy and
completeness of information and the methods that are used to process and manage
it.

61
[88] Improper validation of input from web requests may expose vulnerabilities that an
attacker can use to attack backend components (e.g., databases) through the web
application.
3.5.2.1 Forced browsing
[CISS-203] The CISS shall prevent 'forced browsing' past access control checks. For
purposes of this SRS, forced browsing is an attack where the aim is to enumerate
and access resources that are not referenced by the application, but still can be
accessible.
3.5.2.2 Path Traversal
[CISS-204] The CISS shall prevent "path traversal" past access control checks. For purposes
of this SRS, a path traversal attack is one that aims to unauthorised navigate
through the file system and access files and directories that are stored outside
Web root folder, particularly by manipulating variables that reference files with
"dot-dot-slash (../)" sequences. Path traversal attacks includes providing relative
path information as part of a request (e.g. ../../etc/passwd).
3.5.2.3 Cross-site scripting (XSS)
[89] Without proper protection, a web application can be used as a mechanism to transport
an attack to an end User's browser, causing a User's web browser to execute a
malicious script. A successful attack can disclose an end User's session token, attack
the local machine or spoof content to fool the User.
[CISS-205] The CISS shall perform validation of all headers, cookies, query strings, form
fields and hidden fields.
[CISS-206] The CISS shall ensure that the HTTP TRACE method is turned off on all web
servers to prevent compromise of cookie data.
[CISS-207] The CISS shall encode User-supplied output to prevent XSS. Best practice
suggests conversion of characters in the table below to the appropriate HTML
entity encoding.

62
Table 11 Character to HTML encoding

Character Encoding
> <
< >
& &
" "
' '
( (
) )
# #
% %
+ +
- -
3.5.2.4 Injection Flaws (SQL)
[90] Web applications pass certain parameters when they access external systems or the
local operating system. If an attacker can embed malicious commands in these
parameters, the external system may execute those commands on behalf of the web
application. Injecting valid SQL queries through fields (such as the username and
password fields) could allow the application to send the query through to the database,
allowing the attacker to query the database or authenticate using someone else's
credentials.
[CISS-208] The CISS shall constrain the input by validating it for type, length, format and
range.
[CISS-209] The CISS shall use type-safe SQL parameters. Input shall be treated as a literal
value, and CISS shall not treat it as executable code.
[CISS-210] The CISS shall use filter routines that sanitise the code, adding escape
characters that have special meaning to SQL.
3.5.2.5 Buffer Overflow
[91] Web application components that do not properly validate input can be 'crashed', and
in some cases used to take control of a process. These components can include CGI,
libraries, drivers and web application server services or components. An attacker may
take full control of the system being targeted or kill a process.

63
[CISS-211] The CISS shall ensure that application code which accepts input from Users via
HTTP requests provides appropriate size checking on all inputs.
3.5.2.6 Improper Error Handling
[92] Improper handling of error conditions which occur during normal operation can expose
vulnerabilities. If an attacker can cause errors to occur that the web application cannot
handle, they may gain detailed system information, deny service, cause security
mechanisms to fail or, in some cases, crash the server.
[CISS-212] The CISS shall use custom error pages to prevent server error messages from
being disclosed.
3.5.2.7 Unsecured Storage
[CISS-213] The CISS shall secure stored information (Data at rest) using appropriate
mechanisms.
[CISS-214] The CISS shall properly apply selected asymmetric encryption mechanisms (TLS
and SQL server security mechanisms) according to the standards approved by
NATO Communication and Information Agency and NATO INFOSEC to protect
information and credentials.
[CISS-215] The CISS shall securely configure and enforce file permissions. Unless
specifically authorised by the Purchaser, only files that are specifically intended
to be presented shall be marked as readable. Any Contractor provided proposal
shall be reviewed and approved by the Purchaser
[CISS-216] The CISS shall prevent compromise of information via client-side caching,
including best practice use of mechanisms such as HTTP headers and metatags.
[CISS-217] The CISS shall only expose the absolute minimum number of services and open
ports that are required for the CISS services to function correctly. This list of
required services and open ports shall be documented.

64
3.5.2.8 Unsecured Configuration Management
[93] A strong server configuration standard is critical to secure a web application. These
servers have many configuration options that affect security and are not generally
secure by default. For example, if a web application is not secured, an attacker may
be able via directory traversals to get to directories where authentication details are
stored.
[CISS-218] The CISS security mechanisms shall be properly configured according to best
practices. This includes:
(1) Disabling unused services on the servers
(2) Disabling default accounts, and accounts no longer used
(3) Correctly configuring permissions and accounts
(4) Correctly configuring logging and alerts

3.5.2.9 Free and Open Source Software (FOSS) Components
[CISS-219] Any components based on FOSS shall be verified for compliance to other non-
functional requirements, including security requirements.
3.5.3 Non-repudiation and Accountability

[94] ISO 25010: Non-repudiation. Degree to which actions or events can be proven to have
taken place, so that the events or actions cannot be repudiated later.
[95] ISO 25010: Accountability. Degree to which the actions of an entity can be traced
uniquely to the entity.
[CISS-220] The CISS shall use the details of the logged-in User to maintain the audit
traceability.
[CISS-222] The CISS shall log CISS administrator authentications (preferable to a log-file
that cannot be manually modified by the CISS administrator).
[CISS-223] The CISS shall log all activities/changes made by CISS administrator (preferable
to a log-file that cannot be manually modified by the CISS administrator).

65
[CISS-224] The CISS shall archive the audit log after period of time as configured by the
administrator.
3.5.4 Authenticity and Authorisation

[96] ISO 25010: Degree to which the identity of a subject or resource can be proved to be
the one claimed.
[97] Improper access control features can be exploited to access system configuration,
view sensitive files or use unauthorised functions.
[CISS-225] The CISS shall implement Identification and Authentication (I&A) for identifying
and authenticating Users.
[CISS-226] The CISS users shall be authenticated with appropriate security mechanisms
implementing or supporting Single Sign On (SSO) (see also next point).
[CISS-227] In case CISS is implemented using a solution based on the Windows operating
System, the CISS user accounts shall be declared in an Active Directory
inheriting NATO Group Policy Object [GPO] declared at the network domain level
for password policy (e.g. complexity, history, minimum age, maximum age,
length).
[CISS-228] The password shall not be echoed on the display when a user logs on to the
CISS user interface. An asterisk (*) or similar symbol shall be displayed for each
character when inputting secure passwords during log-on.
[CISS-229] The CISS user interface shall limit the number of failed access attempts in
accordance with NATO policy (e.g. 3 failed attempts.)
[CISS-230] Role-based access control shall be applied according to the following guidelines:
(1) Users are associated with user roles
(2) User Roles determine the functions available to the user.

66
[CISS-231] When a User is authenticated, the User shall be assigned with the Roles for that
User.
[CISS-232] The CISS shall support the following two user roles:
(1) System Administrator: This role shall have access to the user
functionalities specified under:
- 2.5.1 Server Configuration and Maintenance
- 2.5.2 Operational Monitoring
- 2.5.3 Operational Management
(2) Operational Support: This role shall only have access to the user
functionalities specified under:
- 2.5.2 Operational Monitoring
- 2.5.3 Operational Management
[CISS-233] The CISS shall ensure that privilege restrictions of authenticated Users are
properly enforced.
[CISS-234] The CISS shall allow only System Administrators to operate CISS System
Management Functionality and CISS System Maintenance Functionality with
appropriate operating system rights.
[CISS-235] Access controls shall ensure that users cannot access functions beyond those
needed to execute their role.
[CISS-236] The CISS shall limit the feedback of information during authentication to prevent
users gaining knowledge of the authentication process.
[CISS-237] The CISS shall ensure that account credential and session tokens are properly
protected.
[CISS-238] The CISS shall lock User accounts for which a configurable number of failed
authentication attempts have been made to await administrator action.

67
[CISS-239] Failed authentication attempts shall be logged.

[CISS-240] The CISS shall protect authentication details in storage. All authentication details
shall be stored in either hashed or encrypted form to protect them from exposure,
regardless of where they are stored.
[CISS-241] Authentication details shall not be hard-coded in any source code. Decryption
keys shall be strongly protected to prevent unauthorised access.
[CISS-242] The CISS shall protect User credentials in transit. CISS shall employ encryption
of the entire authentication transaction using TSL or similar technologies.
[CISS-243] The CISS shall protect session IDs. CISS shall protect the User's entire session
via TSL to ensure that the session ID (e.g., session cookie) cannot be read off
the network. Session IDs shall never be included in any URL or sent in the
referrer header to prevent caching by the browser. Session IDs shall be long,
complicated random numbers which cannot be easily guessed. Session IDs
chosen by a User shall not be accepted.
[CISS-244] The CISS shall not submit authentication and session data as part of a GET
request. Authentication pages shall be marked with all varieties of the no cache
tag to prevent use of the back button in the web browser and re-submission of
the credentials (best practice suggests use of the autocomplete=false flag to
prevent storing of credentials in autocomplete caches).
[CISS-245] The CISS Web Server functionality shall not act as a proxy. That means it shall
not be possible to use the CISS as a proxy to gain unauthorised access to
resources for which the CISS has access to.
3.6 Maintainability
[98] ISO 25010: This characteristic represents the degree of effectiveness and efficiency
with which a product or system can be modified to improve it, correct it or adapt it to
changes in environment, and in requirements.

68
[99] For the System, the MTTR to be considered is the mean time needed to restore the
system after a failure in the operative condition, excluding administrative and logistics
delay times
[100] The MaxTTR to be considered is the maximum time needed to restore the system in
the operative condition, excluding administrative and logistics delay times.
[101] Recovery Point Objective (RPO) is the threshold of how much data can be afforded
to be lost since the last backup. RPO is measured in hours of data loss.
Table 12 Maintainability by Failure Criticality

Failure Type MTTR MaxTTR
Critical Failure 2 hours 4 hours
Failure 3.5 hours 8 hours
[CISS-246] On the hypothesis of an operational time of 24/7/365 (24 hours per day, 7 days
a week, 365 days per year), the CISS shall provide a MTTR in accordance with
the definition given in Table 12.
[CISS-247] On the hypothesis of an operational time of 24/7/365 (24 hours per day, 7 days
a week, 365 days per year), the CISS shall provide a MaxTTR in accordance with
the definition given in Table 12 for each single maintenance action.
3.6.1 Modularity Requirements

[CISS-248] Any failure or outages of the CISS shall not cause any disruption or Error/ Fault
in the NATO CSD ISR Product Library (CIPL) or in the NATO CSD ISR Workflow
Services (CIWS).
[CISS-249] The video conditioning service providing DASH streaming to web clients (see
section 2.4) shall run as a completely separate service/ executable.
[CISS-250] The CISS main components shall have no dependencies on the video
conditioning service. I.e. it shall be possible to install and run the main CISS
component without having the video conditioning service installed.
[CISS-251] It shall be possible to install and execute the video conditioning service without
having the CISS main components installed. In this case the video conditioning

69
service shall use other sources of video streams and files when serving up DASH
streams.
[CISS-252] The delivery of the video conditioning service shall also include a User Interface
module for playing videos. This video playing module shall be implemented as a
separate module that can be reused for other Web-client applications.
[CISS-253] Use of any free and open-source software (FOSS) component shall not require
the release of custom developed CISS source code.
3.6.1.1 Quality of Modularity
[102] ISO 25010: Modularity. Degree to which a system or computer program is composed
of discrete components such that a change to one component has minimal impact on
other components.
[103] The CISS shall meet the modularity requirements as defined by [CISS-248] through
[CISS-252] for 99.5% of its Operational Time.
3.6.2 Analysability
[104] Fault Detection is the capability of a system to determine that a Fault exists using an
automatic process.
[105] Fault Isolation is the capability of a system to identify, using an automatic process,
which is the component or parameter of the system that is responsible for Fault.
[CISS-254] The CISS shall expose (make available for client applications) the WSDL files for
all implemented web services at a URL where the URL is ending with “?WSDL”.
3.6.2.1 Quality of Analysability
[106] ISO 25010: Analysability. Degree of effectiveness and efficiency with which it is
possible to assess the impact on a product or system of an intended change to one
or more of its parts, or to diagnose a product for deficiencies or causes of failures, or
to identify parts to be modified.
[CISS-255] The CISS shall be able to isolate 85% of the possible Faults/Errors which can
occur, providing an error diagnostics report which identifies the Error/Fault that
has occurred.

70
[CISS-256] The CISS shall be able to detect 95% of the possible Faults/Errors which can
occur, providing a generic diagnostics report which alerts the user that an
Error/Fault that has occurred.
3.6.3 Modifiability
[CISS-257] The CISS software shall include dedicated and automated test software (e.g. for
unit tests) that enables wide-coverage automated regression tests.
[CISS-258] The software modules that are implemented specifically for the CISS, where
source code is part of the deliverable, shall include dedicated and automated
tests (e.g. unit tests) within the delivered source code to support thorough
regression testing.
section 2.4) shall be implemented using the C# [ISO/IEC 23270:2006]
programming language.
[CISS-260] The CISS User Interface (UI) shall be implemented using the Angular framework
(using TypeScript).
[CISS-261] The CISS User Interface shall be based on UI components from the NCI Agency
CompassUI library of UI components implemented in Angular.
[CISS-263] There shall be no Background Intellectual Property Rights for any parts of the
video conditioning service.
[CISS-264] The source code for the video conditioning service shall be maintained
separately from the main CISS component, and shall compile/build separately
from the main CISS component.
[CISS-265] The source code for the video playing User Interface module shall be maintained
separately from the main CISS User Interface software, and it shall be possible
to lift out this video playing module and reuse it in other Web-client applications.

71
[CISS-266] The source code for any custom developed software that the Purchaser shall
obtain IPR for (video conditioning service (see section 2.4) and the user interface
application) shall exhibit a Technical Debt Ratio better than 7% when the SQALE
method (see [SQALE]) is used for the Debt Ratio estimation (e.g. using the tool
[NDepend] for C# code and [SonarQube] for JavaScript code).
[CISS-267] The rule set and the tool to be used for the Technical Debt Ratio estimation shall
be proposed by the Contractor and approved by the Purchaser.
[CISS-268] The source code for the custom developed software shall be documented with
in-line comments written in use "UK English".
[CISS-269] The source comments shall clarify the intent of the code and, at a minimum, shall
be provided for:
(1) Each class definition explaining the purpose of the class
(2) Each member function explaining what the function does, including
descriptions of input parameters and return values
(3) Each member variable explaining what the variable means (including unit
of measure where appropriate)
(4) Each type definition explaining what the type represents.

[CISS-270] Custom developed software shall be documented with comments which can be
extracted and formatted to augment technical documentation. For C# code the
comments shall be formatted according to the "XML Comments" format (i.e.,
beginning with three forward slashes "///" and using XML comment tags), see
also [XML Comments].
[CISS-271] Any component of the video conditioning service based on FOSS shall be
provided with the source code for the FOSS. The FOSS source code shall
correspond to the delivered component (i.e., same version), and the component
shall be capable of being built from the delivered source code.

72
3.6.3.1 Quality of Modifiability
[107] ISO 25010: Modifiability. Degree to which a product or system can be effectively and
efficiently modified without introducing defects or degrading existing product quality.
[CISS-272] For 99.9% of the times that the CISS software is modified for any reason, the
modification shall not introduce any error or fault in the existing software.
3.7 Portability
[108] ISO 25010: Portability. Degree of effectiveness and efficiency with which a system,
product or component can be transferred from one hardware, software or other
operational or usage environment to another.
3.7.1 Adaptability Requirements

[CISS-273] The CISS shall be capable of being installed and correctly run on multi-processor
and multi-core systems.
[CISS-274] The CISS shall be able to execute on a 64-bit operating system for x86-based
CPU architecture that is supported by ITM (MS Windows 7 or newer, or latest
version of Linux Red Hat).
[CISS-275] The CISS shall comply with a latest versions of the operating system available
and supported by the NATO virtualized servers.
[CISS-276] The CISS implementation should be targeted for MS Windows operating system
to optimize alignment with ITM.
[CISS-277] The CISS implementation should be using latest version of MS SQL Server that
is supported by ITM.
[CISS-278] The CISS shall be able to execute in latest official versions of MS Hyper-V Server
and latest official versions of VMWare ESXi.

73
[CISS-279] The CISS shall be compatible with a native file system used on NATO virtualized
servers. Any deviation shall be documented in detail with justification and be
subject to the Purchaser's evaluation and approval.
[CISS-280] The CISS shall be able to utilise virtualised data storage provided by the NATO
virtualised environment.
[CISS-281] The CISS shall not have any direct dependency to the physical parameters of
the storage environment (such as disk type, connection type, Storage Area
Network and protocol) provided by the NATO virtualised environment.
[CISS-282] The CISS shall not have any hardcoded URL, DNS or IP address settings.
[CISS-283] The CISS shall not have any hardcoded Universal Naming Convention (UNC) for
network resources, file path, drive letter, or similar storage location settings.
[CISS-284] The CISS shall run successfully independent of environment regional settings
(e.g. decimal symbol, date/time format).
[CISS-285] The CISS User Interfaces (as defined in section 2.5) shall be implemented as
web-based applications and shall be able to be run in any Web Browser present
on the Approved Fielded Product List (AFPL) at the time of deployment.
[CISS-286] The CISS shall support load-balancing solutions as provided by NATO IT

Modernization (ITM) infrastructure as a service (IaaS).
[CISS-287] If the CISS includes any Free and Open Source Software (FOSS) components,
then use of such components shall not limit the deployment or use of the CISS
in any way.
[CISS-288] The CISS shall support both HTTP and HTTPS.


74
[CISS-289.a] The CISS shall be interoperable with remotely deployed CISS where all
communication is routed through a SATCOM link that has large round-trip delay
times.
[CISS-289.b] The CISS shall support Efficient XML Interchange (EXI) for exchange of XML
data over SATCOM links.
3.7.2 Installability Requirements

[CISS-290] The CISS shall be delivered with an installation wizard enabling easy and correct
installation (e.g. implemented as a MS Windows Installer).
[CISS-291] The CISS installer should enable a fully automated and complete installation
without requiring any manual user configuration steps.
[CISS-292] The CISS shall when installing a CISS upgrade (newer version) automatically
maintain/reuse all configuration settings from the existing CISS installation.
[CISS-293] It shall be possible to perform the CISS installation from a remote location (e.g.
it shall be possible to perform installation for all physical location from the data
centre in Mons, Belgium).
[CISS-294] The CISS installer shall detect, during installation, if the user has insufficient
privileges required for installation (e.g. folder or registry access). The CISS
installer shall report the details of the access failure to the user before aborting
the installation.
[CISS-295] The CISS installer shall detect and appropriately address issues of disk space
and drives with "not enough" space prior to beginning installation.
[CISS-296] The CISS installer shall detect and appropriately address a previous installation
of the CISS. In this case, the installer shall notify the authorised user and prompt
if the user wants to upgrade (in case the existing installation is of an earlier
version), reinstall, repair or cancel, and proceed accordingly.

75
[CISS-297] It shall be possible to install a new version of the CISS and configure the newly
installed CISS to continue operating from an existing and populated CISS
database and existing collection of associated stream files (see also [CISS-300]).
section 2.4) shall have its own separate installer that is separate and independent
from the installer of the main CISS component.
3.7.2.1 Quality of Installability
[109] ISO 25010: Installability. Degree of effectiveness and efficiency with which a product
or system can be successfully installed and/or uninstalled in a specified environment.
[CISS-299] The 99.5% of the time the CISS software is installed and/or uninstalled the
system shall comply with the Installation requirement defined in [CISS-290]
through [CISS-298] without any failure.
3.7.3 Replaceability Requirements

[CISS-300] When replacing a previous version of the CISS, including the existing NATO CSD
(“Bridging Solution”) of baseline Bravo.1, the streams of the existing CSD stream
server shall be imported/ migrated into the new CISS instance and the library
identifier of the existing CSD stream server shall be adopted by the new CISS.
[CISS-301] For other CSD stream server and client applications on the network the
replacement of the existing CSD stream server with the new CISS shall be
seamless (i.e. apart from a drop in connectivity during the replacement the switch
shall not have any interoperability impact). This means all other CSD stream
server and client applications shall automatically switch over to using the new
CISS without needing any configuration changes.
[CISS-302] When replacing the existing NATO CSD (“Bridging Solution”) stream server of
baseline Bravo.1 the CISS shall maintain interoperability with the following
systems and applications:
(1) Current NATO CSD (“Bridging Solution”) stream server
(2) BICES CSD stream server
(3) Release Server


76
3.7.3.1 Quality of Replaceability
[110] ISO 25010: Replaceability. Degree to which a product can replace another specified
software product for the same purpose in the same environment.
[CISS-303] The 99.5% of the time the CISS software is installed and/or uninstalled the
system shall comply with the Replaceability requirement defined in [CISS-300]
through [CISS-302] without any failure.

12 - Ifb Co 14682 CSD Book II Part IV Sow Annex B Srs CSD Isr Streaming Services (Ciss)

Uploaded by

Copyright:

Available Formats

You might also like

12 - Ifb Co 14682 CSD Book II Part IV Sow Annex B Srs CSD Isr Streaming Services (Ciss)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12 - Ifb Co 14682 CSD Book II Part IV Sow Annex B Srs CSD Isr Streaming Services (Ciss)

Uploaded by

Copyright:

Available Formats

NATO CSD

SYSTEM REQUIREMENTS SPECIFICATION (SRS)

CISS NATO UNCLASSIFIED Book II, Part IV, SRS

3.5.3 Non-repudiation and Accountability ............................................................. 64

Figure 1 Envisioned technical solution for the CISS 4

Table 1 Applicable documents 2

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

[CISS-2] Requirements stating a capability to be "supported" shall be understood as

[CISS-3] Requirements stating a capability to be "implemented" shall be understood as a

[CISS-4] This SRS, in addition to explicitly specifying requirements, defines a number of

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

1.4 Applicable documents

Table 1 Applicable documents

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

1.5 Reference documents

Table 2 Reference documents

1.6 Background – Envisioned Capability

(4) Re-stream recorded streaming data to client applications upon requests

(5) Disseminate and synchronize the stream catalogues across a network of

(6) Is interoperable with STANAG 4559 ed4 / Bravo .1 compliant national

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

that this last function is not defined in [4559-Ed4/AEDP-18], and the

(1) A core streaming data system.

(2) A resiliency/ redundancy (and even load balancing) mechanism enabling

Figure 1 Envisioned technical solution for the CISS

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

(1) CISS General Requirements (§ 2.1)

(2) Managing Stream Content:

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

(v) Joining / Catch-up Requirements (§ 2.2.6)

(3) Replaying and Relaying Requirements (§ 2.3)

(4) Video Conditioning for Web Browser (§ 2.4)

(5) User Interface Requirements (§ 2.5)

(6) Application Performance Monitoring (APM) Requirements (§ 2.6)

2.1 CISS General Requirements

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Table 3 Applicable XSDs and WSDLs for the CISS

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

2.1.1 CSD/4559 Bridge Interface not required

2.1.2 CSD Stream Notification Interface not required

2.1.3 Data Model Requirements

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Entity Attribute Sortable Queryable Mandatory From Remark

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Entity Attribute Sortable Queryable Mandatory From Remark

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Entity Attribute Sortable Queryable Mandatory From Remark

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

Entity Attribute Sortable Queryable Mandatory From Remark

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

(1) <extending its metadata model>

(2) <accepting catalogue entries not covered by its metadata model>

2.1.4 Query and Retrieval Requirements

Book II, Part IV, SRS NATO UNCLASSIFIED CISS

[CISS-15] In addition to the getCapabilities mandatory capabilities as defined in [4559-

Book II, Part IV, SRS NATO UNCLASSIFIED CISS