How Ukrainian Engineers Built an Independent Meteorological Data-Exchange Network

In the late 1990s, Ukraine was offered Russian meteorological centers at about $40,000 per unit. The offer was accompanied by a familiar set of arguments: the technology was described as closed, highly complex, and impossible to replace without the original equipment.

But we had different plans.

"Breeze" vs. the "Golden Meteorological Center"

Ukrainian engineers developed their own meteorological information concentrator "Breeze". It was ten times cheaper, worked just as well, but there was a problem:

Russia controlled key access nodes to the international network, and Ukraine’s independent connection was not being enabled through that infrastructure.

The Russian side proudly claimed that their session layer was a closed protocol, making integration impossible.

We did not argue. We implemented an independent integration route.

Minsk: Between Both Sides

Russian meteorological centers were also present in Belarus, and Minsk was an essential communication link in the network.

Minsk did what Minsk often does: it avoided taking visible responsibility for the dispute while leaving a practical communication channel open. The Belarusians did not know the internal workings of the Russian centers, but they could open a communication channel to Kyiv. And they did.

A "Secret Protocol"? Only for Those Unfamiliar with It

The "Breeze" project was led by Andrii Nikolaiev, the chief developer and technical director of the project.

All programmers involved were his colleagues from previous projects, bringing expertise from complex closed engineering systems into civilian applications for Ukraine, benefiting both the nation and its people.

Network Connectivity Diagnostics

With our system fully operational, the only missing piece was connecting to the network.

We performed network connectivity diagnostics and identified the correct communication endpoint and connection parameters.

Connection established!
Ukraine obtained an independent technical route for participation in the international meteorological data-exchange network!

This was not symbolic independence. It was operational technological independence implemented in real infrastructure.

The hydrometeorological telecommunication network built on Ukrainian-developed "Breeze" meteorological centers has been operating continuously, 24/7, for more than a quarter of a century. It provides meteorological information to regional hydrometeorological centers, transport systems, aviation, railways, public services, and other consumers who depend on timely weather data.

In today’s difficult time for Ukraine, the continued operation of this network is not merely a technical fact. It is part of the country’s national resilience and continuity of public services: a working civil infrastructure system created by Ukrainian specialists, under the technical leadership of Andrii Nikolaiev, the architect of the "Breeze" system.

Economic Impact: Savings That Were Unimaginable in 2000

The "Breeze" concentrators were deployed in every region of Ukraine, as well as in airports and railway networks.

There were at least a hundred of them, meaning the savings amounted to millions of dollars.

At the turn of 2000, such financial savings were an unimaginable sum for the country.

Reaction to the Independent Integration

The original system specialists were surprised that the integration had been completed without purchasing their equipment. They had treated the session-layer protocol as closed for independent external integration.

For us, this was not a matter of imitation or improvisation. We had been designing complex real-time data-exchange systems since 1991, so the engineering logic of the protocol was understandable.

And Minsk, as usual, kept its distance:

"We are not involved. We only provided the channel."

From Meteorological Centers to Software Development

When you truly understand technology, you don’t overpay for marketing "locks".

This applies not just to meteorological centers but also to software development.

How do you accurately estimate a project's workload?

How do you avoid unnecessary costs?

How do you determine the right number of developers?

💡 The "Software Development Labor Intensity Calculator" developed by Andrii Nikolaiev answers these questions.

First "Breeze", now – automated estimation of complex projects.

Conclusion

An engineer must not only be a highly qualified specialist but also feel responsibility toward their country and its public infrastructure. This is why initiative and technical competence were shown in creating the "Breeze" meteorological concentrators, drawing on prior experience with complex engineering systems.

In Russia, They Say Their Problems Are Fools and Bad Roads

It’s hard to argue with that, but we should also add poor communication lines to the list.

This is exactly why this protocol was developed in Moscow—to compensate for the low-quality communication channels that plague Russia’s vast territories. However, the protocol itself didn’t truly solve the issue. Instead, it became part of the "golden meteorological centers" scheme, designed to lock former Soviet republics into buying expensive Russian equipment.

How Proprietary Protocols Became Vendor Lock-In

This protocol was invented and implemented in Moscow for RosHydroMet. According to all official regulations, any meteorological centers in the former Soviet republics were required to comply with it. This led Russian authorities to believe that it would force everyone to purchase their "golden" Russian meteorological centers.

They were convinced that without their technology, no one could create, install, or connect a meteorological center. And for many former Soviet republics, this was indeed the case.

But not for Ukraine.

The Protocol Behind the Lock

The following describes the TCP/IP protocol for low-quality communication lines, which was recommended for use in the CIS (Recommendation RG/GST-14). This protocol was the foundation of the closed Russian system, which Ukrainian engineers integrated with independently, without purchasing expensive equipment.

Introduction

The protocol described below was designed for exchanging meteorological messages over a TCP/IP network between Message Switching Systems (MSS) operating on UNIX machines, primarily using analog telephone-type circuits.

Meteorological Session-Level Protocol for Poor Quality Communication Lines

Description: Description of the TCP/IP protocol for low‐quality channels, recommended for use in the CIS (Recommendation RG/GST-14).

Introduction

The protocol described below is designed for the exchange of meteorological messages over a TCP/IP network between Message Switching Systems (MSS) based on UNIX machines, primarily using analog telephone-type circuits.

Process Interaction Algorithm

Data exchange between two MSS is carried out in packets that can be classified as service packets and informational packets. Service packets are used to control the reception and transmission of informational packets containing meteorological messages, as well as to monitor the connection status.

The “client-server” scheme is adopted as the interaction algorithm at the software level, and the interaction mechanism is based on the “socket” network standard. The programs that need to exchange data must operate in different modes, i.e., one program in “server” mode and the other in “client” mode.

When launched, the “server” program opens a socket, assigns it a port number (Bind) that depends on the logical channel number (LCN) under which the MSS is configured, and waits for a connection (accept) from the remote “client” program.

When launched, the “client” program also opens a socket and attempts to locate the “server” on the network and establish a connection (connect), with the “client” specifying the server’s machine name and port number.

Algorithm of interaction of programs

If the “server” cannot be found on the specified machine, the “client” may try to locate the “server” on an alternative machine or retry the connection later.

There are several reasons for a failed connection, the main ones being:

• the “server” machine is turned off;
• the “server” program is inactive;
• the network port on the “server” machine is occupied;
• there is no connection between the remote machines;
• connection timeout.

Upon establishing a connection, the program with data to transmit sequentially sends a service packet describing the message (DATA) and an informational packet (INFO) containing the message text in either its normal or compressed form.

After transmitting the informational packet, a service packet indicating the end of the message transmission (END) is sent.

Upon receiving the service packet describing the message (DATA), the receiving program determines from it the length of the informational data packet and receives the informational packet of the meteorological message. Then, after receiving the end-of-message packet (END), the receiving program compares the parameters from the END packet with those from the DATA packet.

If the parameters match, the message is considered to have been received correctly and completely. The receiving program then forwards the received message to the system for further processing, and a service acknowledgment packet (ACK), which contains all the parameters of the received message, is sent to the transmitting program.

After sending the end-of-message packet (END), the transmitting program starts a timer for waiting for the acknowledgment (ACK WAITING) and, if the time expires without receiving the ACK packet, the message is retransmitted. The transmitting program considers the message transmission successful upon receiving the acknowledgment (ACK) packet.

If, during operation, a network disconnection or any error in reading during reception/transmission is detected, the programs close the “server” and attempt to establish a new connection.

To prevent network channel congestion (which is especially important when operating on poor and slow data transmission channels), the programs must implement a “WINDOW” for transmission, the size of which depends on the channel speed and the required bandwidth.

By default, the transmission window size for the MSS is set to 5, i.e., the transmitting program can send 5 messages over the network without waiting for acknowledgment (ACK) packets.

The ACK WAITING time is a program parameter determined during system installation (in practice, it is usually set between 120–300 seconds). This parameter must be the same for both the “server” and the “client”.

Parameter Values:

• "Transmission window" — 1, 3, 5, 10, 15
• "ACK WAITING" time — 60, 120, 180, 240, 300 seconds

Since the transmission of a meteorological message is considered successful only after the transmitting program receives an acknowledgment (ACK) packet, message loss is virtually impossible, although message repetition may occur – which is of no consequence when using the function of exclusively duplicate messages in the MSS.

To monitor the connection status during pauses between message transmissions, the programs exchange ready-to-receive (RR) service packets.

The program must monitor the timeouts for packet reception and transmission.

During transmission, the program should ensure that some packet is sent to the network at regular intervals; if there are no meteorological messages, the program sends ready-to-receive (RR) packets.

This interval is determined as the ACK WAITING time divided by 4.

During reception, the program must monitor the receipt of any packet within a certain period. If no packet is received, the program should close the socket connection and begin establishing a new connection.

This interval is determined as the ACK WAITING time divided by 2.

2. Message structure for "socket" usage

• Information packets (INFO) have a free structure and contain only the text of the meteorological message in binary format or segments of a facsimile message in the form of standard meteorological messages.
• Meteorological messages can be transmitted in either their normal form or in a packed (compressed) form. For compression, the “COMPRESS” bit in the service packet type field is used.

3. Service Packets

Structure of service packets DATA, END, ACK

a) Packet type – defines the purpose of the packet and can be:

• DATA – message description packet (start of message transmission);
• DATA Z – message description packet (start of message transmission) when using compression mode;
• END – end-of-message transmission packet;
• ACK – acknowledgment packet for message reception;
• RR – ready-to-receive packet.

b) Message identifier – a parameter of the MSS, a special address for the quick retrieval of a message in the queue;

c) Message length – all characters of the message from SOH to ETX;

d) Message sequence number – the “nnn” group;

e) AHD – abbreviated message header (10 characters in ITA-5 code, 2 reserved octets);

f) Message priority – identified for a specific type of data, for the quick retrieval of a message in the queue.

Structure of the RR service packet

This packet is used by the “receiver” to monitor the connection status in the absence of data traffic.

The packet length is 28 octets, identical to other service packets, solely for maintaining state synchronization.

The symbolic parameters for service packets are identified by decimal digits and have the following values:

• DATA – 1
• DATA.Z – 5 (uses the COMPRESS bit with a bitmask of 0x80);
• ACK – 2
• END – 4
• RR – 6

Rules for Using TCP/IP for Communication via "socket"

1. All new connections must begin with the last acknowledgment.
2. An established connection can exist indefinitely.
3. Before transmitting each message, a message description packet (DATA) must precede it.
4. After transmitting all the characters of the message (INFO packet), an end-of-message packet (END) must be sent.
5. The “receiver” must compare the parameters from the end-of-message packet (END) with those from the message description packet (DATA).
   • If the parameters completely match, the message is considered to have been received successfully, and an acknowledgment packet (ACK) is sent to the “transmitter”.
   • If the parameters do not match, the message is considered not received, and the “receiver” terminates the connection.
6. If there is no traffic, the “transmitter” and “receiver” must exchange ready-to-receive (RR) service packets to maintain synchronization at the frequency:

   T_rx-rr = 2T_tx-rr

The protocol is implemented in the software of meteorological concentrators and facsimile servers “Briz” in the regional hydro-meteorological centers of Ukraine and in the Main Data Center of the State Hydrometeorological Service of Ukraine.

We wanted Ukraine's independence not just in words, but in action—wherever we could make a real impact. We achieved this by applying our best technical skills and dedication to our country.

The meteorological network was built on Ukrainian-developed "Breeze" concentrators—a universal and protocol-agnostic system capable of handling any data format, encoding, or communication line. This technical foundation was leveraged in Ukraine's meteorological telecommunications network, incorporating proven solutions from the "Collection" and "Unified Control Center" systems. This foundation later enabled the creation of national real-time systems: "Navigation" (Ukraine's Navigation and Time Support Control System) and the "Metropolitan Passenger Flow Accounting System".

Conclusion

We created a system that worked and brought benefits, not promises.

The Philosophy of Choosing OSI: Why the Standard Open Systems Interconnection Model?

The key decision was made right from the start – to create an open system that can connect with others. This is not merely an architectural choice, but a strategy that defines all future development.

📌 First Principle: Open Systems

• If a network is to integrate with others, it cannot be made closed and limited to one protocol or one technology.
• Only one standard universally solves this problem – the Open Systems Interconnection (OSI) model.
• This was not just a technical decision, but an ideological choice – to build a system that is unrestricted by technologies, manufacturers, or data types.

What Would Happen If OSI Were Not Used?

• Each developer would create their own network, incompatible with others.
• There would be no unified approach, which would lead to chaos in integration.
• Any change in protocol or equipment would necessitate rewriting the entire system.

📌 Second Principle: Seven Layers – Not Just a Structure, but a Tool

• OSI does not merely describe layers – it allows proper functional separation.
• The bottom three layers (network-dependent) are responsible for how data is transmitted.
• The top four layers (network-independent) are responsible for what exactly is transmitted.
• This allowed for the creation of a universal hub where, for the user, it makes no difference how data is transmitted, while the logic of its processing remains the same.

📌 The Harmony of the Seven OSI Layers

The choice of seven layers in OSI was not accidental – it is based on the fundamental principles of information structure and natural interaction.

• Music – seven notes, each playing its role in harmony.
• Light – seven colors of the rainbow (in Ukraine there are exactly seven, unlike the English tradition).
• OSI – seven layers, and each performs its own function without interfering with the others, creating a unified system.

📌 An Important Parallel

If one of the OSI layers is removed, the entire system breaks down, just as if a single note were removed from an octave or one color from the rainbow.

📌 The Main Conclusion

The choice of OSI was not accidental – it was the only logical path when the goal was to create an open network capable of operating long-term and independent of specific technologies.