SMS Call flow , GSM , SMSC call flow, SMSCG detail
February 16, 2017 | Author: Khushwant Negi | Category: N/A
Short Description
Download SMS Call flow , GSM , SMSC call flow, SMSCG detail...
Description
MSCDOCM13 M13.0 Product Documentation
SMS Guide
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
1 (267)
SMS Guide
The information in this documentation is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia's customers only for the purposes of the agreement under which the documentation is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the documentation are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the documentation. Nokia's liability for any errors in the documentation is limited to the documentary correction of errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this documentation or the information in it. This documentation and the product it describes are considered protected by copyright according to the applicable laws. NOKIA logo is a registered trademark of Nokia Corporation. Other product names mentioned in this documentation may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright © Nokia Corporation 2005. All rights reserved.
2 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Contents
Contents Contents 3 List of tables 6 List of figures 7 Summary of changes 11 1 1.1 1.2 1.3 1.3.1 1.3.2 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.5 1.6 1.6.1 1.6.2 1.7 1.8 1.9 1.10 1.11 1.12 1.12.1 1.12.2 1.12.3 1.12.4 1.13 1.14 1.14.1 1.14.2 1.14.3 1.15 1.15.1 1.15.2 1.16 1.17 1.17.1 1.17.2 1.17.3 1.18
dn98905102 Issue 5-0 en
Short Message Services 15 Short Message Services Overview 17 SMS information elements 18 Mobile-originating short message 21 MO-SM procedure 22 Unsuccessful MO-SM delivery 24 Mobile-terminating short message 24 MT-SMS procedure 25 Unsuccessful MT-SM delivery 27 More-messages-to-send 30 Command SM and MO-SM with Status Report request 30 SMSC Alert 34 SMS load sharing 36 SMRSE over X.25 36 SMRSE over TCP/IP 38 Barring SMS in the MSC 41 Welcome SM to the roamer 46 Real Time triggering 47 Incoming Call Treatment 50 Missed Calls Log Service 51 Short Message Service on GPRS 52 SMS over GPRS with MAP version 2 53 SMS over GPRS with MAP version 3 54 Comparative example of SMS over GPRS with MAP version 2 and MAP version 3 59 GPRS with SMSC-MSC connection through MAP interface 62 IN Short Message functionality 63 CAMEL short message service 65 Control of MO-SM with CAMEL 66 Control of MT-SM with CAMEL 71 Interworking between CAMEL SM and IN SM 75 Short message routing 76 SMS routing enhancements 80 Short message routing based on subscriber type 81 Sending SMS without SMSC 82 SMS Forwarding 87 Basic forwarded MT-SMS 87 Provisioning and activating SMS forwarding 89 MMI procedures to activate SMS forwarding 89 Same CLI for multiple subscribers 89
# Nokia Corporation Nokia Proprietary and Confidential
3 (267)
SMS Guide
4 (267)
1.19 1.19.1 1.19.2 1.20 1.20.1 1.20.2 1.20.3 1.20.4 1.20.5 1.20.6 1.21 1.21.1 1.21.2 1.22 1.22.1 1.22.2 1.22.3 1.22.3.1 1.22.3.2 1.22.4 1.22.5 1.22.6 1.22.7 1.23 1.23.1 1.23.2 1.23.3 1.24
Sequential alerting and parallel alerting for MultiSIM Service 90 Delivery of mobile-terminating short messages 91 MT-SMS routing to the primary member 91 Short message charging 91 SMS charging for subscribers 95 Charging of SMs generated by applications 97 Charging of SMs to service applications 98 Charging of CAMEL SMs 99 MO-SM fraud prevention 100 Mobile number portability solutions for MO-SM charging 100 SMS-related statistics 101 SMS statistics in the MSC 102 SMS statistics in the HLR 107 Network elements involved in SMS 108 SME 109 SMSC 109 VMSC and VLR 110 VMSC and VLR in MO-SM procedure 110 VMSC and VLR in MT-SM procedure 113 SMS-IWMSC 117 SMS-GMSC 117 HLR 118 Traffica 120 Interfaces between SMS network elements 121 A interface in SMS 122 SMRSE in SMS 122 MAP in SMS 125 Subscriber interface of SMS 128
2 2.1 2.1.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.4 2.4.1 2.5
Configuring network elements for SMS 131 Configuring MAP interface for SMS 132 Creating global title analysis 133 Configuring X.25 interface for SMS 138 Connecting the SMSC to the SMS-GMSC/SMS-IWMSC 138 Creating analysis on SMS application level in the MSC 148 Setting parameters so that GSM phase 2+ and MT-SM are supported 151 Configuring TCP/IP connection for SMS 153 Connecting the SMSC to the SMS-GMSC/SMS-IWMSC 153 Creating analysis on SMS application level in the MSC 155 Setting parameters so that GSM phase 2+ and MT-SM are supported 156 Handling SMS-related MAP operations in MSC and HLR 158 Handling Error counters in SMS 160 Handling the Welcome SM related parameters 161
3
Managing SMS subscriber-specific data 165
4 4.1 4.2 4.3 4.4
Managing SMS network element-specific data 171 Handling User Data in SMS 171 Handling of MNRR in SMS 172 Activating selective CDR generation in SMS 173 Activating Picture message information in the CDR 175
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Contents
4.5 4.5.1 4.5.2 4.6 4.7
Preventing SMS 175 Preventing MT-SMS 176 Preventing MO-SM 177 Activating SMS measurement 179 Activating routing enhancement in SMS
5 5.1 5.2 5.3 5.4 5.5 5.6
Activating Nokia-specific SMS features 183 PNP numbering for SMS (MO) 183 Handling of IN SMS 185 Activating Real Time triggering 186 Activating MT-SM for Camel Phase 4 189 Activating Direct SM delivery 189 Activating B-IMSI retrieval in MO-side for MNP 190
6 6.1
Working examples for SMS management 191 Configuring network elements for short message services with load sharing 191 Configuring network elements for short message services with more MSCs connected to the same SMSC 200 Configuring network elements for SMS with load sharing of SMSC clusters when the traffic category is normal traffic 208
6.2 6.3
181
7 7.1 7.2 7.3 7.4
Short Message Service Troubleshooting 229 Problems related to SMS network elements 229 Problems related to SMS A interface 230 SMS problems related to SMRSE interface 232 Problems related to SMS charging 236
8 8.1 8.2 8.3
Additional information on SMS 239 MT operation in VMSC 239 SMS procedures performed by MAP 245 Comparison of the SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC 251 Functional differences between SMRSE over X.25 or TCP/IP and SS7 MAP SMSC 253 Functions of SMSC level in SMS 256 Alarms and their meanings in Short Message Service 257 SMS-related general parameter file (PRFILE/FIFILE) parameters 260 Parameters needed for CAMEL SM 264 Parameters for SMS A-interface configuration 265 Parameters needed for Sending SMS without SMSC 266 FIFILE parameter 266 PRFILE parameters 266
8.3.1 8.4 8.5 8.6 8.7 8.8 8.9 8.9.1 8.9.2
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
5 (267)
SMS Guide
List of tables Table 1.
Short Message Services overview
17
Table 2.
MNRR reason codes
Table 3.
Distribution of number range in available SMSCs
Table 4.
Error codes in MT-SMS barring
Table 5.
Events, criteria and types of control
Table 6.
DPs used for the MO SMS State Model
Table 7.
DPs used for the MT-SMS state model
Table 8.
Example of a routing table
Table 9.
Types of CDR and network elements
28 37
44 48 67 73
78 95
Table 10. Clear codes involved in SMS measurement counter update Table 11. Explanation of bytes in UTPFIL records
6 (267)
# Nokia Corporation Nokia Proprietary and Confidential
104
199
dn98905102 Issue 5-0 en
List of figures
List of figures Figure 1.
Basic Short Message Service procedure
Figure 2.
Key characteristics of Short Message Service
Figure 3.
MO-SM successful case
Figure 4.
MO-Forward SMS procedure
Figure 5.
MT-SM successful case
Figure 6.
MT-Forward-SMS procedure
Figure 7.
SMS command and status report
Figure 8.
Successful MO-SM transfer with SMSC-GT-1 parameter
Figure 9.
Successful MT-SM transfer with the SMSC-GT-1 parameter
Figure 10. SMSC alerting
15 16
21 23
25 26 31 33 34
35
Figure 11. SMS load sharing
37
Figure 12. The use of MO-SMS Limiter in load sharing
40
Figure 13. MO-SMS barring configured to the VMSC, case 1
42
Figure 14. MO-SMS barring configured to the VMSC, case 2
43
Figure 15. MO-SMS barring configured to the IWMSC, case 1
43
Figure 16. MO-SMS barring configured to the IWMSC, case 2
44
Figure 17. MT-SMS barring, Case 1
45
Figure 18. MT-SMS barring, Case 2
46
Figure 19. Operation of Real Time triggering
48
Figure 20. Overview of involved network elements
53
Figure 21. Mobile-terminating short message delivery, MS detached for GPRS Figure 22. Sending SMs over GPRS Figure 23. SMS over MAP interface
55
60 62
Figure 24. Functional architecture for the support of CAMEL control of MSC-switched MO SMS 66 Figure 25. MO SMS state model
67
Figure 26. CAMEL mobile-originating short message
68
Figure 27. CAMEL mobile-originating short message with notification of successful submission to gsmSCF 70
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
7 (267)
SMS Guide
Figure 28. Functional architecture for the support of CAMEL control of MSC-switched MT SMS 72 Figure 29. MT SMS state model
73
Figure 30. CAMEL mobile-terminating short message Figure 31. SMS routing
74
77
Figure 32. SMSC address used in MT-SMS between different network elements 79 Figure 33. Short message routing based on prepaid and post-paid subscribers Figure 34. Successful SM delivery
85
Figure 35. Unsuccessful SM delivery, no paging response Figure 36. Unsuccessful SM delivery, absent subscriber Figure 37. Basic forwarded MT-SMS functionality
86 86
87
Figure 38. Charging of SMs generated by applications Figure 39. MO-SMS request
98
111
Figure 40. MO-SMS successful case (positive response)
112
Figure 41. MO-SMS unsuccessful case (negative response) Figure 42. MT-SMS request
113
114
Figure 43. MT-SMS successful case (positive response)
115
Figure 44. MT-SMS unsuccessful case (negative response) Figure 45. Network elements involved in SMS Figure 46. OSI protocol stack
81
115
121
123
Figure 47. Protocol stack for SMS with TCP/IP Figure 48. OSI compared to ITU-T No. 7
125
126
Figure 49. MAP-Gd interface in the SMS GSM Phase 2+ network architecture
128
Figure 50. An example for hexadecimal numbers used in alphanumeric addressing 129 Figure 51. An example for alphanumeric addressing from the MS Figure 52. MO-SM interfaces
131
Figure 53. MT-SM interfaces
132
Figure 54. GT analyses in the SMS-GMSC, the result is the HLR
130
134
Figure 55. GT analyses in the SMS-GMSC/SMS-IWMSC, the result is the VMSC 134
8 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
List of figures
Figure 56. GT analyses in the VMSC, the result is SMS-IWMSC
135
Figure 57. GT analyses in the SMS-IWMSC, the result is the SMS-IWMSC Figure 58. GT analyses in the SMS-GMSC, the result is the SMS-GMSC Figure 59. GT analyses in the HLR, the result is the HLR
136
137
Figure 60. GT analyses in the VMSC, the result is the VMSC
138
Figure 61. An example of outputting a subscriber's SMS data
167
Figure 62. Real-life configuration with load sharing
135
192
Figure 63. Real-life configuration with load sharing and more MSCs connected to the same SMSC 201 Figure 64. Real life configuration with load sharing of SMSC clusters Figure 65. MT-SM in the MCS, channel handover, no SM resending
209 240
Figure 66. MT-SM in the MSC, channel handover, SM resending takes place
241
Figure 67. MT-SM in the MSC, channel handover, SM resending takes place
242
Figure 68. MT-SM in the MSC, T1 expires, SM resending takes place Figure 69. MT-SMS and MO-SMS procedures performed by MAP Figure 70. MT-SM sending fails, HLR is notified Figure 71. ReadyForSM and Alert-SC procedures
245
249 251
Figure 72. SMS architecture in case of SMRSE over X.25 or TCP/IP Figure 73. SMS architecture in case of SS7 MAP
243
252
253
Figure 74. Successful MT-SM transfer with two new parameters towards the SMSC 257
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
9 (267)
SMS Guide
10 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Summary of changes
Summary of changes
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues. Changes made between issues 50 and 45
Changes due to feature MT-SM for CAMEL Phase 4 : .
Subsection Control of MT-SM with CAMEL has been added to Section CAMEL short message service . Information on IN MT functionality has been added to Subsection Interworking between CAMEL SM and IN SM .
.
Subsection Activating MT-SM for Camel Phase 4 has been added to Section Activating Nokia-specific SMS features .
.
Parameter CAMEL_ACTIVE has been added to Section Parameters needed for CAMEL SM .
.
Information related to this feature has been added to parameter CAMEL_SUPPORTED_PHASE in Section Parameters needed for CAMEL SM .
Changes made between issues 45 and 44
Changes due to feature Terminal Management Support : .
Information on the additional functionality of Terminal Management Support has been added to Subsection Real Time triggering .
.
NVLAI parameter has been added to Subsection Real Time triggering .
.
Information on the activation and deactivation of the feature has been added to Subsection Real Time triggering .
.
Information on activating Common MSISDN Sending has been added to Subsection Activating Real Time Triggering .
Changes due to feature SMS Routing Based on Subscriber Type : .
Subsection Short message routing based on subscriber type has been added to Section Short Message Routing .
Changes due to feature Supplementary Services Phase 2 Extensions :
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
11 (267)
SMS Guide
.
Section SMS Forwarding has been added to Chapter Short Message Services .
.
Parameter SMS_FORW_IN_HLR has been added to Subsection SMSrelated general parameter file (PRFILE/FIFILE) parameters .
.
Information on new SMS CFU counters has been added to Subsection SMS-related statistics .
Changes due to feature Sequential and Parallel Alerting for MultiSIM Service : .
Section Sequential and Parallel Alerting has been added to Chapter Short Message Services .
Changes due to feature Same CLI for Multiple Subscribers : .
Section Same CLI for Multiple Subscribers has been added to Chapter Short Message Services .
Changes due to feature Missed Calls Log Service : .
Section Missed Calls Log Service has been added to Chapter Short Message Services .
Changes due to feature Incoming Call Treatment : .
Section Incoming Call Treatement has been added to Chapter Short Message Services .
Changes due to feature B-IMSI Retrieval in MO side for MNP : .
Subsection Mobile number portability solutions for MO-SM charging has been added to Section Short Message Charging .
.
Subsection Activating B-IMSI retrieval in MO-side for MNP has been added to Section Activating Nokia-specific SMS features .
.
Parameter B_IMSI_FOR_MO_SM has been added to Subsection SMSrelated general parameter file (PRFILE/FIFILE) parameters .
Changes due to feature Direct SM Delivery :
12 (267)
.
Section Sending SMS without SMSC has been added to Chapter Short Message Services .
.
Subsection Activating Direct SM delivery has been added to Section Activating Nokia-specific SMS features .
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Summary of changes
.
Subsection Parameters needed for Sending SMS without SMSC has been added to Section Additional information on SMS .
.
Information on SMS measurement related to SMs sent without the SMSC has been added to Section SMS-related statistics .
Other changes .
The title VMSC and VLR in SMS has been changed to VMSC and VLR in Chapter Short Message Services .
.
The title HLR in SMS has been changed to HLR in Chapter Short Message Services .
.
The title Traffica in SMS has been changed to Traffica in Chapter Short Message Services .
Changes made between issues 44 and 43
No content changes. Changes made between issues 43 and 41
No content changes.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
13 (267)
SMS Guide
14 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1
Short Message Services The Point-to-Point Short Message Service (SMS-PP) is a basic teleservice used for transferring Short Messages (SMs) between a Short Message Entity (SME ) and a GSM Mobile Station (MS ). A short message is a freely phrased text message with the maximum length of 140 octets. This means 160 characters if a seven-bit coding method is used, but if some other coding method is used, the number of characters is less. For more information, see 3GPP TS 23.038. SMS is very popular since a message can be sent to other subscribers at any time, even when the MS is not reachable.
MO-SM
SME application GSM/PLMN network SMSC
Figure 1.
MT-SM
Basic Short Message Service procedure
There are two different and independent point-to-point services depending on the direction of the SM transfer: .
Mobile-originating Short Message (MO-SM) sent by subscriber A and transported from an MS to an SMSC
.
Mobile-terminating Short Message (MT-SM) transported from an SMSC to an MS and received by subscriber B. This message can be input to the SMSC by other mobile users (through an MOSM) or by a variety of other sources, for example, speech, e-mail, telex, or facsimile.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
15 (267)
SMS Guide
The SMSC is able to send only one MT-SM to a subscriber address (MSISDN ) at a time. The MS is able to receive one MT-SM and send one MO-SM at a time. The figure below describes the key characteristics of SMS.
SMSC Store and forward point Address + message
Interface to other systems Platform for applications
Mobile-terminating: SMSC to mobile Mobile-originating: from MS to SMSC (or to another MS)
SMS-Alert: relay when reachable
Max. 160 characters/message
Figure 2.
Key characteristics of Short Message Service
Main characteristics of SM delivery
The main characteristics of SM delivery are the following: .
The SM delivery to the SMSC is always acknowledged to the sender.
.
A subscriber can send an SM to subscriber B even when subscriber B's MS is switched off or not reachable. If an MT-SM cannot be delivered to the MS because it is absent (for example, IMSI detached), the network stores an indication of absence, and when the MS is active again, the network initiates the Alert SC procedure to inform the SMSC that the subscriber is available again.
16 (267)
.
Short messaging is independent of the voice services: SMs can be sent and received also during voice calls, though it takes more time.
.
There are special sources of SMs:
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
-
-
Voice Mail System (VMS ), which can send voice mail alerts to a subscriber to indicate that voice messages were left in the voice mailbox. In some cases the SMSC can also tell the VMS that the subscriber's MS has become reachable in the GSM network; thus the VMS can make a delivery call to the subscriber. various kinds of terminals connected to the SMSC
Note The topics included in the following sections cover all SMS matters and contain the following features. There are no separate feature activation instructions available for the following features in the current release:
1.1
.
327: Short Message Services
.
412: SMS-SMSC Interface, GMSC/IWMSC
.
476: PNP Numbering for SMS (MO)
.
619: Short Message Service Enhancements
.
620: Short Message Services, GSM Phase 2 Enhancements
.
714: Short Message Service Enhancements
Short Message Services Overview The following topics are covered under Short Message Services:
Table 1.
Short Message Services overview
Short Message Services descriptions and referential material
Short Message Services Instructions
Short Message Services
Configuring network elements for SMS
Additional information on SMS
Managing SMS subscriber-specific data Managing SMS network element-specific data Activating Nokia-specific SMS features Working examples for SMS management Short Message Service troubleshooting
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
17 (267)
SMS Guide
1.2
SMS information elements SMS-related information elements, such as validity period, service centre time stamp, PID, MoreMessagesToSend, priority request, queueing, and MessagesWaiting, are used for sending and receiving SMs. These parameters give information about the Short Message (SM). The contents and the transfer mechanisms have been specified in 3GPP TS 23.040. The main parameters are explained in the following. Validity-Period
It indicates how long the SM is valid, that is, if the SM cannot be delivered to subscriber B immediately, the length of time the SMSC stores the SM before discarding it if all delivery attempts fail. Each SM has a validity period, after which SMs that have not been delivered are deleted. As the originator of an SM submits the SM for delivery, they decide for how long the delivery attempts should be made if the SM cannot be delivered immediately. Delivery attempts are made until the delivery succeeds, or until the validity period expires; in the latter case, the SM is deleted. The method of giving the validity period depends on the capabilities of the mobile phone used, or on the application that sends the message. For details regarding each type of mobile phone, refer to their respective instructions and user guides. If no validity period is given by the originator, the SMSC inserts a default validity period. There is also a maximum validity period system parameter to inhibit the use of excessive validity period values. This control parameter is an internal MOSM functionality. Service-Centre-Time-Stamp
The SMSC uses it to inform the MS about the time when the SM arrived in the SMSC. The time value is included in every SMS-DELIVER message (TPService-Centre-Time-Stamp field) delivered to the MS. This control parameter is an internal MT-SMS functionality. Protocol-Identifier (PID)
The Short Message Transfer Layer (SM-TL) uses it either to refer to a higher layer protocol, or to indicate interworking with a certain type of device. The SM can be converted, for example, into SMTP , X.400 mail transfer protocols, or fax. The subscriber chooses the method of sending the SM, and normally it is a regular mobile-to-mobile message. This control parameter is an internal SMS functionality.
18 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
More-Messages-to-Send (MMS)
The SMSC uses this functionality to inform the network in a Mobile-terminating Short Message (MT-SM) that the SMSC has more messages to send to the same subscriber. The next short message is not sent until an acknowledgement for the previous one is received. The connection path between the SMSC and the MS is not closed until all SMs have been delivered to the MS. SMS queuing
Queueing takes place when more SMSCs are sending short messages to the same subscriber at the same time. In this case all incoming SMs are placed in a queue in the VMSC and they are served according to the First-In-First-Out (FIFO) principle. Information-Element
This field contains information set by the application in the SMS-SUBMIT/ DELIVERY, with which the receiving entity is able to re-assemble the concatenated short messages in the correct order. The field includes the following elements: .
Concatenated short message reference number : this reference number remains constant for every SM which makes up a particular concatenated short message.
.
Maximum number of short messages in the concatenated short message : it indicates the total number of SMs within the concatenated short message. The value remains constant for every SM which makes up the concatenated short message. If the value is zero, then the receiving entity ignores the whole Information Element.
.
Sequence number of the current short message : this value starts at 1 and increments by one for every SM sent within the concatenated short message.
Priority Request
This parameter tells the PLMN whether an SM is a priority message or not. If the SM is not a priority message, and the MS has been identified as temporarily absent, the system does not try to deliver it. However, the system tries to deliver the non-priority SM if the MS has not been identified as temporarily absent, also when it has been identified as having no free memory capacity. The system tries to deliver a priority SM even if the MS has been identified as temporarily absent or having no free memory capacity.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
19 (267)
SMS Guide
Messages Waiting (MW)
This service element makes the PLMN store information (Messages Waiting Indication (MWI)) listing the SMSCs that have made unsuccessful short message delivery attempts to the MSs in the PLMN in question. The MWI contains the following elements: .
Messages Waiting Data (MWD ) including the address list of the SMSCs having messages waiting to be delivered to the MS
.
Mobile Station Not Reachable Flag (MNRF) indicating if the address list of the MWD contains one or more entries as a result of an unsuccessful SM delivery attempt (stored in the VLR and HLR)
.
Mobile Station Not Reachable Flag for GPRS (MNRG) indicating if the address list of the MWD contains one or more entries as a result of an unsuccessful SM delivery attempt (stored in the SGSN and HLR)
.
Mobile Station Not Reachable Reason (MNRR ) for GSM and SGSN storing the reason why an MS is absent when an attempt to deliver a short message failed in the MSC
.
Mobile Station Memory Capacity Exceeded Flag (MCEF) indicating that the mobile station memory capacity does not allow short message delivery (stored in the HLR). For more information on SMS elements, see 3GPP TS 23.040.
Main parameters on the Short Message Relay Protocol (SM-RP) layer
The following parameters are visible on the Short Message Relay Protocol (SMRP) layer according to 3GPP TS 23.040.
Mobile-terminating short messages: .
SMSC Address
.
Destination Address (IMSI or MSISDN of subscriber B)
.
User Data containing Short Message Transfer Layer Protocol Data Unit (SM-TL PDU )
.
Message Reference
.
Priority Request
.
More Messages To Send
Mobile-originating short messages:
20 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.3
.
Message Reference
.
Originating Address (subscriber A)
.
Destination Address (SMSC)
.
User Data containing Short Message Transfer Layer Protocol Data Unit (SM-TL PDU)
Mobile-originating short message The Mobile-originating Short Message (MO-SM) procedure is used to forward an SM from a mobile subscriber to an SMSC . An active MS is able to send an SMSSUBMIT at any time, no matter if there is a speech or data call in progress or not. The following figure shows the MO-SM successful case: VLR
HLR
2
MO-ForwardSM
1
3
4
7
6
5
MSC
Figure 3.
dn98905102 Issue 5-0 en
SMS-IWMSC
SMSC
MO-SM successful case
# Nokia Corporation Nokia Proprietary and Confidential
21 (267)
SMS Guide
1.3.1
MO-SM procedure MO-SM procedure when the SMSC is connected through the SMRSE interface
22 (267)
1.
The MS sends an SM to the VMSC through SDCCH (if the MS is idle) or SACCH (if the MS is busy) signalling channel on the radio interface. The SM includes the address of the SME where the SMSC eventually attempts to forward the SM.
2.
The VMSC checks the data of subscriber A from the VLR.
3.
The VMSC routes the SM to the SMS-IWMSC . The result of the Global Title analysis should be the own signalling point code in the IWMSC .
4.
The SMS-IWMSC routes the SM to the SMSC. A special OSI or TCP/IP application is used between SMS-IWMSC and SMSC, and the SM can be sent through this application.
5.
The SMSC sends a delivery report to the SMS-IWMSC through the OSI or TCP/IP application.
6.
The SMS-IWMSC sends a delivery report to the VMSC.
7.
The VMSC sends a report to the MS of subscriber A through SDCCH or SACCH . The report is a delivery or a failure report, depending on whether the sending was successful or not. In other words, it either confirms that the SMSC has received the SMS-SUBMIT, or informs the MS that it was impossible to deliver the SMS-SUBMIT to the SMSC, including the reason why.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMSIWMSC
SC
HLR
MSC
VLR
MS Access request and possible authentication CP-DATA (RP-DATA)
CP-ACK sendInfoForMO-SMS MOforwardSM Message transfer Delivery report Delivery report
CP-DATA (RP-ACK) CP-ACK
User Data relevant to Feature 1043 is sent in CP-DATA (RP-ACK). Figure 4.
MO-Forward SMS procedure
For more information, see SMRSE in SMS . MO-SM procedure when the SMSC is connected through the MAP interface
The VMSC and SMSC are connected through Common Channel Signalling (CCS). 1.
If a CCS solution is used, the VMSC can route the SM directly to the SMSC.
2.
If a CCS solution is used, the SMSC can send the delivery reports directly to the VMSC.
For related information, see MAP in SMS .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
23 (267)
SMS Guide
You can also find related information in Welcome SM to the roamer , and Network elements involved in SMS .
1.3.2
Unsuccessful MO-SM delivery The sending of the MO-SM can fail in any of the below situations: .
Subscriber A does not have the T22 (MO-SMS) subscription (TeleserviceNotProvisioned).
.
Operator-determined barring is activated by the network operator or barring supplementary service is activated by the subscriber.
.
SMSC address prevention is defined (UnknownSc on the MAP interface).
.
A-number prevention is defined (UnknownSC on the MAP interface).
.
The MO-SM facility is not supported in the network (FacilityNotSupported on the MAP interface).
.
The Short Message Service Centre is unknown (UnknownSc on the MAP interface).
.
The short message transfer is rejected because the SME address is invalid (InvalidSME-Addr on the MAP interface).
.
Subscriber A is not the subscriber of the relevant SMSC (UnidentifiedSubscriber on the MSC-SMSC interface).
.
There is congestion in the SMSC (SC-Congestion on the MSC-SMSC interface).
.
In case of an Intelligent Network (IN ) subscriber, the SCP can bar the short message submission. The error code depends on the SCP.
.
1.4
System failure (SystemFailure on the MAP interface and MSC-SMSC interface)
Mobile-terminating short message The MT-SM procedure is used to transfer an SM sent from the SMSC to a mobile station. An active MS is able to receive an SMS-DELIVER at any time, independently of whether or not there is a speech or data call in progress. The following figure shows the successful MT-SM case.
24 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
HLR
SendRoutingInfoForSM
2
VLR
7
4
MT-ForwardSM
SMSC
1
3
8
6 SMS-GMSC
Figure 5.
1.4.1
5
MSC
MT-SM successful case
MT-SMS procedure MT-SMS procedure when the SMSC is connected through SMRSE interface
The following figure shows a normal case where the sending of MT-SM succeeds: Note that when the priority flag is set, the delivery is attempted even when the MNRF flag is set.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
25 (267)
SMS Guide
SC
SMSGMSC
Message transfer
HLR
MSC
VLR
MS
SendRoutingInfo ForShortMsg MTforwardShortMessage
SendInfoForMT-SM SendInfoForMT-SM (Ack/NAck) Provide Loaction Info Provide Loaction Info Ack/NAck Page Authent. CP-DATA (RP-DATA) Delivery report
Delivery report
User Data relevant to Feature 1043 is sent in CP-ACK. Figure 6.
26 (267)
MT-Forward-SMS procedure
1.
The SMSC sends the SM to the SMS-GMSC by using the SMRSE protocol.
2.
The SMS-GMSC requests the VMSC or SGSN address from the HLR.
3.
The SMS-GMSC routes the SM to the VMSC/SGSN.
4.
The VMSC asks the VLR for the status and location area of the MS of subscriber B . For information on the operations in the SGSN, see Mobileterminating short message over GPRS .
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
5.
If the MS is in idle mode, the VMSC starts paging and delivers the SM to it through the SDCCH of the BTS where the MS is located. If the MS is in busy mode, the VMSC sends the SM through the SACCH . The MS sends a delivery report to the VMSC after receiving the SM.
6.
The VMSC sends the delivery report to the SMS-GMSC. In the case of CCS solution, every MSC must have a GT analysis for routing the SMSCISDN address to the SMSC, and the SMSC must have the GT analysis for receiving that message.
7.
The SMS-GMSC sends the delivery report to the HLR if needed.
8.
The SMS-GMSC sends the delivery report to the SMSC either confirming that the MS has received the SM, or informing the SMSC that it was impossible to deliver the SM to the MS, including the reason why.
For more information, see SMRSE in SMS . MT-SMS procedure when the SMSC is connected through the MAP interface
The SMSC in the MT-SMS procedure has a MAP interface and has the SMSGMSC function. 1.
If a CCS solution is used, the SMSC can request the VLR address from the HLR and route the SM directly to the VMSC.
2.
If a CCS solution is used, the VMSC can send the delivery reports directly to the SMSC.
For related information, see MAP in SMS . Some related information can also be found in Welcome SM to the roamer and Network elements involved in SMS .
1.4.2
Unsuccessful MT-SM delivery The delivery of the MT-SM can fail if any of the following conditions are applicable: .
Subscriber B is absent (AbsentSubscriber on the MAP interface). As a result, MWD (including the SMSC address) and the MNRF flag are set in the HLR. Furthermore, the MNRR stores one of the below detailed reasons for the MS being absent. Note that these reason codes are not available through X.25. See also Handling of MNRR .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
27 (267)
SMS Guide
Table 2.
MNRR reason codes
Reason code
Network element setting the reason code
No paging response through the MSC
VLR
IMSI detached
VLR
Roaming restriction
HLR
MS purged for non-GPRS
HLR
No paging response through the SGSN
SGSN
MS purged for GPRS
HLR
Unidentified subscriber through the MSC *
SMS-GMSC
Unidentified subscriber through the SGSN *
SMS-GMSC
GPRS detached
SGSN
* Note that the VMSC or SGSN sends the Unidentified Subscriber error code to the SMS-GMSC and the SMSGMSC maps it to Absent Subscriber error code.
For detailed information see Short Message Service on GPRS .
28 (267)
.
If both Feature 714: Short Message Services Enhancements and Feature 1043: Short Message Services GSM Phase 2+ are active, feature 1043 overrides feature 714, and the MNRR is sent to the HLR.
.
The subscriber is unknown in the VLR (UnidentifiedSubscriber on the MSC-SMSC interface). As a result, (including the SMSC address) the MNRF flag is set in the HLR.
.
The subscriber is unknown in the HLR (UnknownSubscriber on the MSCSMSC interface). In this case, the MWI is not set.
.
If the global title analysis fails in the SMS-GMSC towards the HLR, the SMSC receives the Unknown_Subscriber error code from the SMSGMSC. This error code is a permanent error code, and consequently the SMSC ceases to retry the sending of the SM. This way the useless load of the network can be avoided.
.
An SMSC is trying to send an SM to the subscriber while another SMSC is already sending him SMs (the paging request is rejected due to BusySubscriber on the MAP interface).
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
MNRF flag is set in the HLR, but the priority flag is not set. The corresponding error code is transferred on the MSC-SMSC interface.
.
Information is found in the HLR that incoming call barring applies to subscriber B (CallBarred on the MSC-SMSC interface).
.
A positive response is received for paging, but the memory capacity of the MS is exceeded (the MCEF flag was not set in the HLR), and the Memory Capacity Exceeded informing procedure starts (MemoryCapacityExceeded on the MAP interface). As a result, MWD (including the SMSC address) and the MCEF flag are set in the HLR.
.
In case of an Intelligent Network (IN ) subscriber, the SCP can respond with a ReleaseCall message, which results in the MSC/VLR not forwarding the SM to Subscriber B. The error code depends on the SCP, and it is transferred on the MAP interface.
.
SMSC address is barred for the visitor subscribers (FacilityNotSupported on the MAP interface).
.
SMSC address is barred for home subscribers (IllegalSubscribers on the MAP interface).
.
System failure occurs (SystemFailure on the MAP interface).
Special conditions .
If subscribers are temporarily out of coverage, and a short message is sent to them, an MNRF is set in the VLR. The service centre address is set in the subscriber's message waiting data (MWD) list. When the MS goes back to coverage area, the VLR does not recognise any change, so the MNRF is not checked until a call or a periodic location update is made. This situation causes delay in the SM delivery. As a Nokia proprietary solution, instead of 'Absent Subscriber' a 'System failure' error code is sent to the SMS-GMSC from the VMSC. The SMSGMSC maps this 'System failure' to temporary 'Invalid SME address' error code towards the SMSC. This error code is not used for any other MT-SM procedure, so the SMSC can handle it as a temporary error situation and polls the subscriber periodically because only the MWF is set in the VLR. Note that the solution works only with Nokia SMS-GMSC and VMSC. If no MT-SM delivery is possible through the MSC, the SGSN route can also be tried.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
29 (267)
SMS Guide
.
1.4.3
If a mobile station cannot receive short messages because of memory shortage, a special error code 'memory capacity exceeded' is returned and carried to the SMS-GMSC through the MAP protocol.
More-messages-to-send More-messages-to-send (MMS) is an information element offering an MS (receiving a short message from an SMSC) the data whether there are still more messages waiting to be sent from that SMSC to the MS. The SMS application reads the MMSWaitTimer from the PRFILE. In MMS case the second route is never tried in the SMS-GMSC. For more information on the PRFILE, see MMS-related parameters in SMSrelated general parameter file (PRFILE/FIFILE) parameters .
1.4.4
Command SM and MO-SM with Status Report request In GSM phase 2, the MS is able to command the SMSC . Subscriber A, for example, can cancel an SM that has not yet been delivered to subscriber B, or can request a status report about whether the SM was delivered to the subscriber or not. These commands appear as ordinary SMs to the network, but the SM data contains a field indicating the message type. This message type is extracted from the SM for charging and statistical purposes. The network indicates the result of the command to the subscriber by Status Report. This message type is extracted from the SM for charging and statistical purposes. MO-SM with Status Report request
When subscribers send mobile-originating SMs, they can request information on whether the SM was delivered to the destination MS, or not. It is possible if the Status Report Request field is set in the mobile-originating SM by the sender. If the SM was delivered, or cannot be delivered at all, Status Report is sent to the originator of the SM indicating the result of the delivery. The information about whether the Status Report request is set in the MO-SM is carried from the SMS application to the charging application, and in this case the SMMO CDR can be generated with the 'Mobile originated short message status report requested' SMS type value. It means that if the optional PRFILE parameter MO_SM_STATUS_REP_REQ is turned on, you are able to apply different charging for MO-SMs in which Status Report is requested.
30 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMS-Command: What happened to the SM I sent to my friend?
SMS-Command
1
2
4 SMS-StatusReport: Your SMS was delivered at 16:51 pm.
3 SMS-StatusReport
Figure 7.
MSC
SMSC
SMS command and status report
For related information, see SMS status report . The relevant parameter can be found among SMS-related general parameter file (PRFILE/FIFILE) parameters . SMSC address on the MSC-SMSC interface
The SMSC address used by the MS can be sent to the SMSC on the TCP/IP interface. If an SMSC number modification happens in the MSC due to different SMS applications (such as bank information), the new SMSC address is used for routing purposes. However, the old SMSC address is also needed in the StatusReport case, because the mobiles can only understand the SMSC addresses stored in them, that is, the ones that were used in SM sending. The MSC sends the SMSC address given by the subscriber to the SMSC on the TCP/IP interface. It does not affect the MSC-SMSC interface because this parameter was implemented on the interface already for future use. With SMSC address sent to the SMSC, you do not need to use predefined SMSC addresses because the StatusReport is appropriate even if you have several SMSC addresses. With the help of this functionality you can also use the networked SMSC solution: several SMSCs can be connected to the network with a single SMSC number, resulting in messages being routed according to destination number to the nearest SMSC.
Note
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
31 (267)
SMS Guide
You can use this feature if you have the SMSC connected through MAP (in the VMSC function), and also if you have the SMSC connected through SMRSE with TCP/IP. MAP version 3 is needed for this functionality. For details refer to the feature activation instructions of Feature 1165: Short Message Services, GSM Phase 2+ Enhancements .
In MO-SMS the SMSC-GT-1 represents the SMSC address given by the subscriber, and the SMSC-GT-2 represents the SMSC address given by the VMSC. If the SMSC address is changed in the VMSC, then the new SMSC address (SMSC-GT-2) is used on the SCCP level for routing purposes, but the MS-defined address is sent in the MO_FORWARD_SM MAP operation. Number modification can also take place in the SMS-IWMSC. In this case the number given by the subscriber is sent to the SMSC (SMSC-GT-1), and the new address (SMSC-GT-2) is used only for routing purposes.
32 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
MS
SMS IWMSC
VMSC
SMSC
CP_DATA CP_ACK
number modification MAP_MO_FORWARD_SM (SMSC-GT-1)
SMSC-GT-2 on SCCP level for routing SC_RP_MO_DATA (SMSC-GT-1)
MAP_MO_FORWARD _SM_ACK
SC_RP_MO_DATA_ACK
CP_DATA CP_ACK
Figure 8.
Successful MO-SM transfer with SMSC-GT-1 parameter
In MT-SMS the SMSC-GT-1 represents the SMSC address given by the MS, and the SMSC-GT-2 represents the physical SMSC address that is used by the subscriber. The transfer of the SMSC address given by the subscriber to the SMSC causes changes in the VMSC, SMS-IWMSC, and SMS-GMSC .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
33 (267)
SMS Guide
SMSGMSC
SMSC
SC_RP_MT_DATA (SMSC-GT-1, SMSCGT-2)
HLR
VMSC
MS
MAP_SEND_ ROUTING_INFO_ FOR_SM (SMSCGT-2 MAP_SEND_ ROUTING_INFO_FOR_ SM_ACK MAP_MT_FORWARD_ SHORT_MESSAGE (SMSC-GT-1) Page Positive page response CP_DATA CP_ACK CP_DATA MAP_MT_FORWARD_ SHORT_MESSAGE _ACK
CP_ACK
SC_RP_ACK
Figure 9.
1.5
Successful MT-SM transfer with the SMSC-GT-1 parameter
SMSC Alert The GSM system uses Alert-SC to inform the SMSC (which acts as a store and forward centre for SMs), that a subscriber has become available again and can now receive new messages. There are two cases in which the system knows when to send the Alert-SC:
34 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.
The subscriber has been absent (for example, the mobile was turned off), and the Mobile-Not-Reachable-Flag (MNRF ) has been set in the VLR and HLR. When the subscriber becomes available (for example, turns his or her mobile on), the VLR sees from the MNRF that there are messages waiting for the subscriber, and informs the HLR with ReadyForSM operation. Finally, the MNRF is cleared. See MAP in SMS for a more detailed description of ReadyForSM operation. After the HLR has been informed about the available subscriber, the Message-Waiting-Data of that subscriber is read and an alert is sent to every SMSC address found on the MWD list. Finally, the MNRF is cleared.
2.
The memory capacity was exceeded (either the mobile station or the SIM card memory was full), and the Memory-Capacity-Exceeded-Flag was set in the HLR. When the MS informs the VLR that it has free memory again, the VLR sends the ReadyForSM operation to the HLR. After the HLR has been informed about the available memory, the Message-Waiting-Data of that subscriber is read and an alert is sent to every SMSC address found on the MWD list. Finally, the MCEF is cleared. See the figure below:
ReadyForSM
2
HLR
3
AlertServiceCentre
Alert 4
1
MSC/VLR
Figure 10.
SMS-IWMSC
SMSC
SMSC alerting
The steps are the following:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
35 (267)
SMS Guide
1.
The MS informs the VLR that it has free memory or has become reachable again .
2.
The VLR informs the HLR with ReadyForSM that the subscriber is available or that there is free memory.
3.
The HLR searches all SMSC addresses listed in MWD from the subscriber data and sends an Alert-SC to each of them.
4.
The SMS-IWMSC forwards the Alert-SC to the SMSC through OSI or TCP/IP application.
There are two types of repeated delivery attempts from the SMSC (the providers of the SMSC and the network define their application): 1.
A repeated delivery attempt because the SMSC has been informed that the MS is active and available for receiving SMs.
2.
An automatic repeated delivery attempt performed by the SMSC.
During the Alert-SC procedure there is no load sharing. For further details, see SMS load sharing . You can also find a list of SMS information elements . For further details, see SMS load sharing . You can also find a list of SMS information elements .
1.6
SMS load sharing
1.6.1
SMRSE over X.25 OSI management does not fully support load sharing. It provides load sharing only when opening a connection. If two or more links exist to an SMSC and the connections are open, OSI management cannot know how much traffic is going within various connections and suggests the first one to be used so long as it is functional. In case of a malfunction, OSI management automatically switches the traffic onto a functional connection. Connection parameters are handled in OSI management by defining parameter sets and linking them to an Application Entity Name (AEN). When subscribers send SMs, they use the ISDN number to select an SMSC. In the MSC/VLR, the ISDN address is tied to an AEN. By defining several AENs to an ISDN address, several connections can be used for load sharing. The maximum amount of AEN connections is 5.
36 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Load sharing, thus, uses a modified algorithm where the AENs used are determined from the last three digits of the sending subscriber's number. This must be used instead of random selection, because command messages must be routed to the same SMSC where the original message was sent while concatenated messages must be routed to the same SMSC where the previous messages were sent.
SMSC01 SMS-IWMSC SMSC02 SMSC-1 SMSC03
SMS-IWMSC has three (3) Application Entities in SMSC address analysis
Figure 11.
SMSC-2
SMS load sharing
The algorithm uses a modulus from the last three digits so that the number range is distributed evenly to all available SMSCs within load sharing. For example, if there are three or five SMSCs (1, 2, 3, 4 and 5) to be shared, the following table applies:
Table 3.
Distribution of number range in available SMSCs
Subscriber number's
3 SMSCs,
5 SMSCs,
last three digits
number to be used
number to be used
160
1
1
161
2
2
162
3
3
163
1
4
164
2
5
165
3
1
166
1
2
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
37 (267)
SMS Guide
Table 3.
Distribution of number range in available SMSCs (cont.)
Subscriber number's
3 SMSCs,
5 SMSCs,
last three digits
number to be used
number to be used
167
2
3
168
3
4
169
1
5
A consequence of load sharing is that when the SMSCs send MT-SMs, they all use individual SMSC addresses, but logically they all mean one SMSC address which then routes the SM further. More details can be found in Short message routing . For more information, see the feature description of Feature 619: Short Message Services Enhancements.
Note Note that during the Alert-SC procedure there is no load sharing. For details, see SMSC Alert .
You can also find related information in SMRSE in SMS .
1.6.2
SMRSE over TCP/IP Load sharing without MO SMS limiter
The maximum amount of SMSC's TCP/IP connections in one MO-SMS load sharing group is increased from 5 to 32. Load sharing, thus, uses a modified algorithm where the IP address used is determined from the last three digits of the sending subscriber's number. This must be used instead of random selection, because command messages must be routed to the same SMSC where the original message was sent while concatenated messages must be routed to the same SMSC where the previous messages were sent. For the illustration of SMS load sharing, see Figure SMS load sharing .
38 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The algorithm uses a modulus from the last three digits so that the number range is distributed evenly to all available SMSCs within load sharing. For example, if there are three or five SMSCs (1, 2, 3, 4 and 5) to be shared, see Table Distribution of number range in available SMSCs A consequence of load sharing is that when the SMSCs send MT-SMs, they all use individual SMSC addresses, but logically they all mean one SMSC address which then routes the SM further. More details can be found in Short message routing . TCP/IP protocol also helps in SMRSE capacity problems. For more information, see the feature descriptions of Feature 931: Short Message Service Transfer over TCP/IP and Feature 619: Short Message Services Enhancements . You can also find related information in SMRSE in SMS . Load sharing with MO-SMS limiter
Improved load sharing based on the SMSC link capacity value is possible with MO-SMS limiter. Weighted distribution can be achieved among SMSCs with different capacity, that is, proportionally equal load can be achieved in all SMSCs if you have Feature 1165: Short Message Services GSM Phase 2+ Enhancements in use in your network.
Note For using this functionality you must have the SMSC connected through SMRSE with TCP/IP.
If there are SMSCs with different capacity in the network, the proportionally equal load sharing in the MSC requires the capacity information from the SMSC. The MO-SMS limiter is sent by the SMSC to the MSC during the connection establishment between the MSC and the SMSC. It tells the MSC what the upper limit for MO-SMs is per second per TCP/IP link. There is an MO-SMS limiter for each SMSC link. The possible value of this parameter ranges from 0 to 10000 MO-SM/sec. The MSC then controls the number of MO-SMs sent to the SMSC (on one TCP/ IP link) per second on the basis of the value of the MO-SMS limiter.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
39 (267)
SMS Guide
Note, that the AlertSC messages are not counted here. The value of the MO-SMS limiter for a specific SMSC link is stored in the connection table of the MSC. The MSC makes the weighted equal distribution among the links involved in the load sharing based on this value. If a link goes down, the load sharing is executed among the rest of the SMSC links. An exception to this is when the error indication is coming from a link because of overload situation. In this case the link stays in the load sharing group. The following figure illustrates how the limiter is used in load sharing:
MO-SMS Limiter:10
SMSC-1
MSC
MO-SMS Limiter:20
SMSC-2
MO-SMS Limiter:30
SMSC-3
MO-SMS Limiter:40
SMSC-4
MO-SMS Limiter:50
SMSC-5
Figure 12.
The use of MO-SMS Limiter in load sharing
This functionality causes changes in the SMS-IWMSC. There is no change on the MSC-SMSC interface, because the MO-SMS limiter parameter is already supported.
40 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Error situation is raised if you have Feature 1165: Short Message Services, GSM Phase 2+ Enhancements in use but there is no MO Limiter value given for the TCP/IP link. In this case load sharing works in the previously described equal distribution method, and Alarm 1224, Missing Mo limiter for SMSC link is issued. See also Alarms and their meaning in Short Message Service . For details, refer to the feature descriptions and feature activation instructions of Feature 1165: Short Message Services, GSM Phase 2+ Enhancement s. Further information can also be found in TCP/IP connection .
1.7
Barring SMS in the MSC Barring of MO-SMS
You can configure certain SMSC and A-subscriber addresses into the VMSC or SMS-IWMSC corresponding to where the MO-SM is not allowed to be sent and from whom it is not allowed to be originated, respectively, but only if you have Feature 1043: Short Message Services GSM Phase 2+ in your network. Without feature 1043 you can only configure MO-deny for all subscribers. With the help of this feature you can separately define whether the SMSC is barred for home subscribers, visitor subscribers or for all subscribers. The MAP interface uses the UnknownSC error code in A-subscriber or SMSC barring, which results in the UnassignedNumber error code sent from the VMSC to the MS. If you want to use this functionality, a new SMSC address analysis (MO-DENY analysis based on SMSC address) is needed to decide whether the use of the SMSC is denied or not. In addition, the A-subscriber MSISDN analysis is also added to the feature. The following barring cases can be considered in the VMSC:
dn98905102 Issue 5-0 en
.
When a home subscriber is in the home PLMN, the A-subscriber barring is not relevant since the removal of the teleservice code from the HLR has the same effect.
.
When a home subscriber is in the home PLMN, the usage of a foreign SMSC can be barred.
.
When a foreign subscriber is in the home PLMN, both the A-subscriber number and the usage of the own SMSC can be barred.
# Nokia Corporation Nokia Proprietary and Confidential
41 (267)
SMS Guide
Special conditions When the network has Mobile Number Portability (MNP), you have to be careful when setting A-number prevention to subscribers. If you want to use A-number prevention in the home country, to prevent SMs sent by the subscribers of another operator and there is MNP in the network, it can happen that your own subscribers will also be barred as a result of their using the MNP functionality. For example, if you set A-number prevention when there is MNP in the network, and if subscribers from another operator becomes your subscribers keeping their old MSISDN number for which the barring exists, they will not be able to send short messages. Similarly, if you want to bar SMs sent by the subscribers of a foreign operator from a foreign country, you can also bar those sent by the subscribers of another operator in the same foreign country. The following figures illustrate possible examples for the use of this functionality:
home PLMN
foreign PLMN
GSM network home subscribers
SMSC operator does not allow SMs to be sent to a foreign SMSC
Figure 13.
42 (267)
MO-SMS barring configured to the VMSC, case 1
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
home PLMN GSM network foreign subscribers
SMSC operator does not allow SMs to be sent to his own SMSC or to be originated from a foreign subscriber
Figure 14.
MO-SMS barring configured to the VMSC, case 2
The following barring cases can be considered in the SMS-IWMSC: .
When a home subscriber is in the home PLMN the A-subscriber barring is not relevant since the removal of the teleservice code from the HLR has the same effect (similarly to the VMSC). In addition, the barring SMSC address is not relevant in this case.
.
When a foreign subscriber is in the home PLMN, you can bar both the Asubscriber number and the usage of the own SMSC.
.
When a foreign subscriber is in the foreign PLMN, you can bar both the Asubscriber number and the usage of the own SMSC. This barring case can only be configured to the IWMSC.
The following figures illustrate possible examples for the use of this functionality:
foreign PLMN
home PLMN GSM network
foreign subscribers
Figure 15.
dn98905102 Issue 5-0 en
SMSC operator does not allow SMs to be sent to his own SMSC or to be originated from a foreign subscriber
MO-SMS barring configured to the IWMSC, case 1
# Nokia Corporation Nokia Proprietary and Confidential
43 (267)
SMS Guide
home PLMN GSM network foreign subscribers
SMSC operator does not allow SMs to be sent to his own SMSC or to be originated from a foreign subscriber
Figure 16.
MO-SMS barring configured to the IWMSC, case 2
Barring of MT-SMS
You can configure certain SMSC addresses (for example, one located in a foreign country) into the VMSC if you have Feature 1043: Short Message Services GSM Phase 2+ in your network. This means that no MT-SM is allowed to be originated from that SMSC address. It is also possible for you to separately define whether a certain SMSC is barred .
for home subscribers
.
for visitor subscribers or
.
for all subscribers
When there is barring in the VMSC, it sends an error code to the SMSC. The following error codes can be sent according to the groups of subscribers concerned:
Table 4.
Error codes in MT-SMS barring
Group of subscribers affected
Error code
Type of failure
Re-delivery according to the SMSC
Home
IllegalSubscriber
Permanent
No
44 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Table 4.
Error codes in MT-SMS barring (cont.)
Group of subscribers affected
Error code
Type of failure
Re-delivery according to the SMSC
Visitor
FacilityNotSupported
Temporary
Yes
All
FacilityNotSupported
Temporary
Yes
Due to the possibility of SMSC barring in MT-SMS case, the filtering needs an SMSC address analysis (MT-DENYanalysis based on the SMSC address) for barring purpose in the VMSC. The result of the analysis can be barring for all subscribers, barring for visitor subscribers, barring for home subscribers or nothing (meaning there is no restriction in the VMSC). This functionality can be useful, for example, if you want to bar the delivery of short messages coming from a special SMSC used by an internet service. For home subscribers the barring is set as permanent, while for visitor subscribers you set the barring as temporary if you want to enable the subscribers to receive the short messages after returning to their home network. To avoid the frequent resending of short messages, you need to set the FacilityNotSupported error code in the SMSC in such a way that the interval between two resendings is as big as possible. This results in a decreased load in the network. The following figures illustrate possible examples for the use of this functionality:
foreign PLMN
home PLMN GSM network
SMSC no roaming contract due to charging problems
Figure 17.
dn98905102 Issue 5-0 en
foreign subscriber
MT-SMS barring, Case 1
# Nokia Corporation Nokia Proprietary and Confidential
45 (267)
SMS Guide
home PLMN
foreign PLMN
GSM network SMSC operator does not allow SMs to be originated from an Internet service
all subscribers
Internet service application
Figure 18.
MT-SMS barring, Case 2
For information on how to configure MT-SMS barring, see Configuring network elements for SMS , Managing SMS network element-specific data and Preventing SMS .
1.8
Welcome SM to the roamer With this function, the SMSC can have the possibility to send a welcome note with predefined text to the roaming subscriber. When a roaming subscriber makes a location update in the operator's own PLMN, the VMSC checks whether it has just arrived from another PLMN (even if it is in the same country). If it has, the VMSC generates a special MO-SM and sends it through the SMS-IWMSC towards a specific SMSC. In this special MO-SM, in the SMS TP-header the TP-Destination-Address is a national address for the SMSC application which is configured also in the VMSC. The TP-User-Data field contains the roaming subscribers MSISDN number, IMSI, LAC and Cell ID in this sequence. The SMSC has to identify the received welcome MO-SM based on the sender virtual subscribers address and it sends a welcome MT-SM as a welcome note to the roaming subscriber.
46 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
You have to configure the SMSC address and the SMSC application address in the VMSC for the welcome SM. You also have to define a virtual MSISDN number (C-MSISDN) as the originator of the created MO-SM in the VMSC.
Note In MAP version 2 the virtual subscriber also has to be created in the HLR. It is not necessary in case of MAP version 3.
The welcome SM functionality is based on a Nokia proprietary solution, which works with an SMSC which supports SM routing towards the application. For activation instructions see Handling the Welcome SM related parameters . The interface type does not affect the Welcome SM operation. It can be SS7, TCP/IP or X.25 towards the SMSC. For further details see the feature description of Feature 1043: Short Message Services, GSM Phase 2+ . You can also find related information in Mobile-terminating short message .
1.9
Real Time triggering With Real Time triggering, the MSC/VLR can provide data to the Nokia Terminal Management Server, and in this way NTMS can configure the mobile phone without the manual typing of end user or operator. As soon as the VLR detects an event, it sends the trigger to NTMS, and these triggers are sent by Short Message, since NTMS has direct connection to the SMSC. For an overview of the operation of the Real Time triggering, see the following figure:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
47 (267)
SMS Guide
NTMS
Detected Event - Inter-PLMN location update - IMEI changes in the database - New visitor with special previous LAC Statistic report: trigger SM Trigger SM (MSISDN, IMEI, IMSI, Detec.event, Common MSISDN)
IMEI checking
VMSC
CIMD
Forward MO-SM
IWMSC
MS
SMSC
Operator has to set -
SMSC address SMSC application address Sender (A number) of the trigger SM IMEI checking
Figure 19.
Operation of Real Time triggering
When the VLR receives an access request from the subscriber and the IMEI checking is switched ON, the VLR gets the subscriber's IMEI number. After the successful location update VLR or IMEI changes in the database (IMEI1 changes to IMEI2) the Real Time triggering functionality can start. Since these trigger SMs result in additional load in the MSC-SMSC interface, you can control which event has to be detected.
Table 5.
Events, criteria and types of control
Event detection
Filtering criteria
Control of event detection
Default activation status
IMEI changes in the VLR database
HOME / VISITOR subscriber
Can be switched ON/OFF
ON
or MS-CLASSMARK
48 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Table 5.
Events, criteria and types of control (cont.)
Event detection
Filtering criteria
Control of event detection
Default activation status
Inter-PLMN location update of new visitor
HOME / VISITOR subscriber
Can be switched ON/OFF
OFF
Can be switched ON/OFF
OFF
or MS-CLASSMARK
New visitor with special previous LAC
HOME / VISITOR subscriber or MS-CLASSMARK
Based on this table, you can set three kinds of EVENT, and two kinds of CRITERIA in the VLR parameter file. .
It is possible to differentiate between the types of mobile stations by using the MS_CLASSMARK parameter.
.
The HOME/VISITOR parameter makes it possible that either the HOME subscriber, or the VISITOR subscriber is detected only, or both.
.
The Inter-PLMN location update event indicates a subscriber who has just arrived from a foreign country. The national roamers are not detected.
.
The New visitor with special previous LAC event can indicate a new subscription in the network. With the configurable UTPFIL parameter, it is possible to set a different kind of initial value for the event 'New visitor with special previous LAC value'.
Note If the special previous LAC is zero, it can also mean an unsuccessful location update.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
49 (267)
SMS Guide
Additional information on Real Time triggering
If the detected event meets the filtering criteria, the VMSC generates the Trigger SM. The Trigger SM TP-User-Data field contains the subscriber MSISDN, IMEI, IMSI number, Detected event, and Common MSISDN in ASCII format. The structure of the User Data can be found below. The numbers are separated with a space. MSC_36209956524_490523102400750_21601585458_PLMN_36209956500 Flag+MSISDN + IMEI + IMSI + Detect.event + Common MSISDN
You have to configure the SMSC address and SMSC application address (Destination - B subscriber number) in the VMSC. Moreover, you also have to define a virtual MSISDN number as the sender of the created MO-SM (A number) in the VMSC. The trigger SM functionality is based on a Nokia proprietary solution, which works with an SMSC which supports SM routing towards the application. As an additional functionality, Terminal Management Support provides both common MSISDN and own MSISDN to the NTMS. The VMSC sends both the common MSISDN and the own MSISDN to the NTMS, which informs the NTMS that this is a multi SIM user. It also provides filtering to detect only those subscribers who belong to the appropriate HPLMN. When the operator has two home networks, and there are different NTMSs for each network, the subscriber's data of the HPLMN1 can be sent only to the NTMS of the HPLMN1. For further details, see the feature description of Feature 1433: Terminal Management Support . For activation instructions, see Activating Real Time triggering .
1.10
Incoming Call Treatment The Incoming Call Treatment service enables the subscriber to decide how the incoming calls should be terminated if they cannot accept the calls. In addition to regular call answer and reject, the subscriber can predefine rules for the possible terminations. These rules are represented in a menu. The user can choose the termination mode from this menu before the rejection. The called party has the following possibilities to handle the call:
50 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
simply rejecting the call
.
forwarding the call to a certain pre-defined number
.
forwarding the call to voice mail
.
rejecting the call with a pre-defined notification to be sent in SMS to the caller -
normal SM: it is stored immediately flash SM (class 0): it is received to the user's screen.
The called party can personalise the service by defining the forwarding numbers and the text in the short message. It is also possible for the user to define more alternatives for the diverted-to numbers and the texts to be sent. The ICT service plays an announcement to the called party until the network receives an answer on how the call should be treated. The ICT service functions in case of home and outbound roaming. For more information see the feature description and the feature activation manual of Feature 1607: Incoming Call Treatment .
1.11
Missed Calls Log Service This feature provides indication about the missed calls to the served user. With the Missed Calls Log (MCL) functionality the subscriber receives information about those calls which were unsuccessful before the alerting phase. In these cases the network generates a special Short Message (SM), which contains the caller's number, time of the missed call, and the reason why the call was unsuccessful. The SM is sent to the MS when it is connected to the network again. The following situations are recorded as missed calls:
dn98905102 Issue 5-0 en
.
The phone is switched off (International Mobile Subscriber Identity (IMSI) detach; with or without Call Forwarding on Not Reachable (CFNRe ).
.
Unconditional Call Forwarding (CFU )
.
The phone is out of radio coverage.
.
The network is busy or there is a congestion.
.
Network Determined User Busy (NDUB )
.
network failure before the alerting phase
# Nokia Corporation Nokia Proprietary and Confidential
51 (267)
SMS Guide
The log contains the following information: .
caller's number (if available)
.
time and date of the missed call
.
reason why the call was unsuccessful
The mobile station receives the logs in short messages. By default, one SM contains one log entry (one unsuccessful call attempt). You can, as an option, choose to combine all log entries for one subscriber into as few SMs as possible. For more information see the feature description and the feature activation manual of Feature 1606: Missed Calls Log Service .
1.12
Short Message Service on GPRS General Packet Switched Services (GPRS) provides packet switched mode service to mobile stations and terminals. This way data can be sent and received by the MS at any time without prearranged network resource reservation or call setup. Short messages can be efficiently delivered over the GPRS radio interface as data packets. A GPRS service can be subscribed just like the GSM service. There can be subscribers (IMSIs) having both circuit switched GSM services and GPRS services, or subscribers having GPRS services only, or circuit switched services only. The following figure gives a general overview of the different network elements and interfaces involved. Please note, that this architecture is characteristic of those networks only in which TCP/IP or X.25 interface, and separate SMS-GMSC and SMS-IWMSC exist.
52 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
External data networks
SMS-GMSC/SMS-IWMSC
MAP (C)
MAP (Gd) GGSN
DX 200 HLR/AUC/EIR MAP (Gr, Gf) VMSC
SGSN HLR
AUC
EIR
BSS
GPRS MS
Figure 20.
Overview of involved network elements
For further details see the feature descriptions of Feature 857: Support of General Packet Radio Services (GPRS) .
1.12.1
SMS over GPRS with MAP version 2 If MAP version 2 is supported in the MAP-C and MAP-Gd interfaces, the MTSM through the SGSN is already available. This kind of environment does not require any special 'SMS over GPRS' support in the SMS-GMSC or the SMSIWMSC because as a subscription option you chose in the HLR whether the MTSM is always delivered through an MSC or through an SGSN. Note that in this kind of implementation the MT-SM is never tried through the other route. There is a subscriber-specific parameter which indicates whether the MT-SM should be sent through the MSC/VLR, or through the SGSN. With the help of this parameter in MAP version 2, you can predefine the preferred route in the HLR. It means that always that route is tried when delivering SMs, even if the subscriber is not reachable through that defined route. The result is, naturally, negative acknowledgement to the SMS-GMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
53 (267)
SMS Guide
Note The Send-Routing-Info-for-SM response includes a single switch address, and the SMS-GMSC never knows whether the GSM or the GPRS channel is used to route the SM. This is entirely dependent on the HLR parameter.
For delivering SMs over GPRS, only HLR support is needed. The details of MT-SM-related HLR activation can be found in the feature activation instructions of Feature 857: Support of General Packet Radio Services (GPRS ). You can also find related information in MAP in SMS , SMS over GPRS with MAP version 3 , Comparative example of SMS over GPRS with MAP version 2 and MAP version 3.
1.12.2
SMS over GPRS with MAP version 3 If MAP version 3 is supported, the MT-SM delivery can be more efficient, because both routes can be tried if the subscriber has both circuit-switched and packet-switched connection. In the HLR it is activated similarly to the MAP version 2 case, described in feature activation instructions of Feature 857: Support of General Packet Radio Services (GPRS) . You can also find related information in Handling of SMSrelated MAP parameters . Mobile-terminating short message service over GPRS
The below example shows an MT-SM delivery where both GPRS and CS networks are used. The subscriber has both SGSN and MSC addresses set in the HLR. The SMS-GMSC first tries the delivery through the GPRS network but it fails because the subscriber is detached. Then the SMS-GMSC tries to deliver the MT-SM through the CS network. The delivery through CS network is successful.
54 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMSC
SMSGMSC
HLR
SGSN
VMSC
MS
short_message_ MAP-Send-Routingdelivery_request Info-for-SM-req (primary route=SGSN) (SMS-GMSC 1 supports GPRS)
2
MAP-Send-RoutingInfo-for-SM-rsp (MSC address, SGSN address)
3
4
MAP-MT-forwardSM-req MAP-MT-forwardSM-rsp (Absent: GPRS detached)
6
5
MAP-MT-forwardSM-req MAP-MT-forwardSM-rsp
9 short_message_ delivery_rsp (succesful delivery)
7
Succesful_ SM_delivery
8
MAP-Report-SMdelivery-Status-req (succesful via MSC, absent via GPRS) MAP-Report-SMdelivery-Status-rsp
10
11
Figure 21.
Mobile-terminating short message delivery, MS detached for GPRS
The procedure is the following: 1.
short_message_delivery_request (primary route=SGSN) The SMSC requests MT SM delivery, with primary route indicator=SGSN.
2.
MAP-Send-Routing-Info-for-SM-req (SMS-GMSC supports GPRS) The SMS-GMSC request the routing information for the MT-SM from the HLR indicating 'SMS-GMSC supports GPRS'.
3.
dn98905102 Issue 5-0 en
MAP-Send-Routing-Info-for-SM-rsp (MSC address, SGSN address)
# Nokia Corporation Nokia Proprietary and Confidential
55 (267)
SMS Guide
SMS-GMSC receives two addresses from HLR: the VMSC address and the SGSN address. 4.
MAP-MT-forward-SM-req Since the route indicator received from SMSC tells that the GPRS network is the primary route, the SMS-GMSC first tries to deliver the MT-SM through GPRS network using the SGSN address received.
5.
MAP-MT-forward-SM-rsp (Absent: GPRS detached) MT-SM delivery was unsuccessful through GPRS network because the subscriber is detached. The SMS-GMSC receives the reason for unsuccessful delivery.
6.
MAP-MT-forward-SM-req SMS-GMSC tries to deliver the MT-SM through the secondary route, that is, the VMSC.
7.
Successful_SM_delivery The MT-SM is successfully delivered through the VMSC to the subscriber.
8.
MAP-MT-forward-SM-rsp The VMSC informs the SMS-GMSC about the successful delivery of the MT-SM.
9.
MAP-Report-SM-delivey-Status-req (successful through MSC, absent through GPRS) SMS-GMSC reports the delivery status, informing the HLR that the MTSM was successfully delivered through the VMSC and failed through the GPRS network, because the subscriber was absent.
10.
MAP-report-SM-delivery-Status-rsp HLR acknowledges the report.
11.
short_message_delivery_rsp (successful delivery) SMS-GMSC informs the SMSC that the MT-SM delivery was successful.
SGSN and MSC address handling in the HLR and SMS-GMSC
If the subscriber has both SGSN and MSC addresses in the HLR, the HLR can return one or both of them in response to the MAP-Send-Routing-Info-for-SM.
56 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
The HLR is allowed to return both the MSC address and the SGSN address in case that: -
.
The HLR might return only the MSC address in case that: -
.
the SMS-GMSC indicates in the request that it supports the GPRS SM delivery and subscriber-specific HLR parameter 'network access mode' is set to BOTH and 'MT-SM through GPRS suppressed' is set OFF for that subscriber.
the SMS-GMSC does not indicate the support of GPRS SM delivery, and MT-SM through SGSN is set to MSC, and network access mode is set to BOTH, or 'MT-SM through GPRS suppressed' is set ON for subscriber in the HLR, or 'network access mode' is set to MSC for the subscriber in the HLR.
The HLR might return only the SGSN address in case that: -
-
-
the SMS-GMSC does not indicate the support of GPRS SM delivery and MT-SM through SGSN is set to SGSN and 'network access mode' is set to BOTH, or the SMS-GMSC indicates in the request that it supports the GPRS SM delivery and 'MT-SM through GPRS suppressed' is set OFF for subscriber in HLR and 'network access mode' is set to BOTH or GPRS, or 'network access mode' is set to GPRS for subscriber in HLR.
If MNRG , MNRF , 'SGSN area restricted', and 'MSC area restricted' flags in the subscriber data indicate that the subscriber is not reachable through either the SGSN and/or the MSC, then the HLR does not return that address, respectively. When the SMS-GMSC receives two addresses, on the basis of the indicator received from SMSC or if not available, on the basis of an operator-controlled parameter it determines whether the GPRS or CS network is the primary route to try the delivery. If the MS is not reachable through the primary route (for example, the subscriber is detached or unidentified), the secondary route is tried. If the delivery was unsuccessful through one or both the routes, or if the delivery was successful for a priority short message, the delivery status is reported to the HLR, and MNRF and MNRG flags are set accordingly. Also the MNRR is set according to the absent subscriber diagnostic received from the SMS-GMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
57 (267)
SMS Guide
If the MT-SM delivery was successful through either of the routes, SMSC is informed only of the successful delivery. If there is only one route available and the MT-SM delivery failed, the error situation is indicated also to the SMSC. If the delivery failed both through MSC and through SGSN, the error codes of both routes are indicated to the SMSC. You can select the primary route by defining the option in the SMS-GMSC (GPRS_SUPP_IN_SMSGMSC ). However, if the SMSC indicates the primary route to the SMS-GMSC, it overrides this option. Parameters needed for sending SM over GPRS
Subscriber-specific parameters: network access mode: It is used to indicate if the subscriber has access to both the CS (MSC) and the GPRS (SGSN) networks, or only to one of them. MT-SM through GPRS suppressed: It is used to suppress the SGSN route for the subscriber. MT-SM through GPRS: It indicates if the MT-SM should be sent through the MSC or through the SGSN if the SMS-GMSC does not support GPRS SM delivery (that is, the GPRS_SUPP_IN_SMSGMSC is set to zero). The value of this parameter has an effect only when network access mode is 'access to both networks' and the 'MTSM through GPRS suppressed' parameter is OFF.
Network-specific parameters: GPRS_SUPP_IN_SMSGMSC: It is used for the activation/deactivation of the service. It also states the primary route through which the mobile-terminating short message service (MT-SMS) is sent (MSC or SGSN), in case the Short Message Service Centre (SMSC) does not provide the primary route indicator. If its value is 0, it means that the SMS-GMSC can receive only one address in response to MAP-Send-Routing-Info-forSM. If its value is 1, the SMS-GMSC can receive both MSC and SGSN address in response to MAP-Send-Routing-Infofor-SM, the primary route is SGSN. If its value is 2, the SMSGMSC can receive both the MSC and the SGSN address in response to MAP-Send-Routing-Info-for-SM, the primary route is MSC.
58 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
GPRS_V2_IN_USE: It indicates the activation status of GPRS v2. For related information, see SMS-related general parameter file (PRFILE/ FIFILE) parameters . Mobile-originating short message service over GPRS
If the MS is GPRS-attached, it sends the short message through SGSN to the SMS-IWMSC which forwards them to the short message service centre. Subscription check is done in the SGSN according to the data received from the HLR in the GPRS location update. Ready for SM indication in SGSN
When the MS informs the HLR of its presence through SGSN (Gr interface), the MNRG flag is reset and the SMSCs, if there are any SMSC addresses in the HLR database, are alerted. Note that it is possible that a MNRG or a MNRF flag is set in the database even if there are no SMSC addresses. The reason is that the MS can become reachable through SGSN and still remain not reachable through MSC (or vice versa). For further information, see MAP in SMS , and Comparative example of SMS over GPRS with MAP version 2 and MAP version 3 .
1.12.3
Comparative example of SMS over GPRS with MAP version 2 and MAP version 3 Generally, the MT-SMS with MAP version 3 includes ten basic steps as described in the following figure.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
59 (267)
SMS Guide
SMSC 1.
SMS-GMSC SMS-IWMSC
MSC/VLR
10.
7.
9.
6.
8. 2.
7.
5.
6.
4. 3.
HLR BSC
SGSN BTS
Figure 22.
Sending SMs over GPRS
1.
SMSC sends an MT-SM.
2.
Send-Routing-Info-for-SM arg GMSC requests for routing info from the HLR.
3.
Send-Routing-Info-for-SM res HLR sends back the SGSN and VMSC address (because the subscriber has both GSM and GPRS subscription, and is available through both routes)
4.
MTForward-SM arg SMS-GMSC tries to deliver the SM through the primary route, that is the SGSN.
5.
MTForward-SM res Negative acknowledgement is sent back by the SGSN as the subscriber is not reachable through GPRS.
60 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
6.
MTForward-SM arg SMS-GMSC tries to deliver the SM through the secondary route, that is the MSC/VLR.
7.
MTForward-SM res Positive acknowledgement is sent back by the MSC/VLR as the SM was successfully delivered to the subscriber.
8.
Report-SM-Delivery-Status arg Successful delivery through the MSC/VLR is reported to the HLR.
9.
Report-SM-Delivery-Status res HLR acknowledges the receipt of successful delivery status.
10.
SMS-GMSC acknowledges the SM delivery to the SMSC.
If a subscriber has both GSM and GPRS subscription, the subscriber is recognized in the HLR as being available through both SGSN and MSC, the primary route indicator set by you is GPRS and the default route in the HLR is set to GPRS, then the main differences between the short message service over GPRS with MAP version 2 and MAP version 3 are the followings:
MAP version 2 An MT-SM is sent from the SMSC, the SMS-GMSC request for routing information, and the HLR sends back the SGSN address. The delivery through SGSN is tried but since the subscriber is absent, an AbsentSubscriber Delivery Outcome is sent back to the HLR. The HLR sets the MNRG flag, and the SMSGMSC sends back a negative acknowledgement to the SMSC. (The SMSC waits for AlertSC , or retries delivering the SM according to the SMSC`s RetryTable value for AbsentSubscriber.) If a second SM is sent to the same subscriber, the HLR finds that the MNRG is set, and as the GPRS is set to be the primary route it sends a SendRoutingInfoForSM negative acknowledgement. The GSM route is not tried, and any SM can be delivered only when the subscriber becomes active through GPRS again. It means that although the subscriber is available through GSM, the SM is waiting in the SMSC until the subscriber is GPRS attached again.
MAP version 3
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
61 (267)
SMS Guide
An MT-SM is sent from the SMSC, the SMS-GMSC request for routing information and the HLR sends back both the SGSN and the VMSC address. Based on the primary route indicator coming from the SMSC or the one stored in the SMS-GMSC, for example, the GPRS route is tried first. The subscriber is absent through this route, so the SMS-GMSC tries the VMSC route where the SM delivery succeed and finally a successful report goes back to the SMSC. At the same time the MNRG flag is set in the HLR, so the next SM delivery for that subscriber is tried only through the GSM network. If the subscriber switches over to GPRS, the Ready-For-SM is sent to the HLR by the SGSN. For more information, see MAP interface operations (MT) , MAP in SMS , and GPRS with SMSC-MSC connection through MAP interface .
1.12.4
GPRS with SMSC-MSC connection through MAP interface SMS over GPRS is also possible in such SMS architecture which includes SS7 MAP interface between the MSC and the SMSC. However, the functions supporting sending short messages over the GPRS network must be implemented in the HLR and in the SMSC as well.
VMSC
MAP
BSC
SMSC SGSN
MAP Gd HLR
Figure 23.
SMS over MAP interface
For more information, see SMSC product descriptions and instructions. You can also find related information in Comparison of the SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC.
62 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.13
IN Short Message functionality There is a Nokia-specific INAP interface between the MSC and the SCP which realises the IN SMS. It means that the subscriber can benefit the services provided by the SCP only when inside the HPLMN . The SMS triggering detection points (MO-, MT-, Status Report) make IN services possible for example, redirecting of short messages to another subscriber, or allowing the user to prevent short messages from a certain source. Also, Event Detection Points have been introduced for MO-, MT- and Status Report TDP. The triggers defined for the IN SMS are located in the VMSC . Mobile-originating IN SMS
In the MO case, the TDP is met after the authentication and ciphering for the MO-SMS has been carried out and the MSC has received the SM from the MS. If the TDP is armed (the TDP data is included in the subscriber data), the MSC/ VLR sends an IN service request to the SCP , which can react in several ways. In the following cases, the SM transfer continues: .
The SCP responds with the Continue message, and does not change the SM. The MSC/VLR forwards the original SM to the original SMSIWMSC .
.
The SCP responds with the Connect message. The SCP can change the destination, both the SMSC address and subscriber B to whom the message was originally sent. The SCP can also change other parameters in the SM header, for example, the type of the message. When receiving the changed header from the SCP, the MSC/VLR alters the original SM header and sends the message to the SMS-IWMSC.
.
The SCP arms one or both EDPs (successful or failure), or can request the monitoring mode. The type of the EDPs can be either notification (EDP-N ) or request (EDP-R ).
.
The SCP sends the FurnishChargingInformation message(s) related to the Connect or Continue message. When the MSC/VLR receives this message, it generates the IN CDR .
SM transfer is rejected if the SCP sends the ReleaseCall message. In this case, the MSC/VLR does not forward the SM to the SMS-IWMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
63 (267)
SMS Guide
Mobile-terminating IN SMS / Status Report SMS
In the MT case, the TDP is met at the earliest possible point after the MSC has received the SM from the SMS-GMSC , and the subscriber data in the VLR has been checked. If the TDP is armed (the TDP data is included in the subscriber data), the MSC/VLR sends an IN service request to the SCP , which can react in several ways. In the following cases, the SM transfer continues: .
The SCP responds with the Continue message and does not change the SM. The transfer continues normally, and the MSC/VLR starts paging, and forwards the SM to the MS.
.
The SCP can change the A-subscriber's address, or can send it back to the SSP (changed/unchanged) in a MT-Connect operation (MT-VMSC). That is, the mobile terminated SM (derived from the Connect case) can contain also the A subscriber's address in the originating address field, which makes improved SMS-based services, for example banking services available
.
If the SCP wants to reroute the SM, it responds with the Connect message. The SCP can provide the address of the SMSC, or the A-, and Bsubscriber's addresses as well. The SCP also changes the message header of the SM. The SCP must change the SMS type from mobile-terminating to mobile-originating before forwarding it to the specified SMS-IWMSC. MSC/VLR can receives three different kind of SM Header from SCP. These are the following: -
-
-
64 (267)
When the MSC/VLR has received the Connect message, it generates the MO short message and forwards it to the specified IWMSC. After receiving the acknowledgement from the IWMSC, the MSC can report the success of the transfer to the GMSC. The event is not reported to the SCP if the EDP has been armed in MT/SR-SMS Connect case. In that case the MSC/VLR disarms the request of the SCP. If the short message transfer to the SMSC is unsuccessful, the MSC reports an error back to the GMSC. The event is not reported to the SCP if the EDP has been armed in MT/SR-SMS Connect case. In that case the MSC/VLR disarms the request of SCP. When the MSC/VLR has received the Connect message with MTHeader (SMS DELIVER) , it delivers the MTSM to the mobile subscriber. After receiving the acknowledgement from the MS, the MSC reports the success or failure of the transfer to the SCP, depending on whether the EDPs are armed or not. When the MSC/VLR has received the Connect message with Status report-Header (SMS REPORT), it delivers the status report to the mobile subscriber. After receiving the acknowledgement from MS, the MSC reports the success or failure of the transfer to the SCP, depending on whether the EDPs are armed or not.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The SCP can also arm EDP s (of either notification or request type), or can request the monitoring mode. SM transfer is rejected if the SCP responds with the ReleaseCall message. The MSC/VLR does not forward the SM to the MS. Before sending the ReleaseCall message, the SCP can arm the EDP(s). It can also send FurnishChargingInformation message(s) but no IN CDR is created. For more information, refer to the feature description of Feature 910: IN Short Message Service . For further information, see Interworking between CAMEL SM and IN SM . Activation information can be found in Handling of IN SMS .
1.14
CAMEL short message service CAMEL (Customised Applications for Mobile network Enhanced Logic) is a tool to provide operator-specific services independently of the serving network. In CAMEL SMS there is a standardized CAP interface between the MSC and the SCP . In this case the subscriber can benefit from the services provided by the SCP even when roaming outside the HPLMN . With CAMEL improved control of MO-SM is possible. The VPLMN shall be able to detect a SMS set-up request and the CSE shall be able to modify the handling of the SMS set-up request. If the subscriber is provided with CAMEL based SMS MO service, at SMS set-up, the VPLMN suspends SMS processing, makes contact with the CSE and waits for further instructions. When the VPLMN has made contact with the CSE, the CSE is able to instruct the VPLMN to include information received from the CSE in charging records and/or to activate other control service events for the SM submission (Unsuccessful SM Submission). Once the CSE has concluded issuing the above instructions, it issues one of the following instructions:
dn98905102 Issue 5-0 en
.
bar the SM submission
.
allow the submission to continue unchanged
.
allow the SMS processing with modified information (called party number, calling party number, SMSC address)
# Nokia Corporation Nokia Proprietary and Confidential
65 (267)
SMS Guide
1.14.1
Control of MO-SM with CAMEL The following figure describes the relevant network elements and interfaces for the support of CAMEL control of MSC switched MO SMS.
HLR
gsmSCF
SMSC CAP
MAP
MS
MAP
VLR
SMSC SMRSE
IWMSC
gsmSSF A Interface
VMSC
gsmSCF:
GSM Service Control Function
gsmSSF:
GSM Service Switching Function
CAP:
Camel Application Part
Figure 24.
MAP
Functional architecture for the support of CAMEL control of MSCswitched MO SMS
The MO SMS State Model contains the service logic for CAMEL control of MO SMS. It is applicable from CAMEL 3 onwards. The MO SMS state model is activated when the subscriber sends a mobileoriginating short message.
66 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMS_Null_&_Start_& Authorize
SMS_Exception
DP SMS_Collected_Info
DP O_SMS_Failure
SMS_Analyse & Routing
DP O_SMS_Submitted
Figure 25.
O_SMS_Exception
MO SMS state model
The detection points (DPs) of the model:
Table 6.
DPs used for the MO SMS State Model
CAMEL DP
DP Type
Use of the DP
SMS_Collected_Info
TDP-R
Indication that the SMS-CSI is analysed and a mobileoriginating short message is received. The gsmSCF can control short message processing with the following operations: ConnectSMS, ContinueSMS, ReleaseSMS, ResetTimerSMS, RequestReportSMSEvent, FurnishChargingInformationSMS.
O_SMS_Failure
EDP-N EDP-R
O_SMS_Submitted
EDP-N EDP-R
Indication that the short message submission to the SMSC has failed. Indication that the short message has been successfully delivered to the SMSC.
For more information refer to feature description of Features 1148 and 1159: CAMEL Phase 3 .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
67 (267)
SMS Guide
Scenario of CAMEL mobile-originating short message
Home Network
HLR
gsmSCF
2.
VLR
1.
gsmSSF Setup MSC
MS
MO SMS outgoing leg Visited Network
Figure 26.
CAMEL mobile-originating short message
Preconditions: .
The SMS CSI has been provisioned for the A-subscriber.
Steps: 1.
The VMSC/VLR has noticed that the A-subscriber has the SMS-CSI, after which the VMSC makes the initial contact with the gsmSCF (through gsmSSF) in the SMS_Collected_Info DP of the MO-SM. The CAP operation InitialDPSMS is used.
2.
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ContinueSMS. In this example the destination number and the SMSC address are not modified. OR
68 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ReleaseSMS. In this case the MSC does not submit the MO-SM towards the SMSC. .
The SCP arms one or both EDPs (successful or failure). The type of the EDPs can be either notification (EDP-N ) or request (EDP-R ).
.
The SCP sends the FurnishChargingInformation message(s) related to the Connect or Continue message. When the MSC/VLR receives this message, it generates the IN CDR .
Scenario of CAMEL mobile-originating short message with modified destination
For the Scenario of mobile-originating short message with modified destination, see Figure Scenario of mobile-originating short message.
Note Please note, that step 2 of Scenario of CAMEL mobile-originating short message with modified destination differs from step 2 of Scenario of CAMEL mobileoriginating short message .
Precondition: .
The SMS-CSI has been provisioned for the A-subscriber.
Steps:
dn98905102 Issue 5-0 en
1.
The VMSC/VLR has noticed that the A-subscriber has the SMS-CSI, after which the VMSC makes the initial contact with the gsmSCF (through gsmSSF) in the SMS_Collected_Info DP of the MO-SM. The CAP operation InitialDPSMS is used.
2.
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ConnectSMS that instruct the gsmSSF to change the destination number. The short message is routed to the new destination.
# Nokia Corporation Nokia Proprietary and Confidential
69 (267)
SMS Guide
Scenario of CAMEL mobile-originating short message with notification of successful submission to gsmSCF
Home Network
HLR
gsmSCF
4
1
3
2
VLR
gsmSSF Setup MSC
MS
MO SMS outgoing leg Visited Network
Figure 27.
CAMEL mobile-originating short message with notification of successful submission to gsmSCF
Preconditions: .
The SMS-CSI has been provisioned for the A-subscriber.
Steps:
70 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.
The VMSC/VLR has noticed that the A-subscriber has the SMS-CSI, after which the VMSC makes the initial contact with the gsmSCF (through gsmSSF) in the SMS_Collected_Info DP of the MO-SM. The CAP operation InitialDPSMS is used.
2.
The gsmSCF arms the detection points O_SMS_Submitted and O_SMS_Failure in the notify mode (EDP-N) with the RequestReportSMSEvent operation.
3.
The gsmSCF sends the ContinueSMS or ConnectSMS operation. In this example the destination number and the SMSC address are not modified.
4.
When the O_SMS_Submitted DP is met (that is, the SM was successfully delivered to the SMSC), the gsmSSF sends the EventReportSMS (Notify and Continue) operation to the gsmSCF. After this the relationship is terminated. OR When the O_SMS_Failure DP is met (that is, the SM delivery to the SMSC was unsuccessful), the gsmSSF sends the EventReportSMS (Notify and Continue) operation to the gsmSCF. After this the relationship is terminated.
For more information, refer to the feature description of Features 1148 and 1159: CAMEL Phase 3 . SMS reference number
The SMS reference number makes it possible to correlate the SMS Call Detailed Records (CDR) produced by the MSC/SGSN with the SMS CDRs produced by the Service Control Point (SCP) for Camel Control of MO SMS.
1.14.2
Control of MT-SM with CAMEL The following figure describes the relevant network elements and interfaces for the support of CAMEL control of MSC switched MT SMS.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
71 (267)
SMS Guide
HLR
gsmSCF MAP
SMSC CAP
MS
MAP
VLR
SMSC SMRSE
GMSC
gsmSSF A Interface
VMSC
gsmSCF:
GSM Service Control Function
gsmSSF:
GSM Service Switching Function
CAP:
Camel Application Part
Figure 28.
MAP
Functional architecture for the support of CAMEL control of MSCswitched MT SMS
The MT SMS state model contains the service logic for CAMEL control of MT SMS. It is applicable from CAMEL 4 onwards.
72 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMS Null & Start & Authorize
DP SMS_Delivery_Request
SMS_Exception
DP T_SMS_Failure
SMS Delivery
DP T_SMS_Delivered
Figure 29.
T_SMS_Exception
MT SMS state model
The detection points (DPs) of the model:
Table 7.
DPs used for the MT-SMS state model
CAMEL detection point
DP type
Description
DP SMS Delivery Request
TDP-R
Indication that the MT-SMS-CSI is analysed and a mobile-terminating short message is received.
DP T_SMS_Failure
EDP-N
Indication that the SM delivery to the MS has failed.
EDP-R DP T_SMS_Delilvered
EDP-N EDP-R
Indication that the SM has been successfully delivered to the MS.
For more information refer to the feature description of Feature 1364: MT-SM for CAMEL Phase 4 .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
73 (267)
SMS Guide
Scenario of CAMEL mobile-terminating short message
Home Network
HLR
gsmSCF
2.
VLR
1.
gsmSSF Deliver MSC
MS
MT SMS outgoing leg Visited Network
Figure 30.
CAMEL mobile-terminating short message
Precondition: .
The SMS CAMEL subscription information (CSI ) has been provisioned for the B-subscriber.
Steps: 1.
The VMSC/VLR has noticed that the B-subscriber has the SMS-CSI, after which the VMSC makes the initial contact with the gsmSCF (via gsmSSF) in the DP SMS Delivery Request of the MT-SM. The CAP operation InitialDPSMS is used.
2.
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ContinueSMS. In this example the destination number and the SMSC address are not modified. OR
74 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ReleaseSMS. In this case the MSC does not submit the MT-SM towards the SMSC. The SCP arms one or both EDPs (successful or failure). The type of the EDPs can be either notification (EDP-N ) or request (EDP-R ). Scenario of CAMEL mobile-terminating short message with modified destination
Precondition: .
The MT-SMS-CSI has been provisioned for the B-subscriber.
Steps: .
The VMSC/VLR has noticed that the B-subscriber has the MT-SMS-CSI, after which the VMSC makes the initial contact with the gsmSCF (via gsmSSF) in the SMS_Delivery_Request DP of the MT-SM. The CAP operation InitialDPSMS is used.
.
The gsmSCF ends the dialogue with the gsmSSF with the CAP operation ConnectSMS that instruct the gsmSSF to change the Calling Party address. The short message is delivered to subscriber B.
Note The Called Party Address and the SMSC address can not be changed.
SMS reference number
The SMS reference number makes it possible to correlate the SMS Call Detailed Records (CDR) produced by the MSC/SGSN with the SMS CDRs produced by the Service Control Point (SCP) for Camel Control of MT SMS.
1.14.3
Interworking between CAMEL SM and IN SM IN Short Message Service (feature 910) has a proprietary functionality which is similar to the SMS part of CAMEL 3 and CAMEL 4. For more details, see IN short message functionality .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
75 (267)
SMS Guide
When the subscriber is roaming, CAMEL 3 CAMEL 4 are the features that can be active. When the subscriber is in the Home PLMN, the following case cases can be distinguished:
1.15
.
If the IN functionality MO DP is set for the subscriber, the IN MO functionality takes precedence over CAMEL 3. If you want CAMEL 3 to work for that subscriber also in the HPLMN, you have to set off Feature 910: IN Short Message Service MO DP for that subscriber.
.
When IN functionality MT DP is set for the subscriber, IN MT functionality will take precedence over CAMEL 4. If you want CAMEL 4 to work for that subscriber also in the HPLMN, you have to set off Feature 910: IN Short Message Service MT DP for that subscriber.
Short message routing Most of the operators have GSM network with more than one SMSC. This means that services offered by one SMSC are not the same as those offered by another SMSC. For example, one SMSC can be dedicated for MO-MTs and voice mail alert services, and another for e-mail, telefax, and for accessing service provider services (such as weather, stock market information), and so on. This is confusing for the subscribers, because if they want to use all the services, they should not only know many SMSC addresses, but also remember to change the address in the MS before using the services. A solution for overcoming this is to always use the same SMSC address in the MS, and to configure the VMSC in a way that the MO-SM is routed to the right SMSC in the PLMN. This is possible only if the MSC is able to solve the destination application from the MO-SM. The standard procedure for this is to use a PID (Protocol Identifier). The MML command for creating SMS routing analysis is CFE . For example, when sending an MO-SM, the subscriber selects the appropriate PID value (for example, telefax, X.400), after which the MSC should know in which SMSC the application exists.
76 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMSC1 for MS-to-MS messages normal MO-SMS
1
SMS-IWMSC1 1
1 2
fax MO-SMS
fax MO-SMS
2
2
VMSC
Figure 31.
SMS-IWMSC2
SMSC2 for fax and email messages
SMS routing
However, the PID alone is not enough, because there are applications which do not have PID values of their own. In the Nokia VMSC you can solve this by using a Service Application Prefix (SAP). The Nokia SMSC also uses this prefix to differentiate between the applications. Each application known by the SMSC has its own SAP. The SAP can be, for example, 991 for service provider applications, 992 for e-mail, 993 for telefax and so on. Note that in this way it is not necessary to change the PID value for e-mail or telefax. The subscriber gives the SAP in the beginning of the destination address, for example, weather reports could be requested by sending a message to address '991 1000'. In this case, 991 indicates the service provider application, and 1000 the service (here: weather reports). There is a table for MO-SM routing based on PIDs and/or SAPsin the MSC, and an MML for maintaining the table, as shown in the example below:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
77 (267)
SMS Guide
Table 8.
Example of a routing table
Service Application Name
PID
SAP
SAPTYPE
SMSC address
Tariff class
CIMD
991
international
443580002
1
FAX
52
993
national
443580001
3
E-MAIL
53
EMAIL
alphanumeric
443580001
4
E-MAIL
992
international
443580001
MT
0
443580003
DEFAULT
443589999
2
The fields of the table are interpreted in the following way: 1.
If a PID in the MO-SM has been defined in the table, use the SMSC address defined for the PID.
2.
If a SAP in the MO-SM has been defined in the table, use the SMSC address defined for the SAP.
3.
You can also set a default SMSC to be used and/or a tariff class for it in a case where no SAP or PID analysis is found. This could be used, for example, to make all the subscribers of a particular network use the operator's own SMSCs. If none of the above have been defined, use the SMSC address normally given by the subscriber.
If, for example, a PID is defined for fax only, the normal SMS functionality is not affected. Only faxes are handled in a different way, everything else is handled as if no PID/SAP analysis existed. When routing SMs from one MSC to another, you must be careful that a loop between MSCs does not occur. This could happen when the MSC1 routes messages to MSC2 which again forwards them to the MSC1. For more information on the relation of tariff classes and charging, see Charging of SMs to service applications .
78 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
One consequence of SMS routing is that when the SMSCs send MT-SMs, they all use individual SMSC addresses. However, they correspond to one logical SMSC address. This can cause problems with an MS if, when receiving status reports, it compares this MT-SMS address with the original address stored in mobile setup. This can be solved by configuring the SMSC address used towards subscribers in the SMS-GMSC . The same address that SMSC originally used in MT-SMS when setting the MWD must be used to make sure that alerts work correctly, that is, they are sent from the HLR to the correct SMSC. For more information see SMS management instructions in Configuring network elements for SMS , and Managing SMS network element-specific data . See also Working examples for SMS management . The following figure describes how SMSC address are used in MT-SMS between different network elements: SMSCA SMSC A
SMSCB
SMSCA SMS-GMSC
SMSCB
HLR
SMSC SMSC
SMSC B
Linetype Linetype
Figure 32.
VMSC
means SMS transfer from SMSCA means SMS transfer from SMSCB
SMSC address used in MT-SMS between different network elements
SMS routing analysis
The decision whether the SMS routing analysis is executed or not in the VMSC, depends on the availability of Feature 1165: GSM Phase 2+ Enhancements . The execution of the analysis in the SMS-IWMSC is unconditional if you have this function in use. If you have feature 1165 in use in your network, the SMSC address is analysed by invoking the SMS routing support analysis. This analysis indicates whether the SMS routing analysis should be executed or not.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
79 (267)
SMS Guide
If you do not have feature 1165 in use, the decision about executing the SMS routing analysis is entirely based on the roaming status information received form the VLR. The roaming status is determined from the IMSI of the subscriber in the VLR. If the roaming status is home network/home subscriber, the SMS routing analysis is invoked.
Note If the SMS routing support analysis function is not active, the VLR sets the subscriber's roaming status by reading the status of HPLMN and home country (HCOUN) from the result record in the PLMN-specific parameter file and sends it to the SMS application. If you set the home PLMNs in the PLMN-specific parameter file with the MXN command so that HPLMN=Y, HCOUN=Y, the roaming status will be 'HOME' despite the different network codes. This way the SMS routing analysis is executed for all home subscribers.
For further information, see Alphanumeric addressing of SMS-related applications .
1.15.1
SMS routing enhancements Routing of short messages is enhanced by: .
a change in the routing analysis
.
the use of alphanumeric addresses
Note MAP version 3 is needed for these functionalities. These enhancements are available if you have Feature 1165: Short Message Services, GSM Phase 2+ Enhancements in your network. For details, refer to the feature activation instructions of Feature 1165: Short Message Services, GSM Phase 2+ Enhancements .
There is a change in the logic which defines when the routing analysis (based on PID or SAP) applies for a short message. As the protocol identifier and SAP are tightly related to the SMSC's function, this feature enables you to define an SMSC address on the basis of which the routing analysis is executed. If you define a need for the SMSC routing analysis, the routing analysis is executed.
80 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The routing enhancement also enables you to define different routing rules for national, international and alphabetical destination addresses. Please note, that the alphanumeric destination address can be maximum 11 characters. The SAP analysis has to be defined separately for national, international and alphabetical addresses. Note that the length of not only the alphanumeric, but all the other destination addresses is extended. This results in further changes in the charging and statistics for alphanumeric addresses, and in the storage of numbers in the analysis files. For related information, see Activating routing enhancement in SMS .
1.15.2
Short message routing based on subscriber type If you have Feature 1598: SMS Routing Based on Subscriber Type in use, it is possible to reduce the load of the Intelligent Network (IN) platform node, by routing Short Messages (SMs) either to the Short Message Service Center (SMSC) or to the IN platform based on the subscriber type. The following figure shows a solution for routing SMs based on the type of the subscriber: GT analysis for Logical SMSC address DPC=IN platform Logical SMSC address remains SMSC address: Logical SMSC address
IN platform
MS Prepaid
SMSC1 SMSC address is changed to virtual SMSC address as this is the input of the load sharing algorithm.
SMSC address: Logical SMSC address
MS Post-paid
VMSC
Figure 33.
dn98905102 Issue 5-0 en
Application level or SCCP level load sharing is executed between SMSC1 and SMSC2.
SMSC2
Short message routing based on prepaid and post-paid subscribers
# Nokia Corporation Nokia Proprietary and Confidential
81 (267)
SMS Guide
By splitting the SM traffic of prepaid and post-paid subscribers, it is possible to route Mobile-Originated Short Messages (MO-SMs) from the Home Public Land Mobile Network (HPLMN) to the IN platform in case of a prepaid subscriber, or directly to the SMSC in case of a post-paid subscriber. To route SMs depending on subscriber type, it is necessary that only one logical SMSC address is used in the network, and that each subscriber is marked with the ICK (IN category key) parameter if they are prepaid or post-paid subscribers. The type of the subscriber is determined by checking the value of ICK parameter. If you use this feature, this value is shown in the Mobile-Originated Short Message Service Charging Records (SMMO CDR).
1.16
Sending SMS without SMSC If you have Feature 1633: Direct SM Delivery in use, it is possible to provide solution for direct SM delivery without the involvement of the Short Message Service Centre (SMSC ). This solution provides a considerable decrease in the load of the SMSC and also the MAP or SMRSE interface between the Mobile Services Switching Centre (MSC ) and the SMSC. In case of SMRSE SMSC, the load of the Interworking MSC (IWMSC) and the Gateway MSC (GMSC ) is also reduced. This feature is implemented in the Mobile-Originated Visited Mobile Services Switching Centre (MO-VMSC). If subscriber B is available and subscriber A is not roaming, the MO-VMSC can directly deliver the MO-SM by converting it to an MT-SM, and forwarding it to the proper Mobile-Terminated Visited Mobile Services Switching Centre (MTVMSC) after the Home Location Register (HLR) enquiry. In case of any error, the MO-VMSC forwards the MO-SM to the SMSC, and SM delivery is carried out in the traditional way. This solution also enables you to distinguish the direct SMs from normal SMs in the SMS measurement and in the Charging Data Records (CDRs). The decision on 'Non-store and forward' SM delivery without the SMSC is made as follows:
82 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.
The MO-VMSC receives a normal MO-SM from the subscriber.
2.
The SMS application executes the IN interaction (if needed), and the barring checking. It also checks if there is routing analysis for the Bnumber of the MO-SM. Depending on whether there is routing analysis for the B-number, the SM can be handled in the following ways: .
.
If there is analysis for the application terminated SM, the MO-SM is forwarded to the SMSC in the traditional way. If there is no analysis for the B-number of the MO-SM, the MSC delivers the SM directly.
It is possible to check the Service Application Name (SAN) to decide if direct SM delivery should be performed, if SMS routing analysis is used in the network also for MO-MT SMs (not just for MO-AT SMs). For more information about possible parameter setting, see the feature description of Feature 1633: Direct SM Delivery Direct SM delivery
When direct SM delivery is performed, the SMS application sends positive acknowledgement to the MS, which receives a 'Message sent' response. The SMS application also converts the MO-SM to an MT-SM, and starts the GMSC functionality. This means that the MSC makes the HLR enquiry and sends the Forward-SM MAP operation to the correct MT-VMSC. The MT-VMSC delivers the MT-SM in a normal way. If the MT-SM delivery is not successful, the MT-VMSC sends back a negative acknowledgement to the MT-GMSC/MO-VMSC. The MO-VMSC then forwards the SM to the SMSC. If DIRECT_SM_FAILURE_IND parameter is activated, the MO-VMSC sets the reserved value of Transport Protocol-Message Type Indication (TP-MTI) field in the SUBMIT-MO-SM. If the SMSC supports this functionality, it can handle the SM based on this reserved value as delayed delivery, and the next delivery attempt will be based on the SMSC retry table. If DIRECT_SM_STA_CHA_INFO parameter is activated, the SMSC address of the MO-SM is changed to the operator-predefined SMSC address, which allows that the SM delivered by the MSC can be differentiated from the normal SM in the statistics reports and charging data records. When the MT-SM arrives in the MT-VMSC, the SMS application checks the SMSC address. If the SMSC address of the MT-SM is the same as stored in the HRNFIL, the MT-SM is a DIRECTSM, which has to be indicated in the statistics and charging data records.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
83 (267)
SMS Guide
The following figures illustrate the SMSC with MAP interface including the Interworking Mobile Services Switching Centre (IWMSC ) functionality. If the SMSC has SMRSE interface, the IWMSC is a separate network element, and it is not affected by this feature.
4 1
13
3
2 12
5
11 MO-VMSC MT-GMSC
HLR 6
10
7 9
8
MT-VMSC
84 (267)
SMSC
1.
SUBMIT-MO-SM
2.
Checking SMS routing analysis (Application-terminated SM), and converting MO-SM to MT-SM (GMSC functionality invoked)
3.
SMS-SUBMIT-REPORT
4.
SRI-FOR-SM
5.
SRI-FOR-SM-ACK
6.
MT-FORWARD-SM
7.
SMS-DELIVER
8.
SMS-DELIVER-REPORT
9.
SMMT CDR, STATISTICS REPORT UPDATE
10.
MT-FORWARD-SM-ACK
11.
SMMT CDR from GMSC, STATISTICS REPORT UPDATE
12.
SMMO CDR from MO-VMSC, STATISTICS REPORT UPDATE
13.
MSC generates the status report, if it is requested
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Figure 34.
Successful SM delivery
1 3
4
14
5
2 11 MO-VMSC MT-GMSC
HLR 6
7
10
12
13
8
9 MT-VMSC
dn98905102 Issue 5-0 en
SMSC
1.
SUBMIT-MO-SM
2.
Checking SMS routing analysis (Application-terminated SM), and converting MO-SM to MT-SM (GMSC functionality invoked)
3.
SMS-SUBMIT-REPORT
4.
SRI-FOR-SM
5.
SRI-FOR-SM-ACK
6.
MT-FORWARD-SM
7.
PAGING
8.
No paging response (timer expires)
9.
SMMT CDR from MT-VMSC, STATISTICS REPORT UPDATE
10.
MT-FORWARD-SM-NACK
11.
SMMT CDR from MT-GMSC, STATISTICS REPORT UPDATE
12.
MO-FORWARD-SM to SMSC
13.
MO-FORWARD-SM-ACK
14.
SMMO CDR from MO-VMSC, STATISTICS REPORT UPDATE
# Nokia Corporation Nokia Proprietary and Confidential
85 (267)
SMS Guide
Figure 35.
Unsuccessful SM delivery, no paging response
4 1 3
6 5
2 9 MO-VMSC MT-GMSC
HLR 7
MT-VMSC
SMSC
1.
SUBMIT-MO-SM
2.
Checking SMS routing analysis (Application-terminated SM), and converting MO-SM to MT-SM (GMSC functionality invoked)
3.
SMS-SUBMIT-REPORT
4.
SRI-FOR-SM
5.
SRI-FOR-SM-NACK (subscriber in detach state)
6.
SMMT CDR from MT-GMSC, STATISTICS REPORT UPDATE
7.
MO-FORWARD-SM to SMSC
8.
MO-FORWARD-SM-ACK
9.
SMMO CDR from MO-VMSC, STATISTICS REPORT UPDATE
Figure 36.
86 (267)
8
Unsuccessful SM delivery, absent subscriber
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.17
SMS Forwarding Short Message Service Call Forwarding Unconditional (SMS CFU ) supports SMS forwarding either to an active subscriber or to a subscriber who is currently detached. If you have Feature 626: Supplementary Services Phase 2 Extensions in use, the subscriber can flexibly define the number to which the SM is forwarded. SMS forwarding is an HLR-feature, but MAP version 3 must be supported in the HLR. SMS CFU also works in situations where the subscriber receives an SM from a foreign PLMN.
1.17.1
Basic forwarded MT-SMS The following figure shows the basic forwarded MT-SMS functionality.
GMSC/ SMSC
VMSC
HLR-B
HLR-C
SendRoutingInfoForSM SendIMSI SendIMSIAck SendRoutingInfoForSM SendRoutingInfoForSMAck Inform-SC SendRoutingInfoForSMAck Inform-SC MT-ForwardSM MT-ForwardSMAck
Figure 37.
dn98905102 Issue 5-0 en
Basic forwarded MT-SMS functionality
# Nokia Corporation Nokia Proprietary and Confidential
87 (267)
SMS Guide
When subscriber A sends an SM to subscriber B, this SM can be forwarded to subscriber C under the following conditions: .
subscriber B has SMS CFU active to subscriber C
.
the feature is active in subscriber B's HLR
.
SMS forwarding is allowed to subscriber C's network. Subscriber C must belong to the same network with subscriber B or to one of the additional networks defined by the operator.
The subscriber C's HLR should also support the SMS forwarding feature. Otherwise there are some restrictions in the functionality, especially when subscriber C is not reachable. For more information, see the feature description of Feature 626: Supplementary Services Phase 2 Extensions . The maximum number of forwardings is one. This means that subscriber B can forward the SMS to subscriber C, but subscriber C is not allowed to forward it further. The procedure is the following: 1.
HLR-B receives SendRoutingInfoForSM operation.
2.
It notices that subscriber B has CFU active and the request should be forwarded to HLR-C.
3.
Before forwarding, HLR-B checks that forwarding is allowed to the destination PLMN by requesting subscriber C's IMSI from the HLR.
4.
If forwarding is allowed, SendRoutingInfoForSM is sent to HLR-C.
5.
HLR-C acknowledges the operation to the GMSC with subscriber C's information.
The Inform-SC operation contains the MSISDN-C number, and inform-SC is always sent from HLR-C. Exceptions:
88 (267)
1.
Subscriber C is in a PLMN where forwarding is not allowed. In that case the SM is sent to subscriber B, and not forwarded to subscriber C. This can happen if subscriber C has changed the operator after subscriber B has registered SMS CFU to subscriber C.
2.
If the SMSC does not support the Inform-SC procedure, MSISDN-C is not stored in the SMSC. This kind of situation causes problems if subscriber C is unreachable and then becomes reachable again.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.17.2
Provisioning and activating SMS forwarding SMS CFU is provisioned and activated separately from CFU. This means that if CFU is provisioned or activated to all basic services by using MML commands, this does not include SMS forwarding. You can give SMS at the same time with the provision of CFU or add CFU for SMS afterwards. If you give CFU for SMS, and the subscriber does not have CFU, then the HLR automatically provides CFU for the subscriber. It is not possible to provide CFU only for SMS. It is also not possible to remove SMS CFU separately, but the complete CFU must be removed. Create SMS basic service to the subscriber before provisioning SMS CFU, otherwise the command fails with error code 'Teleservice not provided'.
1.17.3
MMI procedures to activate SMS forwarding The subscriber can manage SMS CFU by using the MMI of the mobile station (MS). If the MS understands these MMI strings (for example, activate, register), they are sent as GSM standard supplementary service operations. If the MS does not support these service codes, the subscriber cannot manage the service with the MS. The following MMI procedures can be used:
1.18
.
**21*nbr*16# (RegisterSS)
.
*21**16# (ActivateSS)
.
##21**16# (EraseSS)
.
#21**16# (DeactivateSS)
.
*#21**16# (InterrogateSS)
Same CLI for multiple subscribers If you have Feature 1541: Same CLI for Multiple Subscribers in your network, it is possible that several mobile phones (IMSIs) use a common MSISDN number when originating calls (voice or data) or sending short messages. The phones can belong to one or more users. The HLR stores the subscriber (IMSI) -related data under the so-called 'own MSISDN' number. In the HLR, each subscriber has its own record, which is extended with an attribute. This attribute contains the 'common MSISDN' number. The own MSISDN number is a unique identifier, whereas the common MSISDN number can belong to several records.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
89 (267)
SMS Guide
The primary phone has the same own and common MSISDN number. In case of an HLR query with the common MSISDN number, the primary IMSI-related data is retrieved and included in the response of the transaction. This means that the short messages sent to the common MSISDN will reach the primary phone. Depending on the visited PLMN's capability, either the own MSISDN number or the common MSISDN number is transferred to the VLR/SGSN during a location update as primary identifier (preconfigurable in the HLR). As an option, the CLI restriction service can be set to hide the own MSISDN number in permanent mode if the PLMN does not support storing many records with the same MSISDN number in the same VLR/SGSN. The CLI restriction, however, has no effect on the 'CLI' included in MO-SM. Even if the common MSISDN is used as the primary identifier, the own MSISDN number is still sent to the VLR as a normal subscriber attribute (in a proprietary extension). The usage of Same CLI for multiple subscribers feature can have effect on SMS based services. When the user sends short message from the non-primary phone (the own MSISDN is different from the common MSISDN) to a service center requesting some content (for example, exchange info, train timetable), the server responds to the received originating MSISDN (the common MSISDN) and the response SM finally goes to the primary phone.
1.19
Sequential alerting and parallel alerting for MultiSIM Service MultiSIM is a service that makes it possible to group several individual subscriptions behind the same Mobile Subscriber International ISDN Number (MSISDN). The MultiSIM service comprises of the combination of the following features: Same CLI for Multiple Subscribers, Sequential Alerting, and Parallel Alerting. The Same CLI for Multiple Subscribers feature makes it possible for several subscribers to use a common MSISDN in mobile-originating transactions. The features Sequential Alerting and Parallel Alerting make it possible to terminate speech calls to a group MSISDN sequentially (in a user definable order) or simultaneously alerting the phones (SIMs). This service is applicable only to voice calls and data calls in case of sequential alerting. Other mobile-terminating transactions with the ringing group MSISDN are delivered only to a dedicated member called primary member.
90 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
For more information about the functionality, see Feature 1545 and 1576: Sequential and Parallel Alerting.
1.19.1
Delivery of mobile-terminating short messages MT-SM to the ringing group number is delivered only to the primary phone if the primary member exists, otherwise the MT-SM fails due to the absent subscriber. Delivery status report for MO-SMs from any of the phones normally goes to the primary member, when the common MSISDN number is delivered to the MSC/ VLR and it identifies a ringing group. The members of the ringing group can also be considered as individual subscribers. MT-SMs to their member MSISDN are delivered only to the specific member. It is possible to restrict the mobile-terminating speech calls and MT-SMs with the member number.
1.19.2
MT-SMS routing to the primary member There are two alternative methods to route SMS to the primary member: 1.
an internal method which is not visible to MAP level
2.
SMS forwarding mechanism of Feature 626: GSM Supplementary Services Phase 2 Extensions
The SMS Forwarding mechanism requires that Feature 626: GSM Supplementary Services Phase 2 Extensions is in use. If that feature is not in use, then the internal method is the only possibility. In the internal method, the Message Waiting Data (MWD ) is stored into the group subscriber data. A new flag: Mobile Not Reachable Multi (MNRM) is stored into the primary member data to indicate that there is MWD in the group subscriber data. In the SMS Forwarding mechanism, the group subscriber in MultiSIM service uses the MSISDN of the primary member in the same way as c-number of SMS Call Forwarding Unconditional (CFU). The functionality of the primary member is exactly the same as the functionality of C-subscriber in case of SMS CFU. MWD is stored into both the group subscriber and primary member data.
1.20
Short message charging It is possible to collect charging data for both the MT-SMS and MO-SMS in the VMSC , the SMS-GMSC , and the SMS-IWMSC . Traffic administration can collect SMS data in the VMSC, SMS-GMSC and SMS-IWMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
91 (267)
SMS Guide
If Feature 619: Short Message Service Enhancements is in use in your exchange, you can create different charging cases for different short message services. These include charging of roaming subscribers, charging based on subscriber's IMSI, charging of SMs created by applications, charging of command SMs and status reports between MS and SMSC, as well as charging of SMs to service applications such as fax and e-mail. The different charging cases are explained below. If charging is concentrated in the SMS-IWMSC/SMS-GMSC, the amount of CDRs generated in the VMSC can be limited. You can use the commands of Detailed Charging Handling GT command group to control SMS-related charging. For operating instructions and descriptions refer to Charging Handling . Charging records (CDRs)
The SMS-related CDRs are the following: .
SMMO CDRs (for mobile-originating SMS)
.
SMMT CDRs (for mobile-terminating SMS)
.
SMMF CDRs (for forwarded SMS)
.
IN CDRs (for IN SMS)
Operators usually charge the subscribers for short messages on the basis of the MO-SM CDRs. However, the majority of the billing information can also be obtained from the MT-SM CDR. The most important exception to this is when MO-SMs are being sent to a service application. In this case, the MO-SM CDRs are the only place to charge, since these SMs do not contain an MT-SM part, and thus no MT-SM CDR is generated. For further information, see Charging of SMs to service applications . In addition, the CDRs contain information such as:
92 (267)
.
tariff class
.
calling IMSI
.
called IMSI
.
calling VMSC number
.
called number
.
SMS length
.
dialled number
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Note If the subscriber B number is wrong, the called number field in the SMS-IWMSC is empty, while the dialled number field is filled.
.
SMS type
.
picture message
.
routing category
SM status request indication can also be included in the MO-SM CDRs, that is, you can apply different charging for mobile-originating short messages without having separate MT-SM CDRs for status reports if the subscribers wishes to receive a status report about whether their SMs were delivered to subscriber B or not. The SMS type field contains information about whether the SM is: .
MO-SM
.
mobile-originating command short message
.
MT-SM
.
mobile-terminating status report
.
mobile-originating message status report requested
.
forwarded short message
.
special SM (Welcome SM, Direct SM, Trigger SM)
The CDRs also include information on concatenated short messages and picture messages. In case of concatenated short messages, it is possible to generate CDRs only for the first SM by setting the 031:0028 PRFILE parameter on. Generating CDRs only for the first SM in a concatenated short message substantially decreases the load of both the network and the billing centre. The routing category can be defined separately for each subscriber, and this information in the CDR can be used, for example, to distinguish between prepaid and postpaid subscribers. The charging data record for MO-SMs has a new field dialled_digits_TON to indicate the dialled alphanumeric number type. If the dialled number is not of alphanumeric type, the value of this field is unknown. For related information, see Alphanumeric addressing of SMS-related applications .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
93 (267)
SMS Guide
The following fields can have alphanumeric value in the SMMO CDR: .
dialled_digits
.
called_number
The SMSC application can send MT-SM when the originating address (A number) is of alphanumeric type. The MSC/VLR supports this function and generates SMMT and SMMF CDRs.
Note In the SMMO CDR there is a VMSC address field indicating through which VMSC the SM is sent. However, if SM rerouting takes place, note that in the SMMO CDR created in the second SMS-IWMSC this field contains the previous SMS-IWMSC address instead of the VMSC address.
For more information on CDRs in general, see CDR Field Description, Interface Specification and MSC/HLR-BC, Interface Specification. For more information on CDR improvements see the feature descriptions of Feature 619: Short Message Service Enhancements , and Feature 1043: Short Message Services GSM Phase 2+ . Selective CDR generation in the Transit MSC (TSC)
Nowadays, the TSC (which means here the SMS-IWMSC and SMS-GMSC) generates CDRs for all the MO-/ MT-SMs. In case of SMs originating and terminating in the same PLMN, the same CDRs are generated in the visited MSC and TSC (for subscriber A and subscriber B ). You can reduce the CDR generation by using an option in the TSC (SMS-IWMSC and SMS-GMSC) by allowing CDR generation only when they are really needed, that is, for subscriber charging and/or inter-operator accounting. It means that if the optional FIFILE parameter 031:0026 TRANS_SEL_CDR_GEN is turned on, the TSC (SMSIWMSC and SMS-GMSC) does not generate CDRs for the MO-/MT-SMs which come from or go to the same PLMN. This way you can decrease the load of both the network and the billing centre.
94 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Note You can control the MO-SM and MT-SM CDR generation separately with the direction parameter. This means, that by defining the SMSC address, it is possible to suppress either the MO-SM CDR generation, or the MT-SM CDR generation only, or both at the same time. This results in a decrease of load in the MSC/billing centre.
Selective CDR generation based on SMSC address
Charging Records (CDRs) can be suppressed depending on the SMSC ISDN address. You can control the MO-SM and MT-SM CDR generation with MML commands. The following table shows from which network elements the CDRs can be controlled:
Table 9.
Types of CDR and network elements
Type of CDR
Network element from where it can be controlled
MO-SM CDR
VMSC, SMS-IWMSC
MT-SM CDR
VMSC, SMS-GMSC
MF-SM CDR
VMSC
In connection with this functionality, a new SMSC address analysis is needed in the MSC to decide whether the MO-SM or the MT-SM CDR is barred or not. For related information, see Activating selective CDR generation in SMS .
1.20.1
SMS charging for subscribers Improvements made in charging data transfer enable you to perform different types of charging, depending on whether the subscribers are roaming in different network elements, and on what services they are using. You can also charge different value-added applications that use MS services.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
95 (267)
SMS Guide
SMS charging for mobile subscribers
If feature 327 is in use in your exchange, the charging implications include an option to make detail record of MO-SMs (both in the VMSC and the SMSIWMSC and MT-SMs (both in the SMS-GMSC and the VMSC). For more information, see the feature description of Feature 327: Short Message Services . Both MT-SMs and MO-SMs can be charged in the VMSC , SMS-GMSC and SMS-IWMSC , and the traffic administration can collect SMS data in all of them. For more information, see Feature 619: Short Message Service Enhancements . You can choose how to perform SMS charging by following steps given below. .
Create a CDR for all normal SMs which are sent (excluding SMSCOMMAND and STATUS-REPORT).
.
Create a CDR for only those normal SMs which were sent successfully (excluding SMS-COMMAND and STATUS-REPORT).
.
Create a CDR for all SMS-COMMAND SMs which are sent.
.
Create a CDR only for SMS-COMMAND SMs which were sent successfully.
.
Create a CDR for all SMS-STATUS-REPORT SMs which are sent.
.
Create a CDR only for SMS-STATUS-REPORT SMs which were sent successfully.
Furthermore, if charging is concentrated in SMS-IWMSC/SMS-GMSC, you can set the CDR to be created in the VMSC for roaming subscribers only. .
Create a CDR only for roaming subscribers for all SMs which are sent (including SMS-COMMAND and STATUS-REPORT).
.
Create a CDR only for roaming subscribers for only those normal SMs which were sent successfully (including SMS-COMMAND and STATUSREPORT).
SMS charging for roaming subscribers
Roaming subscribers cannot be charged according to their location unless information is transferred on subscriber A's location (VMSC address) in the MTSM CDR . In the SMS-IWMSC, subscriber A's VMSC address is transferred to the SMSC which further transfers it to a SMS-GMSC, where the address is added to the MT-SM CDR. The billing centre can now analyse at least the networks where the subscriber is roaming, or, if both are located in their own networks, the
96 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
MSCs where the subscribers are located. An analysis of the MO-SM CDR is no longer needed. Adding subscriber A's VMSC field in the MT-SM CDR allows determining extra charges for an MO-SM sent from a subscriber roaming outside the subscriber's own network. Note that the availability of a VMSC address depends on the network configuration. If signalling point addressing is used on the SCCP level, the VMSC address cannot be obtained. On the other hand, cases like this are likely to happen only within one's own network. Inter-network addressing is usually based on global title addresses, and VMSC addresses are available. SMS charging based on subscriber's IMSI
Charging can generally be based on IMSI rather than MSISDN address. In MTSMS a subscriber's IMSI is available both in the SMS-GMSC and the VMSC . In MO-SMS in case of MAP version 2 , IMSI is not available in the SMS-IWMSC. It is possible for SMS-IWMSC to fetch the subscriber's IMSI from the HLR by using MAP phase 2 operation send_IMSI if you have feature 619 in use. In case of MAP version 3 the VMSC sends the IMSI to the SMS-IWMSC through the MO-Forward-SM operation. Feature 619 makes it possible for you to control whether IMSI is sent to the SMSC for charging purposes. You have to set the CHARGING_BASED_ON_IMSI PRFILE parameter on to determine whether the IMSI of a subscriber is used for charging purposes within the SMS. You can find a list of parameters in SMS-related general parameter file (PRFILE/FIFILE) parameters .
1.20.2
Charging of SMs generated by applications To avoid constant changes in configurations, information on new tariff classes is added to the MT-SM CDR . The SMSC transfers tariff classes to the SMSGMSC, where they are added to the MT-SM CDR. The billing centre can now set the fee by using tariff classes which have been defined only once for both the SMSC and the billing centre. New services with different origins can easily be added because the fee can be determined on the basis of tariff class information. The following figure shows the charging of SMs generated by applications.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
97 (267)
SMS Guide
HLR Application
SRI
SMSC
2 SMS-GMSC
VMSC
MT-SMS 1
3
Tariff Class
ForwardSM
MT-SMS 4
Tariff Class -> MT-CDR
Figure 38.
Charging of SMs generated by applications
The tariff class field makes it easier to add new service applications without having to define them in the billing system.
1.20.3
Charging of SMs to service applications The MO-SM routing analysis in the MSC is useful also for charging purposes. The MO-SMs to different applications can have different prices, for example, an MO-SM to another MS can be charged quite low, while an MO-SM to a telefax address can be much more expensive. The tariff class is included in the MO-SM CDR . The use of prefixes for charging can be useful, for example, in case of short messages sent to Wireless Applications Protocol (WAP) servers. In this case, charging can be determined on the basis of the prefix associated with the relevant WAP application. If no tariff class has been defined for a certain PID /prefix, it is not sent to the charging applications. Neither the PID nor the prefix are sent to charging applications. SMs to applications are charged according to the MO-SM CDRs, and SMs to MSs are charged according to the MT-SM CDRs.
98 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Note that some of the new parameters are optional, and not carried in all interfaces. Therefore, they are not necessarily available for charging and statistical purposes in every MSC/VLR. To be able to charge subscribers sending SMs to different services (users) from different locations, note the following suggestions on the configuration:
1.20.4
1.
A PID and/or a prefix analysis with a tariff class is created for every application service for an MO-SM. Charging of these SMs is handled from the SMS-IWMSC/VMSC CDRs.
2.
Separate charging can be created for SMS commands by transferring the SM type 'command' to the charging application in the SMS-IWMSC/ VMSC.
3.
MT-SMs generated by an application service are charged from the SMSGMSC if a tariff class has been received from the SMSC.
4.
Normal MS-to-MS SMs are charged from the SMS-GMSC of the MTCDR. The fee can be determined by comparing subscriber A's VMSC address with the SMS-GMSC address, and/or by comparing subscriber B's VMSC address with the SMS-GMSC address.
Charging of CAMEL SMs The CAMEL service at the SCP can create special CDRs for SMs containing free format data by FCI operation. These can be used for billing the subscriber by the service based at the billing center. In case of a prepaid service, the SCP manages the billing, and the call time of the subscriber is restricted in the SSP according the instructions of the SCP. When the gsmSCF modifies the subscriber number, the modified number is used in CDRs. For background information see CAMEL short message service . CDR generation in CAMEL SMS
SMMO CDR is generated for originated SM. In CAMEL 2, IN4 CDR is used already in call related cases. In CAMEL 3, the maximum length of FCI data raises from the current 40 octets to 160 octets, and the new IN5 CDR is introduced. New CDR Fields IN5 CDR includes the same fields as IN4 CDR. Fields to which the information is not available are filled with FF's (CAMEL_CALL_REFERENCE, CAMEL_EXCHANGE_ID, CAMEL_EXCHANGE_ID_TON AND PARTY_TO_CHARGE).
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
99 (267)
SMS Guide
DEFAULT_SMS_HANDLING and CAMEL_SMS_MODIFICATION fields are added to SMMO CDR. Default SMS Handling parameter indicates what happened, if, for example, the gsmSCF was not available and whether CAMEL encountered default SMS handling. This flag is set ON when gsmSCF connection fails, but the event is not cleared. CAMEL SMS Modification indicates the parameters that CAMEL has modified. These are the following:
1.20.5
.
calling number
.
destination subscriber number
.
SMSC address
.
SMS Reference number
MO-SM fraud prevention You can allow real charging information to be forwarded from the SMS application to charging application with the CHAR_WITHOUT_ACK_TO_MS PRFILE parameter even if a release message has been received from the MS before the acknowledgement from the SMSC. The release message can be received if the subscriber, for example, removes the battery from the MS (or in some mobiles, pushes the 'red button') right after sending an MO-SM. If the parameter has a TRUE value, the SMS application ignores the release message from the MS and waits for the real result of the MO-SM, which is sent towards the charging application. In case of a FALSE value, the SMS application informs the charging application about the MO-SM being unsuccessful even if it is delivered successfully to the SMSC. You can find a list of parameters in section SMS-related general parameter file (PRFILE/FIFILE) parameters .
1.20.6
Mobile number portability solutions for MO-SM charging If Mobile Number Portability (MNP ) is used in the network, the B-MSISDN number does not specify the destination network of an SM and therefore not enough for charging purposes. If you want to offer different prices based on the mobile service provider of the called party in case of MNP, B-IMSI number needs to be put into the SM-MO CDR, since only this number can identify the network of the B subscriber.
100 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
If you have Feature 1641: B-IMSI retrieval in MO side for MNP in use in your network, you can charge differently the MO-SMs which are sent to home or to different networks. For this, the SMS application (which runs in MO-IWMSC) has to initiate a SEND_IMSI MAP operation to retrieve the B-subscriber's IMSI number because of the MNP service. B-IMSI is written into the SMMO_CDR as follows: 1.
When a SUBMIT MO-SM arrives to the IWMSC and the feature is active, SMS application checks the SMS routing analysis to decide if the MO-SM is application terminated SM, or MS to MS SM.
2.
If the MO-SM is not application terminated SM, the SMS application initiates SEND_IMSI operation with the B-MSISDN number to get the IMSI number of subscriber B through the SRRi towards the HLR. For more information, see the feature description of Feature 1641: B-IMSI Retrieval in MO side for MNP.
3.
When the response arrives from HLR, the received B-IMSI is written into the SMMO-CDR.
When MAP version 2 is in use between the network elements, then A-IMSI is not transferred from MO-VMSC to MO-IWMSC. So double SEND_IMSI operations must be done in MO-IWMSC to gain both IMSIs for charging purposes.
Note The functionality is implemented in MO_IWMSC.
1.21
SMS-related statistics The following statistical reports and functions provide SMS-related statistical information:
dn98905102 Issue 5-0 en
.
SMS measurement
.
service measurement
.
MSC SMS observation report
.
MAP measurement
# Nokia Corporation Nokia Proprietary and Confidential
101 (267)
SMS Guide
.
Rejected Calls Observation Report
.
Traffica
SCP visit preventions are shown in IN service gapping measurement. SCP visits can be seen in INAP measurement as protocol level events. Detailed information on statistics on SMS can be found in NSS Statistics , and in NSS Statistics, Reports (ASCII, Binary) .
1.21.1
SMS statistics in the MSC SMS measurement
If you have Feature 1165: Short Message Services, GSM Phase 2+ Enhancements in use in your network, you can use SMS measurement. There are statistical counters for the number of mobile-terminating short messages (including welcome MT-SMs) coming from a certain SMSC and for the number of MO-SMs going to a certain SMSC. This can be used, for example, for filtering the misuse of SMs by easily recognizing SMSCs frequently used by the subscribers. You can check whether, for example, a foreign PLMN's SMSC is frequently used by roaming subscribers or it is misused by their own subscribers. In the latter case you can define the appropriate barring to avoid bulk short messages. You can use this functionality if you have the SMSC connected through MAP (in the VMSC function), or if you have the SMSC connected through SMRSE (both with X.25 and TCP/IP). This measurement counts the successful and unsuccessful MO-SMs and successful and unsuccessful MT-SMs according to SMSC address. In the MT-SM unsuccessful cases it can be either temporary or permanent. The measurements include welcome MT-SMs. Welcome MO-SMs are separately counted. However, welcome MT-SMs are included in the MT-SM counters, because they are seen by SMSC as ordinary MT-SMs.
Note The measurement of the Welcome SMs means the Welcome MO trigger SM count. For more information on welcome MO-SMs and welcome MT-SMs, see Welcome SM to the roamer .
102 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
The Real Time trigger functionality can be seen in the Field Reporting Service Measurement as TSMS Triggered SMS IWMSC. The facility is available only in the IWMSC. Furthermore, this SM can be seen in the SMS measurement as well, in the IWMSC part by the Logical SMSC address. In the GMSC the SMS measurement also shows the SM sent without the SMSC in a separate object. In the MT-VMSC the SM is indicated as a normal MT-SM again. If direct SM delivery fails, the SM is delivered to the SMSC and this SM is counted in the SMS measurement. In normal cases the logical SMSC address is visible in the MO-VMSC/MTVMSC. In the GMSC a new counter, MSC DELIVERED SM, shows the number of directly delivered SMs. MOBILE TERMINATING SHORT MESSAGES IN GMSC PHYSICAL SMSC SUCCESSFUL TEMP FAIL 945387587 22564 344 945853123 675 5 940020001 2567 78 MSC DELIVERED SM 21202 5222
PERM FAIL 23 1 0 3224
However, if the parameter DIRECT_SM_STA_CHA_INFO is activated, the predefined SMSC address (defined by the operator) can be seen in the MOVMSC/MT-VMSC. The SMSC address appearing in the ASCII, binary, and XML reports can be either SMSC-GT-1 (logical SMSC address given by the subscriber) or SMSCGT-2 (physical SMSC address resulting from the SMS routing analysis) or both. In case of the IWMSC the physical SMSC address means an IP (either IPv4 or IPv6) or an X.25 address. IP version 6 addresses, which can be used for TCP/IP connection between the SMS-IWMSC and the SMSC, are also included in the SMS measurement report. The successful and unsuccessful SM transactions can also be counted through links with IPv6 addresses. The report can contain measurements for maximum 5 x 50 SMSC addresses. There are 50 SMSC addresses in each type of MSC (for VMSC-MO (logical), VMSC-MT (physical), IWMSC-MO (logical), IWMSC-MO (physical) and GMSC-MT (physical) cases). You can define maximum five SMSC addresses in each type of MSC in the measurement with an MML command (see also Destination Object Lists, TD MML command group. Note, that there is one exception: you cannot define measurement with MML commands for MO-SM with SMSC link addresses. The maximum number of SMSC addresses in a given type of MSC is 49. The 50th record indicates all the other SMSC addresses. This means that if, for example,
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
103 (267)
SMS Guide
you define 5 SMSC addresses, the measurements of 44 other SMSC addresses is indicated separately in the reports depending on their actual use (giving altogether 49 SMSC addresses). If there are 100 SMSC addresses used in an hour, the 50th record will add up the number of SMs of the remaining 51 SMSC addresses. Please note, that the counters for the successful SMs are updated for the clear code of 0x0. The following table lists the clear codes that are involved in updating the counter for temporary failed and permanently failed SMs.
Table 10.
Clear codes involved in SMS measurement counter update
Clear codes for temporary failed SMs
Clear codes for permanently failed SMs
0x5 cd_t_b_subscriber_busy
0x250 cd_t_a_not_sc_subscriber
0x10 absent subscriber
0x300 cd_t_restrict_in_out_direction
0x12 cd_t_no_paging_response
0x301 cd_t_oper_restr_in_out_direct
0x304 cd_t_b_line_out_of_service
0x312 cd_t_tele_serv_not_prov
0x316 cd_t_memory_capacity_exceeded
0x313 cd_t_illegal_subscriber
0x405 cd_t_err_req_from_co_process
0x314 cd_t_unidentified_subscriber
0x407 cd_t_err_answer_from_co_process
0x319 cd_t_illegal_subscriber_station
0x40C cd_t_map_congestion
0x410 cd_t_gt_analysis_failed
0x603 cd_t_no_response_from_co_process
0x509 cd_t_file_error
0x60B cd_t_overload_congestion
0x7FF cd_t_initialization_value
0x60E cd_t_unit_restarted
0x812 cd_t_map_failure
0x815 cd_t_ciphering_not_succeeded
0xD04 cd_t_subs_sig_protocol_error
0x810 cd_t_facility_not_supported
0xD11 cd_t_invalid_ie_content
0x811 cd_t_network_failure 0x850 cd_t_sc_congestion
For the activation and deactivation information of this measurement see the command descriptions of Measurement Handling, T2 command group, and Activating SMS measurement . For more information on reports, see referential material NSS Statistics, Reports (ASCII) . Additional information on XML reports can be found in the feature description of Feature 1258: XML File Format for Statistics . MSC Observation Report
The MSC SMS observation report contains the following blocks:
104 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
heading information (similar in all phase 2 trace reports)
.
subscriber data
.
information on the short messages
Depending on the invoking event, certain report fields can be missing. This is due to the fact that the statistical program block only fills in the fields for which the required information is available at the moment the report is generated. If the parameter of a specific report line does not have a value, the line is not printed out at all. The report contains the following new information: .
RECEIVED SMSC ADDRESS: the logical SMSC address, which is given by the subscriber in MO-SM.
.
CAMEL MODIFICATION: the called/calling number or the used SMSC address can be modified by the gsmSCF in case the gsmSCF has controlled SMS processing with CAP operations. If any of them is modified, it is indicated here.
.
CELL BAND: the band of the cell (GSM/DCS/WCDMA)
.
RNC ID: shows the identifier of the Radio Network Controller. It contains valid information if the Radio System is UMTS.
.
BSC ID: shows the identifier of the Base Station Controller. It contains valid information if the Radio System is GSM.
.
ROUTING CATEGORY: stands for the routing category of the subscriber
.
ROUTING CATEGORY+: stands for the additional routing category of the subscriber
.
Two new fields for the Type Of Number (TON) of the called and dialled (address) number. These numbers can be alphanumeric.
.
The radio system to/from where the subscriber sends/receives the SMS.
.
MCC and MNC are added to the cell identifier
.
SMS reference number (MO-SM).
Note This report is available only if you have Feature 593: GSM Phase 2 Trace in your network.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
105 (267)
SMS Guide
For more information, see NSS Statistics, Advanced Guide and NSS Statistics, Reports (ASCII) . MAP measurement
MAP measurements provide information about SMS usage. See instructions and descriptions on NSS Statistics . Rejected calls observation report
In the rejected calls observation report the services can be observed per computer unit. These reports contain the following data: .
incoming service requests
.
the percentage of service requests rejected because of overload control
.
the number of rejected service requests
See also referential material NSS Statistics, Reports (ASCII) . Service measurement
Service measurement gives information on the usage of SMS. MO-SMs are further separated to show SMs coming from the VMSC , SMS-IWMSC, or from the TRANSIT MSC. MT-SMs are further separated to show SMs handled in the VMSC or SMS-GMSC. The SMS service measurement includes field reports. The field reports contain the following measurement data: .
facility name
.
usage times
The SMS-related subscriber facilities are the following:
106 (267)
.
T21..SHORT MESSAGE MT GMSC representing the SMSC -SMSGMSC interface in MT-SM.
.
T21..SHORT MESSAGE MT VMSC representing the VMSC - MS interface in MT-SM.
.
T22..SHORT MESSAGE MO VMSC representing the MS- VMSC interface in MO-SM.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
T22..SHORT MESSAGE MO IWMSC representing the SMS-IWMSC SMSC interface in MO-SM.
.
T22..SHORT MESSAGE MO TRANSIT representing the SMS-IWMSC SMS-IWMSC interface in MO-SM.
Traffica in SMS statistics
Note This functionality is available only if you have Feature 939: MSC Support for Real Time Reporting in your network.
Through Traffica, a detailed report is sent if the following conditions are met: .
the SM is sent form the VMSC
.
the SM is forwarded
.
the SM is sent from SMS-IWMSC or SMS-GMSC governed by parameter (if the VMSC is not in the same network)
For detailed information see the feature description of Feature 939: MSC Support for Real Time Reporting and Traffica product description.
1.21.2
SMS statistics in the HLR Information on SMS statistics in the HLR can be obtained from HLR measurement and HLR observation report. HLR measurement
Field reports contain the following measurement data: .
T21..ATTEMPTED REQUEST FOR SM ROUTING INFORMATION
.
New SMS CFU counters are added to the basic services. The new counters are visible only if the feature is active.
See also referential material NSS Statistics, Reports (ASCII) .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
107 (267)
SMS Guide
HLR observation report
The HLR subscriber observation report shows the types of the HLR operations that have been carried out by the subscriber under observation. The HLR observation report is printed after the following events: SRI for SM, ready for SM, and alert service center. The HLR subscriber observation report contains the following blocks: .
heading information (similar in all phase 2 trace reports)
.
subscriber data, such as MSISDN or IMSI
.
location update information
.
information on the use of basic services
.
information on the use of supplementary services (the type of action, the name of the service and the time)
.
result of the operation that caused the report
.
information on the use of short message services
.
new routing category
Note This report is available only if you have Feature 593: GSM Phase 2 Trace in your network.
See also referential section NSS Statistics, HLR Observation. For detailed information refer to feature description of Feature 593: GSM Phase 2 Trace .
1.22
Network elements involved in SMS The network elements involved in SMS are SME , SMSC , VMSC , VLR , SMSGMSC , SMS-IWMSC , and HLR . Note that SMS-GMSC and SMS-IWMSC are functional roles that a single DX 200 MSC can fulfil. SGSN is also involved if the SM delivery takes place through the GPRS network.
108 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.22.1
SME A Short Message Entity (SME) is a terminal that can receive and send SMs. The SME can be located in a fixed network, in an MS or in an SMSC. An SME can send and receive SMs if: .
it has a display facility
.
it is able to handle SM Transfer Protocol Data Units (TPDUs)
.
the BSC supports SMS (proper BSSAP version)
.
the MSCs and HLRs in the PLMN have SMS routing definitions
Of all the SMEs, only an MS can receive SMs if the subscriber has subscription to the basic service T21 (SMS-MT/PP). The subscriber does not need a different MSISDN for this basic service. For example, the MSISDN of T11 can be used for T21 as well. There should also be empty storage space in the memory of either the mobile equipment or the SIM. An MS can send SMs if the subscriber has subscription to the basic service T22, SMS-MO/PP. The MSISDN of T11 can be used for T22 as well.
1.22.2
SMSC The SMSC acts as: .
a store and a forward point for SMs
.
an interface to other systems
.
a platform for applications
An SMSC must be capable of: .
submitting an SM to an MS, and retaining the responsibility of the SM until a report has been received or the validity period set for it expires
.
receiving a report from the PLMN
.
receiving an SM from an MS
.
returning a report to the PLMN for a previously received SM
The SMSC is not part of the GSM PLMN. It stores and forwards SMs. Thus a GSM PLMN needs to support the transfer of SMs between SMSCs and MSs. One SMSC can have a connection to more than one PLMN, or one PLMN can have more than one SMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
109 (267)
SMS Guide
All SM services which a GSM operator sells to subscribers are implemented in the SMSC: the role of the GSM network in a nutshell is just to pass the SMs between the SMSC and the MS. The SMSC can be connected to any computer that has a specialised service. This opens the way for a wide range of services to be offered to the mobile subscribers, such as weather forecast service and stock market information service. The SMRSE over the TCP/IP interface is supported between the MSC and SMSC. SMRSE over X.25 or MAP SS7 is also possible. If the Welcome SM function is active in the MSC, the SMSC receives a trigger message from the VMSC at the arrival of a new roamer. The SMSC has to recognise this special MO-SM from the VMSC, which contains the subscriber's MSISDN number, IMSI, LAC, and VMSC address. For further information, see Welcome SM to the roamer . If the Trigger SM function is active in the MSC, the SMSC receives a trigger message from the VMSC at triggering detection. The SMSC has to recognise this special MO-SM from the VMSC, which contains the subscriber's MSISDN number, IMEI, IMSI, and Common MSISDN. For further information, see Real Time Triggering .
1.22.3
VMSC and VLR The VLR contains two different kinds of subscriber data: service subscription data and Message Waiting Indication. The service subscription data consists of T21 basic service (MT-SMS) and T22 (MO-SMS). The Message Waiting Indication consists of the Mobile Station Not Reachable Flag.
1.22.3.1
VMSC and VLR in MO-SM procedure
VMSC and VLR provide the following properties in the MO-SM: A interface operations in VMSC and VLR (MO)
MS starts the MO-SMS operation by sending a Common Service Request to the network. The request includes authentication, ciphering, IMEI checking and TMSI reallocation . These operations are exactly the same as in ordinary voice calls. The actions are defined in VLR and subscriber parameters. The MS sends the SM in CP DATA message and receives an acknowledgement in CP ACK message. The acknowledgement of the SMSC is transmitted back to the MS in CP DATA message, and the MS acknowledges it in CP ACK. For detailed description, see Figure MO-Forward SMS procedure .
110 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
CP DATA is retransmitted if the RR (Radio Resource) connection is changed, or the MS does not acknowledge it. The reason for changing the RR connection can be a handover, for example. The ReadyForSM operation and MWD support Memory Capacity Available facility. The MS can use this service to inform the SMSC that it is ready to receive messages that it could not receive earlier because it had no free memory. For background information, see A interface in SMS .
VMSC
A-IF
-
- Originating (A-subscriber) Address - Destination (SMSC) Address - User Data MAP
Message Reference Originating (A-subscriber) Address Destination (SMSC) Address User Data
MS
SMS-IWMSC
SMRSE
- Message Reference - Originating (A-subscriber) Address - User Data
SMSC
Figure 39.
MO-SMS request
MAP interface operations
The MO-SM is transmitted further from the VMSC in MOForwardSM operation. The message contains different kinds of data, for example the addresses of subscriber A and the SMSC, plus the SM data. If the SMS-IWMSC knows the SMSC, it transfers the SM to it. When the SMS-IWMSC receives a response for the SM from the SMSC, it transfers the response to the VMSC. If the VMSC and the SMS-IWMSC are physically in one MSC then the information is transferred internally and not on the MAP interface. For more information, see SMS procedures performed by MAP .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
111 (267)
SMS Guide
VMSC
A-IF
MAP
- Message Reference - User Data
SMS-IWMSC
SMRSE
MS
- Message Reference - User Data
SMSC
Figure 40.
MO-SMS successful case (positive response)
VLR operations in SMS (MO)
The VLR receives data from the HLR, that contains information about barrings set by the subscriber, that is, interworking between subscriber-activated outgoing call barring service, and the barrings set by you. The VLR parameters define what operations are performed for the subscriber during the set-up phase, that is, whether IMEI is authenticated or ciphered. The relevant barring categories are the following: .
Operator-determined barrings: -
.
barring of outgoing calls barring of outgoing inter-zonal calls barring of outgoing inter-zonal calls except those directed to the home PLMN country barring of outgoing international calls except those directed to the home PLMN country and barring of outgoing inter-zonal calls
Supplementary service barrings: -
barring of all outgoing calls barring of outgoing international calls barring of outgoing calls except those directed to the home country
Please take the following restrictions into account:
112 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
.
The MO-SMS is provisioned for every subscriber as a basic service. Subscribers who have not been provisioned the MO-SMS in that particular VLR area are not allowed to use the service.
.
If the SMSC address is unknown or outgoing calls are barred, the SM transfer to the SMSC is not possible, and the SMS request is denied in the MSC. - Cause (error code) - User Data
VMSC
A-IF
MAP
- Message Reference - Cause (error code) - User Data
SMS-IWMSC
SMRSE
MS
- Message Reference - Cause (error reason) - User Data
SMSC
Figure 41.
MO-SMS unsuccessful case (negative response)
The MO-SMS is allowed at the same time when an active call and/or MT-SMS and/or USSD or SS operation to the subscriber is taking place, and vice versa. Special conditions .
Two MO-SMS requests are not allowed simultaneously, but if there are more messages from the same subscriber, a session between MSC and MS is not disconnected before the last message has been transferred.
.
The SMSC can send diagnostic data in negative acknowledgements to the MS. The amount of data is at most the same as in MO-SMS.
For related information, see Mobile-originating short message . 1.22.3.2
VMSC and VLR in MT-SM procedure
VMSC and VLR provide the following properties in the MT-SM:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
113 (267)
SMS Guide
A interface operations in VMSC and VLR (MT)
The GSM system starts the A interface MT-SMS operation by paging the MS. The paging procedure includes authentication, ciphering, IMEI checking and TMSI reallocation . Next the MSC sends the SM in a CP DATA message and the MS acknowledges it in a CP ACK message. The acknowledgement of the MS is transmitted back to the MSC in the CP DATA message, and the MSC acknowledges it in the CP ACK. See Figure MO-Forward SMS procedure and the figures below:
SMS-GMSC
-
More Message To Send Originating Address (SMSC) Destination Address (B-subscriber) User Data
MAP
A-IF
SMRSE
-
SGSN
Priority Request More Message To Send Message Reference Originating Address (SMSC) Destination Address (B-subscriber) User Data
SMSC
- Message Reference - Originating Address (SMSC) - Destination Address (B-subscriber) - User Data
MS
Figure 42.
114 (267)
VMSC
MT-SMS request
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMS-GMSC
VMSC
MAP
A-IF
SMRSE
MAP
A-IF SGSN
- Message Reference
- Message Reference
SMSC
MS
Figure 43.
MT-SMS successful case (positive response)
- Cause (error type) - User Data
SMS-GMSC
VMSC
MAP
A-IF
SMRSE
MAP
SGSN
- Cause (error type) - Message Reference - User Data
A-IF
- Message Reference - Cause (error code) - User Data
SMSC
MS
Figure 44.
MT-SMS unsuccessful case (negative response)
For background information see A interface in SMS .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
115 (267)
SMS Guide
MAP interface operations (MT)
MT-SM is transmitted further from the SMS-GMSC in MTForwardSM operation. The message contains different kinds of data, for example, the address of subscriber B, and the SMSC plus the SM data. Note, that if the VMSC has a direct connection to the SMSC, the SMS-GMSC and the IWMSCfunctions as specified later on in this section are available in the SMSC. For more information on SMS procedures performed by MAP, see SMS procedures performed by MAP . Special conditions .
Multiple messages during one A interface connection are possible. If the SMSC has more messages to send, or several SMSCs are sending SMs to the same subscriber, queueing is needed. The MS is informed about this, and the connection is left open. When queueing takes place, all incoming SMs are placed in a queue in the VMSC, and they are served according to FIFO principle. All SMs are transferred to the MS in the same connection between VMSC and MS. The queue handling takes into account what kind of A interface connection is used (fast/slow), how long the queued SM is, and how many SMs the queue contains. Calculations based on this information define how long the SM is expected to stay in the queue, and make sure that the specified maximum queuing time will not be exceeded.
.
The MT-SMS is allowed when an active call and/or MO-SMS and/or USSD or SS-operation to the subscriber is taking place, and vice versa.
.
The MSC has a functionality which resends the MT-SM to the MS if a handover or a time-out takes place: if More-Messages-to-Send functionality is in use, the SMSC informs the MSC that the SMSC contains one or more SMs waiting to be delivered to the MS. The connection path between the SMSC and the MS is not closed when there are more than one SMs to the same subscriber.
.
The mobile station not reachable flag is initialized in the VLR restart.
.
Interworking with supplementary services, except with call barrings, is not provided in the VMSC/VLR. For more information, see troubleshooting instructions in Short Message Service troubleshooting .
For information on SMS resending and timer values, see MT operation in VMSC . For further information, see Mobile-terminating short message .
116 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.22.4
SMS-IWMSC In the case of an MO-SM, the MSC with a connection to an SMSC is called Interworking MSC (SMS-IWMSC). The purpose of the SMS-IWMSC is to receive MO-SMs from within the PLMN, and of transferring them from the VMSC to the SMSC. It also provides the Alert-SC function to inform the SMSC of subscribers who have become active and who have an MT-SM waiting to be delivered to them. The SM is stored in the SMSC. If the SMSC is connected through MAP interface, the function of the SMSIWMSC is implemented in the SMSC. Special conditions
1.22.5
.
In case of an MO-SM, if the SMSC address received from the VMSC is unknown, the SM delivery is rejected.
.
If the SMSC address received from the HLR is unknown, the Alert-SC request is cancelled. The SMSC can send diagnostic data in negative acknowledgements to the MS. The amount of data is as long as the data in MO-SM at the most. For more information, see 3GPP TS 23.040.
SMS-GMSC In the case of an MT-SM, the MSC that has direct SMSC connections is called Gateway MSC (SMS-GMSC). The SMS-GMSC is capable of receiving SMs from the SMSC and interrogating the HLR for routing and SMS information with SendRoutingInfoForSM operation. The purpose of the SMS-GMSC is to transfer an MT-SM from the SMSC to an appropriate VMSC /SGSN . In case of an unsuccessful SM delivery attempt, it uses the ReportSM-DeliveryStatus operation to set the MNRF /MNRG or MCEF flag, and to put the SMSC address to the MWD list of the subscriber. See Figure MT-SMS procedure . In case of MAP interface, the function of the SMS-GMSC is implemented in the SMSC. Special conditions
In case the absent subscriber error code is received from the HLR, information indicating whether the SMSC address is included in the MWD list or not, is sent to the SMSC. If an error code indicating an absent or unidentified subscriber is received from the VMSC, the SMS-GMSC initiates ReportSM-DeliveryStatus operation towards the HLR, provided that the SMSC address was not previously included in the MWD list. The subscriber address, which is used for alerting when the subscriber becomes available, is also returned.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
117 (267)
SMS Guide
If a subscriber has MWD in HLR, an SM with priority indication can be sent, causing the HLR to return routing information. If the SM transfer succeeds, the SMS-GMSC informs the HLR about a successful transfer, which in turn starts the Alert-SC operation. An MS can send diagnostic data in negative acknowledgements to the SMSC. The amount of data is as long as the data in the MT-SM at the most. Two MT-SMS requests are not allowed simultaneously, but if there are more messages for the same subscriber, the session between the SMSC and the MS is not disconnected before the last message is transferred. This is indicated with the MoreMessagesToSend parameter in the MT-SM.
1.22.6
HLR Both MO-SMS and MT-SMS are implemented as basic services in the HLR. For SMS, it is possible to obtain routing information for an incoming SM. The implementation of SMS in the HLR can be divided into the storage of SMSrelated data in the HLR, the operations for the SMS service, and the management of SMS functions. Subscriber management functions provide the management of SMS: they allow the addition, deletion, and modification of subscribers' basic services. For detailed instructions, see Managing SMS subscriber-specific data . SMS-related data in HLR
The HLR provides two information elements for the SMS function that form an integral part of the HLR and its file system. These are the following: .
SM services (mobile-terminating and mobile-originating are considered as separate services)
.
subscriber-specific SMSC address lists for each subscriber for whom the SMS services have been allocated
The HLR provides these functions together with MAP. There are three different kinds of procedure concerning the SM operation:
118 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.
When the HLR receives a ReportSMDeliveryStatus message, it sets the address of the SMSC into the MWD list and returns a positive acknowledgement to the element that requested it. If the address already exists, the HLR sends a positive acknowledgement.
2.
When the MWD list contains SMSCs, it means that the subscriber is unreachable and all inquiries about the SM routing are rejected. The only exception is the priority SM. In this case, routing an SM to a subscriber is attempted even if MWD contains addresses.
3.
If no priority is used and the MWD contains addresses, a negative acknowledgement is sent with the error code 'absent subscriber' to the SMSC, and the SMSC address is stored in the MWD.
If the SMS services (both MO/PP and MT/PP) are not defined for a subscriber as basic services, all SMS-related operations are rejected for that subscriber, and the SM services are not available for him in the network. The incoming call barring supplementary services and also operator-determined barring can be used with the MT-SMS. The HLR provides the supplementary service support. For the SMSC address lists only one address list space is provided, and the subscribers' lists are implemented by relational indexing inside this common pool. There is no inherent limit to the length of a subscriber's SMSC list. HLR operations for SMS service
The following MAP-level operations implemented in the HLR are supported: 1.
SendRoutingInfoForSM This operation allows MT-SMs to be routed to mobile subscribers everywhere in the GSM networks using VMSC address.
2.
ReportSM-DeliveryStatus In the case of a non-deliverable SM, the SMS-GMSC informs the HLR, which stores the address of delivered SMSC for subsequent use. The HLR is also notified if a transfer succeeds when an MWD was set.
3.
ReadyForSM When the subscriber has again become active, or has free memory capacity again, the VLR sends this operation to the HLR.
4.
InformServiceCentre This operation informs the SMSC which ISDN number is used for indicating that an MS can receive SMs.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
119 (267)
SMS Guide
5.
AlertServiceCentre When a subscriber has again become active, the HLR informs all SMSCs that have undeliverable SMs waiting for him.
The data in the HLR can be further divided into service subscription data and message waiting data. Service subscription data consists of the following two services: .
T21 basic service (MT-SMS)
.
T22 basic service (MO-SMS)
Message Waiting Indication consists of: .
Message Waiting Data List (SMSC addresses)
.
Mobile Station Not Reachable Flag (MNRF)
.
Mobile Station Not Reachable for GRPS Flag (MNRG)
.
Mobile Station Not Reachable Reason (MNRR)
.
Mobile Station Memory Capacity Exceeded Flag
For more information, see SMS information elements . When the system attempts to send an SM to a subscriber, the HLR receives the routing inquiry for the SM. If the subscriber does not have the T21 basic service provisioned, the HLR rejects the operation. SMS Forwarding functionality is implemented in the HLR.
1.22.7
Traffica The information about the Welcome SM is sent to Traffica, which is a real time monitoring tool. For background information, see Welcome SM to the roamer. For statistics-related information on Traffica see Traffica in SMS Statistics .
120 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
1.23
Interfaces between SMS network elements The interfaces and the network elements involved in SMS are introduced below: HLR
VLR MAP-D
MAP-C
SMRSE
A-IF
MAP-E
SMSC
SMS-GMSC
MSC
MAP-Gd
MAP Gr, Gf
SGSN
Figure 45.
dn98905102 Issue 5-0 en
Network elements involved in SMS
.
The A interface uses common channel signalling protocols MTP , SCCP , and BSSAP .
.
The C and D interfaces use common channel signalling protocols MTP, SCCP, TCAP , and MAP.
.
The E interface functions either as the MAP interface, like C and D interfaces, or as an internal service interface in the DX 200 MSC, if the MSC performs the tasks of the SMS-GMSC and VMSC, or the SMSIWMSC and VMSC, simultaneously.
# Nokia Corporation Nokia Proprietary and Confidential
121 (267)
SMS Guide
1.23.1
.
The P interface functions as the X.25 interface. The following OSI protocols are used in this interface: OSI-layers 4-6, ROSE, ACSE and SMRSE (Short Message Relay Service Element). The SMRSE is specified in ETSI Specification 03.47.
.
There is also a Nokia-specific TCP/IP interface for P interface. For more information, see Feature 931: Short Message Service transfer over TCP/IP .
A interface in SMS Short Messaging uses only the following signalling channels: .
SDCCH A Stand Alone Dedicated Control Channel is a two-way signalling channel normally used for call establishment and location updates. When there is no voice call active, SDCCH channels are used for short messages. One traffic channel (TCH) can be combined into 8 SDCCHs.
.
SACCH If a voice call is active, a Slow Associated Control Channel is used for short messaging, which means that messages can be sent and received even during a call. Each SDCCH or traffic channel is accompanied by a twoway SACCH.
When there is no active call, USSD and SMS use the same SDCCH signalling channel. During a call, USSD uses FACCH channel, when SMS uses SACCH. With SACCH the sending of the SM takes about three times longer than with SDCCH. The transfer of USSD with FACCH is 5-7 times faster than SMS with SACCH. USSD and SMS are possible simultaneously, even during a call. For more information on the A interface, see 3GPP TS 24.008 and 24.011. For more information, see A interface operations in VMSC and VLR (MO) , and A interface operations in VMSC and VLR (MT) .
1.23.2
SMRSE in SMS The exchange of messages between the MSC and the SMSC is based on Short Message Relay Service Element (SMRSE) interface defined in Technical report 03.47. The SMRSE needs a reliable transport service to exchange messages. There are two alternatives: X.25 and TCP/IP connection. Both interface options can co-exist in the MSC site. Each SMSC can support either the TCP/IP or X.25 connection.
122 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
X.25 connection
OSI application with X.25 connection: if the SMSC operator and the PLMN operator are the same, the X.25 connection is considered to be a safer way. In this method the user must create a definition in the SMS-IWMSC to link the SMSCISDN address to an OSI application. The following figure describes the OSI protocol stack:
Non OSI applications
OSI applications
FTAM
VT
ACSE
CMISE
SMRSE
ROSE
Presentation layer Transport service user CONS network service user
MSW
PAD
Session layer Transport layer 0
Transport layer
CLNS
CONS
X.25 packet level
SNDCF
ISO IP, ES-IS, IS-IS
X.25 data link level
LLC
physical level
CSMA/CD
X.25 network
Figure 46.
Transport layer 4
802.3 subnetwork
OSI protocol stack
In the technical report of the SMRSE, the number of simultaneous MS transfers (message reference) is limited to 255. This means that a maximum of 256 of messages from one SMSC can be made at the same time in the network. In case of high capacity links, this limitation can result in a bottleneck, and therefore more space is reserved (1000).
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
123 (267)
SMS Guide
If feature 619 is in use in your exchange, you can control the maximum value of message references towards SMSC (MO-SMS). TCP/IP connection
The full seven layered OSI stack of the X.25 connection is quite heavy for transferring relatively simple data, such as SMs, and therefore it unnecessarily loads the physical line transfer capacity and the processing capacity of the computer unit that controls the line. Therefore, if Feature 931: Short Message Service Transfer over TCP/IP is in use in your network, it can increase the performance of the transmission between the MSC and the Nokia SMSC conveying SM traffic. The purpose of TCP/IP is to provide a fast and efficient way of transferring SMs between MSCs and SMSCs. It implements the functionality defined for SMRSE. There are also some Nokia-specific features, for example, additional parameters, which have to be implemented. Altogether this feature provides all the tasks and features of the previous solution, but in a more efficient way. TCP/IP reduces the amount of protocol layers and therefore the time needed for processing a message. The interface improves the SM transfer capacity considerably. Because of the high capacity, the number of messages that can be handled simultaneously increases significantly. Consequently, there must be a way to restrict the traffic. The amount of the messages can be tuned up to the optimal for the system configuration used. This prevents the SM transfer system from producing too high a load in the rest of the system. The following figure describe the protocol stack for SMS with TCP/IP.
124 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
SMS-IWMSC/GMSC SMSC
SMRSE
TCP/IP stack
SMRSE
TCP
MAP TCAP
TCP/IP Protocol Stack
IP Link Layer 802.3
Ethernet
Figure 47.
SMS Appl.
SCCP MTP
SS7
Protocol stack for SMS with TCP/IP
Both IPv4 and IPv6 are supported. For a more detailed information refer to the feature descriptions of Feature 931: Short Message Service Transfer over TCP/IP . For related information, see Comparison of SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC .
1.23.3
MAP in SMS MAP is an interface that follows the GSM specification. See the figure below:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
125 (267)
SMS Guide
ITU-T
OSI
Nr. 7 MAP
layer 7
TCAP BSSAP
TUP/
layer 6 layer 5
ISUP
layer 4
level 4
SCCP level 3
layer 3
level 2
layer 2
MTP level 1
layer 1
Figure 48.
OSI compared to ITU-T No. 7
MAP covers the following interfaces in the GSM network: .
C interface between MSC and HLR
.
D interface between VLR and HLR
.
E interface between MSC and MSC
.
F interface between MSC and EIR
.
G interface between VLR and VLR
B interface between MSC and VLR is not described in these descriptions of Short Message Services. In the GPRS network the following MAP interfaces exist:
126 (267)
.
MAP-Gd: between MSC and SGSN
.
MAP-Gr: between SGSN and HLR
.
MAP-Gf: between SGSN and HLR
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
MAP provides the following SMS procedures for its users: .
MOForwardSM: between VMSC and SMS-IWMSC or between VMSC and SMSC
.
MTForwardSM: between SMS-GMSC and VMSC or between SMSC and VMSC
.
SendRoutingInfoForSM: between SMS-GMSC and HLR or between SMSC and HLR
.
ReportSM-DeliveryStatus: between SMS-GMSC and HLR or between SMSC and HLR
.
InformServiceCentre: between HLR and SMS-GMSC or between HLR and SMSC
.
ReadyForSM: between VLR and HLR
.
AlertServiceCentre: between HLR and SMS-GMSC or between HLR and SMSC
.
SendIMSI: between SMS-IWMSC and HLR or between SMSC and HLR
One MAP procedure can be executed during one TCAP dialogue. See SMS procedures performed by MAP for detailed explanations of the procedures. The alternative to OSI for implementing SMSC and SMS-GMSC or SMSIWMSC connection is the MAP interface with CCS7 link. In this case the SMSC is integrated to the CCS7 network, and the functionalities of SMS-GMSC and SMS-IWMSC are combined to the SMSC. Routing definitions are easier than with the X.25 connection. Every MSC and HLR can send SMs directly to the SMSC, as well as receive them directly from there. MAP version 3 is supported if you have Feature 1043: Short Message Services GSM Phase 2+ in the network. This MAP version includes the parameters necessary for SMS over GPRS . For more information refer to feature descriptions of Feature 1043: Short Message Services GSM Phase 2+ and Feature 857: Support of General Packet Radio Service (GPRS) . MAP-Gd
MAP-Gd is the interface between the MSC and the Serving GPRS Support Node (SGSN). The SMS-related MAP version 3 makes the usage of Feature 857: Support of General Packet Radio Service (GPRS ) possible. The following figure shows the SMS architecture with SGSN.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
127 (267)
SMS Guide
HLR
MSC A-IF
MAP-E
MAP-C
BSS SMS-GMSC
SMSC
MAP-Gd
SMRSE
Gb
SGSN
Short message service centre
Figure 49.
MAP-Gd interface in the SMS GSM Phase 2+ network architecture
For related information, see SMS procedures performed by MAP , Short Message Service on GPRS , and Comparison of the SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC .
1.24
Subscriber interface of SMS SMS status report
The subscribers receive a notification when there are one or more SMs delivered to them, and when they send a message, a notification that a message has been sent. However, the latter notification only means that the SM was successfully sent to the SMSC, nothing about a future delivery. Whether the SM delivery was successful or not is indicated in a status report . A status report informs the subscriber of the status of the MO-SM that was sent. Its status can be either successful, that is, the SM was delivered successfully to the MS, or unsuccessful. Usually the SMSC address is stored in the MS, but the subscribers can also set it themselves when they are using other than the usual kind of SMs, such as fax, for example. For background information, see Command SM and MO-SM with Status Report request .
128 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Services
Prevention of SMS
If the subscribers want to bar incoming or outgoing SMs or both, they, in general, must bar all incoming or outgoing calls, or both. They can bar all incoming/ outgoing SMs if the menu of their MS supports it. Likewise, if they bar all incoming and/or outgoing calls, this automatically means that SMs are also barred. For background information, see Barring SMS in the MSC . User Data in MT/MO-SMS acknowledgement message
Since the UserData in the acknowledgement messages is available, SIM data download becomes possible. This can be useful in cases when, for example, the user has a prepaid SIM card because the data download is possible by the SMS. Alphanumeric addressing of SMS-related applications
The subscriber has the benefit of easy addressing of SMS-related applications as this feature supports alphanumeric addresses for the destinations of short messages. The alphabetical address is carried in the MO-SM. The characters are represented by a hexadecimal number in an 7bit octet. For example, the character 'J' is represented as 0x4A (01001010 in binary format). The upper 4 bits (from the most significant bit (MSB)) contains the first digit of the hexadecimal number and the below 4 bits (from the least significant bit (LSB)) contains the second digit thereof. Our example (the letter 'J') can be, thus, represented as below:
MSB
LSB 1 0 0 1 0 1 0 "4"
Figure 50.
"A"
An example for hexadecimal numbers used in alphanumeric addressing
Accordingly, if the subscriber sends a short message to the address 'JOKEBOX', the address in hexadecimal format is 4A 4F 4B 45 42 4F 58 (see below).
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
129 (267)
SMS Guide
short message
MS
4A 4F 4B 45 42 4F 58 - - - - - - - - - - - - - - - - - - --
Figure 51.
130 (267)
An example for alphanumeric addressing from the MS
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
2
Configuring network elements for SMS The SMS-PP is available for use after the SW installation, the creation of Global Title analyses, the SMSC address analysis, and the connection between the SMSIWMSC/SMS-GMSC and the SMSC. For more information, see the Feature descriptions of Feature 327: Short Message Services and SMSC Guide to Commissioning for HP 9000/700 and 9000/800 and the instructions on OSI. The interfaces and the network elements involved in SMS-PP are shown in the following figures.
MS
A
BSS
VMSC
E
SMSGMSC
P
SMSC
B
VLR
In the examples below the network element addresses are: VMSC address: 4434050 VLR address: 4434051 IWMSC address: 443406 SMSC address: 44340600001
Figure 52.
dn98905102 Issue 5-0 en
MO-SM interfaces
# Nokia Corporation Nokia Proprietary and Confidential
131 (267)
SMS Guide
MS
BSS
A
VMSC
E
SMSGMSC
B
VLR
P
SMSC
C D
HLR
In the examples below the network element addresses are: HLR address: 443404 VMSC address: 4434050 VLR address: 4434051 GMSC address: 443406 SMSC address: 44340600001
The relevant signalling point codes are: HLR SPC: 340 VMSC SCP: 342 SMS-IWMSC SCP: 341 SMS-GMSC SCP: 341 Figure 53.
MT-SM interfaces
For related information, see Parameters for SMS A-interface configuration . For the whole topic summary, see Short Message Services Overview.
2.1
Configuring MAP interface for SMS The MAP configuration contains global title analyses used by the Short Message Service.
132 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
You can find detailed information on MAP in MAP in SMS . Before you start
Some of these global title analyses can already exist, so check their existence first and create only the ones that are missing. Use the benefits offered by network topology, if possible. In the examples presented in this section, the SMSC address of the SMSC is 44340600001, and the address of the SMS-GMSC is 443406. Thus, you need to create a global title analysis, if one does not already exist, for the SMS-GMSC address (443406). It is enough to route the SM to the SMSC because the beginning of the SMSC address is the same.
2.1.1
Creating global title analysis Before you start
Find out what network is in use (NA0, NA1, IN0, IN1). You can only use an existing network. ZNET:; where is the symbolic name of the signalling network which the signalling point belongs to. The default is all networks. You are recommended to use route on global title (RI=GT) if there are any SCCP gateway node points between the origin and destination point. Steps
1.
Create global title translation result and global title analysis (NAC, NBC) Create global title translation result. ZNAC:NET=,DPC=,RI=GT; To interrogate the translation results, use the following command: ZNAI:; Create global title analysis. ZNBC::::;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
133 (267)
SMS Guide
2.
Create global title analyses for the E.164 MSISDN number in the SMS-GMSC (NAC, NBC) The result is the HLR, as shown in the figure below:
SMS- GT-analyses: 443404 GMSC Result record: 1
HLR
HLR address: 443404
Figure 54.
a.
b.
3.
GT analyses in the SMS-GMSC, the result is the HLR
Create a global title translation result. Here the value of is the HLR SPC. ZNAC:NET=NA0,DPC=340,RI=GT; Create a global title analysis. Here the value of is the MSISDN number of subscriber B (the first five digits). ZNBC:::443404:1;
Create global title analyses for the E.164 VMSC number in the SMSGMSC/SMS-IWMSC (NAC, NBC) The result is the VMSC, as shown in the figure below:
SMS-GMSC/ GT-analyses: 443405 SMS-IWMSC Result record: 2
VMSC
VMSC address: 4434050
Figure 55.
a.
b.
134 (267)
GT analyses in the SMS-GMSC/SMS-IWMSC, the result is the VMSC
Create a global title translation result. Here the value of is the VMSC SPC. ZNAC:NET=NA0,DPC=342,RI=GT; Create a global title analysis.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
ZNBC:::443405:2; 4.
Create global title analysis for E.164 SMSC address in the VMSC (NAC, NBC) The result is the SMS-IWMSC. See the figure below. GT-analyses: 443406
VMSC
Figure 56.
a.
b.
5.
SMSIWMSC
SMSC
SMS-IWMSC address: 443406
SMSC address: 44340600001
Result record: 3
GT analyses in the VMSC, the result is SMS-IWMSC
Create a global title translation result. Here the value of is the VMSC SPC. ZNAC:NET=NA0,DPC=342,RI=GT; Create a global title analysis. Here the value of parameter is the SMSC ISDN number. ZNBC:::443406:3;
Create global title analyses for the E.164 SMSC address in the SMSIWMSC (NAC, NBC) The result is the SMS-IWMSC. The start of the SMSC address can be the same as the SMS-IWMSC address, so check whether you need to create this analysis or whether it already exists. See the figure below: GT-analyses: 443406
VMSC
Figure 57.
dn98905102 Issue 5-0 en
SMSIWMSC
SMSC
SMS-IWMSC address: 443406
SMSC address: 44340600001
Result record: 3
GT analyses in the SMS-IWMSC, the result is the SMS-IWMSC
# Nokia Corporation Nokia Proprietary and Confidential
135 (267)
SMS Guide
a.
b.
6.
Create a global title translation result. Here the value of is the SMS-IWMSC SPC. ZNAC:NET=NA0,DPC=341,RI=GT; Create a global title analysis. Here the value of parameter is the SMSC ISDN number. ZNBC:::443406:3;
Create global title analyses for the E.164 SMS-GMSC number in the SMS-GMSC (NAC, NBC) The result is the SMS-GMSC. See the figure below:
HLR
GT-analyses: 443406000001 Result record: 3
SMSIWMSC
SMSC
SMS-IWMSC address: 443406
Figure 58.
a.
b.
GT analyses in the SMS-GMSC, the result is the SMS-GMSC
Create a global title translation result. Here the value of is the SMS-GMSC SPC. ZNAC:NET=NA0,DPC=341,RI=GT; Create a global title analysis. Here the value of is the SMS-GMSC ISDN number. ZNBC:::443406:3;
Note Due to the configuration we are using, this analysis is the same as the previous analysis.
7.
Create global title analysis for E.164 SMSC number in the HLR (NAC, NBC) The result is the SMS-IWMSC.
136 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
a.
b.
8.
Create a global title translation result. Here the is the HLR SPC. ZNAC:NET=NA0,DPC=340,RI=GT; Create a global title analysis. Here the value of is the SMSC ISDN number. ZNBC:::443406:3;
Create global title analyses for the E.164 HLR number in the HLR (NAC, NBC) The result is the HLR. See the figure below:
SMS-GMSC/ SMS-IWMSC
GT-analyses: 443404 Result record: 1
HLR
HLR address: 443404
Figure 59.
a.
b.
9.
GT analyses in the HLR, the result is the HLR
Create a global title translation result. Here the is the HLR SPC. ZNAC:NET=NA0,DPC=340,RI=GT; Create a global title analysis. Here the value of is the HLR ISDN number. ZNBC:::443404:1;
Create global title analyses for the E.164 VMSC number in the VMSC (NAC, NBC) The result is the VMSC. See the figure below:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
137 (267)
SMS Guide
SMS-GMSC/ SMS-IWMSC
GT-analyses: 443405 Result record: 2
VMSC
VMSC address: 4434050
Figure 60.
a.
b.
GT analyses in the VMSC, the result is the VMSC
Create a global title translation result. Here the value of is the HLR SPC. ZNAC:NET=NA0,DPC=342,RI=GT; Create a global title analysis. Here the value of is the HLR ISDN number. ZNBC:::443405:2;
Further information:
Note It is very important to check that there is no loop between the global title analyses you created.
2.2
Configuring X.25 interface for SMS Configuring the X.25 connection consists of three parts:
2.2.1
Connecting the SMSC to the SMS-GMSC/SMS-IWMSC Before you start: Check the parameter set
Note that the consistency of the parameter set has to be checked so that both the SMSC and the MSC have similar settings. The basic settings that are changed are: L3UDS, L3WIN, L3HTC, and L3LTC.
138 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
L3UDS tells the length of the user data, and L3WIN the window size. L3LTC is the lowest and L3HTC is the highest traffic channel used. If the X.25 connection from the SMSC to the MSC does not work, check the value of the highest traffic channel in the MSC. The DTE entity creates the connection with the highest, and the DCE entity with the lowest traffic channel defined. Therefore, make sure that these values are the same in the SMSC and the MSC. Use command ZQXI; for checking the parameter set. Steps
1.
Create a parameter set (QXC) ZQXC::; where is the identifier of the parameter set with 1 - 8 characters.
2.
Modify a parameter set (QXM) ZQXM::;
3.
Set the physical level characteristics for an analogue interface (QTC) These characteristics are set for a unit which has an interface with the SMS. Repeat the command for each interface. For more detailed information, see instructions on OSI management and SMSC Guide to Commissioning for HP 9000/700 and 9000/800. ZQTC:BDCU,:,: , ; To find out the unit index, use the command ZUSI:BDCU; To find out the analog terminal index, use the command ZWTI:P:BDCU; or ZQTI;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
139 (267)
SMS Guide
4.
Create a physical channel (QCS) Repeat the command for each channel. ZQCS::BDCU,,:: ,; To find out the unit index, use the command ZUSI:BDCU; To find out the analog terminal index, use the command ZWTI:P:BDCU; or ZQTI;
5.
Unlock the physical channel (QSC) Repeat the command for each channel. ZQSC:,UNL; where identifies the physical channel(s). Characters & and && are allowed. To find out the number, use the QSI command (address number).
6.
Create a channel group (QGC) Repeat the command for each channel group. The channel group includes all channels to the group. ZQGC::,,;
7.
Create the NSAPs (QBN) ZQBN:::: DTE=,SPI=,CHG=; Note that CHG is used only for creating remote NSAPs.
140 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
To find out the C number, use the QNI command: ZQNI; 8.
Create network addresses to connect application to the relevant interface (QBC) Create network addresses to connect application to the interface which it is going to use. Attach the NSAP addresses of the interfaces to this network address. ZQBC::;
9.
Attach NSAPs (QBT) ZQBT::;
10.
Unlock the NSAP addresses (QBG) ZQBG:,;
11.
Create OSI applications (QDL, QDR) You can create local or remote application. a.
b.
12.
Create a local application, that is, a process that uses OSI services. Create an application to the first CCSU unit only. ZQDL:::::, :::::; Create a remote OSI application ZQDR::::::;
Set the OSI access control method (QQM, QQC) There are two alternatives in the MSC for allowing connection requests from outside: either all incoming calls are allowed, or only the calls whose addresses are defined as allowed ones. ZQQM:; If you use the value L (use access control list), add SNPA to OSI access control list.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
141 (267)
SMS Guide
ZQQC:; where is the remote SMSC DTE address. Further information:
If the creation of a physical channel fails, check the equipping of the plug-in units with following command. ZWTI:P:BDCU; Especially wrong memory addresses in plug-unit equipping can cause error situations. Example 1. Connecting the SMSC to the SMS-GMSC/SMS-IWMSC 1.
Check the parameter set ZQXI; a.
Create a parameter set ZQXC:SMSCSET:; An example printout:
CREATED X25 CONFIGURATION PARAMETER SET DATA PARAMETER SET NAME: SMSCSET ================== MAXIMUM NETWORK SERVICE DATA UNIT LENGTH: 2048 BYTES L2 CONNECTION MODE: INITIATED AFTER START UP LEVEL 2 PARAMETERS: -----------------L2 TIMER T1: 6 SECONDS L2 BITS IN FRAME: 1024 BITS L2 TIMER T2: NOT IN USE L2 RETRY COUNT: 10 TIMES L2 TIMER T3: NOT IN USE L2 WINDOW: 7 FRAMES L2 INTERFRAME FILL: 01111110 L2 LINE DOWN TIMER: 20 (NOT SUPPORTED) LEVEL 3 PARAMETERS: -----------------L3 USER DATA SIZE: 128 BYTES L3 SEND WINDOW SIZE: 2 FRAMES L3 MODULO: 8 L3 TIMER T20: 180 SECONDS L3 TIMER T21: 200 SECONDS L3 TIMER T22: 180 SECONDS L3 RESET RETRY COUNT: 5 TIMES L3 TIMER T23: 180 SECONDS L3 CLEAR RETRY COUNT: 5 TIMES L3 FIRST PVC: 0 (= NOT IN USE) L3 LAST PVC: 0 (= NOT IN USE) L3 LIC: 0 (NOT SUPPORTED) L3 HIC: 0 (NOT SUPPORTED) L3 LTC: 0 (= NOT IN USE) L3 HTC: 0 (= NOT IN USE) L3 LOC: 0 (NOT SUPPORTED) L3 HOC: 0 (NOT SUPPORTED) USER FACILITIES: ---------------
142 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
NO USER FACILITIES COMMAND EXECUTED
b.
Modify a parameter set ZQXM:SMSCSET:L3UDS=1024,L3WIN=7,L3HTC=2, L3LTC=1,; An example printout:
OLD X25 CONFIGURATION PARAMETER SET DATA PARAMETER SET NAME: SMSCSET ================== MAXIMUM NETWORK SERVICE DATA UNIT LENGTH: 2048 BYTES L2 CONNECTION MODE: INITIATED AFTER START UP LEVEL 2 PARAMETERS: -----------------L2 TIMER T1: 6 SECONDS L2 BITS IN FRAME: 1024 BITS L2 TIMER T2: NOT IN USE L2 RETRY COUNT: 10 TIMES L2 TIMER T3: NOT IN USE L2 WINDOW: 7 FRAMES L2 INTERFRAME FILL: 01111110 L2 LINE DOWN TIMER: 20 (NOT SUPPORTED) LEVEL 3 PARAMETERS: -----------------L3 USER DATA SIZE: 128 BYTES L3 SEND WINDOW SIZE: 2 FRAMES L3 MODULO: 8 L3 TIMER T20: 180 SECONDS L3 TIMER T21: 200 SECONDS L3 TIMER T22: 180 SECONDS L3 RESET RETRY COUNT: 5 TIMES L3 TIMER T23: 180 SECONDS L3 CLEAR RETRY COUNT: 5 TIMES L3 FIRST PVC: 0 (= NOT IN USE) L3 LAST PVC: 0 (= NOT IN USE) L3 LIC: 0 (NOT SUPPORTED) L3 HIC: 0 (NOT SUPPORTED) L3 LTC: 0 (= NOT IN USE) L3 HTC: 0 (= NOT IN USE) L3 LOC: 0 (NOT SUPPORTED) L3 HOC: 0 (NOT SUPPORTED) USER FACILITIES: --------------NO USER FACILITIES NEW X25 CONFIGURATION PARAMETER SET DATA PARAMETER SET NAME: SMSCSET ================== MAXIMUM NETWORK SERVICE DATA UNIT LENGTH: 2048 BYTES L2 CONNECTION MODE: INITIATED AFTER START UP LEVEL 2 PARAMETERS: -----------------L2 TIMER T1: 6 SECONDS L2 BITS IN FRAME: 8192 BITS L2 TIMER T2: NOT IN USE L2 RETRY COUNT: 10 TIMES L2 TIMER T3: NOT IN USE L2 WINDOW: 7 FRAMES L2 INTERFRAME FILL: 01111110 L2 LINE DOWN TIMER: 20 (NOT SUPPORTED) LEVEL 3 PARAMETERS: -----------------L3 USER DATA SIZE: 1024 BYTES L3 SEND WINDOW SIZE: 7 FRAMES L3 MODULO: 8 L3 TIMER T20: 180 SECONDS L3 TIMER T21: 200 SECONDS L3 TIMER T22: 180 SECONDS L3 RESET RETRY COUNT: 5 TIMES L3 TIMER T23: 180 SECONDS L3 CLEAR RETRY COUNT: 5 TIMES
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
143 (267)
SMS Guide
L3 FIRST PVC: 0 (= NOT IN USE) L3 LAST PVC: 0 (= NOT IN USE) L3 LIC: 0 (NOT SUPPORTED) L3 HIC: 0 (NOT SUPPORTED) L3 LTC: 1 L3 HTC: 2 L3 LOC: 0 (NOT SUPPORTED) L3 HOC: 0 (NOT SUPPORTED) USER FACILITIES: --------------NO USER FACILITIES COMMAND EXECUTED
2.
Set the physical level characteristics for an analog interface. These characteristics are set for a unit which has an interface with the SMS. Repeat the command for each interface. ZQTC:BDCU,0:AC25S,1:V35,61440:; Example printouts: CREATING ANALOG TERMINAL DATA PIU PIU INTERFACE BIT PHYS UNIT TYPE INDEX TYPE RATE CHAN NB ---------- ------------- --------- ------ ------BDCU-0 AC25-S 1 V.35 61440 COMMAND EXECUTED CREATING ANALOG TERMINAL DATA PIU PIU INTERFACE BIT PHYS UNIT TYPE INDEX TYPE RATE CHAN NB ---------- ------------- --------- ------ ------BDCU-0 AC25-S 1 X.21 153600 COMMAND EXECUTED
3.
Create a physical channel. Repeat the command for each channel. ZQCS::BDCU,0,1::DCE,SMSCSET:; An example printout:
CREATED PHYSICAL CHANNEL DATA SNPA DTE/ X.25 PHYS DATA RATE CHANNEL SNPA-ADDRESS INTP UNIT TERM DCE PARAM SET LEVEL BITS/S ------- ---------------- ---- -------- ---- ---- --------- ------ --------1 SNPA NOT IN USE IGNO BDCU-0 1 DCE SMSCSET V.35 61440 COMMAND EXECUTED
4.
Unlock the physical channel. Repeat the command for each channel. ZQSC:1,UNL; An example printout: CHANGING PHYSICAL CHANNEL STATE CHANNEL OLD STATE NEW STATE INFO ------- --------- --------- ---1 LOC-ENA UNL-ENA COMMAND EXECUTED
144 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
5.
Create a channel group. Repeat the command for each channel group. The channel group includes all channels to the SMSCG1. ZQGC:SMSCG1:0,,50; An example printout: CREATED PHYSICAL CHANNEL GROUP DATA VC CHAN CHAN GROUP ID CHAN NUMBER PRIO STATE -------- -------------------------SMSCG1 0 0 50 UNL-ENA COMMAND EXECUTED
6.
Create the NSAPs ZQBN::L:1:DTE=37926,SPI=03010100; or ZQBN::R:1:DTE=450530,SPI=03010100,CHG=SMSCG1,; Example printouts for the commands: CREATED NSAP X.25 NETWORK PROTOCOL ADDRESS INFORMATION NBR ROLE STATE CHG DTE SPI ----- ------ ------- -------- --------------- -------1 LOCAL LOC-DIS - 37926 03010100 COMMAND EXECUTED CREATED NSAP X.25 NETWORK PROTOCOL ADDRESS INFORMATION NBR ROLE STATE CHG DTE SPI ----- ------ ------- -------- --------------- -------1 REMOTE LOC-DIS SMSCG1 450530 03010100 COMMAND EXECUTED
7.
Create network addresses to connect application to the interface which it is going to use. Attach the NSAP address of the interface to this network address. ZQBC:SMSCLNET:L:; or ZQBC:SMSCRNET:R:; Example printouts: CREATED NETWORK ADDRESS NET ADDR ROLE -------- -----SMSCLNET LOCAL COMMAND EXECUTED CREATED NETWORK ADDRESS
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
145 (267)
SMS Guide
NET ADDR ROLE -------- -----SMSCRNET REMOTE COMMAND EXECUTED
8.
Attach NSAPs ZQBT:SMSCLNET:1:; or ZQBT:SMSCRNET:2:; Example printouts for the commands: TTACHED NSAP NET ADDR ROLE NSAP NR PRIO -------- ------ ------- ---SMSCLNET LOCAL 1 COMMAND EXECUTED ATTACHED NSAP NET ADDR ROLE NSAP NR PRIO -------- ------ ------- ---SMSCRNET REMOTE 2 50 COMMAND EXECUTED
9.
Unlock the NSAP addresses ZQBG:,UNL; An example printout: CHANGING NSAP STATE NBR OLD STATE NEW STATE ----- --------- --------1 LOC-DIS UNL-ENA 2 LOC-DIS UNL-ENA COMMAND EXECUTED
10.
Create OSI applications a.
Create a local application, that is, a process that uses OSI services. Create an application to the first CCSU unit only. ZQDL:SMHPRB:::UNL:CCSU,0:SMS: SMSCLNET:03:03:03:; An example printout:
CREATED OSI APPLICATION AE-NAME APPL NET ADDR STATE UNIT FAM ID PROC ID ---------------- ------ -------- ------- ---------- ------- ------SMHPRB SMS SMSCLNET UNL-ENA CCSU AP_TYPE : NOT IN USE
146 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
AP_TITLE : AEQ : P-SELECTOR: 03 S-SELECTOR: 03 T-SELECTOR: 03 COMMAND EXECUTED
b.
Create a remote OSI application ZQDR:REMSMSC:::UNL:SMS:SMSCRNET:; An example printout: CREATED OSI APPLICATION AE-NAME APPL NET ADDR STATE ---------------- ------ -------- ------REMSMSC SMS SMSCRNET UNL-ENA AP_TYPE : NOT IN USE AP_TITLE : AEQ : P-SELECTOR: S-SELECTOR: T-SELECTOR: COMMAND EXECUTED
11.
Set the OSI access control method. There are two alternatives, allow all incoming calls and allow incoming calls only from the SMSC. Examples of both are presented below. a.
Allow all incoming calls ZQQM:A; An example printout: MODIFYING OSI ACCESS CONTROL METHOD OLD METHOD NEW METHOD --------------------------------------------------ALL INCOMING CALLS DENIED ALL INCOMING CALLS ALLOWED COMMAND EXECUTED
b.
Allow incoming calls only from the SMSC ZQQM:L; An example printout: MODIFYING OSI ACCESS CONTROL METHOD OLD METHOD NEW METHOD --------------------------------------------------ALL INCOMING CALLS DENIED ACCESS CONTROL LIST IN USE COMMAND EXECUTED
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
147 (267)
SMS Guide
2.2.2
Creating analysis on SMS application level in the MSC Steps
1.
Create SMS routing support analysis (CFU) You can create a SMS routing support analysis for defining the case when SMS routing analysis is started. ZCFU:SMSC=;
Note You can execute this command only if you have Feature 1165: Short Message Services GSM Phase 2+ Enhancements in use in your network. If you do not have feature 1165, for the available conditions see SMS routing analysis .
2.
Create an SMS routing analysis (CFE) ZCFE:PID=,SAP=,SAPTYPE=:SMSC=,TC=,SAN=;
Note This step is optional and is necessary only if you want to route the subscriber's SMS request to the service application in the desired SMSC or if you want to create different tariff classes for MO-SMs.
3.
Create an SMSC address analysis (CFS) ZCFS:,:: :; By giving multiple X.25 connections (applications entity names) you can enable load sharing in your system.
148 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
For more information, see SMS load sharing . ZCFS:,::ADD: ,,,,; 4.
Preconfigure the SMSC address, if necessary If you want to use always the same SMSC address towards the MS, you have to add the address to the UTPFIL.
Note This step is necessary only if you do not have Feature 1165: Short Message Services GSM Phase 2+ Enhancements in use in your network.
For more information, see Working examples for SMS management . a.
Find out the UTPFIL and its number running in the CCSU / GSU (WQV, DFL) ZWQV:CCSU:UTP%;
b. c.
d. e. f.
ZDFL:CCSU,0:NAME= ; Find the CM in WO-EX state ZUSI:CM; Find out three free records in UTPFIL (DFD) ZDFD:CM,x:; where x means the active CM, is the number for the UTPFIL, given as a hexadecimal. If the variant part (the last 4 digits) is 0000, it can be omitted. For example, 20000 can be given as 2. Add the SMSC address into UTPFIL records Make sure that you do the changes in every CCSU. Add the SMSC address into UTPFIL records ZDFS:CM,x:,; Restart every CCSU unit one by one
Further information:
Example 2. Creating an analysis for the SMSC address in the SMS-
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
149 (267)
SMS Guide
IWMSC 1.
Create SMS routing support analysis ZCFU:SMSC=223;
2.
Create an SMS routing analysis ZCFE:PID=53,SAP=N:SMSC=222,SAN=E-MAIL;
3.
Create an SMSC address analysis ZCFS:44340600001,AEN:LEVEL=S1:ADD: REMSMSC ; ZCFS:44340600001,AEN:LEVEL=S1: ADD: SMSC01 , SMSC02 ,SMSC03 ;
4.
Preconfigure the SMSC address a.
Find out three free records in UTPFIL ZDFD:CM,x:5AC0007; where x is the active CM.
Note Note, that for compact MSCi the UTPFIL number is 5AC01017.
b.
Add the SMSC address (44340600001) into UTPFIL records. The changes are made in every CCSU. ZDFS:CM,x:...,y; where x is the active CM, and y is the record to be patched. ZDFS:CM,x:...,y+1; where x is the active CM and y+1 is the record to be patched. ZDFS:CM,x:...,y+2; where x is the active CM and y+2 is the record to be patched. In this example the records in the UTPFIL should look like this after the commands: 9D 01 25 00 07 91 44 43 9D 01 26 00 91 F0 FF FF 9D 01 27 00 60 00 00 10
c.
150 (267)
Restart every CCSU unit one by one
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
2.2.3
Setting parameters so that GSM phase 2+ and MT-SM are supported For more information, see MAP in SMS especially MAP version 3. MAP version 3 related instructions can be found in section Handling SMSrelated MAP operations in MSC and HLR . Steps
1.
Set parameters so that GSM phase 2+ is supported by default (OPH) a.
Check the SMS-related application context-specific MAP versions ZOPH:INTERR; Examine the SMS-related application contexts on the execution printout. 20 shortMsgGateway . 21 shortMsgMO-Relay . 23 shorMsgAlert Note that MAP version 2 is allowed only in this application context. There is no change for MAP version 3. . 24 mwdMngt . 25 shortMsgMT-Relay Modify the parameters, if necessary ZOPH:MODIFY:AC=:VER=; .
b.
2.
Make sure MT-SM is supported in the MSC/VLR (MXM) You can activate MT-SMs by giving the following commands in the VLR: ZMXM::::T21=Y; ZMXM::::T22=Y;
Further information:
Example 3. Setting parameters so that GSM phase 2+ and MT-SM are supported 1.
Set parameters so that GSM phase 2+ is supported by default a.
Check the SMS-related application context-specific MAP versions ZOPH:INTERR;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
151 (267)
SMS Guide
Examine the SMS-related application contexts 21 (shortMsgMORelay), 23 (shortMsgAlert) and 25 (shortMsgMT-Relay) on the execution printout. AC NBR AC NAME ALLOWED MAP VERSIONS 1 networkLocUp 1 2 3 2 locationCancellation 1 2 3 3 roamingNumberEnquiry 1 2 3 5 locationInfoRetrieval 1 2 3 7 reporting 3 8 callCompletion 3 10 reset 1 2 11 handoverControl 1 2 13 equipmentMngt 1 2 14 infoRetrieval 1 2 15 interVlrInfoRetrieval 1 2 16 subscriberDataMngt 1 2 3 17 tracing 1 2 3 18 networkFunctionalSs 1 2 19 networkUnstructuredSs 2 20 shortMsgGateway 1 2 3 21 shortMsgMO-Relay 1 2 3 23 shortMsgAlert 1 2 24 mwdMngt 1 2 3 25 shortMsgMT-Relay 1 2 3 26 imsiRetrieval 2 27 msPurging 2 3 28 subscriberInfoEnquiry 3 29 anyTimeEnquiry 3 32 gprsLocationUpdate 3 36 ss-InvocationNotification 3 37 locationSvcGateway 3 38 locationSvcEnquiry 3
b.
2.
Modify the parameters, if necessary. For phase 2+ use the following version numbers: ZOPH:MODIFY:AC=21:VER=3; ZOPH:MODIFY:AC=23:VER=2; ZOPH:MODIFY:AC=25:VER=3;
Make sure MT-SM is supported in the MSC/VLR ZMXM::::T21=Y; ZMXM::::T22=Y;
152 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
2.3
Configuring TCP/IP connection for SMS The TCP/IP connection is an alternative to the X.25 interface between the SMSC and the MSC. For more information on TCP/IP, see Interfaces between SMS network elements , SMRSE in SMS , and Comparison of SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC . Configuring the TCP/IP connection consists of three parts:
2.3.1
Connecting the SMSC to the SMS-GMSC/SMS-IWMSC Steps
1.
Connect the SMSC to the MSC Connect the SMSC to the MSC physically with the Ethernet cable. In case of i-series products the TCP/IP connection is accessible through the CPU card of the BDCU, otherwise the COCEN card of the BDCU is used.
2.
Create the COCEN plug-in units to the system in case of subrack MSC (WTP) ZWTP:BDCU,0:COCEN,,: INT=;
3.
Create a TCP/IP network interface for each BDCU unit (QRN) Create a TCP/IP network interface for each BDCU unit running the short message transfer system by using the QRN command. Unblock the created interfaces. ZQRN:BDCU,0:::,,::; where: . .
It is EL0 in case of a cartridge MSC. It is COx (x means the PIU index) in case of a subrack MSC.
Expected outcome
You can check the terminal number available in BDCU-0 for the network interface with the following command:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
153 (267)
SMS Guide
ZWTI:P:BDCU,0;
Note In i-series products the terminal number of the CPU card can be used, which is usually 0.
4.
Check ZIPBOXMX.IMG file (MXP) Make sure that the ZIPBOXMX.IMG file can be found in the BLCODE directory. You can check it with the following Service Terminal command in the OMU. ZMXP:WO-BLCODE/ZIPBOXMX.IMG:*
5.
Restart BDCU units (USU) Restart the BDCU units which you modified. Force the units to load the code from the disk with the USU command. ZUSU:BDCU,0:C=DSK;
Further information:
Example 4. Connecting the SMSC to the SMS-GMSC/SMS-IWMSC 1.
Connect the SMSC to the MSC physically with the Ethernet cable. In case of i-series products the TCP/IP connection is accessible through the CPU card of the BDCU, otherwise the COCEN card of the BDCU is used.
2.
Create the COCEN plug-in units for the BDCU-0. The plug-in unit is located in slot 5 in the cartridge, and its interrupt level is 22H. The track number is 47. ZWTP:BDCU,0:COCEN,5,47:INT=22;
3.
Create a TCP/IP network interface for each BDCU unit running the short message transfer system. The netmask length is 25. Unblock the created interface. ZQRN:BDCU,0:CO5:188.67.89.128,P:25:UP;
154 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
4.
Make sure that the ZIPBOXMX.IMG file can be found in the BLCODE directory. You can check it with the following Service Terminal command in the OMU: ZMXP:WO-BLCODE/ZIPBOXMX.IMG:*
5.
Restart the BDCU units which you modified. Force the units to load the code from the disk. ZUSU:BDCU,0:C=DSK;
2.3.2
Creating analysis on SMS application level in the MSC Steps
1.
Create SMS routing support analysis (CFU) You can create a SMS routing support analysis for defining the case when SMS routing analysis is started. ZCFU:SMSC=;
Note You can execute this command only if you have Feature 1165: Short Message Services GSM Phase 2+ Enhancements in use in your network. If you do not have feature 1165, for the available conditions, see SMS routing analysis .
2.
Create an SMS routing analysis (CFE)
Note This step is optional and is necessary only if you want to route the subscriber's SMS request to the service application in the desired SMSC or if you want to create different tariff classes for MO-SMs.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
155 (267)
SMS Guide
ZCFE:PID=,SAP=,SAPTYPE=:SMSC=,TC=,SAN=; 3.
Create an SMSC address analysis (CFS) ZCFS:,IP:LEVEL=, PASSW=::;
4.
Preconfigure the SMSC address, if necessary If you want to use always the same SMSC address towards the MS, you have to add the address to the UTPFIL. For more information, see Working examples for SMS management . a.
Find out the UTPFIL and its number running in the CCSU / GSU (WQV, DFL) ZWQV:CCSU:UTP%;
b. c.
d.
e.
2.3.3
ZDFL:CCSU,0:NAME= ; Find the CM in WO-EX state ZUSI:CM; Find out three free records in UTPFIL (DFD) ZDFD:CM,x:; where is the number for the UTPFIL, given as a hexadecimal. If the variant part (the last 4 digits) is 0000, it can be omitted. For example, 20000 can be given as 2. Add the SMSC address into UTPFIL records Make sure that you do the changes in every CCSU. ZDFS:CM,x:,; Restart every CCSU unit one by one
Setting parameters so that GSM phase 2+ and MT-SM are supported See also MAP in SMS , especially MAP version 3 for more information. MAP version 3 related instructions can be found in Handling SMS-related MAP operations in MSC and HLR .
156 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
Steps
1.
Set parameters so that GSM phase 2+ is supported by default (OPH) a.
Check the SMS-related application context-specific MAP versions ZOPH:INTERR; Examine the SMS-related application contexts on the execution printout. 20 shortMsgGateway 21 shortMsgMO-Relay . 23 shorMsgAlert Note that MAP version 2 is allowed only in this application context. There is no change for MAP version 3. . 24 mwdMngt . 25 shortMsgMT-Relay Modify the parameters, if necessary ZOPH:MODIFY:AC=:VER=; . .
b.
2.
Check MT-SM support in MSC/VLR (MXM) Make sure MT-SM is supported in the MSC/VLR. You can activate them by giving the following commands in the VLR: ZMXM::::T21=Y; ZMXM::::T22=Y;
Further information:
Example 5. Setting parameters so that GSM phase 2+ and MT-SM are supported 1.
Set parameters so that GSM phase 2+ is supported by default a.
Check the SMS-related application context-specific MAP versions. ZOPH:INTERR; Examine the SMS-related application contexts 21 (shortMsgMORelay), 23 (shortMsgAlert) and 25 (shortMsgMT-Relay) on the execution printout. AC NBR AC NAME ALLOWED MAP VERSIONS 1 networkLocUp 1 2 3
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
157 (267)
SMS Guide
2 locationCancellation 1 2 3 3 roamingNumberEnquiry 1 2 3 5 locationInfoRetrieval 1 2 3 7 reporting 3 8 callCompletion 3 10 reset 1 2 11 handoverControl 1 2 13 equipmentMngt 1 2 14 infoRetrieval 1 2 15 interVlrInfoRetrieval 1 2 16 subscriberDataMngt 1 2 3 17 tracing 1 2 3 18 networkFunctionalSs 1 2 19 networkUnstructuredSs 2 20 shortMsgGateway 1 2 3 21 shortMsgMO-Relay 1 2 3 23 shortMsgAlert 1 2 24 mwdMngt 1 2 3 25 shortMsgMT-Relay 1 2 3 26 imsiRetrieval 2 27 msPurging 2 3 28 subscriberInfoEnquiry 3 29 anyTimeEnquiry 3 32 gprsLocationUpdate 3 36 ss-InvocationNotification 3 37 locationSvcGateway 3 38 locationSvcEnquiry 3
b.
2.
Modify the parameters, if necessary. For phase 2+ use the following version numbers: ZOPH:MODIFY:AC=21:VER=3; ZOPH:MODIFY:AC=23:VER=2; ZOPH:MODIFY:AC=25:VER=3;
Make sure MT-SM is supported in the MSC/VLR ZMXM::::T21=Y; ZMXM::::T22=Y;
2.4
Handling SMS-related MAP operations in MSC and HLR The possibility to set MAP version 3 by MMLs appears only if you have Feature 1043: Short Message Services GSM Phase 2+ in use in your network . From Feature 1043 point of view the SMS related Application Context (AC) defaults should be set to version 3. These ACs are the following:
158 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
.
shortMsgGateway 20
.
shortMsgMO-Relay 21
.
mwdMngt 24 and
.
shortMsgMT-Relay 25
If the MAP version of shortMsgMO-Relay (21) Application Context is set to version 3, then the IMSI of A-subscriber is sent to SMS-IWMSC form the VMSC.
Note If there is MAP version 3 in the VMSC, Feature 714: Short Message Service Enhancements is disregarded and normal reason code (MNRR) is sent back instead of system failure, which makes it possible to have Feature 714: Short Message Service Enhancements and Feature 1043: Short Message Services, GSM Phase 2+ switched on at the same time.
Steps
1.
Interrogate the Application Context-Specific defaults (OPH) ZOPH:INTERR;
2.
Set the version of SMS related Application Contexts to version 3 (OPH) Set the version of SMS related Application Contexts (20, 21, 24, 25) to version 3. ZOPH:MODIFY:AC=:VER=; If you do not want to use MAP version 3 signalling between network elements for SMS operations, set back the MAP version of SMS related operations to version 2 using the MML commands mentioned above (OPH for Application Contexts, OPA and OPR for Error Counters, OPS for Alarm Thresholds). Further information:
Example 6. ZOPH:MODIFY:AC=20:VER=3;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
159 (267)
SMS Guide
Further information:
Due to the new MAP version, there is a change in the Network Entity Address Analysis Result Handling. In the OPV command the new MAP version 3 is also a possible value for the MAP operation version.
2.4.1
Handling Error counters in SMS Optionally, you can activate/deactivate/reset Error Counters to MAP operations using the OPA and OPR commands. The Error Counters can be activated/ deactivated/reset to MAP version 3 operations also. Steps
1.
Interrogate the Error Counters (OPA) ZOPA;
2.
Activate/Deactivate Error Counter (OPA) ZOPA:::; Further information:
Example 7. ZOPA:2:3:ACT; 3.
Setting Error Counters for MAP version 3 (OPR) a.
Interrogate the Error Counter
b.
ZOPA; Reset Error Counter ZOPR::;
Further information:
Example 8. ZOPR:2:3; 4.
160 (267)
Setting Error Alarm Threshold (OPS)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
a.
Interrogate Error Alarm Thresholds for MAP operation ZOPQ:;
b.
2.5
for example: ZOPQ:2; Set Error Alarm Thresholds for MAP operation ZOPS::: LOW=,MEDIUM=, HIGH=; for example: ZOPS:2:3:LOW=100,MEDIUM=150, HIGH=200; The HIGH value should be higher than the MEDIUM value, and the MEDIUM value should be higher than the LOW value.
Handling the Welcome SM related parameters Description of the Welcome SM functionality can be found in Welcome SM to the roamer . Before you start
The 'Welcome-SM' related parameters appears only if the WELCOME_SM FIFILE parameter is set to value ACTIVE. If you have the 'Welcome-SM' function you can activate it by MML commands: .
The 'Welcome-SM' function can be activated by setting the WELCOME_SM (class 2) FIFILE parameter to A (activate). ZWOA:,, ; Where: Parameter class in FIFILE (=2). The number of the WELCOME_SM parameter. Given value can be D (deactive) or A (active). The parameter can be checked by the WOS command:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
161 (267)
SMS Guide
ZWOS:,; Steps
1.
Set the SMSC address (in MSC and HLR) (WVS) ZWVS:SCADDR=:NP=, TON=;
Example 9. Set the SMSC address ZWVS:SCADDR=491770000097:NP=E164,TON=INT; 2.
Set the SMSC application address (in MSC and HLR) (WVS) ZWVS:WSCAPP=: NP=,TON=;
Example 10. Set the SMSC application address ZWVS:WSCAPP=491776789:NP=E164,TON=INT; 3.
Set the Configurable MSISDN address of virtual subscriber (WVS) ZWVS:CMSISDN=: NP=,TON=;
Note After setting these three parameters, you need to wait 2 minutes to get the global data updated in MSC.
Example 11. Set the Configurable MSISDN address ZWVS:CMSISDN=491774020388:NP=E164,TON=INT; 4.
Create virtual subscriber in the HLR if you use MAP version 2 (MIC) ZMIC:IMSI=,MSISDN=;
Example 12. ZMIC:IMSI=262030024020388,MSISDN=491774020388;
162 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Configuring network elements for SMS
5.
Interrogate the parameters (in MSC and HLR) (WVI) a. b. c.
6.
Interrogate SMSC address ZWVI:SCADDR; Interrogate SMSC application address ZWVI:WSCAPP; Interrogate Configurable MSISDN address ZWVI:CMSISDN;
Remove the parameters (in MSC and HLR) (WVR) a.
Remove the SMSC address ZWVR:SCADDR=: NP=,TON=;
b.
c.
d.
dn98905102 Issue 5-0 en
for example: ZWVR:SCADDR=491770000097:NP=E164, TON=INT; Remove the SMSC application address ZWVR:WSCAPP=: NP=,TON=; for example: ZWVR:WSCAPP=491776789:NP=E164, TON=INT; Remove the Configurable MSISDN address ZWVR:CMSISDN=: NP=,TON=; for example: ZWVR:CMSISDN=491774020388:NP=E164, TON=INT; Remove virtual subscriber form HLR ZMID:IMSI= or MSISDN=;
# Nokia Corporation Nokia Proprietary and Confidential
163 (267)
SMS Guide
164 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS subscriber-specific data
3
Managing SMS subscriber-specific data The subscriber management functions allow the addition and deletion of the subscriber's short message services. The subscriber can use the SM services only if SMS is provided for him/her through subscriber management. Define the SMS basic services by using the MB command group. For the whole topic summary, see Short Message Services Overview. Steps
1.
Create SMS for a subscriber in HLR (MBF, MBC) a.
Create SMS for a subscriber in HLR (MBF, MBC) If you want to create a basic service with a new basic service code index for a subscriber, you must create first the new basic service code index with the MBF command. . Create the new basic service for the subscriber with the MBC command afterwards. For more information, see instructions on Basic Service Handling . . The recommended way of creating SMS for a number of subscribers at a time is to use multiple subscribers handling. For more information, see Subscriber Administration . Create SMS for subscriber ZMBC:IMSI=,MSISDN=,BSERV=; For IN SMS-related information, see Handling of IN SMS . .
b.
Further information:
Example 13. Creating SMS for a subscriber Create a basic service for a subscriber whose IMSI number is 244041112346 and MSISDN number 358401154322. The teleservice to be created is 'short message MT/PP' (T21). Other parameters have default values.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
165 (267)
SMS Guide
ZMBC:IMSI=24404112346,MSISDN=358401154322,BSERV=T21; 2.
Output a subscriber's SMS data in HLR (MBO, MIS) You can list the basic service data of a given subscriber with the MBO command in the HLR, or the MVO command in the VLR. a.
List the basic service data of a subscriber in the HLR ZMBO:; where specifies the IMSI of the subscriber whose basic services are displayed. The parameter is a decimal number of 15 digits at the maximum. The command lists the following information of the subscriber: international mobile subscriber identity, mobile subscriber international ISDN number, basic service, service area of MSISDN.
b.
These are followed by a list of the bearer capabilities of the subscriber's basic services as determined with the basic service code index (see the MBF command). List the subscriber's service centers in the HLR ZMIS:IMSI=,MSISDN=;
Further information:
Example 14. Outputting a subscriber's SMS data List the basic services of a subscriber whose IMSI is 244041112345. ZMBO:IMSI=244041112345; The execution printout of the command is the following: BASIC SERVICE DATA: INTERNATIONAL MOBILE SUBSCRIBER IDENTITY ... MOBILE STATION ISDN NUMBER ................. BASIC SERVICE .............................. SERVICE AREA OF MSISDN ..................... MOBILE STATION ISDN NUMBER ................. BASIC SERVICE .............................. SERVICE AREA OF MSISDN ..................... MOBILE STATION ISDN NUMBER ................. BASIC SERVICE .............................. SERVICE AREA OF MSISDN ..................... COMMAND EXECUTED
166 (267)
# Nokia Corporation Nokia Proprietary and Confidential
24404112346 358401154322 T11,000 ALL T21,000 ALL T22,000 ALL
dn98905102 Issue 5-0 en
Managing SMS subscriber-specific data
Figure 61.
An example of outputting a subscriber's SMS data
Example 15. Listing the subscribers service centers in the HLR Display the service center addresses of subscriber whose IMSI number is 244051112345. ZMIS: IMSI=2440511123445; The execution printout of the command is the following: INTERNATIONAL MOBILE SUBSCRIBER IDENTITY ...... 244051112345 MOBILE STATION NOT REACHABLE FLAG ............. Y MOBILE STATION NOT REACHABLE FOR GPRS FLAG .....N MOBILE STATION MEMORY CAPACITY EXCEEDED FLAG .. N MOBILE STATION NOT REACHABLE REASON FOR GPRS: IMSIDET!!!!!! MOBILE STATION NOT REACHABLE REASON FOR NON GPRS: USUBMSC SERVICE CENTER ADDRESS (ES) -------------------------------------------------12345678 87654321 COMMAND EXECUTED
The fields in the execution printout have the following meanings: MOBILE STATION NOT REACHABLE FLAG The value Y (Yes) in this field indicates that an attempt to transfer a short message has been unsuccessful because the subscriber has not been reached. MOBILE STATION NOT REACHABLE FOR GPRS FLAG The value Y (Yes) in this field indicates that an attempt to transfer a short message through GPRS has been unsuccessful because the subscriber has not been reached. MOBILE STATION MEMORY CAPACITY EXCEEDED FLAG The value Y (Yes) in this field indicates that an attempt to transfer a short message has been unsuccessful because the mobile memory capacity has been exceeded. MOBILE STATION NOT REACHABLE REASON FOR GPRS or MOBILE STATION NOT REACHABLE REASON FOR NON GPRS These fields give the reason why a mobile station is not reachable for General Packet Radio Service (GPRS) or for non-GPRS. The possible reasons are the following:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
167 (267)
SMS Guide
. . .
. .
.
3.
NPMSC (no paging response through the MSC) IMSIDET (IMSI detached) NPSGSN (no paging response through the SGSN) GPRSDET (GPRS detached) USUBMSC (Unidentified subscriber through the MSC) USUBSGSN (Unidentified subscriber through the SGSN)
Delete a subscriber's SMS (MBD) a.
Delete basic services from a subscriber (MBD)
Note You cannot delete a subscriber's primary basic service.
ZMBD:,; Further information:
Example 16. Deleting a subscriber's SMS Delete basic service data from a subscriber whose IMSI is 244041112345. The MSISDN number of the basic service to be deleted is 358401154321. ZMBD:IMSI=244041112345,MSISDN=358401154321; 4.
Prevent roaming from other networks A subscriber can activate normal MT and MO barrings for SMS. You can activate ODB categories that affect also the subscriber's MO-SMs and MTSMs. For more information, see Feature 220: Operator Determined Barring . You can also use HLR parameters to prevent the sending of MT-SMS and MO-SMS basic services to a given PLMN, in which case the subscriber cannot receive or send SMs when roaming in the given network.
168 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS subscriber-specific data
You can also affect the sending and receiving of SMs with Feature 910: IN Short Message Service . The GSM barrings and operator-determined barrings do not have an effect if the subscriber's SMs go through SGSN. For more information, see the feature description of Feature 857: Support for General Packet Radio System . The HLR contains a separate parameter management for a GPRS subscriber's MT-SMS and MO-SMS basic services.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
169 (267)
SMS Guide
170 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
4
Managing SMS network element-specific data This section gives procedural information on various network element-related functions, such as user data and MNRR handling, activation of picture message information, SMS prevention, SMS measurement, and routing enhancement. For the whole topic summary, see Short Message Services Overview.
4.1
Handling User Data in SMS The transfer of UserData in MO/MT-SM with positive and negative acknowledgement requires MAP version 3 SMS-related operations between the network elements. It means that the version of the SMS-related MAP operations should be set to version 3 both in the MSC and HLR. For the ability to transfer the UserData to the SMSC, the SMSC should be connected to the MSC through TCP/IP. In this case the SMSC level should be set to SMS phase 2+ (S3) in the MSC using the CFS command. Before you start
If you have Feature 1043: Short MessageServices GSM Phase 2+ in use, the network provides full support of SMS GSM phase 2+ standard and MAP version 3 (SMS-related operations). This parameter should be set both in the MSC and HLR. The MAP version of the SMS-related Application contexts should be set to MAP version 3, as described in Handling SMS-related MAP operations in MSC and HLR . Steps
1.
Set the SMSC level to SMS Phase 2+ in MSC (CFS) ZCFS:,IP:LEVEL=;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
171 (267)
SMS Guide
Example 17. ZCFS:1234567890,IP:LEVEL=S3; 2.
Test the UserData transfer in positive acknowledgement a. b. c.
Make a Location Update Send a successful MT-SMS to MS(A) Send a successful MO-SMS to a subscriber
Deactivating the User Data transferring
If you do not want to transfer the UserData between the Mobile Station and the SMSC:
4.2
1.
Set the MAP version 2 for the SMS operations
2.
Set the SMSC level to SMS level 2 using the MML command CFS
Handling of MNRR in SMS The transfer of MNRR requires MAP version 3 SMS-related operations between the network elements. It means that the version of the SMS-related MAP operations should be set to version 3 both in the MSC and HLR. For the ability to transfer the MNRRs to the SMSC, the SMSC should be connected to the MSC through TCP/IP. In this case the SMSC level should be set to SMS phase 2+ (S3) in the MSC by using the CFS command. Before you start
If you have Feature 1043: Short Message Services GSM Phase 2+ in use, the network provides full support of SMS GSM phase 2+ standard and MAP version 3 (SMS-related operations). The MAP version of the SMS-related Application contexts should be set to MAPv3 as described in Handling SMS-related MAP operation in MSC and HLR .
Note If there is MAP version 3 in the VMSC, Feature 714: Short Message Service Enhancements is disregarded, and normal reason code (MNRR) is sent back instead of system failure, which makes it possible to have Feature 714: Short Message Service Enhancements and Feature 1043: Short Message Services, GSM Phase 2+ switched on at the same time.
172 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
Steps
1.
Set the SMSC level to SMS Phase 2+ in the MSC (CFS) ZCFS:,IP:LEVEL=;
Example 18. ZCFS:1234567890,IP:LEVEL=S3; 2.
Test the MNRR a.
b.
Make a Location Update For example to test the IMSI Detached reason code: Make an IMSI Detach. Send an MT-SM to MS (A)
Expected outcome
The MNRF flag and the MNRR field is set in the HLR . Check the MNRR field in the HLR by using the ZMIS:IMSI=; command. The MNRR should be IMSI Detached. 3.
Deactivate MNRR transferring If you do not want to transfer MNRRs between the Mobile Station and the SMSC, do the following a. b.
4.3
Set the MAP version 2 for the SMS operations Set the SMSC level to SMS level 2 by using the MML command CFS
Activating selective CDR generation in SMS With the selective CDR generation functionality the CDR generation can be reduced in the TMSC or based on the SMSC address. This feature makes it possible to differentiate between the suppression of MO and MT CDRs, which results in a decrease of load in the MSC/billing centre. For background information, see Charging records and Selective CDR generation in TMSC and Selective CDR generation based on SMSC address , or refer to feature description of Feature 1043: Short Message Services, GSM Phase 2+ .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
173 (267)
SMS Guide
Before you start
You must have Feature 1043: Short Message Services GSM Phase 2+ in your network to suppress the not needed CDR generation based on the SMSC address. Steps
1.
Make a Location Update
2.
Prevent the CDR generation in the MSC (CFR) a. b.
Interrogate the existing analysis in MSC ZCFI:TYPE=CDR; Prevent CDR generation for the used SMSC address ZCFR:SMSC=, DIRECTION=; MO
prevent CDR generation for MO-SM
MT
prevent CDR generation for MT-SM
BOTH
prevent CDR generation for both MO- and MTSM
3.
Send an MT-SM to MS(A)
4.
Send an MO-SM with MS(A)
5.
Delete the unnecessary SMS CDR generation prevention (CFD) ZCFD:TYPE=CDR:DIG=; Expected outcome
Check that no charging record is generated in MO- and MT-SMS cases. Deactivating selective CDR generation
You can deactivate the Selective CDR generation by deleting the created SMSC analysis for SELECTIVE CDR PREVENTION with the CFD command.
174 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
4.4
Activating Picture message information in the CDR There is a Picture message information in the CDR: concerning to concatenated short message in case of a picture message, you can choose to generate a CDR only for the first SM, instead of generating CDRs for all the SMs in the concatenated SM. In this case, the GEN_CDR_FOR_FIRST_SM PRFILE parameter must be turned on. For further background information see Charging records . Steps
1.
Turn on the GEN_CDR_FOR_FIRST_SM PRFILE parameter (WOC) ZWOC:,, ; Where: 31 28 parameter value is FFh (TRUE), or 00h (FALSE).
4.5
Preventing SMS You are allowed to configure SMSC or A number addresses in the VMSC by MML commands, if Feature 1043: Short Message Services GSM Phase 2+ is available in your network. The following addresses can be configured: .
SMSC address from where the MT-SM is not allowed to be sent
.
SMSC address to where the MO-SM is not allowed to be sent
.
A-subscriber number from where the MO-SM is not allowed to be originated
For testing the different kind of prevention cases you need two switches connected to each other, and an SMSC connected to one of them (this is the 'home switch').
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
175 (267)
SMS Guide
You can deactivate the prevention of SMs from both directions by deleting the created A-NUMBER PREVENTION and SMSC DENY analyses by using the CFD command. For background information, see Barring SMS in the MSC , or refer to feature description of Feature 1043: Short Message Services, GSM Phase 2+ . Steps
4.5.1
1.
Create MS(A) to 'home switch' with SMS capacity, and make a Location Update
2.
Create MS(B) to 'visitor switch' with SMS capacity and make a Location Update
Preventing MT-SMS Steps
1.
Roam with MS(A) to 'visitor switch'
2.
Create an SMSC address barring to 'visitor switch' for the SMSC address (CFL) ZCFL:SMSC=,DIRECTION=, DENYOBJ=; Where: is the ISDN address of the SMSC
can be .
.
'MO' for MO-SMS prevention or 'MT' for MT-SMS prevention
can be . . .
176 (267)
# Nokia Corporation Nokia Proprietary and Confidential
HOME if the barring is for home subscribers VISITOR if the barring is for visitor subscribers ALL if the barring is for all subscribers
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
Further information:
Example 19. ZCFL:SMSC=,DIRECTION=MT,DENYOBJ=VISITOR; 3.
Send an MT-SM to both MS(A) and MS(B)
4.
Test the prevention for HOME and ALL subscribers For testing the prevention for HOME and ALL subscribers delete the existing analysis and create a new one for HOME/ALL subscribers For deleting MT-SMS prevention analysis use the CFD command: ZCFD:TYPE=MT-DENY:DIG=;
5.
Interrogate the existing analysis (CFI) ZCFI:TYPE=MT-DENY; Expected outcome .
.
4.5.2
If the prevention analysis for MT-SMS is set for visitor or all subscribers, it means temporary error for the SMSC so it tries to deliver the SM according to its Retry Table (when real SMSC is used). If the prevention analysis for MT-SMS is set for home subscribers, it means permanent error for the SMSC so it will not try to deliver the SM again.
Preventing MO-SM MO-SM prevention can be configured both into the VMSC and into the SMSIWMSC. Steps
1.
Prevent MO-SM (preventing certain SMSC address) For background information, see Section Barring of MO-SM , especially SMSC barring. a.
Test the analysis affecting VMSC Make a Location Update with both MS(A) and MS(B) to 'home switch'.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
177 (267)
SMS Guide
b.
c.
d.
e. f.
2.
Create an analysis to 'home switch' for MO-SMs (CFL) ZCFL:SMSC=,DIRECTION=MO, DENYOBJ=VISITOR; Send an MO-SM with both MS(A) and MS(B) The MO-SM should be successful for MS(A) as a home subscriber but not successful for MS(B) as a visitor subscriber. Test the prevention for HOME and ALL subscribers For testing the prevention for HOME and ALL subscribers, delete the existing analysis and create a new one for HOME/ALL subscribers Delete MO-SMS prevention analysis (CFD) ZCFD:TYPE=MO-DENY:DIG=; Interrogate the existing analysis (CFI) ZCFI:TYPE=MO-DENY;
Prevent MO-SM (preventing certain subscriber/range of subscribers) a. b. c. d. e.
Test the analysis affecting the VMSC Make a Location Update with MS(A) to 'home switch'. Create an analysis to 'home switch' for MS(A) MSISDN (CFV) ZCFV:MSISDN=; Send an MO-SM with MS(A) Delete analysis (CFD) ZCFD:TYPE=PREV:DIG=; Interrogating the existing analysis (CFI) ZCFI:TYPE=PREV;
Further information:
To test the proper functioning in the SMS-IWMSC for the analyses for MO-SMs that was mentioned above, do the following: a. b. c.
178 (267)
Make a Location Update with both MS(A) and MS(B) to SMSGMSC Create similar analyses to 'home switch' for MO-SMSs by using the MMLs mentioned earlier Try to send MO-SMs with MS(A) /home/ and MS(B) /visitor/ subscribers using the address of the SMSC (SMS generator) connected to the 'home switch'
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
4.6
Activating SMS measurement SMS measurement provides statistical counters for the number of mobileterminating short messages (including welcome MT-SMs) coming from a certain SMSC, and for the number of MO-SMs going to a certain SMSC. In DX 200 MSC the SMS measurement takes place in the STU. In DX 200 Transit MSC the SMS measurement takes place in the CMU. Before you start
The SMSC (latest NOKIA SMSC) should be connected to the DX 200 MSC over TCP/IP connection. The value of the SMS_ENHANCEMENT parameter in the PRFILE should be ON. This enhancement works only if you have Feature 1165: Short Message Services, GSM Phase 2+ Enhancements in your network. For details, refer to the feature description of Feature 1165: Short Message Services, GSM Phase 2+ Enhancements .
Note When the SMS measurement is active, the load of the Message Bus (MB) in the cartridge MSC increases about 15000 byte/s, which means a 0.08% load increase with the 16 Mbyte/s MB (assuming 1.8 million SMs in peak hour). In the transit MSC the load increases about 45800 byte/s, which is 0,13% increase with the 32 Mbyte/s MB (assuming 5.5 million SMs in peak hour). In the subrack MSC, the load of the message bus increases about 1000 byte/s (assuming 120000 SMs in peak hour), which means 0,02% load increase with the 4 Mbyte/s MB (subrack).
Steps
1.
Create Destination Object List for SMS measurement (TDC) You can add 5 SMSC addresses in each type of the SMS measurement. ZTDC:SMS,: SMSCTYPE=:MSC=: SMSC=;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
179 (267)
SMS Guide
Further information:
Example 20. ZTDC:SMS,1:SMSCTYPE=L:MSC=VMSC:SMSC=491770000097; 2.
Create Object List (T2C) ZT2C:MID=: OID=: OLN=; The object list identifier must be 3 digits (for example, 001). Further information:
Example 21. ZT2C:MID=135:OID=001:OLN=TEST; 3.
Start SMS measurement (T2S) ZT2S:NAME=PMEAS135:OID=: RAP=,SD=, ST=,ED=,ET=, ROP=,OD=; Further information:
Example 22. ZT2S:NAME=PMEAS135:OID=001:RAP=15,SD=2001-02-02,ST=0606-06,ED=2001-02-03,ET=06-06-06,ROP=0800-2400,OD=10; 4.
Interrogate SMS measurement (T2I) ZT2I:NAME=: OID=: ICH=; Further information:
Example 23. ZT2I:NAME=:OID=001:ICH=B; 5.
180 (267)
Modify SMS measurement (T2M)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Managing SMS network element-specific data
ZT2M:NAME=: OID=: RAP=, ROP=,OD=; Further information:
Example 24. ZT2M:NAME=:OID=001:RAP=15,ROP=08002400,OD=10; 6.
Stop SMS measurement (T2E) ZT2E:NAME=: OID=:ED=, ET=; Further information:
Example 25. ZT2E:NAME=:OID=001:ED=2001-02-03, ET=06-0 6-06; Further information:
For background information on SMS measurement, see Section SMS measurement .
4.7
Activating routing enhancement in SMS Routing is enhanced by that national and international destinations are handled differently, and that the destination can be addressed with an alphanumeric address. You can define for which SMSC address the SMS routing analysis must be started. This way you can use the number for national service code (with the same digits) with no restrictions, that is, there is no conflict if the country code is the same as the national service code. In addition, the alphabetical numbering makes it easier for the subscribers to use special services which are using applications connected to the SMSC. It can result in increased SMS usage and increased revenue. Before you start
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
181 (267)
SMS Guide
The SMSC (latest NOKIA SMSC) should be connected to the DX 200 MSC over either TCP/IP or X.25 connection. This enhancement works only if you have Feature 1165: Short Message Services, GSM Phase 2+ Enhancements in your network. For details refer to the feature description of Feature 1165: Short Message Services GSM Phase 2+ Enhancements . MAP version 3 is needed for this functionality. The SMSC should support the alphanumeric destination address and the extended destination address length. Steps
1.
Create SMS routing support analysis (CFU) This analysis identifies the SMSC for which the SMS routing analysis has to be executed. ZCFU:SMSC=; Further information:
Example 26. ZCFU:SMSC=491770000097; 2.
Create SMS routing analysis for the SMSC (CFE) ZCFE:PID=, SAP=, SAPTYPE=,TON=;
186 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Activating Nokia-specific SMS features
b.
c.
4.
Set the SMSC application address ZWVS:TRIGAC=:NP=numbering plan>,TON=; Set the common MSISDN number ZWVS:TMSISDN=:NP=numbering plan>,TON=;
Define the detection criteria (MXM) a.
Event detection: inter-PLMN location update ZMXM:INPLU=Y;
b.
c.
d.
This parameter is used when the subscriber arrives from a foreign country, to set that the VMSC generates a trigger SM. Event detection: new visitor and previous LAI is zero ZMXM:NVLAI=Y; This parameter is used to set that VMSC generates a trigger SM when the subscriber arrives to the VLR and the subscriber's previous LAI is zero. Filtering criteria: HOME or VISITOR ZMXM:RSTAT=H; H
home subscriber
V
visitor subscriber
E
every subscriber
The HOME/VISITOR parameter makes it possible that either the HOME subscriber or the VISITOR subscriber is detected only, or both. Filtering criteria: MS_CLASSMARK ZMXM:MCLASS=PH2; PH1
Phase 1 and above equipments are triggered
PH2
Phase 2 and above equipments are triggered
PH3
Phase 3 equipments are triggered
This parameter controls that either the newer mobile phone or every mobile phone is detected. 5.
dn98905102 Issue 5-0 en
Activate Common MSISDN Sending
# Nokia Corporation Nokia Proprietary and Confidential
187 (267)
SMS Guide
Activate this functionality with the COMMON_MSISDN_SENT parameter. ZWOC:2,867,FF;
6.
2
class identifier
867
identifier of COMMON_MSISDN_SENT
FF
value: TRUE
Activate PLMN-specific Filtering Activate this functionality with the NTMS_PLMN_SPEC_FILT parameter. ZWOA:2,942,A;
7.
2
class identifier
942
identifier of NTMS_PLMN_SPEC_FILT
Activate/deactivate Real Time SM Sending Activate the functionality with the NTMS_REAL_TIME_SM_ACTIVE parameter. ZWOC:31,49,1; 31
class identifier
49
identifier of NTMS_REAL_TIME_SM_ACTIVE
1
value: TRUE
Further information:
For further details, see the feature description and the feature activation instructions ofFeature 1433: Terminal Management Support . For more background information, see Real Time triggering .
188 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Activating Nokia-specific SMS features
5.4
Activating MT-SM for Camel Phase 4 Camel Phase 4 extends the available MT-SM services to the roaming subscribers. Steps
1.
Activate the feature (WOA) Activate the feature with the CAMEL_ACTIVE parameter. ZWOA:41,2,04H; 41
class identifier
2
identifier of CAMEL_ACTIVE
04H
value: TRUE
Further information:
For further details, see the feature description and the feature activation instructions of Feature 1364: MT-SM for Camel Phase 4 .
5.5
Activating Direct SM delivery The feature provides solution for direct SM delivery without involving the SMSC. Steps
1.
Activate the feature (WOA) Activate the feature with the MSC_DELIVERED_SM parameter. ZWOA:2,991,A; 2
class identifier
991
identifier of MSC_DELIVERED_SM
Further information:
For detailed information, refer to the feature activation instructions of Feature 1633: Direct SM delivery .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
189 (267)
SMS Guide
5.6
Activating B-IMSI retrieval in MO-side for MNP The feature provide solution for differentiated MO-SM charging for MNP by putting B-IMSI into the SM-MO CDR. Steps
1.
Activate the feature (WOA) Activate the feature with the B_IMSI_FOR_MO_SM parameter. ZWOA:2,1029,A;
190 (267)
2
class identifier
1029
identifier of B_IMSI_FOR_MO_SM
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
6 6.1
Working examples for SMS management Configuring network elements for short message services with load sharing In this example a real configuration is described with more clusters (gateways), load sharing, and the service application being connected to where the operator wants a special routing. Configure network elements for short message services where the logical SMSC address is 358400000000, the physical SMSC addresses are 358400000001, 358400000002, 358400000003, and 358400000004, the VMSC addresses are 358411111111 and 358422222222, the destination point codes of the gateway MSCs are 340 and 341, and the destination point codes of the VMSCs are 301 and 302 (see the figure below).
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
191 (267)
SMS Guide
SMSC-1 VMSC-1 NAMP G/IWMSC-1 Cluster 1
SMSCREMOTE-1
SMSC-2
SMSCREMOTE-2
HLR HPLMN SMSC-3 SMSCREMOTE-3 SMSCREMOTE-4
Cluster 2
VMSC-2
SMSC-4 G/IWMSC-2
Figure 62.
Real-life configuration with load sharing
Note The G/IWMSC presented in the figure has gateway and interworking functions.
If the VMSCs are connected to both G/IWMSCs, the SMS routing support and SMS routing analyses to access NAMP can be done in the VMSCs. This means that MO-SMs can be directly routed to G/IWMSC-1 without passing through G/ IWMSC-2.
Note In the following examples the SMSC level can be set to S2 as well.
192 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
In these examples no GT analyses have been defined previously, so when creating GT analysis with the NAC command the resulting analysis is defined as result record index 1, the next GT analysis is defined as result record index 2, and so on. You can check whether there are already GT analyses defined in your system with the NAI command. If yes, the result record index of the GT analyses starts from the first free record.
Steps
1.
Create global title analyses in the HLR for all physical SMSC ISDNs pointing to their own G/IWMSCs (NAC, NBC) Create global title analyses in the HLR for all physical SMSC ISDNs pointing to their own G/IWMSCs. a.
Create a GT for G/IWMSC-1 ZNAC:NET=NA0,DPC=340,RI=GT; ZNBC:::358400000001:1;
b.
2.
ZNBC:::358400000002:1; Create a GT for G/IWMSC-2 ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000003:2; ZNBC:::358400000004:2;
Group the VMSCs (NAC, NBC) Group the VMSCs (358411111111 and 358422222222) into two clusters. This grouping (defined for logical number) can be implemented through GT analyses in a way that the GT analyses for the logical SMSC address in all VMSCs in cluster 1 should point to G/IWMSC-1 and those in cluster 2 to G/IWMSC-2. a.
In VMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
dn98905102 Issue 5-0 en
ZNBC:::358400000000:1; In VMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
# Nokia Corporation Nokia Proprietary and Confidential
193 (267)
SMS Guide
3.
Create GT analysis in the G/IWMSCs for the logical SMSC-ISDN pointing to itself (NAC, NBC) a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
4.
ZNBC:::358400000000:1; In G/IWMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
Create a GT analysis in the G/IWMSC-2 for the physical SMSC-ISDN to route the SMs to NAMP (NAC, NBC) ZNAC:NET=NA0,DPC=340,RI=GT; ZNBC:::358400000001:2;
5.
Create GT analysis in both G/IWMSCs for the VMSC-ISDN to route MT-SMs (NAC, NBC) a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
b.
6.
ZNBC:::358411111111:2; In G/IWMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:3;
Create GT analysis in both VMSCs for the VMSC-ISDNs pointing to themselves (NAC, NBC) a.
In VMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
b.
7.
194 (267)
ZNBC:::358411111111:2; In VMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:2;
Create GT analysis in the G/IWMSCs for the physical SMSC addresses for Alert SC purposes pointing to themselves (NBC)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
a.
In G/IWMSC-1: As in Step 3 this GT analysis has already been created, result record 1 has to be used. ZNBC:::358400000001:1;
b.
8.
ZNBC:::358400000002:1; In G/IWMSC-2 As in Step 3 this GT analysis has already been created, result record 1 has to be used. ZNBC:::358400000003:1; ZNBC:::358400000004:1;
Create SMS routing support analysis for the logical SMSC ISDN address (CFU) ZCFU:SMSC=358400000000;
9.
Create an SMS routing analysis to access NAMP in both G/IWMSCs pointing to the physical SMSC-ISDN connected to NAMP (CFE) ZCFE:SAP=991,SAPTYPE=NAT:SMSC=358400000001, SAN=NAMP; Further information:
The execution printout of this command is the following: CREATING SMS ROUTING ANALYSIS PID SAP SAPTYPE SMSC ADDRESS TARIFF SERVICE CLASS APPLICATION NAME N 991 NAT 358400000001 - NAMP COMMAND EXECUTED
10.
Create SMSC analyses to G/IWMSC-1 (CFS) ZCFS:358400000000,AEN:LEVEL=S3: ADD: SMSCREMOTE1 , SMSCREMOTE2 ; ZCFS:358400000001,AEN:LEVEL=S3:ADD: SMSCREMOTE1 ; ZCFS:358400000002,AEN:LEVEL=S3:ADD: SMSCREMOTE2 ; The analyses for the physical addresses (358400000001, 358400000002) are needed for the Alert SC request routing.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
195 (267)
SMS Guide
Note In this example the SMSC level can be set to S2 as well.
Expected outcome
The execution printouts of the above commands are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000000 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE1 SMSCREMOTE2
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000001 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE1
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000002 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE2
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command.
196 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
ZCFI:TYPE=SMSC; The example for the execution printout is the following: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE1 SMSCREMOTE2 SMSC ADDRESS = 358400000001 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE1 SMSC ADDRESS = 358400000002 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE2 COMMAND EXECUTED
11.
Create SMSC analyses to G/IWMSC-2 (CFS) ZCFS:358400000000,AEN:LEVEL=S3: ADD: SMSCREMOTE3 , SMSCREMOTE4 ; ZCFS:358400000003,AEN:LEVEL=S3:ADD: SMSCREMOTE3 ; ZCFS:358400000004,AEN:LEVEL=S3:ADD: SMSCREMOTE4 ; Expected outcome
The execution printouts of the commands mentioned above are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000000 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE3 SMSCREMOTE4
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
197 (267)
SMS Guide
CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000003 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE3
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000004 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE4
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command. ZCFI:TYPE=SMSC; The example for the execution printout is the following: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE3 SMSCREMOTE4 SMSC ADDRESS = 358400000003 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE3 SMSC ADDRESS = 358400000004 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE4 COMMAND EXECUTED
12.
Patch UTPFIL in both G/IWMSCs Patch UTPFIL in both G/IWMSCs, that is, put the logical SMSC-ISDN (358400000000) to UTPFIL.
198 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
Note This step is necessary only if you do not have Feature 1165: Short Message Service GSM Phase 2+ Enhancements in your network.
a. b.
Identify the active CM ZUSI:CM; Find the first free record in CCSU-UTPFIL (= record full of zeros) ZDFD:CM,x:5AC0007,; where x is the active CM.
Note For compact MSCi the UTPFIL number is 5AC01017.
c.
d.
Patch the following three records ZDFS:CM,x:5AC0007,y,; where x is the active CM and y is the record to be patched. The new value for the record is: 9D 01 25 00 0C 91 53 48. ZDFS:CM,x:5AC0007,y+1,; where x is the active CM and y+1 is the record to be patched. The new value for the record is: 9D 01 26 00 00 00 00 00. ZDFS:CM,x:5AC0007,y+2,; where x is the active CM and y+2 is the record to be patched. The new value for the record is: 9D 01 27 00 FF FF FF FF. Restart every CCSU unit one by one
The meaning of the record is the following:
Table 11.
Explanation of bytes in UTPFIL records
Byte(s)
Explanation
9D 01
019D (SMHPRB)
25 00
index in SMHPRB
5th byte in record 1
number length of logical SMSC address (for example, 12 = 0C)
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
199 (267)
SMS Guide
Table 11.
Explanation of bytes in UTPFIL records (cont.)
Byte(s)
Explanation
6th byte in record 1
number indicator
7th and 8th bytes in record 1
first part of the number (for example, 53 4 8 ==> 3584)
5th - 8th bytes in record 2
continuation of the number (for example, 00 00 00 00 ==> 00000000)
5th - 8th bytes in record 3
end of the number (for example, FF FF FF FF)
6.2
Configuring network elements for short message services with more MSCs connected to the same SMSC This example shows that it is possible to connect more MSCs to the same SMSC . It shows a possible configuration of network elements for short message services where the logical SMSC address is 358400000000, the physical SMSC addresses are 358400000001 and 358400000002, the VMSC addresses are 358411111111 and 358422222222, the destination point codes of the gateway MSCs are 340 and 341 and the destination point codes of the VMSCs are 301 and 302 (see also the figure below).
200 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
VMSC-1 G/IWMSC-1 Cluster 1 SMSCREMOTE-1
SMSC-1 NAMP
SMSCREMOTE-3
HLR HPLMN
G/IWMSC-2
SMSC-2 SMSCREMOTE-2
Cluster 2
VMSC-2
Figure 63.
SMSCREMOTE-4
Real-life configuration with load sharing and more MSCs connected to the same SMSC
Note The G/IWMSC presented in the figure has gateway and interworking functions. In the following examples the SMSC level can be set to S2 as well. In these examples no GT analyses have been defined previously, therefore when creating GT analysis with the NAC command, the resulting analysis is defined as result record index 1, the next GT analysis is defined as result record index 2, and so on. You can check whether there are already GT analyses defined in your system with the NAI command. If yes, the result record index of the GT analyses starts from the first free record.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
201 (267)
SMS Guide
Steps
1.
Create global title analyses in the HLR for the physical SMSC ISDNs pointing to their own G/IWMSCs (NAC, NBC) a. b.
2.
Create a global title translation result ZNAC:NET=NA0,DPC=340,RI=GT; Create global title analyses ZNBC:::358400000001:1; ZNBC:::358400000002:1;
Group the VMSCs (NAC, NBC) Group the VMSCs (358411111111 and 358422222222) into two clusters. This grouping (defined for logical number) can be implemented through GT analyses in a way that the GT analyses in the VMSC in cluster 1 should point to G/IWMSC 1 and that in cluster 2 to G/IWMSC 2. a.
In VMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
3.
ZNBC:::358400000000:1; In VMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
Create GT analysis in the G/IWMSCs for the logical SC-ISDN pointing to themselves (NAC, NBC) a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
4.
ZNBC:::358400000000:1; In G/IWMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
Create GT analysis in G/IWMSC1 (NBC) Create GT analysis in G/IWMSC1 for the physical SMSC addresses poiting to itself for Alert SC purposes. As this GT analysis has already been created in the previous step, result record 1 has to be used.
202 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
ZNBC:::358400000001:1; ZNBC:::358400000002:1; 5.
Create GT analysis in both G/IWMSCs (NAC, NBC) Create GT analysis in both G/IWMSCs for the VMSC-ISDNs to route MTSMs. a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
b.
6.
ZNBC:::358411111111:2; In G/IWMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:2;
Create GT analysis in both VMSCs for the VMSC-ISDNs pointing to themselves (NAC, NBC) a.
In VMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
b.
7.
ZNBC:::358411111111:2; In VMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:2;
Create SMS routing support analysis for logical SMSC ISDN address (CFU) ZCFU:SMSC=358400000000;
8.
Create an SMS routing analysis to access NAMP (CFE) Create an SMS routing analysis to access NAMP in both G/IWMSCs poiting to the physical SMSC-ISDN connected to NAMP. ZCFE:SAP=991,SAPTYPE=NAT:SMSC=358400000001, SAN=NAMP; Expected outcome
The execution printout of this command is the following:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
203 (267)
SMS Guide
CREATING SMS ROUTING ANALYSIS
PID SAP
SAPTYPE
SMSC ADDRESS
TARIFF CLASS
SERVICE APPLICATION NAME
N
NAT
358400000001
-
NAMP
991
COMMAND EXECUTED
9.
Create SC analyses to G/IWMSC-1 (CFS) ZCFS:358400000000,AEN:LEVEL=S2: ADD: SMSCREMOTE1 , SMSCREMOTE2 ; ZCFS:358400000001,AEN:LEVEL=S3:ADD: SMSCREMOTE1 ; ZCFS:358400000002,AEN:LEVEL=S3:ADD: SMSCREMOTE2 ; The analyses for the physical addresses (358400000001, 358400000002) are needed for the Alert SC request routing.
Note In this example the SMSC level can be set to S2 as well.
Expected outcome
The execution printouts of the above commands are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000000 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE1 SMSCREMOTE2
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
204 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000001 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE1
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000002 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE2
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command. ZCFI:TYPE=SMSC; The example for the execution printout is the following: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE1 SMSCREMOTE2 SMSC ADDRESS = 358400000001 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE1 SMSC ADDRESS = 358400000002 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE2 COMMAND EXECUTED
10.
Create SMSC analyses to G/IWMSC-2 (CFS) ZCFS:358400000000,AEN:LEVEL=S3: ADD: SMSCREMOTE3 , SMSCREMOTE4 ;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
205 (267)
SMS Guide
ZCFS:358400000001,AEN:LEVEL=S3:ADD: SMSCREMOTE3 ; Expected outcome
The execution printouts of these commands are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000000 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE3 SMSCREMOTE4
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS SMSC ADDRESS RESULT SMSC LEVEL AENS
= = = =
358400000001 ROUTE SM TO SMSC WITH AEN STANDARD PHASE 2+ SMSCREMOTE3
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command. ZCFI:TYPE=SMSC; The example for the execution printout is the following: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE3 SMSCREMOTE4 SMSC ADDRESS = 358400000001 RESULT = ROUTE SM TO SMSC WITH AEN SMSC LEVEL = STANDARD PHASE 2+ AENS = SMSCREMOTE3 COMMAND EXECUTED
206 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
11.
Patch UTPFIL in both G/IWMSCs Patch UTPFIL in both G/IWMSCs, that is, put the logical SMSC-ISDN (358400000000) to UTPFIL.
Note This step is necessary only if you do not have Feature 1165: Short Message Services GSM Phase 2+ Enhancements in use in your network.
a. b.
Identify the active CM ZUSI:CM; Find the first free record in CCSU-UTPFIL (= record full of zeros) ZDFD:CM,x:5AC0007,; where x is the active CM.
Note For compact MSCi the UTPFIL number is 5AC01017.
c.
d.
dn98905102 Issue 5-0 en
Patch the following three records ZDFS:CM,x:5AC0007,y,; where x is the active CM and y is the record to be patched. The new value for the record is: 9D 01 25 00 0C 91 53 48. ZDFS:CM,x:5AC0007,y+1,; where x is the active CM and y+1 is the record to be patched. The new value for the record is: 9D 01 26 00 00 00 00 00. ZDFS:CM,x:5AC0007,y+2,; where x is the active CM and y+2 is the record to be patched. The new value for the record is: 9D 01 27 00 FF FF FF FF. You can find the meaning of the record in Table Explanation of bytes in UTPFIL records . Restart every CCSU unit one by one
# Nokia Corporation Nokia Proprietary and Confidential
207 (267)
SMS Guide
6.3
Configuring network elements for SMS with load sharing of SMSC clusters when the traffic category is normal traffic In this example a real configuration is described with TCP/IP interface between the network elements. The main difference between this example and the example given for Configuring network elements for short message services with load sharing, is the way in which the G/IWMSC and the SMSC are connected. To utilise most effectively this interface and reach full redundancy, it is recommended to utilize 2 BDCUs (do not necessarily be dedicated to SMS) in the MSC and create two LAN connections between MSC and SMSC and use 2 IP addresses for one SMSC.
Note It is not allowed to connect SMSC(s) having the same IP address to one MSC.
The example shows a possible configuration of network elements for short message services where the logical SMSC address is 358400000000, the physical SMSC addresses are 358400000001, 358400000002, 358400000003, 358400000004, 358400000005, and 358400000006, the VMSC addresses are 358411111111 and 358422222222, the destination point codes of the gateway MSCs are 340 and 341, and the destination point codes of the VMSCs are 301 and 302 (see also the figure below).
208 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
SMSC cluster 1 SMSC-1 IP1 IP2
IP3
VMSC-1
SMSC-2 NAMP
IP4
G/IWMSC-1 Cluster 1
BDCU
LAN 1 IP5
BDCU
SMSC-3
LAN 2 IP6
HLR HPLMN
SMSC-4 LAN 1
IP7
BDCU
Cluster 2
VMSC-2
BDCU G/IWMSC-2
LAN 2
IP8
IP9
SMSC-5
IP10 SMSC-6 IP11 IP12
SMSC cluster 2
Figure 64.
Real life configuration with load sharing of SMSC clusters
Note The G/IWMSC presented in the figure has gateway and interworking functions.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
209 (267)
SMS Guide
In these examples no GT analyses have been defined previously, so when creating GT analysis with the NAC command, the resulting analysis is defined as result record index 1, the next GT analysis is defined as result record index 2, and so on. You can check whether there are already GT analyses defined in your system with the NAI command. If yes, the result record index of the GT analyses starts from the first free record.
Steps
1.
Create global title analyses in the HLR for the physical SMSC ISDNs pointing to their own G/IWMSC (NAC, NBC) a.
Create a GT for G/IWMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT; ZNBC:::358400000001:1; ZNBC:::358400000002:1;
b.
2.
ZNBC:::358400000003:1; Create a GT for G/IWMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000004:2; ZNBC:::358400000005:2; ZNBC:::358400000006:2;
Group the VMSCs (NAC, NBC) Group the VMSCs (358411111111 and 358422222222) into two clusters. This grouping (defined for logical number) can be implemented through GT analyses in a way that the GT analyses for the logical SMSC address in all VMSCs in cluster 1 should point to G/IWMSC-1 and those in cluster 2 to G/IWMSC-2. a.
In VMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
210 (267)
ZNBC:::358400000000:1; In VMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
3.
Create GT analysis in both G/IWMSCs for the logical SMSC-ISDN pointing to themselves (NAC, NBC) a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=340,RI=GT;
b.
4.
ZNBC:::358400000000:1; In G/IWMSC-2: ZNAC:NET=NA0,DPC=341,RI=GT; ZNBC:::358400000000:1;
Create a GT analysis in the G/IWMSC-2 for the physical SMSC-ISDN to route the SMs to NAMP (NAC, NBC) ZNAC:NET=NA0,DPC=340,RI=GT; ZNBC:::358400000111:2;
5.
Create a GT analysis in G/IWMSC-1 for the physical SMSC-ISDN for NAMP pointing to itself (NBC) As this GT analysis has already been created in step 3 in the G/IWMSC-1 result record 1 has to be used. ZNBC:::358400000111:1;
6.
Create GT analysis in both G/IWMSCs (NAC, NBC) Create GT analysis in both G/IWMSCs for the VMSC-ISDNs to route the MT-SMs. a.
In G/IWMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
b.
7.
ZNBC:::358411111111:2; In G/IWMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:3;
Create GT analysis in both VMSCs for VMSC-ISDNs pointing to themselves (NAC, NBC) a.
In VMSC-1: ZNAC:NET=NA0,DPC=301,RI=GT;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
211 (267)
SMS Guide
b.
8.
ZNBC:::358411111111:2; In VMSC-2: ZNAC:NET=NA0,DPC=302,RI=GT; ZNBC:::358422222222:2;
Create GT analyses in the G/IWMSCs (NBC) Create GT analyses in the G/IWMSCs for the physical SMSC addresses for Alert SC purposes pointing to themselves. a.
In G/IWMSC-1: As this GT analysis has already been created in step 3 result record 1 has to be used. ZNBC:::358400000001:1; ZNBC:::358400000002:1;
b.
9.
ZNBC:::358400000003:1; In G/IWMSC-2: As this GT analysis has already been created in step 3 result record 1 has to be used. ZNBC:::358400000004:1; ZNBC:::358400000005:1; ZNBC:::358400000006:1;
Create SMS routing support analysis for logical SMSC ISDN address (CFU) ZCFU:SMSC=358400000000;
10.
Create an SMS routing analysis to access NAMP (CFE) Create an SMS routing analysis to access NAMP in both G/IWMSCs pointing to the physical SMSC-ISDN connected to NAMP. ZCFE:SAP=991,SAPTYPE=NAT:SMSC=358400000111, SAN=NAMP; Expected outcome
The execution printout of this command is the following: CREATING SMS ROUTING ANALYSIS
212 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
PID SAP
SAPTYPE
SMSC ADDRESS
TARIFF CLASS
SERVICE APPLICATION NAME
N
NAT
358400000111
-
NAMP
991
COMMAND EXECUTED
11.
Create SC analyses to G/IWMSC-1 (CFS) ZCFS:358400000000,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP1 , IP2 , IP3 , IP4 , IP5 , IP6 ,; Create SMSC analyses for IP addresses one by one like this: ZCFS:358400000000,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP1 ,; ZCFS:358400000000,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP2 ,; ZCFS:358400000000,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP3 ,; and so on. Confirm each command execution. ZCFS:358400000111,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP3 ; ZCFS:358400000111,IP:LEVEL=S3:ADD: IP4 ; ZCFS:358400000001,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP1 ; ZCFS:358400000001,IP:LEVEL=S3:ADD: IP2 ; ZCFS:358400000002,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP3 ; ZCFS:358400000002,IP:LEVEL=S3:ADD: IP4 ; ZCFS:358400000003,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP5 ;
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
213 (267)
SMS Guide
ZCFS:358400000003,IP:LEVEL=S3:ADD: IP6 ; The analyses for the physical addresses (358400000001, 358400000002, 358400000003) are needed for the Alert SC request routing. In case of Alert SC there is no load sharing between the IP addresses, and always the first IP address is used. It is important to define two IP addresses compulsorily belonging to one SMSC, because if one LAN breaks down, the Alert SC sending will succeed through the other LAN. Expected outcome
The execution printouts of the above commands are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
214 (267)
= = = = =
# Nokia Corporation Nokia Proprietary and Confidential
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72
dn98905102 Issue 5-0 en
Working examples for SMS management
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
dn98905102 Issue 5-0 en
= = = = =
# Nokia Corporation Nokia Proprietary and Confidential
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72
215 (267)
SMS Guide
172. 24.175. 73 172. 24.175. 74 COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73 172. 24.175. 74
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73 172. 24.175. 74 172. 24.175. 75
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND: SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73 172. 24.175. 74 172. 24.175. 75
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
216 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73 172. 24.175. 74 172. 24.175. 75 172. 24.175. 76
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000111 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 73
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000111 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 73
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000111 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 73 172. 24.175. 74
COMMAND EXECUTED
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
217 (267)
SMS Guide
CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000001 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000001 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000001 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 71 172. 24.175. 72
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS = 358400000002 RESULT = ROUTE SM TO SMSC WITH IP SMSC LEVEL = STANDARD PHASE 2+
218 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
PASSWORD IPS
= PASSWORD = 172. 24.175. 73
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000002 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 73
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000002 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 73 172. 24.175. 74
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000003 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 75
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS = 358400000003
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
219 (267)
SMS Guide
RESULT SMSC LEVEL PASSWORD IPS
= = = =
ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 75
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000003 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 75 172. 24.175. 76
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command. ZCFI:TYPE=SMSC; The execution printout should look like this: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000001 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 71 172. 24.175. 72 SMSC ADDRESS = 358400000002 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 73 172. 24.175. 74 SMSC ADDRESS = 358400000003 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 75 172. 24.175. 76 SMSC ADDRESS = 358400000111 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 73 172. 24.175. 74 SMSC ADDRESS = 358400000000
220 (267)
# Nokia Corporation Nokia Proprietary and Confidential
IP
IP
IP
IP
dn98905102 Issue 5-0 en
Working examples for SMS management
RESULT = ROUTE SM TO SMSC WITH IP SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 71 172. 24.175. 72 172. 24.175. 73 172. 24.175. 74 172. 24.175. 75 172. 24.175. 76 COMMAND EXECUTED
12.
Create SMSC analyses to G/IWMSC-2 (CFS) ZCFS:358400000000,IP:LEVEL=S3,PASSW=: ADD: IP7 , IP8 , IP9 , IP10 , IP11 , IP12 ; Create SMSC analyses for IP addresses one by one like in the previous step. Then confirm each command execution. ZCFS:358400000004,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP7 ; ZCFS:358400000004,IP:LEVEL=S3:ADD: IP8 ; ZCFS:358400000005,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP9 ; ZCFS:358400000005,IP:LEVEL=S3:ADD: IP10 ; ZCFS:358400000006,IP:LEVEL=S3,PASSW=PASSWORD: ADD: IP11 ; ZCFS:358400000006,IP:LEVEL=S3:ADD: IP12 ; Expected outcome
The execution printouts of these commands are the following: CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH IP SMSC LEVEL = STANDARD PHASE 2+
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
221 (267)
SMS Guide
PASSWORD IPS
= PASSWORD = 172. 24.175. 77
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
222 (267)
= = = = =
# Nokia Corporation Nokia Proprietary and Confidential
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77
dn98905102 Issue 5-0 en
Working examples for SMS management
172. 24.175. 78 172. 24.175. 79 COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
223 (267)
SMS Guide
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80 172. 24.175. 81
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80 172. 24.175. 81
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000000 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80 172. 24.175. 81 172. 24.175. 82
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
224 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000004 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000004 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000004 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 77 172. 24.175. 78
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000005 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 79
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
225 (267)
SMS Guide
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000005 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 79
CONFIRM COMMAND EXECUTION: Y/N ? Y MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000005 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 79 172. 24.175. 80
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
NO EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND
CREATING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000006 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 81
COMMAND EXECUTED CREATING/MODIFYING SMSC ADDRESS ANALYSIS
EXISTING ANALYSIS FOR THIS SMSC ADDRESS FOUND:
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000006 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 81
CONFIRM COMMAND EXECUTION: Y/N ? Y
226 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Working examples for SMS management
MODIFYING SMSC ADDRESS ANALYSIS
SMSC ADDRESS RESULT SMSC LEVEL PASSWORD IPS
= = = = =
358400000006 ROUTE SM TO SMSC WITH IP STANDARD PHASE 2+ PASSWORD 172. 24.175. 81 172. 24.175. 82
COMMAND EXECUTED
Further information:
If you want to check the SMSC address analyses, use the CFI command. ZCFI:TYPE=SMSC; The example for the execution printout is the following: SMSC ADDRESS ANALYSES SMSC ADDRESS = 358400000004 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 77 172. 24.175. 78 SMSC ADDRESS = 358400000005 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 79 172. 24.175. 80 SMSC ADDRESS = 358400000006 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 81 172. 24.175. 82 SMSC ADDRESS = 358400000000 RESULT = ROUTE SM TO SMSC WITH SMSC LEVEL = STANDARD PHASE 2+ PASSWORD = PASSWORD IPS = 172. 24.175. 77 172. 24.175. 78 172. 24.175. 79 172. 24.175. 80 172. 24.175. 81 172. 24.175. 82 COMMAND EXECUTED
13.
dn98905102 Issue 5-0 en
IP
IP
IP
IP
Patch UTPFIL in both G/IWMSCs
# Nokia Corporation Nokia Proprietary and Confidential
227 (267)
SMS Guide
Patch UTPFIL in both G/IWMSCs, that is, put the logical SC-ISDN (358400000000) to UTPFIL.
Note This step is necessary only if you do not have Feature 1165: Short Message Services GSM Phase 2+ Enhancements .
a. b.
Identify the active CM ZUSI:CM; Find the first free record in CCSU-UTPFIL (= record full of zeros) ZDFD:CM,x:5AC0007,; where x is the active CM.
Note For compact MSCi, the UTPFIL number is 5AC01017.
c.
d.
Patch the following three records: ZDFS:CM,x:5AC0007,y,; where x is the active CM and y is the record to be patched. The new value for the record is: 9D 01 25 00 0C 91 53 48. ZDFS:CM,x:5AC0007,y+1,; where x is the active CM and y+1 is the record to be patched. The new value for the record is: 9D 01 26 00 00 00 00 00. ZDFS:CM,x:5AC0007,y+2,; where x is the active CM and y+2 is the record to be patched. The new value for the record is: 9D 01 27 00 FF FF FF FF. You can find the meaning of the record in Table Explanation of bytes in UTPFIL records . Restart every CCSU unit one by one
Further information:
For the whole topic summary, see Short Message Services Overview.
228 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Service Troubleshooting
7
Short Message Service Troubleshooting The following sections give instructions on what to do in case of problems related to SMS sending, for example, how to correct situations when subscribers do not receive their SMs or receive them twice, or when the SM is not sent though the SMSC acknowledges the successful sending, or when SMS charging is not appropriate. For the whole topic summary, see Short Message Services Overview.
7.1
Problems related to SMS network elements The current SMS contains certain deficiencies in the service level because of some incomplete standardisation (3GPP TS 23.040 and 29.002). These deficiencies can cause delay in the SM transfer to subscribers, and in the worst case the subscribers can be jammed out so that they are unable to receive SMs unless some corrective action is taken. The defects that can occur because of incomplete standardisation are listed below, together with possible corrective methods. Discrepancy between MWF and MWD
Situation: In some circumstances an error situation can occur where the MNRF is set in VLR but the MWD is not set in HLR, or vice versa. The first one is not a problem, because it causes only an additional indication of a mobile becoming reachable. The latter, however, can cause the subscriber not to receive SMs. In this case a subscriber is detached and switches his/her mobile on (IMSI attach) but receives no SMs. This is due to a signalling collision in the A interface and in the lower layers. If TMSI reallocation, ciphering and other activities are defined to take place during IMSI attach or location updating, the signalling takes so much time that the SM arrives too early, when the mobile cannot yet answer to paging requests. This causes the MWD to be set again, and the delivery of the SM fails.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
229 (267)
SMS Guide
Only after a call or period location updating the VLR notices its MNRF and the delivery is attempted again. Only priority SMs can be sent to the subscriber if the SMSC supports priority SMs. The MWD can only be cleared after a location update in the HLR, or manually by the operator.
Analysis: During update location to a new VLR, signalling delays can cause the old VLR to set its MNRF and to send an MWD to the HLR when the new VLR has no MNRF, and no knowledge of the MWD in the HLR. The reason is that the new VLR address is accepted in the HLR only after a certain period of time.
Corrective action: Add delay to the sending of Alert-SC from HLR to SMSC so that the new VLR is ready to receive the SM. The delay prevents SMs from arriving too early to the MSC. Give the following MML command: ZMJM:ALERT=5; It should now take about 5 seconds before subscriber B receives an SM after switching his/her MS on.
7.2
Problems related to SMS A interface Subscriber does not receive SM after becoming reachable
Situation: If a subscriber is temporarily away from the coverage area, and an SM is sent to him/her, the MWF is set in the VLR even if the subscriber does not have MTSMS basic service provisioned. For more information, see Special conditions of unsuccessful MT-SM delivery.
Analysis You can check the status of the MWF and the provisioned SMS basic services for the subscriber with MML commands. The SMSC address is set in the subscriber's MWD list. When the MS is reachable again, the VLR does not receive the information; thus it cannot clear the MWF. The VLR notices the MWF only after a call or a period location updating.
230 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Service Troubleshooting
The VLR knows when the subscriber is registered in the VLR (IMSI attached) and does not respond to paging requests. In this situation the subscriber is presumed not to be under the coverage area. Usually when paging fails, an 'absent subscriber' error indication is returned to the SMSC, which assumes that the HLR notifies SMSC when a subscriber is reachable again (MWF and MWD are set).
Corrective action: One method of improving reachability is to change the 'absent subscriber' error indication towards the SMSC to another one which better indicates that the situation is temporary. This is done by using internal error codes in the MAP and X.25 protocols that both the MSCs and SMSC support. In this case both the MWF and the MWD are set. Another way, that depends on the SMSC functionality, is to change the 'absent subscriber' error indication to a 'system failure' towards the SMSC. This error cause indicates a temporary error situation in which the SMSC must poll the subscriber periodically because only the MWF is set in the VLR. The first model is implemented because the latter error code has other meanings as well. If the SMSC receives 'invalid SME address' when delivering an MT-SM, it indicates that the subscriber can be in a blind spot and does not answer to paging. The SMSC polls the MS periodically with a priority SM to check if the subscriber has come to coverage area. For related information, see Alarms and their meanings in Short Message Service. Subscriber receives duplicated SMs
Corrective action: CP DATA retransmission can be controlled in the PRFILE with the following A interface parameters. Normally you do not need to modify these parameters: PRFILE class 31 SHORT MESSAGE SERVICE .
000 TC1 MINIMUM -
dn98905102 Issue 5-0 en
default value 0 seconds allowed range from 0 (0 s) to 3000 (30 s) minimum duration of the timer TC1 controlling CP-DATA resending
# Nokia Corporation Nokia Proprietary and Confidential
231 (267)
SMS Guide
.
001 TC1 DELTA -
.
value presented in 10 ms default value 0 no allowed range defined for this parameter delta to the timer TC1* value retrieved from the channel type and the short message length
002 CP_DATA_REPETITION -
default value 1 allowed range from 1 to 3 maximum number of CP-DATA message resendings
See also Sections SMS-related general PRFILE/FIFILE parameters and Alarms and their meanings in Short Message Service .
7.3
SMS problems related to SMRSE interface Some frequent problem situations caused by SMRSE interface configuration failures are presented below. If any MO- and MT-SMS traffic breakdown happens, or connection establishment fails in the SMSC, as a help to identify the problem, an advanced monitoring and checking possibility is provided with the CFI command, which allows you to obtain information on the current state of the SMRSE links. ZCFI:type=conn_tbl; MS-A gets 'Message not sent this time' although MS-B receives the SM successfully
Situation: Every time an MO-SM is sent to the SMSC, a timer is started in the MSC. That timer controls the MO-SM transaction. If there is congestion somewhere in the SMRSE interface or the SMSC is temporarily overloaded, the MO-ACK message can arrive later than the default 10 s time limit. In this case the MO-ACK arrives after the timer expiration, therefore the SMRSE application has already sent MONACK towards MS-A, despite the fact that the SMSC has delivered the SM successfully to MS-B.
Analysis:
232 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Service Troubleshooting
Check the BDCU computer log of the SMS-IWMSC with the GSC service terminal command. The following error logs indicate this error situation: .
MO timeout
.
delayed MO/ALERT-ACK
.
number of delayed MO/ALERT-ACKs
The following error logs also indicate that there is some delay in the MO-SM processing: .
delayed MO/ALERT-NACK
.
number of delayed MO/ALERT-NACKs
However, these two errors indicate a different situation from the previous one: the MO-SM transaction was unsuccessful and MS-B did not receive the SM.
Corrective action: Increase the value of the timer controlling the MO-SM by setting the PRFILE parameter called SMRSE_MO_TIMER (31:38) to the appropriate value. This value should be the default value (10 s = 1000D) plus the maximum delay time (if the maximum delay time is much greater than the average delay time, then the parameter should be set to the default time plus the average delay time value). The delay time of an MO-(N)ACK is the time which elapses starting form the MO timeout until the delayed MO-(N)ACK arrives and the 'Delayed MO/ ALERT-(N)ACK' error log is written. This interval can be calculated by comparing the timestamps of that 'MO timeout' and 'Delayed MO/ALERT-(N) ACK' error log pair whose message reference in the user data information field is matching. For example, in case of the following MO-SM transaction, which is identified by message reference 00F5, the delay is 0.09 s. WRITE TIME: YYYY-MM-DD HH:MM:SS PARAMETERS: E-02 001C.00007650 00000001 000C.00009C10 USER TEXT : MO timeout. USER DATA : 00F5 WRITE TIME: YYYY-MM-DD HH:MM:SS PARAMETERS: E-02 001C.00007650 00000001 000C.0000DF99 USER TEXT : Delayed MO/ALERT-ACK. USER DATA : 00F5
Note
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
233 (267)
SMS Guide
1.
Change the SMRSE_MO_TIMER only if the problem described above occurs regularly.
2.
The setting of the SMRSE_MO_TIMER requires special attention because a timer which is not correctly configured can cause problems in the SM transfer. For example, if you accidentally set the MO timer value too short (1.1 s instead of 11 s) it results in even more MO-NACK than before changing the parameter. Also, you should set this parameter to a lower value than the MO control timer value of the SMS application in the SMSIWMSC, which is 12 s by default.
3.
A radically increased MO timer value also means that the message entries in the MO pending table are kept reserved for a longer time, so if there are several slow MO-transactions, and at the same time lots of incoming MOSMs, the MO pending table can be filled up. Consequently, there is no free message entry for every MO-SM, and those without message entry are negatively acknowledged back to the SMS application.
Configure the parameter very carefully to reach the optimal settings. PRFILE class 31 SHORT MESSAGE SERVICE .
038 SMRSE_MO_TIMER -
default value 1000D (10 s) allowed range from 0 (0 s) to 2000D (20 s) SMRSE MO-SM response timer in SMS-IWMSC
Subscriber receives duplicated SMs
Situation: Every time the SMRSE application in the SMS-GMSC forwards an MT-SM to the SMS application, a timer is started which controls that MT-SM transaction. If there is a congestion in the network towards the MS, or part of the NSS is overloaded, the MT-ACK sent by the SMS application can arrive later than the default 90 s time limit. In this case the MT-ACK arrives after the timer expiration, therefore the SMRSE application has already sent MT-NACK towards the SMSC. Consequently, the SMSC re-sends this SM despite the fact that MS-B has successfully received it.
Analysis: Check the BDCU computer log of the SMS-GMSC with the GSC service terminal command. The following error logs indicate this error situation:
234 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Service Troubleshooting
.
MT timeout
.
MT entry not found
.
Delayed MT ACK (only in case of TCP/IP SMRSE application)
The following error log also indicates that there is some delay in the MT-SM processing: .
delayed MT NACK (only in case of TCP/IP SMRSE application)
However, in this case, as opposed to the previous situation, the MT-SM transaction was unsuccessful, so MS-B might not receive the SM several times.
Corrective action: Increase the value of the timer controlling the MT-SM by setting the PRFILE parameter called SMRSE_MT_TIMER (31:39) to the appropriate value. This value should be the default value (90 s = 9000D) plus the maximum delay time (if the maximum delay time is much greater than the average delay time, then the parameter should be set to the default time plus the average delay time value). The delay time of an MT-(N)ACK is the time that elapses starting form the MT timeout until the delayed MT-(N)ACK arrives and the 'MT entry not found' error log is written. This interval can be calculated by comparing the timestamps of that 'MT timeout' and 'MT entry not found' error log pair whose message reference in the user data information field is matching. For example, in case of the following MT-SM transaction, which is identified by message reference 02E1, the delay is 2.46 s. WRITE TIME: YYYY-MM-DD HH:MM:SS PARAMETERS: E-02 001C.00007654 00000001 000C.0000B3AD USER TEXT : MT timeout. USER DATA : 02E1 WRITE TIME: YYYY-MM-DD HH:MM:SS PARAMETERS: E-02 001C.00007654 00000001 000C.00006D09 USER TEXT : MT entry not found. USER DATA : 02E1
Note
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
235 (267)
SMS Guide
1.
Change the SMRSE_MT_TIMER only if the problem described above occurs regularly.
2.
The setting of the SMRSE_MT_TIMER requires special attention, because a timer which is not correctly configured can cause problems in the SM transfer. For example, if you accidentally set the MT timer value too short it causes more MT-NACK. Furthermore, a too long MT timer can affect the retransmission of the unsuccessful MT-SMs in the SMSC. That is, with longer MT timer the SMSC has to store the pending messages for a longer time, so its buffers can be filled more easily, and this can result in congestion. On the other hand, the value of this parameter can not exceed the MT control timer of the SMSC either.
3.
A radically increased MT timer value also means that the message entries in the MT pending table are kept reserved for a longer time, so if there are several slow MT-transactions and at the same time lots of incoming MTSMs, the MT pending table can be filled up. Consequently, there is no free message entry available for every MT-SM and these SMs are negatively acknowledged back to the SMSC.
Configure the parameter very carefully to reach the optimal settings. PRFILE class 31 SHORT MESSAGE SERVICE .
039 SMRSE_MT_TIMER -
7.4
default value 9000D (90 s) allowed range from 0 (0 s) to 15000D (150 s) SMRSE MT-SM response timer in SMS-GMSC
Problems related to SMS charging Real charging information is not forwarded to the charging application
Situation: It can happen that the subscriber, for example, removes the battery from the MS (or in some mobiles, pushes the 'red button') right after sending a short message and thus, commits fraud. For more information, see MO-SM fraud prevention .
Analysis:
236 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Short Message Service Troubleshooting
For example, if the subscriber removes the battery (or pushes the 'red button') right after sending a short message, the subscriber forces the SMS application to inform the charging application about the MO-SM being unsuccessful despite the fact that the MO-SM was delivered to the SMSC successfully.
Corrective action: You can use the 031:0025 CHAR_WITHOUT_ACK_TO_MS PRFILE parameter to prevent MO-SM fraud. For related information, see Short message routing , and Short message charging .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
237 (267)
SMS Guide
238 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
8
Additional information on SMS
8.1
MT operation in VMSC SMS resending
In handover cases the MSC notices that a handover occurred and sets a new timer supervision that is greater than the one in the MS. The SMS resending is performed only after the supervision time has exceeded, because it is possible that the MS has not received the first CP-DATA message at all. The following logical timers are presented in the message sequences listed below: T1
Supervision for CP-ACK message when CP-DATA message is sent. It is calculated from the SMS length, and varies between 3 - 20 seconds.
T2
The overall supervision time for the total SM transfer.
T5
The time period after which the MS is likely to have received the CP-DATA message. It is calculated from the SM length and varies between 1 - 15 seconds. If a handover is received during this time, timer T1 is set again in order to see whether the MS received the first CP-DATA message.
T6
If a handover is received during a time period after which the MS is likely to have received the CP-DATA message, this guard timer is set before the CP-DATA message is resent. This may happen after the T5 has expired.
The following figure shows a case where a handover takes place after the MS has received the CP-DATA message, and the MSC delays the SM resending. The result is that no duplication is made as the MS has time to acknowledge this with the CP-ACK message:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
239 (267)
SMS Guide
MS
MSC CP-DATA 1
MSC starts timers T1, T2 and T5 TO SIM MT-SMS 2 T5 has expired in MSC, T1 T2 are running FROM BTS handover 3 MSC starts timer T6 CP-ACT 4 T6, T1 and T2 are running in MSC resending causing duplication is avoided CP-DATA 5 CP-ACK
Figure 65.
6
MT-SM in the MCS, channel handover, no SM resending
1.
The MSC sends an MT-SM to an MS in the CP-DATA message.
2.
The MS receives the MT-SM and begins to store it.
3.
The MSC is notified about the handover. The 10 second timer is started in the MS before the CP-ACK message is resent.
4.
The MS acknowledges that the MT-SM has been received.
5.
The MS sends a response to the MT-SM.
6.
The MSC replies that the MT-SM has been acknowledged by the MS.
The following figure shows a case where a handover takes place after the MS has received the CP-DATA message, and the MSC delays the SMS resending. The CP-ACK message sent by the MS is lost and will be resent:
240 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
MS
MSC CP-DATA 1
MSC starts timers T1, T2 and T5 TO SIM MT-SMS 2 T5 has expired in MSC, T1 T2 are running FROM BTS handover 3 MSC starts timer T6 FROM TIMER T6 4 CP-DATA 5 CP-ACK 6 CP-DATA 7 CP-ACK
Figure 66.
dn98905102 Issue 5-0 en
8
MT-SM in the MSC, channel handover, SM resending takes place
1.
The MSC sends an MT-SM to an MS within the CP-DATA message.
2.
The MS receives the MT-SM and begins to store it.
3.
The MSC is notified about the handover.
4.
Supervision timer T6 expires.
5.
The SM resending takes place.
6.
The MS acknowledges that the MT-SM has been received.
7.
The MS sends a response to the MT-SM.
8.
The MSC replies that the MT-SM has been acknowledged by the MS.
# Nokia Corporation Nokia Proprietary and Confidential
241 (267)
SMS Guide
The following figure shows a case where a handover takes place before the MS has received CP-DATA message, and the MSC resets timer T1, thus delaying the resending of CP-DATA message:
MS
MSC CP-DATA 1
MSC starts timers T1, T2 and T5 FROM BTS handover 2 T5, T1 and T2 are running in MSC T1 timer is set again CP-DATA 3 CP-ACK 4 5
Figure 67.
CP-DATA CP-ACK
6
MT-SM in the MSC, channel handover, SM resending takes place
1.
The MSC sends an MT-SM to the MS within the CP-DATA message.
2.
SMS resending takes place. Timer T1 expires, resulting in SM resending.
3.
The MS acknowledges that the MT-SM has been received.
4.
The MS sends a response to the MT-SM.
5.
The MSC replies that MT-SM has been acknowledged by the MS.
The following figure shows a case where no handover takes place, but the MS does not reply at all. T1 expires, which results in the SM resending:
242 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
MS
MSC CP-DATA 1
MSC starts timers T1, T2 and T5 CP-DATA 2 T1 has expired in MSC, T2 is running CP-ACK 3 4
CP-DATA CP-ACK
Figure 68.
5
MT-SM in the MSC, T1 expires, SM resending takes place
1.
The MSC sends an MT-SM to the MS within the CP-DATA message.
2.
SM resending takes place.
3.
The MS acknowledges that the MT-SM has been received.
4.
The MS sends a response to the MT-SM.
5.
The MSC replies that the MT-SM has been acknowledged by the MS.
Values for timers
The MSC has the timeout supervision T1 for CP-ACK. The timeout is calculated from the SM length according to the following rules: .
Channel type is SACCH : (SMS_LENGTH/18)*0.96 sec + 6 sec + delta
.
Channel type is SDCCH : (SMS_LENGTH/20)*0.24 sec + 3 sec + delta
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
243 (267)
SMS Guide
If CP-ACK is not received during the time calculated on the basis of the channel type and SM length, it will be resent. Resending counts may vary from 1 to 3. Counts and timer delta values can be set in Parameter File (PRFILE), Class 31. In practice, timer T1 varies from 3.3 to 15 seconds, and SMS_LENGTH in the A interface from 33 to 172 octets. Timer T5 is related to T1, it is the part of T1 used for sending CP-DATA to the MS when T1 includes also the CP-ACK sent by the mobile station. Therefore T5 is estimated to be T1 - 5 seconds in SACCH channel, and T1 - 2 in SDCCH channel. Timer T6 is derived from the MS resending timer. In the MS the timer value is 10 seconds, therefore the MSC has the value of 13 seconds. Timer T2 is the maximum time that can be left for the A interface signalling. When the SM arrives through the MAP interface to the MSC, the maximum timeout in the SMS-GMSC for sending the MT-SM is 60 seconds. The 58 second timer is set for the VMSC MAP, and the 55 second time is left for the A interface. You can find an estimate of the worst case for T2 below: .
If a handover takes place at the latest point when the resending is possible, the time is Start + T1 (that is, 15 s).
.
The next step is to start resending the guard timer T6. T6 is 13 seconds (in MS 10 seconds, in MSC a margin of 3 seconds must be added).
.
T6 expires, and resending takes place. T1 is started again, the time now is Start + T1 + T6 (that is, 15 + 13 s).
.
The MS gives an acknowledgement just before T1 expires, the time now is Start + T1 + T6 + T1 (that is, 15 + 13 + 15 s).
If you want to make sure that a duplication exists, prepare to wait for responses for a long time. Here the total time would be 43 seconds, and that does not include MS paging, authentication, and what needs to be done before beginning to send an MT-SM. Also check when resending is possible, that is, how much time has already been consumed by comparing the present time with the time left in T2. For example, if several handovers take place, each of which causes T6 to be reset, there are 14 seconds left in T2 at the point when the last handover takes place, and T1 is calculated to be 15 seconds, stop the SM transfer. The reason for the interruption is that the time left would probably not be sufficient. For more information, see VMSC and VLR .
244 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
8.2
SMS procedures performed by MAP The following figure illustrates the MO-SMS and MT-SMS from the point of view of MAP:
A subs.
SMSC
6.
4.
3.
1.
7.
10.
2. VMSC
14.
SMS-GMSC
VMSC 13.
5. 8.
9.
12.
11.
HLR
B subs.
Figure 69.
MT-SMS and MO-SMS procedures performed by MAP
Note Numbers 1 6 in the figure apply to MO-SMS and numbers 7 14 to MT-SMS
The numbers given in the figure refer to the following:
dn98905102 Issue 5-0 en
1.
RP-MO-Data
2.
FwdSMarg
# Nokia Corporation Nokia Proprietary and Confidential
245 (267)
SMS Guide
3.
SC_RP_MO_DATA
4.
SC_RP_MO_ACK
5.
FwdSMres
6.
RP-MO-Ack
7.
SC_RP_MT_DATA
8.
SRIforSMarg
9.
SRIforSMres
10.
FwdSMarg
11.
RP-MT-Data
12.
RP-MT-Ack
13.
FwdSMres
14.
SC_RP_MT_ACK
The following paragraphs explain the procedures in detail: 1.
MobileOrginatingSM The MO SMS procedures are used to forward an SM from a mobile subscriber to an SMSC . The MAP offers a procedure which can be used to transfer an MO-SM from the VMSC to the SMS-IWMSC . a.
MO SMS transfer procedure in MAP version 1 and version 2: ForwardSM (FSM) begins a dialogue, and the VMSC sends the operation in the TC-BEGIN message when it receives an SM from the MS. If the SMS-IWMSC knows the SMSC, it transfers the SM to it. When the SMS-IWMSC receives a response for the SM from the SMSC, it transfers the response to the VMSC.
2.
RoutingInfoEnquiryForSM The SM handling function of the SMS-GMSC requests the routing information from the HLR when it receives an MT-SM from the SMSC. When the routing information is received, and the subscriber is registered in the MSC area in question (SMS-GMSC), the SMS-GMSC itself sends the MS to the MS. Otherwise the SMS-GMSC transfers the SM to the VMSC.
246 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
RoutingInfoEnquiryForSM procedures offered by MAP are different in InformServiceCentre operation to tell the SMSC which ISDN number is used to indicate the availability of the SM for SMs. a.
RoutingInfoEnquiryForSM procedure in MAP version 1: SendRoutingInfoForSM (SRI-SM) begins a dialogue, and the SMSGMSC sends the operation in the TC-BEGIN message when it receives an SM from the SMSC.
b.
After handling the procedure, the HLR sends the result or an error message for SRI-SM in TC-END. RoutingInfoEnquiryForSM procedure in MAP version 2: .
.
.
3.
The SendRoutingInfoForSM (SRI-SM) begins a dialogue, and the SMS-GMSC sends the operation in the TC-BEGIN message when it receives an SM from the SMSC. After handling the procedure, the HLR sends the result or an error message for the SRI-SM in the TC-END message. The HLR can send an optional InformServiceCentre operation which is packed in the same network primitive as the SRI-SM result/error.
MobileTerminatingSM The MT-SM transfer procedure is used to forward an SM or several SMs from an SMSC to a mobile subscriber. The MAP offers a procedure which can be used to transfer an MT-SM from the SMS-GMSC to the VMSC. MT-SM transfer procedures offered by MAP are different in the MAP versions 1 and 2. In version 1, only one SM can be transferred during a dialogue, but in version 2, several SMs can be transferred during the same dialogue. a.
MT-SM transfer procedure in MAP version 1:
b.
ForwardSM begins a dialogue, and the SMS-GMSC sends the operation in the TC-BEGIN message if it has received routing information from the HLR, indicating that the subscriber is registered in another MSC area. If the subscriber is reachable, the VMSC sends him/her the SM. . When the VMSC receives a response for the SM from the MS, it transfers the response to the SMS-GMSC. After receiving the response, the SMS-GMSC may start ReportSMDeliveryStatus, in any case, it transfers the responses to the SMSC. MT-SM transfer procedure in MAP version 2: .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
247 (267)
SMS Guide
The ForwardSM operation can appear several times in a dialogue. Furthermore, the first FSM may contain only the MAP-OPEN PDU if the PDU and the SM are too large to fit together in one TCAP primitive. .
.
.
.
4.
The ForwardSM begins a dialogue, and the SMS-GMSC sends the operation in the TC-BEGIN message if it has received routing information from the HLR indicating that the subscriber is registered in another MSC. If the message is too long to fit in the network message frame, only the MAPOPEN-PDU is sent in the TC-BEGIN message, and the message part is sent separately after that. If the MS can be reached, the VMSC sends an SM to it. When the VMSC receives a response for the SM from the MS, it transfers the response to the SMS-GMSC. After receiving the response, the SMS-GMSC can start the ReportSM-DeliveryStatus, in any case, it transfers the responses to the SMSC. In the multiple SM transfer, the FSM service can be used several times. The FSM is always acknowledged to the SMSC before the next SM is sent.
ReportSM-DeliveryStatus
Note This operation was called SetMessageWaitingData in the old specification.
If the MT-SM transfer fails, the SMS-GMSC can inform this to the HLR by using the ReportSM-DeliveryStatus operation. The following figure illustrates a situation where MT-SM sending fails and the HLR is notified:
248 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
SMSC
2.
VMSC
SMS-GMSC
1.
3.
4.
HLR
Figure 70.
MT-SM sending fails, HLR is notified
The numbers given in the figure refer to the following: a. SRIforSMarg/res b. FwdSMarg/res c. ReportSM-Delivery Status arg d. ReportSM-Delivery Status res The SMS-GMSC informs the HLR if an absent subscriber, unidentified subscriber, or SM delivery failure with 'error cause MS memory capacity exceeded' indication is received from the visited MSC, and the corresponding flags received in the InformServiceCentre operation are not already set, or the SMSC address is not yet included in the MWD set. The SMS-GMSC may also invoke the procedure when the transfer was successful, if the MNRF and MCEF flags, or both, were set in the HLR. a.
ReportSM-DeliveryStatus procedure in MAP version 1 and version 2: .
.
dn98905102 Issue 5-0 en
ReportSM-DeliveryStatus (RSM-DS) begins a dialogue, and the SMS-GMSC sends the operation in the TC-BEGIN message when it receives ForwardSM response from the VMSC. After handling the procedure, the HLR sends the result or an error message for RSM-DS in the TC-END message.
# Nokia Corporation Nokia Proprietary and Confidential
249 (267)
SMS Guide
5.
ReadyForSM When receiving the ProcessAccessRequest or UpdateLocationArea indication from the MS, while the MS not reachable flag (MNRF) is set, the VLR starts the ReadyForSM procedure to the HLR. The ReadyForSM procedures offered by MAP are different in MAP versions 1 and 2. a.
b.
6.
ReadyForSM in MAP version 1 The NoteSubscriberPresent operation begins and ends a dialogue, and the VLR sends the operation in the TC-BEGIN message to the HLR. Because this is a class 4 operation, and the procedure does not contain any other operations, the dialogue is ended immediately. ReadyForSM in MAP version 2 The ReadyForSM operation begins a dialogue, and the VLR sends the operation in the TC-BEGIN message to the HLR. If an error occurs in the HLR, the HLR sends an error message containing UnknownSubscriber, DataMissing, FacilityNotSupported and SystemFailure, otherwise it sends an empty result for the ReadyForSM in the TC-END message to the VLR.
Alert-SC When the subscriber has an SMSC address or addresses in the MWD, and the HLR receives ReadyForSM, UpdateLocation or Supplementary Service Control request for this subscriber, it can start Alert-SC procedure to all SMSCs included in the subscriber's MWD. The Alert-SC procedures offered by MAP are different in MAP version 1 and 2. a.
b.
Alert-SC in MAP version 1 The Alert-SC-WithoutResult operation begins and ends a dialogue, and the HLR sends the operation in the TC-BEGIN message. Because this is a class 4 operation, and the procedure does not contain any other operations, the dialogue is ended immediately. Alert-SC in MAP version 2 The Alert-SC operation begins the dialogue, and the HLR sends the operation in the TC-BEGIN message to the SMS-IWMSC. If an error occurs in the HLR, the HLR sends an error message containing the UnknownSubscriber, DataMissing, FacilityNotSupported and SystemFailure, otherwise it sends an empty result for Alert-SC in the TC-END message.
The following figure illustrates the ReadyForSM and Alert-SC procedures:
250 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
VMSC
1.
GMSC
2.
3.
SMSC
4.
HLR
Figure 71.
ReadyForSM and Alert-SC procedures
The numbers given in the figure refer to the following: 1.
NoteMSpresent (MAP 1) ReadyForSMarg
2.
Ready res
3.
AlertSCwithoutRes Arg (MAP 1) AlertSC Arg
4.
AlertSCRes
For more information, see MAP in SMS and Interfaces between SMS network elements .
8.3
Comparison of the SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC The DX 200 MSC/VLR enables you to use the SMSC with SMRSE or SS7 MAP connection. The SMS architecture in case of SMRSE over X.25 or TCP/IP SMSC is the following:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
251 (267)
SMS Guide
SMS-IWMSC
VMSC
MAP-E
A MS
MAP-E MAP-C
MAP-Gd
SMRSE
SMSC
SMRSE
Gb MAP-Gd
SGSN
SMS-GMSC
MAP-C
HLR
Figure 72.
SMS architecture in case of SMRSE over X.25 or TCP/IP
The SMS architecture in case of SS7 MAP is the following:
252 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
VMSC
MS A
SMSC MAP-E
MAP-Gd
MAP-C
HLR SGSN
Figure 73.
SMS architecture in case of SS7 MAP
Due to the different architecture, the provided functionalities are different in the cases given above. Note that this section does not cover the functionalities provided with the SMRSE over TCP/IP SMSC.
8.3.1
Functional differences between SMRSE over X.25 or TCP/IP and SS7 MAP SMSC Charging and statistics
The charging and statistic functionalities in the SMS-IWMSC and the SMSGMSC are the following: .
Creating CDR s Subscriber billing can be based on the CDRs generated in the SMSIWMSC and the SMS-GSMC. See the following examples:
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
253 (267)
SMS Guide
1.
Those home subscribers' SMs who are roaming out of the HPLMN can be charged in the SMS-IWMSC. 2. The SMs generated by applications can be charged in the SMSGMSC where the tariff class information is available, or when the destination home subscriber is out of the HPLMN, the application generated SMs can be charged only in the SMS-GMSC. 3. The charging of the command SM and/or the status report SM can be in the SMS-GMSC and the SMS-IWMSC when the home subscriber is out of the HPLMN. The CDRs generated in the SMS-IWMSC and the SMS-GMSC are not available in case of SS7 MAP SMSC, however, if the charging is in the SS7 MAP SMSC and the SMSC has an interface with the Billing Centre, the above cases can be handled also in the SS7 MAP SMSC. .
Field reporting - service measurement T21 SHORT MESSAGE MT GMSC and T22 SHORT MESSAGE MO IWMSC counters are not updated in case of MAP SMSC.
.
MAP measurement The SendRoutingInfoForSM and the ReportSM-DeliveryStatus operation are not counted according to the source in the MSC in case of MAP SMSC.
.
Online call monitoring (OLCM) and Lawfully Authorized Electronic Surveillance (LAES) information is not available from the SMS-IWMSC and the SMS-GMSC in case of MAP SMSC.
For more information, see Short message charging , and SMS-related statistics . Routing of SMs to service applications
The SMS routing analyses are used to route the SMs based on PID and/or prefix towards the proper SMSC. The logic of these analyses is strongly determined by the used SMS architecture, therefore in case of changing the SMS architecture the SMS routing analysis and the SMSC address analysis should be reconsidered in all MSCs. Tips for checking the analyses:
254 (267)
.
The result of SMSC address analysis can be number modification or SMSC deny in case of SS7 SMSC. Beyond these results, the result can be AEN(s) in case of X.25 over SMRSE SMSC.
.
If you uses tariff class information for charging SMs, it is preferable to include this information in SMS routing analysis results in every MSC of the HPLMN.
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
Additionally, the SCCP routings are also different: .
In MSC: using GT analysis, the result of the GT analysis should be the routing to the MAP SMSC in case of MAP SMSC, and routing to the SMS-IWMSC in case of SMRSE SMSC.
.
In HLR: using GT analysis, the result of the GT analysis should be the routing to the MAP SMSC in case of MAP SMSC, and routing to the SMS-GMSC in case of SMRSE SMSC.
For further information, see Short message routing . MAP interface
The MAP operation SendIMSI is not available in case of MAP SMSC, therefore the IMSI as a subscriber identifier cannot be used in charging. However, the SS7 MAP SMSC implements the SendIMSI operation and fetches the subscriber's IMSI from the HLR. The MAP-Gd interface is also supported by the SS7 MAP SMSC, so the subscribers using only GPRS can send and receive short messages to and from the MAP SS7 SMSC. PRFILE parameters without effects in case of MAP interface .
CHARGING BASED ON IMSI (feature 619): the value of this parameter has no effect
.
SMS_EXT_MSG_REF_IN_X25 (feature 619): the value of this parameter has no effect
.
MMS_SMSC_TIMER (feature 620): the value of this parameter has no effect
For related information, see SMS-related general parameter file (PRFILE/ FIFILE) parameters . Possible defects
The function which provides corrective method for the incomplete standardisation problems (subscriber does not receive SM after becoming reachable, discrepancy between Messages Waiting (MWF) and MWD ) does not work in case of SS7 SMSC. For further information about the function see the feature description of Feature 714: Short Message Service Enhancements .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
255 (267)
SMS Guide
8.4
Functions of SMSC level in SMS The available functions of SMS, and the SMSC levels associated with them are described in the interface specification of MSC-SMSC Interface for TCP/IP in the MSC Specification . The following addresses can be transferred only if the SMSC level is set to N3. .
MO logical SMSC address in Rp_timeout message Making the use of predefined SMSC addresses unnecessary through enabling that the status report is appropriate even if the operator has several SMSC addresses.
.
Alert SC address in Alert message Identifying the SMSC to be used for the alerting procedure.
.
IMSI and VMSC/SGSN address in Rp_Ack and RP_error message (MT case)
IMSI and VMSC/SGSN address sent to the SMSC in MT SMS
The IMSI number of subscriber B and the destination VMSC/SGSN address are sent to the SMSC (on the TCP/IP interface) in the MT SMS acknowledgement (RPAck and RPError) messages. In the RPAck message the VMSC or the SGSN address is sent depending on which delivery was successful, while in the RPError message both addresses are sent regardless of the HLR settings. The SMSC requires the IMSI and VMSC/SGSN data for statistical purposes. In addition, if the SMSC charges for SMS, the VMSC address is a useful piece of information for locating subscriber B.
Note You can use this feature if you have the SMSC connected through SMRSE with TCP/IP. MAP version 3 is needed for this functionality. For details, refer to the feature activation instructions of Feature 1165: Short Message Services, GSM Phase 2+ Enhancements . The SMSC level has to be set to N3.
The following message sequence shows how the parameters are sent in the RP_Ack message.
256 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
SMSC
SMSGMSC
SC_RP_MT_DATA
HLR
VMSC
MS
MAP_SEND_ ROUTING_INFO _FOR_SM MAP_SEND_ ROUTING_INFO _FOR_SM_ACK (IMSI, VMSC/SGSN) MAP_MT_FORWARD_ SHORT_MESSAGE Page Positive page response CP_DATA CP_ACK CP_DATA
SC_RP_ACK (IMSI, VMSC/SGSN)
Figure 74.
8.5
MAP_MT_FORWARD_ SHORT_MESSAGE _ACK
CP_ACK
Successful MT-SM transfer with two new parameters towards the SMSC
Alarms and their meanings in Short Message Service The following alarms may be issued in connection with SMS. For more information, see referential material on Alarms .
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
257 (267)
SMS Guide
.
1024, HAND CREATION FAIL This alarm is issued if there is overload in the network or in one of the units, or in situations when the capacity is increased (especially in the transit MSC) because of heavy traffic.
.
1088, SMSC ACCESS FAILURE This alarm is used to indicate an unauthorised attempt to create a connection. It is raised if there is a failed attempt for a connection. The situation occurs if the SC address analysis is missing for the SMSC which tries to open a connection. The alarm is also used when the connection drops down in an unexceptional way, for example, when the physical medium breaks down.
.
2439, SMSC LINK FAILURE The system sets the alarm when SM sending to SMSC fails because of link failure. The priority of the alarm is three stars. Check the link state and connection parameters as well as hardware. The system clears the alarm automatically after recovery. This alarm is related to X.25 and TCP/IP link. In case of TCP/IP links, the alarm is generated only for physical SMSC addresses. Logical SMSC addresses cannot be alarmed.
.
1572, SMS SUBMIT PRIMITIVE ENCODING FAILURE Due to the use of the PNP service in the SMS, an error occurred in the encoding of the TPDU . The data in the TPDU contains erroneous values. This alarm is related to the A interface.
.
1647, OPERATION TIMER EXPIRY An operation has been sent to the network, but an acknowledgement to it has not been received fast enough, and as a result, the ongoing dialogue is interrupted. The effect on the functioning of the system and on the service received by the subscriber depends on the operation in question. The disturbance can indicate a routing problem, or congestion in the network element to which the operation was sent. This alarm is related to MAP protocol.
.
1652, DECODING ERROR OF THE MESSAGE RECEIVED FROM THE MS The alarm notifies the user about a message which was received from the MS and could not be decoded. This alarm is generated when CPDU encoding fails due to:
258 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
incorrect message type (not CP-ACK, CP-ERROR or CP-DATA) incorrect protocol identifier (not SMS) incorrect transaction identifier or when RPDU encoding fails due to: .
too long SM (TPDU ) incorrect SC address
2246, SCCP ROUTING FAILURE The SCCP has failed in routing a message received from the user part of the SCCP. The alarm is caused by erroneous configuration of the system. The fault may affect the traffic capacity of the system. This alarm is related to MAP protocol.
.
2646, PROTOCOL ROUTING FAILURE A routing problem has been detected in a protocol dialogue. This indicates that the protocol cannot send the operation to the network because its own subsystem does not function, or that a faulty routing address has been received from the network or from the user of the protocol, or that there is no global title translation for the routing address used. Due to the error situation, protocol traffic is congested either partly or totally. This alarm is related to MAP protocol.
.
2748, NO ANALYSIS FOR SMSC ADDRESS The HLR sends the number of the SMSC to the MSC in connection with the AlertSC operation, but no analysis can be found for this number in the MSC. This alarm is related to X.25 link.
.
2749, NO ANALYSIS FOR SMSC AEN The number of the SMSC is analysed in connection with the AlertSC operation. The result is the identifier of the remote application. The identifier is used in an inquiry to find out the OSHORT identifier and the PSAP addresses. Also the identifiers of the O45LRS and the plug-in unit are received. If the inquiry fails, the alarm is generated. This alarm is related to X.25 link.
.
1224, MISSING MOLIMITER FOR SMSC LINK The missing_molimiter_a alarm is raised by ZIPBOX PRB during the connection establishment between the MSC and SMSC if there is no MO Limiter value in the SMR-BIND request for the given TCP/IP link and the SMS_ENHANCEMENT and the DYN_TCPIP_LOADSHARING PRFILE parameters are turned on. The disturbance can be cleared by the operator.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
259 (267)
SMS Guide
8.6
SMS-related general parameter file (PRFILE/FIFILE) parameters The following PRFILE/FIFILE parameters are related to SMS: TC1_MINIMUM 031:0000 Minimum duration of TC1* timer. TC1_DELTA
031:0001 Delta to timer TC1* value retrieved from channel type and short message length.
CP_DATA_REPETITION 031:0002 Maximum number of CP-DATA message resending. SMS_QUEUING_TIME 031:0003 Maximum queuing time of short messages. MMS_WAIT_TIMER 031:0007 Subsequent short message waiting timer. MMS_PHASE_1_MS_SUPPORT 031:0008 MMS is supported for phase 1 mobiles. NUMBER_OF_MMS 031:0009 Maximum number of simultaneous MMS short messages. MMS_SMSC_TIMER 031:0010 SMSC timer for subsequent short message in GMSC.
260 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
SMS_EXT_MSG_REF_IN_X25 031:0013 Short Message Service; Extended SMS message reference in X.25 link. CHARGING_BASED_ON_IMSI 031:0014 SMS charging based on IMSI. IN_MM_FOR_SMS_ACT 031:0015 IN Short Message Service. MAX_MT_REFERENCE 031:0016 Maximum number of concurrent MT short messages. MAX_MO_REFERENCE 031:0017 Maximum number of concurrent MO short messages. SMS_PORT_NUMBER 031:0018 TCP/IP port number for short message service. ALIVE_CHECK_INTERVAL 031:0019 Timer value for TCP/IP connection check. SELECT_SMS_CDR_GEN 031:0023 Suppress unnecessary CDR generation based on the SMSC address. GPRS_SUPP_IN_SMSGMSC 031:0024 GPRS support in SMS-GMSC.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
261 (267)
SMS Guide
CHAR_WITHOUT_ACK_TO_MS 031:0025 Fraud prevention in MO-SM. MO_SM_STATUS_REP_REQ 031:0027 Mobile-originated short message with the indication of status report requested. GEN_CDR_FOR_FIRST_SM 031:0028 Generation of a CDR only for the first message in the concatenated SM. SMS_MAP_SMSCADDR 031:0031 SMSC address transfer on MAP. DYN_TCPIP_LOADSHARING 031:0032 Dynamic loadsharing on TCP/IP links between MSC and SMSC. X25_LENGHT_ENC_SCHEME 031:0033 Encoding of SMS on X.25 interface. IN_MM_FOR_SMS_MO 031:0034 Activation of MO-SMS IN-TDP. IN_MM_FOR_SMS_MT 031:0035 Activation of MT-SMS IN-TDP. A_NUM_CHECK_IN_CONN 031:0037
262 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
Checking the MSISDN number of the A-subscriber in the CONNECT operation (MT-VMSC, MT-SM). MO_TIMER_SMRSE 031:0038 MO timer for the SMRSE interface operations. MT_TIMER_SMRSE 031:0039 MT timer for the SMRSE interface operations. WELCOME_SM 002:0681 Activation and use of the Welcome SM operation in the VMSC. SCP_AVAILABILITY_TIMER 006:0036 SCP availability timer. TCPIP_SMMT_OLC_USED 012:0074 Overload control. BDCU_UNHA_MSGS_LIM_IN 012:0075 Overload control. BDCU_UNHA_MSGS_LIM_OUT 012:0076 Overload control. SMS_FORW_IN_HLR 002:0851 HLR-based SMS CFU.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
263 (267)
SMS Guide
B_IMSI_FOR_MO_SM 002:1029 B-IMSI retrieval in MO side for MNP. NTMS_REAL_TIME_SM_ACTIV 031:0049 Activation and deactivation of Real-time trigger SM sending. MMS-related parameters
MMS_WAIT_TIMER 031:0007 Subsequent short message waiting timer. MMS_PHASE_1_MS_SUPPORT 031:0008 MMS is supported for phase 1 mobile stations. NUMBER_OF_MMS 031:0009 Maximum number of simultaneous MMS short messages. MMS_SMSC_TIMER 031:0010 SMSC timer for subsequent short message in GMSC. For related information, see Parameters needed for CAMEL SM .
8.7
Parameters needed for CAMEL SM CAMEL_TSSF_TIMER (0041:0004)
The TSSF timer determines the time in 100 milliseconds, after which the gsmSSF aborts the dialogue with the gsmSCF if no response has been received from the gsmSCF. CAMEL_ACTIVE (0041:0002)
The parameter also indicates whether CAMEL is in use.
264 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
That is, in case of mobile-originating short messages, the gsmSCF contact is possible if the MO-SMS-CSI has been provisioned to the sending subscriber. This means that originating short messages are handled with the control of CAMEL service if the parameter value is set to 3. In case of mobile-terminating short messages, the gsmSCF contact is possible if the MT-SMS-CSI has been provisioned to the sending subscriber. This means that originating short messages are handled with the control of CAMEL service if the parameter value is set to 4. CAMEL_SUPPORTED_PHASE (0041:0001)
This parameter indicates which CAMEL phase is supported in the network element (MSC/VLR, HLR). It controls whether no CAMEL functionality, CAMEL phase 1, CAMEL phase 1 and 2, CAMEL phase 1, 2 and 3, or CAMEL phase 1, 2, 3 and 4 is active or deactive in the network element (MSC/VLR, HLR). In CAMEL phase 1 only the active/deactive values are used. With this parameter you can make sure that all CAMEL services (of all phases) provisioned to the gsmSCF can be used.
8.8
Parameters for SMS A-interface configuration Check and set the following PRFILE parameters controlling SMS queuing and multiple messages. Class 31: Short Message Services .
031:0003 SMS QUEUING TIME -
.
031:0007 MMS WAIT TIMER -
dn98905102 Issue 5-0 en
default value 3000 (30 s) allowed range is not limited but MAP timers require values less than 30 s maximum waiting time in the queue
default value 90 allowed range from 0 to 300 how long subsequent short message is waited before the A- interface and MAP connection is released in the VMSC
# Nokia Corporation Nokia Proprietary and Confidential
265 (267)
SMS Guide
.
031:0008 MMS PHASE 1 SUPPORT -
.
default value TRUE allowed range FALSE, TRUE This parameter defines whether the more messages facility may be sent for phase 1 mobile stations.
031:0010 MMS SMSC TIMER
8.9
Parameters needed for Sending SMS without SMSC
8.9.1
FIFILE parameter MSC_DELIVERED_SM (002:0991)
This parameter controls the feature activation and deactivation.
8.9.2
PRFILE parameters ROUTE_IND_MSC_DELIV_SM (031:0042)
This parameter sets the preferred delivery route (MT-VMSC/Serving GPRS Support Node (SGSN)) for the DIRECT-SM. DIRECT_SM_FAILURE_IND (031:0043)
This parameter allows the MSC to set the reserved value of the TP-MTI field in the SUBMIT-MO-SM. Thus, the SMSC can be informed about the MTSM delivery failure. DIRECT_SM_STA_CHA_INFO (031:0044)
This parameter enables the MSC to change the SMSC address to predefined SMSC address, which can be seen in the SMS measurement and charging data records. This allows that normal SMs and DIRECT-SMs can be differentiated in the statistic report and CDRs. DIRECT_SM_STAT_REP_USED (031:0045)
This parameter allows you to enable or disable the sending of status report (if it is requested by subscriber A) after successful direct SM delivery.
266 (267)
# Nokia Corporation Nokia Proprietary and Confidential
dn98905102 Issue 5-0 en
Additional information on SMS
DIRECT_SM_FOR_PREPAIDS (031:0046)
Using this parameter you can enable or disable direct SM delivery of MO-SMs initiated by prepaid subscribers with special routing category values (defined in UTPFIL). FORW_SM_TO_SC_IF_SR_REQ (031:0047)
If the MSC performs Direct SM delivery, it is possible that subscriber A does not receive the Status report back. If this parameter is set, and MO-SM contains a status report request, the MSC forwards the MO-SM to SMSC but does not make Direct SM delivery DIRECT_SM_BASED_ON_SAN (031:0048)
If MS-MS SMS routing is used in the network, the Service Application Name in SMS routing table has to decide whether Direct SM delivery is used for the arriving MO-SM.
dn98905102 Issue 5-0 en
# Nokia Corporation Nokia Proprietary and Confidential
267 (267)
View more...
Comments
