Smsdetails En-RL PDF

FUNCTIONAL SPECIFICATION
not permitted without written authorization from Alcatel.

All rights reserved. Passing on and copying of this
document, use and communication of its contents
TABLE OF CONTENTS
LIST OF FIGURES AND TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
REFERENCED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Options list in FS Short Message Terminating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 DETAILED DESCRIPTION AND SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Subscriber data related to SMS–MT and Flags definition . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 SMS connection between the SC and the SMS–GMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Establishment of the connection and determination of SMSAP version . . . . . . . . . . . . . 9
2.2.2 Forwarding of first Short Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Forwarding of Subsequent Short Message (phase 1 feature) . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Forwarding of Multiple Short Message (phase 2 feature) . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Release of connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Retrieval of routing information procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 MSC number inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Forwarding of short message procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1 Messages; Forwarding of single short message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Messages; Forwarding of multiple short messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Set Message waiting data and SM Delivery Status Report procedures . . . . . . . . . . . . . 37
2.6.1 SMS–GMSC treatments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.2 HLR treatments at the reception of the message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7 Alerting Service Center procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7.1 Alert procedure triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7.2 Alert procedure at HLR level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7.3 Alert procedure at IWMSC level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.7.4 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
04 980513
SYS/DFB F. SALIS
03 970926 SYS/DFB Y.MARTY
01 9608 DSR Y.MARTY
ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

1AA 00014 0004 (9007) A4 – ALICE 04.10
SHORT MESSAGE SERVICE TERMINATING
SMT
ED 04
CIT AAC020298400DS En 1 / 135
135
3 INTERFACE MATRIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 CONSEQUENCES OF V1 AND V2 MAP APPLICATION CONTEXTS MIX BETWEEN PLMN ENTI-

TIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Restrictions of feature induced by use of v1 context: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Consequences of v1 and v2 Application Context mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 INTERFACES WITHIN THE FUNCTION SHORT MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 MIRSMSSM: Interface between the GMSC and the SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 MIRSMHSM: Interface between RCF and HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Send Routing Information for Short Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2 InformServiceCentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.3 Set Message Waiting Data / Report SM Delivery Status . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.4 AlertServiceCenterWithoutResult (Phase 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.5 Alert Service Center (Phase 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 MIRSMRSM : Interface between GMSC and VMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.1 Forward Short Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4 MIRSMVSM: Interface between servicing MSC and VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.1 Send Information for SMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.2 Complete Short Message Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.3 Set MNRF flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 MIRSMBSM: Interface between RCF in VMSC and BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.1 CP–DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.2 CP–ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5.3 CP–ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.4 Specific defense treatments upon DTAP protocol (CP–layer) . . . . . . . . . . . . . . . . . . . . . . 68
5.6 MIRSMRSM : Interface inside the RCF in the VMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.1 MI_DBL_STR_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.2 MI_DBL_STR_ERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 INTERFACE WITH OTHER FUNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1 Security Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.1.1 Between VLR and HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.1.2 Within VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1.3 Within RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 LOCATION REGISTRATION INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.1 Within HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.2 Between VLR and RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.3 Between VLR and HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3 Short message originating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 Paging Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4.1 Within VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4.2 Within RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.5 Call Barring Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.6 Radio Resource Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7 Charging Data Collection Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.8 Observation Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.9 Supplementary Service Handling interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.10 MM interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7 SPONTANEOUS MESSAGES TO OPERATOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

1AA 00014 0004 (9007) A4 – ALICE 04.10
8 ERROR GENERATED BY SMT FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1 Definition of Internal errors generated by SM in HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.2 Definition of Internal Errors generated by SM in VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
ED 04
CIT AAC020298400DS En 2 / 135
135
8.3 Definition of internal errors generated by SM in RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9 TIMERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1 Timer in RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.1 SMS–GMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.2 VMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.3 IWMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.2 Timer in VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.3 Timer in HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10 SDL DIAGRAMS HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11 SDL DIAGRAMS VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12 SDL DIAGRAMS RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
ANNEXE A OVERVIEW OF PROTOCOLS USED IN SMS–MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.1 Network structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.2 Transfer protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.2.1 Simplified protocol layer overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.2.2 SC/PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.2.3 SMS–GMSC/HLR and HLR/SMS–IWMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.2.4 SMS–GMSC/MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
A.2.5 VLR/HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
A.2.6 MSC/VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
A.2.7 MSC/MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 3 / 135
135
LIST OF FIGURES AND TABLES
Figure 1. Functional environment of the Short Message terminating function . . . . . . . . . . . . . . . . . . 8

Figure 2. SMS connection set–up (1/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


Figure 5. Retrieval of routing information from the HLR(1/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 6. Retrieval of routing information from the HLR(2/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 7. Channels used for short message transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 8. Forwarding of short message (1/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 9. Forwarding of short message – single transfer (2/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 10. Forwarding of short message – Multiple transfer (1/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 11. Forwarding of short message – Multiple transfer (2/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 12. IMSI unknown (1/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 13. IMSI unknown (2/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 14. Send info for SMT error (1/4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 17. Check IMEI failure (4/4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 18. Error case VMSC <–––> MS CP level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 19. Error case VMSC <–––> MS RP level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 20. Failure at the radio side (1/1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 21. Set message waiting data/ SM Delivery Status report – Absent subscriber case . . . . . . 39
Figure 22. Set message waiting data/ SM Delivery Status report – Memory capacity exceeded case ..
40
Figure 23. SM Delivery Status report – Successful delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 24. Alert procedure triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 25. Alert service center (1/5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 30. Short Message Service Funtional Matrix(1/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 33. Send Routing Information for Short Message : messages layout . . . . . . . . . . . . . . . . . . . 54
Figure 34. Set Message Waiting Data : messages layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 35. Report SM Delivery Status : messages layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 36. Alert Service Center Without Result message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 37. Alert Service Center message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 38. Forward Short Message: messages layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 39. Send Information for SMT : messages layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 40. Complete SMT call: message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 41. Set MNRF flag : messages layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 42. CP–DATA message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 43. RP–Data message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 44. RP–Error message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 45. RP–Ack message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 46. CP–ACK message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 47. CP–ERROR message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 48. ReadyForSM (VLR–>HLR) message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Figure 49. Note MS–present (HLR LR–>HLR SMT) message layout . . . . . . . . . . . . . . . . . . . . . . . . . 72
ED 04
CIT AAC020298400DS En 4 / 135
135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
Creation
Updated
04
HISTORY
04 on 98–05–13
03 on 97–09–26
02 on 97–03–14
01 on 96–08–30
Updating by RT/DM
Updating by RT/DM
135
AAC020298400DS
En
5 / 135
REFERENCED DOCUMENTS
[1] AAC020298400DT – Mobile Terminating point to point SMS

[2] AAC030546400DT – Mobile Originating point to point SMS

[3] AAC030546400DS – Mobile Originating point to point SMS
[4] AAC030205400DS – SMSAP MSC – SC protocol for SMS
[5] AAC020006400DS – Terminating call
[6] AAC020003400DS – Paging
[7] AAC020010400DS – Security
[8] AAC020015400DS – Radio Resource Management
[9] AAC020097400DS – Internal and external Error Mapping
[10] AAC020004400DS – Location Registration
[11] AAC020023400DS – Observations
[12] AAC020018400DS – Call Barring
[13] AAC020017400DS – Charging Data Collection
[14] AAC020030400DS – Supplementary Service Handling
[15] AAC020016400DS – Traduction
[16] AAC020754400DS – Version handling
[17] AAC020031400DS – Defence of PLMN
[18] AAC030508400DS – Operator Determined Barring
[19] AAC020748400DS – Application document for GSM PH.2 TS 09.02 (MSC/VLR behaviour)
[20] AAC020747400DS – Application document for GSM PH.2 TS 09.02 (HLR behaviour)
[21] Functional Options List (note 1)
Note 1 : One document per customer
GLOSSARY
– BSSAP Base Station System Application Part

– BSSMAP Base Station System Management Application Part
– DTAP Direct Transfer Application Part
– DT1 Data Form 1
– HLR Home Location Register
1AA 00014 0004 (9007) A4 – ALICE 04.10
– HLR SMT HLR Short Message terminating Function

– MAP Mobile Application Part
– MCEF Memory Capacity Exceeded Flag
ED 04
CIT AAC020298400DS En 6 / 135
135
– MNR Mobile station Not Reachable Flag
– MWD Messages Waiting Data
– MWI Messages Waiting Indication
– MS Mobile Station
– MSC Mobile Services Switching Center

– RCF Radio Control Function

– RCF SMT RCF Short Message Function
– RPDU Relay Protocol Data Unit
– SAPI Service Access Point Identifier
– SC Service Center
– SCCP Signalling Connection Control Part
– SMT Short Message Terminating Function
– SMO Short Message Originating Function
– SM MT PP Short Message Mobile Terminating Point To Point
– SM MO PP Short Message Mobile Originating Point To Point
– SMS Short Message Service
– SMSAP Short Message Service Application Part
– SMS GMSC Gateway MSC for short messages service
– SMS IWMSC Interworking MSC for short messages service
– SMS VMSC Visited MSC for short messages service
– TPDU Transfer Protocol Data Unit
– UDT Unit DaTa
– VLR Visited Location Register
– VLR SMT VLR Short Message terminating Function
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 7 / 135
135
1 INTRODUCTION
The general description of a Mobile Terminating SMS PP function is given in the associated feature de-
scription (see [1] page 6).
The SM MT PP is a teleservice offered by the short message point to point function: the general purpose
of the function, within the PLMN, is to transfer short messages from a SC to the MS (TPDU SMS–DELIV-
ER) or a status report from a SC to the MS (TPDU SMS–STATUS–REPORT associated with a previous
SMS–MO procedure).
In this document, the term ”short message” is used by extension to design both cases.
Therefore a mobile terminating short message procedure has to perform all the actions needed to estab-
lish a transaction for Short message transfer required by a Service Center towards the MS, to guarantee
the short message forwarding, to handle the failure cases that may arise during the set–up of the transac-
tion or the forwarding of the message and to report to the SC the result of the message transfer attempt.
The PLMN entities will handle also the alert procedure in order to inform the SC that the MS has recovered
operation or has recovered available memory (phase 2 dialogue only).
To perform correctly the short message transfer, the SMT (Short Message Terminating) function is imple-
mented in the PLMN entities.
– The HLR SMT has to provide the routing information requested by the RCF SMT (acting as SMS–
GMSC) and to handle all the different kind of error report.
It has to handle also the Set Message Waiting Data procedure (phase 1) or SM delivery status report
procedure (phase 2) on request from RCF SMT in SMS–GMSC.
Besides it has to handle the Alert procedure towards the IWMSC.
– The VLR SMT has to provide the information needed to complete the call towards the MS (e.g. by
the authentication or the ciphering procedure).
Besides it has to handle the failures related to the terminating call and the procedure to inform the
SC (via the HLR) that the MS is again reachable (MS present).
N.B. The VLR SMO function has to handle the procedure to inform the HLR that the MS has
recovered available memory.
– The RCF SMT in the SMS–GMSC has to perform the forwarding of the Short Message between the
SMS–GMSC and the SMS–VMSC.
Besides it has to initiate the Set Message Waiting Data procedure (phase 1) or SM Delivery Status
Report procedure (phase 2) towards the HLR and all the failures of the message transfer attempt.
– The RCF SMT in the SMS_VMSC has to perform the forwarding of the short message between the
VMSC and the MS.
Besides it has to handle all the failure condition (i.e. failure detected by the SMT function in the VLR,
SM delivery failure).
– The RCF SMT in the IWMSC has to handle the Alert procedure towards the Service Center.
1.1 Options list in FS Short Message Terminating
F–SMS–001 Addressing mode of SMS IWMSC

F–SMS–002 VMSC and GMSC supports SMS
F–SMS–003 SMS offered with IMSI unknown,including an update location
F–SMS–004 Handling in HLR of the priority on SM delivery
1AA 00014 0004 (9007) A4 – ALICE 04.10
F–SMS–005 Special use of SRI for SM as MSC number inquiry

F–SMS–006 HLR protection against optimal routing for SMS–MT
F–SMS–007 SDCCh assignment for SMS
ED 04
CIT AAC020298400DS En 8 / 135
135
F–ODB–001 Operator Determined Barring function
F–HB–001 Hot billing option
F–SC–011 Authentication 1/n
BSS RCF Service Center
PA SC
MS
OB
SMS
function SMT
RM CG
VLR HLR
PA SC CB LR
RCF
SMT SMT SMT
OB LR OB
SMO
Abreviations :
CB : Call Barring
SC : Security
PA : Paging
CG : Charging
OB : Observation
RM : Radio Management
LR : Location Registration
SMT : Short Message Terminating
SMO: Short Message Originating
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 1. Functional environment of the Short Message terminating function
ED 04
CIT AAC020298400DS En 9 / 135
135
2 DETAILED DESCRIPTION AND SCENARIOS
2.1 Subscriber data related to SMS–MT and Flags definition

a) In the HLR, the MSISDN–Alert indicator marks the MSISDN to be used as MSISDN–Alert.
b) As part of Messages–Waiting–Indication (MWI), the Messages–Waiting–Data (MWD) is stored in the

HLR against the subscriber MSISDN–Alert. MWD consists of an address list of the SCs which have
messages waiting to be delivered to the MS.
c) As part of Messages–Waiting–Indication (MWI), the Mobile–Station–Not–Reachable–Flag (MNRF)

is stored in the VLR and the HLR. MNRF is a boolean indicating if the address list of MWD contains
one or more entries because an attempt to deliver a short message has failed at VLR with Absent
Subscriber cause
• due to the MS temporarily absent.
• due to the MS located in a non authorized area (due to national roaming, regional subscription
or unsupported feature in the current VLR).
d) As part of Messages–Waiting–Indication (MWI), the Mobile–Station–Memory–Capacity–Exceeded–

Flag (MCEF) is stored only in the HLR. MCEF is a boolean indicating SM Delivery failure due to MS
Memory Capacity Exceeded.
2.2 SMS connection between the SC and the SMS–GMSC
2.2.1 Establishment of the connection and determination of SMSAP version
See < [4] page 6>.
2.2.2 Forwarding of first Short Message
When connection is established, the SC sends the message DATA FORM 1 (SCCP class 2 message) to
the SMS GMSC to carry the first short message (as a user data).
The MT SMS PP procedure at the GMSC is then started by the SMT function which checks the
RP_MT_Data content.
If no error is detected, the procedure continues in the normal way with retreival of routing information pro-
cedure (see section 2.3 page 16).
If any error is detected in the layout of the RP_MT_Data message, DATA FORM 1 (SCCP class 2
message) is sent by the SMS GMSC (SMT function) to inform the SC about the failure of the
RP_MT_Data message transfer attempt.
The DT1 message contains as user data parameter the RP_MT_Error message including the
RP_cause element.
When GMSC is informed of the successful end of retrieval of routing information, i.e. on reception of
MI_S_RGI_SM_R from the HLR, the Forward Short Message procedure is started by sending to the
VMSC the MI_F_SM_I message (see section 2.5 page 20).
In case of unsuccessful retrieval of routing information, i.e. on reception of MI_S_RGI_SM_E from

the HLR, SMT fonction in GMSC informs the SC about the failure of the RP_MT_Data message trans-
1AA 00014 0004 (9007) A4 – ALICE 04.10
fer attempt by sending the message DATA FORM 1 (SCCP class 2 message) which contains as user
data parameter the RP_MT_Error message.
ED 04
CIT AAC020298400DS En 10 / 135
135
2.2.2.1 End of the forwarding of first Short message in SMS GMSC
When GMSC, waiting for response from VMSC, receives MI_F_SM_R message, it triggers the SM Deliv-
ery Status Report procedure in case of phase 2 dialogue with HLR, if MCEF and/or MNRF is known to be
set in HLR (refer 2.6 page 38);

Then, it sends DATA FORM 1 (SCCP class 2 message) to the service center.
The DT1 message contains as user data parameter the RP_MT_Ack message which indicates that the
mobile terminating SM procedure has been correctly completed.
If the GMSC receives MI_F_SM_E message, it means that forwarding of the Short Message to the
MS has failed.
The RCF SMT of the GMSC informs the SC about the failure of the RP_MT_Data message transfer
attempt by sending the message DATA FORM 1 (SCCP class 2 message) which carries as user data
parameter the RP_MT_Error message.
2.2.3 Forwarding of Subsequent Short Message (phase 1 feature)
This procedure is used by the SC and the SMS–GMSC when the dialogue between both entities is based
on SMSAP V1 protocol.
After each DATA FORM 1 message, carrying a RP_MT_Error message when SM transfer has failed or
carrying a RP_MT_Ack message when SM transfer has been successful, sent to the SC, SMT in GMSC
waits for a DATA FORM 1 message carrying a subsequent short message to forward.
When a subsequent RP_MT_Data is received, SMT in GMSC checks its content and verifies that the sub-
sequent Short message is to be sent to the same MS than the previous Short Message.
If it is not the case, a DATA FORM 1(SCCP class 2 message) message which carries as user
data parameter the RP_MT_Error message is sent to the SC.
– If a subsequent RP_MT_Data is received when retrieval of routing information for the previous Short
Message has not been done or has been unsuccessful, SMT in GMSC starts again retrieval of routing
information procedure before to forward the SM to the VMSC (like for the first RP_MT_Data).
– If a subsequent RP_MT_Data is received when retrieval of routing information has been successful
and forward short message procedure has been initiated for the previous short message, SMT in
GMSC starts directly the Forward Short Message procedure for this subsequent Short Message.
N.B. If SMT in GMSC receives a RP_MT_Data from the SC when there is already a Short Message
being treated with no report already sent to the SC, DATA FORM 1 message which carries as
user data parameter the RP_MT_Error message is sent to the SC.
2.2.3.1 End of the forwarding of subsequent Short message in SMS GMSC
Same handling as for the first one.
2.2.4 Forwarding of Multiple Short Message (phase 2 feature)
This procedure may be used by the SC and the SMS–GMSC when the dialogue between both entities is
based on SMSAP V2 protocol.
The SC informs the SMS–GMSC that a subsequent short message will follow in inserting the ”More Mes-
1AA 00014 0004 (9007) A4 – ALICE 04.10
sage To send” parameter in a RP–MT–Data. This parameter is forwarded towards the VMSC (See < 2.5.2
page 25>).
At the end of short message transfer procedure (sending of RP–MT–Ack), the SMS–GMSC will be waiting
for another subsequent message.
ED 04
CIT AAC020298400DS En 11 / 135
135
If a RP–MT–Error is returned to SC instead RP–MT–Ack (procedure unsuccessful), no more subsequent
message will be expected by SMS–GMSC.
The handling of subsequent short message is the same as above.

2.2.5 Release of connection
The release of the SMS connection and therefore of the short message procedure may be requested either
by the SC, the GMSC or the MS.
2.2.5.1 Release requested by the SC (Normal release).
The procedure is started by sending the message RELEASED (SCCP class 2 ”RLSD”) to the GMSC.
At the reception of the message the resources involved in the procedure have to be released, that is the
GMSC releases the TCAP transaction towards the VMSC or the HLR (if still active) by sending an Abort
Request message and replies to the SC by sending the RELEASE–CONFIRM (SCCP class 2 ”RLC”) mes-
sage.
2.2.5.2 Release requested by the MS
In this case the radio side (BSS) releases autonomously the short message procedure and then informs
the VMSC by sending the SAPI”n”CLR–CMND message.
The SC is not informed about the release since the message from the BSC is ignored.
N.B. The short message release procedure is implicitly invoked on reception from the BSC of a
CLEAR REQUEST message due to the detection of radio failures (on the SAPI 3 as well as on
the SAPI 0) implying the release of all the radio resources.
For further details, see [8] page 6.
2.2.5.3 Release requested by the GMSC
A timer (T–SCRLS) supervises at the GMSC the release of the SCCP connection from the SC.
It will be started on sending the RP_MT_Ack message (or RP_MT_Error) and stopped at the reception
of either a RP_MT_Data message or a RLSD message.
At the expiry of the timer the GMSC releases autonomously the SCCP connection by sending the RLSD
message to the SC.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 12 / 135
135
2.2.6 Scenarios
2.2.6.1 Successful case

FORWARDING OF SINGLE SHORT MESSAGE
SMS–GMSC
SC
RCF
Connection Request
Connection Confirm
Data Form 1
(RP–MT–Data)
RP–MT–data is tested
by SMT function
Send Routing information toward

HLR
(TC_BEGIN)
Send Routing information Res from
HLR
(TC_END)
Forward Short Message toward
VMSC
(TC_BEGIN)
Forward Short Message Res from
VMSC
(TC_END)
Data Form 1
(RP–MT–Ack)
Released
Release confirm
Figure 2. SMS connection set–up (1/3)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 13 / 135
135
FORWARDING OF MULTIPLE SHORT MESSAGES
SMS–GMSC
SC
RCF
Connection Request
Connection Confirm
Data Form 1
(RP–MT–Data)
Send Routing information toward
HLR
(TC_BEGIN)
Send Routing information Res from
HLR
(TC_END)
VMSC
(TC_BEGIN)
VMSC
(TC_CONT)
Data Form 1
(RP–MT–Ack)
Data Form 1
(RP–MT–Data)
VMSC
(TC_CONT)
VMSC
(TC_END)
Data Form 1
(RP–MT–Ack)
Released
Release confirm

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 14 / 135
135
2.2.6.2 Unsuccessful cases
PARAMETERS ERROR DETECTED AT APPLICATION LEVEL
SMS–GMSC
SC
RCF
Data Form 1
(RP–MT–Data
the RP–MT–Data message is
tested by the SMT function
which detects errors in the
message layout (i.e. mandatory
information element error,
information el. not
Data Form 1
implemented)
(RP–MT–Error)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 15 / 135
135
2.3 Retrieval of routing information procedure
2.3.1 Messages
2.3.1.1 MI_S_RGI_SM_I (MAP ”Send Routing Information for SM”)
a) This message is sent by the RCF SMT of the GMSC to the HLR SMT retrieved from the MS–ISDN
number.
b) On receipt by the HLR, if the functional option F–SMS–006 is applicable, the message is rejected
if the originating SMS–GMSC does not belong to HPLMN. For all that, if the dialogue between SMS–
GMSC and HLR is phase 2, the dialogue is aborted by SMT function with a TC–U–ABORT .
If the dialogue between SMS–GMSC and HLR is phase 1, RCF SMT function sends a TC–REJECT.
If the operation has to be handled, SMT in HLR :

• verifies the validity of the message fields;
• verifies that the MS can be identified from the MSIsdn number;
• verifies that the MS does not contravene Operator Determined Barring if F–ODB–001 is active,
or that the MS is not locked
• verifies that the mobile subscription, identified by the MSIsdn number, comprises the MT SM
service;
• verifies that the MS is not deregistered;
• verifies that the VMSC where the MS is roaming has the SMS capability (SMSMT flag is set);
• verifies that roaming is allowed for this subscriber (see [10] page 6
If anyone of the checks fails the SMT HLR sends to the RCF SMT (GMSC) the message
MI_S_RGI_SM_E (MAP ”SM Routing Information error for SM”) containing a cause field identifying
the failure.
The cause ”Absent Subscriber” indicates that the MS is deregistered or that roaming is not allowed
in that MSC area and in this case, the HLR will include, if possible, the new SC address in the MWD.
If the checks are successful the HLR SMT sends the message MI_ICB_CHECK (Internal message)
to CB function in HLR to check whether the incoming call is barred or not.
If the call is barred the HLR CB sends to the HLR SMT the message MI_ICB (call barred).
At the reception of the message the HLR SMT sends to the RCF SMT (in the GMSC) the message
MI_S_RGI_SM_E(MAP ”SM Routing Information error) including as error the ”Call barred” indica-
tion.
If the call is not barred the HLR CB sends to the HLR SMT the message MI_NO_ICB (Internal mes-
sage indicating No Barring).
The optionnal function F–SMS–004 indicates if the priority feature is handled in HLR to deliver Short
Message. If F–SMS–004 is not applicable, the message is assumed to be non–priority message and
the parameter SM_RP_PRI is ignored.
If F–SMS–004 is applicable, the parameter SM_RP_PRI is taken into account (SM_RP_PRI = true
indicates the message is a priority one, SM_RP_PRI = false, a non–priority message).
The message MI_S_RGI_SM_R reporting routing informations is sent to RCF SMT in GMSC as fol-
lows:
1AA 00014 0004 (9007) A4 – ALICE 04.10
• If the message is a priority one.
N.B. MNRF and/or MCEF flags set in HLR do not prevent the routing of the message in
this case.
ED 04
CIT AAC020298400DS En 16 / 135
135
• If the message is a non–priority message and the MNRF flag is not set in HLR database.
N.B. MCEF flag set in HLR does not prevent the routing of a short message to VMSC.
In the opposite, the message MI_S_RGI_SM_E reporting ”Absent subscriber” error is sent to RCF
SMT in GMSC if the message is a non–priority message and the MNRF flag is set in HLR database.
Furthermore, in this case, the HLR includes the SC address in MWD, if SC address is not already
in MWD and if MWD is not full.
N.B. MNRF flag is set only when the MS is not reachable at VMSC level.
2.3.1.2 MI_I_SC_I (MAP Phase 2 ”Inform Service Centre”)
This message is sent by the HLR in phase 2 dialogue with SMS–GMSC in the same message as SendRou-
tingInfo error or result:
– After the HLR has sent a SendRoutingInfoForSM error
The InformServiceCenter is only sent in case of ”Absent subscriber” error.
The storedMSISDN parameter is included if the MSISDN of SendRoutingInfoForSM invoke is not the
same as MSISDN–Alert used in MWD file.
The mw–Status parameter is always included.
– After the HLR has sent a SendRoutingInfoForSM result
The InformServiceCenter is sent if:

• either MNRF or MCEF flag or both are set in HLR,
The mw–Status parameter is then included with mnrf–set and/or mcef–set.
The SC–AddressNotIncluded is set if SC address is not in MWD list.
• the MSISDN of SendRoutingInfoForSM invoke is not the same as MSISDN–Alert.
The storedMSISDN parameter is then filled with MSISDN–Alert.
In phase 1 dialogue between HLR and SMS–GMSC, the mwd–set parameter is always included
– in SendRoutingInfoForSM result MI_S_RGI_SM_R,
– in SendRoutingInfoForSM error MI_S_RGI_SM_E in case of Absent subscriber error.
Refer to message description < 5.2.1 page 54>.
2.3.1.3 After retrieval of routing information procedure
a) If MI_S_RGI_SM_R has been received in RCF SMT in GMSC, the routing information is available
and the procedure continues in the normal way (see section 2.5 page 20).
b) If MI–S–RGI–SM–E has been received the GMSC (SMT function in RCF) informs the SC about the
failure of the RP–Data message transfer attempt by sending the message: DATA FORM 1(SCCP
class 2 message) which contains as user data parameter the RP_MT_Error message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 17 / 135
135
2.3.2 Scenarios
2.3.2.1 Successful case

Successful case in phase 1 dialogue with HLR

Successful case in phase 2 dialogue with HLR (MCEF and MNRF not set, MSISDN = MSISDN–Alert)
SMS–GMSC HLR
SMT SMT CB
MI–S–RGI–SM–I
(TC–Begin)
MI–ICB–CHECK
MI–NO–ICB
MI–S–RGI–SM–R
(TC–End)
forward short message towards

VMSC
Figure 5. Retrieval of routing information from the HLR(1/2)
Successful case with phase 2 dialogue with HLR

(MCEF and/or MNRF set) and/or (MSISDN <> MSISDN–Alert)
SMS–GMSC HLR
SMT SMT CB
MI–S–RGI–SM–I
(TC–Begin)
MI–ICB–CHECK
MI–NO–ICB
MI–S–RGI–SM–R
MI–I–SC–I
(TC–End)
forward short message towards

VMSC
Figure 6. Retrieval of routing information from the HLR(2/2)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 18 / 135
135
2.4 MSC number inquiry
If the option F–SMS–005 is set and a particular private numbering plan used for MSISDN indicates the
special message usage, the following applies.
2.4.1 Messages
MI_S_RGI_SM_I(MAP ”Send Routing Information for SM”)

This message is sent in order to retrieve the address of the MSC in which area the MS is currently regis-
tered in.
At the reception of this message SMT in HLR :

– verifies the validity of the message fields;
– verifies that the MS can be identified from the MSIsdn number;
– verifies that the MS is not locked;
– verifies that roaming is allowed for this subscriber (see [15] page 6
If anyone of the checks fails, the SMT HLR returns the message MI_S_RGI_SM_E(MAP ”Send Routing
Information For SM” error) containing a cause field identifying the failure. The cause ”absent subscriber”
indicates that the MS is not registered.
In the successful case, the message MI_S_RGI_SM_R (MAP ”Send Routing Information For SM” result)
reporting the address of the MSC the MS concerned is controlled by is sent back to the requesting entity.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 19 / 135
135
2.5 Forwarding of short message procedure
2.5.1 Messages; Forwarding of single short message

N.B. This paragraph concerns only the forwarding of a single short message, the multiple short mes-
sage case is described separately.
2.5.1.1 SMS GMSC <––> SMS VMSC <––> VLR interface
a) MI–F–SM–I(MAP ”Forward short message”)

This message is sent by the RCF SMT of the GMSC to the RCF SMT of the VMSC to request the
forwarding of an MS terminated short message.
After the determination of the MAP dialogue version, some checks are performed to determine if the
length of User data allows the MAP transfer and, in the positive case, if segmentation is needed for
MAP version > 1.
Three system parameters are defined:
L1 Max length of User data supported by MAP, whatever MAP version.
L2 Max length of User data supported by a MAP version > 1 with segmenting process.
L3 Max length of User data which can be carried by a MAP version > 1 without segmenting.
• If User data length <= L3, then no segmenting process is needed, whatever MAP version of dia-
logue.
• If L3 < User data length <= L2, then segmenting process is required if the MAP version of dia-
logue is > 1.
• If L1 < User data length, the RP_MT_DATA is rejected during the check of the parameters ( see
2.2.2 page 10) just after the receipt of the message from the SC.
If segmenting would be needed, TC–BEGIN is sent with ACN, with or without USI (< 5.3.1 page 62>)
and without component to open the dialogue with the VMSC, and after the reception of an empty TC–
CONT, a TC–CONT is sent with TC–INVOKE component.
After the sending, RCF SMT in GMSC waits for the response from RCF SMT in VMSC.
N.B. MAP interface is maintained even if the GMSC and the VMSC are colocated. Yet, in this
case the interface is internal within MSC/VLR.
b) At the reception of the message, RCF SMT in VMSC verifies that it supports the short message ser-
vice (F–SMS–002 option is active).
In case the option F–SMS–002 is inactive, RCF SMT in VMSC sends to RCF SMT in GMSC the mes-
sage MI–F–SM–E.
Then, the RCF SMT in VMSC verifies the parameters of the message (see < 5.3.1 page 62>).
In case of error, it sends to the RCF SMT in GMSC the message MI–F–SM–E(MAP ”Short mes-
sage forwarding error”).
If the message from the GMSC is correctly received, RCF SMT in VMSC sends to the VLR SMT in
VMSC the message MI_SINF_SMT_I (Specific RCF–VLR interface message).
c) At the reception of the message, the VLR verifies that the IMSI is known.
If the IMSI is unknown (unknown at the VLR but known at the HLR)
1AA 00014 0004 (9007) A4 – ALICE 04.10
• If F–SMS–003 function is offered, a searching procedure is attempted and VLR SMT asks VLR
PA for searching by sending MI_SEAR_SMT_REQ message.
ED 04
CIT AAC020298400DS En 20 / 135
135
If Searching succeeds, it will result in an update location toward the HLR after authentification.
(if the MS answers with TMSI to the paging request, SM delivery will fail).
• If F–SMS–003 function is not offered, the treatment specified by the GSM applies (i.e VLR SMT
sends to RCF SMT in VMSC the message MI_SINF_SMT_E with cause ”Unidentified subscrib-
er”).
If the IMSI is known, then VLR verifies that the IMSI is not detached and that the LA is allowed (see
[10] page 6
If the IMSI is detached or if the LA is not allowed, VLR SMT sends to RCF SMT in VMSC the message
MI_SINF_SMT_E with cause ”Absent subscriber”, after having set to true the MNRF flag.
The VLR verifies also that the subscriber data are available (flag MS–DATA–KNOWN see [10] page
6. If the subscriber data are not available, the VLR SMT sends to RCF SMT in VMSC the message
MI_SINF_SMT_E with cause ”Unidentified subscriber”.
At the reception of the message MI_SINF_SMT_E, RCF SMT in VMSC sends MI_F_SM_E to the
RCF SMT in GMSC including the reason of the failure.
If the checks are successful, (IMSI known, data known, not detached and LA allowed) SMT in VLR
asks PA in VLR for paging by sending MI_PAGE_SMT_REQ (Internal message) in order to establish
the radio contact with the called MS.
If the functional option F–SMS–007 is activated, a Channel seizure is sent by PA function to RM func-
tion after the Paging response to allocate a SDDCH. This message is not sent if the parameter cho-
sen channel is present and set to SDCCH in paging response.
For further details about paging (or searching) procedure for an SMT transaction, see [6] page 6.
If the VLR has an IMSI marked ”LA not known” the VLR handles the request in the normal way, except
that SMT in VLR sends MI_SEAR_SMT_REQ to PA in the VLR.
MI_PAGE_SMT_ACK is sent back by PA to SMT in VLR when paging is successful. It contains the
status of the connection which is established with the called MS on the radio side.
In case of paging failure or if the mobile is not SMS equipped (Classmark 2 SM capability), the mes-
sage sent back by PA to SMT in VLR is MI_PAGE_SMT_NACK
In case of paging failure due to ”Not SMS equipped” the security procedure is nevertheless started
and, if succeeded, SMDeliveryfailure(MSNotEquipped) will be forwarded in ForwardShortMessage
error. If the security procedure failed, the paging error is forgotten and security error is taken into ac-
count.
MI_VSM_SC_REQ (Internal message) is sent by SMT in VLR to SC in VLR in order to perform, if

needed, MS authentification, TMSI reallocation and ciphering command. Information received in the
MI_PAGE_SMT_ACK is used.
MI_VSM_SC_RES (Internal message) is sent back by SC in VLR to SMT in VLR when security re-
lated operations have been performed successfuly.
In case of security failure, the message sent back by SC to SMT in VLR is MI_VSM_SC_ERR
After a good completion of PA and SC actions, MI_COM_SMT_I (Specific RCF–VLR interface mes-
sage) is sent by SMT in VLR to SMT in RCF, indicating that the SMT call can be offered to the MS.
1AA 00014 0004 (9007) A4 – ALICE 04.10
d) If there is an other transaction waiting for the end of MM procedures, SMT in RCF sends a
MI_DBL_STR_RES message to inform the awaiting transactions that its MM procedure has finished
with success.
ED 04
CIT AAC020298400DS En 21 / 135
135
If the MS is currently involved in a Location Registration procedure when a short message is to be
offered to the MS, as LR function in RCF never registers the IMSI (in its context data), PA function
in RCF will not be aware that the MS is running a MM procedure.
The LR procedure will normally succeed, and the PA procedure will fail in case of LAC change. The
paging may succeed (due to paging repetition) if the LR procedure is a periodic one (no LAC change).
e) RCF SMT in VMSC waits for result of IMEI checking from Security before sending the short message
to the mobile.
MI_IMEI_ACK (Internal message) is sent back by Security in RCF to SMT in RCF at the end of the
check IMEI process.
If case of IMEI check failure (e.g.black list) MI_IMEI_NACK is sent back by Security to SMT in RCF.
A message MI_F_SM_E is then forwarded to the GMSC.
RCF SMT in VMSC waits for result of the Short Message transfer before sending any response to
RCF SMT in GMSC.
f) Description of the Short Message delivery to the MS (RCF SMT in VMSC <––> MS interface) is de-
scribed at section 2.5.1.2 page 22.
g) Error cases
If paging or security has failed, VLR SMT sends MI_SINF_SMT_E to RCF SMT, containing the failure
cause.
If there is an other transaction waiting for the end of MM procedures, SMT in RCF sends a
MI_DBL_STR_ERR message to inform the awaiting transactions that its MM procedure has finished
with error.
N.B. If the MS has not answered to the paging (cause Absent Subscriber), the VLR sets the
MNRF flag to true.
At the reception of this message RCF SMT in VMSC sends MI_F_SM_E (MAP ”Forward Short Mes-
sage Error”) to the RCF SMT in GMSC including the reason of the failure.
h) On reception of an acknowledge from the MS that the SM has been correctly received (RP–ACK),
the VMSC sends MI_F_SM_R (MAP ”Forward short message Result”) to the RCF SMT of the SMS–
GMSC.
It doesn’t contain user data field since it only indicates that the message transfer to the MS has been
successfully completed;
In case of failure of a short message transfer to the MS, the VMSC sends MI_F_SM_E to the RCF
SMT in SMS–GMSC.
For further details about failure causes, see 2.5.1.2 page 22.
The end of the Forward Short Message procedure in SMS–GMSC is described at section 2.2.2 page
10
2.5.1.2 MSC <–––> BSC BSSAP interface
At the reception of the MI–COM–SMT–I confirming that the MS has been reached, the RCF SMT function
is ready to forward the RP–Data message to the MS (via the BSSMAP of the BSC).
N.B. An SMT transaction can take place during an OC or a TC or an SH or several others SMT trans-
1AA 00014 0004 (9007) A4 – ALICE 04.10
actions. But only ONE Short Message can be sent to the MS at one and the same time; as sever-
al Short Messages can arrive at the same time for the same MS (from different Service Centers),
SMT function in RCF in VMSC has to serialize the distribution of Short Messages to the MS.
ED 04
CIT AAC020298400DS En 22 / 135
135
So before to send the RP_Data, SMT tests if there is an other transaction sending a Short Mes-
sage to the MS :
– If there is one, SMT has to wait for the end of the transaction, which will be signalled to it
with MI_DBL_STR_RES message from an other SMT transaction, before to send
RP_Data.
– If there is not, RP_Data can be sent at once.
a) The RP–Data is sent within the user data of a CP–DATA (DTAP message) message.
The CP–DATA will be the user data of a SCCP DATA IND message carrying a DTAP message (that
is to say the layer 3 Information sent to the BSS within a SCCP DATA–IND message) and will be iden-
tified by the following Distribution Data Unit:
• Discriminator parameter = 1
• DLCI = C2 C1 000 S3 S2 S1
Where
– S3 S2 S1 = SAPI 3 = short message = 3
– C2 C1 = radio channel on which the short message has to be transferred (only significant
for phase 1 BSS)
Value 0 is set by the MSC irrespective of the BSC type.
The SDCCH or SACCH will be used according to the fact that the TCH is already allocated (when
the Short Message has to be sent) or not :
• if the TCH is allocated (a transaction using SAPI 0 is active on a TCH), the short message is
transferred on the SACCH,
• if the TCH is not allocated (a transaction using SAPI 0 is active on a SDCCH), the short message
is transferred on the SDCCH,
• if the TCH is allocated during the short message transfer (a transaction on a TCH is in progress
(using SAPI 0)), the short message will be moved, at the radio side, from the SDCCH to the
SACCH;
• if a transaction on TCH using SAPI 0 is terminated but the short message transfer is still active,
the TCH is maintained as long as the short messages procedure is activated.
The following table summarizes the channels use:
Channel dependency Channel used
TCH not allocated SDCCH

TCH not allocated –> TCH allocated SDCCH –> SACCH
TCH allocated SACCH
TCH allocated –> TCH not allocated SACCH –> SACCH
Figure 7. Channels used for short message transfer
b) The MS acknowledges the CP–DATA message by sending the message CP–ACK(DTAP message)
which doesn’t contain user information and which is forwarded by the BSC (DTAP) to the VMSC (RCF
SMT function).
The MS may refuse the CP–DATA by sending the message CP–ERROR(DTAP message) containing
a CP–cause field identifying the error (see phase 1 & 2 GSM 04.11, § 8.1.4.2). After translation of
1AA 00014 0004 (9007) A4 – ALICE 04.10
error, the VMSC (RCF SMT) sends the message MI–F–SM–E to indicate to the GMSC a transfer
failure.
c)
ED 04
CIT AAC020298400DS En 23 / 135
135
• If the MS has correctly received the short message (RP–DATA) it sends the message CP–DATA
(DTAP message) containing the RP–ACK message.
– If the CP_DATA is correct the VMSC (RCF SMT) acknowledges the message by sending
to the MS the message CP–ACK and it sends the message MI–F–SM–R to the GMSC.
– In case of invalid data in the CP_DATA, the VMSC (RCF SMT) sends to the MS the CP–
ERROR message containing a CP–cause field identifying the error (see phase 1 & 2 GSM
04.11, § 8.1.4.2) and sends the message MI–F–SM–E to indicate to the GMSC a transfer
failure.
• The failures of the message transfer attempt detected by the MS are notified to the MSC (RCF)
by the CP–DATA message containing the RP–ERROR message with the related cause.
The RCF SMT acknowledges the CP–DATA(RP ERROR) by sending the CP–ACK message
(without user information) and sends to the GMSC the message MI–F–SM–E to indicate to the
GMSC a transfer failure.
If the RP_Userdata field of RP–ERROR message is longer than L4 threshold (proposed value
of L4= 200 bytes), the RP_Userdata cannot be inserted in diagnostic field of ForwardShortMes-
sage error. Then the RP–ERROR is ignored and a CP–ERROR will be sent to the MS when
TR1N will expire.
N.B.
– If the SMT transaction ends right, it has possibly to inform an other SMT transaction waiting
for forwarding a Short Message, if there is at least one, by sending MI_DBL_STR_RES
message to the awaiting transaction.
If the SMT transaction ends wrong due to Channel release indication received from RM,
or CP–ERROR / RP–ERROR received from the MS, all the awaiting short message trans-
action are aborted by sending MI_DBL_STR_ERR message.
If the SMT transaction ends wrong due to others events, a MI_DBL_STR_RES message
is also sent to the awaiting transaction.
2.5.1.2.1 CP messages loss
Due to structure of message flow on SAPI 0 and SAPI 3 it is possible that the CP–ACK of a short message
transfer might not be received (e.g. due to handover).
If the first CP–ACK (acknowledging the CP–DATA that carried the first TPDU) is not received, the reception
of CP–DATA is interpreted as the reception of the awaited CP–ACK and CP–DATA message.
Furthermore, to prevent against CP messages loss the following timers have to be implemented by the
MSC (according to the GSM 04.11):
Timer TC1N : started on sending the CP–DATA message to the MS : it supervises the recep-
tion of the CP–ACK from the MS.
The starting value of TC1N shall not be affected by a change of channel type
after transmission of the initial CP–DATA.
If it expires, the CP–DATA is retransmitted, up to n times (n system parameter,
default value = 3) unless TR1N expires.
If the CP–ACK is always not received, then the short message transfer attempt
is considered as failed and the MI_F_SM_E (cause ”SM Delivery failure”) is sent
to the GMSC.
1AA 00014 0004 (9007) A4 – ALICE 04.10
Timer TR1N : It supervises the reception of the RP–ACK from the MS.
Started on sending the CP–DATA message to the MS.
ED 04
CIT AAC020298400DS En 24 / 135
135
If it expires the short message transfer attempt is considered as failed and the
MI_F_SM_E (cause ”SM Delivery failure”) is sent to the GMSC.
2.5.1.3 Release of MM connection

When the MM connection has to be released, the VMSC (RCF SMT) sends a Channel release to RM func-
tion. But this message is sent only when a timer T_BEFORE_REL has expired to ensure the BSS is able
to send its last DTAP message. This T_BEFORE_REL timer is set when the last DTAP message is sent
to the MS.
When the SMT function in RCF receives from RM a Channel release indication, if the cause of the Clear
Request message received from the MS is ”radio interface message failure”, it returns a ForwardShort-
Message error with ”Absent subscriber” cause. Then Set–MNRF message is sent by SMT RCF to SMT
VLR to request the setting of MNRF flag in VLR database.
When the SMT function in RCF receives from RM a Channel release indication due to an IMSI detach pro-
cedure (cause set to specific LR error ERR_LR_104), and a transfer towards the MS is ongoing with the
CP–DATA(RP–ACK) not yet received, it returns a ForwardShortMessage error with ”Absent subscriber”
cause. Then Set–MNRF message is sent by SMT RCF to SMT VLR to request the setting of MNRF flag
in VLR database.
2.5.2 Messages; Forwarding of multiple short messages
If the dialogue versions between SC , SMS–GMSC and VMSC are adequate (SMSAP V2 and MAP phase
2), the SC indicates to SMS–GMSC that other message is following. Then, the SMS–GMSC forwards this
information to the VMSC.
If the dialogue versions are inadequate, the transfer of several and subsequent short messages is handled
at VMSC as independant short messages.
a) Transfer of the first short message:
The ”More message to send” parameter of FSM message indicates to VMSC that a subsequent short
message has to be waited.
The message is treated in the same way as a single short message, except that
• At the end of transfer, the VMSC does not release the MS.
• The ForwardShortMessage result is sent in a TC–CONTINUE. Yet, if the VMSC sends a For-
wardShortMessage error, the transaction to the gateway MSC is terminated even if a new For-
wardShortMessage is expected on the same transaction.
• A timer T_SUBSEQ is introduced to supervise the receipt of the subsequent ForwardShortMes-
sage in the same TCAP dialogue. If the timer expires, the MSC shall close the TCAP transaction
with a TC–END and requests a Channel release to RM function.
b) Transfer of following short messages:

• The subsequent messages expected on the same MAP transaction suspend the treatment of
short messages waiting in the delivery queue (MT short message coming from others SCs).
• The authentication and identification procedures are not performed again.
• The same RR connection is used to transfer a subsequent MT short message.
• The Transaction Identifier used for the new transaction is different from the last one used.
• The CP–Data is coded using the Sm–RP–DA of the initial MT short message transfer.
• The MSC ignores the eventual Sm–RP–OA of the subsequent ForwardShortMessage and uses
1AA 00014 0004 (9007) A4 – ALICE 04.10
the one of the initial message.
ED 04
CIT AAC020298400DS En 25 / 135
135
2.5.2.1 Management of the Forward Check SS Indication
RCF SMT in VMSC may receive at any time the MI_F_C_SS_H_I message which comes from the HLR
through the VLR.
As soon as MI_F_C_SS_H_I message is received, SMT forwards the ”ForwardCheckSSIndication” to SH

in the MI_FCSS_SH_REQ message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 26 / 135
135
2.5.3 Scenarios
2.5.3.1 Successful case – Single Short Message Transfer

GMSC VMSC VMSC

S RCF RCF VLR MS

C
SMT SMT PA SC SH SMT PA SC LR
MI–F–SM–I
(TC–Beg) MI–SINF–SMT–I
(TC–Begin)
MI–PAGE–SMT–REQ
Paging (see [6] page 6)
MI–PAGE–SMT–ACK
MI–VSM–SC–REQ
Security (see [7] page 6)
MI–VSM–SC–RES
Check IMEI (see [7] page 6)
MI_F_C_SS_H_I (1)
MI_FCSS_SH_REQ
MI–COM–SMT–I
(TC–End)
MI_DBL_STR_RES
IMEI_ACK
(1) If received from the HLR
Figure 8. Forwarding of short message (1/2)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 27 / 135
135
GMSC VMSC VMSC
S RCF RCF VLR MS
C
SMT SMT PA SC SH RM SMT PA SC LR
CP–DATA (RP–Data)
CP–ACK
CP–DTA (RP–Ack)
CP–ACK
MI–F–SM–R
(TC–End)
Figure 9. Forwarding of short message – single transfer (2/2)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 28 / 135
135
2.5.3.2 Successful case – Multiple Short Message Transfer – Phase 2 dialogue GMSC–VMSC
GMSC VMSC VMSC

S RCF RCF VLR MS
C
See SMS connection between SC and SMS–GMSC
Data Form 1 (RP–MT–DATA)
See retrieval of routing information
MI–F–SM–I
(1)
(TC–Begin)
MI–SINF–SMT–I
See successful case – Single SM transfer
MI–COM–SMT–I
CP–ACK
CP–DATA (RP–Ack)
CP–ACK
MI–F–SM–R
(TC–Continue)
Data Form 1 (RP–MT–ACK)
(1) with MoreMessageToSend parameter
Figure 10. Forwarding of short message – Multiple transfer (1/2)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 29 / 135
135
GMSC VMSC VMSC
S RCF RCF VLR MS
C
Data Form 1 (RP–MT–DATA)
MI–F–SM–I
(TC–Continue)
CP–ACK
CP–ACK
MI–F–SM–R
(TC–End)
set message waiting data or SM delivery status report procedure is started
Figure 11. Forwarding of short message – Multiple transfer (2/2)
2.5.3.3 Unsuccessful case – GMSC <–––> VMSC <–––> VLR interface

IMSI UNKNOWN – F–SMS–003 is not offered
GMSC VMSC VMSC

S RCF RCF VLR
C
SMT SMT SMT
MI–F–SM–I
(TC–Begin) MI–SINF–SMT–I
(TC–Begin)
IMSI unknown
MI–SINF–SMT–E
(unidentified subscriber
(TC–End)
MI–F–SM–E
(TC–End)
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 12. IMSI unknown (1/2)
ED 04
CIT AAC020298400DS En 30 / 135
135
IMSI UNKNOWN – F–SMS–003 is offered
GMSC VMSC VMSC

S RCF RCF VLR

C
SMT SMT SMT PA
MI–F–SM–I
(TC–Begin)
IMSI unknown
MI_SEAR_SMT_REQ
SECURITY PHASE
UPDATE LOCATION
MI_F_SM_R
(TC–end)
Figure 13. IMSI unknown (2/2)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 31 / 135
135
IMSI DETACHED
GMSC VMSC VMSC

S RCF RCF VLR
C
SMT SMT SMT
MI–F–SM–I
(TC–Begin)
IMSI detached or
LA not allowed
MI–SINF–SMT–E
(absent subscriber)
(TC–End)
SM sets to true
MNRF
MI–F–SM–E
(absent subscriber)
(TC–End)
set message waiting data or SM Delivery status report

procedure is started
Figure 14. Send info for SMT error (1/4)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 32 / 135
135
PAGE NEGATIVE ACKNOWLEDGE
GMSC VMSC VMSC

S RCF RCF VLR MS
C
SMT SMT PA SMT PA
MI–F–SM–I
(TC–Begin) M–SINF–SMT–I
(TC–Begin)
Paging
(see [6] page 6)
no answer from the MS
MI–PAGE–SMT–NACK
(Absent Subscriber)
SMTfunction sets
the MNRF to true
MI–SINF–SMT–E
(Absent Subscriber)
(TC–End)
MI_DBL_STR_ERR
MI–F–SM–E
(Absent subscriber)
(TC–End)
set message waiting data or SM Delivery status report

procedure is started

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 33 / 135
135
SECURITY REQUEST REJECT
GMSC VMSC VMSC

S RCF RCF VLR MS
C
SMT SMT PA SMT PA SC
MI–F–SM–I
(TC–Begin)
Paging
(see [6] page 6)
MI–PAGE–SMT–ACK
MI–VMS–SC–REQ
Security
(see [7] page 6)
MI–VSM–SC–ERR
(Illegal MS)
MI–SINF–SMT–E
(Illegal MS)
(TC–End)
MI_DBL_STR_ERR
MI–AUTH–REJ
MI–F–SM–E
(Illegal MS)
(TC–End)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 34 / 135
135
IMEI CHEK FAILED
GMSC VMSC VMSC

S RCF RCF VLR MS
C
SMT SMT PA SC SMT PA SC
MI–F–SM–I
(TC–Begin)
Paging
(see [6] page 6)
MI––PAGE–SMT–ACK
MI–VSM–SC–REQ
Security
(see [7] page 6)
MI–VSM–SC–RES
Check IMEI
(see [7] page 6)
MI–COM–SMT–I
(TC–End)
MI_DBL_STR_RES
IMEI_NACK
MI_F_SM_E
(TC–End)
Figure 17. Check IMEI failure (4/4)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 35 / 135
135
2.5.3.4 Unsuccessful case – VMSC <––––> MS CP level
GMSC VMSC VMSC

S RCF RCF VLR MS
C
MI–F–SM–I
Successful case
Receipt of CP–ERROR:
CP–ERROR
MI–F–SM–E
OR
Invalid CP–DATA:
CP–ACK
CP–ERROR
MI–F–SM–E
Figure 18. Error case VMSC <–––> MS CP level
2.5.3.5 Unsuccessful case – VMSC <––––> MS RP level
GMSC VMSC VMSC

S RCF RCF VLR MS
C
MI–F–SM–I
Successful case
CP–ACK
Receipt of RP–ERROR:
CP–DATA (RP–Error)
CP–ACK
MI–F–SM–E
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 19. Error case VMSC <–––> MS RP level
ED 04
CIT AAC020298400DS En 36 / 135
135
2.5.3.6 Unsuccessful case – RCF <––––> BSSMAP interface
SAPI ”n” REJECT
GMSC VMSC BSS

S RCF RCF MS
C
SMT SMT RM BSSMAP
SAPI ”n” REJECT
Radio Ressource Management

See [8] page 6)
MI–CH–REL–IND
MI–F–SM–E
(TC–End)
Figure 20. Failure at the radio side (1/1)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 37 / 135
135
2.6 Set Message waiting data and SM Delivery Status Report procedures
a) The procedure is started in case of unsuccessful delivery attempt due to:

• Absent subscriber (i.e. IMSI detached, no paging response, or LA not allowed),
• Unidentified subscriber at VMSC,

• SM delivery failure with cause ”memory capacity exceeded” (only when phase 2 dialogue with
HLR).
MI_S_MW_I (MAP phase 1 ”Set message waiting data”) or MI_R_SMD_S_I (MAP phase 2 ”Report
SM Delivery Status”) with AbsentSubscriber or MemoryCapacityExceeded as SM–DeliveryOut-
come is sent by the RCF SMT of the SMS–GMSC to the HLR SMT in order to include a new SC ad-
dress in the MWD.
b) The procedure is also started in case of successful delivery attemp to report the HLR about a suc-
cessful transfer and then to trigger an Alert procedure (only when phase 2 dialogue with HLR).
MI_R_SMD_S_I (MAP phase 2 ”Report SM Delivery Status”) with Successful Transfer as SM–Deliv-
eryOutcome is sent by the RCF SM of the SMS–GMSC to the HLR SM.
2.6.1 SMS–GMSC treatments
2.6.1.1 Sending of Set Message Waiting Data / Report SM Delivery Status
This message is sent by the SMS–GMSC as follows:
a) After the SMS–GMSC has received a ForwardShortMessage error with error cause set to:
• SM–Deliveryfailure with cause ”Memory capacity exceeded”:
With phase 2 dialogue with HLR, the SMS–GMSC sends the ReportSMDeliveryStatus, with
SM_DeliveryOutcome set to MemoryCapacityExceeded, if the MCEF flag is clear in HLR or if
the SC address is not yet included in MWD.
With phase 1 dialogue with HLR, no specific action is performed by the SMS–GMSC.
• Absent subscriber or Unidentified subscriber:
With phase 2 dialogue with HLR, the SMS–GMSC sends the ReportSMDeliveryStatus, with
SM_DeliveryOutcome set to AbsentSubscriber, if the MNRF flag is clear in HLR or if the SC ad-
dress is not yet included in MWD.
With phase 1 dialogue with HLR, the SMS–GMSC sends the SetMessageWaitingData mes-
sage, if the MNRF flag is clear in HLR or if the SC address is not yet included in MWD.
N.B.
The GMSC has got the state of flags and MWD file from the HLR in InformServiceCenter
(phase 2) or SendRoutingInfoForSM result (phase1) message, otherwise a default in-
formation is used (Flags clear and SC address not included in MWD).
b) After the SMS–GMSC has received a ForwardShortMessage result
With phase 2 dialogue with HLR, the SMS–GMSC sends the ReportSMDeliveryStatus, with SM_De-
liveryOutcome set to SuccessfulTransfert, if MNRF and/or MCEF flag is set in HLR (data got by the
1AA 00014 0004 (9007) A4 – ALICE 04.10
GMSC from the HLR in InformServiceCenter message).

The HLR is in that way informed of successful transfer and can reset MNRF and MCEF flags and
triggers an Alert procedure.
ED 04
CIT AAC020298400DS En 38 / 135
135
With phase 1 dialogue with HLR, the SMS–GMSC performs no action.
2.6.1.2 End of set message waiting data / SM delivery status report procedure
After the end of the procedure (receipt of result or error from HLR), the GMSC (RCF SMT) informs the SC
about the original error received from VMSC by sending a DT1 containing a RP–MT–ERROR message
which layout depends on the result of the set message waiting or SM delivery status report procedure:
– RP–MW flag, indicating whether the MWD has been updated,
– RP–cause (error cause received from VMSC in Forward short message error translated towards the
SC)
– RP–MSISDN (only SMSAP V2) indicating the MSISDN–Alert if received from HLR in SM delivery
status report procedure.
– RP–User–data (only SMSAP V2) which contains, if received in MI_F_SM_E, the field DiagnosticInfo
of SM–DeliveryFailure error cause.
2.6.2 HLR treatments at the reception of the message
At the reception of the message, the HLR SMT

– verifies the correctness of the data content;
– verifies that the MSISDN number is known;
Futhermore,
– If the SM delivery outcome reports a successful delivery, the HLR alert the SCs in the MWD list as
described in < 2.7 page 42>.
– If the SM delivery outcome reports a unsuccessful delivery, the HLR verifies that the MWD is not full.
If any of the checks fails, the message MI_S_MW_E (MAP phase 1 ”Set message waiting data error”) or
MI_R_SMD_S_E (MAP phase 2 ”Report SM Delivery Status error”) is returned to the RCF SMT in GMSC.
If the MWD is correctly updated,

– The MCEF flag is set and MNRF reset if SM delivery outcome is memory capacity exceeded. The
MNRF flag is set if SM delivery outcome is absent subscriber.
– The message MI_S_MW_R (MAP phase 1 ”Set message waiting data result”) or MI_R_SMD_S_R
(MAP phase 2 ”Report SM Delivery Status result”) with the MSISDN–alert as parameter is returned
to the RCF SMT in GMSC.
N.B. To avoid that the SC addresses remain in the MWD in case the MS is not reachable for a long
period, the HLR will provide, for each SC address, a timer T_MWD to be started when the SC
address has been added to the MWD.
It will be stopped after the SC address has been deleted from the MWD (owing to the sending
of an Alert message to the IWMSC).
At the expiry of the timer the SC address is deleted from the MWD.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 39 / 135
135
2.6.3 Scenarios
GMSC VMSC VMSC HLR

S RCF RCF VLR
C
SMT SMT SMT SMT
MI–SINF–SMT–E
(absent subscriber)
(TC–End)
MI–F–SM–E
(absent subscriber)
(TC–End)
MI–S–MW–I / MI–R–SMD–S–I
(TC–Begin) the SC address

is added to the
MWD
MRF flag is set
MI–S–MW–R / MI–R–SMD–S–R
(TC–End)
Data Form 1
RP–MT–Error
Figure 21. Set message waiting data/ SM Delivery Status report – Absent subscriber case
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 40 / 135
135
GMSC VMSC HLR
S RCF RCF MS
C
SMT SMT SMT
CP–DATA (RP–Error) (Memory capacity exceeded)
CP–ACK
MI–F–SM–E
SM–deliveryFailure cause MemoryCapacityExceeded
(TC–End)
MI–R–SMD–S–I
(1)
(TC–Begin) the SC address
is added to the
MWD
MCEF flag is set
MNRF flag is reset
MI–R–SMD–S–R
(TC–End)
Data Form 1
RP–MT–Error
(1) Only in MAP phase 2 dialogue with HLR
Figure 22. Set message waiting data/ SM Delivery Status report – Memory capacity exceeded case
GMSC VMSC VMSC HLR

S RCF RCF VLR
C
SMT SMT SMT SMT
MI–F–SM–R
(TC–End)
(1)
(TC–Begin)
MI–R–SMD–S–R– or MI–R–SMD–S–E
(TC–End)
Data Form 1
RP–MT–Ack
1AA 00014 0004 (9007) A4 – ALICE 04.10
(1) may trigger an Alert procedure
Figure 23. SM Delivery Status report – Successful delivery
ED 04
CIT AAC020298400DS En 41 / 135
135
2.7 Alerting Service Center procedure
The purpose of the procedure is to inform a SC that:

– a MS for which a delivery attempt has been unsuccessful (due to IMSI detached, no paging response
or LA not allowed reason) is again reachable,

– a MS for which a delivery attempt has been unsuccessful (due to memory capacity exceeded) has
again memory capacity to accept a short message,
– a delivery attempt ended with success towards a MS for which a delivery attempt has been previously
unsuccessful.
The alerting of the service center is always invoked by the HLR (via the IWMSC) either directly or on the
VLR request.
2.7.1 Alert procedure triggering

GMSC HLR VMSC
LR (2) LR
HLR VLR
(1) (3) SC
VLR
SMT (5) SMT (4) SMO SMO

RCF HLR VLR RCF
(1) Note MS present (internal interface)

triggered by an Update location procedure at HLR level
(2) Ready for SM / Note subscriber present (ms–present as alert reason)
triggered by an Update location procedure at VLR level
(3) Ready for SM / Note subscriber present (ms–present as alert reason)
triggered by a Security request (from OC,TC,LR,SH,SMT,
SMO) ended with success
(4) Ready for SM (memoryavailable as alert reason)
triggered by a Short message originating procedure
with SM–Memory–Available
(5) Report SM delivery status (successfultransfert as SMDeliveryOutcome)
triggered by a successful short message transfer
Figure 24. Alert procedure triggering

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 42 / 135
135
The messages which may trigger an Alert procedure in HLR are:
– MI–MS–P–I (MAP phase 1 ”NoteSubscriberPresent”)

or MI–R–F–SM–I (MAP phase 2 ”ReadyForSM”) with ms–present as alert reason is sent by the VLR
to the HLR SMT when the VLR detects that one of the following procedure has been successfully
completed:
• Paging or searching;
• Update location area;
• Attach IMSI;
• Process access request;
and if MNRF indicates that there is at least one message waiting to be delivered to the MS.
The message is sent at the completion either of the security procedures or of the update location pro-
cedure (when no security procedure is required).
This message is sent by Security function in VLR, only if the mobile station has SMS capability.
Refer to SDLs of SC function in VLR < [7] page 6>.
It can be sent also by LR in case flag MNRF is true and the MS is allowed to roam in the new LA.
Moreover it can also be sent by LR if no Security is performed for this Update Location.
Refer to SDLs of LR function in VLR < [10] page 6>.
In Phase 1 dialogue with the HLR, after sending the message the MNRF is reset to false.
In Phase 2 dialogue with the HLR, the MNRF flag is cleared only if the procedure is successful (receipt
of MI–R–F–SM–R).
– MI–R–F–SM–I (MAP phase 2 ”ReadyForSM”) with memoryavailable as alert reason is sent by the
VLR to the HLR SMT when the VLR detects that the MS has again memory available for short mes-
sage.
– MI–R–SMD–S–I (MAP phase 2 ”ReportSMDeliveryStatus”) with SuccessfulTransfert as SM–Deliv-

eryOutcome is sent by the GMSC to the HLR SMT when a short message has ended successfully
and MNRF and/or MCEF are known set in HLR.
– MI–MS–PRESENT (Internal message) is sent by the HLR LR to the HLR SMT when an update loca-
tion procedure has been correctly completed.
2.7.2 Alert procedure at HLR level
If one of these messages is not correctly received, no further action is performed by the HLR.
If one message is correctly received and the MWD is not empty,the HLR SMT, for each SC address of the
MWD, sends to the IWMSC the message MI–A–SC–WR–I (MAP phase 1 ”AlertServiceCenterWithoutRe-
sult”) or the message MI–A–SC–I (MAP phase 2 ”AlertServiceCenter”).
Furthermore,
– For Alerting required by the VLR with MS present reason, the Alert procedure is not triggered if MCEF
flag is set. The trigger of Alert procedure is delayed if neither MCEF, nor MNRF flag are set (a race
situation with Report SM delivery status is then assumed, refer to the scenario for the particular treat-
ment). The HLR MNRF flag is cleared in any cases.
1AA 00014 0004 (9007) A4 – ALICE 04.10
– For Alerting required by the VLR with memory available reason, the trigger of Alert procedure is
delayed if neither MCEF, nor MNRF flag are set (a race situation is then assumed, refer to the scenar-
io for the particular treatment).
The HLR MNRF and MCEF flags are cleared.
ED 04
CIT AAC020298400DS En 43 / 135
135
– For Alerting required by the GMSC with successful transfer reason, the HLR MNRF and MCEF flags
are cleared.
In accordance with the option F–SMS–001, routing information towards the IWMSC is retrieved either by
analysis of the SC address or by analysis of one IWMSC address contained in an HLR data.
In Phase 1 dialogue with the IWMSC, after sending the message the SC address is deleted from the MWD.
In Phase 2 dialogue with the IWMSC, The MWD entry is deleted when the positive acknowledge is re-
ceived from the IWMSC. The unsuccessful alert is repeated (the number of attempts is a system parame-
ter, default value = 2).
In the unsuccessful case, the MWD is purged by the treatment described in 2.6 page 38.
2.7.3 Alert procedure at IWMSC level
If the message is correctly received, the RCF (SMT) alerts the Service Center by sending the message
RP_ALERT containing the involved MSIsdn.
The message is sent to the SC in a connectionless mode that is using a UDT SCCP message which will
contain the following fields:
– Calling address = MS address = MS ISDN
– Called address = SC address
– User data = RP Alert message
Just after the sending towards the SC, the IWMSC acknowledges the HLR Alert message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 44 / 135
135
2.7.4 Scenarios
ALERTING REQUIRED BY THE VLR (MS PRESENT)
IWMSC VLR HLR

S RCF
C
SMT SMT SC OC LR SMT
security procedure
(requested by TC, LR, OC,
SH, SMT, SMO successfuly ended)
MNRF is true
MI–MS–P–I or MI–R–F–SM–I
(1)
MI–R–F–SM–R
(2)
MI–A–SC–WR–I or MI–A–SC–I
(3)
(TC–Begin)
UDT
(RP_Alert)
MI–A–SC–R
(2)
(TC–End)
(1) It can be sent also by LR in case flag MNRFis true and the MS is allowed to roam in the new LA.
Moreover it can also be sent by LR if no Security is performed for this Update Location.
(2) Only in MAP phase 2 dialogue
(3) Only if MCEF is false
Figure 25. Alert service center (1/5)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 45 / 135
135
ALERTING REQUIRED BY THE VLR (MEMORY AVAILABLE)
Only if Phase 2 dialogue between VLR and HLR
IWMSC VLR HLR

S RCF
C
SMT SMO SMT
MI–R–F–SM–I (memory available)
MI–R–F–SM–R
(TC–Begin)
UDT
(RP_Alert)
MI–A–SC–R
(2)
(TC–End)
ALERTING REQUIRED BY THE GMSC (SUCCESSFUL TRANSFER)
Only if Phase 2 dialogue between GMSC and HLR

IWMSC GMSC HLR
S RCF RCF
C
SMT SMT SMT
MI–R–SMD–S–I (successful transfer)

(1)
(TC–Begin)
UDT
(RP_Alert)
MI–A–SC–R
(2)
(TC–End)
(1) Only if MNRF and/or MCEF are known set in HLR


1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 46 / 135
135
ALERTING REQUIRED BY THE VLR (RACE SITUATION)
SMS–GMSC VLR HLR

S RCF
C
SMT SMT SMT
MI–MS–P–I or MI–R–F–SM–I
(1)
MI–R–F–SM–R
(4)
(2)
(4)
(TC–Begin)
UDT (RP–Alert)
MI–A–SC–R
(4)
(TC–End)
(1) If neither MNRF nor MCEF are set, it is assumed that a race situation occurs. Then,
a timer T_RACE is triggered to wait the Report SM delivery status message.
(2) If a Report SM delivery status is received when the timer is running, this message is handled
normally.
At the timer expiry, if the MNRF or MCEF are set the Alert procedure is restarted.
Elseif no further treatment is performed.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 47 / 135
135
ALERTING REQUIRED BY THE HLR
IWMSC VLR HLR

S RCF
C
SMT SMT PA LR SC SMT LR
MI–MS–PRESENT
MWD not empty

(TC–Begin)
UDT
(RP_Alert)
MI–A–SC–R
(2)
(TC–End)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 48 / 135
135
3 INTERFACE MATRIX
The names of interfaces use SM for SMT function and MO for SMO function (e.g. MIVMOHSM refers to
the interface between SMO function in VLR and SMT function in HLR).
Function
Related functions Implementation
Messages
B R V H S
Name FB S C L L C
S F R R
Short Message Service MIRSMSSM

Terminating P U –RP–MT–Data
(DT1)
U P –RP–MT–Error
(DT1)
U P –RP–MT–Ack
(DT1)
U P –RP–Alert
(UDT)
MIRSMHSM
U P –Send routing info for SM
(INV/RES/ERR)
P U –Inform Service Center
(INV)
U P –Set Message Waiting Data
(INV/RES/ERR)
U P –Report SM Delivery
Status
(INV/RES/ERR)
P U –Alert Service Center
(INV/RES/ERR)
P U –Alert Service Center
Without Result
(INV)
MIRSMRSM
U/P –Forward Short Message
(INV/RES/ERR)
MIRSMVSM
U P –Send info inc sm call
(INV/ERR)
P U –Complete sm call
(INV)
–Set MNRF flag
MIRSMRSM
U –DeblockSMtransaction
(Res/Err)
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 30. Short Message Service Funtional Matrix(1/3)
ED 04
CIT AAC020298400DS En 49 / 135
135
Function
Messages
B R V H S
Name FB S C L L C
S F R R
Short Message Service MIRSMSSM

terminating MIRSMBSM
P U –CP–Data(RP–data)
U P –CP–ACK
P U –CP–ACK
U P –CP–Data(RP–Ack)
U P –CP–Data(RP–Error)
P U –CP–Error
U P –CP–Error
Paging VLR MIVSMVPA

U –Page request
(Request/ack/nack)
U –Search request
(Request/ack/nack)
Security VLR MIVSMVSC

U –Security Req. from SM
(Request/ack/reject)
U –Security Release from SM
U –IMEI Check
(Ack/nack)
MIVSCHSM
U P –Note subscriber present
(INV)
U P –Ready For SM
(INV/RES/ERR)
Location Registration HLR MIHLRHSM

U –Note MS present
VLR MIRSMVLR
P –ForwardCheckSSIndication
MIVLRHSM
U P –Ready For SM
(INV/RES/ERR)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 50 / 135
135
Function
Messages
B R V H S
Name FB S C L L C
S F R R
Call Barring HLR MIHSMHCB

U –Inc. call barring check
(Request/result)
Radio Res. Management RCF MIRSMRRM

U – Chann. rel. Ind.
U – Channel release
U – Channel release complete
U – Channel in use
Charging RCF MIRSMRCG

U – Charging request from SM
Sup. Service Handling RCF MIRSHRSM

U – ForwardCheckSS transfer
(Request)
MM RCF P MIRMMRMM
– Deblock transaction
waiting for MM proc.
(Res/Err)
Short Message Service VLR

Originating
MIVMOHSM
U P –Ready For SM
(INV/RES/ERR)

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 51 / 135
135
4 CONSEQUENCES OF V1 AND V2 MAP APPLICATION CONTEXTS MIX BE-
TWEEN PLMN ENTITIES
Assumption: The data at HLR and VLR level are according to phase 2 (handling of MSISDN–Alert, MNRF,
MCEF and MWD). The phase 2 treatments at HLR and VLR level are always used. They are designed
to be compatible with phase 1. Phase 1 dialogues between entities entails only some restrictions of fea-
ture.
(4)
SMS–IWMSC
(1) (3)
SMS–GMSC HLR MSC/VLR
(2)
(1) shortMsgGatewayContext V1/V2 :

SendRoutingInfoForSM
ReportSMDeliveryStatus/SetMessageWaitingData
InformServiceCenter
(2) shortMsgMT–RelayContext V2, shortMsgRelayContext V1 :
ForwardShortMessage
(3) mwdMngtContext V1/V2 :
ReadyForSM/NoteSubscriberPresent
(4) shortmsgAlertContext V1/V2 :
AlertServiceCenter/AlertServiceCenterwithoutresult
4.1 Restrictions of feature induced by use of v1 context:
– (1) Use of v1 context entails:

The SC cannot received indication on MNRF and MCEF flags.
The HLR cannot be informed of successful transfer for triggerring an Alert procedure.
The HLR cannot be informed of MemoryCapacityExceeded for inserting the SC address in MWD.
– (2) Use of v1 context entails no main feature restriction (a new dialogue is used for each transfer and
the SMS–DELIVER–REPORT TPDU cannot be forwarded towards the SC)
– (3) The Alert procedure with reason memoryavailable cannot be triggered in case of v1 context use.
– (4) Use of v1 context entails no feature restriction (the message has no response).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 52 / 135
135
4.2 Consequences of v1 and v2 Application Context mix
Some inconsistencies may occur related to MemoryCapacityExceeded/Available feature. MCEF flag be-
ing handled only in HLR , incoherency between HLR and VLR is not possible.
But, if (1) Application Context is in V2 and (3) in V1, and there is memory capacity exceeded in the MS:
– SC address will be inserted in MWD and MCEF flag set in HLR,

– The Alert procedure will never be triggered by the VMSC.
It is not unsafe because:
– The MCEF flag set in HLR does not prevent the short message to be forwarded towards VMSC.
– A successful transfer reset MCEF flag and may trigger an Alerting procedure.
Furthermore, the described case above occurs also with a phase 1 MS which cannot indicate memory
avalaible event.
In the opposite, if (1) is in V1 and (3) in V2, on receipt of ReadyForSM with alert reason MemoryAvailable,
an Alert procedure will be triggered if MNRF is set at HLR.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 53 / 135
135
5 INTERFACES WITHIN THE FUNCTION SHORT MESSAGE
5.1 MIRSMSSM: Interface between the GMSC and the SC

See < [4] page 6>.
5.2 MIRSMHSM: Interface between RCF and HLR
5.2.1 Send Routing Information for Short Message
This message is sent by the RCF of the GMSC to the HLR to retrieve routing information.
If the functional option F–SMS–005 is offered, this message may be sent to the HLR in order to retrieve
the MSC address only. Any particularities are described in note (11).
– Identity of the interface : MIRSMHSM
– Type of interface : MAP
– Ref : GSM phase 1 09.02 fig. 6.2/13 (Sheet 1 of 2)

GSM phase 2 09.02 §14.6.5
– Information exchanged on the interface :

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 54 / 135
135
Message Identification Parameters V1 V2
SendRoutingInfoForSM – msIsdn (1) M M

(Invoke) – sm–RP–PRI (2) M M

– ServiceCenterAddress (3) M M
– TeleserviceCode (4) O
MI_S_RGI_SM_I
RCF–––>HLR See also note (11)
SendRoutingInfoForSM – UnknownSubscriber x x
(Error) – CallBarred (5) x x
CallBarringCause O O
– CUG–Reject x
– TeleserviceNot x x
provisioned
– AbsentSubscriber (6) x x
mwd–set (boolean) O O
– FacilityNotSupported (7) x x
– SystemFailure x x
MI_S_RGI_SM_E – DataMissing x x
– UnexpectedDataValue x x
HLR–––>RCF See also note (11)
SendRoutingInfoForSM – imsi M M
(Result) – locationInfo (8) M
– MSCNumber M
– lmsi (9) O O
– mwd–Set (boolean) (10) O O
MI_S_RGI_SM_R
HLR–––>RCF See also note (11)
(M) means Mandatory

(O) means Optional
Figure 33. Send Routing Information for Short Message : messages layout
Notes:
– (1) : The RCF sends to HLR an E.164 international number (i.e. ’Nature of address indicator’ = ’in-
ternational number’ and ’Numbering indicator’ = ’ISDN/Telephony number plan (REC E.164)’).
The digits are those of RP–Destination–address received from SC in RP–MT–Data.
The HLR accepts an E.164 number with ’Nature of address indicator’ = ’international number’ or ’na-
tional number’.
– (2) : Handling of parameter SM–RP–PRI depends on a functional option (F_SMS_004). When prior-
ity is not handled, all short messages are considered to be non–priority messages.
When priority is handled, this parameter is filled according to the RP–Priority parameter received
1AA 00014 0004 (9007) A4 – ALICE 04.10
from SC in RP–MT–Data.
– (3) : International Number ISDN/Telephony E.164.
ED 04
CIT AAC020298400DS En 55 / 135
135
Digits are those received from SC in RP–Originating–address parameter of RP–MT–Data.
– (4) : The field is not sent by the RCF.

If the HLR receives the CUG–Interlock parameter, it would be rejected with the error ”mistyped pa-
rameter”.
If the HLR receives the teleservice code parameter, it would be ignored.
– (5) : CallBarringCause may be ’BarringServiceActive’ or ’OperatorBarring’
– (6) : In MAP phase 1, the associated parameter is the mwd–set indicating whether the SC address
has been included in the MWD or not.
Always sent in MAP phase 1 by the HLR. When not sent by a HLR, RCF does as it is FALSE.
The mwd–Set, not foreseen in GSM phase 2 09.02, is set Optional in order to ignore it, if received
in phase 2 dialogue.
In MAP phase 2, see InformServiceCenter message.
The Absent subscriber error corresponds with the following cases:

• No MSC identity in HLR
• ”MSC area restricted flag” set in HLR
• ”MS purged flag” set in HLR
• SM–RP–PRI = false and MNRF flag set in HLR (MCEF any)
– (7) : This cause (SMS–MT not supported by the VMSC) is sent to RCF due to the check of SMSMT
flag.
– (8) : The LocationInfo may indicate roaming number or servicing MSC address; but the RCF handles
only the MSC address.
– (9) : It is mandatory for the HLR to include the LMSI, if the VLR has used the LMSI (See update loca-
tion procedure).
– (10) : The mwd–Set, not foreseen in GSM phase 2 09.02, is set Optional in order to ignore it, if re-
ceived in phase 2 dialogue.
In MAP phase 2, see InformServiceCenter message.
Always sent in MAP phase 1 by the HLR. When not sent by a HLR, RCF does as it is FALSE.
– (11) : If the option F–SMS–005 is set the MSISDN sent in Private Numbering Plan will be accepted.
The following applies in this case:
• ServiceCenterAddress is an international E.164 number, but may have a dummy value
• TeleserviceCode is not sent
• the following errors are not applicable
– Cug–reject
– TeleserviceNotProvisioned
– FacilityNotSupported
• lmsi is not sent by the HLR
• mwd–set is not applicable
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 56 / 135
135
5.2.2 InformServiceCentre
This service is used between the HLR and the SMS–GMSC to inform the SC which MSISDN number is
stored in the MWD file. This service replaces also the parameter mwd–set of SRI message in use for phase
1 dialogue.
– Ref : GSM phase 2 09.02 §14.6.5
Message Identification Parameters V2
InformServiceCentre – storedMSISDN (1) O

– mw–Status (2) O
MI_I_SC_I Bit String(
.sc–AddressNotIncluded
.mnrf–set
.mcef–set)
HLR–––>RCF
Notes:
– (1): If the stored MSISDN number is not the same than the one received from the GMSC in the SRI,
the stored number is included. The stored MSISDN is the MSISDN–Alert.
– (2): If mw–Status is not received, the value zero is assumed.

SC–AddressNotIncluded indicates the status of the particular SC address presence in the MWD file
(i.e. if the SC address is not included in the MWD list).
N.B. See < 2.3.1.2 page 17> for details (when this message is sent and how it is filled).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 57 / 135
135
5.2.3 Set Message Waiting Data / Report SM Delivery Status
5.2.3.1 Set Message Waiting Data

This message is sent by the RCF to the HLR to request the inclusion of the new SC address in the MWD.
SetMessageWaitingData – msIsdn M
(Invoke) – ServiceCenterAddress M
MI_S_MW_I
RCF–––>HLR
SetMessageWaitingData – UnknownSubscriber
(Error) – MessageWaitingListFull
– UnexpectedDataValue
MI_S_MW_E – Data missing
HLR–––>RCF
SetMessageWaitingData none
(Result)
MI_S_MW_R
HLR–––>RCF
(M) means Mandatory

(O) means Optional
Figure 34. Set Message Waiting Data : messages layout

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 58 / 135
135
5.2.3.2 Report SM Delivery Status
This service is used by the SMS–GMSC to set the MWD into the HLR or to inform the HLR of successful
SM transfer.
– Ref : GSM phase 2 09.02 §14.6.5
ReportSM–DeliveryStatus – msIsdn M
– sm–DeliveryOutcome M
MI_R_SMD_S_I Enumerated
(AbsentSubscriber
(MemoryCapacityExceeded
RCF–––>HLR (SuccessfulTransfert
ReportSM–DeliveryStatus – UnknownSubscriber
(Error) – MessageWaitingListFull
MI_R_SMD_S_E – DataMissing
HLR–––>RCF
ReportSM–DeliveryStatus – storedMSISDN (1) O

(Result)
MI_R_SMD_S_R
HLR–––>RCF
(M) means Mandatory

(O) means Optional
Figure 35. Report SM Delivery Status : messages layout
Note:
– (1) It is the MSISDN–Alert. Stored MSISDN parameter is inserted if the MSISDN–Alert is not the
same as MSISDN of invoke.
N.B. See < 2.6.1 page 38> for details (when this message is sent and how it is filled).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 59 / 135
135
5.2.4 AlertServiceCenterWithoutResult (Phase 1)
This message is sent by the HLR to the IWMSC to invoke the starting of the Alert procedure towards the
SCs.
AlertServiceCenterwithout – msIsdn (1) M

Result (Invoke) – ServiceCenterAddress M
MI_A_SC_WR_I
HLR–––>RCF
(M) means Mandatory

(O) means Optional
Figure 36. Alert Service Center Without Result message layout
Note:
– (1) : The provided MSISDN shall be the one which is stored in the MWD file (MSISDN–Alert).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 60 / 135
135
5.2.5 Alert Service Center (Phase 2)
The HLR sends this message if a subscriber, whose is in the MWD file, becomes active or the MS has
memory available.
– Ref : GSM phase 2 09.02 §14.6.5
AlertServiceCenter – msIsdn (1) M

MI_A_SC_I
HLR–––>RCF
AlertServiceCenter – SystemFailure
(Error) – DataMissing
MI_A_SC_E
RCF–––>HLR
AlertServiceCenter
(Result) none
MI_A_SC_R
RCF–––>HLR
(M) means Mandatory

(O) means Optional
Figure 37. Alert Service Center message layout
Note:
– (1) : The provided MSISDN shall be the one which is stored in the MWD file (MSISDN–Alert).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 61 / 135
135
5.3 MIRSMRSM : Interface between GMSC and VMSC
5.3.1 Forward Short Message

This message is sent by the RCF of the gateway MSC to the RCF of the servicing MSC to require the for-
ward of the short message.
In phase 2, the MAP ForwardShortMessage may be received at the beginning of the MAP transaction or
as a subsequent message in the same MAP transaction.
– Identity of the interface : MIRSMRSM
GSM phase 2 09.02 §14.6.5
ForwardShortMessage – SM–RP–DA (1) M M

(Invoke) Choice (
.imsi x x
MI_F_SM_I .lmsi x x
.roamingnumber x
.noSM–RP–DA ) x
– SM–RP–OA (2) M M
Choice (
.ServiceCenterAddressOA x x
.noSM–RP–OA) x
– SM–RP–UI (3) M M
RCF–––>RCF – MoreMessagesToSend (4) O
ForwardShortMessage – UnidentifiedSubscriber x x
(Error) – AbsentSubscriber x x
– FacilityNotSupported x x
– IllegalMS x
– IllegalSubscriber (5) x
MI_F_SM_E – SystemFailure x x
– UnexpectedDataValue x x
– SM–DeliveryFailure x x
.Cause M M
(memory capacity exceeded x x
(equipment protocol error x x
(equipment Not SM equipped x x
.DiagnosticInfo (6) O
– IllegalEquipment (7) x
RCF–––>RCF – DataMissing x
– SubscriberBusyForMT (8) x
ForwardShortMessage
(Result) none
MI–F–SM–R
RCF–––>RCF
1AA 00014 0004 (9007) A4 – ALICE 04.10
(M) means Mandatory (O) means Optional
Figure 38. Forward Short Message: messages layout
ED 04
CIT AAC020298400DS En 62 / 135
135
Notes:
– (1) : The SMS–GMSC sends the LMSI if received from HLR in the SendRoutingInfoForSM result. In
this case, the IMSI is included in the User Information Part (USI) : ”destination reference” field of TC–
BEGIN dialog portion (map–open choice of MAP–DialoguePDU, see GSM 09.02 v4.12.0 §5.3.1 and
§14.4).
For a phase 1 dialogue, SM–RP–DA shall contain an IMSI. Receipt of LMSI at VMSC entails a For-
wardShortMessage error in response.
For a phase 2 dialogue, SM–RP–DA may contain an IMSI or a LMSI.
• In case of LMSI, the IMSI must be retreived from the User Information Part (USI) in the ”destina-
tion reference” field of TC–BEGIN dialog portion.
• In case of IMSI, SM–RP–DA contains the IMSI which is not present in the USI.
At VMSC, if LMSI is not send by the SMS–GMSC, even though the VLR has sent it in update location
procedure, the received IMSI is used and a spontaneous message is issued.
The parameter roamingNumber is not accepted by the VMSC which responds with a ForwardShort-
Message error. It is never sent by our SMS–GMSC.
NoSM–RP–DA is used by the SMS–GMSC in case of subsequent MT short message transfer.

SM–RP–DA parameter is ignored by the VMSC in case of multiple MT short message transfer in the
same TCAP transaction; the value of the first ForwardShortMessage is used.
– (2) : ServiceCenterAddressOA is received from the SC in RP–Originator Address of RP–MT–Data

message.
The lack of address is indicated, either by an empty address (i.e.reduced to the first octet), or by the
use of noSM–RP–OA in phase 2 dialogue. In this case, the MSC code this Information Element of
the RP–DATA towards the MS with a length equal to ”0”.
NoSM–RP–OA is used by the SMS–GMSC in case of subsequent MT short message transfer.
SM–RP–OA parameter is ignored by the VMSC in case of multiple MT short message transfer in the
same TCAP transaction; the value of the first ForwardShortMessage is used.
– (3) : RP_User_Data of RP_MT_Data message received from the SC.

The content of the SM–RP–UI parameter is not checked by the MSC (MSC transparent to the TL
protocol).
– (4) : The MoreMessagesToSend parameter is set if a MoreMessagesToSend indication has been re-
ceived from the SC. In phase 1 dialogue the element MoreMessagesToSend cannot be transmitted.
In this case, if there are more than one message from SC, the SMS–GMSC process one phase 1
procedure for each message.
– (5) : Delivery of SM failed because the MS fails to be authenticate.
– (6) : SM–DELIVERY–REPORT can be transfered in this field (transfer without analysis of RP–user-
data field of RP–Error received from MS)
– (7) : Delivery of SM failed because the IMEI check fails.
– (8) : Only used in phase 2 dialogue.

Sent by the MSC when the delivery queue in VMSC cannot store a short message.
Sent also by the MSC when PA function responds with ”busy subscriber” error.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 63 / 135
135
5.4 MIRSMVSM: Interface between servicing MSC and VLR
5.4.1 Send Information for SMT

This message is sent by the RCF to the VLR to request whether the call can be offered to the MS.
– Identity of the interface : MIRSMVSM
– Type of interface : Specific RCF–VLR internal interface
– Ref : no GSM reference
Message Identification Parameters
Send Info for short message – IMSI (M)

(Invoke)
MI–SINF–SMT–I
RCF–––>VLR
Send–Info–for–MT–SMS
(Error)
MI–SINF–SMT–E – Unidentified subscriber

VLR–––>RCF – Absent subscriber
– Illegal MS
– Illegal equipment
– System failure
– impossible call completion
– MS not equipped
– A5/X incompatibility
(M) means Mandatory

(O) means Optional
Figure 39. Send Information for SMT : messages layout
5.4.2 Complete Short Message Call
This message is sent by the VLR to the RCF to confirm that the call can be offered to the MS.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 64 / 135
135
COMplete SMT call – Category (M) (1)

(Invoke)
– MSISDN (M) (2)

MI–COM–SMT–I
– Authentication status (O) (3)
VLR–––>RCF
(M) means Mandatory

(O) means Optional
Figure 40. Complete SMT call: message layout
– (1) : Category indicates to RCF the possible Hot Billing discrimination of the called MS, for generation
of the Hot Billing ticket (if F–HB–001 functionnality is offered).
– (2) : e.g. for charging purpose (see ref. [13] ).
– (3) : Applies if F–SC–011 is active. Aunthentication status, set to ON when authentication is not per-
formed due to ’Authentication 1/n’ function, is passed to RCF in order to not request authentication
for further transactions established in parallel.
5.4.3 Set MNRF flag
This message is sent by the RCF to the VLR to request the MNRF flag to be set in VLR database.
Set MNRF flag – IMSI (M)

(Invoke)
MI–SET–MNRF–I
RCF–––>VLR
(M) means Mandatory

(O) means Optional
Figure 41. Set MNRF flag : messages layout

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 65 / 135
135
5.5 MIRSMBSM: Interface between RCF in VMSC and BSS
5.5.1 CP–DATA
This message may be sent either by the RCF to the MS (via the BSS) or by the MS to the RCF (via the
BSS).
In the direction to the MS, it contains the short message.
In the direction to the RCF it contains the acknowledge of the short message.
– Identity of the interface : MIRSMBSM
– Type of interface : BSSAP (DTAP) message
– Ref : GSM phase 1 04.11 table 7.1

GSM phase 2 04.11 §7.2.1
CP–DATA – Protocol discriminator M M

(DTAP) – Transaction Identifier M M
– Message Type M M
– CP–User Data (1) M O
RCF<––>MS
(M) means Mandatory

(O) means Optional
Figure 42. CP–DATA message layout
Note:
– (1) : Length of CP–User Data parameter <= 249 bytes.
The parameter CP–User Data is set Optional in contrary of GSM 04.11 where it is mandatory to allow
the checks described in defence specification < [17] page 6>.
The field RPDU of CP–User Data parameter is :

• the RP–DATA from RCF towards the MS, in line with RP_MT_Data received by the GMSC from
the SC and forwarded to the VMSC in MI_F_SM_I message. (see section 5.5.1.1 page 66).
• the RP–ERROR from MS towards the RCF (see section 5.5.1.2 page 67).
• the RP–ACK from MS towards the RCF (see section 5.5.1.3 page 68).
5.5.1.1 RP–DATA layout
– Ref : GSM phase 1 04.11, table 7.4 & figure 8.3 and GSM phase 2 04.11 §7.3.1, in line with GSM
03.40.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 66 / 135
135
RP–Data – Priority indicator (1) M

– Message type indicator M M

– Message reference (2) M M

– Originator Address (3) M M
– Destination Address (4) M M
– RP–User data (5) M M
RCF––>MS
(M) means Mandatory

(O) means Optional
Figure 43. RP–Data message layout
Notes:
– (1) : Set to 0. Priority indicator (bit 6 of the first octet) is not significant in phase 2 message.
– (2) : Sequence number used to link a RP_Ack or RP_Error message to the RP_Data transfer attempt;
its value may be the transaction number.
– (3) : Service Center Address. Refer to < [4] page 6>.
– (4) : Not relevant, so length value = 0.
– (5) : Same as received from the SC. Length <= 234 bytes.
5.5.1.2 RP–ERROR layout
– Ref : GSM phase 1 04.11 table 7.6 & figure 8.5 and GSM phase 2 04.11 §7.3.4, in line with GSM 03.40.
RP–Error – Message type indicator M M

– Message reference M M
– RP–Cause (1) M M
Cause value
Diagnostic field
MS–––>RCF – RP–User Data (2) O
(M) means Mandatory

(O) means Optional
Figure 44. RP–Error message layout
– (1) : the possible causes are indicated in GSM phase 1 04.11 table 8.4 and GSM phase 2 04.11
§8.2.5.4.
Diagnostic field is ignored when received.
1AA 00014 0004 (9007) A4 – ALICE 04.10
– (2) : RP–User Data has to be forwarded by the RCF in SM–Delivery–Failure of Forward–Short–Mes-

sage (diagnostic information).
ED 04
CIT AAC020298400DS En 67 / 135
135
5.5.1.3 RP–ACK layout
– Ref : GSM 04.11 table 7.5 & figure 8.4, in line with GSM 03.40. and GSM phase 2 04.11 §7.3.3, in
line with GSM 03.40.

RP–Ack – Message type indicator M M

– Message reference M M
MS–––>RCF
(M) means Mandatory

(O) means Optional
Figure 45. RP–Ack message layout
5.5.1.4 Specific defense treatments upon RP–layer
97VFT100000348VRM1
– Any additional IE not described in the RP messages shall be ignored.
– RP layer protocol; unknown or unforeseen message reference
The RP entity within the MSC shall ignore any RP message whose Message Reference is missing
or not associated with active short message transfer. The CP–DATA message carrying the RPDU
shall be acknowledged by a CP–ACK.
– RP layer protocol; unknown or unforeseen message type
The RP entity within the MSC shall ignore any RP Message whose RP message Type is missing or
not corresponding to ms–>n message type. It shall also ignore any RP message outside the specified
sequence. The CP–DATA message carrying the RPDU shall be acknowledged by a CP–ACK.
– RP layer protocol; Non–semantical mandatory IE errors
In the case of an invalid RPDU (RP–ERROR with a missing RP–cause IE) the MSC shall acknowl-
edge it by a CP–ACK. The MSC shall also return a ForwardShortMessage error with ”SMdeliveryfai-
lure(protocol error)”.
5.5.2 CP–ACK
This message is sent to acknowledge a CP–DATA message : it is sent either by the MS (via the BSS) to
the RCF or by the RCF (via the BSS) to the MS.

GSM phase 2 04.11 §7.2.2
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 68 / 135
135
CP–ACK – Protocol discriminator M M


MS<––>RCF
(M) means Mandatory

(O) means Optional
Figure 46. CP–ACK message layout
5.5.3 CP–ERROR
This message is sent by the RCF to the MS or by the MS to the RCF to report invalid CP–DATA content.

GSM phase 2 04.11 §7.2.3
CP–ERROR – Protocol discriminator M M

– CP–cause (1) M M
MS<–––RCF
MS–––>RCF
(M) means Mandatory

(O) means Optional
Figure 47. CP–ERROR message layout
– (1) : the possible causes are indicated in GSM phase 1 04.11 table 8.2 and GSM phase 2 04.11
§8.1.4.2
5.5.4 Specific defense treatments upon DTAP protocol (CP–layer)
Refer to < [17] page 6>.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 69 / 135
135
5.6 MIRSMRSM : Interface inside the RCF in the VMSC
5.6.1 MI_DBL_STR_RES
This message is sent by an SMT transaction in RCF which has finished to transfer a Short Message to
the MS, to an other SMT transaction in RCF which is awaiting to forward a Short Message to the same
MS.
– Type of interface : Internal message
– Ref : None
– Information exchanged on the interface : None.
5.6.2 MI_DBL_STR_ERR
This message is sent by an SMT transaction in RCF which has not transfered with success a Short Mes-
sage (CP–ERROR, RP–ERROR or CLEAR REQUEST received from the MS) to an other SMT transaction
in RCF which is awaiting to forward a Short Message to the same MS.
– Type of interface : Internal message
– Ref : None
– Information exchanged on the interface : None.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 70 / 135
135
6 INTERFACE WITH OTHER FUNCTIONS
6.1 Security Interface

6.1.1 Between VLR and HLR
6.1.1.1 NoteSubscriberPresent (phase 1)
The message NotesubscriberPresent is sent by the VLR (SC function) to the HLR (SMT function) when
the MS is again reachable.
– Identity of the interface : MIVSCHSM
Note Subscriber Present – imsi M

(Invoke)
MI–MS–P–I
VLR–––>HLR
6.1.1.2 ReadyForSM (phase 2)
The message ReadyForSM is sent by the VLR (SC function) to the HLR (SMT function) when the MS is
again reachable.
– Identity of the interface : MIVSCHSM
– Ref : GSM phase 2 09.02 §14.6.5

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 71 / 135
135
ReadyForSM – imsi M
(Invoke) – alertReason (1) M

(ms–Present
MI–R–F–SM–I (memoryAvailable
VLR–––>HLR
ReadyForSM – DataMissing
(Error) – UnexpectedDataValue
– FacilityNotSupported (2)
MI–R–F–SM–E – UnknownSubscriber (3)
HLR–––>VLR
ReadyForSM
(Result) none
MI–R–F–SM–R
HLR–––>VLR
(M) means Mandatory

(O) means Optional
Figure 48. ReadyForSM (VLR–>HLR) message layout
Notes:
– (1) : Use of ms–present by SC and LR function in VLR, use of memory available by SMO function
in VLR.
– (2) : If the HLR does not support the MNRF,MCEF and MWD feature. Never sent by our HLR.
– (3) : If the IMSI is unknown at HLR.
6.1.1.2.1 Protocol fallback
For ms–present alert reason, NoteSubscriberPresent is used instead of ReadyForSM if the HLR supports
MAP V1 only.
For memoryavailable alert reason, a facility not supported error is returned to RCF by the VLR.
6.1.2 Within VLR
This interface is used by SMT function to ask SC (Security) function for authentication procedures after
a successful paging.
– Identity of the interface : MIVSMVSC
– Type of interface : internal to VLR
– Information exchanged on the interface : see [7] page 6.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 72 / 135
135
6.1.3 Within RCF
This interface is used by SC function to provide the result of the IMEI check to continue short message
service establishment.
– Identity of the interface : MIRSMRSC
– Type of interface : internal to RCF
6.2 LOCATION REGISTRATION INTERFACE
6.2.1 Within HLR
This interface is used by LR function to inform SMT function that the MS is again reachable.
– Identity of the interface : MIHLRHSM
– Type of interface : internal to HLR
Note MS present – IMSI (M)
MI–MS–PRESENT
(M) means Mandatory

(O) means Optional
Figure 49. Note MS–present (HLR LR–>HLR SMT) message layout
6.2.2 Between VLR and RCF
This interface is used by LR function to inform SMT function that the ForwardCheckSS Indication has to
be forwarded to the MS.
– Identity of the interface : MIRSMVLR
– Type of interface : Internal
– Ref : No GSM reference

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 73 / 135
135
6.2.3 Between VLR and HLR
The message ReadyForSM (phase 2) or NoteSubscriberPresent (phase 1) is sent by the VLR (LR func-
tion) to the HLR (SMT function) when the MS is again reachable.
– Identity of the interface : MIVLRHSM
– Ref : GSM phase 1 09.02 fig.6.2/13 (Sheet 2 of 2)

GSM phase 2 09.02 §14.6.5
– Information exchanged on the interface : see < 6.1.1 page 71>
6.3 Short message originating
The message ReadyForSM is sent by the VLR (SMO function) to the HLR (SMT function) when the MS
indicates memory available situation (only phase 2 feature).
– Identity of the interface : MIVMOHSM
– Ref : GSM phase 2 09.02 §14.6.5
– Information exchanged on the interface : see < 6.1.1 page 71>
6.4 Paging Interface
6.4.1 Within VLR
This interface allows SMT function to ask PA (Paging) function for establishment of the radio contact with
the called MS.
– Identity of the interface : MIVSMVPA
– Type of interface : internal to VLR
6.4.2 Within RCF
This interface is used by the SMT function to inform the PA function that the call is released so that the
PA function can terminate its processing without waiting for a timer expiry.
– Identity of the interface : MIRSMRPA

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 74 / 135
135
6.5 Call Barring Interface
This interface is used in HLR by SMT function to ask CB (Call barring) function for call barring checking.
– Identity of the interface : MIHSMHCB

– Type of interface : internal to HLR
6.6 Radio Resource Management Interface
This interface is used by SMT function to ask the Radio Resource Management (RM) function for release
of the channel used for the call.
The interface is also used by RM to indicate to SMT that the channel allocated for short message purpose
has to be released or that the SAPI 3 has not been established at the radio side. SMT has to release its
resources and to ask RM for channel release.
– Identity of the interface : MIRSMRRM
6.7 Charging Data Collection Interface
This interface is used by SMT function in the RCF: for billing purpose at the successful completion of a
SMS terminating call procedure, charging tickets have to be generated by the GMSC and by the MSC as
well.
– Identity of the interface : MIRSMRCG
6.8 Observation Interface
The purpose of this interface is to take into account the main events during a short message service termi-
nating call.
The counters incremented during a SMS terminating call are listed in [11] page 6.
6.9 Supplementary Service Handling interface

1AA 00014 0004 (9007) A4 – ALICE 04.10
The message MI_FCSS_SH_REQ is sent by SMT function to ask SH function in the RCP to open an inde-
pendant SS transaction with the mobile in order to forward the ”ForwardCheckSSIndication”.
– Identity of the interface : MIRSHRSM
ED 04
CIT AAC020298400DS En 75 / 135
135

– Information exchanged on the interface : see [14] page 6

6.10 MM interface
This interface is used to inform the other activities of the same mobile that the MM procedures for SMS
are ended.
Refer to [6] page 6.
– Identity of the interface : MIRMMRMM
– Messages exchanged on the interface :

• MI_DBL_STR_RES
• MI_DBL_STR_ERR
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 76 / 135
135
7 SPONTANEOUS MESSAGES TO OPERATOR
Spontaneous messages are issued to the operator if SMT function detects, during its operation, an illegal
or erroneous event.
– Spontaneous messages in RCF
• WR_SM_300
wording CALLED NUMBER/SCCP ROUTE TRANSLATION FAILURE
CLDLEN= CLDNBR=
meaning This warning is edited when the analysis of the called number to de-
termine the SCCP route informations has failed (No SCCP route from
MSISDN number or from MSC address or from SC address).
parameters CLDLEN = Called number length
CLDNBR = Called number
• WR_SM_302
wording LMSI NOT PROVIDED IN FORWARD SHORT MESSAGE
meaning This warning is edited when the LMSI is not provided in ”Forward-
ShortMessage” operation. The transfer is performed with the pro-
vided IMSI.
parameters IMSI of the subscriber = IMSI
– Spontaneous messages in HLR
• WR_SM_301
wording TRANSLATION ERROR CALLED NUMBER / SCCP ROUTE
meaning This warning is edited when it is impossible to find SCCP route of the
IWMSC.
parameters MSCADD = IWMSV address
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 77 / 135
135
8 ERROR GENERATED BY SMT FUNCTION
8.1 Definition of Internal errors generated by SM in HLR

– ERR_SM_100
Data Missing in the MI_S_RGI_SM_I (MAP ”Send Routing Info for SM”) message.
– ERR_SM_101
Unexpected Data Value in the MI_S_RGI_SM_I message
– ERR_SM_102
Data Missing in the MI_S_MW_I (MAP ”Set message waiting data”) message or MI_R_SMD_S_I
(MAP ”Report SM Delivery Status”) message
– ERR_SM_103
Short Message Terminating function is not supported in VMSC
– ERR_SM_104
Unexpected Data Value in the MI_S_MW_I message or MI_R_SMD_S_I message
– ERR_SM_105
AbsentSubscriber due to MNRF set and non priority message
– ERR_SM_106
Data missing in MI_R_F_SM_I (MAP ”Ready for SM”) message
– ERR_SM_107
Unexpected data value in MI_R_F_SM_I message
– ERR_SM_108
Unknown IMSI received in MI_R_F_SM_I message
– ERR_SM_109
A MI_S_RGI_SM_I message has been received from an entity which does not belong to HPLMN
– ERR_SM_110
Unknown MSISDN received in MI_S_RGI_SM_I message
– ERR_SM_111
Teleservice not provisioned to the MS.
– ERR_SM_112
MWD list full.
– ERR_SM_113
MS barred due to Operator Determined Barring
– ERR_SM_114
Incoming call barring applicable.
– ERR_SM_115
Spare.
1AA 00014 0004 (9007) A4 – ALICE 04.10
– ERR_SM_116
No MSC address in the subscriber data, or MS not allowed to roam.
– ERR_SM_117
ED 04
CIT AAC020298400DS En 78 / 135
135
Unknown MSISDN received in MI_S_MW_I message or MI_R_SMD_S_I message
8.2 Definition of Internal Errors generated by SM in VLR

– ERR_SM_200
Spare.
– ERR_SM_201
Spare.
– ERR_SM_202
Unidentified subscriber.
– ERR_SM_203
AbsentSubscriber.
8.3 Definition of internal errors generated by SM in RCF
– ERR_SM_300 (GMSC)
RP_Originator Address or RP_Destination Address are not correct in RP_MT_DATA message.
– ERR_SM_301 (VMSC)
Unidentified subscriber (IMSI not received in RP_DA) in phase 1 dialogue with GMSC.
USI syntactically incorrect in TC_BEGIN
– ERR_SM_303 (GSMC)
Unexpected data value in the S_RGI_SM_R.
T_smr, timer on S_RGI_SM opration, expiry.
Abort Indication (RCF_HLR Transaction).
Destination reference of USI is not an IMSI address
CP_Userdata IE missing or not matching its length in CP_Data
Timer TC1N expiry.
Timer TR1N expiry.
Impossible translation of the MSISDN into SCCP route.
1AA 00014 0004 (9007) A4 – ALICE 04.10
Impossible translation of the MSC address into SCCP route.
Abort Indication (RCF_VLR transaction).
ED 04
CIT AAC020298400DS En 79 / 135
135
– ERR_SM_313 (GMSC) (VMSC)
Short Message Terminating function not supported in the MSC.
Unexpected data value or SC address too long in the MI_F_SM_I message.

– ERR_SM_315 (GMSC) (VMSC)

Abort Indication (RCF_RCF transaction).
T–fsm, timer on F_SM operation, expiry.
Lack of IMSI in ForwardShortMessage.
T–mwd, timer on S_MW operation, expiry.
T–sism, timer on SINF_SMT operation, expiry.
Map error ”SM–DeliveryFailure”, with parameter value ”memory capacity exceeded”, received in
MI_F_SM_E message.
Map error ”SM–DeliveryFailure”, with parameter value ”MS protocol error”, received in MI_F_SM_E
message.
Map error ”SM–DeliveryFailure”, with parameter value ”MS not equipped”, received in MI_F_SM_E
message.
A subsequent RP_MT_Data has been received for a subscriber different from the first.
A subsequent RP_MT_Data has been received when an other is already being treated.
A subsequent RP_MT_Data has been received with priority low and MWD is set.
– ERR_SM_326 (IWMSC)
Unexpected data value in MI_A_SC_I message
– ERR_SM_327 (IWMSC)
Impossible translation of the SC address into SCCP route
RP User data is too long to be carried by the MAP
IMSI received in USI and LMSI not present in FSM message
1AA 00014 0004 (9007) A4 – ALICE 04.10
Default error due to lack of RP–Cause in RP–Error or CP–Cause in CP–Error
ED 04
CIT AAC020298400DS En 80 / 135
135
Max number of transaction waiting at VMSC reached
Memory capacity exceeded not reported to HLR in ReportSMDelivery message due to MAP v1 dia-
logue with HLR

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 81 / 135
135
9 TIMERS
9.1 Timer in RCF

9.1.1 SMS–GMSC
T_SCRLS Supervises at GMSC the release of the SCCP connection or the receipt of
another awaited short message from the SC.
PLMN data
Range : 15s ––> 60s
Default value = 60 s.
T_smr Supervises MAP ”SendRoutingInfoForSM” operation

System parameter
Value = refer to < [19] page 6>.
T_fsm Supervises MAP ”ForwardShortMessage” operation

System parameter
T_mwd Supervises MAP ”SetMessageWaitingData” or ”ReportSMDeliveryStatus” op-

eration
System parameter
9.1.2 VMSC
TC1N Supervises the reception of CP–ACK message from the MS.

PLMN data
Range : 2s ––> 30s
Default value : 20 s for SACCH and SDCCH.
TR1N Supervises the reception of RP–ACK message from the MS.

PLMN data
Range : 2s ––> 60s with constraint : 2TC1N + 5 = TR1N
Defaut value : 45 s
T_SUBSEQ Supervises the reception of subsequent short message in the same TCAP dia-
logue.
PLMN data
Range: 15s ––> 60s
Default value = 20s
T_BEFORE_REL Delay for sending a Channel release (to ensure the BSS is able to send its last
DTAP message).
PLMN data
Range: 100ms ––> 2s
Default value = 200ms
T_CONT Supervises the receipt of a TC_CONT from the SMS–GMSC after an empty
1AA 00014 0004 (9007) A4 – ALICE 04.10
TC_BEGIN.
system parameter
Default value = 10s
ED 04
CIT AAC020298400DS En 82 / 135
135
9.1.3 IWMSC
T_WAIT_SSCS Activated when sending RP–Alert to the SC

See < [15] page 6> for the value.
9.2 Timer in VLR
None
9.3 Timer in HLR
T_asc Supervises MAP ”AlertServiceCenter” operation

System parameter
T_MWD Watch dog timer for the duration of a SC address in the MWD file.
PLMN data
Range: maximum 10 days, be aware of impacts on the storage capacity of MWD
file.
Default value = 24 hours.
T_WAIT_SSCS Activated when sending MI_A_SC_WR (AlertServiceCenterWithoutResult)

phase 1 only message to the IWMSC.
See < [15] page 6> for the value.
T_RACE Triggered by the HLR if an Alert procedure is requested and neither MCEF nor
MNRF are set, to prevent a race situation with a successful transfer.
System parameter
Value = 5s
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 83 / 135
135
1AA 00014 0004 (9007) A4 – ALICE 04.10 not permitted without written authorization from Alcatel.
ED
CIT
04
10 SDL DIAGRAMS HLR
135
AAC020298400DS
En
84 / 135
ED
CIT
04
135
AAC020298400DS
En
85 / 135
ED
CIT
04
135
AAC020298400DS
En
86 / 135
ED
CIT
04
135
AAC020298400DS
En
87 / 135
ED
CIT
04
135
AAC020298400DS
En
88 / 135
ED
CIT
04
135
AAC020298400DS
En
89 / 135
ED
CIT
04
135
AAC020298400DS
En
90 / 135
ED
CIT
04
135
AAC020298400DS
En
91 / 135
ED
CIT
04
135
AAC020298400DS
En
92 / 135
ED
CIT
04
135
AAC020298400DS
En
93 / 135
ED
CIT
04
135
AAC020298400DS
En
94 / 135
ED
CIT
04
135
AAC020298400DS
En
95 / 135
ED
CIT
04
135
AAC020298400DS
En
96 / 135
ED
CIT
04
135
AAC020298400DS
En
97 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
11 SDL DIAGRAMS VLR
135
AAC020298400DS
En
98 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
99 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
100 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
101 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
12 SDL DIAGRAMS RCF
135
AAC020298400DS
En
102 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
103 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
104 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
105 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
106 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
107 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
108 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
109 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
110 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
111 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
112 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
113 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
114 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
115 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
116 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
117 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
118 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
119 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
120 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
121 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
122 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
123 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
124 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
125 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
126 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
127 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
128 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
129 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
130 / 135
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
04
135
AAC020298400DS
En
131 / 135
ANNEXE A OVERVIEW OF PROTOCOLS USED IN SMS–MT
A.1 Network structure

SC
PLMN
link 3
SMS– link 6
GMSC MSC MS
link 1
IWF–SMS link 2 link 5
SMS– link 2 link 4

IWMSC HLR VLR
link 1
A.2 Transfer protocols
A.2.1 Simplified protocol layer overview

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 132 / 135
135
SMS–GMSC
SC SMS–IWMSC MSC MS
SM–AL
Appli SMS–
SM–TL
Transf RS– MAP– SM–RL–
SM–RL RP–MT– RP– SMR entity

Relay N TC MNSMS–
(SMSAP) (MAP E)
SM–LL CP– CM sublayer
Layer 3 MMSMS– SMC entity
(SCCP) (TCAP) (DTAP)
(SCCP) (SCCP) MM sublayer
RR sublayer
Layer 2
TPDU at SM–TL :
(1) SMS–DELIVER conveying a SM from SC to MS
(1) SMS–STATUS–REPORT conveying a status report from SC to MS
SMS–DELIVER–REPORT (if necessary)
(2) SMS–SUBMIT conveying a SM from MS to SC
(2) SMS–COMMAND conveying a command from MS to SC
SMS–SUBMIT–REPORT (if necessary)
(1) Use of short message terminating procedure
(2) Use of short message Originating procedure
A.2.2 SC/PLMN
Refer to Link 1.
No mandatory protocol between the Service Centre and the PLMN is specified by GSM. The protocol used
is an Alcatel generic implementation which uses the Signalling Connection Control Part (SCCP) of CCITT
no 7.
The sub–system user of SCCP for SMS is called SMSAP.
See < [4] page 6>.
– RP–MT–Data: for transferring a ”SMS–Deliver” or ”SMS–Status–report” from SC to MS,
– RP–MT–Ack: for acknowledging an RP–MT–Data,
– RP–MT–Error: for informing of an unsuccessful RP–MT–Data transfer attempt. The RP–MSISDN
parameter of RP–MT–Error can give the MS–ISDN Alert to be used by the SC.
– RP–Alert: for alerting the SC that the MS has recovered operation
A.2.3 SMS–GMSC/HLR and HLR/SMS–IWMSC
Refer to Link 2.
1AA 00014 0004 (9007) A4 – ALICE 04.10
MAP is used.
MAP messages used to obtain routing information:
ED 04
CIT AAC020298400DS En 133 / 135
135
– Send routing information for short message (from SMS–GMSC to HLR).
– Short message routing information or an error message (result sent by HLR to SMS–GMSC).
In phase 2 MAP dialogue, HLR may, if necessary, send to the SMS–GMSC the MS–ISDN Alert of the MS
and the state of MWI in

– Inform Service Center message
In case of phase 1 MAP dialogue between SMS–GMSC and HLR, MAP messages used to request inclu-
sion of a Service Centre address in the Message Waiting Data in the HLR:
– Set message waiting data (from SMS–GMSC to HLR).
– Set message waiting data ack or an error message (result sent by HLR to SMS–GMSC).
In case of phase 2 MAP dialogue between SMS–GMSC and HLR, MAP messages used to report the SM
delivery status to the HLR
– Report SM delivery status (from SMS–GMSC to HLR).
– Report SM delivery status ack or an error message (result sent by HLR to SMS–GMSC).
If necessary, the HLR, on recept of this message set the Service Center address in the Message Waiting
Data.
The MAP message: ”Alert Service Centre” (phase 2) or ”Alert Service Centre Without Result” (phase 1)
is used by the HLR to request a SMS–IWMSC to inform a Service Centre that
– the MS is again available or
– the MS has again available memory or
– a Short message has been successfuly delivered to the MS
A.2.4 SMS–GMSC/MSC
Refer to Link 3.
MAP is used.
The MAP message ”Forward short message” is used by the SMS–GMSC to request the servicing MSC
to forward a short message to the MS.
The MSC sends back a forwarding acknowledge message if the short message has been successfully
delivered to the MS, otherwise an error message (absent subscriber, system failure, ...) is sent back to
the SMS–GMSC.
A.2.5 VLR/HLR
Refer to Link 4.
MAP is used.
In case of phase 1 MAP dialogue between VLR and HLR, the MAP message: ”Note subscriber present”
is used by a VLR to inform the HLR that the MS may be reachable again.
In case of phase 2 MAP dialogue between VLR and HLR, the MAP message: ”Ready for SM” is used by
a VLR to inform the HLR that the MS may be reachable again or the MS has available memory.
A.2.6 MSC/VLR
1AA 00014 0004 (9007) A4 – ALICE 04.10
Refer to Link 5.
The MSC uses the message ”Send information for short message” to retrieve subscriber information from
VLR.
ED 04
CIT AAC020298400DS En 134 / 135
135
The message ”Complete call” is used by the VLR to request the MSC to transfer the short message to the
MS.
The message ”Ready for SM” is used by the MSC, when a subscriber indicates memory available situa-
tion, to request VLR to initiate an Alert procedure.
A.2.7 MSC/MS
Refer to Link 6.
BSSAP is used.
– Direct Transfer Application Part (DTAP):

CP–messages are DTAP messages used to transfer on the Air Interface SMS data between the MSC
and the MS.
In these messages the Data Link Connection Identification (DLCI) parameter indicates the SAPI val-
ue 3 (reserved to SMS).
CP–messages during a short message transfer procedure :

• CP–Data :
– From MSC to MS contains a RP–DATA (contains itself a SMS–DELIVER or a SMS–STA-
TUS–REPORT)
– From MS to MSC contains a RP–ACK or a RP–ERROR (response of the RP–DATA)
The RP–ERROR may contains itself a SMS–DELIVER–REPORT to be forwarded from
MS to SC.
• CP–Ack : acknowledge of the CP–Data
• CP–Error
CP–messages when the MS indicates that memory capacity is again available :

• CP–Data :
– From MS to MSC contains a RP–SMMA (SM Memory Available)
– From MSC to MS contains a RP–ACK or a RP–ERROR (response of the RP–SMMA)
• CP–Ack : acknowledge of the CP–Data
• CP–Error
– Base Station System Management Application Part (BSSMAP):

• The SAPI 3 establishment is initiated by the BSC itself for the first transfer request from the MSC
(CP–Data).
• SAPI ”N” Reject message is sent by the BSC when the BSS is not able to send the short mes-
sage (BSS not equipped, MS not equipped, processor overload, O&M intervention).
FIN DE DOCUMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 04
CIT AAC020298400DS En 135 / 135
135

Smsdetails En-RL PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Smsdetails En-RL PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

FUNCTIONAL SPECIFICATION

not permitted without written authorization from Alcatel.

LIST OF FIGURES AND TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 DETAILED DESCRIPTION AND SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

01 9608 DSR Y.MARTY

ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

SHORT MESSAGE SERVICE TERMINATING

CIT AAC020298400DS En 1 / 135

4 CONSEQUENCES OF V1 AND V2 MAP APPLICATION CONTEXTS MIX BETWEEN PLMN ENTI-

4.1 Restrictions of feature induced by use of v1 context: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Consequences of v1 and v2 Application Context mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 INTERFACES WITHIN THE FUNCTION SHORT MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 INTERFACE WITH OTHER FUNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 SPONTANEOUS MESSAGES TO OPERATOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8 ERROR GENERATED BY SMT FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

CIT AAC020298400DS En 2 / 135

10 SDL DIAGRAMS HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

11 SDL DIAGRAMS VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

12 SDL DIAGRAMS RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

ANNEXE A OVERVIEW OF PROTOCOLS USED IN SMS–MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

CIT AAC020298400DS En 3 / 135

Figure 1. Functional environment of the Short Message terminating function . . . . . . . . . . . . . . . . . . 8

Figure 3. SMS connection set–up (2/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 4. SMS connection set–up (3/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 48. ReadyForSM (VLR–>HLR) message layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

CIT AAC020298400DS En 4 / 135

[1] AAC020298400DT – Mobile Terminating point to point SMS

[2] AAC030546400DT – Mobile Originating point to point SMS

[3] AAC030546400DS – Mobile Originating point to point SMS

[4] AAC030205400DS – SMSAP MSC – SC protocol for SMS

[5] AAC020006400DS – Terminating call

[6] AAC020003400DS – Paging

[7] AAC020010400DS – Security

[8] AAC020015400DS – Radio Resource Management

[9] AAC020097400DS – Internal and external Error Mapping

[10] AAC020004400DS – Location Registration

[11] AAC020023400DS – Observations

[12] AAC020018400DS – Call Barring

[13] AAC020017400DS – Charging Data Collection

[14] AAC020030400DS – Supplementary Service Handling

[15] AAC020016400DS – Traduction

[16] AAC020754400DS – Version handling

[17] AAC020031400DS – Defence of PLMN

[18] AAC030508400DS – Operator Determined Barring

[21] Functional Options List (note 1)

Note 1 : One document per customer

– BSSAP Base Station System Application Part

– HLR SMT HLR Short Message terminating Function

CIT AAC020298400DS En 6 / 135

– MSC Mobile Services Switching Center

– RCF Radio Control Function

CIT AAC020298400DS En 7 / 135

1.1 Options list in FS Short Message Terminating

F–SMS–001 Addressing mode of SMS IWMSC

F–SMS–005 Special use of SRI for SM as MSC number inquiry

CIT AAC020298400DS En 8 / 135

BSS RCF Service Center

SMT SMT SMT

Figure 1. Functional environment of the Short Message terminating function

CIT AAC020298400DS En 9 / 135

2.1 Subscriber data related to SMS–MT and Flags definition

b) As part of Messages–Waiting–Indication (MWI), the Messages–Waiting–Data (MWD) is stored in the

c) As part of Messages–Waiting–Indication (MWI), the Mobile–Station–Not–Reachable–Flag (MNRF)