Väljaminev kiri

Appendix N – Technical Description (eCall / NG eCall

router)

1. Requirements/standards under EU law, and the

current situation

1.1 eCall (in‑band, CS - Circuit Switched)

EU law:

26.11.2012 European Commission Delegated Regulation No 305/2013

29.04.2015 Regulation of the European Parliament and of the Council No 2015/758

15.05.2014 Decision of the European Parliament and of the Council No 585/2014/EU

12.09.2016 European Commission Delegated Regulation No 2017/79

Standards:

EN 16072:2015 „Intelligent transport systems - eSafety - Pan-European eCall operating

requirements“;

EN 16062:2015 „Intelligent transport systems - eSafety - eCall high level application

requirements“;

EN 16454:2015 „Intelligent transport systems - eSafety - eCall end to end conformance testing “;

EN 15722:2015 „Intelligent transport systems - eSafety - eCall minimum set of data “.

In 2017, SMIT procured a so-called “eCall (In-Band)” hardware solution that met the above

requirements from the bidder Datus AG through a public procurement (eCall-Decoder – see

https://www.datus.com/notruf-systeme). The solution was integrated with the Mitel phone

system/”old” call solution used by the Emergency Support Center’s 112 service and with the SOS

information system. It was taken into use in 2018. By now, the procured hardware solution has been

working for 8 years and needs to be updated or replaced.

1.2 NG eCall (IMS/SIP, PS – Packet Switched)

EU law:

06.02.2024 European Commission Delegated Regulation No 2024/1084

14.02.2024 European Commission Delegated Regulation No 2024/1180

23.07.2025 European Commission Delegated Regulation No 2025/1871

Standards:

EN 16072:2025 „Intelligent transport systems - eSafety - Pan-European eCall operating

requirements“;

EN 16062:2023 „Intelligent transport systems - eSafety - eCall high level application requirements

using GSM/UMTS circuit switched networks “

EN 17184:2024 „Intelligent transport systems - eSafety - eCall high level application protocols

using IP Multimedia Subsystem (IMS) over packet switched networks“;

EN 16454:2023 „Intelligent transport systems - eSafety - eCall end to end conformance testing “;

EN 17240:2024 „Intelligent transport systems - eSafety - eCall end to end conformance testing

for IP Multimedia Subsystem (IMS) packet switched based systems“

EN 15722:2020 „Intelligent transport systems - eSafety - eCall minimum set of data “.

At the end of 2025, SMIT procured hardware for testing both eCall and NG eCall calls (provider

OECON Products & Services GmbH – manufacturer Kontron AG - see

https://www.kontron.com/en/products/ngecall-test-and-validation/p188189 ), a so-called “analogue”

for the IVS system. Working with the communication operators, the first tests were carried out for

moving the connections used by the Emergency Response Center voice communication over to IMS

connections.

The plan for 2026 is to move all the connections presently in use by the operators and the Emergency

Response Center 112 voice communication over to IMS connections and to procure an eCall

software solution that is in compliance with the aforementioned standards (the present procurement)

and supports both eCall (in-band, CS) and NG eCall (IMS/SIP, PS). In the end of 2026, the plan is

to integrate the new eCall/NG eCall solution with the 112 Call Solution of the Emergency Response

Center in development by SMIT and with the existing SOS information system. As soon as possible,

the whole solution should be in use.

Estonian communication operators will not support (NG) eCall calls in SIP 4G/5G SIP calls before

the implementation of NG eCall solution. The IVS systems of new vehicles that follow the new NG

eCall standards must also be able to execute eCall calls in 2G networks (3G network is closed in

Estonia) which has been supported by the operators and the Emergency Response Center since

2018.

2. Description of necessity Considering the needs of the Emergency Response Center, SMIT wishes to replace the old eCall

Decoder solution (in-band, CS), dependent on separate special hardware, with a new software

solution that supports both eCall (in-band, CS) and NG eCall (IMS/SIP, PS) calls.

NB – the eCall (in-band) call received by SMIT from the mobile network operator is always

done so as a SIP call, regardless that the call between the IVS and the operator is in 2G (the

connection between the operator and SMIT is IMS and SIP based).

The procured solution must conform, in addition to what is described in the current and upcoming

chapters, to the standards described in chapter 1 in so much as these regulate the receiving of eCall

(in-band, CS) and NG eCall (IMS/SIP, PS) calls at the Emergency Response Center.

2.1 Abbreviations

112 Workstation - (PSAP Workstation). The computer workstation of the rescue coordinator of the

Emergency Response Center, equipped with the 112 Call Solution and the SOS information

system.

112 Call Solution – the new 112 Call Solution of the Emergency Response Center in development

by SMIT. Includes the Location Information System (LIS).

112 Phone System – (112 IP PBX) the new phone system at the Emergency Response Center

(Asterisk IP PBX).

API – Application Programming Interface. A collection of rules and protocols that allow different

software components to communicate and share data with each other.

CS – Circuit Switched communication technology. The traditional telecommunications method (e.g.,

2G) where a dedicated communications channel is created for the duration of the call. Used in

eCall (in-band) calls.

DC – Data Center.

IMS – IP Multimedia Subsystem. An architectural framework that allows delivering IP-based

multimedia services (e.g., VoLTE and NG eCall) within mobile networks.

IP PBX – Internet Protocol Private Branch Exchange. A software-based communication server (e.g.,

Asterisk) that handles voice communications over IP network using SIP protocol.

IVS – In-Vehicle System. A car on-board device that can detect vehicular accidents, create an

emergency call and transmit MSD.

LIS – Location Information System. A solution for handling the location information of the initiator of

the emergency notification (call, eCall, SMS) and for transmitting it to the management system of

the Emergency Response Center.

MSD – Minimum Set of Data. Standardized (see standard EN 15722:2020) digital data block

(location, VIN etc.) that is sent from a vehicle to the Emergency Response Center during an

eCall/NG eCall call.

MNO – Mobile Network Operator.

MQ – Message Queue server. Enables inter-system asynchronous data communication.

PS – Packet Switched communication technology. A telecommunications method where data is

transmitted as packets over an IP network (4G/5G). NG eCall works over a PS-network.

PSAP – Public Safety Answering Point. Emergency Response Center.

SBC – Session Border Controller. A network device that secures and handles SIP-based traffic and

distributes calls between servers.

SIP – Session Initiation Protocol. Standard protocol for handling multimedia-sessions (sound, video,

data) within IP-networks. Used in NG eCall calls.

SOS – the existing information system of the Emergency Response Center used for handling

emergency events and for managing and dispatching resources to the location of the emergency.

VM – Virtual Machine (server).

2.2 Functionality

1) The solution must support eCall (in-band, CS) calls so that:

a. In case of an incoming eCall call:

i. Answers the incoming eCall (in-band) call;

ii. Decodes the MSD transmitted in the audio stream (in-band); depending on whether the

CRC matches or doesn’t match, sends or doesn’t send an ACK in audio;

iii. After MSD decoding, forwards the call to 112 Phone System (Asterisk IP PBX);

iv. Transmits the decoded MSD to the 112 Call Solution via its interface*;

v. Provides a service through its API to initiate a new MSD query during an active incoming

eCall (in-band) call; it returns the result (MSD) to the query via the API or outputs it

asynchronously to the 112 Call Solution via the interface*.

b. In case of a callback (outgoing) call initiated by the Emergency Response Center to the IVS

with eCall (in-band, CS) capability:

i. Enables the 112 Phone System to initiate a callback (outgoing) call to the IVS device with

eCall (in-band) capability;

ii. If possible, automatically initiates an MSD query (in-band) at the start of the callback

(outgoing) call and transmits the result to the 112 Call Solution via its interface*;

iii. Provides a service through its API to initiate a new MSD query during an active callback

(outgoing) call; it returns the result (MSD) to the query via the API or outputs it

asynchronously to the 112 Call Solution via the interface*.

2) The solution must support NG eCall (IMS/SIP, PS) calls so that:

a. In case of an incoming NG eCall call:

i. Answers the incoming NG eCall call (INVITE message reception, including standard

validation of its content);

ii. Reads the MSD field from the body of the SIP INVITE message; when responding to the

INVITE message with a 200 OK, the data representing the "result" of reading the MSD

field is included in the body of the message, in accordance with the standard (adds/fills in

„Content-Type: application/EmergencyCallData.Control+xml“, including reporting a

"Success" or "Error" status in the <MSD_Status> field);

iii. After reading the MSD, forwards the call to 112 Phone System;

iv. Transmits the MSD received from the INVITE body in SIP to the 112 Call Solution via its

interface*;

v. Provides a service through its API to initiate a new MSD query (includes sending an INFO

message with an appropriate body and processing the response) during an active

incoming NG eCall (in-SIP) call, or the ability to configure a periodic query during the

active incoming call (e.g., after every 30 or 60 sec). It returns the result (MSD) to the

query via the API or outputs it asynchronously to the 112 Call Solution via the interface*.

b. In case of callback (outgoing) call by the Emergency Response Center to the IVS:

i. Enables the 112 Phone System to initiate a callback (outgoing) call to the IVS device with

NG eCall (IMS/SIP) capability;

ii. If possible, automatically initiates an MSD query (in-SIP) at the start of the callback

(outgoing) call and transmits the result to the 112 Call Solution via its interface*;

iii. Provides a service through its API to initiate a new MSD query (in-SIP) during an active

callback (outgoing) call, or the ability to configure a periodic query during the active

outgoing call (e.g., after every 30 or 60 sec). It returns the result (MSD) to the query via

the API or outputs it asynchronously to the 112 Call Solution via the interface*.

* - The integration of the 112 Call Solution with the provider’s interface is developed and implemented

by SMIT. This includes creating a REST service for receiving MSD that complies with the

specifications provided by the provider or establishing and maintaining a connection with a message

queue (MQ) and consuming MSD messages from it.

3)Call audio encoding

a) The minimum supported codec is G.711 for both eCall ang NGeCall.

2.3 Solution type

Software solution.

2.4 Installation (including the operating system)

The solution must support Linux-based installation (container or virtual machine). For a virtual

machine, the operating system must be a Linux-based distribution that supports RPM-based

package management.

the Purchaser gives Linux-based Docker container solution 20p and Linux-based installation on a

virtual machine gives 0p (for more details, please see Appendix 4).

2.5 Database requirements

If a database is used to store the solution configuration or the unsent MSD data, it must be open-

source software (preferably PostgreSQL or MariaDB).

The database must be separated from the application (usable as a standalone database service),

and its connection parameters must be configurable. The Provider’s delivery must include the

creation of the database structure and the initial population with default values, if necessary. To this

end, the solution must either support automatic structure management (database migrations upon

application launch), or the Provider must provide the necessary SQL-scripts for creating and

configuring the structure.

2.6 MSD data transmission via interface and API

The solution's interface must forward the MSD data obtained from the eCall or NG eCall call upon

its arrival to SMIT's call solution in a structured format (preferably in JSON or XML formatting). As

the transmission method, the solution must support either a REST call towards the API of SMIT's

call solution (POST/PUT) or the use of a message broker (preferably RabbitMQ).

Additionally, the delivered solution must provide its own API interface for a repeated MSD query

during an active (incoming or callback/outgoing) eCall call from both in-band- and SIP-capable IVS

device.

The Provider will provide detailed service descriptions (e.g., OpenAPI/Swagger) for all the interfaces

(both for data transmission and for repeat query). The descriptions must enable SMIT to

independently develop the capability to receive data and make queries, deploy these in the

necessary environments, and configure the parameters required for the interface to function.

If the MSD data transmitted or returned via the API is not identical to the "original" eCall MSD

standard (1:1), the Provider must also provide a detailed description of the returned data fields and

their structure.

2.7 Availability and data integrity

The implementation of the solution's interfaces and APIs must take into account the heightened

requirements for availability and mitigate the risk of data loss. If the transmission of MSD data from

an eCall call to a REST interface or message queue fails, the system must ensure that the data is

resent, if possible (retry logic).

2.8 Monitoring and status control

The solution must log its operations at a level that enables its continued operating, including error

analysis and rapid response. It must be possible to forward logs to the central log server by the agent

installed by SMIT.

The solution must support real-time monitoring (provide services for monitoring its functionality) in

order to ensure the detection of its operating status by an external monitoring system.

2.9 Installation environment and high availability

The solution must support high availability (HA) architecture both in the production environment

(Live) and the test and training environments.

Call distribution and failover: The forward layer of the system is a network element (SBC) that

handles the routing of eCall/NG eCall calls and the load distribution among the servicing servers.

The solution must be installable and ready for operation in Primary-Secondary mode. SBC routes

the call traffic to the first (primary) server. If the primary server is unavailable (for example if the

eCall/NG eCall server doesn't respond to SIP OPTION queries), SBC will automatically reroute the

call traffic over to the second (secondary) server.

Environmental similarity: The architecture of the test and training environments must be identical to

that of the production environment, to enable the installation, management, stress testing, and the

verification of the failover mechanisms under the same conditions as in the Live-environment.

2.10 Data volumes and performance requirements

Production environment (LIVE):

Session count: The solution must be capable of handling at least 10 simultaneous eCall/NG

eCall calls/sessions without any delays in data processing.

Capacity: The system must be able to process up to 670 eCall calls per day.

Note: The figures are projected with a 10-to-30-fold reserve compared to the statistics for 2024

(ca 800 calls per year). The calculation takes into account the steady increase of vehicles with

eCall capabilities in the car fleet (due to the addition of new vehicles and the replacement of

old ones), which increases the load on the system even if the average age or the total number

of vehicles in the fleet remains the same.

Test and training environment (TEST):

Session count: Test environment must be capable of handling up to 2 simultaneous eCall/NG

eCall calls (depending on the number of test devices and vehicles used)

Resource use:

The solution must be optimal and should not place an unreasonable load on system resources

(CPU, RAM, disk, etc.).

2.11 Installation and architecture

The diagram does not show:

 Using a database if necessary (see part "2.5 Database requirements");

 Using MQ instead of REST when sending MSD (MQ is not visualized as a separate component

– it’s part of the 112 Call Solution);

 Callback by the Emergency Response Center to the IVS device (see „2.2 Functionality“ section

1.b.i and 2.b.i);

 Querying a new MSD during an eCall call from an IVS device or from the Emergency Response

Center to an IVS device - eCall / NG eCall router provides a service to 112 Call Solution for

that (see „2.2 Functionality“ section 1.a.v, 1.b.iii, 2.a.v and 2.b.iii).

The installation and architecture are identical in production, test, and training environments.

3. Product delivery

3.1. Delivery content and components

The Provider must deliver a fully assembled and ready-to-install software package. The delivery

includes:

 Software delivery: The delivery must contain all the necessary components according to the

selected architecture (e.g., for Docker-container, the container file and installation files; for

installation on a VM, the installation packages and all necessary dependencies).

 Database components: If the software installation requires the creation of a database, the

delivery package must include the necessary scripts for creating the structure of an empty

database and/or populating it with default data.

 Documentation: Software installation and management guide (in English or Estonian).

 Interface description (API documentation, etc.) with the level of detail required for development

(in English or Estonian).

3.2. Delivery deadline

The procurement object must be delivered in full, and the delivery must be completed no later than

30 (thirty) calendar days after the conclusion of the procurement contract.

3.3. Installation and technical support

The software is installed in the test and production environment by the Purchaser (SMIT).

The Provider is required to provide free technical support for a period of 3 months following the

delivery of the procurement object to resolve any issues arising during installation or integration that

result from the product itself or from inaccuracies or omissions in the installation and maintenance

manual.

If support provided via email or phone is insufficient for resolving the issue, the Provider must ensure

operational real-time (online) video conference support at a time that is convenient for both parties

and mutually agreed upon.

4. Terms of use for the product and requirements for

the support/maintenance of the product

4.1 Terms of use for the product

Upon the delivery of the procurement object, the Provider shall grant the Purchaser (SMIT) and the

end user (Emergency Response Center) a perpetual, unrestricted and royalty-free right (license) to

install and use the product in the manner and to the extent specified in the technical specifications.

The ordering of product support and maintenance must be optional for the Purchaser starting from

the third (3) year.

4.2 Support, maintenance and warranty

The Provider shall provide product support and maintenance services at minimum under the

following conditions:

During the product support and maintenance period, all product updates must be made available to

the Purchaser, including:

 Standards updates: Bringing the product into compliance with evolving NG eCall standards

and technical requirements.

 Base software compatibility: Changes resulting from the updates to the base software required

for the functioning of the product (e.g., operating system versions, database engines, container

platforms).

 Security patches: Fixing critical security vulnerabilities and releasing security patches shall be

determined on a case-by-case basis by agreement between the Purchaser and the Provider,

but in no event later than within 90 days following the identification of the vulnerability, whether

identified by the Provider themself or by a publicly disclosed manufacturer, CERT, or other

reputable source.

Issue resolution and response times:

Issues are reported on weekdays (M – F, 09:00–17:00 CET+1).

The Provider must begin responding no later than two (2) weekdays after receiving the report.

The timeframe for resolving the issue will be agreed upon based on the severity of the issue, but

the Provider must do everything in their power to provide an initial solution or a temporary

solution/workaround at the earliest opportunity.

Product support includes technical consultation via email or phone and, when necessary (if the issue

cannot be resolved remotely), real-time ONLINE support via video conference.

The Provider guarantees that the product meets the requirements set out in the technical description

(warranty). During the warranty period (1 year from the delivery of the procurement object), the

Provider is obliged to eliminate, free of charge, any software defects in the product that prevent its

intended use.

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

19.06.2026 nr 3-13/138

Avatud hankemenetluse "eCall/NG eCall ruuteri tarkvara ja tootetoe soetamine" (310645) alusdokumentide muutmine

Peadirektori 01.07.2025. a käskkirja nr 1-1/105 „Siseministeeriumi infotehnoloogia- ja

arenduskeskuse riigihangete kord“ punkti 3.1.11 alusel:

1. Muudan riigihanke alusdokumenti ,,Lisa 2 – Tehniline kirjeldus’’ ja lisan punkti 2.2 alapunkti 3 (lisatud).

2. Teen muudetud dokumendid avalikult kättesaadavaks riigihangete registri vahendusel.

Lugupidamisega

(allkirjastatud digitaalselt)

Paavo Kirsi hankejuht

Paavo Kirsi, [email protected]

mLisa N - Tehniline kirjeldus (eCall / NG eCall ruuter)

1. EL õigusruumist nõuded/standardid ja hetkeseis

1.1 eCall (in‑band, CS - Circuit Switched)

EL õigusruum:

26.11.2012 Euroopa Komisjoni delegeeritud määrus nr 305/2013

29.04.2015 Euroopa Parlament ja Euroopa Liidu Nõukogu määrus nr 2015/758

15.05.2014 Euroopa Parlament ja Euroopa Liidu Nõukogu otsus nr 585/2014/EL

12.09.2016 Euroopa Komisjon delegeeritud määrus nr 2017/79

Standardid:

EN 16072:2015 „Intelligentsed transpordisüsteemid – eSafety – üleeuroopaline eCall-süsteem –

käitamisnõuded“;

EN 16062:2015 „Intelligentsed transpordisüsteemid – eSafety – eCall-süsteemi kõrgetasemeliste

rakenduste nõuded“;

EN 16454:2015 „Intelligentsed transpordisüsteemid – eSafety – eCall-süsteemi vastavuse

tervikkatsetus“;

EN 15722:2015 „Intelligentsed transpordisüsteemid – eSafety – automaatse hädaabikõne kaudu

edastatav miinimumteave“.

2017 hankis SMIT riigihanke käigus ülaltoodud nõuetele vastava nö „eCall (In-Band)“ riistvaralise

lahenduse pakkujalt Datus AG (eCall-Decoder – vt https://www.datus.com/notruf-systeme).

Lahendus integreeriti Häirekeskuse 112 teenuses kasutatava Mitel telefonijaama/“vana“

kõnelahendusega ning SOS menetluse infosüsteemiga ning võeti 2018 aastal kasutusele. Soetatud

riistvaraline lahendus on tänaseks töötanud 8 aastat ning vajab uuendamist/väljavahetamist.

1.2 NG eCall (IMS/SIP, PS – Packet Switched)

EL õigusruum:

06.02.2024 Euroopa Komisjon delegeeritud määrus nr 2024/1084

14.02.2024 Euroopa Komisjon delegeeritud määrus nr 2024/1180

23.07.2025 Euroopa Komisjon delegeeritud määrus nr 2025/1871

Standardid:

EN 16072:2025 „Intelligentsed transpordisüsteemid – eSafety – üleeuroopaline eCall-süsteem –

käitamisnõuded“;

EN 16062:2023 „Intelligentsed transpordisüsteemid – eSafety – eCall-süsteemi kõrgetasemeliste

rakenduste nõuded“

EN 17184:2024 „Intelligentsed transpordisüsteemid – eSafety – nõuded eCall-süsteemi

kõrgetasemelistele rakendustele, milles kasutatakse IP multimeediumi alamsüsteemi (IMS)

pakettkommuteeritud võrkudes“;

EN 16454:2023 „Intelligentsed transpordisüsteemid – eSafety – eCall-süsteemi kui terviku

vastavuskatsed“;

EN 17240:2024 „Intelligentsed transpordisüsteemid – eSafety – eCall-süsteemi kui terviku

vastavuskatsed IP multimeediumi alamsüsteemi (IMS) pakettkommuteeritud süsteemidele“

EN 15722:2020 „Intelligentsed transpordisüsteemid – eSafety – automaatse hädaabikõne kaudu

edastatavad miinimumandmed“.

2025 lõpus hankis SMIT nii eCall kui NG eCall kõnesid võimaldava test riistvara (pakkuja OECON

Products & Services GmbH – tootja Kontron AG - vt https://www.kontron.com/en/products/ngecall-

test-and-validation/p188189) st nö IVS süsteemi „analoogi“ ja teostas koostöös sideoperaatoritega

Häirekeskuse kõnesides kasutatavate ühenduste IMS ühendustele ülekolimise esimesed testid.

2026 on kavas kõik operaatorite ja Häirekeskuse 112 kõnesides kasutatavad ühendused reaalselt

IMS ühendustele üle kolida ning hankida ülaltoodud standarditele vastav eCall tarkvaraline eCall

lahendus (käesolev hange), mis toetab nii eCall-i (in‑band, CS) kui NG eCall-i (IMS/SIP, PS). 2026

teisel poolel on kavas uus eCall/NG eCall lahendus viimase API kaudu integreerida SMIT poolt

arendatava Häirekeskuse uue 112 kõnelahenduse ja olemasoleva SOS menetluse infosüsteemiga

ning võtta kasutusele terviklahendus.

Kuni NG eCall lahenduse kasutuselevõtuni ei toeta Eesti sideoperaatorid SIP 4G/5G SIP kõnedes

nö (NG) eCall kõnesid ning uut NG eCall standardit toetavate sõidukite IVS süsteemid peavad

hädaolukorras vastavalt standardile teostama eCall kõne 2G võrgus (3G võrk on Eestis suletud),

mida operaatorid ja Häirekeskus alates 2018 toetavad.

2. Vajaduse kirjeldus Pidades silmas Häirekeskuse vajadusi on SMIT-il soov asendada vana eraldi spetsiaalsel riistvaral

põhinev eCall Decoder lahendus (in‑band, CS) uue tarkvaralise lahendusega, mis toetab nii eCall

(in‑band, CS) kui NG eCall (IMS/SIP, PS) kõnesid.

NB – eCall (in-band) kõne laekub mobiilside operaatorilt SMIT-i alati SIP kõnena, sõltumatult

sellest et IVS ja operaatori vahel on kõne 2G-s (operaatori ja SMIT vaheline side on IMS ja SIP

põhine).

Hangitav lahendus peab lisaks käesolevas ja järgnevates peatükkides kirjeldatule vastama ka

peatükis 1 toodud standarditele niivõrd, kuivõrd need reguleerivad eCall (in‑band, CS) ja NG eCall

(IMS/SIP, PS) kõnede vastuvõtmist häirekeskuses.

2.1 Lühendid

112 Töökoht - (PSAP Workstation) . Häirekeskuse päästekorraldaja arvutitöökoht, mis on

varustatud 112 kõnelahenduse ja SOS menetluse infosüsteemiga.

112 Kõnelahendus – (112 Call Solution) SMIT poolt arendatav Häirekeskuse uus 112 kõnelahendus

sh asukohainfo süsteem (LIS).

112 Telefonijaam – (112 IP PBX) Häirekeskuses uus telefonijaam (Asteriski IP PBX).

API – (Application Programming Interface) rakendusliides. Reeglite ja protokollide kogum, mis

võimaldab erinevatel tarkvarakomponentidel omavahel suhelda ja andmeid vahetada.

CS – (Circuit Switched) kanalimodulatsiooniga (kanali-lülitusega) sidetehnoloogia. Traditsiooniline

kõnesidemeetod (nt 2G), kus kõne ajaks luuakse püsiühendus. Kasutatakse eCall (in-band)

kõnedes.

DC – (Data Center) andmekeskus.

IMS – (IP Multimedia Subsystem) IP-multimeedia alamsüsteem. Arhitektuurne raamistik, mis

võimaldab pakkuda IP-põhiseid multimeediateenuseid (nt VoLTE ja NG eCall)

mobiilsidevõrkudes.

IP PBX – (Internet Protocol Private Branch Exchange) IP-põhine keskjaam. Tarkvaraline sideserver

(nt Asterisk), mis haldab kõnesidet üle IP-võrgu, kasutades SIP-protokolli.

IVS – (In-Vehicle System) sõidukipõhine süsteem. Auto pardaseade, mis tuvastab õnnetuse, loob

hädaabikõne ja edastab MSD-andmed.

LIS – (Location Information System) asukohainfo süsteem. Hädaabiteadete (kõned, eCall, SMS)

algatajate asukohainfo haldamise ning Häirekeskuse menetlussüsteemile vahendamise

lahendus.

MSD – (Minimum Set of Data) vähim andmekogum. Standardiseeritud (vt standard EN 15722:2020)

digitaalne andmeplokk (asukoht, VIN jm), mis saadetakse sõidukist Häirekeskusele eCall/NG

eCall kõne ajal.

MNO – (Mobile Network Operator) mobiilsideoperaator.

MQ – (Message Queue) sõnumi(järjekorra) server. Süsteemidevahelist asünkroonset

andmevahetust võimaldav lahendus.

PS – (Packet Switched) pakettkommunikatsiooniga sidetehnoloogia. Meetod, kus andmed

edastatakse pakettidena üle IP-võrgu (4G/5G). NG eCall toimib PS-võrgus.

PSAP – (Public Safety Answering Point) hädaabiteadete vahendamise punkt. Häirekeskus.

SBC – (Session Border Controller) seansipiirihaldur. Võrguseade, mis turvab ja haldab SIP-põhist

liiklust ning teostab kõnejaotust serverite vahel.

SIP – (Session Initiation Protocol) seansialustusprotokoll. Standardne protokoll multimeedia-

sessioonide (heli, video, andmed) haldamiseks IP-võrkudes. Kasutatakse NG eCall kõnedes.

SOS – olemasolev Häirekeskuse hädaabiteadete menetlemise, ressursside haldamiseks ja

sündmuskohale suunamiseks infosüsteem.

VM – (Virtual Machine) virtuaalmasin (server).

2.2 Funktsionaalsus

1) Lahendus peab toetama eCall (in‑band, CS) kõnesid st

a. Siseneva eCall kõne korral:

i. Võtab siseneva eCall (in‑band) kõne vastu;

ii. Dekodeerib selle audios (in-band) esitatava MSD sh CRC sobivusel/mitte-sobivusel

saadab/ei saada audios ACK-d;

iii. Sildab peale MSD dekodeerimist kõne edasi 112 Telefonijaamale (Asteriski IP PBX-ile);

iv. Edastab dekodeeritud MSD oma liidese kaudu* 112 Kõnelahendusele;

v. Pakub oma API kaudu teenust algatada aktiivse siseneva eCall (in‑band) kõne ajal uue

MSD küsimist sh tagastab tulemuse (MSD) API kaudu päringule või väljastab selle liidese

kaudu* 112 Kõnelahendusele a-sünkroonselt.

b. Häirekeskusest eCall (in‑band, CS) võimekusega IVS-ile algatatud tagasi-helistamise

(väljuva) kõne korral:

i. Võimaldab 112 Telefonijaamale võimalust tema kaudu algatada eCall (in-band)

võimekusega IVS seadmele nö tagasi-helistamise (väljuvat) kõne;

ii. Algatab võimalusel tagasi-helistamise (väljuva) kõne alguses automaatselt MSD küsimise

(in-band) sh edastab oma liidese kaudu* selle tulemuse 112 Kõnelahendusele;

iii. Pakub oma API kaudu teenust algatada aktiivse tagasi-helistamise (väljuva) kõne ajal uue

MSD küsimist (in-band) sh tagastab tulemuse (MSD) API kaudu päringule või väljastab

selle liidese kaudu* 112 Kõnelahendusele a-sünkroonselt.

2) Lahendus peab toetama NG eCall (IMS/SIP, PS) kõnesid st

a. Siseneva NG eCall kõne korral:

i. Võtab siseneva NG eCall kõne vastu (INVITE sõnumi vastuvõtt sh selle sisu standardne

kontroll);

ii. Loeb SIP INVITE sõnumi kehast välja MSD osa sh INVITE sõnumile 200 OK vastates

väljastab standardi kohaselt vastuse kehas MSD väljalugemise „tulemuse“ andmed

(lisab/täidab osa „Content-Type: application/EmergencyCallData.Control+xml“ sh osas

<MSD_Status> kajastab „success“ või „error“ staatust);

iii. Sildab peale MSD lugemist kõne edasi 112 Telefonijaamale;

iv. Edastab SIP-ist INVITE kehast saadud MSD oma liidese kaudu* 112 Kõnelahendusele;

v. Pakub API kaudu teenust algatada aktiivse siseneva NG eCall (in-SIP) kõne ajal uue MSD

küsimist (vastava kehaga sõnumi INFO saatmist sh vastuse töötlust) või võimalust

konfigureerida selle perioodiline küsimine aktiivse siseneva kõne käigus (n: iga 30 või 60

sek järel) sh tagastab tulemuse (MSD) API kaudu päringule või väljastab selle liidese

kaudu* 112 Kõnelahendusele a-sünkroonselt.

b. Häirekeskusest IVS-ile algatatud tagasi-helistamise (väljuva) kõne korral:

i. Võimaldab 112 Telefonijaamale võimalust tema kaudu algatada NG eCall (IMS/SIP)

võimekusega IVS seadmele nö tagasi-helistamise (väljuvat) kõne;

ii. Algatab võimalusel tagasi-helistamise (väljuva) kõne alguses automaatselt MSD küsimise

(in SIP) sh edastab oma liidese kaudu* selle tulemuse 112 Kõnelahendusele;

iii. Pakub API kaudu teenust algatada aktiivses tagasi-helistamise (väljuva) kõne ajal uue

MSD küsimist (in-SIP) või võimalust konfigureerida selle perioodiline küsimine aktiivse

väljuva kõne käigus (n: iga 30 või 60 sek järel) sh tagastab tulemuse (MSD) API kaudu

päringule või väljastab selle liidese kaudu* 112 Kõnelahendusele a-sünkroonselt.

* - 112 Kõnelahenduse integratsiooni pakkuja liidesega arendab ja realiseerib SMIT. See hõlmab

pakkuja poolt edastatud spetsifikatsioonile vastava REST-teenuse loomist MSD vastuvõtmiseks või

sõnumiserveriga (MQ) ühenduse loomist ja hoidmist ning sealt MSD-sõnumite tarbimist.

3)Kõneformaadi vorming

a)Toetatud koodek on minimaalselt G.711 nii eCalli kui NGecalli osas.

2.3 Lahenduse tüüp

Tarkvaraline lahendus.

2.4 Paigaldamine (sh operatsioonisüsteem)

Lahendus peab toetama Linuxi-põhist paigaldust (konteiner või virtuaalmasin). Virtuaalmasina (VM)

puhul peab operatsioonisüsteemiks olema Linuxi-põhine distributsioon, mis toetab RPM-põhist

pakettide haldust.

Hankija annab pakkumuste hindamisel Linuxi-põhisele Dockeri konteiner lahendusele 20p ja

Linuxi-põhisele paigaldusele virtuaalmasinale annab 0p (vaata täpsemalt Lisa 4 -

Hindamiskriteeriumid).

2.5 Nõuded andmebaasile

Kui lahenduse konfiguratsiooni või edastamata MSD-andmete säilitamiseks kasutatakse

andmebaasi, peab see olema avatud lähtekoodiga vabavara (eelistatult PostgreSQL või MariaDB).

Andmebaas peab asuma rakendusest eraldi (kasutatav eraldiseisva andmebaasiteenusena) ning

selle ühenduse parameetrid peavad olema konfigureeritavad. Pakkuja tarne peab sisaldama

andmebaasi struktuuri loomist ja vajadusel esmast täitmist vaikeandmetega. Selleks peab lahendus

toetama kas automaatset struktuuri haldust (andmebaasi migratsioonid rakenduse käivitumisel) või

peab Pakkuja tarnima vastavad SQL-skriptid struktuuri loomiseks ja algseadistamiseks.

2.6 Liidestuse ja API kaudu MSD andmete edastamine

Lahenduse liides peab eCall- ja NG eCall-kõnest selle sisenemisel saadud MSD-andmed edastama

SMIT-i kõnelahendusele struktureeritud kujul (eelistatult JSON- või XML-vormingus).

Edastusmeetodina peab lahendus toetama kas REST-pöördumist SMIT-i kõnelahenduse API suunal

(POST/PUT) või sõnumiserveri kasutamist (eelistatud on RabbitMQ).

Lisaks peab tarnitav lahendus pakkuma omapoolset API-liidest aktiivse (siseneva või

tagasihelistamise/väljuva) eCall kõne ajal nii in-band- kui SIP- võimekuse IVS seadmelt MSD

andmete korduvaks pärimiseks.

Pakkuja tarnib kõikide liideste kohta (nii andmete edastamiseks kui korduvküsimiseks) detailsed

teenuse kirjeldused (nt OpenAPI/Swagger). Kirjeldused peavad võimaldama SMIT-il iseseisvalt välja

arendada andmete vastuvõtmise ja päringute tegemise võimekuse, paigaldada need vajalikesse

keskkondadesse ning seadistada liidese toimimiseks vajalikud parameetrid.

Kui edastatav või API kaudu väljastatav MSD-andmestik ei ole identne eCall-i MSD „algsele“

standardile (1:1-le), peab pakkuja tarnima ka väljastatavate andmeväljade ja nende struktuuri täpse

kirjelduse.

2.7 Käideldavus ja andmeterviklus

Lahenduse liideste ja API-de realisatsioon peab arvestama kõrgendatud nõuetega käideldavusele

ning maandama andmekao riske. Kui eCall-kõnest saadud MSD-andmete edastamine REST-

liidesele või sõnumiserverile ebaõnnestub, peab süsteem tagama võimalusel andmete

korduvsaatmise (retry logic).

2.8 Monitooritavus ja olekukontroll

Lahendus peab oma tegevust logima tasemel, mis võimaldab selle töö sh viga analüüsi ja

operatiivset reageerimist. Logisi peab olema võimalik edasi saata kesksesse logiserverisse SMIT

poolt paigaldatud agendi poolt.

Lahendus peab toetama reaalajas monitooringut (pakkuma teenuseid oma toimivuse jälgimiseks),

et tagada selle töökorra tuvastamine välise monitooringusüsteemi poolt.

2.9 Paigalduskeskkonnad ja kõrgkäideldavus

Lahendus peab toetama kõrgkäideldavat (HA) arhitektuuri nii toodangukeskkonnas (Live) kui ka

testi- ja koolituskeskkonnas.

Kõnejaotus ja rikkeümberlülitus (failover): Süsteemi eesmiseks kihiks on võrguelement (SBC), mis

teostab eCall/NG eCall kõnede suunamist ja koormuse jaotamist teenindavate serverite vahel.

Lahendus peab olema paigaldatav ja valmis töötama Primary-Secondary (aktiivne-passiivne)

režiimis. SBC suunab kõneliikluse esimesele (primaarsele) serverile. Esmase serveri

kättesaamatuse korral (näiteks juhul, kui eCall/NG eCall server ei vasta SIP OPTION päringutele)

lülitab SBC kõneliikluse automaatselt ümber teisele (sekundaarsele) serverile.

Keskkondade samasus: Test- ja koolituskeskkonna arhitektuur peab olema identne

toodangukeskkonnaga, võimaldamaks lahenduse paigaldust, haldust, koormustestimist ja

lülitusmehhanismide (failover) kontrolli samadel tingimustel nagu Live-keskkonnas.

2.10 Andmemahud ja jõudlusnõuded

Toodangukeskkond (LIVE):

Sessioonide arv: Lahendus peab suutma teenindada vähemalt 10 üheaegset eCall/NG eCall

kõnet/sessiooni ilma viivitusteta andmetöötluses.

Läbilaskevõime: Süsteem peab olema suuteline töötlema kuni 670 eCall-kõnet ööpäevas.

Märkus: näitajad on prognoositud 10–30-kordse varuga võrreldes 2024. aasta statistikaga (ca

800 kõnet aastas). Arvutus arvestab eCall-võimekusega sõidukite osakaalu pidevat kasvu

autopargis (uute sõidukite lisandumine ja vanemate väljavahetamine), mis tõstab süsteemi

koormust ka juhul, kui autopargi keskmine vanus või üldarv jääb samaks.

Testi- ja koolituskeskkond (TEST):

Sessioonide arv: Testkeskkond peab suutma teenindada kuni 2 üheaegset eCall/NG eCall kõnet

(vastavalt kasutatavate testseadmete ja -sõidukite hulgale).

Ressursikasutus:

Lahendus peab olema optimaalne, mitte tekitama põhjendamatut koormust (CPU/RAM/ketas

jne).

2.11 Paigaldus ja arhitektuur

Joonis ei kajasta:

 vajadusel andmebaasi kasutust (vt ptk „2.5 Nõuded andmebaasile“);

 MSD saatmisel REST asemel MQ kasutamist (MQ-d pole eraldi komponendina kajastatud –

see on nö üks osa 112 Kõnelahendusest);

 Häirekeskuse poolt IVS seadmele tagasihelistamist (vt „2.2 Funktsionaalsus“ punkt 1.b.i ja

2.b.i);

 IVS seadmelt siseneva kui Häirekeskuselt IVS seadmele tehtava eCall kõne ajal uue MSD

küsimist - eCall / NG eCall ruuter pakub selleks teenust 112 Kõnelahendusele (vt „2.2

Funktsionaalsus“ punkt 1.a.v, 1.b.iii, 2.a.v ja 2.b.iii).

Paigaldus ja arhitektuur on toodangu ning test- ja koolituskeskkonnas identne.

3. Toote tarnimine

3.1. Tarne sisu ja komponendid

Pakkuja peab tarnima täielikult komplekteeritud ja paigaldusvalmis tarkvarapaketi. Tarne koosseisu

kuuluvad:

 Tarkvara üleandmine: vastavalt valitud arhitektuurile peab tarne sisaldama kõiki vajalikke

komponente (nt Docker-konteinerite puhul konteineri fail ja paigaldusfailid; VM-ile

paigaldamise korral paigalduspaketid ja kõik vajalikud sõltuvused).

 Andmebaasi komponendid: kui tarkvara paigaldus eeldab andmebaasi loomist, peavad tarne

koosseisus olema vajalikud skriptid tühja andmebaasi struktuuri loomiseks ja/või vaike-

andmetega täitmiseks.

 Dokumentatsioon: Tarkvara paigaldus- ja haldusjuhend (inglise või eesti keelne).

 Liidestuse kirjeldus (API dokumentatsioon jm) arendamiseks vajaliku detailsusega (inglise või

eesti keeles).

3.2. Tarnetähtaeg

Hankeobjekt tuleb täies mahus üle anda ja tarne teostada hiljemalt 30 (kolmekümne) kalendripäeva

jooksul pärast hankelepingu sõlmimist.

3.3. Paigaldus ja tehniline tugi

Tarkvara paigaldab test- ja toodangukeskkonda Hankija (SMIT).

Pakkuja on kohustatud pakkuma 3 kuud hankeobjekti üleandmisest tasuta tehnilist tuge paigalduse

või liidestuse käigus tekkivate probleemide lahendamiseks, mis tulenevad tootest või paigaldus- ja

haldusjuhendi ebatäpsusest/puudulikkusest.

Kui toe pakkumine e-posti või telefoni teel ei ole probleemi lahendamiseks piisav, peab Pakkuja

tagama operatiivse toe reaalajas (online) videokonverentsi vahendusel mõlemale osapoolele sobival

ja kokkulepitud ajal.

4. Toote kasutustingimused ning nõuded

tootetoele/hooldusele

4.1 Toote kasutustingimused

Pakkuja annab hankeobjekti üleandmisel Hankijale (SMIT) ning lõppkasutajale (Häirekeskus) üle

tähtajatu, piiramatu ja tasutud õiguse (litsentsi) toodet paigaldada ja kasutada.

Tootetoe ja hoolduse tellimine peab olema Hankijale alates kolmandast (3) aastast vabatahtlik.

4.2 Tugi, hooldus ja garantii

Pakkuja pakub tootetoe ja hoolduse teenust minimaalselt järgmistel tingimustel:

Tootetoe ja hoolduse perioodil peavad Hankijale olema kättesaadavad kõik toote uuendused,

sealhulgas:

 Standardite ajakohastamine: Toote vastavusse viimine muutuvate NG eCall standardite ja

tehniliste nõuetega.

 Alustarkvara ühilduvus: Toote toimimiseks vajaliku alustarkvara (nt operatsioonisüsteemi

versioonid, andmebaasimootorid, konteinerplatvormid) uuendustega kaasnevad muudatused.

 Turvapaigad: Kriitiliste turvavigade parandamine ja turvapaikade (security patches)

väljastamine otsustatakse igakordselt tellija ja täitja vahel, kuid mitte kauem kui 90 päeva

pärast haavatavuse avastamist, kas pakkuja enda poolt või avalikkustatud tootja, CERT’i või

muu tunnustaud allika poolt.

Probleemide lahendamine ja reageerimisajad:

Probleemidest teavitamine toimub tööpäeviti (E–R, 09:00–17:00 CET+1).

Pakkuja peab reageerimist alustama hiljemalt kahe (2) tööpäeva jooksul pärast teate

kättesaamist.

Vea kõrvaldamise aeg lepitakse kokku vastavalt vea kriitilisusele, kuid pakkuja peab tegema kõik

endast oleneva esmase lahenduse või ajutise lahenduse/möödapääsu (workaround)

pakkumiseks esimesel võimalusel.

Tootetugi hõlmab tehnilist konsultatsiooni e-posti või telefoni teel ning vajadusel (kui distantsilt

lahendamine ei ole võimalik) reaalajas online-tuge videokonverentsi vahendusel.

Pakkuja tagab, et toode vastab tehnilises kirjelduses esitatud nõuetele (garantii). Garantiiperioodi

jooksul (1 aasta hankeobjekti üleandmisest) kohustub Pakkuja tasuta kõrvaldama kõik toote

tarkvaralised vead, mis takistavad selle sihtotstarbelist kasutamist.