DB GSM-R Iot Test Specification

File: IOT - Test Specification_amendment_F017_2011_10_14
Interoperability of EIRENE Networks

IOT Test Specification
for EIRENE networks

Functional interoperability tests

- Amendment -

DB Systel GmbH

Author: DB Systel GmbH

Version: F017_111014

Status: Final

Date: 14.10.2011
DB Systel GmbH

IOT Test Specification for EIRENE networks

IOT Test Specification for EIRENE networks Page: 2 von 1839
Table of Contents
1 General 14
1.1 Evolution Sheet 14
1.2 Involved Notified Bodies 15
1.3 References 16
1.4 Abbreviations 18
2 Introduction 20
3 Overview and basis 21
4 Prerequisites and Test configuration 23
4.1 Prerequisites for IOT testing on EIRENE networks 23
4.2 Reference configuration of EIRENE network 24
4.3 IOT Test scenarios 26
4.4 Nomenclature 28
4.5 Test environment and test conditions 35
4.6 Test configuration 35
4.6.1 Test configuration GSMR Network 35
4.6.2 Test configuration for Functional Addressing 38
4.6.3 Test configuration of Location Depending Addressing (LDA) 40
4.6.4 Check of GSM-R network parameters 40
4.7 Test equipment 41
4.7.1 EIRENE Mobile Stations, EIRENE Controller Terminals 42
4.7.2 EIRENE SIM, Subscriber profiles 42
4.7.3 Air Interface Simulator 45
4.7.4 Optional test equipment 46
5 IOT Tests Cases 47
5.1 Basic and Supplementary Services 48
5.1.1 Successful Location Update after MS Power On (non-roaming case) 48
5.1.2 Successful Location Update after change of Location Area (non-roaming case)50
5.1.3 Unsuccessful Location Update (subscription in HLR is unknown) (non-roaming
case) 52
5.1.4 Unsuccessful Location Update ( due to PLMN not allowed) (non-roaming case)54
5.1.5 Successful Location Cancellation (non-roaming case) 56
5.1.6 IMSI Detach by MS Power Off (non-roaming case) 58
5.1.7 MTM to detached mobile subscriber (non-roaming case) 60
5.1.8 MTM, mobile subscribers are in different location areas (non-roaming case) 62


5.1.9 MTM, radio link failure on A-side, A and B subscriber are in different cell (non-
roaming case) 64
5.1.10 Supplementary Service Call Hold (non-roaming case) 66
5.1.11 Supplementary Service Call Waiting (non-roaming case) 68
5.1.12 Supplementary Service CLIP MMC with Call Forwarding Unconditional (non-
roaming case) 70
5.1.13 Supplementary Service CoLP (non-roaming case) 72
5.1.14 Supplementary Service MPTY (incl. Multivendor MPTY) (non-roaming case) 74
5.1.15 Notification of Call Forwarding (non-roaming case) 77
5.1.16 Establishment of several MTM Data calls (Bearer Services) with different
eMLPP priorities (non-roaming case) 79
5.1.17 Establishment of several PTP calls with different priorities (non-roaming case)83
5.1.18 Call to busy Mobile CFBusy to other mobile subscriber (non-roaming case) 85
5.1.19 MOC call when terminator rejects call (non-roaming case) 87
5.1.20 Unsuccessful MOC call due to unallocated number (non-roaming case) 89
5.1.21 MTC call Paging Time Out (non-roaming case) 91
5.1.22 Unsuccessful MTC, subscriber not in VLR (non-roaming case) 93
5.1.23 Successful Location update after MS Power On (roaming case) 95
5.1.24 Successful Location Update after change of Location Area (roaming case) 98
5.1.25 Unsuccessful Location Update (subscription in HLR is unknown) (roaming case)100
5.1.26 Unsuccessful Location Update (due to PLMN not allowed) (roaming case) 102
5.1.27 Successful Location Cancellation (roaming case) 104
5.1.28 Successful IMSI Detach by MS Power Off (roaming case) 106
5.1.29 MTM to detached mobile subscriber (roaming case) 108
5.1.30 MTM, mobile subscribers are in different Location areas (roaming case) 110
5.1.31 MTM, radio link failure on A-side, A and B subscriber are in different cell
(roaming case) 116
5.1.32 Supplementary Service Call Hold (roaming case) 119
5.1.33 Supplementary Service Call Waiting (roaming case) 123
5.1.34 Supplementary Service CLIP MTM with Call Forwarding Unconditional
(roaming case) 126
5.1.35 Supplementary Service CoLP (roaming case) 128
5.1.36 Supplementary Service MPTY (incl. Multivendor MPTY) (roaming case) 131
5.1.37 Notification of Call Forwarding (roaming case) 138
5.1.38 Establishment of several MTM Data calls (Bearer Services) with different
eMLPP priorities (roaming case) 141
5.1.39 Establishment of several PTP calls with different priorities (roaming case) 157
5.1.40 Call to busy Mobile CFBusy to other mobile subscriber (roaming case) 160
5.1.41 MOC call when terminator rejects call (roaming case) 166
5.1.42 Unsuccessful MOC due to unallocated number (roaming case) 168
5.1.43 MTC Paging Time Out (roaming case) 171
5.1.44 Unsuccessful MTC call, subscriber not in VLR (roaming case) 173
5.1.45 Closed User Group (non-roaming case) 176
5.1.46 Closed User Group (roaming case) 183


5.1.47 Call barring (roaming case) 210
5.1.48 Public Emergency Call With SIM (non-roaming case) 215
5.1.49 Public Emergency Call Without SIM (non-roaming case) 217
5.1.50 Public Emergency Call with TMSI and IMSI unknown in VLR (non-roaming
case) 219
5.1.51 Public Emergency Call With SIM (roaming case) 221
5.1.52 Public Emergency Call Without SIM (roaming case) 223
5.1.53 Public Emergency Call with TMSI and IMSI unknown in VLR (roaming case)225
5.2 Functional Addressing 227
5.2.1 Register of a FN (non-roaming case) 227
5.2.2 Register 3 functional numbers to one user (non-roaming case) 230
5.2.3 Register 3 functional numbers to one user (roaming case) 232
5.2.4 Registration of an unknown FN fails (non-roaming case) 235
5.2.5 Deregistration of a FN (non-roaming case) 237
5.2.6 Deregistration of a FN fails (non-roaming case) 240
5.2.7 Forced Deregistration of a FN (non-roaming case) 242
5.2.8 Forced Deregistration of a FN fails (non-roaming case) 244
5.2.9 Class of Registration (CoR) check (non-roaming case) 246
5.2.10 Registration of a FN (roaming case) 248
5.2.11 Registration of a unknown FN fails (roaming case) 254
5.2.12 Check of the storage of CT2 Number and its destination in the current EIRENE
network. 256
5.2.13 Check of the storage of CT3 Number and the according destination in the home
EIRENE network. 258
5.2.14 Check of the storage of CT4 Number and its destination in the home EIRENE
network. 260
5.2.15 Check of the storage of CT6 and CT7 Numbers and their destinations in the
home EIRENE network. 262
5.2.16 Registration failures --> outcome code 61 [remote party already registered]
(non-roaming case) 264
5.2.17 Registration failures --> outcome code 61 [remote party already registered]
(roaming case) 266
5.2.18 Deregistration of a FN (roaming case) 269
5.2.19 Deregistration of a FN fails (roaming case) 273
5.2.20 Forced Deregistration of a FN (roaming case) 276
5.2.21 Forced Deregistration of a FN fails due to a missing supervisor CoR (roaming
case) 279
5.2.22 Class of registration (CoR) check (roaming case) 282
5.2.23 FFN recovery 285
5.2.24 FA Call Successful Call (national call) 287
5.2.25 FA Call Call is not completed (national call) 292
5.2.26 FA Call Successful Call (international call) 294
5.2.27 FA Call Call is not completed (international call) 298
5.3 Access Matrix and Access to External Networks 300


5.3.1 National call: AM allows call 301
5.3.2 National call: AM denies call 304
5.3.3 International call: AM allows call 308
5.3.4 International call: AM denies call 313
5.3.5 Calling party outside the EIRENE network (non-roaming case) 318
5.3.6 Calling party outside the EIRENE network (roaming case) 320
5.3.7 Access to other GSM-R networks: Break out codes (non-roaming case) 322
5.3.8 Access to other GSM-R networks: Break out codes (roaming case) 325
5.3.9 Access to public networks (non-roaming case) 328
5.3.10 Access to public networks (roaming case) 330
5.3.11 Access to private networks: Break out codes (non-roaming case) 333
5.3.12 Access to private networks: Break out codes (roaming case) 335
5.4 Location Depending Addressing 337
5.4.1 LDA call (non-roaming case) 337
5.4.2 LDA call fails (non-roaming case) 339
5.4.3 LDA call (roaming case) 341
5.4.4 LDA call fails (roaming case) 343
5.5 MLPP 345
5.5.1 PtP call pre-emption at the E-IF between two networks by REC 347
5.5.2 PtP call pre-emption at the E-IF between two networks by an other PtP call 359
5.5.3 Link to a controller of a VGCS call is pre-empted at the E-IF between two
networks and at the PRI by REC 362
5.5.4 Link to the originator as first talker of a VGCS call is pre-empted at the E-IF
between two networks by REC 368
5.5.5 Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF
between two networks by REC 372
5.5.6 Link to a controller of a VGCS call is pre-empted at the E-IF between two
networks by PtP call 376
5.5.7 Link to the originator as first talker of a VGCS call is pre-empted at the E-IF
between two networks by PtP call 380
5.5.8 Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF
between two networks by PtP call 384
5.5.9 Inter MSC handover of a point to point voice call with MLPP pre-emption at E-IF388
5.5.10 Inter MSC handover of a circuit switched data call with MLPP pre-emption at E-
IF 390
5.5.11 Inter MSC handover of a railway emergency call originator with pre-emption at
E-IF 392
5.5.12 Inter MSC handover of a VGCS dedicated channel with MLPP pre-emption at
E-IF 396
5.5.13 Inter MSC handover of a VBS originator channel with MLPP pre-emption at E-IF400
5.6 Railway Emergency Call (REC), Late Entry (LE) 404
5.6.1 REC call setup by a service subscriber (non-roaming case) 404
5.6.2 REC call setup by a controller 408
5.6.3 REC notification and joining (non-roaming case) 411


5.6.4 REC acknowledgement (non-roaming case) 418
5.6.5 REC call setup by a service subscriber (roaming case) 421
5.6.6 REC notification and joining (roaming case) 437
5.6.7 REC acknowledgement (roaming case) 507
5.6.8 C-OTDI check 556
5.6.9 LE idle mode (non-roaming case) 560
5.6.10 LE dedicated mode (non-roaming case) 565
5.6.11 LE group receive mode (non-roaming case) 570
5.6.12 LE group transmit mode (non-roaming case) 577
5.6.13 LE group mode, dedicated channel (non-roaming case) 585
5.6.14 LE idle mode (roaming case) 592
5.6.15 LE dedicated mode (more than one MSC) 599
5.6.16 LE group receive mode (roaming case) 607
5.6.17 LE group transmit mode (more than one MSC) 621
5.6.18 LE group mode, dedicated channel (more than one MSC) 635
5.6.19 REC call is taken down due to expiry of No activity timer. 649
5.6.20 REC first talker notification (MS dedicated mode, incoming PTP call, non
roaming case) 651
5.6.21 REC first talker notification (MS dedicated mode, incoming VGCS call, non
roaming case) 654
5.6.22 REC first talker notification (MS dedicated mode, incoming VBS call, non
roaming case) 657
5.6.23 REC first talker notification (MS dedicated mode, incoming PTP call, roaming)660
5.6.24 REC first talker notification (MS dedicated mode, incoming VGCS call, roaming)675
5.6.25 REC first talker notification (MS dedicated mode, incoming VBS call, roaming)715
5.6.26 REC first talker notification (MS dedicated mode, incoming second REC, non
roaming case) 752
5.6.27 REC first talker notification (MS dedicated mode, incoming second REC,
roaming) 755
5.6.28 Shunting emergency call (non-roaming case) 781
5.6.29 Shunting emergency call (roaming case) 785
5.7 eMLPP 801
5.7.1 MS in VBS call as listener, pre-emption on MS by higher prio PtP call 804
5.7.2 MS in VGCS call on DCH, pre-emption on Um by higher prio PtP call 806
5.7.3 MS in VGCS call having the UL of the GCH, pre-emption on A IF by higher prio
PtP call 808
5.7.4 MS in PEC, pre-emption on A-IF by higher prio PtP call 811
5.7.5 MS in PtP call, pre-emption on MS by higher prio VBS call 813
5.7.6 MS in VBS call as originator, pre-emption on A IF by higher prio VBS call 815
5.7.7 MS in VBS call as listener, pre-emption on Um by higher prio VBS call 817
5.7.8 MS in VGCS call on DCH, pre-emption on MS by higher prio VBS call 819
5.7.9 MS in VGCS call having the UL of the GCH, pre-emption on Um by higher prio
VBS call 821
5.7.10 MS in data call, pre-emption on A IF by higher prio VBS call 823


5.7.11 MS in PEC, pre-emption on Um by REC 825
5.7.12 MS in PtP call, pre-emption on A IF by higher prio PtP call 827
5.7.13 MS in PtP call, pre-emption on MS by higher prio VGCS call (REC) 829
5.7.14 MS in VBS call as originator, pre-emption on Um by higher prio VGCS call
(REC) 831
5.7.15 MS in VBS call as listener, pre-emption on A IF by higher prio VGCS call (REC)833
5.7.16 MS in VGCS call having the UL of the GCH, pre-emption on MS by higher prio
VGCS call (REC) 835
5.7.17 MS in VGCS call as listener, pre-emption on A IF by higher prio VGCS call
(REC) 837
5.7.18 MS in data call, pre-emption on Um by higher prio VGCS call (REC) 839
5.7.19 MS in PtP call, pre-emption on Um by higher prio data call (4.8 kbit/s,
transparent) 841
5.7.20 MS in VBS call as originator, pre-emption on Um by higher prio data call (9.6
kbit/s, transparent) 843
5.7.21 MS in VGCS call on DCH, pre-emption on A IF by higher prio data call (9.6
5.7.22 MS in VGCS as listener, pre-emption on Um by data call (4.8 kbit/s,
transparent) 848
5.7.23 MS in VBS call as originator, pre-emption on A IF by higher prio data call (2.4
5.7.24 MS in VBS call as originator, pre-emption on A IF by lower prio PtP call does
not take place 852
5.7.25 MS in VBS call as listener, pre-emption on Um by lower prio PtP call does not
take place 854
5.7.26 MS in VGCS call as listener, pre-emption on Um by lower prio PtP call does not
take place 856
5.7.27 MS in data call, pre-emption on A IF by lower prio PtP call does not take place858
5.7.28 MS in VGCS call, pre-emption on Um by lower prio VBS call does not take
place 860
5.7.29 MS in VGCS call as listener, pre-emption on A IF by lower prio VBS call does
not take place 862
5.7.30 MS in VGCS call on DCH, pre-emption on A IF by lower prio VGCS call does
not take place 864
5.7.31 MS in VGCS call having the UL on the GCH, pre-emption on Um by lower prio
VGCS all does not take place 866
5.7.32 MS in PEC, pre-emption on Um by lower prio VGCS call does not take place868
5.7.33 MS in VBS call as originator, pre-emption on Um by lower prio data call does
not take place 870
5.7.34 MS in VBS call as listener, pre-emption on A IF by lower prio data call does not
take place 872
5.7.35 MS in VGCS call having the UL of the GCH, pre-emption on A IF by lower prio
data call does not take place 874
5.7.36 MS in data call, pre-emption on Um by lower prio data call does not take place876
5.7.37 MS in PEC, pre-emption on A IF by lower priority data call does not take place878
5.7.38 Pre-emption of VBS A IF resources on A and B BSS simultaneously 880


5.7.39 Pre-emption of VGCS A IF resources on A and B BSS simultaneously 882
5.7.40 Pre-emption of VBS Um resources on A and B BSS simultaneously 884
5.7.41 Pre-emption of VGCS Um resources on A and B BSS simultaneously 886
5.7.42 VGCS ongoing in GCA covering both BSS, pre-emption of the B VGCS
resources on Um, VGCS on A BSS is still up 888
5.7.43 VGCS ongoing in GCA covering both BSS, pre-emption of the A VGCS
resources on Um, VGCS on B BSS is still up 890
5.7.44 eMLPP priority is preserved during CFU (Call Forwarding Unconditionally) 892
5.7.45 eMLPP priority is preserved during CFB (Call Forwarding Busy) 894
5.7.46 Multi-Party: M6PORT: with different Prio 896
5.7.47 Pre-emption on A-IF when pre-empted party has no subscription to eMLPP
(assignment of default eMLPP priority) 898
5.7.48 Pre-emption on Um when pre-empted party has no subscription to eMLPP
(assignment of default eMLPP priority) 901
5.7.49 3 TS available on A IF, 1 TS in use by prio 3 GCH, 1 TS in use by prio 4 GCH.
Make prio 3 VBS and verify that the prio 4 GCH is pre-empted 904
5.7.50 Check of maximum authorized eMLPP level (non-roaming case) 906
5.7.51 Check of maximum authorized eMLPP level (roaming case) 908
5.8 VGCS 910
5.8.1 SS originates VGCS call 910
5.8.2 Service Subscriber originates a VGCS (priority 3) call 912
5.8.3 Controller originates a VGCS (priority 2) call 914
5.8.4 SS originates, leaves, rejoins and ends VGCS call 917
5.8.5 SS is notified when enters into VGCS broadcast area with ongoing VGCS call920
5.8.6 Controller joins ongoing VGCS call 922
5.8.7 Originator of VGCS call releases DCH 925
5.8.8 Originator of VGCS call takes uplink 928
5.8.9 Joiner of VGCS call takes Uplink 931
5.8.10 Un-mute and mute sequence for originating controller 934
5.8.11 Un-mute and mute sequence for joining controller 937
5.8.12 Parallel group calls are possible in the same cell 940
5.8.13 Parallel VBS/VGCS calls with same GID are possible (same BSS and different
BSS) 943
5.8.14 MSC receives VBS/VGCS Queuing Indication followed by Assignment Result
from non CoO 946
5.8.15 MSC receives VBS/VGCS Queuing Indication followed by Assignment Result from
CoO 949
5.8.16 MSC receives VBS/VGCS Queuing Indication followed by Assignment Failure
from non CoO 952
5.8.17 Origination of VGCS call from non subscribed MS fails 955
5.8.18 Origination by controller fails 957
5.8.19 Killing of VGCS call by controller fails 959
5.8.20 Uplink release when DCH is allocated in case of SS contact lost 962
5.8.21 Uplink release when DCH is allocated in case of Equipment failure (TRX) 965


5.8.22 Uplink Release when DCH is allocated in case of Equipment failure (PCM) 968
5.8.23 Uplink release when GCCH Uplink is allocated in case of SS contact lost 971
5.8.24 Uplink release when GCCH Uplink is allocated in case of Equipment failure
(TRX) 974
5.8.25 Uplink release when GCCH Uplink is allocated in case of Equipment failure
(PCM) 979
5.8.26 Uplink Request is rejected due to Uplink already allocated 984
5.8.27 Two controllers initiate VGCS with the same GID but different GCAs 986
5.8.28 VGCS call taken down during setup by SS 989
5.8.29 VGCS call taken down during setup by controller 991
5.8.30 More than one Uplink Request at the same time (same BSS and different BSS)993
5.8.31 Two SS originate VGCS call at same time (same BSS and different BSS) 996
5.8.32 Two controllers originate VGCS call at the same time 999
5.8.33 VGCS originator leaves GCA 1002
5.8.34 VGCS talker leaves GCA 1005
5.8.35 Service Subscriber initiated VGCS from Relay MSC in PLMN A, call to A-MSC
Controller 1008
5.8.36 Controller originates a VGCS call from Relay MSC- 1014
5.8.37 SS initiated VGCS call from Relay MSC. Controller in A-MSC area can re-
connect to on-going VGCS call 1021
5.8.38 VGCS first talker notification (MS dedicated mode, incoming PTP call, non
roaming case) 1027
5.8.39 VGCS first talker notification (MS dedicated mode, incoming VGCS call, non
roaming case) 1030
5.8.40 VGCS first talker notification (MS dedicated mode, incoming VBS call, non
roaming case) 1033
5.8.41 VGCS first talker notification (MS dedicated mode, incoming PTP call, roaming)1036
5.8.42 VGCS first talker notification (MS dedicated mode, incoming VGCS call,
roaming) 1050
5.8.43 VGCS first talker notification (MS dedicated mode, incoming VBS call, roaming)1090
5.8.44 VGCS first talker notification (MS dedicated mode, incoming REC, non roaming
case) 1126
5.8.45 VGCS first talker notification (MS dedicated mode, incoming REC, roaming
case) 1130
5.8.46 Multiple VGCS membership (non roaming case) 1150
5.8.47 Multiple VGCS membership (roaming case) 1153
5.8.48 VGCS call established in CoO when non CoO is locked 1178
5.9 VBS 1180
5.9.1 SS originates VBS call 1180
5.9.2 Modification of broadcast area 1182
5.9.3 SS originates a VBS (prio4) call 1185
5.9.4 Controller originates a VBS (prio3) call. 1187
5.9.5 Controller originates a VBS (prio4) call 1189
5.9.6 Controller joins ongoing VBS call 1191


5.9.7 SS enters into VBS broadcast area with ongoing VBS call and is notified of it,
SS joins the VBS call 1193
5.9.8 Parallel VBS (different GID) calls are possible in the same cell 1195
5.9.9 Parallel VBS calls with the same GID are possible (same BSS, different BSS)1197
5.9.10 Two controllers initiate VBS with the same GID but different GCAs 1201
from non COO during SS originated VBS call 1204
from COO during SS originated VBS call 1207
from non COO during SS originated VBS call 1210
from CoO during SS originated VBS call 1213
5.9.15 Contact loss for VBS originator 1216
5.9.16 Equipment failure (TRX) for VBS originator 1218
5.9.17 Equipment failure (PCM) for VBS originator 1220
5.9.18 VBS call established in CoO when non CoO is locked 1222
5.9.19 Origination of VBS call from non subscribed MS fails 1224
5.9.20 Origination by controller fails 1226
5.9.21 Killing of VBS call by controller fails 1228
5.9.22 VBS call taken down during setup by SS 1230
5.9.23 VBS call taken down during setup by Controller 1232
5.9.24 Two SS originate VBS call at same time (same BSS and different BSS) 1234
5.9.25 Two controllers originate VBS call at the same time 1237
5.9.26 Service Subscriber initiated VBS from Relay MSC. Call to A-MSC controller1239
5.9.27 Controller originates a VBS call from Relay MSC 1243
5.9.28 VBS originator notification (MS dedicated mode, incoming PTP call, non
roaming case) 1247
5.9.29 VBS originator notification (MS dedicated mode, incoming VGCS call, non
roaming case) 1249
5.9.30 VBS originator notification (MS dedicated mode, incoming VBS call, non
roaming case) 1252
5.9.31 VBS originator notification (MS dedicated mode, incoming PTP call, roaming)1255
5.9.32 VBS originator notification (MS dedicated mode, incoming VGCS call, roaming)1268
5.9.33 VBS originator notification (MS dedicated mode, incoming VBS call, roaming)1304
5.9.34 VBS originator notification (MS dedicated mode, incoming REC, non roaming
case) 1333
5.9.35 VBS originator notification (MS dedicated mode, incoming REC, roaming case)1336
5.9.36 Multiple VBS membership (non roaming case) 1353
5.9.37 Multiple VBS membership (roaming case) 1356
5.10 Cell Reselection and Handover 1369
5.10.1 Intra BTS cell reselection in idle mode 1369
5.10.2 Intra BTS cell reselection of a VBS listener 1371
5.10.3 Intra BTS cell reselection of a VGCS listener 1373


5.10.4 Intra BTS cell reselection of a REC listener 1375
5.10.5 Inter BTS cell reselection in idle mode 1377
5.10.6 Inter BTS cell reselection of a VBS listener 1379
5.10.7 Inter BTS cell reselection of a VGCS listener 1381
5.10.8 Inter BTS cell reselection of a REC listener 1383
5.10.9 Inter BSC cell reselection in idle mode 1385
5.10.10 Inter BSC cell reselection of a VBS listener 1387
5.10.11 Inter BSC cell reselection of a VGCS listener 1389
5.10.12 Inter BSC cell reselection of a REC listener 1391
5.10.13 Inter MSC reselection of a VBS listener 1393
5.10.14 Inter MSC reselection of a VGCS listener 1399
5.10.15 Intra BTS handover of a point to point voice call 1405
5.10.16 Intra BTS handover of a circuit switched data call 1407
5.10.17 Intra BTS handover of a railway emergency call originator 1410
5.10.18 Intra BTS handover of a VGCS call uplink 1413
5.10.19 Intra BTS handover of a VGCS dedicated channel 1415
5.10.20 Intra BTS handover of a VBS originator 1417
5.10.21 Inter BTS handover of a point to point voice call 1419
5.10.22 Inter BTS handover of a circuit switched data call 1421
5.10.23 Inter BTS handover of a railway emergency call originator 1424
5.10.24 Inter BTS handover of a VGCS call uplink 1427
5.10.25 Inter BTS handover of a VGCS dedicated channel 1429
5.10.26 Inter BTS handover of a VBS originator 1431
5.10.27 Inter BSC handover of a point to point voice call 1433
5.10.28 Inter BSC handover of a circuit switched data call 1435
5.10.29 Inter BSC handover of a railway emergency call originator 1438
5.10.30 Inter BSC handover of a VGCS call uplink 1441
5.10.31 Inter BSC handover of a VGCS dedicated channel 1444
5.10.32 Inter BSC handover of a VBS originator 1446
5.10.33 Inter MSC handover of a point to point voice call 1448
5.10.34 Inter MSC handover of a circuit switched data call 1450
5.10.35 Inter MSC handover of a railway emergency call originator 1454
5.10.36 Inter MSC handover of a VGCS call uplink. 1460
5.10.37 Inter MSC handover of a VGCS dedicated channel 1466
5.10.38 Inter MSC handover of a VBS originator 1471
5.10.39 Intra BTS handover failure of a point to point voice call (pre-emption Um-IF
not possible) 1476
5.10.40 Intra BTS handover failure of a circuit switched data call (pre-emption Um-IF
not possible) 1479
5.10.41 Intra BTS Handover failure of a railway emergency originator (DCH) (pre-
emption Um-IF not possible) 1483
5.10.42 Intra BTS Handover failure of a VGCS dedicated channel (pre-emption Um-
IF not possible) 1486


5.10.43 Intra BTS Handover failure of a VBS originator (pre-emption Um-IF not
possible) 1489
5.10.44 Inter BTS handover failure of a point to point voice call (pre-emption Um-IF
not possible) 1492
5.10.45 Inter BTS handover failure of a circuit switched data call (pre-emption Um-IF
not possible) 1495
5.10.46 Inter BTS Handover failure of a railway emergency originator (DCH) (pre-
5.10.47 Inter BTS Handover failure of a VGCS dedicated channel (pre-emption Um-
5.10.48 Inter BTS Handover failure of a VBS originator (pre-emption Um-IF not
possible) 1505
5.10.49 Inter BSC handover failure of a point to point voice call (pre-emption Um-IF
not possible) 1508
5.10.50 Inter BSC handover failure of a circuit switched data call (pre-emption Um-IF
not possible) 1511
5.10.51 Inter BSC Handover failure of a railway emergency originator (DCH) (pre-
5.10.52 Inter BSC Handover failure of a VGCS dedicated channel (pre-emption Um-
5.10.53 Inter BSC Handover failure of a VBS originator (pre-emption Um-IF not
possible) 1521
5.10.54 Inter MSC handover failure of a point to point voice call (pre-emption Um-IF
not possible) 1524
5.10.55 Inter MSC handover failure of a circuit switched data call (pre-emption Um-IF
not possible) 1529
5.10.56 Inter MSC Handover failure of a railway emergency originator (DCH) (pre-
emption Um-IF not possible 1537
5.10.57 Inter MSC Handover failure of a VGCS dedicated channel (pre-emption Um-
IF not possible 1550
5.10.58 Inter MSC Handover failure of a VBS originator (pre-emption Um-IF not
possible 1563
5.10.59 Point to Point voice call performing intra BTS handover followed by an Inter
BTS and a BSC handover 1576
5.10.60 Ongoing point to point voice call in the destination cell pre-empted (Um-IF)
by an intra BTS Handover of a point to point voice call 1578
by an intra BTS Handover of a circuit switched data call 1581
by an intra BTS Handover of a railway emergency call originator (DCH) 1585
by an intra BTS Handover of VGCS dedicated channel 1588
by an intra BTS Handover of VBS originator 1591
by an inter BTS Handover of a point to point voice call 1594


by an inter BTS Handover of a circuit switched data call 1597
by an inter BTS Handover of a railway emergency call originator (DCH) 1601
by an inter BTS Handover of VGCS dedicated channel 1604
by an inter BTS Handover of VBS originator 1607
by an inter BSC Handover of a point to point voice call 1610
by an inter BSC Handover of a circuit switched data call 1613
by an inter BSC Handover of a railway emergency call originator (DCH) 1617
by an inter BSC Handover of VGCS dedicated channel 1620
by an inter BSC handover of VBS originator 1623
by an inter MSC handover of VBS originator 1626
5.10.76 Inter BSC handover of a point to point voice call with eMLPP pre-emption at
A-IF 1637
5.10.77 Inter BSC handover of a circuit switched data call with pre-emption with
eMLPP pre-emption at A-IF 1639
5.10.78 Inter BSC handover of a railway emergency call originator with eMLPP pre-
emption at A-IF 1641
5.10.79 Inter BSC handover of a VGCS dedicated channel with eMLPP pre-emption
at A-IF 1643
5.10.80 Inter BSC handover of a VBS originator with eMLPP pre-emption at A-IF 1645
6 Annex 1647
6.1 Annex - IOT test case overview 1647
6.1.1 Overview of the IOT test cases 1648
6.1.2 Cross reference of EIRENE FRS V7 mandatory requirements to the IOT test
cases 1679
6.1.3 Cross reference of EIRENE SRS V15 mandatory requirements to the IOT test
cases 1751
6.2 Annex - Configuration of User Equipment for Data Calls 1827
6.3 Annex Example for documentation of test configuration 1830


1 General
1.1 Evolution Sheet

Version Date Author Modification
F016_110601 01.06.2011 DB Systel GmbH Final version, approved by Notified Bodies
(see chapter 1.2)
F017_111014 14.10.2011 DB Systel GmbH Amendmant of chapters 1, 2, 5.6.15 -
5.6.18, 5.10.13, 5.10.14, 5.10.39 5.10.48,
6.1


1.2 Involved Notified Bodies
The Companies listed below represent accredited Notified Bodies according to the European Di-
rectives 2008/57/EC.
The following Notified Bodies have been involved in the creation and the approval of this docu-
ment.
Notified Body Representatives Approval
(name / date)
Belgorail S.A.
Railway Certification Body
Notified Body 1615
Rue Ravensteinstraat, 60 B. 7
B-1000 Bruxelles-Brussel

Jean-Marc DUPAS,
Managing Director
Fanny LEFEBVRE,
Project Manager Signalling
System
Francis PARMENTIER,
Quality & Information Mana-
ger QMS Auditor
Vincent CAUDRON
GSM-R Expert
Jean-Marc DUPAS
22/06/2011
Railcert
Notified Body 0941
Leidseveer 10
NL-3511 SB Utrecht
P.O.Box 2027
NL-3500 GA Utrecht,
Nederland

P.H.J. (Paul) van de Ven,
MIRSE, Managing Director
Herman M. Meijsen,
Senior Assessor
P.H.J. (Paul) van de Ven
20/06/2011
RINA Services S.p.A.
Certification and Industrial
Services
Railway Department
Notified Body 0474
Via Corsica 12
I-16128 Genova, Italy

Berardino Vittorini,
Product Manager - Control-
command & Signalling
Federica Fornari,
Signalling Engineer
Luca Macchi,
Signalling Engineer
Francesco Manca
17/06/2011

TV InterTraffic, filial af
TV Rheinland Intertraffic
GmbH, Tyskland
Notified Body 1638
Larsbjrnsstraede 3
DK-1454 Kbenhavn,
Denmark

Jens Wolff, Dipl.-Ing.,
Principal Assessor
Richard Kubitza
Florian Steiner,
Richard Kubitza
26/07/2011


1.3 References

No. Document Title
1 2008/57/EC DIRECTIVE 2008/57/EC OF THE EUROPEAN PARLIAMENT
AND OF THE COUNCIL of 17 June 2008 on the interoperability
of the rail system within the Community
2 TSI
Technical Specification for Interoperability relating to the Con-
trol/Command & Signalling subsystem of the trans European
High Speed Rail (07.11.2006).
3 TSI Technical Specification for Interoperability relating to the Con-
trol/Command & Signalling subsystem of the trans European
Conventional Rail (28.03.2006)
4 EIRENE FRS v7 EIRENE Functional Requirement Specification, version 7
5 EIRENE SRS v15 EIRENE System Requirement Specification, version 15
6 ETSI EN 301515, v2.3.0 Requirements for GSM operation on railways
7 ETSI TR 102 281 Detailed requirements for GSM operation on Railways
8 CENELEC EN 50126 Railway applications - The specification and demonstration of
reliability, availability, maintainability and safety (RAMS)
9 MORANE A 01 T 0004 1 ASCI options for interoperability, version 1
10 MORANE P 38 T 9001 3 FFFIS for GSM-R SIM cards version 3
11 MORANE H 22 T 0001 2 Specification on usage of the UUIE in the GSM-R environment
version 2
12 MORANE E 10 T 6001 3
version 3
FFFS Functional addressing
13 MORANE E 12 T 6001 4
version 4
FIS Functional addressing
14 MORANE F 10 T 6001 3
version 3
FFFS Location dependent addressing
15 MORANE F 12 T 6001 2
version 2
FIS Location dependent addressing
16 MORANE F 10 T 6002 3
version 3
FFFS Confirmation of high priority calls
17 MORANE F 12 T 6002 3
version 3
FIS Confirmation of high priority calls
18 MORANE F 10 T 6003 3
version 3
FFFS Presentation of functional numbers
19 MORANE F 12 T 6003 3
version 3
FIS Presentation of functional numbers
20 GSMA IR.22
GSM Association, Permanent Reference Document IR.24
SCCP Signalling Aspects for Roaming
21 GSMA IR.23
GSM Association, Permanent Reference Document IR.24
Organisation of GSM International Roaming Tests


No. Document Title
22 GSMA IR.24 GSM Association, Permanent Reference Document IR.24
End-to-End Functional Capability, Specification for Inter-PLMN
Roaming (Stage 4 Testing).
End-to-End Functional Capability, Specification for Inter-PLMN
Roaming (Stage 4 Testing). Addendum for Phase 2, Supplemen-
tary Services and Operator Determined Barring
Functional Capability Test Specification for Inter-PLMN Roaming
(Stage 4 Testing). Phase 1 Data Services, Fax Services
25 GSMA: IR.50 2G/2.5G/3G Roaming
26 DB Systel, IOT test case overview, version 2011_10_13


1.4 Abbreviations

3GPP 3
rd
Generation Partnership Project
AAeM Automatic Answer for eMLPP Service
ACK Acknowledgment Center
AIS Air Interface Simulator
ASCI Advance Speech Call Items
BSC Base Station Controller
BSS Base Station Sub-system
BTS Base Transceiver Station
CHPC Confirmation of high priority calls
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CoO Cell of Origin
CT Call Type or Controller Terminal
DCE Data Circuit Terminating Equipment
DCH Dedicated Channel
Dest Destination Controller
eMLPP enhanced Multi-Level Precedence and Pre-emption
ERA European Railway Agency
ERTMS European Rail Traffic Management System
ETSI European Telecommunication Standardization Institute
FA Functional Addressing
FN Functional Number
GC Group Call
GCA Group Call Area
GCCH Group Call Cannel
GCR Group Call Register
GCRef Group Call Reference
GID Group Identity
GSM-R Global System for Mobile communication Railways
HLR Home Location Register
IF Interface
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity


IOT Interoperability Test
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LDA Location Dependent Addressing
LE Late Entry
MAP Mobile Application Part
MOC Mobile Originated Call (Call from Mobile to Fixed Network)
MS Mobile Station
MSC Mobile Switching Centre
MTC Mobile Terminated Call (Call from Fixed Network to Mobile)
MTM Mobile To Mobile Call (Call from Mobile to Mobile)
NSS Network Sub-system
Orig Originator
PCM Pulse Code Modulation (Link)
PLMN Public Land Mobile Network
PRI ISDN Primary Rate Interface
QoS Quality of Service
REC Railway Emergency Call
SCP Service Control Point
SS Service Subscriber
TCU Transcoding Unit
Term Terminator
TRX Transceiver (transmitter and receiver)
TSI Technical Specification for Interoperability
UE User Equipment
VLR Visitor Location Register
VBS Voice Broadcast Service
VGCS Voice Group Call Service


2 Introduction
Technical interoperability of EIRENE networks is necessary for the interoperability of rail systems,
especially in context of the track train communication in terms of the Technical Specification
for Interoperability (TSI).
Legal basis for interoperability of rail systems is represented by the DIRECTIVE 2008/57/EC OF
THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 June 2008 on the interoperability
of the rail system within the Community. Secondary the TSI specifies the requirements for inter-
operability to the subsystems. The EIRENE networks are covered by the Subsystem Control
Command and Signalling.
On the other hand, no interoperability test specification, which can be used by any railway or sys-
tem supplier to verify and to ensure the interoperability of EIRENE networks, is available today.
The European Railway Agency (ERA) has a great interest to provide an approved and generally
accepted reference for Interoperability Tests (IOT) to all railways and suppliers.
Therefore ERA supports the creation of this common interoperability test specification for EIRENE
networks by an independent test case creator. ERA informed the board of the Notified Bodies (NB
Rail) about the project and asked the Notified Bodies to support the document creators with the
completion of this IOT test specification.
Following the request of the ERA four interested Notified Bodies from different countries raised
their interest in contributing to this work and actively collaborated with the test case creator.

Belgium: Belgorail S.A.
Netherlands: Railcert,
Italy: RINA Services S.p.A.
Germany: TV Rheinland InterTraffic GmbH
To achieve an approved IOT test specification the following approach has been agreed between
ERA, the involved Notified Bodies and the test case creator:
- Scope of work is the creation of a specification for functional interoperability tests covering
the mandatory requirements of the EIRENE specifications
- Creation of IOT test cases subsequently in four parts based on an agreed list of test cases
and test scenarios
- Review of created test cases and approval of the finalized IOT test specification by the in-
volved Notified Bodies
- Issue of IOT test specification to UIC and GSM-R Industry Group for review
It is the common intention to provide an approved IOT test specification for EIRENE networks to
ERA. This document will for the first time in Europe allow ERA, Railways and Suppliers to perform
interoperability tests for EIRENE Networks.
Finally the IOT test specification could be used in the context of GSM-R network assessment.


3 Overview and basis
Scope of this document is to provide a catalogue of functional interoperability tests cases for EI-
RENE networks.
Other aspects like verification of radio coverage, Quality of Service and network performance
tests are out of scope of this test specification. Such tests scenarios depend on national imple-
mentation (i.e. of radio design) and may be covered by a separate test specification dedicated to
dynamic performance tests..
The references and legal basis are the EIRENE Functional Requirement Specification (E-FRS),
version 7 and the EIRENE System Requirement Specification (E-SRS), version 15. No back-
wards compatibility to other EIRENE specifications is required for the moment.
The objective is to test the mandatory EIRENE features from a functional aspect in respect of the
track train interface. This requires considering different operational scenarios and different ge-
neric network configurations like multivendor environments or interconnection and roaming cases.
Optional EIRENE features will not be considered in the IOT test specification.
Basis for this IOT test specification is the document IOT test case overview [26].
The IOT test case overview contains
- Test scenarios relevant for IOT of EIRENE networks
- List of IOT test cases (titles with references to E-FRS, E-SRS)
- Traceability matrix to E-FRS
- Traceability matrix to E-SRS
The detailed content of IOT test case overview is attached to Annex 6.1.
The following EIRENE main topics will be covered:
- Basic and Supplementary Services
- Functional Addressing, Access Matrix, Location Depending Addressing, Access to exter-
nal networks
- MLPP, eMLPP
- REC, Late Entry
- VGCS, VBS
- Mobility aspects: Cell reselection, Handover
Chapter 5 of this document IOT Tests Cases is structured according to these topics. Chapter 4
supports with prerequisites, aspects of test configuration and explains the nomenclature used in
the test cases. The annex chapter 6 contains also additional information about data tests and an
example form for documentation of the test configuration.
The IOT test cases have been created subsequently in four thematic parts.
IOT test case overview and the IOT test specification have been reviewed by the involved Notifies
Bodies.
The involved Notifies Bodies confirm completeness and consistency of this IOT test specification
with regard to the mandatory requirements of the:
- EIRENE specifications E-FRS V7 and
- E-SRS V15 as well as with respect to


- the TSI and the relevant ETSI specifications.

Clarification by ERA to relationship between E-FRS V7 / E-SRS V15 and E-SRS V15.1
To clarify the relationship between the current baseline E-FRS V7 / E-SRS V15 and the latest
sub-version E-SRS V15.1, the European Railway Agency represented by GSM-R Project Officer
of ERTMS Unit provides the following statement on 2
nd
March 2011:
The official GSM-R Requirements in the existing TSI are the EIRENE documents FRS 7 and
SRS 15.They will be replaced by the Interoperability Requirements of the Baseline 0 for the next
(new) TSI. The EIRENE Version 7.1/15.1 is on the WEB of UIC and describing the changes of
options, with one exception "Muting control". For this feature change it was agreed that there is no
influence in interoperability, only in quality. The version in 7/15 was never implemented, therefore
the status of the EIRENE version 7.1/15.1 is correct. With the new definition of the baseline 0 and
the follow up of baseline 1 the situation will be cleaned up and only the "Muting function" de-
scribed in 7.1/15.1 will be the valid one.

Decision of the Notifies Bodies regarding E-FRS V7 / E-SRS V15 vs. E-SRS V15.1
Based on the ERA statement the involved Notified Bodies decided to keep the IOT baseline E
FRS V7 / E-SRS V15 with the exception Muting Control (E-SRS V15.1).
The involved Notified Bodies agreed to finalize and to approve the IOT test catalogue based on
that decision. Later only the delta between E-SRS V15 and E-SRS V15.1 will be certified.

In consequence the EIRENE feature muting and unmuting for VGCS calls is considered in this
IOT test catalogue for the relevant test cases according to EIRENE specification SRS 15.1:
3.8 Muting and unmuting for VGCS calls
3.8.1 The muting and unmuting for VGCS shall be in line with [EN 301 515, Index [4]]. (M)
3.8.2 The network shall send the SET-PARAMETER message with the attribute D-ATT = T1
[EN 301 515, Index [6]] to the mobile station of the talking subscriber if it receives the 3-digit se-
quence ### transmitted via DTMF from a controller terminal. However, receiving the 3-digit se-
quence ###from any additional controller terminal while the controller mentioned above is still
talking shall not result in sending another SETPARAMETER message with the attribute D-ATT =
T. (M)
3.8.3 When the network has detected the 3-digit DTMF sequence ###from a controller terminal
and if the controller was not previously talking it should indicate its recognition by playing a single
DTMF grant tone # of duration of 100ms 5ms to be sent to that controller terminal only. (O)
3.8.4 The network shall send the SET-PARAMETER message with the attribute D-ATT = F2
[EN 301 515, Index [6]] to the mobile of the talking subscriber only if it has received the 3-digit
sequence #** transmitted via DTMF from all the talking controllers. (M)


4 Prerequisites and Test configuration
This chapter deals with the prerequisites for interoperability tests on EIRENE networks, aspects
of the network and test configuration as well as a description of test equipment based for the IOT
test cases.
4.1 Prerequisites for IOT testing on EIRENE networks
As general prerequisite for IOT is that the EIRENE network shall be
- designed,
- planned,
- built and
- configured
fully compliant to the current valid EIRENE specifications. This compliancy is not sufficient to en-
sure the EIRENE functionalities, but it is an absolute necessary precondition and must be verified
before testing interoperability.
In particular that means to verify:
- System architecture and conditions for system functionality meets the EIRENE functional
and system requirement specifications (E-FRS and E-SRS) in the current valid version.
- Traffic model of EIRENE network and configuration of network capacity according to the
traffic model, no resource limitations.
- Network configuration (e. g. NSS, BSS, subscribers) meets planning.
- Interface to other (EIRENE) networks for interconnections and roaming are configured
correctly and verified according to relevant specification e.g. IREG tests.
- Radio design meets the EIRENE specifications implicitly ETSI / 3GPP (see ETSI EN
301515).
The radio coverage meets the requirements of the EIRENE Specifications (E-SRS, chapter 3.2.2)
and has been verified. The air interface of EIRENE network should be optimized in terms of
speed, frequency and interferences generated by other mobile networks. Verification of radio co-
verage and network optimization is a precondition for IOT testing but not scope of this document.
Basic requirements regarding Quality of Service (QoS) (e.g. call setup time or handover success
rate) and network performances (e.g. handover duration), specified in the EIRENE functional and
system requirement specifications, have to be fulfilled. The verification is part of QoS and per-
formances testing and not covered by this document. For QoS testing can be used for example
UIC OG O-2575 (ERTMS/GSM-R Quality of Service, Test Specification (ETCS), version 3.0) and
UIC OG O-2875 (ERTMS/GSM-R Quality of Service, Test Specification, Voice and non-ETCS
data, version 0.21).
Furthermore the EIRENE network(s) have to fulfil the RAMS (reliability, availability, maintainability
and safety) requirements according to CENELEC EN 50126.
The EIRENE network(s) under test are in real operation and working trouble-free (no active
alarms, no defect components); all network resources are available and working correctly.
Access to the management systems of the EIRENE network will be needed to provide specific
network configurations defined in the IOT test cases.


Before start of IOT testing it shall be ensured and documented that the EIRENE network fulfils the
preconditions mentioned above.
Furthermore, environmental parameters such as temperature and humidity of the test environ-
ment should be recorded.
Hardware and software of the EIRENE network under test shall not be changed or modified dur-
ing IOT testing.

4.2 Reference configuration of EIRENE network
Based on GSM-R architecture, the following figure shows the reference configuration and the
interfaces of an EIRENE network and the terminals relevant for IOT testing.

Figure 4.1: Reference configuration and the interfaces of an EIRENE network

With respect of the track train relation the U
m
-interfaces are most relevant for functional end-to-
end IOT testing. The E-interface represents the connection to other networks in case of intercon-
nection and roaming. In a multivendor environment (BSS, NSS) the A-interface has to be consid-
ered. Communication equipment connected to GSM-R core network via T-interface and respec-
tively S-interface is to regard as part of the GSM-R network in respect of functional end-to-end
IOT testing.


Interoperability of EIRENE networks
The next figure gives an overview about typical interconnections of EIRENE and non EIRENE
networks.
Interoperability implies interconnection and roaming of two EIRENE networks to allow the safe
and uninterrupted movement of trains at the relevant lines of a rail system as the core require-
ment of interoperability.

Figure 4.2: Overview of possible interconnections of EIRENE and non EIRENE networks (source:
UIC, Draft GSM-R Procurement & Implementation Guide)

In generic cases of the interoperability tests one network is the EIRENE network under test and
the other shall be a certified EIRENE network.


4.3 IOT Test scenarios
To test the interoperability of one or, in case of roaming, of more than one EIRENE network, there
are three generic relevant test scenarios. These generic scenarios are applicable for single as
well as for multivendor network environments.
These test scenarios are applicable to different single test cases. The test case overview (Annex
6.1) shows the relationship between single test cases and test scenarios.

Test scenario I:
The first scenario represents the typical and generic situation: Two EIRENE networks (network A
and network B) are connected. This includes interconnection as well as roaming in national and
international cases.

Figure 4.3: Test scenario I Interconnection of two EIRENE networks

Focus of this scenario is to test features that are relevant when two networks are connected via E
interface and subscribers are roaming in both networks, as well as moving from one network to
the other.
The scope of the tests is to check the interfaces between EIRENE users and the EIRENE net-
work(s) as well as the correct interworking of both EIRENE networks.
Basically this generic scenario does not exclude network configurations described in test scenar-
ios II and III, but in terms of the test focus this is not considered in this test scenario.

Test scenario II:
This test scenario represents the generic configuration of a single EIRENE network.



Figure 4.4: Test scenario II configuration of a single EIRENE networks

Scope of this scenario is to test all EIRENE relevant functionalities without interconnection and
roaming aspects and with no respect to specific BSS configurations described in test scenario III.
Test scenario II covers also network configurations with more than one MSC, as well as multi
vendor NSS configurations.

Test Scenario III:
Test scenario III considers EIRENE network configurations with two or more different BSS.

Figure 4.5: Test scenario III focus to EIRENE networks with different BSS


Focus of scenario III is to test functionalities only relevant in case of more than one BSS, as well
as cases of multivendor BSS configurations.

4.4 Nomenclature
In this document a nomenclature is applied to describe the specific test configuration of the EI-
RENE networks and the role of the network elements including the terminals.
The following table gives an overview of the nomenclature used for the test cases. In addition the
abbreviations listed in section 1.4 have to be considered. These definitions are essential to read
the IOT test specification.

Object Nomenclature Example
Mobile Subscriber MS_(Network and running num-
ber)
MS_A1, MS_A2 (Mobile Sub-
scribers of network A).
MS_B1 (Mobile Subscriber of
network B).
Cells Cell_(Network and running num-
ber)
cell_A1, cell_A2 (cells of network
A).
cell_B1 (cell of network B).
BSC BSC_(Network and running num-
ber)
BSC_A1, BSC_A2 (BSCs of
network A).
BSC_B1 (BSC of network B).
MSC
A-MSC (Anchor MSC)
R-MSC (Relay MSC)
MSC_(Network and running num-
ber).
A-MSC (Network and running
number).
R-MSC (Network and running
number).
MSC_A1, MSC_A2 (MSCs of
network A).
MSC_B1 (MSC of network B).
A-MSC_A1 (MSC of network A,
configured as anchor).
R-MSC_A1 (MSC of network A,
configured as relay).
A-MSC_B1 (MSC of network B,
configured as anchor).

VLR VLR_(Network and running num-
ber)
VLR_A1, VLR_A2 (VLRs of
network A).
VLR_B1 (VLR of network B)
HLR HLR_(Network and running num-
ber)
HLR_A1, HLR_A2 (HLRs of
network A).
HLR_B1 (HLR of network B)
SIM card SIM
controller terminal (CT) CT_(Network and running number) CT_A1, CT_A2 (CT connected to


Object Nomenclature Example
network A).
CT_B1 (CT connected to net-
work B).
Group Call Area GCA _(Network and running num-
ber)
GCA_A1 (GCA including cells of
network A).
GCA_B1 (GCA including cells of
network B).
GCA_AB1 (GCA including cells
of network A and B).

Priority number Prio (number) Prio 1 (call priority 1).
Prio 2 (call priority 2).
point to point call PTP
mobile to mobile call MMC
mobile terminated call MTC
mobile originated call MOC
Cell of Origin CoO CoO=cell_A1 means REC,
VGCS or VBS calls can be es-
tablished in cell_A1.
International Code IC_(Network) IC_A, IC_B
Functional Number FN_(running number) FN_1, FN_2
FollowMe Functional
Node (e.g. IN / SCP)
FFN_(Network) FFN_A, FFN_B
Table 4.1: Overview of used nomenclature

Following description of network behaviours and configurations are also important to have a bet-
ter understanding of the test cases respectively test steps.

Uplink on the dedicated channel
When a REC or a VGCS call is originated, a dedicated channel (DCH) is allocated in the cell of
origin. The originator can take the uplink on the DCH only if he requests this during the first 5 sec-
onds after the connect message on DCH is sent. After these 5 seconds (timer implemented EI-
RENE in mobile station), the DCH will be released and it is only possible to take the uplink on the
group call channel (GCCH).
Note: The message flow for group calls and the interfaces, where the different messages (e.g.
Uplink Free) can be monitored are described in ETSI TS 100 933 (GSM 03.68, VGCS)
and ETSI TS 100 934 (GSM 03.69, VBS).

Uplink control


This IOT test specification considers the implememtation of uplink control for VGCS calls in the
EIRENE networks according to MORANE ASCI Options for Interoperability [9]:
Required for interoperability
NSS BSS MS
Uplink control (only VGCS):
originator channel release procedure - Yes Yes
Uplink on the common channel Yes Yes Yes
transition by handover procedure - No No
transition by assignment procedure - No No
transition by channel mode modify - No No
use of the UIC for RACH coding - No No
uplink reply procedure - No No

From point of view of interoperability there is no requirement for transition of the uplink of VGCS
calls, neither by a channel assignment procedure nor by a handover procedure nor by a channel
mode modify procedure. This means that during a handover procedure the uplink can be handed
over from DCH to DCH or from DCH to GCH in the case of a VGCS call originator as a first talker.
This document considers uplink handover procedures from DCH to DCH.
If the EIRENE network under test supports e. g. handover from DCH to GCH then the system
behaviour may different from the behaviour expected in some IOT test cases. In this case it is to
evaluate if the test case can be executed reasonable with regard to the test case purpose. Oth-
erwise the test case can not be executed. This refers mainly to test cases dealing with handover
or pre-emption scenarios for VGCS calls during the uplink on DCH. Examples for this are the test
cases 5.5.11 or 5.6.18.
See in addition the clarification for Uplink on the dedicated channel in the section above.

Muting and un-muting for VGCS calls
In the test cases dealing with muting control the expected behaviour is described in such a way:
The controller (CT) has voice path to all mobile subscribers. If one mobile subscriber takes the
uplink of the group call on GCCH, the downlink to the talking mobile subscriber will be muted. The
talking mobile subscriber is not able to listen to the announcement of CT. To un-mute the down-
link to the talking mobile subscriber the un-mute sequence (###) has to be dialled by CT. After
un-mute the DL, the talking SS will listen its own echo

TRX (Transmitter and receiver of a base station)
One TRX provides 8 time slots (TS) used for signalling and traffic. For configuration of the TRX
time slots see available channels below.

TRX Failure
To originate a TRX failure, the TRX is disconnected physically.



PCM Failure
To originate a PCM failure, the Abis PCM is disconnected physically.

Lock and unlock of resources
To lock the resources means to put resources out of service using the operation and maintenance
terminal.
To unlock the resources means to put resources into service using the operation and mainte-
nance terminal.

Available channels and time slots - resources limitation for pre-emption tests
Pre-emption tests Air interface (Um):
Only one TRX is available.
Following configuration is assumed:
TS0 Main BCCH,
TS1 SDCCH/8,
TS2 up to TS7 Traffic channel full rate.
Therefore, each cell has only 6 traffic channels available. For the pre-emption tests regarding the
air interface, the number of channels available was reduced either by performing several PTP
calls that use the resources or by putting them out of service using the operation and mainte-
nance terminal.

Pre-emption tests A and E interface:
For the pre-emption tests regarding the A and E interface, it was decided to reduce the number of
tine slots available by putting them out of service using the operation and maintenance terminal.

Note: A description of pre-emption can be found in ITU-T Q.735-3 (MLPP stage 3), ETSI EN 300
924 (GSM 02.67, eMLPP stage 1), ETSI TS 100 932 (3GPP TS 03.67, eMLPP stage 2)
and ETSI EN 300 947 (GSM 04.67, eMLPP stage 3)

Network attachment
If not described in another way in the test case, it is assumed that the mobiles are attached to the
network shown in the test configuration picture and therefore they have correct subscriber infor-
mation in VLR. The mobiles are in status idle updated.

Minimal configuration
All tests cases consider the minimal resources needed to be able to perform the test case. For
example, the test scenarios for cell reselection and handover always involve just two BCCH. The
group call areas include only one or two cells.

Subscription to VGCS/VBS calls
Type of mobile subscriber needed according to test description


It is specified in each test case the kind of mobiles needed to be able to perform the regarding
test.
For some cases it is absolutely necessary that the subscriber is able to perform VBS / VGCS calls
with a specific GID. For example:
MS_B2 (VBS GID: 202)

For some cases it is absolutely necessary that the subscriber is not able to perform VBS / VGCS
calls. For example:
MS_A3 (no VGCS / VBS subscriber)
For other cases it has no influence for the test case if the mobile is able to perform any VBS and
VGCS calls or not. For example:
MS_B2
When a test case needs subscriber with other specific configuration different from the default con-
figuration, then it is described in the test case.

Type of controller needed according to test description
It is specified in each test case the kind of controller needed to be able to perform the regarding
test.
For some cases it is absolutely necessary that the controller is able to originate, receive and kill
VBS / VGCS calls with a specific GID for the regarding GCA. For example:
CT_A1 (GCA_AB1, VGCS GID: 200)
CT_A2 (GCA_AB1, REC GID: 299)
For other cases the controller is not entitled to originate, receive and kill any VGCS / VBS calls.
For example:
CT_B1.
For specific test cases where it is needed that the controller receives VGCS / VBS calls but it is
not entitled to originate and kill them, this will be explicitly indicated in the test case.

Subscription for roaming
Subscribers have roaming per default. When a test case needs subscriber without roaming, then
it is described in the test case.
The roaming test cases check the correct interworking of both EIRENE networks and the inter-
faces between EIRENE users and both EIRENE networks. Especially in case of group calls it is
necessary to test the behaviour of the networks from both sites (MSC anchor relay relationship).
This is the reason for so many different test steps within a single group call roaming test case.
Nevertheless the scope of test is mainly the home network.



Example for the description of test configuration
The following example should explain the description of typical test configuration within this
document.

Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (VBS GID: 202) MS_B1 (VGCS GID: 200)
MS_B2 (VBS GID: 202) MS_A2 (VBS GID: 202)
MS_A3 (no VGCS / VBS subscriber) MS_B3 (no VGCS / VBS subscriber)
MS_A4
CT_A2

Figure 4.6: Example description of test configuration used in the IOT test specification

This figure means:

Section picture:
MSC_A1 belongs to network A and is configured as anchor MSC, MSC_B1 belongs to network B
and is configured as relay MSC.
BSC_A1 belongs to network A, BSC_B1, belongs to network B.
Cell_A1 belongs to network A, cell_B1, belongs to network B.
The group call area GCA_AB1 includes cells cell_A1 and cell_B1. Cell_A1 is cell of origin for this
group call area.
CoO=Cell_A1

GCA_AB1, VBS GID: 202 Prio 3

CoO=Cell_B1

GCA_B1, VGCS GID: 200 Prio 2


VBS calls can be established in GCA_AB1 using GID 202 with priority 3.
The group call area GCA_B1 includes only cell_B1. Cell_B1 is cell of origin for this group call
area.
VGCS calls can be established in GCA_B1 using GID 200 with priority 2.

Section table:
MS_A1, MS_A2, MS_A3 and MS_A4 are subscribers of network A.
MS_B1, MS_B2 and MS_B3 are subscribers of network B.
MS_A1, MS_B2, MS_A3 and MS_A4 are located in cell_A1, therefore they have correct sub-
scriber information in VLR_A1 and are attached to network A.
MS_A2, MS_B3 and MS_B1 are located in cell_B1, therefore they have correct subscriber infor-
mation in VLR_B1 and are attached to network B.
CT_A1 is connected to network A and can originate, receive and kill VGCS calls GID 200 with
priority 2 in GCA_AB1

HLR settings of MS_A1, MS_A2 and MS_A3 allow them to perform roaming in network B.
HLR settings of MS_B1, MS_B2 and MS_B3 allow them to perform roaming in network A.
MS_A1, MS_A2 and MS_B2 have subscription to VBS GID 202. VBS GID 202 is available and
activated on the SIM cards.
MS_B1 has subscription to VGCS GID 200. VGCS GID 200 is available and activated on the SIM
card.
For MS_A3 and MS_B3 it is absolutely necessary that the mobiles are not able to perform VBS
and VGCS calls.
For MS_A4 it has no influence for the test case if the mobile is able to perform any VBS and
VGCS calls or not.
Controller terminal CT_A1 can originate, receive and kill VGCS calls with GID 200 on the regard-
ing GCA_AB1.
CT_A2 is not entitled to originate, receive and kill any VGCS / VBS call.


4.5 Test environment and test conditions
The IOT test specifications can be applied to all EIRENE compliant GSM-R networks. The GSM-
R network can be either a test lab environment or a live GSM-R network.
Nevertheless the execution of the full set of the IOT test specifications is recommended to be
done in a test lab environment.
The IOT tests should be done under normal conditions.
Furthermore the IOT tests should be performed with speed profiles described in EIRENE SRS,
chapter 3.2. In addition speed and area profiles for radio propagation specified in the ETSI speci-
fication TS 100 911 (3GPP TS 05.05 annex C) should be considered.
In case of test lab environment an Air Interface Simulator (realtime RF switching matrix) is rec-
ommended to simulate radio propagation and to force handover and cell resection.

4.6 Test configuration
In general not less than the following network elements are needed to ensure a GSM-R test net-
work that is able to realize the IOT test specification.

Network elements per network (Network A and Network B)
- NSS ( MSC, VLR, HLR, AUC, GCR, SMSC, OMC)
- BSS ( BSC, TCU, 3 BTS, OMC)
- IN (Intelligent Network)
- ACK Center (Acknowledgment Center with CHPC recorder)

In practical each live GSM-R network has an individual configuration. Hence it would be absurd to
define or to force a specific IOT test configuration or specific GSM-R network parameters. In fact
the purpose of IOT is to test the GSM-R networks as they are.
Therefore only the minimum test configuration is described that is needed to perform the IOT test
cases. In any case the EIRENE networks shall be configured according to requirements de-
scribed in chapter 2 and 3 of the EIRENE FRS and SRS.

4.6.1 Test configuration GSMR Network

The generic test configuration is simplified shown in the figure below.



Figure 4.7: Generic IOT test configuration for GSM-R networks

The figure shows also the measurement points for protocols on the different interfaces, drawn by
a circle and numbers.
During IOT testing the protocols listed below should be monitored and analyzed at the relevant
interfaces.



Interface Um (1): Abis (2): A (3): E (4): S
RR CM MAP ISUP DSS1 Layer 3
(by trace
mobile only)
BTSM MM TCAP SCCP
Lapd BSSMAP SCCP MTP
Layer 1 SCCP MTP
Protocol
MTP

Table 4.2: Relevant interfaces of GSM-R network and protocols

The message flow between the different interfaces is described in the relevant ETSI specifica-
tions and will not be described in this document.

The configuration of BTS for IOT testing is assumed with
Only one TRX is available.
TS0 Main BCCH,
TS1 SDCCH/8,
TS2 up to TS7 Traffic channel full rate.

The mapping of MLPP and eMLPP priorities is configured in a one-to-one relation. This means for
example MLPP priority 1 is matched to eMLPP priority 1 and vice versa. EMLPP priorities A and
B are not used. Default priority is 4 within the GSM-R network.

Priority
MLPP --- --- 0 1 2 3 4
eMLPP A B 0 1 2 3 4

Table 4.3: Mapping of MLPP and eMLPP priorities

Additional information about data test configuration and an example form for documentation of the
test configuration is described in annex 6.2.


4.6.2 Test configuration for Functional Addressing
Configuration of FN database
There are two possible options of configuration of FN database.
Pre-provisioning of FN
Prior to the registration of a FN, the FFN database should include all FN to register by a
MS. In this case the FFN is checking if the FN has been data filled in the functional num-
ber table before allowing the registration attempt to proceed. Only if the FN is data filled
(preconfigured) the FFN accepts the registration attempt.
Dynamic FN Creation
FFN does not reject the registration if no FN is found. Instead it will check the FN for con-
sistency by applying certain criteria like the length of Train Number, number format etc.
If all conditions are met the FFN will create a record for the requested FN and inform the
user via USSD response about the successful registration. This is known as dynamic FN
creation.
Optionally FN record is deleted when deregistered.

Configuration of International Codes, Functional Numbers and Controller Functional Numbers
The following tables represent an example configuration may use for test cases. The values have
to be changes according the specific configuration of the EIRENE networks under test.

International Codes (IC):
IC_A e.g. 049
IC_B e.g. 043

Functional Numbers (FN: CT2, 3, 4, 6):
FN_1 CT2, 5digits UIN, FC01 (e.g. 2 12345 01)
FN_2 CT3, FC01 (e.g. 3 80123456 01)
FN_3 CT4, FC01 (e.g. 801234567 01)
FN_4 CT6, FC5yxx (e.g. 6 12345 5101)
FN_5 CT2, 5 digits UIN, FC02 (e.g. 2 12345 02)
FN_8 CT2, 6 digits UIN FC01 (e.g. 2 123456 01)


Controller Function Numbers (FN: CT7):
FN_11 CT7, FC01 (e.g. 7 85001 01)
FN_12 CT7, FC01 (e.g. 7 85002 01)
FN_13 CT7, FC02 (e.g. 7 85005 02)
FN_14 CT7, FC02 (e.g. 7 85008 02)
FN_15 CT7, FC01 (e.g. 7 86001 01)
FN_16 CT7, FC02 (e.g. 7 86001 02)
FN_17 CT7, FC01 (e.g. 7 86003 01)
FN_18 CT7, FC02 (e.g. 7 86003 02)

Configuation of EIRENE Subcribers:
The test cases for Functional Addressing are based on the following subscriber configuration.

MS Follow Me Subscription on HLR_A
(Class Of Registration)
Supervisor Subscription on HLR_A
MS_A1 ABCD ABCD
MS_A2 ABCD Not given
MS_A3 Not given Not given

MS Follow Me Subscription on HLR_B
Supervisor Subscription on HLR_B
MS_B1 ABCD ABCD
MS_B2 ABCD Not given
MS_B3 Not given Not given


4.6.3 Test configuration of Location Depending Addressing (LDA)
The table below shows the test configuration of LDA.

Network A
Cell Of Origin Short Code Destination
1200 FN_11 Cell_A1
1300 FN_13
1200 FN_12 Cell_A2
1300 FN_14

Network B
Cell Of Origin Short Code Destination
1200 FN_15 Cell_B1
1300 FN_16
1200 FN_17 Cell_B2
1300 FN_18

4.6.4 Check of GSM-R network parameters
In preparation of IOT testing the following configurations of parameters and data of the GSM-R
network should be checked regarding the general requirements for EIRENE networks according
to EIRENE FRS and SRS as well as the national railway specific configuration aspects.

BSS:
- Logical Chanel Configuration on the air interface, e.g.
- Not combined
- TS0 (BCCH, RACH, PCH AGCH)
- TS1 (SDCCH/8 (07))
- TS2 TS7 (TCH)
- Handover and Cell Selection / Reselection
o Handover Types (Intra cell, Inter cell, Intra BSS, Inter BSS, Intra MSC, Inter MSC)
o Handover Parameters: (Margin, Quality, Level, Distance, Better cell, Power
Budget, also considering high speed)
- Power Control
- Transfer Mode: Discontinuous Transmission (DTX)


MSC:
- Parameter to Control of the registry query ( Registration, Authentification, Encryption )
- Parameter to Control the Handover
- Parameters for call control (VGCS, VBS, PTP)
- Mapping of MLPP and eMLPP levels, default priority
- Parameters for interconnection of networks (routing)
- Parameter for Roaming (national, international)

AuC / HLR:
- Subscribers activation
- Subscribed services

GCR:
The group call register contains attributes of voice group and broadcast call configuration.
- Group ID
- Group area ID
- Croup call reference ( Group ID + Group area ID)
- Priority levels
- Controllers configuration for group calls

EIRENE data:
- Group call service areas
- UIC group addresses
- Access matrix ( Call type, Function code combination / IN)
- EIRENE numbering plan (Functional Addressing / IN), see chapter 4.6.2
- Location dependent addressing-/ routing schema (IN)
- Private numbering plan

Note: If no Network Destination Code (NDC) is available the EIRENE numbering format should be
used.

4.7 Test equipment
The test equipment listed below represents a minimum set that is needed for two networks (A and
B) in order to be able to execute the complete IOT test specification. The test equipment shall be
to be compliant to ETSI GSM-R phase 2+ (release 1999).


- 10 EIRENE mobile stations, at least two different manufactures, with EIRENE SIM
- 4 EIRENE Controller Terminals
- 2 ISDN terminals with application for data tests (user equipment for data tests, see annex
6.2)
- Protocol analyzer for tracing the full set of messages of A, A-bis, E and S interfaces
- Air interface simulator (AIS) for test in lab environment (see chapter 4.7.3 AIS)

4.7.1 EIRENE Mobile Stations, EIRENE Controller Terminals
The mobile stations and controller terminals used for IOT testing shall be fully compliant to the
EIRENE specifications (EIRENE FRS V7 and SRS V15, see references). For controller terminals
there is an exception regarding the implementation of the EIRENE feature muting and unmuting
according to E-SRS V15.1, as explained in chapter 3.
These EIRENE Mobile Stations and EIRENE Controller Terminals have to be certified by a Noti-
fied Body accredited according to the European Directive 2008/57/EC.
Not every EIRENE Mobile Station supports all EIRENE features. EIRENE FRS chapter 4.2 speci-
fies which type of EIRENE mobile station has to support what EIRENE features.
The cab radio supports all EIRENE mandatory features except ETCS train control application. Is it
recommended to use cab radios for IOT testing.
Nevertheless other types of EIRENE mobiles can be used for IOT testing if the mobile supports
the EIRENE features needed in the single IOT test cases.
EIRENE mobile station shall be configured with EIRENE SIM according to one of the subscriber
profiles described in chapter 4.7.2.
For IOT test cases these require mobile stations without VGCS / VBS or REC subscription (see
chapter 4.4) it is not recommended to use a cab radio, but other types of mobiles stations. EI-
RENE cab radio has to support these features as mandatory. Hence some implementations of
cab radios will not start up when the GID 299 for REC is not activated on SIM because of safety.
Mobile stations and ISDN data terminal used for data tests should be subscribers that are not
able to perform VBS / VGCS calls. This avoids interferences of data transmission during test
caused by in-band notification.
Controller terminals and the supported features are specified in EIRENE FRS chapter 8 and SRS
chapter 8.3.
The mobile stations and controller terminals used for IOT testing shall be documented with type,
IMEI or serial number as well as hardware and software version, see chapter 6.3 Annex Exam-
ple for documentation of test configuration.

4.7.2 EIRENE SIM, Subscriber profiles
As explained in chapter 4.4 the IOT test cases requires different subscriber configurations for
mobiles station and controller terminals. For the subscriber configuration is only the minimal con-
figuration considered that is needed to be able to perform the test case.
Subscriber profiles listed below shall be configured in the HLR of the GSM-R network and on the
SIM, in case of controller also in the GCR.


For EIRENE SIM technical basis profile for GSM-R applications is described in the UIC specifica-
tion FFFIS for the GSM-R SIM Cards, Reference P38 T 9001 4.

Mobile subscriber profile 1 (full EIRENE profile, equivalent with train radio)
This profile supports all mandatory EIRENE features according to E-FRS V7 and E-SRS V15.

Teleservices:
11 Telephony
12 Emergency calls
21 Short message MT/PP
22 Short message MO/PP
23 Short message cell broadcast
91 Voice Group Call Service (VGCS)
92 Voice Broadcast Service (VBS)

Bearer services:
24 Asynchronous 2.4 kbps T
(T - Transparent; NT - Non-transparent)


Supplementary service:
Calling Line Identification Presentation (CLIP)
Connected Line Identification Presentation (CoLP)
Call Forwarding Unconditional (CFU)
Call waiting (CW)
Call hold (HOLD)
Multi Party Service (MPTY)
Closed User Group (CUG)
BOIC except those to Home PLMN Country (BOIC-exHC)
Barring of Incoming Calls when Roaming Outside the Home PLMN Country (BIC-Roam)
Unstructured Supplementary Service Data (USSD)
Sub-addressing*
Enhanced Multi-Level Precedence and Pre-emption (eMLPP)
User-to-User Signalling 1 (UUS1)

EIRENE specific features:
Functional addressing (based on USSD, COR, Supervisor COR), see chapter 4.6.2
Multiple driver communications (based on VGCS GID 200)
Railway Emergency Calls
EIRENE Train Emergency call (based on VGCS GID 299)
EIRENE Shunting Emergency call (based on VGCS GID 599)

For IOT test the subscriber with this profile is able to perform VBS and VGCS calls with the fol-
lowing specific GID used in the IOT test cases.
VGCS:
- GID: 299, Priority 0 (REC train)
- GID: 599, Priority 0 (REC shunting)
- GID: 200, Priority 2
VBS:

Fast Call Setup is configured for high priority calls (priority 0) on SIM.
This profile is used as default for IOT testing.


Mobile subscriber profile 2 (no VGCS / VBS subscription)
The subscriber supports all services and features of profile 1, but the subscriber is not able to
setup or receive VBS / VGCS calls, however it supports eMLPP and AAeM.
Therefore is no subscription for VGCS and VBS on SIM (SIM Service Table) and in HLR and no
GID is subscribed.
This profile should be used for subscribers performing data test.

Mobile subscriber profile 3 (no ASCI)
The subscriber supports the GSM standard services.
ASCI features (VGCS, VBS, eMLPP, AAeM) are not supported and not subscribed on SIM and in
HLR. This subscriber has no maximum eMLPP priority level 0 and no default eMLPP priority level
assigned.
This profile is required in some MLPP / eMLPP test cases.

As described above the mobile subscriber profile 1 is used for IOT testing as default. If a test
case requires a different configuration then it the mobile subscriber profile 2 or 3 have to use ac-
cording to the features required.
All Subscribers (except mobile subscriber profile 3) are configured in HLR and on SIM with maxi-
mum eMLPP priority level 0 and default eMLPP priority level 4. This means the priority levels 0, 1,
2, 3 and 4 are allowed.
Subscribers have roaming per default. When a test case needs subscriber without roaming or
with other specific configuration different from the default configuration, then it is described in the
test case.

Subscriber profile for controller
The EIRENE features that have to be configured for controller are described in general in E-FRS
chapter 8 and E-SRS chapter 8.2.
In the GCR it is to configure that the controller is able to originate, receive and kill VBS / VGCS
calls with a specific GID for the regarding GCA as specified in each test case.
For specific test cases where a different configuration for the controller is needed, this will be ex-
plicitly indicated in the test case.

Before the start of IOT tests, the SIM and controller configuration have to be verified and docu-
mented.

4.7.3 Air Interface Simulator
An Air Interface Simulator (AIS) is used in lab environment to simulate drive tests and radio
propagation. Without AIS the IOT testing in lab can only be performed under static conditions.
IOT test cases covering handover and cell reselection can not be performed reliably without AIS.
The following simulation characteristics should be possible:
- Simulation of topographic areas / events ( urban, rural, tunnels, bridges )


- Simulation of different speeds (low speed, high speed)
- Optional: simulation of radio propagation with different fading models (Rician Fading,
Rayleigh Fading)

Speed and area profiles applicable for GSM-R are described in the ETSI specification TS 100 911
(3GPP TS 05.05 annex C). In addition the speed profiles described in EIRENE SRS, chapter
3.2 have to be considered.

The AIS should support simulations at least with four cells (BTS) and at least with four independ-
ent radio paths for mobile stations. At all the AIS should provide the capacity to connect the mini-
mum number of Mobile Stations used for IOT testing.

4.7.4 Optional test equipment
Additional measurement equipment is helpful to support the IOT tests.

- Spectrum Analyzer
- Network Analyzer
- RF Power Meter
- Temperature / Humidity Log Tool

This equipment is recommended to measure insertion loss (Air Interface Simulator), output power
(Base Stations) and measurement of environmental interference.
The measurement equipment that is used for IOT testing shall be calibrated and should be docu-
mented with the test configuration (see chapter 6.3 Annex Example for documentation of test
configuration).


5 IOT Tests Cases
This section contains the IOT test cases covering the following EIRENE features.

Chapter EIRENE Feature
5.1 Basic and Supplementary Services
5.2 Functional Addressing
5.3 Access Matrix and Access to external networks
5.4 Location Depending Addressing
5.5 MLPP
5.6 REC, Late Entry
5.7 eMLPP
5.8 VGCS
5.9 VBS
5.10 Cell reselection, Handover


5.1 Basic and Supplementary Services
5.1.1 Successful Location Update after MS Power On (non-roaming case)

EIRENE FRS V7 EIRENE SRS V15 other Reference to

EN 301515

a) Purpose
Verify correct location update after MS is switched on.

b) Test configuration / initial conditions
MS_A1 is switched off.

Network A

MS_A1

c) Test procedure



Step Action Expected result(s)
1) Switch on MS_A1 in cell_A1. A normal location update is performed.
Messages seen: Location Updating Request
and Location Updating Accept.
Authentication Request is transmitted from
the MSC to the BSC and from the BSC to the
base station.
Authentication Response is transmitted from
the base station to the BSC and from the BSC
to the MSC.
Cipher Mode Command is transmitted from
base station.
Cipher Mode Complete is transmitted from the
base station to the BSC and from the BSC to
the MSC.
In Cipher Mode Command message you can
find the encryption algorithm supported by the
network. In Cipher Mode Complete message
you can find the chosen encryption algorithm.
MS_A1 has correct subscriber data in the
VLR_A and is attached to the network.

d) Success criteria
Location update after MS is switched on is successful.

e) Test result

Specific test configuration
Specific test conditions
Remarks
Attachments
(log / trace file)

Test result Passed / failed / test not performed
Signatures


5.1.2 Successful Location Update after change of Location Area (non-roaming case)


EN 301515

a) Purpose
Verify correct location update after moving to a cell with different location area.

Cell_A1 and cell_A2 have different location areas.

Network A

Cell_A1 Cell_A2
MS_A1

c) Test procedure

1) MS_A1 moves from cell_A1 to cell_A2. A normal location update is performed.
2) MS_A1 moves back to cell_A1. A normal location update is performed again.



d) Success criteria
Successful location update after moving to a cell with different location areas.

e) Test result

Remarks
Attachments
(log / trace file)

Signatures


5.1.3 Unsuccessful Location Update (subscription in HLR is unknown) (non-roaming
case)

EIRENE FRS V7 EIRENE SRS V15 Other Reference to

EN 301515

a) Purpose
Verify that location update cannot be performed if the SIM is not known in the HLR.


Network A

MS_A1

c) Test procedure

1) MS_A1 has a SIM that is not known in
HLR_A1.
Switch on MS_A1 in cell_A1.

Location update is not performed (initiated but
fails).
and Location Updating Reject with reject
cause IMSI unknown in HLR.



d) Success criteria
Location update cannot be performed if the SIM is not known in HLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signatures


5.1.4 Unsuccessful Location Update ( due to PLMN not allowed) (non-roaming case)


EN 301515

a) Purpose
Verify that location update cannot be performed if the PLMN is not allowed.

HLR settings of MS_A1 do not allow it to perform roaming in network A.

Network A

MS_A1

c) Test procedure

1) Switch on MS_A1 in cell_A1. Location update is not performed.
cause PLMN not allowed.
2) Check the subscriber information in the
VLR_A1.
There is no subscriber information available in
the VLR_A1.



d) Success criteria
Location update failed with cause PLMN not allowed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.5 Successful Location Cancellation (non-roaming case)


EN 301515

a) Purpose
Verify location update cancellation when moving from one cell to another (from one VLR to an-
other).


Network A

MSC_A1 MSC_A2
MS_A1

c) Test procedure

1) MS_A1 moves to cell_A2. MS_A1 performs a location update in cell_A2.
Location cancellation is performed. No
VLR_A1 information for MS_A1 is available
anymore.
MS_A1 has correct subscriber information in
VLR_A2.


2) MS_A1 moves back to cell_A1. MS_A1 performs a location update in cell_A1.
anymore.
VLR_A1.

d) Success criteria
Location cancellation is performed successfully when moving from one cell to another (from one
VLR to another).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.6 IMSI Detach by MS Power Off (non-roaming case)

EN 301515

a) Purpose
Verify that the IMSI is detached when switching off the MS.

IMSI attached/detached must be enabled in the network.

Network A

MS_A1

c) Test procedure

1) Switch on MS_A1 in cell_A1. A normal location update is performed.
and Location Updating Accept
2) Switch off MS_A1. IMSI is detached. Detachment message is sent
from the BTS to the BSC and from the BSC to
the MSC.



d) Success criteria
IMSI is detached when switching off the MS.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.7 MTM to detached mobile subscriber (non-roaming case)


2.2.1
2.2.3
2.2.4
2.2.1

a) Purpose
Verify that no call can be established to a mobile which IMSI has been detached.

IMSI attached/detached must be enabled in the network.

Network A

MS_A1
MS_A2

c) Test procedure

1) Switch off MS_A2. IMSI is detached. The detachment message is
sent from the BTS to the BSC and from the
BSC to the MSC.
2) MS_A1 calls MS_A2. A release tone is sent to MS_A1. The MSC
does not send the paging message to the
BSC. No call can be established.



d) Success criteria
No call can be established to a mobile which IMSI has been detached.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.8 MTM, mobile subscribers are in different location areas (non-roaming case)


2.2.1
2.2.2
2.2.3
2.2.4
3.2.3
2.2.1
9.7.1
9.7.2
9.7.3
10.7.1i
10.7.3

a) Purpose
Check that a mobile to mobile call can be established even if the mobile subscribers are in differ-
ent location areas.

Cell_A1 and cell_A2 belong to different location areas.

Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure



1) MS_A1 establishes a PTP call to MS_A2. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
The call is established successfully. The sub-
scribers can talk to each other.
2) MS_A1 releases the call. Call is correctly released. All related resources
are de-allocated.

d) Success criteria
A PTP call could be established between two mobile subscribers located in different location ar-
eas.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.9 MTM, radio link failure on A-side, A and B subscriber are in different cell (non-
roaming case)


2.2.1
2.2.3
2.2.4
2.2.1

a) Purpose
Verify that a PTP call is correctly released when the mobile subscriber looses contact with the
network.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. The call is established successfully. The sub-
2) Remove the battery of MS_A1 in order to
originate a radio link failure.
The call is correctly released. All related re-
sources are de-allocated.



d) Success criteria
The PTP call is correctly released when the mobile subscriber looses contact with the network
due to a radio link failure.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.10 Supplementary Service Call Hold (non-roaming case)


2.4.1
2.4.13
2.4.14
2.4.1

a) Purpose
Verify the Supplementary Service Call Hold.

MS_A1 have Supplementary Service Call Hold.

Network A

MS_A1
MS_A2
MS_A3

c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. MS_A2 is notified of the incoming call from
MS_A1.
2) MS_A2 takes the call. PTP call between MS_A1 and MS_A2 is suc-
cessfully established. MS_A1 has speech path
to MS_A2.
3) MS_A1 puts subscriber MS_A2 on hold. MS_A2 is on hold, no speech path between
MS_A1 and MS_A2 available.


4) MS_A1 establishes a second PTP call to
MS_A3.
MS_A3 is notified of the incoming call from
MS_A1.
to MS_A3.
6) MS_A1 toggles (rejoin) between sub-
scriber MS_A2 and MS_A3 by putting
one on hold and retrieving the other one.
After that puts MS_A2 on hold.
The subscriber that is on hold has no speech
path to MS_A1. The subscriber that is not on
hold is able to communicate with MS_A1.

7) MS_A1 closes the call to MS_A3 Call to MS_A3 is released. All related re-
MS_A1 has again speech path to MS_A2.
8) MS_A1 closes the call. Call to MS_A2 is released. All related re-

d) Success criteria
MS_A1 was able to put subscribers on hold.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.11 Supplementary Service Call Waiting (non-roaming case)


2.4.1
2.4.15
2.4.1

a) Purpose
Verify the Supplementary Service Call Waiting.

MS_A1 has Supplementary Service Call Waiting.

Network A

MS_A1
MS_A2
MS_A3

c) Test procedure

MS_A1.
to MS_A2.
MS_A3. MS_A3 gets ringing tone.


4) MS_A1 accepts the call from MS_A3. MS_A1 puts the call to MS_A2 automatically
on hold.
PTP call between MS_A1 and MS_A3 is suc-
to MS_A3.
5) MS_A1 closes the call to MS_A3. Call to MS_A3 is released. All related re-

d) Success criteria
MS_A1 was successfully notified about the PTP call from MS_A3 during the ongoing PTP call to
MS_A2.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.12 Supplementary Service CLIP MMC with Call Forwarding Unconditional (non-
roaming case)


2.4.1
2.4.2
2.4.12
2.4.1

a) Purpose
Verify the Supplementary Service Calling Line Identification Presentation (CLIP) with activated
Call Forwarding Unconditional (CFU).

MS_A1 has Supplementary Service Calling Line Identification Restriction (CLIR) set to off.
MS_A2 and MS_A3 have Supplementary Service Calling Line Identification Presentation (CLIP).
MS_A2 has activated Call Forwarding Unconditional (CFU) to MS_A3.

Network A

MS_A1
MS_A2
MS_A3


c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. MS-A2 is forwarded to MS_A3. MS_A3 is noti-
fied of the incoming call from MS_A1. The
MSISDN of MS_A1 is displayed on MS_A3.
MS_A1 is notified of the call forwarding to
MS_A3.
2) MS_A3 takes the call. The PTP call between MS_A1 and MS_A3 is
successfully established. MS_A1 has speech
path to MS_A3.
3) MS_A1 closes the call. Call is released. All related resources are de-
allocated.
4) MS_A2 deactivates the call forwarding to
MS_A3.
Call forwarding to MS_A3 is deactivated.
MS_A1. The MSISDN of MS_A1 is displayed
on MS_A2.
path to MS_A2.
allocated.

d) Success criteria
MS_A3 was successfully notified about the PTP call from MS_A1. The MSISDN of MS_A1 is dis-
played on MS_A3.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.13 Supplementary Service CoLP (non-roaming case)


2.4.1

a) Purpose
Verify the Supplementary Service Connected Line Identification Presentation (CoLP).

MS_A1 have Supplementary Service Connected Line Identification Presentation (CoLP) and
Supplementary Service Calling Line Identification Presentation (CLIP) activated.
MS_A2 have Supplementary Service Connected Line Identification Restriction (CoLR) deacti-
vated.

Network A

MS_A1
MS_A2


c) Test procedure

on MS_A2.
successfully established. The MSISDN of
MS_A2 is displayed on MS_A1. MS_A1 has
speech path to MS_A2.
allocated.

d) Success criteria
MS_A2 was successfully notified about the PTP call from MS_A1. The MSISDN from MS_A2 was
displayed on MS_A1.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.14 Supplementary Service MPTY (incl. Multivendor MPTY) (non-roaming case)


2.2.1
2.2.17
2.2.18
2.4.1
2.5.1

a) Purpose
Verify the Supplementary Service Multiparty (MPTY).

MS_A1 have Supplementary Service Verify Multiparty (MPTY) and Call Hold (HOLD)..
CT_A1 and CT_A2 are connected to Network A.
MSC_A2 and BSC_A2 can be from another vendor as MSC_A1 and BSC_A1.
The 2 cells have different location areas.

Network A

MSC_A1 MSC_A2
MS_A1 MS_A3
MS_A2 MS_A4
CT_A1 CT_A2


c) Test procedure

MS_A1.
path to MS_A2.
3) MS_A1 puts MS_A2 on hold.
MS_A1 establishes a PTP call to CT_A1.
MS_A2 is put on hold. CT_A1 is notified of the
incoming call from MS_A1.
4) CT_A1 takes the call. The PTP call between MS_A1 and CT_A1 is
path to CT_A1.
5) MS_A1 puts both subscribers together to
a multiparty call.
The multiparty call between MS_A1, MS_A2
and CT_A1 is successfully established. All
subscribers have speech path and can talk to
each other.
6) MS_A1 puts MS_A2 and CT_A1 on hold.
MS_A1 establishes a PTP call to MS_A3.
MS_A2 and CT_A1 are put on hold. MS_A3 is
notified of the incoming call from MS_A1.
path to MS_A3.
8) MS_A1 puts the three subscribers to-
gether to a multiparty call.
The multiparty call between MS_A1, MS_A2,
MS_A3 and CT_A1 is successfully established.
All subscribers have speech path and can talk
to each other.
9) MS_A1 puts MS_A2, CT_A1 and MS_A3
on hold.
MS_A1 establishes a PTP call to MS_A4.
MS_A2, MS_A3 and CT_A1 are put on hold.
MS_A1.
path to MS_A4.
11) MS_A1 puts the four subscribers to-
MS_A3, MS_A4 and CT_A1 is successfully
established. All subscribers have speech path
and can talk to each other.
12) MS_A1 puts MS_A2, CT_A1, MS_A3
and MS_A4 on hold
MS_A1 establishes a PTP call to CT_A2.
MS_A2, MS_A3, MS_A4 and CT_A1 are put
on hold. CT_A2 is notified of the incoming call
from MS_A1.
path to CT_A2.


14) MS_A1 puts the five subscribers together
to a multiparty call.
MS_A3, MS_A4, CT_A1 and CT_A2 is suc-
cessfully established. All subscribers have
speech path and can talk to each other.
15) MS_A1 closes the multiparty call. Multiparty call is released. All related resources
are de-allocated.

d) Success criteria
MS_A1 was able to initialize a multiparty call with mobile subscribers and fixed line subscribers.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.15 Notification of Call Forwarding (non-roaming case)


2.4.1
2.4.12
2.4.1

a) Purpose
Verify notification of a forwarded call.

MS_A2 have Supplementary Service Call Forwarding Unconditional (CFU) and has forwarded his
calls to MS_A3.

Network A

MS_A1
MS_A2
MS_A3


c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. MS_A2 has forwarded his calls to MS_A3.
on MS_A3.
path to MS_A3.
allocated.

d) Success criteria
MS_A3 was successfully notified about the forwarded PTP call. The MSISDN from MS_A1 was
displayed on MS_A3.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.16 Establishment of several MTM Data calls (Bearer Services) with different eMLPP
priorities (non-roaming case)


2.3.1
2.3.6
2.3.8
2.3.13
2.4.1
2.4.5
9.2.1.2
10.2.1
10.2.2
2.3.1
10.2.1
3GPP TS27.007
3GPP TS22.002
3GPP TS22.003

a) Purpose
Verify the different bearer services.

DCE_A1 is connected to network A (Data Circuit Terminating Equipment).
MS_A1 and MS_A2 are terminals with subscriptions to the following bearer services:

Service EIRENE SRS v15
BS 24 Asynchronous 2,4 Kbit/s T for full-rate channel M

Terminal application needed to send and receive test data.
To configure the bearer services and to set up a call with the terminal refer to chapter 6.2Annex -
Configuration of User Equipment for Data Calls.
This test case has been divided into the following steps:
Step 1: Mobile to mobile data call
Step 2: Data call between mobile network and fixed network.


Test configuration for step 1 and 2

Network A

DCE_A1

c) Test procedure

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1 X X 3
2 X (V.22bis) X 1
3 X X 4
4
BS 24
2400 bps
X (V.22bis) X 2
5 X X 1
6 X (V.32) X 3
7 X X 2
8
BS 25
4800 bps
X (V.32) X 4
9 X X 1
10 X (V.32) X 2
11 X X 3
12
BS 26
9600 bps
X (V.32) X 4


Step 1: Mobile to mobile data call
1) Configure MS_A1 and MS_A2 to perform
a data call with the settings indicated in
table above case 1. To configure the
bearer services see chapter 6.2 Annex -
Configuration of User Equipment for Data
Calls
MS_A1 and MS_A2 are configured with the
correct bearer service.
2) MS_A1 establishes a data call to MS_A2
by dialling:
ATD *75<Priority>#<MSISDN>
(Reference 3GPP TS27.007)
MS_A2 is notified of the incoming data call
from MS_A1. The MSISDN of MS_A1 is dis-
played on MS_A2.
3) MS_A2 takes the data call. The data call between MS_A1 and MS_A2 is
successfully established with the correct bear-
er service and line speed. Therefore check the
channel assignment messages.
4) MS_A1 sends test data to MS_A2. The test data is successfully transmitted and
received.
5) MS_A2 sends test data to MS_A1. The test data is successfully transmitted re-
ceived.
allocated.
7) Repeat the test using case 2 and 12 from
table above.

Step 2: Data call between mobile network and fixed network
1) Configure MS_A1 and DCE_A1 to per-
form a data call with the settings indi-
cated in table above case 1. To configure
the bearer services see chapter 6.2
Annex - Configuration of User Equip-
ment for Data Calls
MS_A1 and DCE_A1 are configured with the
2) MS_A1 establishes a data call to
DCE_A1 by dialling:
DCE_A1 is notified of the incoming data call
from MS_A1.
3) DCE_A1 takes the data call. The data call between MS_A1 and DCE_A1 is
4) MS_A1 sends test data to DCE_A1. The test data is successfully transmitted and
received.


5) DCE_A1 sends test data to MS_A1. The test data is successfully transmitted and
received.
allocated.
7) DCE_A1 establishes a data call to
MS_A1.
from DCE_A1.
8) MS_A1 takes the data call. DCE_A1 and MS_A1 are successfully estab-
lished with the correct bearer service and line
speed. Therefore check the channel assign-
ment messages.
received.
received.
11) DCE_A1 closes the call. Call is released. All related resources are de-
allocated.
table above.

d) Success criteria
MS_A1, MS_A2 and the Data Circuit Terminating Equipment DCE_A1 are able to setup and re-
ceive data calls with different bearer services and line speeds.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.17 Establishment of several PTP calls with different priorities (non-roaming case)


2.4.1
2.4.5
10.2.1
10.2.2
10.2.1

a) Purpose
Verify that a PTP call is established successfully with the correct priority.


Network A

MS_A1
MS_A2

c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2
with priority 0 by dialling
*75<Priority>#<MSISDN>.
The call is established correctly, there is a
speech path between MS_A1 and MS_A2.
The priority is transmitted correctly through the
network.
The priority is seen on messages: CM Service
request, Call Proceeding and Setup sent to
MS_A2.
2) MS_A1 releases the call. The call is correctly released. All related re-


3) Repeat step 1 and 2 using priorities 1, 2,
3 and 4.

d) Success criteria
The PTP call is established successfully with the correct priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.18 Call to busy Mobile CFBusy to other mobile subscriber (non-roaming case)


2.4.1
2.4.12
2.4.1

a) Purpose
Verify that a PTP call to a busy mobile subscriber is forwarded when this subscriber has activated
Call Forwarding Busy (CFB).

MS_A1 has Supplementary Service Call Forwarding Busy (CFB).

Network A

MS_A1
MS_A2
MS_A3
MS_A4

c) Test procedure

1) MS_A1 activates CFB to MS_A3. If MS_A1 is busy, incoming calls will be for-
warded to MS_A3.
2) MS_A1 calls MS_A2. Call is correctly established. There is speech
path between MS_A1 and MS_A2.


3) MS_A4 calls MS_A1. The call is forwarded to MS_A3. The MSISDN
number from MS_A4 is displayed on MS_A3.
There is speech path between MS_A4 and
MS_A3.
6) MS_A1 deactivates CFB to MS_A3. CFB is deactivated.
7) MS_A1 calls MS_A2. Call is correctly established. There is speech
8) MS_A4 calls MS_A1. The call is not forwarded. MS_A4 gets the
busy ring tone and the call is released. All re-
lated resources are de-allocated.

d) Success criteria
The PTP call to a busy mobile subscriber was correctly forwarded.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.19 MOC call when terminator rejects call (non-roaming case)


EN 301515

a) Purpose
Verify that a MOC is released when the terminator rejects it.

CT_A1 is connected to network A.

Network A

MS_A1
CT_A1

c) Test procedure

1) MS_A1 calls CT_A1. CT_A1 is notified of the incoming call.
2) CT_A1 rejects the call. The call is correctly released. All related re-



d) Success criteria
The mobile originating call is released when terminating subscriber rejects the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.20 Unsuccessful MOC call due to unallocated number (non-roaming case)


EN 301515

a) Purpose
Verify that no mobile originating call can be established when calling a number that is not as-
signed.


Network A

MS_A1
CT_A1

c) Test procedure

1) MS_A1 calls CT_A1 by dialling a number
that is not assigned.
MS_A1 receives an audible indicator (e.g. an-
nouncement or a tree-tone). Depending on the
network configuration.
2) MS_A1 closes the call or awaits the net-
work terminates the call.
Call is released. All related resources are de-
allocated.



d) Success criteria
No mobile originating call can be established when calling a number that is not assigned.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.21 MTC call Paging Time Out (non-roaming case)


9.7.4

a) Purpose
Verify that a mobile terminated call is released after paging time out when the terminating sub-
scriber does not answer the call.


Network A

MS_A1
CT_A1

c) Test procedure

1) MS_A1 leaves the coverage area. VLR_A1 data still available for MS_A1. It is still
attached to network A.
2) CT_A1 calls MS_A1. The call is correctly released after paging time
out. All related resources are de-allocated.



d) Success criteria
The mobile terminated call is released after paging time out when the terminating subscriber does
not answer the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.22 Unsuccessful MTC, subscriber not in VLR (non-roaming case)


EN 301515

a) Purpose
Verify that a mobile terminating call is released when there is no VLR subscriber information for
the terminating subscriber.


Network A

MS_A1
CT_A1

c) Test procedure

1) Delete the subscriber information for
MS_A1 in VLR_A1.
Subscriber information is not available any-
more for MS_A1 in VLR_A1.
2) CT_A1 calls MS_A1. The call is correctly released. All related re-



d) Success criteria
The MTC is released because there is no VLR subscriber information for the terminating sub-
scriber.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.23 Successful Location update after MS Power On (roaming case)


EN 301515

a) Purpose
Verify correct location update after MS is switched on.

MS_A1 and MS_B1 are switched off.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

1) Switch on MS_B1 in cell_A1. A normal location update is performed.
base station.
to the MSC.
base station.
the MSC.
MS_B1 has correct subscriber data in the
VLR_A1 and is attached to network A.


2) Switch on MS_A1 in cell_B1. A normal location update is performed.
base station.
to the MSC.
base station.
the MSC.
VLR_B1 and is attached to network B.

d) Success criteria
Location update after MS is switched on is successful.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.24 Successful Location Update after change of Location Area (roaming case)


EN 301515

a) Purpose
Verify that location update is correctly performed after moving to a cell with different LAC.


Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1

c) Test procedure

1) MS_B1 moves from cell_B1 to cell_A1. A normal location update is performed.
2) MS_B1 moves back to cell_A1. A normal location update is performed again.
3) MS_A1 moves from cell_A1 to cell_B1. A normal location update is performed.


4) MS_A1 moves back to cell_A1. A normal location update is performed again.

d) Success criteria
Successful location update after moving to a cell with different location area.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.25 Unsuccessful Location Update (subscription in HLR is unknown) (roaming case)


EN 301515

a) Purpose
Verify that location update cannot be performed if the SIM is not known in the HLR.

MS_B1 has a SIM that is not known in HLR_B1.
MS_A1 has a SIM that is not known in HLR_A1.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

1) Switch on MS_B1 in cell_A1.

fails).
2) Switch on MS_A1 in cell_B1.

fails).

d) Success criteria
Location update cannot be performed if the SIM is not known in HLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.26 Unsuccessful Location Update (due to PLMN not allowed) (roaming case)


EN 301515

a) Purpose
Verify that location update cannot be performed if the PLMN is not allowed.

HLR settings of MS_A1 and MS_B1 do not allow them to perform roaming in network B and A
respectively.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

1) Switch on MS_B1 in cell_A1. Location update is not performed.
VLR_A1.
the VLR_A1.
3) Switch on MS_A1 in cell_B1. Location update is not performed.
VLR_B1.
the VLR_B1.

d) Success criteria
Location update failed with cause PLMN not allowed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.27 Successful Location Cancellation (roaming case)


EN 301515

a) Purpose
Verify location update cancellation when moving from one cell to another (from one VLR to an-
other).


Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1

c) Test procedure

1) MS_B1 moves to cell_A1. MS_B1 performs a location update in cell_A1.
VLR_B1 information for MS_B1 available.


2) MS_B1 moves back to cell_B1. MS_B1 performs a location update in cell_B1.
VLR_A1 information for MS_B1 is available
anymore.
3) MS_A1 moves to cell_B1. MS_A1 performs a location update in cell_B1.
anymore.
4) MS_A1 moves back to cell_A1. MS_A1 performs a location update in cell_A1.
VLR_B1 information for MS_A1 is available
anymore.

d) Success criteria
Location cancellation is performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.28 Successful IMSI Detach by MS Power Off (roaming case)

EN 301515

a) Purpose
Verify the procedure IMSI detach when switching off the MS.

IMSI attached / detached must be enabled in the network.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1

c) Test procedure

1) Switch on MS_B1 in cell_A1. MS_B1 has correct subscriber data in the
VLR_A1 and is attached to the network.
2) Switch off MS_B1. IMSI is detached. Detachment message is sent
the MSC.


3) Switch on MS_A1 in cell_B1. MS_A1 has correct subscriber data in the
VLR_B1 and is attached to the network.
4) Switch off MS_A1. IMSI is detached. Detachment message is sent
the MSC.

d) Success criteria
IMSI is detached when switching off the MS.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.29 MTM to detached mobile subscriber (roaming case)


2.2.1
2.2.3
2.2.4
2.2.1

a) Purpose
Verify that no call can be established to a mobile which IMSI has been detached.

IMSI attached / detached must be enabled in the network.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
MS_B2 MS_A2

c) Test procedure

1) Switch off MS_B2. IMSI is detached. The detachment message is
BSC to the MSC.
2) MS_B1 calls MS_B2. A release tone is sent to MS_B1. The MSC


3) Switch off MS_A2. IMSI is detached. The detachment message is
BSC to the MSC.
4) MS_A1 calls MS_A2. A release tone is sent to MS_A1. The MSC

d) Success criteria
No call can be established to a mobile which IMSI has been detached.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.30 MTM, mobile subscribers are in different Location areas (roaming case)


2.2.1
2.2.3
2.2.4
2.2.1
10.7.1i
10.7.3

a) Purpose
Check that a mobile to mobile call can be established even if the mobile subscribers are in differ-
ent location areas.


Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2


c) Test procedure

1) MS_A1 establishes a PTP call to MS_B1. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
are de-allocated.
3) MS_B2 establishes a PTP call to MS_A2. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
4) MS_B2 releases the call. Call is correctly released. All related resources
are de-allocated.


5) MS_A2 establishes a PTP call to MS_B2. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
are de-allocated.
7) MS_B1 establishes a PTP call to MS_A1. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
are de-allocated.


base station.
to the MSC.
base station.
the MSC.
are de-allocated.
base station.
to the MSC.
base station.
the MSC.
are de-allocated.


13) MS_B2 establishes a PTP call to MS_B1. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
are de-allocated.
15) MS_B1 establishes a PTP call to MS_B2. Authentication Request is transmitted from
base station.
to the MSC.
base station.
the MSC.
are de-allocated.



d) Success criteria
A PTP call could be established between two mobile subscribers located in different location ar-
eas.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.31 MTM, radio link failure on A-side, A and B subscriber are in different cell (roaming
case)


2.2.1
2.2.3
2.2.4
2.2.1

a) Purpose
Verify that a PTP call is correctly released when the mobile subscriber looses contact with the
network.

Step 1: Remove the battery of MS_A1 in network A.
Step 2: Remove the battery of MS_B1 in network B.
Step 3: Remove the battery of MS_B2 in network A.
Step 4: Remove the battery of MS_A2 in network B.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2

c) Test procedure


Step 1: Remove the battery of MS_A1 in network A.
1) MS_A1 establishes a PTP call to MS_B1. The call is established successfully. The sub-
3) Put back the battery and switch on
MS_A1.
MS_A1 is attached to network A again.
MS_A1.
MS_A1 is attached to network A again.

Step 2: Remove the battery of MS_B1 in network B.
1) MS_B1 establishes a PTP call to MS_A1. The call is established successfully. The sub-
2) Remove the battery of MS_B1 in order to
MS_B1.
MS_B1 is attached to network B again.
4) MS_B1 establishes a PTP call to MS_B2. The call is established successfully. The sub-
MS_B1.
MS_B1 is attached to network B again.

Step 3: Remove the battery of MS_B2 in network A.
1) MS_B2 establishes a PTP call to MS_A2. The call is established successfully. The sub-
MS_B2.
MS_B2 is attached to network A again.
4) MS_B2 establishes a PTP call to MS_B1. The call is established successfully. The sub-


MS_B2.
MS_B2 is attached to network A again.

Step 4: Remove the battery of MS_A2 in network B.
1) MS_A2 establishes a PTP call to MS_B2. The call is established successfully. The sub-
MS_A2.
MS_A2 is attached to network B again.
MS_A2.
MS_A2 is attached to network B again.

d) Success criteria
The PTP call is correctly released when the mobile subscriber looses contact with the network
due to a radio link failure.

e) Test result

Remarks
Attachments
(log / trace file)



5.1.32 Supplementary Service Call Hold (roaming case)


2.4.1
2.4.13
2.4.14
2.4.1

a) Purpose
Verify the Supplementary Service Call Hold.

MS_A1, MS_A2, MS_B1 and MS_B2 have Supplementary Service Call Hold.

Step 1: MS_A1 in network A calls MS_A2 in network B.
Step 2: MS_B1 in network A calls MS_B2 in network B.
Step 3: MS_B2 in network A calls MS_A1 in network A.
Step 4: MS_A2 in network B calls MS_B1 in network B.

Test configuration for step 1 to 4

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2


c) Test procedure

Step 1: MS_A1 in network A calls MS_A2 in network B.
MS_A1.
to MS_A2.
3) MS_A1 puts subscriber MS_A2 on hold. MS_A2 is on hold, no speech path between
MS_A1 and MS_A2 available.
MS_B1.
MS_B1 is notified of the incoming call from
MS_A1.
5) MS_B1 takes the call. PTP call between MS_A1 and MS_B1 is suc-
to MS_B1.
scriber MS_A2 and MS_B1 by putting
7) MS_A1 closes the call to MS_B1 Call to MS_B1 is released. All related re-

Step 2: MS_B1 in network A calls MS_B2 in network B.
1) MS_B1 establishes a PTP call to MS_B2. MS_B2 is notified of the incoming call from
MS_B1.
2) MS_B2 takes the call. PTP call between MS_B1 and MS_B2 is suc-
cessfully established. MS_B1 has speech path
to MS_B2.
3) MS_B1 puts subscriber MS_B2 on hold. MS_B2 is on hold, no speech path between
MS_B1 and MS_B2 available.
4) MS_B1 establishes a second PTP call to
MS_A1.
MS_B1.
5) MS_A1 takes the call. PTP call between MS_B1 and MS_A1 is suc-
to MS_A1.


6) MS_B1 toggles (rejoin) between sub-
scriber MS_B2 and MS_A1 by putting
After that puts MS_B2 on hold.
path to MS_B1. The subscriber that is not on
hold is able to communicate with MS_B1.
7) MS_B1 closes the call to MS_A1. Call to MS_A1 is released. All related re-
MS_B1 has again speech path to MS_B2.
8) MS_B1 closes the call. Call to MS_B2 is released. All related re-

Step 3: MS_B2 in network A calls MS_A1 in network A.
1) MS_B2 establishes a PTP call to MS_A1. MS_A1 is notified of the incoming call from
MS_B2.
to MS_A1.
3) MS_B2 puts subscriber MS_A1 on hold. MS_A1 is on hold, no speech path between
MS_B2 and MS_A1 available.
4) MS_B2 establishes a second PTP call to
MS_A2.
MS_B2.
to MS_A2.
6) MS_B2 toggles (rejoin) between sub-
scriber MS_A1 and MS_A2 by putting
path to MS_B2. The subscriber that is not on
hold is able to communicate with MS_B2.
7) MS_B2 closes the call to MS_A2 Call to MS_A2 is released. All related re-
8) MS_B2 closes the call. Call to MS_A1 is released. All related re-

Step 4: MS_A2 in network B calls MS_B1 in network B.
1) MS_A2 establishes a PTP call to MS_B1. MS_B1 is notified of the incoming call from
MS_A2.
to MS_B1.


3) MS_A2 puts subscriber MS_B1 on hold. MS_B1 is on hold, no speech path between
MS_A2 and MS_B1 available.
MS_B2.
MS_A2.
to MS_B2.
scriber MS_B1 and MS_B2 by putting
After that puts MS_B1 on hold.
7) MS_A2 closes the call to MS_B2. Call to MS_B2 is released. All related re-
8) MS_A2 closes the call. Call to MS_B1 is released. All related re-

d) Success criteria
MS_A1, MS_A2, MS_B1 and MS_B2 are able to put subscribers on hold.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.33 Supplementary Service Call Waiting (roaming case)


2.4.1
2.4.15
2.4.1

a) Purpose
Verify the Supplementary Service Call Waiting.

MS_A1 and MS_B1 have Supplementary Service Call Waiting.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
MS_B2 MS_A2
MS_B3 MS_A3


c) Test procedure

MS_B1.
2) MS_B2 takes the call. PTP call between MS_B1 and MS_B2 is suc-
to MS_B2.
MS_B3. MS_B3 gets ringing tone.
4) MS_B1 close the call to MS_B2. Call is released. All related resources are de-
allocated.
5) MS_B1 takes the call from MS_B3. PTP call between MS_B1 and MS_B3 is suc-
to MS_B3.
6) MS_B1 closes the call. Call is released. All related resources are de-
allocated.
MS_A1.
to MS_A2.
MS_A3. MS_A3 gets ringing tone.
10) MS_A1 closes the call to MS_A2. Call is released. All related resources are de-
allocated.
11) MS_A1 takes the call from MS_A3. PTP call between MS_A1 and MS_A3 is suc-
to MS_A3.
allocated.

d) Success criteria
MS_B1 was successfully notified about the PTP call from MS_B3 during the ongoing PTP call to
MS_B2.
MS_A1 was successfully notified about the PTP call from MS_A3 during the ongoing PTP call to
MS_A2.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.34 Supplementary Service CLIP MTM with Call Forwarding Unconditional (roaming
case)


2.4.1
2.4.2
2.4.12
2.4.1

a) Purpose
Verify the Supplementary Service Calling Line Identification Presentation (CLIP) with activated
Call Forwarding Unconditional (CFU).

MS_A1 and MS_B1 have Supplementary Service Calling Line Identification Restriction (CLIR) set
to off.
MS_A2, MS_A3, MS_B2 and MS_B3 have Supplementary Service Calling Line Identification
Presentation (CLIP).
MS_A2 have activated Call Forwarding Unconditional (CFU) to MS_A3 and MS_B2 have acti-
vated Call Forwarding Unconditional (CFU) to MS_B3.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
MS_B2 MS_A2
MS_B3 MS_A3


c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. MS-A2 is forwarded to MS_A3. MS_A3 is noti-
fied of the incoming call from MS_A1. The
MSISDN of MS_A1 is displayed on MS_A3.
MS_A1 is notified of the call forwarding to
MS_A3.
path to MS_A3.
allocated.
4) MS_B1 establishes a PTP call to MS_B2. MS-B2 is forwarded to MS_B3. MS_B3 is noti-
fied of the incoming call from MS_B1. The
MSISDN of MS_B1 is displayed on MS_B3.
MS_B1 is notified of the call forwarding to
MS_B3.
5) MS_B3 takes the call. The PTP call between MS_B1 and MS_B3 is
successfully established. MS_B1 has speech
path to MS_B3.
allocated.

d) Success criteria
MS_A3 was successfully notified about the PTP call from MS_A1. The MSISDN of MS_A1 is dis-
played on MS_A3.
MS_B3 was successfully notified about the PTP call from MS_B1. The MSISDN of MS_B1 is dis-
played on MS_B3.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.35 Supplementary Service CoLP (roaming case)


2.4.1

a) Purpose
Verify the Supplementary Service Connected Line Identification Presentation (CoLP).

All MS have Supplementary Service Calling Line Identification Presentation (CLIP) activated.
All MS have Supplementary Service Connected Line Identification Presentation (CoLP) activated.
All MS have Supplementary Service Connected Line Identification Restriction (CoLR) deacti-
vated.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
MS_B2 MS_A2


c) Test procedure

on MS_A2.
MS_A2 is displayed on MS_A1. MS_A1 has
allocated.
on MS_B1.
5) MS_B1 takes the call. The PTP call between MS_A1 and MS_B1 is
MS_B1 is displayed on MS_A1. MS_A1 has
speech path to MS_B1.
allocated.
MS_B1. The MSISDN of MS_B1 is displayed
on MS_B2.
MS_B2 is displayed on MS_B1. MS_B1 has
speech path to MS_B2.
allocated.
on MS_A1.
11) MS_A1 takes the call. The PTP call between MS_B1 and MS_A1 is
MS_A1 is displayed on MS_B1. MS_B1 has
allocated.



d) Success criteria
MS_A2 and MS_B1 are successfully notified about the PTP call from MS_A1. The MSISDN from
MS_A2 and MS_B1 are displayed on MS_A1.
MS_A1 and MS_B2 are successfully notified about the PTP call from MS_B1. The MSISDN from
MS_A1 and MS_B2 are displayed on MS_B1.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.36 Supplementary Service MPTY (incl. Multivendor MPTY) (roaming case)


2.2.1
2.2.17
2.2.18
2.4.1
2.5.1

a) Purpose
Verify the Supplementary Service Multiparty (MPTY).

MS_A1 and MS_A2 have Supplementary Service Multiparty (MPTY) and Call Hold (HOLD) acti-
vated.
MS_B1 and MS_B3 have Supplementary Service Multiparty (MPTY) and Call Hold (HOLD) acti-
vated.
CT_A1 is connected to Network A.
CT_B1 is connected to Network B.

Step 1: MS_A1 starts the MPTY call in network A.
Step 2: MS_B1 starts the MPTY call in network B.
Step 3: MS_B2 starts the MPTY call in network A.
Step 4: MS_A2 starts the MPTY call in network B.



Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2
CT_A1 CT_B1

c) Test procedure

Step 1: MS_A1 starts the MPTY call in network A.
MS_A1.
successfully established. MS_A1 have speech
path to MS_A2.
3) MS_A1 establishes a PTP call to CT_A1. MS_A2 is put on hold. CT_A1 is notified of the
path to CT_A1.
a multiparty call.
The multiparty call between MS_A1, MS_A2
each other.
6) MS_A1 establishes a PTP call to MS_B1. MS_A2 and CT_A1 are put on hold. MS_B1 is
path to MS_B1.


CT_A1 and MS_B1 is successfully established.
to each other.
9) MS_A1 establishes a PTP call to MS_B2. MS_A2, CT_A1 and MS_B1 are put on hold.
MS_A1.
path to MS_B2.
CT_A1, MS_B1 and MS_B2 is successfully
12) MS_A1 establishes a PTP call to CT_B1. MS_A2, CT_A1, MS_B1 and MS_B2 are put
on hold. CT_B1 is notified of the incoming call
from MS_A1.
13) CT_B1 takes the call. The PTP call between MS_A1 and CT_B1 is
path to CT_B1.
CT_A1, MS_B1, MS_B2 and CT_B1 is suc-
are de-allocated.

Step 2: MS_B1 starts the MPTY call in network B.
MS_B1.
successfully established. MS_B1 have speech
path to MS_B2.
3) MS_B1 establishes a PTP call to CT_B1. MS_B2 is put on hold. CT_B1 is notified of the
incoming call from MS_B1.
4) CT_B1 takes the call. The PTP call between MS_B1 and CT_B1 is
path to CT_B1.
5) MS_B1 puts both subscribers together to
a multiparty call.
The multiparty call between MS_B1, MS_B2
and CT_B1 is successfully established. All
each other.


6) MS_B1 establishes a PTP call to MS_A1. MS_B2 and CT_B1 are put on hold. MS_A1 is
notified of the incoming call from MS_B1.
path to MS_A1.
8) MS_B1 puts the three subscribers to-
The multiparty call between MS_B1, MS_B2,
CT_B1 and MS_A1 is successfully established.
to each other.
9) MS_B1 establishes a PTP call to MS_A2. MS_B2, CT_B1 and MS_A1 are put on hold.
MS_B1.
path to MS_A2.
11) MS_B1 puts the four subscribers to-
CT_B1, MS_A1 and MS_A2 is successfully
12) MS_B1 establishes a PTP call to CT_A1. MS_B2, CT_B1, MS_A1 and MS_A2 are put
from MS_B1.
13) CT_A1 takes the call. The PTP call between MS_B1 and CT_A1 is
path to CT_A1.
14) MS_B1 puts the five subscribers together
CT_B1, MS_A1, MS_A2 and CT_A1 is suc-
15) MS_B1 closes the multiparty call. Multiparty call is released. All related resources
are de-allocated.

Step 3: MS_B2 starts the MPTY call in network A.
MS_B2.
path to MS_A1.
3) MS_B2 establishes a PTP call to CT_A1. MS_A1 is put on hold. CT_A1 is notified of the
incoming call from MS_B2.


4) CT_A1 takes the call. The PTP call between MS_B2 and CT_A1 is
path to CT_A1.
5) MS_B2 puts both subscribers together to
a multiparty call.
The multiparty call between MS_B2, MS_A1
each other.
6) MS_B2 establishes a PTP call to MS_A2. MS_A1 and CT_A1 are put on hold. MS_A2 is
notified of the incoming call from MS_B2.
path to MS_A2.
8) MS_B2 puts the three subscribers to-
The multiparty call between MS_B2, MS_A1,
CT_A1 and MS_A2 is successfully established.
to each other.
9) MS_B2 establishes a PTP call to MS_B1. MS_A1, CT_A1 and MS_A2 are put on hold.
MS_B2.
path to MS_B1.
11) MS_B2 puts the four subscribers to-
CT_A1, MS_A2 and MS_B1 is successfully
12) MS_B2 establishes a PTP call to CT_B1. MS_A1, CT_A1, MS_A2 and MS_B1 are put
on hold. CT_B1 is notified of the incoming call
from MS_B2.
13) CT_B1 takes the call. The PTP call between MS_B2 and CT_B1 is
path to CT_B1.
14) MS_B2 puts the five subscribers together
CT_A1, MS_A2, MS_B1 and CT_B1 is suc-
15) MS_B3 closes the multiparty call. Multiparty call is released. All related resources
are de-allocated.

Step 4: MS_A2 starts the MPTY call in network B.
MS_A2.


path to MS_B1.
3) MS_A2 establishes a PTP call to CT_B1. MS_B1 is put on hold. CT_B1 is notified of the
4) CT_B1 takes the call. The PTP call between MS_A2 and CT_B1 is
path to CT_B1.
a multiparty call.
The multiparty call between MS_A2, MS_B1
and CT_B1 is successfully established. All
each other.
6) MS_A2 establishes a PTP call to MS_B2. MS_B1 and CT_B1 are put on hold. MS_B2 is
path to MS_B2.
The multiparty call between MS_A2, MS_B1,
CT_B1 and MS_B2 is successfully established.
to each other.
9) MS_A2 establishes a PTP call to MS_A1. MS_B1, CT_B1 and MS_B2 are put on hold.
MS_A2
path to MS_A1.
CT_B1, MS_B2 and MS_A1 is successfully
12) MS_A2 establishes a PTP call to CT_A1. MS_B1, CT_B1, MS_B2 and MS_A1 are put
from MS_A2.
path to CT_A1.
to a Multiparty call.
CT_B1, MS_B2, MS_A1 and CT_A1 is suc-
are de-allocated.


d) Success criteria
MS_A1, MS_A2, MS_B1 and MS_B2 are able to initialize a multiparty call with mobile subscribers
and fixed line subscribers.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.37 Notification of Call Forwarding (roaming case)


2.4.1
2.4.2
2.4.12
2.4.1

a) Purpose
Verify notification of a forwarded call.

MS_A2 have Supplementary Service Call Forwarding Unconditional (CFU) and has his calls for-
warded to MS_A3.
MS_B2 have Supplementary Service Call Forwarding Unconditional (CFU) and has his calls for-
warded to MS_B3.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_A2 MS_B2
MS_B3 MS_A3


c) Test procedure
1) MS_A1 establishes a PTP call to MS_A2. MS_A2 has forwarded his calls to MS_A3.
on MS_A3. MS_A1 is notified of the call for-
warding to MS_A3.
path to MS_A3.
allocated.
4) MS_B1 establishes a PTP call to MS_B2. MS_B2 has forwarded his calls to MS_B3.
on MS_B3. MS_B1 is notified of the call for-
warding to MS_B3.
path to MS_B3.
allocated.
7) MS_B1 establishes a PTP call to MS_A2. MS_A2 has forwarded his calls to MS_A3.
on MS_A3. MS_B1 is notified of the call for-
warding to MS_A3.
path to MS_A3.
allocated.
10) MS_A1 establishes a PTP call to MS_B2. MS_B2 has forwarded his calls to MS_B3.
on MS_B3. MS_A1 is notified of the call for-
warding to MS_B3.
path to MS_B3.
allocated.



d) Success criteria
MS_A3 was successfully notified about the forwarded PTP call. The MSISDN of the originator
was displayed on MS_A3.
MS_B3 was successfully notified about the forwarded PTP call. The MSISDN of the originator
was displayed on MS_B3.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.38 Establishment of several MTM Data calls (Bearer Services) with different eMLPP
priorities (roaming case)


2.3.1
2.3.6
2.3.8
2.3.13
2.4.1
2.4.5
10.2.1
10.2.2
2.3.1
10.2.1
3GPP TS27.007

a) Purpose
Verify the different bearer services in roaming case.

DCE_A1 is connected to network A (Data Circuit Terminating Equipment).
DCE_B1 is connected to network B (Data Circuit Terminating Equipment).
MS_A1, MS_A2, MS_B1 and MS_B2 are terminals with subscriptions to the following bearer
services:

To configure the bearer services and to set up a call with the terminal, refer to chapter 6.2 Annex
- Configuration of User Equipment for Data Calls.



Step 1: Mobile to mobile data call from MS_A1 in network A to MS_B2 in network A.
Step 2: Mobile to mobile data call from MS_A1 in network A to MS_A2 in network B.
Step 3: Mobile to mobile data call from MS_A1 in network A to MS_B1 in network B.
Step 4: Mobile to mobile data call from MS_B1 in network B to MS_A2 in network B.
Step 5: Mobile to mobile data call from MS_B1 in network B to MS_B2 in network A.
Step 6: Mobile to mobile data call from MS_B1 in network B to MS_A1 in network A.
Step 7: Data call between DCE_A1 in network A to DCE_B1 in network B.
Step 8: Mobile to fixed network data call from MS_A1 in network A to DCE_A1 in network A.
Step 9: Mobile to fixed network data call from MS_B2 in network A to DCE_A1 in network A.
Step 10: Mobile to fixed network data call from MS_B1 in network B to DCE_A1 in network A.
Step 11: Mobile to fixed network data call from MS_A2 in network B to DCE_A1 in network A.
Step 12: Mobile to fixed network data call from MS_B1 in network B to DCE_B1 in network B.
Step 13: Mobile to fixed network data call from MS_A2 in network B to DCE_B1 in network B.
Step 14: Mobile to fixed network data call from MS_A1 in network A to DCE_B1 in network B.
Step 15: Mobile to fixed network data call from MS_B2 in network A to DCE_B1 in network B.


Network A Network B

MSC_A1 MSC_B1
DCE_A1 (no VGCS / VBS subscriber) DCE_B1 (no VGCS / VBS subscriber)
MS_B2 (no VGCS / VBS subscriber) MS_A2 (no VGCS / VBS subscriber)

c) Test procedure



Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1 X X 3
2 X (V.22bis) X 1
3 X X 4
4
BS 24
2400 bps
X (V.22bis) X 2
5 X X 1
6 X (V.32) X 3
7 X X 2
8
BS 25
4800 bps
X (V.32) X 4
9 X X 1
10 X (V.32) X 2
11 X X 3
12
BS 26
9600 bps
X (V.32) X 4

Step 1: Mobile to mobile data call from MS_A1 in network A to MS_B2 in network A.
1) Configure MS_A1 and MS_B2 to perform
Calls
MS_A1 and MS_B2 are configured with the
2) MS_A1 establishes a data call to MS_B2
by dialling:
MS_B2 is notified of the incoming data call
played on MS_B2.
3) MS_B2 takes the data call. The data call between MS_A1 and MS_B2 is
successfully established.
4) MS_A1 sends test data to MS_B2. The test data is successfully transmitted and
received.
5) MS_B2 sends test data to MS_A1. The test data is successfully transmitted and
received.
allocated.
table above.

Step 2: Mobile to mobile data call from MS_A1 in network A to MS_A2 in network B.


Calls
by dialling:
played on MS_A2.
received.
received.
allocated.
table above.

Step 3: Mobile to mobile data call from MS_A1 in network A to MS_B1 in network B.
1) Configure MS_A1 and MS_B1 to perform
Calls
MS_A1 and MS_B1 are configured with the
2) MS_A1 establishes a data call to MS_B1
by dialling:
played on MS_B1.
3) MS_B1 takes the data call. The data call between MS_A1 and MS_B1 is
received.
received.
allocated.


table above.

Step 4: Mobile to mobile data call from MS_B1 in network B to MS_A2 in network B.
1) Configure MS_B1 and MS_A2 to perform
Calls
MS_B1 and MS_A2 are configured with the
2) MS_B1 establishes a data call to MS_A2
by dialling:
from MS_B1. The MSISDN of MS_B1 is dis-
played on MS_A2.
3) MS_A2 takes the data call. The data call between MS_B1 and MS_A2 is
received.
received.
allocated.
table above.

Step 5: Mobile to mobile data call from MS_B1 in network B to MS_B2 in network A.
1) Configure MS_B1 and MS_B2 to perform
Calls
MS_B1 and MS_B2 are configured with the
2) MS_B1 establishes a data call to MS_B2
by dialling:
played on MS_B2.
3) MS_B2 takes the data call. The data call between MS_B1 and MS_B2 is


4) MS_B1 sends test data to MS_B2. The test data is successfully transmitted and
received.
5) MS_B2 sends test data to MS_B1. The test data is successfully transmitted and
received.
allocated.
table above.

Step 6: Mobile to mobile data call from MS_B1 in network B to MS_A1 in network A.
1) Configure MS_B1 and MS_A1 to perform
Calls
MS_B1 and MS_A1 are configured with the
2) MS_B1 establishes a data call to MS_A1
by dialling:
played on MS_A1.
3) MS_A1 takes the data call. The data call between MS_B1 and MS_A1 is
4) MS_B1 sends test data to MS_A1. The test data is successfully transmitted re-
ceived.
received.
allocated.
table above.


Step 7: Data call between DCE_A1 in network A to DCE_B1 in network B.
1) Configure DCE_A1 and DCE_B1 to per-
ment for Data Calls
DCE_A1 and DCE_B1 are configured with the
DCE_B1 by dialling:
DCE_B1 is notified of the incoming data call
from DCE_A1.
3) DCE_B1 takes the data call. The data call between DCE_A1 and DCE_B1
is successfully established with the correct
bearer service and line speed. Therefore check
the channel assignment messages.
4) DCE_A1 sends test data to DCE_B1. The test data is successfully transmitted and
received.
5) DCE_B1 sends test data to DCE_A1. The test data is successfully transmitted and
received.
allocated.
7) DCE_B1 establishes a data call to
DCE_A1 by dialling:
from DCE_B1.
8) DCE_A1 takes the data call. The data call between DCE_B1 and DCE_A1
is successfully established with the correct
bearer service and line speed. Therefore check
the channel assignment messages.
9) DCE_A1 sends test data to DCE_B1. The test data is successfully transmitted and
received.
10) DCE_B1 sends test data to DCE_A1. The test data is successfully transmitted and
received.
11) DCE_B1 closes the call. Call is released. All related resources are de-
allocated.
table above.


Step 8: Mobile to fixed network data call from MS_A1 in network A to DCE_A1 in network A.
ment for Data Calls
DCE_A1 by dialling:
from MS_A1.
received.
received.
allocated.
MS_A1 by dialling:
from DCE_A1.
8) MS_A1 takes the data call. The data call between DCE_A1 and MS_A1 is
received.
received.
allocated.
table above.


Step 9: Mobile to fixed network data call from MS_B2 in network A to DCE_A1 in network A.
1) Configure MS_B2 and DCE_A1 to per-
ment for Data Calls
MS_B2 and DCE_A1 are configured with the
2) MS_B2 establishes a data call to
DCE_A1 by dialling:
from MS_B2.
3) DCE_A1 takes the data call. The data call between MS_B2 and DCE_A1 is
4) MS_B2 sends test data to DCE_A1. The test data is successfully transmitted and
received.
5) DCE_A1 sends test data to MS_B2. The test data is successfully transmitted and
received.
allocated.
MS_B2 by dialling:
from DCE_A1.
8) MS_B2 takes the data call. The data call between DCE_A1 and MS_B2 is
received.
received.
allocated.
table above.


Step 10: Mobile to fixed network data call from MS_B1 in network B to DCE_A1 in network A.
1) Configure MS_B1 and DCE_A1 to per-
ment for Data Calls
DCE_A1 by dialling:
from MS_B1.
3) DCE_A1 takes the data call. The data call between MS_B1 and DCE_A1 is
received.
received.
allocated.
MS_B1 by dialling:
from DCE_A1.
8) MS_B1 takes the data call. The data call between DCE_A1 and MS_B1 is
received.
received.
allocated.
table above.


Step 11: Mobile to fixed network data call from MS_A2 in network B to DCE_A1 in network A.
ment for Data Calls
DCE_A1 by dialling:
from MS_A2.
received.
received.
allocated.
MS_A2 by dialling:
from DCE_A1.
8) MS_A2 takes the data call. The data call between DCE_A1 and MS_A2 is
received.
received.
allocated.
table above.


Step 12: Mobile to fixed network data call from MS_B1 in network B to DCE_B1 in network B.
1) Configure MS_B1 and DCE_B1 to per-
ment for Data Calls
MS_B1 and DCE_B1 are configured with the
DCE_B1 by dialling:
from MS_B1.
3) DCE_B1 takes the data call. The data call between MS_B1 and DCE_B1 is
4) MS_B1 sends test data to DCE_B1. The test data is successfully transmitted and
received.
5) DCE_B1 sends test data to MS_B1. The test data is successfully transmitted and
received.
allocated.
MS_B1 by dialling:
from DCE_B1.
8) MS_B1 takes the data call. The data call between DCE_B1 and MS_B1 is
received.
received.
allocated.
table above.


Step 13: Mobile to fixed network data call from MS_A2 in network B to DCE_B1 in network B.
1) Configure MS_A2 and DCE_B1 to per-
ment for Data Calls
MS_A2 and DCE_B1 are configured with the
DCE_B1 by dialling:
from MS_A2.
3) DCE_B1 takes the data call. The data call between MS_A2 and DCE_B1 is
4) MS_A2 sends test data to DCE_B1. The test data is successfully transmitted and
received.
5) DCE_B1 sends test data to MS_A2. The test data is successfully transmitted and
received.
allocated.
MS_A2 by dialling:
from DCE_B1.
8) MS_A2 takes the data call. The data call between DCE_B1 and MS_A2 is
received.
received.
allocated.
table above.


Step 14: Mobile to fixed network data call from MS_A1 in network A to DCE_B1 in network B.
1) Configure MS_A1 and DCE_B1 to per-
ment for Data Calls
MS_A1 and DCE_B1 are configured with the
DCE_B1 by dialling:
from MS_A1.
3) DCE_B1 takes the data call. The data call between MS_A1 and DCE_B1 is
received.
received.
allocated.
MS_A1 by dialling:
from DCE_B1.
8) MS_A1 takes the data call. The data call between DCE_B1 and MS_A1 is
received.
received.
allocated.
table above.


Step 15: Mobile to fixed network data call from MS_B2 in network A to DCE_B1 in network B.
1) Configure MS_B2 and DCE_B1 to per-
ment for Data Calls
MS_B2 and DCE_B1 are configured with the
DCE_B1 by dialling:
from MS_B2.
3) DCE_B1 takes the data call. The data call between MS_B2 and DCE_B1 is
received.
received.
allocated.
MS_B2 by dialling:
from DCE_B1.
8) MS_B2 takes the data call. The data call between DCE_B1 and MS_B2 is
received.
received.
allocated.
table above.



d) Success criteria
MS_A1, MS_A2, MS_B1, MS_B2 and the Data Circuit Terminating Equipment DCE_A1 and
DCE_B1 are able to setup and receive data calls with different bearer services and line speeds.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.39 Establishment of several PTP calls with different priorities (roaming case)


2.4.1
2.4.5
10.2.1
10.2.2
10.2.1

a) Purpose
Verify that a PTP call is established successfully with the correct priority.

Step 1: MS_A1 in network A calls MS_B1 in network B.
Step 2: MS_B2 in network A calls MS_A2 in network B.
Step 3: MS_B1 in network B calls MS_A1 in network A.
Step 4: MS_A2 in network B calls MS_B2 in network A.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2

c) Test procedure


Step 1: MS_A1 in network A calls MS_B1 in network B.

1) MS_A1 establishes a PTP call to MS_B1
speech path between MS_A1 and MS_B1.
network.
MS_B1.
3 and 4.

Step 2: MS_B2 in network A calls MS_A2 in network B.

1) MS_B2 establishes a PTP call to MS_A2
speech path between MS_B2 and MS_A2.
network.
MS_A2.
2) MS_B2 releases the call. The call is correctly released. All related re-
3 and 4.

Step 3: MS_B1 in network B calls MS_A1 in network A.

1) MS_B1 establishes a PTP call to MS_A1
speech path between MS_B1 and MS_A1.
network.
MS_A1.


3 and 4.

Step 4: MS_A2 in network B calls MS_B2 in network A.

1) MS_A2 establishes a PTP call to MS_B2
speech path between MS_A2 and MS_B2.
network.
MS_B2.
3 and 4.

d) Success criteria
The PTP call is established successfully with the correct priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.40 Call to busy Mobile CFBusy to other mobile subscriber (roaming case)


2.4.1
2.4.12
2.4.1

a) Purpose
Verify that a PTP call to a busy mobile subscriber is forwarded when this subscriber has activated
Call Forwarding Busy (CFB).

MS_A1 and MS_B1 have Supplementary Service Call Forwarding Busy (CFB).

Step 1: MS_A1 in network A activates CFB to MS_B2 in network A.
Step 2: MS_A1 in network A activates CFB to MS_A3 in network B.
Step 3: MS_A1 in network A activates CFB to MS_B4 in network B.
Step 4: MS_B1 in network B activates CFB to MS_A2 in network B.
Step 5: MS_B1 in network B activates CFB to MS_B3 in network A.
Step 6: MS_B1 in network B activates CFB to MS_A4 in network A.



Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2
MS_B3 MS_A3
MS_A4 MS_B4

c) Test procedure

1) MS_A1 activates Call Forwarding Busy
(CFB) to MS_B2.
If MS_A1 is busy, incoming calls will be for-
warded to MS_B2.
2) MS_A1 calls MS_B1. Call is correctly established. There is speech
path between MS_A1 and MS_B1.
3) MS_A2 calls MS_A1. The call is forwarded to MS_B2. The MSISDN
number from MS_A2 is displayed on MS_B2.
MS_B2.
6) MS_A1 deactivates CFB to MS_B2. CFB is deactivated.



1) MS_A1 activates CFB to MS_A3. If MS_A1 is busy, incoming calls will be for-
warded to MS_A3.
3) MS_A2 calls MS_A1. The call is forwarded to MS_A3. The MSISDN
number from MS_A2 is displayed on MS_A3.
MS_A3.
6) MS_A1 deactivates CFB to MS_A3. CFB is deactivated.

Step 3: MS_A1 in network A activates CFB to MS_B4 in network B.
1) MS_A1 activates CFB to MS_B4. If MS_A1 is busy, incoming calls will be for-
warded to MS_B4.
3) MS_A2 calls MS_A1. The call is forwarded to MS_B4. The MSISDN
number from MS_A2 is displayed on MS_B4.
MS_B4.


6) MS_A1 deactivates CFB to MS_B4. CFB is deactivated.

Step 4: MS_B1 in network B activates CFB to MS_A2 in network B.
1) MS_B1 activates Call Forwarding Busy
(CFB) to MS_A2.
If MS_B1 is busy, incoming calls will be for-
warded to MS_A2.
2) MS_B1 calls MS_A1. Call is correctly established. There is speech
path between MS_B1 and MS_A1.
3) MS_B2 calls MS_B1. The call is forwarded to MS_A2. The MSISDN
number from MS_B2 is displayed on MS_A2.
There is speech path between MS_B2 and
MS_A2.
6) MS_B1 deactivates CFB to MS_A2. CFB is deactivated.
8) MS_B2 calls MS_B1. The call is not forwarded. MS_B2 gets the

Step 5: MS_B1 in network B activates CFB to MS_B3 in network A.
1) MS_B1 activates CFB to MS_B3. If MS_B1 is busy, incoming calls will be for-
warded to MS_B3.
3) MS_B2 calls MS_B1. The call is forwarded to MS_B3. The MSISDN
number from MS_B2 is displayed on MS_B3.


MS_B3.
6) MS_B1 deactivates CFB to MS_B3. CFB is deactivated.

Step 6: MS_B1 in network B activates CFB to MS_A4 in network A.
1) MS_B1 activates CFB to MS_A4. If MS_B1 is busy, incoming calls will be for-
warded to MS_A4.
3) MS_B2 calls MS_B1. The call is forwarded to MS_A4. The MSISDN
number from MS_B2 is displayed on MS_A4.
MS_A4.
6) MS_B1 deactivates CFB to MS_A4. CFB is deactivated.



d) Success criteria
The PTP call to a busy mobile subscriber was correctly forwarded.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.41 MOC call when terminator rejects call (roaming case)


EN 301515

a) Purpose
Verify that a MOC is released when the terminator rejects it.

CT_B1 is connected to network B.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2
CT_A1 CT_B1

c) Test procedure

3) MS_B1 calls CT_B1 CT_B1 is notified of the incoming call.


4) CT_B1 rejects the call. The call is correctly released. All related re-
5) MS_A1 calls CT_B1. CT_B1 is notified of the incoming call.
7) MS_B1 calls CT_A1. CT_A1 is notified of the incoming call.
9) MS_B2 calls CT_A1. CT_A1 is notified of the incoming call.
11) MS_A2 calls CT_B1. CT_B1 is notified of the incoming call.
15) MS_B2 calls CT_B1. CT_B1 is notified of the incoming call.

d) Success criteria
The mobile originating call is released when terminating subscriber rejects the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.42 Unsuccessful MOC due to unallocated number (roaming case)


EN 301515

a) Purpose
Verify that no mobile originating call can be established when calling a number that is not as-
signed.


Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2
CT_A1 CT_B1

c) Test procedure



3) MS_B1 calls CT_B1 by dialling a number
MS_B1 receives an audible indicator (e.g. an-
4) MS_B1 closes the call or awaits the net-
5) MS_A1 calls CT_B1 by dialling a number
7) MS_B1 calls CT_A1 by dialling a number
9) MS_B2 calls CT_A1 by dialling a number
11) MS_A2 calls CT_B1 by dialling a number
15) MS_B2 calls CT_B1 by dialling a number

d) Success criteria
No mobile originating call can be established when calling a number that is not assigned.


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.43 MTC Paging Time Out (roaming case)


EN 301515

a) Purpose
Verify that a MTC is released after paging time out when the terminating subscriber does not an-
swer the call.


Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
CT_A1 CT_B1

c) Test procedure

1) MS_B1 leaves coverage area. VLR_A1 data still available for MS_B1. It is still
2) CT_A1 calls MS_B1. The call is correctly released after paging time
3) MS_B1 moves to coverage area. MS_B1 is attached to network A.


4) MS_A1 leaves coverage area. VLR_B1 data still available for MS_A1. It is still
attached to network B.
5) CT_B1 calls MS_A1. The call is correctly released after paging time
6) MS_A1 moves to coverage area. MS_A1 is attached to network B.
7) MS_B1 leaves coverage area. VLR_A1 data still available for MS_B1. It is still
8) CT_B1 calls MS_B1. The call is correctly released after paging time
9) MS_B1 moves to coverage area. MS_B1 is attached to network A.
10) MS_A1 leaves coverage area. VLR_B1 data still available for MS_A1. It is still
attached to network B.
11) CT_A1 calls MS_A1. The call is correctly released after paging time
12) MS_A1 moves to coverage area. MS_A1 is attached to network B.

d) Success criteria
The mobile terminated call is released after paging time out when the terminating subscriber does
not answer the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.44 Unsuccessful MTC call, subscriber not in VLR (roaming case)


EN 301515

a) Purpose
Verify that a mobile terminating call is released when there is no VLR subscriber information for
the terminating subscriber.

Step 1: Delete the subscriber information for MS_B1 in VLR_B1.
Step 2: Delete the subscriber information for MS_A1 in VLR_A1.
Step 3: Delete the subscriber information for MS_B2 in VLR_A1.
Step 4: Delete the subscriber information for MS_A2 in VLR_B1.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 MS_A2

c) Test procedure


Step 1: Delete the subscriber information for MS_B1 in VLR_B1.
MS_B1 in VLR_B1.
more for MS_B1 in VLR_B1.
2) MS_A1 calls MS_B1. The call is correctly released. All related re-
3) MS_B2 calls MS_B1. The call is correctly released. All related re-
5) Switch off MS_B1 and switch it on again. MS_B1 performs location update, has correct
subscriber data in the VLR_B1 and is attached
to network B.

Step 2: Delete the subscriber information for MS_A1 in VLR_A1.
MS_A1 in VLR_A1.
more for MS_A1 in VLR_A1.
2) MS_B1 calls MS_A1. The call is correctly released. All related re-
3) MS_A2 calls MS_A1. The call is correctly released. All related re-
5) Switch off MS_A1 and switch it on again. MS_A1 performs location update, has correct
subscriber data in the VLR_A1 and is attached
to network A.

Step 3: Delete the subscriber information for MS_B2 in VLR_A1.
MS_B2 in VLR_A1.
more for MS_B2 in VLR_A1.
3) MS_B1 calls MS_B2. The call is correctly released. All related re-
5) Switch off MS_B2 and switch it on again. MS_B2 performs location update, has correct
subscriber data in the VLR_A1 and is attached
to network A.



Step 4: Delete the subscriber information for MS_A2 in VLR_B1.
MS_A2 in VLR_B1.
more for MS_A2 in VLR_B1.
3) MS_A1 calls MS_A2. The call is correctly released. All related re-
5) Switch off MS_A2 and switch it on again. MS_A2 performs location update, has correct
subscriber data in the VLR_B1 and is attached
to network B.

d) Success criteria
The MTC is released because there is no VLR subscriber information for the terminating sub-
scriber.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.45 Closed User Group (non-roaming case)


2.4.1
2.4.8
2.4.9
10.4
2.4.1
10.4.2
11.3.2
11.3.8i
11.5.1
3GPP TS22.085

a) Purpose
Verify the Supplementary Service Closed User Group (CUG).

Incoming Access (IA):
An arrangement which allows a member of a CUG to receive calls from outside the CUG.

Outgoing Access (OA):
An arrangement which allows a member of a CUG to place calls outside the CUG.

Incoming Calls Barred Within A CUG (ICB):
An access restriction that prevents a CUG member from receiving calls from other members
of that group.

Outgoing Calls Barred Within A CUG (OCB):
An access restriction that prevents a CUG member from placing calls to other members of
that group.

Subscriber membership of one or more CUGs
A specific user may be a member of one or more CUGs.

The ability to set up emergency calls remains unaffected according to 3GPP
TS22.085

The ability to set up Railway emergency calls remains unaffected according to EI-
RENE FRS/SRS.


MS_A1, MS_A2, MS_A3 MS_A4 have Supplementary Service Closed User Group.

Step 1: Incoming Access (IA).
Step 2: Outgoing Access (OA).
Step 3: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A CUG (OCB).
Step 4: Outgoing Access (OA) subscription CUG_A1 and CUG_A2.
Step 5: Public Emergency Call and Railway Emergency Call (GID: 299).

Test configuration for steps 1 to 5:

Network A

MS_A1 (REC GID: 299, CUG_A1)
MS_A2 (CUG_A1, no VGCS / VBS subscriber)
MS_A4 (CUG_A1, CUG_A2, no VGCS / VBS
subscriber)
MS_A5 (no CUG, no VGCS / VBS subscriber)
CT_A1 (REC GID: 299)

CoO=Cell_A1

GCA_A1, REC GID: 299 Prio 0


c) Test procedure
Step 1: Incoming Access (IA).
1) All CUG_A1 members have incoming
access (IA).
Incoming calls to CUG_A1 members are pos-
sible.
2) All CUG_A2 members have NO incoming
access (IA).
Incoming calls to CUG_A2 members are not
possible.
on MS_A1.
path to MS_A1.
allocated.
6) MS_A5 establishes a PTP call to MS_A3. MS_A5 receives an audible indicator (e.g. an-
allocated.

Step 2: Outgoing Access (OA).
1) All CUG_A1 members have outgoing
access (OA).
Outgoing calls for CUG_A1 members are pos-
sible.
2) All CUG_A2 members have NO outgoing
access (OA).
Outgoing calls for CUG_A2 members are not
possible.
on MS_A5.
path to MS_A5.
allocated.
allocated.


Step 3: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A CUG (OCB).
access (IA) and outgoing access (OA).
Incoming and outgoing calls for CUG_A1
members are possible.
2) Subscriber MS_A1 have incoming calls
barred within a CUG (ICB).
Incoming calls to MS_A1 form other CUG_A1
members are not possible.
3) Subscriber MS_A2 have outgoing calls
barred within a CUG (OCB).
Outgoing calls from MS_A2 to other CUG_A1
on MS_A5.
path to MS_A5.
allocated.
on MS_A1.
path to MS_A1.
allocated.
on MS_A5.
path to MS_A5.
allocated.
on MS_A2.
path to MS_A2.
allocated.


allocated.
on MS_A4.
path to MS_A4.
20) MS_A1 closes the call Call is released. All related resources are de-
allocated.
allocated.
on MS_A2.
path to MS_A2.
25) MS_A4 closes the call Call is released. All related resources are de-
allocated.

Step 4: Outgoing Access (OA) subscription CUG_A1 and CUG_A2.
access (OA).
possible.
access (OA).
sible.
on MS_A1.
path to MS_A1.
allocated.
on MS_A3.


path to MS_A3.
allocated.
allocated.

Step 5: Public Emergency Call and Railway Emergency Call (GID: 299).
access (OA).
possible.
2) MS_A1 is registered to a FN (Functional
Number).
MS_A1 have a FN witch is shown on the dis-
play of MS_A1.
3) MS_A1 establishes a Public Emergency
Call.
The PSAP (Public Safety Answering Point)
operator is notified of the incoming emergency
call from MS_A1. The MSISDN of MS_A1 is
displayed on the display of the operator termi-
nal.
4) The PSAP operator takes the call. The emergency call between MS_A1 and
PSAP operator is successfully established.
MS_A1 has speech path to the operator.
5) MS_A1 closes the call. Emergency call is released. All related re-
6) MS_A1 establishes a Railway Emer-
gency Call (GID: 299).
The CT_A1 is notified of the incoming emer-
gency call from MS_A1. The FN (Functional
Number) of MS_A1 is displayed on the display
of the CT_A1 terminal via OTDI.
7) The CT_A1 takes the call. The emergency call between MS_A1 and the
CT_A1 is successfully established. MS_A1 has
speech path to the CT_A1.



d) Success criteria
Handling from incoming and outgoing calls are in accordance with the barring settings of the CUG
members.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.46 Closed User Group (roaming case)


2.4.1
2.4.8
2.4.9
10.4
2.4.1
10.4.2
11.3.2
11.3.8i
11.5.1
3GPP TS22.085

a) Purpose
Verify the Supplementary Service Closed User Group (CUG).

Incoming Access (IA):
An arrangement which allows a member of a CUG to receive calls from outside the CUG.

Outgoing Access (OA):
An arrangement which allows a member of a CUG to place calls outside the CUG.

Incoming Calls Barred Within A CUG (ICB):
An access restriction that prevents a CUG member from receiving calls from other members
of that group.

Outgoing Calls Barred Within A CUG (OCB):
An access restriction that prevents a CUG member from placing calls to other members of
that group.

Subscriber membership of one or more CUGs
A specific user may be a member of one or more CUGs.

The ability to set up emergency calls remains unaffected according to 3GPP
TS22.085.

The ability to set up Railway emergency calls remains unaffected according to EI-
RENE FRS/SRS.

MS_A1, MS_A2, MS_A3 MS_A5, MS_A6, MS_A7, MS_B1, MS_B2, MS_B3 MS_B5, MS_B6 and
MS_B7 have Supplementary Service Closed User Group.




Step 1: Incoming Access (IA) originating subscriber of HLR_A1 in network A, CUG/HLR_A1.
Step 2: Incoming Access (IA) originating subscriber of HLR_B1 in network A, CUG/HLR_A1.
Step 3: Incoming Access (IA) originating subscriber of HLR_A1 in network B, CUG/HLR_A1.
Step 4: Incoming Access (IA) originating subscriber of HLR_B1 in network B, CUG/HLR_A1.
Step 5: Incoming Access (IA) originating subscriber of HLR_B1 in network B, CUG/HLR_B1.
Step 6: Incoming Access (IA) originating subscriber of HLR_A1 in network B, CUG/HLR_B1.
Step 7: Incoming Access (IA) originating subscriber of HLR_B1 in network A, CUG/HLR_B1.
Step 8: Incoming Access (IA) originating subscriber of HLR_A1 in network A, CUG/HLR_B1.
Step 9: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 in network A.
Step 11: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 and CUG_A2 in network A.
Step 12: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 in network B.
Step 13: No Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A2 in network B.
Step 14: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 and CUG_A2 in network B.
Step 15: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A CUG
(OCB) CUG in HLR_A1.
Step 16: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A CUG
(OCB) CUG in HLR_B1.
Step 17: Public Emergency Call.
Step 18: Railway Emergency Call (GID: 299).



Test configuration for step 1 to 18:

Network A Network B

A-MSC_A1 R-MSC_B1
MS_B1 (REC GID: 299, CUG_B3) MS_A1 (REC GID: 299, CUG_A1)
MS_B2 (CUG_B4, no VGCS / VBS subscriber)
MS_A2 (CUG_A2, no VGCS / VBS
subscriber)
MS_B3 (CUG_B3, CUG_B4, no VGCS / VBS
subscriber)
subscriber)
MS_B4 (no CUG, no VGCS / VBS subscriber) MS_A4 (no CUG, no VGCS / VBS subscriber)
MS_A5 (REC GID: 299, CUG_A1) MS_B5 (REC GID: 299, CUG_B3)
MS_B6 (CUG_B4, no VGCS / VBS
subscriber)
subscriber)
MS_B7 (CUG_B3, CUG_B4, no VGCS / VBS
subscriber)
MS_A8 (no CUG, no VGCS / VBS subscriber) MS_B8 (no CUG, no VGCS / VBS subscriber)
CT_A1 (GCA_AB1, REC GID: 299) CT_B1 (GCA_AB1, REC GID: 299)

CoO=Cell_A1 CoO=Cell_B1

GCA_AB1, REC GID: 299 Prio 0


c) Test procedure

Step 1: Incoming Access (IA) originating subscriber of HLR_A1 in network A, CUG/HLR_A1.
access (IA).
sible.
access (IA).
possible.
on MS_A1.
path to MS_A1.
allocated.
allocated.
on MS_A5.
path to MS_A5.
allocated.
allocated.
on MS_A3.
path to MS_A3.
allocated.


on MS_A7.
path to MS_A7.
allocated.

Step 2: Incoming Access (IA) originating subscriber of HLR_B1 in network A, CUG/HLR_A1.
access (IA).
sible.
access (IA).
possible.
on MS_A1.
path to MS_A1.
allocated.
6) MS_B4 establishes a PTP call to MS_A2. MS_B4 receives an audible indicator (e.g. an-
allocated.
on MS_A5.
path to MS_A5.
allocated.
allocated.


on MS_A3.
path to MS_A3.
allocated.
on MS_A7.
path to MS_A7.
allocated.

Step 3: Incoming Access (IA) originating subscriber of HLR_A1 in network B,CUG/HLR_A1.
access (IA).
sible.
access (IA).
possible.
on MS_A5.
path to MS_A5.
allocated.
allocated.
on MS_A1.


path to MS_A1.
allocated.
allocated.
on MS_A7.
path to MS_A7.
allocated.
on MS_A3.
path to MS_A3.
allocated.

Step 4: Incoming Access (IA) originating subscriber of HLR_B1 in network B,CUG/HLR_A1.
access (IA).
sible.
access (IA).
possible.
on MS_A5.
path to MS_A5.
allocated.


allocated.
on MS_A1.
path to MS_A1.
allocated.
allocated.
on MS_A7.
path to MS_A7.
allocated.
on MS_A3.
path to MS_A3.
allocated.

Step 5: Incoming Access (IA) originating subscriber of HLR_B1 in network B,CUG/HLR_B1.
1) All CUG_B3 members have incoming
access (IA).
Incoming calls to CUG_B3 members are pos-
sible.
2) All CUG_B4 members have NO incoming
access (IA).
Incoming calls to CUG_B4 members are not
possible.


on MS_B1.
path to MS_B1.
allocated.
6) MS_B8 establishes a PTP call to MS_B2. MS_B8 receives an audible indicator (e.g. an-
allocated.
on MS_B5.
path to MS_B5.
allocated.
allocated.
on MS_B3.
path to MS_B3.
allocated.
on MS_B7.
path to MS_B7.
allocated.



Step 6: Incoming Access (IA) originating subscriber of HLR_A1 in network B, CUG/HLR_B1.
access (IA).
sible.
access (IA).
possible.
on MS_B1.
path to MS_B1.
allocated.
6) MS_A4 establishes a PTP call to MS_B2. MS_A4 receives an audible indicator (e.g. an-
allocated.
on MS_B5.
path to MS_B5.
allocated.
allocated.
on MS_B3.
path to MS_B3.
allocated.


on MS_B7.
path to MS_B7.
allocated.

Step 7: Incoming Access (IA) originating subscriber of HLR_B1 in network A, CUG/HLR_B1.
access (IA).
sible.
access (IA).
possible.
on MS_B5.
path to MS_B5.
allocated.
allocated.
on MS_B1.
path to MS_B1.
allocated.
allocated.


on MS_B7.
path to MS_B7.
allocated.
on MS_B3.
path to MS_B3.
allocated.

Step 8: Incoming Access (IA) originating subscriber of HLR_A1 in network A, CUG/HLR_B1.
access (IA).
sible.
access (IA).
possible.
on MS_B5.
path to MS_B5.
allocated.
allocated.
on MS_B1.


path to MS_B1.
allocated.
allocated.
on MS_B7.
path to MS_B7.
allocated.
on MS_B3.
path to MS_B3.
allocated.

access (OA).
sible.
access (OA).
possible.
on MS_A4.
path to MS_A4.
allocated.


on MS_B8.
path to MS_B8.
allocated.
on MS_B4.
path to MS_B4.
allocated.

access (OA).
sible.
access (OA).
possible.
allocated.
allocated.
allocated.


Step 11: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 and CUG_A2 in
network A.
access (OA).
sible.
access (OA).
possible.
on MS_A4.
path to MS_A4.
allocated.
on MS_B8.
path to MS_B8.
allocated.
on MS_B4.
path to MS_B4.
allocated.

Step 12: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 in network B.
access (OA).
sible.
access (OA).
possible.
on MS_A8.


path to MS_A8.
allocated.
on MS_B4.
path to MS_B4.
allocated.
on MS_B8.
path to MS_B8.
allocated.
on MS_A4.
13) MS_A4 takes the call. The PTP call between MS_A1 and MS_BA4 is
path to MS_A4.
allocated.

Step 13: No Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A2 in network B.
access (OA).
sible.
access (OA).
possible.
allocated.


allocated.
allocated.
allocated.

Step 14: Outgoing Access (OA) originating subscriber of HLR_A1/CUG_A1 and CUG_A2 in
network B.
access (OA).
sible.
2) All CUG_A2 have NO outgoing access
(OA).
possible.
on MS_A8.
path to MS_A8.
allocated.
on MS_B4.
path to MS_B4.
allocated.
on MS_B8.


path to MS_B8.
allocated.
on MS_A4.
13) MS_A4 takes the call. The PTP call between MS_A3 and MS_BA4 is
path to MS_A4.
allocated.

Step 15: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A
CUG (OCB) CUG in HLR_A1.
access (IA).
Incoming calls for CUG_A1 members are pos-
sible.
access (OA).
sible.
3) Subscriber MS_A1 have incoming calls
Incoming calls to MS_A1 form other CUG_A1
4) Subscriber MS_A5 have outgoing calls
Outgoing calls from MS_A5 form other
CUG_A1 members are not possible.
on MS_A8.
path to MS_A8.
allocated.
on MS_B4.
path to MS_B4.
allocated.


on MS_A4.
path to MS_A4.
allocated.
on MS_B8.
path to MS_B8.
allocated.
on MS_A1.
path to MS_A1.
allocated.
on MS_A1.
path to MS_A1.
allocated.
on MS_A1.
path to MS_A1.
allocated.
on MS_A1.


path to MS_A1.
allocated.
on MS_A5.
path to MS_A5.
allocated.
allocated.
on MS_A3.
path to MS_A3.
allocated.
allocated.
on MS_A7.
path to MS_A7.
allocated.


allocated.
allocated.
on MS_A5.
path to MS_A5.
allocated.
49) MS_A5 establishes a PTP call to MS_A7 MS_A5 receives an audible indicator (e.g. an-
allocated.
on MS_A5.
path to MS_A5.
allocated.

Step 16: Incoming Calls Barred Within A CUG (ICB) and Outgoing Calls Barred Within A
CUG (OCB) CUG in HLR_B1.
access (IA).
Incoming calls for CUG_A1 members are pos-
sible.
2) All CUG_B3 members have outgoing
access (OA).
sible.
3) Subscriber MS_B1 have incoming calls
Incoming calls to MS_B1 form other CUG_B3
4) Subscriber MS_B5 have outgoing calls
Outgoing calls from MS_B5 form other
CUG_B3 members are not possible.


on MS_A8.
path to MS_A8.
allocated.
on MS_B4.
path to MS_B4.
allocated.
on MS_A4.
path to MS_A4.
allocated.
on MS_B8.
path to MS_B8.
allocated.
on MS_B1.
path to MS_B1.
allocated.
on MS_B1.


path to MS_B1.
allocated.
on MS_B1.
path to MS_B1.
allocated.
on MS_B1.
path to MS_B1.
allocated.
on MS_A5.
path to MS_A5.
allocated.
allocated.
on MS_A3.
path to MS_A3.
allocated.


allocated.
on MS_A7.
path to MS_A7.
allocated.
allocated.
allocated.
on MS_A5.
path to MS_A5.
allocated.
49) MS_A5 establishes a PTP call to MS_A7 MS_A5 receives an audible indicator (e.g. an-
allocated.
on MS_A5.
path to MS_A5.


allocated.

Step 17: Public Emergency Call.
1) Subscribers MS_A1, MS_A5, MS_B1
and MS_B5 do not have the service out-
going access (OA).
Outgoing calls for MS_A1, MS_A5, MS_B1
and MS_B5 are NOT possible.
Call.
nal.
Call.
nal.
8) MS_B1 establishes a Public Emergency
Call.
call from MS_B1. The MSISDN of MS_B1 is
nal.
9) The PSAP operator takes the call. The emergency call between MS_B1 and
MS_B1 has speech path to the operator.
10) MS_B1 closes the call. Emergency call is released. All related re-
Call.
nal.



Step 18: Railway Emergency Call (GID: 299).
1) Subscribers MS_A1, MS_A5, MS_B1
and MS_B5 do not have the service out-
going access (OA).
Outgoing calls for MS_A1, MS_A5, MS_B1
and MS_B5 are NOT possible.
Number).
play of MS_A1.
The CT_A1 and CT_B1 are notified of the in-
coming emergency call from MS_A1. The FN
(Functional Number) of MS_A1 is displayed on
the display of the CT terminals via OTDI.
5) The CT_B1 takes the call. The emergency call between MS_A1 and the
CT_B1 is successfully established. MS_A1 has
speech path to the CT_B1.
Number).
play of MS_A5.
coming emergency call from MS_A5. The FN
(Functional Number) of MS_A5 is displayed on
10) The CT_B1 takes the call. The emergency call between MS_A5 and the
CT_B1 is successfully established. MS_A5 has
12) MS_B1 is registered to a FN (Functional
Number).
MS_B1 have a FN witch is shown on the dis-
play of MS_B1.


13) MS_B1 establishes a Railway Emer-
coming emergency call from MS_B1. The FN
(Functional Number) of MS_B1 is displayed on
14) The CT_A1 takes the call. The emergency call between MS_B1 and the
CT_A1 is successfully established. MS_B1 has
15) The CT_B1 takes the call. The emergency call between MS_B1 and the
CT_B1 is successfully established. MS_B1 has
17) MS_B5 is registered to a FN (Functional
Number).
MS_B5 have a FN witch is shown on the dis-
play of MS_B5.
18) MS_B5 establishes a Railway Emer-
coming emergency call from MS_B5. The FN
(Functional Number) of MS_B5 is displayed on
19) The CT_A1 takes the call. The emergency call between MS_B5 and the
CT_A1 is successfully established. MS_B5 has
20) The CT_B1 takes the call. The emergency call between MS_B5 and the
CT_B1 is successfully established. MS_B5 has

d) Success criteria
Handling from incoming and outgoing calls are in accordance with the barring settings of the CUG
members.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.47 Call barring (roaming case)


2.4.1
2.4.17

2.4.1
9.10.2

a) Purpose
Verify the Supplementary Service Call barring.
Barring of outgoing international calls except those directed to the home PLMN country
(BOICEXHC)
Barring of incoming calls when roaming outside the home PLMN country (BIC-Roam)

MS_A1 have Supplementary Service Call barring.

Step 1: Barring of outgoing international calls except those directed to the home PLMN country
(BOICEXHC).
Step 2: Barring of incoming calls when roaming outside the home PLMN country (BIC-Roam).


Test configuration for step 1 and 2:

Network A Network B Network C

MSC_A1 MSC_B1
MSC_C1
MS_B1 MS_A1
MS_C1
MS_A2 MS_B2

MS_A3

c) Test procedure

All Call Barring codes are specific to your network, so you'll have to ask the network operator
what [code] to enter below:

Feature All Outgoing Incoming
Outgoing
International
Outgoing Intl
except home
country
Incoming
outside
home
country
Activate
Cancel
Status
**330*[code]#
##330*[code]#
*#330#
**333*[code]#
##333*[code]#
*#333#
**35*[code]#
##35*[code]#
*#35#
**331*[code]#
##331*[code]#
*#331#
**332*[code]#
##332*[code]#
*#332#
**351*[code]#
##351*[code]#
*#351#


Step 1: Barring of outgoing international calls except those directed to the home PLMN
country (BOICEXHC).
1) Configure MS_A1 to further call barring
of outgoing international calls except
those directed to the home PLMN coun-
try by dialling **332*[code]#.
Subscriber information is updated.
2) MS_A1 establishes a PTP Call to
MS_B1.
on MS_B1.
path to MS_B1.
allocated.
MS_B2.
on MS_B2.
path to MS_B2.
allocated.
MS_A2.
on MS_A2.
path to MS_A2.
allocated.
MS_A3.
on MS_A3.
path to MS_A3.
allocated.
MS_C1.
allocated.


16) MS_A1 did cancel the call barring of out-
going international calls except those
directed to the home PLMN country by
dialling ##332*[code]#.
Barring of outgoing international calls except
those directed to the home PLMN country is
deactivated.
17) MS_A1 did check the status by dialling
*#332# for call barring of outgoing inter-
national calls except those directed to the
home PLMN country.

Step 2: Barring of incoming calls when roaming outside the home PLMN country (BIC-
Roam).
1) Configure MS_A1 to further call barring
of incoming calls when roaming outside
the home PLMN country by dialling
**351*[code]#.
Subscriber information is updated.
2) MS_A2 establishes a PTP Call to MS_
A1.
allocated.
4) MS_A3 establishes a PTP Call to MS_
A1.
allocated.
6) MS_B1 establishes a PTP Call to MS_
A1.
allocated.
8) MS_B2 establishes a PTP Call to MS_
A1.
allocated.
10) MS_A1 did cancel the call barring of in-
coming calls when roaming outside the
home PLMN country by dialling
##351*[code]#.
Barring of incoming calls when roaming out-
side the home PLMN country is deactivated.


11) MS_A1 did check the status by dialling
*#351# for call barring of incoming calls
when roaming outside the home PLMN
country.

d) Success criteria
MS_A1 was able configure different call barring settings. Handling from incoming and outgoing
calls are in accordance with the barring settings.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.48 Public Emergency Call With SIM (non-roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call With SIM.


Network A

MS_A1

c) Test procedure

Call.
nal.


d) Success criteria
MS_A1 was able to establish a Public Emergency Call. The MSISDN from MS_A1 was displayed
on PSAP (Public Safety Answering Point) operator terminal.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.49 Public Emergency Call Without SIM (non-roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call Without SIM.

MS_A1 has NO SIM inside.

Network A

MS_A1

c) Test procedure

Call.
NOT displayed on the display of the operator
terminal.



d) Success criteria
MS_A1 was able to establish a Public Emergency Call without SIM.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.50 Public Emergency Call with TMSI and IMSI unknown in VLR (non-roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call With SIM, but the TMSI and IMSI are unknown in VLR

SIM of MS_A1 has no subscription to network A.

Network A

MS_A1

c) Test procedure

Call.
terminal.
3) MS_A1 close the call. Emergency call is released. All related re-



d) Success criteria
MS_A1 is able to establish a Public Emergency Call with unknown TMSI and IMSI in VLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.51 Public Emergency Call With SIM (roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call With SIM.


Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1

c) Test procedure

Call.
nal.


Call.
nal.

d) Success criteria
MS_A1 and MS_B1 are able to establish a Public Emergency Call. The MSISDN of the originator
was displayed on PSAP (Public Safety Answering Point) operator terminal.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.52 Public Emergency Call Without SIM (roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call Without SIM.

MS_A1 has NO SIM.
MS_B1 has NO SIM.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

Call.
terminal.
Call.
terminal.

d) Success criteria
MS_A1 and MS_B1 are able to establish a Public Emergency Call without SIM.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.1.53 Public Emergency Call with TMSI and IMSI unknown in VLR (roaming case)


2.2.1
2.2.5
9.3.2
2.2.1

a) Purpose
Verify Public Emergency Call With SIM, but the TMSI and IMSI are unknown in VLR.

HLR settings of MS_A1 do NOT allow it to perform roaming in network B.
HLR settings of MS_B1 do NOT allow it to perform roaming in network A.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

Call.
terminal.
3) MS_A1 close the call. Emergency call is released. All related re-
Call.
terminal.
6) MS_B1 close the call. Emergency call is released. All related re-

d) Success criteria
MS_A1 and MS_B1 are able to establish a Public Emergency Call with unknown TMSI and IMSI
in VLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2 Functional Addressing
General Purpose
Verify the registration, deregistration, interrogation and forced deregistration of FN in home net-
work and also in roaming cases.

5.2.1 Register of a FN (non-roaming case)

2.5.1
11.2.1.1
11.3.2.1
11.3.2.3
2.4.1
2.5.1
11.3.2
11.3.5
11.3.7

a) Purpose
Verify registration of FN in different ways.
Verify the registration of 10 FN within 30 seconds.

Step 1: Register of a FN in different ways
Step 2: Register of 10 FN

Preprovisioning of FN or Dynamic FN creation
All FN to register are unregistered.
Protocol analyzer is configured to trace A-interface to verify the transmitting USSD string from
and to the network on the MAP interface.



Network A

MS_A1

c) Test procedure

Step 1: Register of a FN in different ways
1) MS_A1 registers a FN_1, CT2, FC01 by
sending an USSD string
**214*<IC_A+FN_1>***#.

The MAP interface contains the USSD
string as sent from MS.
The USSD outcome code 01 which
means Follow Me activated is displayed
on MS A1.
Alternatively MS converts the outcome
code in an appropriate text message.
2) Verify the corresponding entry of FFN data-
base.
An entry of mapping between FN_1 and
MS_A1 exists in FFN database.
using the mobile menu.

on MS A1.
4) Verify the corresponding entry of FFN data-
base.
MS_A1 exists in FFN database.

Step 2: Register of 10 FN
1)
Define 10 FN to register. 10 FN to register are defined.


2)
MS_A1 sends the first USSD message for
registration either by typing it manually or by
using the terminal menu.
When sending the USSD message, start the
stop watch simultaneously.
The stop watch runs.
3)
Observe the display of MS_A1.
When MS_A1 displays the confirmation of
registration (outcome code or text mes-
sage), stop the stop watch.
MS_A1 displays the confirmation of Regis-
tration.
The stop watch stops.
4)
Repeat 2) and 3) until all 10 FN registered. MS_A1 registered to 10 FN.
5)
Verify the recorded duration of the stop
watch.
The measured time does not exceed 30
seconds.
6)
Verify the corresponding entries of FFN
database.
All 10 entries of mapping between FN and
MS_A1 exist in FFN database.

d) Success criteria
Registration of FN works in different ways.
Registration of 10 FN within 30 seconds is possible.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.2 Register 3 functional numbers to one user (non-roaming case)

11.2.1.4 2.4.1
2.5.1

a) Purpose
Verify the registration of 3 FN to one and the same user is possible.

Preprovisioning of FN or Dynamic FN Creation.

Network A

MS_A1

c) Test procedure

**214*<IC_A+FN_1>***#.

means FollowMe activated is displayed
on MS A1.


**214*<IC_A+FN_2>***#.

on MS_A1.
**214*<IC_A+FN_3>***#.

on MS_A1.

d) Success criteria
MS_A1 is registered to 3 different functional numbers.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.3 Register 3 functional numbers to one user (roaming case)

11.2.1.4 2.4.1
2.5.1

a) Purpose
Verify the registration of 3 FN to one and the same user is possible.

Step 1: Registration of 3 FN to one and the same user in roaming network B.
Step 2: Registration of 3 FN to one and the same user in roaming network A.

Preprovisioning of FN or Dynamic FN Creation.

Network A Network B

MSC_A1 MSC_B1
MS_B2 MS_A2

c) Test procedure


1) MS_A2 registers a FN_1, CT2, FC01
by sending an USSD string
**214*<IC_B+FN_1>***#.

The USSD outcome code 01 which means
FollowMe activated is displayed on MS_A2.

Alternatively MS converts the outcome code in
an appropriate text message.
**214*<IC_B+FN_2>***#.

Follow Me activated is displayed on MS_A2.

**214*<IC_B+FN_3>***#.



1) MS_B2 registers a FN_1, CT2, FC01
**214*<IC_A+FN_1>***#.

FollowMe activated is displayed on MS_B2.

**214*<IC_A+FN_2>***#.

Follow Me activated is displayed on MS_B2.

**214*<IC_A+FN_3>***#.

Follow Me activated is displayed on MS_B2.


d) Success criteria
MS_A2 is registered to 3 different functional numbers of the network B and MS_B2 is registered
to 3 different functional numbers of the network A.


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.4 Registration of an unknown FN fails (non-roaming case)

11.3.2.4 2.4.1
2.5.1
11.3.8
11.3.9

a) Purpose
Verify the registration of a FN which is not preconfigured in the database fails.

Preprovioning of FN: the test configuration does not allow the dynamic FN creation.
FN_9 to register is not data filled in FA database.

c) Test procedure

1) MS_A1 sends an USSD string
**214*<IC_A+FN_9>***#.

means Unknown Remote Party is dis-
played on MS_A1.

d) Success criteria
Registration of a FN which is not preconfigured in the database fails.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.5 Deregistration of a FN (non-roaming case)

2.5.1
11.3.3.1
11.3.3.3
11.3.3.5
2.4.1
2.5.1
11.3.2
11.3.5
11.3.7
11.3.10
11.3.12

a) Purpose
Verify the deregistration of a FN.
Verify the deregistration of 10 FN within 30 seconds.

Step 1: Deregister of a FN in different ways
Step 2: Deregister of 10 FN

Step 1: MS_A1 is registered to at least 2 FN (e.g. FN_1 and FN_2).
Corresponding entries exist in FFN database.
Step 2: MS_A1 is registered to 10 FN.
Corresponding entries exist in FFN database.

Network A

MS_A1 (FN_1, FN_2)


c) Test procedure

Step 1: Deregister of a FN in different ways
1) MS_A1 deregisters a FN by sending an
USSD string ##214*<IC_A+FN_1>***#.

means Follow Me deactivated is dis-
played on MS_A1.
MS_A1 is still registered to FN_2.
2) Verify FFN database. The mapping between FN_1 and MS_A1
does no more exist or is labelled as de-
registered in FFN database.
3) MS_A1 deregisters its still registered FN_2
by using the mobile menu.

played on MS_A1.
does no more exist or is labelled as de-

Step2: Deregister of 10 FN
1) Define 10 FN to deregister. 10 FN to deregister are defined.
2) MS_A1 sends the first USSD message for
deregistration either by typing it manually or
by using the terminal menu.

3) Observe the display of MS_A1.
deregistration (outcome code or text mes-
MS_A1 displays the confirmation of dereg-
istration.
4) Repeat 2) and 3) until all 10 FN deregis-
tered.
MS_A1 deregistered to 10 FN.


5) Verify the recorded duration of the stop
watch.
seconds.
6) Verify FFN database. The mappings between the 10 FN and
MS_A1 no more exist or labelled as de-

d) Success criteria
Deregistration of FN works in different ways.
Deregistration of 10 FN within 30 seconds is possible.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.6 Deregistration of a FN fails (non-roaming case)

11.3.3.1 2.4.1
2.5.1
11.3.10
11.3.12

a) Purpose
Verify the deregistration of a FN by a non-owner fails.

MS_A1 is registered to FN_1.
A corresponding entry exists in FFN database.

Network A

MS_A1 (FN_1)
MS_A2

c) Test procedure



##214*<IC_A+FN_1>***#.

means Remote Party not registered to
this MSISDN is displayed on MS_A2.
MS_A1 is still registered to FN_A1.
still exists in FFN database.

d) Success criteria
Deregistration of a FN by a non-owner fails.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.7 Forced Deregistration of a FN (non-roaming case)

11.3.3.4 2.4.1
2.5.1
11.3.7
11.3.8i

a) Purpose
Verify the forced deregistration of a FN.

MS_A1 has HLR subscription to perform Forced Deregistration.

Network A

MS_A1
MS_A2 (FN_1)

c) Test procedure

1) MS_A1 performs an interrogation of the
FN_1 to forced-deregister by sending USSD
string *#214*<IC_A+FN_1>***# or by us-
ing Terminal Menu.

The USSD response for successful inter-
rogation is displayed. It contains the out-
come code 03 and the MSISDN digits.
2) MS_A1 performs a forced deregistration of The USSD outcome code 02 which


the FN to which MS_A2 registered by send-
ing USSD string ##214*<IC_A+FN to
forced-deregister>*88*<MSISDN of
MS_A2>*# or by using Terminal Menu.

played on MS_A1.

3) Verify that the FFN_A sends Forced Dereg-
istration Notification to MS_A2.
FFN_A logged the Forced Deregistration
Notification sent to MS_A2.
4) Verify that MS_A2 sends an Interrogation
invoked by the implementation of MS-
feature, receives a related notification and
erases the FN_1.

MS_A2 erases FN_1 forced deregistered.
Note: This is a MS-Feature, not a network-
feature.

d) Success criteria
Forced deregistration of a FN works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.8 Forced Deregistration of a FN fails (non-roaming case)

11.3.3.4 2.4.1
2.5.1
11.3.7
11.3.8i

a) Purpose
Verify the forced deregistration of a FN fails in case of missing supervisor CoR.

MS_A2 does not have the HLR subscription to perform Forced Deregistration.

Network A

MS_A1(FN_1)
MS_A2

c) Test procedure

ing Terminal Menu.

come code 03 and the MSISDN digits.
2) MS_A2 performs a forced-deregistration by The USSD outcome code 22 which


sending USSD string ##214*<IC_A+FN to

means Unauthorised request is dis-
played on MS_A2.

3) Verify that MS_A1 still registered to FN_1. MS_A1 displays its identity, FN_1.
A corresponding entry exists in FFN data-
base.

d) Success criteria
Forced Deregistration of a FN fails in case of missing supervisor CoR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.9 Class of Registration (CoR) check (non-roaming case)

2.4.1
2.5.1
11.3.6

a) Purpose
Verify the CoR check is performed on registration of a FN.

Step 1: Follow Me Subscription check for a registration
Step 2: Follow Me Subscription- different CoR check for a registration

HLR Provisioning Tool is available.
FN_7 is not registered.
MS_A3 does not have the HLR_A subscription to perform Follow Me Services.
CoR of MS_A2 has been temporarily changed from ABCD to ABD on HLR_A.

Network A

MS_A3

c) Test procedure


Step 1: Follow Me Subscription check for a registration
**214*<IC_A+FN_8>***# for a registration.

played on MS_A3.

Step 2: Follow Me Subscription- different CoR check for a registration
**214*<IC_A+FN_7>***# for a registration.

played on MS_A2, as the CoR C is re-
quired to register to any FN with FC 10.
2) Undo the CoR change for MS_A2. MS_A2 gets the initial CoR, ABCD again.
3) Repeat 1) The USSD outcome code 01 which
on MS_A2.
exists in FFN database.

d) Success criteria
CoR check is performed on registration of a FN.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.10 Registration of a FN (roaming case)
5.2.10.1 Registration of a FN (roaming case Roaming does not affect registered FN)

11.2.1.1
11.2.1.7
11.2.1.8
11.3.2.1
11.3.2.3
11.3.4
2.4.1
2.5.1
11.3.2
11.3.7
11.3.14
11.3.17
11.6

a) Purpose
Verify FN which is registered in home network is still valid in roaming network.
Verify the registration of 10 FN within 30 seconds.

Step 1: Register of a FN in Home Network (A) and verify its validness after Network change (B)
Step 2: Register of a FN in Home Network (B) and verify its validness after Network change (A)
Step 3: Register of 10 FN in Home Network (A), take time measurement and verify FN-validness
after Network change (B)
Step 4: Register of 10 FN in Home Network (B), take time measurement and verify FN-validness
after Network change (A)

Test configuration for step 1, 2, 3 and 4
All FNs to register are defined and unregistered.
MS-Feature which performs automatic registration of train number after network change has to be
deactivated if it has been implemented.



Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1

c) Test procedure

Step 1: Register of a FN in Home Network (A) and verify its validness after Network change (B)
1) MS_A1 registers a FN by sending an USSD
string **214*<IC_A+FN_1>***#.

on MS_A1.
2) Change the serving cell of MS_A1 to
cell_B1.
Cell_B1 of Network B is now the serving
Network of MS_A1.
3) Verify that MS_A1 still registered to FN_1. MS_A1 still displays the identity FN_1.
MS_A1 exists in FFN database of network
A.



Step 2: Register of a FN in Home Network (B) and verify its validness after Network change (A)
1) MS_B1 registers a FN by sending an USSD
string **214*<IC_B+FN_8>***#.

on MS_B1.
2) Change the serving cell of MS_B1 to
cell_A1.
Cell_A1 of Network A is now the serving
Network of MS_B1.
3) Verify that MS_B1 still registered to FN_8. MS_B1 still displays the identity FN_8.
MS_B1 exists in FFN database of network
B.

Step 3: Register of 10 FN in Home Network (A), take time measurement and verify FN-
validness after Network change (B)
1) MS_A1 sends the first USSD message for
2) Observe the display of MS_A1.
MS_A1 displays the confirmation of Regis-
tration.
3) Repeat 1) and 2) until all 10 FN registered. MS_A1 registered to 10 FN.
watch.
seconds.
5) Verify the corresponding entries of FFN
database of network A.
All 10 entries of mappings between FN
and MS_A1 exist in FFN database of net-
work A.
6) Change the serving cell of MS_A1 to
cell_B1.
Cell_B1 of Network B is now the serving
Network of MS_A1.
7) Verify that MS_A1 still registered to all 10
FN.
MS_A1 still displays its last registered
identity FN.
FFN database of network A contains the
entries of mappings between 10 FNs and
MS_A1.


Step 4: Register of 10 FN in Home Network (B), take time measurement and verify FN-
validness after Network change (A)
1) MS_B1 sends the first USSD message for
2) Observe the display of MS_B1.
When MS_B1 displays the confirmation of
MS_B1 displays the confirmation of Regis-
tration.
3) Repeat 1) and 2) until all 10 FN registered. MS_B1 registered to 10 FN.
watch.
seconds.
5) Verify the corresponding entries of FFN
database of network B.
All 10 entries of mappings between FN
and MS_B1 exist in FFN database of net-
work B.
6) Change the serving cell of MS_B1 to
cell_A1.
Cell_A1 of Network A is now the serving
Network of MS_B1.
7) Verify that MS_B1 still registered to all 10
FN.
MS_B1 still displays its last registered
identity FN.
FFN database of network B contains the
entries of mappings between 10 FNs and
MS_B1.

d) Success criteria
All FN which are registered in home network are still valid in roaming network.
Registration of 10 FN does not take more than 30 seconds.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.10.2 Registration of a FN (roaming case Registration of a FN after network change)

a) Purpose
Verify the registration of a FN in a roaming network works.

Step 1: Register of a FN in roaming Network B.
Step 2: Register of a FN in roaming Network A.

MS_A1 roams in network B.
MS_B1 roams in network A.
MS feature which performs automatic registration of train number after network change has to be
deactivated if it has been implemented.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1

c) Test procedure


Step 1: Register of a FN in roaming Network B.
1) MS_A1 registers a FN by sending an USSD
string **214*<IC_B+FN_1>***#.

on MS_A1.
2) Verify the registration. MS_A1 displays the identity FN_1.
B.

Step 2: Register of a FN in roaming Network A.
1) MS_B1 registers a FN by sending an USSD
string **214*<IC_A+FN_8>***#.

on MS_B1.
2) Verify the registration. MS_B1 displays the identity FN_8.
A.

d) Success criteria
Registration of a FN in a roaming network works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.11 Registration of a unknown FN fails (roaming case)

11.3.2.4 2.4.1
2.5.1
11.3.8
11.3.9

a) Purpose
Verify the registration of a FN which is not preconfigured in the database fails.

Step 1: Registration of an unknown FN in roaming network B.
Step 2: Registration of an unknown FN in roaming network A.

Preprovioning of FN.
FN_9 to register is not data filled in FA database in network B.
FN_4 to register is not data filled in FA database in network A.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1


c) Test procedure

Step 1: Registration of an unknown FN in roaming network B.
**214*<IC_B+FN_9>***#.

played on MS_A1.
code in a text message like FN unknown.

Step 2: Registration of an unknown FN in roaming network A.
2) MS_B1 sends an USSD string
**214*<IC_A+FN_4>***#.

played on MS_B1.
code in a text message like FN unknown.

d) Success criteria
Registration of a unknown FN fails.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.12 Check of the storage of CT2 Number and its destination in the current EIRENE net-
work.

9.2.3

a) Purpose
Verify the storage of CT2 Number and its associated MSISDN numbers in the same routing data-
base, which is the database of the GSM-R network in which the train is currently operating.

Step 1: Registration of a FN after network change, check of FFN database in roaming network B.
Step 2: Registration of a FN after network change, check of FFN database in roaming network B.

MS_A1 is registered to IC_A, FN_1.
MS_B1 is registered to IC_B, FN_8.

Network A Network B

MSC_A1 MSC_B1
MS_A1 (IC_A, FN_1) MS_B1 (IC_B, FN_8)

c) Test procedure


Step 1: Registration of a FN after network change, check of FFN database in roaming net-
work B.
1) MS_A1 roams in network B, registers to
IC_B, FN_1 by sending an USSD string
**214*<IC_B+FN_1>***# or using the ter-
minal menu.

on MS_A1.
2) Verify the according entry in FFN database
of network B.
The corresponding entry exists in FFN

Step 2: Registration of a FN after network change, check of FFN database in roaming net-
work A.
1) MS_B1 roams in network A, registers to
IC_A, FN_8 which is the same train number
but in the currently operating network by
**214*<IC_A+FN_8>***# or using the ter-
minal menu.
on MS_B1.
2) Verify the according entry in FFN database
of network A.

d) Success criteria
The storage of CT2 Number and its associated MSISDN numbers is available in the same routing
database in which the train is currently operating.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.13 Check of the storage of CT3 Number and the according destination in the home EI-
RENE network.

9.2.5

a) Purpose
Verify the storage of CT3 Number and associated MSISDN number as an entry in the routing da-
tabase of the home GSM-R network of the engine at any time.

An engine number IC_A, FN_2 (CT3 /FC01) is associated to the MSISDN number of MS_A1.

Network A Network B

MSC_A1 MSC_B1
MS_A1

c) Test procedure

1) Verify the entry of IC_A, FN_2 in FFN data-
base of network A.

An entry of mapping between IC_A, FN_2
and the MSISDN of MS_A1 as destination
number exists in FFN database of network
A.
2) MS_A1 roams in network B. Cell_B1 of Network B is serving Network
of MS_A1.


3) Repeat 1) An entry of mapping between IC_A, FN_2
number still exists in FFN database of
network A.
4) MS_A1 switches off (see purpose at any
time.
MS_A1 switched off.
network A.

d) Success criteria
The storage of CT3 Number and associated MSISDN number as an entry is available in the rout-
ing database of the home GSM-R network of the engine at any time.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.14 Check of the storage of CT4 Number and its destination in the home EIRENE net-
work.

9.2.6

a) Purpose
Verify the storage of CT4 Number and associated MSISDN number as an entry in the routing da-
tabase of the home GSM-R network of the coach at any time.

An engine number IC_A, FN_3 (CT4 /FC01) is associated to the MSISDN number of MS_A2.

Network A Network B

MSC_A1 MSC_B1
MS_A2

c) Test procedure

base of network A.

A.
2) MS_A2 roams in network B. Cell_B1 of Network B is serving Network
of MS_A2.


network A.
4) MS_A2 switches off (see purpose at any
time).
MS_A2 switched off.
network A.

d) Success criteria
The storage of CT4 Number and associated MSISDN number as an entry is available in the rout-
ing database of the home GSM-R network of the coach at any time.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.15 Check of the storage of CT6 and CT7 Numbers and their destinations in the home
EIRENE network.

9.2.8

a) Purpose
Verify the storage of CT6 and CT7 Number and associated MSISDN numbers as entries in the
routing database of the home GSM-R network.

CT_A1 is associated to IC_A, FN_11.

Network A

CT_A1 (IC_A, FN_11)
MS_A1

c) Test procedure

1) Verify the entry of IC_A, FN_11 in FFN da-
tabase of network A.

An entry of mapping between IC_A,
FN_11 and the MSISDN of CT_A1 as des-
tination number exists in FFN database of
network A.


2) MS_A1 registers to IC_A, FN_4. (CT6
/FC5yxx)
on MS_A1.
base of network A.

A.

d) Success criteria
Storages of CT6 and CT7 Number and associated MSISDN numbers as entries are available in
the routing database of the home GSM-R network.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.16 Registration failures --> outcome code 61 [remote party already registered] (non-
roaming case)

9.2.2.2
9.2.3.2
11.2.1.5
11.2.2.1
11.3.2.5
2.4.1
2.5.1
9.2.1
11.3.8
11.3.9

a) Purpose
Verify a registration attempt to an already registered functional number fails.

The corresponding entry exists in FFN database of network A.

Network A

MS_A1 (IC_A, FN_1)
MS_A2

c) Test procedure

1) Make sure that MS_A1 is registered to
IC_A, FN_1.
MS A1 displays the functional identity of
FN_1.


**214*<IC_A+FN_1>***#.

means remote party already registered is
displayed on MS_A2.
3) MS_A1 is still registers to FN_1 There is no change of the displayed func-
tional identity of FN_1.
The corresponding entry still exists in FFN

d) Success criteria
MS_A2 cannot register to an already registered functional number.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.17 Registration failures --> outcome code 61 [remote party already registered] (roam-
ing case)

9.2.2.2
9.2.3.2
11.2.1.5
11.2.2.1
11.3.2.5
2.4.1
2.5.1
9.2.1
11.3.8
11.3.9

a) Purpose
Verify a registration attempt to an already registered functional number fails.

Step 1: Registration of a FN which is already registered to another user fails in roaming network A.
Step 2: Registration of a FN which is already registered to another user fails in roaming network B.

The corresponding entries exist in FFN database of network A and B.

Network A Network B

MSC_A1 MSC_B1
MS_B2 MS_A2


c) Test procedure

Step 1: Registration of a FN which is already registered to another user fails in roaming
network A.
1) MS_B2 which roams in network A, sends an
USSD string **214*<IC_A+FN_5>***#.

displayed on MS_B2.
2) MS_A1 is still registers to FN_5. There is no change of the displayed func-
tional identity of FN_5 on MS_A1.
The corresponding entry still exists in FFN

Step 2: Registration of a FN which is already registered to another user fails in roaming
network A.
1) MS_A2 which roams in network B, sends an
USSD string **214*<IC_B+FN_1>***#.

displayed on MS_A2.
2) MS_B1 is still registers to FN_1 There is no change of the displayed func-
tional identity of FN_1 on MS_B1.

d) Success criteria
MS_A2 and MS_B2 cannot register to an already registered functional number.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.18 Deregistration of a FN (roaming case)

11.2.1.7
11.2.1.8
11.3.3.1
11.3.3.3
11.3.3.5
2.4.1
2.5.1
11.3.2
11.3.7
11.3.10
11.3.12
11.3.14
11.3.17
11.6

a) Purpose
Verify the deregistration of FN in roaming network which is a part of re-registration.
Verify the deregistration of 10 FN within 30 seconds.

Step 1: Deregistration of a FN in roaming network B.
Step 2: Deregistration of a FN in roaming network A.
Step 3: Deregistration of 10 FN in roaming network B with taking time measurement.
Step 4: Deregistration of 10 FN in roaming network A with taking time measurement.

MS_A1 roams in network B and is still registered to a FN in network A
MS_B1 roams in network A and is still registered to a FN in network B.
The corresponding entries exist in FFN database of network A and B respectively.



Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1

c) Test procedure

Step 1: Deregistration of a FN in roaming network B.
1) MS_A1 deregisters its FN by sending an
USSD string ##214*<IC_A+FN_1>***#.

played on MS_A1.

Step 2: Deregistration of a FN in roaming network A.
1) MS_B1 deregisters its FN by sending an
USSD string ##214*<IC_B+FN_1>***#.

played on MS_B1.



MS_A1 roams in network B and is still registered to 10 FN in network A
MS_B1 roams in network A and is still registered to 10 FN in network B.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1

Step 3: Deregistration of 10 FN in roaming network B with taking time measurement.
1)
MS_A1 sends the first USSD message for
2)
Observe the display of MS_A1.
MS_A1 displays the confirmation of De-
registration.
3)
Repeat 1) and 2) until all 10 FN deregis-
tered.
MS_A1 deregistered to 10 FN.
4)
Verify the recorded duration of the stop
watch.
seconds.
5)
Verify the deregistration. MS_A1 does not display any of the FN
deregistered above.
All 10 above entries of mappings between
FN and MS_A1 no more exist in FFN da-
tabase of network A.


Step 4: Deregistration of 10 FN in roaming network A with taking time measurement.
1) MS_B1 sends the first USSD message for
2) Observe the display of MS_B1.
When MS_B1 displays the confirmation of
MS_B1 displays the confirmation of De-
registration.
3) Repeat 1) and 2) until all 10 FN deregis-
tered.
MS_B1 deregistered to 10 FN.
watch.
seconds.
5) Verify the deregistration. MS_B1 does not display any of the FN
deregistered above.
All 10 above entries of mappings between
FN and MS_B1 no more exist in FFN da-
tabase of network B.

d) Success criteria
Deregistration FN in roaming network works.
Deregistration of 10 FNs in roaming network neither do nor take more than 30 seconds.

e) Test result
Remarks
Attachments
(log / trace file)

Signature


5.2.19 Deregistration of a FN fails (roaming case)

11.2.1.7
11.2.1.8
11.3.3.1

2.4.1
2.5.1
11.3.10
11.3.12

a) Purpose
Verify deregistration of a FN to which another MS registered fails.

Step 1: Deregistration of a FN to which another MS registered in roaming network B fails.
Step 2: Deregistration of a FN to which another MS registered in roaming network A fails.

MS_A1 roams in network B and is not registered to IC_A, FN_9.
MS_B2 roams in network A and is not registered to IC_B, FN_1.

Network A Network B

MSC_A1 MSC_B1
MS_B2 MS_A1


c) Test procedure

Step 1: Deregistration of a FN to which another MS registered in roaming network B fails.
##214*<IC_B+FN_1>***# to deregister the
FN to which MS_B1 is registered.
means Remote party not registered to
this MSISDN is displayed on MS_A1.
2) Verify that MS_B1 is still registered to its
FN.
MS_B1 displays its identity FN_1.
The entry of mapping between FN_1 and
MS_B1 still exists in FFN database of
network B.

Step 2: Deregistration of a FN to which another MS registered in roaming network A fails.
##214*<IC_A+FN_9>***# to deregister the
FN to which MS_A2 is registered.
means Remote party not registered to
this MSISDN is displayed on MS_B2.

2) Verify that MS_A2 is still registered to its
FN.
MS_A2 displays its identity FN_9.
MS_A2 still exists in FFN database of
network A.

d) Success criteria
Deregistration of a FN to which another MS registered fails, also in roaming case.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.20 Forced Deregistration of a FN (roaming case)

11.3.3.4 2.4.1
2.5.1
11.3.8i
11.3.17
11.6

a) Purpose
Verify the forced deregistration of a FN in a roaming case.

Step 1: Forced Deregistration of a FN to which a roaming MS registered (network B).
Step 2: Forced Deregistration of a FN to which a roaming MS registered (network A).

MS_A2 is registered to IC_B, FN_1.
MS_B2 is registered to IC_A, FN_8.

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_B1
MS_B2 (IC_A, FN_8) MS_A2 (IC_B, FN_1)


c) Test procedure

Step 1: Forced Deregistration of a FN to which a roaming MS registered (network B).
1) MS_B1 performs an interrogation of the
string *#214*<IC_B+FN_1>***# or by us-
ing Terminal Menu.

come code 03 and the MSISDN digits of
MS_A2.
2) MS_B1 forced deregisters the FN to which
MS_A2 has registered by sending USSD
string ##214*<IC_B+FN to forced-
deregister>*88*<MSISDN of MS_A2>*# or
by using Terminal Menu.
played on MS_B1.
3) Verify that the FFN_B sends Forced Dereg-
istration Notification to MS_A2.
FFN_B logged the Forced Deregistration
Notification sent to MS_A2.
4) Verify that MS_A2 sends an Interrogation
erases the FN_1.
MS_A2 erases FN_1 forced deregistered.
Note: This is a MS-feature, not a network-
feature.

Step 2: Forced Deregistration of a FN to which a roaming MS registered (network A).
ing Terminal Menu.

MS_B2.
2) MS_A1 forced deregisters the FN to which
MS_B2 has registered by sending USSD
string ##214*<IC_A+FN to forced-
deregister>*88*<MSISDN of MS_B2>*# or
by using Terminal Menu.
played on MS_A1.
3) Verify that the FFN_A sends Forced Dereg-
istration Notification to MS_B2.
FFN_A logged the Forced Deregistration
Notification sent to MS_B2.
4) Verify that MS_B2 sends an Interrogation
erases the FN_8.
MS_B2 erases FN_8 forced deregistered.
Note: This is a MS-feature, not a network-
feature.


d) Success criteria
Forced deregistration of a FN in a roaming case works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.21 Forced Deregistration of a FN fails due to a missing supervisor CoR (roaming case)

11.3.3.4 2.4.1
2.5.1
11.3.8i

a) Purpose
Verify the forced deregistration of a FN fails in case of missing supervisor CoR.

Step 1: Forced Deregistration of a FN to which a roaming MS registered fails due to missing CoR
(network B).
Step 2: Forced Deregistration of a FN to which a roaming MS registered fails due to missing CoR
(network A).

MS_A1 is registered to IC_B, FN_1.
MS_B1 is registered to IC_A, FN_4.

Network A Network B

MSC_A1 MSC_B1
MS_A2 MS_B2


c) Test procedure

Step 1: Forced Deregistration of a FN to which a roaming MS registered fails due to miss-
ing CoR (network B).
1) MS_B2 performs an interrogation of the
string *#214*<IC_B+FN_1>***# or by us-
ing Terminal Menu.

MS_A1.
2) MS_B2 initiates a forced deregistration of
the FN to which MS_A1 has registered by
sending USSD string ##214*<IC_B+FN to
Note: MS_B2 has no subscription to super-
visor CoR.
means Unauthorized request is dis-
played on MS_B2.

3) Verify that MS_A1 still registered to IC_B,
FN_1.
MS_A1 displays its identity FN_1.
MS_A1 still exists in FFN database of
network B.

Step 2: Forced Deregistration of a FN to which a roaming MS registered fails due to miss-
ing CoR (network A).
MS_A2 performs an interrogation of the
ing Terminal Menu.

MS_B1.

2) MS_A2 initiates a forced deregistration of
the FN to which MS_B1 has registered by
sending USSD string ##214*<IC_A+FN to
MS_B1>*# or by using Terminal Menu.
Note: MS_A2 has no subscription to super-
visor CoR.
played on MS_A2.



3) Verify that MS_B1 still registered to IC_A,
FN_4.
MS_B1 displays its identity FN_4.
MS_B1 still exists in FFN database of
network A.

d) Success criteria
Forced deregistration of a FN fails in case of missing supervisor CoR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.22 Class of registration (CoR) check (roaming case)

2.4.1
2.5.1
11.3.6

a) Purpose
Verify the CoR check is performed on registration of a FN.

Step 1: Registration of a FN first without and after with CoR Subscription in roaming network B.
Step 2: Registration of a FN first without and after with CoR Subscription in roaming network A.

HLR Provisioning Tool is available.

Network A Network B

MSC_A1 MSC_B1
MS_B3 MS_A3

c) Test procedure


Step 1: Registration of a FN first without and after with CoR Subscription in roaming net-
work B.
**214*<IC_B+FN_8>***#.

Note: MS_A3 has no subscription to per-
form any Follow Me service.
played on MS_A3.
2) Assign MS_A3 a subscription to Follow Me
Service CoR A on HLR_A temporarily.
HLR_A subscription allows the MS_A3 to
register only the Engine/Train cab-radio
basic functions.
3) Repeat 1)

on MS_A3.
4) Verify the registration. MS_A3 displays its identity FN_8.
B.
5) Undo the CoR change of 2). Follow Me Service CoR A for MS_A3 is
detracted on HLR_A again.

Step 2: Registration of a FN first without and after with CoR Subscription in roaming net-
work A.
**214*<IC_A+FN_8>***#.

Note: MS_B3 has no subscription to per-
form any Follow Me service.
played on MS_B3.
2) Assign MS_B3 a subscription to Follow Me
Service CoR A on HLR_B temporarily.
HLR_B subscription allows the MS_B3 to
register only the Engine/Train cab-radio
basic functions.
3) Repeat 1)

on MS_B3.


4) Verify the registration. MS_B3 displays its identity FN_8.
A.
5) Undo the CoR change of 2). Follow Me Service CoR A for MS_B3 is
detracted on HLR_B again.

d) Success criteria
CoR check is performed on registration of a FN.

e) Test result

Remarks
Attachments
(log / trace file)



5.2.23 FFN recovery

11.3.2.6 11.4.1

a) Purpose
Verify the FFN database can be recovered after a system failure.

Step 1: FFN Database recovery in case of geo-redundancy.
Step 2: FFN Database recovery in case of non-geo-redundancy.

For step 1: The (geo)redundant FFN databases are available.
For step 2: The only FFN database is available.

c) Test procedure

Step 1: FFN Database recovery in case of geo-redundancy.
1) Stop database replication between
(geo)redundant SCP databases.
The FFN database replication feature be-
tween (geo)redundant SCP databases is
disabled.
2) Perform a registration on one active SCP
database.

The registration creates or updates the
according entry in the active FFN data-
base.
3) Redirect SS7 traffic to other SCP and if
necessary activate other SCP and its data-
base.
Newly active database does not have the
registration made in 2)
4) Make a call to FN registered in 2). The call is not successful.


5) Activate database replication feature be-
tween the (geo)redundant SCP databases.
The FFN database replication feature be-
tween (geo)redundant FFN databases is
enabled.
6) In case the FFN databases do not synchro-
nise automatically, perform a manual data-
base synchronisation.
The (geo)redundant FFN databases are
synchronised.
7) Make a call to FN registered in 2) The call is now successful.

Step 2: FFN Database recovery in case of non-geo-redundancy.
1) Make a backup of FFN database as in-
structed in the system manual.
A complete copy of FFN database has
been made.
2) Simulate the failure of FFN, e.g. by power
cut or disconnecting of SS7 interface(s) to
FFN.
FFN is not available in the network.
3) Perform registrations. Registrations are not possible.
4) Undo 2). FFN is available again.
5) Restore the FFN database by using the
database backup in 1).
FFN database contains data from the time
point of 1).
6) Perform registrations. Registrations are now possible.
7) Make a call to FN registered in 6) The call is now successful.

d) Success criteria
FFN database can be recovered after a system failure.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.24 FA Call Successful Call (national call)

3.2.3
9.2.1.1
9.2.4.1
9.2.4.2
9.2.4.3
9.2.4.4
2.4.3
11.2.1.10
11.2.2.2
11.2.3.1

2.4.1
2.5.1
9.2.2
9.2.4
9.2.7
9.4.1
9.5.2
9.5.3
9.5.4
9.6.2
9.A2
9.A3
11.2.3
11.5.1
11.5.2
11.5.4
11.5.5

a) Purpose
Verify FA calls to different Call Types (CT).

Step 1: CT2 /FC01 calls CT2 /FC08.
Step3: CT2 /FC01 calls CT4 /FC01.
Step4: CT3 /FC01 calls CT6 /FC5yxx.

Test configuration for all steps
Access Matrix which controls calls from and to FN is disabled. This can be done either by switch-
off of Access Matrix or by setting all calls to Yes temporarily.
Protocol analyzer is configured to trace A-interface to verify the Setup message.
For the Step 1, MS_A1 is registered to IC_A, FN_1 and MS_A2 is registered to IC_A, FN_6.
The corresponding entries exist in FFN database of network A.
All FN to register in the following calls are unregistered.


Network A

MS_A1 (FN_1)
MS_A2 (FN_6)

c) Test procedure

Step1: CT2 /FC01 calls CT2 /FC08
1) MS_A1 initiates a call to FN_6. The outgoing call is displayed on MS_A1.
2) Verify that the function related SA (Sub
Address) derived from the FN, using
ODD (originally dialled digits) is provided
in the Setup Message.
Protocol analyzer shows the corresponding
Setup Message including the correct SA.
The incoming call is displayed on MS_A2.
3) MS_A2 accepts the call. The PTP call between MS_A1 and MS_A2 is
4) Verify Presentation of FN (PFN) and
check the number displayed on both call-
ing- and called party.
MS_A1 displays the function of the connected
MS_A2 and MS_A2 displays the function of
MS_A1.
5) MS_A2 closes the call. Call is released.
6) MS_A1 initiates a call to FN_6 by pre-
ceding the Breakout Code (BC) 900 and
IC_A.
The outgoing call is displayed on MS_A1.
7) Repeat 3) to 6). See above.


1) MS_A1 registers to IC_A, FN_2.


2) MS_A1 initiates a call to FN_6. The outgoing call is displayed on MS_A1.
5) Verify PFN and check the number dis-
played on both calling- and called party.
MS_A1.
IC_A.



2) MS_A1 initiates a call to FN_3. The outgoing call is displayed on MS_A1
MS_A1.


IC_A.

Step4: CT3 /FC01 calls CT6 /FC5yxx.

2) MS_A1 whose last registered FN is FN_2
(CT3 /FC01) initiates a call to FN_4.
MS_A1.
IC_A.

1) IC_A, FN_11 is assigned to CT_A1.

CT_A1 displays its identity FN_11.
2) CT_A1 initiates a call to FN_1. The incoming call is displayed on MS_A1.
3) MS_A1 accepts the call. The PTP call between CT_A1 and MS_A1 is
CT_A1 and CT_A1 displays the function of
MS_A1.
6) CT_A1 initiates a call to FN_1 by preced-
ing the Breakout Code (BC) 900 and
IC_A.
The outgoing call is displayed on CT_A1.



d) Success criteria
All FA calls are successfully connected. The Presentation Of Functional Number (PFN) was cor-
rect in all calls.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.25 FA Call Call is not completed (national call)

EN 301515

a) Purpose
Verify that a call to an unregistered FN can not be completed.

Access Matrix which controls calls from and to FN is disabled. This can be done either by switch-
off of Access Matrix or by setting all calls to Yes temporarily.
For the Step 1, MS_A1 is registered to IC_A, FN_1.
The corresponding entry exists in FFN database of network A.
None of the used MS is registered to FN_7.

Network A

MS_A1 (FN_1)

c) Test procedure

1) Make sure that MS_A1 is located in Cell
_A1, network A.

Cell_A1 of network A is serving network of
MS_A1.
2) MS_A1 initiates a call to FN_7 to which No call sets up.


none of the test MS registered.

An appropriate tone or an announcement can
be played to MS_A1 indicating that the dialled
FN is not registered.
Note: EIRENE-SRS V15.1 is going to define a
special call release cause indicating a not reg-
istered FN.
3) MS_A1 closes the call. MS_A1 turns to an idle mode.

d) Success criteria
FA call to an unregistered FN can not be completed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.26 FA Call Successful Call (international call)

9.2.1.1
2.4.3
11.2.1.10
11.2.3.1

2.4.1
2.5.1
9.4.1
9.5.2
9.6.2
9.6.3
9.6.4
9.10.1
9.10.1ii
11.5.1
11.5.2
11.5.4
11.5.5

a) Purpose
Verify FA calls to different Call Types (CT).

Step 1: international CT2 /FC01 to CT2 /FC01 call.
Step 3: international CT2 /FC01 to CT3 FC01 call.
Step 5: international CT7 /FC01 to CT6 /FC5yxx call.

Access Matrix which controls calls from and to FN is disabled in both networks A and B. This can
be done either by switch-off of Access Matrix or by setting all calls to Yes temporarily.
The initial registration is given as diagram shows below. The corresponding entries exist in FFN
database of network A and B.
All FN to register in the following calls are unregistered.


Network A Network B

MSC_A1 MSC_B1
CT_A1 (IC_A, FN_11) CT_B1 (IC_B, FN_12)

c) Test procedure

1) MS_A1 initiates a call to IC_B, FN_8 by
preceding the Breakout Code (BC) 900.
The incoming call is displayed on MS_B1.
2) MS_B1 accepts the call. The PTP call between MS_A1 and MS_B1 is
MS_B1 and MS_B1 displays the function of
MS_A1.
4) MS_B1 closes the call. Call is released.

1) CT_A1 initiates a call to IC_B, FN_8 by
preceding the BC 900.
3) MS_B1 accepts the call. The PTP call between CT_A1 and MS_B1 is
CT_A1 displays the function of the connected
CT_A1.
5) CT_A1 closes the call. Call is released.


Step 3: international CT2 /FC01 to CT3 FC01 call.
1) MS_B1 initiates a call to IC_A, FN_2 by
3) MS_A2 accepts the call. The PTP call between MS_A2 and MS_B1 is
MS_A2.

1) CT_B1 initiates a call to IC_A, FN_1 by
3) MS_A1 accepts the call. The PTP call between CT_B1 and MS_A1 is
CT_B1 displays the function of the connected
CT_B1.
5) CT_B1 closes the call. Call is released.
t
Step 5: international CT7 /FC01 to CT6 /FC5yxx call.


1) CT_B1 initiates a call to IC_A, FN_4 by
3) MS_A2 accepts the call. The PTP call between CT_B1 and MS_A2 is
CT_B1 displays the function of the connected
CT_B1.
5) CT_B1 closes the call. Call is released.



d) Success criteria
All international FA calls are successfully connected. The Presentation of Functional Number
(PFN) was correct in all calls.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.2.27 FA Call Call is not completed (international call)

EN 301515

a) Purpose
Verify that a call to an unregistered FN can not be completed.

None of the used MS is registered to FN_5.

Network A Network B

MSC_A1 MSC_B1
MS_A1 CT_B1 (IC_B, FN_15)

c) Test procedure

1) MS_A1 initiates a call to IC_B, FN_5 to
which none of the test MS registered by

No call sets up.
be played to MS_A1 indicating that the dialled
2) MS_A1 closes the call. MS_A1 turns to an idle mode.


3) CT_B1 initiates a call to IC_A, FN_5 to
which none of the test MS registered by

No call sets up.
be played to CT_B1 indicating that the dialled
Note: EIRENE-SRS V15.1 is going to define a
special call release cause indicating a not reg-
istered FN.
4) CT_B1 closes the call. CT_B1 turns to an idle mode.

d) Success criteria
FA call to an unregistered FN can not be completed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3 Access Matrix and Access to External Networks
The following table shows the Access Matrix defined in the EIRENE FRS V7 and will be used as
the test configuration.

Excerpt from FRS v7.0

10.6.2 Yes indicates that the network shall allow a call from the stated initiating party to the
stated receiving party. Yes* indicates that the call shall be allowed at least for users on the
same train. Open indicates that permissions for calls of this type are to be assigned by the im-
plementing railway according to their specific communication requirements. Shaded cells on the
access matrix mean that this call is outside the scope of the EIRENE specifications. The access
matrix is shown in table 10-2. (M)


5.3.1 National call: AM allows call

10.6.1
10.6.2
11.8.1

a) Purpose
Verify the Access matrix configuration works.

Step 1: CT2 / FC 01 calls CT7 /FC01.

Access Matrix is enabled and configured as defined in the EIRENE FRS V7 and shown above.
The initial registration has been done as the diagram shows below. The corresponding entries
exist in FFN database of network A.
MS_A3 has the Follow Me subscription ABCD.

Network A

MS_A1 (FN_1)
MS_A2 (FN_5)
MS_A3 (FN_7)
CT_A1 (FN_11)
CT_A2 (FN_13)


c) Test procedure

1) MS_A1 calls FN_11.

AM allows the call, the incoming call is
displayed on CT_A1.
2) MS_A1 accepts the call. The PTP call between CT_A1 and MS_A1
is successfully established.
3) Verify PFN and check the number displayed
on both calling- and called party.
CT_A1 displays the function of the con-
nected MS_A1 and MS_A1 displays the
function of CT_A1.
4) One of the calling- and called party closes
the call.
Call is released.


displayed on CT_A2.
2) CT_A2 accepts the call. The PTP call between CT_A2 and MS_A2
function of CT_A2.
the call.
Call is released.


displayed on MS_A3.
2) MS_A3 accepts the call. The PTP call between MS_A3 and MS_A1
MS_A3 displays the function of the con-
function of MS_A3.
the call.
Call is released.



displayed on MS_A1.
2) MS_A1 accepts the call. The PTP call between MS_A3 and MS_A1
function of MS_A3.
the call.
Call is released.

d) Success criteria
All above calls set up as the Access Matrix configuration allows.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.2 National call: AM denies call

10.6.1
10.6.2
11.8.1

a) Purpose
Verify the Access matrix check on call processing.
Step 1: CT7 /FC 01 calls CT2 /FC02.

Access Matrix is enabled and configured as defined in the EIRENE FRS V7 and shown above.
The cells marked to Open in the Access Matrix are set up to No.
exist in FFN database of network A.
MS_A3 has the Follow Me subscription ABCD.

Network A

MS_A1 (FN_1)
MS_A2 (FN_5)
MS_A3 (FN_7)
CT_A1 (FN_11)
CT_A2 (FN_13)


c) Test procedure

Step 1: CT7 /FC 01 calls CT2 /FC02.
1) CT_A1 calls FN_5.

AM does not allow the call.
Note: EIRENE-SRS V15.1 is going to de-
fine a special call release cause indicating
a disallowed call by AM.
2) Change the according entry of AM to allow
the call (yes) temporarily.
The affected call is configured to be al-
lowed.

AM now allows the call, the incoming call
is displayed on MS_A2.
4) MS_A2 accepts the call. The PTP call between MS_A2 and CT_A1
nected CT_A1 and CT_A1 displays the
function of MS_A2.
the call.
Call is released.
7) Undo the above temporary change. The affected cell of AM is configured to
No.


lowed.

function of MS_A3.
the call.
Call is released.


No.


on MS_A2.

lowed.

function of MS_A2.
the call.
Call is released.
No.


lowed.

is displayed on CT_A2.


4) CT_A2 accepts the call. The PTP call between MS_A3 and CT_A2
function of MS_A3.
the call.
Call is released.
No.
8) Undo the subscription change for MS_A3. MS_A3 has no more Follow Me subscrip-
tion.

d) Success criteria
Calls can be set up only if the Access Matrix configuration allows.
Dependent on network configuration an appropriate tone and/or an announcement can be played
to the calling party in case of not allowed call by Access Matrix.
Note: E-SRS V15.1 will specify a special call release code for such a case.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.3 International call: AM allows call

10.6.1
10.6.2
9.3.4
9.10.1
9.10.1ii
11.8.1

a) Purpose
Verify the Access matrix check on international call processing.

Step 1: IC_A /CT7 /FC01 calls IC_B /CT2 /FC01.
Step 3: IC_B /CT2 /FC01 calls IC_A /CT7 /FC01.

Access Matrix is enabled and configured as defined in the EIRENE FRS V7 and shown above in
both networks A and B.
MS_A1 and MS_A2 roam in network B.
MS_B1 and MS_B2 roam in network A.
exist in FFN database of network A and B.



Network A Network B

MSC_A1 MSC_B1
MS_B1 (IC_A, FN_1) MS_A1 (IC_B, FN_7 )
CT_A1 ( IC_A, FN_11) CT_B1 (IC_B, FN_15)

c) Test procedure

1) Make sure that the last assigned FN of
CT_A1 is IC_A, FN_11.
CT_A1 displays the functional identity of
FN_11.
2) CT_A1 calls IC_B, FN_8 by preceding the
BC 900.
AM of network B allows the call, the in-
coming call is displayed on MS_A2.
function of MS_A2.
the call.
Call is released.

CT_A2 is IC_A, FN_13.
CT_A2 displays the functional identity of
FN_13.
BC 900.
coming call is displayed on MS_A2.


function of MS_A2.
the call.
Call is released.

1) Make sure that the last registered FN of
MS_A2 is IC_B, FN_8.
MS_A2 displays the functional identity of
FN_8.
2) MS_A2 calls IC_A, FN_11 by preceding the
BC 900.
AM of network A allows the call, the in-
coming call is displayed on CT_A1.
3) CT_A1 accepts the call. The PTP call between MS_A2 and CT_A1
function of MS_A2.
the call.
Call is released.

CT_B1 is IC_B, FN_15.
CT_B1 displays the functional identity of
FN_15.
2) CT_B1 calls IC_A, FN_1 by preceding the
BC 900.
coming call is displayed on MS_B1.
3) MS_B1 accepts the call. The PTP call between MS_B1 and CT_B1
MS_B1 displays the function of the con-
nected CT_B1 and CT_B1 displays the
function of MS_B1.
the call.
Call is released.



CT_B2 is IC_B, FN_16.
CT_B2 displays the functional identity of
FN_16.
BC 900.
coming call is displayed on MS_B1.
function of MS_B1.
the call.
Call is released.

1) Make sure that the last registered FN of
MS_B1 is IC_A, FN_1.
MS_B1 displays the functional identity of
FN_1.
2) MS_B1 calls IC_B, FN_15 by preceding the
BC 900.
coming call is displayed on CT_B1.
3) CT_B1 accepts the call. The PTP call between MS_B1 and CT_B1
function of MS_B1.
the call.
Call is released.

d) Success criteria
International FA-calls can be set up as the Access Matrix allows.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.4 International call: AM denies call

10.6.1
10.6.2
11.8.1

a) Purpose
Verify the Access matrix check on international call processing.


Access Matrix is enabled and configured as defined in the EIRENE FRS V7 and shown above in
both networks A and B.
The cells marked to Open in the above Access Matrix are set up to No.
MS_A1 and MS_A2 roam in network B.
MS_B1 and MS_B2 roam in network A.
exist in FFN database of network A and B.



Network A Network B

MSC_A1 MSC_B1
CT_A1(IC_A, FN_11) CT_B1 (IC_B, FN_15)

c) Test procedure

BC 900.

AM of network B does not allow the call.
2) Change the according entry of AM on net-
work B to allow the call (yes) temporarily.
lowed.
BC 900.
AM of network B now allows the call, the
incoming call is displayed on MS_A2.
function of MS_A2.
the call.
Call is released.
No.


BC 900.

lowed.
BC 900.
incoming call is displayed on MS_A1.
function of MS_A1.
the call.
Call is released.
No.

BC 900.

AM of network A does not allow the call.
work A to allow the call (yes) temporarily.
lowed.
BC 900.
AM of network A now allows the call, the
incoming call is displayed on CT_A1.
4) CT_A1 accepts the call. The PTP call between CT_A1 and MS_A2
function of CT_A1.
the call.
Call is released.
No.


BC 900.

lowed.
BC 900.
incoming call is displayed on MS_B2.
function of MS_B2.
the call.
Call is released.
No.

BC 900.

lowed.
BC 900.
incoming call is displayed on MS_B1.
function of MS_B1.
the call.
Call is released.
No.


BC 900.

lowed.
BC 900.
incoming call is displayed on CT_B1.
4) CT_B1 accepts the call. The PTP call between CT_B1 and MS_B2
CT_B1 displays the function of the con-
nected MS_B2 and MS_B2 displays the
function of CT_B1.
the call.
Call is released.
No.

d) Success criteria
International FA-calls can be set up in case that Access Matrix allows.
Dependent on network configuration an appropriate tone and/or an announcement can be played
to the calling party in case of not allowed call by Access Matrix.
Note: E-SRS V15.1 will specify a special call release code for such a case.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.5 Calling party outside the EIRENE network (non-roaming case)

2.4.17
9.5.1
11.2.1.10
9.2.9
11.8.1

a) Purpose
Verify the check on call authorization.

A PSTN Phone is available.
MS_A1 is authorized to receive incoming calls from public network(s).
MS_A2 is not authorized to receive incoming calls from public network(s).
The configuration of above subscriber information can be done either on HLR or on IN/SCP.

Network A

MS_A1
MS_A2

c) Test procedure

1) A PSTN phone calls MS_A1 by dialling
AC+NDC+SN.



2) MS_A1 accepts the call. The PTP call between MS_A1 and the
PSTN phone is successfully established.
AC+NDC+SN.

The call does not establish. Dependent on
network setting the calling party gets an
appropriate tone or an announcement
played.

d) Success criteria
Check on call authorization works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.6 Calling party outside the EIRENE network (roaming case)

2.4.17
9.5.1
11.2.1.10
9.2.9
11.8.1

a) Purpose
Verify the check on call authorization in case of roaming.

A PSTN Phone is available.
MS_A1 is authorized to receive incoming calls from public network(s).
MS_A2 is not authorized to receive incoming calls from public network(s).
MS_A1 and MS_A2 are roaming in network B.

Network A Network B

MSC_A1 MSC_B1
MS_A1
MS_A2

c) Test procedure



AC+CC+NDC+SN.

2) MS_A1 accepts the call. The PTP call between MS_A1 and the
PSTN phone is successfully established.
AC+CC+NDC+SN.

The call does not establish. Dependent on
network setting the calling party gets an
appropriate tone or an announcement
played.

d) Success criteria
Check on call authorization works also in roaming case.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.7 Access to other GSM-R networks: Break out codes (non-roaming case)

9.4.2
9.10.1
9.10.1i
9.10.1ii
9.10.1iii

a) Purpose
Verify the access to other GSM-R network by using BC (Breakout Code) and AC (Access Code)
works.

Step 1: Access to other GSM-R network by using BC (Breakout Code) from network A.
Step 2: Access to other GSM-R network by using BC (Breakout Code) from network B.
Step 3: Access to other GSM-R network by using AC (Access Code) from network A.
Step 4: Access to other GSM-R network by using AC (Access Code) from network B.


Network A Network B

MSC_A1 MSC_B1


c) Test procedure

1) MS_A1 initiates a call to IC_B, FN_1 by
CDN = 900 + IC_B + FN_1
MS_A1.

1) MS_B1 initiates a call to IC_A, FN_8 by
CDN = 900 + IC_A + FN_8
MS_A1.

1) MS_A1 initiates a call to MS_B1 by dial-
ling the AC 00 followed by CC and NSN
(National Significant Number = NDC +
SN).
CDN = 00 + CC_B + NDC_B + SN
MS_A1.


1) MS_B1 initiates a call to MS_A1 by dial-
ling the AC 00 followed by CC and NSN
(National Significant Number = NDC +
SN).
CDN = 00 + CC_A + NDC_A + SN
MS_A1.

d) Success criteria
Access to other GSM-R network by using BC (Breakout Code) and AC (Access Code) works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.8 Access to other GSM-R networks: Break out codes (roaming case)

9.4.2
9.10.1
9.10.1i
9.10.1ii
9.10.1iii

a) Purpose
Verify the access to other GSM-R network by using BC (Breakout Code) and AC (Access Code)
works also in roaming case.



Network A Network B

MSC_A1 MSC_B1
MS_B2 MS_A2


c) Test procedure

1) MS_B2 which roams in network A initi-
ates a call to IC_B, FN_1 by preceding
the Breakout Code (BC) 900.
CDN = 900 + IC_B + FN_1
2) MS_B1 accepts the call. The PTP call between MS_B2 and MS_B1 is
MS_B2 displays the function of the connected
MS_B1.

1) MS_A2 which roams in network B initi-
ates a call to IC_A, FN_8 by preceding
the Breakout Code (BC) 900.
CDN = 900 + IC_A + FN_8
MS_A1.

1) MS_B2 which roams in network A initi-
ates a call to MS_B1 by dialling the AC
00 followed by CC and NSN (National
Significant Number = NDC + SN).
CDN = 00 + CC_B + NDC_B + SN
2) MS_B1 accepts the call. The PTP call between MS_B2 and MS_B1 is
MS_B2 displays the function of the connected
MS_B1.


1) MS_A2 which roams in network B initi-
ates a call to MS_A1 by dialling the AC
00 followed by CC and NSN (National
Significant Number = NDC + SN).
CDN = 00 + CC_A + NDC_A + SN
MS_A1.

d) Success criteria
Access to other GSM-R network by using BC (Breakout Code) and AC (Access Code) works also
in roaming case.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.9 Access to public networks (non-roaming case)

9.10.3

a) Purpose
Verify the access to public networks by using AC (Access Code) works.

Network_A is connected to a Public Network.
PSTN Phone(s) are available.
MS_A1 is authorized to make outgoing calls to public network(s).

Network A

MS_A1

c) Test procedure

1) MS_A1 calls a PSTN Number by dialling
AC (0) +NDC+SN.
CDN = 0 + NDC + SN
The incoming call is displayed on the PSTN
phone.
2) The PSTN phone accepts the call. The PTP call between MS_A1 and the PSTN
phone is successfully established.


AC (00)+CC+NDC+SN.
CDN = 00 + CC + NDC + SN
phone.

d) Success criteria
Access to public networks by using AC (Access Code) works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.10 Access to public networks (roaming case)

9.10.3

a) Purpose
Verify the access to public networks by using AC (Access Code) works also in roaming case.

Step 1: Access to public network by using AC (Access Code) from roaming network B.
Step 2: Access to public network by using AC (Access Code) from roaming network A.

Network_A and Network_B are connected to a Public Network.
PSTN Phone(s) are available.
MS_A1 is authorized to make outgoing calls to public network(s) and roams in network B
MS_B1 is authorized to make outgoing calls to public network(s) and roams in network A.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1



c) Test procedure

Step 1: Access to public network by using AC (Access Code) from roaming network B.
1) MS_A1 which roams in network B calls a
PSTN Number by dialling AC (0)
+NDC+SN.
CDN = 0 + NDC + SN
phone.
AC (00) +CC+NDC+SN.
phone.
6) The PSTN phone closes the call. Call is released.

Step 2: Access to public network by using AC (Access Code) from roaming network A.
1) MS_B1 which roams in network A calls a
PSTN Number by dialling AC (0)
+NDC+SN.
CDN = 0 + NDC + SN
phone.
2) The PSTN phone accepts the call. The PTP call between MS_B1 and the PSTN
4) MS_B1 calls a PSTN Number by dialling
AC (00) +CC+NDC+SN.
phone.
5) The PSTN phone accepts the call. The PTP call between MS_B1 and the PSTN
6) The PSTN phone closes the call. Call is released.

d) Success criteria
Access to public networks by using AC (Access Code) works also in roaming case.


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.11 Access to private networks: Break out codes (non-roaming case)

9.10.1v

a) Purpose
Verify the access to private networks by using BC (Breakout Code) works.

Network_A is connected to a private Network.
Private network Phone(s) are available.
MS_A1 is authorized to make outgoing calls to private network(s) in case this is not generally al-
lowed.

Network A

MS_A1

c) Test procedure

1) MS_A1 calls the private network phone
Number by dialling BC (901) +Private
Network Code + SN.
CDN = 901 + Private NC + SN
The incoming call is displayed on the Private
network phone.


2) The Private network phone accepts the
call.
The PTP call between MS_A1 and the Private
network phone is successfully established.

d) Success criteria
Access to private networks by using BC (Breakout Code) works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.3.12 Access to private networks: Break out codes (roaming case)

9.10.1v

a) Purpose
Verify the access to private networks by using BC (Breakout Code) while roaming works.

Network_B is connected to a Private Network.
Private network Phone(s) are available.
MS_A1 is authorized to make outgoing calls to private network(s) in case this is not generally al-
lowed.

Network A Network B

MSC_A1 MSC_B1
MS_A1

c) Test procedure



Number by dialling AC(00) + CC_A +
NDC + BC (901) +Private Network Code
+ SN.
CDN = AC + CC_A + NDC + BC(901) +
Private NC + SN
network phone.
call.
Number by dialling BC(900) + IC_A + BC
(901) +Private Network Code+SN.
CDN = BC(900) + IC_A + BC(901) + Pri-
vate NC + SN
network phone.
call.

d) Success criteria
Access to private networks by using BC (Breakout Code) while roaming works.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.4 Location Depending Addressing
The test configuration of LDA is described in chapter 4.6.3.

5.4.1 LDA call (non-roaming case)

2.5.1
3.2.3
9.3.2
11.4
2.5.1
9.4.1
9.8.1
9.8.2
9.8.3
9.8.4
11.7.1
11.7.2

a) Purpose
Verify the short code calls are routed to the preconfigured controller.

CT_A1, primary controller in charge of cell_A1 is assigned to IC_A, FN_11.
CT_A2, secondary controller in charge of cell_A1 is assigned to IC_A, FN_13.

Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
CT_A1 (IC_A, FN_11) CT_A3 (IC_A, FN_12)



c) Test procedure

1) MS_A1 dials short code 1200.

The call is routed to CT_A1 and if any, the
functional number of MS_A1 is displayed
on CT_A1.

on CT_A3.

on CT_A2.

on CT_A4.

d) Success criteria
All calls are routed dependent on cell of origin. The System Log-files show the right routing data
including cell of origin, Short Code and predefined destination etc.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.4.2 LDA call fails (non-roaming case)

2.5.1
11.4
2.5.1
11.7.1
11.7.2

a) Purpose
Verify LDA calls cannot be routed in case of missing configurations.

Primary controller of cell_B is not defined.

Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
CT_A1 (IC_A, FN_11)

c) Test procedure




No destination number for the short code
1500 is defined; an appropriate tone or an
announcement is played to calling party.
Note: E-SRS V15.1 will specify a special
call release code for such a case.

1200 is defined; an appropriate tone or an
announcement is played to calling party.

d) Success criteria
LDA calls are released in case of missing configurations.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.4.3 LDA call (roaming case)

2.5.1
9.3.2
11.4
2.5.1
9.4.1
9.8.1
9.8.2
9.8.3
9.8.4
11.7.1
11.7.2

a) Purpose
Verify the short code calls are routed to the preconfigured controller.

CT_B1, primary controller in charge of cell_B1 is assigned to IC_B, FN_15.
CT_B2, secondary controller in charge of cell_B1 is assigned to IC_A, FN_1.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1



c) Test procedure


The call is routed to CT_B1 and if any, the
on CT_B1.

The call is routed to CT_B2 and if any, the
on CT_B2.
3) MS_B1 dials short code 1200.

functional number of MS_B1 is displayed
on CT_A1.

functional number of MS_B1 is displayed
on CT_A2.

d) Success criteria
All calls are routed dependent on cell of origin. The System Log files show the right routing data
including cell of origin, Short Code and predefined destination etc.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.4.4 LDA call fails (roaming case)

2.5.1
11.4
2.5.1
11.7.1
11.7.2

a) Purpose
Verify LDA calls cannot be routed in case of missing configurations.

CT_B1, primary controller in charge of cell_B1 is assigned to IC_B, FN_15.
CT_B2, secondary controller in charge of cell_B1 is assigned to IC_A, FN_16.
Secondary controller of cell_A1 is not defined.

Network A Network B

MSC_A1 MSC_B1
MS_B1 MS_A1
CT_B2 (IC_B, FN_16)

c) Test procedure




1300 for cell_A1 in network A is defined,
an appropriate announcement is played to
calling party.

1500 for cell_B1 in network B is defined,
an appropriate announcement is played to
calling party.

d) Success criteria
LDA calls are released in case of missing configurations.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5 MLPP
Overview reference to EIRENE FRS V7:

Chapter: Text
2.4.1 The EIRENE network will support the following call related services: display of identity
of called/calling user; (M)
- restriction of display of called/calling user; (O)
- priority and pre-emption; (M)
- closed user group; (M)
- call forwarding; (M)
- call hold; (M)
- call waiting; (M)
- charging information; (O)
- call barring. (M)
2.4.6 This mechanism shall allow calls with a higher assigned priority to override (pre-empt)
existing calls of a lower priority. (M)
2.4.7 Pre-empted calls will be discontinued and the new call of a higher priority shall be
connected instead. (M)
10.2.3 The lowest priority ongoing call shall be pre-empted before that of a higher priority. (M)

Overview reference to EIRENE SRS 15:

Chapter: Text
2.4.1 The GSM supplementary services [EN 301 515, Index [9]] to be supported are listed in
table 2-3. The applicability of these supplementary services to GSM basic services will
be as indicated in [GSM 02.81-02.89 and EN 301 515, Index [28]]. (I)
10.2.1 In order to provide a consistent international service, it is necessary to ensure that pri-
orities are allocated consistently across all railways. The following allocation of UIC
priority levels to eMLPP priority codes is mandatory: (M)



Allocation of priorities according to Table 10-1 of EIRENE SRS 15:

UIC Priority Automatic
answering*
eMLPP priority
designation
Pre-emption
(of)
Railway emergency Y 0 Control-command (safety) and
below
Control-command (safety)

Y 1 Public emergency, group calls be-
tween drivers in the same area and
below
Public emergency and group
calls between drivers in the
same area

Y 2 Railway operation. Control-
command information and below
Railway operation
(e.g. calls from or for drivers
and controllers) and Control-
command information
Y**

3 Railway information and all other
calls
Railway information and all
other calls
N 4 ---

General Purpose:
Verify the call related service MLPP at the E-Interface.
Verify that a mobile subscriber can be subscribed with a default and a maximal priority.

Preconditions:
Fast Call Setup is configured for high priority calls on SIM.
Not all subscribers and controllers are subscribed for the REC.
The function of the subscribers and controllers can change from step to step and from case to
case.
All subscribers have the default priority 4 and max priority 0 subscribed in HLR.
Sometimes its necessary that the mobile do not react to the 299 REC. Special configured SIM-
Cards may be necessary for that, e.g. subscriber profile 2.
The VGCS GIDs used in this chapter are:
GID: 299 with prio 0


5.5.1 PtP call pre-emption at the E-IF between two networks by REC


2.4.1
2.4.6
2.4.7
10.2.3
2.4.1
10.2.1

a) Purpose
Verify that any PtP connection at E-IF can be pre-empted from any side by a REC.

Step 1: REC initiated by service subscriber in A-MSC_A. MSC_A is pre-empting.
Step 2: REC initiated by service subscriber in R-MSC_B. MSC_A and MSC_B are pre-empting.
Step 3: REC initiated by service subscriber in A-MSC_B. MSC_B is pre-empting.
Step 4: REC initiated by service subscriber in R-MSC_A. MSC_A and MSC_B are pre-empting.
Step 5: Pre-emption of PtP at E-IF by controller connection to/from MSC_B. MSC_A or MSC_B is
pre-empting.
Step 6: Pre-emption of PtP at E-IF by controller connection to/from MSC1. MSC_A or MSC_B is
pre-empting.


Test configuration for steps 1-2: Pre-emption by originator and group call connection
The trunk capacity between the networks is reduced to 2 Time Slots (TSs).

Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (no VGCS / VBS subscriber) MS_A2 (no VGCS / VBS subscriber)
MS_A5 (REC GID: 299) ,
CoO=Cell_A1
MS_A6 (REC GID: 299) ,
CoO=Cell_B1
CT_A1

2 TSs at E-IF

CT_B1

c) Test procedure

Step 1: REC initiated by service subscriber in A-MSC_A. MSC_A is pre-empting.
1.1 MS_A1 calls MS_A2 with Prio 4 MS_A1 connected with MS_A2 with Prio 4
All TSs at E are BUSY
1.3 MS_A5 originates a REC
in A-MSC_A
MS_A6 receives the REC
MS_A1 and MS_A2 are disconnected
MS_A3 connected with MS_A4 with Prio 3


1.4 MS_A5 releases the REC The REC is released
MS_A6 is idle
in A-MSC_A
MS_A6 is idle
1.8 CT_B1 calls MS_A1 with Prio 4 MS_A1 connected with CT_B1 with Prio 4
in A-MSC_A
MS_A1 and CT_B1 are disconnected
MS_A6 is idle
1.11 CT_A1 calls MS_A2 with Prio 4 MS_A2 connected with CT_A1 with Prio 4
in A-MSC_A
MS_A2 and CT_A1 are disconnected
MS_A6 is idle
1.14 MS_A2 calls CT_A1 with Prio 4 MS_A2 connected with CT_A1 with Prio 4
in A-MSC_A


MS_A6 is idle
MS_A3 connected with MS_A4
1.17 Terminate the remaining PtP call All participants and both TSs at E are IDLE

Step 2: REC initiated by service subscriber in R-MSC_B. MSC_A and MSC_B are pre-empting.
in R-MSC_B
Connection MS_A1/MS_A2 pre-empted first
MS_A5 is idle
All participants and TSs at E are IDLE
2.5 MS_A2 calls MS_A1 with Prio 3
MS_A4 calls MS_A3 with Prio 4
in R-MSC_B
MS_A6 is idle
2.8 MS_A1 calls CT_B1 with Prio 4
CT_A1 calls MS_A2 with Prio 3
MS_A1 connected with CT_B1 with Prio 4
MS_A2 connected with CT_A1 with Prio 3
in R-MSC_B
MS_A1 disconnected with CT_B1
MS_A2 disconnected with CT_A1
Connection MS_A1/CT_B1 pre-empted first


MS_A5 is idle
All participants and TSS at E are IDLE
2.11 CT_B1 calls MS_A1 with Prio 3
MS_A2 calls CT_A1 with Prio 4
in R-MSC_B
Connection MS_A2/CT_A1 pre-empted first
MS_A5 is idle

Test configuration for steps 3-4: Pre-emption by originator and group call connection

Network A Network B

R-MSC_A1 A-MSC_B1
MS_A5 (REC GID: 299), MS_A6 (REC GID: 299) ,
CT_A1

2 TSs at E-IF

CT_B1


Test procedure:

Step 3: REC initiated by service subscriber in A-MSC_B. MSC_B is pre-empting.
in A-MSC_B
MS_A5 is idle
in A-MSC_B
MS_A5 is idle
3.8 MS_A1 calls CT_B1 with Prio 4 MS_A1 connected with CT_B1 with Prio 4
in A-MSC_B
MS_A5 is idle
3.11 CT_B1 calls MS_A1 with Prio 4 MS_A1connected with CT_B1 with Prio 4
in A-MSC_B


MS_A5 is idle
3.14 CT_A1 calls MS_A2 with Prio 4 MS_A2 connected with CT_A1 with Prio 4
in A-MSC_B
MS_A5 is idle
in A-MSC_B
MS_A5 is idle
3.20 Terminate the remaining PtP call All participants and both TSs at E are IDLE

In R-MSC_A
MS_A6 is idle


In R-MSC_A
MS_A6 is idle
4.8 MS_A1 calls CT_B1 with Prio 4
CT_A1 calls MS_A2 with Prio 3
In R-MSC_A
Connection MS_A1/CT_B1 pre-empted first
MS_A5 is idle
All participants and TSS at E are IDLE
4.11 CT_B1 calls MS_A1 with Prio 3
MS_A2 calls CT_A1 with Prio 4
In R-MSC_A
Connection MS_A2/CT_A1 pre-empted first
MS_A5 is idle
All participants and both TSs at E are IDLE


Test configuration for step 5-6: Pre-emption by controller connection

Network A Network B

MSC_A1 MSC_B1
MS_A5 (REC GID: 299) MS_A6 (REC GID: 299)
CT_A1 (GCA_B1, REC GID: 299) CT_B1 (GCA_A1, REC GID: 299)
CT_A2

2 TSs at E-IF
CT_B2

Test procedure

Step 5: Pre-emption of PtP at E-IF by controller connection to/from MSC_B. MSC_A or
MSC_B is pre-empting.
in MSC_A
CT_B1 receives the REC
MS_A3 and MS_A4 are connected with Prio 3


CT_B1 is idle
5.5 CT_A2 calls CT_B2 with Prio 4 MS_A3 and MS_A4 are connected with Prio 3
CT_A2 connected with CT_B2 with Prio 4
in MSC_A
CT_A2 and CT_B2 are disconnected
CT_B1 is idle
CT_A2 and CT_B2 are IDLE
5.8 CT_B2 calls CT_A2 with Prio 4 MS_A3 and MS_A4 are connected with Prio 3
in MSC_A
CT_B1 is idle
5.11 MS_A3 release the call All participants and TSs at E are IDLE
5.12 CT_B2 calls CT_A2 with Prio 4 CT_A2 connected with CT_B2 with Prio 4
5.14 CT_B1 connected to MSC_B origi-
nates a REC in MSC_A
5.15 CT_B1 releases the REC MS_A1 and MS_A2 are connected with Prio 3
MS_A5 is IDLE
5.16 Release the remaining PtP call All participants and both TSs at E are IDLE


Step 6: Pre-emption of PtP at E-IF by controller connection to/from MSC1. MSC_A or
MSC_B is pre-empting.
in MSC_B
CT_A1 receives the REC
CT_A1 is idle
6.5 CT_A2 calls CT_B2 with Prio 4 MS_A3 and MS_A4 are connected with Prio 3
in MSC_B
CT_A1 is idle
6.8 CT_B2 calls CT_A2 with Prio 4 MS_A3 and MS_A4 are connected with Prio 3
in MSC_B
CT_A1 is idle
6.11 MS_A3 release the call All participants and TSs at E are IDLE


6.14 CT_A1 located in MSC_A originates a
REC in MSC_B
6.15 CT_A1 releases the REC MS_A1 and MS_A2 are connected with Prio 3
MS_A6 is IDLE
6.16 Terminate the remaining PtP call All participants and TSs at E are IDLE
6.17 Unblock the TSs at E-IF All resources are IDLE

d) Success criteria
Any PtP connection at E-IF can be pre-empted from any side by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.2 PtP call pre-emption at the E-IF between two networks by an other PtP call


2.4.6
2.4.7
10.2.3

a) Purpose
Verify that any PtP connection at E-IF can be pre-empted by any other PtP call with higher priority
from any side of it.

Step 1: PtP call pre-emption at the E-IF between two networks by another PtP call. MSC_A is
pre-empting.
Step 2: PtP call pre-emption at the E-IF between two networks by another PtP call. MSC_B is
pre-empting.

Test configuration for step 1 and 2:

Network A Network B

MSC_A1 MSC_B1
MS_A1 MS_A2
MS_A3 MS_A4
CT_A1

2 TSs at E-IF
CT_B1

c) Test procedures


Step 1: PtP call pre-emption at the E-IF between two networks by another PtP call. MSC_A
is pre-empting.
1.3 CT_A1 calls CT_B1 with Prio 4 Call is unsuccessful
1.4 CT_A1 calls CT_B1 with Prio 3 CT_A1 connected with CT_B1 with Prio 3
MS_A1 and MS_A2 or MS_A3 and MS_A4
are disconnected.
1.5 Release the remaining calls All participants and TSs at E-IF are IDLE
1.8 CT_A1 calls CT_B1 with Prio 3 CT_A1 connected with CT_B1 with Prio 3
MS_A1 and MS_A2 are disconnected.
1.9 Release the remaining calls All participants and TSs at E are IDLE
1.10 MS_A1 calls CT_B1 with Prio 4 MS_A1 connected with CT_B1 with Prio 4
1.11 CT_A1 calls MS_A2 with Prio 3 CT_A1 connected with MS_A2 with Prio 3
CT_A1 connected with MS_A2 with Prio 3
1.13 Release the remaining calls All participants and both TSs at E are IDLE

Step 2: PtP call pre-emption at the E-IF between two networks by another PtP call. MSC_B
is pre-empting.
2.3 CT_B1 calls CT_A1 with Prio 4 Call is unsuccessful
MS_A1 and MS_A2 or MS_A3 and MS_A4
are disconnected.
2.5 Release the remaining calls All participants and TSs at E are IDLE


2.8 CT_B1 calls CT_A1 with Prio 3 CT_B1 connected with CT_A1 with Prio 3
MS_A1 and MS_A2 are disconnected.
2.11 CT_B1 calls MS_A1 with Prio 3 CT_B1 connected with MS_A1 with Prio 3
CT_B1 connected with MS_A1 with Prio 3

d) Success criteria
Any PtP connection at E-IF can be pre-empted by any other PtP call with higher priority from any
side of it.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.3 Link to a controller of a VGCS call is pre-empted at the E-IF between two networks
and at the PRI by REC


2.4.6
2.4.7
10.2.3

a) Purpose
Verify that a controller connection at E-IF and at PRI can be pre-empted by a REC. Pre-emption
from the PBX-side is not covered by this TC.

Step 1: Link to a controller of a VGCS call is pre-empted at the E-IF between two networks by a
REC. MSC_A1 and MSC_B1 are pre-empting.
Step 2: Link to a controller of a VGCS call is pre-empted at the E-IF between two networks by a
REC. MSC_B and MSC_B are pre-empting.
Step 3: Link to a controller of a VGCS call is pre-empted by REC at PRI in MSC_A.
Step 4: Link to a controller of a VGCS call is pre-empted by REC at PRI in MSC_B.


Test configuration for step 1:

Network A Network B

MSC_A1 MSC_B1
MS_A1 (VGCS GID: 200) CT_B1 (GCA_A1, VGCS GID: 200)
CT_B2 (GCA_A1, VGCS GID: 200)
MS_A2 (REC GID: 299)

2 TSs at E-IF
CT_ B3 (GCA_A1, REC GID: 299)

c) Test procedure

Step 1: Link to a controller of a VGCS call is pre-empted at the E-IF between two networks
by a REC. MSC_A and MSC_B are pre-empting.
1.1 MS_A1 originates a 200 VGCS in
MSC_A
CT_B1 und CT_B2 receive the 200 VGCS
1.2 MS_A2 originates a REC in
MSC_A
CT_B1 or CT_B2 are pre-empted
1.3 All existing calls are released All participants and TSs at E are IDLE
MSC_A
CT_B1 und CT_B2 receive the 200 VGCS
1.5 CT_B3 placed in MSC_B originates a
REC in MSC_A
CT_B1 or CT_B2 are pre-empted
1.6 All existing calls are released All participants and both TSs at E are IDLE


Test configuration for step 2: Controller connection pre-empted by REC at E-IF

Network A Network B

MSC_A1 MSC_B1
CT_A1 (GCA_B1, VGCS GID: 200) MS_A1 (VGCS GID: 200)
CT_A2 (GCA_B1, VGCS GID: 200)
CT_A3 (GCA_B1, REC GID: 299)

2 TSs at E-IF

Test procedure

Step 2: Link to a controller of a VGCS call is pre-empted at the E-IF between two networks
by a REC. MSC_B and MSC_B are pre-empting.
MSC_B
CT_A1 und CT_A2 receive the 200 VGCS
2.2 MS_A2 originates a REC in
MSC_B
CT_A1 or CT_A2 are pre-empted
MSC_B
CT_A1 und CT_A2 receive the 200 VGCS
2.5 CT_A3 placed in MSC_A originates a
REC in MSC_B
CT_A1 or CT_A2 are pre-empted
2.6 All existing calls are released All participants and both TSs at E are IDLE


Test configuration for step 3: Controller connection pre-empted by REC at PRI

Network A

MSC_A1 PBX
MS_A1 (VGCS GID: 200) CT_A1 (GCA_A1, VGCS GID: 200)

1 TS at PRI
CT_A2 (GCA_A1, REC GID: 299)

Test procedure

Step 3: Link to a controller of a VGCS call is pre-empted by REC at PRI in MSC_A.
4.1 MS_A1 originates a 200 VGCS CT_A1 receives the 200 VGCS
All TSs at the PRI are BUSY
4.2 MS_A2 originates the REC CT_A2 receives the REC
CT_A1 is pre-empted at PRI
4.4 MS_A1 originates a 200 VGCS CT_A1 receives the 200 VGCS
4.5 CT_A2 originates the REC MS_A2 receives the REC
CT_A1 pre-empted at PRI
4.6 All existing calls are released All participants and TSs at PRI are IDLE
4.7 Unblock the TSs at the PRI All resources are IDLE


Test configuration for step 4: Controller connection pre-empted by REC at PRI

Network B

MSC_B1 PBX
MS_B1 (VGCS GID: 200) CT_B1 (GCA_B1, VGCS GID: 200)
MS_B2 (REC GID: 299)

1 TS at PRI
CT_B2 (GCA_B1, REC GID: 299)

Test Procedure

Step 4: Link to a controller of a VGCS call is pre-empted by REC at PRI in MSC_B.
4.1 MS_B1 originates a 200 VGCS CT_B1 receives the 200 VGCS
4.2 MS_B2 originates the REC CT_B2 receives the REC
CT_B1 is pre-empted at PRI
4.4 MS_B1 originates a 200 VGCS CT_B1 receives the 200 VGCS
4.5 CT_B2 originates the REC MS_B2 receives the REC
CT_A1 pre-empted at PRI
4.6 All existing calls are released All participants and TSs at PRI are IDLE
4.7 Unblock the TSs at the PRI All resources are IDLE



d) Success criteria
A controller connection at E-IF and at PRI can be pre-empted by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.4 Link to the originator as first talker of a VGCS call is pre-empted at the E-IF between
two networks by REC

2.4.6
2.4.7
10.2.3

a) Purpose
Verify that the dedicated link at E-IF can be pre-empted from any side by a REC.

Step 2: REC initiated by service subscriber in R-MSC_B. MSC_B and MSC_A are pre-empting.

Test configuration for step 1

Network A Network B

R-MSC_A1 A-MSC_B1
MS_A1 (VGCS GID: 200) MS_A2 (VGCS GID: 200)

2 TSs at E-IF
CT_B1 (GCA_AB1, VGCS GID: 200)


c) Test procedures

Step 1: REC initiated by service subscriber in R-MSC_A. MSC_A and MSC_B are pre-
empting.
R-MSC_A and keep the dedicated link
MS_A2 and CT_B1 receives the 200 VGCS
All TSs at E-IF are BUSY
1.2 MS_A3 originates the REC in
R-MSC_A
MS_A4 receives the REC in A-MSC_B
MS_A1 is IDLE after the pre-emption of the
DCH and the group channel at E-IF
The 200 VGCS is probably released in R-
MSC_A
The 200 VGCS exists probably in A-MSC_B
(behaviour not specified, implementation de-
pendent)
MS_A2 can not release the 200 VGCS
1.3 MS_A3 releases the REC All TSs at E-IF are IDLE
MS_A2 is probably still in 200 VGCS and it
can request the uplink
1.4 CT_B1 kills the 200 VGCS All participants and both TSs at E-IF are IDLE
R-MSC_A and keep the dedicated link
1.6 MS_A4 originates the REC in A-MSC_B The DCH of MS_A1 or the group channel of
the 200 VGCS is pre-empted at E-IF by the
REC (behaviour not specified)
1.7 MS_A4 releases the REC
CT_B1 kills the 200 VGCS
All parties are IDLE



Network A Network B

A-MSC_A1 R-MSC_B1

2 TSs at E-IF

Test procedure

Step 2: REC initiated by service subscriber in R-MSC_B. MSC_B and MSC_A are pre-
empting.
R-MSC_B and keep the dedicated link
MS_A1 and CT_A1 receives the 200 VGCS
2.2 MS_A4 originates the REC in
R-MSC_B
MS_A3 receives the REC in A-MSC_A
MS_A2 is IDLE after the pre-emption
The 200 VGCS is probably released in R-
MSC_B
The 200 VGCS exists probably in A-MSC_A
pendent)
MS_A1 can not release the 200 VGCS


2.3 MS_A4 releases the REC All TSs at E-IF are IDLE
MS_A1 is probably still in 200 VGCS and it
can request the uplink
2.4 CT_A1 kills the 200 VGCS All participants and both TSs at E-IF are IDLE
R-MSC_B and keep the dedicated link
2.6 MS_A3 originates the REC in A-MSC_A The DCH of MS_A2 or the group channel of
the 200 VGCS is pre-empted at E-IF by the
REC (behaviour not specified)
2.7 MS_A3 releases the REC
CT_A1 kills the 200 VGCS
All parties are IDLE

d) Success criteria
The dedicated link of a VGCS call can be pre-empted at E-IF from any side by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.5 Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between two
networks by REC

2.4.6
2.4.7
10.2.3

a) Purpose
Verify that the group channel at E-IF can be pre-empted from any side by a REC.
Note: Some implementations do not support E-IF pre-emption in this case.

Step 1: Group Channel pre-empted at E-IF. MSC_A is pre-empting.
Step 2: Group Channel pre-empted at E-IF. MSC_B is pre-empting.


Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 ( VGCS GID: 200) MS_A2 (VGCS GID: 200)

1 TS at E-IF



c) Test procedures

Step 1: Group Channel pre-empted at E-IF. MSC_A is pre-empting.
1.1 MS_A1 originates a 200 VGCS
in A-MSC_A
in A-MSC_A
MS_A4 receives the REC in R-MSC_B
MS_A2 is disconnected from the 200 VGCS
The 200 VGCS is released in R-MSC_B
pendent)
1.3 MS_A3 releases the REC MS_A4 is IDLE
1.4 CT_A1 kill the 200 VGCS MS_A1 is IDLE
in A-MSC_A
in R-MSC_B
The REC is not established, while there is only
one TS at E-IF.
The group channel of the 200 VGCS is pre-
empted at E-IF.
MS_A2 is IDLE
The 200 VGCS is released in R-MSC_B
pendent)
1.7 CT_A1 kill the 200 VGCS All participants and TSs at E-IF are IDLE



Network A Network B

R-MSC_A1 A-MSC_B1

1 TS at E-IF

Test procedure

Step 2: Group Channel pre-empted at E-IF. MSC_B is pre-empting.
in A-MSC_B
in A-MSC_B
MS_A3 receives the REC in R-MSC_A
The 200 VGCS is released in R-MSC_A
pendent)
2.4 CT_B1 kill the 200 VGCS MS_A2 is IDLE
in A-MSC_B


in R-MSC_B
The REC is not established, while there is only
one TS at E-IF.
empted at E-IF.
MS_A1 is IDLE
The 200 VGCS is released in R-MSC_A
pendent)
2.8 CT_B1 kill the 200 VGCS All participants and both TSs at E-IF are IDLE

d) Success criteria
The group channel of a VGCS call can be pre-empted at E-IF from any side by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.6 Link to a controller of a VGCS call is pre-empted at the E-IF between two networks
by PtP call

2.2.2
2.4.6
2.4.7
10.2.3

a) Purpose
Verify that the link to a controller of VGCS Call can be pre-empted by a PtP call at E-IF.

Step 1: Controller connection at E-IF pre-empted by PtP call. Group Call in MSC_A.
Step 2: Controller connection at E-IF pre-empted by PtP call. Group Call in MSC_B.

Network A Network B

MSC_A1 MSC_B1
CT_A1 (GCA_B1, VGCS GID: 204) CT_B1 (GCA_A1, VGCSD GID: 204)
CT_A2

1 TS at E-IF
CT_B2


c) Test procedures

Step 1: Controller connection at E-IF pre-empted by PtP call. Group Call in MSC_A.
MSC_A
CT_B1 receives the 204 VGCS from MSC_A
1.2 MS_A1 calls MS_A2 with Prio 3 The connection to CT_B1 is pre-empted at
E-IF
MS_A1 is connected with MS_A2
1.3 MS_A3 releases the VGCS call
MS_A1 releases the PtP call
All participants are IDLE
MSC_A
1.5 MS_A2 calls MS_A1 with Prio 3 The connection to CT_B1 is pre-empted at
E-IF
MSC_A
1.8 CT_A2 calls CT_B2 with Prio 3 The connection to CT_B1 is pre-empted at
E-IF
CT_A2 is connected with CT_B2
CT_A2 releases the PtP call
MSC_A
1.11 CT_B2 calls CT_A2 with Prio 3 The connection to CT_B1 is pre-empted at
E-IF
CT_B2 is connected with CT_A2
CT_B2 releases the PtP call


Step 2: Controller connection at E-IF pre-empted by PtP call. Group Call in MSC_B.
MSC_B
CT_A1 receives the 204 VGCS from MSC_B
2.2 MS_A1 calls MS_A2 with Prio 3 The connection to CT_A1 is pre-empted at
E-IF
MSC_B
2.5 MS_A2 calls MS_A1 with Prio 3 The connection to CT_A1 is pre-empted at
E-IF
MSC_B
2.8 CT_A2 calls CT_B2 with Prio 3 The connection to CT_A1 is pre-empted at
E-IF
CT_A2 is connected with CT_B2
CT_A2 releases the PtP call
MSC_B
2.11 CT_B2 calls CT_A2 with Prio 3 The connection to CT_A1 is pre-empted at
E-IF
CT_B2 is connected with CT_A2
CT_B2 releases the PtP call
2.19 Unblock all TSs at E-IF All resources are IDLE

d) Success criteria
The link to a controller of VGCS Call can be pre-empted by a PtP call at E-IF.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.7 Link to the originator as first talker of a VGCS call is pre-empted at the E-IF between
two networks by PtP call

2.4.6
2.4.7
10.2.3

a) Purpose
Verify that the dedicated link at E-IF can be pre-empted from any side by a PtP call.
Note: Some implementations do not support group channel pre-emption at E-IF.

Step 1: Link to the originator as first talker of a VGCS call is pre-empted at the E-IF between two
networks by a PtP call. Group Call originated in R-MSC_A.
Step 2: Link to the originator as first talker of a VGCS call is pre-empted at the E-IF between two
networks by a PtP call. Group Call originated in R-MSC_B.


Network A Network B

R-MSC_A1 A-MSC_B1

2 TSs at E-IF


c) Test procedures

Step 1: Link to the originator as first talker of a VGCS call is pre-empted at the E-IF be-
tween two networks by a PtP call. Group Call originated in R-MSC_A.
in R-MSC_A and keep the dedicated link
MS_A6 and CT_B1 receive the 204 VGCS
and parallel
The Dedicated link of MS_A5 is pre-empted
The group channel of the inter MSC group call
is pre-empted.
Group Call released in R-MSC_A
Group Call probably existing in A-MSC_B
MS_A6 can take the uplink.
in R-MSC_A and keep the dedicated link
MS_A6 and CT_B1 receive the 204 VGCS
and parallel
is pre-empted.
1.7 Release all calls All participants and both TSs at E-IF are IDLE


Test configuration for Step 2:

Network A Network B

A-MSC_A R-MSC_B

2 TSs at E-IF

Test procedure

Step 2: Link to the originator as first talker of a VGCS call is pre-empted at the E-IF be-
tween two networks by a PtP call. Group Call originated in R-MSC_B.
in R-MSC_B and keep the dedicated link
MS_A5 and CT_A1 receive the 204 VGCS
and parallel
The group channel of the inter MSC group
call is pre-empted.
Group Call probably existing in A-MSC_A


in R-MSC_B and keep the dedicated link
and parallel
is pre-empted.
2.7 Release all calls All participants and both TSs at E-IF are IDLE
2.8 Unblock the TSS at EIF All resources are IDLE
2.9 Set the Prio of the 204 VGCS to the right
value (prio 2).
The previous configuration is re-established.

d) Success criteria
The dedicated link of a VGCS call can be pre-empted at E-IF from any side by a PtP call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.8 Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between two
networks by PtP call


2.4.6
2.4.7
10.2.3

a) Purpose:
Verify that the Link between A-MSC and R-MSC of VGCS at E-IF can be pre-empted from any
side by a PtP call.
Note: Some implementations do not support E-IF pre-emption in this case.

Step 1: Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between two
networks by a PtP call. Group Call originated in A-MSC_A.
Step 2: Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between two
networks by a PtP call. Group Call originated in A-MSC_B.


Network A Network B

A-MSC_A1 R-MSC_B1
CT_A2

1 TS at E-IF



c) Test procedures

Step 1: Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between
two networks by a PtP call. Group Call originated in A-MSC_A.
in A-MSC_A
MS_A4 receives the 204 VGCS
1.2 CT_A2 calls MS_A2 with Prio 3 The group channel of the inter MSC group call
is pre-empted by MSC_A.
CT_A2 connected with MS_A2
Group Call released in R-MSC_B
1.3 MS_A3 releases the 204 VGCS
CT_A2 releases the PtP to MS_A2
All participants and TSs at E-IF are IDLE
in A-MSC_A
1.5 MS_A2 calls MS_A1 with Prio 3 The group channel of the inter MSC group call
is pre-empted by MSC_B.
Group Call released in R-MSC_B
MS_A2 releases the PtP to MS_A1



Network A Network B

R-MSC_A1 A-MSC_B1
CT_A2

1 TS at E-IF

Test procedure

Step 2: Link between A-MSC and R-MSC of VGCS call is pre-empted at the E-IF between
two networks by a PtP call. Group Call originated in A-MSC_B.
in A-MSC_B
2.2 CT_A2 calls MS_A2 with Prio 3 The group channel of the inter MSC group call
is pre-empted by MSC_A.
CT_A2 connected with MS_A2
CT_A2 releases the PtP to MS_A2
in A-MSC_B


2.5 MS_A2 calls MS_A1 with Prio 3 The group channel of the inter MSC group call
is pre-empted by MSC_B.
MS_A2 releases the PtP to MS_A1

d) Success criteria
The Link between A-MSC and R-MSC of VGCS at E-IF can be pre-empted from any side by a
PtP call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.9 Inter MSC handover of a point to point voice call with MLPP pre-emption at E-IF


2.4.1

a) Purpose:
Verify that the PtP connection at E-IF can be pre-empted during an intra PLMN / inter MSC-HO
from any side by another PtP call with higher priority.


Network A Network A

MSC_A1 MSC_A2
MS_A1 MS_A2
MS_A3
MS_A4

1 TS at E-IF

c) Test procedures

1 MS_A1 calls MS_A2 with prio 4 MS_A1 connected with MS_A2
There are no IDLE TSs at E-IF
3 MS_A3 moves to Cell_A2 and than back
to Cell_A1
The connection MS_A1 to MS_A2 is pre-
empted at E-IF.


5 MS_A3 moves to Cell_A2 The connection MS_A1 to MS_A2 is pre-
empted at E-IF.
6 MS_A3 releases the call to MS_A4 All participants are IDLE
7 MS_A4 moves to Cell_A2 MS_A3 and MS_A4 are placed in Cell_A2
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
13 MS_A3 releases the call to MS_A4 All participants are IDLE
14 Unlock the TSs at E-IF All resources are IDLE

d) Success criteria
A PtP connection at E-IF can be pre-empted during an intra PLMN / inter MSC-HO from any side
by another PtP call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.10 Inter MSC handover of a circuit switched data call with MLPP pre-emption at E-IF


2.4.1

a) Purpose:
from any side by a data call with higher priority.


Network A Network A

MSC_A1 MSC_A2
MS_A1 MS_A2
MS_A3
MS_A4

1 TS at E-IF

c) Test procedures

2 MS_A3 originates a data call (UDI, 9600
Bit/s, transparent) to MS_A4 with prio 1


to Cell_A1
empted at E-IF.
empted at E-IF.
6 MS_A4 moves to Cell_A2 There is one TS IDLE at E-IF
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
11 MS_A3 releases the data call to MS_A4 All participants are IDLE
12 Unlock the TSs at E-IF All resources are IDLE

d) Success criteria
A PtP connection at E-IF can be pre-empted during an intra PLMN / inter MSC-HO from any side
by a data call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.11 Inter MSC handover of a railway emergency call originator with pre-emption at E-IF

2.4.1

a) Purpose:
of the REC DCH from any side.

b) Test configuration/ initial conditions
Step 1: Inter MSC handover of a railway emergency call originator with pre-emption at E-IF.
MSC_A1 is the A-MSC.

Test configuration for Step 1

Network A Network A

A-MSC_A1 R-MSC_A2

3 TS at E-IF



c) Test procedures

1.1 MS_A1 calls MS_A2 with prio 4 MS_A1 connected with MS_A2
1.3 MS_A5 originates the REC in A-MSC_A1
and keep the DCH
All TSs are busy at E-IF
1.4 MS_A5 moves to Cell_A2 and than back
to Cell_A1
empted at E-IF.
to Cell_A1
empted at E-IF.
1.7 MS_A5 releases the REC MS_A5 and MS_A6 are IDLE
1.9 MS_A6 originates the REC in R-MSC_A2
and keep the DCH
empted at E-IF.
to Cell_A2
empted at E-IF.
1 TS is IDLE at E-IF.
to Cell_A2
empted at E-IF.
1 TSs are IDLE at E-IF.
1.13 MS_A6 releases the REC All participants are IDLE
1.14 Unlock the TSs at E-IF All resources are IDLE



Network A Network A

R-MSC_A1 A-MSC_A2

3 TS at E-IF

Test procedure

2.3 MS_A6 originates the REC in A-MSC_A2
and keep the DCH
All TSs are busy at E-IF
to Cell_A4
empted at E-IF.
to Cell_A4
empted at E-IF.


2.7 MS_A6 releases the REC MS_A5 and MS_A6 are IDLE
2.9 MS_A5 originates the REC in R-MSC_A1
and keep the DCH
empted at E-IF.
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
2.13 MS_A5 releases the REC All participants are IDLE

d) Success criteria
A PtP connection can be pre-empted from any side at E-IF during an intra PLMN / inter MSC-HO
of the REC DCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.12 Inter MSC handover of a VGCS dedicated channel with MLPP pre-emption at E-IF

2.4.1

a) Purpose:
of the VGCS DCH from any side.
b) Test configuration
Step 1: Inter MSC / intra PLMN handover of a VGCS dedicated channel with MLPP pre-emption
at E-IF. MSC_A1 is the A-MSC.
Step 2: Inter MSC / intra PLMN handover of a VGCS dedicated channel with MLPP pre-emption
at E-IF. MSC_A2 is the A-MSC.

Test configuration / initial conditions for Step 1

Network A Network A

A-MSC_A1 R-MSC_A2
MS_A5 (VGCS GID: 200)

3 TS at E-IF



c) Test procedures

Step 1: Inter MSC handover of a VGCS dedicated channel with MLPP pre-emption at E-IF.
1.3 MS_A5 originates the VGCS call in A-
MSC_A1 and keep the DCH
MS_A6 receives the VGCS call
to Cell_A1
empted at E-IF.
to Cell_A1
empted at E-IF.
1.7 MS_A5 releases the VGCS call MS_A5 and MS_A6 are IDLE
1.9 MS_A6 originates the VGCS call in R-
empted at E-IF.
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
1.13 MS_A6 releases the VGCS call All participants are IDLE



Network A Network A

R-MSC_A1 A-MSC_A2

3 TS at E-IF

Test procedure

Step 2: Inter MSC handover of a VGCS dedicated channel with MLPP pre-emption at E-IF.
2.3 MS_A6 originates the VGCS call in A-
to Cell_A4
empted at E-IF.
to Cell_A4
empted at E-IF.
2.7 MS_A6 releases the VGCS call MS_A5 and MS_A6 are IDLE


2.9 MS_A5 originates the VGCS call in R-
empted at E-IF.
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
2.13 MS_A5 releases the VGCS call All participants are IDLE

d) Success criteria
A PtP connection at E-IF can be pre-empted from any side during an intra PLMN / inter MSC-HO
of the VGCS DCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.5.13 Inter MSC handover of a VBS originator channel with MLPP pre-emption at E-IF

2.4.1

a) Purpose:
Verify that the PtP connection at E-IF can be pre-empted during an intra PLMN / inter MSC-HO of
the VBS DCH from any side.

Step 1: Intra PLMN / Inter MSC handover of a VBS originator channel with MLPP pre-emption at
E-IF. MSC_A1 is the A-MSC.
Step 2: Intra PLMN / Inter MSC handover of a VBS originator channel with MLPP pre-emption at
E-IF. MSC_A2 is the A-MSC.


Network A Network A

A-MSC_A1 R-MSC_A2
MS_A5 (VBS GID: 202)

3 TS at E-IF



c) Test procedures

Step 1: Inter MSC handover of a VBS originator channel with MLPP pre-emption at E-IF.
1.3 MS_A5 originates the VBS call in A-
MSC_A1
MS_A6 receives the VBS call
to Cell_A1
empted at E-IF.
to Cell_A1
empted at E-IF.
1.7 MS_A5 releases the VBS call MS_A5 and MS_A6 are IDLE
1.9 MS_A6 originates the VBS call in R-
MSC_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
1.13 MS_A6 releases the VBS call All participants are IDLE



Network A Network A

R-MSC_A1 A-MSC_A2

3 TS at E-IF

Test procedure

Step 2: Inter MSC handover of a VBS originator channel with MLPP pre-emption at E-IF.
2.3 MS_A6 originates the VBS call in A-
MSC_A2
to Cell_A4
empted at E-IF.
to Cell_A4
empted at E-IF.
2.7 MS_A6 releases the VBS call MS_A5 and MS_A6 are IDLE


2.9 MS_A5 originates the VBS call in R-
MSC_A1
empted at E-IF.
to Cell_A2
empted at E-IF.
to Cell_A2
empted at E-IF.
2.13 MS_A5 releases the VBS call All participants are IDLE

d) Success criteria
A PtP connection at E-IF can be pre-empted from any side during an intra PLMN / inter MSC-HO
of the VBS DCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6 Railway Emergency Call (REC), Late Entry (LE)
5.6.1 REC call setup by a service subscriber (non-roaming case)


2.5.1
9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1
13.2.2
13.3.3

a) Purpose
Verify a service subscriber can originate and close a Railway Emergency Call (REC) with GID
299.


Network A


CoO=Cell_A1



c) Test procedure

1) MS_A1 originates a REC (GID 299). REC (GID 299) is correctly established.
A dedicated channel (DCH) and a group call
channel (GCCH) are allocated in Cell_A1.
MS_A2 is notified about the incoming REC
(GID 299) on the NCH.
CT_A1 is notified about the incoming REC
(GID 299) and the Group Call Reference is
displayed on CT terminal.
2) CT_A1 automatically accepts the REC
(GID 299).
CT_A1 automatically joins the REC (GID
299).
CT_A1 has voice path to all mobile subscrib-
ers. If one mobile subscriber takes the uplink
of the group call on GCCH the downlink to
the talking mobile subscriber will be muted.
The talking mobile subscriber is not able to
listen to the announcement of CT_A1.
3) MS_A2 automatically accepts the REC
(GID 299).
MS_A2 automatically joins the REC (GID
299) in group receive mode and is able to
4) MS_A1 takes the uplink on DCH. MS_A1 has voice path on DCH.
MS_A2 and CT_A1 are able to listen to the
announcement of MS_A1.
5) MS_A1 releases the uplink on DCH. Uplink free message is send in Cell_A1 and
the DCH is correctly released.
6) MS_A1 takes the uplink on GCCH. MS_A1 has voice path on GCCH. MS_A2
and CT_A1 are able to listen to the an-
nouncement of MS_A1.
MS_A1 is not able to listen to the announce-
ment of CT_A1.
MS_A2 still able to listen to the announce-
ment of CT_A1.
7) CT_A1 un-mutes the downlink to MS_A1
by using the un-mute sequence (dialling
###).
MSC_A1 sends set parameter message and
MS_A1 un-mutes its downlink to get two-way
voice path on GCCH.
MS_A1 and MS_A2 are able to listen to the
announcement of CT_A1.


8) CT_A1 mutes the downlink to MS_A1 by
using the mute sequence (dialling #**).
MS_A1 mutes its downlink.
ment of CT_A1.
ment of CT_A1.
CT_A1 still able to listen to the announce-
ment of MS_A1.
9) MS_A1 releases the uplink on GCCH. Uplink free message is send in Cell_A1 and
uplink is correctly released.
10) MS_A2 takes the uplink on GCCH. MS_A2 has voice path on GCCH. MS_A1
and CT_A1 are able to listen to the an-
nouncement of MS_A2.
ment of CT_A1.
ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
ment of CT_A1.
CT_A1 still able to listen to the announce-
ment of MS_A2.
14) MS_A1 releases the REC (GID 299). REC (GID 299) is released. All related re-



d) Success criteria
MS_A1 is able to originate and close a Railway Emergency Call (REC) with GID 299.
MS_A1 is able to get the uplink on DCH and GCCH.
MS_A2 is able to receive the Railway Emergency Call (REC) with GID 299 and is able to get the
uplink on GCCH.
CT_A1 is able to receive the Railway Emergency Call (REC) with GID 299 and able to un-mute /
mute the downlink to the talking mobile subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.2 REC call setup by a controller


2.5.1
9.3.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3

a) Purpose
Verify a controller can originate and close a Railway Emergency Call (REC) with GID 299.


Network A


CoO=Cell_A1



c) Test procedure

1) CT_A1 originates a REC (GID 299) by
dialling.
50 + <GCA> + <GID>
REC (GID 299) is correctly established.
A group call channel (GCCH) is allocated in
Cell_A1. Uplink still free in Cell_A1.
ers. If one mobile subscriber takes the uplink of
the group call on GCCH the downlink to the
talking mobile subscriber will be muted. The
talking mobile subscriber is not able to listen to
the announcement of CT_A1.
2) MS_A1 automatically accept the REC
(GID 299).
MS_A1 automatically joins the REC (GID 299)
in group receive mode.
CT_A1 has voice path and MS_A1 is able to
3) MS_A1 takes the uplink on GCCH. MS_A1 has voice path on GCCH.
CT_A1 is able to listen to the announcement of
MS_A1.
ment of CT_A1.
###).
voice path on GCCH.
MS_A1 is able to listen to the announcement
of CT_A1.
ment of CT_A1.
CT_A1 still able to listen to the announcement
of MS_A1.
7) CT_A1 releases the REC (GID 299) by
using the kill sequence (dialling ***).
REC (GID 299) is released. All related re-


d) Success criteria
CT_A1 is able to originate and close a Railway Emergency Call (REC) with GID 299 and able to
un-mute/mute the downlink to the talking mobile subscriber on GCCH.
MS_A1 is able to receive the Railway Emergency Call (REC) with GID 299 and able to get the
uplink on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.3 REC notification and joining (non-roaming case)


2.5.1
9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3
13.4.1
13.4.2

a) Purpose
Verify that mobile subscribers and controllers will be notified about incoming Railway Emergency
Calls (REC) and can join them.

CT_A1, CT_A2 and CT_A3 are connected to network A.
MS_A3 and MS_A4 are shunting mobiles in shunting mode and not registered to a functional
number (FN).

Step 1: REC (GID 299) call setup by service subscriber MS_A1.




Network A

CT_A3 (no VGCS / VBS subscriber)

CoO=Cell_A1

GCA_A1, REC GID: 299, 599
Prio 0


c) Test procedure

All other MS will not respond to the NCH notifi-
cation.
displayed on the CT terminal.
CT_A2 and CT_A3 did not receive the REC
(GID 299).
(GID 299).
CT_A1 automatically joins the REC (GID 299).
(GID 299).
ment of CT_A1.
MS_A2 still able to listen to the announcement
of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
10) MS_A2 takes the uplink on GCCH. MS_A2 has voice path on GCCH. MS_A1 and
CT_A1 are able to listen to the announcement
of MS_A2.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
14) MS_A1 releases the REC (GID 299) REC (GID 299) is released. All related re-


cation.
displayed on the CT terminal.
CT_A1 and CT_A3 did not receive the REC
(GID 599).
2) CT_A2 automatically accept the REC
(GID 599).
3) MS_A4 automatically accept the REC
(GID 599).
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.


ment of CT_A2.
of CT_A2.
of MS_A3.
10) MS_A4 takes the uplink on GCCH. MS_A4 voice path on GCCH.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A4.

d) Success criteria
MS_A1 is able to establish and to close the Railway Emergency Call (REC) with GID 299 and
able to get the uplink on DCH and GCCH. MS_A1 did not receive the Railway Emergency Call
(REC) with GID 599.


MS_A2 is able to receive and join the Railway Emergency Call (REC) with GID 299 and able to
get the uplink on GCCH. MS_A2 did not receive the Railway Emergency Call (REC) with GID
599.
MS_A3 is able to establish and to close the Railway Emergency Call (REC) with GID 599 and
able to get the uplink on DCH and GCCH. MS_A3 did not receive the Railway Emergency Call
(REC) with GID 299.
MS_A4 is able to receive and join the Railway Emergency Call (REC) with GID 599 and able to
get the uplink on GCCH. MS_A4 did not receive the Railway Emergency Call (REC) with GID
299.
CT_A1 is able to receive and join the Railway Emergency Call (REC) with GID 299 and able to
un-mute/mute the downlink to the talking mobile subscriber on GCCH. CT_A1 did not receive the
Railway Emergency Call (REC) with GID 599.
un-mute/mute the downlink to the talking mobile subscriber on GCCH. CT_A2 did not receive the
Railway Emergency Call (REC) with GID 299.
MS_A5 and CT_A3 did not receive the Railway Emergency Calls (REC) with GID 299 or GID 599.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.4 REC acknowledgement (non-roaming case)


2.5.1
13.4.5
13.4.6
2.5.1
13.5.3
13.5.5
13.5.7
13.5.9
13.5.10

a) Purpose
Verify the acknowledgements successfully send after Railway Emergency Call (REC) with GID
299 is closed. The acknowledgement center must receive acknowledgements from all mobile
subscribers involved in Railway Emergency Call (REC) with GID 299.

The acknowledgment center is configured and connected to MSC_A1.

Network A


c) Test procedure

CoO=Cell_A1



(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.


11) MS_A1 and MS_A2 are sending ac-
knowledgements to the acknowledge-
ment center.
Acknowledgements successfully send to the
acknowledgement center.
Check the A-interface trace files for setup
messages to 1612 from each mobile sub-
scribe involved in REC (GID 299).
12) Check the logs of the acknowledgement
center
Acknowledgements successfully received with
the right data such as talker flag from all mo-
bile subscribers involved in REC (GID 299).

d) Success criteria
Acknowledgements successfully send to the acknowledgement center with the correct data inside
from MS_A1 and MS_A2.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.5 REC call setup by a service subscriber (roaming case)


2.5.1
9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1
13.2.2
13.3.3

a) Purpose
Verify a roaming service subscriber can originate and close a Railway Emergency Call (REC) with
GID 299.


Step 1: REC (GID 299) call setup by service subscriber MS_B2 in network A (MSC_A1 Anchor).
Step 2: REC (GID 299) call setup by service subscriber MS_A2 in network B (MSC_A1 Anchor).
Step 3: REC (GID 299) call setup by service subscriber MS_B2 in network A (MSC_B1 Anchor).
Step 4: REC (GID 299) call setup by service subscriber MS_A2 in network B (MSC_B1 Anchor).




Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (REC GID: 299) MS_B1 (REC GID: 299)
MS_B2 (REC GID: 299) MS_A2 (REC GID: 299)

c) Test procedure

Step 1: REC (GID 299) call setup by service subscriber MS_B2 in network A (MSC_A1 An-
chor)
1) MS_B2 originates a REC (GID 299). REC (GID 299) is correctly established.
Cell_B1.
MS_A1, MS_B1 and MS_A2 are notified about
the incoming REC (GID 299) on the NCH.
CT_A1 and CT_B1 are notified about the in-
coming REC (GID 299) and the Group Call
Reference is displayed on CT terminals.



2) MS_A1, MS_B1 and MS_A2 automati-
cally accepting the REC (GID 299).
MS_A1, MS_B1 and MS_A2 automatically
joining the REC (GID 299) in group receive
mode.
3) CT_A1 and CT_B1 automatically accept-
ing the REC (GID 299).
CT_A1 and CT_B1 automatically joining the
REC (GID 299).
CT_A1 and CT_B1 have voice path to all mo-
bile subscribers. If one mobile subscriber takes
the uplink of the group call on GCCH the
downlink to the talking mobile subscriber will
be muted. The talking mobile subscriber is not
able to listen to the announcement of CT_A1
and CT_B1.
4) MS_B2 takes the uplink on DCH. MS_B2 has voice path on DCH.
MS_A1, MS_B1 and MS_A2, CT_A1 and
CT_B1 are able to listen to the announcement
of MS_B2.
5) MS_B2 releases the uplink on DCH. Uplink free message is send for REC (GID
299) in Cell_A1 and Cell_B1, the DCH in
Cell_A1 is correctly released.
6) MS_B2 takes the uplink on GCCH. MS_B2 has voice path on GCCH.
of MS_B2.
MS_B2 is not able to listen to the announce-
ment of CT_A1 and CT_B1.
MS_A1, MS_B1 and MS_A2 still able to listen
to the announcement of CT_A1 and CT_B1.
7) CT_A1 un-mutes the downlink to MS_B2
###).
MS_B2 un-mutes its downlink to get two-way
voice path on GCCH.
MS_A1, MS_A2, MS_B1 and MS_B2 are able
to listen to the announcement of CT_A1 and
CT_B1.
8) CT_A1 mutes the downlink to MS_B2 by
MS_B2 mutes its downlink.
CT_A1 and CT_B1 still able to listen to the
announcement of MS_B2.


9) CT_B1 un-mutes the downlink to MS_B2
###).
voice path on GCCH.
CT_B1.
10) CT_B1 mutes the downlink to MS_B2 by
MS_A1, MS_A2, MS_B1 still able to listen to
the announcement of CT_A1 and CT_B1.
11) MS_B2 releases the uplink on GCCH. Uplink free message is send for REC (GID
299) in Cell_A1 and Cell B1, the uplink is cor-
rectly released.
MS_A1, MS_B1 and MS_B2, CT_A1 and
of MS_A2.
MS_A1, MS_B1 and MS_B2 still able to listen
###).
MSC_A1 sends information about the downlink
attached status to MSC_B1. MSC_B1 sends
set parameter message and MS_A2 un-mutes
its downlink to get two-way voice path on
GCCH.
CT_B1.
set parameter message and MS_A2 mutes its
downlink.


15) CT_B1 un-mutes the downlink to MS_A2
###).
GCCH.
CT_B1.
16) CT_B1 mutes the downlink to MS_A2 by
downlink.
MS_A1, MS_B1, MS_B2 still able to listen to
17) MS_A2 releases the uplink on GCCH. Uplink free message is send for REC (GID
rectly released.
18) MS_B2 releases the REC (GID 299). REC (GID 299) is released. All related re-


Step 2: REC (GID 599) call setup by service subscriber MS_A2 in network B (MSC_A1 An-
chor).
channel (GCCH) are allocated in Cell_B1.
Cell_A1.
MS_A1, MS_B1 and MS_B2 are notified about
2) MS_A1, MS_B1 and MS_B2 automati-
MS_A1, MS_B1 and MS_B2 automatically
mode.
REC (GID 299).
and CT_B1.
of MS_A2.
5) MS_A2 releases the uplink on DCH. Uplink free message is send for REC (GID
Cell_B1 is correctly released.
of MS_A2.


###).
GCCH.
MS_A1, MS_A2, MS_B1 and MS_A2 are able
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.
rectly released.


of MS_B2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A1, MS_B1, MS_A2 still able to listen to
rectly released.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 3: REC (GID 299) call setup by service subscriber MS_B2 in network A (MSC_B1 An-
chor).
Cell_B1.
mode.



REC (GID 299).
and CT_B1.
of MS_B2.
of MS_B2.
###).
MSC_B1 sends information about the downlink
attached status to MSC_A1. MSC_A1 sends
set parameter message and MS_B2 un-mutes
GCCH.
CT_B1.
set parameter message and MS_B2 mutes its
downlink.


###).
GCCH.
CT_B1.
downlink.
rectly released.
of MS_A2.
###).
MSC_B1 sends set parameter message and
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
rectly released.


Step 4: REC (GID 599) call setup by service subscriber MS_A2 in network B (MSC_B1 An-
chor).
Cell_A1.
mode.
REC (GID 299).
and CT_B1.
of MS_A2.
of MS_A2.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
rectly released.
of MS_B2.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.
rectly released.



d) Success criteria
MS_A2 is able to originate and close a Railway Emergency Call (REC) with GID 299 when roam-
ing in network B.
MS_B2 is able to originate and close a Railway Emergency Call (REC) with GID 299 when roam-
ing in network A.
CT_A1 is connected to MSC_A1 and is able to originate, receive and close Railway Emergency
Call (REC) with GID 299. CT_A1 is also able to un-mute/mute the downlink to the talking mobile
subscriber on GCCH.
CT_B1 is connected to MSC_B1 and is able to originate, receive and close Railway Emergency
Call (REC) with GID 299. CT_B1 is also able to un-mute/mute the downlink to the talking mobile
subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.6 REC notification and joining (roaming case)


2.5.1
9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
2.5.1
13.2.2
13.2.3
13.3.1
13.3.3
13.4.1
13.4.2

a) Purpose
Verify that roaming mobile subscribers and controllers will be notified about incoming Railway
Emergency Calls (REC) and can join them.

MS_A2, MS_A5, MS_B2 and MS_B5 are shunting mobiles in shunting mode and not registered
to a functional number (FN).
CT_A1, CT_A2 and CT_A3 are connected to network A.
CT_B1, CT_B2 and CT_B3 are connected to network B.

Step 1: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_A1 Anchor).
Step 3: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_A1 Anchor).
Step 5: REC (GID 299) call setup by CT_A1 in network A (MSC_A1 Anchor).
Step 6: REC (GID 299) call setup by CT_B1 in network B (MSC_A1 Anchor).
Step 7: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_B1 Anchor).
Step 9: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_B1 Anchor).
Step 11: REC (GID 299) call setup by CT_A1 in network A (MSC_B1 Anchor).
Step 12: REC (GID 299) call setup by CT_B1 in network B (MSC_B1 Anchor).




Network A Network B

A-MSC_A1 R-MSC_B1
CT_A3 (no VGCS / VBS subscriber) CT_B2 (no VGCS / VBS subscriber)

c) Test procedure


GCA_AB1, REC GID: 299, 599 Prio 0


Step 1: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_A1 An-
chor).
Cell_B1.
cation.
Reference is displayed on the CT terminals.
CT_A2, CT_A3, CT_B2 and CT_B3 did not
receive the REC (GID 299).
mode.
REC (GID 299).
and CT_B1.
MS_A4, MS_B1, MS_B4, CT_A1 and CT_B1
are able to listen to the announcement of
MS_A1.
Cell_B1. The DCH in Cell_A1 is correctly re-
leased.


MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
Cell_B1. The uplink is correctly released.


MS_A1, MS_A4, MS_B1, CT_A1 and CT_B1
MS_B4.
MS_A1, MS_A4 and MS_B1 still able to listen
to the announcement of CT_A1 and CT_B1
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
17) MS_B4 releases the uplink on GCCH. Uplink free message is send in Cell_A1 and


MS_B1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_A4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.

chor).
Cell_B1.
MS_A1, MS_A4 and MS_B1 are notified about
cation.


2) MS_A1, MS_A4 and MS_B1 automati-
MS_A1, MS_A4 and MS_B1 automatically
mode.
REC (GID 299).
and CT_B1.
MS_B4.
5) MS_B4 releases the uplink on DCH. Uplink free message is send in Cell_A1 and
leased.
MS_B4.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_A1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_B1.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_A4.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
30) MS_B4 releases the REC (GID 299) REC (GID 299) is released. All related re-


Step 3: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_B1 An-
chor).
Cell_A1.
cation.
mode.
REC (GID 299).
and CT_B1.
MS_B1.
leased.


MS_B1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B4.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_A4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
MS_A1, MS_MS_A4, MS_B1 and MS_B4 are
and CT_B1.
downlink.

chor).
Cell_A1.
cation.


mode.
REC (GID 299).
and CT_B1.
MS_A4.
leased.
MS_A4.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
MS_A1.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_B4.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_B1.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
and CT_B1.
downlink.


Step 5: REC (GID 299) call setup by CT_A1 in network A (MSC_A1 Anchor).
1) CT_A1 originates a REC (GID 299).

Group call channels (GCCH) are allocated in
Cell_A1 and Cell_B1.
MS_A1, MS_A4, MS_B1 and MS_B4 are noti-
fied about the incoming REC (GID 299) on the
NCH.
cation.
CT_B1 is notified about the incoming REC
displayed on the CT terminals.
and CT_B1.
2) MS_A1, MS_A4, MS_B1 and MS_B4
automatically accepting the REC (GID
299).
MS_A1, MS_A4, MS_B1 and MS_B4 auto-
matically joining the REC (GID 299) in group
receive mode.
3) CT_B1 automatically accepts the REC
(GID 299).
CT_B1 automatically joins the REC (GID 299).
and CT_B1.
4) MS_A1 takes the uplink on GCCH. MS_A1 has two-way voice path on GCCH.
MS_A1.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
10) MS_B4 takes the uplink on GCCH. MS_B4 has two-way voice path on GCCH.
MS_B4.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_B1.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
and CT_B1.
downlink.


MS_A4.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
28) CT_A1 closes the REC (GID 299) using
kill sequence (dialling ***).

Step 6: REC (GID 299) call setup by CT_B1 in network B (MSC_A1 Anchor).
1) CT_B1 originates a REC (GID 299).

NCH.
cation.
and CT_B1.
299).
receive mode.


(GID 299).
and CT_B1.
MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B4.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B1.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
and CT_B1.
downlink.
MS_A4.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
28) CT_B1 closes the REC (GID 299) using




Network A Network B

R-MSC_A1 A-MSC_B1
CT_A3 (no VGCS / VBS subscriber) CT_B2 (no VGCS / VBS subscriber)

Test procedure


GCA_AB1, REC GID: 299, 599 Prio 0


Step 7: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_B1 An-
chor).
Cell_B1.
cation.
mode.
REC (GID 299).
and CT_B1.
MS_A1.
leased.


MS_A1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_B4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_B1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_A4.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.

chor).
Cell_B1.
cation.
mode.


REC (GID 299).
and CT_B1.
MS_B4.
leased.
MS_B4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_A1.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
MS_B1.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A4.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


chor).
Cell_A1.
cation.
mode.
REC (GID 299).
and CT_B1.
MS_B1.
leased.


MS_B1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_A1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_B4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_A4.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
and CT_B1.

chor).
Cell_A1.
cation.
mode.


REC (GID 299).
and CT_B1.
MS_A4.
leased.
MS_A4.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_A1.
###).
GCCH.
CT_B1.
downlink.


###).
voice path on GCCH.
CT_B1.
downlink.
MS_B4.
###).
GCCH.
CT_B1.


downlink.
###).
voice path on GCCH.
CT_B1.
downlink.
MS_B1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
and CT_B1.
sing the mute sequence (dialling #**).


Step 11: REC (GID 299) call setup by CT_A1 in network A (MSC_B1 Anchor).
1) CT_A1 originates a REC (GID 299).

NCH.
cation.
and CT_B1.
299).
receive mode.
(GID 299).
and CT_B1.
MS_A1.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


MS_B4.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_B1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
and CT_B1.


MS_A4.
###).
voice path on GCCH.
CT_B1.
downlink.
###).
voice path on GCCH.
CT_B1.


28) CT_A1 closes the REC (GID 299) using

Step 12: REC (GID 299) call setup by CT_B1 in network B (MSC_B1 Anchor).
1) CT_B1 originates a REC (GID 299).

NCH.
cation.
and CT_B1.
299).
receive mode.


(GID 299).
and CT_B1.
MS_A1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


MS_B4.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_B1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
and CT_B1.
MS_A4.
###).
voice path on GCCH.
CT_B1.
downlink.


###).
voice path on GCCH.
CT_B1.
28) CT_B1 closes the REC (GID 299) using

d) Success criteria
MS_A1 and MS_A4 are able to establish and to close the Railway Emergency Call (GID 299) and
able to get the uplink on DCH and GCCH.
MS_A2 and MS_A5 did not receive the Railway Emergency Call (GID 299).
MS_B1 and MS_B4 are able to establish and to close the Railway Emergency Call (GID 299) and
able to get the uplink on DCH and GCCH. MS_B1 and MS_B4 did not receive the Railway Emer-
gency Call (GID 599).
MS_B2 and MS_B5 did not receive the Railway Emergency Call (GID 299).
CT_A1 is able to receive and join the Railway Emergency Call (GID 299) and is able to un-
mute/mute the downlink to the talking mobile subscriber on GCCH. CT_A1 did not receive the
Railway Emergency Call (GID 599).
CT_A2 did not receive the Railway Emergency Call (GID 299).
CT_B1 is able to receive and join the Railway Emergency Call (GID 299) and able to un-
mute/mute the downlink to the talking mobile subscriber on GCCH. CT_B1 did not receive the
Railway Emergency Call (GID 599).
CT_B2 did not receive the Railway Emergency Call (GID 299).
MS_A3, MS_A6, MS_B3, MS_B6, CT_A3 and CT_B3 did not receive the Railway Emergency
Calls (GID 299, GID 599)



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.7 REC acknowledgement (roaming case)


2.5.1
13.4.5
13.4.6
2.5.1
13.5.3
13.5.5
13.5.7
13.5.9
13.5.10

a) Purpose
Verify the acknowledgements successfully send after Railway Emergency Call (REC) with GID
299 is closed. The acknowledgement center must receive acknowledgements from all mobile
subscribers involved in Railway Emergency Call (REC) with GID 299.

The acknowledgment center of network A is configured and connected to MSC_A1.
The acknowledgment center of network B is configured and connected to MSC_B1.

Step 1: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_A1 Anchor).
Step 3: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_A1 Anchor).
Step 5: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_B1 Anchor).
Step 7: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_B1 Anchor).



Test configuration for Step 1 to 4

Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_A1 An-
chor).
Cell_B1.
mode.



REC (GID 299).
and CT_B1.
MS_A1.
leased.
MS_A1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_B2.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_B1.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_A2.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
31) MS_A1 and MS_B2 are sending ac-
ment center of network A.
acknowledgement center of network A. Check
the A-interface trace files for setup messages
to 1612 from each mobile subscribe involved
in REC (GID 299).
32) MS_B1 and MS_A2 are sending ac-
ment center of network B.
acknowledgement center of network B. Check
in REC (GID 299).


center of Network A.
the right data such as talker/originator informa-
tion from all mobile subscribers involved in
REC (GID 299).
center of Network B.
REC (GID 299).

chor).
Cell_B1.
mode.
REC (GID 299).
and CT_B1.
MS_B2.
leased.


MS_B2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_A2.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).


Step 3: REC (GID 299) call setup by service subscriber MS_B1 in network B (MSC_A1 An-
chor).
Cell_A1.
mode.
REC (GID 299).
and CT_B1.
MS_B1.
leased.
MS_B1.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.


MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_A2.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
and CT_B1.


downlink.
in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).


chor).
Cell_A1.
mode.
REC (GID 299).
and CT_B1.
MS_A2.
leased.
MS_A2.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.


MS_A1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.


MS_B1.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
and CT_B1.


downlink.
in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).




Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 5: REC (GID 299) call setup by service subscriber MS_A1 in network A (MSC_B1 An-
chor).
Cell_B1.
mode.



REC (GID 299).
and CT_B1.
MS_A1.
leased.
MS_A1.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_B2.
###).
GCCH.
CT_B1.


downlink.
###).
GCCH.
CT_B1.
downlink.
MS_B1.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A2.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
in REC (GID 299).
in REC (GID 299).


REC (GID 299).
REC (GID 299).

chor).
Cell_B1.
mode.
REC (GID 299).
and CT_B1.
MS_B2.
leased.


MS_B2.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_A1.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
MS_B1.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
MS_A2.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).


chor).
Cell_A1.
mode.
REC (GID 299).
and CT_B1.
MS_B1.
leased.
MS_B1.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A1.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.


MS_B2.
###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.


downlink.
MS_A2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
and CT_B1.


in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).


chor).
Cell_A1.
mode.
REC (GID 299).
and CT_B1.
MS_A2.
leased.
MS_A2.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A1.


###).
GCCH.
CT_B1.
downlink.
###).
voice path on GCCH.
CT_B1.
downlink.


MS_B2.
###).
GCCH.
CT_B1.
downlink.
###).
voice path on GCCH.
CT_B1.
downlink.


MS_B1.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
and CT_B1.
sing the mute sequence (dialling #**).


in REC (GID 299).
in REC (GID 299).
REC (GID 299).
REC (GID 299).

d) Success criteria
Acknowledgements successfully send to the acknowledgement center of network A with the cor-
rect data inside from MS_A1 and MS_B2.
Acknowledgements successfully send to the acknowledgement center of network B with the cor-
rect data inside from MS_B1 and MS_A2.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.8 C-OTDI check


2.2.1
2.5.1
13.3.2
2.2.1
2.5.1
13.4.6
13.4.7

a) Purpose
Verify that the compressed originator to dispatcher information (C-OTDI) is send correctly and
displayed at the controller terminal (CT).

Network A is configured to support immediate setup 2 (Rel. 99) for Railway Emergency Calls
(REC).
MS_A1 is registered to a functional number (FN).

Network A


c) Test procedure

CoO=Cell_A1



1) MS_A1 originates a REC (GID 299). MS_A1 originates the REC (GID 299) using
immediate setup.
Check the immediate setup2 message content
if it includes the functional number (FN) as
compressed originator to dispatcher informa-
tion (C-OTDI) at the user to user information
element (UUIE) field.
(GID 299) and the functional number (FN)
taken from the user to user information ele-
ment (UUIE) field is displayed on CT terminal.
(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.



d) Success criteria
The immediate setup2 message of MS_A1 includes the functional number (FN) as compressed
originator to dispatcher information (C-OTDI) at the user to user information element (UUIE) field.
The compressed originator to dispatcher information (C-OTDI) is send correctly and displayed at
the controller terminal (CT). CT_A1 is also able to un-mute/mute the downlink to the talking mo-
bile subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.9 LE idle mode (non-roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
Verify that mobile subscribers receive the notification on the NCH about ongoing Railway Emer-
gency Calls (REC) and automatically join in group receive mode after successful cell reselection
in idle mode.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1




c) Test procedure

(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
14) MS_A3 moves form Cell_A2 to Cell_A1. MS_A3 performs a cell reselection from
Cell_A2 to Cell_A1 and receives the notifica-
tion on the NCH about the REC (GID 299) in
Cell_A1.
(GID 299).
After successful cell reselection MS_A3 auto-
matically joins the REC (GID 299) in group
receive mode.


MS_A1, MS_A2 and CT_A1 are able to listen
to the announcement of MS_A3.
ment of CT_A1.
MS_A1 and MS_A2 still able to listen to the
###).
voice path on GCCH.
MS_A1, MS_A2 and MS_A3 are able to listen
to the announcement of CT_A1.
ment of CT_A1.
of MS_A3.

d) Success criteria
MS_A3 receives the notification after successful cell reselection from Cell_A2 to Cell_A1 on the
NCH about the REC (GID 299) in Cell_A1 and automatically joins the REC (GID 299) in group
receive mode.
MS_A3 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.
CT_A1 is able to receive the Railway Emergency Call (REC) with GID 299 and to un-mute/mute
the downlink to the talking mobile subscriber on GCCH.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.10 LE dedicated mode (non-roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
Verify that mobile subscribers receive the in-band notification on the FACCH about ongoing Rail-
way Emergency Calls (REC) and automatically join in group receive mode after successful hand-
over in dedicated mode.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

1) MS_A3 establishes a PTP call to MS_A4 The PTP call is established successfully. The
subscribers can talk to each other.
(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
15) MS_A3 moves form Cell_A2 to Cell_A1 MS_A3 performs a handover from Cell_A2 to
Cell_A1 and receives the in-band notification
on the FACCH about the REC (GID 299) in
Cell_A1.
(GID 299).
After successful handover the PTP call be-
tween MS_A3 and MS_A4 will be pre-empted.
All resources related to the PTP call are de-
allocated.


ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of MS_A3.

d) Success criteria
MS_A3 receives the in-band notification after successful handover from Cell_A2 to Cell_A1 on
the FACCH about the REC (GID 299) in Cell_A1. The PTP call between MS_A3 and MS_A4 will
be pre-empted. MS_A3 automatically joins the REC (GID 299) in group receive mode.
MS_A3 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.11 LE group receive mode (non-roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
gency Calls (REC) and automatically join in group receive mode after successful cell reselection

CT_A1 and CT_A2 are connected to network A.

Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299) MS_A3 (REC GID: 299, VGCS GID: 200)
CT_A2 (GCA_A2, VGCS GID: 200)
CoO=Cell_A1

CoO=Cell_A2

GCA_A2, VGCS GID: 200 Prio 2


c) Test procedure

1) MS_A3 originates a GC (GID 200). GC (GID 200) is correctly established.
Cell_A1.
MS_A4 is notified about the incoming GC (GID
200) on the NCH.
CT_A2 is notified about the incoming GC (GID
200) and the Group Call Reference is dis-
played on CT terminal.
CT_A1 is not notified about the incoming GC
(GID 200).
MS_A1 and MS_A2 not respond to the notifi-
cation on the NCH about the GC (GID 200) in
Cell_A2.
2) MS_A4 automatically accepts the GC
(GID 200).
MS_A4 automatically joins the GC (GID 200) in
group receive mode.
3) CT_A2 automatically accepts the GC
(GID 200).
CT_A2 automatically joins the GC (GID 200).
5) MS_A3 releases the uplink on DCH. Uplink free message is send for GC (GID 200)
in Cell_A1 and Cell_A2 and the DCH is cor-
rectly released.
ment of CT_A2.
of CT_A2.


###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
9) MS_A3 releases the uplink on GCCH. Uplink free message is send for GC (GID 200)
in Cell_A1 and Cell_A2 and uplink is correctly
released.
CT_A2 is not notified about the incoming REC
(GID 299).
(GID 299).
(GID 299).


ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A2.
23) MS_A3 moves form Cell_A2 to Cell_A1 MS_A3 performs a cell reselection in group
receive mode from Cell_A2 to Cell_A1 and
receives the notification on the NCH about the
REC (GID 299) in Cell_A1.
(GID 299).
After successful cell reselection MS_A3 auto-
matically leaves the GC (GID 200) and joins
the REC (GID 299) in group receive mode.
GCCH in Cell_A1 and Cell_A2 for GC (GID
200) stay allocated.

ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of MS_A3.


MS_A4.
###).
voice path on GCCH.
of CT_A1.
ment of CT_A1.
of MS_A4.
released.
MS_A3 is re-notified about the ongoing GC
(GID 200) in Cell_A1 on the NCH.
(GID 200).
group receive mode.
ment of CT_A1.
of CT_A1.
Talker flag is updated at MS_A3
###).
voice path on GCCH.


ment of CT_A2.
of CT_A2.
of MS_A3.
released.
39) MS_A3 releases the GC (GID 200). GC (GID 200) is released. All related re-

d) Success criteria
MS_A3 receives the notification after successful cell reselection from Cell_A2 to Cell_A1 on the
NCH about the REC (GID 299) in Cell_A1. MS_A3 automatically joins the REC (GID 299) in
group receive mode.
MS_A3 is able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.
MS_A3 is also able to get the uplink on GCCH and to close the GC (GID 200) after the REC (GID
299) is released.
CT_A2 is able to receive Group Calls (GC) with GID 200 and to un-mute/mute the downlink to the
talking mobile subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.12 LE group transmit mode (non-roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
over in group transmit mode.


Network A

Cell_A1 Cell_A2
CoO=Cell_A1

CoO=Cell_A2



c) Test procedure

Cell_A1.
200) on the NCH.
(GID 200).
Cell_A2.
(GID 200).
group receive mode.
(GID 200).
5) MS_A3 releases the uplink on DCH. Uplink free message is send for GC (GID 200)
in Cell_A1 and Cell_A2 and the DCH is cor-
rectly released.
ment of CT_A2.
of CT_A2.


###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
released.
(GID 299).
(GID 299).
(GID 299).


ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A2.
ment of CT_A2.
of CT_A2.
24) MS_A3 moves form Cell_A2 to Cell_A1 MS_A3 performs a handover in group transmit
mode from Cell_A2 to Cell_A1 and receives
the notification on the FACCH about the REC
(GID 299) in Cell_A1.
(GID 299).
After successful handover MS_A3 automati-
cally leaves the GC (GID 200) and joins the
REC (GID 299) in group receive mode.
Uplink free message is send for GC (GID 200)
released.
ment of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of MS_A3.
MS_A4.
###).
voice path on GCCH.
of CT_A1.
ment of CT_A1.
of MS_A4.
released.
(GID 200).
group receive mode.
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
released.

d) Success criteria
MS_A3 receives the in-band notification after successful handover in group transmit mode from
Cell_A2 to Cell_A1 on the FACCH about the REC (GID 299) in Cell_A1. MS_A3 automatically
joins the REC (GID 299) in group receive mode.
299) is released.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.13 LE group mode, dedicated channel (non-roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
over in group transmit mode on dedicated channel (DCH).


Network A

Cell_A1 Cell_A2
CoO=Cell_A1

CoO=Cell_A2



c) Test procedure

Cell_A1.
200) on the NCH.
(GID 200).
Cell_A2.
(GID 200).
group receive mode.
(GID 200).
4) MS_A3 takes the uplink on DCH and
keep it.
MS_A3 has voice path on DCH.
(GID 299).
(GID 299).
MS_A2 automatically join the REC (GID 299)


(GID 299).
CT_A1 automatically join the REC (GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
18) MS_A3 moves form Cell_A2 to Cell_A1. MS_A3 performs a handover on DCH from
Cell_A2 to Cell_A1 and receives the notifica-
tion on the FACCH about the REC (GID 299)
in Cell_A1.
(GID 299).
cally leaves the GC (GID 200) and joins the
REC (GID 299) in group receive mode.
released.
The dedicated channel (DCH) is released. All
related resources are de-allocated.
ment of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of MS_A3.
MS_A4.
###).
voice path on GCCH.
of CT_A1.
ment of CT_A1.
of MS_A4.
released.
(GID 200).
MS_A3 automatically join the GC (GID 200) in
group receive mode.
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
released.



d) Success criteria
MS_A3 receives the in-band notification after successful handover in group transmit mode on
dedicated channel (DCH) from Cell_A2 to Cell_A1 on the FACCH about the REC (GID 299) in
Cell_A1. MS_A3 automatically joins the REC (GID 299) in group receive mode.
299) is released.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.14 LE idle mode (roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
gency Calls (REC) and automatically join in group receive mode after successful cell reselection.


Network A Network B

A-MSC_A1 A-MSC_B1
CT_A1 (GCA_A1, REC GID: 299) CT_B1 (GCA_B1, REC GID: 299)

c) Test procedure

CoO=Cell_A1

CoO=Cell_B1

GCA_B1, REC GID: 299 Prio 0


(GID 299).
(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
14) MS_B2 moves form Cell_B1 to Cell_A1 After MS_B2 is out of coverage of Network B it
performs a network reselection to Network A
and receives the notification on the NCH about
the REC (GID 299) in Cell_A1.
15) MS_B2 automatically accepts the REC
(GID 299).
After successful network reselection MS_B2
automatically joins the REC (GID 299) in group
receive mode.
GCCH in Cell_B1 for REC (GID 299) stay allo-
cated.


to the announcement of MS_B2.
ment of CT_A1.
###).
voice path on GCCH.
MS_A1, MS_A2 and MS_B2 are able to listen
ment of CT_A1.
of MS_B2.
21) MS_B2 moves form Cell_A1 to Cell_B1 After MS_B2 is out of coverage of Network A it
performs a network reselection to Network B.
MS_B2 is notified about the incoming REC
(GID 299).
CT_B1 has voice path to all mobile subscrib-
the announcement of CT_B1.


MS_B2 and CT_B1 are able to listen to the
299) in Cell_B1 and the DCH is correctly re-
leased.
ment of CT_B1.
MS_B2 still able to listen to the announcement
of CT_B1.
###).
voice path on GCCH.
MS_B1 and MS_B2 are able to listen to the
announcement of CT_B1.
ment of CT_B1.
of CT_B1.
CT_B1 still able to listen to the announcement
of MS_B1.
299) in Cell_B1 and uplink is correctly re-
leased.
ment of CT_B1.
of CT_B1.
###).
voice path on GCCH.


ment of CT_B1.
of CT_B1.
of MS_B2.
299) in Cell_B1 and uplink is correctly re-
leased.
34) MS_A2 moves form Cell_A1 to Cell_B1 After MS_A2 is out of coverage of Network A it
performs a network reselection to Network B
the REC (GID 299) in Cell_B1.
(GID 299).
After successful network reselection MS_A2
receive mode.
GCCH in Cell_A1 for REC (GID 299) stay allo-
cated.
ment of CT_B1.
of CT_B1.
###).
voice path on GCCH.
MS_B1 and MS_A2 are able to listen to the
ment of CT_B1.
of CT_B1.
of MS_A2.
39) MS_A2 releases the uplink on GCCH. Uplink free message is send in Cell_B1 and



d) Success criteria
MS_B2 receive the notification after successful network reselection from Network B to Network A
on the NCH about the REC (GID 299) in Cell_A1 and automatically joins the REC (GID 299) in
group receive mode.
MS_B2 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.
MS_A2 receive the notification after successful network reselection from Network A to Network B
on the NCH about the REC (GID 299) in Cell_B1 and automatically joins the REC (GID 299) in
group receive mode.
MS_A2 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_B1.
CT_A1 and CT_B1 are able to receive the Railway Emergency Call (REC) with GID 299 and to

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.15 LE dedicated mode (more than one MSC)


2.5.1
13.2.2.7
2.5.1

a) Purpose
over in dedicated mode.


Step 1: LE of service subscriber MS_A4 during PTP call.



Network A

A-MSC_A1 A-MSC_A2
CT_A1 (GCA_A1, REC GID: 299) CT_A2 (GCA_A2, REC GID: 299)

c) Test procedure

1) MS_A3 establishes a PTP call to MS_A4. The PTP call is established successfully. The
(GID 299).
CoO=Cell_A1

CoO=Cell_A2



(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
10) MS_A1 releases the uplink on GCCH. Uplink free message is sent in Cell_A1 and
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
Cell_A1.
(GID 299).
allocated.
ment of CT_A1.
MS_A1 and MS_A2 are still able to listen to the
###).
voice path on DCH.


ment of CT_A1.
of MS_A4.

1) MS_A1 establishes a PTP call to MS_A2 The PTP call is established successfully. The
(GID 299).
(GID 299).


ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.


ment of CT_A2.
of CT_A2.
of MS_A4.
15) MS_A2 moves form Cell_A1 to Cell_A2. MS_A2 performs a handover from Cell_A1 to
Cell_A2.
(GID 299).
allocated.
ment of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of MS_A2.



d) Success criteria
MS_A4 receives the notification after successful handover from Cell_A2 to Cell_A1 on the
FACCH about the REC (GID 299) in Cell_A1 and automatically joins the REC (GID 299) in group
receive mode. MS_A4 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.
MS_A2 receives the notification after successful handover from Cell_A1 to Cell_A2 on the
FACCH about the REC (GID 299) in Cell_A2 and automatically joins the REC (GID 299) in group
receive mode. MS_A2 is also able to get the uplink on GCCH of the REC (GID 299) in Cell_A2.
CT_A1 and CT_A2 are able to receive the Railway Emergency Call (REC) with GID 299 and to

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.16 LE group receive mode (roaming case)


2.5.1
13.2.2.7
2.5.1

a) Purpose
gency Calls (REC) and automatically join in group receive mode after successful network selec-
tion in group receive mode.


Step 1: LE of service subscriber MS_B2 in group receive mode.
Step 2: LE of service subscriber MS_A2 in group receive mode.



Network A Network B

A-MSC_A1 A-MSC_B1
MS_A2 (REC GID: 299, VGCS GID: 200) MS_B2 (REC GID: 299, VGCS GID: 200)
CT_A1 (GCA_A1, REC GID: 299) CT_AB1 (GCA_B1, VGCS GID: 200)

c) Test procedure

Step 1: LE of service subscriber MS_B2 in group receive mode.
(GID 299).
CoO=Cell_A1

CoO=Cell_B1

GCA_AB1, VGCS GID: 200 Prio 2


(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
14) MS_B1 originates a GC (GID 200). GC (GID 200) is correctly established.
Cell_A1.
MS_B2 is notified about the incoming GC (GID
200) on the NCH.
CT_B1 is notified about the incoming GC (GID
MS_A2 receives an in-band notification on
FACCH about the incoming GC (GID 200).
MS_A2 did not respond to the notification, the
priority of the GC (GID 200) is lower than the
priority of the REC (GID 299).
15) MS_B2 automatically accepts the GC
(GID 200).
MS_B2 automatically joins the GC (GID 200) in
group receive mode.
16) CT_B1 automatically accepts the GC
(GID 200).
CT_B1 automatically joins the GC (GID 200).


Cell_B1. The DCH in Cell_B1 is correctly re-
leased.
ment of CT_B1.
of CT_B1.
###).
voice path on GCCH.
ment of CT_B1.
of CT_B1.
of MS_B1.
22) MS_B1 releases the uplink on GCCH. Uplink free message is send in Cell_B1 and
Cell_A1. The uplink in Cell_B1 is correctly re-
leased.
23) MS_B2 moves form Cell_B1 to Cell_A1 After MS_B2 is out of coverage of Network B it
performs a network reselection to Network A
the REC (GID 299) in Cell_A1.
(GID 299).
After successful network reselection MS_B2
receive mode.
GCCH in Cell_B1 and Cell_A1 for GC (GID
200) stays allocated.
to the announcement of MS_B2.
ment of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of MS_B2.
MS_B2 is re-notified about the ongoing GC
30) MS_B2 automatically accepts the GC
(GID 200).
MS_B2 automatically joins the GC (GID 200) in
group receive mode.
ment of CT_B1.
of CT_B1.
###).
its downlink get two-way voice path on GCCH.


using the mute sequence (dialling #**)
downlink.
ment of CT_B1.
of CT_B1.
of MS_B2.
Cell_B1. The uplink in Cell_A1 is correctly re-
leased.
35) MS_B1 releases the GC (GID 200). GC (GID 200) is released. All related re-



Network A Network B

A-MSC_A1 A-MSC_B1
MS_A2 (REC GID: 299, VGCS GID: 200) MS_B2 (REC GID: 299, VGCS GID: 200)
CT_A1 (GCA_AB1, VGCS GID: 200) CT_B1 (GCA_B1, REC GID: 299)

Test procedure

Step 2: LE of service subscriber MS_A2 in group receive mode.
MS_B2 is notified about the incoming REC
(GID 299).
MS_B2 automatically join the REC (GID 299)
CoO=Cell_B1

CoO=Cell_A1



(GID 299).
CT_B1 automatically join the REC (GID 299).
5) MS_B1 releases the uplink on DCH. Uplink free message is send in Cell_B1 and
ment of CT_B1.
of CT_B1.
###).
voice path on GCCH.
ment of CT_B1.
of CT_B1.
of MS_B1.
ment of CT_B1.
of CT_B1.


###).
voice path on GCCH.
ment of CT_B1.
of CT_B1.
of MS_B2.
Cell_B1.
200) on the NCH.
MS_B2 receives an in-band notification on
FACCH about the incoming GC (GID 200).
MS_A2 did not respond to the notification, the
priority of the GC (GID 200) is lower than the
priority of the REC (GID 299).
(GID 200).
group receive mode.
(GID 200).


leased.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
Cell_A1. The uplink in Cell_A1 is correctly re-
leased.
23) MS_A2 moves form Cell_A1 to Cell_A1 After MS_A2 is out of coverage of Network A it
performs a network reselection to Network B
the REC (GID 299) in Cell_B1.
(GID 299).
After successful network reselection MS_A2
receive mode.
GCCH in Cell_A1 and Cell_B1 for GC (GID
MS_B1, MS_B2 and CT_B1 are able to listen
ment of CT_B1.
MS_B1 and MS_B2 still able to listen to the


###).
voice path on GCCH.
MS_B1, MS_B2 and MS_A2 are able to listen
to the announcement of CT_B1.
ment of CT_B1.
MS_B1 and MS_B2 still able to listen to the
of MS_A2.
(GID 200) in Cell_B1 on the NCH.
(GID 200).
group receive mode.
ment of CT_A1.
of CT_A1.
###).


downlink.
ment of CT_A1.
of CT_A1.
of MS_A2.
Cell_B1. The uplink in Cell_B1 is correctly re-
leased.

d) Success criteria
MS_B2 receives the notification after successful network selection from Network B to Network A
on NCH about the REC (GID 299) in Cell_A1. MS_B2 automatically joins the REC (GID 299) in
group receive mode.
MS_B2 is able to get the uplink on GCCH of the REC (GID 299) in Cell_A1.
MS_B2 is also able to get the uplink on GCCH of the GC (GID 200) in Cell_A1 after the REC
(GID 299) is released.
MS_A2 receives the notification after successful network selection from Network A to Network B
on NCH about the REC (GID 299) in Cell_B1. MS_A2 automatically joins the REC (GID 299) in
group receive mode.
MS_A2 is able to get the uplink on GCCH of the REC (GID 299) in Cell_B1.
MS_A2 is also able to get the uplink on GCCH of the GC (GID 200) in Cell_B1 after the REC
(GID 299) is released.
CT_A1 and CT_B1 are able to receive the Railway Emergency Call (REC) with GID 299 and
Group Calls (GC) with GID 200. CT_A1 and CT_B1 are also able to un-mute/mute the downlink
to the talking mobile subscriber on GCCH.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.17 LE group transmit mode (more than one MSC)


2.5.1
13.2.2.7
2.5.1

a) Purpose
over in group transmit mode.


Step 1: LE in group transmit mode from MSC_A2 to MSC_A1.
Step 2: LE to group transmit mode from MSC_A1 to MSC_A2.



Network A

A-MSC_A1 (GCA_A1)
R-MSC_A1 (GCA_A2) A-MSC_A2 (GCA_A2)
MS_A1 (REC GID: 299) MS_A3 (VGCS GID: 200)
CT_A1 (GCA_A1, REC GID: 299) CT_A2 (GCA_A2, VGCS GID: 200)

c) Test procedure

Step 1: LE in group transmit mode from MSC_A2 to MSC_A1.
(GID 299).
CoO=Cell_A1

CoO=Cell_A2



(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
ment of CT_A1.
of CT_A1.


###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
14) MS_A3 originates a VGCS call (GID
200).
VGCS call (GID 200) is correctly established.
Cell_A1.
MS_A4 is notified about the incoming VGCS
CT_A2 is notified about the incoming VGCS
FACCH about the incoming VGCS call (GID
200). MS_A2 did not respond to the notifica-
tion, the priority of the VGCS call (GID 200) is
lower than the priority of the REC (GID 299).
15) MS_A4 automatically accepts the VGCS
call (GID 200).
MS_A4 automatically joins the VGCS call (GID
200) in group receive mode.
16) CT_A3 automatically accepts the VGCS
call (GID 200).
CT_A2 automatically joins the VGCS call (GID
200).


Cell_A2. The DCH in Cell_A2 is correctly re-
leased.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
leased.
23) MS_A4 takes the uplink on GCCH and
keep it.
MS_A4 has voice path on GCCH.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.


ment of CT_A2.
of CT_A2.
of MS_A4.
Cell_A1.
(GID 299).
cally leaves the VGCS call (GID 200) and joins
Uplink free message is sent for VGCS call
(GID 200) in Cell_A1 and Cell_A2 and uplink is
correctly released.
GCCH in Cell_A1 and Cell_A2 for VGCS call
(GID 200) stays allocated.
ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of MS_A4.


MS_A4 is re-notified about the ongoing VGCS
call (GID 200) in Cell_A1 on the NCH.
call (GID 200).
ment of CT_A2.
of CT_A2.
###).
downlink.
ment of CT_A2.
of CT_A2.
of MS_A4.
leased.
38) MS_A3 releases the VGCS call (GID
200).
VGCS call (GID 200) is released. All related
resources are de-allocated.



Network A

A-MSC_A2 (CGA_A2)
A-MSC_A1 (CGA_A1) R-MSC_A2 (CGA_A1)
MS_A1 (VGCS GID: 200) MS_A3 (REC GID: 299)
MS_A2 (REC GID: 299, VGCS GID: 200) MS_A4 (REC GID: 299)
CT_A1 (GCA_A1, VGCS GID: 200) CT_A2 (GCA_A2, REC GID: 299)

Test procedure

Step 2: LE to group transmit mode from MSC_A1 to MSC_A2.
(GID 299).
CoO=Cell_A2

CoO=Cell_A1



(GID 299).
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A3.
ment of CT_A2.
of CT_A2.


###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A4.
200).
Cell_A2.
call (GID 200) on the NCH.
CT_A1 is notified about the incoming VGCS
call (GID 200) and the Group Call Reference is
FACCH about the incoming VGCS call (GID
200). MS_A2 did not respond to the notifica-
tion, the priority of the GC (GID 200) is lower
than the priority of the REC (GID 299).
call (GID 200).
16) CT_A1 automatically accepts the VGC S
call (GID 200).
CT_A1 automatically joins the VGCS call (GID
200).


Cell_A2. The DCH in Cell_A1 is correctly re-
leased.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
leased.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A2.
26) MS_A2 moves form Cell_A1 to Cell_A2. MS_A2 performs a handover from Cell_A1 to
Cell_A2.
(GID 299).
cally leaves the VGCS call (GID 200) and joins
Uplink free message is send for VGCS call
(GID 200) in Cell_A1 and Cell_A2 and uplink is
correctly released.
GCCH in Cell_A1 and Cell_A2 for VGCS call
(GID 200) stays allocated.
ment of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of MS_A2.


MS_A2 is re-notified about the ongoing VGCS
call (GID 200) in Cell_A2 on the NCH.
call (GID 200).
ment of CT_A1.
of CT_A1.
###).
downlink.
ment of CT_A1.
of CT_A1.
of MS_A2.
leased.
200).
VGCS call (GID 200) is released. All related
resources are de-allocated.


d) Success criteria
the FACCH about the REC (GID 299) in Cell_A1. MS_A4 automatically joins the REC (GID 299)
MS_A4 is also able to get the uplink on GCCH.
MS_A3 is able to close the VGCS call (GID 200) after the REC (GID 299) is released.
MS_A2 is also able to get the uplink on GCCH.
MS_A1 is able to close the VGCS call (GID 200) after the REC (GID 299) is released.
CT_A1 and CT_A2 are able to receive the Railway Emergency Call (REC) with GID 299 and
VGCS calls with GID 200. CT_A1 and CT_A2 are also able to un-mute/mute the downlink to the

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.18 LE group mode, dedicated channel (more than one MSC)


2.5.1
13.2.2.7
2.5.1

a) Purpose
over in group transmit mode on dedicated channel (DCH).


Step 1: LE in group mode on DCH from MSC_A2 to MSC_A1.
Step 2: LE to group mode on DCH from MSC_A1 to MSC_A2.



Network A

A-MSC_A1 (GCA_A1)
R-MSC_A1 (GCA_A2) A-MSC_A2 (GCA_A2)
MS_A1 (REC GID: 299) MS_A3 (REC GID: 299. VGCS GID: 200)
MS_A2 (REC GID: 299) MS_A4 (VGCS GID: 200)
CT_A1 (GCA_A1, REC GID: 299) CT_A2 (GCA_A2, VGCS GID: 200)

c) Test procedure

Step 1: LE in group mode on DCH from MSC_A2 to MSC_A1.
CoO=Cell_A1

CoO=Cell_A2



(GID 299).
(GID 299).
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.


ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.
Cell_A1.
200) on the NCH.
(GID 200).
group receive mode.
(GID 200).


keeps it.
18) MS_A3 moves form Cell_A2 to Cell_A1 MS_A3 performs a handover on DCH from
Cell_A2 to Cell_A1 and receives the in-band
notification on the FACCH about the REC (GID
299) in Cell_A1.
(GID 299).
After successful handover on DCH, MS_A3
automatically leaves the GC (GID 200) and
joins the REC (GID 299) in group receive
mode.
Uplink free message is sent for GC (GID 200)
in Cell_A1 and Cell_A2. The DCH is correctly
released.
ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of MS_A3.


(GID 200).
group receive mode.
Talker flag is updated at MS_A3.
ment of CT_A2.
of CT_A2.
###).
its downlink and get two-way voice path on
GCCH.
downlink.
ment of CT_A2.
of CT_A2.
of MS_A3.
leased.
30) MS_A4 takes the uplink on GCCH and
keep it.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.


ment of CT_A2.
of CT_A2.
of MS_A4.
leased.



Network A

A-MSC_A2 (GCA_A2)
A-MSC_A1 (GCA_A1) R-MSC_A2 (GCA_A1)
MS_A1 (REC GID: 299, VGCS GID: 200) MS_A3 (REC GID: 299)
MS_A2 (VGCS GID: 200) MS_A4 (REC GID: 299)
CT_A1 (GCA_A1, VGCS GID: 200) CT_A2 (GCA_A2, REC GID: 299)

Test procedure

Step 2: LE to group mode on DCH from MSC_A1 to MSC_A2.
CoO=Cell_A2

CoO=Cell_A1



(GID 299).
(GID 299).
5) MS_A3 releases the uplink on DCH. Uplink free message is sent in Cell_A3 and the
DCH is correctly released.
ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A3.
of MS_A3.


ment of CT_A2.
of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of CT_A2.
of MS_A4.
Cell_A2.
200) on the NCH.
(GID 200).
group receive mode.
(GID 200).


keep it.
Cell_A2.
(GID 299).
After successful handover on DCH, MS_A1
automatically leaves the GC (GID 200) and
joins the REC (GID 299) in group receive
mode.
in Cell_A1 and Cell_A2. The DCH is correctly
released.
ment of CT_A2.
###).
voice path on GCCH.
ment of CT_A2.
of MS_A1.


(GID 200).
group receive mode.
Talker flag is updated at MS_A1.
ment of CT_A1.
of CT_A1.
###).
downlink.
ment of CT_A1.
of CT_A1.
of MS_A1.
leased.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A2.

d) Success criteria
299) is released.
299) is released.
CT_A1 and CT_A2 are able to receive the Railway Emergency Call (REC) with GID 299 and
Group Calls (GC) with GID 200. CT_A1 and CT_A2 are also able to un-mute/mute the downlink
to the talking mobile subscriber on GCCH.


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.19 REC call is taken down due to expiry of No activity timer.


2.5.1
13.2.4.1

a) Purpose
Verify that a Railway Emergency Call (REC) is released after expiration of the No activity timer.


Network A


CoO=Cell_A1



c) Test procedure

1) Service subscriber MS_A1 originates a
REC (GID 299).
MS_A2 receives notification of the incoming
REC (GID 299) on the NCH.
So long the dedicated channel is not released,
MS_A1 has two-way voice path.
2) MS_A2 automatically accepts the incom-
ing REC (GID 299).
MS_A2 automatically join the REC (GID 299).
3) MS_A1 takes the uplink on the group call
channel.
MS_A1 has two-way voice path, MS_A2 is only
listener.
4) MS_A1 releases the uplink. The uplink is correctly released.
5) Wait until expiration of No activity timer. The REC (GID 299) is released after expiration
of the No activity timer and all resources are
correctly de-allocated.

d) Success criteria
The Railway Emergency Call (REC) with GID 299 is correctly released after expiration of the No
activity timer.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.20 REC first talker notification (MS dedicated mode, incoming PTP call, non roaming
case)


2.2.1
2.5.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3

a) Purpose
Verify that a REC (GID 299) first talker on dedicated channel get a notification about an incoming
PTP call.


Network A

Cell_A1 Cell_A2
MS_A2 (REC GID: 299) MS_A4 (no VGCS / VBS subscriber)

CoO=Cell_A1 CoO=Cell_A2



c) Test procedure

1) Service subscriber MS_A1 originates
REC (GID 299).
channel (GCCH) are allocated in cell_A1.
cell_A2.
MS_A2, MS_A3 receives a notification about
the incoming REC (GID 299).
2) MS_A2, MS_A3 automatically accepts
the incoming REC (GID 299).
MS_A2, MS_A3 joins REC (GID 299).
3) MS_A1 takes the uplink on DCH. MS_A1 has two-way voice path. MS_A2,
of MS_A1.

4) MS_A4 originates a PTP call with priority
4 to MS_A1.
MS_A1 receives an in-band paging on the
FACCH channel about the incoming PTP call
from MS_A4. MS_A1 advertise the incoming
PTP call from MS_A4 optically and acousti-
cally.
5) MS_A1 dont accept the incoming PTP
call from MS_A4.
After the paging timer is expired the call will be
released by the network. All related resources
are correctly de-allocated.
7) MS_A1 releases the REC (GID 299). REC (GID 299) is released successfully and all
resources are correctly de-allocated.
8) Repeat from step 1 to 7 with priority 3 for
the PTP call.

d) Success criteria
The REC (GID 299) first talker on the dedicated channel is able to receive notification about an
incoming PTP call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.21 REC first talker notification (MS dedicated mode, incoming VGCS call, non roaming
case)


2.2.1
2.5.1
5.2.2.47
5.5.19
5.5.20
5.5.21

a) Purpose
VGCS call.


Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299, VGCS GID: 200) MS_A3 (VGCS GID: 200)


GCA_A1, REC GID: 299 Prio 0, VGCS GID: 200 Prio 2


c) Test procedure

REC (GID 299).
cell_A2.
MS_A2 receives a notification about the incom-
ing REC (GID 299).
ing REC (GID 299).
MS_A2 joins REC (GID 299).
3) MS_A1 takes the uplink on DCH. MS_A1 has two-way voice path. MS_A2 is
able to listen to the announcement of MS_A1.
VGCS call (GID 200) with priority 2.
cell_A1.
MS_A1 receives an in-band notification over
the FACCH channel about the incoming VGCS
call (GID 200). MS_A1 advertise the incoming
VGCS call (GID 200) optically and acoustically.
5) MS_A1 dont accept the incoming VGCS
call (GID 200).

6) MS_A3 releases the uplink. The uplink is correctly released. Uplink free
message is send in cell_A1 and cell_A2.
7) MS_A3 terminates the VGCS call (GID
200).
VGCS call (GID 200) is released successfully
and all resources are correctly de-allocated.
10) Repeat from step 1 to 9 with priorities 3
and 4 for the VGCS call.



d) Success criteria
incoming VGCS call (GID 200).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.22 REC first talker notification (MS dedicated mode, incoming VBS call, non roaming
case)


2.2.1
2.5.1
5.2.2.47
5.5.19
5.5.20
5.5.21

a) Purpose
VBS call (GID 202).


Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299, VBS GID: 202) MS_A3 (VBS GID: 202)


GCA_A1, REC GID: 299 Prio 0, VBS GID: 202 Prio 3


c) Test procedure

REC (GID 299).
cell_A2.
ing REC (GID 299).
ing REC (GID 299).

VBS call (GID 202) with priority 3.
VBS call (GID 202) is correctly established.
cell_A2.
MS_A1 receive an in-band notification over the
FACCH channel about the incoming VBS call
(GID 202). MS_A1 advertise the incoming VBS
call (GID 202) optically and acoustically.
5) MS_A1 dont accept the incoming VBS
call (GID 202).

6) MS_A3 terminates the VBS call (GID
202).
VBS call (GID 202) is released successfully
the VBS call (GID 202).

d) Success criteria
incoming VBS call (GID 202).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.23 REC first talker notification (MS dedicated mode, incoming PTP call, roaming)


2.2.1
2.5.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3

a) Purpose
PTP call. This should be verified in different networks (roaming).

Step 1: MS of network A in HPLMN call MS of network A (REC originator) in HPLMN (MSC_A1
anchor).
Step 2: MS of network A in HPLMN call MS of network B (REC originator) in VPLMN (MSC_A1
anchor).
Step 3: MS of network A in HPLMN call MS of network B (REC originator) in HPLMN (MSC_A1
anchor).
Step 4: MS of network A in HPLMN call MS of network A (REC originator) in VPLMN (MSC_A1
anchor).
Step 5: MS of network A in HPLMN call MS of network A (REC originator) in HPLMN (MSC_B1
anchor).
Step 6: MS of network A in HPLMN call MS of network B (REC originator) in VPLMN (MSC_B1
anchor).
Step 7: MS of network A in HPLMN call MS of network B (REC originator) in HPLMN (MSC_B1
anchor).
Step 8: MS of network A in HPLMN call MS of network A (REC originator) in VPLMN (MSC_B1
anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: MS of network A in HPLMN call MS of network A (REC originator) in HPLMN
(MSC_A1 anchor).
Step Action
Expected result(s)
REC (GID 299).
cell_B1.
MS_A3, MS_B1 and MS_B3 receive a notifica-
tion about the incoming REC (GID 299).
cally accept the incoming REC (GID
299).
MS_A3, MS_B1 and MS_B3 join REC (GID
299).



Step Action
Expected result(s)
4 to MS_A1.
cally.
call from MS_A2.
6) MS_B4 originates a PTP call with priority
4 to MS_A1.
from MS_B4. MS_A1 advertise the incoming
PTP call from MS_B4 optically and acousti-
cally.
call from MS_B4.
4 to MS_A1.
cally.
call from MS_B2.
4 to MS_A1.
cally.
call from MS_A4.
message is send in cell_A1 and cell_B1.
14) Repeat from step 1 to 13 with priority 3
for the PTP calls.


Step 2: MS of network A in HPLMN call MS of network B (REC originator) in VPLMN
(MSC_A1 anchor).
1) Service subscriber MS_B3 originates
REC (GID 299).
cell_B1.
MS_A1, MS_B1 and MS_A3 receive a notifica-
MS_B3 has two-way voice path.
299).
MS_A1, MS_B1 and MS_A3 join REC (GID
299).
3) MS_B3 takes the uplink on DCH. MS_B3 has two-way voice path. MS_A1,
4 to MS_B3.
MS_B3 receives an in-band paging on the
from MS_A2. MS_B3 advertise the incoming
cally.
5) MS_B3 dont accept the incoming PTP
call from MS_A2.
4 to MS_B3.
from MS_B4. MS_B3 advertise the incoming
cally.
call from MS_B4.
4 to MS_B3.
cally.
call from MS_B2.


4 to MS_B3.
cally.
call from MS_A4.
12) MS_B3 releases the uplink. The uplink is correctly released. Uplink free
13) MS_B3 releases the REC call. REC (GID 299) is released successfully and all
for the PTP calls.

Step 3: MS of network A in HPLMN call MS of network B (REC originator) in HPLMN
(MSC_A1 anchor).
REC (GID 299).
channel (GCCH) are allocated in cell_B1.
cell_A1.
MS_A1, MS_A3 and MS_B3 receive a notifica-
299).
MS_A1, MS_A3 and MS_B3 join REC (GID
299).
MS_A3 and MS_B3 are able to listen to the
4 to MS_B1.
cally.
call from MS_A2.


4 to MS_B1.
cally.
call from MS_B4.
4 to MS_B1.
cally.
call from MS_B2.
4 to MS_B1.
cally.
call from MS_A4.
for the PTP calls.


Step 4: MS of network A in HPLMN call MS of network A (REC originator) in VPLMN
(MSC_A1 anchor).
REC (GID 299).
cell_A1.
299).
299).
4 to MS_A3.
cally.
call from MS_A2.
4 to MS_A3.
cally.
call from MS_B4.
4 to MS_A3.
cally.
call from MS_B2.


4 to MS_A3.
cally.
call from MS_A4.
for the PTP calls.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 5: MS of network A in HPLMN call MS of network A (REC originator) in HPLMN
(MSC_B1 anchor).
REC (GID 299).
cell_B1.
299).
299).



4 to MS_A1.
cally.
call from MS_A2.
4 to MS_A1.
cally.
call from MS_B4.
4 to MS_A1.
cally.
call from MS_B2.
4 to MS_A1.
cally.
call from MS_A4.
for the PTP calls.


Step 6: MS of network A in HPLMN call MS of network B (REC originator) in VPLMN
(MSC_B1 anchor).
REC (GID 299).
cell_B1.
299).
MS_A1, MS_B1 and MS_A3 join REC (GID
299).
4 to MS_B3.
cally.
call from MS_A2.
4 to MS_B3.
cally.
call from MS_B4.
4 to MS_B3.
cally.
call from MS_B2.


4 to MS_B3.
cally.
call from MS_A4.
for the PTP calls.

Step 7: MS of network A in HPLMN call MS of network B (REC originator) in HPLMN
(MSC_B1 anchor).
REC (GID 299).
cell_A1.
299).
299).
4 to MS_B1.
cally.
call from MS_A2.


4 to MS_B1.
cally.
call from MS_B4.
4 to MS_B1.
cally.
call from MS_B2.
4 to MS_B1.
cally.
call from MS_A4.
for the PTP calls.


Step 8: MS of network A in HPLMN call MS of network A (REC originator) in VPLMN
(MSC_B1 anchor).
REC (GID 299).
cell_A1.
299).
299).
4 to MS_A3.
cally.
call from MS_A2.
4 to MS_A3.
cally.
call from MS_B4.
4 to MS_A3.
cally.
call from MS_B2.


4 to MS_A3.
cally.
call from MS_A4.
for the PTP calls.

d) Success criteria
incoming PTP call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.24 REC first talker notification (MS dedicated mode, incoming VGCS call, roaming)


2.2.1
2.5.1
5.2.2.47
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a REC (REC) first talker on dedicated channel get a notification about an incoming
VGCS CALL (GID 200) call. This should be verified in different networks (roaming).

Step 1: MS of network A in HPLMN originates a REC and MS of network A in HPLMN originates
a VGCS (MSC_A1 anchor).
Step 2: MS of network B in VPLMN originates a REC and MS of network A in HPLMN originates a
VGCS (MSC_A1 anchor).
Step 3: MS of network A in HPLMN originates a REC and MS of network B in VPLMN originates a
Step 4: MS of network B in VPLMN originates a REC and MS of network B in VPLMN originates a
Step 5: MS of network B in HPLMN originates a REC and MS of network B in HPLMN originates
Step 6: MS of network A in VPLMN originates a REC and MS of network B in HPLMN originates a
Step 7: MS of network B in HPLMN originates a REC and MS of network A in VPLMN originates a
Step 8: MS of network A in VPLMN originates a REC and MS of network A in VPLMN originates a
Step 9: MS of network A in HPLMN originates a REC and MS of network A in VPLMN originates a
Step 10: MS of network A in HPLMN originates a REC and MS of network B in HPLMN originates
Step 11: MS of network B in HPLMN originates a REC and MS of network B in VPLMN originates
Step 12: MS of network B in HPLMN originates a REC and MS of network A in HPLMN originates
a VGCS (MSC_B1 anchor).


Step 14: MS of network B in VPLMN originates a REC and MS of network A in HPLMN originates
Step 15: MS of network A in HPLMN originates a REC and MS of network B in VPLMN originates
Step 16: MS of network B in VPLMN originates a REC and MS of network B in VPLMN originates
Step 18: MS of network A in VPLMN originates a REC and MS of network B in HPLMN originates
Step 19: MS of network B in HPLMN originates a REC and MS of network A in VPLMN originates
Step 20: MS of network A in VPLMN originates a REC and MS of network A in VPLMN originates
Step 21: MS of network A in HPLMN originates a REC and MS of network A in VPLMN originates



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (REC GID: 299, VGCS GID:200) MS_B1 (REC GID: 299, VGCS GID:200)
MS_A2 (VGCS GID:200) MS_B2 (VGCS GID:200)
MS_B3 (REC GID: 299, VGCS GID:200) MS_A3 (REC GID: 299, VGCS GID:200)
MS_B4 (VGCS GID:200) MS_A4 (VGCS GID:200)

c) Test procedure

Step 1: MS of network A in HPLMN originates a REC and MS of network A in HPLMN origi-
nates a VGCS (MSC_A1 anchor).
REC (GID 299).
cell_B1.
299).
299).

GCA_AB1, REC GID: 299 Prio 0, VGCS GID: 200 Prio 2


4) MS_A2 originates a VGCS call (GID 200)
with priority 2.
cell_B1.
tion about the incoming VGCS call (GID 200).
MS_A1, MS_B1, MS_A3 and MS_B3 receive
an in-band notification over the FACCH chan-
nel about the incoming VGCS call (GID 200).
MS_A1, MS_B1, MS_A3 and MS_B3 advertise
the incoming VGCS call (GID 200) optically
and acoustically.
cally accept the incoming VGCS call
(GID 200), if the priority of the VGCS call
(GID 200) is higher or equal than 3.
If the priority is lower than 3, the user has
to accept the VGCS call (GID 200)
manually.
MS_A3, MS_B1 and MS_B3 can not accept
the VGCS call (GID 200); the priority of the
VGCS call (GID 200) is lower than the priority
of REC (GID 299).
call (GID 200).

200).
The VGCS call (GID 200) is released success-
fully and all resources are correctly de-
allocated.
11) Repeat from step 1 to 10 with priorities 3,
and 4 for the VGCS call (GID 200).


Step 2: MS of network B in VPLMN originates a REC and MS of network A in HPLMN origi-
REC (299).
cell_B1.
299).
299).

with priority 2.
cell_B1.
and acoustically.
manually.
MS_A1, MS_A3 and MS_B1 can not accept
of REC (GID 299).
6) MS_B3 dont accept the incoming VGCS
call (GID 200).


200).
allocated.
10) MS_B3 releases the REC (GID 299). REC (GID 299) is released successfully and all

Step 3: MS of network A in HPLMN originates a REC and MS of network B in VPLMN origi-
REC (GID 299).
cell_B1.
tion about the incoming REC.
299).
299).


4) MS_B4 originates a VGCS call (GID 200)
with priority 2.
cell_B1.
MS_A1, MS_B1, MS_A3 and MS_B3 get an in-
band notification over the FACCH channel
about the incoming VGCS call (GID 200).
and acoustically.
5) MS_A2 MS_A4 and MS_B2 automati-
If the priority is lower than 3, the user as
manually.
of REC (GID 299).
call (GID 200).

8) MS_B4 terminates the VGCS call (GID
200).
allocated.


Step 4: MS of network B in VPLMN originates a REC and MS of network B in VPLMN origi-
REC (GID 299).
cell_B1.
299).
299).
with priority 2.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

Step 5: MS of network B in HPLMN originates a REC and MS of network B in HPLMN origi-
REC (GID 299).
cell_A1.
299).
299).


4) MS_B2 originates a VGCS call (GID
200).
channel (GCCH) are allocated in cell_
B1.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


Step 6: MS of network A in VPLMN originates a REC and MS of network B in HPLMN origi-
REC (GID 299).
cell_A1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

Step 7: MS of network B in HPLMN originates a REC and MS of network A in VPLMN origi-
REC (GID 299).
cell_A1.
299).
299).


with priority 2.
cell_A1.
and acoustically.
5) MS_A2 MS_B2 and MS_B4 automati-
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


Step 8: MS of network A in VPLMN originates a REC and MS of network A in VPLMN origi-
REC (GID 299).
cell_A1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

Step 9: MS of network A in HPLMN originates a REC and MS of network A in VPLMN origi-
REC (GID 299).
cell_B1.
299).
299).


with priority 2.
cell_A1.
MS_42 has two-way voice path.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


Step 10: MS of network A in HPLMN originates a REC and MS of network B in HPLMN origi-
REC (GID 299).
cell_B1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

Step 11: MS of network B in HPLMN originates a REC and MS of network B in VPLMN origi-
REC (GID 299).
cell_A1.
299).
299).


200).
A1.
cell_B1.
tion about the incoming VGCS CALL (GID
200).
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


Step 12: MS of network B in HPLMN originates a REC and MS of network A in HPLMN origi-
REC (GID 299).
cell_A1.
299).
299).
200).
A1.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (REC GID: 299, VGCS GID:200) MS_B1 (REC GID: 299, VGCS GID:200)
MS_A2 (VGCS GID:200) MS_B2 (VGCS GID:200)
MS_B3 (REC GID: 299, VGCS GID:200) MS_A3 (REC GID: 299, VGCS GID:200)
MS_B4 (VGCS GID:200) MS_A4 (VGCS GID:200)

Test procedure

nates a VGCS (MSC_B1 anchor).
REC (GID 299).
cell_B1.
299).
299).

GCA_AB1, REC GID: 299 Prio 0, VGCS GID: 200 Prio 2


with priority 2.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (299).
cell_B1.
299).
299).

with priority 2.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

REC (GID 299).
cell_B1.
299).
299).


with priority 2.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (GID 299).
cell_B1.
299).
299).
with priority 2.
cell_B1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

REC (GID 299).
cell_A1.
299).
299).


200).
B1.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

REC (GID 299).
cell_A1.
299).
299).


with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

REC (GID 299).
cell_B1.
299).
299).


with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (GID 299).
cell_B1.
299).
299).
with priority 2.
cell_A1.
and acoustically.
manually.
of REC (GID 299).
call (GID 200).


200).
allocated.

REC (GID 299).
cell_A1.
299).
299).


200).
A1.
cell_B1.
tion about the incoming VGCS CALL (GID
200).
and acoustically.
manually.
of REC (GID 299).
call (GID 200).

200).
allocated.


REC (GID 299).
cell_A1.
299).
299).

200).
A1.
cell_B1.
and acoustically.
manually.
of REC (GID 299).


call (GID 200).

200).
allocated.

d) Success criteria
incoming VGCS call (GID 200). This should succeed in different networks (roaming).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.25 REC first talker notification (MS dedicated mode, incoming VBS call, roaming)


2.2.1
2.5.1
5.2.2.47
5.5.19
5.5.20
5.5.21

a) Purpose
VBS call (GID 202). This should be verified in different networks (roaming).

a VBS (MSC_A1 anchor).
Step 2: MS of network B in VPLMN originates a REC and MS of network A in HPLMN originates a
VBS (MSC_A1 anchor).
Step 3: MS of network A in HPLMN originates a REC and MS of network B in VPLMN originates a
Step 4: MS of network B in VPLMN originates a REC and MS of network B in VPLMN originates a
Step 6: MS of network A in VPLMN originates a REC and MS of network B in HPLMN originates a
Step 7: MS of network B in HPLMN originates a REC and MS of network A in VPLMN originates a
Step 8: MS of network A in VPLMN originates a REC and MS of network A in VPLMN originates a
a VBS (MSC_B1 anchor).


Step 14: MS of network B in VPLMN originates a REC and MS of network A in HPLMN originates
Step 15: MS of network A in HPLMN originates a REC and MS of network B in VPLMN originates
Step 16: MS of network B in VPLMN originates a REC and MS of network B in VPLMN originates
Step 18: MS of network A in VPLMN originates a REC and MS of network B in HPLMN originates
Step 19: MS of network B in HPLMN originates a REC and MS of network A in VPLMN originates
Step 20: MS of network A in VPLMN originates a REC and MS of network A in VPLMN originates



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (REC GID: 299, VBS GID:202) MS_B1 (REC GID: 299, VBS GID:202)
MS_A2 (VBS GID:202) MS_B2 (VBS GID:202)
MS_B3 (REC GID: 299, VBS GID:202) MS_A3 (REC GID: 299, VBS GID:202)
MS_B4 (VBS GID:202) MS_A4 (VBS GID:202)

c) Test procedure

nates a VBS (MSC_A1 anchor).
REC (GID 299).
cell_B1.
299).
299).

GCA_AB1, REC GID: 299 Prio 0, VBS GID: 200 Prio 3


4) MS_A2 originates a VBS call (GID 202)
with priority 3.
cell_B1.
tion about the incoming VBS call (GID 202).
nel about the incoming VBS call (GID 202).
the incoming VBS call (GID 202) optically and
acoustically.
cally accept the incoming VBS call (GID
202), if the priority of the VBS call (GID
202) is higher or equal than 3.
to accept the VBS call (GID 202) manu-
ally.
the VBS call (GID 202); the priority of the VBS
call (GID 202) is lower than the priority of REC
(GID 299).
call (GID 202).

202).
The VBS call (GID 202) is released success-
allocated.
9) MS_A1 terminates the REC (GID 299). REC (GID 299) is released successfully and all


REC (299).
cell_B1.
299).
299).
with priority 3.
cell_B1.
acoustically.
ally.
(GID 299).
6) MS_B3 dont accept the incoming VBS
call (GID 202).

202).
The VBS (GID 202) call is released success-
allocated.


9) MS_B3 terminates the REC (GID 299). REC (GID 299) is released successfully and all

REC (GID 299).
cell_B1.
299).
299).
4) MS_B4 originates a VBS call (GID 202)
with priority 3.
cell_B1.
about the incoming VBS call (GID 202).
acoustically.


ally.
(GID 299).
call (GID 202).

7) MS_B4 terminates the VBS call (GID
202).
allocated.

REC (GID 299).
cell_B1.
299).
299).


with priority 3.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 3.
VBS call is correctly established.
B1.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_A1.
299).
299).
with priority 3.
cell_A1.

acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.

REC (GID 299).
cell_A1.
299).
299).


with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_B1.
299).
299).
with priority 3.
cell_A1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.

REC (GID 299).
cell_B1.
299).
299).


with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (GID 299).
cell_A1.
299).
299).

with priority 3.
A1.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).


202).
allocated.

REC (GID 299).
cell_A1.
299).
299).
with priority 3.
A1.
cell_B1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.



Network A Network B

R-MSC_A1 A-MSC_B1
MS_A1 (REC GID: 299, VBS GID:202) MS_B1 (REC GID: 299, VBS GID:202)
MS_A2 (VBS GID:202) MS_B2 (VBS GID:202)
MS_B3 (REC GID: 299, VBS GID:202) MS_A3 (REC GID: 299, VBS GID:202)
MS_B4 (VBS GID:202) MS_A4 (VBS GID:202)

Test procedure

nates a VBS (MSC_B1 anchor).
REC (GID 299).
cell_B1.
299).
299).

GCA_AB1, REC GID: 299 Prio 0, VBS GID: 200 Prio 3



with priority 3.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (299).
cell_B1.
299).
299).
with priority 3.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_B1.
299).
299).
with priority 3.
cell_B1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.
and 4 for the VBS call (GID 202).

REC (GID 299).
cell_B1.
299).
299).


with priority 3.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 3.
B1.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_A1.
299).
299).

with priority 3.
cell_A1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.


REC (GID 299).
cell_A1.
299).
299).
with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_A1.
299).
299).
with priority 3.
cell_A1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.

REC (GID 299).
cell_B1.
299).
299).


with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.
and 4 for the VBS call (GID 202).


REC (GID 299).
cell_B1.
299).
299).
with priority 3.
cell_A1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.



REC (GID 299).
cell_A1.
299).
299).
with priority 3.
A1.
cell_B1.
acoustically.


ally.
(GID 299).
call (GID 202).

202).
allocated.

REC (GID 299).
cell_A1.
299).
299).


with priority 3.
A1.
cell_B1.
acoustically.
ally.
(GID 299).
call (GID 202).

202).
allocated.

d) Success criteria
incoming VBS call (GID 202). This should succeed in different networks (roaming).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.26 REC first talker notification (MS dedicated mode, incoming second REC, non roam-
ing case)


2.2.1
2.5.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21

a) Purpose
second REC (GID 299).


Network A

Cell_A1 Cell_A2

CoO=Cell_A1

CoO=Cell_A2



c) Test procedure

REC (GID 299).
ing REC (GID 299).
ing REC (GID 299).
REC (GID 299).
cell_A1.
ing REC (GID 299).
MS_A1 and MS_A2 receive an in-band notifi-
cation over the FACCH channel about the in-
coming second REC (GID 299). MS_A1 and
MS_A2 advertise the incoming second REC
(GID 299) optically and acoustically.
ing REC (GID 299).
6) MS_A1 and MS_A2 dont accept the in-
coming second REC (GID 299).

message is send in cell_A1.



d) Success criteria
incoming second REC (GID 299).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.27 REC first talker notification (MS dedicated mode, incoming second REC, roaming)


2.2.1
2.5.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a REC (REC) first talke0r on dedicated channel get a notification about an incoming
second REC (GID 299) call. This should be verified in different networks (roaming).

a second REC (MSC_A1 anchor for both GCAs).
Step 2: MS of network B in VPLMN originates a REC and MS of network B in HPLMN originates a
second REC (MSC_A1 anchor for both GCAs).
Step 4: MS of network B in VPLMN originates a REC and MS of network A in VPLMN originates a
a second REC (MSC_B1 anchor for both GCAs).
Step 6: MS of network A in VPLMN originates a REC and MS of network A in HPLMN originates a
second REC (MSC_B1 anchor for both GCAs).
Step 7: MS of network B in HPLMN originates a REC and MS of network B in VPLMN originates a
Step 8: MS of network A in VPLMN originates a REC and MS of network B in VPLMN originates a
a second REC (MSC_A1 anchor for GCA_A1 and MSC_B1 anchor for GCA_AB1).
Step 10: MS of network B in VPLMN originates a REC and MS of network B in HPLMN originates
Step 12: MS of network B in VPLMN originates a REC and MS of network A in VPLMN originates
a second REC (MSC_A1 anchor for GCA_AB1 and MSC_B1 anchor for GCA_B1).


Step 14: MS of network A in VPLMN originates a REC and MS of network A in HPLMN originates
Step 16: MS of network A in VPLMN originates a REC and MS of network B in VPLMN originates


Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

CoO=Cell_A1

CoO=Cell_B1



nates a second REC (MSC_A1 anchor for both GCAs).
REC (GID 299).
MS_A2 MS_B3 and MS_B4 receive a notifica-
299).
299).

cell_A1.
MS_B2, MS_A3 and MS_A4 receive a notifica-
MS_A1, MS_A2, MS_B3 and MS_B4 receive
nel about the incoming second REC (GID 299).
MS_A1, MS_A2, MS_B3 and MS_B4 advertise
the incoming second REC (GID 299) optically
and acoustically.
5) MS_B2, MS_A3 and MS_A4 automati-
299).
MS_B2, MS_A3 and MS_A4 join REC (GID
299).
dont accept the incoming second REC
(GID 299).

8) MS_B1 terminates the REC (GID 299). The REC (GID 299) is released successfully



Step 2: MS of network B in VPLMN originates a REC and MS of network B in HPLMN origi-
REC (GID 299).
MS_A1 MS_A2 and MS_B4 receive a notifica-
299).
299).
cell_A1.
and acoustically.
299).
299).
(GID 299).



REC (GID 299).
299).
299).

cell_A1.
MS_B1, MS_B2 and MS_A4 receive a notifica-
and acoustically.


5) MS_B1, MS_B2 and MS_A4 automati-
299).
MS_B1, MS_B2 and MS_A4 join REC (GID
299).
(GID 299).

8) MS_A3 terminates the REC (GID 299). The REC (GID 299) is released successfully

Step 4: MS of network B in VPLMN originates a REC and MS of network A in VPLMN origi-
REC (GID 299).
299).
299).


cell_A1.
and acoustically.
299).
299).
(GID 299).



Test configuration for test step 5 to 8

Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

nates a second REC (MSC_B1 anchor for both GCAs).
REC (GID 299).
MS_B2 MS_A3 and MS_A4 receive a notifica-
CoO=Cell_B1

CoO=Cell_A1



299).
299).
3) MS_B1 takes the uplink on DCH. MS_B1 has two-way voice path. MS_B2,
cell_B1.
MS_B1, MS_B2, MS_A3 and MS_A4 receive
MS_B1, MS_B2, MS_A3 and MS_A4 advertise
and acoustically.
299).
299).
6) MS_B1, MS_B2, MS_A3 and MS_A4
(GID 299).

message is send in cell_B1.


Step 6: MS of network A in VPLMN originates a REC and MS of network A in HPLMN origi-
REC (GID 299).
299).
299).
3) MS_A3 takes the uplink on DCH. MS_A3 has two-way voice path. MS_B1,

cell_B1.
and acoustically.
299).
299).
(GID 299).




REC (GID 299).
299).
299).
channel (GCCH) are allocated in cell_a1.
cell_B1.
and acoustically.
299).
299).
(GID 299).



Step 8: MS of network A in VPLMN originates a REC and MS of network B in VPLMN origi-
REC (GID 299).
MS_B1 MS_B2 and MS_A4 receive a notifica-
299).
299).
cell_B1.
and acoustically.


299).
299).
(GID 299).




Network A Network B

R-MSC_A1 (GCA_AB1) A-MSC_B1 (GCA_AB1)
A-MSC_A1 (GCA_A1)

Test procedure

nates a second REC (MSC_A1 anchor for GCA_A1 and MSC_B1 anchor for GCA_AB1).
REC (GID 299).
CoO=Cell_A1

CoO=Cell_B1



299).
299).
cell_A1.
and acoustically.
299).
299).
(GID 299).



Step 10: MS of network B in VPLMN originates a REC and MS of network B in HPLMN origi-
REC (GID 299).
299).
299).

cell_A1.
and acoustically.
299).
299).
(GID 299).




REC (GID 299).
299).
299).
cell_A1.
and acoustically.
299).
299).


(GID 299).


Step 12: MS of network B in VPLMN originates a REC and MS of network A in VPLMN origi-
REC (GID 299).
299).
299).


cell_A1.
and acoustically.
299).
299).
(GID 299).




Network A Network B

A-MSC_A1 (GCA_AB1) R-MSC_B1 (GCA_AB1)
A-MSC_B1 (GCA_B1)

Test procedure

CoO=Cell_B1

CoO=Cell_AB1



nates a second REC (MSC_A1 anchor for GCA_AB1 and MSC_B1 anchor for GCA_B1).
REC (GID 299).
299).
299).
cell_B1.
and acoustically.
299).
299).
(GID 299).




Step 14: MS of network A in VPLMN originates a REC and MS of network A in HPLMN origi-
REC (GID 299).
299).
299).
cell_B1.
and acoustically.
299).
299).
(GID 299).



REC (GID 299).
299).
299).


channel (GCCH) are allocated in cell_a1.
cell_B1.

and acoustically.
299).
299).
(GID 299).



Step 16: MS of network A in VPLMN originates a REC and MS of network B in VPLMN origi-
REC (GID 299).
MS_B1 MS_B2 and MS_A4 receive a notifica-
299).
299).
cell_B1.
and acoustically.
299).
299).
(GID 299).




d) Success criteria
incoming second REC (GID 299). This should succeed in different networks (roaming).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.28 Shunting emergency call (non-roaming case)


2.5.1
13.1.7
13.1.8
13.2.4.1
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3

a) Purpose
Verify a service subscriber in shunting mode can originate and close a Railway Emergency Call
(REC) with GID 599.

MS_A1 and MS_A2 are shunting mobiles in shunting mode and not registered to a functional
number (FN).

Network A


CoO=Cell_A1



c) Test procedure

(GID 599).
(GID 599).
in group receive mode and is able to listen to
of MS_A1.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.


ment of CT_A1.
of CT_A1.
of MS_A1.
of MS_A2.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A2.



d) Success criteria
MS_A1 was able to originate and close a Railway Emergency Call (REC) with GID 599.
MS_A1 was able to get the uplink on DCH and GCCH.
MS_A2 was able to receive the Railway Emergency Call (REC) with GID 599 and able to get the
uplink on GCCH.
CT_A1 is able to receive the Railway Emergency Call (REC) with GID 599 and is able to un-
mute/mute the downlink to the talking mobile subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.6.29 Shunting emergency call (roaming case)


2.5.1
13.1.7
13.1.8
13.2.4.1
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3

a) Purpose
Verify a roaming service subscriber can originate and close a Railway Emergency Call (REC) with
GID 599.

MS_A1, MS_A2, MS_B1 and MS_B2 are shunting mobiles in shunting mode and not registered
to a functional number (FN).

Step 1: REC setup by roaming subscriber in network A (MSC_A1 anchor).
Step 2: REC setup by roaming subscriber in network B (MSC_A1 anchor).
Step 3: REC setup by roaming subscriber in network A (MSC_B1 anchor).
Step 4: REC setup by roaming subscriber in network B (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: REC setup by roaming subscriber in network A (MSC_A1 anchor).
Cell_B1.
mode.



REC (GID 599).
and CT_B1.
of MS_B2.
of MS_B2.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
rectly released.
of MS_A2.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
rectly released.


Step 2: REC setup by roaming subscriber in network B (MSC_A1 anchor).
Cell_A1.
mode.
REC (GID 599).
and CT_B1.
of MS_A2.
of MS_A2.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.
rectly released.


of MS_B2.
###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
MS_A1, MS_B1, MS_A2 still able to listen to
rectly released.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 3: REC setup by roaming subscriber in network A (MSC_B1 anchor).
Cell_B1.
mode.



REC (GID 599).
and CT_B1.
of MS_B2.
of MS_B2.
###).
GCCH.
CT_B1.
downlink.


###).
GCCH.
CT_B1.
downlink.
rectly released.
of MS_A2.
###).
voice path on GCCH.
CT_B1.


###).
voice path on GCCH.
CT_B1.
rectly released.


Step 4: REC setup by roaming subscriber in network B (MSC_B1 anchor).
Cell_A1.
mode.
REC (GID 599).
and CT_B1.
of MS_A2.
of MS_A2.


###).
voice path on GCCH.
CT_B1.
###).
voice path on GCCH.
CT_B1.
rectly released.
of MS_B2.


###).
GCCH.
CT_B1.
downlink.
###).
GCCH.
CT_B1.
downlink.
rectly released.



d) Success criteria
MS_A2 was able to originate and close a Railway Emergency Call (REC) with GID 599 when
roaming in network B.
MS_A2 was able to get the uplink on DCH and GCCH
MS_B2 was able to originate and close a Railway Emergency Call (REC) with GID 599 when
roaming in network A.
MS_B2 was able to get the uplink on DCH and GCCH.
CT_A1 and CT_B1 are able to receive the Railway Emergency Call (REC) with GID 599 and they
are also able to un-mute/mute the downlink to the talking mobile subscriber on GCCH.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7 eMLPP

Reference to EIRENE FRS V7:

Chapter: Text
2.4.1 The EIRENE network will support the following call related services:
- display of identity of called/calling user; (M)
- restriction of display of called/calling user; (O)
- priority and pre-emption; (M)
- closed user group; (M)
- call forwarding; (M)
- call hold; (M)
- call waiting; (M)
- charging information; (O)
- call barring. (M)
Display of identity
2.4.5 The network shall provide a mechanism whereby calls may be assigned one of a num-
ber of different priority levels. (M)
2.4.6 This mechanism shall allow calls with a higher assigned priority to override (pre-empt)
existing calls of a lower priority. (M)
2.4.7 Pre-empted calls will be discontinued and the new call of a higher priority shall be con-
nected instead. (M)
10.2.1 A number of levels of priority shall be required in order to offer different grades of ser-
vice to different users and calls. Five levels of priority shall be defined: (M)
- Railway emergency;
- control-command (safety);
- public emergency and group calls between drivers in the same area;
- railway operation;
- railway information.
10.2.2 In order to provide interoperability, priorities shall be allocated consistently across all
EIRENE networks, as shown in the following table. (M)



10.2.3 The lowest priority ongoing call shall be pre-empted before that of a higher priority. (M)

Reference to EIRENE SRS 15:

Chapter: Text
2.4.1 The GSM supplementary services [EN 301 515, Index [9]] to be supported are listed in
table 2-3. The applicability of these supplementary services to GSM basic services will
be as indicated in [GSM 02.81-02.89 and EN 301 515, Index [28]]. (I)
9.8.5 In addition, the network shall support the special short codes as defined in table 9-11.
(M)
Code Description
112 European emergency number



General Purpose:
Verify the call related service eMLPP in GSM-R Network
Verify that a mobile subscriber can be subscribed with a default and a maximal priority
Verify that pre-emption of calls on the Um take place, when there are not enough traffic channels
available.
Verify that the network allows the call with the highest priority in case of lack of resources.
Verify that pre-emption applies also in case of handover.
To verify called party pre-emption based on the transmitted eMLPP priority.

Preconditions:
Fast Call Setup is configured for high priority calls on SIM.
Not all subscribers and controllers are subscribed for the REC.
The function of the subscribers and controllers can change from step to step and from case to
case.
All subscribers have the default priority 4 and max priority 0 subscribed in HLR.
Cab Radios are used for the test of the eMLPP priority transmitted to the MS based on Automatic
Answering.
Cab Radios are prepared for VGCS and VBS.

The priorities assigned to the GIDs are as follows:
VGCS GID: 299 => Priority=0
VBS GID: 202 => Priority=3
VBS GID: 203 => Priority=4


5.7.1 MS in VBS call as listener, pre-emption on MS by higher prio PtP call


2.4.1
2.4.5
2.4.6
2.4.7
3.2.3
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
To verify pre-emption on MS based on the transmitted eMLPP priority.


Network A


c) Test procedure

1 MS_A1 originates the 203 VBS MS_A2 receives the 203 VBS
2 MS_A3 calls MS_A2 with Prio 3 MS_A2 answers automatically the PtP call
3 MS_A3 releases the PtP call MS_A2 receives the 203 VBS
4 MS_A1 releases the VBS call All participants are IDLE



d) Success criteria
The pre-emption on MS based on the transmitted eMLPP priority has taken place in the mobile.
The expected priorities have been used at Um.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.2 MS in VGCS call on DCH, pre-emption on Um by higher prio PtP call


2.4.1
2.4.5
2.4.6
2.4.7
3.2.3
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the dedicated channel of a VGCS can be pre-empted on Um by a PtP call.


Network A

Cell_A1 Cell_A2 Cell_A3
MS_A1 (VGCS GID: 204, Cell_A1)
MS_A4 (Cell_A1, no VGCS / VBS
subscriber)

MS_A5 (Cell_A1, no VGCS / VBS
subscriber)

CT_A1
The Capacity on the Um in Cell_A1 is reduced to two TSs



c) Test procedure

1 MS_A1 originates the 204 VGCS and
keep the dedicated link (DCH)
CT_A1 receives the 204 VGCS
2 MS_A4 calls MS_A5 with Prio 4 The call is unsuccessful
3 MS_A4 calls MS_A5 with Prio 3 The DCH and the group channel is pre-
empted on Um in Cell_A1
MS_A1 and MS_A2 are IDLE
MS_A3 can take the uplink and speak to
CT_A1
4 CT_A1 terminates the group call MS_A3 is IDLE
5 MS_A4 releases the PtP call All participants are IDLE
6 Unblock/unlock the blocked/locked TSs
in Cell_A1
All resources are IDLE

d) Success criteria
The dedicated channel of a VGCS call can be pre-empted on Um by a PtP call with higher prior-
ity.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.3 MS in VGCS call having the UL of the GCH, pre-emption on A IF by higher prio PtP
call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a group channel of a VGCS can be pre-empted on A IF by a PtP call.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 204, Cell_A1) MS_A2 (VGCS GID: 204, Cell_A2)
MS_A4 (Cell_A1, no VGCS / VBS subscriber) MS_A5 (Cell_A2, no VGCS / VBS subscriber)
The Capacity on the A IF to BSC_A2 is reduced to one TS
Only the Cell_A2 belongs to the GCA in BSC_A2


c) Test procedure

1 MS_A1 originates the 204 VGCS and do
not keep the dedicated link (DCH)
2 MS_A2 requests the uplink MS_A2 can speak to MS_A1 and MS_A3
4 MS_A4 calls MS_A5 with Prio 3 The group channel is pre-empted on A IF of
BSC_A2
MS_A2 are IDLE
MS_A1
5 MS_A1 releases the group call
MS_A4 releases the PtP
6 MS_A1 originates the 204 VGCS and do
not keep the dedicated link (DCH)
7 MS_A2 requests the uplink MS_A2 can speak to MS_A1 and MS_A3
9 MS_A5 calls MS_A4 with Prio 3 The group channel is pre-empted on A IF of
BSC_A2
MS_A2 are IDLE
MS_A1
10 MS_A1 releases the group call
MS_A4 releases the PtP
11 Unblock/unlock the blocked/locked TSs
on A IF to BSC_A2

d) Success criteria
The group channel of a VGCS call can be pre-empted on A IF by a PtP call with higher priority.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.4 MS in PEC, pre-emption on A-IF by higher prio PtP call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1
9.8.5

a) Purpose
Verify that a MS in PEC can be pre-empted on A-IF by a PtP call.


Network A

Cell_A1 Cell_A2
MS_A1 (Cell_A1, no VGCS / VBS subscriber) MS_A2 (Cell_A2, no VGCS / VBS subscriber)
MS_A3 (Cell_A2, no VGCS / VBS subscriber)
The Capacity on the A IF to BSC_A2 is reduced to one TS

c) Test procedure

1 MS_A2 originates a 112 PEC MS_A2 is connected with emergency operator
2 MS_A1 calls MS_A3 with Prio 2 Call is unsuccessful


3 MS_A1 calls MS_A3 with Prio 1 MS_A2 is pre-empted at A-IF
MS_A2 is IDLE
5 MS_A2 originates a 112 PEC MS_A2 is connected with emergency operator
7 MS_A3 calls MS_A1 with Prio 1 (e.g.
data call)
MS_A2 is pre-empted at A-IF
MS_A2 is IDLE
9 Unblock the TSs to BCS_A2 at A-IF All resources are IDLE

d) Success criteria
A MS in PEC can be pre-empted on A-IF by a PtP call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.5 MS in PtP call, pre-emption on MS by higher prio VBS call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose


Network A


c) Test procedure

1 MS_A3 calls MS_A4 with Prio 4 MS_A3 is connected with MS_A4


MS_A3 receives automatically the 202 VBS
MS_A4 receives automatically the 202 VBS
The PtP call is released

d) Success criteria
A PtP call can be pre-empted in mobile by a VBS call with higher priority. The pre-emption is
based on the transmitted eMLPP priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.6 MS in VBS call as originator, pre-emption on A IF by higher prio VBS call


2.2.9
2.4.1
2,4,5
2.4.6
2.4.7
20.1.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS-Call can be pre-empted on A-Interface by another VBS-Call with higher priority.


Network A

The Capacity on the A-IF to BSC_A1 is reduced to two TSs

c) Test procedure



All TSs at A-IF are BUSY
The 203 VBS-Call is terminated
4 Unblock all TSS at A-IF All resources are IDLE

d) Success criteria
A VBS-Call can be pre-empted on A-Interface by another VBS-Call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.7 MS in VBS call as listener, pre-emption on Um by higher prio VBS call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS-group channel can be pre-empted on Um by another VBS-Call with higher prior-
ity.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID: 203, Cell_A1) MS_A2 (VBS GID: 203, Cell_A2)
MS_A3 (VBS GID: 202, Cell_A1) MS_A4 (VBS GID: 202, Cell A2)
The Capacity on the Um in Cell_A2 is reduced to one TS



c) Test procedure

All TSs at Um in Cell_A2 are BUSY
2 MS_A3 originates the 202 VBS MS_A4 receives the 202 VBS in Cell_A2
The 203 VBS-group channel in Cell_A2 is
pre-empted
MS_A2 is IDLE
3 MS_A1 and MS_A3 releases the VBS
calls
4 Unblock all TSS at Um in Cell_A2 All resources are IDLE

d) Success criteria
A VBS-group channel can be pre-empted on Um by another VBS-Call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.8 MS in VGCS call on DCH, pre-emption on MS by higher prio VBS call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose


Network A

MS_A1 (VGCS GID: 204, VBS GID: 211)

c) Test procedure

1 MS_A1 originates the 204 VGCS and
keeps the DCH


MS_A1 receives the 202 VBS
MS_A2 can take the uplink in the 204 VGCS
3 MS_A1 and MS_A3 releases the VGCS
and the VBS call

d) Success criteria
The DCH of en VGCS call can be pre-empted in the mobile by a VBS call with higher priority. The
pre-emption is based on the transmitted eMLPP priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.9 MS in VGCS call having the UL of the GCH, pre-emption on Um by higher prio VBS
call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS-group channel can be pre-empted on Um by another VBS-Call with higher
priority.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 204, Cell_A1) MS_A2 (VGCS GID: 204, Cell_A2)
MS_A3 (VBS GID: 202, Cell_A1) MS_A4 (VBS GID: 202, Cell A2)



c) Test procedure

1 MS_A1 originates the 204 VGCS MS_A2 receives the 204 VGCS and take the
uplink
All TSs at Um in Cell_A2 are BUSY
2 MS_A3 originates the 202 VBS MS_A4 receives the 202 VBS in Cell_A2
The 204 VGCS-group channel in Cell_A2
is pre-empted by the VBS group channel
MS_A2 is IDLE
MS_A1 can take the uplink of the VGCS-call
3 MS_A1 and MS_A3 releases the VGCS
and the VBS calls
4 Unblock all TSS at Um in Cell_A2 All resources are IDLE

d) Success criteria
A VGCS-group channel with an active UL can be pre-empted on Um by a VBS-call with higher
priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.10 MS in data call, pre-emption on A IF by higher prio VBS call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a data call can be pre-empted on Um by another VBS-Call with higher priority.


Network A

The Capacity on the A-IF in BSC_A1 is reduced to two TSs

c) Test procedure



1 MS_A1 originates a data call (transpar-
ent, 2.4, 4.8 or 9.6 kbit/s) to MS_A2 with
Prio 4
MS_1 connected with MS_A2
All TSS at A-IF are BUSY
MS_A1 and MS_A2 are pre-empted at A-IF
4 Unblock the TSs at Um All resources are IDLE

d) Success criteria
A data call can be pre-empted on Um by a VBS-Call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.11 MS in PEC, pre-emption on Um by REC


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3

a) Purpose
Verify that the priority two is assigned by the network to a PEC and that the PEC can be pre-
empted on Um by a REC.


Network A

MS_A3 ( REC GID: 299)

c) Test procedure



1 MS_A1 originates a 112 PEC MS_1 is connected with the emergency control
manager
2 CT_A1 originates the REC MS_A1 is pre-empted at Um
3 CT_A1 releases the REC All participants are IDLE

d) Success criteria
The priority two is assigned by the network to a PEC and the PEC can be pre-empted on Um by a
REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.12 MS in PtP call, pre-emption on A IF by higher prio PtP call


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted on A-Interface by another PtP-Call with higher priority.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3 MS_A4
The Capacity on the A-IF to BSC_A2 is reduced to one TS

c) Test procedure



3 MS_A3 calls MS_A4 with Prio 3 MS_A1 is disconnected from MS_A2
MS_A3 is connected with MS_A4 with Prio 3
4 MS_A2 releases the call All participants are IDLE
5 Unblock the TSs to BSC_A2 All resources are IDLE

d) Success criteria
A PtP call can be pre-empted on A-Interface by another PtP-Call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.13 MS in PtP call, pre-emption on MS by higher prio VGCS call (REC)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose


Network A


c) Test procedure



1 MS_A1 calls MS_A2 with Prio 3 MS_1 is connected MS_A2
2 MS_A3 originates the REC MS_A4 receives the REC
MS_A1 and MS_A2 receives the REC
All Mobiles are involved in the REC
3 MS_A3 releases the REC All participants are IDLE

d) Success criteria
The pre-emption on MS takes place in the mobile. The pre-emption is based on the transmitted
eMLPP priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.14 MS in VBS call as originator, pre-emption on Um by higher prio VGCS call (REC)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the DCH of a VBS call can be pre-empted on A-Interface by a REC


Network A


c) Test procedure



1 MS_A1 originates the 202 VBS MS_2 receives the VBS
2 MS_A3 originates the 299 REC MS_A4 receives the 299 REC
The VBS DCH and the group channel are
pre-empted by the REC

d) Success criteria
The DCH of a VBS call can be pre-empted on A-Interface by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.15 MS in VBS call as listener, pre-emption on A IF by higher prio VGCS call (REC)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the group channel of a VBS call can be pre-empted on A-Interface by a REC.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID: 202) MS_A2 (VBS GID: 202)
The Capacity on the A-IF of BSC_A2 is reduced to one TS
Only one cell of BSC_A2 belongs to the GCA

c) Test procedure



The group channel of the VBS is pre-
empted at A-IF of BSC_A2
MS_A2 is IDLE

d) Success criteria
The group channel of a VBS call can be pre-empted on A-Interface by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.16 MS in VGCS call having the UL of the GCH, pre-emption on MS by higher prio VGCS
call (REC)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3

a) Purpose


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 200) MS_A2 (VGCS GID: 200, REC GID: 299)

c) Test procedure



1 MS_A1 originates the 200 VGCS MS_A2 receives the 200 VGCS and take the
uplink
MS_A2 receives the 299 REC
MS_A1 can take the uplink of the 200 VGCS
3 MS_A3 releases the REC
MS_A1 releases the 200 VGCS

d) Success criteria
Mobile keeping the uplink of a VGCS call is notified about a REC. The VGCS call with the lower
priority is pre-empted at the mobile. The pre-emption in the mobile is based on the transmitted
eMLPP priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.17 MS in VGCS call as listener, pre-emption on A IF by higher prio VGCS call (REC)


2.2.14
2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel call can be pre-empted on A-Interface by a VGCS-Call with
higher priority.


Network A

Cell_A1 Cell_A2
Only one cell of BSC_A2 belongs to the GCA

c) Test procedure



1 MS_A1 originates the 200 VGCS
and take the uplink
empted
3 MS_A3 releases the REC
MS_A1 releases the 200 VGCS
4 Unblock the A-IF TSs to BSC_A2 All resources are IDLE

d) Success criteria
A VGCS group channel call can be pre-empted on A-Interface by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.18 MS in data call, pre-emption on Um by higher prio VGCS call (REC)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a data call can be pre-empted on Um by VGCS-Call with higher priority.


Network A

Cell_A1 Cell_A2
The Capacity on the Um of Cell_A1 is reduced to two TSs

c) Test procedure



1 MS_A3 originates a data call with Prio 1
(transparent, 2.4, 4.8 or 9.6 kbit/s) to
MS_A4
One TS in Cell_A1 is BUSY, one TS is IDLE
MS_A3 is pre-empted in Cell_A1
4 Unblock the Um TSs in Cell_A1 All resources are IDLE

d) Success criteria
A data call can be pre-empted on Um by a REC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.19 MS in PtP call, pre-emption on Um by higher prio data call (4.8 kbit/s, transparent)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted on Um by a data call with higher priority


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3 MS_A4
The Capacity on the Um of Cell_A1 is reduced to one TS

c) Test procedure

All TSs in Cell_A1 are BUSY
ent, 4.8 kbit/s) with Prio 4 to MS_A4
Call is unsuccessful


to MS_A4 (transparent, 4.8 kbit/s)
4 MS_A3 releases the data call All participants are IDLE

d) Success criteria
A PtP call can be pre-empted on Um by a data call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.20 MS in VBS call as originator, pre-emption on Um by higher prio data call (9.6 kbit/s,
transparent)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the DCH of a VBS call can be pre-empted on Um by a data call with higher priority.


Network A

Cell_A1 Cell_A2
The Capacity on the Um of Cell_A1 is reduced to two TSs

c) Test procedure



1 MS_A1 originates a 202 VBS call MS_A2 receives the 202 VBS call
to MS_A4 (9.6 kbit/s, transparent)
The DCH or the group channel of the VBS
call is pre-empted:
- DCH => VBS call is terminated
- Group Channel => VBS may be terminated
4 MS_A1 releases the VBS call (if still ex-
isting)
MS_A3 releases the data call
The DCH or the group channel of the VBS
call is pre-empted:
- DCH => VBS call is terminated
- Group Channel => VBS may be terminated
7 MS_A1 releases the VBS call (if still ex-
isting)
The VBS call is terminated (DCH and group
channel are pre-empted)

d) Success criteria
The DCH of a VBS call can be pre-empted on Um by a data call with higher priority.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.21 MS in VGCS call on DCH, pre-emption on A IF by higher prio data call (9.6 kbit/s,
transparent)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the DCH of a VGCS call can be pre-empted on A-Interface by a data call with higher
priority.


Network A

Cell_A1 Cell_A2

c) Test procedure


1 MS_A1 originates a 200 VGCS call and
keep the DCH
call
to MS_A4 (9600 baud tr.)
The DCH or the group channel of the VGCS
call is pre-empted:
- DCH => VGCS call is continued
- Group Channel => VGCS may be terminated
4 CT_A1 terminates the VGCS call (if ex-
isting)
keep the DCH
MS_A2 and CT_A1 receive the 200 VGCS call
The DCH and the group channel are pre-
empted in Cell_A1
The VGCS call may be terminated in BSC_A1
or in all BSCs
7 CT_A1 terminates the VGCS call (if ex-
isting)

d) Success criteria
The DCH of a VGCS call can be pre-empted on A-Interface by a data call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.22 MS in VGCS as listener, pre-emption on Um by data call (4.8 kbit/s, transparent)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel can be pre-empted on Um by a data call with higher priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



1 MS_A1 originates a 200 VGCS call MS_A2 and MS_A5 receive the 200 VGCS call
The group channel is pre-empted in Cell_A2
MS_A2 is IDLE
MS_A1 and MS_A5 are still in the VGCS call
4 MS_A1 releases the VGCS call
5 MS_A1 originates a 200 VGCS call MS_A2 and MS_A5 receive the 200 VGCS call
The group channel is pre-empted in Cell_A2
MS_A2 is IDLE
MS_A1 and MS_A5 are still in the VGCS call

d) Success criteria
A VGCS group channel can be pre-empted on Um by a data call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.23 MS in VBS call as originator, pre-emption on A IF by higher prio data call (2.4 kbit/s,
transparent)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the group channel and the connection to the originator of a VBS call can be pre-
empted on A-Interface by a data call with higher priority.


Network A

Cell_A1 Cell_A2
Only the Cell_A1 in BSC_A1 belongs to the GCA.


c) Test procedure

1 MS_A5 originates a 202 VBS call MS_A1 and MS_A2 receive the 202 VBS call
The VBS group call is terminated. The
group channel and the connection to the
originator are preempted.

d) Success criteria
The group channel and the connection to the originator of a VBS call can be pre-empted on A-
Interface by a data call with higher priority.

e) Test result
Remarks
Attachments
(log / trace file)

Signature


5.7.24 MS in VBS call as originator, pre-emption on A IF by lower prio PtP call does not
take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the DCH of a VBS call can not be pre-empted on A-Interface by a PtP call with lower
priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



to MS_A4
3 MS_A4 originates a data call ((transpar-
ent, 2.4, 4.8 or 9.6 kbit/s) with Prio 4 to
MS_A3

d) Success criteria
The DCH of a VBS call can not be pre-empted on A-Interface by a PtP call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.25 MS in VBS call as listener, pre-emption on Um by lower prio PtP call does not take
place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.5

a) Purpose
Verify that a VBS group channel can not be pre-empted on Um by a PtP call with lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



MS_A4
to MS_A4
5 Unblock the Um TSs to Cell_A1 All resources are IDLE

d) Success criteria
A VBS group channel can not be pre-empted on Um by a PtP call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.26 MS in VGCS call as listener, pre-emption on Um by lower prio PtP call does not take
place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel ca not be pre-empted on Um by a PtP call with lower priority.


Network A

Cell_A1 Cell_A2
The Capacity on the Um in Cell_A2 is reduced to one TS!!!

c) Test procedure



1 MS_A1 originates a 200 VGCS call MS_A2 receives the 200 VGCS call
MS_A3
to MS_A4
4 MS_A1 releases the VGCS call All participants are IDLE

d) Success criteria
A VGCS group channel can not be pre-empted on Um by a PtP call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.27 MS in data call, pre-emption on A IF by lower prio PtP call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a data call can not be pre-empted on A-Interface by a PtP-Call with lower priority.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3 MS_A4
The Capacity on the A-IF of BSC_A2 is reduced to one TS

c) Test procedure

MS_A2
There are no IDLE TSs to BSC_A2



d) Success criteria
A data call can not be pre-empted on A-Interface by a PtP-Call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.28 MS in VGCS call, pre-emption on Um by lower prio VBS call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel can not be pre-empted on Um by a VBS call with lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



2 MS_A3 originates a 202 VBS call The VBS group channel in Cell_A2 is not
established.
The VBS is established in Cell_A1
3 MS_A3 releases the VBS call
4 The Capacity on the Um in Cell_A1 is
reduced to two TSs!!!
All TSs in Cell_A2 are unblocked!!
The test conditions have changed.

200 VGCS is still active
5 MS_A3 originates a 202 VBS call The VBS DCH and the group channel in
Cell_A1 are not established.

d) Success criteria
A VGCS group channel can not be pre-empted on Um by a VBS call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.29 MS in VGCS call as listener, pre-emption on A IF by lower prio VBS call does not
take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel can not be pre-empted on A-Interface by a VBS call with lower
priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



2 MS_A3 originates a 202 VBS call The VBS group channel in Cell_A2 is not
established.
The VBS is established in Cell_A1
MS_A2 is still in the 200 VGCS call.
MS_A3 releases the VBS call

d) Success criteria
A VGCS group channel can not be pre-empted on A-Interface by a VBS call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.30 MS in VGCS call on DCH, pre-emption on A IF by lower prio VGCS call does not take
place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS DCH can not be pre-empted on A-Interface by a VGCS call with lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



keeps the DCH
MS_A2 receives the 200 VGCS call
2 MS_A3 originates a 201 VGCS call The VGCS call is not established.
MS_A3 get a proper release cause.
MS_A2 is still in the 200 VGCS call.

d) Success criteria
A VGCS DCH can not be pre-empted on A-Interface by a VGCS call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.31 MS in VGCS call having the UL on the GCH, pre-emption on Um by lower prio VGCS
all does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel with uplink can not be pre-empted on Um by a VGCS call with
lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



2 MS_A2 takes the uplink MS_A1 is listening to MS_A2
3 MS_A3 originates a 201 VGCS call The 201 VGCS group channel in Cell_A2 is
not established.
The 200 VGCS group channel is not pre-
empted
The 201 VGCS call is established in Cell_A1
4 MS_A1 releases the 200 VGCS call
MS_A3 releases the 201 VGCS call

d) Success criteria
A VGCS group channel with active uplink can not be pre-empted on Um by a VGCS call with
lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.32 MS in PEC, pre-emption on Um by lower prio VGCS call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1
9.8.5

a) Purpose
Verify that a PEC can not be pre-empted on Um by a VGCS call with lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



1 MS_A3 originates a 112 PEC MS_A3 is connected to the emergency center
2 MS_A1 originates a 201 VGCS call The 201 VGCS group channel in Cell_A2 is
not established.
The 201 VGCS call is established in Cell_A1
3 MS_A1 releases the 201 VGCS call
MS_A3 releases the PEC

d) Success criteria
A PEC can not be pre-empted on Um by a VGCS call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.33 MS in VBS call as originator, pre-emption on Um by lower prio data call does not
take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS DCH can not be pre-empted on Um by a data call with lower priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



There are no IDLE TSs in Cell_A1
MS_A4
MS_A3

d) Success criteria
A VBS DCH can not be pre-empted on Um by a data call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.34 MS in VBS call as listener, pre-emption on A IF by lower prio data call does not take
place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS group channel can not be pre-empted on A-Interface by a data call with lower
priority.


Network A

Cell_A1 Cell_A2
The Capacity on the A-IF to BSC_A1 is reduced to one TS.

c) Test procedure



Prio 4
Prio 4
Prio 3
Prio 3

d) Success criteria
A VBS group channel can not be pre-empted on A-Interface by a data call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.35 MS in VGCS call having the UL of the GCH, pre-emption on A IF by lower prio data
call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS group channel can not be pre-empted on A-Interface by a data call with lower
priority.


Network A

Cell_A1 Cell_A2

c) Test procedure



1 MS_A2 originates a 200 VGCS call MS_A1 receives the 200 VGCS call and take
the uplink.
ent, 2.4, 4.8 or 9.6 kbit/s) to MS_A4
with Prio 4
with Prio 4
with Prio 3
with Prio 3

d) Success criteria
A VGCS group channel can not be pre-empted on A-Interface by a data call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.36 MS in data call, pre-emption on Um by lower prio data call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a data call can not be pre-empted on Um by a data call with lower priority.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3 MS_A4

c) Test procedure

Prio 1
MS_A4


MS_A4
MS_A3

d) Success criteria
A data call can not be pre-empted on Um by a data call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.37 MS in PEC, pre-emption on A IF by lower priority data call does not take place


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1
9.8.5

a) Purpose
Verify that a PEC call can not be pre-empted on A-Interface by a data call with lower priority.


Network A

Cell_A1 Cell_A2
MS_A1
MS_A3 MS_A4

c) Test procedure

1 MS_A1 originates a 112 PEC MS_A1 is connected with the emergency center
2 MS_A3 originates a data call
(transparent, 2.4, 4.8 or 9.6 kbit/s)
with Prio 4 to MS_A4


5 MS_A1 releases the PEC All participants are IDLE

d) Success criteria
A PEC call can not be pre-empted on A-Interface by a data call with lower priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.38 Pre-emption of VBS A IF resources on A and B BSS simultaneously


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS call can be pre-empted on two A-Interfaces simultaneously.


Network A

Cell_A1 Cell_A2
MS_A1 (REC, VBS GID: 202) MS_A2 (REC GID: 299, VBS GID: 202)
CT_A2 (GCA_A1, VBS GID: 202)
The Capacity on the A-IF to BSC_A1 and to BSC_A2 is reduced to one TS

c) Test procedure



1 CT_A2 originates a 202 VBS MS_A1 and MS_A2 receive the VBS call
There are no IDLE TSs to BSC_A1 and
BSC_A2
2 CT_A1 originates a 299 REC The VBS group channels are pre-empted at
A-IF to BSC_A1 and BSC_A2
MS_A1 and MS_A2 receive the REC
CT_A2 is IDLE, the VBS call is terminated
3 CT_A1 terminates the REC All participants are IDLE
4 Unblock the A-IF TSs to BSC_A1 and
BSC_A2

d) Success criteria
A VBS call can be pre-empted on two A-Interfaces simultaneously.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.39 Pre-emption of VGCS A IF resources on A and B BSS simultaneously


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS call can be pre-empted on two A-Interfaces simultaneously.


Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299, VGCS GID: 200) MS_A2 (REC GID:299, VGCS GID: 200)
The Capacity on the A-IF to BSC_A1 and to BSC_A2 is reduced to one TS

c) Test procedure



1 CT_A2 originates a 200 VGCS MS_A1 and MS_A2 receive the VGCS call
BSC_A2
2 CT_A1 originates the 299 REC The VGCS group channels are pre-empted
at A-IF to BSC_A1 and BSC_A2
CT_A2 is IDLE, the VGCS call is terminated
4 Unblock the A-IF TSs to BSC_A1 and
BSC_A2

d) Success criteria
A VGCS call can be pre-empted on two A-Interfaces simultaneously.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.40 Pre-emption of VBS Um resources on A and B BSS simultaneously


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VBS call can be pre-empted simultaneously on two Ums in two different BSCs.


Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299, VBS GID: 202) MS_A2 (REC GID: 299, VBS GID: 202)
The Capacity on the Um in Cell_A1 and Cell_A2 is reduced to one TS

c) Test procedure



1 CT_A2 originates a 202 VBS MS_A1 and MS_A2 receive the VBS call
BSC_A2
2 CT_A1 originates a 299 REC The VBS group channels are pre-empted at
Um to Cell_A1 and Cell_A2
CT_A2 is IDLE, the VBS call is terminated
4 Unblock one more TS in Cell_A1 There are two IDLE TSs in Cell_A1 and one
TS in Cell_A2
5 MS_A1 originates the 202 VBS MS_A2 receive the VBS call
There are no IDLE TSs in Cell_A1 and
Cell_A2
6 MS_A3 originates the 299 REC The VBS group channels are pre-empted at
Um to Cell_A1 and Cell_A2
The VBS call is terminated
7 Unblock the Um TSs to Cell_A1 and
Cell_A2

d) Success criteria
A VBS call can be pre-empted simultaneously on two Ums in two different BSCs.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.41 Pre-emption of VGCS Um resources on A and B BSS simultaneously


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS call can be pre-empted simultaneously on two Ums in two different BSCs.

Network A

Cell_A1 Cell_A2
MS_A1 (REC GID: 299, VGCS GID: 200) MS_A2 (REC GID: 299, VGCS GID: 200)
The Capacity on the Um in Cell_A1 and Cell_A2 is reduced to one TS

c) Test procedure



1 CT_A2 originates a 200 VGCS MS_A1 and MS_A2 receive the VGCS call
BSC_A2
2 CT_A1 originates a 299 REC The VGCS group channels are pre-empted
at Um to Cell_A1 and Cell_A2
CT_A2 is IDLE, the VGCS call is terminated
4 Unblock one more TS in Cell_A1 There are two IDLE TSs in Cell_A1 and one
TS in Cell_A2
5 MS_A1 originates the 200 VGCS MS_A2 receives the VGCS call
There are no IDLE TSs in Cell_A1 and
Cell_A2
6 MS_A3 originates a 299 REC The VGCS group channels are pre-empted
at Um to Cell_A1 and Cell_A2
The VGCS call is terminated
8 Unblock the Um TSs to Cell_A1 and
Cell_A2

d) Success criteria
A VGCS call can be pre-empted simultaneously on two Ums in two different BSCs.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.42 VGCS ongoing in GCA covering both BSS, pre-emption of the B VGCS resources on
Um, VGCS on A BSS is still up


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS call can be pre-empted on Um in one BSC and stay active in another BSC.


Network A

Cell_A1 Cell_A2

c) Test procedure



1 MS_A1 originates a 204 VGCS MS_A2 and MS_A5 receive the VGCS call
There are no IDLE TSs to Cell_A2
2 MS_A3 calls MS_A4 with Prio 3 The VGCS group channel is pre-empted at
Um of Cell_A2
MS_A2 is IDLE
MS_A1 and MS_A5 are still in the VGCS Call

d) Success criteria
A VGCS call can be pre-empted on Um in one BSC and stay active in another BSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.43 VGCS ongoing in GCA covering both BSS, pre-emption of the A VGCS resources on
Um, VGCS on B BSS is still up


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that a VGCS call can be pre-empted on Um in one BSC and stay active in another BSC.


Network A

Cell_A1 Cell_A2
MS_A3 (no VGCS / VBS subscriber) MS_A4 (VGCS GID: 204)

c) Test procedure



1 MS_A1 originates a 204 VGCS and
keep the dedicated link
MS_A2, MS_A4 and CT_A1 receive the
VGCS call
There are no IDLE TSs in Cell_A1
2 MS_A3 calls MS_A5 with Prio 3 The VGCS group channel and the dedicated
link are pre-empted at Um to Cell_A1
MS_A1 is IDLE
MS_A2 and MS_A4 are still in the VGCS Call
3 CT_A1 releases the VGCS call

d) Success criteria
A VGCS call can be pre-empted on Um in one BSC and stay active in another BSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.44 eMLPP priority is preserved during CFU (Call Forwarding Unconditionally)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the eMLPP priority is preserved in case of CFU.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A4
MS_A3 in Cell_A1 with CFU to MS_A5 MS_A5

c) Test procedure



1 MS_A2 calls MS_A4 with prio 4 MS_A2 is connected with MS_A4
4 MS_A1 releases the PtP All participants are IDLE
5 Unblock the TSs at Um to Cell_A2 All resources are IDLE

d) Success criteria
The eMLPP priority is preserved in case of CFU.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.45 eMLPP priority is preserved during CFB (Call Forwarding Busy)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that the eMLPP priority is preserved in case of CFB.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A4
MS_A3 with CFB to MS_A5 and no CW MS_A5
MS_A6

c) Test procedure



5 MS_A1 releases the PtP All participants are IDLE

d) Success criteria
The eMLPP priority is preserved in case of CFB.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.46 Multi-Party: M6PORT: with different Prio


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
According to 3GPP TS 02.67 the eMLPP shall apply to the different call legs of a MPTY as for
other calls.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6
MS_A7 MS_A8

c) Test procedure


2 MS_A1 calls MS_A3 with Prio 3 and con-
nect MS_A2 and MS_A3 to a conference
MS_A3 is a participant of the conference
3 MS_A1 calls MS_A4 to MS_A6 with dif-
ferent priorities and connect them to the
conference.
MS_A1 to MS_A6 are connected in a confer-
ence
The conference leg of MS_A1 is pre-empted
at Um of Cell_A1
The conference is released
MS_A2 to MS_A6 are IDLE
5 MS_A7 releases the call to MS_A8 MS_A7 and MS_A8 are IDLE
7 MS_A2 calls MS_A3 to MS_A6 with dif-
ferent priorities and connect them to the
conference.
MS_A1 to MS_A6 are connected in a confer-
ence
The conference leg of MS_A1 is pre-empted
at Um of Cell_A1
The conference is still running
9 MS_A8 and MS_A2 releases the calls All participants are IDLE

d) Success criteria
The eMLPP applies to the different call legs of a MPTY as for other calls.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.47 Pre-emption on A-IF when pre-empted party has no subscription to eMLPP (as-
signment of default eMLPP priority)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that pre-emption on A-Interface is possible, if the A-IF resources are occupied by party
without eMLPP subscription.


Network A

Cell_A1 Cell_A2
MS_A1 (without eMLPP subscription) MS_A2 (without eMLPP subscription)
MS_A3 (VGCS, VBS GID: 202) MS_A4 (VGCS, VBS GID: 202)
CT_A1 (GCA_A1, VGCS GID: 200 , VBS GID:
202)

Only the one Cell_A2 in BCS_A2 belongs to the GCA.

c) Test procedure



1 MS_A1 calls MS_A2 MS_A1 is connected with MS_A2 with the de-
fault priority 4
2 MS_A3 calls MS_A4 with Prio 3 The connection MS_A1 to MS_A2 is pre-
empted.
fault priority 4
5 CT_A1 originates a 200 VGCS call The connection MS_A1 to MS_A2 is pre-
empted.
MS_A3 and MS_A4 receive the VGCS call
6 CT_A1 terminates the VGCS call All participants are IDLE
fault priority 4
8 CT_A1 originates a 202 VBS call The connection MS_A1 to MS_A2 is pre-
empted.
MS_A3 and MS_A4 receive the VBS call
9 CT_A1 terminates the VBS call All participants are IDLE

d) Success criteria
Pre-emption on A-Interface is possible, if the A-IF resources are occupied by party without
eMLPP subscription.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.48 Pre-emption on Um when pre-empted party has no subscription to eMLPP (assign-
ment of default eMLPP priority)


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that pre-emption on Um is possible, if the Um resources are occupied by party without
eMLPP subscription.

Network A

Cell_A1 Cell_A2
MS_A1 (without eMLPP subscription) MS_A2 (without eMLPP subscription)
MS_A3 (VGCS GID: 200, VBS GID: 202) MS_A4 (VGCS GID: 200, VBS GID: 202)
CT_A1 (GCA_A1, VGCS GID 200 , VBS GID:
202)

The Capacity on the Um to Cell_A2 is reduced to one TS
Only the one Cell_A2 in BCS_A2 belongs to the GCA.



c) Test procedure

fault priority 4
2 MS_A3 calls MS_A4 with Prio 3 The connection MS_A1 to MS_A2 is pre-
empted.
fault priority 4
5 CT_A1 originates a 200 VGCS call The connection MS_A1 to MS_A2 is pre-
empted.
6 CT_A1 terminates the VGCS call All participants are IDLE
fault priority 4
8 CT_A1 originates a 202 VBS call The connection MS_A1 to MS_A2 is pre-
empted.
MS_A3 and MS_A4 receive the VBS call
9 CT_A1 terminates the VBS call All participants are IDLE

d) Success criteria
Pre-emption on Um is possible, if the Um resources are occupied by party without eMLPP sub-
scription.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.49 3 TS available on A IF, 1 TS in use by prio 3 GCH, 1 TS in use by prio 4 GCH. Make
prio 3 VBS and verify that the prio 4 GCH is pre-empted


2.4.1
2.4.5
2.4.6
2.4.7
10.2.1
10.2.2
10.2.3
2.4.1

a) Purpose
Verify that lowest priority on A-Interface is pre-empted, if the resources are occupied with different
priorities.


Network A

Cell_A1 Cell_A2
The Capacity on the A-IF to BSC_A2 is reduced to three TSs


c) Test procedure

1 MS_A1 originates the 201 VGCS MS_A2 receives the 201 VGCS call
2 MS_A3 originates the 203 VBS MS_A4 receives the 203 VBS call
3 MS_A6 originates the 202 VBS MS_A5 receives the 202 VBS call
The group channel of the 203 VBS is pre-
empted at A-IF to BSC_A2
MS_A4 is IDLE
MS_A3 is still in the 203 VBS
4 MS_A1, MS_A3 and MS_A6 terminate
their group calls

d) Success criteria
The lowest priority on A-Interface is pre-empted, if the resources are occupied with different priori-
ties.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.50 Check of maximum authorized eMLPP level (non-roaming case)


2.4.1

2.4.1

a) Purpose
Verify that a subscriber can not use higher call priority than subscribed for him in HLR


Network A

BSC_A1 BSC_B1
Cell_A1 Cell_A2 Cell_B1
MS_A1 (max eMLPP
prio=3; default eMLPP
prio=4)
MS_B1
MS_A2 MS_A3

c) Test procedure

Use protocol tester to verify the priorities!



1 MS_A1 calls MS_A2 with default prio
MS_A1 releases the call
Prio 4 is used at A- and Abis-IF of
BSC_A1
2 MS_A1 calls MS_A2 with prio 2
Prio 3 is used at A- and Abis-IF of
BSC_A1
3 MS_A1 calls MS_B1 with prio 2
Prio 3 is used at E-IF to MSC_B, at A- and
Abis-IF of BSC_B1

d) Success criteria
A subscriber can not use higher call priority than subscribed for him in HLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.7.51 Check of maximum authorized eMLPP level (roaming case)


2.4.1

2.4.1

a) Purpose
Verify that a subscriber can not use higher call priority than subscribed for him in HLR


Network A

BSC_A1 BSC_B1
Cell_A1 Cell_A2 Cell_B1
MS_B1 (max eMLPP
prio=3; default
EMLPP prio=4.
MS_B1 is roamer in
MSC_A)
MS_B2
MS_A2 MS_A3

c) Test procedure

Use protocol tester to verify the priorities!



1 MS_B1 calls MS_A2 with default prio
MS_B1 releases the call
Prio 4 is used at A- and Abis-IF of BSC_A1
2 MS_B1 calls MS_A3 with prio 2
Prio 3 is used at A- and Abis-IF of BSC_A1
3 MS_B1 calls MS_B2 with prio 2
Prio 3 is used at E-IF to MSC_B, at A- and
Abis-IF of BSC_B1

d) Success criteria
A subscriber can not use higher call priority than subscribed for him in HLR.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8 VGCS
5.8.1 SS originates VGCS call


2.2.1
2.2.12
2.2.15
2.2.16
3.2.3
3.5.2
3.5.3
9.2.5.1
11.2.3.2
2.2.1
9.2.10
9.2.11
9.9.3
9.9.5

a) Purpose
Verify that a service subscriber can originate a VGCS call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
VGCS call is correctly established.
A GCCH is allocated in cell_A2.
call.
2) MS_A2 accepts the incoming VGCS call. MS_A2 joins VGCS call.
3) MS_A1 takes the uplink on the dedicated
channel (DCH).
MS_A1 is able to keep the uplink on the DCH.
listener.
5) MS_A2 requests the uplink on the group
call channel (GCCH).
MS_A2 can take the uplink (GCCH) and has
two-way voice path, MS_A1 is only listener.
7) MS_A1 requests the uplink on GCCH. MS_A1 can take the uplink (GCCH) and has
9) MS_A1 releases the VGCS call. The call is released and all resources are cor-
rectly de-allocated.

d) Success criteria
The service subscriber is able to originate a VGCS call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.2 Service Subscriber originates a VGCS (priority 3) call


2.2.1 2.2.1

a) Purpose
Verify that a service subscriber is able to establish a VGCS call priority 3 and the correct priority is
transmitted from the BSC.


Network A


c) Test procedure
CoO=Cell_A1




1) MS_A1 originates a VGCS call. VGCS call is correctly established.
call.
2) MS_A2 accepts the incoming VGCS. MS_A2 joins VGCS call.
3) Check the Notification Command mes-
sage sent from the BSC.
The correct priority is transmitted from the
BSC.
4) MS_A1 takes the uplink on the group call
channel.
listener.
6) MS_A1 releases the VGCS call. The call is released and all related resources
are de-allocated.

d) Success criteria
A service subscriber is able to establish a VGCS call priority 3 and the correct priority is transmit-
ted from the BSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.3 Controller originates a VGCS (priority 2) call


2.2.1
3.5.2
3.5.3
2.2.1
3.7.2
9.9.2

a) Purpose
Verify that a controller can originate a VGCS call with priority 2 and that the correct priority is sent
on the Notification message from the BSC.


Network A


c) Test procedure
CoO=Cell_A1




1) Controller CT_A1 originates a VGCS call
by dialling 50 + < GCA > + <GID>

cell_A1. Uplink still free in cell_A1.
MS_A1 and MS_A2 receive notification of the
incoming VGCS call.
the group call on GCCH, the downlink to the
2) MS_A1 and MS_A2 accept the incoming
VGCS.
MS_A1 and MS_A2 join VGCS call.
CT_A1 has voice path and MS_A1 and MS_A2
CT_A1.
BSC.
4) MS_A1 takes the uplink (group call
channel).
MS_A1.
ment of CT_A1.
MS_A2 is still able to listen to the announce-
ment of CT_A1.
5) Controller CT_A1 releases the call by
The call is released and all resources are cor-

d) Success criteria
The controller can originate a VGCS call with priority 2 and the correct priority is sent on the Noti-
fication message from the BSC.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.4 SS originates, leaves, rejoins and ends VGCS call


9.2.5.1 2.2.1

a) Purpose
Verify that a service subscriber can originate, leave, rejoin and end a VGCS call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
3) MS_A1 requests the uplink (group call
channel).
two-way voice path, MS_A2 and MS_A3 are
only listeners.
5) MS_A2 requests the uplink (GCCH). MS_A2 can take the uplink (GCCH) and has
only listeners.
6) MS_A1 leaves the call. MS_A1 is able to leave the call. The VGCS call
is not released.
7) MS_A1 rejoins the call. MS_A1 is able to join the call. MS_A2 has still
the uplink. MS_A2 has two-way voice path,
MS_A1 and MS_A3 are only listeners.
9) MS_A1 requests the uplink (GCCH). MS_A1 can take the uplink (GCCH) and has
only listeners.

d) Success criteria
The service subscriber originates, leaves, rejoins and ends a VGCS call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.5 SS is notified when enters into VGCS broadcast area with ongoing VGCS call


3.5.7
9.2.5.1
2.2.1

a) Purpose
Verify that a service subscriber is notified of an ongoing VGCS call by entering the VGCS broad-
cast area and is able to join this call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A2




VGCS call.
call.
channel).
4) MS_A1 moves from cell_A1 to cell_A2
(VGCS broadcast area).
MS_A1 is notified about the ongoing VGCS
call.
5) MS_A1 joins the call. MS_A1 joins the call. MS_A2 has two-way
voice path, MS_A1 and MS_A3 are only listen-
ers.
7) MS_A1 requests the uplink. MS_A1 can take the uplink (GCCH) and has
only listeners.

d) Success criteria
The service subscriber is notified of the ongoing VGCS call by entering the VGCS broadcast area
and is able to join the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.6 Controller joins ongoing VGCS call


9.2.5.1 2.2.1

a) Purpose
Verify that a controller can join an ongoing VGCS call.


Network A


c) Test procedure
CoO=Cell_A1




VGCS call.
CT_A1 and MS_A2 receive notification of the
incoming call.
2) MS_A2 and CT_A1 accept the incoming
VGCS call.
CT_A1 joins VGCS call.
MS_A2 joins VGCS call as listener. CT_A1 has
voice path and MS_A2 is able to listen to the
3) MS_A1 takes the uplink (GCCH). MS_A1 has voice path on GCCH.
ment of CT_A1.
of CT_A1.
4) Controller CT_A1 hangs up. Controller CT_A1 leaves the VGCS call. It is
not involved in the call anymore. Call is not
released.
5) Controller CT_A1 joins the VGCS call by
dialling 50 + < GCA > + <GID>
ment of CT_A1.
of CT_A1.
7) CT_A1 releases the call by using the kill
sequence (dialling ***).



d) Success criteria
The controller can join an ongoing VGCS call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.7 Originator of VGCS call releases DCH


9.2.5.1 2.2.1

a) Purpose
Verify that the originator of a VGCS can release the dedicated channel.


Network A

Cell_A1 Cell_A2

c) Test procedure




VGCS call.
call.
3) MS_A1 keeps the uplink (dedicated
channel).
The dedicated channel is not released. MS_A1
has two-way voice path, MS_A2 is only lis-
tener.
4) MS_A2 requests the uplink. MS_A2 cannot take the uplink.
6) MS_A2 requests the uplink. MS_A2 can take the uplink (GCCH). MS_A2
tener.
VGCS call.
call.
channel).
tener.
tener.



d) Success criteria
The originator of a VGCS call can release the dedicated channel.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.8 Originator of VGCS call takes uplink


9.2.5.1 2.2.1

a) Purpose
Verify that the originator of a VGCS can take the uplink on the group call channel.


Network A

Cell_A1 Cell_A2

c) Test procedure




VGCS call.
call.
MS_A1 has two way voice path.
channel) after the dedicated channel is
released.
MS_A1 takes the uplink. MS_A1 has two-way
voice path, MS_A2 is only listener.
tener.
VGCS call.
call.
released.
tener.



d) Success criteria
The originator of a VGCS call can take the uplink on the group call channel.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.9 Joiner of VGCS call takes Uplink


9.2.5.1 2.2.1

a) Purpose
Verify that the joiner of a VGCS can take the uplink on the group call channel.

MS_A3 and MS_A4 are off.

Network A

Cell_A1 Cell_A2

c) Test procedure




VGCS call.
call.
released.
5) Switch on MS_A3 in cell_A1. MS_A3 has correct subscriber information in
the VLR_A1 and is attached to the network.
MS_A3 receives notification of the ongoing call
and joins the call.
has two-way voice path, MS_A1 and MS_A2
are only listeners.
8) MS_A3 leaves the call. The call is not released.
10) Switch off MS_A3.
VGCS call.
call.
released.


15) Switch on MS_A4 in cell_A2. MS_A4 has correct subscriber information in
MS_A4 receives notification of the ongoing call
and joins the call.
are only listeners.
18) MS_A4 leaves the call. The call is not released.

d) Success criteria
The joiner of a VGCS call can take the uplink on the group call channel.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.10 Un-mute and mute sequence for originating controller

9.2.5.1 2.2.1
3.7.2
3.8.1
3.8.2
3.8.4
3.8.5

a) Purpose
Verify that an originating controller can use the un-mute and mute sequences correctly.


Network A


c) Test procedure
CoO=Cell_A1




incoming VGCS call.
VGCS.
CT_A1 has voice path and MS_A1 and MS_A2
CT_A1.
channel).
MS_A1.
ment of CT_A1.
ment of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.



d) Success criteria
The originating controller can use the un-mute and mute sequences correctly.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.11 Un-mute and mute sequence for joining controller


9.2.5.1 2.2.1
3.7.2
3.8.1
3.8.2
3.8.4
3.8.5

a) Purpose
Verify that a joining controller can use the un-mute and mute sequences correctly.

Controller CT_A1 is connected to network A.

Network A


c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS call.
3) MS_A1 takes the uplink (GCCH). MS_A1 has voice path on GCCH.
ment of CT_A1.
of CT_A1.
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.
6) Controller CT_A1 leaves the VGCS call. CT_A1 is not involved in the call anymore.


7) Controller CT_A1 joins the VGCS call by
dialling 50 + < GCA > + <GID>
###).
voice path on GCCH.
ment of CT_A1.
of CT_A1.
of MS_A1.

d) Success criteria
The joining controller can use the un-mute and mute sequences correctly.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.12 Parallel group calls are possible in the same cell


9.2.5.1 2.2.1

a) Purpose
Verify that it is possible to have different VGCS calls in a cell in parallel.


Network A


c) Test procedure
CoO=Cell_A1

GCA_A1, VGCS GID: 200 Prio 2,
VGCS GID: 203 Prio 3



VGCS call with GID 200.
call.
3) MS_A1 takes the uplink (dedicated
channel).
listener.
VGCS call with GID 203.
call.
channel).
listener.
channel).
listener.
channel).
listener.

d) Success criteria
It is possible to have different VGCS calls in a cell in parallel.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.13 Parallel VBS/VGCS calls with same GID are possible (same BSS and different BSS)


2.2.1
2.2.7
3.5.2
3.5.3
9.2.5.1
2.2.1

a) Purpose
Verify that it is possible to establish a VBS and a VGCS call with the same GID in parallel in the
same BSS as well as in different BSS.


Network A

Cell_A1 Cell_A2
MS_A2 (VBS GID: 203) MS_A6 (VGCS GID: 203)

c) Test procedure

GCA_A1, VGCS GID: 203 Prio 3, VBS GID: 203 Prio 4



VBS call.
cell_A2.
incoming call.
The DCH (uplink) remains allocated during the
whole VBS call.
VBS call.
MS_A2 and MS_A5 join VBS call. MS_A1 has
only listener.
VGCS call.
cell_A2.
incoming call.
VGCS call.
channel).
MS_A3 has two-way voice path, MS_A4 and
MS_A6 are only listener.
6) MS_A1 releases the VBS call. The call is released and all resources are cor-
VBS call.
whole VBS call.
incoming call.
10) MS_A1 and MS_A2 accept the incoming MS_A1 and MS_A2 join VBS call. MS_A5 has


VBS call. two-way voice path, MS_A1 and MS_A2 are
only listener.
VGCS call.
incoming call.
VGCS call.
channel).

d) Success criteria
It was possible to establish a VBS and a VGCS call with the same GID in parallel in the same
BSS as well as in different BSS.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


non CoO


1.4.1.1
9.2.5.1
2.2.1

a) Purpose
Verify that a VGCS call can be established in the cell of origin, even if in the non cell of origin the
call is queued and verify that after resources are freed, Assignment Result is sent to the MSC
and a GCCH is allocated in the non cell of origin.

Queuing is activated on the network.

Network A

Cell_A1 Cell_A2
MS_A5
MS_A6
MS_A7
MS_A8
CoO=Cell_A1



c) Test procedure

There is no more traffic channel available in
cell_A2.
VGCS call.
VGCS call is correctly established in cell_A1.
call.
In cell_A2, all traffic channels are busy. VGCS
call is queued for this cell.
VGCS/VBS Queuing Indication message is
sent from the BSC to the MSC.
If traffic channels are available before timer
T14 expires, the message VGCS/VBS As-
signment Result is sent to the MSC.
channel).
listener.
channel).
listener.
10) MS_A3 releases the PTP call before
timer T14 expires.
VGCS/VBS Assignment Result is sent to the
MSC before timer expiration.
MS_A3 and MS_A4 are notified about the in-
coming VGCS call.
11) MS_A3 and MS_4 accept the incoming
VGCS call.
MS_A3 and MS_A4 join the VGCS call.


12) MS_A3 requests the uplink. MS_A3 has two-way voice path. MS_A1,
MS_A2 and MS_A4 are only listener.
15) MS_A5 releases the PTP call. The call is released and all related resources

d) Success criteria
The VGCS call can be established in the cell of origin, even if in the non cell of origin the call is
queued. After resources are freed, Assignment Result is sent to the MSC and a GCCH is allo-
cated in the non cell of origin.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.15 MSC receives VBS/VGCS Queuing Indication followed by Assignment Result from CoO


1.4.1.1
9.2.5.1
2.2.1

a) Purpose
Verify that a VGCS call can be established in the cell of origin, when in this cell the group call
channel is queued and after resources are freed, Assignment Result is sent to the MSC and a
GCCH is allocated.

Check values of BSC Timer T14 and MSC Timer Txx.

Network A

Cell_A1 Cell_A2
MS_A1 MS_A7 (VGCS GID: 200)
MS_A2
MS_A5
CT_A1
CoO=Cell_A1



c) Test procedure

Two traffic channels are busy in the cell of ori-
gin.
Four traffic channels are busy in the cell of
origin.
3) MS_A5 establishes a PTP call to CT_A1
*75<Priority>#<ISDN>.
speech path between MS_A5 and CT_A1.
All traffic channels except one are busy on the
cell of origin cell_A1.
VGCS call. MS_A6 does not take the
uplink.
A dedicated channel (DCH) is allocated in
cell_A1.
The group call channel is queued in cell_A1.
call.
5) If BSC Timer T14 > MSC Timer Txx then:
MS_A3 releases the PTP call after the
BSC sends the VGCS/VBS Queuing
Indication message to the MSC but be-
fore expiration of timer Txx. Otherwise
the call will be terminated from the MSC.
If MSC Timer Txx > BSC Timer T14 then:
fore expiration of timer T14. Otherwise
message VGCS/VBS Assignment Fail-
ure is sent to the MSC.
Message VGCS/VBS Assignment Result is
sent to the MSC.
cell_A1.
incoming call.
VGCS.
channel).
MS_A3 has two-way voice path, MS_A6,
MS_A7, and MS_A4 are only listener.


9) MS_A6 releases the VGCS call.

The call is released and all related resources

d) Success criteria
A VGCS call can be established in the cell of origin, when in this cell the group call channel is
queued and after resources are freed, Assignment Result is sent to the MSC and a GCCH is
allocated.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.16 MSC receives VBS/VGCS Queuing Indication followed by Assignment Failure from
non CoO


9.2.5.1 2.2.1

a) Purpose
Verify that VGCS call can be established in the cell of origin, even if in the non cell of origin the
call is queued and an Assignment Failure is sent to the MSC.

Cell_A2 has only one TRX.

Network A

Cell_A1 Cell_A2
MS_A5
MS_A6
MS_A7
MS_A8
CoO=Cell_A1



c) Test procedure

There are no more traffic channels available in
cell_A2.
VGCS call.
call.
In cell_A2, all traffic channels are busy. VGCS
If no traffic channels are available before timer
signment Failure with cause No radio re-
source available is sent to the MSC.
channel).
listener.
8) MS_A3 releases the PTP call after timer
T14 expires.
VGCS/VBS Assignment Failure with cause
No radio resource available is sent to the
MSC after timer expiration.
The PTP call is released and all related re-
sources are correctly de-allocated.
No VGCS call could be established in cell_A2.



d) Success criteria
The VGCS call can be established in the cell of origin, even if in the non cell of origin the call is
queued and an Assignment Failure is sent to the MSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.17 Origination of VGCS call from non subscribed MS fails


2.2.1 2.2.1

a) Purpose
Verify that a service subscriber cannot originate a VGCS call if it is located outside the GCA or if it
has no subscription to regarding GID.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 200) MS_A2 (no VGCS / VBS subscriber)

c) Test procedure

VGCS call.
VGCS call is not established.
VGCS call.
CoO=Cell_A2




d) Success criteria
The service subscriber cannot originate a VGCS call if it is located outside the GCA or if it has no
subscription to regarding GID.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.18 Origination by controller fails


9.2.5.1 2.2.1

a) Purpose
Verify that a controller cannot originate a VGCS call if it is not entitled for this.

CT_A1 is not entitled to originate calls on the regarding GCA.

Network A


c) Test procedure
CoO=Cell_A1




1) MS_A1 is located in cell_A1. MS_A1 has correct subscriber information in

d) Success criteria
The controller cannot originate a VGCS call if it is not entitled for this.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.19 Killing of VGCS call by controller fails


9.2.5.1 2.2.1

a) Purpose
Verify that a controller cannot kill a VGCS call if it is not entitled for this.

CT_A1 is not entitled to kill calls on the regarding GCA.

Network A


c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
3) MS_A1 takes the uplink (on the group
call channel).
ment of CT_A1.
of CT_A1.
The call is not released.

d) Success criteria
The controller cannot kill a VGCS call if it is not entitled for this.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.20 Uplink release when DCH is allocated in case of SS contact lost


9.2.5.1 2.2.1

a) Purpose
Verify that the uplink on the dedicated channel is correctly released in case the service subscriber
looses contact to the network.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
channel).
4) Remove the battery of MS_A1 so it
looses contact with the network.
The uplink (dedicated channel) is correctly
released. Release cause: Radio Interface
Failure.
two-way voice path. MS_A3 is only listener.
6) Put back the battery of MS_A1 and
switch it on.
and joins it.
MS_A2 has two-way voice path. MS_A1 and
only listener.

d) Success criteria
The uplink on the dedicated channel is correctly released in case the service subscriber looses
contact to the network.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.21 Uplink release when DCH is allocated in case of Equipment failure (TRX)


9.2.5.1 2.2.1 TS 100933

a) Purpose
Verify that the uplink on the dedicated channel is correctly released in case of equipment failure
(TRX failure).


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
channel).
4) Originate a TRX failure on the TRX of
cell_A1.
The uplink (dedicated channel) is correctly
released. Release cause: Equipment Failure.
6) MS_A1 moves to cell_A2. MS_A1 performs a cell reselection. MS_A1 is
notified about the ongoing VGCS and joins it.
7)
only listener.
12) Put TRX back into service again. TRX is working again.

d) Success criteria
The uplink on the dedicated channel is correctly released in case of equipment failure (TRX fail-
ure).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.22 Uplink Release when DCH is allocated in case of Equipment failure (PCM)


9.2.5.1 2.2.1 TS 100933

a) Purpose
Verify that the uplink on the dedicated call channel is correctly released in case of equipment fail-
ure (PCM failure) in the originating cell and that the call is not released in the non-originating cell.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS call.
channel).
4) Originate a PCM failure on the Abis PCM
of cell_A1 (where the uplink is allocated).
The uplink (group call channel) is correctly
released.
Messages sent:
From the BSC to the MSC: Uplink Release
Indication with cause Equipment failure.
From the BSC to all BTS in the GCA. Uplink
Free.
In cell_A2 the call is not released.
two-way voice path. MS_A3 only listener.
6) MS_A1 moves to cell_A2. MS_A1 performs a normal location update.
and joins it.
only listener.
11) Put PCM back into service again. PCM is working again.



d) Success criteria
The uplink on the dedicated call channel is correctly released in case of equipment failure (PCM
failure) in the originating cell and the call is not released in the non-originating cell.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.23 Uplink release when GCCH Uplink is allocated in case of SS contact lost


9.2.5.1 2.2.1 TS 100933

a) Purpose
Verify that the uplink on the group call channel is correctly released in case the service subscriber
who has the uplink looses contact to the network.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
channel).
MS_A1 can take the uplink (GCCH)
MS_A1 has two-way voice path, MS_A2, and
released.
Messages sent:
From the BSC to the MSC: Uplink Release
Indication with cause Radio interface failure.
Free.
6) Put back the battery of MS_A1 and
switch it on.
and joins it.
only listener.

d) Success criteria
The uplink on the group call channel and on the dedicated channel is correctly released in case
the service subscriber who has the uplink, looses contact to the network.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.24 Uplink release when GCCH Uplink is allocated in case of Equipment failure (TRX)


9.2.5.1 2.2.1 TS 100933

a) Purpose
Verify that the uplink on the group call channel is correctly released in case of equipment failure
(TRX failure) in the originating cell and that the call is not released in the non-originating cell.
(TRX failure) in the non-originating cell and that the call is not released in the originating cell.
Verify that the uplink on the group call channel and the VGCS call are not released in case of
equipment failure (TRX failure) in the non-originating cell where a listener is allocated.

Step 1: Uplink release in originating cell when TRX failure in originating cell.
Step 2: Uplink release in non-originating cell when TRX failure in non-originating cell.
Step 3: No uplink release in originating cell when TRX failure in non-originating cell.

Network A

Cell_A1 Cell_A2
CoO=Cell_A1



c) Test procedure

Step 1: Uplink release in originating cell when TRX failure in originating cell.
VGCS call and does not keep the dedi-
cated channel.
MS_A2, MS_A3 and MS_A4 receive notifica-
tion of the incoming call.
2) MS_A2, MS_A3 and MS_A4 accept the
incoming VGCS call.
MS_A2, MS_A3 and MS_A4 join VGCS call.
channel).
cell_A1 (where the uplink is allocated).
released.
Messages sent:
from the BSC to the MSC: Uplink Release
Free.
In cell A2 the call is not released.
two-way voice path. MS_A3 only listener.
6)
MS_A1 moves to cell_A2.
MS_A1 performs a cell reselection. MS_A1 is
notified about the ongoing VGCS and joins it.
only listener.
12) MS_A1 moves to cell_A1. MS_A1 performs a cell reselection.


Step 2: Uplink release in non-originating cell when TRX failure in non-originating cell.
cated channel.
incoming VGCS call.
channel).
cell_A2 (where the subsequent talker is
allocated).
released.
Messages sent:
Free.
5) MS_A1 requests the uplink. MS_A1 can take the uplink (GCCH).
listener.


Step 3: No uplink release in originating cell when TRX failure in non-originating cell.
cated channel.
incoming VGCS call.
channel).
cell_A2 (where no talker is allocated).
The group channel in cell_A2 is correctly re-
leased.
Message sent:
from the BSC to the MSC: Clear Request
with cause Equipment failure.
The uplink and the call are not released In
cell_A1.

d) Success criteria
The uplink on the group call channel is correctly released in case of equipment failure (TRX fail-
ure) in the originating cell and the call is not released in the non-originating cell..
The uplink on the group call channel is correctly released in case of equipment failure (TRX fail-
ure) in the non-originating cell and the call is not released in the originating cell.
The uplink on the group call channel and the VGCS call are not released in case of equipment
failure (TRX failure) in the non-originating cell where a listener is allocated.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.25 Uplink release when GCCH Uplink is allocated in case of Equipment failure (PCM)


9.2.5.1 2.2.1 TS 100933

a) Purpose
(PCM failure) in the originating cell and that the call is not released in the non-originating cell.
(PCM failure) in the non-originating cell and that the call is not released in the originating cell.
Verify that the uplink on the group call channel and the VGCS call are not released in case of
equipment failure (PCM failure) in the non-originating cell where a listener is allocated.

Step 1: Uplink release in originating cell when PCM failure in originating cell.
Step 2: Uplink release in non-originating cell when PCM failure in non-originating cell.
Step 3: No uplink release in originating cell when PCM failure in non-originating cell.

Network A

Cell_A1 Cell_A2
CoO=Cell_A1



c) Test procedure

Step 1: Uplink release in originating cell when PCM failure in originating cell.
cated channel.
incoming VGCS call.
channel).
of cell_A1 (where the uplink is allocated).
released.
Messages sent:
Free.
6) MS_A1 moves to cell_A2. MS_A1 performs a normal location update.
call and joins it.
only listener.
12) MS_A1 moves to cell_A1. MS_A1 performs a normal location update



Step 2: Uplink release in non-originating cell when PCM failure in non-originating cell.
cated channel.
incoming VGCS call.
channel).
of cell_A2 (where the subsequent talker
is allocated).
released.
Messages sent:
Free.
5) MS_A1 requests the uplink. MS_A1 can take the uplink (GCCH).
listener.


Step 3: No uplink release in originating cell when PCM failure in non-originating cell.
cated channel.
incoming VGCS call.
channel).
of cell_A2 (where no talker is allocated).
The group channel in cell_A2 is correctly re-
leased.
Message sent:
from the BSC to the MSC: Clear Request
with cause Equipment failure.
The uplink and the call are not released In
cell_A1.

d) Success criteria
The uplink on the group call channel is correctly released in case of equipment failure (PCM fail-
ure) in the originating cell and the call is not released in the non-originating cell..
The uplink on the group call channel is correctly released in case of equipment failure (PCM fail-
ure) in the non-originating cell and the call is not released in the originating cell.
The uplink on the group call channel and the VGCS call are not released in case of equipment
failure (PCM failure) in the non-originating cell where a listener is allocated.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.26 Uplink Request is rejected due to Uplink already allocated


5.2.2.51
5.2.2.53
5.2.2.54
6.2.2.10
6.2.2.12
6.2.2.13
7.2.2.18
7.2.2.20
7.2.2.21
9.2.5.1
2.2.1

EN301515

a) Purpose
Verify that the uplink can only be allocated to one mobile subscriber at a time.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call. MS_A1 does not take the
uplink.
call.
channel).
MS_A1 cannot take the uplink (GCCH).

d) Success criteria
The uplink can only be allocated to one mobile subscriber at a time.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.27 Two controllers initiate VGCS with the same GID but different GCAs


3.5.2
3.5.3
9.2.5.1
2.2.1 EN301515

a) Purpose
Verify that two controller originated group calls can be established with the same GID in different
group call areas at the same time.


Network A

Cell_A1 Cell_A2
CT_A1 (GCA_A1, VGCS GID: 200) CT_A2 (GCA_A2, VGCS GID: 200)

c) Test procedure
GCA_A1, VBS GID: 200 Prio 2 GCA_A2, VBS GID: 200 Prio 2



1) At the same time:
controller CT_A1 originates a VGCS call
by dialling 50 + < GCA_A1 > + <GID>
and
controller CT_A2 originates a VGCS call
by dialling 50 + < GCA_A2 > + <GID>
VGCS calls are correctly established.
MS_A1 receives notification of one incoming
VGCS call.
MS_A2 receives notification of other incoming
VGCS call.
CT_A1 has voice path to MS_A1. If MS_A1
takes the uplink of the group call on GCCH, the
able to listen to the announcement of CT_A1.
CT_A2 has voice path to MS_A2. If MS_A2
takes the uplink of the group call on GCCH,
the downlink to the talking mobile subscriber
will be muted. The talking mobile subscriber is
not able to listen to the announcement of
CT_A2.
VGCS calls.
MS_A1 joins one VGCS call as listener.
MS_A2 joins the other VGCS call as listener.
3) MS_A1 takes the uplink. MS_A1 has voice path on GCCH.
MS_A1.
ment of CT_A1.
MS_A2.
ment of CT_A2.



d) Success criteria
Two controller originated group calls can be established with the same GID in different group call
areas at the same time.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.28 VGCS call taken down during setup by SS


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that a service subscriber can take down a VGCS call during the call establishment.


Network A


c) Test procedure

VGCS call and hangs up before the call
is established.
All resources are correctly de-allocated.
CoO=Cell_A1




d) Success criteria
A service subscriber can take down a VGCS call during the call establishment.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.29 VGCS call taken down during setup by controller


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that a controller can take down a VGCS call during the call establishment.


Network A


c) Test procedure

by dialling 50 + < GCA > + <GID> and
hangs up before the call is established.



d) Success criteria
Controller can take down a VGCS call during the call establishment.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.30 More than one Uplink Request at the same time (same BSS and different BSS)


2.2.16
5.2.2.51
5.2.2.53
5.2.2.54
6.2.2.10
6.2.2.12
6.2.2.13
7.2.2.18
7.2.2.20
7.2.2.21
9.2.5.1
2.2.1 EN301515

a) Purpose
Verify that only one service subscriber can take the uplink at a time.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

VGCS call.
incoming call.
VGCS.
channel).
5) MS_A1 and MS_A3 request the uplink at
the same time.
Only one MS can take the uplink. The other
gets uplink reject. The mobile able to take the
uplink has two-way voice path, the other one
and MS_A2 are only listener.
6) The MS releases the uplink. The uplink is correctly released.
7) MS_A1 and MS_A2 request the uplink at
the same time.
Only one MS can take the uplink. The other
gets uplink reject. The mobile able to take the
uplink has two-way voice path, the other one
and MS_A3 are only listener.
8) The MS releases the uplink. The uplink is correctly released.

d) Success criteria
Only one service subscriber can take the uplink at a time.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.31 Two SS originate VGCS call at same time (same BSS and different BSS)


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that when two service subscribers originate a VGCS call at the same time, only one can
establish the call and the other receives the notification of this incoming call.


Network A

Cell_A1 Cell_A2

c) Test procedure




Service subscriber MS_A1 originates a
VGCS call.
VGCS call.
Only one service subscriber can establish the
VGCS.
The other MS and MS_A2 receive notification
of the incoming call.
the MS who established the VGCS call has
two-way voice path.
2) The notified MS and MS_A2 accept the
incoming VGCS.
The notified MS and MS_A2 join VGCS call.
3) The originating MS takes the uplink
(group call channel).
The originating MS has two-way voice path,
MS_A2 and the notified MS are only listener.
4) The originating MS releases the uplink. The uplink is correctly released.
5) Originating MS releases the VGCS call. The call is released and all resources are cor-
VGCS call.
VGCS call.
VGCS call.
channel (GCCH) are allocated in the cell where
the call was established.
A GCCH is allocated in the other cell.
the MS who established the VGCS call has
two-way voice path.
incoming VGCS.
MS and MS_A3 join VGCS call.
8) The originating MS takes the uplink
(group call channel).
The originating MS has two-way voice path,
the notified MS and MS_A3 are only listener.
9) The originating MS releases the uplink. The uplink is correctly released.
10) Originating MS releases the VGCS call. The call is released and all resources are cor-



d) Success criteria
When two service subscribers originate a VGCS call at the same time, only one can establish the
call and the other receives the notification of this incoming call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.32 Two controllers originate VGCS call at the same time


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that when two controllers originate a VGCS call at the same time (same group call refer-
ence), only one can establish the call.


Network A

Cell_A1 Cell_A2

c) Test procedure




Controller CT_A1 originates a VGCS call
Controller CT_A2 originates a VGCS call
Only one controller manages to establish a
VGCS call.
cell_A1 and cell_A2.
coming VGCS call.
The controller not able to establish the call is
notified about the incoming VGCS call.
Both controllers have voice path to all mobile
subscribers. If one mobile subscriber takes the
uplink of the group call on GCCH, the downlink
to the talking mobile subscriber will be muted.
The talking mobile subscriber is not able to
listen to the announcement of the controllers.
2) MS_A1, MS_A2 and controller not able
to establish the call accept the incoming
VGCS.
MS_A1 and MS_A2 join VGCS call in group
receive mode.
Controller not able to establish the call joins
the VGCS call.
Both controllers can hear and talk to each
other and have voice path to MS_A1 and
MS_A2. MS_A1 and MS_A2 are able to listen
to the announcement of the controllers.
Controllers are able to listen to the announce-
ment of MS_A1.
ment of the controllers.
ment of the controllers.
Both controllers can hear and talk to each
other and have voice path to MS_A1 and
MS_A2. MS_A1 and MS_A2 are able to listen
to the announcement of the controllers.
5) The controller able to establish the call
releases it by using the kill sequence
(dialling ***).



d) Success criteria
When two controllers originate a VGCS call at the same time, only one can establish the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.33 VGCS originator leaves GCA


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that the originator of a VGCS call can leave the group call area and the call is not released.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS call.
channel).
5) MS_A1 moves to cell_A2. Originator leaves the group call area, call is not
released.
7) MS_A1 moves back to cell_A1. MS_A1 is notified of the ongoing VGCS call.
8) MS_A1 joins the VGCS call. MS_A2 has two-way voice path, MS_A1 and
channel).
only listeners.

d) Success criteria
The originator of a VGCS call can leave the group call area and the call is not released.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.34 VGCS talker leaves GCA


9.2.5.1 2.2.1 EN301515

a) Purpose
Verify that when the subsequent talker of a VGCS call leaves the group call area, the uplink is
correctly released but not the call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
incoming call.
VGCS.
channel).
channel).
6) MS_A2 moves to cell_A2. Subsequent talker leaves the group call area.
released, but not the call.

d) Success criteria
When the subsequent talker of a VGCS call leaves the group call area, the uplink is correctly re-
leased but not the call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.35 Service Subscriber initiated VGCS from Relay MSC in PLMN A, call to A-MSC Con-
troller


9.2.5.1
9.4.2
2.2.1
9.5.4
9.9.4

a) Purpose
Verify that a service subscriber can originate and release a VGCS call from relay MSC. A control-
ler in anchor MSC is connected to the call.
Step 1: MS establishes VGCS call in relay MSC_B1.
Step 2: MS establishes VGCS call in relay MSC_A1.



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (VGCS GID: 200) MS_B1 (VGCS GID: 200)

c) Test procedure

Step 1: MS establishes VGCS call in relay MSC_B1.
1) Service subscriber MS_B1 originates a
VGCS call.
CT_A1, MS_A1, MS_A2 and MS_B2 receive
notification of the incoming call.
CoO=Cell_B1



2) CT_A1, MS_A1, MS_A2 and MS_B2
accept the incoming VGCS.
MS_A1, MS_A2 and MS_B2 join VGCS call as
listener. CT_A1 has voice path and MS_A1,
3) MS_B1 takes the uplink (dedicated
channel).
MS_B1 has voice path on DCH.
MS_A1, MS_A2, MS_B2 and CT_A1 are able
to listen to the announcement of MS_B1.
MS_B1 is able to listen to the announcement
of CT_A1.
MS_A1, MS_A2 and MS_B2 are still able to
4) MS_B1 releases the uplink. The uplink is correctly released.
ers. They are able to listen to the announce-
ment of CT_A1.
MS_A1, MS_A2, MS_B1 and MS_B2 are lis-
tener.
5) MS_B1 requests the uplink (group call
channel).
MS_B1 has voice path on GCCH.
ment of CT_A1.
MS_A1, MS_A2 and MS_B2 are still able to
channel).
MS_B1, MS_A2, MS_B2 and CT_A1 are able
to listen to the announcement of MS_A1.
ment of CT_A1.
MS_B1, MS_A2 and MS_B2 are still able to


9) MS_B1 releases the VGCS call. The call is released and all resources are cor-


Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 2: MS establishes VGCS call in relay MSC_A1.
VGCS call.
A GCCH is allocated in cell_B1.
CT_B1, MS_B1, MS_A2 and MS_B2 receive
CoO=Cell_A1



2) CT_B1, MS_B1, MS_A2 and MS_B2
accept the incoming VGCS.
CT_B1 joins VGCS call.
MS_A2, MS_B1 and MS_B2 join VGCS call as
listener. CT_B1 has voice path and MS_B1,
channel).
MS_B1, MS_A2, MS_B2 and CT_B1 are able
of CT_B1.
listen to the announcement of CT_B1.
ment of CT_B1.
MS_A1, MS_A2, MS_B1 and MS_B2 are lis-
tener.
channel).
ment of CT_B1.
listen to the announcement of CT_B1.
channel).
ment of CT_B1.



d) Success criteria
The service subscriber can originate and release a VGCS call from relay MSC. The controller in
anchor MSC is connected to the call.
e) Test result

Remarks
Attachments
(log / trace file)



5.8.36 Controller originates a VGCS call from Relay MSC-


9.2.5.1 2.2.1
9.5.4

a) Purpose
Verify that a controller can originate and kill a VGCS call from relay MSC.

Step 1: Controller establishes VGCS call in relay MSC_B1.
Step 2: Controller establishes VGCS call in relay MSC_A1.


Network A Network B

A-MSC_A1 R-MSC_B1




c) Test procedure

Step 1: Controller establishes VGCS call in relay MSC_B1.
1) Controller CT_B1 originates a VGCS call
by dialling 900 + < IC > + 50 + < GCA >
+ <GID> (CT 5 Eirene Format).
cell_B1. Uplink still free in cell_B1.
MS_A1 and MS_B1 receive notification of the
incoming VGCS call.
2) MS_A1 and MS_B1 accept the incoming
VGCS call.
MS_A1 and MS_B1 join VGCS call.
CT_B1 has voice path and MS_A1 and MS_B1
CT_B1.
channel).
CT_B1 is able to listen to the announcement of
MS_A1.
ment of CT_B1.
MS_B1 is still able to listen to the announce-
ment of CT_B1.
CT_B1 has voice path. MS_A1 and MS_B1 are
able to listen to the announcement of CT_B1.
5) MS_B1 takes the uplink (group call
channel).
MS_B1.
ment of CT_B1.
ment of CT_B1.


CT_B1 has voice path. MS_B1 and MS_A1 are
7) CT_B1 releases the call by using the kill
8) Controller CT_B1 originates a VGCS call
by dialling < CC > + < NDC > + 50 + <
GCA > + <GID> (CT 5 ITU Format
E.164)
incoming VGCS call.
VGCS call.
CT_B1 has voice path and MS_A1 and MS_B1
CT_B1.
channel).
MS_A1.
ment of CT_B1.
ment of CT_B1.
CT_B1 has voice path. MS_A1 and MS_B1 are
channel).
MS_B1.
ment of CT_B1.
ment of CT_B1.


CT_B1 has voice path. MS_B1 and MS_A1 are


Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure



Step 2: Controller establishes VGCS call in relay MSC_A1.
+ <GID> (CT 5 Eirene Format).
incoming VGCS call.
VGCS call.
CT_A1 has voice path and MS_A1 and MS_B1
CT_A1.
channel).
MS_B1.
ment of CT_A1.
ment of CT_A1.
CT_A1 has voice path. MS_A1 and MS_B1 are
channel).
MS_A1.
ment of CT_A1.
ment of CT_A1.
CT_A1 has voice path. MS_B1 and MS_A1 are


E.164)
incoming VGCS call.
VGCS call.
CT_A1 has voice path and MS_A1 and MS_B1
CT_A1.
channel).
MS_B1.
ment of CT_A1.
ment of CT_A1.
CT_A1 has voice path. MS_A1 and MS_B1 are
channel).
MS_A1.
ment of CT_A1.
ment of CT_A1.
CT_A1 has voice path. MS_B1 and MS_A1 are

d) Success criteria


The controller can originate and kill a VGCS call from relay MSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.37 SS initiated VGCS call from Relay MSC. Controller in A-MSC area can re-connect to
on-going VGCS call


2.2.1
9.2.5.1
2.2.1

a) Purpose
Verify that a service subscriber can originate a VGCS call from relay MSC and that a controller in
anchor MSC area can re-connect to the ongoing VGCS call and can release the call using the
killing sequence.


Step 1: Controller in anchor MSC_A1 area re-connects VGCS call established in relay MSC_B1.
Step 2: Controller in anchor MSC_B1 area re-connects VGCS call established in relay MSC_A1.



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: Controller in anchor MSC_A1 area re-connects VGCS call established in relay
MSC_B1.
VGCS call.
cell_A1.
CoO=Cell_B1



accept the incoming VGCS call.
MS_A1, MS_A2 and MS_B2 join VGCS call as
listener. CT_A1 has voice path. MS_A1,
channel).
ment of CT_A1.
4) Controller CT_A1 hangs up. Controller is able to leave the VGCS call with-
out the call being released.
MS_A1, MS_A2 and MS_B2 are listeners
5) Controller CT_A1 rejoins VGCS call by
dialling 900 + < IC > + 50 + < GCA > +
<GID> (CT 5 Eirene Format).
Controller rejoins the VGCS call.
ment of CT_A1.
ers.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

Step 2: Controller in anchor MSC_B1 area re-connects VGCS call established in relay
MSC_A1.
VGCS call.
cell_B1.
CoO=Cell_A1



accept the incoming VGCS call.
MS_B1, MS_A2 and MS_B2 join VGCS call as
listener. CT_B1 has voice path. MS_B1,
channel).
ment of CT_B1.
MS_B1, MS_A2 and MS_B2 still able to listen
4) Controller CT_B1 hangs up. Controller is able to leave the VGCS call with-
out the call being released.
MS_B1, MS_A2 and MS_B2 are listeners
5) Controller CT_B1 rejoins VGCS call by
dialling 900 + < IC > + 50 + < GCA > +
<GID> (CT 5 Eirene Format).
Controller rejoins the VGCS call.
ment of CT_B1.
MS_B1, MS_A2 and MS_B2 still able to listen
ers.
MS_B1, MS_A2 and MS_B2 are able to listen



d) Success criteria
A service subscriber can originate a VGCS call from relay MSC and a controller in anchor MSC
area can re-connect to the ongoing VGCS call and can release the call using the killing sequence.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.38 VGCS first talker notification (MS dedicated mode, incoming PTP call, non roam-
ing case)


2.2.1
5.2.2.43
9.2.5.1
2.2.1
5.5.19
5.5.20
5.5.21
14.3.3

a) Purpose
Verify that a VGCS first talker on the dedicated channel get a notification of an incoming PTP call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call (GID 200).
cell_A2.
MS_A2, MS_A3 receives notification of the
incoming VGCS call (GID 200).
the incoming VGCS call (GID 200).
MS_A2, MS_A3 joins VGCS call (GID 200).
4 to MS_A1.
MS_A1 receives an in-band paging on FACCH
channel about the incoming PTP call from
MS_A4. MS_A1 advertise the incoming PTP
call from MS_A4 optically and acoustically.
call from MS_A4.
released by the network. All resources are cor-
rectly released by the network.
6) MS_A1 releases the uplink. Uplink free message is send in Cell_A1,
Cell_A2 and DCH is correctly released.
200).
8) Repeat step 1 to 7 with priority 3 for the
PTP call.

d) Success criteria
The VGCS call (GID 200) first talker on the dedicated channel is able to receive notification about
an incoming PTP call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.39 VGCS first talker notification (MS dedicated mode, incoming VGCS call, non roam-
ing case)


2.2.1
5.2.2.47
9.2.5.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VGCS call (GID 200) first talker on dedicated channel get a notification of an incom-
ing VGCS call (GID 203, 204) call.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 200, 203, 204) MS_A3 (VGCS GID: 203, 204)

c) Test procedure

GCA_A1, VGCS GID: 200 Prio 2, GID: 203 Prio 3, GID: 204 Prio 4



cell_A2.
ing VGCS call (GID 200).
MS_A2 joins VGCS call (GID 200).
3) MS_A1 takes the uplink on DCH. MS_A1 has two-way voice path. MS_A2 is only
listener.
cell_A1.
FACCH channel about the incoming VGCS call
(GID 203). MS_A1 advertise the incoming
call (GID 203).

203).
7) MS_A1 releases the uplink. Uplink free message is send in cell_A1 and
cell_A2 and the DCH is correctly released.
200).
9) Repeat from step 1 to 8 with VGCS call
(GID 204) instead of VGCS call (GID
203).

d) Success criteria
VGCS call (GID 200) first talker on the dedicated channel is able to receive notification about an
incoming VGCS call (GID 203, 204).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.40 VGCS first talker notification (MS dedicated mode, incoming VBS call, non roam-
ing case)


2.2.1
5.2.2.47
9.2.5.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VGCS call (GID 200) first talker originator on dedicated channel get a notification
about an incoming VBS call (GID 203, 204).


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID: 200, VBS GID: 202, 203) MS_A3 (VBS GID: 202, 203)

c) Test procedure

GCA_A1, VGCS GID: 200 Prio 2, VBS GID: 202 Prio 3, GID: 203 Prio 4



cell_A2.
MS_A2 joins VGCS call (GID 200).
3) MS_A1 takes the uplink on DCH. MS_A1 has two-way voice path. MS_A2 is only
listener.
cell_A1.
MS_A1 receive an in-band notification on
call (GID 202).

6) MS_A3 releases the VBS call (GID 202). VBS call (GID 202) is released successfully
200).
9) Repeat from step 1 to 8 with VBS call
(GID 203) instead of VBS call (GID 202).

d) Success criteria
VGCS call (GID 200) first talker on the dedicated channel is able to receive notification about an
incoming VBS call (GID 202, 203).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.41 VGCS first talker notification (MS dedicated mode, incoming PTP call, roaming)


2.2.1
5.2.2.43
9.2.5.1
2.2.1
5.5.19
5.5.20
5.5.21
14.3.3

a) Purpose
Verify that a VGCS call (GID 200) first talker on dedicated channel get a notification about an in-
coming PTP call. This should be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VGCS call in HPLMN (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VGCS call in VPLMN (MSC_A1 anchor).
Step 3: Mobile subscriber of network B originates VGCS call in HPLMN (MSC_A1 anchor).
Step 4: Mobile subscriber of network A originates VGCS call in VPLMN (MSC_A1 anchor).
Step 5: Mobile subscriber of network A originates VGCS call in HPLMN (MSC_B1 anchor).
Step 6: Mobile subscriber of network B originates VGCS call in VPLMN (MSC_B1 anchor).
Step 7: Mobile subscriber of network B originates VGCS call in HPLMN (MSC_B1 anchor).
Step 8: Mobile subscriber of network A originates VGCS call in VPLMN (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1
MS_B3 (VGCS GID: 200) MS_A3 (VGCS GID: 200)

c) Test procedure

Step 1: Mobile subscriber of network A originates VGCS call in HPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).
MS_A3, MS_B1 and MS_B3 are joining the



4 to MS_A1.
call from MS_A2.
4 to MS_A1.
MS_B4. MS_A1 advertise the incoming PTP
call from MS_B4 optically and acoustically.
call from MS_B4.
4 to MS_A1.
call from MS_B2.
4 to MS_A1.
call from MS_A4.
cell_B1 and the DCH is correctly released.
200).
for the PTP calls instead of priority 4.


Step 2: Mobile subscriber of network B originates VGCS call in VPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).
MS_A1, MS_B1 and MS_A3 are joining the
4 to MS_A1.
MS_B3 receives an in-band paging on FACCH
MS_A2. MS_B3 advertise the incoming PTP
call from MS_A2.
4 to MS_B3.
MS_B4. MS_B3 advertise the incoming PTP
call from MS_B4.
4 to MS_B3.
call from MS_B2.
4 to MS_B3.


call from MS_A4.
12) MS_B3 releases the uplink. Uplink free message is send in cell_A1 and
13) MS_B3 releases the VGCS call (GID
200).

Step 3: Mobile subscriber of network B originates VGCS call in HPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).
MS_A1, MS_A3 and MS_B3 are joining the
4 to MS_B1.
call from MS_A2.
4 to MS_B1.
call from MS_B4.


4 to MS_B1.
call from MS_B2.
4 to MS_B1.
call from MS_A4.
200).

Step 4: Mobile subscriber of network A originates VGCS call in VPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).


4 to MS_A3.
call from MS_A2.
4 to MS_A3.
call from MS_B4.
4 to MS_A3.
call from MS_B2.
4 to MS_A3.
call from MS_A4.
200).



Network A Network B

B-MSC_A1 A-MSC_B1

Test procedure

Step 5: Mobile subscriber of network A originates VGCS call in HPLMN (MSC_B1 anchor)
cell_B1.
(GID 200).



4 to MS_A1.
call from MS_A2.
4 to MS_A1.
call from MS_B4.
4 to MS_A1.
call from MS_B2.
4 to MS_A1.
call from MS_A4.
200).


Step 6: Mobile subscriber of network B originates VGCS call in VPLMN (MSC_B1 anchor)
cell_B1.
(GID 200).
4 to MS_A1.
call from MS_A2.
4 to MS_B3.
call from MS_B4.
4 to MS_B3.
call from MS_B2.
4 to MS_B3.


call from MS_A4.
200).

Step 7: Mobile subscriber of network B originates VGCS call in HPLMN (MSC_B1 anchor)
cell_A1.
(GID 200).
4 to MS_B1.
call from MS_A2.
4 to MS_B1.
call from MS_B4.


4 to MS_B1.
call from MS_B2.
4 to MS_B1.
call from MS_A4.
200).

Step 8: Mobile subscriber of network A originates VGCS call in VPLMN (MSC_B1 anchor)
cell_A1.
(GID 200).


4 to MS_A3.
call from MS_A2.
4 to MS_A3.
call from MS_B4.
4 to MS_A3.
call from MS_B2.
4 to MS_A3.
call from MS_A4.
200).

d) Success criteria
an incoming PTP call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.42 VGCS first talker notification (MS dedicated mode, incoming VGCS call, roaming)


2.2.1
5.2.2.47
9.5.2.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
coming VGCS call (GID 203, 204). This should be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VGCS call in HPLMN. Second VGCS call origi-
nated by mobile subscriber of network A in HPLMN (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VGCS call in VPLMN. Second VGCS call origi-
nated by mobile subscriber of network A in HPLMN (MSC_A1 anchor).
nated by mobile subscriber of network B in VPLMN (MSC_A1 anchor).
Step 4: Mobile subscriber of network B originates VGCS call in VPLMN. Second VGCS call origi-
nated by mobile subscriber of network B in VPLMN (MSC_A1 anchor).
Step 5: Mobile subscriber of network B originates VGCS call in HPLMN. Second VGCS call origi-
nated by mobile subscriber of network B in HPLMN (MSC_A1 anchor).
Step 6: Mobile subscriber of network A originates VGCS call in VPLMN. Second VGCS call origi-
nated by mobile subscriber of network B in HPLMN (MSC_A1 anchor).
Step 7: Mobile subscriber of network B originates VGCS call in HPLMN. Second VGCS call origi-
nated by mobile subscriber of network A in VPLMN (MSC_A1 anchor).
Step 8: Mobile subscriber of network A originates VGCS call in VPLMN. Second VGCS call origi-
Step 10: Mobile subscriber of network A originates VGCS call in HPLMN. Second VGCS call
originated by mobile subscriber of network B in HPLMN (MSC_A1 anchor).
Step 11: Mobile subscriber of network B originates VGCS call in HPLMN. Second VGCS call
originated by mobile subscriber of network B in VPLMN (MSC_A1 anchor).
originated by mobile subscriber of network A in HPLMN (MSC_A1 anchor).
originated by mobile subscriber of network A in HPLMN (MSC_B1 anchor).


Step 14: Mobile subscriber of network B originates VGCS call in VPLMN. Second VGCS call
originated by mobile subscriber of network B in VPLMN (MSC_B1 anchor).
originated by mobile subscriber of network B in HPLMN (MSC_B1 anchor).
Step 18: Mobile subscriber of network A originates VGCS call in VPLMN. Second VGCS call
originated by mobile subscriber of network A in VPLMN (MSC_B1 anchor).



Network A Network B

A-MSC_A1 B-MSC_B1
MS_A1 (VGCS GID: 200, 203, 204) MS_B1 (VGCS GID: 200, 203, 204)
MS_A2 (VGCS GID: 203, 204) MS_B2 (VGCS GID: 203, 204)
MS_B3 (VGCS GID: 200, 203, 204) MS_A3 (VGCS GID: 200, 203, 204)
MS_B4 (VGCS GID: 203, 204) MS_A4 (VGCS GID: 203, 204)

c) Test procedure

originated by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).

GCA_AB1, VGCS GID: 200 Prio 2, GID: 203 Prio 3, GID: 204 Prio 4


with priority 3.
cell_B1.
an in-band notification on FACCH channel
and acoustically.
to accept the VGCS call manually.
the VGCS call (GID 203), the priority of the
of VGCS call (GID 200).
call (GID 203).

203).
allocated.
200).
203).


originated by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
VGCS (200).
cell_B1.
(GID 200).
with priority 3.
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

originated by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).


with priority 3.
cell_B1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


originated by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

originated by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).


203).
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


originated by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

originated by mobile subscriber of network A in VPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).


with priority 3.
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


originated by mobile subscriber of network A in VPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

originated by mobile subscriber of network A in VPLMN (MSC_A1 anchor).
cell_B1.
(GID 200).


with priority 3.
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


Step 10: Mobile subscriber of network A originates VGCS call in HPLMN. Second VGCS
call originated by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

Step 11: Mobile subscriber of network B originates VGCS call in HPLMN. Second VGCS
call originated by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
cell_A1.
(GID 200).


203).
cell_B1.
tion about the incoming VGCS (GID 203).
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


call originated by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
cell_A1.
cally accept the incoming VGCS CALL
(GID 200).
203).
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).


Network A Network B

R-MSC_A1 A-MSC_B1
MS_A1 (VGCS GID: 200, 203, 204) MS_B1 (VGCS GID: 200, 203, 204)
MS_B3 (VGCS GID: 200, 203, 204) MS_A3 (VGCS GID: 200, 203, 204)

Test procedure


GCA_AB1, VGCS GID: 200 Prio 2, GID: 203 Prio 3, GID: 204 Prio 4


call originated by mobile subscriber of network A in HPLMN (MSC_B1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

Step 14: Mobile subscriber of network B originates VGCS call in VPLMN. Second VGCS
VGCS (200).
cell_B1.
(GID 200).


with priority 3.
cell_B1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


call originated by mobile subscriber of network B in VPLMN (MSC_B1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

Step 16: Mobile subscriber of network B originates VGCS call in VPLMN. Second VGCS
cell_B1.
(GID 200).


with priority 3.
cell_B1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


call originated by mobile subscriber of network B in HPLMN (MSC_B1 anchor)
cell_A1.
(GID 200).
203).
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

Step 18: Mobile subscriber of network A originates VGCS call in VPLMN. Second VGCS
cell_A1.
(GID 200).


with priority 3.
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


call originated by mobile subscriber of network A in VPLMN (MSC_B1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

Step 20: Mobile subscriber of network A originates VGCS call in VPLMN. Second VGCS
call originated by mobile subscriber of network A in VPLMN (MSC_B1 anchor)
cell_A1.
(GID 200).


with priority 3.
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


call originated by mobile subscriber of network A in VPLMN (MSC_B1 anchor).
cell_B1.
(GID 200).
with priority 3.
cell_A1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

cell_B1.
(GID 200).


with priority 3.
cell_A1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).


cell_A1.
(GID 200).
203).
cell_B1.
and acoustically.
call (GID 203).


203).
allocated.
200).
203).

cell_A1.
(GID 200).


203).
cell_B1.
and acoustically.
call (GID 203).

203).
allocated.
200).
203).

d) Success criteria
an incoming VGCS call (GID 203, 204). This should succeed in different networks (roaming).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.43 VGCS first talker notification (MS dedicated mode, incoming VBS call, roaming)


2.2.1
5.2.2.47
9.2.5.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
coming VBS call (GID 202, 203). This should be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VGCS call in HPLMN and mobile subscriber of
network A in HPLMN originates VBS call (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VGCS call in VPLMN and mobile subscriber of
network B in VPLMN originates VBS call (MSC_A1 anchor).
Step 5: Mobile subscriber of network B originates VGCS call in HPLMN and mobile subscriber of
network B in HPLMN originates VBS call (MSC_A1 anchor).
Step 6: Mobile subscriber of network A originates VGCS call in VPLMN and mobile subscriber of
network A in VPLMN originates VBS call (MSC_A1 anchor).
network A in HPLMN originates VBS call (MSC_B1 anchor).


network B in VPLMN originates VBS call (MSC_B1 anchor).
network B in HPLMN originates VBS call (MSC_B1 anchor).
network A in VPLMN originates VBS call (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (VGCS GID: 200, VBS GID: 202, 203) MS_B1 (VGCS GID: 200, VBS GID: 202, 203)
MS_A2 (VBS GID: 202, 203) MS_B2 (VBS GID: 202, 203)
MS_B3 (VGCS GID: 200, VBS GID: 202, 203) MS_A3 (VGCS GID: 200, VBS GID: 202, 203)
MS_B4 (VBS GID: 202, 203) MS_A4 (VBS GID: 202, 203)

c) Test procedure

Step 1: Mobile subscriber of network A originates VGCS call in HPLMN and mobile sub-
scriber of network A in HPLMN originates VBS call (MSC_A1 anchor)
cell_B1.
(GID 200).

GCA_AB1, VGCS GID: 200 Prio 2, VBS GID: 202 Prio 3, GID: 203 Prio 4


with priority 3.
cell_B1.
acoustically.
to accept the VBS call manually.
the VBS call (GID 202), the priority of the VBS
call (GID 202) is lower than the priority of
call (GID 202).

7) MS_A2 releases the VBS call (GID 202). The VBS call (GID 202) is released success-
allocated.
200).


Step 2: Mobile subscriber of network B originates VGCS call in VPLMN and mobile sub-
scriber of network A in HPLMN originates VBS call (MSC_A1 anchor)
VGCS call (200).
cell_B1.
(GID 200).
with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.


200).

scriber of network B in VPLMN originates VBS call (MSC_A1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_B1.
acoustically.


VGCS CALL (GID 200).
call (GID 202).

7) MS_B4 releases the VBS call (GID 202). The VBS call (GID 202) is released success-
allocated.
200).

scriber of network B in VPLMN originates VBS call (MSC_A1 anchor)
cell_B1.
(GID 200).


with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.
200).


Step 5: Mobile subscriber of network B originates VGCS call in HPLMN and mobile sub-
scriber of network B in HPLMN originates VBS call (MSC_A1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.


200).

Step 6: Mobile subscriber of network A originates VGCS call in VPLMN and mobile sub-
cell_A1.
(GID 200).
VGCS Call (GID 200).
with priority 3.
cell_A1.
acoustically.


call (GID 202).

allocated.
200).

scriber of network A in VPLMN originates VBS call (MSC_A1 anchor)
cell_A1.
(GID 200).


with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.
200).


cell_A1.
(GID 200).
with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.


200).

cell_B1.
(GID 200).
with priority 3.
cell_A1.
acoustically.


call (GID 202).

allocated.
200).

cell_B1.
(GID 200).


with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.
200).


scriber of network B in VPLMN originates VBS call (MSC_A1 anchor).
cell_A1.
(GID 200).
with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.


200).

scriber of network A in HPLMN originates VBS call (MSC_A1 anchor).
cell_A1.
(GID 200).
with priority 3.
cell_B1.
acoustically.


call (GID 202).

allocated.
200).



Network A Network B

R-MSC_A1 A-MSC_B1
MS_A1 (VGCS GID: 200, VBS GID: 202, 203) MS_B1 (VGCS GID: 200, VBS GID: 202, 203)
MS_B3 (VGCS GID: 200, VBS GID: 202, 203) MS_A3 (VGCS GID: 200, VBS GID: 202, 203)

Test procedure

scriber of network A in HPLMN originates VBS call (MSC_B1 anchor)
cell_B1.
(GID 200).

GCA_AB1, VGCS GID: 200 Prio 2, VBS GID: 202 Prio 3, GID: 203 Prio 4


with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.
200).


scriber of network A in HPLMN originates VBS call (MSC_B1 anchor).
VGCS call (200).
cell_B1.
(GID 200).
with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.


200).

scriber of network B in VPLMN originates VBS call (MSC_B1 anchor)
cell_B1.
(GID 200).
with priority 3.
cell_B1.
acoustically.


ally.
call (GID 202).

allocated.
200).

cell_B1.
(GID 200).


with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.
200).


scriber of network B in HPLMN originates VBS call (MSC_B1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.


200).

cell_A1.
(GID 200).
VGCS Call (GID 200).
with priority 3.
cell_A1.
acoustically.


call (GID 202).

allocated.
200).

scriber of network A in VPLMN originates VBS call (MSC_B1 anchor)
cell_A1.
(GID 200).


with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.
200).


cell_A1.
(GID 200).
with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.


200).

cell_B1.
(GID 200).
with priority 3.
cell_A1.
acoustically.


call (GID 202).

allocated.
200).

cell_B1.
(GID 200).


with priority 3.
cell_A1.
acoustically.
call (GID 202).

allocated.
200).


cell_A1.
(GID 200).
with priority 3.
cell_B1.
acoustically.
call (GID 202).

allocated.


200).

scriber of network A in HPLMN originates VBS call (MSC_B1 anchor)
cell_A1.
(GID 200).
with priority 3.
cell_B1.
acoustically.


call (GID 202).

allocated.
200).

d) Success criteria
an incoming VBS call (GID 202, 203). This should succeed in different networks (roaming).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.44 VGCS first talker notification (MS dedicated mode, incoming REC, non roaming
case)


2.2.1
5.2.2.47
9.2.5.1
13.3.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
coming REC (GID 299).


Network A

Cell_A1
Cell_A2 Cell_A3
MS_A1 (REC GID: 299,
VGCS GID: 200, 203, 204)
VGCS GID: 200, 203, 204)
VGCS GID: 200, 203, 204)
VGCS GID: 200, 203, 204)
CoO=Cell_A2

GID: 203 Prio 3, GID: 204 Prio 4
CoO=Cell_A3



c) Test procedure

cell_A1.
MS_A1, MS_A2 and MS_A4 receive a notifica-
2) MS_A1, MS_A2 and MS_A4 automati-
MS_A1, MS_A2 and MS_A4 are joining the
REC (GID 299).
cell_A2.
ing REC (GID 299).
cation on FACCH channel about the incoming
REC (GID 299). MS_A3 and MS_A4 advertise
the incoming REC (GID 299) optically and
acoustically.
5) MS_A4 and MS_A6 automatically ac-
cepting the incoming REC (GID 299).
MS_A4 and MS_A6 are joining the REC (GID
299).
ing REC call (GID 299).
MS_A3 automatically joins the REC (GID 299).
The uplink on DCH of MS_A3 for the VGCS
call (GID 200) will be released automatically.
Uplink free message is send in cell_A1 and
cell_A2.


9) MS_A5 takes the uplink on GCCH. MS_A5 has two-way voice path. MS_A3,
cell_A3 and the uplink is correctly released.
11) MS_A1 takes the uplink on GCCH. MS_A1 has two-way voice path. MS_A2 is
16) MS_A3 and MS_A4 receive a notification
about the ongoing VGCS call (GID 200).
MS_A3 and MS_A4 rejoin the ongoing VGCS
call (GID 200).
MS_A2, and MS_A4 are able to listen to the
Talker flag at MS_A3 for VGCS call (GID 200)
will be updated.
200)
(GID 203, 204) instead of VGCS call
(GID 200).

d) Success criteria
an incoming REC (GID 299).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.45 VGCS first talker notification (MS dedicated mode, incoming REC, roaming case)


2.2.1
5.2.2.47
9.2.5.1
13.3.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VGCS CALL (GID 200) first talker on dedicated channel get a notification about an
incoming REC (GID 299). This should be verified in different networks (roaming).


network A in HPLMN originates a REC (MSC_A1 anchor).
network B in HPLMN originates a REC (MSC_A1 anchor).
network A in HPLMN originates a REC (MSC_B1 anchor).
network B in HPLMN originates a REC (MSC_B1 anchor).



Network A Network B

Cell_A1 Cell_A2 Cell_B1 Cell_B2
MS_A1 (REC GID: 299
MS_A3 (REC GID:
299,
VGCS GID: 200,
203, 204)
MS_B3 (REC GID:
299,
VGCS GID: 200, 203,
204)
MS_B1 (REC GID: 299
MS_A2 (REC GID: 299
MS_B4 (REC GID:
299,
VGCS GID: 200,
203, 204)
MS_A4 (REC GID:
299,
VGCS GID: 200, 203,
204)
MS_B2 (REC GID: 299

c) Test procedure

GCA_AB1, VGCS GID: 200 Prio 2,




scriber of network A in HPLMN originates a REC (MSC_A1 anchor)
cell_B1.
REC (GID 299).
cell_A2, cell_B1 and cell_B2.
MS_A2, MS_B1 and MS_B2 receiving a notifi-
cation about the incoming REC (GID 299).
about the incoming REC (GID 299). MS_A3,
MS_A4, MS_B3 and MS_B4 advertise the in-
coming REC (GID 299) optically and acousti-
cally.
5) MS_A2, MS_A3, MS_A4, MS_B1,
MS_B2 and MS_B3 automatically ac-
MS_A2, MS_A3, MS_A4, MS_B1, MS_B2 and
MS_B3 are joining the REC (GID 299).
6) MS_B4 automatically accepts the incom-
MS_B4 automatically joins the REC (GID 299).
The uplink on DCH of MS_B4 for the VGCS
cell_B1.


MS_A3, MS_A4, MS_B1, MS_B2, MS_B3 and
MS_B4 are able to listen to the announcement
of MS_A1.
8) MS_A1 releases the uplink. Uplink free message is send in cell_A1,
cell_A2, cell_B1 and cell_B2 and the DCH is
correctly released.
of MS_A1.
cell_A2, cell_B1 and cell_B2 and the uplink is
correctly released.
11) MS_B4 takes the uplink on GCCH. MS_B4 has two-way voice path. MS_A1,
of MS_B4.
12) MS_B4 releases the uplink. Uplink free message is send in cell_A1,
correctly released.
receive a notification about the ongoing
MS_A3, MS_A4, MS_B3 and MS_B4 rejoin the
ongoing VGCS call (GID 200).
MS_A4, and MS_B3 are able to listen to the
Talker flag at MS_B4 for VGCS call (GID 200)
will be updated.
cell_B1 and the uplink is correctly released.
200)
(GID 200).


scriber of network B in HPLMN originates a REC (MSC_A1 anchor)
cell_B1.
REC (GID 299).
cell_A1, cell_A2 and cell_B2.
MS_A1, MS_A2 and MS_B2 receiving a notifi-
cally.
5) MS_A1, MS_A2, MS_A3, MS_A4,
MS_A1, MS_A2, MS_A3, MS_A4, MS_B2 and
cell_B1.


of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_B4.
correctly released.
will be updated.
200)
(GID 200).


cell_A2.
REC (GID 299).
cally.
5) MS_A2, MS_A3, MS_B1, MS_B2,
cell_B1.


of MS_A1.
correctly released.
of MS_A1.
correctly released.
of MS_A4.
correctly released.
MS_B3, and MS_B4 are able to listen to the
will be updated.
200)
(GID 200).


cell_A2.
REC (GID 299).
cally.
cell_B1.


of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_A4.
correctly released.
will be updated.
200)
(GID 200).



Network A Network B

MS_A1 (REC GID: 299
MS_A3 (REC GID:
299,
VGCS GID: 200,
203, 204)
MS_B3 (REC GID:
299,
VGCS GID: 200, 203,
204)
MS_B1 (REC GID: 299
MS_A2 (REC GID: 299
MS_B4 (REC GID:
299,
VGCS GID: 200,
203, 204)
MS_A4 (REC GID:
299,
VGCS GID: 200, 203,
204)
MS_B2 (REC GID: 299

c) Test procedure

GCA_AB1, VGCS GID: 200 Prio 2,




scriber of network A in HPLMN originates a REC (MSC_B1 anchor)
cell_B1.
REC (GID 299).
cally.
cell_B1.


of MS_A1.
correctly released.
of MS_A1.
correctly released.
of MS_B4.
correctly released.
will be updated.
200)
(GID 200).


scriber of network B in HPLMN originates a REC (MSC_B1 anchor)
cell_B1.
REC (GID 299).
cally.
cell_B1.


of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_B4.
correctly released.
will be updated.
200)
(GID 200).


cell_A2.
REC (GID 299).
cally.
cell_B1.


of MS_A1.
correctly released.
of MS_A1.
correctly released.
of MS_A4.
correctly released.
will be updated.
200)
(GID 200).


cell_A2.
REC (GID 299).
cally.
cell_B1.


of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_A4.
correctly released.
will be updated.
200)
(GID 200).



d) Success criteria
The VGCS (GID 299) first talker on the dedicated channel is able to receive notification about an
incoming REC (GID 299).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.46 Multiple VGCS membership (non roaming case)


2.2.14
9.2.5.1
2.2.1

a) Purpose
Verify that a service subscriber can be a member of several VGCS calls at the same time.


Network A

MS_A1 (VGCS GID: 200, 203)
MS_A2 (VGCS GID: 200, 203)
MS_A3 (VGCS GID: 200, 203)
MS_A4 (VGCS GID: 200, 203)

c) Test procedure
CoO=Cell_A1

203 Prio 3



(GID 200).
4) MS_A1 releases the uplink. Uplink free message is send in cell_A1 and the
9) MS_A2 leaves the ongoing VGCS call
(GID 200).
MS_A2 is able to leave VGCS call (GID 200).
MS_A1, MS_A3 and MS_A4 receive an in-
band notification on FACCH channel about the
incoming VGCS call (GID 203). MS_A1,
MS_A3 and MS_A4 advertise the incoming
11) MS_A3 joins the VGCS (GID 203). MS_A3 is able to join the VGCS (GID 203).


203).
allocated.
18) MS_A2 and MS_A3 rejoin the VGCS call
(GID 200).
MS_A1 has two-way voice path. MS_A2. MS_A3
and MS_A4 are able to listen to the announcement
of MS_A1.
200).

d) Success criteria
A service subscriber can be a member of several VGCS calls at the same time.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.47 Multiple VGCS membership (roaming case)


2.2.14
9.2.5.1
2.2.1

a) Purpose
Verify that a service subscriber can be a member of several VGCS calls at the same time.


network B in VPLMN leaves ongoing VGCS and originates second VGCS call (MSC_A1 anchor).
network A in HPLMN leaves ongoing VGCS and originates second VGCS call (MSC_A1 anchor).
network A in VPLMN leaves ongoing VGCS and originates second VGCS call (MSC_A1 anchor).
network B in HPLMN leaves ongoing VGCS and originates second VGCS call (MSC_A1 anchor).
network B in VPLMN leaves ongoing VGCS and originates second VGCS call (MSC_B1 anchor).
network A in HPLMN leaves ongoing VGCS and originates second VGCS call (MSC_B1 anchor).
network A in VPLMN leaves ongoing VGCS and originates second VGCS call (MSC_B1 anchor).
network B in HPLMN leaves ongoing VGCS and originates second VGCS call (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

Test procedure

scriber of network B in VPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_A1 anchor)
cell_B1.
MS_A2, MS_A3, MS_A4, MS_B1, MS_B2,
MS_B3 and MS_B4 receive a notification

GCA_AB1, VGCS GID: 200 Prio 2, GID: 203 Prio 3


MS_B2, MS_B3 and MS_B4 automati-
(GID 200).
MS_B3 and MS_B4 are joining the VGCS call
(GID 200).
of MS_A1.
of MS_A1.
of MS_B3.
of MS_B1.
of MS_A3.
13) MS_B3 leaves the ongoing VGCS call
(GID 200).
MS_B3 is able to leave VGCS call (GID 200).


cell_B1.
MS_A1, MS_A3 and MS_B1 receive an in-
MS_A3 and MS_B1 advertise the incoming
15) MS_A1, MS_A3 and MS_B1 are joining
the VGCS (GID 203).
MS_A1, MS_A3 and MS_B1 are able to join
the VGCS (GID 203).
22) MS_B1 releases the uplink. Uplink free message is send in cell_A1 and the


203).
allocated.
rejoin the VGCS call (GID 200).
MS_A2 has two-way voice path. MS_A1,
of MS_A2.
of MS_A1.
200).

scriber of network A in HPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_A1 anchor)
cell_B1.
MS_A1, MS_A2, MS_A3, MS_A4, MS_B1,
(GID 200).
(GID 200).
of MS_B3.


of MS_B3.
of MS_A1.
of MS_B1.
of MS_A3.
(GID 200).
cell_B1.
MS_A3, MS_B1 and MS_B3 receive an in-
MS_B1 and MS_B3 advertise the incoming
15) MS_A3, MS_B1 and MS_B3 are joining
the VGCS (GID 203).
MS_A3, MS_B1 and MS_B3 are able to join
the VGCS (GID 203).


203).
allocated.
of MS_A2.
of MS_B3.
200).



scriber of network A in VPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_A1 anchor)
cell_A1.
(GID 200).
(GID 200).
of MS_B1.
of MS_B1.
of MS_B3.
of MS_A1.


of MS_A3.
(GID 200).
cell_A1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
MS_B2 has two-way voice path. MS_A1,
of MS_B2.
of MS_B1.
200).


scriber of network B in HPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_A1 anchor)
cell_A1.
(GID 200).
(GID 200).
of MS_A3.
of MS_A3.
of MS_B3.
of MS_A1.


of MS_B1.
(GID 200).
cell_A1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
of MS_B2.
of MS_A3.
200).



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

scriber of network B in VPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_B1 anchor)
cell_B1.

GCA_AB1, VGCS GID: 200 Prio 2, GID: 203 Prio 3


(GID 200).
(GID 200).
of MS_A1.
of MS_A1.
of MS_B3.
of MS_B1.
of MS_A3.
(GID 200).


cell_B1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
of MS_A2.
of MS_A1.
200).

scriber of network A in HPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_B1 anchor)
cell_B1.
(GID 200).
(GID 200).
of MS_B3.


of MS_B3.
of MS_A1.
of MS_B1.
of MS_A3.
(GID 200).
cell_B1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
of MS_A2.
of MS_B3.
200).



scriber of network A in VPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_B1 anchor)
cell_A1.
(GID 200).
(GID 200).
of MS_B1.
of MS_B1.
of MS_B3.
of MS_A1.


of MS_A3.
(GID 200).
cell_A1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
of MS_B2.
of MS_B1.
200).

scriber of network B in HPLMN leaves ongoing VGCS and originates second VGCS call
(MSC_B1 anchor)


cell_A1.
(GID 200).
(GID 200).
of MS_A3.
of MS_A3.
of MS_B3.
of MS_A1.
of MS_B1.


(GID 200).
cell_A1.
the VGCS (GID 203).
the VGCS (GID 203).


203).
allocated.
of MS_B2.
of MS_A3.
200).

d) Success criteria
A service subscriber can join multiple VGCS calls (GID 200, GID 203) in different networks.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.8.48 VGCS call established in CoO when non CoO is locked


9.2.5.1 2.2.1

a) Purpose
Verify that a VGCS call can be established in the cell of origin, even if the non cell of origin is
locked.

Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




1) Lock cell_A2. Cell_A2 is locked.
VGCS call.
call.
Cell_A2 is locked. No GCCH can be allocated
in this cell.
VGCS/VBS Assignment Failure is sent from
the BSC to the MSC with cause No radio re-
source available.
channel).
listener.
7) Unlock cell_A2. Cell_A2 is unlocked.

d) Success criteria
The VGCS call can be established in the cell of origin, even if the non cell of origin is locked.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9 VBS
5.9.1 SS originates VBS call


2.2.1
2.2.7
2.2.11
3.2.3
3.5.2
3.5.3
11.2.3.2
2.2.1
9.2.11

a) Purpose
Verify that a service subscriber can originate a VBS call and the correct priority is transmitted
from the BSC.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1

GCA_A1, VBS GID: 202 Prio 3



VBS call.
call.
whole VBS call.
2) MS_A2 accepts the incoming VBS. MS_A2 can join VBS call. MS_A1 has two-way
BSC.

d) Success criteria
The service subscriber is able to originate a VBS call and the correct priority is transmitted from
the BSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.2 Modification of broadcast area


2.2.10 2.2.1

a) Purpose
Verify that it is possible to modify a broadcast area.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
call.
whole VBS call.
4) Add cell_A2 to the group call area. The group call area consists of cell_A1 and
cell_A2 as shown in the picture below.

Network A

Cell_A1 Cell_A2
CoO=Cell_A1



VBS call.
cell_A2.
incoming call.
whole VBS call.
VBS call.
MS_A2 and MS_A3 can join VBS call. MS_A1
are only listener.

d) Success criteria
It is possible to modify a broadcast area.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.3 SS originates a VBS (prio4) call


2.2.1

a) Purpose
Verify that a service subscriber is able to establish a VBS call priority 4 and the correct priority is
transmitted from the BSC.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
call.
whole VBS call.
BSC.

d) Success criteria
A service subscriber is able to establish a VBS call priority 4 and the correct priority is transmitted
from the BSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.4 Controller originates a VBS (prio3) call.


3.5.2
3.5.3
2.2.1
9.2.11
9.5.4

a) Purpose
Verify that a controller can originate a VBS call with priority 3 and that the correct priority is sent
on the Notification message from the BSC. Verify that the controller can release the call using
the kill sequence.


Network A


c) Test procedure




1) Controller CT_A1 originates a VBS call
cell_A1.
VBS call.
2) MS_A1 accepts the incoming VBS. MS_A1 joins VBS call.
MS_A1 is only listener.
BSC.

d) Success criteria
A controller can originate a VBS call with priority 3 and that the correct priority is sent on the Noti-
fication message from the BSC. The controller can release the call using the kill sequence.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.5 Controller originates a VBS (prio4) call


3.5.2
3.5.3
2.2.1

a) Purpose
Verify that a controller can originate a VBS call with priority 4 and that the correct priority is sent
on the Notification message from the BSC. Verify that the controller can release the call using
the kill sequence.


Network A


c) Test procedure




cell_A1.
VBS call.
BSC.

d) Success criteria
A controller can originate a VBS call with priority 4 and that the correct priority is sent on the Noti-
fication message from the BSC. The controller can release the call using the kill sequence.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.6 Controller joins ongoing VBS call


2.2.1

a) Purpose
Verify that a controller can join an ongoing VBS call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
MS_A2 and CT_A1 receive notification of the
incoming call.
whole VBS call.
VBS call.
MS_A2 and CT_A1 can join the VBS call.
MS_A1 has two-way voice path, CT_A1 and
3) CT_A1 leaves the VBS call. CT_A1 is not part of the call anymore. VBS call
is not released.
4) Controller CT_A1 dials 51 + < GCA > +
<GID>
Controller CT_A1 joins the VBS call again.
CT_A1 joins VBS call.
MS_A1 has two-way voice path, CT_A1 and

d) Success criteria
A controller can join an ongoing VBS call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.7 SS enters into VBS broadcast area with ongoing VBS call and is notified of it, SS
joins the VBS call


2.2.1

a) Purpose
Verify that a service subscriber is notified of an ongoing VBS call by entering the VBS broadcast
area and is able to join this call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A2




VBS call.
call.
whole VBS call.
listener.
3) MS_A1 moves from cell_A1 to cell_A2
(VBS broadcast area).
MS_A1 is notified about the ongoing VBS call.
4) MS_A1 joins the call. MS_A1 joins the call. MS_A2 has two-way
voice path, MS_A1 and MS_A3 are only listen-
ers.

d) Success criteria
The service subscriber is notified of the ongoing VBS call by entering the VBS broadcast area
and is able to join the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.8 Parallel VBS (different GID) calls are possible in the same cell


2.2.1

a) Purpose
Verify that it is possible to have different VBS calls with a different GID in a cell in parallel.


Network A


c) Test procedure
CoO=Cell_A1

GCA_A1, VBS GID: 202 Prio 3,
VBS GID: 203 Prio 4



VBS call.
call.
whole VBS call.
2) MS_A2 accepts the incoming VBS call. MS_A2 joins VBS call.
listener.
VBS call.
call.
whole VBS call.
listener.

d) Success criteria
It is possible to have different VBS calls with a different GID in a cell in parallel.

e) Test result

Remarks
Attachments
(log / trace file)



5.9.9 Parallel VBS calls with the same GID are possible (same BSS, different BSS)


2.2.1

a) Purpose
Verify that it is possible to establish two VBS calls with the same GID in parallel in the same BSS
as well as in different BSS.

Step 1: Two VBS calls established in same BSS.
Step 2: Two VBS calls established in different BSS.

Network A

Cell_A1
Cell_A3
Cell_A2
MS_A1 (VBS GID:
202)
MS_A2 (VBS GID:
202)

MS_A4 (VBS GID:
202)


CoO=Cell_A3




c) Test procedure

Step 1: Two VBS calls established in same BSS.
VBS call (GCA_A2).

cell_A2.
whole VBS call.
incoming VBS.
MS_A3, MS_A4 and MS_A5 join VBS call.
VBS call (GCA_A1)

MS_A2, MS_A3, MS_A4 and MS_A5 receive
whole VBS call.
4) MS_A3 leaves the first VBS call
(GCA_A2) and joins the second VBS call
(GCA_A1).
MS_A2, MS_A4 and MS_A5 remain on
the first call (GCA_A2).
MS_A3 joins VBS call. MS_A1 has two-way
MS_A2, MS_A4 and MS_A5 do not join the
second call (GCA_A1).
5) MS_A1 releases the VBS call.
MS_A2 releases the VBS call.
The calls are released and all resources are


Step 2: Two VBS calls established in different BSS.
VBS call (GCA_A2).

cell_A2.
whole VBS call.
incoming VBS.
MS_A3, MS_A4 and MS_A5 join VBS call.
3) Service subscriber MS_A3 leaves the
first VBS call (GCA_A1).
Service subscriber MS_A3 leaves the call.
VBS call (GCA_A1)

MS_A1, MS_A2, MS_A4 and MS_A5 receive
whole VBS call.
5) MS_A1 joins the VBS call with
(GCA_A1).
MS_A2, MS_A4 and MS_A5 are notified
about the second VBS call, but do not
accept this one.
MS_A1 joins VBS call. MS_A3 has two-way
MS_A2, MS_A4 and MS_A5 remain on the first
VBS call (GCA_A2).
MS_A3 releases the VBS call.
The calls are released and all resources are

d) Success criteria
It is possible to establish two VBS calls with the same GID in parallel in the same BSS as well as
in different BSS.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.10 Two controllers initiate VBS with the same GID but different GCAs


3.5.2
3.5.3
2.2.1

a) Purpose
Verify that two voice broadcast calls can be established with the same GID in different group call
areas at the same time.


Network A

Cell_A1 Cell_A2
CT_A1 (GCA_A1, VBS GID: 202) CT_A2 (GCA_A2, VBS GID: 202)

c) Test procedure
CoO=Cell_A1

CoO=Cell_A2




controller CT_A1 originates a VBS call by
dialling 51 + < GCA_A1 > + <GID>
and
controller CT_A2 originates a VBS call by
dialling 51 + < GCA_A2 > + <GID>
VBS call (GCA_A1).
VBS call (GCA_A2).
VBS call respectively.
MS_A1 joins VBS call (GCA_A1). VBS call is
correctly established.
cell_A1.
CT_A1 has two-way voice path during the
whole call.
MS_A2 joins VBS call (GCA_A2). VBS call is
cell_A2.
whole call.

d) Success criteria
Two voice broadcast calls can be established with the same GID in different group call areas at
the same time.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


non COO during SS originated VBS call


2.2.1

a) Purpose
Verify that a VBS call can be established in the cell of origin, even if in the non cell of origin the
call is queued and verify that after resources are freed, Assignment Result is sent to the MSC
and a GCCH is allocated in the non cell of origin.


Network A

Cell_A1 Cell_A2
MS_A5
MS_A6
MS_A7
MS_A8
CoO=Cell_A1




c) Test procedure



cell_A2.
VBS call.
VBS call is correctly established in cell_A1.
call.
whole VBS call.
In cell_A2, all traffic channels are busy. VBS
If traffic channels are available before timer
signment Result is sent to the MSC.
listener.
6) MS_A3 releases the PTP call before
timer T14 expires.
VGCS/VBS Assignment Result is sent to the
MSC before timer expiration.
coming VBS call.
7) MS_A3 and MS_4 accept the incoming
VBS call.
MS_A3 and MS_A4 join the VBS call. MS_A1
has two-way voice path. MS_A2, MS_A3 and



d) Success criteria
The VBS call can be established in the cell of origin, even if in the non cell of origin the call is
queued. After resources are freed, Assignment Result is sent to the MSC and a GCCH is allo-
cated in the non cell of origin.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


COO during SS originated VBS call


2.2.1

a) Purpose
Verify that a VBS call can be established in the cell of origin, when in this cell the group call chan-
nel is queued and after resources are freed, Assignment Result is sent to the MSC and a GCCH
is allocated.

Check the values of BSC Timer T14 and MSC Timer Txx.

Network A

Cell_A1 Cell_A2
MS_A1 MS_A7 (VBS GID: 202)
MS_A2
MS_A5
CT_A1
CoO=Cell_A1




c) Test procedure

gin.
origin.
VBS call.
cell_A1.
call.
5) If BSC Timer T14 > MSC Timer Txx then:
fore expiration of timer Txx. Otherwise
the call will be terminated from the MSC.
If MSC Timer Txx > BSC Timer T14 then:
fore expiration of timer T14. Otherwise
message VGCS/VBS Assignment Fail-
ure is sent to the MSC.
Message VGCS/VBS Assignment Result is
sent to the MSC.
cell_A1.
incoming call.
whole VBS call.
VBS call.
two-way voice path, MS_A3, MS_A7, and

The call is released and all related resources



d) Success criteria
A VBS call can be established in the cell of origin, when in this cell the group call channel is
queued and after resources are freed, Assignment Result is sent to the MSC and a GCCH is
allocated.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


non COO during SS originated VBS call


2.2.1

a) Purpose
Verify that VBS call can be established in the cell of origin, even if in the non cell of origin the call
is queued and an Assignment Failure is sent to the MSC.


Network A

Cell_A1 Cell_A2
MS_A5
MS_A6
MS_A7
MS_A8
CoO=Cell_A1




c) Test procedure


cell_A2.
VBS call.
call.
whole VBS call.
In cell_A2, all traffic channels are busy. VBS
If no traffic channels are available before timer
signment Failure with cause No radio re-
source available is sent to the MSC.
5) MS_A2 accepts the incoming VBS. MS_A2 joins VBS call. MS_A1 has two-way
6) MS_A3 releases the PTP call after timer
T14 expires.
VGCS/VBS Assignment Failure with cause
No radio resource available is sent to the
MSC after timer expiration.
The PTP call is released and all related re-
No VBS call could be established in cell_A2.



d) Success criteria
The VBS call can be established in the cell of origin, even if in the non cell of origin the call is
queued and an Assignment Failure is sent to the MSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


CoO during SS originated VBS call


2.2.1

a) Purpose
Verify that a VBS call cannot be established in the cell of origin, when in this cell the group call
channel is queued and resources are not freed before T14 expires.

MSC Timer Txx > BSC Timer T14. Otherwise Assignment Failure will not be available because
the call will be terminated from the MSC. Note: In this case the test case is not applicable.



Network A

Cell_A1 Cell_A2
MS_A1 MS_A7 (VBS GID: 202)
MS_A2
MS_A5
CT_A1

c) Test procedure

gin.
origin.
CoO=Cell_A1



VBS call.
cell_A1.
call.
5) MS_A3 releases the PTP call after the
Indication message to the MSC and after
expiration of timer T14.
Message VGCS/VBS Assignment Failure is
sent to the MSC.
All related resources are correctly de-allocated.

d) Success criteria
The VBS call cannot be established in the cell of origin, when in this cell the group call channel is
queued and resources are not freed before T14 expires.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.15 Contact loss for VBS originator


2.2.1

a) Purpose
Verify that the VBS call is correctly released in case the originating service subscriber looses con-
tact to the network.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
incoming call.
whole VBS call.
VBS.
only listener.
The dedicated channel is correctly released.
Release cause: Radio Interface Failure.

d) Success criteria
The VBS call is correctly released in case the originating service subscriber looses contact to the
network.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.16 Equipment failure (TRX) for VBS originator


2.2.1

a) Purpose
Verify that the VBS call is correctly released in case of equipment failure (TRX failure) on the TRX
where the dedicated channel is allocated.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
incoming call.
whole VBS call.
VBS.
MS_A2 and MS_A3 join VBS call.
cell_A1 (where the dedicated channel is
allocated).
Release cause: Equipment Failure.
4) Put TRX back into service again.

TRX is working correctly.

d) Success criteria
The VBS call is correctly released in case of equipment failure (TRX failure) on the TRX where
the dedicated channel is allocated.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.17 Equipment failure (PCM) for VBS originator


2.2.1

a) Purpose
Verify that the VBS call is correctly released in case of equipment failure (PCM failure) in the cell
where the dedicated channel is allocated.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
incoming call.
whole VBS call.
VBS.
MS_A2 and MS_A3 join VBS call.
3) Originate a PCM failure in cell_A1 (where
the dedicated channel is allocated).
Release cause: Equipment Failure.
4) Put the PCM link back into service again. PCM link is working correctly.

d) Success criteria
The VBS call is correctly released in case of equipment failure (PCM failure) in the cell where the
dedicated channel is allocated.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.18 VBS call established in CoO when non CoO is locked


2.2.1

a) Purpose
Verify that a VBS call can be established in the cell of origin, even if the non cell of origin is
locked.

Network A

Cell_A1 Cell_A2

c) Test procedure

1) Lock cell_A2. Cell_A2 is locked.
CoO=Cell_A1



VBS call.
call.
whole VBS call.
Cell_A2 is locked. No GCCH can be allocated
in this cell.
VGCS/VBS Assignment Failure is sent from
the BSC to the MSC with cause No radio re-
source available.
3) MS_A2 accepts the incoming VBS call. MS_A2 joins VBS call.
listener.
5) Unlock cell_A2. Cell_A2 is unlocked.

d) Success criteria
The VBS call can be established in the cell of origin, even if the non cell of origin is locked.
e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.19 Origination of VBS call from non subscribed MS fails


2.2.1

a) Purpose
Verify that a service subscriber cannot originate a VBS call if it is located outside the GCA or if it
has no subscription to regarding GID.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID: 202) MS_A2

c) Test procedure
CoO=Cell_A2




VBS call.
VBS call is not established.
VBS call.

d) Success criteria
The service subscriber cannot originate a VBS call if it is located outside the GCA or if it has no
subscription to regarding GID.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.20 Origination by controller fails


2.2.1

a) Purpose
Verify that a controller cannot originate a VBS call if it is not entitled for this.

CT_A1 is not entitled to originate calls on the regarding GCA.

Network A


c) Test procedure




d) Success criteria
The controller cannot originate a VBS call if it is not entitled for this.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.21 Killing of VBS call by controller fails


2.2.1

a) Purpose
Verify that a controller cannot kill a VBS call if it is not entitled for this.

CT_A1 is not entitled to kill calls on the regarding GCA.

Network A


c) Test procedure
CoO=Cell_A1




VBS call.
incoming call.
whole VBS call.
VBS.
MS_A2 and CT_A1 join the VBS call. VBS call
is correctly established.
MS_A2 and CT_A1 are only listener.
The call is not released.

d) Success criteria
The controller cannot kill a VBS call if it is not entitled for this.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.22 VBS call taken down during setup by SS


2.2.1

a) Purpose
Verify that a service subscriber can take down a VBS call during the call establishment.


Network A


c) Test procedure

VBS call and hangs up before the call is
established.
CoO=Cell_A1




d) Success criteria
A service subscriber can take down a VBS call during the call establishment.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.23 VBS call taken down during setup by Controller


2.2.1

a) Purpose
Verify that a controller can take down a VBS call during the call establishment.


Network A


c) Test procedure

by dialling 51 + < GCA > + <GID> and
hangs up before the call is established.




d) Success criteria
Controller can take down a VBS call during the call establishment.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.24 Two SS originate VBS call at same time (same BSS and different BSS)


2.2.1

a) Purpose
Verify that when two service subscribers originate a VBS call at the same time, only one can es-
tablish the call and the other receives the notification of this incoming call.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1
CoO=Cell_A2




VBS call.
VBS call with.
VBS call.
whole VBS call.
incoming VBS.
The notified MS and MS_A2 join VBS call. The
originating MS has two-way voice path, the
other two are only listener.
3) Originating MS releases the VBS call. The call is released and all resources are cor-
VBS call.
VBS call.
VBS.
channel (GCCH) are allocated in the cell where
the call was established.
A GCCH is allocated in the other cell.
whole VBS call.
incoming VBS.
MS and MS_A3 join VBS call. The originating
MS has two-way voice path, the other two are
only listener.
6) Originating MS releases the VBS call. The call is released and all resources are cor-

d) Success criteria
When two service subscribers originate a VBS call at the same time, only one can establish the
call and the other receives the notification of this incoming call.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.25 Two controllers originate VBS call at the same time


2.2.1

a) Purpose
Verify that when two controllers originate a VBS call at the same time (same group call refer-
ence), only one can establish the call.


Network A

Cell_A1 Cell_A2

c) Test procedure




Controller CT_A1 originates a VBS call
Controller CT_A2 originates a VBS call
Only one controller manages to establish a
VBS call.
coming VBS call.
The controller not able to establish the call is
notified about the incoming VBS call.
2) MS_A1, MS_A2 and controller not able
to establish the call accept the incoming
VBS call.
MS_A1 and MS_A2 join VBS call in group re-
ceive mode.
Controller not able to establish the call joins
the VBS call.
Controller able to establish the call has voice
path and MS_A1, MS_A2 and joining controller
are able to listen to the announcement of the
originating controller.
3) The controller able to establish the call
releases it by using the kill sequence
(dialling ***).

d) Success criteria
When two controllers originate a VBS call at the same time (same group call reference), only one
can establish the call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.26 Service Subscriber initiated VBS from Relay MSC. Call to A-MSC controller


2.2.1

a) Purpose
Verify that a service subscriber can originate and release a VBS call from relay MSC. A controller
in anchor MSC is connected to the call.
Step 1: VBS call establishment in relay MSC_B1.
Step 2: VBS call establishment in relay MSC_A1.



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (VBS GID: 202) MS_B1 (VBS GID: 202)
CT_A1 (GCA_AB1, VBS GID: 202)

c) Test procedure

Step 1: VBS call establishment in relay MSC_B1
VBS call.
whole VBS call.
accept the incoming VBS.
CT_A1, MS_A1, MS_A2 and MS_B2 join VBS
call.
MS_B1 has two-way voice path, CT_A1
MS_A1, MS_A2 and MS_B2 are only listener.
3) MS_B1 releases the VBS call. The call is released and all resources are cor-
CoO=Cell_B1





Network A Network B

R-MSC_A1 A-MSC_B1
CT_B1 (GCA_AB1, VBS GID: 202)

Test procedure
CoO=Cell_A1



Step 2: VBS call establishment in relay MSC_A1
VBS call.
whole VBS call.
accept the incoming VBS.
CT_B1, MS_B1, MS_A2 and MS_B2 join VBS
call.
MS_B1 has two-way voice path, CT_B1
MS_B1, MS_A2 and MS_B2 are only listener.

d) Success criteria
The service subscriber can originate and release a VBS call from relay MSC. The controller in
anchor MSC is connected to the call..

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.27 Controller originates a VBS call from Relay MSC


2.2.1

a) Purpose
Verify that a controller can originate and kill a VBS call from relay MSC.

Step 1: VBS call establishment in anchor MSC_A1.
Step 2: VBS call establishment in anchor MSC_B1.



Network A Network B

A-MSC_A1 R-MSC_B1
CT_B1 (GCA_AB1, VBS GID: 202)

c) Test procedure

Step 1: VBS call establishment in anchor MSC_A1
1) Controller CT_B1 originates a VBS call
+ <GID> (CT 5 Eirene Format)
incoming VBS call.
VBS.
MS_A1 and MS_B1 join VBS call. VBS call is
cell_A1 and cell_B1 respectively.
CT_B1 has two-way voice path during the
whole call.
MS_A1 and MS_B1 are only listener.
4) Controller CT_B1 originates a VBS call
E.164)
incoming VBS call.



VBS call.
CT_B1 has two-way voice path during the
whole call.


Network A Network B

R-MSC_A1 A-MSC_B1
CT_A1 (GCA_AB1, VBS GID: 202)

Test procedure



Step 2: VBS call establishment in anchor MSC_B1
+ <GID> (CT 5 Eirene Format)
incoming VBS call.
VBS.
whole call.
E.164)
incoming VBS call.
VBS call.
whole call.

d) Success criteria
The controller can originate and kill a VBS call from relay MSC.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.28 VBS originator notification (MS dedicated mode, incoming PTP call, non roaming
case)


2.2.1
5.2.2.43
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS originator get a notification about an incoming PTP call.


Network A

Cell_A1 Cell_A2
MS_A2 (VBS GID: 202) MS_A4 (no VGCS / VBS subscriber)

c) Test procedure
CoO=Cell_A1




VBS call (GID 202).
cell_A2.
MS_A2, MS_A3 receives notification of the
incoming VBS call (GID 202).
the incoming VBS call (GID 202).
MS_A2, MS_A3 joins VBS call (GID 202).
4 to MS_A1.
call from MS_A4.
released by the network. All resources are cor-
rectly released by the network.
6) Repeat step 1 to 5 with priority 3 for the
PTP call.

d) Success criteria
The VBS (GID 202) originator is able to receive notification about an incoming PTP call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.29 VBS originator notification (MS dedicated mode, incoming VGCS call, non roaming
case)


2.2.1
5.2.2.47
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming VGCS call.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID: 202, VGCS GID: 203, 204) MS_A3 (VGCS GID: 203, 204)

c) Test procedure

GCA_A1, VBS GID: 202 Prio 3, VGCS GID: 203 Prio 3, GID: 204
Prio 4



1)
VBS call (GID 202).
cell_A2.
ing VBS call (GID 202).
2)
MS_A2 automatically accepts the incom-
MS_A2 joins VBS call (GID 202).
MS_A1 has two-way voice path. MS_A2 is only
listener.
3)
cell_A1.
FACCH channel about the incoming VGCS call
(GID 203). MS_A1 advertise the incoming
4)
MS_A1 dont accept the incoming VGCS
call (GID 203).

5)
MS_A3 releases the VGCS call (GID
203).
6)
MS_A1 releases the VBS call (GID 202). VBS call (GID 202) is released successfully
7)
Repeat from step 1 to 6 with VGCS call
203).



d) Success criteria
The VBS (GID 202) originator is able to receive notification about an incoming VGCS call (GID
203, 204).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.30 VBS originator notification (MS dedicated mode, incoming VBS call, non roaming
case)


2.2.1
5.2.2.47
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming VBS call (GID 200).


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID: 202, 203) MS_A3 (VBS GID: 203)

c) Test procedure

GCA_A1, VBS GID: 202 Prio 3, GID: 203 Prio 4



VBS call (GID 202).
cell_A2.
MS_A2 joins VBS call (GID 202).
listener.
cell_A1.
MS_A1 receive an in-band notification on
call (GID 203).


d) Success criteria
The VBS (GID 202) originator is able to receive notification about an incoming VBS call (GID
200).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.31 VBS originator notification (MS dedicated mode, incoming PTP call, roaming)


2.2.1
5.2.2.43
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming PTP call. This should
be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VBS call in HPLMN (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VBS call in VPLMN (MSC_A1 anchor).
Step 3: Mobile subscriber of network B originates VBS call in HPLMN (MSC_A1 anchor).
Step 4: Mobile subscriber of network A originates VBS call in VPLMN (MSC_A1 anchor).
Step 5: Mobile subscriber of network A originates VBS call in HPLMN (MSC_B1 anchor).
Step 6: Mobile subscriber of network B originates VBS call in VPLMN (MSC_B1 anchor).
Step 7: Mobile subscriber of network B originates VBS call in HPLMN (MSC_B1 anchor).
Step 8: Mobile subscriber of network A originates VBS call in VPLMN (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: Mobile subscriber of network A originates VBS call in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).



4 to MS_A1.
call from MS_A2.
4 to MS_A1.
call from MS_B4.
4 to MS_A1.
call from MS_B2.
4 to MS_A1.
call from MS_A4.


Step 2: Mobile subscriber of network B originates VBS call in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
4 to MS_A1.
call from MS_A2.
4 to MS_B3.
call from MS_B4.
4 to MS_B3.
call from MS_B2.
4 to MS_B3.
call from MS_A4.
11) MS_B3 releases the VBS call (GID 202). VBS call (GID 202) is released successfully



Step 3: Mobile subscriber of network B originates VBS call in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
4 to MS_B1.
call from MS_A2.
4 to MS_B1.
call from MS_B4.
4 to MS_B1.
call from MS_B2.
4 to MS_B1.


call from MS_A4.

Step 4: Mobile subscriber of network A originates VBS call in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
4 to MS_A3.
call from MS_A2.
4 to MS_A3.
call from MS_B4.
4 to MS_A3.


call from MS_B2.
4 to MS_A3.
call from MS_A4.



Network A Network B

B-MSC_A1 A-MSC_B1

Test procedure

Step 5: Mobile subscriber of network A originates VBS call in HPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).



4 to MS_A1.
call from MS_A2.
4 to MS_A1.
call from MS_B4.
4 to MS_A1.
call from MS_B2.
4 to MS_A1.
call from MS_A4.


Step 6: Mobile subscriber of network B originates VBS call in VPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
4 to MS_A1.
call from MS_A2.
4 to MS_B3.
call from MS_B4.
4 to MS_B3.
call from MS_B2.
4 to MS_B3.
call from MS_A4.



Step 7: Mobile subscriber of network B originates VBS call in HPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
4 to MS_B1.
call from MS_A2.
4 to MS_B1.
call from MS_B4.
4 to MS_B1.
call from MS_B2.
4 to MS_B1.


call from MS_A4.

Step 8: Mobile subscriber of network A originates VBS call in VPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
4 to MS_A3.
call from MS_A2.
4 to MS_A3.
call from MS_B4.
4 to MS_A3.


call from MS_B2.
4 to MS_A3.
call from MS_A4.

d) Success criteria
Verify that a VBS (GID 202) originator is able to receive notification about an incoming PTP call.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.32 VBS originator notification (MS dedicated mode, incoming VGCS call, roaming)


2.2.1
5.2.2.47
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming VGCS call (GID 203,
204) call. This should be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VBS call in HPLMN. VGCS call originated by
mobile subscriber of network A in HPLMN (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VBS call in VPLMN. VGCS call originated by
mobile subscriber of network B in VPLMN (MSC_A1 anchor).
Step 5: Mobile subscriber of network B originates VBS call in HPLMN. VGCS call originated by
mobile subscriber of network B in HPLMN (MSC_A1 anchor).
Step 6: Mobile subscriber of network A originates VBS call in VPLMN. VGCS call originated by
mobile subscriber of network A in VPLMN (MSC_A1 anchor).
mobile subscriber of network A in HPLMN (MSC_B1 anchor).


mobile subscriber of network B in VPLMN (MSC_B1 anchor).
mobile subscriber of network B in HPLMN (MSC_B1 anchor).
mobile subscriber of network A in VPLMN (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1
MS_A1 (VBS GID: 202, VGCS GID: 203, 204) MS_B1 (VBS GID: 202, VGCS GID: 203, 204)
MS_B3 (VBS GID: 202, VGCS GID: 203, 204) MS_A3 (VBS GID: 202, VGCS GID: 203, 204)

c) Test procedure

Step 1: Mobile subscriber of network A originates VBS call in HPLMN. VGCS call originated
by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).

GCA_AB1, VBS GID: 202 Prio 3, VGCS GID: 203 Prio 3, GID: 204 Prio 4


with priority 3.
cell_B1.
and acoustically.
MS_A1, MS_A3, MS_B1 and MS_B3
dont accept the incoming VGCS call
(GID 203).

203).
allocated.
203).


Step 2: Mobile subscriber of network B originates VBS call in VPLMN. VGCS call originated
by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
VBS (202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
and acoustically.
(GID 203).

203).
allocated.


203).

by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
and acoustically.


(GID 203).

203).
allocated.
203).

Step 4: Mobile subscriber of network B originates VBS call in VPLMN. VGCS call originated
by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).


with priority 3.
cell_B1.
and acoustically.
(GID 203).

203).
allocated.
203).


Step 5: Mobile subscriber of network B originates VBS call in HPLMN. VGCS call originated
by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_A1.
and acoustically.
(GID 203).

203).
allocated.


203).

Step 6: Mobile subscriber of network A originates VBS call in VPLMN. VGCS call originated
by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.


(GID 203).

203).
allocated.
203).

Step 7: Mobile subscriber of network B originates VBS call in HPLMN. VGCS call originated
by mobile subscriber of network A in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).


with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.
203).


Step 8: Mobile subscriber of network A originates VBS call in VPLMN. VGCS call origi-
nated by mobile subscriber of network A in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.


203).

by mobile subscriber of network A in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.


(GID 203).

203).
allocated.
203).

Step 10: Mobile subscriber of network A originates VBS call in HPLMN. VGCS call origi-
nated by mobile subscriber of network B in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).


with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.
203).


Step 11: Mobile subscriber of network B originates VBS call in HPLMN. VGCS call origi-
nated by mobile subscriber of network B in VPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_B1.
and acoustically.
(GID 203).

203).
allocated.


203).

nated by mobile subscriber of network A in HPLMN (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_B1.
and acoustically.


(GID 203).

203).
allocated.
203).



Network A Network B

R-MSC_A1 A-MSC_B1
MS_A1 (VBS GID: 202, VGCS GID: 203, 204) MS_B1 (VBS GID: 202, VGCS GID: 203, 204)
MS_B3 (VBS GID: 202, VGCS GID: 203, 204) MS_A3 (VBS GID: 202, VGCS GID: 203, 204)

Test procedure
nated by mobile subscriber of network A in HPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).

GCA_AB1, VBS GID: 202 Prio 3, VGCS GID: 203 Prio 3, GID: 204 Prio 4


with priority 3.
cell_B1.
and acoustically.
(GID 203).

203).
allocated.
203).


Step 14: Mobile subscriber of network B originates VBS call in VPLMN. VGCS call origi-
VBS (202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
and acoustically.
(GID 203).

203).
allocated.


203).

nated by mobile subscriber of network B in VPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
and acoustically.


(GID 203).

203).
allocated.
203).

Step 16: Mobile subscriber of network B originates VBS call in VPLMN. VGCS call origi-
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).


with priority 3.
cell_B1.
and acoustically.
(GID 203).

203).
allocated.
203).


nated by mobile subscriber of network B in HPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_A1.
and acoustically.
(GID 203).

203).
allocated.


203).

VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.


(GID 203).

203).
allocated.
203).

nated by mobile subscriber of network A in VPLMN (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
200).
VBS call (GID 202).


with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.
203).


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.


203).

VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
and acoustically.


(GID 203).

203).
allocated.
203).

VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).


with priority 3.
cell_A1.
and acoustically.
(GID 203).

203).
allocated.
203).


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_B1.
and acoustically.
(GID 203).

203).
allocated.


203).

VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
203).
cell_B1.
and acoustically.


(GID 203).

203).
allocated.
203).

d) Success criteria
Verify that a VBS (GID 202) originator is able to receive notification about an incoming VGCS call
(GID 200). This should succeed in different networks (roaming).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.33 VBS originator notification (MS dedicated mode, incoming VBS call, roaming)


2.2.1
5.2.2.47
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming VBS call (GID 203).
This should be verified in different networks (roaming).

Step 1: Mobile subscriber of network A originates VBS call in HPLMN and mobile subscriber of
network A in HPLMN originates a second VBS call (MSC_A1 anchor).
Step 2: Mobile subscriber of network B originates VBS call in VPLMN and mobile subscriber of
network B in VPLMN originates a second VBS call (MSC_A1 anchor).
Step 5: Mobile subscriber of network B originates VBS call in HPLMN and mobile subscriber of
network B in HPLMN originates a second VBS call (MSC_A1 anchor).
Step 6: Mobile subscriber of network A originates VBS call in VPLMN and mobile subscriber of
network A in VPLMN originates a second VBS call (MSC_A1 anchor).
network A in HPLMN originates a second VBS call (MSC_B1 anchor).


network B in VPLMN originates a second VBS call (MSC_B1 anchor).
network B in HPLMN originates a second VBS call (MSC_B1 anchor).
network A in VPLMN originates a second VBS call (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

Step 1: Mobile subscriber of network A originates VBS call in HPLMN and mobile sub-
scriber of network A in HPLMN originates a second VBS call (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).

GCA_AB1, VBS GID: 202 Prio 3, GID: 203 Prio 4


with priority 4.
cell_B1.
acoustically.
dont accept the incoming VBS call (GID
203).

allocated.


Step 2: Mobile subscriber of network B originates VBS call in VPLMN and mobile sub-
VBS call (202).
cell_B1.
202).
VBS call (GID 202).
with priority 4.
cell_B1.
acoustically.

allocated.


scriber of network B in VPLMN originates a second VBS call (MSC_A1 anchor)
VBS call (GID 202).
cell_B1.
tion about the incoming VBS.
202).
VBS call (GID 202).
with priority 4.
cell_B1.
acoustically.

allocated.


VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 4.
cell_B1.
acoustically.

allocated.


Step 5: Mobile subscriber of network B originates VBS call in HPLMN and mobile sub-
scriber of network B in HPLMN originates a second VBS call (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


Step 6: Mobile subscriber of network A originates VBS call in VPLMN and mobile sub-
VBS call (GID 202).
cell_A1.
202).
VBS Call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


scriber of network A in VPLMN originates a second VBS call (MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
acoustically.

allocated.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

scriber of network A in HPLMN originates a second VBS call (MSC_B1 anchor)
VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).



with priority 3.
cell_B1.
acoustically.

allocated.

VBS call (202).
cell_B1.
202).
VBS call (GID 202).


with priority 3.
cell_B1.
acoustically.

allocated.


scriber of network B in VPLMN originates a second VBS call (MSC_B1 anchor)
1)
Service subscriber MS_A1 originates
VBS call (GID 202).
cell_B1.
2)
MS_A3, MS_B1 and MS_B3 automati-
202).
VBS call (GID 202).
3)
MS_B4 originates a VBS call (GID 203)
with priority 3.
cell_B1.
acoustically.
4)
MS_A2 MS_A4 and MS_B2 automati-
If the priority is lower than 3, the user as to
accept the VBS call (GID 203) manually.

5)
MS_B4 releases the VBS call (GID 203). The VBS call (GID 203) is released success-
allocated.
6)


scriber of network B in VPLMN originates a second VBS call (MSC_B1 anchor)
1)
Service subscriber MS_B3 originates
VBS call (GID 202).
cell_B1.
2)
MS_A1, MS_A3 and MS_B1 automati-
202).
VBS call (GID 202).
3)
MS_B4 originates a VBS call (GID 203)
with priority 3.
cell_B1.
acoustically.
4)

5)
allocated.
6)
MS_B3 releases the VBS call (GID 202). VBS call (GID 202) is released successfully


scriber of network B in HPLMN originates a second VBS call (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS Call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


scriber of network A in VPLMN originates a second VBS call (MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


VBS call (GID 202).
cell_B1.
202).
VBS call (GID 202).
with priority 3.
cell_A1.
acoustically.

allocated.


scriber of network B in VPLMN originates a second VBS call (MSC_B1 anchor).
VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
acoustically.

allocated.


VBS call (GID 202).
cell_A1.
202).
VBS call (GID 202).
with priority 3.
cell_B1.
acoustically.

allocated.



d) Success criteria
Verify that a VBS (GID 202) originator is able to receive notification about an incoming VBS call
(GID 200). This should succeed in different networks (roaming).

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.34 VBS originator notification (MS dedicated mode, incoming REC, non roaming
case)


2.2.1
5.2.2.47
13.3.1
2.2.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming REC (GID 299).


Network A

Cell_A1
Cell_A2 Cell_A3
MS_A1 (REC GID: 299, VBS
GID: 202, 203)
VBS GID: 202, 203)
MS_A2 (REC GID: 299, VBS
GID: 202, 203)
VBS GID: 202, 203)
CoO=Cell_A2

GID: 203 Prio 4
CoO=Cell_A3



c) Test procedure

1)
VBS call (GID 202).
cell_A1.
2)
MS_A1, MS_A2 and MS_A4 automati-
VBS call (GID 202).
3)
REC (GID 299).
cell_A2.
ing REC (GID 299).
cation on FACCH channel about the incoming
REC (GID 299). MS_A3 and MS_A4 advertise
the incoming REC (GID 299) optically and
acoustically.
4)
MS_A4 and MS_A6 automatically ac-
MS_A4 and MS_A6 are joining the REC (GID
299).
5)
MS_A3 automatically accepts the incom-
The VBS call (GID 202) will be released auto-
matically and all resources are correctly de-
allocated.
6)
MS_A5 takes the uplink on DCH. MS_A5 has two-way voice path. MS_A3,


7)
MS_A5 releases the uplink. Uplink free message is send in cell_A2 and
8)
MS_A5 takes the uplink on GCCH. MS_A5 has two-way voice path. MS_A3,
9)
10)
11)
12)
MS_A5 releases the REC (GID 299). REC (GID 299) is released successfully and all
13)
Repeat from step 1 to 12 with VBS call

d) Success criteria
The VBS (GID 202) originator is able to receive notification about an incoming REC call (GID 299)
and will be pre-empted.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.35 VBS originator notification (MS dedicated mode, incoming REC, roaming case)


2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21

a) Purpose
Verify that a VBS (GID 202) originator get a notification about an incoming REC (GID 299). This
should be verified in different networks (roaming).




Network A Network B

MS_A1 (REC GID: 299
MS_A3 (REC GID:
299,
VBS GID: 202, 203)
MS_B3 (REC GID:
299,
VBS GID: 202, 203)
MS_B1 (REC GID: 299
MS_A2 (REC GID: 299
MS_B4 (REC GID:
299,
VBS GID: 202, 203)
MS_A4 (REC GID:
299,
VBS GID: 202, 203)
MS_B2 (REC GID: 299

c) Test procedure


GCA_AB1, VBS GID: 202 Prio 3,
GID: 203 Prio 4




1)
Service subscriber MS_B4 originates a
VBS call (GID 202).
cell_B1.
2)
VBS call (GID 202).
3)
REC (GID 299).
cally.
4)
MS_A2, MS_A3, MS_A4, MS_B1,
5)
MS_B4 automatically accepts the incom-
allocated.


6)
of MS_A1.
7)
MS_A1 releases the uplink. Uplink free message is send in cell_A1,
correctly released.
8)
of MS_A1.
9)
correctly released.
10)
MS_B4 takes the uplink on GCCH. MS_B4 has two-way voice path. MS_A1,
of MS_B4.
11)
MS_B4 releases the uplink. Uplink free message is send in cell_A1,
correctly released.
12)
13)

VBS call (GID 202).
cell_B1.
VBS call (GID 202).


REC (GID 299).
cally.
allocated.
of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_B4.
correctly released.



VBS call (GID 202).
cell_A2.
VBS call (GID 202).
REC (GID 299).
cally.


allocated.
of MS_A1.
correctly released.
of MS_A1.
correctly released.
of MS_A4.
correctly released.

VBS call (GID 202).
cell_A2.


VBS call (GID 202).
REC (GID 299).
cally.
allocated.
of MS_B1.
correctly released.
of MS_B1.
correctly released.


of MS_A4.
correctly released.



Network A Network B

MS_A1 (REC GID: 299
MS_A3 (REC GID:
299,
VBS GID: 202, 203)
MS_B3 (REC GID:
299,
VBS GID: 202, 203)
MS_B1 (REC GID: 299
MS_A2 (REC GID: 299
MS_B4 (REC GID:
299,
VBS GID: 202, 203)
MS_A4 (REC GID:
299,
VBS GID: 202, 203)
MS_B2 (REC GID: 299

Test procedure


GCA_AB1, VBS GID: 202 Prio 3,
GID: 203 Prio 4




1)
VBS call (GID 202).
cell_B1.
2)
VBS call (GID 202).
3)
REC (GID 299).
cally.
4)
5)
MS_B4 automatically accepts the incom-
allocated.


6)
of MS_A1.
7)
correctly released.
8)
of MS_A1.
9)
correctly released.
10)
MS_B4 takes the uplink on GCCH. MS_B4 has two-way voice path. MS_A1,
of MS_B4.
11)
MS_B4 releases the uplink. Uplink free message is send in cell_A1,
correctly released.
12)
13)

VBS call (GID 202).
cell_B1.
VBS call (GID 202).


REC (GID 299).
cally.
allocated.
of MS_B1.
correctly released.
of MS_B1.
correctly released.
of MS_B4.
correctly released.



VBS call (GID 202).
cell_A2.
VBS call (GID 202).
REC (GID 299).
cally.


allocated.
of MS_A1.
correctly released.
of MS_A1.
correctly released.
of MS_A4.
correctly released.

VBS call (GID 202).
cell_A2.


VBS call (GID 202).
REC (GID 299).
cally.
allocated.
of MS_B1.
correctly released.
of MS_B1.
correctly released.


of MS_A4.
correctly released.

d) Success criteria
The VBS (GID 202) originator is able to receive notification about an incoming REC call (GID 299)
and will be pre-empted.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.36 Multiple VBS membership (non roaming case)


2.2.9

a) Purpose
Verify that a service subscriber can be a member of multiple VBS calls (GID 201, GID 202).


Network A

MS_A1 (VBS GID: 202, 203)
MS_A2 (VBS GID: 202, 203)
MS_A3 (VBS GID: 202, 203)
MS_A4 (VBS GID: 202, 203)

c) Test procedure
CoO=Cell_A1

203 Prio 4



VBS call (GID 202).
202).
VBS call (GID 202).
3) MS_A2 leaves the ongoing VBS call
(GID 202).
MS_A2 is able to leave VBS call (GID 202).
VBS call (GID 203).
MS_A1, MS_A3 and MS_A4 receive an in-
incoming VBS call (GID 203). MS_A1, MS_A3
and MS_A4 advertise the incoming VBS call
5) MS_A3 joins the VBS (GID 203). MS_A3 is able to join the VBS (GID 203).
MS_A2 has two-way voice path. MS_A3 is
allocated.
7) MS_A2 and MS_A3 rejoin the VBS call
(GID 202).
MS_A1 has two-way voice path. MS_A2. MS_A3
and MS_A4 are able to listen to the announcement
of MS_A1.

d) Success criteria
A service subscriber can join multiple VBS calls (GID 202, GID 203).



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.9.37 Multiple VBS membership (roaming case)


2.2.9

a) Purpose
Verify that a service subscriber can be a member of multiple VBS calls (GID 202, GID 203). This
should be verified in different networks (roaming).

network B in VPLMN leaves ongoing VBS and originates second VBS call (MSC_A1 anchor).
network A in HPLMN leaves ongoing VBS and originates second VBS call (MSC_A1 anchor).
network A in VPLMN leaves ongoing VBS and originates second VBS call (MSC_A1 anchor).
network B in HPLMN leaves ongoing VBS and originates second VBS call (MSC_A1 anchor).
network B in VPLMN leaves ongoing VBS and originates second VBS call (MSC_B1 anchor).
network A in HPLMN leaves ongoing VBS and originates second VBS call (MSC_B1 anchor).
network A in VPLMN leaves ongoing VBS and originates second VBS call (MSC_B1 anchor).
network B in HPLMN leaves ongoing VBS and originates second VBS call (MSC_B1 anchor).



Network A Network B

A-MSC_A1 R-MSC_B1

c) Test procedure

scriber of network B in VPLMN leaves ongoing VBS and originates second VBS call
(MSC_A1 anchor)
1)
VBS call (GID 202).
cell_B1.



2)
202).
MS_B3 and MS_B4 are joining the VBS call
(GID 202).
of MS_A1.
3)
MS_B3 leaves the ongoing VBS call
(GID 202).
MS_B3 is able to leave VBS call (GID 202).
4)
VBS call (GID 203).
cell_B1.
and MS_B1 advertise the incoming VBS call
5) MS_A3 and MS_B1 automatically accept
the incoming VBS call (GID 203) if the
priority of the VBS call (GID 203) is
higher or equal than 3.
MS_A3 and MS_B1 are able to join the VBS
(GID 203).
MS_B3 has two-way voice path. MS_A3 and
of MS_B3.
6)
allocated.
7)
MS_A3, MS_B1 and MS_B3 rejoin the
VBS call (GID 202).
of MS_A1.
8)


scriber of network A in HPLMN leaves ongoing VBS and originates second VBS call
(MSC_A1 anchor)
1)
VBS call (GID 202).
cell_B1.
2)
MS_A1, MS_A2, MS_A3, MS_A4,
202).
(GID 202).
of MS_B3.
3)
MS_A1 leaves the ongoing VBS call
(GID 202).
4)
VBS call (GID 203).
cell_B1.
incoming VBS call (GID 203). MS_A3, MS_B1
(GID 203).
of MS_A1.
6)
MS_A1 releases the VBS call (GID 203). The VBS call (GID 203) is released success-
allocated.


7)
MS_A1, MS_A3 and MS_B1 rejoin the
VBS call (GID 202).
of MS_B3.
8)

scriber of network A in VPLMN leaves ongoing VBS and originates second VBS call
(MSC_A1 anchor)
VBS call (GID 202).
cell_A1.
202).
(GID 202).
of MS_B1.
(GID 202).
VBS call (GID 203).
cell_A1.


(GID 203).
of MS_A3.
allocated.
7) MS_A1, MS_A3 and MS_B3 rejoin the
VBS call (GID 202).
of MS_B1.

scriber of network B in HPLMN leaves ongoing VBS and originates second VBS call
(MSC_A1 anchor)
1)
VBS call (GID 202).
cell_A1.
2)
202).
(GID 202).
of MS_A3.
3)
(GID 202).


4)
VBS call (GID 203).
cell_A1.
(GID 203).
of MS_B1.
6)
allocated.
7)
VBS call (GID 202).
of MS_A3.
8)



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

scriber of network B in VPLMN leaves ongoing VBS and originates second VBS call
(MSC_B1 anchor)
1)
VBS call (GID 202).
cell_B1.



2)
202).
(GID 202).
of MS_A1.
3)
(GID 202).
4)
VBS call (GID 203).
cell_B1.
(GID 203).
of MS_B3.
6)
allocated.
7)
VBS call (GID 202).
of MS_A1.
8)


scriber of network A in HPLMN leaves ongoing VBS and originates second VBS call
(MSC_B1 anchor)
1)
VBS call (GID 202).
cell_B1.
2)
MS_A1, MS_A2, MS_A3, MS_A4,
202).
(GID 202).
of MS_B3.
3)
MS_A1 leaves the ongoing VBS call
(GID 202).
4)
VBS call (GID 203).
cell_B1.
(GID 203).
of MS_A1.
6)
MS_A1 releases the VBS call (GID 203). The VBS call (GID 203) is released success-
allocated.


7)
MS_A1, MS_A3 and MS_B1 rejoin the
VBS call (GID 202).
of MS_B3.
8)

scriber of network A in VPLMN leaves ongoing VBS and originates second VBS call
(MSC_B1 anchor)
VBS call (GID 202).
cell_A1.
202).
(GID 202).
of MS_B1.
(GID 202).
VBS call (GID 203).
cell_A1.


(GID 203).
of MS_A3.
allocated.
7) MS_A1, MS_A3 and MS_B3 rejoin the
VBS call (GID 202).
of MS_B1.

scriber of network B in HPLMN leaves ongoing VBS and originates second VBS call
(MSC_B1 anchor)
1)
VBS call (GID 202).
cell_A1.
2)
202).
(GID 202).
of MS_A3.
3)
(GID 202).


4)
VBS call (GID 203).
cell_A1.
(GID 203).
of MS_B1.
6)
allocated.
7)
VBS call (GID 202).
of MS_A3.
8)

d) Success criteria
A service subscriber can join multiple VGCS calls (GID 200, GID 202) in different networks.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10 Cell Reselection and Handover
General reference for this chapter is the EN 301515, for handover in detail the ETSI TS 100 940.
Although cell reselection is mainly performed by the mobile station, cell reselection relays on the
correct support of the EIRENE network. This aspect is the focus of the cell reselection test cases.
References for cell reselection are in addition the ETSI TS 100 930, ETSI EN 300 908 and ETSI
EN 300 911.

5.10.1 Intra BTS cell reselection in idle mode


EN 301515

a) Purpose
Verify that intra BTS cell reselection in idle mode is successfully performed.


Network A

Cell_A1
MS_A1


c) Test procedure

1) MS_A1 moves in idle mode to cell_A2. Cell reselection successfully performed.
The mobile camps onto the BCCH of the desti-
nation cell.

d) Success criteria
Cell reselection of MS_A1 in idle mode has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.2 Intra BTS cell reselection of a VBS listener


EN 301515

a) Purpose
Verify that an intra BTS cell reselection of a VBS listener has been performed successfully.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID:202) MS_A2 (VBS GID:202)

c) Test procedure
CoO=Cell_A1




VBS call.
whole VBS call.
call.
2) MS_A2 accepts the incoming VBS call. MS_A2 joins the VBS call. MS_A1 has two-
way voice path. MS_A2 is only listener.
3) MS_A2 moves from cell_A2 to cell_A1. Cell reselection has been performed. MS_A2
camps onto the BCCH of the destination cell.
The call stays connected.
4) MS_A1 releases the call. The call is released and all resources are cor-

d) Success criteria
An intra BTS cell reselection of a VBS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.3 Intra BTS cell reselection of a VGCS listener


EN 301515

a) Purpose
Verify that an intra BTS cell reselection of a VGCS listener is successfully performed.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID:200) MS_A2 (VGCS GID:200)

c) Test procedure
CoO=Cell_A1




VGCS call.
call.
So long the dedicated channel is not released;
2) MS_A2 accepts the incoming VGCS call. MS_A2 joins the VGCS call.
channel).
has two-way voice path. MS_A2 is only lis-
tener.

d) Success criteria
An intra BTS cell reselection of a VGCS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.4 Intra BTS cell reselection of a REC listener

EIRENE FRS V7 EIRENE SRS V15 Other
Reference to

EN 301515

a) Purpose
Verify that an intra BTS cell reselection of a REC listener is successfully performed.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




1) MS_A1 originates a REC. REC is correctly established.
cell_A2.
MS_A2 is notified about the incoming REC on
the NCH.
2) MS_A2 automatically accepts the REC. MS_A2 automatically joins the REC in group
receive mode.
3) MS_A1 keeps the uplink on the dedi-
cated channel (DCH).
MS_A1 is able to keep the uplink on the dedi-
cated channel. MS_A1 has two-way voice
path. MS_A2 is only listener.
5) MS_A1 releases the uplink.
The uplink is correctly released.
6) MS_A1 releases the REC. The call is released and all resources are cor-

d) Success criteria
An intra BTS cell reselection of a REC listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.5 Inter BTS cell reselection in idle mode


EN 301515

a) Purpose
Verify that inter BTS cell reselection in idle mode is successfully performed.


Network A

Cell_A1
MS_A1

c) Test procedure

1) MS_A1 moves in idle mode to cell_A2 Cell reselection successfully performed.
The mobile camps onto the BCCH of the desti-
nation cell.

d) Success criteria
An inter BTS cell reselection in idle mode has been successfully performed.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.6 Inter BTS cell reselection of a VBS listener


EN 301515

a) Purpose
Verify that an inter BTS cell reselection of a VBS listener is successfully performed.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VBS call.
whole VBS call.
call.

d) Success criteria
An inter BTS cell reselection of a VBS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.7 Inter BTS cell reselection of a VGCS listener


EN 301515

a) Purpose
Verify that an inter BTS cell reselection of a VGCS listener is successfully performed.


Network A

Cell_A1 Cell_A2
MS_A1 (VGCS GID:200) MS_A2 (VGCS GID:200)

c) Test procedure
CoO=Cell_A1




VGCS call.
A GCCH is allocated in cell_A2. MS_A2 re-
ceives notification of the incoming call.
2) MS_A2 accepts the incoming VGCS call. MS_A2 joins the VGCS call. MS_A1 has two-
channel.
MS_A1 takes the uplink on the group channel.
listener.

d) Success criteria
An inter BTS cell reselection of a VGCS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.8 Inter BTS cell reselection of a REC listener


EN 301515

a) Purpose
Verify that an inter BTS cell reselection of a REC listener is successfully performed.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
the NCH.
receive mode.

d) Success criteria
An inter BTS cell reselection of a REC listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.9 Inter BSC cell reselection in idle mode


EN 301515

a) Purpose
Verify that inter BSC cell reselection in idle mode is successfully performed.


Network A

Cell_A1
MS_A1

c) Test procedure

Location Update has been done.
MS_A1 camps onto the BCCH of the destina-
tion cell.
Location Update has been done.
MS_A1 camps onto the BCCH of the destina-
tion cell.


d) Success criteria
An inter BSC cell reselection in idle mode has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)



5.10.10 Inter BSC cell reselection of a VBS listener


EN 301515

a) Purpose
Verify that an inter BCS cell reselection of a VBS listener is successfully performed.


Network A

Cell_A1 Cell_A2
MS_A1 (VBS GID:202) MS_A2 (VBS GID:202)

c) Test procedure
CoO=Cell_A1




VBS call.
whole VBS call.
call.
camps onto the BCCH of the destination cell
and location update has been performed. The
call stays connected.
camps onto the BCCH of the destination cell
and location update has been performed. The
call stays connected.

d) Success criteria
An inter BSC cell reselection of a VBS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.11 Inter BSC cell reselection of a VGCS listener


EN 301515

a) Purpose
Verify that an inter BCS cell reselection of a VGCS listener is successfully performed.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




VGCS call.
call.
2) MS_A2 accepts the incoming VGCS call. MS_A2 joins the VGCS call.
channel.
MS_A1 takes the uplink on the group channel.
listener.
Location update has been performed. The call
stays connected.
Location update has been performed. The call
stays connected.

d) Success criteria
An inter BSC cell reselection of a VGCS listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.12 Inter BSC cell reselection of a REC listener


EN 301515

a) Purpose
Verify that an inter BCS cell reselection of a REC listener is successfully performed.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
the NCH.
receive mode.
Location update has been done. The call stays
connected.
Location update has been done. The call stays
connected.

d) Success criteria
An inter BSC cell reselection of a REC listener has been performed successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.13 Inter MSC reselection of a VBS listener


EN 301515

a) Purpose
Verify that an inter MSC reselection of a VBS listener is successfully performed.


Test configuration for steps 1 and 2

Network A Network B

A-MSC_A1 R-MSC_B1




c) Test procedure

Step Action
Expected result(s)
VBS call.
whole VBS call.
MS_A2, MS_A3, MS_B1, MS_B2 and MS_B3
receive notification of the incoming call.
2) MS_A2, MS_A3, MS_B1, MS_B2 and
MS_B3 accept the incoming VBS call.
join the VBS call. MS_A1 has two-way voice
path. MS_A2, MS_A3, MS_B1, MS_B2 and
MS_B3 are only listeners.
3) MS_B1 moves from cell_B1 to cell_A1. Network reselection has been performed.
MS_B1 receives the notification on the NCH
about the VBS call and rejoins it.
4) MS_B1 moves back to cell_B1. Network reselection has been performed
again.
5) MS_A2 moves from cell_B1 to cell_A1. Network reselection has been performed.
MS_A2 receives the notification on the NCH
6) MS_A2 moves back to cell_B1. Network reselection has been performed
again.
7) MS_B2 moves from cell_A1 to cell_B1. Network reselection has been performed.
8) MS_B2 moves back to cell_A1. Network reselection has been performed
again.
9) MS_A3 moves from cell_A1 to cell_B1. Network reselection has been performed.
10) MS_A3 moves back to cell_A1. Network reselection has been performed
again.


VBS call.
whole VBS call.
MS_A1, MS_A2, MS_A3, MS_B2 and MS_B3
2) MS_A1, MS_A2, MS_A3, MS_B2 and
join the VBS call. MS_B1 has two-way voice
path. MS_A1, MS_A2, MS_A3, MS_B2 and
MS_B3 are only listener.
again.
again.
again.
again.
11) MS_B1 releases the call. The call is released and all resources are cor-




Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

VBS call.
whole VBS call.
join the VBS call. MS_A1 has two-way voice
path. MS_A2, MS_A3, MS_B1, MS_B2 and
MS_B3 are only listeners.



again.
again.
again.
again.

VBS call.
whole VBS call.
join the VBS call. MS_B1 has two-way voice
path. MS_A1, MS_A2, MS_A3, MS_B2 and
MS_B3 are only listener.


again.
again.
again.
again.

d) Success criteria
An inter MSC reselection of a VBS listener is successfully performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.14 Inter MSC reselection of a VGCS listener


EN 301515

a) Purpose
Verify that an inter MSC reselection of a VGCS listener is successfully performed.

Step 1: VGCS call establishment in anchor MSC_A1.
Step 2: VGCS call establishment in relay MSC_B1.
Step 3: VGCS call establishment in relay MSC_A1.
Step 4: VGCS call establishment in anchor MSC_B1.


Network A Network B

A-MSC_A1 R-MSC_B1




c) Test procedure

Step Action
Expected result(s)
VGCS call.
MS_B3 accept the incoming VGCS call.
join the VGCS call.
MS_A3, MS_B1, MS_B2 and MS_B3 are only
listeners.
about the VGCS call and rejoins it.
again.
again.
again.
again.


Step 2: VGCS call establishment in relay MSC_B1.
Step Action
Expected result(s)
VGCS call.
MS_B1 has two way voice path.
join the VGCS call.
MS_A2, MS_A3, MS_B2 and MS_B3 are only
listeners.
again.
again.
again.
again.



Network A Network B

R-MSC_A1 A-MSC_B1

Test procedure

VGCS call.
join the VGCS call.
MS_A3, MS_B1, MS_B2 and MS_B3 are only
listeners.



again.
again.
again.
again.

Step 4: VGCS call establishment in anchor MSC_B1.
VGCS call.
MS_B1 has two way voice path.
join the VGCS call.
MS_A2, MS_A3, MS_B2 and MS_B3 are only
listeners.


again.
again.
again.
again.

d) Success criteria
An inter MSC reselection of a VGCS listener is successfully performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.15 Intra BTS handover of a point to point voice call


EN 301515

a) Purpose
Verify that the originator of a PTP voice call can perform an intra BTS handover successfully.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure

1) MS_A1 establishes a PTP call to MS_A2. The PTP call is successfully established.
2) MS_A1 moves from cell_A1 to cell_A2. MS_A1 performs a handover from cell_A1 to
cell_A2.
3) MS_A1 releases the call. PTP call successfully released and all re-
sources are de-allocated correctly.



d) Success criteria
The originator of a PTP voice call performs an intra BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.16 Intra BTS handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
Verify that the originator of a PTP data call can perform an intra BTS handover successfully.




Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure
A subset of the mandatory data services will be used for the handover test.



Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4

bearer services refer to Annex - Con-
figuration of User Equipment for Data
Calls
by dialling:
ATD <MSISDN>
played on MS_A2.
successfully established with the correct
bearer service and line speed. These are seen
on messages:
From BSC to BTS: Channel activation.
From BTS to BSC and from BSC to MSC: Call
confirmed.
4) Send test data from MS_A1 to MS_A2
and from MS_A2 to MS_A1.
Test data is transmitted and received correctly.
cell_A2.
7) MS_A1 releases the call. Data call is successfully released and all re-
table above.


d) Success criteria
The originator of a PTP data call performs an intra BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.17 Intra BTS handover of a railway emergency call originator


EN 301515

a) Purpose
Verify that the originator of a Railway Emergency Call (REC) can perform an intra BTS handover
successfully on the dedicated channel as well as on the group call channel.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
the NCH.
receive mode.
4) MS_A1 moves from cell_A1 to cell_A2. Intra BTS handover successfully performed.
MS_A1 has still two-way voice path. MS_A2 is
only listener.
only listener.
6) MS_A1 releases the uplink on DCH.
7) MS_A1 requests the uplink on GCCH. MS_A1 takes the uplink (GCCH). MS_A1 has
two-way voice path. MS-A2 is only listener.
only listener.
only listener.
11) MS_A1 releases the REC. REC is released and all resources are correctly
de-allocated.

d) Success criteria
The originator of a Railway Emergency Call (REC) performs an intra BTS handover successfully
on the dedicated channel as well as on the group call channel.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.18 Intra BTS handover of a VGCS call uplink


EN 301515

a) Purpose
Verify that the subsequent talker of a VGCS call can perform an intra BTS handover successfully.


Network A

Cell_A1 Cell_A2

c) Test procedure

CoO=Cell_A1



1) MS_A1 originates a VGCS call and
keeps the uplink on the dedicated chan-
nel (DCH)
cell_A2.
call.
2) MS_A2 accepts the VGCS call. MS_A2 joins the VGCS call and is in listening
mode. MS_A1 has two-way voice path.
3) MS_A1 releases the uplink. The DCH in cell_A1 is released after MS_A1
releases the uplink. Uplink free is sent to all
cells of the GCA.
4) MS_A2 requests the uplink on the
GCCH.
MS_A2 is able to take the uplink and has a
5) MS_A2 moves from cell_A2 to cell_A1 An intra BTS handover is successfully per-
formed. MS_A2 has still two-way voice path.
MS_A1 is still listener.
6) MS_A2 releases the uplink on GCCH.
7) MS_A1 in cell_A1 requests the uplink on
GCCH.
MS_A1 is able to take the uplink and has two-
way voice path. MS_A2 is only listener
9) MS_A1 releases the VGCS call. VGCS call is released and all resources are

d) Success criteria
The subsequent talker of a VGCS call performs an intra BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.19 Intra BTS handover of a VGCS dedicated channel


EN 301515

a) Purpose
Verify that the originator of a VGCS call (on the dedicated channel) can perform an intra BTS
handover successfully.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
call.
2) MS_A2 accepts the VGCS call.
MS_A2 joins the VGCS call.
3) MS_A1 keeps the uplink on DCH. MS_A1 is able to take the uplink on DCH and
has two-way voice path. MS_A2 is only lis-
tener.
cell_A2. The VGCS call stays connected.
only listener.

d) Success criteria
The originator of a VGCS call (on the dedicated channel) performs an intra BTS handover suc-
cessfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.20 Intra BTS handover of a VBS originator


EN 301515

a) Purpose
Verify that the originator of a VBS call performed an intra BTS handover successfully.

b) Test configuration / initial conditions.

Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




1) MS_A1 originates a VBS call. VBS call is correctly established.
cell_A2.
whole VBS call.
MS_A2 is notified about the incoming VBS call.
2) MS_A2 accepts the VBS call. MS_A2 joins the VBS call and is listener.
cell_A2. The VBS call stays connected.
only listener.
4) MS_A1 releases the VBS call. VBS call is released and all resources are cor-

d) Success criteria
The originator of a VBS call performs an intra BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.21 Inter BTS handover of a point to point voice call


EN 301515

a) Purpose
Verify that the originator of a PTP voice call can perform an inter BTS handover successfully.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure

2) MS_A1 moves from cell_A1 to cell_A2. MS_A1 performs an inter BTS handover from
cell_A1 to cell_A2.
3) MS_A1 releases the call. PTP call is successfully released and all re-



d) Success criteria
The originator of a PTP voice call performs an inter BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.22 Inter BTS handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
Verify that the originator of a PTP data call can perform an inter BTS handover successfully.




Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure



Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4

Calls
by dialling:
ATD <MSISDN>
played on MS_A2.
on messages:
confirmed.
cell_A2.
table above.



d) Success criteria
The originator of a PTP data call performs an inter BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.23 Inter BTS handover of a railway emergency call originator


EN 301515

a) Purpose
Verify that the originator of a Railway Emergency Call (REC) can perform an inter BTS handover


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
the NCH.
receive mode.
4) MS_A1 moves from cell_A1 to cell_A2. Inter BTS handover successfully performed.
only listener.
only listener.
only listener.
only listener.
de-allocated.

d) Success criteria
The originator of a Railway Emergency Call (REC) performs an inter BTS handover successfully



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.24 Inter BTS handover of a VGCS call uplink


EN 301515

a) Purpose
Verify that the subsequent talker of a VGCS call can perform an inter BTS handover successfully.


Network A

Cell_A1 Cell_A2

c) Test procedure

CoO=Cell_A1




cell_A2.
call.
mode.
3) MS_A1 keeps the uplink on the DCH. MS_A1 is able to keep the uplink. MS_A1 has
two-way voice path. MS_A2 is listener.
4) MS_A1 releases the uplink. The DCH in cell_A1 is released. Uplink free is
sent to all cells of the GCA.
5) MS_A2 in cell_A2 takes the uplink on the
GCCH.
two-way-voice path. MS_A1 is only listener.
6) MS_A2 moves from cell_A2 to cell_A1. An inter BTS handover is successfully per-
formed. MS_A2 has still two-way voice path.
The uplink is released.
8) MS_A1 in cell_A1 takes the uplink. MS_A1 is able to take the uplink and has two-
way voice path. MS_A2 is listener.

d) Success criteria
The subsequent talker of a VGCS call performs an inter BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.25 Inter BTS handover of a VGCS dedicated channel


EN 301515

a) Purpose
Verify that the originator of a VGCS call (on the dedicated channel) can perform an inter BTS


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
call.
3) MS_A1 keeps the uplink on the DCH. MS_A1 has two-way voice path. MS_A2 is only
listener.
MS_A1 has still two-way voice path.

d) Success criteria
The originator of a VGCS call (on the dedicated channel) can perform an inter BTS handover
successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.26 Inter BTS handover of a VBS originator


EN 301515

a) Purpose
Verity that the originator of a VBS call can perform an inter BTS handover successfully.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
whole VBS call.
MS_A2 is notified about the incoming VBS call.
only listener.

d) Success criteria
The originator of a VBS call performs an inter BTS handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.27 Inter BSC handover of a point to point voice call


EN 301515

a) Purpose
Verify that the originator of a PTP voice call can perform an inter BSC handover successfully.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure

cell_A2.
cell_A1.


d) Success criteria
The originator of a PTP voice call performs an inter BSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.28 Inter BSC handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
Verify that the originator of a PTP data call can perform an inter BSC handover successfully.




Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure




Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4

Calls
by dialling:
ATD <MSISDN>
played on MS_A2.
on messages:
confirmed.
cell_A2.
cell_A1.


table above.

d) Success criteria
The originator of a PTP data call performs an inter BSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.29 Inter BSC handover of a railway emergency call originator


EN 301515

a) Purpose
Verify that the originator of a Railway Emergency Call (REC) can perform an inter BSC handover


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
the NCH.
receive mode.
4) MS_A1 moves from cell_A1 to cell_A2. Handover successfully performed. MS_A1 has
still two-way voice path. MS_A2 is only lis-
tener.
tener.
tener.
tener.
de-allocated.

d) Success criteria
The originator of a Railway Emergency Call (REC) performs an inter BSC handover successfully



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.30 Inter BSC handover of a VGCS call uplink


EN 301515

a) Purpose
Verify that the subsequent talker of a VGCS call can perform an inter BSC handover successfully.


Network A

Cell_A1 Cell_A1

c) Test procedure
CoO=Cell_A1




cell_A2.
on the NCH.
mode. MS_A1 has two-way voice path.
3) MS_A1 releases the uplink. The DCH in cell_A1 is released after MS_A1
releases the uplink. Uplink free is sent to all
cells of the GCA.
4) MS_A2 in cell_A2 takes the uplink on the
GCCH.
two-way-voice path. MS_A1 is only listener.
5) MS_A2 moves from cell_A2 to cell_A1. An inter BSC handover is successfully per-
formed MS_A2 has still two-way voice path.
6) MS_A2 moves from cell_A1 to cell_A2. An inter BSC handover is successfully per-
formed MS_A2 has still two-way voice path.
8) MS_A1 in cell_A1 takes the uplink. MS_A1 is able to take the uplink and has two-

d) Success criteria
Verify that the subsequent talker of a VGCS call can perform an inter BSC handover successfully.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.31 Inter BSC handover of a VGCS dedicated channel


EN 301515

a) Purpose
Verify that the originator of a VGCS call (on the dedicated channel) can perform an inter BSC


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




cell_A2.
call on the NCH.
3) MS_A1 keeps the uplink on the DCH. MS_A1 has two-way voice path. MS_A2 is
listener.
still listener.
still listener.

d) Success criteria
The originator of a VGCS call (on the dedicated channel) can perform an inter BSC handover
successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.32 Inter BSC handover of a VBS originator


EN 301515

a) Purpose
Verity that the originator of a VBS call can perform an inter BSC handover successfully.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1

GCA_A1, VBS GID: 202, Prio 3



cell_A2.
whole VBS call.
MS_A2 is notified about the incoming VBS on
the NCH.
still listener.
still listener.

d) Success criteria
The originator of a VBS call performs an inter BSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.33 Inter MSC handover of a point to point voice call


EN 301515

a) Purpose
Verify that the originator of a PTP voice call can perform an inter MSC handover successfully.


Network A

MSC_A1 MSC_A2
MS_A1 MS_A2

c) Test procedure

cell_A2.
3) MS_A1 moves back to cell_A1. MS_A1 performs a handover from cell_A2 to
cell_A1.


cell_A1.
7) MS_A2 moves back to cell_A2. MS_A2 performs a handover from cell_A1 to
cell_A2.

d) Success criteria
The originator of a PTP voice call performs an inter MSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.34 Inter MSC handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
Verify that the originator of a PTP data call can perform an inter MSC handover successfully.




Step 1: Data call establishment in MSC_A1.



Network A

MSC_A1 MSC_ A2
MS_A1 MS_A2

c) Test procedure

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4

1) Configure MS_A1and MS_A2 to perform
Calls
2) MS_A1 establishes a data call to MS_ A2
by dialling:
ATD <MSISDN>
MS_ A2 is notified of the incoming data call
played on MS_ A2.


3) MS_ A2 takes the data call. The data call between MS_A1 and MS_ A2 is
on messages:
From BTS to BSC and from BSC to MSC: `Call
confirmed.
4) Send test data from MS_A1 to MS_ A2
and from MS_ A2 to MS_A1.
5) MS_A1 moves from cell_A1 to cell_ A2. MS_A1 performs a handover from cell_A1 to
cell_ A2.
7) MS_A1 moves back to cell_A1. MS_A1 performs a handover from cell_ A2 to
cell_A1.
table above.

Calls
by dialling:
ATD <MSISDN>
from MS_ A2. The MSISDN of MS_ A2 is dis-
played on MS_A1.
3) MS_A1 takes the data call. The data call between MS_A1 and MS_ A2 is
on messages:
confirmed.


4) Send test data from MS_ A2 to MS_A1
and from MS_A1 to MS_ A2.
5) MS_ A2 moves from cell_ A2 to cell_A1. MS_ A2 performs a handover from cell_ A2 to
cell_A1.
7) MS_ A2 moves back to cell_ A2. MS_ A2 performs a handover from cell_A1 to
cell_ A2.
9) MS_ A2 releases the call. Data call is successfully released and all re-
table above

d) Success criteria
The originator of a PTP data call can perform an inter MSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.35 Inter MSC handover of a railway emergency call originator


EN 301515

a) Purpose
Verify that the originator of a Railway Emergency Call (REC) can perform an inter MSC handover

Step 1: REC establishment in anchor MSC_A1.
Step 2: REC establishment in relay MSC_A2.
Step 4: REC establishment in anchor MSC_ A2.

Steps 3 and 4 only applicable in case MSC_A1 and MSC_A2 are from different vendors.


Network A

A-MSC_A1 R-MSC_ A2





c) Test procedure

cell_ A2.
MS_ A2 is notified about the incoming REC on
the NCH.
receive mode.
4) MS_A1 moves from cell_A1 to cell_ A2. Handover successfully performed. MS_A1 has
still two-way voice path. MS_A2 is only listener
5) MS_A1 moves back to cell_A1. Handover successfully performed. MS_A1 has
6) MS_A1 releases the uplink on DCH. The uplink is correctly released.
de-allocated.



Step 2: REC establishment in relay MSC_ A2.
channel (GCCH) are allocated in cell_ A2.
cell_A1.
the NCH.
MS_ A2 has two way voice path.
receive mode.
3) MS_ A2 keeps the uplink on the dedi-
MS_ A2 is able to keep the uplink on the dedi-
cated channel. MS_ A2 has two-way voice
4) MS_ A2 moves from cell_ A2 to cell_A1. Handover successfully performed. MS_ A2
has still two-way voice path. MS_A1 is only
listener.
5) MS_ A2 moves back to cell_ A2. Handover successfully performed. MS_ A2
listener.
6) MS_ A2 releases the uplink on DCH. The uplink is correctly released.
7) MS_ A2 requests the uplink on GCCH. MS_ A2 takes the uplink (GCCH). MS_A2 has
listener.
listener.
10) MS_ A2 releases the uplink. The uplink is correctly released.
11) MS_ A2 releases the REC. REC is released and all resources are correctly
de-allocated.




Network A

R-MSC_A1 A-MSC_ A2

Test procedure

cell_ A2.
MS_ A2 is notified about the incoming REC on
the NCH.
receive mode.



6) MS_A1 releases the uplink on DCH. The uplink is correctly released.
de-allocated.

Step Action
Expected result(s)
cell_A1.
the NCH.
MS_ A2 has two way voice path.
receive mode.
3) MS_ A2 keeps the uplink on the dedi-
MS_ A2 is able to keep the uplink on the dedi-
cated channel. MS_ A2 has two-way voice
listener.
listener.
6) MS_ A2 releases the uplink on DCH. The uplink is correctly released.


7) MS_ A2 requests the uplink on GCCH. MS_ A2 takes the uplink (GCCH). MS_A2 has
listener.
listener.
11) MS_ A2 releases the REC. REC is released and all resources are correctly
de-allocated.

d) Success criteria
The originator of a Railway Emergency Call (REC) performs an inter MSC handover successfully

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.36 Inter MSC handover of a VGCS call uplink.


EN 301515

a) Purpose

Verify that the originator of a VGCS call can perform an inter MSC handover successfully on the
group call channel.

Step 4: VGCS call establishment in anchor MSC_ A2.




Network A

A-MSC_A1 R-MSC_B1

c) Test procedure

cell_ A2.
call on the NCH.
call.
MS_A2 automatically joins the VGCS call in
group receive mode.



tener.
tener.

Step 2: VGCS call establishment in relay MSC_ A2.
1) MS_ A2 originates a VGCS call. VGCS call is correctly established.
cell_A1.
call on the NCH.
MS_ A2 has two-way voice path.
call.
group receive mode.
3) MS_ A2 requests the uplink on GCCH. MS_ A2 takes the uplink (GCCH). MS_ A2 has
listener.
listener.
7) MS_ A2 releases the VGCS call. VGCS call is released and all resources are




Network A

R-MSC_A1 A-MSC_A2

Test procedure

cell_ A2.
call on the NCH.
call.
group receive mode.



tener.
tener.

Step Action
Expected result(s)
cell_A1.
call on the NCH.
call.
group receive mode.
3) MS_ A2 requests the uplink on GCCH. MS_ A2 takes the uplink (GCCH). MS_ A2 has
listener.
listener.

d) Success criteria
The originator of a VGCS call performs an inter MSC handover successfully on the group call
channel.


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.37 Inter MSC handover of a VGCS dedicated channel

EN 301515

a) Purpose
Verify that the originator of a VGCS call can perform an inter MSC handover successfully on the
dedicated channel.



Network A

A-MSC_A1 R-MSC_A2




c) Test procedure

cell_A2.
call on the NCH.
call.
group receive mode.
3) MS_A1 requests the uplink on DCH. MS_A1 takes the uplink (DCH). MS_A1 has

cell_A1.
call on the NCH.
call.
group receive mode.


3) MS_ A2 requests the uplink on DCH. MS_ A2 takes the uplink (DCH). MS_ A2 has
listener.
listener.


Network A

R-MSC_A1 A-MSC_A2

Test procedure




cell_A2.
call on the NCH.
call.
group receive mode.
3) MS_A1 requests the uplink on DCH. MS_A1 takes the uplink (DCH). MS_A1 has

cell_A1.
call on the NCH.
call.
group receive mode.
3) MS_ A2 requests the uplink on DCH. MS_ A2 takes the uplink (DCH). MS_ A2 has


listener.
listener.

d) Success criteria
The originator of a VGCS call performs an inter MSC handover successfully on the dedicated
channel.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.38 Inter MSC handover of a VBS originator

EN 301515

a) Purpose
Verify that the originator of a VBS call can perform an inter MSC handover successfully.



Network A

A-MSC_A1 R-MSC_A2





c) Test procedure

cell_A2.
whole VBS call.
MS_A2 is notified about the incoming VBS call
on the NCH.
2) MS_A2 automatically accepts the VBS
call.
MS_A2 automatically joins the VBS call in
group receive mode.
listener.
tener.
tener.

1) MS_ A2 originates a VBS call. VBS call is correctly established.
cell_A1.
whole VBS call.
on the NCH.


call.
group receive mode.
MS_ A2 has two-way voice path. MS_A1 is
only listener.
listener.
listener.
5) MS_ A2 releases the VBS call. VBS call is released and all resources are cor-


Network A

R-MSC_A1 A-MSC_A2

Test procedure




Step Action
Expected result(s)
cell_A2.
whole VBS call.
on the NCH.
call.
group receive mode.
listener.
tener.
tener.

1) MS_ A2 originates a VBS call. VBS call is correctly established.
cell_A1.
whole VBS call.
on the NCH.
call.
group receive mode.
MS_ A2 has two-way voice path. MS_A1 is
only listener.


listener.
listener.
5) MS_ A2 releases the VBS call. VBS call is released and all resources are cor-

d) Success criteria
The originator of a VBS call performs an inter MSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.39 Intra BTS handover failure of a point to point voice call (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
Verify that an ongoing point to point voice call in the destination cell is not pre-empted by an in-
coming intra BTS handover of a subscriber of another ongoing point to point voice call with the
same or lower priority with the result that no handover is performed.


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure


1) MS_A1 originates a PTP call to MS_A2
with priority 4.
The call is established correctly, there is a two-
way voice path between MS_A1 and MS_A2.
network.
request, Call Proceeding and Setup.
with priority 4.
network.
with priority 4.
network.
There is no traffic channel available in cell_A2.
with priority 4.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Intra BTS handover from cell_A1 to cell_A2 is
not performed because the priority of the in-
coming call is the same as the ongoing call.
The call stays connected until the mobile is out
of coverage of cell A1.
6) MS_A7 releases the call if not already
dropped.
PTP call is successfully released and all re-
7) Release all PTP calls in cell A2. PTP calls are successfully released and all



d) Success criteria
An ongoing point to point voice call in the destination cell is not pre-empted by an incoming intra
BTS handover of a subscriber of another ongoing point to point voice call with the same or lower
priority with the result that no handover is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.40 Intra BTS handover failure of a circuit switched data call (pre-emption Um-IF
not possible)

2.3.1 EN 301515

a) Purpose
coming intra BTS handover of a subscriber of another ongoing point to point data call with the






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure
A subset of the mandatory data services will be used for the test.

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4



4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A6.
network.
Calls
with priority 4 by dialling:
ATD<MSISDN>
played on MS_A8.
successfully established with the correct bea-
rer service and line speed. These are seen on
messages:
confirmed.
network.


9) MS_A7 releases the data call if not al-
ready dropped.
Data call successfully released and all re-
10) Release all PTP calls in cell_A2. PTP calls are successfully released and all
table above.

d) Success criteria
BTS handover of a subscriber of another ongoing point to point data call with the same or lower

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.41 Intra BTS Handover failure of a railway emergency originator (DCH) (pre-
emption Um-IF not possible)


EN 301515

a) Purpose
coming intra BTS handover of the originator (on dedicated channel) of an ongoing railway emer-
gency call with the same priority with the result that no handover is performed.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

Step Action
Expected result(s)
network.
network.
network.
Only 1 TCH is available in cell_A2.
cell_A2.
coming REC on the NCH.
No TCH is available in cell_A2.
5) MS_A8 and MS_A9 automatically accept
the REC.
MS_A8 and MS_A9 automatically join the REC
network.
The priority is seen on message: Notification
Command sent from the BSC.


Step Action
Expected result(s)
6) MS_A7 keeps the uplink on the DCH. MS_A7 is able to take the uplink on DCH.
MS_A9 are only listeners.
The DCH remains allocated until the mobile is
out of coverage of cell A1.
8) MS_A7 releases the uplink if not already
released.
9) MS_A7 releases the REC. REC is successfully released and all resources

d) Success criteria
BTS handover of the originator (on dedicated channel) of an ongoing railway emergency call with
the same priority with the result that no handover is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.42 Intra BTS Handover failure of a VGCS dedicated channel (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming intra BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

Step Action
Expected result(s)
network.
network.
network.
cell_A2.
coming VGCS call on the NCH.
the VGCS call.
MS_A8 and MS_A9 automatically join the
VGCS call in group receive mode.
network.


Step Action
Expected result(s)
released.
9) MS_A7 releases the VGCS call. VGCS call is successfully released and all re-

d) Success criteria
BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with the same

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.43 Intra BTS Handover failure of a VBS originator (pre-emption Um-IF not possi-
ble)


EN 301515

a) Purpose
coming intra BTS handover of the originator of an ongoing VBS call with the same priority with the
result that no handover is performed.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

network.
network.
network.
cell_A2.
whole VBS call.
coming VBS call on the NCH.
the VBS call.
MS_A8 and MS_A9 automatically join the VBS
call in group receive mode.
network.


The VBS call stays connected until the mobile
is out of coverage of cell A1.
7) MS_A7 releases the VBS call if not al-
ready released.
VBS call successfully released and all re-
sources de-allocated.

d) Success criteria
BTS handover of the originator of an ongoing VBS call with the same priority with the result that
no handover is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.44 Inter BTS handover failure of a point to point voice call (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming inter BTS handover of a subscriber of another ongoing point to point voice call with the


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure


Step Action
Expected result(s)
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Inter BTS handover from cell_A1 to cell_A2 is
dropped.

d) Success criteria
An ongoing point to point voice call in the destination cell is not pre-empted by an incoming inter
BTS handover of a subscriber of another ongoing point to point voice call with the same or lower


e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.45 Inter BTS handover failure of a circuit switched data call (pre-emption Um-IF
not possible)


2.3.1 EN 301515

a) Purpose
coming inter BTS handover of a subscriber of another ongoing point to point data call with the






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4



Step Action
Expected result(s)
4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A6.
network.
Calls
ATD<MSISDN>
played on MS_A8.
messages:
confirmed.
network.


Step Action
Expected result(s)
ready dropped.
table above.

d) Success criteria
BTS handover of a subscriber of another ongoing point to point data call with the same or lower

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.46 Inter BTS Handover failure of a railway emergency originator (DCH) (pre-


EN 301515

a) Purpose
coming inter BTS handover of the originator (on dedicated channel) of an ongoing railway emer-


Network A

Cell_A1 Cell_A2

CoO=Cell_A1




c) Test procedure

Step Action
Expected result(s)
network.
network.
network.
cell_A2.
the REC.
network.


Step Action
Expected result(s)
released.

d) Success criteria
BTS handover of the originator (on dedicated channel) of an ongoing railway emergency call with

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.47 Inter BTS Handover failure of a VGCS dedicated channel (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming inter BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




Step Action
Expected result(s)
network.
network.
network.
cell_A2.
the VGCS call.
network.


Step Action
Expected result(s)
released.

d) Success criteria
BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with the same

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.48 Inter BTS Handover failure of a VBS originator (pre-emption Um-IF not possi-
ble)


EN 301515

a) Purpose
coming inter BTS handover of the originator of an ongoing VBS call with the same priority with the
result that no handover is performed.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

network.
network.
network.
cell_A2.
whole VBS call.
the VBS call.
network.


ready released.

d) Success criteria
BTS handover of the originator of an ongoing VBS call with the same priority with the result that

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.49 Inter BSC handover failure of a point to point voice call (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming inter BSC handover of a subscriber of another ongoing point to point voice call with the


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure

Step Action
Expected result(s)


Step Action
Expected result(s)
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Inter BSC handover from cell_A1 to cell_A2 is
The BSC_A2 sends Handover Failure with
cause No radio resource available to the
MSC.
The MSC sends Handover Required Reject
to the BSC_A1.
dropped.
MS_A7 performs a normal location update
successfully.


Step Action
Expected result(s)

d) Success criteria
BSC handover of a subscriber of another ongoing point to point voice call with the same or lower

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.50 Inter BSC handover failure of a circuit switched data call (pre-emption Um-IF
not possible)


2.3.1 EN 301515

a) Purpose
coming inter BSC handover of a subscriber of an ongoing point to point data call with the same or
lower priority with the result that no handover is performed.






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure


Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4



Step Action
Expected result(s)
4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A6.
network.
Calls
ATD<MSISDN>
played on MS_A8.
messages:
confirmed.
network.


Step Action
Expected result(s)
MSC.
to the BSC_A1.
ready dropped.
successfully.
table above.

d) Success criteria
BSC handover of a subscriber of an ongoing point to point data call with the same or lower priority
with the result that no handover is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.51 Inter BSC Handover failure of a railway emergency originator (DCH) (pre-


EN 301515

a) Purpose
coming inter BSC handover of the originator (on dedicated channel) of an ongoing railway emer-


Network A

Cell_A1 Cell_A2

CoO=Cell_A1




c) Test procedure

Step Action
Expected result(s)
network.
network.
network.
cell_A2.
the REC.
network.


Step Action
Expected result(s)
MSC.
to the BSC_A1.
released.
successfully.

d) Success criteria
BSC handover of the originator (on dedicated channel) of an ongoing railway emergency call with

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.52 Inter BSC Handover failure of a VGCS dedicated channel (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming inter BSC handover of the originator (on dedicated channel) of an ongoing VGCS call with


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

Step Action
Expected result(s)
network.
network.
network.
cell_A2.
the VGCS call.
network.


Step Action
Expected result(s)
MSC.
to the BSC_A1.
released.
successfully.

d) Success criteria
BSC handover of the originator (on dedicated channel) of an ongoing VGCS call with the same

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.53 Inter BSC Handover failure of a VBS originator (pre-emption Um-IF not pos-
sible)


EN 301515

a) Purpose
coming inter BSC handover of the originator of an ongoing VBS call with the same priority with
the result that no handover is performed.


Network A

Cell_A1 Cell_A2

c) Test procedure

CoO=Cell_A1



network.
network.
network.
cell_A2.
whole VBS call.
the VBS call.
network.


MSC.
to the BSC_A1.
ready released.
successfully.

d) Success criteria
BSC handover of the originator of an ongoing VBS call with the same priority with the result that

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.54 Inter MSC handover failure of a point to point voice call (pre-emption Um-IF
not possible)


EN 301515

a) Purpose
coming inter MSC handover of a subscriber of another ongoing point to point voice call with the

Step 1: PTP call to be handovered is established in MSC_A1.
Step 2 only applicable in case MSC_A1 and MSC_A2 are from different vendors.


Network A

MSC_A1 MSC_A2
MS_A1 MS_A3
MS_A2 MS_A4
MS_A5
MS_A6
MS_A7
MS_A8


c) Test procedure

Step Action
Expected result(s)
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
5) MS_A1 moves from cell_A1 to cell_A2. Inter MSC handover from cell_A1 to cell_A2 is
MSC_A2.
The MSC_A1 sends Handover Required Re-
ject to the BSC_A1.
of coverage of cell_A1.


Step Action
Expected result(s)
dropped.
successfully.
7) Release all PTP calls in cell A2. PTP calls are successfully released and all re-


Network A

MSC_A1 MSC_A2
MS_A3 MS_A1
MS_A4 MS_A2
MS_A5
MS_A6
MS_A7
MS_A8



Test procedure

Step Action
Expected result(s)
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
MSC_A1.
ject to the BSC_A2.
of coverage of cell_A2.


Step Action
Expected result(s)
dropped.
successfully.

d) Success criteria
MSC handover of a subscriber of another ongoing point to point voice call with the same or lower

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.55 Inter MSC handover failure of a circuit switched data call (pre-emption Um-IF
not possible)


2.3.1 EN 301515

a) Purpose
coming inter MSC handover of a subscriber of an ongoing point to point data call with the same or
lower priority with the result that no handover is performed.




Step 1: Data call established in MSC_A1.
Step 2 only applicable in case MSC_A1 and MSC_A2 are from different vendors.




Network A

MSC_A1 MSC_A2
MS_A1 MS_A3
MS_A2 MS_A4
MS_A5
MS_A6
MS_A7
MS_A8

c) Test procedure

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4



Step
Action Expected result(s)
with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
the table above case 1. To configure the
Calls
ATD<MSISDN>
played on MS_A2.


Step
Action Expected result(s)
messages:
confirmed.
network.
MSC_A2.
ject to the BSC_A1.
ready dropped.
successfully.
the table above.




Network A

MSC_A1 MSC_A2
MS_A3 MS_A1
MS_A4 MS_A2
MS_A5
MS_A6
MS_A7
MS_A8

Test procedure


Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 4
2
BS 25
4800 bps
X X 4
3
BS 26
9600 bps
X X 4



with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
the table above case 1. To configure the
Calls
ATD<MSISDN>
played on MS_A2.


messages:
confirmed.
network.
MSC_A1.
ject to the BSC_A2.
ready dropped.
successfully.
the table above.

d) Success criteria
MSC handover of a subscriber of an ongoing point to point data call with the same or lower prior-
ity with the result that no handover is performed.



e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.56 Inter MSC Handover failure of a railway emergency originator (DCH) (pre-
emption Um-IF not possible


EN 301515

a) Purpose
coming inter MSC handover of the originator (on dedicated channel) of an ongoing railway emer-





Network A

A-MSC_A1 R-MSC_A2

c) Test procedure


network.



network.
network.
Only 1 TCH is available in cell A2.
cell_A2.
the NCH.
receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
released.
successfully.
de-allocated.




Network A

A-MSC_A1 R-MSC_A2
MS_A2 (no VGCS / VBS subscriber) MS_A7 (REC GID: 299)

Test procedure


network.



network.
network.
cell_A1.
the NCH.
receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
released.
successfully.
de-allocated.




Network A

R-MSC_A1 A-MSC_A2

Test procedure


network.



network.
network.
cell_A2.
the NCH.
receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
released.
successfully.
de-allocated.




Network A

R-MSC_A1 A-MSC_A2

Test procedure


network.



network.
network.
cell_A1.
the NCH.
receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
released.
successfully.
de-allocated.

d) Success criteria
MSC handover of the originator (on dedicated channel) of an ongoing railway emergency call with

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.57 Inter MSC Handover failure of a VGCS dedicated channel (pre-emption Um-IF
not possible


EN 301515

a) Purpose
coming inter MSC handover of the originator (on dedicated channel) of a VGCS call with the
same priority with the result that no handover is performed.





Network A

A-MSC_A1 R-MSC_A2

c) Test procedure

Step 1: VGCS establishment in anchor MSC_A1.

network.



network.
network.
cell_A2.
call on the NCH.
call.
group receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
released.
successfully.




Network A

A-MSC_A1 R-MSC_A2

Test procedure

Step 2: VGCS establishment in relay MSC_A2.

network.



network.
network.
cell_A1.
call on the NCH.
call.
group receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
released.
successfully.




Network A

R-MSC_A1 A-MSC_A2

Test procedure

Step 3: VGCS establishment in relay MSC_A1.

network.



network.
network.
cell_A2.
call on the NCH.
call.
group receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
released.
successfully.




Network A

R-MSC_A1 A-MSC_A2

Test procedure

Step 4: VGCS establishment in anchor MSC_A2.
network.



network.
network.
cell_A1.
call on the NCH.
call.
group receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
released.
successfully.

d) Success criteria
MSC handover of the originator (on dedicated channel) of a VGCS call with the same priority with
the result that no handover is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.58 Inter MSC Handover failure of a VBS originator (pre-emption Um-IF not pos-
sible


EN 301515

a) Purpose
coming inter MSC handover of the originator of a VBS call with the same priority with the result
that no handover is performed.





Network A

A-MSC_A1 R-MSC_A2

c) Test procedure

Step 1: VBS establishment in anchor MSC_A1.

network.



network.
network.
cell_A2.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
ready released.
VBS call is released and all resources are cor-
successfully.




Network A

A-MSC_A1 R-MSC_A2
MS_A2 (no VGCS / VBS subscriber) MS_A7 (VBS GID: 202)

Test procedure

Step 2: VBS establishment in relay MSC_A2.

network.



network.
network.
cell_A1.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
7) MS_A7 releases the VBS call not already
released.
successfully.




Network A

R-MSC_A1 A-MSC_A2

Test procedure

Step 3: VBS establishment in relay MSC_A1.

network.



network.
network.
cell_A2.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.


MSC_A2.
ject to the BSC_A1.
ready released.
successfully.




Network A

R-MSC_A1 A-MSC_A2

Test procedure

Step 4: VBS establishment in anchor MSC_A2.

network.



network.
network.
cell_A1.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.


MSC_A1.
ject to the BSC_A2.
7) MS_A7 releases the VBS call not already
released.
successfully.

d) Success criteria
MSC handover of the originator of a VBS call with the same priority with the result that no hand-
over is performed.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.59 Point to Point voice call performing intra BTS handover followed by an Inter
BTS and a BSC handover


EN 301515

a) Purpose
Verify that the originator of a PTP voice call can perform an intra BTS handover, followed by an
inter BTS handover and an inter BSC handover successfully.


Network A

Cell_A1 Cell_A2 Cell_A3 Cell_A4
MS_A1 MS_A2

c) Test procedure

Step Action
Expected result(s)
1) MS_A1 establishes a PTP call with prior-
ity 4 to MS_A2.
The PTP call is successfully established, there
is a two-way voice path between MS_A1 and
MS_A2.
2) MS_A1 moves from cell_A1 to cell_A2. MS_A1 performs an intra BTS handover from
cell_A1 to cell_A2.There is a two-way voice


Step Action
Expected result(s)
3) MS_A1 moves from cell_A2 to cell_A3. MS_A1 performs an inter BTS handover from
cell_A2 to cell_A3. There is a two-way voice
4) MS_A1 moves from cell_A3 to cell_A4. MS_A1 performs an inter BSC handover from
cell_A3 to cell_A4.
There is a two-way voice path between MS_A1
and MS_A2.
successfully.

d) Success criteria
The originator of a PTP voice call performs an intra BTS handover, followed by an inter BTS
handover and an inter BSC handover successfully.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an intra BTS Handover of a point to point voice call


EN 301515

a) Purpose
Verify that an ongoing point to point voice call in the destination cell is pre-empted by an incoming
intra BTS handover of a subscriber of another ongoing point to point voice call with higher priority.


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure



with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Intra BTS handover from cell_A1 to cell_A2
successfully performed.
One ongoing PTP call in cell_A2 is pre-empted
in order to allocate MS_A7.
Clear request is sent from the BSC to the MSC
with cause pre-emption.
Clear command is sent from the MSC to the
BSC with cause pre-emption.
MS_A7 has speech path to MS_A8.


d) Success criteria
An ongoing point to point voice call in the destination cell is pre-empted by an incoming intra BTS
handover of a subscriber of another ongoing point to point voice call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an intra BTS Handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
intra BTS handover of a subscriber of an ongoing point to point data call with higher priority.






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure
Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 3
2
BS 25
4800 bps
X X 3
3
BS 26
9600 bps
X X 3

4 to MS_A2.
network.


4 to MS_A4.
network.
4 to MS_A6.
network.
Calls
ATD*75<Priority>#<MSISDN>

played on MS_A8.
messages:
confirmed.
network.


10) MS_A7 releases the data call. Data call successfully released and all re-
table above.

d) Success criteria
handover of a subscriber of an ongoing point to point data call with higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an intra BTS Handover of a railway emergency call originator (DCH)


EN 301515

a) Purpose
intra BTS handover of the originator (on dedicated channel) of an ongoing railway emergency call
with a higher priority.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1




c) Test procedure

4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
the REC.
network.


Clear request is sent from BSC to the MSC
Clear command is sent from MSC to the BSC
9) MS_A7 releases the REC. REC successfully released and all resources

d) Success criteria
handover of the originator (on dedicated channel) of an ongoing railway emergency call with a
higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an intra BTS Handover of VGCS dedicated channel


EN 301515

a) Purpose
intra BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with higher
priority.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1



4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
the VGCS call.
network.



d) Success criteria
handover of the originator (on dedicated channel) of an ongoing VGCS call with a higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an intra BTS Handover of VBS originator


EN 301515

a) Purpose
intra BTS handover of the originator of an ongoing VBS call with higher priority.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
4) MS_A7 originates a VBS call with priority
3.
cell_A2.
coming VBS on the NCH.
whole VBS call.
the VBS call.
network.


7) MS_A7 releases the VBS call. VBS call successfully released and all re-

d) Success criteria
handover of the originator of an ongoing VBS call with a higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BTS Handover of a point to point voice call


EN 301515

a) Purpose
inter BTS handover of a subscriber of another ongoing point to point voice call with higher priority.


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure



with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Inter BTS handover from cell_A1 to cell_A2



d) Success criteria
An ongoing point to point voice call in the destination cell is pre-empted by an incoming inter BTS

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BTS Handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
inter BTS handover of a subscriber of an ongoing point to point data call with higher priority.






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 3
2
BS 25
4800 bps
X X 3
3
BS 26
9600 bps
X X 3



4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A6.
network.
Calls
played on MS_A8.
messages:
confirmed.
network.


table above.

d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BTS Handover of a railway emergency call originator (DCH)


EN 301515

a) Purpose
inter BTS handover of the originator (on dedicated channel) of an ongoing railway emergency call
with a higher priority.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
the REC.
network.



d) Success criteria
higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BTS Handover of VGCS dedicated channel


EN 301515

a) Purpose
inter BTS handover of the originator (on dedicated channel) of an ongoing VGCS call with higher
priority.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
coming VGCS on the NCH.
the VGCS call.
network.



d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BTS Handover of VBS originator


EN 301515

a) Purpose
inter BTS handover of the originator of an ongoing VBS call with higher priority.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1




c) Test procedure
4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
4) MS_A7 originates a VBS call with priority
3.
cell_A2.
coming VBS on the NCH.
whole VBS call.
the VBS call.
network.



d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BSC Handover of a point to point voice call


EN 301515

a) Purpose
inter BSC handover of a subscriber of another ongoing point to point voice call with higher priority.


Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure



with priority 4.
network.
with priority 4.
network.
with priority 4.
network.
network.
5) MS_A7 moves from cell_A1 to cell_A2. Inter BSC handover from cell_A1 to cell_A2
successfully.



d) Success criteria
An ongoing point to point voice call in the destination cell is pre-empted by an incoming inter BSC

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BSC Handover of a circuit switched data call


2.3.1 EN 301515

a) Purpose
inter BSC handover of a subscriber of an ongoing point to point data call with higher priority.






Network A

Cell_A1 Cell_A2
MS_A7 MS_A1
MS_A8 MS_A2
MS_A3
MS_A4
MS_A5
MS_A6

c) Test procedure

A subset of the mandatory data services will be used for handover test.

Case Data service
Digital
interworking
(UDI / ISDN)
V.110
Analogue
interworking
(3,1 kHz)
V.22bis, V.32
Transparent
eMLPP
Priority
1
BS 24
2400 bps
X (V.22bis) X 3
2
BS 25
4800 bps
X X 3
3
BS 26
9600 bps
X X 3



4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A6.
network.
Calls

played on MS_A8.
messages:
confirmed.
network.


successfully.
table above.

d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BSC Handover of a railway emergency call originator (DCH)


EN 301515

a) Purpose
inter BSC handover of the originator (on dedicated channel) of an ongoing railway emergency call
with higher priority.


Network A

Cell_A1 Cell_A2

CoO=Cell_A1



c) Test procedure

4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
the REC.
(GID 299) in group receive mode.
network.


successfully.

d) Success criteria
higher priority.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BSC Handover of VGCS dedicated channel


EN 301515

a) Purpose
inter BSC handover of the originator (on dedicated channel) of an ongoing VGCS call with higher
priority

Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
the VGCS call.
network.


successfully.

d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter BSC handover of VBS originator


EN 301515

a) Purpose
inter BSC handover of the originator of an ongoing VBS call with higher priority.


Network A

Cell_A1 Cell_A2

c) Test procedure
CoO=Cell_A1




4 to MS_A2.
network.
4 to MS_A4.
network.
4 to MS_A5.
network.
cell_A2.
whole VBS call.
the VBS call.
network.


successfully.

d) Success criteria

e) Test result

Remarks
Attachments
(log / trace file)

Signature


by an inter MSC handover of VBS originator


EN 301515

a) Purpose
inter MSC handover of the originator of an ongoing VBS call with higher priority.





Network A

A-MSC_A1 R-MSC_A2

c) Test procedure

Step Action
Expected result(s)
network.



Step Action
Expected result(s)
network.
network.
cell_A2.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.
6) MS_A7 moves from cell_A1 to cell_A2. Inter MSC handover successfully performed.


Step Action
Expected result(s)
successfully.


Network A

A-MSC_A1 R-MSC_A2

Test procedure




Step Action
Expected result(s)
network.
network.
network.
cell_A1.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
MS_A7 has two-way voice path. MS_B8 is only
listener.


Step Action
Expected result(s)
successfully.




Network A

R-MSC_A1 A-MSC_A2

Test procedure

Step Action
Expected result(s)
network.



Step Action
Expected result(s)
network.
network.
cell_A2.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
listener.


Step Action
Expected result(s)
successfully.


Network A

R-MSC_A1 A-MSC_A2

Test procedure




Step Action
Expected result(s)
network.
network.
network.
cell_A1.
on the NCH.
whole VBS call.
call.
group receive mode.
network.
MS_A7 has two-way voice path. MS_B8 is only
listener.


Step Action
Expected result(s)
successfully.

d) Success criteria
An ongoing point to point voice call in the destination cell is pre-empted by an incoming inter MSC

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.76 Inter BSC handover of a point to point voice call with eMLPP pre-emption at
A-IF


2.4.1
2.4.5
10.2.1
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted at A-IF by another PtP during a inter BSC-HO.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3
MS_A4
There is only 1 TS available at A-IF to BSC_A2

c) Test procedure



No IDLE TSs at A-IF to BSC_A2
MS_A3 still connected with MS_A4
5 Unlock the TSs to BSC_A2 All resources are IDLE

d) Success criteria
A PtP call can be pre-empted at A-IF by another PtP during a inter BSC-HO.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.77 Inter BSC handover of a circuit switched data call with pre-emption with
eMLPP pre-emption at A-IF


2.4.1
2.4.5
10.2.1
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted at A-IF by a data call during a inter BSC-HO.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2
MS_A3
MS_A4
There is only 1 TS available at A-IF to BSC_A2

c) Test procedure



No IDLE TSs at A-IF to BSC_A2
2 MS_A3 originates a data call to MS_A4
with prio 3
MS_A3 still connected with MS_A4

d) Success criteria
A PtP call can be pre-empted at A-IF by a data call with higher priority during a inter BSC-HO.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.78 Inter BSC handover of a railway emergency call originator with eMLPP pre-
emption at A-IF

2.4.1
2.4.5
10.2.1
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted at A-IF by the DCH of a REC during a inter BSC-HO


Network A

Cell_A1 Cell_A2
MS_A1 (no VGCS / VBS subscriber!) MS_A2 (no VGCS / VBS subscriber)
There are only 2 TSs available at A-IF to BSC_A2

c) Test procedure



2 MS_A3 originates the REC and keeps
the DCH

4 MS_A3 releases the DCH MS_A5 can take the uplink and speak to
MS_A3 and MS_A4.

d) Success criteria
A PtP call can be pre-empted at A-IF by the DCH of a REC during a inter BSC-HO.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.79 Inter BSC handover of a VGCS dedicated channel with eMLPP pre-emption at
A-IF


2.4.1
2.4.5
10.2.1
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted at A-IF by the DCH of a VGCS during a inter BSC-HO.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure



2 MS_A3 originates the 200 VGCS
and keep the DCH

3 MS_A3 moves to Cell_A2 The connection MS_A1 to MS_A2 is pre-empted
at A-IF to BSC_A2
4 MS_A3 releases the DCH MS_A5 can take the uplink and speak to MS_A3
and MS_A4.

d) Success criteria
A PtP call can be pre-empted at A-IF by the DCH of a VGCS during a inter BSC-HO.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


5.10.80 Inter BSC handover of a VBS originator with eMLPP pre-emption at A-IF


2.4.1
2.4.5
10.2.1
2.4.1

a) Purpose
Verify that a PtP call can be pre-empted at A-IF by the DCH of a VBS during a inter BSC-HO.


Network A

Cell_A1 Cell_A2
MS_A1 MS_A2

c) Test procedure



2 MS_A3 originates the 202 VBS MS_A4 and MS_A5 receive the VBS call

d) Success criteria
A PtP call can be pre-empted at A-IF by the DCH of a VBS with higher priority during a inter BSC-
HO.

e) Test result

Remarks
Attachments
(log / trace file)

Signature


6 Annex
6.1 Annex - IOT test case overview
The involved Notifies Bodies reviewed the IOT test case overview and confirmed completeness
regarding to the mandatory requirements of the EIRENE specifications E-FRS V7 and E-SRS
V15 as well as with respect to the TSI and the relevant ETSI specifications.
Note: The indicated cross references in the IOT test case table between E-FRS V7 / E-SRS V15
and the test cases are given in such way that every mandatory requirement is covered by
at least one test case.


6.1.1 Overview of the IOT test cases

TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
1 Basic and Supplementary Services
1.1 Successful Location Update after MS Power On (non-roaming
case)
No Yes No
1.2 Successful Location Update after change of Location Area (non-
roaming case)
No Yes Yes
1.3 Unsuccessful Location Update (HLR ID on the SIM card is un-
known) (non-roaming case)
No Yes No
1.4 Unsuccessful Location Update ( due to PLMN not allowed) (non-
roaming case)
No Yes No
1.5 Successful Location Cancellation (non-roaming case) No Yes No
1.6 Successful IMSI Detach by MS Power Off (non-roaming case) No Yes No
1.7 MTM to detached mobile subscriber (non-roaming case) No Yes No 2.2.1
2.2.3
2.2.4
2.2.1
1.8 MTM, mobile subscribers are in different Location areas (non-
roaming case)
No Yes Yes 2.2.1 2.2.2
2.2.3
2.2.4
3.2.3
2.2.1
9.7.1
9.7.2
9.7.3 10.7.1i
10.7.3
1.9 MTM, radio link failure on A-side, A and B subscriber are in differ-
ent cell (non-roaming case)
No Yes No 2.2.1
2.2.3
2.2.4
2.2.1
1.10 Supplementary Service Call Hold (non-roaming case) No Yes No 2.4.1
2.4.13
2.4.14
2.4.1
1.11 Supplementary Service Call Waiting (non-roaming case) No Yes No 2.4.1
2.4.15
2.4.1
1.12 Supplementary Service CLIP MTM with Call Forwarding Uncon-
ditional (non-roaming case)
No Yes No 2.4.1
2.4.2
2.4.12
2.4.1


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
1.13 Supplementary Service COLP (non-roaming case) No Yes No 2.4.1
1.14 Supplementary Service MPTY (incl. Multivendor MPTY) (non-
roaming case)
No Yes No 2.2.1
2.2.17
2.2.18
2.4.1 2.5.1
1.15 Notification of Call Forwarding (non-roaming case) No Yes No 2.4.1
2.4.12
2.4.1
1.16 Establishment of several data calls (Bearer and Tele Services) with
different eMLPP priotities(non-roaming case)
No Yes No 2.3.1
2.3.6
2.3.8
2.3.13
2.4.1
2.4.5
9.2.1.2
10.2.1
10.2.2
10.2.1 2.3.1
1.17 Establishment of several PTP calls with different priorities (non-
roaming case)
No Yes No 2.4.1
2.4.5
10.2.1
10.2.2
10.2.1
1.18 Call to busy Mobile CFBusy to other mobile subscriber (non-
roaming case)
No Yes No 2.4.1 2.4.12 2.4.1
1.19 MOC when terminator rejects call (non-roaming case) No Yes No
1.20 Unsuccessful MOC due to unallocated number (non-roaming case) No Yes No
1.21 MTC Paging Time Out (non-roaming case) No Yes No 9.7.4 (MT call)
1.22 Unsuccessful MTC, subscriber not in VLR (non-roaming case) No Yes No
1.23 Successful Location Update after MS Power On (roaming case) Yes No No
1.24 Successful Location Update after change of Location Area (roam-
ing case)
Yes No No
1.25 Unsuccessful Location Update (HLR ID on the SIM card is un-
known) (roaming case)
Yes No No
1.26 Unsuccessful Location Update ( due to PLMN not allowed) (roam-
ing case)
Yes No No
1.27 Successful Location Cancellation (roaming case) Yes No No


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
1.28 Successful IMSI Detach by MS Power Off (roaming case) Yes No No
1.29 MTM to detached mobile subscriber (roaming case) Yes No No 2.2.1
2.2.3
2.2.4
2.2.1
1.30 MTM, mobile subscribers are in different Location areas (roaming
case)
Yes No No 2.2.1
2.2.3
2.2.4
2.2.1
10.7.1i
10.7.3
1.31 MTM, radio link failure on A-side, A and B subscriber are in differ-
ent cell (roaming case)
Yes No No 2.2.1
2.2.3
2.2.4
2.2.1
1.32 Supplementary Service Call Hold (roaming case) Yes No No 2.4.1
2.4.13
2.4.14
2.4.1
1.33 Supplementary Service Call Waiting (roaming case) Yes No No 2.4.1
2.4.15
2.4.1
1.34 Supplementary Service CLIP MTM with Call Forwarding Uncon-
ditional (roaming case)
Yes No No 2.4.1
2.4.2
2.4.12
2.4.1
1.35 Supplementary Service COLP(roaming case) Yes No No 2.4.1
1.36 Supplementary Service MPTY (incl. Multivendor MPTY) (roaming
case)
Yes No No 2.2.1
2.2.17
2.2.18
2.4.1 2.5.1
1.37 Notification of Call Forwarding (roaming case) Yes No No 2.4.1
2.4.2
2.4.12
2.4.1
1.38 Establishment of several data calls with different eMLPP priotities
(roaming case)
Yes No No 2.3.1
2.3.6
2.3.8
2.3.13
2.4.1
2.4.5
10.2.1
10.2.2
10.2.1 2.3.1


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
1.39 Establishment of several PTP calls with different priorities (roaming
case)
Yes No No 2.4.1
2.4.5
10.2.1
10.2.2
10.2.1
1.40 Call to busy Mobile CFBusy to other mobile subscriber (roaming
case)
Yes No No 2.4.1 2.4.12 2.4.1
1.41 MOC when terminator rejects call (roaming case) Yes No No
1.42 Unsuccessful MOC due to unallocated number (roaming case) Yes No No
1.43 MTC Paging Time Out (roaming case) Yes No No
1.44 Unsuccessful MTC, subscriber not in VLR (roaming case) Yes No No
1.45 Closed User Group (non-roaming case) No Yes No 2.4.1
2.4.8
2.4.9
10.4
2.4.1
10.4.2 11.3.2
11.3.8i 11.5.1
1.46 Closed User Group (roaming case) Yes No No 2.4.1
2.4.8
2.4.9
10.4
2.4.1
10.4.2 11.3.2
11.3.8i 11.5.1
1.47 Call barring (roaming case) Yes No No 2.4.1
2.4.17
2.4.1
9.10.2
1.48 Public Emergency Call With SIM (non-roaming case) No Yes No 2.2.1
2.2.5
9.3.2
2.2.1
1.49 Public Emergency Call Without SIM (non-roaming case) No Yes No 2.2.1
2.2.5
9.3.2
2.2.1
1.50 Public Emergency Call with TMSI and IMSI unknown in VLR
(non-roaming case)
No Yes No 2.2.1
2.2.5
9.3.2
2.2.1
1.51 Public Emergency Call With SIM (roaming case) Yes No No 2.2.1
2.2.5
9.3.2
2.2.1


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
1.52 Public Emergency Call Without SIM (roaming case) Yes No No 2.2.1
2.2.5
9.3.2
2.2.1
1.53 Public Emergency Call with TMSI and IMSI unknown in VLR
(roaming case)
Yes No No 2.2.1
2.2.5
9.3.2
2.2.1
2 Functional Addressing
2.1 Registration of a FN (non-roaming case) No Yes No 2.5.1
11.2.1.1
11.3.2.1
11.3.2.3
2.4.1 2.5.1
11.3.2
11.3.5
11.3.7
2.2 Register 3 function numbers to one user (non-roaming case) No Yes No 11.2.1.4 2.4.1
2.5.1
2.3 Register 3 function numbers to one user (roaming case) Yes No No 11.2.1.4 2.4.1
2.5.1
2.4 Registration of a unknown FN fails (non-roaming case) No Yes No 11.3.2.4 2.4.1 2.5.1
11.3.8
11.3.9
2.5 Deregistration of a FN (non-roaming case) No Yes No 2.5.1
11.3.3.1
11.3.3.3
11.3.3.5
2.4.1 2.5.1
11.3.2
11.3.5
11.3.7
11.3.10
11.3.12
2.6 Deregistration of a FN fails (non-roaming case) No Yes No 11.3.3.1 2.4.1 2.5.1
11.3.10
11.3.12
2.7 Forced Deregistration of a FN (non-roaming case) No Yes No 11.3.3.4 2.4.1 2.5.1
11.3.7
11.3.8i
2.8 Forced Deregistration of a FN fails (non-roaming case) No Yes No 11.3.3.4 2.4.1 2.5.1
11.3.7
11.3.8i


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
2.9 Class of registration (CoR) check (non-roaming case) No Yes No 2.4.1 2.5.1
11.3.6
2.10 Registration of a FN (roaming case) Yes No No 11.2.1.1
11.2.1.7
11.2.1.8
11.3.2.1
11.3.2.3
11.3.4
2.4.1 2.5.1
11.3.2
11.3.7
11.3.14
11.3.17
11.6
2.11 Registration of a unknown FN fails (roaming case) Yes No No 11.3.2.4 2.4.1 2.5.1
11.3.8
11.3.9
2.12 Check of the storage of CT2 Number and its destination in the
current EIRENE network.
Yes No No 9.2.3
2.13 Check of the storage of CT3 Number and the according destination
in the home EIRENE network.
Yes No No 9.2.5
2.14 Check of the storage of CT4 Number and its destination in the
home EIRENE network.
Yes No No 9.2.6
2.15 Check of the storage of CT6 and CT7 Numbers and their destina-
tions in the home EIRENE network.
No Yes No 9.2.8
2.16 Registration failures --> outcome code 61 [remote party already
registered] (non-roaming case)
No Yes No 9.2.2.2
9.2.3.2
11.2.1.5
11.2.2.1
11.3.2.5
2.4.1 2.5.1
9.2.1 11.3.8
11.3.9
2.17 Registration failures --> outcome code 61 [remote party already
registered] (roaming case)
Yes No No 9.2.2.2
9.2.3.2
11.2.1.5
11.2.2.1
11.3.2.5
2.4.1
2.5.1
9.2.1
11.3.8
11.3.9


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
2.18 Deregistration of a FN (roaming case) Yes No No 11.2.1.7
11.2.1.8
11.3.3.1
11.3.3.3
11.3.3.5
2.4.1 2.5.1
11.3.2
11.3.7
11.3.10
11.3.12
11.3.14
11.3.17
11.6
2.19 Deregistration of a FN fails (roaming case) Yes No No 11.2.1.7
11.2.1.8
11.3.3.1
2.4.1 2.5.1
11.3.10
11.3.12
2.20 Forced Deregistration of a FN (roaming case) Yes No No 11.3.3.4 2.4.1 2.5.1
11.3.8i
11.3.17
11.6
2.21 Forced Deregistration of a FN fails due to a missing supervisor
CoR (roaming case)
Yes No No 11.3.3.4 2.4.1 2.5.1
11.3.8i
2.22 Class of registration (CoR) check (roaming case) Yes No No 2.4.1 2.5.1
11.3.6
2.23 FFN-Recovery Yes No No 11.3.2.6 11.4.1


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
2.24 FA Call - Successful Call (national call) No Yes No 3.2.3
9.2.1.1
9.2.4.1
9.2.4.2
9.2.4.3
9.2.4.4
2.4.3
11.2.1.10
11.2.2.2
11.2.3.1
11.2.3.2
11.2.3.3
11.2.3.4
11.2.3.5
2.4.1
2.5.1
9.2.2
9.2.4
9.2.7
9.4.1
9.5.2
9.5.3
9.5.4
9.6.2
9.A2
9.A3
11.2.3
11.5.1
11.5.2
11.5.4
11.5.5
2.25 FA Call Call is not completed (national call) No Yes No
2.26 FA Call - Successful Call (international call) Yes No No 9.2.1.1 2.4.3
11.2.1.10
11.2.3.1
11.2.3.2
11.2.3.3
11.2.3.4
11.2.3.5
2.4.1
2.5.1
9.4.1
9.5.2
9.6.2
9.6.3
9.6.4
9.10.1
9.10.1ii
11.5.1
11.5.2
11.5.4
11.5.5
2.27 FA Call Call is not completed (international call) Yes No No
3 Access Matrix and Access to External Networks


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
3.1 National call: AM allows call No Yes No 10.6.1
10.6.2
11.8.1
3.2 National call: AM denies call No Yes No 10.6.1
10.6.2
11.8.1
3.3 International call: AM allows call Yes No No 10.6.1
10.6.2
9.3.4
9.10.1
9.10.1ii
11.8.1
3.4 International call: AM denies call Yes No No 10.6.1
10.6.2
11.8.1
3.5 Calling party outside the EIRENE network (non-roaming case) No Yes No 2.4.17
9.5.1
11.2.1.10
9.2.9
11.8.1
3.6 Calling party outside the EIRENE network (roaming case) Yes No No 2.4.17
9.5.1
11.2.1.10
9.2.9
11.8.1
3.7 Access to other GSM-R networks: Break out codes (non-roaming
case)
Yes No No 9.4.2
9.10.1
9.10.1i
9.10.1ii
9.10.1iii
3.8 Access to other GSM-R networks: Break out codes (roaming case) Yes No No 9.4.2
9.10.1
9.10.1i
9.10.1ii
9.10.1iii
3.9 Access to public networks (non-roaming case) No Yes No 9.10.3
3.10 Acces to public networks (roaming case) Yes No No 9.10.3
3.11 Access to private networks: Break out codes (non-roaming case) No Yes No 9.10.1v
3.12 Access to private networks: Break out codes (roaming case) Yes No No 9.10.1v
4 Location Depending Addressing


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
4.1 LDA call (non-roaming case) No Yes No 2.5.1
3.2.3
9.3.2
11.4
2.5.1
9.4.1
9.8.1
9.8.2
9.8.3
9.8.4
11.7.1
11.7.2
4.2 LDA call fails (non-roaming case) No Yes No 2.5.1
11.4
2.5.1
11.7.1
11.7.2
4.3 LDA call (roaming case) Yes No No 2.5.1
9.3.2
11.4
2.5.1
9.4.1
9.8.1
9.8.2
9.8.3
9.8.4
11.7.1
11.7.2
4.4 LDA call fails (roaming case) Yes No No 2.5.1
11.4
2.5.1 11.7.1
11.7.2
5 MLPP
5.1 ptp call pre-emption at the E-IF between two networks by a REC Yes No No 2.4.1
2.4.6
2.4.7
10.2.3
2.4.1
10.2.1
5.2 ptp call pre-emption at the E-IF between two networks by an other
ptp call
Yes No No 2.4.6
2.4.7
10.2.3

5.3 Link to a controller of a VGCS call is preempted at the E-IF be-
tween two networks by a REC
Yes No No 2.4.6
2.4.7
10.2.3

5.4 Link to the originator as first talker of a VGCS call is preempted at
the E-IF between two networks by a REC
Yes No No 2.4.6
2.4.7
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
5.5 Link between A-MSC and R-MSC of VGCS call is preempted at the
E-IF between two networks by a REC
Yes No No 2.4.6
2.4.7
10.2.3

5.6 Link to a controller of a VGCS call is preempted at the E-IF be-
tween two networks by a ptp call
Yes No No 2.2.2
2.4.6
2.4.7
10.2.3

5.7 Link to the originator as first talker of a VGCS call is preempted at
the E-IF between two networks by a ptp call
Yes No No 2.4.6
2.4.7
10.2.3

5.8 Link between A-MSC and R-MSC of VGCS call is preempted at the
E-IF between two networks by a ptp call
Yes No No 2.4.6
2.4.7
10.2.3

5.9 Inter MSC handover of a point to point voice call with MLPP pre-
emption at E-IF
Yes Yes No 2.4.1
5.10 Inter MSC handover of a circuit switched data call with MLPP pre-
emption at E-IF
Yes Yes No 2.4.1
5.11 Inter MSC handover of a railway emergency call originator with
pre-emption at E-IF
Yes Yes No 2.4.1
5.12 Inter MSC handover of a VGCS dedicated channel with MLPP pre-
emption at E-IF
Yes Yes No 2.4.1
5.13 Inter MSC handover of a VBS originator channel with MLPP pre-
emption at E-IF
Yes Yes No 2.4.1
6 REC 2.5.1
6.1 REC call setup by a service subscriber (non-roaming case) No Yes No 9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1 13.2.2
13.3.3
6.2 REC call setup by a controller No Yes No 9.3.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1
9.5.4 13.2.2
13.3.1
13.3.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
6.3 REC notification and joining (non-roaming case) No Yes No 13.1.6 9.3.2
13.2.2.2
13.2.3.1
13.2.3.3
2.5.1
9.5.4 13.2.2
13.3.1
13.3.3
13.4.1
13.4.2
6.4 REC acknowledgement (non-roaming case) No Yes No 13.4.5
13.4.6
2.5.1
13.5.3
13.5.5
13.5.7
13.5.9
13.5.10
6.5 REC call setup by a service subscriber (roaming case) Yes No No 9.3.2
13.1.6
13.2.2.2
13.2.3.1
13.2.3.3
13.2.4.1
2.5.1 13.2.2
13.3.3
6.6 REC notification and joining (roaming case) Yes No No 13.1.6 9.3.2
13.2.2.2
13.2.3.1
13.2.3.3
2.5.1
13.2.2
13.2.3
13.3.1
13.3.3
13.4.1
13.4.2
6.7 REC acknowledgement (roaming case) Yes No No 13.4.5
13.4.6
2.5.1
13.5.3
13.5.5
13.5.7
13.5.9
13.5.10
6.8 C-OTDI check No Yes No 2.2.1
13.3.2
2.2.1
2.5.1
13.4.6
13.4.7


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
6.9 LE idle mode (non-roaming case) No Yes No 13.2.2.7 2.5.1
6.10 LE dedicated mode (non-roaming case) No Yes No 13.2.2.7 2.5.1
6.11 LE group receive mode (non-roaming case) No Yes No 13.2.2.7 2.5.1
6.12 LE group transmit mode (non-roaming case) No Yes No 13.2.2.7 2.5.1
6.13 LE group mode, dedicated channel (non-roaming case) No Yes No 13.2.2.7 2.5.1
6.14 LE idle mode (roaming case) Yes No No 13.2.2.7 2.5.1
6.15 LE dedicated mode (roaming case) Yes No No 13.2.2.7 2.5.1
6.16 LE group receive mode (roaming case) Yes No No 13.2.2.7 2.5.1
6.17 LE group transmit mode (roaming case) Yes No No 13.2.2.7 2.5.1
6.18 LE group mode, dedicated channel (roaming case) Yes No No 13.2.2.7 2.5.1
6.19 VGCS call is taken down due to expiry of No activity timer. No Yes No 13.2.4.1
6.20 REC first talker notification (MS dedicated mode, incoming ptp call,
non-roaming case)
No Yes No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3
6.21 REC first talker notification (MS dedicated mode, incoming REC
call), non-roaming case)
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
6.22 REC first talker notification (MS dedicated mode, incoming VBS
call, non-roaming case)
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
6.23 REC first talker notification (MS dedicated mode, incoming ptp call,
roaming)
Yes No No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3
6.24 REC first talker notification (MS dedicated mode, incoming REC
call, roaming case)
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
6.25 REC first talker notification (MS dedicated mode, incoming VBS
call, roaming case)
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
6.26 REC first talker notification (MS dedicated mode, incoming second
REC), non-roaming case)
No Yes No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
6.27 REC first talker notification (MS dedicated mode, incoming second
REC, roaming case)
Yes No No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
6.28 Shunting emergency call (non-roaming case) No Yes No 13.1.7
13.1.8
13.2.4.1
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3
6.29 Shunting emergency call (roaming case) Yes No No 13.1.7
13.1.8
13.2.4.1
2.5.1
9.5.4
13.2.2
13.3.1
13.3.3
7 eMLPP 2.4.1
2.4.5
10.2.1
2.4.1
7.1 MS in VBS call as listener, pre-emption on MS by higher prio PtP
call.
No Yes No 2.4.6
2.4.7
3.2.3
10.2.2
10.2.3

7.2 MS in VGCS call on DCH, pre-emption on Um IF by higher prio
PtP call
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.3 MS in VGCS call having the UL of the GCH, pre-emption on A IF
by higher prio PtP call
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.4 MS in PEC, pre-emption on A IF by higher prio PtP call No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3
9.8.5
7.5 MS in PtP call, pre-emption on MS by higher prio VBS call No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.6 MS in VBS call as originator, pre-emption on A IF by higher prio
VBS call
No Yes No 2.2.9
2.4.6
2.4.7
10.2.2
10.2.3

7.7 MS in VBS call as listener, pre-emption on Um IF by higher prio
VBS call.
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.8 MS in VGCS call on DCH, pre-emption on MS by higher prio VBS
call
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.9 MS in VGCS call having the UL of the GCH, pre-emption on Um IF
by higher prio VBS call.
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.10 MS in data call, pre-emption on A IF by higher prio VBS call No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.11 MS in PEC, pre-emption on Um IF by a REC No Yes No 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.12 MS in PtP call, pre-emption on A IF by higher prio PtP call. No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.13 MS in PtP call, pre-emption on MS by higher prio VGCS call (REC) No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.14 MS in VBS call as originator, pre-emption on Um IF by higher prio
VGCS call (REC)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.15 MS in VBS call as listener, pre-emption on A IF by higher prio
VGCS call (REC)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.16 MS in VGCS call having the UL of the GCH, pre-emption on MS by
higher prio VGCS call (REC)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.17 MS in VGCS call as listener, pre-emption on A IF by higher prio
VGCS call (REC)
No Yes Yes 2.2.14
2.4.6
2.4.7
10.2.2
10.2.3

7.18 MS in data call, pre-emption on Um IF by higher prio VGCS call
(REC)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.19 MS in PtP call, pre-emption on Um IF by higher prio data call (4.8
kbit/s, transparent)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.20 MS in VBS call as originator, pre-emption on Um IF by higher prio
data call (9.6 kbit/s, transparent)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.21 MS in VGCS call on DCH, pre-emption on A IF by higher prio data
call (9.6 kbit/s, transparent)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.22 MS in VGCS as listener, pre-emption on Um IF by higher prio data
call (4.8 kbit/s, transparent)
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.23 MS in VBS call as originator, pre-emption on A IF by higher prio
data call (2.4 kbit/s, transparent)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.24 MS in VBS call as originator, pre-emption on A IF by lower prio PtP
call does not take place.
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.25 MS in VBS call as listener, pre-emption on Um IF by lower prio PtP
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.26 MS in VGCS call as listener, pre-emption on Um IF by lower prio
PtP call does not take place
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.27 MS in data call, pre-emption on A IF by lower prio PtP call does not
take place.
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.28 MS in VGCS call , pre-emption on Um IF by lower prio VBS call
does not take place.
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.29 MS in VGCS call as listener, pre-emption on A IF by lower prio
VBS call does not take place.
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.30 MS in VGCS call on DCH, pre-emption on A IF by lower prio VGCS
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.31 MS in VGCS call having the UL on the GCH, pre-emption on Um IF
by lower prio VGCS all does not take place.
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.32 MS in PEC, pre-emption on Um IF by lower prio VGCS call does
not take place
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3
9.8.5
7.33 MS in VBS call as originator, pre-emption on Um IF by lower prio
data call does not take place
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.34 MS in VBS call as listener, pre-emption on A IF by lower prio data
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.35 MS in VGCS call having the UL of the GCH, pre-emption on A IF
by lower prio data call does not take place.
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.36 MS in data call, pre-emption on Um IF by lower prio data call does
not take place
No Yes No 2.4.6
2.4.7
10.2.2
10.2.3

7.37 MS in PEC, pre-emption on A IF by lower prio data call does not
take place.
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3
9.8.5
7.38 Pre-emption of VBS A IF resources on A and B BSS simultane-
ously
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.39 Pre-emption of VGCS A IF resources on A and B BSS simultane-
ously
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.40 Pre-emption of VBS Um IF resources on A and B BSS simultane-
ously
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.41 Pre-emption of VGCS Um IF resources on A and B BSS simulta-
neously
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.42 VGCS ongoing in GCA covering both BSS, pre-emption of the B
VGCS resources on Um. VGCS on A BSS is still up.
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.43 VGCS ongoing in GCA covering both BSS, pre-emption of the A
VGCS resources on Um. VGCS on B BSS is still up.
No No Yes 2.4.6
2.4.7
10.2.2
10.2.3


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
7.44 eMLPP priority is preserved during CFU (Call Forwarding Uncondi-
tionally)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.45 eMLPP priority is preserved during CFB (Call Forwarding Busy) No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.46 Multi-Party: M6PORT: with different Prio No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.47 Preemption on A-IF when pre-empted party has no subscription to
eMLPP (assignment of default eMLPP priority)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.48 Preemption on Um-IF when pre-empted party has no subscription
to eMLPP (assignment of default eMLPP priority)
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.49 3TS available on A IF, 1 TS in use by prio 3 GCH, 1 TS in use by
prio 4 GCH. Make prio 3 VBS and verify that the prio4 GCH is pre-
empted
No Yes Yes 2.4.6
2.4.7
10.2.2
10.2.3

7.50 Check of maximum authorized eMLPP level (non-roaming case) No Yes No 2.4.1 2.4.1
7.51 Check of maximum authorized eMLPP level (roaming case) Yes No No 2.4.1 2.4.1
8 VGCS 9.2.5.1 2.2.1


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
8.1 SS originates VGCS call No Yes No 2.2.1
2.2.12
2.2.15
2.2.16
3.2.3
3.5.2
3.5.3
11.2.3.2
9.2.10
9.2.11
9.9.3
9.9.5
8.2 Serv. Subs. Originates a VGCS (p3) call. No Yes No 2.2.1 2.2.1
8.3 Controller originates a VGCS (p2) call and takes it down with the
kill Sequence
No Yes No 2.2.1
3.5.2
3.5.3
2.2.1
3.7.2
9.9.2
8.4 SS originates VGCS call, leaves, rejoins and ends it. No Yes No
8.5 SS is notified when entering into VGCS broadcast area with ongo-
ing VGCS call
No Yes No 3.5.7
8.6 Controller joins ongoing VGCS call No Yes No
8.7 Originator of VGCS call releases DCH No Yes Yes
8.8 Originator of VGCS call takes Uplink No Yes Yes
8.9 Joiner of VGCS call takes Uplink No Yes Yes
8.10 Un-mute and Mute sequence for originating Controller No Yes No 3.7.2
3.8.1
3.8.2
3.8.4
3.8.5
8.11 Un-mute and Mute sequence for joining Controller No Yes No 3.7.2
3.8.1
3.8.2
3.8.4
3.8.5
8.12 Parallel group calls are possible in the same cell. No Yes No


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
8.13 Parallel VBS/VGCS calls with same GID are possible (same BSS
and different BSS)
No Yes Yes 2.2.1
2.2.7
3.5.2
3.5.3
2.2.1
8.14 MSC receives VBS/VGCS Queuing Indication followed by Assign-
ment Result from non COO
No Yes No 1.4.1.1
ment Result from COO
No Yes No 1.4.1.1
ment Failure from non COO
No Yes No
8.17 Origination of VGCS call from non subscribed MS fails No Yes No 2.2.1 2.2.1
8.18 Origination by a controller fails No Yes No
8.19 Killing of VGCS call by a controller fails No Yes No
8.20 Uplink release when DCH is allocated in case of SS contact lost No Yes No
8.21 Uplink release when DCH is allocated in case of Equipment failure
(TRX)
No Yes No
8.22 Uplink Release when DCH is allocated in case of Equipment failure
(PCM)
No Yes Yes
8.23 Uplink release when GCH Uplink is allocated in case of SS contact
lost
No Yes No
8.24 Uplink release when GCH Uplink is allocated in case of Equipment
failure (TRX)
No Yes No
8.25 Uplink release when GCH Uplink is allocated in case of Equipment
failure (PCM)
No Yes Yes
8.26 Uplink Request is rejected due to Uplink already allocated No Yes No 5.2.2.51
5.2.2.53
5.2.2.54
6.2.2.10
6.2.2.12
6.2.2.13
7.2.2.18
7.2.2.20
7.2.2.21


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
8.27 2 Controllers initiate VGCS with the same GID but different GCAs No Yes No 3.5.2
3.5.3

8.28 VGCS call taken down during setup by SS No Yes No
8.29 VGCS call taken down during setup by a controller No Yes No
8.30 More than 1 Uplink Request at the same time (same BSS and dif-
ferent BSS)
No Yes Yes 2.2.16
5.2.2.51
5.2.2.53
5.2.2.54
6.2.2.10
6.2.2.12
6.2.2.13
7.2.2.18
7.2.2.20
7.2.2.21

8.31 2 SS originate VGCS call at same time (same BSS and different
BSS)
No Yes Yes
8.32 2 controllers originate VGCS call at the same time No Yes Yes
8.33 VGCS originator leaves GCA No Yes No
8.34 VGCS talker leaves GCA No Yes No
8.35 Service Subscriber initiated VGCS from Relay MSC in PLMN A,
call to A-MSC Controller
Yes No No 9.4.2 9.5.4
9.9.4
8.36 Controller originates a VGCS call from Relay MSC Yes No No 9.5.4
8.37 SS initiated VGCS call from Relay MSC. Controller in A-MSC area
can re-connect to on-going VGCS call
Yes No No 2.2.1
8.38 VGCS first talker notification (MS dedicated mode, incoming ptp
No Yes No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3
8.39 VGCS first talker notification (MS dedicated mode, incoming VGCS
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
8.40 VGCS first talker notification (MS dedicated mode, incoming VBS
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
8.41 VGCS first talker notification (MS dedicated mode, incoming ptp
call, roaming)
Yes No No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
14.3.3
8.42 VGCS first talker notification (MS dedicated mode, incoming VGCS
call, roaming case)
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
8.43 VGCS first talker notification (MS dedicated mode, incoming VBS
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
8.44 VGCS first talker notification (MS dedicated mode, incoming REC),
non-roaming case)
No Yes No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
8.45 VGCS first talker notification (MS dedicated mode, incoming REC,
roaming case)
Yes No No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
8.46 Multiple VGCS membership (non-roaming case) No Yes No 2.2.14
8.47 Multiple VGCS membership (roaming case) Yes No No 2.2.14
8.48 VGCS call established in CoO when non CoO is locked No Yes No
9 VBS 2.2.1 without
TCs 9.47 and
9.48
9.1 SS originates VBS call No Yes No 2.2.1
2.2.7
2.2.11
3.2.3
3.5.2
3.5.3
11.2.3.2
9.2.11
9.2 Modification of broadcast area. No Yes No 2.2.10


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
9.3 SS originates a VBS (prio4) call. No Yes No
9.4 Controller originates a VBS (prio3) call. No Yes No 3.5.2
3.5.3
9.2.11
9.5.4
9.5 Controller originates a VBS (prio4) call. No Yes No 3.5.2
3.5.3

9.6 Controller joins ongoing VBS call No Yes No
9.7 SS enters into VBS broadcast area with ongoing VBS call and is
notified of it, SS joins the VBS call
No Yes No
9.8 Parallel VBS (different GID) calls are possible in the same cell. No Yes No
9.9 Parallel VBS calls with the same GID are possible (same BSS,
different BSS)
No Yes Yes
9.10 2 controllers initiate VBS with the same GID but different GCAs No Yes No 3.5.2
3.5.3

ment Result from non COO during SS originated VBS call
No Yes No
ment Result from COO during SS originated VBS call
No Yes No
ment Failure from non COO during SS originated VBS call
No Yes No
ment Failure from COO during SS originated VBS call
No Yes No
9.15 Contact loss for VBS originator No Yes No
9.16 Equipment failure (TRX) for VBS originator No Yes No
9.17 Equipment failure (PCM) for VBS originator No Yes No
9.18 VBS call established in CoO when non CoO is locked No Yes No
9.19 Origination of VBS call from non subscribed MS fails No Yes No
9.20 Origination by controller fails No Yes No
9.21 Killing of VBS call by controller fails No Yes No
9.22 VBS call taken down during setup by SS No Yes No
9.23 VBS call taken down during setup by Controller No Yes No


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
9.24 2 SS originate VBS call at same time (same BSS and different
BSS)
No Yes Yes
9.25 2 controllers originate VBS call at the same time (same BSS and
different BSS)
No Yes Yes
9.26 Service Subscriber initiated VBS from Relay MSC. Call to A-MSC
controller
Yes No No
9.27 Controller originates a VBS call from Relay MSC Yes No No
9.28 VBS originator notification (MS dedicated mode, incoming ptp call,
non-roaming case)
No Yes No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
9.29 VBS originator notification (MS dedicated mode, incoming VGCS
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
9.30 VBS originator notification (MS dedicated mode, incoming VBS
No Yes No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
9.31 VBS originator notification (MS dedicated mode, incoming ptp call,
roaming)
Yes No No 2.2.1
5.2.2.43
5.5.19
5.5.20
5.5.21
9.32 VBS originator notification (MS dedicated mode, incoming VGCS
call, roaming case)
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
9.33 VBS originator notification (MS dedicated mode, incoming VBS
Yes No No 2.2.1
5.2.2.47
5.5.19
5.5.20
5.5.21
9.34 VBS originator notification (MS dedicated mode, incoming REC),
non-roaming case)
No Yes No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
9.35 VBS originator notification (MS dedicated mode, incoming REC,
roaming case)
Yes No No 2.2.1
5.2.2.47
13.3.1
5.5.19
5.5.20
5.5.21
9.36 Multiple VGCS membership (non-roaming case) No Yes No 2.2.9
9.37 Multiple VGCS membership (roaming case) Yes No No 2.2.9
10 Cell reselection & handover


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
10.1 Intra BTS cell reselection in idle mode No Yes No
10.2 Intra BTS cell reselection of a VBS listener No Yes No
10.3 Intra BTS cell reselection of a VGCS listener No Yes No
10.4 Intra BTS cell reselection of a REC listener No Yes No
10.5 Inter BTS cell reselection in idle mode No Yes No
10.6 Inter BTS cell reselection of a VBS listener No Yes No
10.7 Inter BTS cell reselection of a VGCS listener No Yes No
10.8 Inter BTS cell reselection of a REC listener No Yes No
10.9 Inter BSC cell reselection in idle mode No Yes Yes
10.10 Inter BSC cell reselection of a VBS listener No Yes Yes
10.11 Inter BSC cell reselection of a VGCS listener No Yes Yes
10.12 Inter BSC cell reselection of a REC listener No Yes Yes
10.13 Inter MSC cell reselection of a VBS listener Yes Yes No
10.14 Inter MSC cell reselection of a VGCS listener Yes Yes No
10.15 Intra BTS handover of a point to point voice call No Yes No
10.16 Intra BTS handover of a circuit switched data call No Yes No 2.3.1
10.17 Intra BTS handover of a railway emergency call originator No Yes No
10.18 Intra BTS handover of a VGCS call uplink No Yes No
10.19 Intra BTS handover of a VGCS dedicated channel No Yes No
10.20 Intra BTS handover of a VBS originator No Yes No
10.21 Inter BTS handover of a point to point voice call No Yes No
10.22 Inter BTS handover of a circuit switched data call No Yes No 2.3.1
10.23 Inter BTS handover of a railway emergency call originator No Yes No
10.24 Inter BTS handover of a VGCS call uplink No Yes No
10.25 Inter BTS handover of a VGCS dedicated channel No Yes No
10.26 Inter BTS handover of a VBS originator No Yes No
10.27 Inter BSC handover of a point to point voice call No Yes Yes


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
10.28 Inter BSC handover of a circuit switched data call No Yes Yes 2.3.1
10.29 Inter BSC handover of a railway emergency call originator No Yes Yes
10.30 Inter BSC handover of a VGCS call uplink No Yes Yes
10.31 Inter BSC handover of a VGCS dedicated channel No Yes Yes
10.32 Inter BSC handover of a VBS originator No Yes Yes
10.33 Inter MSC handover of a point to point voice call Yes Yes No
10.34 Inter MSC handover of a circuit switched data call Yes Yes No 2.3.1
10.35 Inter MSC handover of a railway emergency call originator Yes Yes No
10.36 Inter MSC handover of a VGCS call uplink Yes Yes No
10.37 Inter MSC handover of a VGCS dedicated channel Yes Yes No
10.38 Inter MSC handover of a VBS originator channel Yes Yes No
10.39 Intra BTS handover failure of a point to point voice call (pre-
No Yes No
10.40 Intra BTS handover failure of a circuit switched data call (pre-
No Yes No 2.3.1
10.41 Intra BTS handover failure of a railway emergency call originator
(DCH) (pre-emption Um-IF not possible)
No Yes No
10.42 Intra BTS handover failure of a VGCS dedicated channel (pre-
No Yes No
10.43 Intra BTS handover failure of a VBS originator (pre-emption Um-IF
not possible)
No Yes No
10.44 Inter BTS handover failure of a point to point voice call (pre-
No Yes No
10.45 Inter BTS handover failure of a circuit switched data call (pre-
No Yes No 2.3.1
10.46 Inter BTS handover failure of a railway emergency call originator
No Yes No
10.47 Inter BTS handover failure of a VGCS dedicated channel (pre-
No Yes No
10.48 Inter BTS handover failure of a VBS originator (pre-emption Um-IF
not possible)
No Yes No


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
10.49 Inter BSC handover failure of a point to point voice call (pre-
No Yes Yes
10.50 Inter BSC handover failure of a circuit switched data call (pre-
No Yes Yes 2.3.1
10.51 Inter BSC handover failure of a railway emergency call originator
No Yes Yes
10.52 Inter BSC handover failure of a VGCS dedicated channel (pre-
No Yes Yes
10.53 Inter BSC handover failure of a VBS originator (pre-emption Um-IF
not possible)
No Yes Yes
10.54 Inter MSC handover failure of a point to point voice call (pre-
Yes Yes No
10.55 Inter MSC handover failure of a circuit switched data call (pre-
Yes Yes No 2.3.1
10.56 Inter MSC handover failure of a railway emergency call originator
Yes Yes No
10.57 Inter MSC handover failure of a VGCS dedicated channel (pre-
Yes Yes No
10.58 Inter MSC handover failure of a VBS originator (pre-emption Um-IF
not possible)
Yes Yes No
10.59 Point to Point call performing intra BTS handover followed by a
inter BTS and a inter BSC handover
No Yes Yes
10.60 Ongoing point to point voice call in the destination cell pre-empted
(Um-IF) by a intra BTS handover of a point to point voice call
No Yes No
(Um-IF) by a intra BTS handover of a circuit switched data call
No Yes No 2.3.1
(Um-IF) by a intra BTS handover of a railway emergency call origi-
nator (DCH)
No Yes No
(Um-IF) by a intra BTS handover of a VGCS dedicated channel
No Yes No
(Um-IF) by a intra BTS handover of a VBS originator
No Yes No


TC
Index
Test case Scenario
I
Scenario
II
Scenario
III
FRS V7 SRS V15
(Um-IF) by a inter BTS handover of a point to point voice call
No Yes No
(Um-IF) by a inter BTS handover of a circuit switched data call
No Yes No 2.3.1
(Um-IF) by a inter BTS handover of a railway emergency call origi-
nator (DCH)
No Yes No
(Um-IF) by a inter BTS handover of a VGCS dedicated channel
No Yes No
(Um-IF) by a inter BTS handover of a VBS originator
No Yes No
(Um-IF) by a inter BSC handover of a point to point voice call
No Yes Yes
(Um-IF) by a inter BSC handover of a circuit switched data call
No Yes Yes 2.3.1
(Um-IF) by a inter BSC handover of a railway emergency call origi-
nator (DCH)
No Yes Yes
(Um-IF) by a inter BSC handover of a VGCS dedicated channel
No Yes Yes
(Um-IF) by a inter BSC handover of a VBS originator
No Yes Yes
(Um-IF) by a inter MSC handover of a VBS originator
Yes Yes No
10.76 Inter BSC handover of a point to point voice call with eMLPP pre-
emption at A-IF
No Yes Yes 2.4.1 2.4.1
10.77 Inter BSC handover of a circuit switched data call with pre-emption
with eMLPP pre-emption at A-IF
No Yes Yes 2.4.1 2.4.1
10.78 Inter BSC handover of a railway emergency call originator with
eMLPP pre-emption at A-IF
No Yes Yes 2.4.1 2.4.1
10.79 Inter BSC handover of a VGCS dedicated channel with eMLPP
pre-emption at A-IF
No Yes Yes 2.4.1 2.4.1
10.80 Inter BSC handover of a VBS originator with eMLPP pre-emption
at A-IF
No Yes Yes 2.4.1 2.4.1



Table 6.1: Overview of the IOT test cases


6.1.2 Cross reference of EIRENE FRS V7 mandatory requirements to the IOT test cases

Chapter Subject Linked test case
1 Introduction
1.1 General
1.2 Scope
1.3 Applicability
1.4 System overview 8.14
(1.4.1.1)
8.15
(1.4.1.1)

1.5 Structure of the specification
2 Network requirements
2.1 Introduction
2.1.1 The network services necessary to meet the range of
UIC requirements are detailed below. These services
are to be considered as a minimum set for implementa-
tion within each UIC standard network. Railways may
implement additional network services as desired. (I)

2,2 Voice services
2.2.1 This section describes the generic voice telephony ser-
vices which are to be supported by the EIRENE net-
work: (M)

point-to-point voice calls; 1.7 1.8 1.9 1.29 1.30 1.31
public emergency voice calls; 1.49 1.50 1.51 1.45 1.52 1.53 1.48
broadcast voice calls; 9.1 8.13
group voice calls 8.1 8.17 8.2 8.3 8.20 6.8
6.20-6.27
8.13
8.38-8.45
9.28-9.33
9.34-9.35
multi-party voice calls. 1.14 1.45 1.17 1.36
2.2.2 All voice call services shall be able to operate between
any combination of fixed and mobile equipment users.
(M)
5.6 1,8 various
other
TCs

Point-to-point voice calls


2.2.3 The system shall support point-to-point voice calls be-
tween any two call parties. (M)
1.7 1.8 1.9 1.29 1.30 1.31
2.2.4 Such point-to-point calls shall allow both parties to talk
simultaneously. (M)
1.7 1,8 1.9 1.29 1.30 1.31
Public emergency voice calls
2.2.5 The system shall allow a user to make public emer-
gency point-to-point voice calls. (M)
1.49 1.50 1.51 1.45 1.52 1.53 1.48
2.2.6 Such emergency calls include 112 calls and may not
be used for railway emergencies. (I)

Broadcast voice calls
2.2.7 The system shall support broadcast voice calls. (M) 9.1 8.13
2.2.8 Broadcast voice calls provide one-way voice communi-
cations from a single user to multiple users in a pre-
defined local area, all of whom are members of the
same call group. (I)

2.2.9 The composition of call groups shall be able to be modi-
fied within the network. A single user shall be able to be
a member of one or more call groups. (M)
9.36 9.37 7.6
2.2.10 The local area over which broadcast calls shall be im-
plemented shall be able to be modified within the net-
work. (M)
9.2
2.2.11 It shall only be possible for the user who initiated the
call to talk, other users can only listen. (M)
9.1
Group voice calls
2.2.12 The system shall support group voice calls. (M) 8.1
2.2.13 Group voice calls provide voice communications be-
tween a number of users in a pre-defined local area, all
of whom are members of the same call group. (I)

2.2.14 The composition of call groups shall be able to be modi-
fied within the network. A single user shall be able to be
a member of one or more call groups. (M)
8.46 8.47 7.17
2.2.15 The local area over which group calls are implemented
shall be able to be modified within the network. (M)
8.1


2.2.16 It is acceptable that only one mobile user involved in the
group call may talk at any time. In this case:

It shall be possible for controllers to speak at any time
during the call. (M)
8.1 8.30-8.34
A mechanism shall be provided by the system to arbi-
trate between those users wishing to speak within the
group call. (M)
8.33
Multi-party voice calls
2.2.17 The system shall support multi-party voice communica-
tions between up to six different parties. (M)
1.14 1.36
2.2.18 Any of the parties involved in a multi-party voice call
shall be able to talk simultaneously. (M)
1.14 1.36

2,3 Data services
2.3.1 The EIRENE network will provide data services to sup-
port the following data applications:

text messages; (O)
general data applications; (M) 1.16 1.38
automatic fax; (O)
train control applications. (O)
Text messages
2.3.2 The network should support the transmission of point-
to-point and point-to-multipoint text messages from the
ground to mobile users. (O)

2.3.3 The network should support the receipt of mobile-
originated text messages by the ground. (O)

2.3.4 If the text message facility is implemented, it shall not
interfere with the ability of users to make or receive high
priority voice or data calls. (M)

General data applications
2.3.5 Support is required for a range of data communications
between the ground and mobile users. Such applica-
tions may include: (I)


timetable information;
maintenance and diagnostic applications;
e-mail;
remote database access.
2.3.6 The network shall support point-to-point data communi-
cations. (M)
1.16 1.38
2.3.7 Deleted.
2.3.8 The network shall support data rates of at least 2.4
kbit/s. (M)
1.16 1.38
2.3.9 Higher data rates will be required by some data applica-
tions in order to provide the necessary performance and
acceptable transmission times. (I)

2.3.10 The priority scheme for calls described in section 10.2
is also valid for data applications. (I)

Automatic fax
2.3.11 The network should support fax transmissions between
the ground and mobile users. (O)

2.3.12 Where fax functionality is provided, it shall be possible
to interrupt the fax to make or receive a high priority
voice or data call. (M)

Train control applications
2.3.13 Where ERTMS/ETCS level 2 or 3 is implemented, the
network shall be capable of supporting data communi-
cations for that train control system. (M)
1.16 1.38
2.3.14 The communications requirements for ERTMS/ETCS
are included in the document Summary of ERTMS
Communications Requirements6. (I)

2.3.15 Communications for train control may be characterised
as low data rate per train; however, in some areas there
will be a high density of trains requiring simultaneous
communications. (I)

2.3.16 The priority scheme for calls described in section 10.2
is also valid for train control applications. (I)



2,4 Call related services
2.4.1 The EIRENE network will support the following call re-
lated services:

display of identity of called/calling user; (M) 1.12 1.34
restriction of display of called/calling user; (O)
priority and pre-emption; (M) 1.16 1.17 1.38 1.39 7.1-7.51 5.1 5.9-5.13 10.76-
10.80
closed user group; (M) 1.46 1.47 1.45
call forwarding; (M) 1.12 1.15 1.43 1.37 1.18 1.40
call hold; (M) 1.10 1.32
call waiting; (M) 1.11 1.33
charging information; (O)
call barring. (M) 1.59 1.47
Display of identity
2.4.2 It shall be possible for the equipment to display the
identity of the called or calling party in the form of a
standard telephone number. (M)
1.12 1.34 1.37
2.4.3 It shall be possible to display the identity of the called or
calling party as a textual description of their function.
(M)
2.24 2.26
Restriction of display of identity
2.4.4 It should be possible for the network to prevent the
identity of certain users from being displayed on the
mobile, either when being called, calling or both. (O)

Priority and pre-emption
2.4.5 The network shall provide a mechanism whereby calls
may be assigned one of a number of different priority
levels. (M)
1.16 1.17 1.38 1.39 7
2.4.6 This mechanism shall allow calls with a higher assigned
priority to override (pre-empt) existing calls of a lower
priority. (M)
5 7.1-7.49


2.4.7 Pre-empted calls will be discontinued and the new call
of a higher priority shall be connected instead. (M)
5 7.1 - 7.49
Closed user group
2.4.8 The group of users who may access the facilities of the
EIRENE network shall be limited. (M)
1.46 1.47 1.45
2.4.9 Any user who is not within the list of allowed EIRENE
users shall not be able to gain access to any of the
functions and services provided by the network. (M)
1.46 1.47 1.45
Call forwarding
2.4.10 It shall be possible for an incoming call or data mes-
sage for one user to be forwarded to another user using
functionality provided by the network. (M)
1.15 1.18 1.43 1.46
2.4.11 In the case of voice calls, it shall be possible for the
user who is attempting to forward a call to converse
with the intended recipient prior to forwarding. (M)
1.15 1.18 1.43 1.46
2.4.12 There are a number of sub-classes of call forwarding to
be supported by the network:

automatically forward the incoming call without any user
interaction (unconditional); (M)
1.12 1.34
automatically forward the incoming call without user
interaction if the user is busy in an existing call (busy);
(M)
1.15 1.37 1.18 1.40
automatically forward the incoming call if there is no
reply from the intended recipient (no reply); (O)

automatically forward the incoming call if the intended
recipient cannot be contacted via the network (not
reachable). (O)

Call hold
2.4.13 The network shall allow the user to temporarily exit from
an existing call by putting the call on hold. (M)
1.10 1.32
2.4.14 It shall be possible for the user to re-join the call which
is on hold at any time. (M)
1.10 1.32
Call waiting


2.4.15 The network shall provide the ability to inform a user,
who is involved in an existing call, of attempts by other
users to contact them. (M)
1.11 1.33
Charging information
2.4.16 Where network services are chargeable, it should be
possible for the network to provide information about
call rates and on-going call charges. (O)

Call barring
2.4.17 It shall be possible, using network management or
maintenance facilities, to prevent individual users from:
(M)
making calls to:
another network (fixed or mobile) (eg can only call on
home network);
certain types of numbers within or external to the
network (eg cannot call teleshopping numbers);
certain pre-defined telephone numbers (eg cannot
call drivers and on-train users);
receiving calls from:
all other networks (fixed or mobile);
certain other networks (fixed or mobile);
certain types of numbers within or external to the
network;
certain pre-defined telephone numbers.
1.59 1.47 3.5 3.6
2.5 Railway specific services
2.5.1 The EIRENE network shall also provide support for the
following railway specific services:

functional addressing including registra-
tion/deregistration (see section 11); (M)
2.1, 2.5
location dependent addressing (see section 11); (M) 4.1 - 4.4
shunting mode (see section 14); (M) Absent. It is irrelevant to the network infrastructure, unnecessary to test
Railway emergency calls (see section 13). (M) 6
3 Network Configuration


3,1 Introduction
3.1.1 This section describes the requirements for the EIRENE
network and the performance levels which are to be
achieved. The aim is to provide interoperability between
networks and a consistent level of service. (I)

3.1.2 It may be necessary to supplement this Functional Re-
quirements Specification with special requirements for
supporting the train control application. Further informa-
tion on the communications requirements to support
ERTMS can be found in the Summary of ERTMS
Communication Requirements document 6. (I)

3,2 Coverage and performance
3.2.1 For network planning, the coverage level is defined in
terms of time and area where the minimum signal crite-
ria are achieved. (I)

3.2.2 The level of coverage should be at least 95% of the
time over 95% of the designated coverage area for a
radio installed in a vehicle with an external antenna. (O)

3.2.3 The network shall support all EIRENE-compliant mo-
biles. (M)
1,8 2.24 4.1 7.1 8.1 9.1
3.2.4 The land-based part of the system shall provide com-
munications for mobiles when stationary and when
travelling at speeds up to the maximum allowable line
speed or 500 km/h, whichever is the lower. (M)
Not applicable
3,3 Network interconnection
3.3.1 (Network selection requirements for mobiles have been
moved to sections 5, 6 and 7)

3.3.2 Deleted.
3.3.3 Network interconnection is subject to a bilateral agree-
ment between network
operators. The interconnection between the networks
must, as a minimum, be
compliant with applicable open specifications. (I)


3.3.4 During the process of moving from one GSM-R network
to another, the system must
minimise the inconvenience to the user. (I)

3,4 Call set-up time requirement Part of a new part (sub part)
3.4.1 Call set-up time requirements are dependent mainly
upon priority (see section 10.2). (I)

3.4.2i The requirements for end-to-end call set-up perform-
ance are indicated in table 3-1. (I)

Call type
Call set-up time

Railway emergency calls <2s* Part of a new part (sub part)
Group calls between drivers in the same area <5s Part of a new part (sub part)
All operational mobile-to-fixed calls not covered by the
above <5s

All operational fixed-to-mobile calls not covered by the
above <7s

All operational mobile-to-mobile calls not covered by the
above <10s

All low priority calls <10s
3.4.2 The required call set-up times shall be achieved in 95%
of cases. (M)
Part of a new part (sub part)
3.4.3 Call set-up times for 99% of cases shall not be more
than 1.5 times the required call set-up time. (M)
QoS is outside the IOTs
3.4.4 Set-up times shall include the time required for any
translation of functional numbers internal to the EIRENE
network. (M)
3,5 Broadcast and group call areas
3.5.1 Where fixed network users are involved in a group or
broadcast call, fixed network users will be pre-defined
and will not change during the course of the call. (I)


3.5.2 The group or broadcast call area used will have the
effect of determining which mobiles can participate in
the call (ie those currently within the area defined). It
shall be possible to determine the area over which the
call takes place by one, or a combination, of the follow-
ing: (M)
8.1 8.3 8.27 9.1 9.10 9.4 9.5 8.13
The location of the call initiator (if mobile-originated);
The identity of the group being called (eg all users, all
trains, etc);

A prefix to the group identity specifying the call area (if
fixed network-initiated).

3.5.3 Any group or broadcast calls initiated in a given location
shall be broadcast over an associated area based on
the location of the call originator, and also to any fixed
network numbers associated with the originating loca-
tion. (M)
8.1 8.3 8.30 9.1 9.10 9.4 9.7 8.13
3.5.4 The definition of each broadcast or group call area
should take into account factors such as the speed of
trains on the line (stopping distance) and the opera-
tional control areas. (O)

3.5.5 It is acceptable that mobiles which move out of the call
area during the call shall be dropped from the call. (I)

3.5.6 Mobiles configured for reception of railway emergency
calls entering into a call area where a railway emer-
gency call is ongoing shall automatically join this call.
(M)
Terminal feature
3.5.7 Cab Radios configured for reception of a call to all driv-
ers in the same area entering an area where a call to all
drivers in the same area is ongoing shall automatically
join this call unless involved in a higher priority call or
involved in a call of the same priority.(M)
8.5 Open issue (see 3.5.8)
3.5.8 Requirement 3.5.7 needs further technical specification
changes before field implementation can be achieved.
(I)

4 Mobile equipment core specification Outside the IOTs


4,1 Introduction
4.1.1 All EIRENE mobiles are specified with a common level
of basic services, facilities and features. This section of
the specification gives details of these core require-
ments, while sections 5, 6 and 7 detail requirements
specific to each of the radio types.

4.1.1i Where there are mandatory requirements for human-
machine interface attributes that are not defined in this
specification, the decision for the way of presentation is
a national issue. In any case, these national solutions
must not conflict with those of the CENELEC Standard,
in particular for the actions required from the drivers of
trains passing the borders.

4.1.2 Three distinct mobile radio types are required, based
on the type of role they will perform and the environ-
ment in which they will operate, as follows: (I)
a) Cab radio for use by the driver of a train and/or by
other on-train systems, eg ERTMS/ETCS;
b) General purpose radio for general use by railway
personnel;
c) Operational radio for use by railway personnel in-
volved in train operations such as shunting and track-
side maintenance.

4.1.3 It shall be possible to operate all mobiles in the fre-
quency bands around 900 MHz, allocated for use by the
railways, and in the public GSM networks.

4.1.4 Mobile equipment shall function correctly when travel-
ling at speeds from 0 km/h to 500 km/h.

4,2 Services and facilities
4.2.1 The following voice telephony services, identified in
section 2, are to be supported for each type of mobile
radio:

Cab radio


Group voice calls
General purpose radio
Group voice calls
Operational radio
Group voice calls
4.2.2 The following data applications, identified in section 2,
are to be supported for each type of mobile radio:

Cab radio
Text message service
Automatic fax
Automatic fax


Operational radio
Automatic fax
4.2.3 The following call related services are to be supported
for each type of mobile radio:

Cab radio
Display of calling user identity
Display of called user identity
Restriction of display of user identity
EIRENE closed user group
Call forwarding:
- unconditional M
- if user busy O
- if no reply O
- if not reachable O

Call hold
Call waiting
Display of call charging information
Call barring
Auto answer service
Call supervisory information
Call forwarding:


- unconditional O
- if user busy O
- if no reply O

Call hold
Call waiting
Call barring
Auto answer service
Operational radio
Call forwarding:
- unconditional O
- if user busy O
- if no reply O

Call hold
Call waiting
Call barring
Auto answer service
4.2.4 The following EIRENE features are to be supported for
each type of mobile radio:

Cab radio
Functional addressing (section 11)


Location dependent addressing
(section 11)

Direct mode (section 15)
Shunting mode (section 14)
Multiple driver communications within the same train
(section 5)

Railway emergency calls(section 13)
(section 11)

(section 5)

Operational radio
(section 11)

(section 5)

4,3 Environmental and physical requirements
5 Cab radio Outside the IOTs
5,1 Introduction


5.1.1 This section identifies the functional requirements for
the EIRENE Cab radio. It covers the functionality pro-
vided by the Cab radio, driver MMI and support to other
on-train systems. (I)

5.1.2 Moreover, a driver may be provided with a handheld
portable to allow communications whilst the driver is
outside the train. (O)

5,2 Functional requirements
5.2.1 Summary
5.2.1.1 In this subsection, the functions to be provided by the
Cab radio are described. (I)

5.2.1.2 The following functions will be provided:
Driver call-related functions:
call controller: (M)
primary controller;
secondary controller;
power supply controller;

call other drivers in the area; (M)
send Railway emergency call; (M)
confirm receipt of Railway emergency call; (M)
communicate with other drivers on same train; (M)
call train staff; (M)
call other authorised users; (M)
receive incoming voice calls; (M)
terminate calls; (M)
receive text messages; (M)
enter/leave shunting mode; (M)
enter/leave direct mode; (O)
monitor calls to other on-train users/devices; (M)
forward calls/cancel call forwarding to/from driver
handheld; (O)


Other driver-related functions:
powering up radio; (M)
switch radio MMI on and off; (M)
select language; (M)
adjust loudspeaker volume; (M)
select mobile radio network; (M)
register and deregister train number; (M)
register and deregister on-train users; (O)
register and deregister stock number; (M)
store/retrieve numbers and their details; (M)
invoke supplementary services; (M)
invoke tests; (M)
Other Cab radio functions:
automatic connection of incoming calls to appropriate
on-train users or devices(conductor, public address
system, data systems, etc); (M)

automatic establishment of outgoing calls initiated by
on-train users or devices; (M)

automatic handling of calls of varying priorities; (M)
send to the controller(s) a signal on activation of
driver safety device; (M)

transmit Railway emergency call event indication to
train-borne recorder; (M)

run-time diagnostics. (O)
5.2.2 Driver call related functions
5.2.2i Once a call has been established the connected parties
shall be able to communicate.
(M)

5.2.2ii Picking up the handset shall transfer the communication
to the handset and reduce the loudspeaker volume to
its minimum level. (M)


5.2.2iii Replacing the handset either: (M)
cancels the call; or
transfers the call to the loudspeaker at the initial vol
ume.

5.2.2iv A Push-To-Talk function shall be provided for use dur-
ing group calls. (M)

5.2.2v The use of Push-To-Talk for all types of communica-
tions is acceptable if needed for ergonomic reasons or
to avoid the noise of the cab being transmitted to the
other party.
(I)

Call controller
5.2.2.1 It shall be possible for the driver to initiate a call to any
of the following types of
controller with a minimum of driver action being re-
quired (eg a single keystroke): (M)
primary controller;
secondary controller;
power supply controller.

5.2.2.2 If the radio system cannot give a unique identity for a
given type of controller, the
identity could be obtained using external systems as
defined in 11.4.7. (I)

5.2.2.3 Once an appropriate destination has been obtained, the
radio shall attempt to establish
a call to this destination. The functional identity shall be
displayed to the controller.
(M)

5.2.2.3i The functional identity includes the following:
the train number, if available; (M)
the engine number, if no train number is available;
(M)

the coach number of the leading cab, if neither a train
number nor an enginenumber is available. (O)


5.2.2.4 An audible and visual indication shall be provided to the
driver that the call is proceeding. (M)

5.2.2.5 When the call is connected to the controller, an audible
and visual indication is to be provided to the driver. The
call shall be connected to the loudspeaker at the pre-set
value. (M)

5.2.2.6 The functional identity of the connected party, if avail-
able, shall be displayed to the driver. (M)

5.2.2.7 If the functional identity of the connected party contains
an alphanumeric description,
this shall also be displayed. (M)

5.2.2.8 If the system is not able to connect the call, an audible
and visual indication shall be provided to the driver that
the call was not received by the controller. This shall
also indicate if the called party was busy or if the net-
work could not connect the call. (M)

Call other drivers in the area (on other trains)
5.2.2.9 It shall be possible for a driver to initiate and participate
in group voice calls between drivers in a pre-defined
geographical area. (M)

5.2.2.10 A driver shall be able to initiate the establishment of a
call to other drivers with a minimum of action (eg a sin-
gle keystroke). (M)

5.2.2.11 The group identity shall be displayed on the Cab radios
of the participating drivers.(M)

driver that the call isproceeding. (M)

5.2.2.13 Once connected, the driver shall be able to communi-
cate with other driver(s) by using the Push-To-Talk but-
ton on the handset. An indication shall be provided to
the driveras a reminder of the need to use the Push-To-
Talk button on the handset if he wants to talk. (M)

5.2.2.14 The call shall be connected to the loudspeaker until the
driver picks up the handset.(M)


5.2.2.15 The call shall continue until terminated by the calling
driver, an authorised controller or the network. (M)

5.2.2.16 If the train moves out of the group call area whilst the
call is in progress, an audibleand visual indication of the
loss of call shall be provided to the driver. (M)

and visual indication shall beprovided to the driver. (M)

Send Railway emergency call
5.2.2.18 It shall be possible for a driver to initiate Railway emer-
gency calls (see section 13). (M)

5.2.2.19 If a train-borne recorder is connected to the Cab radio,
details of the activation,termination and any failures of
the emergency function shall be sent to the train-borne
recorder as each event occurs. (M)

5.2.2.20 A continuous visual and short audible indication (from 0
to 20 seconds, for trials: 5 seconds) that the emergency
function has been activated shall be provided in the
cab.(Note that when the handset is off-hook, the audible
indication shall be sounded from the loudspeaker at a
low volume, but shall not be sounded from the hand-
set.) (M)

5.2.2.21 Once the Railway emergency call is connected and the
audible indication is finished, an indication shall be pro-
vided to the driver as a reminder of the need to use the
Push-To-Talk button on the handset if he wants to
speak. (M)

5.2.2.22 The call shall be connected to the loudspeaker until the
driver picks up the handset.(M)

5.2.2.23 If the train moves out of the call area whilst the call is in
progress, it will leave the call and an audible and visual
indication of the loss of call shall be provided to the
driver.(M)

5.2.2.24 Once the call is terminated, the continuous visual alarm
indication in the cab shall cease. (M)


and visual indication shall be
provided to the driver. (M)

Communicate with other drivers on same train
5.2.2.26 Many trains employ multiple active traction vehicles.
Where these vehicles are not connected by on-train
wire connections, it shall be possible for the lead driver
toestablish a permanent radio connection between each
of the active cabs. (M)

5.2.2.27 The call will be established from the active cab of the
lead traction vehicle. (I)

5.2.2.28 Whilst on-going, a multi-drivers indication shall be dis-
played permanently at all Cab radios. (M)

The lead driver shall be notified if a member of the
group has placed the call on hold, although this shall
not affect communications between the remaining
members of the group. (M)

5.2.2.30 At any time during the call, the lead driver shall be able
to remove a member of the group. (M)

5.2.2.31 The lead driver shall be able to terminate the entire call.
(M)

5.2.2.32 If a driver is disconnected from the multi-driver call, a
clear indication shall be given.(M)

5.2.2.33 The setting up and closing down of a multi-driver call
shall be simplified using automation or guidance
through the steps required. (M)

5.2.2.34 In each cab, the call shall be connected to the loud-
speaker whilst the handset is onhook.(M)

5.2.2.35 If any part of the call fails, an audible and visual indica-
tion shall be provided in the appropriate cab. (M)

5.2.2.36 If the call fails in the lead traction vehicle, the lead driver
will be responsible for reestablishing the call. If the call
fails to any other cab, the driver in that cab will call the
lead cab and request re-establishment of the call. (I)


5.2.2.37 For calls between a controller and the lead cab, it shall
be possible to add the controller to the multi-driver call.
Either the lead driver calls the controller or the controller
calls the lead driver. In the latter case, the controller is
automatically added into the multidriver call. Functional
identity of the controller shall be displayed in the leading
cab.(M)

Call train staff
5.2.2.38 It shall be possible for the driver to contact members of
on-board train staff using apoint-to-point voice call. (M)

5.2.2.39 Upon activation of this function, the Cab radio shall
provide the driver with a list ofgeneric staff, eg: (M)
chief conductor;
conductor 1;
conductor 2;
catering staff 1.

5.2.2.40 The driver shall then be prompted to select the train
staff with which he wishes to communicate. (M)

5.2.2.41 On many trains, staff may be connected by intercom or
internal telephone rather than by radio. It is required
that, in these cases, the Cab radio shall be integrated
with internal communication systems such that the ap-
propriate means of connection (wire or radio) will be
determined automatically. (M)

Call other authorised users
5.2.2.42 The Cab radio shall be capable of being used as a
standard telephone, such that the driver is able to call
any valid number subject to pre-defined call restrictions.
The call may be initiated by: (M)
selection from a pre-defined list (up to 99 entries);
direct dialling a subscriber number;
calling a functional number.

5.2.2.43 An audible and visual indication of an incoming call
shall be provided. (M)
6.20 6.23 8.38 8.41 6.20 9.28 9.31


5.2.2.44 The functional identity (which may contain an alphanu-
meric description) of the calling party, when available,
shall be displayed. (M)

5.2.2.45 Point-to-point calls that are not automatically answered
(see table 10-1) shall only be answered once the driver
accepts the call. (M)

5.2.2.46 Once the driver has accepted the standard point-to-
point call, it shall be connected appropriately, eg if the
driver has accepted the call by lifting the handset, then
the call shall be routed to the handset. (M)

Receive incoming group or broadcast voice call
5.2.2.47 An audible and visual indication of the incoming call
shall be provided when a Cab radio receives a group or
broadcast call. (M)
6.21 6.22 6.24-6.27 8.39-8.40 8.42-8.45 9.29-9.30 9.32-9.45
5.2.2.48 The group identity of the voice group call (VBS or
VGCS) shall be displayed. (M)

5.2.2.49 Group or broadcast calls shall automatically be con-
nected to the loudspeaker if the handset is not in use,
or to the handset if the handset is off hook. (M)

5.2.2.50 The driver shall be informed if a broadcast call is ongo-
ing by a visual indication displayed on the MMI. (M)

5.2.2.50i It is not possible for the driver to speak as part of the
call when receiving a broadcast call. (I)

5.2.2.51 If the call is a group call, the driver shall be required to
request permission before being able to speak as part
of the call by lifting the handset and pushing the Push-
To-Talk (PTT) button. (M)
8.26 8.30-8.34
5.2.2.52 During a group call, a visual indication shall be dis-
played on the drivers MMI to remind the driver of the
need to use the PTT button. (M)

5.2.2.53 The driver can not speak in a group call until permission
is granted by the network after pushing the PTT button.
(I)
8.26 8.30-8.34


5.2.2.54 In a group call, an audible and visual indication of
whether the request to talk was successful shall be
provided. The driver shall then be able to speak as part
of the call whilst the PTT button is pressed. (M)
8.26 8.30-8.34
5.2.2.55 If the train moves out of the group or broadcast call
area whilst the call is in progress, an audible and visual
driver. (M)

Receive incoming Railway emergency call
5.2.2.56 Reception of this call proceeds as for a standard group
or broadcast call, except that a distinctive audible and
visual indication shall be provided in the cab. (M)

5.2.2.57 If a train-borne recorder is connected to the Cab radio,
details of an incoming Railway emergency call shall be
transmitted to the train-borne recorder for recording,
see section 5.8. (M)

Confirm receipt of Railway emergency call
5.2.2.58 An automatic confirmation shall be generated by the
Cab radio at the end of the Railway emergency call as
detailed in section 13. (M)

5.2.2.59 Automatic confirmation of receipt of Railway emergency
calls will be used to provide a means of determining
which trains have received a Railway emergency call
(see section 13). (I)

Terminate calls
5.2.2.60 The Cab radio shall provide a means for the driver to
terminate calls which he is authorised to terminate (ie
all calls except Railway emergency calls not initiated by
the driver and shunting group calls). (M)

5.2.2.61 For group or broadcast calls, a means to leave the call
without terminating the call shall be provided. (M)

Receive text messages
5.2.2.62 The Cab radio system shall be able to receive incoming
text messages (see section 12 for details). (M)


Enter/leave shunting mode
5.2.2.63 The Cab radio shall support a shunting mode of opera-
tion that provides a link assurance tone to reassure
users of the integrity of the communication link (see
section 14). (M)

5.2.2.64 A means to enter and leave shunting mode shall be
provided. (M)

5.2.2.65 The functionality to enter and leave shunting mode shall
not be available when there are on-going calls involving
the Cab radio. (M)

5.2.2.66 The link assurance tone shall be provided via the loud-
speaker. (M)

5.2.2.67 If the Cab radio is equipped with an additional security
device, this audible indication may be muted for the
drivers convenience. In this case, the security device
alerts the driver if the link has failed or if it is cancelled.
(I)

Enter/leave direct mode
5.2.2.68 It should be possible for the Cab radio to be used with-
out the network service (if itshould fail or if there is no
authorised network coverage), such that local open
channel communications are still possible. This mode of
operation is termed direct mode (see section 15). (O)

5.2.2.69 If direct mode is implemented, a means to enter and
leave direct mode shall be provided. (M)

5.2.2.70 If the radio is in direct mode and the normal network
service returns, the user shall be provided with an audi-
ble and visual indication. (M)

Monitor calls to other on-train users/devices using the
Cab radio

5.2.2.71 Not all communications using the Cab radio will involve
the driver. Where these calls involve the Cab radio, the
driver shall be provided with an indication that the Cab
radio is busy. (M)


5.2.2.72 For voice calls using the Cab radio not involving the
driver as a called or calling party, the driver shall have
the possibility to listen to the audio output of the com-
munication.(M)

5.2.2.73 For voice communications, if the driver picks up the
handset, the radio shall allow him to join the communi-
cation. (M)

5.2.2.74 The driver shall be able to terminate communications
(voice or data) by selecting another call. (M)

Forward calls to driver handheld
5.2.2.75 Where the Cab radio is required by a national railway to
support a handheld portable, the Cab radio shall: (M)
provide a clear indication as to whether the handheld
portable is activated or not;
provide an interface to allow the handheld portable to
be recharged when not inuse;
forward calls automatically to the handheld portable
when the handheld portable is activated;
cancel any call forwarding to the handheld portable
when it is deactivated;
allow the driver to override the call forwarding to the
handheld portable.

5.2.3 Other driver-related functions
Powering up radio
5.2.3.1 Powering up the Cab radio will initiate the following:
automatic self-testing; (M)
automatic selection of the pre-set loudspeaker vol-
ume; (M)

registration with other on-train systems, such as
ERTMS/ETCS; (M)

all failures of self-tests should be recorded in the
train-borne recorder; (O)


connection of the Cab radio to an authorised mobile
network. This shall be the network to which the mobile
was last registered (where available); (M)

if connection is successful, the name of the network
shall be displayed on the MMI and an audible indica
tion of successful connection shall be given; (M)

if connection is not successful, an audible and visual
indication shall be provided.(M)

if connection is not successful, the manual network
selection procedure may be initiated by the driver
(see 5.2.3.23). (I)

5.2.3.2 At the point of successful connection, the Cab radio will
be able to receive all calls made using the Cab radios
telephone number, engine number or appropriate group
call numbers (including Railway emergency calls). (I)

5.2.3.3 Powering down the Cab radio shall cause the discon-
nection of the Cab radio from the mobile network. (M)

5.2.3.4 When switched off, the radio shall retain any numbers
which are stored at the time the radio is switched off.
(M)

Switch radio MMI on/off
5.2.3.5 The MMI on/off control shall be designed to prevent
accidental activation/ deactivation. (M)

5.2.3.6 Switching the MMI on shall cause the following: (M)
self test of MMI (eg transitory lighting of the display
and of all the controls and indicator lights of the MMI);
determination of the status of the Cab radio, providing
a display of radio status on the MMI.


5.2.3.7 When the MMI is switched on, the configuration shall be
determined by the time elapsed since the MMI was last
switched off: (M)
less than t minutes
the MMI shall power up with the same configuration
as when it was last powered down;
greater than t minutes
the MMI shall power up with default settings.

5.2.3.8 The time t should be able to be varied between 0 and
240 minutes, as a maintenance function, allowing the
radio to power up in a consistent state following minor
operational procedures or power interruptions. (O)

5.2.3.9 Switch off shall be soft so that the Cab radio com-
pletes the following housekeeping
functions before actually switching off: (M)
controlled termination of a current call;
deregister train number (where applicable);
store required data;
confirmation of Railway emergency calls (see section
13).

5.2.3.10 As far as possible, the above procedure should also
apply on power failure. (O)

5.2.3.11 When switched off, the following functions (if available)
shall still be provided: (M)
public address;
call Chief Conductor;
intercom.

Select language
5.2.3.12 It shall be possible to present radio related prompts and
information in a number of
different languages. (M)

5.2.3.13 By default, prompts and information shall be displayed
in the language selected by the
train owner (as stored within the system). (M)


5.2.3.14 It shall be possible for the user to display a list of avail-
able languages and select the language in which radio
related prompts and information are displayed both at
turn on and during a journey (eg where a change of
drivers may occur). (M)

5.2.3.15 The languages to be supported will be a matter for each
national railway to decide. (I)

5.2.3.16 The radio shall support at least ten different languages.
(M)

Adjust loudspeaker volume
5.2.3.17 By default, the loudspeaker volume shall be set to a
pre-determined level suitable for the operating environ-
ment (as stored within the system). (M)

It shall be possible for the driver to increase and de-
crease the loudspeaker volume within the adjustment
range selected. (M)

When the handset is picked up, the loudspeaker shall
continue to operate, but at a reduced volume level. (M)

Manual network selection
5.2.3.23 Using a simple MMI action, it shall be possible for the
driver to view a prioritised list of all authorised mobile
radio networks (see section 10.5). (M)

5.2.3.23i When presented with this list, it shall be possible for the
driver (using simple MMI actions) to select the required
mobile radio network manually, whereupon the Cab
radio shall attempt to attach to this selected network.
(M)

5.2.3.24 The manual network selection function shall not be
available when there are on-going voice calls involving
the Cab radio. (M)

5.2.3.25 A visual confirmation of the new network identity shall
be given to the driver when a manually initiated network
change has been completed successfully. (M)

5.2.3.25i Manual network selection is suitable for crossing inter-
national borders. (I)


Directed network selection
5.2.3.25ii The Cab radio should be capable of selecting the mo-
bile radio network as directed by input from an external
device (eg a balise). (O)

5.2.3.25iii If directed network selection is implemented and voice
calls are ongoing at the time when the external device
attempts to trigger a network change, an audible and
visual indication shall be given to the driver and network
change shall be deferred until the call is terminated or
until coverage of the current network is lost. (M)

5.2.3.25iv If directed network selection is implemented, input from
the external device(s) shall initiate the network change
regardless of the identity of the current network and
how it was selected. (M)

5.2.3.25v Directed network selection is suitable for crossing inter-
national borders. (I)

Automatic network selection
5.2.3.25vi The Cab radio should be capable of selecting the mo-
bile radio network automatically from a list of suitable
networks (see section 10.5). (O)

5.2.3.25vii If automatic network selection is implemented, it shall
be possible for the driver to activate and deactivate
automatic network selection. (M)

5.2.3.25viii Automatic network selection shall not be used for inter-
national border crossing. (M)

5.2.3.25ix Automatic network selection is not suitable for use in
areas where there is a risk that the Cab radio will
change to a foreign network unpredictably. (I)

5.2.3.25x If directed network selection and/or automatic network
selection are implemented, the driver shall be informed
by means of an audible and visual indication of the new
network identity whenever a network change takes
place without user intervention. (M)

Register and deregister train number


5.2.3.26 It shall be possible for the driver to register and deregis-
ter a train number in the following ways:

1) enter train number; (M)
2) initiate automated request (applicable only for lead-
ing driver). (O)

5.2.3.27 Where the driver is required to enter the train number
information, the information entered shall be shown on
the display and require confirmation by the driver before
further actions are possible. (M)

5.2.3.28 If an automated request is initiated (option 2), the driver
shall be able to accept or reject the train number re-
turned by the network. (M)

5.2.3.28i Where ERTMS/ETCS and radio systems are available
and the driver is required to enter the train number as
part of the initialisation procedure, this task shall be
carried out only once on the ERTMS/ETCS system and
the entered number transmitted to the radio system. (M)

5.2.3.28ii Data entry may be from either system depending on the
operating procedures agreed between the train operator
and the railway infrastructure operator. (I)

5.2.3.29 The driver shall be warned (by audible and visual indi-
cations) if a train with the same train number is already
registered on the same network. (M)

5.2.3.30 A means to override the currently registered train num-
ber shall be provided to the newly registering driver.
(M)

5.2.3.31 The driver of the previously registered train shall be
informed (by audible and visual indications) that his
train number has been overridden by another driver.
(M)

5.2.3.32 Where a change of train number is required during the
course of a train's journey, it shall be possible for the
driver to initiate the change or override the automatic
change. This shall be carried out by entering the train
number (option 1 in 5.2.3.26). (M)


5.2.3.33 Non leading drivers shall be able to indicate to the sys-
tem their location in the train during the registration
procedure (2nd driver, 3rd driver etc). (M)

Register and deregister on-train users (on-train func-
tions)

5.2.3.34 The drivers functional number shall be automatically
registered/deregistered when the train number is regis-
tered/deregistered. (M)

5.2.3.35 The functional number of other on-train users who may
be addressed through the Cab radio via the on-train bus
shall be registered/deregistered automatically at the
same time as the registration/deregistration of the
drivers functional number. (M)

5.2.3.36 Where an on-train bus is connected to the Cab radio,
deregistration of functional numbers can be performed
on an individual basis and also by the train driver, by
one action for all users (including the driver), at the end
of the journey when the train number is no longer asso-
ciated with the train. (O)

Register and deregister stock number (engine/coach
number)

5.2.3.37 There shall be a fixed relationship between the tele-
phone numbers of radios installed in the locomo-
tive/coach and the stock number, which shall remain
even if the radio is changed. (M)

5.2.3.38 It shall be possible to register and deregister a stock
number in one or both of the following ways: (M)
automatically using information from on-board sys
tems;
automatically via a fixed interface between the loco
motive/coach and the radio.

Store/retrieve numbers and their details
The Cab radio shall have a reconfigurable list of stored
numbers that may be used to perform abbreviated dial-
ling to named user identities. (M)


It shall be possible for the driver to find and display
stored numbers and their information. (M)

It should be possible for the driver to store and over-
write numbers and their details in the Cab radio. (O)

Invoke supplementary services
5.2.3.42 General MMI functions are required to support the fol-
lowing call functions:

forward call to the driver handportable; (O)
put a call on hold; (M)
display incoming call details whilst in an on-going call;
(M)

temporarily exit an existing call to answer another
incoming call; (M)

multi-driver call service. (M)
5.2.3.43 The actions required from the driver will be as simple as
possible. (I)

Invoke tests
5.2.3.44 It shall be possible to initiate tests of the radio to pro-
vide the driver with a reasonable level of certainty that
the radio and MMI are working. (M)

5.2.3.45 Such tests shall not prevent calls. (M)
5.2.3.46 The result of the tests shall be displayed in a similar
format to the self-test when MMI is powered on. (M)

5.2.4 Other Cab radio functions
Handle incoming/outgoing calls to/from appropriate on-
train users or devices

5.2.4.1 The Cab radio system may be required to be able to
handle incoming and outgoing calls not only to and from
the driver, but also to and from other on-train users and
devices (conductor, public address system, data sys-
tems, etc) via appropriate interfaces and ports. (I)

5.2.4.2 For data applications, calls shall be possible even if the
driver MMI is switched off. (M)


5.2.4.3 The Cab radio may need to conserve battery power
when the radio is powered up but the MMI is switched
off. (I)

Handling of call priorities
5.2.4.4 The Cab radio may be required to set up calls from a
number of different sources.
Therefore, the radio shall provide a priority function for
calls from different sources in order to handle conten-
tion for the radio. (M)

5.2.4.5 In order to meet other call priorities, established calls
shall be able to be either put on hold or cleared down
(pre-empted). (M)

5.2.4.6 The Cab radio shall be capable of handling contention
between calls of differing priorities. (M)

5.2.4.7 An outgoing call request of higher priority than an es-
tablished call shall take precedence over the estab-
lished call. (M)

5.2.4.8 Where pre-emption occurs, an advisory indication may
be provided to the pre-empted parties. (O)

5.2.4.9 Priority call handling facilities shall be provided such
that the performance requirements defined in sections
3.4 and 10.2 can be met. (M)

Run-time diagnostics
5.2.4.10 Upon the request of the driver, the Cab radio should be
able to perform a suite of runtime diagnostic tests on all
physical interfaces. (O)

5.2.4.11 If run-time diagnostics are implemented, failure of an
interface shall be reported to the
driver via the display. (M)

5.2.4.12 If run-time diagnostics are implemented, all failures
should be available to be recorded in a train-borne re-
corder. (O)

5.2.4.13 If run-time diagnostics are implemented, diagnostic
tests shall not interfere with normal operation of the Cab
radio. (M)


5.2.4.14 Railways will require facilities to support the use of
automatic test equipment with mobile radios. (I)

5,4 Driver man-machine interface
5.4.1 The driver man-machine interface shall comprise the
following components: (M)
display;
control panel;
loudspeaker;
handset with Push-To-Talk button.

5.4.2 Radio equipment installed in a drivers Cab shall not
obstruct the drivers vision or otherwise hinder the safe
driving of the train. (M)

5.4.2i The design of the equipment shall make it possible to
install it within a cab complying with the requirements of
UIC fiche 651 concerning the layout of cab equipment5.
(M)

5.4.3 All call related functions shall be possible with the
handset on or off the hook. (M)

5.4.4 Note: there is no requirement for hands free operation.
(I)

5.4.5 The driver shall be able to adjust the brightness of but-
tons, indicator lights and displays according to the am-
bient lighting in the cab. (M)

5.4.6 The driver shall be able to adjust the contrast of the
display. (M)

5.4.7 The emergency call button shall be red and shall be
protected against accidental use. (M)

5.4.8 Any displays shall be clearly readable from a normal
drivers position, assuming a normal reading distance.
(M)

5.4.9 Displayed characters shall have a minimum height of
5mm. (M)


5.4.10 The following colours shall only be used where man-
dated in 5.4.11: (M)
red;
green.

5.4.11 The standard set of audible and visual indications
specified in the CENELEC Standard for the Driver-
Machine Interface for ERTMS shall be implemented in
the Cab radio system. (M)

5.4.12 Deleted.
5.4.13 Some Cab radios may need to be operated by staff
wearing gloves and controls may need to be suitable for
use in a wide range of conditions, eg splash proof and
suitable for viewing in direct sunlight and in darkness.
(O)

5.4.14 Where there is a risk that stored numbers or other set-
up details may be accidentally changed, facilities should
be provided on the Cab radio in order to prevent this
happening. (O)

5.4.15 Cab radios shall provide a means of preventing tamper-
ing. (M)

Service availability
5.4.16 If contact with the mobile radio network is lost, then the
Cab radio shall give an audible and visual indication.
(M)

5,7 Driver safety device interface
5.7.1 A driver safety device (DSD) interface should be pro-
vided in traction units that are equipped with a DSD in
order to support the transmission of a DSD alarm. (O)

5.7.1i If such an interface is implemented, it shall be capable
of being connected to a device complying with UIC fiche
6413 concerning automatic vigilance devices used in
international traffic. (M)

5.7.2 The activation of the driver safety device shall auto-
matically trigger the Cab radio to send a data message.
(M)


5.7.3 The DSD alarm call/message shall provide the following
information:

train number; (M)
engine number; (M)
location information. (O)
5.7.4 DSD alarm information shall be transmitted to the pri-
mary controller. (M)

5.7.5 Additional information may also be provided if available
from external systems. (O)

5,8 Train-borne recorder
5.8.1 The Cab radio shall be able to provide the following
information to a train-borne recorder or other equipment
via a standardised interface:

activation of Cab radio emergency call button; (M)
receipt of incoming Railway emergency call; (M)
termination of outgoing or incoming Railway emer
gency call; (M)

radio faults; (O)
driver safety device alarm message transmission; (M)
details of confirmation of Railway emergency call. (M)
5,9 Control/command interfaces
5.9.1 On-train mobiles shall provide a standardised interface
to ERTMS/ETCS. (M)

5.9.2 In addition, individual railways may have requirements
to interface to national control/command systems. (I)

5.10 Other interfaces
5.10.1 Other interfaces may be provided in the Cab radio sys-
tem. (O)

6 General purpose radio Outside the IOTs
6,1 Introduction


6.1.1 This section identifies the functional requirements for
General purpose radio. It covers the functionality to be
provided by the General purpose radio and the man-
machine interface (MMI) is also defined. (I)

6.2.1 Summary
6.2.1.1 In this section, the functions to be provided by the Gen-
eral purpose radio are described. (I)

Call related functions
send Railway emergency calls; (O)
receive Railway emergency calls; (O)
receive incoming calls; (M)
group and broadcast calls; (M)
Other functions
switch radio on and off; (M)
register and deregister functional numbers; (M)
computer interface. (O)
6.2.2 Call related functions
Call authorised users
6.2.2.1 The General purpose radio shall be capable of use as a
standard telephone, such that the user is able to call
any valid number subject to call restrictions enforced by
the network. (M)



6.2.2.2 The facility for a given General purpose radio to send a
Railway emergency call (see section 13) shall be de-
termined as a management function. (M)

6.2.2.3 A special MMI action shall be required for a General
purpose radio user to send a Railway emergency call.
(M)

6.2.2.4 It shall not be possible for any General purpose radio
user to send a Railway emergency call by dialling a
short code or telephone number. (M)

Receive incoming point to point voice call

6.2.2.6 Where available, the functional identity of the calling
party shall be displayed. (M)

6.2.2.7 A short audible and visual indication of the incoming call


6.2.2.9 If the call is a broadcast call, the user shall be informed
that he cannot speak as part of the broadcast call. (M)

6.2.2.10 If the call is a group call, the user has to request per-
mission to speak during the call by using the Push-To-
Talk (PTT) function. (M)
8.26 8.30-8.34
6.2.2.11 In a group call, a visual indication shall be provided to
remind the user of the need to use the PTT function.
(M)

6.2.2.12 The user may not speak in a group call until permission
is granted by the network after using the PTT function.
(I)
8.26 8.30-8.34
whether the request was successful shall be provided.
The user may then talk whilst the PTT function is used.
(M)
8.26 8.30-8.34


6.2.2.14 If the user moves out of the group or broadcast call
user. (M)

6.2.2.15 Reception of this call (if implemented) shall proceed as
for a standard group or broadcast call except that a
distinctive audible and visual indication shall be pro-
vided. (M)

Terminate calls
6.2.2.16 The radio shall provide a means for the user to termi-
nate calls which he is authorised to terminate (ie all
calls except broadcast or group calls not initiated by the
user). (M)

6.2.3 Other functions
Switch radio on and off
6.2.3.1 The radio shall have an on/off switch. Switching the
radio on shall initiate the following: (M)
transitory lighting of any display, controls or indicator
lights;
automatic self-testing;
if the self-test fails a visible and audible indication
shall be provided;
connection to a mobile network (see section 3.3);
shall be displayed and an audible confirmation of
successful connection shall be given;
indication shall be provided.

6.2.3.2 At this point, the radio will be able to receive all calls
initiated using the telephone number or appropriate
group call number. (I)


6.2.3.3 Switching the radio off shall cause the following: (M)
termination of all calls under the control of (ie initiated
by) the radio;
disconnection of the radio from the network;
clearing the display and inhibition of functions.

6.2.3.4 When switched off, the radio shall retain any settings
and numbers which are stored at the time the radio is
switched off. (M)

Select language
6.2.3.5 Prompts and messages shall be capable of being dis-
played in at least 10 languages (each railway will
choose which languages will be implemented). (M)

6.2.3.6 The user shall be able to select his preferred language
for the display; this setting shall be retained by the ra-
dio. (M)

6.2.3.7 When the radio is first powered on, the language that
appears on the display shall be the default one set by
the national railway. (M)

Select mobile radio network
6.2.3.8 Where more than one mobile radio network is available
for use by a mobile, the selection of the network to use
shall be automatic (see section 10.5). (M)

6.2.3.9 When the mobile changes network automatically, a
visual and audible indication shall be given. (M)

6.2.3.9i It shall be possible for a user to override the automatic
network selection manually.
This function shall not be available during calls. (M)

Register and deregister functional number
6.2.3.10 It shall be possible to register and deregister a func-
tional number in the following way:
Initiated by the user and transmitted to the ground:
user enters functional number which is transmitted to
the network. (M)

6.2.3.11 Where a change of functional number is required, it
shall be possible for the user to initiate the change. (M)


6.2.3.12 It shall be possible for the user to find and display
stored numbers and their
information. (M)

6.2.3.13 It shall be possible for the user to store and/or overwrite
numbers and their details in the radio. (M)

Computer interface
6.2.3.14 A standard data interface should be provided to allow a
computer to be connected to the radio. (O)

6.3 Environmental and physical requirements
6,4 Man-machine interface
6.4.1 General
6.4.1.1 The General purpose radio should comprise the man-
machine interface which includes the following compo-
nents: (O)
display;
control panel;
loudspeaker;
microphone.

6.4.1.2 The MMI should be suitable for use both by day and
night. (O)

6.4.2 Controls
6.4.2.1 The on/off control should be designed to prevent acci-
dental activation/deactivation.(O)

6.4.2.2 Facilities should be provided to adjust the loudspeaker
volume. (O)

6.4.2.3 A Push-To-Talk function shall be provided. The Push-
To-Talk function does not need to be a dedicated but-
ton. (M)

6.4.2.4 Four buttons should be provided for designated stored
numbers. These buttons need not be dedicated buttons.
(This facility is required to allow calls to specified users
to be initiated quickly.) (O)


6.4.2.5 Stored numbers and other set-up details should be
protected against accidental alteration. (O)

6.4.2.6 If the ability to initiate Railway emergency calls is im-
plemented in the radio, accidental initiation of a Railway
emergency call shall be prevented. (M)

6.4.3 Indications
6.4.3.1 A visual and audible indication shall be given when the
remaining capacity of the battery is such as to enable
only 10 minutes of full duplex call time. (M)

6.4.3.2 A network service availability indication shall be pro-
vided to the user. (M)

6.4.3.3 A visual indication shall be provided to the user if the
network service is no longer available. (M)

6.4.3.4 An audible indication should be provided to the user if
the network service is no longer available. (O)

7 Operational radio Outside the IOTs
7,1 Introduction
7,2 Operational radio functions
7.2.1 Summary
7.2.1.1 In this section, the functions to be provided by the Op-
erational radio are described. (I)

Call related functions
call authorised users; (M)
call controller; (M)
send Railway emergency calls; (M)
receive Railway emergency calls; (M)
receive incoming calls; (M)
group and broadcast calls; (M)
shunting mode communications; (O)


enter/leave direct mode; (O)
Other functions
switch radio on/off; (M)
register and deregister functional number; (M)
computer interface. (O)
7.2.2 Call related functions
Call authorised users
7.2.2.1 The Operational radio shall be capable of use as a
standard telephone, such that the user is able to call
any valid number subject to call restrictions enforced by
the network. (M)

Call controllers
7.2.2.2 It shall be possible for the user of an Operational radio
to establish a call with each of the following types of
controller (who are not permanently included in a shunt-
ing group) with a minimum number of actions being
required:

primary controller; (M)
secondary controller; (M)
power supply controller. (O)


7.2.2.3 For some users, particularly for shunting team leaders,
up to twenty valid numbers may be stored for one con-
troller type. In these cases, the identities of the control-
lers corresponding to these valid numbers shall be dis-
played with an audible and visual prompt for one to be
selected. The number of the controller selected shall
then be used to establish the call. If no selection is
made by the user within 10 seconds the radio shall
abandon the call attempt. (O)

7.2.2.4 Once an appropriate number has been obtained, the
radio shall attempt to establish a call to this number with
railway operation priority. (M)

user that the call is proceeding. (M)

7.2.2.6 When the call is connected to the controller, an audible
and visual indication shall be provided to the user. (M)

7.2.2.7 The functional identity of the connected party, if avail-
able, shall be displayed to the user. (M)

7.2.2.8 Where available, an alphanumeric description of the
identity of the connected party shall be displayed. (M)

and visual indication shall be provided to the user. (M)

7.2.2.10 The Railway emergency call shall be able to be initiated
using a single red button (see section 13). (M)

7.2.2.11 It should be possible, as a maintenance function, to
enable/disable the emergency call function. (O)

7.2.2.12 If the emergency call function is disabled, a visual indi-
cation and short audible indication shall be given when:

the radio is switched on; (M)
the emergency button is pushed (in this case nothing
else will happen). (M)

Receive incoming point to point voice call


7.2.2.14 Where available, the functional identity of the calling
party shall be displayed. (M)

7.2.2.15 A short audible and visual indication of the incoming call


7.2.2.17 If the call is a broadcast call, the user shall be informed
that he cannot speak as part of the broadcast call. (M)

7.2.2.18 If the call is a group call, the user has to request per-
mission to speak during the call by using the Push-To-
Talk (PTT) function. (M)
8.26 8.30-8.34
7.2.2.19 In a group call, a visual indication shall be provided to
remind the user of the need to use the PTT function.
(M)

7.2.2.20 The user may not speak in a group call until permission
is granted by the network after using the PTT function.
(I)
8.26 8.30-8.34
whether the request was successful shall be provided.
The user may then talk whilst the PTT function is used.
(M)
8.26 8.30-8.34
7.2.2.22 If the user moves out of the group or broadcast call
user. (M)

7.2.2.23 Reception of this call shall proceed as for a standard
group or broadcast call except that a distinctive audible
and visual indication shall be provided. (M)

Terminate calls
7.2.2.24 The radio shall provide a means for the user to termi-
nate calls which he is authorised to terminate (ie all
calls except broadcast or group calls not initiated by the
user). (M)


Shunting mode communications
7.2.2.25 The Operational radio should provide facilities to sup-
port shunting mode as described in section 14. (O)

7.2.2.26 If shunting mode is implemented, a means to enter and
leave shunting mode shall be provided. (M)

7.2.2.27 If shunting mode is implemented, the functionality to
enter or leave shunting mode shall not be available
whilst there are on-going calls involving the Operational
radio. (M)

7.2.2.28 If shunting mode is implemented, the link assurance
tone shall be provided via the loudspeaker. (M)

Direct mode
7.2.2.29 A means to enter/leave the direct mode of operation
should be provided (see section 15). (O)

7.2.3 Other functions
Switch radio on and off
7.2.3.1 The radio shall have an on/off switch. Switching the
radio on shall initiate the following: (M)
transitory lighting of any display, controls or indicator
lights;
automatic self-testing;
if the self-test fails a visible and audible indication
shall be provided;
connection to a mobile network (see section 3.3);
shall be displayed and an audible confirmation of
successful connection shall be given;

7.2.3.2 At this point the radio should be able to receive all calls
initiated using the telephone number or appropriate
group call number. (I)


7.2.3.3 Switching the radio off shall cause the following: (M)
termination of all calls under the control of (ie initiated
by) the radio;
disconnection of the radio from the network;
clearing the display and inhibition of functions.

7.2.3.4 When switched off, the radio shall retain any settings
and numbers which are stored at the time the radio is
switched off. (M)

Select language
7.2.3.5 Prompts and messages shall be capable of being dis-
played in at least 10 languages (each railway will
choose which languages will be implemented). (M)

The user shall be able to select his preferred language
for the display; this setting shall be retained by the ra-
dio. (M)

When the radio is first powered on, the language that
appears on the display shall be the default one set by
the national railway. (M)

Select mobile radio network
7.2.3.8 Where more than one mobile radio network is available
for use by a mobile, the selection of the network to use
shall be automatic (see section 10.5). (M)

7.2.3.9 When the mobile changes network automatically, a
visual and audible indication shall be given. (M)

7.2.3.9i It shall be possible for a user to override the automatic
network selection manually. This function shall not be
available during calls. (M)

7.2.3.10 It shall be possible to register and deregister a func-
tional number in the following way:
Initiated by the user and transmitted to the ground:
user enters functional number which is transmitted to
the network. (M)

7.2.3.11 Where a change of functional number is required, it
shall be possible for the user to initiate the change. (M)


7.2.3.12 It shall be possible for the user to find and display
stored numbers and their information. (M)

7.2.3.13 It shall be possible for the user to store and/or overwrite
numbers and their details in the radio. (M)

Computer interface
7.2.3.14 A standard data interface should be provided to allow a
computer to be connected to the radio. (O)

7,4 Operational radio man-machine interface
7.4.1 Introduction
7.4.1.1 The Operational radio MMI shall comprise the following
components: (O)
display;
control panel;
loudspeaker;
microphone.

7.4.1.2 The MMI should be suitable for use both by day and
night. (O)

7.4.2 Display
7.4.2.1 The display shall be capable of displaying at least 6
lines, each of 20 characters. (M)

7.4.3 Controls
7.4.3.1 Four buttons should be provided for designated stored
numbers. (This facility is required for calls to local con-
trollers, etc.) (O)

7.4.3.2 The emergency button shall be designed to avoid acci-
dental use. (M)

7.4.3.3 If shunting mode is implemented, the link assurance
button shall be designed to avoid accidental use. (M)

7.4.3.4 A dedicated Push-To-Talk button shall be provided. (M)
7.4.4 Indications


7.4.4.1 A visual and audible indication shall be given when the
remaining capacity of the battery is such as to enable
only 10 minutes of full duplex call time. (M)

7.4.4.2 A visual indication shall be provided to the user if the
network service is no longer available. (M)

7.4.4.3 An audible indication should be provided to the user if
the network service is no longer available. (O)

8 Controller equipment specifications Outside the IOTs
8,1 General
8,2 Primary controllers MMI
8.2.1 The primary controllers MMI should provide the follow-
ing functionality: (O)
Queue all incoming calls or call requests.
Display the queue to the controller, showing the func
tional identity and priority of callers. High priority calls
should be identified and presented at the top of the
queue.
Allow the controller to select any of the incoming calls
currently queued by the system.
Allow the controller to establish a call of Railway
emergency, public emergency or railway operation
priority to any mobile by selection from the display.
Allow the controller to establish, close, enter and lea
ve group calls (at Railway emergency, public emer
gency or railway operation priority).
Allow sending and receiving of text messages.

8.2.2 For post incident analysis, the controller equipment
should provide the possibility to record all operational
speech and data calls. (O)

8.2.3 It should be possible for calls to be answered automati-
cally according to incoming call priority as defined in
section 10.2. (O)

8,3 Other controllers MMIs


8.3.1 The functionality required by other types of controllers is
essentially the same as for primary controllers, but the
control area will differ and the call set-up subsystem
may be integrated into their own function management
system. (I)

8.3.2 At the detailed level, different controllers may have spe-
cific addressing needs, eg catering controllers will need
to call specific vehicles in a train. (I)

8.4 Controller terminal interface
8.4.1 The communications architecture will be dictated by
local circumstances. The definition of this interface is
beyond the scope of EIRENE. (I)

8,5 Environmental specification
8.5.1 The controller equipment must be designed to function
correctly in a railway operating environment, such as
control centres and signal boxes. (I)

9 Numbering plan
9,1 General
9.1.1 International standardisation of numbering plans is
needed to ensure interworking between networks. Fur-
thermore, standardised allocation of numbers to sub-
scribers will facilitate schemes for identification, barring,
etc. (I)

9.1.2 This section addresses the following: (I)
numbering plan requirements;
standardised telephone numbers;
group numbers;
calls from external networks to the EIRENE network.
9,2 Numbering plan requirements
9.2.1 General
9.2.1.1 The EIRENE system shall enable users to originate and
receive calls by functional number. (M)
2.24 2.26


9.2.1.2 Each mobile shall be identified by a unique telephone
number. (M)
Configuaration aspects are tested implicitely by various test cases, e.g. 1.16
9.2.2 Use of running number
9.2.2.1 The use of running numbers to address trains shall not
result in any ambiguities. (I)

9.2.2.2 Every on-train function shall be identified by a unique
standard number. (M)
2.16 2.17
9.2.3 Use of engine/coach number
9.2.3.1 The use of engine/coach numbers to address trains
shall not result in any ambiguities. (I)

9.2.3.2 Every on-engine/coach function shall be identified by a
unique standard number. (M)
2.16 2.17
9.2.4 Use of shunting team, maintenance team or controller
number

9.2.4.1 Every shunting team number shall be based on an as-
sociation of: (M)
2.24
service area identifier;
shunting team identifier.
9.2.4.2 Every maintenance team number shall be based on an
association of: (M)
2.24
service area identifier;
type of maintenance team (speciality code);
maintenance team identifier.
9.2.4.3 Every controller number shall be based on an associa-
tion of: (M)
2.24
controller location;
controller identifier.
9.2.4.4 The numbering for other teams shall be treated in the
same way as maintenance teams in 9.2.4.2. (M)
Configuaration issue. It's not tested directly by the IOTs, see e.g. 2.24
9.2.5 Use of group calls
9.2.5.1 Group call service areas shall be freely configurable
within the operational responsibility of each railway
network. (M)
Configuaration aspects are tested implicitely by various test cases, see 8


9.2.6 Use of alphanumerical numbers
9.2.6.1 In some countries, train numbers are alphanumeric.
Support for such numbers is not required for interop-
erability. (I)

9.3 Telephone numbers
9.3.1 Telephone numbers can be defined on a national basis,
but codes for certain functions shall be used on an in-
ternational basis in order to allow interoperability. (M)
Tested by various national international calls, e.g. 4.1 and 4.3
9.3.2 For certain functions, standardised telephone numbers
shall be implemented. These functions are: (M)

Route call to most appropriate ERTMS/ETCS RBC; 4
Railway emergency call; 6.1 6.2 6.3 6.5 6.6
Route call to primary controller; 4.1 4.3
Route call to secondary controller; 4.1 4.3
Route call to power supply controller; 4.1 4.3
Public emergency call. 1.49 1.50 1.51 1.45 1.52 1.53 1.48
9,4 Group numbers
9.4.1 To provide interoperability between the fixed railway
networks within the EIRENE network, standardisation of
UIC group numbering will be required. (I)

9.4.2 In network boundary areas, the pre-defined local area
shall be allocated on a bilateral basis. (M)
8.35
9,5 Calls from external networks to the EIRENE network
9.5.1 Authorised users within the EIRENE network shall be
able to receive calls from calling parties outside the
EIRENE network. (M)
3.5 3.6
10 Subscriber management
10,1 Introduction
10,2 Allocation of priorities


10.2.1 10.2.1 A number of levels of priority shall be required in
order to offer different grades of service to different
users and calls. Five levels of priority shall be defined:
(M)
Railway emergency;
control-command (safety);
public emergency and group calls between drivers in
the same area;
railway operation;
railway information.
1.16 1.17 1.38 1.39 7.1-7.68
10.2.2 In order to provide interoperability, priorities shall be
allocated consistently across all EIRENE networks, as
shown in the following table. (M) [Table 10-1: Allocation
of priorities]
1.16 1.17 1.38 1.39 5 7.1 - 7.49
10.2.3 The lowest priority ongoing call shall be pre-empted
before that of a higher priority. (M)
5 7.1 - 7.49
10.2.4 In the case where an EIRENE mobile attempts to
make a Railway emergency call over a public network,
the ability to pre-empt lower priority calls (particularly
public emergency calls) may be inhibited, unless a spe-
cial agreement is in place. (I)

10.3 Call restriction
10.3.1 Various types of call restriction may be employed
by the railways as an additional security measure. Such
facilities may be particularly important if public network
access to the radio system is provided (eg to prevent
members of the public calling drivers and drivers calling
members of the public). (O)

10.3.2Any implementation of such call restrictions shall
not affect international interoperability. (M)

10.4 Group membership 1.45
10.4.1

A mobile may be a member of a number of groups. It
shall be possible to activate or deactivate the mobiles
subscription to these groups. (M)


10.4.2

Activating a group on the mobile shall allow a user to
receive a call from that group. (M)

10.4.3

Deactivating a group on the mobile shall prevent a user
receiving calls from that group. (M)

10.4.4

In order to provide interoperability, Cab radios will be
members of a number of standard groups:

- Railway emergency call; (M)
- all train drivers; (M)
- shunting team; (M)
- trackside worker. (O)
10.4.5 All mobiles with Railway emergency group call sub-
scription(s) shall be prevented from deactivating the
emergency group(s) whilst operational. (M)

10.5 Network selection list Terminal's feature
10.5.1 Authorised networks shall be listed (or automatically
selected if automatic selection has been enabled) in the
following order: (M)
home EIRENE network;
foreign EIRENE networks;
public networks.

10.5.2 Where EIRENE facilities are not available within the
currently selected network, the user shall be given a
visible indication. (M)

10,6 10.6 Access matrix
10.6.1 The access matrix defines which subscribers are able
to contact which other subscribers within the EIRENE
network. (M)
3.1 3.2 3.3 3.4


10.6.2 Yes indicates that the network shall allow a call from
the stated initiating party to the stated receiving party.
Yes* indicates that the call shall be allowed at least for
users on the same train. Open indicates that permis-
sions for calls of this type are to be assigned by the
implementing railway according to their specific com-
munication requirements. Shaded cells on the access
matrix mean that this call is outside the scope of the
EIRENE specifications. The access matrix is shown in
table 10-2. (M)
3.1 3.2 3.3 3.4
10.6.3 If required, a railway may make additional restrictions
to the access matrix.

11 Functional numbering and location dependent address-
ing

11,1 General
11,2 Functional addressing
11.2.1 Principles
11.2.1.1 An addressing scheme shall be provided which permits
users to be identified by numbers corresponding to their
functional roles rather than by numbers tied to the ter-
minal equipment that they are using. (M)
2.1
11.2.1.2 The primary usage of functional addressing will be for
controllers to establish communications with train driv-
ers by making use of the train number. The train
number will vary between journeys although EIRENE
equipment in the cab is unlikely to change. (I)

11.2.1.3 Other uses of functional addressing will include identify-
ing on-train functions and other users performing par-
ticular roles such as shunting team leaders, mainte-
nance team members, etc. (I)

11.2.1.4 It shall be possible to assign up to a minimum of 3 func-
tional numbers to an EIRENE user at any one time. (M)
2.2 2.3
11.2.1.5 Only one EIRENE user shall be assigned to a given
functional number at any one time. (M)
2.16 2.17


11.2.1.6 Deleted.
11.2.1.7 A user shall be able to set up a functional number on
one network, and cancel the number from another net-
work. (M)
2.10 2.18 2.19
11.2.1.8 The functional number shall remain valid as a user
roams from one network to another. (M)
2.10 2.18 2.19
11.2.1.9 The functional addressing scheme shall be independent
of specific configurations of mobile and terminal equip-
ment. For example, the functional number of a conduc-
tor on board a particular train shall be the same irre-
spective of whether the conductor accesses the net-
work through the Cab radio or has a separate dedicated
EIRENE mobile. (M)
Terminal issue
11.2.1.10 It shall be possible to call EIRENE users by functional
numbers from a wide range of terminals (EIRENE and
non-EIRENE). Examples include EIRENE mobiles,
controller terminals, railway fixed network telephones
and public telephones. (All such calls will be subject to
any access restrictions - see section 10.3.) (M)
2.24 2.26 3.5 3.6
11.2.1.11 The functional addressing scheme should permit calls
to be routed from a controller to an international train
within the control area without reference to any EIRENE
system other than that providing service to the interna-
tional train. (O)

11.2.2 Format of functional numbers
11.2.2.1 Functional numbers must be unique within the domain
of operation. Since the number must be independent of
networks, each number must be unique across all net-
works (including implementation of EIRENE facilities on
public networks). (M)
2.16 2.17
11.2.2.2 The functional number shall consist of numeric charac-
ters only. (M)


11.2.2.3 If alphanumeric numbers are applied by a national rail-
way, the railway will be responsible for the translation to
unique numeric functional numbers compatible with the
EIRENE specification. (I)

11.2.3 Presentation of functional identity
11.2.3.1 The functional identity of the called user shall be pre-
sented to the user initiating a call and the functional
identity of the initiator shall be presented to the user
receiving a call. (M)
2.24 2.26
11.2.3.2 For broadcast and group voice communications, the
functional identity provided shall be that of the broad-
cast or group identity. (M)
8.1 9.1
11.2.3.3 If the user initiating the call has more than one func-
tional identity, the user shall be able to select, prior to
call establishment, which functional identity is presented
to the receiving user. (M)
MS-issue
11.2.3.4 In the case of Cab radio, when a train number is as-
signed as a functional identity, this
shall take priority over other Cab radio functional identi-
ties, and shall be the functional identity for the Cab ra-
dio to be displayed to other users. (M)
MS-issue
11.2.3.5 The functional identity shall be presented to the user in
a form which can be readily understood (eg 'driver of
train abcd' rather than 'abcd01' or 'xyz shunting team 3'
rather than 'xyz03'). (M)
MS-issue
11,3 Functional addressing registration procedures principles
11.3.1 Three procedures can be identified for managing the
relationship between the functional number and the
telephone number by the mobile user as defined below.
(I)

11.3.2 Registration
11.3.2.1 The functional addressing scheme shall be supported
by a straightforward procedure for registration of func-
tional numbers. This procedure shall be carried out by
the user on commencement of the functional role. (M)
2.1 2.10


11.3.2.2 The functional number registration facility shall be sup-
ported by all EIRENE user equipment. (M)
Terminal issue
11.3.2.2i It should be possible for the system to prevent certain
types of users from registering
functional numbers that they are not authorised to use,
for example: (O)
train number;
driver of train;
shunting team leader.

11.3.2.3 It shall be possible to register up to ten functional num-
bers to items of equipment physically connected to the
Cab radio within 30 seconds. (M)
2.1 2.1
11.3.2.4 The registration procedure shall provide a means to
prevent mis-allocation of functional numbers during
registration. (M)
2.4 2.11
11.3.2.5 Duplicate functional numbers (eg two trains with the
same train number) shall be prevented. (M)
2.16 2.17
11.3.2.6 The system shall provide a means to recover consistent
data sets following a system failure during which func-
tional addressing facilities are lost. During this recovery
period, the system shall not permit the use of unverified
functional numbers. (M)
2.23
11.3.3 Deregistration
11.3.3.1 The functional addressing scheme shall be supported
by a straightforward procedure for deregistration of
functional numbers. This procedure shall be carried out
by the user at the end of the functional role. (M)
2.4 2.6 2.18 2.19
11.3.3.2 The functional number deregistration facility shall be
supported by all EIRENE user equipment. (M)
Terminal issue
11.3.3.3 It shall be possible to deregister up to ten functional
numbers to items of equipment physically connected to
the Cab radio within 30 seconds. (M)
2.4 2.18


11.3.3.4 In addition, a given set of users shall also be allowed to:
(M)
deregister a functional number which is no longer
valid but which has not been
deregistered by the user;
deregister, by overriding, another user of the same
type (eg a driver can deregister
a train number that another driver has forgotten to de-
register);
deregister, with one action, all functional numbers
associated with the same mobile
(eg the driver deregisters all functions at the end of the
journey).
2.7 2.8 2.20 2.21
11.3.3.5 An EIRENE mobile shall remove the displayed func-
tional number and provide an indication to the user that
deregistration has taken place. (M)
2.4 2.18
11.3.4 Re-registration 2.1
11.3.4.1 To allow roaming between EIRENE networks, the sys-
tem shall support a procedure for the re-registration of
functional numbers after selection of a new network.
(M)
2.15
11.3.4.2 This procedure shall be carried out without manual in-
tervention. (M)
MS-issue
11.3.4.3 After automatic re-registration is performed, the new
registration details shall be displayed to the user. (M)
2.15
11,4 Location dependent addressing
11.4.1 Location dependent addressing shall be provided to
route calls for a given function to a destination number
that is dependent upon the user's location. (M)
4.1 4.2 4.3 4.4
11.4.2 The functions to which calls shall be routed based upon
the location of the mobile shall include: (M)
Primary controller;
Secondary controller;
Power supply controller;
Train management centre (eg RBC, CTS).
4.1 4.2 4.3 4.4


11.4.3 The correspondence between the locations and the
destination of the call shall be easily re-configurable to
support dynamic changes in controller area boundaries
(eg controller area boundaries will change from peak to
off-peak periods during the working day or over longer
periods, areas may change to match changes in railway
organisation or traffic demand). (M)
4.1 4.2 4.3 4.4
11.4.4 When operating with location dependent addressing, no
manual action shall be required to update the system
when a mobile moves between locations. (M)
4.1 4.2 4.3 4.4
11.4.5 The location dependent addressing scheme shall be
available to all mobiles. (M)
4.1 4.2 4.3 4.4
11.4.6 As a minimum, the location information used by the
EIRENE system shall be derived from that available
from the network itself (eg current cell or base station
serving the mobile). (M)
4.1 4.2 4.3 4.4
11.4.7 Where greater accuracy for location dependent ad-
dressing is required, additional
location information may be provided by systems exter-
nal to EIRENE. Sources of such
information may include: (O)
a) ground-based signalling systems;
b) on-train systems (eg ERTMS/ETCS equipment, bal-
ise readers, GPS etc).

12 Text messaging
12,1 Introduction
12.1.1 12.1.1 There is no requirement for an internationally
standardised pre-defined messaging application. How-
ever, it is anticipated that individual national railways
may have a requirement for pre-defined messages, in
which case the application will be specified as part of
individual national procurements.

12.2 Definition of the service
12.2.1 It should be possible to transfer text messages between
ground and mobile(s) through the EIRENE system. (O)


12.2.2 In order to ensure interoperability, the service is op-
tional for the ground and mandatory for the Cab radio.
(M)

12.2.3 If a message is safety related, the safety mechanisms
will be included at the application level and do not con-
cern the EIRENE system. (I)

12.3 Performance
12.3.1 The maximum length of a message segment shall be
96 characters. A message can include several seg-
ments. (M)

12.3.2 The transfer time for each message segment should be
less then 30 seconds for 95% of messages. (O)

12.3.3 The text message facility shall not interfere with the
ability of users to use the radio. (M)

12.4 Interface
12.4.1 A standard data interface between the mobile and the
application module shall be provided. (M)

13 Railway emergency calls
13,1 Introduction
13.1.1 This section covers the use of the EIRENE radio sys-
tem for Railway emergency calls.
This section also describes the facility for confirmation
of such emergency calls and storage of confirmation for
post-incident analysis. (I)

13.1.2 This section describes the handling of high priority voice
calls for railway operational emergencies and does not
cover public emergency calls (ie handling of 112 calls).
(I)

13.1.3 There are two types of Railway emergency call: (I)
Train emergency call;
Shunting emergency call.


13.1.4 The type of call initiated shall be determined automati-
cally, based upon the mode of operation of the radio.
(M)
Terminal feature
13.1.5 If the mobile is in shunting mode, the emergency call
button shall initiate a shunting emergency call, other-
wise the call shall be a Train emergency call. (M)
Terminal feature
Train emergency call
13.1.6 The Train emergency call shall be sent to all drivers and
controller(s) within an area, which is pre-defined to
meet operational requirements. The predefined areas
for emergency calls shall include, where necessary,
parts of one or more network(s). (M)
6.1 6.5 6.3 6.6
13.1.6i The appropriate ERTMS/ETCS RBC should be in-
formed when a Train emergency call is initiated. (O)

Shunting emergency call
13.1.7 The Shunting emergency call shall be sent to all users
involved in shunting operations in the shunting area.
(M)
6.19 6.20 6.28 6.29
13.1.8 The Shunting emergency call shall automatically take
priority over the link assurance signal. (M)
6.19 6.20 6.28 6.29
13,2 Management of Railway emergency calls
13.2.1 Summary
13.2.1.1 A Railway emergency call may be defined in three dis-
tinct phases. These are: (I)
Stage 1: Warning;
Stage 2: Information;
Stage 3: Terminate Railway emergency call.

13.2.2 Stage 1: Warning
13.2.2.1 A Railway emergency call shall be able to be initiated
by using a simple MMI action (eg a single MMI action
for the Cab and Operational radios). (M)
Terminal feature
13.2.2.2 A connection of Railway emergency priority (see sec-
tion 10.2) shall be established to a pre-determined set
of receiving mobiles and controller(s). (M)
6.1 6.5 6.3 6.6


13.2.2.3 If the system is not able to connect the call, the system
shall automatically keep trying to connect the call for 30
seconds. (M)
Terminal's feature
13.2.2.3i During this period the user shall be provided with an
audible and visual indication that the system is trying to
connect the call. (M)
Terminal's feature
13.2.2.3ii After the 30 second period, if the connection was un-
successful, the system shall provide another audible
and visual indication that it was unable to connect the
call. (M)
Terminal's feature
13.2.2.4 An audible indication of 5 seconds (to be confirmed by
trials) shall be provided to originating and receiving
users that the emergency function has been activated.
(M)
Terminal's feature
13.2.2.5 Different indications at the originating and receiving
terminal may be provided. (O)
Terminal's feature
13.2.2.6 A continuous visual indication that the emergency func-
tion has been activated shall be provided at the originat-
ing and all receiving terminals. (M)
Terminal's feature
13.2.2.7 In the event that a train enters the affected area after
the warning stage is complete, the same audible and
visual indications shall be provided. (M)
6.9-6.18
13.2.3 Stage 2: Information
13.2.3.1 A speech connection shall be established immediately
following the warning tone, to allow the originator of the
emergency call, to give information concerning the na-
ture of the emergency. (M)
6.1 6.5 6.2 6.3 6.6
13.2.3.1i Speech should be possible to allow a controller receiv-
ing the warning tone to give information. (O)

13.2.3.2 Additionally, speech should be possible to allow other
mobile users receiving the warning tone to give informa-
tion. (O)

13.2.3.3 The information shall be received by the same set of
users who received the warning tone. (M)
6.1 6.5 6.2 6.3 6.6
13.2.4 Stage 3: Terminate Railway emergency call


13.2.4.1 A Railway emergency call may only be terminated by:
(M)
the originator of the call;
a controller participating in the call;
the network following a (nationally determined) period
of no speech.
6.1 6.5 6.19 6.20 6.19 6.2 6.28 6.29
13.2.4.2 If the radio moves out of the area whilst the emergency
call is in progress, an audible and visual indication of
the loss of the call shall be provided to the user. (M)
Terminal's feature
13.3 Receipt of Railway emergency calls
13.3.1 Authorised EIRENE mobiles shall be able to receive a
Railway emergency call at any time while the mobile is
powered up. (M)
Termi-
nal's
feature
6.26 6.27 8.44 8.45 9.34 9.35
13.3.2 For Railway emergency calls initiated by a mobile, the
controllers display will indicate:
6.8
location; (O)
the functional identity of the originating mobile, which
includes the following:

the train number, if available; (M) 6.8
the engine number, if no train number is available; M) 6.8
the coach number of the leading cab, if neither a train
number nor an engine number is available. (O)

13.4 Confirmation of Railway emergency calls
13.4.1 For post-incident analysis, it is important that the origi-
nation and reception of Railway emergency calls by
mobiles is confirmed by a message sent to a ground-
based central location (and also recorded in the on-train
recording device). (I)

13.4.2 The confirmation shall be generated automatically with-
out input from the user. (M)
Terminal's feature
13.4.3 The confirmation message shall commence at the end
of the call or if the radio moves out of the call area. (M)
Terminal's feature


13.4.4 If the radio loses contact with the network, the mecha-
nism shall commence as soon as possible on regaining
communications, for up to a maximum of 5 minutes
without achieving contact. (M
Terminal's feature
13.4.5 For Railway emergency calls initiated by a mobile, the
automatic confirmation message of the initiating mobile
shall contain: (M)
the time at call establishment;
the time at clear down;
the functional number of the call originator;
the train number and engine number of the call origi
nator, if a train.
6.4 6.7
13.4.6 For Railway emergency calls received by a mobile, the
automatic confirmation message of the receiving mobile
shall contain: (M)
the time at which the call was first received;
the time at which the call was lost (or terminated);
the group identity of the sender;
the functional number of the recipient;
the train number and engine number of the recipient,
if a train.
6.4 6.7
13.4.7 The confirmation message shall be received at the cen-
tral location with a 99% probability of success within 5
minutes of call termination. (M)
Performance test
13.4.8 The performance of the confirmation procedure shall
not be dependent upon the current use of the mobile
and shall not overload the network. (M)
Performance test, terminal's feature
14 Shunting mode Terminal's feature
14,1 Introduction
14.1.1 Shunting mode is the term used to describe the applica-
tion that will regulate and control user access to facili-
ties and features in the mobile while it is being used for
shunting communications. (I)


14.1.2 There is a requirement to regulate the membership of
shunting groups to prevent uncontrolled membership.
(I)

14.1.3 During specific shunting operations where the driver is
not able to see the way ahead and where he is there-
fore relying on information from another shunting mem-
ber, a link assurance signal is needed to provide reas-
surance during silent periods that the radio link is still
established. This signal is also employed to provide
reassurance that this other shunting member is not
incapacitated. (I)

14.2.1 The shunting call shall be a group call and shall have
Railway operation priority (see section 10.2). (M)

14.2.2 Throughout the duration of the shunting group call, it
shall be possible for any member of the shunting group
to speak to all other members of the group, using the
PTT function (as described in sections 5.2.2.53,
6.2.2.12 and 7.2.2.20), except during transmission of
the link assurance signal. (M)

14.2.2i During the transmission of the link assurance signal,
only the originator of the link assurance signal shall be
able to speak to all other members using the PTT func-
tion. (M)

14.2.3 The shunting communication shall be protected from
unintentional and unauthorised access. (M)

14.2.4 It shall be possible for all mobile members of the shunt-
ing group (except the driver) to transmit a link assur-
ance signal. (M)

14.2.5 Within the shunting group, it shall be possible for only
one member of the group to transmit the link assurance
signal at any time. (M)

14.2.6 Operational radios used for shunting shall enable the
link assurance signal to be activated and de-activated
by the shunting group member. (M)


14.2.7 The link assurance signal should be used to reassure
the driver of the integrity of the member at the head of
the shunting movement. (O)

14.2.8 Operational radios used for shunting shall be able to be
switched between the following two operating modes by
a maintenance function: (M)
Mode 1: the member is required to continuously press
the link assurance signal button in order to transmit
the link assurance signal;
Mode 2: the member is required to switch on the link
assurance signal and then periodically press a button
in order to transmit the link assurance signal (failure
to do so shall result in the deactivation of the link as
surance signal after a predefined period has elapsed).

14.2.9 The link assurance signal shall be used to provide an
audible indication to all group members. For the driver,
this indicates that the radio link is operational. (M)

14.2.10 Deleted.
14.2.11 It shall be possible for any member of the shunting
group (including a driver) to transmit a shunting emer-
gency call to all shunting groups in the area. (M)

14.2.12 It shall be possible for all shunting drivers and shunting
group members to receive a shunting emergency call
from any equipment capable of taking part in shunting
communications. The shunting emergency call shall
cause the audible link assurance signal to be inter-
rupted. (M)

14.2.13 It should be possible for the system to record: (O)
shunting group composition at a given instant;
the source and time a shunting emergency call was
transmitted;

the recipients of a shunting emergency call.


14.2.14 If a user, other than the shunting leader, attempts to
make another call whilst being an active member of a
shunting group, the attempt shall be ignored. (M)

14.2.15 If the radio is used by the team leader for a shunting
group call (ie initiated the shunting group call), switching
the radio off shall result in the termination of the
shunting group call. (M)

14,3 Group membership
14.3.1 A shunting group shall be able to consist of the follow-
ing mobile members: (M)
the shunting leader;
the shunting driver, who may remain fixed (ie in a
shunting area) or may change one or more times
during a working period (ie passenger or freight sta
tions);
up to three shunting team members.

14.3.2 In addition to the above shunting group members:
- a controller shall be able to be associated permanently
or temporarily with the shunting group; (M)

- a shunting manager or other person capable of taking
part in a shunting communication should be able to be
temporarily associated with the shunting group. (O)

14.3.3 It shall only be possible for the shunting leader to com-
municate with a person external to the ongoing shunting
communication. This may be initiated by either the
shunting leader or the external user. In the latter case,
in order to avoid disturbing a shunting movement, the
shunting leader should be informed by a visual and
audible indication. The shunting leader can then choose
the moment when he takes or rejects the call. (M)
8.55 8.58
14.3.4 The shunting leader shall then be able to allow the ex-
ternal user to join the shunting communication. (M)


14.3.5 National railways will be responsible for limiting the
availability of equipment that is capable of taking part in
shunting communications to persons that are author-
ised to engage in such communications. (I)

14,4 Link assurance signal
14.4.1 The link assurance signal is a means to provide end-to-
end confirmation between users that a voice communi-
cation link remains intact. This facility is required princi-
pally for the safe conduct of pushing manoeuvres to
assure continuing availability of the radio channel while
a shunting worker is guiding a train driver. (I)

14.4.2 The link assurance signal shall consist of an intermittent
audio tone (between 800 and 850Hz). The tone shall be
of one second duration, followed by an interval of two
seconds. (M)

14.4.3 In order to fulfil the requirements of some railways, it
should be possible to provide an alternative means of
link assurance indication. (O)

14.4.4 This means will consist of an additional safety device
(external to the radio system) interposed between the
Cab radio and the loudspeaker with the purpose of mut-
ing the continuous link assurance signal for the drivers
convenience. In this case, the safety device will alert
the driver only if the link assurance signal has failed or if
it is cancelled. (I)

Operational radios used for shunting shall be able to be
switched between the following two operating modes by
a maintenance function: (M)
Mode A: the link assurance signal shall be inter
rupted, but not cancelled, when the initiator of the link
assurance signal presses the PTT to speak.
Mode B: the link assurance signal shall not be inter
rupted when the initiator of the link assurance signal
presses the PTT to speak.


14.4.5 The link assurance signal shall be deactivated upon
receipt of a shunting emergency call. (M)

14.4.6 All members of the shunting group, other than the initia-
tor of the link assurance signal, shall be unable to
speak during the transmission of the link assurance
signal. However, they shall be able to initiate a shunting
emergency call at any time. (M)

14,5 Constraints
14.5.1 Operating flexibility:
- it shall be possible to modify a shunting groups compo-
sition during a working period. The process for accep-
tance (or rejection) of new members, and for admission
and removal of temporary members, shall be simple.
(M)

14.5.2 Management flexibility:
- in a given area, a radio set shall be capable of opera-
tion in any of the shunting groups in use in that area,
subject to any user access restrictions. (M)

15 Direct mode
15,1 Introduction
15.2.1 Implementation of direct mode is optional. Where the
facility is provided, the following requirements are man-
datory. (O)

15.2.2 Principal requirements are: (M see above)
a range of up to at least 2000m in open terrain be-
tween a direct mode transmitter and receiver;
a voice only capability that supports the use of the link
assurance signal;
open channel mode of operation such that all users
employing direct mode receive transmissions when in
range of the transmitting user;
it is sufficient that the user may talk or listen only, but
not both. The ability to talk shall be achieved through


use of the Push-To-Talk function;
a minimum of one channel is to be available for use of
direct mode facilities;
if more than one channel is provided, there must be a
function allowing the user to manually select the
channel;
where equipment provides both normal and direct
mode capability, the user shall be able to switch be
tween the two modes in a straightforward manner (but
not by accident);
the user may only select direct mode when the nor
mal mobile telephony services are not available;
controls shall be simple to use, eg:
direct mode on/off switch;
Push-To-Talk function;
channel selection;
volume control;
battery life for handportables operating in direct mode
shall be a minimum of 8 hours based on the following
cycle:
20% transmit;
20% receive;
60% stand-by;
when direct mode is used as a fall-back, an audible
and visual indication shall be provided of normal mo
bile telephony services returning.
battery warning for handportables;

Table 6.2: Cross reference of EIRENE FRS V7 mandatory requirements to the IOT test cases


6.1.3 Cross reference of EIRENE SRS V15 mandatory requirements to the IOT test cases

Section Subject Linked test case
1 Introduction
1,1 General
1,2 Scope
1,3 Applicability
1,4 System overview
1.4.1 Extent of specification
1.4.1.1 The system is based on the ETSI GSM standard. To
meet additional functionality and performance require-
ments, this standard is to be supplemented by:

the following GSM services:
voice broadcast service;
voice group call service;
enhanced multi-level precedence and pre-emption;
General Packet Radio Service (GPRS);
railway specific applications:
exchange of number and location information between
train and ground to support

functional and location dependent addressing;
emergency calls;
shunting mode;
multiple driver communications;
direct mode facility for set-to-set operation;
railway specific features, network parameters and stan-
dards:

link assurance signal;
calling and connected line presentation of functional
identities;


cab radio, man-machine and other interfaces;
environmental specifications;
controller position functional specifications;
system configuration (numbering plans, priority levels,
subscriber details, closed user groups, etc).

1.4.1.2 The scope of the specification is shown in figure 1-2,
showing the hierarchy of the GSM, and railway features
to be implemented.

1.4.1.3 A list of ETSI and 3GPP specifications is provided in the
normative references section of this document.

1.4.1.4 Compliance to the list of normative documents is man-
datory for all of the GSM services necessary to provide
the functionality specified in the [EIRENE FRS].

1.4.1.5 Later releases of these specifications may be used,
providing that the system is backwards-compatible with
the versions listed.

1.4.2 Outline architecture
1.4.2.1 The system is based on the GSM architecture which is
summarised in figure 1-3.

1.4.2.2 The system comprises the following elements:
Base station sub-systems (BSSs) of base station con-
trollers (BSCs) controlling base transceiver stations
(BTSs) each containing a number of transceivers
(TRXs).

Network sub-systems (NSSs) interfacing to the BSS via
the GSM 'A' interface. The NSS contains mobile ser-
vices switching centres (MSCs) with primary responsi-
bility for call control. The MSC is supported by a visitor
location register (VLR) containing temporary details of
subscribers active within the MSC area, a group call
register (GCR) containing attributes of voice group and
broadcast call configurations for the related MSC area
and home location registers (HLRs) holding subscriber
details on a permanent basis.


The network also comprises General Packet Radio
Service (GPRS) infrastructure elements supporting the
respective packet radio services. The serving GPRS
support node (SGSN) is a location register function
storing subscription information and location information
for each subscriber registered in that node. It interfaces
to the BSS via the Gb interface and to the MSC/VLR via
the Gs interface and to the HLR via the Gr interface.
The gateway GPRS support node (GGSN) is a location
register function storing subscription information and
routeing information (needed to tunnel packet data traf-
fic destined for a GPRS MS to the SGSN where the MS
is registered) for each subscriber for which the GGSN
has at least one PDP context active. It interfaces to the
SGSN via the Gn interface, to the HLR via the Gx inter-
face, to external packet data networks via the Gi inter-
face and to other GSM/GPRS networks via the Gp in-
terface.

Mobile equipment (ME) interfacing to the BSS via the
air (Um) interface.

Subscriber Identity Modules (SIMs) containing informa-
tion specific to single subscribers. A standardised inter-
face links mobile equipment to SIM cards. A SIM and
ME combined are termed a mobile station (MS).

Operation and Maintenance Centre (OMC) for manag-
ing the network.

Billing Centre.
1.4.2.3 Signalling within the NSS and between NSSs is carried
out according to signalling system number 7, SS7, mak-
ing specific use of the mobile application part (MAP) of
that standard.

1.4.2.4 Railway networks may implement a short message
service centre to be interfaced to the GSM network in
order to support railway specific messaging applica-
tions.


1.4.2.5 A railway GSM network is also likely to have external
interfaces to:

private railway fixed networks;
public operator networks;
controller equipment;
specialised railway systems (eg train control systems).
1.4.2.6 EIRENE will provide the radio bearer for ERTMS/ETCS.
The EURORADIO layers are responsible for ensuring
the overall safety of the transmission link between train-
borne and trackside ERTMS/ETCS applications.

1.4.2.7 In addition to a GSM capability, a direct mode capability
may be provided for railway mobiles for set-to-set op-
eration.

1.4.2.8 Standardised interface protocols are to be provided to
allow applications external to EIRENE to access EI-
RENE bearer services.

Applications may include:
public address;
intercom;
driver safety device;
train borne recorder.
1.4.3 Railway specific services and facilities
1.4.3.1 To meet the specific railway requirements, a number of
additional features are required some of which have
been incorporated in the GSM Standard. The main as-
pects are summarised in the following paragraphs.

1.4.3.2 Frequency: Equipment is to be capable of operation in
the following frequency bands:

Band Frequencies (MHz)
Railway GSM (R-GSM) 876-915/921-960


Note: the R-GSM band includes the Public GSM (P-
GSM) and Extended GSM (E-GSM)
bands.

1.4.3.3 Voice broadcast and group call facilities: All mobiles are
to support these services as defined in the relevant
GSM specifications. The services will mainly be used
to:

broadcast messages from controllers to certain groups
of trains in a controller area;

broadcast messages from trains or shunting team
members to controllers or other mobiles in a defined
area;

conduct group calls between train drivers and control-
lers over pre-defined areas;

conduct group calls between trackside workers, shunt-
ing team members, station staff and similar groups,
typically over local areas.

1.4.3.4 Enhanced multi-level precedence and pre-emption: This
GSM specification is to be implemented in order to
achieve the high performance requirements necessary
for emergency group calls. It is also necessary to meet
different grades of service requirements for different
types of communications traffic on the system (eg
safety (eg train control system), operational and admin-
istrative communications).

1.4.3.5 Functional numbering: Many railway staff need to be
addressed by functional rather than personal numbers.
The functional numbers may change on a regular basis.
The principal example is that of train drivers, who need
to be addressed by train numbers which change with
each journey. To overcome this difficulty a translation
facility will be provided to allow calls to functional num-
bers to be forwarded to the most appropriate personal
number at that time. Thus calls made to a train number
are forwarded by the network to the appropriate driver
or locomotive for that train at that time.


1.4.3.6 A follow-me service will be implemented in the EIRENE
network using the GSM Unstructured Supplementary
Service Data (USSD) facility to allow users to establish
and terminate the forwarding of calls from a functional
number to their personal number.

1.4.3.7 Location dependent addressing: Train drivers need to
be able to contact controllers and other staff at the push
of a single button. As the train moves through different
areas, controllers are liable to change. As a conse-
quence it is necessary to provide a means of address-
ing calls from a train to certain functions based on the
location of the train.

1.4.3.8 The only source of location information available within
the GSM network is the cell that the train is in. How-
ever, there are a number of external sources from
which more accurate location information may be de-
rived:

on-train location systems;
trackside balises;
information from ground based systems.
1.4.3.9 Within EIRENE, the primary means of determining the
location of a train for the purpose of location dependent
addressing will be based on the cell dependent routing.
This may be supplemented with additional information
from external systems to provide a greater degree of
accuracy.

1.4.3.10 Direct mode: Railway mobiles may support a direct
communications mode whereby a mobile can commu-
nicate with all other railway mobiles in a local area with-
out the use of GSM infrastructure. Such a mode is re-
quired for use where:

no GSM infrastructure is provided;
GSM infrastructure equipment has failed.
1,5 Structure of the specification


1.5.1 The specification is divided into the following separate
sections:

1.5.2 Section 2 lists the services and facilities which are to be
supported by GSM-R networks. Section 3 provides
requirements and recommendations concerning the
configuration, planning and implementation of networks.

1.5.3 Sections 4, 5, 6, and 7 are concerned with mobile
equipment. Section 4 provides specifications applicable
to all GSM-R mobiles. Sections 5, 6, and 7 detail the
additional requirements for Cab radio, General purpose
radio, and Operational radio equipment respectively.
Note that for the handheld version of the General pur-
pose radio, commercial standards apply.

1.5.4 Section 8 covers controller equipment. Section 9 is
concerned with a numbering plan for the variety of func-
tional numbers which are required. Section 10 details
the handling of other information, such as priority,
closed user groups and encryption algorithms, which
must be applied consistently in all networks.

1.5.5 Section 11 specifies functional and location dependent
addressing. Section 12 refers to the possible use of pre-
defined text messages (not required for interoperability).

1.5.6 Sections 13 to 15 describe the implementation of emer-
gency calls, shunting mode and direct mode.

1.5.7 References for all sections are included in appendix A.
2 Network requirements
2.1 Introduction
2.1.1 The network services necessary to meet the range of
UIC requirements are detailed
below. These services are to be considered as a mini-
mum set for implementation
within each GSM-R standard network. Railways may
implement additional network
services as desired. (I)


2,2 GSM teleservices
2.2.1 The GSM teleservices [EN 301 515, Index [24]] to be
supported are indicated in table 2-1.

11 Telephony M

12 Emergency calls M

91 Voice Group Call Service (VGCS) M

92 Voice Broadcast Service (VBS) M
1.7

1.48-1.51

8.1-8.50
8.52 8.54
8.17

9.1-9.46
9.48-9.50
8.15
1.8, 1.9,
1.29
1.52-1.53

8.25 8.3
8.20 6.8
1.30,
1.31
various
other
TCs

2.3 GSM bearer services
2.3.1 The GSM bearer services [EN 301 515, Index [23]] to
be supported are listed in table 2-2.
1.38
24. Asynchronous 2.4 kbps NT M
1.16 1.47 10.16 10.22 10.28 10.34 10.40 10.45,
10.55,
10.61,
10.66,
10.71
2.3.2 Note: The Adaptive Multi-Rate (AMR) CODEC is not
suitable for voice group calls or
for voice broadcast calls. (I)

2.4 GSM supplementary services
2.4.1 The GSM supplementary services [EN 301 515, Index
[9]] to be supported are listed in table
2-3. The applicability of these supplementary services
to GSM basic services will be as
indicated in [GSM 02.81-02.89 and EN 301 515, Index
[28]]. (I)


CLIP M
CoLP M
CFU M
CFB M
CW M
HOLD M
MPTY M
CUG M
BOIC-exHC M
BIC-Roam M
USSD M

Sub-addressing M
eMLPP M

UUS1 M
1.12
1.13
1.15
1.18
1.11
1.10
1.14
1.46
1.47
1.47
2.1-2.24
2.26
2.24 2.26
5.1

2.24 2.26
1.34
1.35
1.37
1.40
1.33
1.32
1.36
1.45

10.76 -
10.80

2.5 Railway specific services
2.5.1 The railway specific services to be supported are listed
in table 2-4.

Functional addressing M

Locoation dependent addressing M
Shunting mode M
Multiple driver communications M
Emergency calls M
2.1-2.11,
2.16-
2.22,
2.24,
2.26
4.1-4.4

1.14
6.1-6.18,
6.28-6.29

1.36
various
other
TCs

2.6 Alerting duration


2.6.1 The call waiting service (CW) permits a party A to be
notified of an incoming call from party C whilst the traffic
channel is not available for the incoming call and party
A is engaged in an active call with party B. However call
waiting does not operate during the prior set up of the
call between the parties A and B (including alerting if
used). Therefore the alerting duration has to be as short
as possible in order to minimize the risk for the party A
of missing notification of an incoming call from party C
with a higher eMLPP priority. Taking into account tech-
nical and operational aspects, it is recommended to set
the relevant timer(s) in the network in such a way that
the maximum alerting duration is limited to 60s. (I)

3 Network configuration
3,1 Introduction
3,2 Coverage Not applicable for lab test
3.2.1 For network planning, the coverage level is defined as
the field strength at the antenna on the roof of a train
(nominally a height of 4m above the track). An isotropic
antenna with a gain of 0dBi is assumed. This criterion
will be met with a certain probability in the coverage
area. (The target coverage power level is dependent on
the statistical fluctuations caused by the actual propa-
gation conditions.) (I)

3.2.2 The following minimum values shall apply: (M)
- coverage probability of 95% based on a coverage
level of 38.5 dBV/m (-98 dBm) for voice and non-
safety critical data;
coverage probability of 95% based on a coverage
level of 41.5 dBV/m (-95 dBm) on lines with ETCS
levels 2/3 for speeds lower than or equal to 220km/h.


3.2.3 The following minimum values are recommended: (I)
level of 44.5 dBV/m (-92 dBm) on lines with ETCS
levels 2/3 for speeds above 280km/h;
level between 41.5 dBV/m and 44.5 dBV/m (-95 dBm
and 92 dBm) on lines with ETCS levels 2/3 for speeds
above 220km/h and lower than or equal to 280km/h.

3.2.4 The EIRENE mobile installation shall be designed to
operate in a network meeting the criteria in 3.2.2 and
3.2.3. (M)

3,3 Handover and cell selection
3.3.1 The handover success rate should be at least 99.5%
over train routes under design load conditions (as given
in [EN 301 515, Index [30]]). (O)

3.3.2 To avoid the necessity for large cell overlaps to ac-
commodate high speed train operations, optimisation of
the handover process for such trains is considered nec-
essary. Suitable algorithms will be tested and refined as
necessary during the trials process. (I)

3.3.2 To avoid the necessity for large cell overlaps to ac-
commodate high speed train
operations, optimisation of the handover process for
such trains is considered
necessary. Suitable algorithms will be tested and re-
fined as necessary during the trials
process. (I)

3.3.3 The proposed events for measurement of the start and
stop of the handover execution at the mobile are: (I)
receipt of handover command;
receipt of UA after physical info on new channel.


3.3.4 There is a quality of service requirement for handover
executions (eg a break of 10s would clearly be unac-
ceptable to the user). 300ms represents our current
best estimate of the QoS figure, although this will need
to be confirmed through user trials. (I)

3.3.5 An additional option is available to reduce the handover
break period, namely the use of the synchronous hand-
over capability to reduce the break period to about
150ms. Synchronous handover requires the BTS
transmissions in different cells to be synchronised by
the system. Each authority can decide whether it
wishes to use synchronised BTSs. (I)

3,4 Call setup time requirement Not applicable for lab test
3.4.1 Call setup time requirement is dependent upon the
eMLPP priority of a call [EN 301 515, Index [27]]. The
required priority level for each call type is given in sec-
tion 10.2. (I)

3.4.2 Call setup times as defined in the EIRENE FRS shall be
achieved with authentication and ciphering procedures
enabled. (M)

3.4.3 In order to achieve these times the passage of the call
through any networks external to GSM (eg from the
GSM MSC to a controller linked by an ISDN connec-
tion) must take less than 250ms. (I)

3.4.4 Achievement of fast call setup times requires informa-
tion in the setup message to be compressed. A maxi-
mum of 12 digits may be sent as mobile originator-to-
dispatcher information. (I)
3,5 Frequency band and channel arrangements No functionality related
3.5.1 The network shall operate in a sub-band, or combina-
tion of sub-bands, of the R-GSM band as defined in [EN
301 515, Index [35]]. (M)


3.5.2 The UIC frequency band for GSM-R is defined in [CEPT
25-09]: (I)
876 880 MHz (mobile station transmit); paired with
921 925 MHz (base station transmit).

3.5.3 The carrier frequency is designated by the absolute
radio frequency channel number (ARFCN), and is de-
fined in [EN 301 515, Index [35]]. For carriers in the UIC
frequency band the following convention shall be used,
where Fl(n) is the frequency value of the carrier ARFCN
n in the lower band, and Fu(n) the corresponding fre-
quency value in the upper band: (M)
Fl(n) = 890 + 0.2*(n-1024) 955 n 973
Fu(n) = Fl(n) + 45
Frequencies are in MHz.

3,6 DTMF tones and signals
3.6.1 The minimum duration of a DTMF tone and the length
of pause between tones generated by the network
(DTMF sender) and needed for the DTMF digit recogni-
tion in the network (DTMF receiver) are specified in [3G
TS 23.014, Support of Dual Tone MultiFrequency
(DTMF) signalling]. (I)

3,7 Termination of VGCS/VBS calls
3.7.1 An entitled controller may terminate a VGCS/VBS call
based on DTMF signalling [EN 301 515, Index [4] & [5]].
(I)

3.7.2 The network shall terminate the ongoing VGCS/VBS
call if it receives the 3-digit sequence *** transmitted
via DTMF signals. (M)
8.3 8.10 8.12
3.7.3 In order to minimise the discomfort caused by the
DTMF tone added in the voice channel, the duration of
the tone generated by the fixed line dispatcher shall be
70ms 5ms, and there shall be a minimum gap of 65ms
between each tone. (M)
Terminal's feature
3,8 Muting and unmuting for VGCS calls


3.8.1 The muting and unmuting for VGCS shall be in line with
[EN 301 515, Index [4]]. (M)
8.10 8.10
3.8.2 The network shall send the SET-PARAMETER mes-
sage with the attribute D-ATT = T1 [EN 301 515, In-
dex [6]] to the mobile station of the talking subscriber if
it receives the 3- digit sequence ### transmitted via
DTMF or the group call SETUP message2 from a con-
troller terminal. However, receiving the 3-digit sequence
### or the group call SETUP message related to an
additional controller while any other controller is talking
shall not result in sending another SET-PARAMETER
message with the attribute DATT = T. (M)
8.10 8.10
3.8.3 When the network has detected the 3-digit DTMF se-
quence ### transmitted via DTMF from a controller
terminal and if the controller was not previously talking it
should indicate its recognition by playing a single DTMF
grant tone # of duration of 100ms 5ms to be sent to
that controller terminal only. (O)

3.8.4 The network shall send the SET-PARAMETER mes-
sage with the attribute D-ATT = F3 [EN 301 515, In-
dex [6]] to the mobile of the talking subscriber only if it
has received the 3-digit sequence #** transmitted via
DTMF from all the talking controllers4.(M)
8.10 8.10
3.8.5 The duration of each tone (see 3.8.2 and 3.8.4) added
in the voice channel, shall be 70ms 5ms, and there
shall be a minimum gap of 65ms between each tone.
(M)
8.10 8.10
4 Mobile equipment core specification Outside the IOTs
4,1 Introduction
4.1.1 To ensure interoperability, all EIRENE mobiles are
specified with a common level of basic services, facili-
ties and features. This section of the specification gives
details of these core requirements, while sections 5-7
detail requirements specific to each of the radio types.


4.1.2 The logical architecture of an EIRENE mobile station
(EIRENE MS) is shown in figure 4-1. The architecture
consists of the following elements:

a) GSM Mobile Termination (GSM-MT): comprising
GSM mobile equipment and SIM;

b) Direct Mode Mobile Termination (DM-MT): for direct
mode communications;

c) EIRENE applications: standardised features outside
GSM: dependent on radio type;

d) Man Machine Interface (MMI): dependent on radio
type.

4.1.3 The logical architecture comprises a number of inter-
faces between the different EIRENE-MS elements.
These are:

1) GSM-MT air interface: mandatory for interoperability
and conformant to GSM specifications;

2) DM-MT air interface: Direct Mode is optional. How-
ever, where implemented, the requirements concerning
this interface are mandatory for interoperability;

3) GSM-MT - EIRENE Applications interface: specified
to allow an option for separate procurement of GSM-MT
and EIRENE Application equipment for the Cab radio
(see [MORANE FFFIS MTI]);

4) DM-MT - EIRENE Applications interface: specified to
allow an option for separate procurement of DM-MT
and EIRENE Application equipment for the Cab radio;

5) EIRENE Applications - MMI interface: not specified.
4.1.4 This specification defines three distinct mobile radio
types according to the type of role they will perform and
the environment they will operate in, as follows:

a) Cab radio - for use by the driver of a train and by
ERTMS/ETCS;

b) General purpose radio - for general use by railway
personnel;


c) Operational radio - for use by railway personnel in-
volved in train operations such as shunting and track-
side maintenance.

Note: It is possible that the General purpose and Op-
erational radios may have a number of physical imple-
mentations to meet railway requirements (eg handheld
and vehicle mounted).

4.1.5 All SIM cards used in EIRENE mobiles shall comply
with the requirements of the MORANE FFFIS for GSM-
R SIM Cards [MORANE SIM].

4,2 Radio interface aspects
4.2.1 All mobiles shall be capable of operation in the following
frequency bands:
Railway GSM (R-GSM) 876-915/921-960 MHz

Band Frequencies (MHz)
Railway GSM (R-GSM) 876-915/921-960
Note: the R-GSM band includes the Public GSM (P-
GSM) and Extended GSM (E-GSM) bands.

4.2.2 The mobile radio antenna installation on vehicles shall
be designed so as to ensure that mobiles operate cor-
rectly in networks which conform to the design criteria
defined in section 3.

4.2.3 Mobile radios shall be of the following power classes:
Radio type Power class
Power (W)

Cab radio 2
8

General purpose radio 4*
2*

Operational radio 4*
2*

Vehicle-based versions of the General purpose and
Operational radios may be used to provide 8W mobile
radios.


4,3 Services and facilities
4.3.1 The following GSM teleservices, identified in section 2,
are to be supported for each type of mobile radio:

11 Telephony
12 Emergency calls
21 Short message MT/PP
22 Short message MO/PP
23 Short message cell broadcast
61 Alternate speech and fax group 3
62 Automatic fax group 3
91 Voice Group Call Service (VGCS)
92 Voice Broadcast Service (VBS)
4.3.2 The following bearer services, identified in section 2,
are to be supported for each type of mobile radio

20. Asynchronous General Bearer Service
21. Asynchronous 300 bps T
21. Asynchronous 300 bps NT
22. Asynchronous 1.2 kbps T
22. Asynchronous 1.2 kbps NT
23. Asynchronous 1200/75 bps T
23. Asynchronous 1200/75 bps NT
30. Synchronous General Bearer Service
31. Synchronous 1.2 kbps T


31. Synchronous 1.2 kbps NT
40. General PAD Access Bearer Service
41. PAD access 300 bps T
41. PAD access 300 bps NT
42. PAD access 1.2 kbps T
42. PAD access 1.2 kbps NT
43. PAD access 1200/75 bps T
43. PAD access 1200/75 bps NT
61. Alternate speech/data
70. GPRS
81. Speech followed by data
4.3.3 The following supplementary services, identified in sec-
tion 2, are to be supported for each type of mobile ra-
dio.

Calling Line Identification Presentation (CLIP)
Calling Line Identification Restriction (CLIR)
Connected Line Identification Presentation(CoLP)


Connected Line Identification Restriction (CoLR)
Call Forwarding Unconditional (CFU)
Call Forwarding on Mobile Subscriber Busy(CFB)
Call Forwarding on No Reply (CFNRy)
Call forwarding on Mobile Subscriber Not Reachable
(CFNRc)

Call waiting (CW)
Call hold (HOLD)
Multi Party Service (MPTY)
Closed User Group (CUG)
Advice of Charge (Information) (AoCI)
Advice of Charge (Charging) (AoCC)
Barring of All Outgoing Calls (BAOC)
Barring of Outgoing International Calls (BOIC)
BOIC except those to Home PLMN Country (BOIC-
exHC)

Barring of All Incoming Calls (BAIC)
Barring of Incoming Calls when Roaming Outside the
Home PLMN Country (BIC-Roam)

Unstructured Supplementary Service Data (USSD)
Sub-addressing*
Enhanced Multi-Level Precedence and Pre-emption
(eMLPP)

Explicit Call Transfer (ECT)
Completion of Calls to Busy Subscribers (CCBS)
User-to-User Signalling 1 (UUS1)
4.3.4 The following EIRENE features are to be supported for
each type of mobile radio



Multiple driver communications(section 5)
4.3.5 If a Railway emergency call set up from an EIRENE
radio is unsuccessful, the radio shall automatically re-
attempt the call setup until the call setup is successful,
a retry timer expires (duration 30 seconds, as specified
in the [EIRENE FRS]) or the user abandons the call.

Note: For this, the higher layers of an EIRENE radio
shall automatically repeat setup requests to the layer 3
GCC or BCC entity as soon as an indication is given
from the layer 3 GCC or BCC entity on an abort of the
establishment procedure without the service being ex-
plicitly rejected by the network. No change of the re-
lated layer 3 procedures of GSM is intended.

4,4 Core MMI requirements
4.4.1 A service availability indication shall be provided to
radio users, as defined in [EN 301 515, Index [26]].

4.4.2 The user shall be prevented from entering direct mode
if the GSM service is available.

4.4.3 If the attempt to establish a Railway emergency call is
not successful after 2 seconds, an indication shall be
provided to the user of the status of the establishment
request procedure.

4,5 Core environmental requirements
4.5.1 This subsection defines the core environmental and
physical requirements for all EIRENE mobile equip-
ment. The requirements provided in this section are
augmented by those provided in later sections for each
individual radio type, with each radio type being speci-
fied by the superset of the core plus specific require-
ments.


4.5.2 All EIRENE mobile equipment shall comply with all en-
vironmental, EMC and physical specifications defined in
the GSM standard, especially with reference to [GSM
05.90 and EN 301 515, Index [2] & [35]].

4.5.3 All EIRENE mobile equipment shall conform to [EN
60950] (Safety of Information Technology Equipment),
including Electrical Business Equipment, 1993, plus
amendments A1 and A2.

4.5.4 The categories of requirements defined in each section
describing mobile equipment are as follows:
climatic conditions (temperature, humidity, solar radia-
tion, altitude, etc);
physical conditions (flammability, contamination, physi-
cal protection, etc);
mechanical conditions (shock and vibration);
electrical conditions (power supply variation, battery life,
overloading, etc);
EMC (both emissions and immunity);
tests required to validate compliance with EIRENE
specification.

4.5.5 Any environmental and physical requirements stated
may be superseded by national requirements provided
the national standards provide a higher level of envi-
ronmental and physical protection. Stricter national
standards shall not prevent the use of other EIRENE
mobiles in that country.

4.5.6 Many of the railway specific standards referenced are
Pre-standards (eg [prEN 50155, ENV 50121, prEN
50125]) and should be re-examined for their applicabil-
ity to the EIRENE system if any modifications are made
to these standards in the future.

4.5.7 All design, manufacturing, testing and installation of
EIRENE mobile radio equipment shall comply with the
quality procedures defined in [ISO 9001].


4.5.8 EIRENE mobile equipment shall be capable of operat-
ing over a standard range of temperatures from -20 to
+55

4.5.9 EIRENE mobile equipment shall be capable of being
stored (ie without being operational) at temperatures
down to -40 without any permanent damage.

4.5.10 The equipment shall be capable of coping with tem-
perature variations of up to +/-1/minute

4.5.11 EIRENE mobile equipment shall be capable of operat-
ing between altitudes of -100m and 1800m, referenced
to sea level.

4.5.12 The equipment shall be able to cope with relative hu-
midities of 100% for short periods, although the yearly
average is expected to be 75%. The equipment shall
also cope with 95% humidity for 30 days in the year.

4.5.13 Operationally caused infrequent and slight moisture
condensation shall not lead to any malfunction or fail-
ure.

4.5.14 All equipment shall not degrade photochemically when
exposed to solar radiation of up to 1200 W/.

4.5.15 In normal operation of a mobile radio unit, it shall be
expected that a combination of the above environ-
mental conditions will be experienced.

4.5.16 All EIRENE mobile equipment shall be protected
against shock and vibration in compliance with stan-
dards defined in [prEN 50125] using tests defined in
[prEN 50155].

4.5.17 All handheld mobile equipment shall be capable of
withstanding the following shocks:
non-repetitive shocks of up to 3g for up to 100ms under
normal conditions;
free fall from 0.5m.

4.5.18 EIRENE mobile equipment shall be capable of being
subjected to both sinusoidal and random vibration.


4.5.19 Handheld mobile equipment shall be capable of with-
standing the following levels of continuous sinusoidal
vibration:
frequency range: 5-200 Hz;
peak-to-peak amplitude: 7.5 mm;
peak acceleration: 1.5g.

4.5.20 The random vibrations to be withstood by mobile
equipment shall be 0.25g in all three axes of freedom.

4.5.21 For determining battery requirements, the trans-
mit/receive duty cycles used shall be as shown in table
4-7 for each call type.

4.5.22 Battery requirements shall be provided without the use
of discontinuous reception or transmission (DTX/DRX).

4.5.23 Battery requirements shall be met based on full power
during transmission and assuming hourly periodic loca-
tion updating.

4.5.24 All railway and generic EMC standards define a maxi-
mum level of radiated EMC for a range of frequencies.
However, the nature of radio equipment implies a cer-
tain level of EM emission in the transmission band.

4.5.25 Guidelines concerning the effects of GSM emissions on
hearing aids, pace makers and other sensitive electrical
equipment are provided in [GSM 05.90].

4.5.26 All EIRENE mobile equipment shall be immune to ex-
ternal EMC as defined in [ENV 50121 part 4].

NOTE: EIRENE mobile equipment cannot comply with
the emission requirements defined in this standard ex-
cept outside the GSM transmission band.

4.5.27 The transmission of EM radiation from all EIRENE mo-
bile equipment shall comply with the radio frequency
transmission masks defined in [EN 301 515, Index [35]]
for the range of GSM frequencies defined in section 1 of
this document.


4.5.28 Where the emission levels defined by [EN 301 515,
Index [35]] exceed those stated in [ENV 50121 part 4],
the GSM specification shall take precedence.

4.5.29 Mobile equipment shall comply with the generic stan-
dard for EMC in the industrial environment as defined in
[ENV 50081 part 2], except for emissions at GSM fre-
quencies as noted above.

4.5.30 The emission and immunity standards for the general
railway environment and ancillary services as defined in
[ENV 50121 parts 1, 2, 3-1, 3-2 and 5] shall be consid-
ered.

4.5.31 EIRENE mobiles will generate EM emissions in the
GSM frequency band. It is the responsibility of national
railways operating EIRENE networks to ensure that
EIRENE equipment does not interfere with the normal
operation of any on-train or ground based systems.

4.5.32 In particular, EIRENE equipment could interfere with:
signalling relays and contacts;
speedometers;
public address;
power transformers;
track circuits;
axle counters;
train describers;
other radio equipment;
radar speed measurement equipment;
switched mode power supplies;
telecommunications circuits;
electronic locking systems.

4.5.33 The environmental and physical tolerance of the EI-
RENE mobile radio units shall be tested at a facility in
accordance with [EN 45001].

4.5.34 All EMC emission and immunity tests shall be per-
formed in accordance with guidelines defined in the [EN
61000-4] series and in [EN 50140].


4.5.35 Environmental testing procedures shall follow guide-
lines defined in [IEC 68 part 1].

4.5.36 Specific environmental test procedures to be followed
for EIRENE mobile equipment shall include the follow-
ing tests as defined in the [IEC 68] series:
A Cold;
B Dry heat;
D Damp heat (cyclic);
E Impact;
F Vibration;
G Acceleration;
K Corrosive atmospheres;
M Air pressure;
N Change of temperature;
P Fire hazard.

5 Cab radio Outside the IOTs
5,1 Introduction
5.1.1 This section identifies the system requirements for the
EIRENE Cab radio. It defines how the functionality is to
be provided by the Cab radio system and the man-
machine interface.

5,2 System components
5.2.1 Figure 5-1 shows the logical architecture of an EIRENE
Cab radio. The architecture comprises the following
elements:
GSM Mobile Termination (GSM-MT): comprising GSM
mobile equipment and SIM; Direct Mode Mobile Ter-
mination (DM-MT): for direct mode communications;
EIRENE Cab radio applications: standardised features
outside GSM;
Man Machine Interface (MMI).

5.2.2 The architecture comprises a number of interfaces be-
tween the different EIRENE-MS elements. These are:

1) GSM-MT air interface: mandatory for interoperability
and conformant to GSM specifications.


2) DM-MT air interface: Direct Mode is optional. How-
ever, where implemented, the requirements concerning
this interface are mandatory for interoperability.

3) GSM-MT - EIRENE Applications interface: specified
to allow the option for separate procurement of GSM-
MT and EIRENE Application equipment for the Cab
radio. The Morane FFFIS [MORANE FFFIS MTI] speci-
fies two types of interface based on V.24 and TDMA,
both supporting [EN 301 515, Index [19]].

[Note: this interface is not required where a Cab radio
is implemented as an integrated unit.]

4) DM-MT - EIRENE Applications interface: specified to
allow the option for separate procurement of DM-MT
and EIRENE Application equipment for Cab radio.

5) Interfaces may be provided to a Train Interface Unit
and an ERTMS data interface. More requirements are
given on these interfaces, where implemented, in sub-
sections 5.10 and 5.15.

5,3 Driver call-related functions
5.3.1 Upon an appropriate MMI action, the radio shall initiate
a call to the appropriate controller with 'Railway opera-
tion' priority (see section 10.2)

5.3.2 The calling driver's functional number shall be passed
to the network using UUS1.

5.3.3 On receipt of a 'Call other drivers in area' request, the
radio shall initiate a group call using the 'all trains' group
identification (see section 9) with eMLPP priority level 2
(see section 10.2).


5.3.5 Activation of the 'Railway emergency call' function shall
cuse the radio to initiate a Railway emergency call as
defined in section 13.



5.3.7 Many trains employ multiple active traction vehicles.
wiring, it shall be possible for a permanent radio con-
nection to be established between each of the active
cabs.

5.3.8 Where there is more than one active cab, the radio
connection shall be provided using the GSM Multi-Party
service.

5,1 Introduction
5.1.1 This section identifies the system requirements for the
EIRENE Cab radio. It defines
how the functionality is to be provided by the Cab radio
system and the man-machine
interface. (I)

5,3 Driver call-related functions
call controller
5.3.1 Upon an appropriate MMI action, the radio shall initiate
a call to the appropriate
controller with Railway operation priority (see section
10.2). (M)

5.3.2 The calling drivers functional number shall be passed
to the network using UUS1. (M)

Call other drivers in the area
5.3.3 On receipt of a Call other drivers in area request, the
radio shall initiate a group call
using the all trains group identification (see section 9)
with eMLPP priority level 2
(see section 10.2). (M)




5.3.5 Activation of the Railway emergency call function shall
cause the radio to initiate a
Railway emergency call as defined in section 13. (M)


Communicate with other drivers on same train
5.3.7 Many trains employ multiple active traction vehicles.
wiring, it shall be possible for a permanent radio con-
nection to be established between each of the active
cabs. (I)

5.3.8 Where there is more than one active cab, the radio
connection shall be provided using
the GSM Multi-Party service. (M)

5.3.9 The call will be established from the active cab of the
lead traction vehicle. Each of the other cabs on the train
will be contacted using its functional number (registered
by the other drivers prior to the establishment of the
call). The procedure for setting up a multi-party call is
outlined in figure 5-2. The multi-party call shall have
'Railwayoperation' priority (see section 10.2) and wilst
on-going a 'multi-drivers' indicationshall be displayed
permanently at all Cab radios.

5.3.10 Upon activation of the function 'Call tain staff', the radio
shall determine the appropriate functional number
based on the staff member selected and the train num-
ber (see section 9). A GSM point-to-point voice call at
'Railway operation' priority(see section 10.2) shall then
be initiated.

5.3.11 The Cab radio shall be capable of being used as a
standard GSM telephone, such that the driver is able to
call any valid number subject to closed user group, call
barring or other restrictions.


5.3.12 The Cab radio shall be able to receive, display and
store incoming short (SMS) text messages (see section
12).

5.3.13 The Cab radio shall support shunting mode communi-
cations as defined in section 14.

5.3.14 The Cab radio should support direct mode communica-
tions as defined in section 15.

5,4 MMI functions
5.4.1 When switched on, the radio shall initiate automatic
self-testing using the GSM IMSI attach procedure (in-
cluding the automatic selection of the default loud-
speaker volume - see table 5-1)

5.4.2 Upon switch on, the Cab radio shall be registered with a
mobile network (see section 10.5).

5.4.3 If registration is not successful an audible and visual

5.4.4 Upon registration, the mobile shall be accessible by
calling the MSISDN or the Engine or Coach number
with which it is associated. This shall require the home
network database to maintain this correlation.

5.4.5 The following table provides details of the three volume
adjustment ranges to be provided.

Table 5-1: Volume adjustment levels
5.4.6 The numbers 1 to 5 give the five levels of adjustment
possible for each volume range setting. The default
setting is the pre-defined level automatically selected
when the MMI is switched on.

5.4.7 Upon activation of the registration function, a USSD
message (see section 11) shall be sent by the Cab
radio.

5.4.8 Upon activation of the deregistration function, a USSD
message (see section 11) shall be sent by the Cab
radio.


5.4.9 Upon detection (automatically or based on a list stored
in the Cab radio) of the additional on-train functions for
equipment physically connected to the Cab radio, a
USSD message (see section 11) shall be sent by the
Cab radio after activation of the registration or deregis-
tration function.

5.4.10 This procedure shall take place at the installation of the
Cab radio. It shall be initiated by an external device or
by a member of a maintenance team.

5.4.11 On-train functions for equipment physically connected
to the Cab radio shall be registered or deregistered
automatically based on a USSD message (see section
11) sent by the Cab radio.

5,5 Handling of calls
5.5.1 The sequence of actions required for a mobile origi-
nated call to another user shall be as follows:
Initiating a call: System is provided with the necessary
information to set up call (eg number, bearer type, prior-
ity);
Indication: Provide an audible and visual indication;
Call arbitration: Management of call requests on the
basis of call priority;
Conversation: Where the parties involved in the call can
communicate;
Call termination: Where one of the parties involved in
the call terminates the call.


5.5.2 The sequence of actions for a mobile terminated call to
a driver shall be as follows:
Call arbitration: Management of call requests on the
basis of call priority;
Indication: Provide an audible and visual indication of
incoming call;
Answering the call: Acceptance of incoming call by user
(not required for auto answer);
Indication: Provide an audible and visual indication;
Conversation: Where the parties involved in the call can
communicate;
Call termination: Where one of the parties involved in
the call terminates the call.

5.5.3 The Cab radio system shall provide a means for the
driver to terminate established calls which he is author-
ised to terminate.

5.5.4 It shall be possible to initiate outgoing voice calls in one
of four ways depending on the intended recipient(s) of
the call:
Emergency access: Capable of rapid activation in an
emergency with a minimum of action being required by
the driver (ie single red button);
Priority access: Requiring the minimum of driver actions
to initiate a call (eg a single key stroke);
Stored number: Through the selection of a stored num-
ber or name (eg menu type access);
Dial access: Facility for the driver to enter or select
telephone or functional numbers manually.

5.5.5 Emergency access shall be provided to initiate the fol-
lowing call:

Table 5-2: Call types requiring MMI emergency access
5.5.6 Priority access shall be provided to initiate the following:
Table 5-3: Call types requiring MMI priority access


5.5.7 On activation of the "call other drivers on the same
train" function, the MMI shall provide additional guid-
ance to the user in the establishment and management
of a Multi-Party call.

5.5.8 (*) When there are several controllers of the same type
associated with a cell, and no external means of select-
ing the appropriate one, the choice may be given by the
system to the driver, or a VGCS call may be established
to all of the relevant controllers after initiating the 'Call
controller' function.

5.5.9 The driver shall be able to initiate a call by selecting a
name/number from stored number information in the
radio.

5.5.10 Facilities shall be provided to support a list of stored
names/numbers of up to a minimum of 100 entries.

5.5.11 Stored number access shall be provided to initiate the
following calls:

Table 5-4: Call types requiring MMI stored number ac-
cess

5.5.12 Unless otherwise indicated at time of entry, calls from
the stored numbers list shall be initiated as voice calls.

5.5.13 By default, calls will have a priority of railway informa-
tion calls (eMLPP priority designation 4). It shall be
possible to store a priority in association with a stored
number.

5.5.14 The driver shall be able to initiate a call by dialling any
valid telephone number or functional number.

5.5.15 Dial access shall be provided to initiate the following
calls:

Table 5-5: Call types requiring MMI dial access
5.5.16 Abbreviated dialling facilities shall be supported.
5.5.17 Dialled calls from the MMI shall be point-to-point voice
calls unless otherwise entered from the MMI at the time
of initiation.


5.5.18 By default, dialled calls shall have a priority of railway
information calls (eMLPP priority designation 4).

5.5.19 It shall be possible to receive and manage the following
incoming calls:
emergency calls;
group calls;
broadcast calls;
point-to-point calls;
multi-party calls
8.41-8.46 8.47-8.48 8.38-8.45 9.28-9.35 6.20-6.27
5.5.20 The Cab radio shall arbitrate between calls when:
an incoming call is received whilst the Cab radio is in
an on-going call;
8.41-8.46 8.47-8.48 8.38-8.45 9.28-9.35 6.20-6.27
a Cab radio user attempts to initiate a call whilst the
Cab radio is in an on-going call.

5.5.21 The Cab radio shall apply the arbitration rules outlined
in Table 5A-1 in Appendix 5A.
8.41-8.46 8.47-8.48 8.38-8.45 9.28-9.35 6.20-6.27
5.5.22 Once a call has been established the connected parties
shall be able to communicate.

5.5.23 Replacing the handset shall result in the outcomes
listed in Tables 5A-2 and 5A-3.

5.5.24 Calls shall be able to be terminated by either party sub-
ject to the requirements shown in tables 5A-2 and 5A-3.

5.5.25 Table 5A-2 in Appendix 5A shows the effect of replac-
ing the handset or initiating the 'Call clear' procedure for
the different types of outgoing calls

5.5.26 Table 5A-3 in Appendix 5A shows the effect of putting
down the handset or initiating the 'Call clear' procedure
for the fferent types of incoming calls.

5,6 Other Cab radio functions
5.6.1 Incoming calls to the Cab radio shall be routed to the
correct on-train user or device using information con-
tained in the sub-addressing field.


5.6.1i Using the GSM "Manual" network selection procedure,
the Cab radio application shall allow the driver to ac-
cess a prioritised list of authorised networks (to be dis-
played as stated in section 10.5) and shall allow the
driver to select a desired network from this list. This
function shall not be available if there is an ongoing
voice call involving the Cab radio.

5.6.2 As a train approaches the limits of the coverage of the
PLMN it is registered with, it will be necessary for it to
register with the next PLMN providing coverage.

5.6.3 A means of directed network selection should be pro-
vided to ensure that the MS registers with the required
network.

5.6.4 If directed network selection is implemented, the di-
rected network selection procedure shall be initiated by
an external trigger mechanism, which instructs the Cab
radio application to select the required network unless a
voice call is ongoing.

5.6.4i If directed network selection is implemented and voice
calls are ongoing at the time when the external device
attempts to trigger a network change, an audible and
visual indication shall be given to the driver and network
change shall be deferred until the call is terminated or
until coverage of the current network is lost.

5.6.5 If directed network selection is implemented, the Cab
radio application shall use the GSM 'Manual' network
selection procure (through the AT interface [EN 301
515, Index[19]]) to instruct the MT to register with the
required network.

5.6.5i The Cab radio should be capable of selecting the most
appropriate mobile radio network automatically using
the selection criteria stated in section 10.5.

5.6.5ii If automatic network selection is implemented, the
driver shall be capable of deactivating and/or re-
activating this function using simple MMI actions.


5.6.5iii Whilst automatic network selection is enabled, the MMI
shall display an indication.

5.6.6 In idle mode, if the GSM Service Indicator (see [EN 301
515, Index [26]]) is lost, the mobile shall give an audible
and visual indication.

5,7 Environmental and physical
5.7.1 Train-mounted equipment including the Cab radio ter-
minal equipment, MMI and antenna shall comply with all
specifications in section 4 and all of those defined in
this section, with those defined in this section taking
priority.

5.7.2 Two types of mobile radio equipment will be mounted
in rolling stock: in-cab equipment and external equip-
ment. Each type of equipment has slightly different re-
quirements placed upon it in terms of EMC and climate.
([UIC 651] is a useful reference concerning the layout of
cab equipment.)

5.7.3 The Cab radio shall be capable of operating within a
temperature range of -20!aC to +70!aC.

5.7.4 The aerial and any other equipment mounted external
to the train shall be capable of withstanding extremes of
temperature from -40 to +70

5.7.5 The aerial and any other equipment mounted external
to the train shall function correctly during rapid tempera-
ture fluctuations of up to 3/second

5.7.6 Any equipment mounted external to the train cab shall
withstand the following additional physical conditions:
in-tunnel pressure pulses of 6 kPa (peak to peak) for up
to 3 seconds;
pressure gradients of up to 100 kPa/s.

5.7.7 Measures should be taken to reduce the risk of theft of
radio equipment. Examples of such measures include
physical protection, alarms and access control meas-
ures.


5.7.8 Ease of maintenance should be taken into account in
the design and installation of radio equipment. For ex-
ample, maintenance access to antennas on vehicles
should be provided.

5.7.9 The 'Subscriber Identity Module' (SIM cardshall be
physically integrated with the radio set and shall not be
able to be removed except by maintenance staff.

5.7.10 The Cab radio should be mounted in the train cab in
compliance with [prEN 50261].

5.7.11 Any equipment mounted inside the train cab shall be
capable of withstanding the following maximum levels
of sinusoidal vibration:
peak-to-peak amplitude: 7mm;
acceleration: 1.5g.

5.7.12 Any equipment mounted external to the train cab shall
withstand the following maximum levels of sinusoidal
vibration:
peak-to-peak amplitude: 5mm;
acceleration: 2.5g.

5.7.13 The Cab radio shall comply with draft European stan-
dard [prEN 50124 part 1] concerning insulation co-
ordination with reference to clearances and creepages.

5.7.14 An emergency power supply should be provided for
Cab radios which will enable the driver's radio to con-
tinue to operate for a perod of 6 hours in the event of
failure of the train's main power supply, based on the
following cycle (see section 4.5.21): point-to-point calls
20%; group calls 5%; standby 75%.


5.7.15 The Cab radio equipment shall be capable of withstand-
ing the following changes to the main and backup
power supplies without interrupting normal operation:
voltage fluctuations up to +-15% of nominal supply
voltage;
20% over voltage for up to 10s;
other transient effects according to [IEC 571 parts 1-
3].

5.7.16 The Cab radio shall withstand the effects of power sup-
ply transients as defined in [prEN 50155].

5.7.17 The driver and other in-cab equipment shall be pro-
tected against all electrical hazards arising from EI-
RENE mobile equipment as defined in [EN 50153].

5.7.18 Requirements on EMC emissions for the Cab radio are
to be more stringent than those defined for other radio
types due to close proximity to other train mounted con-
trol and protection equipment, and higher transmission
power.

5.7.19 EMC emission from the Cab radio shall comply with
[ENV 50121 parts 1, 2, 3-2 and 4].

5.7.20 Emissions from the train mounted antenna associated
with the Cab radio shall be limited to those specified by
[EN 301 515, Index [35]].

5.7.21 Any emissions radiating into the driver's cab and other
on-board equipment from the exterior aerial shall meet
the requirements defined in [ENV 50121 parts 1, 2, 3-1,
3-2 and 4] to the highest possible degree.

5.7.22 The Cab radio shall pass electrical tests as defined in
[IEC 571 parts 1, 2 and 3].

5.7.23 Additional guidelines on testing procedures may be
taken from [prEN 50129] and [IEC 1508 part 1].

5,8 Cab radio interfaces to on-train systems
5.8.1 The following list catalogues the interfaces that should
be provided by the Cab Radio to the on-train systems:

Train borne recorder;


ERTMS/ETCS interface;
Public Address;
UIC Intercom;
Driver's Safety Device;
Other interfaces.
5.8.2 Where implemented, these interfaces are subject to the
requirements stated in the following sections.

5,9 Train borne recorder
5.9.1 The Cab radio and the train borne recorder may be
connected via the Train Interface Unit (TIU) or may be
connected directly by means of a nationally determined
interface.

5.10 ERTMS/ETCS interface
5.10.1 Some Cab radios will be required to provide communi-
cations for ERTMS/ETCS.

5.10.2 If ERTMS/ETCS communications are required, an inter-
face as defined in the FFFIS for EURORADIO
[MORANE EURO FFFIS] shall be implemented.

5,11 Public Address interface
5.11.1 If implemented, the Public Address interface should
comply with the specifications of the UIC Fiche [UIC
568].

5.12 UIC Intercom
5.12.1 If implemented, the UIC interface should comply with
the specifications of the UIC Fiches[UIC 558, 568].

5.13 Driver's Safety Device
5.13.1 The Cab radio and the Driver's Safety Device may be
connected via the Train Interface Unit (TIU) or may be
connected directly by means of a nationally determined
interface.

5,14 Other interfaces


5.14.1 Other interfaces may take the form of additional audio
and data inputs and outputs.

5.14.2 Where other data interfaces are implemented, they
should be of the RS422 standard.

5,15 Train Interface Unit (TIU)
5.15.1 Where necessary, a Train Interface Unit may be imple-
mented to adapt on-train systems to the standard inter-
faces provided by the Cab radio.

5.15.2 The interfaces between the TIU and the on-train sys-
tems are outside of the scope of EIRENE standardisa-
tion.

5.15.3 Figure 5-3 shows an example of how the Train Interface
Unit may be implemented:

5A Handling of calls
6 General purpose radio Outside the IOTs
6,1 Introduction
6.1.1 This section identifies the EIRENE applications which
may be used in the General purpose radio and the func-
tionality to be provided by the General purpose radio is
detailed. (I)

6.2.1 The logical architecture of the General purpose radio is
illustrated in figure 6-1. (I)

6.2.2 A standard data interface shall be provided to allow a
computer to be connected to the radio. (M)

6.2.3 The General purpose radio shall operate as a standard
GSM terminal, supplying mobile services as defined in
section 4. (M)

6,3 General purpose radio functions
Switch radio on
6.3.1 Automatic self-testing of the radio shall use the GSM
IMSI attach procedure. (M)


6.3.2 Upon switch on, once the radio is connected to a mobile
network, it shall be able to receive all calls made using
the MSISDN or appropriate group call number. (M)

6.3.3 It shall be possible to register and deregister a func-
tional number by the user entering his functional num-
ber, which is transmitted to the ground along with the
subscribers IMSI, using USSD (see section 11). (M)

6.4.1 The full environmental and physical specification of the
General purpose shall be as close as possible to that of
a Commercial-Off-The-Shelf (COTS) GSM mobile whilst
adhering to the specifications provided in section 4. (M)

6.4.2
6.4.3 The General purpose radio shall comply with the core
climatic conditions defined in section 4. (M)

6.4.4
6.4.2 The General purpose radio shall comply with the core
climatic conditions defined in section 4. (M)

6.4.3 SIM cards should be fixed into the radio to protect
against accidental loss. (O)

Mechanical conditions
6.4.4 No specific mechanical requirements need to be placed
upon the General purpose radio over and above those
defined in section 4. (I)

Electrical
6.4.4 No specific mechanical requirements need to be
placed upon the General purpose radio over and above
those defined in section 4. (I)


6.4.5 General purpose radios shall be equipped with re-
chargeable batteries capable of providing a minimum of
eight hours operation over the temperature range
+18C to +25C from a single charge, based on the
following cycle (see section 4.5.21): (M)
point-to-point calls 20%;
group calls 5%;
standby 75%.

6.4.6 Changing the battery shall not result in the loss of data
stored in the radio. (M)


6.4.7 The General purpose radio shall be suitable for use with
a car adapter kit. (M)

6.4.8
6.4.9 The General purpose radio should comply with [EN
50081] (generic EMC for residential, commercial and
light industry). (O)

6.4.10
6.4.11 No specific testing procedures need to be used on the
General purpose radio over and above those given in
section 4. (I)

6.4.8 The General purpose radio should comply with [EN
50081] (generic EMC for residential, commercial and
light industry). (O)

General purpose radio over and above those given in
section 4. (I)

7 Operational radio Outside the IOTs
7,1 Introduction
may be used in the Operational radio and the function-
ality to be provided by the Operational radio is detailed.
(I)


7.2.1 The logical architecture of the Operational radio is illus-
trated in figure 7-1.(I)

7,1 Introduction
may be used in the Operational radio and the function-
ality to be provided by the Operational radio is detailed.
(I)

7.2.1 The logical architecture of the Operational radio is illus-
trated in figure 7-1. (I)

7.2.2 A standard data interface shall be provided to allow a
computer to be connected to the radio. (M)

7.2.3 The Operational radio shall operate as a standard GSM
terminal, supplying mobile services as defined in sec-
tion 4. (M)

Switch radio on



Call controller
7.3.4 Upon receipt of the call establishment request, the radio
shall retrieve the stored number for the appropriate
controller from the SIM or other storage location. (M)


7.3.5 Once an appropriate number has been obtained, the
radio shall initiate a call to this number with Railway
operation priority (see section 10.2). Any functional
number associated with the user shall be passed to the
network using UUS1 (see section 11.5).
(M)

Send/receive Railway emergency call
cause the radio to initiate a Railway emergency call as
defined in section 13. (M)

The calling users functional number, if there is one,
shall be passed to the network using UUS1. (M)

Enter/leave direct mode
7.3.8 The Operational radio should support direct mode
communications as defined insection 15. (O)

Enter/leave shunting mode
7.3.9 The Operational radio should support shunting mode
communications as defined in
section 14. (O)

7,4 Shunting radio requirements
7.4.1 The requirements for shunting operations are detailed
in section 14. (I)

7.5.1 The Operational radio shall comply with the basic stan-
dards defined for all EIRENE mobile equipment in sec-
tion 4. In addition, the Operational radio is specified to
allow its use in the operating environment experienced
on the operational railway (eg shunting and mainte-
nance), with the specifications in this section taking
priority over those in section 4 where any discrepancy is
identified. (M)

Climatic conditions





7.3.4 Upon receipt of the call establishment request, the radio
shall retrieve the stored number for the appropriate
controller from the SIM or other storage location. (M)

7.3.5 Once an appropriate number has been obtained, the
radio shall initiate a call to this number with Railway
operation priority (see section 10.2). Any functional
number associated with the user shall be passed to the
network using UUS1 (see section 11.5). (M)

cause the radio to initiate a Railway emergency call as
defined in section 13. (M)

7.3.7 The calling users functional number, if there is one,
shall be passed to the network using UUS1. (M)

7.3.8 The Operational radio should support direct mode
communications as defined in section 15. (O)

7.3.9 The Operational radio should support shunting mode
communications as defined in section 14. (O)

7,4 Shunting radio requirements
7.4.1 The requirements for shunting operations are detailed
in section 14. (I)



7.5.1 The Operational radio shall comply with the basic stan-
dards defined for all EIRENE mobile equipment in sec-
tion 4. In addition, the Operational radio is specified to
allow its use in the operating environment experienced
on the operational railway (eg shunting and mainte-
nance), with the specifications in this section taking
priority over those in section 4 where any discrepancy is
identified. (M)

7.5.2 The Operational radio shall cope with rapid temperature
fluctuations of up to 3C/second. (M)

7.5.3 The Operational radio shall be capable of withstanding
exposure to extreme environmental conditions [IEC 721
part 1]. (M)

Physical conditions
exposure to extreme environmental conditions [IEC 721
part 1]. (M)

7.5.4 The Operational radio shall conform to IP 54 [IEC
529/EN 60529] as a minimum. (M)

7.5.5 SIM cards shall be fixed into the radio such that they
can only be removed by the use of a tool. (M)

7.5.6
7.5.5 SIM cards shall be fixed into the radio such that they
can only be removed by the use of a tool. (M)

the following shocks: (M)
semi-sinusoidal shocks of up to 5g for up to 100ms
under normal conditions;
shocks of up to 10g for up to 5ms under exceptional
conditions;
free fall from 1.0m.

Electrical
7.5.7 The Operational radio user shall be protected against
all electrical hazards arising from the mobile equipment
as defined in [EN 50153]. (M)


7.5.7 The Operational radio user shall be protected against
all electrical hazards arising from the mobile equipment
as defined in [EN 50153]. (M)

7.5.8 Operational radios shall be equipped with rechargeable
batteries capable of providing a minimum of eight hours
operation over the temperature range -10C to +55C
from a single charge, based on the following cycle (see
section 4.5.21): (M)
point-to-point calls 20%;
group calls 60%;
standby 20%.


7.5.10 The Operational radio shall be suitable for use with a
car adapter kit. (M)

7.5.11
7.5.12 The Operational radio should comply with [EN 50081
part 2] (generic EMC for the industrial environment). (O)

7.5.13
Operational radio over and above those given in section
4. (I)

7.5.15
7.5.16 Controller equipment specifications
7.5.17 General
7.5.18 Termination of VGCS/VBS calls
based on DTMF signalling (I)

7.5.20 To terminate a VGCS/VBS call by DTMF signalling, the
3-digit sequence *** shall be used.


between each tone.

7.5.22 Muting and unmuting for VGCS calls
7.5.23 Muting and unmuting shall be in line with [EN 301 515,
Index [4]]

7.5.24 A group call controller who wishes to start talking (ex-
cept in the case of an originator,
a joiner or a re-joiner speaking for the first time5) shall
indicate his wish, for example by pressing the PTT but-
ton, whereupon the 3-digit DTMF sequence ### shall
be transferred.

7.5.25 The terminal of the controller should receive a single
DTMF grant tone # of duration 100ms 5ms sent by
the network if it has detected the 3-digit DTMF se-
quence ### and if the controller was not previously
talking.

7.5.26 Any group call controller who wishes to stop talking
shall indicate his wish, for example by releasing the
PTT button, whereupon the 3-digit DTMF sequence
#** shall be transferred.

7.5.11 The Operational radio should comply with [EN 50081
part 2] (generic EMC for the industrial environment). (O)

Operational radio over and above those given in section
4. (I)

8 Controller equipment specifications Outside the IOTs
8,1 General
8,2 Termination of VGCS/VBS calls
based on DTMF signalling (I)


8.2.2 To terminate a VGCS/VBS call by DTMF signalling, the
3-digit sequence *** shall be used.

between each tone.

8,3 Muting and unmuting for VGCS calls
8.3.1 Muting and unmuting shall be in line with [EN 301 515,
Index [4]]

8.3.2 A group call controller who wishes to start talking (ex-
cept in the case of an originator,
a joiner or a re-joiner speaking for the first time5) shall
indicate his wish, for example by pressing the PTT but-
ton, whereupon the 3-digit DTMF sequence ### shall
be transferred.

8.3.3 The terminal of the controller should receive a single
DTMF grant tone # of duration 100ms 5ms sent by
the network if it has detected the 3-digit DTMF se-
quence ### and if the controller was not previously
talking.

8.3.4 Any group call controller who wishes to stop talking
shall indicate his wish, for example by releasing the
PTT button, whereupon the 3-digit DTMF sequence
#** shall be transferred.

8.3.5 The duration of each tone (see 8.3.2 and 8.3.4) added
in the voice channel, shall be 70ms 5ms, and there
shall be a minimum gap of 65ms between each tone.

9 Numbering plan
9,1 General
9.1.1 International standardisation of the numbering plan is
required to ensure interworking between networks. Fur-
thermore, standardised allocation of numbers to sub-
scribers is likely to facilitate schemes for identification,
barring etc. (I)


9.1.2 This section addresses the following: (I)
numbering plan requirements;
numbering plan limitations;
types of numbers;
EIRENE numbering plan;
short dialling codes;
group addresses.

9.1.3 The precise details of the numbering plan to be chosen
for particular railways will depend upon the railway net-
work configuration, its interconnection with other
railway networks and its interconnection with public
telecommunication networks.
Equipment design must therefore be such as to give
maximum flexibility in numbering arrangements. How-
ever, it may be generally assumed that numbers (ex-
cluding access prefixes) will not exceed 15 digits in
length and will consist entirely of the digits 1 to 9
and 0. (I)

9.1.4 Characters * and # may be used locally to gain access
to special facilities such as short code dialling. How-
ever, these arrangements do not form part of the net-
work numbering plan. (I)

9.1.5 Procedures for handling the relationship between EI-
RENE Numbers and MSISDN numbers (ie registration,
deregistration and re-registration) are specified in sec-
tion 11. (I)

9.1.6 Each railway should have appropriate call-barring facili-
ties to prevent unintended access to the GSM-R net-
work by non-authorised users. (O)

9,2 Numbering plan requirements
Use of Train Number
9.2.1 Within each GSM-R network, each Train Number shall
be unique for the period of the journey. (M)
2.16 2.17


9.2.2 Every On-Train Function shall be identified by a stan-
dard code and shall conform to the list of functions
given in Appendix 9A of this section. (M)
9.2.3 All Train Function Numbers and their associated
MSISDN numbers shall be stored in the same routing
database, which is the database of the GSM-R network
in which the train is currently operating. (M)
2.12
Use of Engine Number
9.2.4 Every On-Engine Function shall be identified by a stan-
dard code and shall conform to the list of functions
given in Appendix 9A of this section. (M)
9.2.5 The Engine Function Number(s) and associated
MSISDN numbers shall at any time be stored as an
entry in the routing database of the home GSM-R net-
work6 of the engine. (M)
2.13
Use of Coach Number
9.2.6 The Coach Function Number(s) and associated
MSISDN number(s) shall at any time be stored as an
entry in the routing database of the home GSM-R net-
work of the coach. (M)
2.14
Use of Shunting Team, Maintenance Team or Train
Controller Number

9.2.7 Every Function shall be identified by a standard code
and shall conform to the list of functions given in Ap-
pendix 9A of this section. (M)
9.2.8 The functional numbers of the Shunting Team Mem-
bers, Maintenance Team Members and Train Controller
(and any associated MSISDN numbers) shall be stored
as entries in the routing database of the home GSM-R
network. (M)
2.15
Use of MSISDN number


9.2.9 Implementation of the EIRENE numbering plan shall not
prohibit any authorised caller from using the MSISDN
number where known, thus enabling mobiles to be
assigned to particular personnel where this is appropri-
ate. (M)
3.5 3.6
Use of group call Service Areas
9.2.10 Service areas shall be defined within each railway net-
work. (M)
Configuration aspects are tested implicitely by various test cases,.e.g. 8.1
9.2.11 The numbering of Service Areas for group calls and
broadcast calls shall be made in accordance with GSM
Technical Specifications [EN 301 515, Index [21] & [4]]
and [EN 301 515, Index [22] & [5]] respectively. (M)
Configuration aspects are tested implicitely by various test cases, e.g. 8.1 and 9.1
9.4
9,3 Numbering plan limitations
9.3.1 The EIRENE network can not be considered as a fully
private network, as some parts of either the mobile or
fixed networks may be provided by public operators.
This leads to certain restrictions on the implementation
of a numbering plan. These restrictions are given be-
low. (I)

Number allocation
9.3.2 To achieve integration of the EIRENE numbering plan
with the national public numbering plan, telephone
numbers have to be allocated by the various numbering
regulatory bodies on a national basis. If functional num-
bers are to be used outside the EIRENE network, they
will require either a public number allocation or, alterna-
tively, an EIRENE Network Access Number (ENAN)
may be used as described in 9.11 (I)

9.3.3 Each national railway should obtain a public numbering
allocation for MSISDN numbers from the relevant regu-
latory bodies. (O)

9.3.4 The EIRENE numbering plan shall be standardised to
allow interoperability and shall be implemented as a
private numbering plan within the GSM-R network. (M)
Covered by international calls, e.g. 3.3


Use of alphanumerical numbers
9.3.5 In some countries Train Numbers are alphanumeric.
These numbers do not comply with a numbering plan
that can be interpreted by telephone switches and are
therefore not supported by the call routing solution
given in section 11. (I)

9.3.6 If alphanumerical numbering is required within a railway
network, then these numbers may either be translated
at the user terminal into a subscriber number or
conveyed between the calling party and a routing data-
base using a nationally determined approach. (I)

9,4 Types of numbers
9.4.1 Within the GSM-R network, the user shall be able to
dial the following types of numbers: (M)
National EIRENE Number (NEN): this number is used
to route a call from the calling party to a called party
registered within the same GSM-R network;
International EIRENE Number (IEN): this number is
used to route a call from the calling party to a called
party registered within another GSM-R network;
MSISDN numbers: the number used by a subscriber
of a public fixed (or mobile) network for calling a mo
bile station of a GSM PLMN;
Short Dialling Code (SDC): this number is used to
allow speed dialling functionality.
Covered by national and international calls as well as by LDA calls, e.g. 2.24, 2.26 and 4.1
4.3
9.4.2 In addition, Breakout Codes (BCs) shall be used to
allow users within the GSM-R network to access exter-
nal numbers. (M)
3.7 3.8
9.4.3 Access from the GSM-R network to external networks
shall be as detailed in section 9.10. (M)
11.1 11.2
9,5 Use of National EIRENE Numbers
9.5.1 National EIRENE Numbers are used to set up calls
within a single GSM-R network. (I)


9.5.2 Every railway network shall consider a number as a
National EIRENE Number (NEN) unless the number is
preceded by an International Code, identifying another
GSM-R network. (M)
2.24 2.26
Structure of National EIRENE Number
9.5.3 The National EIRENE Number shall consist of three
distinct parts, as shown in figure
9-1: (M)
2.24
National EIRENE Numbering Plan
9.5.4 The contents of the fields of a National EIRENE Num-
ber shall be as defined below: (M)
2.24 6.2 6.3 6.28 6.29 8.35 8.36 9.4
9,6 Use of International EIRENE Numbers
9.6.1 International EIRENE Numbers are used for calls be-
tween GSM-R networks.
Additional fields are added to the National EIRENE
Number as routing indicators.
The use of such indicators is discussed in subsection
9.10. (I)

9.6.2 GSM-R networks shall recognise International EIRENE
Numbers starting with the IC of the GSM-R network in
which the calling party is currently operating as National
EIRENE Numbers. (M)
2.24 2.26
Structure of International EIRENE Number
9.6.3 The International EIRENE Number shall consist of three
distinct parts, as shown in
figure 9-2: (M)
2.26
International EIRENE Numbering plan
9.6.4 The fields of an International Functional Number shall
be defined as follows: (M)
2.26
9,7 Use of MSISDN numbers
9.7.1 At least one MSISDN number shall be allocated to each
mobile station. (M)
9.7.2 The structure of the MSISDN numbers shall comply
with GSM Technical Specification [GSM 03.03]. (M)


9.7.3 Within each GSM-R network, the following relationships
between the MSISDN Subscriber Number and the Na-
tional EIRENE Number can be identified:
the MSISDN Subscriber Number shall be equal to the
National EIRENE Number for Call Type = 8; (M)
the MSISDN number may be equal to the National
EIRENE Number for any other Call Type. (O)
1.8 (configuration issue)
9.7.4 It shall be possible for authorised subscribers of fixed
and mobile networks to call
mobiles using the appropriate MSISDN number. (M)
1.11 1.21
9,8 Use of Short Dialling Codes
9.8.1 For certain functions, standardised short codes shall be
implemented for mobile
originated calls. (M)
4.1 4.3
9.8.2 Each short dialling code shall consist of four digits. (M) 4.1 4.3
9.8.3 Short dialling codes shall start with the first digit equal
to 1 (ie CT=1). (M)
4.1 4.3
9.8.4 The short dialling codes can be defined on a national
basis, but it is essential that certain codes be used on
an international basis in order to achieve interoperabil-
ity. These codes shall be as given in table 9-10. (M)
4.1 4.3
9.8.5 In addition, the network shall support the special short
codes as defined in table 9-11. (M)
7.4, 7.32,
7.37

9,9 Use of group addresses
9.9.1 Standardisation of UIC group addresses is required to
provide interoperability
between the fixed railway networks within the GSM-R
network. (M)
Standardisation issue
9.9.2 The group address consists of a Service Area (5 digits)
and a Function Code (3 digits) and has a Call Type 5
(see table 9-1). (M)
8.3
9.9.3 The Service Area shall be defined on a national basis.
(M)
9.9.4 In network boundary areas, the Service Area shall be
allocated on a bilateral basis. (M)
8.35


9.9.5 Function Codes shall be defined within the framework
given in table 9-8 on an international basis. (M)
8.1
9.1 Access to external networks
9.10.1 Access to other GSM-R networks shall be possible by
using a Breakout Code (BC) as part of the dialled num-
ber. (M)
3.7 3.8 3.3 2.26
9.10.1i Access to other GSM-R networks may be possible by
using an Access Code (AC) as part of the dialled num-
ber if the NSN (National Significant Number) following
the CC (Country Code) is assigned by the national tele-
communication regulator to the GSM-R operator. (O)
3.7 3.8
9.10.1ii The BC for access to other GSM-R networks is defined
in table 9-12a, and is followed by the full international
EIRENE number of the called party. (M)
3.7 3.8 3.3 2.26
9.10.1iii The AC for access to other GSM-R networks is defined
in table 9-12b, and is followed by the CC + NDC + SN
of the other GSM-R network. The number format com-
plies with [ITU-T 164]. (M)
3.7 3.8
9.10.1iv It is the responsibility of each individual GSM-R opera-
tor to acquire a public domain NDC from their national
telecommunications regulator. (I)
3.12 3.11
9.10.1v Access to private networks shall be performed by using
a BC, defined in table 9-12c. (M)
3.12 3.11
9.10.2 The GSM-R network shall allow users direct access to
public networks, subject to call barring restrictions. (M)
1.47
9.10.3 Where access to public networks is allowed, this shall
be performed by using an Access Code (AC), defined in
table 9-13, followed by the international or national
number of the called subscriber as defined in [ITU-T
164]. (M)
3.9 3.10
9.10.4 Deleted.
9,11 Calls from external networks to the GSM-R network


9.11.1 Access to the GSM-R network should be performed by
dialling an EIRENE Network Access Number (ENAN)8,
followed by the relevant National or International
Functional Number as defined in subsections 9.5 and
9.6 respectively. (O)

9.11.2 Provision should be made to prevent unauthorised calls
to mobiles from outside the GSM-R network. (O)

9A Function Codes
9A.1 Function Codes identify the actual user of a mobile. (I)
9A.2 The Function Codes used in association with the Train
Function Number (CT=2), Engine Function Number
(CT=3) and Coach Function Number (CT=4) shall con-
form to table 9A-1. (M)
9A.3 The Function Codes used in association with Mainte-
nance Services Team Numbers (CT=6) shall conform to
table 9A-2. (M)
10 Subscriber management
10,1 Introduction
10.1.1 In order to provide a consistent level of service in each
railway network and, in particular, to ensure interopera-
bility for train drivers and other users roaming between
networks, it is important to harmonise subscription de-
tails and other information stored in the network. (I)

10.1.2 For the purposes of defining common subscription pro-
files, a number of subscription types might be used, for
example: (I)
Cab radio;
on-train radio;
controller;
trackside worker;
general staff;
data systems;
administration/management.

10,2 Allocation of priorities


10.2.1 In order to provide a consistent international service, it
is necessary to ensure that priorities are allocated con-
sistently across all railways. The following allocation of
UIC priority levels to eMLPP priority codes is manda-
tory: (M)
1.16 1.17 1.38 1.39 5.1
10.2.2 Levels 0 4 are designed to interwork with the ISDN
MLPP service. (I)

10,3 Access classes
10.3.1 User access classes are defined in GSM so that under
critical conditions, part of the user population can be
barred from accessing the network in order to avoid
congestion. However, such barring can be overridden
by a user being a member of one or more of the follow-
ing special access classes: (I)
11 open to network operator;
12 security services;
13 public utilities;
14 emergency services;
15 network operator staff.

10.3.2 Access classes should not be used under normal net-
work operating conditions, where the GSM eMLPP may
be used to provide a better grade of service to certain
users. (O)

10.3.3 For consistent working on public networks and in inter-
national roaming, the use of access classes in a railway
network shall comply with the GSM specification. (M)
eMLPP is applied
10.3.4 If special access classes (eg 12 - 14) are assigned
within a railways network to certain high priority users,
it ought to be noted that when roaming, this will only
have an effect on a national public network, subject to
bilateral agreement. (I)

10,4 Closed user groups


10.4.1 Closed User Groups (CUGs) may be employed by rail-
ways as an additional security measure. Such facilities
may be particularly important if public network access to
the radio system is provided (eg to prevent members of
the public calling drivers and drivers calling members of
the public). (I)

10.4.2 Any implementation of CUGs must take account of re-
quirements for interoperability. (M)
1.46 1.47 1.45
10,5 Network selection Terminal's feature
10.5.1 SIM cards shall contain a list of authorised networks so
that networks shall be displayed (or automatically se-
lected if automatic network selection has been enabled)
in the following order of priority (see [MORANE SIM] for
more details): (M)
home EIRENE network;
foreign EIRENE networks;
non-EIRENE networks (with order of priority prede-
termined by virtue of international subscriptions and
roaming agreements).

10.5.1i In order to shorten the duration of the network selection
procedure, Mobile Stations designed for use in EIRENE
networks shall give preference to the GSM frequency
band allocated for railway use (see 3.5.2). (M)

10.5.2 The use of Over The Air in conjunction with the SIM
Application Toolkit [EN 301 515, Index [36]] to update
SIM cards in the home network is recommended (see
[MORANE SIM] for more details). (I)

10,6 Cell broadcast message identifiers Terminal's feature
10.6.1 Railway mobiles shall be provided with cell broadcast
message identifiers in order to accept SMS-CB mes-
sages. (M)

10,7 Encryption and authentication
10.7.1 Encryption. Licensing of A5/x encryption algorithms is
managed by the GSM Association. (I)


10.7.1i In case of encryption, standardised ciphering algorithms
shall be used. (M)
1.8 1.30
10.7.2 Deleted.
10.7.3 Mobiles shall be capable of operation using algorithms
for all countries in which they need to roam. (M)
1,8 1.30
10.7.4 Authentication. Each railway is free to implement its
own authentication algorithms without any resulting loss
in cross-border interoperability. (I)

11 Functional numbering and location dependent address-
ing

11,1 Introduction
11.1.1 There is a requirement to be able to address communi-
cations to a functional number rather than a more per-
manent subscriber number. Such numbers are gener-
ally only associated with a user for a limited period of
time. (I)

11.1.2 This is an important issue which will affect interoperabil-
ity and the ability to use public network services. There
are specific features of individual railways which make
it difficult to develop a concise and universally accept-
able system within GSM. (I)

11.1.3 To accommodate the different requirements of the indi-
vidual railways, the following approach has been
adopted: (I)
all responsibility for handling addressing lies with the
network infrastructure and other ground based equip
ment, rather than additional functionality in the mobile;
each railway will be responsible for implementing
addressing schemes which best meet its needs;
national addressing schemes are to use the interna
tionally standardised groundtrainprotocol, based on a
single standardised GSM service, for exchanging
information between the ground and mobiles.

11,2 Ground-train addressing


11.2.1 The ground-train addressing can be divided into two
areas: (I)
functional addressing of mobile users;
location dependent addressing of fixed network users.

11.2.2 The first is related to passing information to provide an
association between a mobiles subscriber number and
its functional number. The latter is concerned with en-
suring that calls from a mobile terminal (in particular,
Cab radios) are routed to the correct destination (ie
primary controller, secondary controller), based on the
current location of the mobile. (I)

11.2.3 The numbering plan to be used with functional address-
ing shall be in accordance with the numbering plan
given in section 9. (M)
11,3 Functional numbering
General
11.3.1 Functional numbering provides the mechanism by
which a mobile terminal, or an item of equipment con-
nected to a mobile terminal, can be addressed by a
numberidentifying the function for which it is being
used. (I)

11.3.2 Mobile access to the functional numbering scheme for
registration, deregistration and re-registration shall ap-
ply the USSD messages and protocols over the air in-
terface as specified in the GSM Follow-me service. (M)
2.1 2.4 2.10 2.18 1.46 1.47 1.45
11.3.3 The implementation of functional numbering at a net-
work level is left open for national railways subject to
the requirements for interconnecting EIRENE networks
identified in section 11.6. (I)

11.3.4 Further information may be obtained from [MORANE
SSRS, MORANE FA FFFS, MORANE FA
FIS]. (I)

Functional number management


11.3.5 For communication over the (Um) air interface, the
USSD messages and protocols as specified in the GSM
Follow-me service shall be used to manage the follow-
ing types of functional numbers: (M)
Train number;
Engine number;
Coach number;
Shunting team number;
Maintenance team number.
2.l 2.4
11.3.6 It shall be possible to limit user access to functional
number registration and deregistration facilities based
on each of the types of functional number identified in
11.3.5. (M)
2.9 2.22
11.3.7 Mobile stations shall use the following sequences for
the control of the functional number management: (M)
2.1 2.4 2.7 2.8 2.10 2.10 2.18 2.24
11.3.8 The network operator shall implement the required
functionality to validate the information exchanged be-
tween the mobile and network on registration and
deregistration. (M)
2.4 2.11 2.16 2.17
11.3.8i Functionality shall be provided by the system for the
operator management of Functional Numbers, including
the removal of the relationship between Functional
Numbers and MSISDN Numbers. (M)
2.7 2.8 2.20 2.21 1.46 1.47 1.45
11.3.8.ii The use of the forced de-registration mechanism (with-
out notification) to achieve this requirement is accept-
able. (I)

11.3.8iii The system shall require manual confirmation prior to
the removal of the relationship between Engine Number
and MSISDN Number. (M)
System terminal issue.
Registration


11.3.9 The result of the registration procedure shall be sent
back to the mobile. In the event of a failure, an indica-
tion of the cause shall be provided. Information on the
outcome shall be provided to the mobile according to
[EN 301 515, Index [17]] and [EN 301 515, Index [34]].
(M)
2.4 2.11 2.16 2.17
11.3.9i In the event of a registration procedure failing owing to
the functional number already being registered to an-
other mobile, the Cab radio shall be capable of provid-
ing the user with the ability to perform automatically the
forced de-registration of the previously registered mo-
bile and the registration of this functional number to the
users mobile.
This shall result in the following sequence of actions
being performed by the users Cab radio (see 11.3.7 for
details of message structure): (M)
1. Send interrogation message (from mobile to net-
work).
2. Receive MSISDN (from network to mobile).
3. Send a forced de-registration message (from mobile
to network).
4. Receive the answer (from network to mobile).
5. Send a registration message (from mobile to net-
work).
6. Receive the answer (from network to mobile).
7. Inform the user whether the registration of the func-
tional number to the users
mobile was successful (performed by the mobile).
Terminal issue
11.3.9ii The functionality described in 11.3.9i should also be
available for other types of mobiles. (O)

11.3.9iii In the cases described in 11.3.9i and 11.3.9ii, national
rules may dictate that, prior to or instead of performing
the sequence described in 11.3.9i steps 1-7, the user
shall perform a specified action (e.g. call a dispatcher in
the case of drivers). (I)


11.3.9iv The sequence described in 11.3.9i steps 1-7 may be
interrupted or may require additional user action such
as a confirmation. (I)

Deregistration
11.3.10 Deregistration shall only be performed by the subscrip-
tion identified by the MSISDN number which is associ-
ated with the functional number. (M)
2.4 2.6 2.18 2.19
11.3.11 Deleted.
11.3.12 The result of the deregistration procedure shall be sent
back to the mobile. In the event of a failure, an indica-
tion of the cause shall be provided. Information on the
outcome shall be provided to the mobile according to
[EN 301 515, Index [17]] and [EN 301 515, Index
[34]]. (M)
2.4 2.6 2.18 2.19
Re-registration
11.3.13 Re-registration consists of a registration procedure fol-
lowed by a deregistration procedure. (I)

11.3.14 Re-registration of on-train functional numbers based on
the train number shall be performed every time a train
leaves one EIRENE network and enters into another
EIRENE network. (M)
2.10
11.3.15 Deregistration of a functional number shall not be car-
ried out until registration of the functional number has
been carried out and confirmed as being successful.
(M)
MS-issue
11.3.16 Each railway should define a suitable time-out interval
to be applied as part of the deregistration procedure for
on-train functional numbers. (O)

Functional numbering network interworking
11.3.17 The exchange of information between EIRENE net-
works is handled by the GMSCs and shall use the stan-
dardised protocol as detailed in section 11.6. (M)
2.10 2.18 2.20
11,4 Re-establishment of functional number correlation


11.4.1 In the event of losing correlation between functional
numbers and MSISDNs, provision for recovery from
such a situation shall be made. (M)
2.23
11.4.2 Each national railway is responsible for implementing a
suitable recovery mechanism and ensuring that the use
of unverified functional numbers is prevented. (I)

11.4.3 Deleted.
11.4.4 Deleted.
11.4.5 Deleted.
11,5 Presentation of functional identities
11.5.1 The called party functional identity shall be presented to
the user initiating a call and the calling party functional
identity shall be presented to the user receiving a call.
(M)
2.24 2.26 1.46 1.47 1.45
11.5.2 The calling party functional number shall be passed to
the receiving mobile using the User to User Signalling
supplementary service (UUS1) during call setup. (M)
2.24 2.26
11.5.3 If the calling party functional number is not available or
if the calling party is not registered then the CLI of the
calling party shall be displayed on the receiving mo-
bile's display. (M)
MS-issue
11.5.4 The user-to-user information element in the SETUP,
ALERT or CONNECT messages,
as defined in [EN 301 515, Index [16]], shall be used to
transfer the functional number of the calling party to the
called party. (M)
2.24 2.26
11.5.5 The user-to-user information element shall use the fol-
lowing format: (M)
2.24 2.31
11.5.6 If no valid functional number is available, a fixed length
User-to-User Information Element shall be used with
the following format: (M)
MS-issue
11.5.7 Further information may be obtained from [MORANE
PFN FFFS, MORANE PFN FIS]. (I)

11,6 Inter EIRENE network interfacing 2.10 2.20


11.6.1 Interconnection of EIRENE networks is required to al-
low international call routing. It is not envisaged that any
routing database information is exchanged between
EIRENE networks. (I)

11.6.2 The interconnection of EIRENE networks should take
place by interconnecting GMSCs.(O)

11.6.3 The protocol used for routing of calls shall be Signalling
System No 7 (SS7) as defined by the ITU-T. The signal-
ling system suite shall include the Mobile Application
Part (MAP). (M).
2.15 2.18 2.22
11.6.4 Call setup between EIRENE networks using interna-
tional functional numbers shall be based on the combi-
nation of the Breakout-Code (BC) and International
Code (IC) as specified in section 9. (M).
2.15 2.18 2.22
11.6.5 The Country Code (CC) followed by the National Sig-
nificant Number NSN (as specified in ITU-T E.164,
Chapter 6.2) shall be used as the Global Title, which
forms part of the Signalling Connection Control Part
(SCCP) protocol messages and is used for inter-
network routing of messages. (M)
2.15 2.18 2.22
11.7 Location dependent addressing
General
11.7.1 Location dependent addressing may be provided in the
following ways:
a) cell dependent routing; (M)
b) using location information from external sources. (O)
4.1 4.2 4.3 4.4
Cell dependent routing
11.7.2 As a minimum, call routing using location dependent
addressing shall be based on the use of short codes in
conjunction with cell dependent routing. (M)
4.1 4.2 4.3 4.4
11.7.3 Further information on cell dependent routing for loca-
tion dependent addressing may be obtained from
[MORANE SSRS] [MORANE LDA FFFS] [MORANE
LDA FIS]. (I)


Location information from external sources
11.7.4 Location information may be provided by systems ex-
ternal to the radio system, for example ground-based
systems such as track circuits. (I)

11.7.5 If a more accurate way of location determination is
used, then position information shall be provided to the
radio system which shall be used to associate the short
code with the correct called party subscriber number.
(M)

11.7.6 If implemented, the use of location information from
train-based systems external to the radio system shall
comply with the requirements stated in the enhanced
Location Dependent Addressing FRS and IRS [eLDA
FRS and eLDA IRS]. (M)
eLDA is optional
11,8 Calls from external networks to the EIRENE network
11.8.1 Facilities shall be provided to prevent unauthorised calls
to mobiles either by functional number or MSISDN
number from outside the EIRENE network. (M)
3.1 3.2 3.3 3.4 3.5 3.6
12 Text messaging
12.1 Introduction
12.1.1 There is no requirement for an internationally standard-
ised pre-defined messaging application. However, it is
anticipated that individual national railways may have a
requirement for pre-defined messages, in which case
the application will be specified as part of individual
national procurements.

12,2 System requirements
12.2.1 Where text messaging is implemented in the network,
the Short Message Service (SMS) shall be used

13 Railway emergency calls
13,1 Introduction


13.1.1 This section covers the use of the EIRENE radio sys-
tem for Railway emergency calls.
The section also discusses the facility for confirmation
of such emergency calls and the storage of confirmation
for post-incident analysis.

13.1.2 A Railway emergency call is a high priority call for in-
forming drivers, controllers and other concerned per-
sonnel of a level of danger requiring all Railway move-
ments in a pre-defined area to stop. Two types of Rail-
way emergency calls are defined: (I)
- Train emergency calls (for Railway emergencies whilst
not involved in Shunting operations);
- Shunting emergency calls (for Railway emergencies
whilst involved in Shunting operations).

13.1.3 This section describes the handling of high priority voice
calls for Railway operational emergencies and does not
cover public emergency calls (ie handling of 112 calls).

13,2 Provision of Railway emergency calls
13.2.1 Railway emergency calls are defined as those calls of
Railway emergency priority (see section 10) which are
routed to a pre-defined user or group of users due to a
railway operational emergency

13.2.2 All Railway emergency calls shall be implemented using
GSM VGCS (Specifications [EN 301 515, Index [21] &
[4]]). (M)
6.1 6.2 6.3 6.5 6.6 6.28 6.29
13.2.3 It shall be possible to configure Railway emergency
group call areas to contain combinations of cells con-
trolled by one or more MSC(s) within one or more net-
work(s). (M)
6.6
13.2.4 Where Railway emergency group call areas are con-
trolled by more than one MSC within one or more net-
work(s), a unique anchor MSC is defined for each group
call area.


13.2.5 For international Railway emergency calls, in order to
minimise call set-up times, it is recommended that the
anchor MSC always directly controls the cell where the
Railway emergency call was originated.

13,3 Initiation of Railway emergency calls
13.3.1 A Railway emergency call shall be initiated by using the
appropriate function code for the required type of Rail-
way emergency call (see Table 9-8). (M)
6.2 6.3 6.6 6.28 6.29
13.3.2 The call area and list of train controllers for each emer-
gency group call will be fixed in the Group Call Register
(GCR) of the anchor MSC.

13.3.3 The Railway emergency group IDs required for interop-
erability are defined in section 9.5. The composition of
each group is a matter for national implementation,
although all areas shall have a group defined for all
mandated Group IDs.
6.1 6.2 6.3 6.5 6.28 6.29
13,4 Receipt of Railway emergency calls
13.4.1 Each mobile shall store a list of emergency Group IDs
in the SIM appropriate to its function (the Cab radio will
store Group ID 299 and 599 - see table 9-8).
6.3 6.6
13.4.2 All Railway emergency group IDs required for interop-
erability and appropriate to the operation of the mobile
shall maintain active status whilst the mobile is powered
up.
6.3 6.6
13.4.3 The fixed network user will only receive emergency
voice calls if designated a dispatcher or group member
in any of the calls defined in the GSM GCR.

13.4.4 On receipt of a Railway emergency call, the controllers
display should indicate the location of the train.

13.4.5 If the requirement in 13.4.4 is implemented, as a mini-
mum the location information shall be provided by the
GSM network (eg current cell or base station serving
the mobile).


13.4.6 The mechanism for transferring the functional number
of the originating mobile to controllers is defined in [EN
301 515, Index [6], Release 4] using the Information
Element Compressed OTDI in the Immediate Setup 2
message from the originating mobile.
6.8
13.4.7 If the GSM Release 99 capability and the Immediate
Setup 2 feature defined in [EN 301 515, Index [6], Re-
lease 4] are supported by the network, the network shall
set the MSC Release bit in the Control Channel De-
scription information element to 1. Otherwise, the
MSC Release bit in the Control Channel Description
information element shall be set to 0 (zero) [EN 301
515, Index [41]].
6.8
13.5 Confirmation of Railway emergency calls
13.5.1 For post-incident analysis it is important that the initia-
tion and receipt of Railway emergency calls by mobiles
is confirmed by a message sent to a ground-based
location (and also registered in the train borne recorder,
in cases where a train borne recorder is connected to
the Cab radio).

13.5.2 Not all calls require confirmation. The application must
be able to deduce that a confirmation is necessary from
the call priority, as all calls of Railway emergency
priority must be confirmed.
Terminal's feature
13.5.3 Confirmation of Railway emergency calls shall be im-
plemented using the User to User Signalling supple-
mentary service (UUS1).
6.4 6.7
13.5.4 After clear down of the Railway Emergency call, the
mobile application shall start the confirmation process
by automatically originating a call. In order to avoid
network congestion the call set up shall be delayed by a
random offset.
Terminal's feature


13.5.5 Railway Emergency call confirmation messages shall
be of eMLPP priority 4 -
Railway information and all other calls (see section
10.2).
6.4 6.7
13.5.6 The user information contained in the confirmation
message shall be: (M)
- Cab radio: the engine number or train number (if regis
tered);
- other mobiles: the users functional number (if regis
tered).
Terminal's feature
13.5.7 Confirmation messages shall be sent to a confirmation
centre using a defined short code (see table 9-10),
which shall be associated with the GSM network.
6.4 6.7
13.5.8 In the case of Cab radio, details of the confirmation
shall be passed to the train borne recorder if a train
borne recorder is connected to the Cab radio.
Terminal's feature
13.5.9 The user-to-user information elements in the following
messages, as defined in [EN 301 515, Index [16]], shall
be used for the confirmation of high priority calls: (M)
SETUP: transfer of confirmation message to confir
mation centre;
RELEASE COMPLETE: acknowledgement of the
confirmation message.
6.4 6.7
13.5.10 The SETUP and RELEASE COMPLETE user-to-user
information element shall be as specified in the
[MORANE UUIE].
6.4 6.7
13.5.10i Confirmation centres shall be capable of decoding
messages in either format A or B.
6.4 6.7
13.5.11 Deleted.
13.5.12 Deleted.
14 Shunting mode Not covered by IOTs
14,1 Introduction


14.1.1 The purpose of shunting mode is to provide an effective
means of communication to a group of personnel who
are involved with a shunting operation.

14.1.2 The shunting group may comprise a shunting leader, a
shunting driver, a controller and up to three additional
personnel (the shunting members).

14.1.3 Further information about shunting mode may be ob-
tained from [MORANE SM FFFIS].

14,2 System requirements: Operational Radio
14.2.1 On entering shunting mode, the operational radio shall
determine if any shunting group ID is already activated
on the SIM.

14.2.2 If a shunting group ID is activated, the operational radio
shall proceed to re-establish the group call.

14.2.3 If no shunting group ID is activated, the operational
radio shall initiate a 'regularshunting mode ON' proce-
dure as detailed in table 14-1

14.2.4 After the 'regular shunting mode ON' precedure has
been completed, the procedures shown in table 14-2
and 14-3 shall be used to register the shunting leader
and shunting members to a dedicated group call.


14.2.5 Two possibilities shall be available to the shunting
leader when leaving shunting mode:
Release group call: the shunting leader and all other
shunting members leave the dedicated group call and
all members of the group are deregistered. The proce-
dure that shall be used to release the group call is
shown in table 14-4.
Maintain group call: the shunting leader leaves the
dedicated group call momentarily for the purposes of
conducting other communications. The leader may then
rejoin the group when ready. In the meantime, all other
shunting team members remain active within the dedi-
cated group call. The operational radio procedure that
shall be used to maintain the group call is shown in
table 14-5.

14.2.6 On leaving shunting mode, the Operational radios of
shunting members shall follow the procedure shown in
table 14-6.

14,3 System requirements: Cab radio
14.3.1 On entering shunting mode, the Cab radio shall deter-
mine if any shunting group ID is already activated on
the SIM.

14.3.2 If a shunting group ID is activated, the Cab radio shall
proceed to re-establish the group call.

14.3.3 If no shunting group ID is activated, the Cab radio shall
initiate a 'regular shuntingmode ON' procedure as
shown in table 14-7.
6.20 6.23 8.38 8.41 6.20 6.23
14.3.4 The Cab radio shall exit shunting mode by means of the
"Leave shunting mode" procedure as defined in table
14-8.

14,4 System requirements: Operational radio and Cab radio
14.4.1 On entering shunting mode, the terminal shall initially
select the common shunting group.


14.4.2 The common shunting group provides a point of contact
for leaders and team members to set up a dedicated
shunting group call for their shunting operation.

14.4.3 The terminal application shall prevent members of a
dedicated shunting team from initiating a new call
(unless they are registered as shunting team leader and
have left shunting mode using the 'maintain groupcall'
function described in 14.2.4)

14.5 Numbering plan
14.5.1 The full numbering plan for shunting mode group calls
is defined in subsection 9.9.

14.5.2 Valid group IDs shall be as defined in table 14-9.
14,6 Control of shunting group membership
14.6.1 Users shall be prevented from joining a dedicated
shunting group by the EIRENE terminal application
unless a valid functional number for the group has been
successfully registered to the GSM-R network by their
terminal.

14.7 Link assurance signal
14.7.2 The link assurance tone shall be of the form specified in
subsection 14.4.2 of the [EIRENE FRS].

14.7.3 The mechanism for the generation of the link assurance
signal shall be as specified in [MORANE SM FFFIS].

14.7.5 The mechanism for the deactivation of the link assur-
ance signal shall be as specified in [MORANE SM
FFFIS].

15 Direct mode DM is an option
15.1 Introduction


15.1.1 The operational requirement for direct mode is to: (I)
1) provide short range fall-back communications be-
tween train drivers and trackside personnel in the event
of failure of all railway and/or public GSM services nor-
mally available;
2) provide short range communications for railway per-
sonnel operating in remote areas where no GSM facili-
ties are available.

15,2 System requirements
15.2.1 Implementation of direct mode is optional. However,
where implemented, the
following requirements shall be mandatory. (I)

15.2.2 Frequency modulated equipment conforming to [ETS
300 086] shall be used for direct
mode. (M)

15.2.3 Direct mode equipment shall have a maximum transmit
power of 1 Watt. (M)

15.2.4 Direct mode equipment sensitivity shall be at least
107dBm. (M)

Frequency range and mode of operation
15.2.5 Direct mode equipment shall be capable of operation in
the channels defined in table 15-1. (M)

15.2.6 Direct mode shall operate in simplex mode, a radio link
that uses a single frequency for alternate transmission
and reception. (M)

15.2.7 Voice transmission from direct mode equipment shall
be possible only when the Push- To-Talk (PTT) button
is pressed. (M)

CTCSS
15.2.8 Continuous Tone Coded Squelch Systems (CTCSS)
shall be implemented on all direct
mode equipment. (M)

15.2.9 The CTCSS tone shall be at a frequency of 203.5 Hz.
(M)


15.2.10 The CTCSS modulation shall be within the limits de-
fined in table 15-2. (M)

Direct mode common access channel
15.2.11 The purpose of the common access channel is to pro-
vide a point of contact and information for all direct
mode users. For example, if one direct mode user
wished to initiate contact with another user, communi-
cation would begin with a request for the desired part-
ner on the access channel. After receiving a reply, both
parties may transfer to a free direct mode channel and
continue. (I)

15.2.12 Direct mode channel 1 (876.0125 MHz) shall serve as
the common access channel. (M)

15.2.13 Equipment should default to operation on the common
access channel (direct mode channel 1) on entry into
direct mode. (O)

Direct mode interaction with GSM-R
15.2.14 Direct mode communications will only be used in the
event of normal GSM-R services being unavailable. (I)

15.2.15 The presence of the GSM-R network shall be indicated
to direct mode users. (M)

15.2.16 All terminals shall ensure that when GSM-R services
are available, the user is prevented from entering direct
mode. (M)

15.2.17 In the event of GSM-R causing disruption to ongoing
direct mode communications, each railway will define a
protocol for re-establishing contact by means of GSM-
R. (I)

Shunting link assurance signal
15.2.18 All direct mode equipment shall provide the facility to
broadcast an in-band audio shunting link assurance
signal as defined in subsection 14.4.2 of the [EIRENE
FRS]. (M)


Table 6.3: Cross reference of EIRENE SRS V15 mandatory requirements to the IOT test cases


6.2 Annex - Configuration of User Equipment for Data Calls
The present section describes the configuration of Mobile Termination (MT) compliant with 3GPP
TS 27.007 AT command set for User Equipment and the configuration of ISDN Network Termi-
nation (equal to Data Circuit Terminating Equipment (DCE)) compliant with ITU-T V.25ter / V.250
"Serial asynchronous automatic dialling and control" and ITU-T V.110 Support by an ISDN of
data terminal equipments with V-series type interfaces used for test of data calls.

Figure 6.1: Functional blocks (source: 3GPP TS 27.007)

According to EIRENE SRS 15.0, chapter 2.3.1 the following mandatory bearer services have to
consider for IOT testing:


EIRENE SRS V15, chapter 2.3.1 contains a note regarding different transmission standards (ITU-
T V-series) to support as an example. For IOT testing the standards ITU-T V22bis and V32 are
most the relevant for analogue interworking. ITU-T V.110 is used in case of digital interworking for
connections to standard ISDN fixed networks. Other standards mentioned in EIRENE as
V.21 (300 bit/s), V.22 (1,2 Kbit/s) and V.23 (1,2 Kbit/s, half-duplex) supporting only non manda-
tory data rates lower than 2,4 Kbit/s and will not be considered for IOT testing.

a) Configuration of Mobil Termination (MT)
Configuration and control of the Mobile Termination (MT) will be done by using AT-commands
specified in TS 27.007.
Any successful command execution will be returned by OK, otherwise occurs an error message.


Bearer Service Type
The MT is to configure for the correct bearer service type (data rate, bearer service, connection
element) given by the specific data call test case.
To select barer service type use the following commands:

data rate
[bps]
digital interworking
(UDI / ISDN) - V.110
analogue interworking
(3,1 kHz) V.22bis (2400 bps),
V.32 (4800, 9600 bps)
Transparent non transparent transparent non transparent
2400 AT+CBST=68,0,0 AT+CBST=68,0,1 AT+CBST=4,0,0 AT+CBST=4,0,1

The table above considers only the bearer service data circuit asynchronous.
Data rate, bearer service and connection element supported by the Mobile Termination can be
verified by AT+CBST=?.
AT+CBST? returns the current date configuration.

Fixed data TE rate
The link / data rate between Terminal Equipment (including Terminal Application) and Terminal
Adapter shall be set equal to the data rate of selected bearer service type. To configure the fixed
data TE rate use:
AT+IPR=<rate>, <rate>: 2400, 4800, 9600

Call Priority and Call Control
Setup data call without priority (using default priority):
ATD<dial number>
Setup date call with call priority:
ATD*75<prio>#<dial number>, <prio>: 0, 1, 2, 3, 4
Call can be answered by ATA and be terminated by ATH.

Note: The commands may vary depends on the specific implementation in the MT.


b) Configuration of ISDN Network Termination Equipment
The configuration of ISDN Network Termination regarding bearer service, line speed, transmis-
sion mode (T/NT) depends on the specific implementation of the termination equipment used.
For ISDN Network Termination the following general configuration is recommended:
- ISDN rate adaption:
V.110
Supported data rates 2400 Kbit/s, 4800 Kbit/s, 9600 Kbit/s
Transparent and Non-Transparent date transfer mode
- Analogue modem emulation:
V.22bis, V.32
Supported data rates 2400 Kbit/s, 4800 Kbit/s, 9600 Kbit/s
If applicable the line speed between Terminal Equipment (including Terminal Application) and
Terminal Adapter should be set equal to the selected bearer service.
Setup of call priority and setup of date call itself have to be done according the specific implemen-
tation of the termination equipment, e.g. using the AT-commands.

c) Send and receive test data
Established data connections should be verified by sending and receiving test data in both data
transmission directions. Scope is the functional test of date transmission. Performance and Qual-
ity of Service (QoS) measurements like data transfer rate, data interference or bit error rate are
out of scope. These aspects are covered by separate test specifications (see chapter 4.1).
Basically a terminal application is needed on both parties to send and receive test data.
For test of data connection predefined files containing test data will be transferred bidirectional,
this means from A-party to B-party and vice versa.
The test data consists of a subset of a pseudo random bit sequence (PRBS) or a text string (e. g.
1000 characters). In relation to practical test execution a couple of data files with different test
data should be used.
Optional the terminal application supports comparison of the transferred test data with the original
sent. Otherwise the sent and received test data have to be compared manually.
In test cases dealing with handover scenarios the test data should be sent before and after the
handover. Objective is to verify successful connection before as well as after the handover. Data
interferences due to the handover are scope of QoS tests.


6.3 Annex Example for documentation of test configuration
The template below represents an example that can be used to document the specific configura-
tion of the EIRENE network under test, test conditions and the test equipment used.

a) Test Time / Date / Location

Test time / date / location
Start time / date / location
Stop Time / date / location

b) Environment Parameter (Lab, Field)

Parameter Ambient temperature Air humidity
Minimum
Maximum

c) Network configuration

Network Elements (NE)

Network A
Networks Element Manufacturer Number of NE HW type /
HW version
SW version
PABX
IN
SMSC
SCP
ACK

NSS
MSC
HLR
VLR
GCR


Networks Element Manufacturer Number of NE HW type /
HW version
SW version
BSS
BSC
TCU
BTS
BTS
BTS

Network B
Networks
Elements
Manufacturer Number of
Networks
Elements
HW type /
HW version
SW version
PABX
IN
SMSC
SCP
ACK

NSS
MSC
HLR
VLR
GCR

BSS
BSC
TCU
BTS
BTS
BTS


BSS Configuration

Network A
BSS connection* BTS HW configuration**
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS21
BTS22
BTS23
BTS24

* Loop, Chain, Star, Remote Star
** S222, O2 or another HW configuration
Diagram test configuration:


Network B
BSS connection* BTS HW configuration**
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS21
BTS22
BTS23
BTS24

* Loop, Chain, Star, Remote Star
** S222, O2 or another HW configuration
Diagram test configuration:


BSS Basic Parameters

Network A
LAC BCCH TCH CI BCC TEI
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS
BTS
BTS
BTS

Network B
LAC BCCH TCH CI BCC TEI
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS
BTS
BTS
BTS


Basic Group Call Parameters

Network A
LAC CI GCA G-ID Network A,B*)
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS
BTS
BTS
BTS

* Group Call Area belongs to Network A and / or Network B

Diagram test configuration


Network B
LAC CI GCA G-ID Network A,B*
BSS 1
BTS
BTS
BTS
BTS

BSS 2
BTS
BTS
BTS
BTS

* Group Call Area belongs to Network A and / or Network B

Diagram test configuration


d) Management Systems

Management Systems Manufacturer Network A
SW version
Network B
SW version
OMC-R
OMC-S
LMT

e) EIRENE Mobile Station

EIRENE
Mobile
Station
Manufacturer SW version HW version Subscriber /
SIM- Profile
used
certified
Cab Radio 1
Cab Radio 2
Cab Radio 3
Cab Radio 4
OPH
OPH
OPS
OPS
GPH
GPH
GPH
GPH
GPH
GPH


f) EIRENE Controller

EIRENE
Controller
Manufacturer SW version HW version certified

g) Test equipment

Protocol monitor systems for Abis, A, E and S interface (Lab; Field)
Protocol tester Manufacturer Interface Protocols Protocol Stacks /
SW version

Abis
RR
BTSM
Lapd
Layer 1
A
CM
MM
BSSMAP
SCCP
MTP

E
ISUP
MAP
TCAP
SCCP
MTP
S
DSS1


RF measurement equipment
Title Manufacturer Type / Name Date of
Calibration
Network Analyzer
RF Power Meter
Spectrum Analyzer

h) Test conditions
The table below can be used to document the individual test conditions (e.g. lab or field environ-
ment, static conditions, speed or radio propagation profiles etc.) under the IOT tests have taken
place.

Test condition Value Effected test cases remarks

- End of document

DB GSM-R Iot Test Specification

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

DB GSM-R Iot Test Specification

Uploaded by

Copyright:

Available Formats

File: IOT - Test Specification_amendment_F017_2011_10_14

Interoperability of EIRENE Networks

You might also like