Join us on LinkedIn Read our Blog

Measuring MMHS Performance over HF Radio and Satellite: STANAG 4406 Annex E Encoding and Compression

Summary
This white paper is the first of a set of papers reporting on measurements made of MMHS (Military Message Handling Systems) operating over HF Radio and Satellite. This paper looks at the encoding and compression of STANAG 4406 Annex E messages, which is common to both HF Radio and Satellite transmission.

The paper shows that the encoding of messages is reasonably efficient, and that effective compression can be achieved.

Publish Date
10th June 2008

Share this whitepaper

What is Being Measured

Protocol layers - MMHS over HF Radio and Satellit

The diagram above shows the protocol layers for MMHS over HF Radio and Satellite. Details on these protocols and deployment configurations are given in the Isode whitepaper Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E.

This paper looks at the Message Format (top box), which is the static format common to both HF Radio and Satellite. The dynamic protocols for Radio and Satellite will be looked at in separate papers.

Network Bandwidth

Constrained bandwidth covers a range of speeds, and the numbers in this paper have differing impact across this range of speeds. The following table gives notes on different speeds:

Speed Notes
1 Mbit/sec Typical modern satellite throughput. Although very fast relative to speeds below, this is slow in comparison to commercial networks, and can be a significant bottleneck.
9,600 bits/sec Typical speed for currently deployed military satellites. Top end of HF throughput, which may be achieved in good conditions, with good aerials and strong transmitters (e.g., maritime deployment).
1.200 bits/sec Typical operational HF throughput. This number is taken as a figure for generic HF analysis.
75 bits/sec Bottom end of HF throughput
10 bits/sec Rate for ELF transmission to submarines

The implications of the analysis in this paper and its companions will have quite different impact across this range of speeds.

Why Measure

When communicating over constrained networks such as HF Radio and Satellite, it is important to optimize use of the link. In order to do this, an understanding of the operation of the underlying protocols and the applied load is important. This set of papers provides basic analysis of the protocols involved.

For most scenarios, these measurements need to be interpreted in the context of anticipated traffic load, network configuration and network speed. Outcome of this interpretation may be one or more of:

  1. Information on the best approach to configuration and option selection for the applied load.
  2. An understanding that the protocols are performing well, and where the limits of performance are.
  3. Information on how protocols may be adapted to improve performance.

There are many ways that protocols can be modified. We have observed attempts and suggestions for change that we suspect will make little difference to performance for real traffic. This analysis aims to help determine the most effective points for protocol change to address real operational problems.

How Measurements Were Made

Messages were created using Isode’s test User Agent XUXA, and sent over STANAG 4406 Annex E.

The size of three things was measured:

  1. The Message Content (P2 or P772) size.
  2. The size of the uncompressed message envelope (including message content) in P1 format.
  3. The size of the compressed output of STANAG 4406 Annex E, which is passed to the ACP 142 layer.

The first two measurements show the ASN.1 encoded size of the data to be transferred, and the third measurement shows the effect of the STANAG 4406 Annex E encoding and compression. Annex E allows a choice of compression algorithm, but only one (zlib) is currently mandated. These tests use zlib compression.

An initial "base" test was done, which comprised a message with an absolute minimum of features, and short (but reasonable) X.400 addresses. Subsequent tests added one or more items relative to the "base", to show the effect of different services and attachments.

The Measurements

  Msg Content Msg Envelope STANAG 4406 Annex E  
  Size Delta Size Delta Size Delta Cmprsn  
               
Base 113 - 382 - 232 - 39% The "base" message, using P2 encoding and a single recipient.
             
P772 113 - 379 (3) 233 1 39% This changes the type to STANAG 4406 (P772) which is compatible with P2, but indicates the presence of P7772 extensions in the message.
P772 Priority Qualifier 113 - 396 14 247 15 38% This includes the P772 priority qualifier, that XUXA always includes for military messages (although strictly the encoding is only needed when the value is high). X.400 envelope extensions such as this require encoding of both the extension and the criticality.
Urgent Priority 113 - 385 3 236 4 39% The default ("normal") message priority is not encoded. This shows the overhead of adding a simple envelope feature.
                 
1 char subject 118 5 387 5 235 3 39% The base message did not have a Subject. Adding a very short subject shows the overhead of adding a heading extension. This shows the typical overhead of a P772 extension, most of which are heading extensions.
5 char subject 122 9 391 9 243 11 38% This shows that adding characters to the subject increases content and envelope size according to the subject size (compare with one character subject).
28 char subject 148 35 418 36 270 38 35% This shows a slightly larger increase than would have been expected. This is because ASN.1 encoding is slightly more efficient for values less than 128 characters long, and the message size here increased over this limit. This affects both content and envelope encoding.
                 
Two recipients 160 47 476 94 251 19 47% Another recipient is added. This affects both content and envelope, as the recipient is present in both. The new recipient is similar to the first, which leads to very effective compression of the new data.
Long recipient (added 10 address chars to address) 123 10 402 20 253 21 37% The recipient address is made longer. As above, this affects both content and envelope.
DL Expansion Prohibited 113 - 396 14 248 16 37% This is another example (like P772 priority qualifier) of a simple envelope extension.
Latest Delivery Time 113 - 412 30 235 3 43% This is an example of an envelope extension containing more data. It compresses well, probably because of the similarity of the date to others in the message.
                 
Signature - co cert 113 - 544 162 410 178 25% This uses an X.400 envelope signature (Message Origin Authentication Check). STANAG 4406 messages use content based signatures with CMS encoding. This is likely to add a little more overhead. Signatures do not compress well.
Signature + cert 113 - 1,181 799 928 696 21% Certificates are often included for the convenience of the recipient. This has a quite high overhead for a small message, and it may make sense to NOT include the certificate, allowing the recipient to retrieve the certificate if needed. Certificates do not compress well.
                 
Text: 1 char 123 10 400 18 247 15 38% This shows the overhead of adding a basic body part to the message. This also increases the envelope size, as this includes “Encoded Information Types” reflecting the body part.
Text: 5 char 127 14 404 22 251 19 38% This shows that once the body part is added, that sizes increase linearly with the amount of data added.
Text: 354 bytes 484 371 763 381 508 276 33% Short text (start of a news article) gets some compression.
Text: 4.68 kByte 4,927 4,814 5,206 4,824 2,568 2,336 51% Larger text (all of the news article) compresses well.
Text: 17.8 kByte 18,405 18,292 18,684 18,302 6,910 6,678 63% Larger text (Isode white paper) gives good compression.
                 
1 byte Word Doc 175 62 474 92 308 76 35% Word document is added as a File Transfer Body Part, which has quite a bit of auxiliary information, and reflects several values in the envelope encoded information types. The one byte document was “fake”, as real Word documents are much larger.
24.0 kByte Word doc (3 paras of text) 24,768 24,655 25,068 24,686 3,401 3,169 86% This is a minimal word document, which compresses very well.
74.0 kByte Word doc (2.5 pages of text) 74,954 74,841 75,256 74,874 18,412 18,180 76% This larger Word document also compresses well.
                 
748 kByte PowerPoint 766,146 766,033 766,448 766,066 697,944 697,712 9% PowerPoint uses internal compression, and so only gives some compression.
504 kByte (text heavy) PowerPoint 516,808 516,695 517,110 516,728 422,939 422,707 18% PowerPoint with a lot of text compresses somewhat more.
                 
11.4 kByte JPEG 11,612 11,508 11,921 11,539 11,524 11,292 3% JPEG is a compressed format, and so there is minimal compression.
4.918 Mbyte JPEG 5,035,428 5,035,315 5,035,730 5,035,348 5,035,616 5,035,384 0% For a large JPEG, there is virtually no compression.

 

Analysis & Conclusions

Looking at this data, the following conclusions can be drawn:

  1. The basic ASN.1 encoding used in X.400 and STANAG 4406 is a reasonably compact and efficient encoding (unlike Text and XML encodings) and the data sizes are reasonable for the information carried.
  2. The "base" size of data transferred of 233 bytes represents an approximate minimum data size. For most environments, this overhead will be quite acceptable. A future white paper will consider situations where this size may be too large.
  3. Addition of features appears to give a sensible "per feature" overhead for a range of different extensions. Where it is necessary or desirable to go beyond basic capabilities, the encoding cost of these additional features is acceptable.
  4. The standard zlib compression achieves 35-40% compression with the core message and message features. This seems reasonable. It is likely that some of this compression is due to regularity of the ASN.1 encoding.
  5. Body part compression is very much dependent on the compression achieved for the body part in question, and for larger messages compression will be dominated by body part compression. Compressed data types such as JPEG give almost no compression, whereas text documents and formats such as Word compress well. Where heavy use is made of a special body part type, it may be appropriate to use compression algorithms optimized for that sort of data.

The broad summary is that for most deployments and configurations that the STANAG 4406 Annex E encoding is appropriately compact and that the compression will work well, providing clear benefit.