Data File Transfer from VDS Device to

Postprocessing System

EADS TETRA System Release 4.5 – 5.5

DN99620252-02en
01/2007
The content of this document and its appendices and any information provided (all together "document") is for information purposes
only and is subject to change without notice. The document only specifies the products and services identified in the document. The
document is confidential and contains legally privileged information.

The document is only intended for the use of the recipient and the customer whose representative the recipient is, and may only be used
for the purposes for which the document is submitted. The document or any part of it may not be reproduced, disclosed or transmitted
without the prior written permission of Airbus Defence and Space.

Airbus Defence and Space will reasonably ensure that the information provided in the document is free from material errors and
omissions. However, the suggestions, directions, comments and statements made in the document (e.g. regarding the compatibility,
performance and functionality of mentioned hardware and software) are not intended to be and cannot be considered as binding. The
customer assumes full responsibility for using the document or any part of it. All comments and feedback are welcomed by Airbus
Defence and Space and are used as part of the continuous development and improvement of Airbus Defence and Space’s products,
services and the document.

Airbus Defence and Space disclaim and exclude all representations, warranties and conditions whether express, implied or statutory,
including but not limited to the correctness, accuracy or reliability of the document, or otherwise relating to the document. Airbus Defence
and Space’ total liability for any errors in the document is limited to the documentary correction of errors. Airbus Defence and Space will
not be liable for any direct or indirect damages arising from the use of the document or otherwise relating to the document.

Airbus Defence and Space® is a registered trademark of Airbus Defence and Space. Other product names, trademarks or other
identifiers mentioned in the document may be trademarks of their respective companies and are mentioned for information purposes only.

Copyright © 2014–2015 Airbus DS SAS, all rights reserved.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

2/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Scope of application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Structure of the manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Introduction to transferring files from VDS device to postprocessing system . . . . . . . . . . . . . . . 11

2.1 VDS device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 VDS counterpart application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Transferring data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Operating environment of VDS device and its counterpart application . . . . . . . . . . . . . . . . . . . . 12

3 Files of VDS device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 The VDS Device Data Storage Control File (TTSCOF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 The VDS Device Data File Transfer Control File (TTTCOF). . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 The Parameter File of Virtual Data Storing Device (VIPARA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Storing data to a VDS device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Types of data stored on a VDS device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Storing data on the data files of VDS devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 The operation of VDS devices in error situations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Compression of data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Data transfer connection between DX 200 element and postprocessing system . . . . . . . . . . . . . 27

5.1 FTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1 OSI address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2 File-specific username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.3 Operation-specific passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.4 FTAM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1 IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 FTP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 3/46
 5.2.3 The effect of file definitions on FTP transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Controlling data transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 The transfer of data files by using control files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Activating a data transfer connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Features required from VDS counterpart application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 Starting a VDS counterpart application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 Copying TTSCOFs from a network element to a postprocessing system . . . . . . . . . . . . . . . . . . 39
7.3 Reading data files from TTSCOFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4 Transferring data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.5 Updating the time stamps of TTTCOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.6 Checking the synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Quick guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

4/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
List of Tables.
Table 1 Data file states and their explanations. . . . . . . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 2 Time stamp structure . . . . . . . . . . . . . . . . . . . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 3 Meaning of save mode tickets. . . . . . . . . . . . . . . . . . .... . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 4 Passwords that define the level of user rights for files. ... . . . . . . . . . . . . . . . . . . . . . . . . 29

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 5/46
List of Figures.
Figure 1 The operating environments of a VDS device and its counterpart application. . . . . . . . . . . . 13
Figure 2 Rotation of data file states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 3 The structure of records in the TTSCOF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 4 Structure of TTSCOF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 5 Example of a TTSCOF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 6 Structure of record in TTTCOF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 7 Structure of TTTCOF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 8 Example of the contents of a TTTCOF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 9 Writing data into data files in a ring buffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 10 The data transfer connection between DX 200 network element and postprocessing
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 11 Copying files from a VDS device to a postprocessing system by using control files. . . . . . . . 37

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

6/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 DOCUMENT AMENDMENTS

VERSION DATE COMMENTS CHAPTER

UPDATED
02 01/2007 Changes between document issues are cumulative.
Therefore, the latest document issue contains all
changes made to previous issues.

• The information content has been changed due

to changes in software, e.g. FTP.

References

1. DXT Billing Centre Interface Description

2. OSI Guide, Operating Manual

3. TCP/IP Guide, Operating Manual

4. Virtual Data Storing Device Handling (IF), Command Reference Manual

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 7/46
 PAGE INTENTIONALLY LEFT BLANK

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

8/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
1 Introduction
This manual is intended for those who deal with the postprocessing system of a DX 200 network element. In
this document, the term “DX 200 network element” refers to the Digital Exchange for TETRA (DXT). It gives
instructions on how to design the data transfer application that resides in the postprocessing system. This
kind of management application is needed when it is necessary to automatise the transfer of files from the
VDS device of a network element to the postprocessing system. A VDS device is an entity consisting of a
program application and a disk file system that it manages. It is used in the DX 200 network element to store
data and control its transfer.

1.1 Scope of application

This document describes the data transfer interface between a DX 200 network element (DXT) and a
postprocessing system, and how a VDS device stores and manages data. This document is valid as of fixed
network releases that are based on G 2.0.Having read this document, you should know enough about the
data transfer from a VDS device to a postprocessing system in order to design in the postprocessing system
a VDS counterpart application that manages the data transfer. This document does not describe the VDS
counterpart application itself; it only provides the information needed to design one.

The main emphasis in this document is to describe the interface between a VDS device and the
postprocessing system, and the data transfer over this interface. For more information about the VDS device
and its management, seeVirtual Storing Device Handling (IF), Command Reference Manual.

This document does not give instructions on configuring the data transfer connection between a DX 200
network element (DXT) and the postprocessing system. The instructions for doing this can be found in OSI
Guide, Operating ManualandTCP/IP Guide, Operating Manual.

This document does not describe the format of the data being transferred. For more detailed information on,
for example, charging data, seeDXT Billing Centre Interface Description.

1.2 Assumptions
When this document was written, it was assumed that the reader has a basic knowledge of the structure of DX
200 network elements and of OSI and TCP/IP protocol stacks. We also assumed that before this document
is used, the data transfer connectioins between the DX 200 network elements and the postprocessing
system have already been configured. If they have not, the instructions for doing so are found in OSI Guide,
Operating Manual andTCP/IP Guide, Operating Manual.

Furthermore, when this document was written, it was assumed that the reader who is designing a VDS
counterpart application is an experienced programmer.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 9/46
1.3 Structure of the manual
This manual is divided into seven parts.

Introduction to transferring files from VDS device to postprocessing system

This chapter describes on a general level the operating environments of the VDS device its counterpart
application, and also the data transfer connection between a DX 200 network element and its
postprocesign system. The chapter gives a general outline of the entire subject.

Files of VDS device

This chapter describes the files of VDS devices and how the files are used.

Storing data to a VDS device

This chapter describes how a VDS device stored data to data files.

Data transfer connection between DX 200 element and postproduction system

This chapter describes the data transfer connections between a DX 200 network element and the
postprocessing system, and how these connections are used with OSI and/or TCP/IP protocols.

Controlling data transfer

This chapter describes the operation of the VDS counterpart application in the postprocessing system.
The methods with which the VDS device and its counterpart application control the data transfer are
presented, too.

Features required from VDS counterpart application

This chapter explains further points that must be taken into consideration when designing the VDS
counterpart application. Whenever possible, instructions are given that can improve the operation
of the VDS counterpart application.

The document ends with a Quick guide in which the operation of a VDS counterpart application is presented
in the form of flow charts.

1.4 Conventions

1.4.1 Fonts

Italics
Means:

• Reference to a manual or document section, for example I/O System administration, Operating
Manual.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

10/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
2 Introduction to transferring files from VDS
device to postprocessing system

2.1 VDS device

A VDS device is an entity consisting of a program application and a disk file system that it manages. The
VDS device is used to store data and control its transfer. The VDS program application is an optional part of
the software build of a DX 200 network element. The program application and the disk file system that it
uses reside on the computer unit hard disk of a DX 200 network element (DXT). A VDS can be located in the
computer unit of DX 200 OMU (Operation and Maintenance Unit), STU (Statistical Unit).

VDS devices are used to store data and transfer it from a DX 200 network element to a postprocessing
system. VDS devices can transfer to the postprocessing system any data that can be output through logical
files, such as charging data, reports and alarms. VDS devices write the data sent from logical files into buffer
files, from where it can be further sent to the postprocessing system by using FTAM or FTP. The operating
environment of the VDS device is presented in the figure at the end of this chapter.

2.2 VDS counterpart application

A VDS counterpart application is an application residing in the postprocessing system that copies data files
from a network element to the postprocessing system. The purpose of this document is to give the necessary
information to design a VDS counterpart application.The operating environment of the VDS counterpart
application is presented in the figure at the end of this chapter.

2.3 Transferring data files

The transfer of data files from a DX 200 network element to a postprocessing system can be done either with
the FTAM (file transfer, access and management) protocol in OSI or FTP (file transfer protocol) in TCP/IP.

The transfer of data files from a DX 200 network element to a postprocessing system is controlled with the
control files of VDS devices. The VDS device and VDS counterpart application communicate with each
other with the TTSCOF and TTTCOF. The control files are transferred between the network element and
VDS counterpart application using FTAM or FTP.

The data transmission connection between a DX 200 network element and a postprocessing system is either
a local area network (LAN) connection or a packet switched network that follows the X.25 standard. When
using FTP, only a LAN connection can be used as the data transmission connection. If FTAM is used, either a
LAN or X.25 connection can be used.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 11/46
2.4 Operating environment of VDS device and its counterpart
application
The figure below shows the operating environment of a VDS device in a DX 200 network element. The figure
also illustrates the operating environment of the VDS counterpart application in the postprocessing system,
and the protocols and data transmission connection used in the file transfer.

Data is output on VDS devices through logical files. The VDS device writes the data it receives into a ring
buffer that consists of data files. The VDS counterpart application polls at certain intervals the VDS devices
connected to the DX 200 network element. The figure below has only one DX 200 network element, but
in practice usually more than one network element is connected to one postprocessing system. The basic
principle is that one VDS device is controlled by one postprocessing system.

During polling, the VDS counterpart application checks each VDS device connected to it. First it copies, by
using FTAM or FTP, the VDS Device Data Storage Control File (TTSCOF) to check the numbers of data files
that can be copied. Subsequently the VDS counterpart application copies the full data files by using FTAM or
FTP. Then it updates the VDS Device Data File Transfer Control File (TTTCOF), which it has stored in its
memory, and sends it to the VDS device of the DX 200 network element. Now the VDS device can use the
TTTCOF to find out which data files have been transferred to the postprocessing system, and use the space
that was taken by those files to write in new data.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

12/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 DX 200 Postprocessing
network element system

FTAM or OSI or X.25 or OSI or FTAM or

FTP TCP/IP LAN TCP/IP FTP
Data
Logical
files VDS
counterpart
VDS device
application

WDU-0 WDU-1

data file 1
data file 2
.
.
dn9838289x2x0xen

TTSCOF TTSCOF
data file n TTTCOF TTTCOF
Ring buffer Data files

WDU-0 and WDU 1 Postprocessing system

hard disk

Figure 1 : The operating environments of a VDS device and its counterpart application.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 13/46
 PAGE INTENTIONALLY LEFT BLANK

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

14/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
3 Files of VDS device
3.1 Data files
A VDS device writes the data it receives into data files that are located in the root directory of hard disks in the
OMU, STU, and CHU. The directory name in the network element of a fixed network is /VIDAST/. The data
files form a disk file group that acts as a ring buffer.The number of data files in the buffer can vary between 10
and 999. You can change the number and size of data files with MML commands. The instructions for doing
this are presented in I/O System Administration, Operating Manual. The names of data files contain the data
file number and, depending on the naming conventions in the network element, possibly the number of the
VDS device. The files are named according to the following principle.
CF0001.Dyy
CF0002.Dyy
CF0003.Dyy
.
.
CFxxxx.Dyy

where

xxxx
is the number of the last data file specified

yy
is the number of the VDS device

Data files are controlled with the control files of a VDS device. The TTSCOF contains the information about
the data file's state, time stamp, and save mode. The TTTCOF contains a time stamp. The data files can be
in six different states. The states and their explanations are presented in the table below.

Table 1 : Data file states and their explanations.

State Explanation Value

describing the
state
OPEN Data is being written into the file. Only one file at 00H
a time can be in this state.
FULL The file is full and ready to be transferred to a 01H
postprocessing system outside the exchange.
TRANSFERRED The file has been transferred to a postprocessing 02H
system and can be used again.
WAITING The file waits to be compressed. Uncompressed 03H
files can be read from the disk.
COMPRESSING Compression is in progress. 04H
UNUSEABLE The file cannot be used, because there is not 05H
enough space on the hard disk to create it.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 15/46
The different states help the VDS device to keep a record of the kind of data the data files contain. The
rotation of data file states is shown in the figure below. When a VDS device writes data into a data file, the
state of the data file is OPEN. When the data file becomes full, the VDS device changes the state, depending
on the settings, to FULL, WAITING, or COMPRESSING. FULL means that the contents in the data file can be
transferred to the postprocessing system. COMPRESSING means that compression is in progress. Data files
in the WAITING state wait to be compressed. When the contents in the data file have been transferred to
the postprocessing system, the VDS device changes its state to TRANSFERRED. After this the file can be
used again. A VDS device puts a data file in the UNUSEABLE state, when it cannot be created to the disk.
Data file creation may fail, because there is not enough space on the disk. The state of an UNUSEABLE file
is changed only when there is enough room on the hard disk to create it, and the VDS device has opened
the file.The rotation of the file states is presented in the figure below.

OPEN UNUSEABLE

WAITING TRANSFERRED

COMPRESSING

FULL
dn97101775x2x0xen

Figure 2 : Rotation of data file states.

The time stamp of data files indicates the time, when the data file was last changed either from OPEN to
FULL state or from TRANSFERRED to OPEN state (as indicated in the TTSCOF time stamp). The time
stamp also indicates the time, when the data file has been transferred in the postprocessing system (as
indicated in the TTTCOF time stamp). The time stamp consists of seven bytes, which together express the
date and time. The byte values are shown in outputs as binary-coded decimals (BDC). The table below
shows the structure of the time stamp and how 1 February 1998 at 12:30:45 is coded in the time stamp.

Table 2 : Time stamp structure

Byte Unit Example 1: 1 February 1998

at 12:30:45
0 Seconds 45 BCD
1 Minutes 30 BCD
2 Hours 12 BCD
3 Days 01 BCD

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

16/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
Table 2: Time stamp structure (cont'd.)

Byte Unit Example 1: 1 February 1998

at 12:30:45
4 Months 02 BCD
5 Year (last two digits) 98 BCD
6 Year (first two digits) 19 BCD

The save mode of data files is expressed with save mode tickets. Save mode tickets are bits whose default
value is zero. When a certain save mode is reached, the VDS device changes the value of the corresponding
bit to 1. The VDS device uses save mode tickets, for example to inform the VDS counterpart application,
located in the postprocessing system, on which disk, WDU-0 or WDU-1, data has been saved and whether
the data file has been compressed. The meanings of save mode tickets are shown in the table below.

Table 3 : Meaning of save mode tickets.

Bit Explanation
0 This bit is changed to 1, when data has been successfully saved to disk
WDU-0.
1 This bit is changed to 1, when data has been successfully saved to disk
WDU-1.
2 This bit is changed to 1, when compressed data has been successfully saved
to disk WDU-0.
3 This bit is changed to 1, when compressed data has been successfully saved
to disk WDU-1.
4 This bit is reserved for future use.
5 This bit is changed to 1, when a backup copy of the file has been successfully
copied to portable media.This feature is not in use in network elements of
the fixed network.
6 This bit is changed to 1, when a file is skipped because its state is incorrect.
After this the files are no longer in consecutive order on the disk.
7 This bit is changed to 1, when a file has been changed straight from FULL to
OPEN state. This means that data that has not been transferred is being
written on.

3.2 The VDS Device Data Storage Control File (TTSCOF)

The VDS Device Data Storage Control File (TTSCOF) is a control file that controls the data storing of a VDS
device. It is located in the hard disk of a DX 200 network element's computer unit, in the same directory
as the data files. The TTSCOF is divided into records that contain the information about the state of data
files (1 byte), the time stamp (7 bytes), and the save mode (1 byte).

There is one TTSCOF for each VDS device used. The TTSCOF name is formed as follows:
TTSCOFyy.IMG

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 17/46
where

yy
is the number of the VDS device.

The TTSCOF is divided into 11 - 1000 records, depending on the number of data files that have been defined.
The number of records in a TTSCOF file is always one greater than the number of data files. The records are
numbered from 0 onwards. The first record (record 0) is not a data file. All the other records contain data from
data files that bear the same number. Thus, for example, the data in data file CF0123.D07 originates from
record number 123 in a file called TTSCOF07.IMG.

The figure below shows the contents of one record, consisting of data file data. The record is divided into nine
bytes. The first byte contains the information about the state of the data file. The next seven bytes contain the
time stamp showing when the data file was saved. The last byte in the record contains the bits that describe
the save mode tickets. The possible values of file states, the structure of the time stamp and the possible
values of save mode tickets are presented in the tables of section Data files ( 3.1 ). The BCD in the figure
stands for binary-coded decimal. The values indicating file state and save mode tickets are expressed as
binary-coded hexadecimals.

0 File state 0
1 Seconds BCD 1
2 Minutes BCD 2
3 Hours BCD 3
4 Days BCD 4
5 Months BCD 5
6 Year (last two digits) BCD 6
7 Year (first two digits) BCD 7
8 Save mode tickets ... 3 4 5 6 7 8
dn98313x2x0xen

Figure 3 : The structure of records in the TTSCOF.

The save mode tickets of the last byte are bits with a default value of zero. A VDS device changes the bit
to 1, when a data file has reached a certain save mode. When, for example, both the compressed and
uncompressed data is stored to disks WDU-0 and WDU-1, the save mode tickets receive values 00001111,
which is shown in the output as the binary-coded hexadecimal 0F.

All records in the TTSCOF except the zero records have the structure as shown above. The zero record takes
up the first nine bytes in the TTSCOF. These bytes are reserved for the presentation of control data. The first
word (that is, the first two bytes) in the zero file contain the number of the data file that is currently being used.
The number of the currently used data file is expressed in the word as a binary-coded hexadecimal. The
remaining seven bytes in the zero file are not in use.

The figure below shows the entire structure of the TTSCOF. The file is divided into records, each of which
has nine bytes. No separator bits are used between the records. The first nine bytes belong to record 0,
the following nine to record 1 etc. The number of records in the file depends on the number of data files.
The number of the last record is the same as the number of the last data file.In the figure below, n receives
values between 10 and 999.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

18/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 HEX Decimal
0 0 The number of the 0

1 1 data file currently open 1

2 2 Empty 2
Record 0

8 8 Empty 8

9 0 Data file state 9

A 1 Time stamp (1) 10

Record 1

10 7 Time stamp (7) 16

11 8 Save mode 17

. .

. .

. .
0 Data file state n*9+0
1 Time stamp (1) n*9+1

Record n

7 Time stamp (7) n*9+7

8 Save mode n*9+8
dn98325x2x0xen

Figure 4 : Structure of TTSCOF.

The TTSCOF is divided into disk blocks of 512 bytes on the hard disk of a computer unit in a DX 200 network
element. The first block (0-block), contains FTAM attributes. The first block (that is, 0-block) is not copied
along with the rest of the TTSCOF, so the VDS counterpart application in the postprocessing system can
ignore the 0-block. The actual data in the TTSCOF begins in block 1. The following figure shows an example
of a TTSCOF. The output begins from the beginning of block 1. The file contents continue uninterrupted over
block boundaries, containing as many records as there are data files that have been defined.

The contents of records 0, 3, and 9 are explained in the example output in the example output below. The
time stamps of the records are expressed as binary-coded decimals. The bytes that indicate the state and
save modes of data files, and the word that contains the number of the currently open data file in the 0-record
are expressed as binary-coded hexadecimals. The figure below of the TTSCOF shows that data files 1 to
6 are in the FULL state. Data file 7 is in the COMPRESSING state, 8 is WAITING, 9 is OPEN, and 10
and 11 are in the TRANSFERRED state. The word containing the number of the data file that is currently
open in the 0-record is a binary-coded hexadecimal (09 00 in the figure). If the value of the word were for
example 0A01, it would mean record 266.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 19/46
 OUTPUT/ Byte values in binary-coded decimal

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

0000: 09 00 FF FF FF FF FF FF FF 01 20 15 13 06 02 96
0010: 19 0F 01 16 28 13 06 02 98 19 0F 01 35 55 13 06
0020. 02 98 19 0F 01 11 23 14 06 02 98 19 0F 01 03 48
0030: 14 06 02 98 19 0F 01 09 17 15 06 02 98 19 0F 04
0040: 48 29 12 06 02 98 19 03 03 16 58 15 06 02 98 19
0050: 03 00 33 59 15 06 02 98 19 03 02 56 14 11 06 02
0060: 98 19 0F 02 28 15 11 06 02 98 19 0F

Record 0 contains the number of the data file currently

09 00 FF FF FF FF FF FF FF open. The number of the data file currently open is
expressed as the binary-coded hexadecimal 00 99,
09 00 FF FF FF FF FF FF FF whose desimal equivalent is 9. Otherwise the record
contains no data.

Record 3 contains the information about data file 3.

01 35 55 13 06 02 98 19 0F Data file 3 has been set to the FULL state on 6 Feb 1998,
13:55:35. The save mode tickets indicate that both the
compressed and un compressed data have been saved to
disks WDU-0 and WDU-1.

09 33 59 15 06 02 98 19 03 Record 9 contains the information about data file 9. Data

file 9 in the OPEN state and was opened on 6 Feb 1998,
15:59:33. The save mode tickets indicate the the file has
dn98337x2x0xen been succesfully initialised on disks WDU-0 abd WDU-1.

Figure 5 : Example of a TTSCOF.

3.3 The VDS Device Data File Transfer Control File (TTTCOF)
The VDS Device Data File Transfer Control File (TTTCOF) is a VDS device file that controls data transfer. It
is located on the hard disk of a DX 200 network element's computer unit, in the same directory as the data
files. The TTTCOF contains time stamps that have the same structure as those in the TTSCOF. The names
of TTTCOFs are structured as follows:
TTTCOFyy.IMG

where

yy
is the VDS device number

The TTTCOF is divided, like the TTSCOF, into 11-1000 records, of which the first (the 0-record) contains no
data. The time stamps of the other records in the TTTCOF correspond to a specific record in the TTSCOF
and to a specific data file.

The figure below shows the structure of one record in the TTTCOF. The record consists of seven bytes.
Bytes 0 to 2 contain the time when the data transfer occurred and bytes 3 to 6 the date. BCD stands for
binary-coded decimal.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

20/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 0 Seconds BCD 0
1 Minutes BCD 1
2 Hours BCD 2
3 Days BCD 3
4 Months BCD 4
5 Year (last two digits) BCD 5
6 Year (first two digits) BCD 6
dn98349x2x0xen

Figure 6 : Structure of record in TTTCOF.

The figure below shows the structure of a TTTCOF. The first seven bytes belong to the 0-record. The bytes
do not contain data. The next seven bytes belong to record 1, which contains the time stamp that shows the
time when the first data file was transferred.In the figure below, n can receive values between 10 and 999.

HEX Decimal
0 0 Empty 0

Record 0

6 6 Empty 6
7 0 Time stamp (1) 7

Record 1

E 6 Time stamp (7) 13

. .
. .

0 Time stamp (1) n*7+0

Record n

6 Time stamp (7) n*7+6

dn98352x2x0xen

Figure 7 : Structure of TTTCOF.

The TTTCOF is divided, like the TTSCOF, into disk blocks of 512 bytes on the hard disk of a computer
unit in a DX 200 network element. The first block (the 0- block, or file identification block), contains FTAM
attributes. The 0-block is not copied along with the rest of the TTTCOF, so the VDS counterpart application in
the postprocessing system can ignore it. The actual data in the TTTCOF begins in block 1. The following
figure shows an example of a TTTCOF. The output start at the beginning of block 1. The file contents
continue uninterrupted over block boundaries, containing as many records as there are data files that have
been defined.

The TTTCOF in the figure below contains the time stamps of data files 1 to 11. The time stamps show
the time when the data files have been transferred to the postprocessing system. The figure explains the
contents of records 0, 3, and 9. All the values in the figure are expressed as binary-coded decimals.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 21/46
 OUTPUT/ Byte values in binary-coded decimals.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
0001: 00 00 00 00 00 00 00 02 10 11 06 02 98 19 27 10
0010: 11 06 02 98 19 55 10 11 06 02 98 19 31 11 11 06
0020: 02 98 19 03 12 11 06 02 98 19 36 12 11 06 02 98
0030: 19 10 13 11 06 02 98 19 42 13 11 06 02 98 19 15
0040: 14 11 06 02 98 19 56 14 11 06 02 98 19 26 15 11
0050: 06 02 98 19

FF FF FF FF FF FF FF Record 0 contains no data.

55 10 11 06 02 98 19 Record 3 indicates the time 6 Feb 1998, 11:10:55.

15 14 11 06 02 98 19 Record 9 indicates the time 6 Feb 1998, 11:14:15.

dn98364x2x0xen

Figure 8 : Example of the contents of a TTTCOF.

3.4 The Parameter File of Virtual Data Storing Device (VIPARA)

The Parameter File of Virtual Data Storing Device (VIPARA) is a parameter file that is used to store data
about a VDS device. The VIPARA is located in the / LFILES/ directory on the hard disk of a computer unit in a
DX 200 network element. The file is used by VDS devices and the Virtual Data Storing Device Handling
MML(VIFHAN). In other words, the VIPARA cannot be read from the postprocessing system.

The VIPARA consists of records the number of which is defined by the number of VDS devices in the
exchange. One record contains the data on one VDS device. The record size is 512 bytes. The record
contains the following kind of data:

• the configuration data of the VDS device

• the names of control files and the directory where they are located

• the name base and directory location of data files

• the file-specific usernames of a FTAM connection and the operation-specific passwords

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

22/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
4 Storing data to a VDS device
4.1 Types of data stored on a VDS device
VDS devices are used to store charging data, alarms, and traffic measurement reports. Furthermore, all data
output through logical files can be stored on a VDS device.

4.2 Storing data on the data files of VDS devices

Data is stored into VDS devices through logical files. A VDS device writes data to data files residing in a ring
buffer, handling files in numerical order. The device writes data into a file until the file is full or it is closed by
time supervision or an MML command. Also the application that is writing data can decide that a data file be
closed. Subsequently it begins to write into the next file. The principle of data storing is shown in the following
figure. A VDS device controls the writing of data into data files with the VDS Device Data Storage Control
File (TTSCOF). It reads the first available data file number from the TTSCOF and starts writing into the file.
When the file becomes full or is closed, the VDS device changes the data file state in the TTSCOF to FULL,
COMPRESSING or WAITING and sets the time stamp at the time when the storing was finished. After this
the VDS device moves on to write into the next data file.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 23/46
 RING BUFFER

CF0001.Dyy
CF0002.Dyy
CF0003.Dyy TTSCOFyy.IMG TTTCOFyy.IMG
. Record 0000 Record 0000
. Record 0001 Record 0001
. Record 0002 Record 0002
CFxxxx.Dyy . .
. .
Record xxxx Record xxxx

Reads and
writes

Writes Reads
VDS

In the figure yy stands for the number of the VDS device

xxxx stands for the number of the last data file dn98613939x2x0xen

Figure 9 : Writing data into data files in a ring buffer.

The VDS device updates the TTSCOF with the aid of the TTTCOF. It retrieves all the files that have been
transferred to the postprocessing system and changes them to the TRANSFERRED state in order for them
to be re-used. The VDS compares the time stamps in the control files at regular intervals. When the VDS
device finds a data file that the TTSCOF tells is in the FULL state and whose time stamp in the TTTCOF
is more recent than that in the TTSCOF, it changes the data file state in the TTSCOF to TRANSFERRED.
Subsequently new data can be written into the data file.

4.2.1 The operation of VDS devices in error situations

When the next file to be written into is not free (it is in the TRANSFERRED state), the VDS device can be
configured to react in a certain way. The alternatives are:

1. The VDS device stops writing data (default). The application that is writing data considers its task
unsuccessful.

2. The VDS device stops writing data. The system continues to write data on the spare VDS device. The
application that is writing data considers its task successful.

3. The VDS device skips the data files it cannot write. It searches for the data file next in numerical
sequence that is in the TRANSFERRED state and continues to write data into this file. The VDS
device changes the save mode tickets of the skipped files to indicate that they have been skipped
due to an invalid state.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

24/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 4. The VDS device overwrites data on the next file that is in the FULL state. The VDS device changes the
save mode ticket of the data file to indicate that the file has changed straight from the FULL state to
the OPEN state.

If the creating of a data file onto disk fails, because there is not enough disk space left, the VDS device puts
the data file in the UNUSEABLE state and issues an alarm. The saving operation is acknowledged to the
writing application as having failed. The VDS device retrieves the next data file from the disk and the next
time it receives a saving request, tries to save data into this file. If the VDS device finds other files that have
been defined but not yet created to the disk, it puts them in the UNUSEABLE state.

The fill-up percentage of ring buffers can be followed with the help of alarms. Configuring a VDS device and
setting the alarms is presented in I/O System Administration, Command Reference Manual.

4.2.2 Compression of data files

With settings of the VDS device it can be specified that data files are compressed before moving them to
the postprocessing system. The compression is done by using the GZIP algorithm. The instructions for
compressing files are presented in Virtual Data Storing Device Handling, Command Reference Manual
(command group IF). The VDS device saves the compressed file in the /COMPyy/ directory as CFxxxx.Z and
changes its state to FULL in order for it to be transferred. The /COMPyy/ directory is a subdirectory of the
directory where the data files usually are. In the network elements of the fixed network, compressed data files
are stored in the /VIDAST/COMPyy/ directory. Compressed and uncompressed files can be told apart not
only by the name identifier and the directory location, but also by the save mode ticket. Bits 2 and 3 in the
last byte of the TTSCOF show whether the file is compressed or not.

CAUTION
The compression of data files slows down the saving of data. Before compressing, the environment of the
VDS device and the data transmission capacity must be taken into consideration.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 25/46
 PAGE INTENTIONALLY LEFT BLANK

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

26/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
5 Data transfer connection between DX 200
element and postprocessing system
The data transfer connection between a DX 200 network element and a postprocessing system can be:
• an X.25 connection
• a local area network (LAN) connection (standard IEEE 802.3)

X.25 defines a connection, conforming with ITU-T recommendations, that is used when connecting to packet
switched networks. A local area network (LAN) is a network that conforms with standards in the IEEE
802 series. LAN networks between DX 200 network elements and the postprocessing system follow the
IEEE 802.3 standard. These data transfer connections are used with the FTAM protocol of the OSI model,
or the FTP protocol of the TCP/IP protocol family.
The figure below shows the data transfer connection between a DX 200 network element and a
postprocessing system. The DX 200 OSI protocol stack conforms with the International Organization for
Standardization (ISO) OSI model. Corresponding applications are available for commercial computers. To
learn more about X.25 and LAN connections and about the OSI model and its protocols, see OSI Guide,
Operating Manual. Also the DX 200 TCP/IP protocol stack is compatible with corresponding commercial
protocols. For more information about the TCP/IP protocol stack, see TCP/IP Guide, Operating Manual.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 27/46
 DX 200 network element Postprocessing system

Applications using OSI or Applications using OSI or

TCP/IP services TCP/IP services
VDS device VDS-vastakappale

OSI applications TCP/IP TCP/IP OSI applications

applications applications
FTAM FTP FTP FTAM

Connection- Connectionless Connectionless Connection-

oriented network network service network service oriented network
service service
X.25 IEEE 802.3 IEEE 802.3 X.25

LAN

X.25
dn9838647x2x0xen

Figure 10 : The data transfer connection between DX 200 network element and postprocessing system

5.1 FTAM
FTAM offers the transfer and management services of an OSI network. The DX 200 network element can
be either a FTAM initiator or a FTAM responder. When transferring data from a DX 200 network element to
a postprocessing system, the DX 200 network element is usually the responder, while the postprocessing
system acts as the initiator. This means that the postprocessing system reads files from the DX and writes
them in the DX 200 network element.

5.1.1 OSI address

Creating a FTAM connection from the postprocessing system to a DX 200 network element is done on the
basis of OSI addresses. The names of local OSI applications of the DX 200 network elements and the
postprocessing system are used to form OSI addresses. The OSI protocol stack replaces the names of local

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

28/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
applications with OSI addresses. To learn more about the defining of OSI addresses in a DX 200 network
element, see the OSI Guide, Operating Manual.

5.1.2 File-specific username

The FTAM attributes of files located on the hard disk of a DX 200 network element can be made to include
file-specific usernames. For instructions on creating file-specific passwords, see Virtual Data Storing Device
Handling (IF), Command Reference Manual

5.1.3 Operation-specific passwords

The FTAM attributes of files located on the hard disk of a DX 200 network element can be assigned
passwords that restrict user privileges to a certain degree. Operation-specific passwords can be used only if
the remote end that starts the FTAM transfer can create passwords to individual operations. The passwords
that determine to what extent files can be manipulated are presented in the table below.

Table 4 : Passwords that define the level of user rights for files.

Password Meaning
read_password Allows users to read files.
replace_password Allows users to replace files.
extend_password Allows users to write at the end of the file.
reading_attributes_password Allows users to read file attributes.
delete_password Allows users to delete files.

For instructions on adding operation-specific passwords, seeVirtual Data Storing Device Handling (IF),
Command Reference Manual. The Nokia FTAM supports the use of operation-specific passwords, but
they are generally not used.

5.1.4 FTAM parameters

This section presents the parameters needed to create a FTAM connection and to transfer files. For more
information, see the OSI Guide, Operating Manual.

FTAM Address_query parameters

VFS-local
This parameter indicates the name of the local OSI application, which the OSI protocol stack replaces
with an OSI address.
VFS-remote
This parameter indicates the name of the OSI application in the remote system, which the OSI protocol
stack replaces with an OSI address.

FTAM Connection_request parameters

Username and Password

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 29/46
 If it has been specified that using the FTAM application of a DX 200 network element requires user
privileges, the username and password must be defined when the connection is being established.

FTAM File_open parameters

Filename and path

This parameter defines the name and path of a file to be opened. The Nokia FTAM does not support
logical file names, which means that the entire path must be entered in the parameter. If you want the
file to be copied from a specific disk, you must include in the path also the name of the hard disk
name of the DX 200 network element. If the disk name is not included, the Nokia FTAM uses either a
newer file or a file it can read.
Contents Type and Maximum String Length
This parameter defines the transfer format of files and the maximum length of character strings. The
Nokia FTAM supports unstructured binary transfer and text transfer. Binary files are generally more
common. Character strings have no maximum length in unstructured binary files.
Access Request
This parameter is used to define the access type. When a file is opened for reading, the parameter can
be given the following values:
• read file
• read attributes

When a file is opened for writing, the parameter can be given the following values:
• delete
• replace

Concurrency Access
Use the default values for this parameter.
Operation-specific Passwords
This parameter is used to indicate operation-specific passwords. The use of operation-specific
passwords is presented herein in section 5.1.3 . The Nokia FTAM supports the use of operation-specific
passwords, but they are generally not used.
Owner_id
This parameter is used to indicate file-specific usernames, the use of which is presented herein
in section 5.1.2 .
Override
This parameter is used when overriding files. The usual value is:
• delete and create with new parameters

Future File Size

This parameter is used when creating and overriding files. This parameter should be used, because the
DX disk system uses this information when creating a file. If the disk system does not know the size of
the new file, it will use a default value of 64 kilobytes. When overriding a file, the system retains the
original file size, unless a new file size has been given.
Permitted Actions

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

30/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 This parameter is used only when overriding files. It defines the actions that can be performed on a file
to be created. The alternatives are:
• read file
• read attributes
• delete
• replace

5.2 FTP
FTP offers the data transfer services of a TCP/IP network. The DX 200 FTP contains only the server feature,
which means that the postprocessing system always acts as a client. Data transfer is always prompted
by the postprocessing system.

5.2.1 IP address
An FTP connection from the postprocessing system to a DX 200 network element is established on the basis
of IP address. An IP address identifies uniquely each device that is connected to the Internet. An IP address is
a 32-bit binary-coded decimal. An IP address is interchangeable with a domain name that corresponds with it.

5.2.2 FTP parameters

This sections presents the parameters that are needed to create a Nokia FTP connection and to transfer files.

Open_connection parameters

The Open_connection command is used to create an FTP connection from client to server. The parameter
used with the command is:
host
This parameter specifies the IP address or domain name where you want to establish an FTP
connection, so the value of this parameter is the DX 200 network element's IP address or domain name.

USER/PASS parameters

When the USER/PASS command has been entered, the postprocessing system gives the DX 200 network
element is authority data. The command parameters are:
username
This parameter is used to enter a username in the postprocessing system.
password
This parameter is used to enter a password in a postprocessing system.

RETR parameters

When the RETR command has been entered, the postprocessing system read files from a DX 200 network
element. The command parameters are:
fromFile

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 31/46
 This parameter defines the file name and directory path of the source file in the DX 200 network element.

toFile
This parameter defines the file name and directory path of the target file in the DX 200 network element.

transferType
This parameter defines the format in which the files are transferred: either binary or ASCII.

STOR parameters

When the STOR command has been entered, the postprocessing system writes files in a DX 200 network
element. The command parameters are:

fromFile
This parameter defines the file name and directory path of the source file in the postprocessing system.

toFile
This parameter defines the file name and directory path of the target file in the postprocessing system.

transferType
This parameter defines the format in which the files are transferred: either binary or ASCII.

Allo
This parameter specifies the size of the file to be written. If the disk system does not give the size of
the file to be written, the DX disk system uses a default value of 64 kilobytes for new files and the
original size for files that are being overridden.

5.2.3 The effect of file definitions on FTP transfer

Certain factors must be taken into consideration in FTP transfer. These are: the permitted actions and FTAM
attributes defined for files in a DX 200 network element; file-specific usernames; and operation-specific
passwords.

Reading a file from a DX 200 network element into the postprocessing system (RETR operation) can be
successful only if the permitted actions for the file have been defined as:

• read file

• read attributes

Similarly, writing a file from the postprocessing system to a DX 200 network element (STOR operation) by
overriding an existing file can be successful only if the permitted actions for the existing file have been
defined as:

• delete

• replace

If FTP is used to write a new file to the hard disk of a DX 200 network element, the DX disk system
automatically adds in the zero block the FTAM attributes and permits all operations. On the other hand, when
overriding a file, the attributes already in the zero block are used. In other words, permitted operations do
not have to be defined, when files are transferred to a DX 200 network element with FTP, and in fact the
FTP protocol prevents you from doing so.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

32/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
If, when creating an FTP connection, the FTAM attributes of a file includes a file-specific username ( 5.1.2 ),
it is compared to the username given in the command. Using file-specific usernames makes FTP transfer
more difficult, because you can enter only one username with FTP.

FTP protocol contains no feature for showing operation-specific passwords ( 5.1.3 ). This means that FTP
transfer may fail if operation-specific passwords have been defined in the FTAM attributes of files. If, for
example, the operation-specific passwords read_password or reading_attributes_password have been
defined for a file, the RETR operation will fail. Likewise, if delete_password or read_password have been
defined, the STOP operation will fail.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 33/46
 PAGE INTENTIONALLY LEFT BLANK

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

34/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
6 Controlling data transfer
The transfer of data files from a DX 200 network element to a postprocessing system is controlled with control
files TTSCOF and TTTCOF, as explained in section Files of VDS device. The data transfer protocol used is
either the FTAM protocol of the OSI protocol stack, or the FTP protocol of the TCP/IP protocol stack.

In the postprocessing system, data transfer is done by the counterpart application of the VDS device. The
VDS counterpart application uses either a FTAM or FTP application for data transfer. A FTAM application
in a postprocessing system acts as an initiator, and a FTAM application in a DX 200 network element acts
as a responder. When using FTP protocol, the FTP application of a DX 200 network element acts as the
server and the application of the postprocessing system acts as a client.

6.1 Prerequisites
The data transfer connection between a DX 200 network element and a postprocessing system is either a
local area network (LAN) connection or a packet switched network that follows the X.25 standard. When
using FTP, only a LAN connection can be used as the data transfer connection. If FTAM is used, either a
LAN or X.25 connection can be used.

The postprocessing system must have in operation a protocol stack that conforms with the International
Organization for Standardization (ISO) OSI model; a FTAM application; and an application that controls
data transfer (a VDS counterpart application). If the FTP protocol is used instead of FTAM protocol, the
postprocessing system must also contain a TCP/IP protocol stack and an FTP application. If the VDS
devices compresses files, the postprocessing system must also contain GZIP or some other compatible
application for unpacking.

The data transfer connection must have been defined and activated, and the FTAM or FTP application
must be active, too.

For further information on data transfer connections and the FTAM protocol of OSI, see section Data transfer
connection between DX 200 element and postproduction system. For information on configuring the X.25
and LAN connections and the FTAM protocol, see the OSI Guide, Operating Manual. The configuration
instructions for FTP protocol are presented in TCP/IP guide, Operating Guide.

6.2 The transfer of data files by using control files

The control files of a VDS devices are used to control data transfer. The VDS counterpart application finds
out with the help of the TTSCOF which data files in a DX 200 network element are ready to be transferred.
When the data file transfer has been completed, the VDS counterpart application sends the information about
copied data files to the VDS device of the DX 200 network element through the TTTCOF.

The following figure shows the stages involved in the transfer of data files. The figure presents a view as
seen by the postprocessing system. The transfer is in six stages, which are:

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 35/46
 1. The VDS counter application of the postprocessing system activates either a FTAM or FTP connection
and reads the TTSCOF from the hard disk of the DX 200 network element.

2. The VDS counterpart application examines the TTSCOF for the state information and save mode
information of data files. The application searches for all the data files with a FULL state and uses
the save mode tickets to find out the location of the files in the DX 200 network element, and whether
the file is compressed or not.

3. The VDS counterpart application activates either a FTAM or FTP connection and copies all the data
files from the hard disk of the DX 200 network element that were marked as being in the FULL state in
the TTSCOF. The save mode ticket shows whether the compressed files (having the file extension Z) or
uncompressed files (extension Dyy) are copied from the hard disk of the network element.

4. The VDS counterpart application takes the time stamps of the data files it transferred and updates them
into the TTTCOF on disk in the postprocessing system.

5. The VDS counterpart application activates either a FTAM or FTP connection and writes the TTTCOF on
the hard disk of the DX 200 network element.

6. The VDS device compares the time stamps in the TTSCOF and TTTCOF and changes the states of all
those data files into the TRANSFERRED state whose time stamp is more recent in the TTTCOF.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

36/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 DX 200 network element Postprocessing system

Copy of file
TTSCOFyy.IMG TTSCOFyy.IMG

Record 0000 Record 0000

1. Reading the TTSCOF
Record 0001 Record 0001
file
Record 0002 Record 0002
. . 2. Reading the
data file states
. . from the TTSCOF
Record xxxx Record xxxx file
6. Comparing the time
stamps and updating them
into the TTSCOF file
RING BUFFER

CF0001.Dyy CF0001.Dyy
3. Reading the data
CF0002.Dyy files CF0002.Dyy
CF0003.Dyy CF0003.Dyy
. .
. .
. .
CFxxxx.Dyy CFxxxx.Dyy

Copy of file
TTTCOFyy.IMG TTTCOFyy.IMG

Record 0000 Record 0000

Record 0001 Record 0001
5. Writing the TTTCOF file 4. Updating the time
Record 0002 Record 0002 stamps into the
. . TTTCOF file

. .
Record xxxx Record xxxx

In the figure yy stands for the number of the VDS device

xxxx stands for the number of the last data file dn98391x2x0xen

Figure 11 : Copying files from a VDS device to a postprocessing system by using control files.

In practice the copying of files takes place when the postprocessing system is being polled. The VDS
counterpart application transfers data files from several network elements. During one polling cycle, the VDS
counterpart application goes through the VDS devices of all network elements, one VDS device at a time.
Subsequently the VDS counterpart application moves on to the next network element. It is also possible to go
through many VDS devices simultaneously, provided the postprocessing system is capable of doing it.

6.3 Activating a data transfer connection

The VDS counterpart application that is responsible for data transfer in the postprocessing system activates
a FTAM or FTP connection whenever data is read of written. The parameters needed for the Nokia FTAM

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 37/46
connection are presented here in section FTAM parameters and the parameters for the Nokia FTP are
in sectionFTAM parameters.

The VDS counterpart application activates a FTAM connection by giving the FTAM application the necessary
parameter values as input data. The input data can vary, depending on the FTAM application. The input data
can be some of the following:

• the OSI address of a DX 200 network element

• the name and directory path of a file to be copied

• the name and directory path of a file to be created

In addition to the above, you can also give the following values:

• a file-specific username

• an operation-specific passwords

• information on the size of the file to be created

• permitted actions for the file to be created

When using FTAM applications, the connection is closed automatically when all files have been transferred.
If file transfer fails, the FTAM application acknowledges to the VDS counterpart application with an FTAM
error code.

As regards an FTP connection, it is activated by the VDS counterpart application by giving the following
values:

• the IP address of a DX 200 network element or a domain that corresponds to the IP address

• the name and directory path of a file to be transferred

• the name and directory path of a file to be created

The parameters that are input vary, depending on the FTP application. The following input is also possible:

• the postprocessing system username for the DX 200 network element

• the postprocessing system password for the DX 200 network element

• information on the size of the file to be created

• information on whether the file transfer is done in binary or ASCII format.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

38/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
7 Features required from VDS counterpart
application

7.1 Starting a VDS counterpart application

When a VDS counterpart application is started for the first time, it must read the file template of the TTTCOF
from the DX 200 network element. The VDS counterpart application must be prepared for all possible
transfer errors with TTTCOF.
After each subsequent restart of a VDS counterpart application, the application must read the contents of
the TTTCOF from each DX 200 network element. The application must check the validity of TTTCOF time
stamps. Any time stamp that refers to a future point in time is considered invalid. If the VDS counterpart
application finds any invalid time references, it must issue an alarm in the postprocessing system and allow
the user to change either the TTTCOF time stamp or the time in the postprocessing system clock.

7.2 Copying TTSCOFs from a network element to a

postprocessing system
VDS counterpart applications must at all times be prepared for any error situation when copying TTSCOFs. If
a file cannot be copied, the application must try again after a while (1 to 5 minutes). If copying is repeatedly
unsuccessful, the postprocessing system issues an alarm and moves on to the following network element.

7.3 Reading data files from TTSCOFs

The VDS counterpart application searches TTSCOFs for data files that are in the FULL state. The application
must compare the information on files in the FULL state that are listed in the TTSCOF to the TTSCOF that
was read the previous time. If the information is identical, the VDS counterpart application must inform the
user about this. Some of the possible reasons for the TTSCOF being unchanged are:
1. The VDS device of a network element has not yet updated the TTSCOF after the previous polling
cycle. This is not an error, and the VDS counterpart application can skip this network element and
move on to the next one.
2. The VDS device of a network element cannot update files to disk.
3. The time stamp set by the VDS counterpart application in the TTTCOF in the previous copying cycle
was not more recent than the corresponding time stamp in the TTSCOF.

Before copying data files, the VDS counterpart application must check in the last byte of records in the
TTSCOF what the save mode is for data files that are in the FULL state. The VDS counterpart application can
see from the save mode tickets the disk where the data file is read from and whether the file is compressed
or not.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 39/46
7.4 Transferring data files
The VDS counterpart application must read the data files that are in the FULL state in chronological order
from the VDS device of the network element. Depending on what is stated in the save mode ticket, either
compressed files (having the file extension Z) or uncompressed files (extension Dyy) are copied from the disk
in the exchange. If data file transfer is unsuccessful, the application issues an alarm in the postprocessing
system and proceeds to copy the data file that comes next in chrological order.

The VDS counterpart application must hold a record of the data files that have been successfully copied.
The application must also set an alarm limit for the amount of data that is transferred at a time. This makes
it possible to notice if the amount of data being transferred is exceptionally large. The VDS counterpart
application should also set a time limit.

7.5 Updating the time stamps of TTTCOF

The VDS counterpart application updates the time stamps of the data files it has copied into the TTTCOF it
holds in its memory. Before updating, it checks that all time stamps to be updated have increased by at least
one second from the corresponding time stamps in the TTSCOF, because otherwise the VDS device cannot
change the transferred files to the TRANSFERRED state.

Updating the time stamps in the TTTCOF takes place one record at a time. When a data file has been
successfully transferred, the current time of the postprocessing system is put down in the TTSCOF as the
transfer time of the data file. But if the time stamp of the corresponding record in the TTSCOF is equal to
or more recent that the time in the postprocessing system, the time stamp put down in the TTTCOF will be
that in the TTSCOF plus one second.

7.6 Checking the synchronisation

When the VDS counterpart application has copied the TTTCOF, it must check the validity of time stamps in
them. If the time stamps in the TTTCOF are more recent than the time in the postprocessing system, the
application must inform the user about this. The VDS counterpart application must have a feature that
updates time stamps in the TTTCOF that are too recent. If the time stamps are not corrected, the VDS device
may change untransferred files to the TRANSFERRED state.

When the time stamp of a TTTCOF is updated after data file transfer, the postprocessing system must check
that the TTTCOF time stamp is at least one second more recent than the time stamp in the corresponding file
in the TTSCOF. If the time stamps sent to the VDS device in the TTTCOF are older than in the TTSCOF, the
VDS device cannot update transferred data files into the TRANSFERRED state, but instead the data files
are transferred again.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

40/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
8 Quick guide
The following flowchart presents the operation of the VDS counterpart application when data files are
transferred from the DX 200 network element to the postprocessing system. The flowcharts are independent
of the protocol used to transfer files.
0. Starting the VDS counterpart application.

1. Read the TTTCOFs from all network

elements.

No 3. Try again later (in 1-5 minutes).

2. Was the transfer If repeatedly unsuccessful,
succesfull? issue an alarm.

Yes

4. Check the validity of time

stamps in TTTCOFS.

5. Were the time Yes

6. Go to step 11.
stamps valid?

No
7. Issue an alarm and ask which should
be updated,
a) the clock in the postprocessing system or
b) TTTCOF time stamp.

b) 9. Update the TTTCOF time stamp to that

8. Update
of the time in the postprocessing
a) or b) ?
system and go to step 11.

a)

10. Update the postprocessing system clock

to that of the TTTCOF time stamp.

dn9838308x2x0xen

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 41/46
 11. Proceed to the following network
element and wait for the next transfer.

12. Read the TTSCOF

No 14. Re-try after a while (1 to 5 minutes),

13. Was the transfer and if unsuccessful a few times, issue
succesful ? an alarm and go to step 11.

Yes

15. Compare the information in data files in

the FULL state to the TTSCOF that was
read the previous time.

16. Is the information Yes

identifical? 17. Issue an alarm and go to step 11.

No

18. Check in the TTSCOF whether it contains

any files in the FULL state that 20. Has the TTTCOF No
have not been transferred in this cycle. been updated in this cycle?

Yes
19. Are No
there any untransferred files in 21. Send the TTTCOF to the VDS device of
the FULL state? the network element and go to step 11.

Yes

23. Check in the save mode tickets of the

TTSCOF if the data files have been
compressed. 22. Go to step 11.

dn9838311x2x0xen

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

42/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
 24. Check in the save mode tickets of the
TTSCOF if the data files have been saved
on both disks of the network element.

25. Read the oldest data file that is

in the FULL state.

26. Was the transfer succesful? No 27. Issue an alarm and

go back to step 20.

Yes

28. Compare the time stamp

of the read data file in the TTSCOF
to the time in the postprocessing system.

29. Is the time 30. Replace the time stamp of the

stamp equal to or more recent No data file in the TTTCOF with
the postprocessing system time,
than the time in the and go to step 32
postprocessing system?

Yes

31. Replace the time stamp of the data file in

the TTTCOF with the time stamp taken from
the TTSCOF, increased with one second.

32. Update the information about the

copying in the database of the
postprocessing system and check the
number of files transferred at a time.

dn9838323x2x0xen

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 43/46
 33. Does the
amount of data transferred No
or the time used to 34. Go back to 8.
transfer it exceed the
permitted limit?

Yes

35. Issue an alarm and send the

TTTCOF to the VDS device
of the network element

36. Go back
to step 11. dn9838335x2x0xen

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

44/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation
Glossary
The meanings of the terms and acronyms used in this document are explained below.

For further information on TETRA definitions, terms and concepts and the meaning of all acronyms and
abbreviations used in EADS TETRA System customer documentation, please see document EADS TETRA
System, Glossary (DN00126469).

Term / acronym Meaning

BCD Binary Coded Decimal
CHU Charging unit
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
GZIP GZIP is a data compression application that uses the Lempel-Ziv algorithm.
The same algorithm is also used in, say, ZIP and PKZIP applications.
HLR Home Location Register
LAN Local Area Network
MSC MSC is short for mobile services switching centre.
OMU Operation and Maintenance Unit
OSI Open System Interconnection
STU Statistical Unit
TCP/IP Transmission Control Protocol / Internet Protocol
TTSCOF VDS Device Data Storage Control File
TTTCOF VDS Device Data File Transfer Control File
VDS VDS is short for virtual data storing.
VIDAST VIDAST is short for Virtual Data Storing Device Driver.
VIFHAN VIFHAN is short for Virtual Data Storing Device Handling MML.
VIPARA Parameter File of Virtual Data Storing Device
WDU WDU is short for Winchester Disk Unit.
Domain name A domain name is a unique name that corresponds to an IP address that is
connected to the Internet. A domain consists of names that are separated
from each other with a dot, as in ntc.nokia.com.
DX 200 network A DX 200 network element is general term for all elements of a DX 200-based
element telephone network. In this document, DX 200 network elements refer to the
DXT.
IP address The Internet protocol address identifies uniquely each device connected to
the Internet. It is a 32-bit (4-byte) binary number.
Postprocessing Postprocessing system is a computer system outside the DX 200 network
system element that collects, receives and handles data which has been output from
the network element.

EADS TETRA System Release 4.5 – 5.5 DN99620252-02en

This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation. 45/46
Term / acronym Meaning
Logical file A logical file is a means of routing input and output that is generated and
needed by an exchange between I/O devices and application programs. With
a logical file, outputs can be directed, copied and backed up in the exchange
and the operations and maintenance network.
Record A record is a set of related data or words treated as a unit.
VDS device A VDS device is an entity consisting of a program application and a disk file
system that it manages. The VDS transfers data from a network element to
a postprocessing system.VDS devices are used in network elements OMU,
CHU, and STU of the DX 200.
VDS counterpart A VDS counterpart application is an application residing in the postprocessing
application system that handles the transfer of files from the VDS device of a network
element to the postprocessing system.

DN99620252-02en EADS TETRA System Release 4.5 – 5.5

46/46 This document and its contents are the property of Airbus DS SAS and must not be copied or circulated without authorisation