TETRA System Release 7.0: Charging Services: DXT - CDR Interface Description

Charging Services: DXT - CDR Interface Description
TETRA System Release 7.0

DN00126566-19-4en
(TRASYSAPP00334) 11/2016
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 © 2015–2016 Airbus DS SLC, all rights reserved.
DN00126566-19-4en TETRA System Release 7.0
2/129 This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation
Contents
1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Charging data in DXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Using the disks for CDR storing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Charging control files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Storing capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Configuration of VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Logical file connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Transferring charging data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Transfer process using DXT hard disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Transfer capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Transfer control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 FTP File transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 OSI protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Charging records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Selection of charging records for generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 CDR content formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Charging records of different events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Individual calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Forwarded individual calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.3 Transferred individual calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.4 Group calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.5 Short data and status messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.5.1 SDS and status message transfer within a TETRA network . . . . . . . . . . . . . . . 37
4.3.5.2 SDS and status message transfer over the Inter-System Interface . . . . . . . . . . 37
4.3.5.3 Preventing CDR generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.6 Packet data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.7 Unsuccessful calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.8 Registrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Charging record types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TETRA System Release 7.0 DN00126566-19-4en
This document and its contents are the property of Airbus DS SLC and must not be copied or circulated without authorisation. 3/129
4.4.1 TETRA originated call attempt record (TOC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.2 TETRA terminated call attempt record (TTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.3 Incoming gateway call attempt record (InG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.4 Outgoing gateway call attempt record (OutG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.5 TETRA originated call forwarding (Forw) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.6 TETRA originated Short Data and Status record (SDS-TO) . . . . . . . . . . . . . . . . . . . . . . 57
4.4.7 Packet data record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.8 TETRA originated registration record (Reg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A Data types used in charging records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.1 address_extension_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.2 al_reject_cause_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.3 auth_result_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.4 basic_service_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.5 bcd-coded phone number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.6 calendar_time_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.7 call_priority_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.8 cc_call_identifier_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.9 class_of_ms_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.10 dc_data_call_type_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.11 dc_dws_ack_v_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.12 ext_line_index_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.13 ip_addr_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.14 loc_update_type_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.15 ntn_cell_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.16 ntn_encryption_method_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.17 ntn_la_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.18 org_block_id_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.19 pd_service_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.20 pdp_event_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.21 pdp_qos_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.22 pdp_rej_cau_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.23 piu_index_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.24 piu_type_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.25 reject_cause_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.26 sds_tl_protocol_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.27 sending_profile_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.28 setup_priority_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.29 subscriber_class_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.30 system_id_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.31 tax_reg_ch_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.32 tgt_ch_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.33 term_cause_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.34 unit_index_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.35 urgency_class_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B Identification of the calling and called party in charging records . . . . . . . . . . . . . . . . . . . . . . . . . 83

B.1 MS -> MS call, NITSI number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.2 MS -> MS call, MSISDN number dialled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 MS -> MS call, FSSN number dialled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.4 MS -> PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.5 PSTN -> MS call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.6 MS -> PABX call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.7 PABX -> MS call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C Contents of CDR fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

C.1 Individual and group call: contents of the CDR fields in a TETRA-originated and TETRA-terminated
call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1.1 CDR fields in normal case, cause for termination = 01 . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1.2 CDR fields in a transferred call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
C.1.2.1 Call transfer from a TETRA subscriber to an external subscriber . . . . . . . . . . . 97
C.1.2.2 Call transfer from an external subscriber to a TETRA subscriber . . . . . . . . . . . 98
C.1.3 CDR fields in a forwarded call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1.3.1 Call forwarding from a dispatcher to a TETRA subscriber . . . . . . . . . . . . . . . 100
C.1.3.2 Call transfer from a dispatcher to a TETRA subscriber, followed by call forwarding
to a dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.1.4 CDR fields in a combined group call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.1.5 CDR fields in an ISI-linked group call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.1.6 CDR fields, cause for termination = 02...09. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.2 Short data and status message: contents of the CDR fields in a TETRA-originated short data and
status message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C.2.1 CDR fields in normal case, SDS result = 00/01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C.2.2 CDR fields in a data message delivery to a combined group . . . . . . . . . . . . . . . . . . . . 116
C.2.3 CDR fields in a data message delivery via SMSGW . . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.2.4 CDR fields, SDS result = 02...0A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
C.3 Registration: contents of the CDR fields in TETRA-originated registration . . . . . . . . . . . . . . . . 118
C.3.1 CDR fields in a normal case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
C.3.2 CDR fields in roaming registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
C.3.3 CDR fields in RUA/RUD request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
List of Tables.
Table 1 Description of header record fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 2 Description of trailer record fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 3 Structure of time stamp field in TTSCOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 4 Time stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 5 TOC record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 6 TTC record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 7 InG record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 8 OutG record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 9 Forw record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 10 SDS-TO record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 11 PD record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 12 Reg record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 13 Contents of the basic service information elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 14 BCD coding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 15 The number types and example of prefix digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 16 TOC record, MS -> MS call, ITSI number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 17 TTC record, MS -> MS call, ITSI number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 18 TOC record, MS -> MS call, MSISDN number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Table 19 TTC record, MS -> MS call, MSISDN number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 20 TOC record, MS -> MS call, FSSN number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 21 TTC record, MS -> MS call, FSSN number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 22 TOC record, MS -> PSTN call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 23 Outgoing gateway record, MS -> PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 24 Incoming gateway record, PSTN -> MS call, ITSI number dialled . . . . . . . . . . . . . . . . . . . . 89
Table 25 TTC record, PSTN -> MS call, ITSI number dialled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 26 TOC record, MS -> PABX call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Table 27 Outgoing gateway record, MS -> PABX call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Table 28 Incoming gateway record, PABX -> MS call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Table 29 TTC record, PABX -> MS call, ITSI number dialled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Table 30 TETRA-originated call, normal case (TOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Table 31 TETRA-terminated call, normal case (TTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Table 32 Call transfer: MS -> DWS -> PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 33 Call transfer: PSTN -> DWS -> MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 34 Call forwarding: MS -> DWS -> MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table 35 Call transfer followed by call forwarding: MS -> DWS -> MS – DWS . . . . . . . . . . . . . . . . . 102
Table 36 Combined group call (TOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table 37 CDRs generated in the originating network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table 38 CDRs generated in the controlling network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table 39 CDRs generated in the participating network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 40 Fields different from normal CDR fields (TOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 41 Fields different from normal CDR fields (TTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 42 CDR fields in normal case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table 43 Data message delivery to a combined group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Table 44 Contents of the address fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Table 45 CDR fields in a normal case (ITSI attach) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table 46 CDR fields in a normal case (ITSI detach) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table 47 CDR fields in roaming registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table 48 CDR fields in RUA request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Table 49 CDR fields in RUD request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
List of Figures.
Figure 1 Handling of charging records generated by OMU/CMM/CCC . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 2 Handling of charging records generated by STU in the DXTip. . . . . . . . . . . . . . . . . . . . . . . 14
Figure 3 The structure of charging disk files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 4 An example of charging data in a disk file (65408B charging block used). . . . . . . . . . . . . . . 16
Figure 5 State transitions of charging disk files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 6 Transferring CDRs from the DXT to the post-processing system . . . . . . . . . . . . . . . . . . . . . 24
Figure 7 Transferring communication-related charging disk files from the DXT to the post-processing
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 8 Networking of DXT exchanges for CDR collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 9 CDR collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 10 OSI protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 11 CDR generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
DOCUMENT AMENDMENTS
VERSION DATE COMMENTS CHAPTER

UPDATED
19-4 11/2016 Table SDS-TO record has been updated. Table 10
Table Reg record has been updated. Table 12
19-3 08/2016 Description of the data type loc_update_type_t 's value A.14
04 has been updated.
Editorial correction. A.4
19-2 06/2016 Minor changes. Throughout
19-1 10/2015 Added information about Release 7.0 CDR features. 4.3.8
Updated information on the service usage 4.3.6
characteristics to which packet data charging is based
on.
Updated section CDR generation.
19-0 03/2015 Added information about DXTA. Throughout
Title of the document changed from 'Charging Services:
DXT - Billing Centre Interface Description' to 'Charging
Services: DXT - CDR Interface Description'.
Added the following enhancements to the data content
of CDRs:
TOC CDR update: 4.4.1 , C.1.1 ,
- added option to show more than 100 group call C.1.4
members in the TOC CDR
SDS-TO CDR update: 4.4.6 , C.2
- new fields (target DXT id, target location area, target
channel type, SDS-4 protocol and diagnostics) added
to the CDR
- added data type sds_tl_protocol_t A.26
- added data type tgt_ch_t A.32
Packet data CDR update:
- new values (successful / unsuccessful context A.20
activation) added to data type pdp_event_t. 4.4.7
- added the field Diagnostics to the CDR
Registration CDR update: 4.3.8 , 4.4.8 ,
- new fields (subscriber class and channel type) added C.3
to the registration CDR.
- added data type subscriber_class_t A.29
- added data type tax_reg_ch_t A.31
Updated information on call forwarding:
Updated information on call forwarding and Forw CDR 4.3.2 , 4.3.3 ,
generation. 4.4.5 ,
Added examples on contents of the CDRs in different C.1.3
call forwarding cases.
18-4 05/2014 List of reject causes for data type pdp_rej_cau_t A.22
updated.
References
1. Guide to TETRA Documentation, dn00126445
2. Numbering, dn00126527
3. Data File Transfer from VDS Device to Post-processing System, dn9962025
4. GA - Dynamic Data Handling, dn98908517

5. GE - CDR and Report Saving Handling, dn98908505
6. GT - Detailed Charging Handling, dn98793148
7. IF - Virtual Data Storing Device Handling, dn99613829
8. Glossary, dn00126469
9. Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI). ETSI TS 100
392-2 V2.6.1 (2006-05)
1 About this document
The purpose of this document is to give the information needed for organising the transfer of the charging
data from a DXT to a post-processing system.
We welcome any suggestions for further improvement of this document. Also, should you find any errors or
omissions in this document, please forward your comments to the Airbus Defence and Space representative
or send them to the e-mail address tetra.cudo@airbus.com.
How to use this document
The chapters of this document are organised as follows:
• Chapter 1 About this document introduces the structure of the document.
• Chapter 2 Charging data in DXT describes how charging data is collected and stored in the DXT.
• Chapter 3 Charging data transfer describes the transfer of the charging data from the DXT to the
external billing system.
• Chapter 4 Charging records gives a table-wise presentation of the fields contained in each charging
record type.
Appendix A provides additional information on the data types used in the call records. Appendix B describes
how calling and called parties are identified in the charging records. Appendix C provides example cases
of CDR field contents.
The Glossary section explains the abbreviations used in this document. The full version of the glossary is
provided as a separate document, Glossary, dn00126469.
An Index is provided at the end of this document.
The typographic conventions used in TETRA System customer documentation are explained in Guide to
TETRA Documentation, dn00126445.
PAGE INTENTIONALLY LEFT BLANK
2 Charging data in DXT
2.1 General
The charging data generated in the DXT produces two types of CDRs: communication CDRs and registration
CDRs. Communication CDRs provide information on different types of calls, status and short data messages
and packet data transfer, and the registration CDRs information on radio subscribers' registration and
de-registration. Figures 1 and 2 illustrate the handling of the charging data in the DXT.
Post-processing
system
DXT
OSI /LAN CDR generation
INTERFACE
CMM/CCC
OMU RAM
buffer
TCP /IP/LAN
INTERFACE
VDS
USB MO disk Hard disks

(DXTip)
Dn091397x3x 2xen
Figure 1 : Handling of charging records generated by OMU/CMM/CCC
Post-processing
system
DXTip
OSI /LAN
INTERFACE
TCP /IP/LAN Interface
OMU
CDR TCP /IP

generation Interface
STU
RAM
buffer
VDS
MO disk Hard disks

dn 00124244 x6x1xen
Figure 2 : Handling of charging records generated by STU in the DXTip
The CDRs are generated by the Central Memory and Marker (CMM) unit, if present in the configuration.
Otherwise, the Operations and Management Unit (OMU) is used. In the DXTip, the CDRs are generated by
the Call Control Computer Unit (CCC) or by the Statistical Unit (STU) if the STU unit is equipped. The CDRs
are first placed into a buffer in the RAM memory of the computer unit (CMM/CCC/STU/OMU). When the
buffer fills up, its contents are moved onto the hard disks of the exchange. Alternatively, by using the MML
command GEV, it is possible to set a period after which a block is transferred onto the disk. From the disks
the records are transferred to an external computer system by using the FTP (File Transfer Protocol) in the
TCP/IP or the OSI/FTAM file transfer method as described in Chapter 3.1 of this document.
The CDRs are formed according to a specific format and stored into the RAM memory of the CMM/CCC/STU
unit. The RAM memory is divided into several blocks, where one block is the amount of charging data written
to the disks at one time. When the block becomes full, it is transmitted further to a logical file CDFILE or
HBLOFI. The logical file contains the information to which physical I/O devices the writing tasks are routed.
Usually the two disks of the OMU or STU are used. Alternatively, or in addition to these disks, the CDRs can
be stored in the USB memory stick of the DXT or, in the case of DXTip, on the magneto-optical (MO) disk.
In the case of two OMU units, the active (working) unit takes care of data handling.
2.2 Using the disks for CDR storing

CDRs are written to disk files in the Operation and Maintenance Unit (OMU) or, in the case of DXTip, in the
Statistical Unit (STU) if this unit is included. In these units, the CDRs are stored in the following directories:
• VIDAST/CF0xxx.Dyy
• VIDAST/EVRFILE/EV0xxx.DAT
In the file name, xxx is the ordinal number of the disk file, ranging from 001 to 999, and Dyy or DAT is the
VDS device index (VDS-0 yy = 00 and VDS-3 DAT).
The structure of the CDRs on disk files is shown in Figure 3 . The CDRs are sequentially numbered except
for headers and trailers. The header is located at the beginning and the trailer at the end of the block. The
size of the block and the length of the header are fixed. The header includes, for example, block sequence
number, length of actual data in this block, and time stamp. The number of CDRs in one block may vary
because of the different record lengths.
1st header
1st CDR record
2nd CDR record
1st block
N. CDR record
1st trailer 1st batch =
diskfile
n* FFs CF0001.Dyy /
EV0001.DA T
2nd header
N+1. CDR record
2nd block
M. CDR record
2nd trailer
n* FFs
20 th header
20 th block
20 th trailer
n* FFs
21 st header
2st batch =
21 st block diskfile
CF0002.Dyy /
EV0001.DA T
dn 00124271 x2 x0xen
Figure 3 : The structure of charging disk files
An example of charging data on a disk file is shown in Figure 4 . The contents of header and trailer records
are shown in Table 1 and Table 2 .
Figure 4 : An example of charging data in a disk file (65408B charging block used)
Table 1 : Description of header record fields
FIELD DESCRIPTION HEX FORMAT FIELD CONTENT

Record length 29 00 41 bytes
Record type 00 0 = header
Charging block size 08 size of charging block (default
= 8 = 65408 bytes)
Tape block type 01 00 charging block
Data length in block IF FF 65311 bytes (the header +
CDRs + trailer)
Exchange id 00 00 00 00 00 00 00 00 00 00 not in use
First record number 61 60 00 00 6061
Batch sequence number FF FF FF FF filled with FFs
Block sequence number 16 00 16
Start time 52 00 13 15 03 99 19 15 Mar 1999, 13:00:52
Format version 00 00 00 00 00 00 version of the header record
Table 2 : Description of trailer record fields
FIELD DESCRIPTION HEX FORMAT FIELD CONTENT

Record length 18 00 24 bytes
Record type 10 10 = trailer
Exchange id 00 00 00 00 00 00 00 00 00 00 not in use
End time 34 01 13 15 03 99 19 15 Mar 1999, 13:01:34
Last record number 64 64 00 00 6464
2.3 Charging control files

For each Virtual Data Storage (VDS), there are two separate pairs of charging control files located on the
disks of the OMU/STU unit, each pair containing the following files:
• TTSCOF (VDS Device Data Storage Control File)
• TTTCOF (VDS Device Data File Transfer Control File)
One control file pair is dedicated to the actual communication CDR files and another to the registration
CDR files.
The charging applications of both the billing system and the OMU/STU unit maintain the information
concerning the charging disk files in control files. Both of these files contain one record for each charging
disk file. For example, the information concerning disk file number 123 (CF0123.D00) can be found in the
record number 123. The first record (record number zero) of the TTSCOF is reserved for internal use of the
VDS device driver (VIDAST). The first record of the TTTCOF is not used. The file numbering starts from
one, so that the data file number is the same as the record number.
The file names TTSCOFyy.IMG and TTTCOFyy.IMG show the number of the VDS application (yy).
Note
In the DXT the zero record of the TTSCOF is reserved for the internal use of the VDS device driver (VIDAST)
and its structure can be changed without further notice.
The records of the TTSCOF contain three fields: status information (1 byte), time stamp (7 bytes), and the
save mode (1 byte). The time stamp structure is described in Table 3 .
Table 3 : Structure of time stamp field in TTSCOF
Offset (byte) Unit Example

23rd March 1999 10:35:42
0 seconds 42 BCD
1 minutes 35 BCD
2 hours 10 BCD
3 days 23 BCD
4 months 03 BCD
5 years 99 BCD
6 years (hundreds) 19 BCD
Every time the status of a charging disk file changes, the status information concerning this file is updated.
The possible statuses for a disk file are:
• OPEN (value 00H) - the data is written to the file. Only one file can have the open status at a time.
• FULL (value 01H) - the file is ready to be transferred to the post-processing system.
• TRANSFERRED (value 02H) - the file has been transferred to the post-processing system and can be
used again (overwritten) when needed.
• WAITING (value 03H) - the file waits to be compressed. Uncompressed files can be read from the disk.
• COMPRESSING (value 04H) - compression is in progress.
• UNUSABLE (value 05H) - the file cannot be used, because there is not enough space on the hard
disk to create it.
The TTSCOF file is updated only by the Virtual Data Storage (VDS) of the OMU/STU.
The records of the TTTCOF have a time stamp field only. It has a structure equal to the time stamp field of the
TTSCOF and contains the time information of the last successful charging disk file transfer from the OMU/STU
to the post-processing system. The TTTCOF time stamp field is updated only by the post-processing system.
Changes in the TTTCOF data when the DXT - post-processing system data transfer is brought into use
If the on-line data transfer from the DXT to the post-processing system is not in use, the time stamps of the
TTTCOF are set to year 3000. This means that all charging files are always marked as TRANSFERRED
(except the file that is open).
The following tasks need to be done when bringing the data transfer from the DXT to the post-processing
system into use:
1. If the currently OPEN charging file is the first file to be transferred, the time stamp field of every
TTTCOF record has to be set to the current date and time.
2. If there are other files to be transferred, the time stamps of the files in question (in the TTTCOF) have to
be set older than the time stamps in the TTSCOF.
Note
The size of the TTTCOF and TTSCOF is dynamic and depends on the number of the charging data files.
Functionality of the charging control files
Charging blocks are written to the disk file until the file becomes full, after which the file is closed. A new
charging file is opened when the first block is written. If the file does not exist on the disk, the system creates
it. At this moment the related record of the closed disk file in the TTSCOF is updated with the status FULL
and a time stamp of the file closing time. The time stamp field in the TTSCOF indicates the last time when the
status of the charging disk file was changed from OPEN to FULL, or from TRANSFERRED to OPEN. When
the status of a charging disk file changes from FULL to TRANSFERRED, the time stamp of the TTSCOF is
not updated. The possible state transitions are shown in the following figure:
OPEN UNUSEABLE
WAITING TRANSFERRED
COMPRESSING
FULL
dn 00124283 x1x0xen
Figure 5 : State transitions of charging disk files
The TTSCOF is updated in the following cases:
• the charging disk file is changed
• the MML command ZIFF or ZIFS is used
• after an OMU/STU switchover when the first data block is stored
• after an OMU/STU restart when the first data block is stored
• the TTTCOF time stamps were changed by the post-processing system
• file compression starts
• file compression is completed
The DXT periodically checks the time stamps of the TTTCOF and updates the TTSCOF if any changes are
made to the TTTCOF by the post-processing system.
The alarms for the VDS ring file system fill-up are set and reset at the same time when the TTSCOF
is updated.
The state of the disk files can be changed manually with an MML command. When the state is changed from
TRANSFERRED to FULL, the time stamp field of the TTSCOF is updated with the current time. When the
state is changed from FULL to TRANSFERRED, the time stamp field is reset.
A certain time period (for example, 30 minutes) can also be set after which the charging file is closed. The
next file is opened when the first block is written.
The size and number of charging disk files can be selected with parameters as described in Section 2.5 .
2.4 Storing capacity

The storing capacity is determined by the RAM block size, disk size, and data format. The size of the RAM
block is N (integer) times 8176 bytes. In the TETRA System, the value of N can be 1, 2, 4, or 8. The RAM
block size can be changed in steps of 8176 bytes by changing the corresponding parameter in the PRFILE.
Note
If the parameter value in the PRFILE is set to 0 (zero), the size of the RAM block is 2044 bytes.
CAUTION
When changing the RAM block size, make sure that a corresponding change is made in the post-processing
system.
The size of the disks must be larger than the number of the disk files multiplied by the size of one charging
disk file. The size of these disk files is determined by the operator and may vary from 10 kB to 32768 kB. It
must, however, be larger than the size of the RAM block. The maximum number of the files is 999. If the
size or amount of disk files is changed, the operator must make sure that enough disk space is available.
Changing the file size may temporarily require additional disk space. It can be obtained by deleting some of
the old files manually.
Approximately 1 GB of disk space is available for storing the charging data.
If the disk becomes full before all defined disk files have been created, the VDS restarts from the disk file
CF0001.D00 / EV0001.DAT and limits the number of files to the largest possible.
The amount of data stored depends on the record types generated in different call cases (see Chapter 4 ).
2.5 Configuration of VDS

The VDS system is configured using the Man-Machine Interface (MMI). In the OMU/STU unit, the virtual
data storage device VDS-0 is configured to store communication-related charging records and VDS-3
registration records.
The command group for changing and displaying the VDS configuration is IF. The following tasks can be
performed with this command group:
• change the charging disk file status
• set disk alarm limits
• define the size and amount of files on disk
• define time controls for changing disk files
• display control files
• interrogate disk file information
• copy charging disk files to a magneto-optical disk
• modify FTAM attributes (for example, file passwords).
For more detailed information, refer to document Data File Transfer from VDS Device to Postprocessing
System, dn9962025.
2.6 Logical file connections

The logical file is a method defined in the I/O system for hiding the actual I/O device from an application.
The reading and writing tasks that are directed to a logical file are routed to a physical I/O device according
to the control data contained in the file.
The DXT I/O system is in charge of the special facilities needed for each device and handles the operating
states of the equipment in a centralised way. Thus, an application can direct its I/O task to a logical file, and
the I/O system transfers it further to all the devices that have been defined in the logical file concerned. In a
fault situation the I/O system directs the output to a possible spare device. A maximum of four objects can be
connected to one logical file. The objects may be I/O devices or logical files.
The logical files concerned are CDFILE and HBLOFI. These files are used when data is stored to selected
devices, for example on disks.
When storing on disks, the recommended logical file connection is:
• The CDFILE is connected primarily to VDS-0 device.
The HBLOFI is connected to VDS-3 device.
These connections are defined by default.
• If the removable disk media (magneto-optical disk) is used, the Copy target parameter must have value
FDU-0 or FDU-1. The target can be set with the IFC command, for example:
IFC:STU:GENE00:1&&10,:TARGET=FDU-0,;
For further information, see the IFC command in document IF - Virtual Data Storing Device Handling,
dn99613829, in the DXT Command Reference Manual.
3 Transferring charging data
This chapter describes the process of transferring CDRs from the DXT exchange to an external billing system.
3.1 Transfer process using DXT hard disks

The actual communication CDRs are stored to one Virtual Data Storage (VDS) and the registration CDRs to
another. These VDSs can be accessed by different post-processing systems independently. Anyway, the
mechanism for transferring the data files is the same, i.e. the one described below.
The charging files that contain charging records are transferred from the OMU/STU disks to the
post-processing system by using the FTP (File Transfer Protocol) of the TCP/IP protocol stack. Also,
the FTAM protocol over an OSI/LAN connection can be used. The post-processing system acts as the
initiator of the transfer process. Figure 6 illustrates an example of transferring the files from the DXT to
the post-processing system.
POST-PROCESSING Y
SSTEM
FTP FTAM
TCP /IP OSI
DXT
OSI /LAN
INTERFACE
CMM/CCC
OMU RAM
buffer
TCP /IP/LAN
INTERFACE DXT
VDS
USB MO disk Hard disks

(DXTip)
Dn00124295x6x2xen
Figure 6 : Transferring CDRs from the DXT to the post-processing system
The different transactions during the CDR transfer are listed below, refer also to Figure 7 .
1. The post-processing system activates the file transfer to read the TTSCOF in the OMU/STU.
2. The post-processing system checks the statuses of charging disk files in the TTSCOF.
3. The post-processing system activates the file transfer and reads all the charging disk files with the
status FULL in the OMU/STU.
4. The post-processing system updates the time stamps concerning transferred disk files in the TTTCOF
file. The time stamp cannot be the same as the time stamp in the TTSCOF file but at least 1 second
more. This ensures that the file status is changed from FULL to TRANSFERRED after the transfer.
5. The post-processing system activates the file transfer to write the TTTCOF file in the OMU/STU.
OMU/STU Post-processing system
Charging diskfiles Charging diskfiles
3. read
CF 0001 .Dyy CF 0001 .Dyy
F
CF 0001 .Dyy T CF 0001 .Dyy
CF 0003 .Dyy A CF 0003 .Dyy
M
/
F
T
P CF 0999 .Dyy
CF 0999 .Dyy
CONTROL FILE
TTTCOF
timestamp timestamp
record for
timestamp timestamp CF 0001 .Dyy
timestamp 4.5 timestamp
write
timestamp F timestamp
record for
T CF 0999 .Dyy
A
CONTROL FILE M
TTSCOF
/ status timestamp
status timestamp
record for
CF 0001 .Dyy status timestamp F 1.2 status timestamp
T read
status timestamp status timestamp
P
status timestamp status timestamp

record for
CF 0999 .Dyy dn 00124302 x2x2xen
Figure 7 : Transferring communication-related charging disk files from the DXT to the post-processing system
Note
The charging file marked as OPEN and the file next to it (if the file is marked as TRANSFERRED) must not be
transferred to the post-processing system because it may prevent the storing of charging data on disks.
Note
After software update the post-processing system must read a new base for the TTTCOF file from the DXT
before it writes the TTTCOF in the DXT for the first time.
3.2 Transfer capacity

To provide LAN connectivity the DXT has LAN switches realised as follows:
• DXTs equipped with AHUB3-B blades with HBRT3-B rear transition modules provide L2/L3 LAN
interface with up to 10 Gb of transfer capacity.
• DXTs equipped with ESB24 cards provide L2/L3 LAN interface with up to 1000 Mb/s transfer capacity.
• DXTs equipped with ESB26 cards provide L2 LAN interface with either 10 Mb/s, 100 Mb/s or 1000
Mb/s transfer capacity.
• In case the DXT does not have internal LAN switches, at least 1 Gb transfer capacity is provided
by the LAN interfaces.
Because of the possible limitations of the transfer capacity, it is recommended that the charging data be
transferred from the DXT to the post-processing system only once. In case several copies of the charging
records are needed, it is advisable to make the copies in the post-processing system.
3.3 Transfer control

Two control files in the VDS manage the transfer process: TTSCOF and TTTCOF. Their function is described
in Section 2.3 .
The use of control files ensures that no files are lost during the transfer.
3.4 Networking
Each DXT has its own VDS system, and charging records are generated and stored locally and independently
in every DXT of the TETRA System. The external post-processing system is connected only to one DXT
in the network. Therefore, CDRs are transferred from all DXTs to the post-processing system through the
exchange which is directly connected to the post-processing system as described in Figure 8 .
DXT
Post-processing system
OMU TCP /IP/OSI , LAN

(STU)
FTAM / FTP
File Transfer
TETRA System
O&M Network
OSI Routing
DXT DXT
TCP /IP,
OSI ,
X.25 , OMU
OMU
(STU) LAN (STU)
dn 00124314 x4x1xen
Figure 8 : Networking of DXT exchanges for CDR collection
The TETRA System itself is used for the transfer of charging information to the post-processing system.
File transfers from other exchanges utilise internally the O&M network based on the X.25 connection over
multiple 64 kbit/s timeslots.
The remote post-processing system initiates the transfer and collects the CDRs from each DXT in turn,
using OSI transmission routes configured between the post-processing system and each exchange. The
OSI routes use an OSI stack available in the OMU of each exchange.
Alternatively, all the DXT exchanges in the network may be connected via LAN to a router which is connected
to the post-processing system. In the case of IP-only connected DXTs, this is the only alternative, as their use
of transmission is entirely based on IP. See Figure 9 .
Post-processing system
FTAM (OSI ), FTP (TCP /IP)

LAN
Wide Area Network (WAN)
DXT
FTAM
(OSI )
FTP (TCP /IP)
LAN
dn 00124326 x2x1xen
Router
Figure 9 : CDR collection
3.5 FTP File transfer protocol

The FTP offers the data transfer services of a TCP/IP network . The DXT 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. The transfer process with the control files and the networking principles are briefly
the same with the FTP as described with the FTAM below. When using FTP, transfer connection can be
done directly from the OMU/STU units. Logical IP addressing enables IP address swapping between LAN
interfaces. For more information, refer to the integration manual of the DXT type in question.
3.6 OSI protocol stack

The Open Systems Interconnection (OSI) is a standard protocol stack that enables communication between
two computers. The implementation of the OSI allows the File Transfer, Access and Management (FTAM)
protocol to be used for the transfer of charging information from a DXT to a remote computer system
(billing system).
The OSI software used in the DXT is implemented in accordance with the standards shown in Figure 10
and is compatible with commercial OSI programs.
APPLICATION PROGRAMS
FTAM CMISE VT
ACSE ROSE ACSE ACSE
OSI PRESENT ATION LAYER
OSI SESSION LA YER APPLICATIONS

USING P AD (X.29 )
OSI TRANSPOR T LAYER PAD, X.29
ISO IP CCITT X.25 PLP

ESIS CCITT X.25 LAPB
IEEE 802 .2 Procedures of Individual
IEEE 802 .3 transmission links
Physical signalling V.24 , V.35 , X.21 , G.703
dn 00124338 x1x0xen
Figure 10 : OSI protocol stack
The X.25 interface consists of plug-in units each offering one data communication channel. The digital X.25
AS7 is used to implement digital X.25 function and to establish the G.703 interface.
File transfer, access and management (FTAM)
The OSI protocol stack is mainly used by the application software. Application programming interfaces are
available for the use of the FTAM. The FTAM enables applications to copy files.
The FTAM is a standard of the ISO-OSI model application layer, which contains the services independent of
environment and the protocol for the transfer, access and management of files.
4 Charging records
This chapter describes what types of CDRs are available in the DXT and how they are selected for
generation. Each CDR type is explained in detail.
4.1 Selection of charging records for generation

By using the MML command GTI it is possible to print out a list of those charging records that are at the
moment generated in the DXT. This command displays activated CDRs of both originated and terminated
calls.
The MML command GTM is used to select the CDRs that are generated in the DXT. The CDR generation
parameters define for each CDR type whether CDRs of this particular type are generated or not.
New CDR forms can be activated by using the MML command GAE.
For further information about MML commands, refer to documents GA - Dynamic Data Handling, dn98908517,
GE - CDR and Report Saving Handling, dn98908505 and GT - Detailed Charging Handling, dn98793148 in
the DXT Command Reference Manual.
4.2 CDR content formatting

The exchange produces different types of CDRs, depending on the recorded events such as individual call,
group call, packet data connection or short data service. For further information, see Section 4.3 . Each CDR
type has a different format, in other words, the set of included information items ('fields') varies from type to
type. The format of each CDR type is fixed, meaning that all CDRs of one type have the same format.
It is also possible to tailor the CDR formats according to specific needs. The default format usually contains
all information that can be included in that CDR type. Thus the tailoring means in practice the possibility to
leave some unnecessary fields out of the CDRs. It also means that it is not mandatory to add to the CDRs
new fields introduced by new features when, for example, implementing new system releases. For tailoring,
customer specific CDR format files need to be ordered from Airbus Defence and Space. In the system
upgrade from one release level to another, no CDR format changes are automatically made.
Adding fields that are not included in the default format is usually not possible without additional software
development work. This kind of needs should be discussed with Airbus DS case by case.
Available data for each CDR type is described in detail in Section 4.4 .
4.3 Charging records of different events
4.3.1 Individual calls

Radio subscriber or dispatcher calls another radio subscriber or dispatcher
In individual calls, the call messages are transmitted and the corresponding CDRs including TETRA
originated (TOC) and TETRA terminated (TTC) call records produced in the master exchange of the call, that
is, in the exchange where the calling party exists at the beginning of the call. Gateway records for incoming
calls (InG) and outgoing calls (OutG) are generated in the gateway DXTs.
A TOC record for the calling subscriber and a TTC record for the called subscriber are produced for each
individual call and call attempt.
The chargeable call duration commences when the call is started (connection is established) and ends
when the call is cleared. Possible hold and resource waiting time during the call setup and handover is
not included in the chargeable duration.
If alias profiles are used in the system, the contents of the fields showing the identity of the calling or the
called party may differ according to the identity used in the call. In the TOC record, for example, the Served
number field may contain the calling subscriber's own radio subscriber identity or his/her primary alias
identity. The Connected number field may contain the called party's radio subscriber identity or his/her
primary alias or secondary alias identity depending on which of these numbers was selected. These fields
are used in the similar way in the SDS-TO record.
Radio subscriber or dispatcher calls another radio subscriber or dispatcher over the Inter-System
Interface
If an individual call is made over the Inter-System Interface (ISI) to a radio subscriber or a dispatcher in
another TETRA network
• TOC and OutG records are generated in the originating network for the calling subscriber
• InG and TTC records are generated in the destination network for the called subscriber.
If an individual call is routed from the originating network to the called party's home network over the ISI and
from there, again over the ISI, to a third network where the called party is migrated, the charging records are
generated as follows:
• TOC and OutG records in the originating network
• InG and OutG records in the called party's home network
• InG and TTC records in the terminating network.
When making individual calls over the ISI, ITSI and MSISDN numbers can be used as the calling party
identification and ITSI numbers as the called party identification.
The Other SwMI MNI field in the OutG and InG records contains the Mobile Network Identity (MNI) of the
other party's network, that is, the MNI of the receiving TETRA network in the OutG record and that of the
sending TETRA network in the InG record.
The call identifier given in the Call reference field links together the charging records generated from the
same individual call within one network.
Notice that ISI is supported by E1-connected DXTs only.
Radio subscriber or dispatcher calls a PABX/PSTN subscriber
A TOC record is produced for the calling subscriber and an OutG record for the called subscriber.
Note
No charging pulses are transmitted to an external network.
PABX/PSTN subscriber calls a radio subscriber or a dispatcher
When a PABX/PSTN subscriber makes an individual call to a radio subscriber or dispatcher, an InG record is
produced for the calling subscriber and a TTC record for the called TETRA subscriber.
PABX/PSTN subscriber calls a radio subscriber or a dispatcher over the Inter-System Interface
If the call from the PABX/PSTN is routed to the TETRA subscriber's home network while the subscriber is
migrated in another TETRA network, the home network routes the call to the subscriber's location network
over the ISI interface. The charging records are generated as follows:
• InG record in the incoming gateway DXT for the calling PABX/PSTN subscriber
• OutG record in the home network for the called TETRA subscriber
• InG and TTC records in the network for the called TETRA subscriber.
A call from a PABX/PSTN subscriber cannot be switched to a third TETRA network.
Individual call to group dispatchers
In an individual (hook) call to a group address all dispatchers of the group are alerted. When one of them
answers, a normal point-to-point call is established. The charging information is handled as in normal
individual calls with the following exception: in the TOC record, the Called number field and the Connected
number field contain the group address (NGTSI). In the TTC record the organisation block information
is not available.
If the call is made over the ISI interface, the charging records are generated as follows:
• TOC and OutG records for the calling party in the originating network
• InG and TTC records for the called party in the destination network.
An individual call to group dispatchers cannot be switched to a third TETRA network.
4.3.2 Forwarded individual calls

A call can be forwarded either to a voice mail, or to another subscriber number in the same TETRA network
or in the PSTN/PABX network.
A forwarded call generates the following CDRs:
- a TOC or an InG record for the calling subscriber (InG record in the case of a PSTN/PABX originating call),
- Forw record for each party forwarding the call,
and
- a TTC or OutG record for the called party (OutG record in the case the call is forwarded to a PSTN/PABX
number).
Note that a separate Forw CDR is created for each consecutive call forwarding that happens during the call.
The Forw CDR is generated at the end of the call if there are no further forwardings, or at the moment of the
next call forwarding or transfer. The Forw records for the same call contain the same call reference number.
Refer to Chapter 4.4.5 for the fields of the Forw CDR, and to Appendix C.1.3 for examples on contents of
CDR fields in different call forwarding cases.
4.3.3 Transferred individual calls

Call transfer involves several phases which result in production of CDRs. Basically, the CDR generation
takes place as in normal individual calls.
In a call transfer, CDRs are produced for the following call phases:
• for the call from the calling subscriber to the transferring dispatcher
– TOC and TTC records if the calling subscriber is a TETRA subscriber
– InG and TTC records if the calling subscriber is a PSTN/PABX subscriber
• for the call from the transferring dispatcher to the actual called subscriber (optional call)
– TOC and TTC records if the called subscriber is a TETRA subscriber
– TOC and OutG records if the called subscriber is a PSTN/PABX subscriber
• for the call transfer
– Forw record for the transferring dispatcher
(Note that a Forw CDR is created separately for each call transfer event. See Chapter 4.3.2 .)
• for the transferred call from the original calling subscriber to the actual called subscriber
– TOC and TTC records if the calling and the called subscriber are TETRA subscribers
– TOC and OutG records if the calling subscriber is a TETRA- and the called subscriber a
PSTN/PABX subscriber
– InG and TTC records if the calling subscriber is a PSTN/PABX- and the called subscriber is
a TETRA subscriber.
Among the different phases of a call transfer, the optional call from the transferring dispatcher to the actual
called subscriber is considered as a separate call with its own call identifier. All other phases are identified by
one and the same call identifier.
Charging records are also produced for all unsuccessful call transfer attempts.
TOC record
TOC record for the calling TETRA subscriber is generated in the calling subscriber's DXT.
The record is generated in two parts, the first part being for the call between the calling subscriber and the
transferring dispatcher and the second for the transferred call between the calling and the actual called
subscriber.
TTC record
TTC record for the called TETRA subscriber is generated in the same DXT as the corresponding TOC or
InG record.
The TTC record is generated in two parts if the actual calling subscriber is a TETRA subscriber. The first
part is generated for the call between the called subscriber and the transferring dispatcher and the second
for the transferred call between the original calling and the actual called subscriber. If the actual called
subscriber is a PSTN/PABX subscriber, the TTC is generated only for the part of the call made between the
calling subscriber and the transferring dispatcher.
InG and OutG records
InG record for the calling and OutG record for the called PSTN/PABX subscriber are generated in the
gateway DXT.
The InG record for the external calling subscriber is generated in two parts, the first part being for the call
between the calling subscriber and the transferring dispatcher and the second for the transferred call between
the calling and the actual called subscriber. The OutG record is generated only for the part of the call made
between the original calling subscriber and the actual external called subscriber.
Forw record
Forw record for the transferring dispatcher from the call transfer event itself is generated in the original
calling subscriber's DXT. If the calling subscriber is a PSTN/PABX subscriber, the Forw record is produced
in the incoming gateway DXT.
If the actual called subscriber is a TETRA subscriber who has forwarded his/her calls, additional Forw and
OutG records are created instead of the TTC record for the transferred call between the original calling and
the forwarded-to number. Note that a separate Forw CDR is created for each consecutive call transfer or
forwarding that happens during the call (see Chapter 4.3.2 ).
4.3.4 Group calls

Group calls within a TETRA network
In group calls, a TOC record is produced for the calling subscriber who can be either a radio subscriber using
a radio subscriber identity or alias identity, a DWS user, or a G4WIF member. No information is stored
about the called subscribers.
The TOC record of a group call is generated in the home exchange of the group. In case there is no
connection to the home exchange and a group call is generated in the area DXT, the TOC record can
be produced in the area DXT.
A TOC record is also produced for a dedicated data group call, which is used to reserve a traffic channel
exclusively for sending SDS and status messages. The CDR fields are filled as in normal calls. Because
there are no inactivity timers in dedicated data group calls, the calls tend to be longer than normal group calls.
In a location-based group call, when a radio subscriber makes a call setup to a cover group, the cover
group address is visible in the CDR as the called number. The charging record, however, is generated
for the local group.
Only one charging record is produced for a combined group call. This record is created for the base group
in a normal way so that the Number of members, Traffic channel usage and Allocations fields cover the
information of the whole combined group call. In addition to this, the system provides information about the
combining and a GTSI list of all groups that belong to the combined group.
A CDR form for a charging record containing fields for combined group calls can be ordered from Airbus
Defence and Space. All groups that have been combined during a call are visible in the CDRs even though
the groups have not necessarily been combined for the whole duration of the call.
In group calls, the total duration of the call is recorded as the chargeable duration. A pseudo open channel
group call ends when the inactivity timer expires or the dispatcher releases the call.
Either the calling subscriber or the group can be charged. The decision is made by the post-processing
system.
Group calls over the Inter-System Interface
For ISI-linked group calls that cover several TETRA networks linked together over the ISI interface, charging
records are generated in each network involved in the call, that is, in the originating and in the controlling
network and in all participating networks. The controlling ISI group, to which all other groups are linked,
can also act as an originating ISI group.
If an ISI-linked group is a base group in a group combination the charging records are created for the base
group in a normal way.
For ISI-linked groups, a TOC record is created in the home exchange of each group and InG/OutG records
for each ISI connection in the gateway exchanges. When a group call is originated in a network other than
the controlling network, charging records are generated as follows:
• call setup from the originating network to the controlling network:
- TOC and OutG records for the originating group in the originating network
- InG and TOC records for the controlling ISI group in the controlling network
• call setup from the controlling network to each participating network:
- OutG record for the controlling ISI group for the ISI connection to each participating ISI group
excluding the original originating group.
- InG and TOC records for each participating ISI group in participating networks excluding the original
originating group.
For each attempt to expand a group call to another TETRA network by sending late entry messages over the
ISI interface, an OutG record is created with a dummy value for the calling party.
Charging records are also produced for all unsuccessful group call attempts.
CDR fields in ISI-linked group calls
When OutG and InG records are generated between ISI-connected networks, the Other SwMI MNI field in
these records contains the Mobile Network Identity (MNI) of the other network, that is, the MNI of the receiving
TETRA network in the OutG record and that of the sending TETRA network in the InG record.
The GTSI number of the controlling ISI group is used in the Transmitted number field in OutG records and in
the Called number field in InG records in all networks involved in an ISI-linked group call.
The call identifier given in the Call reference field links together the charging records (TOC, InG, OutG)
generated from the same group call within one network. The GTSI number of the controlling ISI group links
together the charging records generated from the same group call in all networks involved in the call.
Further information on the contents of CDR fields in an ISI-linked group call can be found in Section C.1.5 .
4.3.5 Short data and status messages
4.3.5.1 SDS and status message transfer within a TETRA network

SDS and status message to an individual address
An SDS-TO record is produced for each SDS and status message sent by a TETRA subscriber (radio
subscriber or an alias subscriber, a DWS user or a TCS client) or received from an SMSGW. Messages
coming from the SMSGW can have their origin in the TETRA network or an external network.
The SDS-TO record is generated in the exchange where the sending subscriber exists at the beginning of the
SDS or status transmission or in the exchange to which the SMSGW is connected. For more information on
generating CDRs for SDS messages transmitted via SMSGW, see Section C.2.3 .
SDS and status message to a group address
When sending an SDS or status message to a group, an SDS-TO record is produced for the sending
subscriber in the sending subscriber's home exchange.
In location-based group communication, when an SDS or a status message is sent to a cover group address,
the charging record is generated for the cover group.
When an SDS or a status message is sent to a combined group, only one charging record is produced.
This record is created for the base group in the originating DXT. A field listing all groups of a combined
group to which the message was delivered can be included in this CDR. If the message was delivered to
the original group only, the CDR is created only for that originating group without group list. A CDR form
for creating a CDR with fields for data message delivery to a combined group can be ordered from Airbus
Defence and Space.
4.3.5.2 SDS and status message transfer over the Inter-System Interface
SDS and status message to an individual address
For an individually addressed SDS or status message sent to another TETRA network over the ISI interface,
SDS-TO and InG/OutG records are created as follows:
• SDS-TO record is generated in the originating network and in the recipient's home network and possibly
in the terminating network if the recipient has migrated to another network.
• OutG record is generated in the originating network and possibly in the recipient's home network if
the recipient has migrated to another network.
• InG record is generated in the recipient's home network and possibly in the terminating network if
the recipient has migrated to another network.
SDS-TO records are generated in the exchange of the sender and in the incoming gateway DXT(s) of the
recipient. The InG and OutG records are created in the gateway DXTs.
SDS and status message to a group address
When a group addressed SDS or status message is sent to another TETRA network over the ISI interface,
SDS-TO and InG/OutG records are created as follows:
• SDS-TO record is generated in the originating network and in the home network of the receiving group
• OutG is generated in the originating network
• InG is generated in the home network of the receiving group.
SDS-TO records are generated in the exchange of the sender and in the incoming gateway DXT of the
receiving group. The InG and OutG records are created in the gateway DXTs.
SDS and status message to an ISI-linked group
When an SDS or status message is sent to an ISI-linked group, charging records are generated in each
network involved in the message transfer, that is, in the message originating and in the controlling network
and in all participating networks.
When a message is originated from a network other than the controlling network, the charging records are
generated as follows:
• SDS-TO and OutG records for the originating group in the originating network.
• InG, SDS-TO and OutG records for the controlling ISI group including the OutG record for the
connection to the originating network.
• InG and SDS-TO records for each of the participating ISI groups in the participating networks including
the originating group as also this receives the SDS or status message from the controlling network.
For a group addressed SDS or status message sent over the ISI interface, SDS-TO records are created in
the exchange of the sender and in the incoming gateway DXT of each participating group. The OutG/InG
records are created in the outgoing and incoming gateway DXTs for each ISI connection.
If an ISI-linked group to which the message is sent is a base group in a group combination, the charging
records are created for the base group in a normal way.
CDR fields in SDS and status message transfer over the ISI interface
The Other SwMI MNI field in the OutG and InG records contains the Mobile Network Identity (MNI) of the
other party's network, that is, the MNI of the receiving TETRA network in the OutG record and the MNI of the
sending TETRA network in the InG record. For incoming SDS or status messages to an ISI-linked group, the
Other SwMI MNI field is not available as its contents are not transmitted over the ISI interface.
When sending an SDS or status message to an ISI-linked group, the GTSI number of the controlling ISI group
is used as the group address in OutG/InG records of all networks involved in the message transfer.
The call identifier given in the Call reference field links together the charging records (SDS-TO, InG, OutG)
generated for the transfer of one individually or group addressed message within one network. When a
message is sent to an ISI-linked group, the GTSI number of the controlling ISI group links together the
charging records generated in all networks involved in the message transfer.
4.3.5.3 Preventing CDR generation
There are two ways of preventing CDR generation of data messages within or between TETRA networks.
The first way is to prevent charging of all data message types and the second way is just to prevent charging
of AVL messages.
4.3.6 Packet data

Packet data CDRs are designed and used primarily for charging purposes.
Two types of packet data service are supported in the TETRA System: packet data according to TETRA
Enhanced Data Service (TEDS) and packet data without TEDS functionality. Both packet data types use the
same PD record and the same CDR fields.
The packet data service of the TETRA System may potentially transmit IPv4 and IPv6 datagrams (Network
Layer Protocol Data Units). The scope of the charging is to generate information primarily for charging the
Network Layer (IPv4 and IPv6 Network layer) events within the scope of the TETRA System. Charging
information of the upper level protocols (TCP, Transmission Control Protocol, UDP, User Datagram Protocol
etc.) is not collected.
The point of view of the PD record generation is always a radio; each CDR is related to a distinct radio
subscriber.
Packet data charging can be based on one or some of the following characteristics of the service usage:
• Transferred data volume
• Duration of the PD context is most often related to a user session. This may contain a remarkable
percentage of inactivity time, however, this may be desired to partially influence the charging in some
cases.
• Duration: the amount of time the MS occupied the packet data channel/radio channel (CDR-generated
in case of cell re-selection, the CDR carries information on the amount of time the MS occupied the
packet data channel on the previous cell)
• Number of packets transferred. The length of the packets may vary considerably, however, the number
of them may be desired to partially influence the charging in some cases.
Access point name
Access Point Name (APN) is an optional field that can be added to the CDR. In the TETRA IP backbone
network the APN is a reference to a GGSN (Gateway GPRS Support Node), a gateway to an external IP
network. The APN is composed of two parts, the APN Network Identifier and the APN Operator Identifier. The
APN Network Identifier defines to which external IP network the GGSN is connected to. It is used within
an operator's IP network to find out, by using a DNS (Domain Name System) server, the IP address of the
specific GGSN to which the PDP (Packet Data Protocol) is to be established; and then within that GGSN, a
specific external network and relating data (for example used AAA, DHCP servers) are detected. The APN
Operator Identifier defines in which TETRA IP backbone network the GGSN is located.
CDR generation
The chargeable unit of packet data in time is a PD activity period. A PD activity period starts with the 1st
radio channel reservation and ends with the last radio channel release. One activity period is identified with
a PD context reference. One PD context can contain several activity periods. Also the total PD context
duration is recorded.
It is possible to generate partial records at fixed intervals to enable smooth charging of PD contexts having
long activity periods. The interval is configurable by a system parameter. Typical values could be 30 - 60 min.
A packet data record is generated when:
• the PD context is successfully created (if used)
Release 7.0 feature.
• the PD context creation fails (if used)
Release 7.0 feature.
• the PD context is released
• the PD transfer ends and the MS is allocated back to common control channel (including the time
duration the MS was on the PDCH)
• MS makes a cell re-selection during the packet data transfer (including the duration the MS was on
the packet data channel on the previous cell)
• the interval for partial record generation is elapsed (if used)
• any of the counters cumulating for charging data, for example, a number of octets or number of
datagrams, would overflow.
CDRs are generated by the DXT that owns the PD context being charged.
CDRs are produced also on unsuccessful IP packet data service usage attempts, when the packet data
transfer does not succeed, for example, due to lack of rights or system resources. That is, CDRs are
generated based on the packet data context creation, in the case of rejection of context activation and
rejection of data transmission attempt.
An illustration of the timing of channel occupations, for example PD activity periods and CDR generation, is
presented below (In TETRA1 PD the channel is reserved for one user, in TEDS PD the channel is shared
by several users).
PRSN = Partial Record Serial Number
CDR (PRSN =1) CDR (PRSN =2) CDR (PRSN =3) CDR (PRSN =4)
Partial record
timer period
ch . occup . inact . channel occupation inactivity
T1 T2 T3 T4 T5 T6 T7
time
PD context
IP address IP address
negotiation dn 00125064 x1x0xen release
Figure 11 : CDR generation
Event time stamps
Each CDR contains one or more event time stamps, which are:
• Setup time: The time when the radio user activates the PD context, that is, takes the IP packet data
service into use. This time stamp is present in all CDRs of the same PD context.
• Connect time: The start time of the channel allocation of the PD activity period recorded in this CDR. If
no data is transferred, this time stamp value is insignificant (filled with 0FFH).
• Channel release time: The end time of the channel allocation of the PD activity period recorded in this
CDR. If no data is transferred, this time stamp value is insignificant (filled with 0FFH).
• Deactivation time: The time when the PD context is deactivated, that is, the user has stopped using the
IP service. This time stamp is present only in the last CDR of the PD context. In other CDRs this time
stamp value is insignificant (filled with 0FFH).
Example: The time stamps T1 to T7 in Figure 11 are recorded in the CDRs according to Table 4 .
Table 4 : Time stamps
CDR number Setup time Connect time Channel release Deactivation

time time
1 T1 T2 T3 -
2 T1 T4 - -
3 T1 T4 T6 -
4 T1 - - T7
4.3.7 Unsuccessful calls
Call messages and corresponding CDRs are produced also on unsuccessful call attempts. The reason for
a call not to be established can be, for example, inadequate call rights or lack of resources. Similarly, a
charging record is generated for all failed attempts to send an SDS or status message.
4.3.8 Registrations
The registration records enable the billing systems or other customer applications to collect and archive
information about the registrations of the subscribers.
The CDR generation is activated with the charging parameter Reg CDR generation. A CDR is generated
for each initial registration (ITSI attach) and de-registration (ITSI detach) of a radio subscriber as well as
for all migrating registrations. The information in the registration CDR contains for example the ITSI of the
registered subscriber, location-, authentication- and encryption information and the type, time and result of
the registration. From Release 7.0 onwards CDR also contains subscriber class information and the radio
channel type used for registration signaling: Main Control Channel (MCCH), Secondary Control Channel
(SCCH) including also the channel number (1, 2 or 3), TETRA Enhanced Data Service (TEDS) and Traffic
Channel (TCH). These Release 7.0 additions are introduced when new CDR forms are used.
A registration CDR is also generated for Radio User Assignment/Disassignment (RUA/RUD) -type operations
of alias subscribers.
The registration CDR can contain the TETRA Equipment Identity (TEI) if it is available in the system. The
TEI can be provided in the registration by the itself if TEI query is enabled in the system and supported by
the radio terminal, or it can be extracted from the subscriber’s authentication data. The TEI - ITSI pairs
can be used for example
• to query the present or the latest user
• to see whether and when the user has been authenticated.
The charging parameter Include roaming registration to reg cdr enables the generation of an enhanced
registration CDR. When this parameter is enabled, a CDR is generated for all roaming type registrations,
which, in addition to the registration types mentioned above, include periodic, forward and implicit
registrations, for example. If the ITSI enabled/disabled functionality is in use, a CDR is also generated for
all roaming type registrations of a temporarily disabled radio terminal.
The Include roaming registration to reg cdr parameter also affects the usage of the fields containing
location update information in the registration CDR. If this parameter is disabled, the fields Previous DXT id
and Previous location area are always filled with default values. If the parameter is enabled, these fields
contain the real values.
Generation of registration CDRs is independent of communication CDRs. The results are saved by default
to specific files in a specific directory. It is, however, possible to store the registration CDRs to the same
files together with communication CDRs.
4.4 Charging record types
The detailed format and contents of the charging records available in the TETRA System are described in
this section.
Note
The fields showing the text (currently not available) are at the moment not implemented in the TETRA
System but will be filled with dummy values.
The value of the Record Version field increases in steps every time the specification of the CDR contents
is changed.
The checksum in the corresponding record field is calculated by adding the bytes included in the data block
and dividing the sum by the figure 65536. The resulting remainder forms the checksum.
The call duration is not counted from the event time stamps because the system time may be altered during
the call, for example, when the winter time changes to summer time.
The call duration may have slightly different values in the TOC and OutG records of the same call, as the
possible breaks in the radio path are not included in the call duration calculated for the TOC record. The
same applies to the TTC and InG records.
The column Len defines the length of the record field in bytes. In column Data type word is a variable of two
bytes and dword (doubleword) is of four bytes. Word and doubleword are used so that the least significant
byte is first in the memory and the most significant is last. For example, when the data type is dword and the
value is 82901H, the corresponding successive bytes in memory are 01H, 29H, 08H, 00H. When the data type
of the field is structured, the definition is shown and the data type is described in more detail in Appendix A .
For concepts of NITSI and NGTSI appearing in the following tables, refer to Appendix B .
4.4.1 TETRA originated call attempt record (TOC)

A TETRA originated call attempt (TOC) record is created for each call attempt originated by a TETRA
subscriber.
The total size of a TOC record is 271 bytes.
Table 5 describes the TOC record fields.
Table 5 : TOC record
Field Description Len Data type Values

Record length Length of TOC record (bytes). 2 word 271
Record type TETRA originated. 1 byte 1 = TOC record
Record version Version number of the record 1 byte 1...0FFH
structure.
Recording entity The identity of the DXT that 4 dword, 0 = DXT id unknown
produced the record. system_id_t
Table 5: TOC record (cont'd.)

Checksum Checksum of the fields below. 2 word 0…0FFFFH
Recording A local record sequence number 2 word 0...0FFFFH
sequence at the recording entity. This is for
number audit purposes only.
Partial record If partial records are produced, 1 byte 0...0FFH,
sequence they shall be numbered for each 0 = no partial records
number call.
(currently not
available)
Number of Total number of partial records 1 byte 0...0FFH
partial records related to this call and produced
(currently not for the served party.
available)
Number of Total number of SS records 1 byte 0...0FFH
SS records related to this call and produced
(currently not for the served party (if there are
available) any call related SS events).
Number of Total number of TOS records 1 byte 0...0FFH
TOS records related to this call.
(currently not
available)
Number of Total number of NRU records 1 byte 0...0FFH
NRU records related to this call.
(currently not
available)
Number of Total number of trunk usage 1 byte 0...0FFH
trunk records records related to this call.
(currently not
available)
Call reference A local identifier distinguishing 4 dword, 0...0FFFFFFFFH,
between transactions for the cc_call_id_t 0 = dummy value when
served party. The same call no call identifier assigned
reference shall be used for all
records (partial, supplementary,
and so on) during one call.
Served number Number (= radio subscriber 10 bcd coded bcd,
identity or the primary alias phone number see Appendix A
identity) of the calling party. If
applicable, this is in MSISDN
format. Otherwise NITSI format.
Served NITSI As above, NITSI format. 10 bcd coded bcd,
phone number see Appendix A
Organisation The organisation block of the 12 org_block_id_t Array of six words,
block served (calling) party. see Appendix A

Called number The number dialled by the calling 14 bcd coded bcd, see Appendix A
party (NITSI, NGTSI, MSISDN, phone number
or FSSN).
Translated The called number after number 14 bcd coded bcd, see Appendix A
number modification within the DXT, phone number
MSISDN format if applicable,
otherwise NITSI or NGTSI.
Translated As above, NITSI or NGTSI 10 bcd coded bcd, see Appendix A
NITSI format. phone number
Connected Number (= radio subscriber 14 bcd coded bcd, see Appendix A
number identity or the alias identity) of phone number
the connected party.
This number may be the same
as the Called number and/or
Translated number. This is in
Connected As above, NITSI or NGTSI 10 bcd coded bcd, see Appendix A
NITSI format. phone number
Connection The connection group number if 2 word 0...0FFFFH,
group the called subscriber is a PSTN 0FFFFH = unknown
or PABX subscriber.
Connected DXT The identity of the DXT of the 4 dword, 0 = DXT id unknown
id called party. system_id_t
Served DXT id The identity of the DXT of the 4 dword, 0 = DXT id unknown
served party. system_id_t
Location area The location area of the served 2 word, 0...03FFFH and
party. ntn_la_t 0FFFFH = LA information
not used, 0FEFEH = All
LAs in the DXT
Cell identity The identity of the cell of the 1 byte, 0...3FH and 0FFH = cell
served party. ntn_cell_t information not used,
0FEH = all cells of the LA
Basic service The parameters of the service 4 basic_ Structure of four bytes,
used employed. service_t see Appendix A
Basic service The parameters that were 4 basic_ Structure of four bytes,
requested requested for the service. service_t see Appendix A
Call priority Call priority requested for the 1 byte, 0...15, see Appendix A
call. setup_
priority_t
Urgency class Urgency class granted for the 1 byte, 0...6
call. urgency_ 0FFH = unknown
class_t See Appendix A

Queuing priority Resource queuing priority 1 byte, 0...240 and
granted for the call. call_ 0FFH = unknown
priority_t
Full / Half duplex MS frequency full / half duplex 1 byte 0 = half duplex,
operation requested / granted. 1 = full duplex,
0FFH = unknown
Hook method The hook method requested / 1 byte 0 = no hook sign. (direct
granted. connection)
1 = hook on/off signalling,
0FFH = unknown
Air I/F Indication whether air interface 1 byte 0 = encryption is not
encryption encryption is used or not. used,
1 = encryption is used,
0FFH = unknown
Number of Number of members at the 2 word 0...100 members shown
members in the beginning of a normal / combined (default)
group / location-based group call. 101...10 000 members
shown (definable by
system parameter 373)
0FFFFH = unknown
NOTE: The default is that 0...100 members are
shown.
In order to show more than 100 group members,
the system parameter 373 Max MS count in group
call ToC has to be defined to have a greater value
than 1. The parameter values (1–100) are multipliers
for 100. E.g. value 50 means max. 50*100 = 5000
subscribers shown in TOC.
In the case of a location-based group call, the value
is always 0FFFFH (unknown).
Allocations*) Total number of traffic channel 2 word 0...0FFFFH
allocations during a normal or a
combined group call.
In a dedicated data group call,
the same traffic channels can be
allocated to the call more than
once.
Channel usage Total cumulative usage time for 4 dword, 0...0FFFFFFFFH (unit is
time all traffic channels that were used duration 10 milliseconds)
during a normal or a combined
group call.
During a dedicated data group
call, the traffic channels not in
use can be released and later
reserved again.

Number of Tells the amount of groups 1 byte 0 = not combined
groups involved in a combined group 2-8 = number of
call. combined groups
List of groups Tells the NGTSIs of the groups 80 bcd coded 8 bcd coded 10-byte
involved in a combined group number GTSIs
call.
Event time Setup time (Call setup was 8 calendar_ Structure of 6 bytes
stamps started). time_t and a word: hundredths
of seconds, seconds,
minutes, hours, day,
month, year in bcd form,
see Appendix A
Answer time (Call was answered: 8
in group calls this is a dummy
value).
Connect time (Call entered into 8
progress).
Release time (Call was 8
released).
Call The chargeable duration of the 4 dword, 0...0FFFFFFFFH (unit is
duration connection (connect → release) duration 10 milliseconds),
for successful calls, the holding 0 = unknown or
time (setup → release) for call insignificant value
attempts.
Cause for The reason for the release of the 1 byte, 0...9,
termination connection. term_cause_t see Appendix A
Diagnostics For internal use of Airbus DS. 2 word,
rc_t
*) The same channel is calculated only once except in the case where the call in the area of a certain
DXT is released and started again during the call.
4.4.2 TETRA terminated call attempt record (TTC)

A TETRA terminated call attempt (TTC) record is created for each call attempt terminated to a TETRA
subscriber. In the TETRA System these records are produced only for the called subscriber in a point-to-point
call.
The total size of a TTC record is 133 bytes.
Table 6 describes the TTC record fields.
Table 6 : TTC record
Field Description Len Data type Value

Record length Length of TTC record. 2 word 133
Record type TETRA terminated. 1 byte 2 = TTC record
Record version Version of the record structure. 1 byte 1...0FFH
Recording The identity of the DXT that 4 word, 0 = DXT id unknown
entity produced the record. system_id_t
Recording A local record sequence number at 2 word 0...0FFFFH
sequence the recording entity.
number
Partial record If partial records are produced, they 1 byte 0...0FFH
sequence shall be numbered for each call. 0 = no partial
number records
(currently not
available)
Number of Total number of partial records 1 byte 0...0FFH
partial records related to this call and produced for
(currently not the served party.
available)
Number of Total number of SS records, related 1 byte 0...0FFH
SS records to this call and produced for the
(currently not served party, if there are any.
available)
Number of Total number of NRU records 1 byte 0...0FFH
NRU records related to this call.
(currently not
available)
Number of Total number of trunk usage records 1 byte 0...0FFH
trunk records related to this call.
(currently not
available)
between transactions for the served cc_call_id_t 0 = dummy
party. value, no identifier
assigned
Served Number (= radio subscriber identity 10 bcd coded bcd, see Appendix
number or alias identity) of the called phone number A
party. MSISDN format if applicable,
otherwise NITSI.
Served NITSI of the called party. 10 bcd coded bcd, see Appendix
NITSI phone number A
block *) served party. see Appendix A
Table 6: TTC record (cont'd.)

Calling number Number (= radio subscriber identity 14 bcd coded bcd, see Appendix
or primary alias identity) of the phone number A
calling party, if available. MSISDN
format if applicable, otherwise
NITSI.
Calling NITSI As above, NITSI format. 10 bcd coded bcd, see Appendix
phone number A
DXT id The identity of the DXT of the 4 dword, 0 = DXT id unknown
served party. system_id_t
party. ntn_la_t 0FFFFH = LA
information not
used,
0FEFEH = All LAs
in the DXT
Cell identity The identity of the cell of the served 1 byte, 0...3FH and
party. ntn_cell_t 0FFH = cell
information not
used,
0FEH = all cells of
the LA
Basic service The parameters of the service 4 basic_service_t Structure of
used employed. four bytes, see
Appendix A
Call priority Call priority. 1 byte, 0...15, see
setup_ Appendix A
priority_t
Urgency class Urgency class granted for the call. 1 byte, 0...6
urgency_class_t 0FFH = unknown,
see Appendix A
Queuing Resource queuing priority granted 1 byte, 0...240 and
priority for the call. call_priority_t 0FFH = unknown
Full / Half MS frequency full / half duplex 1 byte 0 = simplex,
duplex operation. 1 = duplex,
0FFH = unknown
Hook method The hook method used for the call. 1 byte 0 = no hook sign.
(direct connection)
1 = hook on/off
signalling,
0FFH = unknown
Table 6: TTC record (cont'd.)

Air I/F Indication whether air interface 1 byte 0 = encryption is
encryption encryption was used or not. not used,
1 = encryption is
used,
0FFH = unknown
Event time Setup time 8 calendar_ Structure of 6 bytes
stamps Answer time 8 time_t and a word, see
Connect time 8 Appendix A
Release time 8
Call The chargeable duration of the 4 dword, 0...0FFFFFFFFH
duration connection for successful calls, the duration (unit is 10
holding time for call attempts. milliseconds),
0 = unknown or
insignificant
Cause for The reason for the release of the 1 byte, 0...9, see Appendix
termination connection. term_cause_t A
rc_t
*) Correct information about the organisation block cannot be received if the call is made using group
overlay number.
4.4.3 Incoming gateway call attempt record (InG)
An incoming gateway record (InG) is created for each incoming call attempt received by a gateway DXT
from another network. These records can be used to settle accounts with other networks. The generation of
gateway records is not affected by the production of TTC records. A gateway record is generated also in
cases when the gateway DXT and terminating DXT are co-located.
The total size of an InG record is 113 bytes.
Table 7 describes the fields of an InG record.
Table 7 : InG record

Record length Length of InG record. 2 word 113
Record type Incoming gateway record. 1 byte 3 = InG record
structure.
Table 7: InG record (cont'd.)

Recording A local record sequence number 2 word 0...0FFFFH
sequence at the recording entity.
number
Call reference A local identifier distinguishing 4 cc_call_id_t 0...0FFFFFFFFH,
between transactions for the 0 = dummy value, no
served party. identifier assigned
Calling number The address of the calling party, 14 bcd coded bcd, see Appendix A
if available. phone number
Called number The address of the called 10 bcd coded bcd, see Appendix A
party as received by the GDXT phone number
from the other network (NITSI,
NGTSI, MSISDN, or FSSN).
number modification within the GDXT. phone number
Translated NITSI As above, NITSI or NGTSI 10 bcd coded bcd, see Appendix A
format. phone number
DXT id The identity of the GDXT. 4 dword, 0 = DXT id unknown
system_id_t
Incoming HW connection that is used for 2 unit_index_t See Appendix A
interface the incoming interface: 2 piu_type_t
FNIM, TLIA, TLIC, and the line 1 piu_index_t
within the TLIA or TLIC 1 ext_line_index_t
or
FNIM ET (ECE2-NT/NTC)
or
ISDN/ISI exchanges
(ECE2-NT/NTC,
EC2ET-NT/NTC)
or
SIP GW.
This field is not necessary for
SDS/status messages but it can
be filled in.
Connection The connection group number. 2 word 0...0FFFFH,
group 0FFFFH = unknown
Other SwMI MNI MNI of the other sending TETRA 4 dword 0
network. address_ or
extension_t 0xFFFFFFFF,
see Appendix A
Charging pulses The number of charging pulses 2 word 0...0FFFFH
(currently not received. 0FFFFH = unknown
available)
Table 7: InG record (cont'd.)

Event time Seizure time of incoming 8 calendar_ Structure of 6 bytes
stamps interface. time_t and a word, see
Appendix A
Answer time for successful 8
individual calls, dummy value
for group calls.
Release time (Release of 8
incoming interface).
Call The accountable duration 4 dword, 0...0FFFFFFFFH
duration (answer → release) of the duration (unit is 10
connection for successful milliseconds),
individual calls or (connect → 0 = unknown or
release) for group calls, the insignificant
holding time of the incoming
interface for call attempts.
Cause for The reason for the release of 1 term_cause_t 0...9, see Appendix A
termination the connection.
rc_t
4.4.4 Outgoing gateway call attempt record (OutG)

An outgoing gateway record (OutG) is created for each outgoing call attempt from a gateway DXT to another
network. These records can be used to settle accounts with other networks. The generation of gateway
records is not affected by the production of TOC records. A gateway record is also generated in cases when
the gateway DXT and the originating DXT are co-located.
The total number of bytes in an OutG record is 99.
Table 8 describes the fields of an OutG record.
Table 8 : OutG record

Record length Length of OutG record. 2 word 99
Record type Outgoing gateway record. 1 byte 4 = OutG
structure.
Table 8: OutG record (cont'd.)

Recording A local record sequence 2 word 0...0FFFFH
sequence number at the recording
number entity.
between transactions for the cc_call_id_t 0 = dummy value, no call
served party. identifier
Calling number The address of the calling 10 bcd coded bcd, see Appendix A
party. MSISDN format if phone number
applicable, otherwise NITSI.
Calling NITSI As above, NITSI format. 10 bcd coded bcd, see Appendix A
phone number
Transmitted The number that was actually 14 bcd coded bcd, see Appendix A
number transmitted by the GDXT to phone number
the other network.
DXT id The identity of the GDXT. 4 dword, 0 = DXT id unknown
system_id_t
Outgoing HW connection that is used 2 unit_index_t See Appendix A
interface for the outgoing interface: 2 piu_type_t
FNIM, TLIA, TLIC, and the 1 piu_index_t
line within the TLIA or TLIC 1 ext_line_index_t
or
FNIM ET (ECE2-NT/NTC)
or
ISDN/ISI exchanges
(ECE2-NT/NTC,
EC2ET-NT/NTC)
or
SIP GW.
This field is not necessary for
SDS/status messages but it
can be filled in.
Connection The connection group 2 word 0...0FFFFH,
group number. 0FFFFH = unknown
Other SwMI MNI MNI of the other (receiving) 4 dword 0
TETRA network. address_ or
extension_t 0xFFFFFFFF,
see Appendix A
Event time Seizure time of outgoing 8 calendar_ Structure of 6 bytes and a
stamps interface. 8 time_t word, see Appendix A
Answer time for successful 8
individual calls, dummy value
for group calls.
Release time (Release of
outgoing interface).
Table 8: OutG record (cont'd.)

Call duration The accountable duration 4 dword, 0...0FFFFFFFFH (unit is 10
(answer → release) of the duration milliseconds),
connection for successful 0 = unknown or insignificant
individual calls or (connect →
release) for group calls, the
holding time of the incoming
interface for call attempts.
Pulses The number of pulses 2 word 0...0FFFFH,
received from PSTN. 0FFFFH = unknown
Cause for The reason for the release of 1 term_cause_t 0...9, see Appendix A
termination the connection.
rc_t
4.4.5 TETRA originated call forwarding (Forw)

In case of call forwarding, the forwarded-leg of the call results in the production of Forw record for the called
subscriber who has the forwarding active (or in the case of a call transfer, the Forw CDR is generated for
the transferring dispatcher). A Forw record is produced in the DXT where the calling subscriber is located
in the setup phase. If the calling subscriber is a PSTN/PABX subscriber, the Forw record is produced in
the incoming gateway.
The total size of a Forw record is 125 bytes.
Table 9 describes the Forw record fields:
Table 9 : Forw record

Record length Length of Forw record. 2 word 125
Record type Call forwarding. 1 byte 7 = Forw record
Record Version number of the record 1 byte 1...0FFH
version structure.
Recording The identity of the DXT that produced 4 dword, 0 = DXT id unknown
entity the record. system_id_t
sequence the recording entity. This is for audit
number purposes only.
Number of Total number of SS records related to 1 byte 0...0FFH
SS records this call and produced for the served
(currently not party (if there are any call related SS
available) events).
Table 9: Forw record (cont'd.)

Number of Total number of NRU records related 1 byte 0...0FFH
NRU records to this call.
(currently not
available)
Number of Total number of trunk usage records 1 byte 0...0FFH
trunk records related to this call.
(currently not
available)
between transactions for the served cc_call_id_t 0 = dummy value
party. The same call reference is used when no call identifier
for all records (partial, sublementary assigned
etc.) during one call.
Served NITSI NITSI of the forwarding party. 10 bcd coded bcd, see Appendix A
phone number
block forwarding party. see Appendix A
Forwarded-to The address of the forwarded-to 14 bcd coded bcd, see Appendix A
number party; MSISDN format if applicable, phone number
otherwise NITSI, or the external
PABX/PSTN number.
Forwarded-to The address of the forwarded-to 10 bcd coded bcd, see Appendix A
NITSI party in NITSI format. If forwarded to phone number
PSTN/PABX, the GW SSI in NITSI
format.
Connection The connection group number of the 2 word 0…0FFFFH,
group forwarded-to party. 0FFFFH = unknown
Forwarded-to The identity of the DXT of the 4 dword, 0 = DXT id unknown
DXT id forwarded-to party. system_id_t
Basic service The parameters of the service 4 basic_service_t Structure of four
used employed. bytes, see Appendix
A
Basic service The parameters that were requested 4 basic_ Structure of four
requested for the service. service_t bytes, see Appendix
A
Call priority Call priority requested for the call. 1 byte, 0...15, see Appendix
setup_ A
priority_t
Urgency class Urgency class granted for the call. 1 byte, 0...6
urgency_ 0FFH = unknown

Queuing Resource queuing priority granted for 1 byte, 0...240 and
priority the call. call_ 0FFH = unknown
priority_t
Full / Half MS frequency full / half duplex 1 byte, 0 = half duplex,
dublex operation requested / granted. simpl_dupl_ 1 = full duplex,
sel_t 0FFH = unknown
Hook method The hook method requested / granted. 1 byte, 0 = no hook sign
hook_meth_ (direct connection)
sel_t 1 = hook on/off
signalling,
0FFH = unknown
Air I/F Indication whether air interface 1 byte 0 = encryption is not
encryption encryption was used or not. used,
1 = encryption is
used,
0FFH = unknown
Event time Forward time (Forwarding started). 8 calendar_ Structure of 6 bytes
stamps time_t and a word:
hundredths of
Answer time (Call answered). 8
seconds, seconds,
Connect time (Call entered into 8 minutes, hours, day,
progress). month, year in bcd
Release time (Call was released). 8 form, see
Appendix A
Note! In the case of call forwarding,
only the 'Forward time' field is filled.
Call duration In call transfer cases: 4 dword, 0...0FFFFFFFFH
The duration of the connection duration (unit is 10
(connect -> release of the transferred milliseconds),
leg of the call) for successful calls, the 0 = unknown or
holding time (forwarded -> release) for insignificant value
call attempts.
For consecutive call forwardings:
forward time.
Cause for The actual cause for forwarding the 1 byte, 0= CFB,
forwarding call. forw_cause_t 1=CFNRc,
2= CFNRy,
3=CFU
4=call_transfer

Cause for The reason for the release of the 1 byte, 1...9 and 0=unknown,
termination connection. term_cause_t see Appendix A
rc_t
4.4.6 TETRA originated Short Data and Status record (SDS-TO)
A TETRA originated SDS record (SDS-TO) is produced for an SDS and status message that is
• sent by a TETRA subscriber (radio subscriber, DWS or TCS client) located in that DXT
• coming from an SMSGW that is directly connected to that DXT, no matter what the actual origin (TETRA
network or an external network) of the message is.
• coming from another TETRA network over the Inter-System Interface.
It is also possible to create SDS-related CDRs in the SMSGW or SMSC. This, however, is the responsibility of
the SMSC/SMSGW supplier.
Acknowledged SDS service involves sending an acknowledgement (SDS Report) back to the sender to
confirm the successful reception of the SDS sent. CDRs are also produced for SDS Report messages.
The total size of an SDS-TO record is 262 bytes.
Table 10 describes the fields of an SDS-TO record.
Table 10 : SDS-TO record

Record length Length of SDS-TO record. 2 word 262
Record type SDS TETRA originated. 1 byte 5 = SDS-TO
Record Version of the record structure. 1 byte 1...0FFH
version
Recording The identity of the DXT that produced 4 dword, 0 = DXT id unknown
entity the record. system_id_t
sequence the recording entity.
number
Number of Total number of SS records related to 1 byte 0...0FFH
SS records this data message, if there are any.
(currently not
available)
Table 10: SDS-TO record (cont'd.)

between transactions for the served cc_call_id_t 0 = dummy value
party. when no call identifier
assigned
Served Number (= radio subscriber identity or 10 bcd coded bcd, see Appendix A
number *) the primary alias identity) of the calling phone number
party. If applicable, this is in MSISDN
format. Otherwise NITSI format.
Served As above, NITSI format. 10 bcd coded bcd, see Appendix A
NITSI *) phone number
Organisation The organisation block of the calling 12 org_block_id_t Array of six words,
block party. see Appendix A
Called The number dialled by the calling 14 bcd coded bcd, see Appendix A
number **) party (NITSI, NGTSI, MSISDN, or phone number
FSSN).
number **) modification within the DXT. MSISDN phone number
format if applicable, otherwise NITSI
or NGTSI.
Translated As above, NITSI or NGTSI format. 10 bcd coded bcd, see Appendix A
NITSI **) phone number
Connected Number (= radio subscriber identity 14 bcd coded bcd, see Appendix A .
number or alias identity) of the connected phone number
party. If applicable, this is in MSISDN
format, otherwise in NITSI or NGTSI
format.
Connected As above, NITSI or NGTSI format 10 bcd coded bcd, see Appendix A
NITSI phone number
Connection The connection group number if the 2 word 0…0FFFFH,
group called subscriber is external. 0FFFFH = unknown
DXT id The identity of the originating DXT. 4 dword, 0 = DXT id unknown
system_id_t
Location area The location area of the served party. 2 word, 0...03FFFH and
ntn_la_t 0FFFFH = LA
information not used,
0FEFEH = All LAs in
the DXT
Cell identity The identity of the cell of the served 1 byte, 0...3FH and
party. ntn_cell_t 0FFH = cell
information not used,
0FEH = all cells of the
LA

Target DXT id The identity of the target DXT. 4 dword, 0xFFFFFFFF
Note:For the group addressed data system_id_t
message sending the field has no
meaning and will have a dummy
value.
Target The location area of the target 2 word, ntn_la_t_unused_
location area subscriber. ntn_la_t la_c
Note:For the group addressed data
value.
Target The channel used or tried to be used 1 byte, tgt_ch_t_unused_c,
channel type for data message transfer. tgt_ch_t see Appendix A
Note:For the group addressed data
value.
SDS TL SDS-4 protocol identifier 1 byte, 0xFF
protocol Note:For the group addressed data sds_tl_protocol_t
value.
Forward Tells the receiving subscriber number 14 bcd coded bcd, see Appendix A
number ***) if a text message is going to the phone number
SMSGW, i.e. the store-and-forward
service is used. The field contains the
NITSI, NGTSI or MSISDN number or
is empty.
Translated The forward number after number 14 bcd coded bcd, see Appendix A
forward modification within the DXT. The phone number
number ***) field contains the NITSI or MSISDN
number or is empty.
Transfer/ Tells the message type, i.e. whether 1 byte 0=
report flag the delivered message is SDS-TL SDS message
Transfer, SDS-TL Report or status. from the calling
subscriber to the
called subscriber
1=
SDS report from the
called subscriber to
the calling subscriber
255 =
status message from
calling subscriber to
the called subscriber.

Message Message identifier taken from the 1 byte 0...255
reference message (user) data; links together
the transmitted message and the
receiver's acknowledgement.
When a status message is sent, the
value shown in this field is 255.
SDS service Acknowledged / non-acknowledged 1 byte 0 = not acknowledged
type service. 1 = acknowledged,
0FFH = unknown
SDS type The type of short data / status 1 byte, 0 = SDS-1,
message sent. dc_data_ 1 = SDS-2,
call_type_t 2 = SDS-3,
3 = SDS-4,
4 = STATUS,
0FFH = unknown
SDS length The length of user defined data-4 4 dword 0...2047 and
(only for SDS-4, number of bits). 0FFFFFFFFH =
unknown
Sending The profile used for SDS-4 message 1 byte, 0...4 and 0xFF = not
profile sending. sending_ used, see Appendix A
profile_t
Number of Tells the amount of combined groups 1 byte 0 = no combined
groups to which the message was sent. groups
2-8 = number of
combined groups
List of groups Tells the NGTSIs of the groups to 80 bcd coded 8 bcd coded 10-byte
which the message was sent. number GTSIs
Time stamp The time at which short data / status 8 calendar_ Structure of 6 bytes
message was received by the DXT time_t and a word, see
from the subscriber. Appendix A
Cells Number of location areas to which 2 word 0...0FFFFH,
distributed SDS was distributed. 0FFFFH = unknown
Cells reached Number of location areas to which 2 word 0...0FFFFH,
SDS delivery was successful. 0FFFFH = unknown
Dispatchers Number of dispatchers to which SDS 1 byte 0...0FFH,
reached delivery was successful. 0FFH = unknown
NOTE: The value
range is normally
0...254. Value
255 indicates that
there are 255 or
more dispatcher
workstations to which
the message was
delivered.

SDS result The result of the delivery. 1 byte, See Appendix A
dc_dws_
ack_v_t
Diagnostics For internal use of Airbus DS. 2 word
*) If the message is coming from the SMSGW, this field contains the number of the SMSGW. The original
calling subscriber's number is shown in the Forward number field and the Translated forward number field is
empty.
**) If the message is sent to the SMSGW, this field contains the number of the SMSGW. The actual called
subscriber's number is shown in the Forward number field. If number translation is needed for the forward
number, the translated number is shown in the Translated forward number field.
***) If the message is transmitted directly from the calling subscriber to the called subscriber without using the
SMSGW, this field is empty. If the message is coming from the SMSGW, the Forward number field contains
the original calling subscriber's number and the Translated forward number field is empty.
4.4.7 Packet data record
If the generation of these records is enabled, a PD record is created for each packet data context activation
attempt originated by a TETRA subscriber. The PD record is generated in the originating (calling subscriber's)
DXT.
Fields DXT id, Location area and Cell identity report the location of the mobile subscriber. Some fields
of the records are not used.
The total size of a PD record is 141 bytes.
Table 11 describes the fields of a packet data record.
Table 11 : PD record

Record length Length of PD record (bytes). 2 word 141
Record type Packet data record. 1 byte 6 = PD record
structure.
produced the record. system_
id_t
Recording sequence A local record sequence 2 word 0...0FFFFH
number number at the recording entity. no partial records
For audit purposes only.
Table 11: PD record (cont'd.)

Partial record serial Serial number of PD record 2 word 1...0FFH
number belonging to this PD context.
PD context reference A local identifier distinguishing 4 0...0FFFFFFFFH,
between transactions for 0
the served party. The same
reference shall be used for
all records during one activity
period.
Served number Number (= radio subscriber 10 bcd coded bcd, see Appendix A
identity) of the calling party. If phone
applicable, this is in MSISDN number
format. Otherwise NITSI
format.
Served NITSI As above, NITSI format. 10 bcd coded bcd, see Appendix A
phone
number
Organisation block The organisation block of the 12 org_block_ Array of six words,
calling party. id_t see Appendix A
Protocol Network layer protocol used. 1 byte 0 = IPv4
1 = IPv6
0FFH=Unknown
Allocated IP address IPv4 or IPv6 address allocated 17 ip_addr_t Array of 17 bytes,
to the served party. see Appendix B
party. ntn_la_t 0FFFFH = LA
information not used
Cell identity The identity of the cell of the 1 byte 0...3FH and
served party. 0FFH = cell
information not used
Quality of service The Quality of Service 2 byte, Structure of 2 bytes,
requested parameters that were pdp_qos_t see Appendix A
requested for the PD context.
Quality of service The Quality of Service 2 byte, Structure of 2 bytes,
granted parameters that were granted pdp_qos_t see Appendix A
for the PD context.
Priority (currently not Packet data priority. 1 byte, 0...15
available) setup_
priority_t
Queuing priority Resource queuing priority 1 byte, 0...240 and
granted for the PD context. call_ 0FFH = unknown
priority_t

Air I/F encryption Indication whether air interface 1 byte 0 = encryption is not
encryption was used or not. used,
1 = encryption is
used and
0FFH = unknown
Allocations Number of timeslots allocated 1 byte 0...3
for the activity period. where 0 equals one
timeslot, 1 equals two
timeslots and so on.
Event time stamps Setup time (PD context was 8 calendar_ Structure of 6
activated). time_t bytes and a word:
hundredths of
Connect time (Start time of the 8
seconds, seconds,
first channel allocation).
minutes, hours, day,
Channel release time (End time 8 month, year in bcd
of the last channel release). form, see Appendix A
Deactivation time (PDP context 8
was deactivated).
PDP context duration PDP context duration recorded 4 dword, 0...0FFFFFFFFH
in this CDR. duration (unit is 10
milliseconds),
0 = unknown or
insignificant value
Channel occupation Cumulated channel occupation 4 dword, 0...0FFFFFFFFH
time time recorded in this CDR. duration (unit is 10
milliseconds),
0 = unknown or
insignificant value
Datagrams sent *) The number of datagrams sent 4 dword 0...0FFFFFFFFH
from the DXT (downlink).
Datagrams The number of datagrams 4 dword 0...0FFFFFFFFH
received *) received at the DXT (uplink).
Octets sent *) The number of data octets sent 4 dword 0...0FFFFFFFFH
from the DXT (downlink).
Octets received *) The number of data octets 4 dword 0...0FFFFFFFFH
received at the DXT (uplink).
Urgency class Urgency class granted for the 1 byte, 0...6
packet data. urgency_ 0FFH = unknown
Pd service Packet data service according 1 byte, 0...1,
to type (TETRA or TEDS) pd_ see Appendix A
service_t
Recording event The event that caused the 1 byte, See Appendix A
generation of this CDR . pdp_event_t

Cause for PD context The reason for the deactivation 1 byte, See Appendix A
deactivation of the PD context. pdp_rej_
cau_t
Diagnostics For internal use of Airbus DS. 2 word
Access Point The name of the external IP 63 byte, For example
Name **) network that the subscriber is character _t Airbus.com
connected to.
*) The number of transmitted and received datagrams represent the number of network layer PDUs, that
is, IP protocol datagrams. The number of transmitted and received data octets represent the data payload
and network layer (IP protocol) headers, that is, they do not include link layer headers (Ethernet framing,
TETRA advanced link).
**) APN is an optional field. A new CDR form with this included can be ordered from Airbus Defence and
Space.
4.4.8 TETRA originated registration record (Reg)
TETRA originated registration records are generated locally in the DXT where the registration took place.
The total size of a registration record is 97 bytes.
Table 12 describes the fields of a registration record.
Table 12 : Reg record

Record length Length of the registration 2 word 97
record (bytes).
Record type Registration. 1 byte 9 = Reg record
Record version Version number of the 1 byte 1...0FFH
record structure.
Recording entity The identity of the DXT 4 dword, 0 = DXT id unknown
that produced the record. system_id_t
Checksum Checksum of the fields 2 word 0...0FFFFH
below.
Recording A local record sequence 2 word 0...0FFFFH
sequence number number at the recording
entity.
Served NITSI NITSI of the served party. 10 bcd coded bcd, see
phone number Appendix A
Assigned ITSI*) Identity assigned in RUA 10 bcd coded bcd, see
operation. phone number Appendix A
Table 12: Reg record (cont'd.)

Originator ITSI*) Originator of the 3rd party 10 bcd coded bcd, see
RUA/RUD. phone number Appendix A
Organisation block Organisation block id of a 12 org_block_id_t Array of six words,
subscriber. see Appendix A
TEI Terminal Equipment 8 imei_t; Max 15 4-bit digits,
Identity of the served dummy value = 0
party.
This field is not used for
alias subscribers.
Registration type Type of requested 1 byte, See Appendix A
registration, depending loc_update_
on the parameter type_t
settings.
See Section 4.3.8 .
Authentication The authentication result 1 byte, Not in use /
of a radio (and/or the auth_result_t, Authenticated /
SwMI) during registration. Failed,
This field is not used for see Appendix A
alias subscribers.
Agreed encryption Clear / TEA1 / TEA2 / 1 byte, See Appendix A
TEA3. ntn_encryption_
This field is not used for method_t
alias subscribers.
Class of MS Class of MS received in 4 dword, See Appendix A
the registration. class_of_ms_t
alias subscribers.
Subscriber class Subscriber class received 2 word, See Appendix A
in the registration. subscriber_
class_t
DXT id The identity of the DXT of 4 dword, 0 = DXT id
the served party. system_id_t unknown,
see Appendix A
Previous DXT id The identity of the 4 dword, 0 = DXT id
previous DXT of the system_id_t information not
served party. This field is used.
filled only if the charging See Appendix A
parameter Include
roaming registration
to reg cdr is enabled.
Otherwise the field
contains the default value
(0).
alias subscribers.
Table 12: Reg record (cont'd.)

Location area The location area of the 2 word, 0…03FFFH and
served party. ntn_la_t 0FFFFH = LA
information not
used,
see Appendix A
Previous location The previous location 2 word, Range 0...03FFFH.
area area of the served party. ntn_la_t 0FFFFH = LA
This field is filled information not
only if the charging used
parameter Include 0FEFEH = all
roaming registration location areas in
to reg cdr is enabled. the DXT.
Otherwise the field See Appendix A
contains the default value
(0xFFFF).
alias subscribers.
Cell identity The identity of the cell of 1 byte, 0…3FH and 0FFH
the served party. ntn_cell_t = cell information
not used,
see Appendix A
Channel type Radio channel type used 1 byte, see Appendix A
in registration. tax_reg_ch_t
Time stamp The time at which 8 calendar_ Structure of 6 bytes
the registration was time_t and a word,
invoked or the time of the see Appendix A
RUA/RUD operation.
Registration Registration 1 bool T=
accepted accepted/rejected. registered or
RUA succeeded or
RUD succeeded.
F=
not registered or
RUA failed or
RUD failed.
Reject cause Reasons for rejecting a 1 byte, See Appendix A
registration attempt or a reject_cause_t,
RUA/RUD operation. and
al_reject_
cause_t
Diagnostics For internal use of Airbus 2 word,
DS. reg_diag_t
* ) No data type definition.
A Data types used in charging records
Note
The values of the fields depend on the implementation of the feature in question.
A.1 address_extension_t
This data type defines the mobile network identity (MNI) for the sending and the receiving network in calls
between TETRA networks. This data type is defined by a dword.
The Mobile Network Identity (MNI) consists of the following two parts:
• Mobile Country Code (MCC), length 10 bits in a 16-bit field with leading zeros.
• Mobile Network Code (MNC) of the system, length 14 bits in a 16-bit field with leading zeros.
The MCC is allocated by ETSI standard. The MNC is usually allocated by the responsible officials of each
country.
A.2 al_reject_cause_t
This data type specifies the reject causes for the assignment/disassignment of an alias identity. This data
type is defined by a byte.
00 = Cause not defined or unknown
01 = Incorrect combination of radio user identity and personal identification number
04 = The assignment is rejected due to proprietary access rules
05 = The system is currently not able to perform the assignment
FF = For internal use only.
A.3 auth_result_t
Authentication result is defined by a byte. It tells whether a subscriber was authenticated in the previous
registration.
This data type has the following values:
1 = Authentication successful
2 = Authentication failed.
0FFH = Authentication not used.
A.4 basic_service_t
This data type informs which basic service is requested. It is a structure of four fields. If the basic service
is unknown or insignificant in the CDR, all fields are filled with 0FFH.
Table 13 : Contents of the basic service information elements
Information subelement Length Value Remark

Circuit mode type 1 byte 00H Speech: TCH/S
(see Note 1) 01H Unprotected: TCH/7.2
02H Low protection: TCH/4.8, N=1
Low protection: TCH/4.8, N=4
04H Low protection: TCH/4.8, N=8
05H High protection: TCH/2.4, N=1
Encryption flag 1 byte 00H Clear mode
(see Note 2) 01H TETRA end-to-end encryption
Communication type 1 byte 00H Point-to-point
01H Point-to-multipoint
02H Point-to-multipoint acknowledged
03H Broadcast
Slots per frame 1 byte 00H One slot
(see Note 3) 01H Two slots
02H Three slots
03H Four slots
Note 1: Indicates the traffic channel (TCH) type and the interleaving depth N.
Note 2: Indicates whether the circuit mode speech or data is end-to-end encrypted.
Note 3: Indicates the required bit rate for a circuit mode data call. For TCH/7.2, TCH/4.8 and TCH/2.4 the
resulting bit rate is the TCH bit rate multiplied by the number of slots per frame. For example, TCH/7.2 in
four time slots per frame gives a circuit mode data rate of 28.8kbit/s. For TCH/S this element shall be
preset (set to 0).
A.5 bcd-coded phone number

The NITSI, NGTSI, MSISDN, FSSN, and other representations of a subscriber number are coded as binary
coded decimal (bcd) number strings. The first byte is the length of the string and the following bytes are the
digits in a bcd form (4 bits/digit). The bcd coding is done according to the following table. For example, the
dialled number 2123456 is represented by bytes 07H, 21H, 23H, 45H, 6FH, ...
If the number is insignificant or unknown, the string is filled with bytes 0FFH.
Table 14 : BCD coding
digit 1 2 3 4 5 6 7 8 9 0 * # A B C D
bcd 1 2 3 4 5 6 7 8 9 0 A B C D E F
code
A.6 calendar_time_t
Calendar time is an eight-byte field that, in binary coded decimal (bcd) form, contains the following items:
hundredths of seconds, seconds, minutes, hours, day, month, year. For example, 25th of November 1998
at 23:59:50:87 (9,13 seconds to midnight) is coded as 87H, 50H, 59H, 23H, 25H, 11H, 98H, 19H. All fields
of the calendar time are filled with 0FFH (year is 0FFFFH) if the time is unknown or insignificant. In some
exceptional situations an unknown value can also be filled with zeros.
A.7 call_priority_t
Call priority is defined by a byte. The value range is 0...240. Value 0FFH is used when the priority is unknown.
A.8 cc_call_identifier_t
The network-wide unique call identifier is defined by a dword. The value range is 0...0FFFFFFFFH. Value 0
means that no call identifier is assigned to the call. The CDRs related to the same call (for example, TOC
and TTC of an MS-MS call) have the same call identifier. If the call identifier is 0 (dummy), only TOC or
InG is generated for that call attempt.
A.9 class_of_ms_t
Class of MS information is received at the registration and it tells which functions are supported or not
supported by a certain terminal. This field consists of 32 bits and is defined by a dword.
For more detailed information, refer to ETSI standard Terrestrial Trunked Radio (TETRA); Voice plus Data
(V+D); Part 2: Air Interface (AI).
BITS (1) d8psk modulation mode support
BITS (1) Extended advanced link(s) support
BITS (1) Support of MAC-D-BLCK PDU and augmented channel allocation
BITS (1) Common SCCH
BITS (3) TETRA air interface standard, version number
BITS (1) SCK air interface encryption
BITS (1) Authentication
BITS (1) Carrier specific signalling channel
BITS (1) Minimum mode
BITS (1) Advanced link
BITS (1) CLCH needed on carrier change
BITS (1) Concurrent circuit mode services
BITS (1) DCK air interface encryption
BITS (1) Fast switching
BITS (1) TETRA packet data
BITS (1) Circuit mode data
BITS (1) End-to-end encryption
BITS (1) Voice calls
BITS (1) Single/multi carrier operation
BITS (1) Single slot/multislot
BITS (1) Frequency simplex/duplex
Unused bits (9)
A.10 dc_data_call_type_t
The type of a SDS or status message is defined by a byte.
The possible values are 0...4 and 0FFH.
00 = SDS User defined data-1
04 = STATUS
0FFH = Unknown
A.11 dc_dws_ack_v_t
The values of this data type tell the successfulness of the data message sending. This data type is defined
by a byte and has the following values:
00H = OK individual delivery
01H = OK group delivery
02H = Failed individual delivery
04H = Failed group delivery
05H = Called party not reachable
06H = Failed, network congestion
07H = System disturbance *)
08H = Too long an SDS message
09H = Illegal service request
0AH = Destination address unknown
0BH = Feature not in use in this system
60H = No response from DXT received to data call setup
0FFH = Unknown
*) Causes for value 07H (System disturbance):
These are related to problems either in reading data from a local database or in communication when fetching
data from another exchange, such as
• reading calling subscriber data from database fails
• enquiry of the called subscriber's data (possibly from another exchange) fails either due to a timeout or
database reading error
• enquiry of SMSGW data fails.
A.12 ext_line_index_t
This field has separate meanings and values for use with FNIM, FNIM ET, ISDN/ISI and SIP GW. External
line index is defined by a byte.
FNIM:
The external line within the plug-in unit.
The possible values are 0...3.
Value 0FFH means that the line index is unknown.
FNIM ET:
Not used.
The value is 0xFF.
ISDN/ISI:
Not used.
The value is 0xFF.
SIP:
SIP GW id that was used in the call.
A.13 ip_addr_t
This is an array of 17 bytes identifying an IP protocol address, either version 4 or version 6. The first byte
identifies the type of the address. The address is presented in hexadecimal format and in network byte order.
The values are:
0 = IPv4 address format
1 = IPv6 address format
IPv4 addresses use the first 4 bytes.
IPv6 addresses use all 16 bytes.
The representation in the network byte order (big endian) means that the leftmost byte is the most significant.
Example:
The IPv4 address 194.28.33.15 in decimal is equal to C2.1C.21.0F in hexadecimal format.
In the CDR, the hexadecimal address is shown as 00C21C210F
where 00 denotes the IP4v.
A.14 loc_update_type_t
This data type indicates the requested type of registration in hexadecimal format. This field is defined
by a byte.
00 = Roaming location updating
01 = Migrating location updating
02 = Periodic location updating
03 = ITSI attach
04 = Call restoration roaming location updating. Reserved for future use.
05 = Call restoration migrating location updating
06 = Demand location updating
07 = Disabled MS updating
08 = Roaming to other DXT
F7 = Radio user assignment
F8 = Radio user disassignment
F9 = Forward registration
FA = ITSI is disabled
FB = ITSI is enabled
FC = Implicit registration
FD = ITSI detach
FE = Subscriber deleted
A.15 ntn_cell_t
The cell is defined by a byte value 0...3FH. Value 0FFH means that cell information is not used. 0FEH has the
meaning All cells of the location area.
A.16 ntn_encryption_method_t
This field provides information about the encryption agreed to be used after the registration. Encryption
method is defined by a byte.
The encryption method has the following values:
0 = TEA1
1 = TEA2
2 = TEA3
FF = CLEAR (no encryption)
A.17 ntn_la_t
The location area (LA) is defined by a word. The value range is 0...03FFFH. Value 0FFFFH means LA
information not used and 0FEFEH means All location areas in the DXT.
A.18 org_block_id_t
An array of 6 words identifying the organisation block of a radio subscriber or dispatcher. The first word
specifies the organisation, and the five succeeding words specify the sublevels.
If one of the sublevels is marked unused (FFFFH), all the subsequent levels are also marked as such.
The numbers 0000H...7FFFH (0...32767) are used as organisation block identifiers.
Numbers 8000H...FFFEH (32768...65534) are reserved.
The special values are:
FFFFH = Unused level
FFFAH = No organisation
A.19 pd_service_t
This data type defines whether the packet data service is implemented according to TETRA or TEDS. The
packet data service is defined by a byte. The values are:
00 = TETRA
01 = TEDS
A.20 pdp_event_t
This data type defines the recording event, that is, why this CDR has been generated. The following
values are currently defined:
00 = User requested end of data transfer
01 = Inactivity timeout
02 = Partial recording timer expired
03 = Data volume counter limit reached
04 = Channel(s) released due to resource pre-emption
05 = Context deactivation
06 = Rejection of data transmission attempt
07 = Channel release due to error
08 = Channel release due to handover
09 = Successful context activation
10 = Unsuccessful context activation
A.21 pdp_qos_t
This data type defines the Quality of Service (QoS) parameters. The structure is 2 bytes: the 1st byte
specifies the number of timeslots within a TDMA frame and the 2nd byte specifies the bandwidth. The
2nd byte can have the following values:
00 = Network dependent minimum
01 = 1/32 of maximum
02 = 1/16 of maximum
03 = 1/8 of maximum
04 = 1/4 of maximum
05 = 1/2 of maximum
07 = Network dependent maximum
FF = Undefined
A.22 pdp_rej_cau_t
This data type indicates the reject cause for the PD context activation. The data type is defined by one byte.
The following causes of context deactivation are defined:
00 = Undefined
01 = MS not provisioned for Packet Data
02 = IPv4 not supported
03 = IPv6 not supported
04 = IPv4 dynamic address negotiation not supported
05 = IPv6 stateful address autoconfiguration not supported
06 = Pv6 stateless address autoconfiguration not supported
07 = Dynamic address pool empty
08 = Static address not correct
09 = Static address in use
10 = Static address not allowed
11 = Static IP address congestion
12 = TETRA Packet data not supported on this location area
13 = TETRA Packet data not supported on this network
14 = Temporary rejection
15 = Packet Data MS Type not supported
16 = SNDCP version not supported
17 = Mobile IPv4 not supported
18 = Mobile IPv4 Co-located care of address not supported
19 = Maximum number of PDP Contexts per ITSI exceeded
20 = User authentication failed
21 = Access point name index not correct
22 = Access point name index not correct
23 = Requested minimum peak throughput not available
24 = Scheduled access not supported
25 = Requested schedule not available
26 = Requested QoS not available
27 = Secondary PDP contexts not supported
28 = Primary PDP context does not exist
29 = Asymmetric QoS not supported
30 = Automatic QoS filter not supported
31 = QoS filter type not supported
32 = QoS filter not available for primary PDP context
250 = Implicit deactivation
251 = Timeout, PD context standby timer expired
252 = User requested deactivation
253 = IP address lease time expires
254 = De-registration (e.g. mobile is switched off)
255 = Undefined
A.23 piu_index_t
Plug-in unit index is defined by a byte. This field has separate meanings and values for use with FNIM,
FNIM ET, ISDN/ISI and SIP.
FNIM:
Plug-in unit index in the FNIM unit.

Value 0FFH means that the index is unknown.
FNIM ET:
Specifies the timeslot of the FNIM ET PCM.

The possible values are 1...15 and 17...31.
ISDN/ISI:
Specifies the timeslot of the ISDN/ISI PCM.

The possible values are 1...15 and 17...31.
SIP:
Not used.
The value is 0xFF.
A.24 piu_type_t
This field has separate meanings and values for use with FNIM, FNIM ET, ISDN/ISI and SIP. The plug-in
unit type is defined by a word.
FNIM:
Identifies the type of the used plug-in unit in the FNIM unit. The possible values are
• 145H = TLIA (R2 interface)
• 148H = TLIC (G4WIF interface)
• 0FFFFH = the field is insignificant.
FNIM ET:
Specifies the FNIM ET PCM number.

ISDN/ISI:
Specifies the ISDN/ISI PCM number.

SIP:
Not used.
The value is 0xFFFF.
A.25 reject_cause_t
This data type specifies the reject causes for the registration of a radio terminal. The data types are defined
by a byte.
01 = ITSI unknown
02 = Illegal or disabled MS
03 = Location area not allowed
04 = Location area unknown
05 = Network failure
06 = Congestion
07 = Forward registration failed or
07 = Service not supported
08 = Service not subscribed
09 = Mandatory element error
10 = Message consistency error
11 = Roaming not supported
12 = Migration not supported
13 = No key stream generator (KSG)
14 = Key stream generator (KSG) not supported
15 = Key type
16 = Key not available
18 = Ciphering required
19 = Authentication failure
FF = Registration accepted
A.26 sds_tl_protocol_t
This data type specifies the protocol used for SDS-4 message sending.
A.27 sending_profile_t
This data type specifies the profiles used for SDS-4 message sending. The data type is defined by a byte.
The following values have been defined:
00 = Normal sending profile
01 = Important sending profile
02 = Paging sending profile
03 = Dedicated sending profile
04 = Repeating sending profile
FF = Not used
A.28 setup_priority_t
One byte (value range 0...15) which defines the priority level of the call. Priorities 12, 13, and 14 are
pre-emptive. Priority 15 is reserved for emergency calls. Value 0 means that the priority is not defined.
A.29 subscriber_class_t
This data type indicates the subscriber class of registering subscriber.
0x0FC0 (0000111111000000) = default class
0xFFFF (1111111111111111) = all classes
A.30 system_id_t
System_id_t contains the unique identity number of the DXT exchange. It is based on a value defined in
an exchange specific parameter file filled at the time of the delivery. Usually it is set to the same value as
the so called c-number. The system id is presented as a dword. Value 0 means that the DXT id information
is not used.
A.31 tax_reg_ch_t
This data type specifies the radio channel type used in registration.
0 = Main control channel
1 = Secondary control channel 1
4 = Traffic channel
5 = TEDS channel
0xFF = Channel type not provided
A.32 tgt_ch_t
This data type specifies the radio channel type that is used in data message transfer. For the successful
data message transfer, the data type indicates the channel that was successfully used. If the data message
transfer was unsuccessful, the channel type indicates the last channel that was used when attempting to
send the data message.
0x00 = Message to traffic channel
0x01 = Message to control channel
0x02 = Message to packet data channel
0x03 = Message to both/all TEDS channels
0x04 = Message to main TEDS channel
0x05 = Message to additional TEDS channel
0x06 = Message to dedicated control channel
0x07 = Message to 1st secondary control channel
0x08 = Message to 2nd secondary control channel
0x09 = Message to 3rd secondary control channel
0xF0 = Message to TEDS channel (TTRX 0)
0xFF = Target not specified/does not exist
A.33 term_cause_t
This data type indicates the reason for the termination of a call. By the termination cause it is possible to
determine whether the call was connected or not. Termination causes 01, 08, and 09 are used for calls that
were connected. For these calls the call duration (in the CDR) is the actual speech connection time.
00 = The field is insignificant
01 = Normal release of a connected call: a calling subscriber hangs up, a called subscriber
hangs up, max. call time or inactivity time
02 = The called subscriber is busy, no answer in time, the calling subscriber released before
the called subscriber answered, the called subscriber is unreachable or not registered
03 = Partial record generation
04 = Unsuccessful call attempt e.g. no rights or a wrong number
05 = Call rejected by the called party
06 = Call rejected by the dispatcher (SS-CAD)
07 = Call rejected by the gateway, gw call i.e. congestion outside the TETRA system
08 = Call terminated by pre-emption
09 = Abnormal termination of a connected call, for example handover failed, resources
failed, radio contact lost.
A.34 unit_index_t
This field has separate meanings and values for use with FNIM, FNIM ET, ISDN/ISI or SIP. The unit index is
defined by a word.
FNIM:
Unit index defines the index of a FNIM unit.

Value 0FFFFH means that the index is unknown.
FNIM ET:
The value of the FNIM ET index is 9.

ISDN/ISI:
The value of the ISDN/ISI index is 8.

SIP:
The value of the SIP index is 10.
A.35 urgency_class_t
This data type indicates the urgency of calls and packet data transfer. The data type is defined by a byte.
Value 0FFH means that this field is insignificant. Values 05 and 06 are not used for packet data.
00 = Normal priority - not pre-emptive
01 = High priority - not pre-emptive
02 = Normal pre-emptive priority
03 = Forced broadcast pre-emptive priority
04 = Emergency pre-emptive priority
05 = Ambience listening priority
06 = Normal priority call that is able to pre-empt other normal priority calls
B Identification of the calling and called party
in charging records
In the following sections it is assumed that the reader is familiar with the numbering systems used in the
TETRA System. Additional information is available in document Numbering, dn00126527.
The abbreviation NITSI meaning Numeric ITSI is a combination of a prefix digit, used for defining the type of
the number, and the subscriber's ITSI number. In group addresses the NGTSI meaning Numeric GTSI has a
similar format. The prefix digit for each number type (NITSI, NGTSI, MSISDN, FSSN etc.) can be configured
using the DXT system parameters; the table below shows the values used in the following examples.
Table 15 : The number types and example of prefix digits
Number type Prefix Format

NITSI 2 2 + country code (4 digits) + TETRA network code (5 digits) + ISSI
(up to 8 digits)
NGTSI 2 2 + country code (4 digits) + TETRA network code (5 digits) + GSSI
(up to 8 digits)
MSISDN 1 1 + country code of the TETRA system in PSTN (up to 3 digits) +
network code of the TETRA system in the PSTN (up to 5 digits) +
subscriber's MSISDN number (up to 10 digits).
The CDR contains a TETRA subscriber's MSISDN number in the
same form as it was defined to the subscriber data. If, for instance,
the subscriber number part (SN) alone was entered to the database,
the country code and the TETRA network code do not show in the
CDR, no matter in which form the number is dialled.
FSSN 3 3 + the short number (up to 6)
PSTN 0 0 + the external number
PABX 9 9 + the number in PABX
The following sections show how the calling/called party is identified in each CDR. The length of the fields is
shown in bytes. The examples are typical simple cases where, for example, no number modification is done.
B.1 MS -> MS call, NITSI number dialled

The following numbers are used in this example call case:
• The SN part of the calling party's MSISDN number is 22334455 (max. 10 digits).
• The ISSI number of the calling party is 7654321 (max. 7 digits).
• The SN part of the called party's MSISDN number is 1234567890 (max. 10 digits).
• The ISSI number of the called party is 7123456 (max. 7 digits).
• The TETRA System PSTN country code is 358 (max. 3 digits).
• The TETRA System PSTN area code is 4551 (max. 5 digits).
• The MSISDN prefix digit in the TETRA System is 1 (the same digit that is used as a prefix must also
be defined as the preceding digit to the post-processing system).
• The NITSI prefix digit in the TETRA System is 2 (the same digit that is used as a prefix must also be
defined as the preceding digit to the post-processing system).
• The radio subscriber dials the number 27123456, in which the first digit '2' is the prefix (leading digit) of
the SSI type of dialling.
• The TETRA System ITSI country code is 4 digits long (mmmm).
• The TETRA System ITSI network code is 5 digits long (vvvvv).
Table 16 : TOC record, MS -> MS call, ITSI number dialled
Field Description Length Example

Served number MSISDN number of the calling party, 10 bytes (i.e. 1358455122334455
including the MSISDN prefix digit, 18 digits)
PSTN country code, and network
code. There is no need for the size
of the country and network code to
be fixed.
If there is no MSISDN number
defined for a served subscriber, only
the subscriber's NITSI format is
indicated in this TOC record.
Served NITSI As above, NITSI format 10 2mmmmvvvvv7654321
Called number The NITSI number dialled by the 14 2mmmmvvvvv7123456
calling party
Translated The called number after number 13 135845511234567890
number modification within the DXT. No
number modification in this example.
Translated NITSI As above, NITSI format 10 2mmmmvvvvv7123456
Connected The number of the connected party 14 135845511234567890
number
Connected As above, NITSI format 10 2mmmmvvvvv7123456
NITSI
Table 17 : TTC record, MS -> MS call, ITSI number dialled

Served number MSISDN number of the called party, 10 bytes (i.e. 135845511234567890
including the MSISDN prefix digit 18 digits)
Table 17: TTC record, MS -> MS call, ITSI number dialled (cont'd.)

Calling number The address of the calling party 10 1358455122334455
(MSISDN format if applicable,
otherwise NITSI)
Calling NITSI As above, NITSI format 10 2mmmmvvvvv7654321
number
B.2 MS -> MS call, MSISDN number dialled

• The radio subscriber dials the number 0-4551-1234567890.
• The TETRA System ITSI country code is 4 digits long (mmmm).
• The TETRA System ITSI network code is 5 digits long (vvvvv).
Table 18 : TOC record, MS -> MS call, MSISDN number dialled

Served number MSISDN number of the calling party 10 bytes (i.e. 1358455122334455
including the MSISDN prefix digit, 18 digits)
PSTN country code, and network
code (without the first prefix digit).
The country code and network code
are optional, depending on the
configuration of the number analysis.
There is no need for the size of the
country and network code to be
fixed.
Table 18: TOC record, MS -> MS call, MSISDN number dialled (cont'd.)

Called number The MSISDN number of the called 14 135845511234567890
party
number modification within the DXT. No
number modification in this example.
number
Connected NITSI As above, NITSI format 10 2mmmmvvvvv7123456
Table 19 : TTC record, MS -> MS call, MSISDN number dialled

Served number MSISDN number of the called party 10 bytes (i.e. 135845511234567890
including the MSISDN prefix digit 18 digits)
otherwise NITSI)
number
B.3 MS -> MS call, FSSN number dialled

• The FSSN number of the calling party is 72 (max. 6 digits).
• The ISSI number the calling party is 7654321 (max. 7 digits).
• The calling party does not have an MSISDN number.
• The FSSN number of the called party is 73 (max. 6 digits).
• The FSSN prefix digit in the TETRA System is 3 (the same digit that is used as a prefix must also be
• The TETRA System ITSI country code is 4 digits (mmmm).
• The TETRA System ITSI network code is 5 digits (vvvvv).
• The FSSN base SSI is 15000000.
• The radio subscriber dials the number 373 -> SSI in the U-SETUP message is 15000073.
Table 20 : TOC record, MS -> MS call, FSSN number dialled

Served number NITSI number of the calling party 10 bytes 2mmmmvvvvv7654321
OR (i.e. max.
MSISDN number, if defined 18 digits)
Called number The FSSN number dialled by the 14 373
calling party
Translated The called number after number 14 2mmmmvvvvv7123456
number modification within the DXT
Connected The number of the connected party 14 2mmmmvvvvv7123456
number
Connected NITSI As above, NITSI format 10 2mmmmvvvvv7123456
Table 21 : TTC record, MS -> MS call, FSSN number dialled

Served number NITSI number of the called party 10 bytes 135845511234567890
OR (i.e. max.
MSISDN number, if defined 18 digits)
Calling number The address of the calling party 10 2mmmmvvvvv7654321
otherwise NITSI)
B.4 MS -> PSTN call

• The Gateway SSI is 16777184.
be defined as the preceding digit to the post-processing system)
• The PSTN prefix digit in the TETRA System is 0 (the same digit that is used as a prefix must also be
• The connection group digits in the TETRA System are 09. These digits are defined to be removed from
the digit string that is sent to the PSTN.
• The radio subscriber dials the number 09-1234567.
Table 22 : TOC record, MS -> PSTN call

Served number MSISDN number of the calling party 10 1358455122334455
including the MSISDN prefix digit,
PSTN country code and network
code.
Served NITSI As above, NITSI format 10 2mmmmvvvvvv7654321
Called number The number dialled by the calling 14 0091234567
party
Translated NITSI GW SSI, NITSI format 10 2mmmmvvvvv16777184
number
Connected NITSI Not used in this case 10 dummy value
Connection The connection group number 2 2341
group
Table 23 : Outgoing gateway record, MS -> PSTN call

MSISDN format (if applicable,
otherwise NITSI)
Calling NITSI As above in NITSI format 10 2mmmmvvvvvv7654321
Table 23: Outgoing gateway record, MS -> PSTN call (cont'd.)

Transmitted The number that was actually 14 1234567
number transmitted by the GDXT to the other
network
DXT id The identity of the GDXT 4 80900
Connection The connection group number of the 2 2341
group outgoing interface
B.5 PSTN -> MS call

The PSTN subscriber has dialled 0-4551-27654321.
Table 24 : Incoming gateway record, PSTN -> MS call, ITSI number dialled

Calling number The address of the calling party (if 14 051128337
received from the other network)
Called number The number of the called party as 10 2mmmmvvvvv7654321
received from the other network
(NITSI in this example)
number modification within the GDXT.
otherwise NITSI.
group
Table 25 : TTC record, PSTN -> MS call, ITSI number dialled

Served number MSISDN number of the called party 10 135845511234567890
code. If there is no MSISDN number
indicated in this TTC record.
Table 25: TTC record, PSTN -> MS call, ITSI number dialled (cont'd.)

Calling NITSI Not used when calling from PSTN 10 dummy
Organisation The organisation block of the called 12 2-5
block party
B.6 MS -> PABX call

• The call is connected to the PABX through gateway whose SSI is 16767000.
• The predefined connection group number for the PABX is 234.
• The PABX prefix digit in the TETRA System is 9 (the same digit that is used as a prefix must also be
• The radio subscriber dials the number 928337.
Table 26 : TOC record, MS -> PABX call

Served number MSISDN number of the calling party 10 1358455122334455
Served NITSI As above, NITSI format 10 2mmmmvvvvvv7654321
Called number The number dialled by the calling 14 9928337
party
Table 26: TOC record, MS -> PABX call (cont'd.)

Translated NITSI GW SSI, NITSI format 10 2mmmmvvvvv16767000
number
Connected NITSI Not used in this case 10 dummy value
group
Table 27 : Outgoing gateway record, MS -> PABX call

Calling number The address of the calling party. 10 1358455122334455
otherwise NITSI.
Calling NITSI As above in NITSI format 10 2mmmmvvvvvv7654321
Transmitted The number that was actually 14 928337
number transmitted by the GDXT to the other
network (the leading digit is not sent)
Connection The connection group number of the 2 234
group outgoing interface
B.7 PABX -> MS call

The PABX subscriber has dialled 0-4551-27654321. The incoming connection group number is 321.
Table 28 : Incoming gateway record, PABX -> MS call

Calling number The address of the calling party (as 14 928337
received from the other network)
Called number The number of the called party as 10 2mmmmvvvvv7654321
received from the other network
(NITSI, NGTSI, MSISDN or FSSN)
number modification within the GDXT.
otherwise NITSI.
Table 28: Incoming gateway record, PABX -> MS call (cont'd.)

group
Table 29 : TTC record, PABX -> MS call, ITSI number dialled

Served number MSISDN number of the called party 10 135845511234567890
indicated in this TTC record.
Calling NITSI Not used when calling from the 10 dummy
PABX
Organisation The organisation block of the called 12 2-5
block party
C Contents of CDR fields
The following abbreviations are used in the tables:
CC
Country code
DXT
The identity of the DXT of the called party
DXTC
The identity of the DXT of the calling party
DXTR
The identity of the DXT that produced the record
ORG
The organisation of the calling party (word)
SUBORG
The sublevels of the organisation of the calling party (5 words)
TNC
TETRA network code
C.1 Individual and group call: contents of the CDR fields in a

TETRA-originated and TETRA-terminated call
Possible CDRs in individual call
• TETRA-originated call (TOC)

• TETRA-terminated call (TTC)
Possible CDR in group call
• TETRA-originated call (TOC)
C.1.1 CDR fields in normal case, cause for termination = 01

Table 30 : TETRA-originated call, normal case (TOC)
TOC:
Record length Length of the record
Record type 01 (TOC)
Record version Version number
Recording entity DXTR
Table 30: TETRA-originated call, normal case (TOC) (cont'd.)
TOC:
Checksum Checksum of the fields
Recording Local record seq_nbr
sequence number
Partial record 00 (not in use)
sequence number
(currently not
available)
Number of partial 00 (not in use)
records (currently
not Number of
partial records
(currently not)
Number of SS 00 (not in use)
records (currently
not available)
Number of TOS 00 (not in use)
records (currently
not available)
Number of NRU 00 (not in use)
records (currently
not available)
Number of trunk 00 (not in use)
records (currently
not available)
Call reference Call id during one call
Served number 2|CC|TNC| ISSI
Served NITSI 2|CC|TNC| ISSI
Organisation block ORG|SUBORG
Called number 2|CC|TNC| ISSI
Translated number 2|CC|TNC| ISSI
Translated NITSI 2|CC|TNC| ISSI
Connected number 2|CC|TNC| ISSI
Connected NITSI 2|CC|TNC| ISSI
Connection group Connection group number, if the called subscriber is
a PSTN or PABX subscriber, otherwise FF FF.
Connected DXT id DXT
Served DXT id DXTC
Location area Location area *)
Cell identity Identity of the cell *)
Basic service used Structure of four bytes
Table 30: TETRA-originated call, normal case (TOC) (cont'd.)
TOC:
Basic service Structure of four bytes
requested
Call priority Value range 0...15
Urgency class Value range 0...6
Queuing priority Value range 0...240
Full / Half duplex 00 / 01, half / full duplex
Hook method 00 / 01, no hook sign. / hook on, off signalling
Air I/F encryption 00 = not in use
01 = in use
Number of members The default is that 0...100 members are shown.
in the group In order to show more than 100 group members, the
system parameter 373 Max MS count in group call
ToC has to be defined to have a greater value than
1. The parameter values (1–100) are multipliers for
100. E.g. value 50 means max. 50*100 = 5000
subscribers shown in TOC.
In the case of a location-based group call, the value
is always 0FFFFH (unknown).
Allocations 0 - FF FFf
Channel usage time 0 - FF FF FF FF
Number of groups 0 = not combined
List of groups -
Setup time Call setup was started
Answer time Call was answered, in group calls a dummy value
FF.
Connect time Call entered into progress
Release time Call was released
Call duration The chargeable duration for successful calls, the
holding time for call attempts
Cause for 01 (normal release)
termination
Diagnostics For internal use of Airbus DS.
*) In a call from the DWS to a radio terminal the field is filled with FF.
Table 31 : TETRA-terminated call, normal case (TTC)
TTC:
Record type 02 (TTC)
Table 31: TETRA-terminated call, normal case (TTC) (cont'd.)
TTC:
Recording Local record seq_nbr
sequence number
Partial record 00 (not in use)
sequence number
(currently not
available)
Number of partial 00 (not in use)
records (currently
not available
records (currently
not available)
Number of NRU 00 (not in use)
records (currently
not available)
Number of trunk 00 (not in use)
records (currently
not available)
Called NITSI 2|CC|TNC| ISSI
Calling number 2|CC|TNC| ISSI
Calling NITSI 2|CC|TNC| ISSI
Called DXT DXT of the called party
Location area Location area *)
Cell identity Identity of the cell of the served party*)
Basic service used Structure of four bytes
Call priority Value range 0...15
Urgency class Value range 0... 6
Queuing priority Value range 0...240
Full / Half duplex 00 / 01, half / full duplex
Hook method 00 / 01, no hook sign. / hook on, off signalling
Air I/F encryption 00 = not in use
01 = in use
Table 31: TETRA-terminated call, normal case (TTC) (cont'd.)
TTC:
Setup time Call setup was started
Answer time Call was answered, in group calls a dummy value
Connect time Call entered into progress
Release time Call was released
Call duration The chargeable duration for successful calls
(connect-release)
Cause for 01 (normal release)
termination
*) In a call from a radio terminal to the DWS the field is filled with FF.
C.1.2 CDR fields in a transferred call

When a call is transferred by a dispatcher, some of the charging records for the call are generated in two
parts: the first part of these records is created before the transfer and the second part after the transfer
has taken place.
Some fields in these records contain different values before and after the transfer. These values are explained
in the example cases below. See also section 4.3.3 .
C.1.2.1 Call transfer from a TETRA subscriber to an external subscriber
Charging records: TOC, TTC, Forw, TOC, OutG
Table 32 : Call transfer: MS -> DWS -> PSTN
Record Field Field explanation

TOC 1
Called number Number of the transferring dispatcher.
Translated number Number of the transferring dispatcher.
Translated NITSI Number of the transferring dispatcher.
Event time stamps: The setup time shows the original setup time
- Setup time of the call, answer time is the time when the
- Answer time transferring dispatcher answered the call,
- Connect time connect time is the time when the calling
- Release time subscriber and the transferring dispatcher
were connected to the call, and release time
is the time the transferring dispatcher was
released from the call.
Call duration Call duration counted from the beginning of
the call to the moment it was transferred.
Table 32: Call transfer: MS -> DWS -> PSTN (cont'd.)

TTC
Served number Number of the transferring dispatcher.
Served NITSI Number of the transferring dispatcher.
FORW
Cause for Call transfer.
forwarding
TOC 2
Called number The actual called subscriber’s number.
Translated number The actual called subscriber’s number.
Translated NITSI The actual called subscriber’s number.
Event time stamps: The setup time shows the actual time of
- Setup time transfer, answer time is the time when the
- Answer time actual called subscriber answered, connect
- Connect time time is the time when the calling subscriber
- Release time and the actual called subscriber were
connected to the call, and release time is the
final release time of the call.
Call duration Call duration from the transfer to the moment
the call was released.
OutG
C.1.2.2 Call transfer from an external subscriber to a TETRA subscriber
Charging records: InG, TTC, Forw, InG, TTC
Table 33 : Call transfer: PSTN -> DWS -> MS

InG 1
Called number Number of the transferring dispatcher.
Event time stamps: The seizure time shows the original setup
- Seizure time time of the call, answer time is the time when
- Answer time the transferring dispatcher answered the call,
- Release time and release time is the time the transferring
dispatcher was released from the call.
TTC 1
Served number Number of the transferring dispatcher.
FORW
forwarding
InG 2
Event time stamps: The seizure time shows the start time of the
- Seizure time transferred call, answer time is the time when
- Answer time the actual called subscriber answered, and
- Release time release time is the final release time of the
call.
Table 33: Call transfer: PSTN -> DWS -> MS (cont'd.)

TTC 2
Served number The actual called subscriber’s number.
Served ITSI The actual called subscriber’s number.
Event time stamps: The setup time shows the actual time of
- Setup time transfer, answer time is the time when the
- Answer time actual called subscriber answered, connect
- Connect time time is the time when the calling and the
- Release time actual called subscriber were connected to
the call, and release time is the final release
time of the call. This part of the TTC record is
generated only if the actual called subscriber
is a TETRA subscriber.
C.1.3 CDR fields in a forwarded call
C.1.3.1 Call forwarding from a dispatcher to a TETRA subscriber
Charging records: TOC, TTC, Forw
Table 34 : Call forwarding: MS -> DWS -> MS

TOC Called number The actual called subscriber’s number.
Connected number The forwarded-to party number.
Connected NITSI The forwarded-to party number.
- Answer time forwarded-to party answered the call, connect
- Release time and the forwarded-to party were connected to
the call, and release time is the time when the
calling subscriber was released from the call.

the call to the moment it was released.
Table 34: Call forwarding: MS -> DWS -> MS (cont'd.)

TTC Served number The forwarded-to party number.
Served NITSI The forwarded-to party number.
Calling number The calling party number.
Calling NITSI The calling party number.
Location area The forwarded-to party location area.
Cell identity The forwarded-to party cell id.
the call, and release time is the time when
the call was disconnected.
Call duration Chargeable duration of the connection

(connect -> release) for a successful call.
FORW Served NITSI The actual called subscriber’s number.

OB The actual called subscriber’s OB.
Forwarded-to The forwarded-to party number.
number
Forwarded-to NITSI The forwarded-to party number.
Event time stamps: Forward time is the time when the forwarding
- Forward time started. Answer time is the time when the
Call duration Chargeable duration of the connection

(connect -> release).
Cause for Call forwarding (from the actual called
forwarding subscriber to the forwarded-to party).
C.1.3.2 Call transfer from a dispatcher to a TETRA subscriber, followed by call

forwarding to a dispatcher
Charging records: TOC 1, TTC 1, Forw 1, TOC 2, TTC 2, Forw 2
Table 35 : Call transfer followed by call forwarding: MS -> DWS -> MS – DWS

TOC 1 Called number Number of the transferring dispatcher.
Connected number Number of the transferring dispatcher.
Connected NITSI Number of the transferring dispatcher.
is the time when the transferring dispatcher
was released from the call and the call was
transferred.
Call duration Call duration counted from the beginning

of the call to the moment it was
released/transferred.
Diagnostics Call transfer.
TTC 1 Served number Number of the transferring dispatcher.

Calling number Calling party number.
Calling NITSI Calling party number.
is the time when the transferring dispatcher
was released from the call.
Call duration Call duration counted from the beginning

of the call to the moment it was
released/transferred.
Diagnostics Call transfer.
Table 35: Call transfer followed by call forwarding: MS -> DWS -> MS – DWS (cont'd.)

FORW 1 Served NITSI Number of the transferring dispatcher.
OB The transferring dispatcher's OB.
Forwarded-to The forwarding party number.
number
Forwarded-to NITSI The forwarding party number.
Event time stamps: Forward time: forwarding time
- Forward time Answer time: empty in this case
- Answer time Connect time: empty
- Connect time Release time: empty
- Release time (Answer, connect and release time fields are
empty, because call transfer is followed by
call forwarding.)
Call duration Duration of call forwarding (from the

transferring dispatcher to the forwarding
party).
forwarding
TOC 2 Served number The calling subscriber's number.

Served NITSI The calling subscriber's number.
Called number The forwarding party number.
Translated number The forwarding party number.
Translated NITSI The forwarding party number.
Connected number The forwarded-to number.
Connected NITSI The forwarded-to number.
Call duration Call duration counted from the transfer to the

moment the call was released.
Table 35: Call transfer followed by call forwarding: MS -> DWS -> MS – DWS (cont'd.)

TTC 2 Served number The forwarded-to party number.
Served NITSI The forwarded-to party number.
Calling number The calling subscriber's number.
Calling NITSI The calling subscriber's number.
Call duration Call duration counted from the call transfer to

the moment the call was released.
FORW 2 Served NITSI The forwarding party number.

OB The forwarding party's OB.
Forwarded-to The forwarded-to party number.
number
Forwarded-to NITSI The forwarded-to party number.
Event time stamps: The forward time shows the forwarding time
- Forward time of the call, answer time is the time when the
Call duration Duration of call forwarding (from the

forwarding party to the forwarded-to party).
Cause for Call forwarding.
forwarding
C.1.4 CDR fields in a combined group call
The following CDR fields are used for a combined group call in the TOC record:
Table 36 : Combined group call (TOC)
TOC:
Number of members The default is that 0...100 members are shown.
in the group In order to show more than 100 group members, the system
parameter 373 Max MS count in group call ToC has to be defined
to have a greater value than 1. The parameter values (1–100)
are multipliers for 100. E.g. value 50 means max. 50*100 =
5000 subscribers shown in TOC.
*)
Allocations 0 - FF FF *)
The number of channels allocated to a combined group call.
Channel usage time 0 - FF FF FF FF *)
The cumulative usage time of all traffic channels used during
a combined group call.
Number of groups 2 - 8 ( = number of groups in the combination)
List of groups 2|CC|TNC| GSSI **)
*) The value in this field covers the whole combined group.
**) This field lists the NGTSI addresses (2-8) of groups that have been involved in the combined group call.
The number of NGTSIs is equal to the number of groups in the previous field. If the value of the Number of
groups -field is 0 (no combined groups), then the group list is not generated at all.
C.1.5 CDR fields in an ISI-linked group call
This section presents an example of the charging records created for an ISI-linked group call.
In this example case, three networks are involved in the group call. A TETRA subscriber starts the group
call by calling a local group in the originating network. This local group (originating group) has an ISI link
defined to a local group (controlling ISI group) in the controlling network. From the controlling network, the
call expands to a new local group (participating ISI group) in a participating network. Also the originating
group adopts the role of a participating ISI group when the call is connected.
The GTSI number of the controlling ISI group is used in all ISI connections during the call.
The charging records generated in this example are
- TOC and OutG in the originating network (O)
- InG, TOC and OutG in the controlling network (C)
- InG and TOC in the participating network (P).
Tables 37 to 39 show the typical contents of the CDR fields in an ISI-linked group call. See also Section 4.3.4 .
Table 37 : CDRs generated in the originating network
Record Field Description

O: TOC Recording entity Identity of the DXT that produced the record.
Call reference Local call ID which is the same in TOC, InG and OutG records
generated from the same ISI-linked group call within one network.
Calling number ITSI or MSISDN number of the TETRA subscriber who started the
group call.
Calling NITSI As above, NITSI format.
Organisation Organisation block of the TETRA subscriber who started the group
block call.
Called number NGTSI number of the originating group to which the call was made.
Translated NGTSI number of the originating group after number modification
number within the DXT.
Translated As above.
NGTSI
Connected As above.
number
Connected As above.
NGTSI
Connection Dummy value.
group
Connected DXT Dummy value.
id
Calling DXT id DXT of the TETRA subscriber who started the group call.
Allocations Total number of traffic channel allocations within one network during
the ISI-linked group call.
Channel usage Total cumulative usage time for all traffic channels that were used
within one network during the ISI-linked group call.
Setup time Time at which the call setup was started.
Answer time Dummy value.
Connect time Time at which the call was connected.
Release time Time at which the call was released.
Call duration Chargeable duration of the connection (connect → release) for a
successful ISI-linked group call, the holding time (setup → release)
for a call attempt.
Cause for Reason for the release of the connection.
termination 01 = normal release.
Table 37: CDRs generated in the originating network (cont'd.)

O: Recording entity Identity of the DXT that produced the record.
OutG
Calling number ITSI or MSISDN number of the TETRA subscriber who started the
group call.
Transmitted NGTSI number of the controlling ISI group transmitted by the
number gateway DXT.
DXT id Identity of the gateway DXT.
Outgoing HW connection that is used for the outgoing ISI interface:
interface - unit_idx (8)
- piu_type (PCM number)
- piu_idx (PCM timeslot)
- extline_idx (0xFF, not used)
Connection Used ISI connection group.
group
Other SwMI MNI MNI of the receiving TETRA network consisting of
- other_SwMI_MCC (length 1 word)
- other_SwMI_MNC (length 1 word)
Time stamp Event time stamps:
- seizure time = line reservation time of the group call
- answer time = time at which the group call is connected
- release time = time at which the group call is disconnected.
Call duration Chargeable duration of the connection (connect → release) for a
successful ISI-linked group call, the holding time (setup → release)
for a call attempt.
Pulses Dummy value.
Table 38 : CDRs generated in the controlling network

C: InG Recording Identity of the DXT that produced the record.
entity
generated from the same group call within one network.
Calling number ITSI or MSISDN number of the TETRA subscriber who started
the group call.
Called number NGTSI number of the controlling ISI group.
Table 38: CDRs generated in the controlling network (cont'd.)

Translated Dummy value.
number
Translated As above, NGTSI format.
NGTSI
Incoming HW connection that is used for the incoming ISI interface:
group
Other SwMI MNI of the calling TETRA network consisting of
MNI - other_SwMI_MCC (length 1 word)
Charging Not in use.
pulses
Call duration Chargeable duration of the connection (connect → release) for
a successful ISI-linked group call, the holding time (setup →
release) for a call attempt.
C: Recording Identity of the DXT that produced the record.

TOC entity
the group call.
Organisation Dummy value (contents of this field was not transmitted over
block the ISI).
Translated NGTSI number of the controlling ISI group after number
number modification within the DXT.

NGTSI
Connected As above.
number
Connected As above.
NGTSI
group
Connected DXT Dummy value.
id
Calling DXT id Identity of the incoming gateway DXT (DXT of the calling party
was not transmitted over the ISI).
Allocations Total number of traffic channel allocations within one network
during the ISI-linked group call.
Channel usage Total cumulative usage time for all traffic channels that were
used within one network during the ISI-linked group call.
C: Recording Identity of the DXT that produced the record.

OutG entity
Calling number ITSI or MSISDN number of the calling TETRA subscriber.
Transmitted NGTSI number of the controlling ISI group transmitted by the
number gateway DXT.

Outgoing HW connection that is used for the outgoing ISI interface:
group
Other SwMI MNI of the call receiving TETRA network consisting of
Pulses Dummy value.
Table 39 : CDRs generated in the participating network

P: InG Recording Identity of the DXT that produced the record.
entity
the group call.
Translated Dummy value.
number
Translated As above, NGTSI format.
NGTSI
Table 39: CDRs generated in the participating network (cont'd.)

Incoming HW connection that is used for the incoming ISI interface:
group
Other SwMI MNI of the calling TETRA network consisting of
Charging Not in use.
pulses
Time stamp Event time stamp:
P: TOC Recording Identity of the DXT that produced the record.

entity
the group call.
Organisation Dummy value (contents of this field was not transmitted over the
block ISI).
Translated NGTSI number of the participating ISI group after number
number modification within the DXT.
NGTSI
Connected As above.
number
Connected As above.
NGTSI
Table 39: CDRs generated in the participating network (cont'd.)

group
Connected Dummy value.
DXT id
Calling DXT id Identity of the incoming gateway DXT (DXT of the original calling
party was not transmitted over the ISI).
Allocations Total number of traffic channel allocations within one network
during the ISI-linked group call.
Channel usage Total cumulative usage time for all traffic channels that were used
within one network during the ISI-linked group call.
C.1.6 CDR fields, cause for termination = 02...09
If the cause for terminating a call is 02...09, the contents of the following fields differ from the normal CDR
fields.
Table 40 : Fields different from normal CDR fields (TOC)
TOC:
Connected number FF FF FF...
Connected NITSI FF FF FF...
Connected DXT id 00 00 00 00
Basic service used FF FF FF FF
Queuing priority FF
Duplex FF
Hook method FF
Answer time FF FF FF FF FF FF FF FF
Table 40: Fields different from normal CDR fields (TOC) (cont'd.)
TOC:
Connect time FF FF FF FF FF FF FF FF
Call duration 00 00 00 00 *)
Table 41 : Fields different from normal CDR fields (TTC)
TTC:
Called DXT id 00 00 00 00
Location area FF FF
Cell identity FF
Basic service used FF FF FF FF
Queuing priority FF
Duplex FF
Hook method FF
*) In case of
- cause of termination = 02-07, call duration refers to the holding time for call attempts (setup-release),
which is nearly zero
- cause of termination = 09 the call duration is the actual speech duration.
Example cases are: Cause for termination = 02/ 04/ 05
Cause for termination = 02:
• The called party is busy

• The called party is not reachable (out of radio coverage)
Changes also in the following fields:

TOC:
Location area FF FF (unused_ la_c)
Cell identity FF (unused_cell_c)
• called subscriber not registered to the system
• The valid or usable emergency address is not found in the database. Either there is no emergency
address defined in the database or the address was not valid or registered.

TOC:
Call priority 0F (emergency call)
TTC:
Called organisation block FF FF FF FF FF FF FF FF FF FF FF FF
Call priority 0F (emergency call)
• the calling subscriber has inadequate rights to set up an internal individual call
• the called subscriber has inadequate rights to receive an internal individual call
• the calling subscriber is trying to make a normal priority call to emergency ident

TTC:
Called organisation block FF FF FF FF FF FF FF FF FF FF FF FF
• call rejected by the called party
C.2 Short data and status message: contents of the CDR fields
in a TETRA-originated short data and status message
Possible CDR in short data or status message:
• TETRA-originated short data and status record (SDS_TO)

• Incoming gateway call attempt record (InG)
• Outgoing gateway call attempt record (OutG).
C.2.1 CDR fields in normal case, SDS result = 00/01

SDS result = 00:
• OK individual delivery
SDS result = 01:
• OK group delivery
Table 42 : CDR fields in normal case
Record type 05 (SDS-TO)

Record version Version of the record
Recording sequence Sequence number
number
records (currently
not available)
Table 42: CDR fields in normal case (cont'd.)

Served number 2|CC|TNC| ISSI
Served NITSI 2|CC|TNC| ISSI
Translated number 2|CC|TNC| ISSI
Translated NITSI 2|CC|TNC| ISSI
Connected number 2|CC|TNC| ISSI
Connected NITSI 2|CC|TNC| ISSI
Connection group FF FF (not in use)
Originating DXT id DXTC
Location area The location area of the served party
Cell identity The identity of the cell
Target DXT id DXT
Target location area The location area of the target subscriber.
Target channel type The channel that was used or tried to be used for data
message transfer.
SDS TL protocol SDS-4 protocol identifier
Forward number 2 | CC | TNC | ISSI
Translated forward 2 | CC | TNC | ISSI
number
transfer/report flag Values 0/1
Message reference Value range 0–255
SDS service type Values 0/1, FF unknown
SDS type Value range 0...4, FF unknown
SDS length The length of user defined data
Sending profile Profile used for SDS-4 message sending
Number of groups 0 (= not combined)
List of groups -
Time stamp Time at which short data/status was received.
Cells distributed Number of location areas to which the SDS was
distributed.
Cells reached Number of location areas to which the SDS was
successfully delivered.
Table 42: CDR fields in normal case (cont'd.)
Dispatchers reached Number of dispatchers to which the SDS was

successfully delivered.
NOTE: The value range is normally 0...254. Value
255 indicates that there are 255 or more dispatcher
workstations to which the message was delivered.
C.2.2 CDR fields in a data message delivery to a combined group

The following fields of the SDS-TO record are related to data message delivery to a combined group:
Table 43 : Data message delivery to a combined group
Number of groups 2 - 8 (= number of groups in the combination)

List of groups 2|CC|TNC| GSSI *)
Cells distributed Number of location areas within a combined group area
to which the SDS was distributed.
Cells reached Number of location areas within a combined group area
to which the SDS was successfully delivered.
Dispatchers reached Number of dispatchers in the combined group to whom
the SDS was successfully delivered.
NOTE: The value range is normally 0...254. Value
255 indicates that there are 255 or more dispatcher
workstations to which the message was delivered.
*) This field lists the NGTSI addresses of groups to which the message was sent. The number of NGTSIs
is equal to the number of groups in the previous field. If the value of the Number of groups -field is 0 (no
combined groups), then the group list is not generated at all.
C.2.3 CDR fields in a data message delivery via SMSGW

In addition to the definitions made by the MML commands, a precondition for activating the generation of
CDRs for data messages sent via SMSGW is that the system parameter Charging options for SMSGW has
been set correctly. This parameter has the following values:
• 0 - Create charging record for messages to and from SMSGW
• 1 - Suppress charging record for messages to SMSGW
• 2 - Suppress charging record for messages from SMSGW
• 3 - Suppress charging record for messages to and from SMSGW.
From the DXT point of view, a data message sent via SMSGW consists of two separate messages, the first
message being transmitted from the calling subscriber to the SMSGW and the second from the SMSGW to
the called subscriber. Messages arriving from the SMSGW can be originated from a TETRA network or an
external network (e.g. GSM).
SDS-TO records are produced separately for the messages from the calling subscriber -> SMSGW and
SMSGW -> called subscriber when calling and the called subscribers are TETRA subscribers. When the
calling / called subscriber belongs to an external network, a CDR is produced for the message from the
SMSGW -> called TETRA subscriber / calling TETRA subscriber -> SMSGW respectively.
A data message sent between TETRA subscribers without using the SMSGW is handled similarly to a normal
delivery case (i.e. the forward address is not needed).
The following table gives a simplified presentation of the contents of individual subscriber address fields
in each transmission phase.
Table 44 : Contents of the address fields
Address field calling subscriber –> SMSGW –> called calling > called
SMSGW subscriber subscriber
(without
SMSGW)
Calling address *) calling subscriber SMSGW calling
subscriber
Called address *) SMSGW called subscriber called
subscriber
Forward address *) called subscriber called subscriber empty
*) This address refers to all CDR fields containing different formats of this particular address (original /
translated / NITSI). For a detailed list of address fields, see Table 42 .
C.2.4 CDR fields, SDS result = 02...0A

Example cases:
SDS result = 02:
• Failed individual delivery

Cells reached 0
Dispatchers reached 0
Cells distributed 01 00 (1)
SDS result = 08:
• SDS message too long

Location area FF FF
Cell identity FF
SDS result = 09:
• Illegal service request
SDS result = 0A:
• Destination address unknown.
C.3 Registration: contents of the CDR fields in TETRA-originated

registration
Possible CDR in registration
• TETRA-originated registration record (Reg)
C.3.1 CDR fields in a normal case

Tables 45 and 46 present an example of the contents of the registration CDR produced when a TETRA
subscriber registers to the network, deregisters from it or performs a migrating registration.
Table 45 : CDR fields in a normal case (ITSI attach)
Basic registration (ITSI attach)

Reg:
Record type 09 (Reg)
Recording sequence number Local record seq_nbr
Served NITSI 2 | CC | TNC | ISSI
Assigned NITSI FF (not in use)
Originator ITSI FF (not in use)
Organisation block ORG | SUBORG
TEI TEI number if known or 00
Registration type 3 (itsi attach)
Authentication FF (authentication succeeded)
Agreed encryption FF (clear)
Class of MS MS class in TETRA
Subscriber class Subscriber class received in the registration.
DXT id DXTR
Previous DXT id 00 (not in use)
Table 45: CDR fields in a normal case (ITSI attach) (cont'd.)
Basic registration (ITSI attach)

Location area Location area
Previous location area FFFF (not in use)
Cell identity Identity of the cell
Channel type Radio channel type used in registration.
Time stamp Registration time
Registration accepted 1 (registration accepted)
Reject cause FF (operation succeeded)
Table 46 : CDR fields in a normal case (ITSI detach)
Basic de-registration (ITSI detach)

Reg:
Registration type FD (itsi detach)
Authentication FF (authentication succeeded)
DXT id DXTR
Time stamp De-registration time
Registration accepted 1 (operation succeeded)
C.3.2 CDR fields in roaming registration

Table 47 shows the contents of the registration CDR in roaming type registrations.
Table 47 : CDR fields in roaming registration
Roaming registration
Reg.
Table 47: CDR fields in roaming registration (cont'd.)
Roaming registration
Served NITSI 2 | CC | TNC | ISSI (Radio subscriber number)
Assigned NITSI FF (not in use)
Originator NITSI FF (not in use)
TEI TEI number if known or 00
Registration type 0 (Roaming location updating)
Authentication FF (not in use)
DXT id DXTR
Previous DXT id Previous DXTR
Previous location area Previous location area
Time stamp Registration time
Registration accepted 1 (registration accepted)
C.3.3 CDR fields in RUA/RUD request

Tables 48 and 49 show the contents of the registration CDR in the case when an alias identity is assigned to
a radio subscriber (RUA) or when this identity is disassigned (RUD). From the alias subscriber's point of
view, the assignment of the alias identity is comparable to the registration to the system (ITSI attach) and
disassignment to the de-registration (ITSI detach).
Table 48 : CDR fields in RUA request
RUA request
Reg.

Assigned NITSI 2 | CC | TNC | ISSI (Assigned alias identity)
Originator NITSI 2 | CC | TNC | ISSI
(Originator identity of the 3rd party RUA if
applicable or FF (not in use))
TEI TEI number (not in use)
Registration type 247 (RUA)
Agreed encryption FF (not in use)
Class of MS MS class in TETRA (not in use)
DXT id Location DXT of the radio subscriber performing
a RUA operation
Time stamp Time of the RUA operation
Registration accepted 1 (RUA succeeded)
Table 49 : CDR fields in RUD request
RUD request
Reg:
Table 49: CDR fields in RUD request (cont'd.)
RUD request
Record ersion Version number
Assigned NITSI 2 | CC | TNC | ISSI (Assigned alias identity)
Originator NITSI 2 | CC | TNC | ISSI
(Originator identity of the 3rd party RUD if
applicable or FF (not in use))
TEI TEI number (not in use)
Registration type 248 (RUD)
Agreed encryption FF (not in use)
Class of MS MS class in TETRA (not in use)
DXT id Location DXT of the radio subscriber performing
a RUD operation
Time stamp Time of the RUD operation
Registration accepted 1 (RUD succeeded)
Glossary
The meanings of the abbreviations 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 TETRA System customer documentation, please see document Glossary, dn00126469.
Term / acronym Meaning

APN Access Point Name
AVL Automatic Vehicle Location
BC Billing Centre
BCD Binary Coded Decimal
CCC Call Control Computer
CDR Charging Data Record
CMM Central Memory and Marker (computer unit)
DDS Digital Data Storage
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
Dword Double word
DWS Dispatcher Work Station
DXT Digital Exchange for TETRA. A generic term.
DXTip DXT, 2nd generation, improved platform
FNIM Fixed Network Interface Module
FNIM ET Fixed Network Interface Module, based on ET exchange
FSSN Fleet Specific Short Number
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
G4WIF General Four-wire Interface
GDXT Gateway DXT
GGSN Gateway GPRS Support Node
HBLOFI Hot Billing Logical File
InG Incoming Gateway Call
I/O Input/Output
IP Internet Protocol
IPv4 IP Protocol version 4
IPv6 IP Protocol version 6
ISDN Integrated Services Digital Network
ISI Inter-System Interface
ISO International Standards Organisation
ISSI Individual Short Subscriber Identity
ITSI Individual TETRA Subscriber Identity
LAN Local Area Network
MMI Man-Machine Interface
MML Man-Machine Language
MNI Mobile Network Identity
MO Magneto-optical (disk)
MS Mobile Subscriber / Mobile Station
MSISDN Mobile Subscriber-Integrated Services Digital Network
NGTSI Numeric Group TETRA Subscriber Identity
NITSI Numeric Individual TETRA Subscriber Identity
NRU Network Resource Usage
OMU Operation and Maintenance Unit
OSI Open Systems Interconnection
OutG Outgoing Gateway Call
PABX Private Automatic Branch Exchange
PD Packet Data
PDP Packet Data Protocol
PDU Protocol Data Unit
POC Pseudo Open Channel
PSTN Public Switched Telephone Network
Qos Quality of Service
R2 Signalling system based on ITU-T Q.400–Q.480
RAM Random Access Memory
SDS-TO Short Data and Status, TETRA Originated
SIP Session Initial Protocol
SIP GW SIP gateway. Device used as a gateway between DXT3 and PSTN/PABX.
SMSC SMS Centre
SMSGW SMS Gateway
SN Subscriber Number part of an MSISDN number
SS Service Subscriber
SSI Short Subscriber Identity
STU Statistical Unit
SwMI Switching and Management Infrastructure
TCH Traffic Channel
TCP Transmission Control Protocol. A connection-oriented transport layer
protocol in TCP/IP protocol suite
TEDS TETRA Enhanced Data Service
TCP/IP Transmission Control Protocol/Internet Protocol
TEI TETRA Equipment Identity
TLIA TETRA Line Interface Adapter type A
TLIC TETRA Line Interface Adapter type C
TOC TETRA Originated Call
TOS Trunk Offering Start
TTC TETRA Terminated Call
UDP User Datagram Protocol. A Connectionless transport layer protocol in
TCP/IP Protocol suite
USB Universal Serial Bus
VDS Virtual Data Storage
VDU Visual Display Unit
X.25 Standard Protocol according to CCITT
INDEX
A event time stamp.......................................... 41

preventing generation .................................. 39
acknowledged SDS service............................. 57 structure ....................................................... 15
alias transferring................................................... 23
identity.......................................................... 32 types of .................................................. 31, 43
reject causes................................................ 67 class of MS ...................................................... 69
RUA/RUD............................................. 42, 120 combined group
APN data message ................................ 37, 60, 116
function ........................................................ 39 group call ............................................. 36, 104
cover group...................................................... 35
B
bcd (binary coded decimal) number D
strings ............................................................ 68
data message
to a combined group .................................... 37
C to a location-based group ............................ 37
to an ISI-linked group................................... 38
calendar time
type definition............................................... 70
fields............................................................. 69
via SMSGW ............................................... 116
call control computer unit................................. 14
data message via SMSGW ............................. 61
call priority
dedicated data group....................................... 35
definition....................................................... 69
DXT exchange
call transfer ................................................ 34, 97
identity number ............................................ 78
CDFILE............................................................ 14
CDR content formatting ................................... 31
cell E
definition....................................................... 73
encryption method ........................................... 73
central memory and marker............................. 14
chargeable call duration
end ............................................................... 32 F
starting ......................................................... 32 FNIM.................................................... 71, 76, 80
charging control files FNIM ET .............................................. 71, 76, 80
fields............................................................. 18 Forw record
location......................................................... 17 fields............................................................. 54
charging disk file size............................................................... 54
changing state manually .............................. 20 FTAM ............................................................... 29
state transitions............................................ 20 FTP.................................................................. 28
status ........................................................... 18
charging pulse ................................................. 33
charging record
G
collecting and storing ................................... 13 group call
to an ISI-linked group .......................... 36, 105 numbering system ........................................... 83
H O
HBLOFI............................................................ 14 O&M network................................................... 27
hook call .......................................................... 33 OMU disks
required size ................................................ 20
I organisation block
identifying..................................................... 73
individual call over the ISI................................ 32 OSI
InG record commercial programs .................................. 28
fields............................................................. 50 protocol stack............................................... 28
size............................................................... 50 transmission routes...................................... 27
IP protocol address OutG record
definition....................................................... 72 fields............................................................. 52
ISDN .................................................... 71, 76, 80 size............................................................... 52
ISI ........................................................ 71, 76, 80
ISI-linked group
data message .............................................. 38
P
group call ............................................. 36, 105 packet data ...................................................... 39
ISO-OSI model application layer ..................... 29 packet data service.......................................... 74
PD record fields ............................................... 61
L priority level of the call

definition....................................................... 78
LAN connection
size............................................................... 26
LAN interface
Q
speed ........................................................... 26 Quality of Service ............................................ 74
location area
definition....................................................... 73
location update type ........................................ 72
R
location-based group radio channel type in data message
data message .............................................. 37 sending .......................................................... 79
group call ..................................................... 35 Radio channel type used in registration .......... 79
logical file......................................................... 21 RAM block
changing the size ......................................... 20
size............................................................... 20
M Reg record
magneto-optical disk.................................. 14, 22 contents ..................................................... 118
migrating registration ............................... 42, 118 fields............................................................. 64
mobile network identity .................................... 67 size............................................................... 64
registration CDR ........................................ 14, 42
reject cause
N alias ............................................................. 67
network-wide call identifier packet data .................................................. 75
definition....................................................... 69 radio terminal ............................................... 77
roaming registration................................... 42, 72 combined group call............................... 36, 47
RUA/RUD ................................................ 42, 120 dedicated data group call............................. 35
fields............................................................. 43
S group call ..................................................... 35
individual call................................................ 32
SDS size............................................................... 43
group addressed .......................................... 37 TTC record
individually addressed.................................. 37 fields............................................................. 47
individually addressed over the ISI .............. 37 size............................................................... 47
to an ISI-linked group .................................. 38 TTTCOF
SDS delivery ack ............................................. 70 time stamp field............................................ 18
SDS-4 sending profile...................................... 78
SDS-4 sending protocol................................... 78
SDS-TO record
U
about ............................................................ 37 unsuccessful call attempt
data message .............................................. 37 CDR ............................................................. 42
fields............................................................. 57 urgency class of the call .................................. 81
size............................................................... 57 USB memory stick ........................................... 14
SIP....................................................... 71, 76, 80
SMSGW..................................................... 57, 61
activation.................................................... 116
V
statistical unit ................................................... 14 VDS device index ............................................ 15
Subscriber class in registration........................ 78 VDS system
changing the configuration........................... 21
T
TEDS ............................................................... 39
X
termination of the call ...................................... 80 X.25 connection............................................... 27
TOC record X.25 interface .................................................. 29
alias identity ................................................. 32

TETRA System Release 7.0: Charging Services: DXT - CDR Interface Description

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TETRA System Release 7.0: Charging Services: DXT - CDR Interface Description

Uploaded by

Copyright:

Available Formats

Charging Services: DXT - CDR Interface Description

TETRA System Release 7.0

Copyright © 2015–2016 Airbus DS SLC, all rights reserved.

DN00126566-19-4en TETRA System Release 7.0

1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Charging data in DXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Transferring charging data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

TETRA System Release 7.0 DN00126566-19-4en

A Data types used in charging records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

DN00126566-19-4en TETRA System Release 7.0

B Identification of the calling and called party in charging records . . . . . . . . . . . . . . . . . . . . . . . . . 83

C Contents of CDR fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

TETRA System Release 7.0 DN00126566-19-4en

DN00126566-19-4en TETRA System Release 7.0

TETRA System Release 7.0 DN00126566-19-4en

DN00126566-19-4en TETRA System Release 7.0

VERSION DATE COMMENTS CHAPTER

TETRA System Release 7.0 DN00126566-19-4en

1. Guide to TETRA Documentation, dn00126445

3. Data File Transfer from VDS Device to Post-processing System, dn9962025

4. GA - Dynamic Data Handling, dn98908517

6. GT - Detailed Charging Handling, dn98793148

7. IF - Virtual Data Storing Device Handling, dn99613829

DN00126566-19-4en TETRA System Release 7.0

How to use this document

The chapters of this document are organised as follows:

• Chapter 1 About this document introduces the structure of the document.

An Index is provided at the end of this document.

TETRA System Release 7.0 DN00126566-19-4en

DN00126566-19-4en TETRA System Release 7.0

USB MO disk Hard disks

Figure 1 : Handling of charging records generated by OMU/CMM/CCC

TETRA System Release 7.0 DN00126566-19-4en

CDR TCP /IP

MO disk Hard disks

Figure 2 : Handling of charging records generated by STU in the DXTip

2.2 Using the disks for CDR storing

DN00126566-19-4en TETRA System Release 7.0

Figure 3 : The structure of charging disk files

TETRA System Release 7.0 DN00126566-19-4en

DN00126566-19-4en TETRA System Release 7.0

FIELD DESCRIPTION HEX FORMAT FIELD CONTENT

Table 2 : Description of trailer record fields

FIELD DESCRIPTION HEX FORMAT FIELD CONTENT

2.3 Charging control files

• TTSCOF (VDS Device Data Storage Control File)

• TTTCOF (VDS Device Data File Transfer Control File)

TETRA System Release 7.0 DN00126566-19-4en

Table 3 : Structure of time stamp field in TTSCOF

Offset (byte) Unit Example

• COMPRESSING (value 04H) - compression is in progress.

DN00126566-19-4en TETRA System Release 7.0

Functionality of the charging control files

Figure 5 : State transitions of charging disk files

TETRA System Release 7.0 DN00126566-19-4en

2.4 Storing capacity

DN00126566-19-4en TETRA System Release 7.0

2.5 Configuration of VDS

2.6 Logical file connections

TETRA System Release 7.0 DN00126566-19-4en

DN00126566-19-4en TETRA System Release 7.0

3.1 Transfer process using DXT hard disks

TETRA System Release 7.0 DN00126566-19-4en