SMS Flow

SMSCDOC9000.00 Nokia SMS Center, Rel. SMSC 9.0, Product Documentation, v.
Message Handling
DN03305622 Issue 5-0 en
# Nokia Siemens Networks
1 (89)
Message Handling
The information in this document 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 Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks 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 are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2007. All rights reserved.
2 (89)
DN03305622 Issue 5-0 en
Contents
Contents
Contents 3 1 1.1 1.2 2 2.1 2.2 3 3.1 3.2 3.3 4 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.4.1 4.3.4.2 4.3.4.3 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.3.10 4.3.11 4.3.12 4.3.13 4.3.14 4.3.15 4.3.16 4.3.17 About this document 5 Summary of changes 5 References 6 Message handling overview 9 Message handling in the network 9 Message handling in the SMS Center
11
Message flow scenarios 15 Mobile-originated - mobile-terminated SMs 15 Mobile-originated - application-terminated SMs 17 Application-originated - mobile-terminated SMs 18 Message processing 21 Mobile-originated (MO) message handling 24 Telecom interface checkings 24 Terminating SMS gateway 27 Mobile number portability (MNP) based barring 28 Anonymous short message 31 Commands in the message 32 Application-originated (AO) message handling 34 CIMD2 application capacity control 35 PSW routing 36 Commands for external applications 36 Common message handling for all (MO-MT, MO-AT or AO-MT) messages 37 Message validation 37 MSC direct SM delivery 38 Virtual SMS Center 39 Resolving destination 39 PID routing 43 PID re-routing 44 Shortcut MT routing 45 Number conversion and barring 46 CIMD2 application overload control (part 1) 48 Subscriber user groups 49 Delivery attributes 51 Message redirection 52 SCTS, PMD, ICA, LIC 52 Online closed user group 56 Regional barring 56 In advance credit check interface 56 Content-based filtering 57 Message collecting interface 58 Fast-forward MT/AT 58 Failures in submitting short messages 63
DN03305622 Issue 5-0 en
3 (89)
Message Handling
4.3.18 4.3.18.1 4.3.18.2 4.3.18.3 4.3.18.4 4.3.18.5 4.3.18.6 4.3.18.7 4.3.18.8 4.3.18.9 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.5 4.5.1 4.5.2 4.6 4.6.1 4.6.2 Appendix A.1 A.1.1 A.1.2
Scheduling message delivery 63 Prioritising messages 64 Scheduled delivery 67 Rescheduling deliveries 67 Rescheduling HLR-based SMS forwarding deliveries Rescheduling FFMT deliveries 69 Deferring deliveries 69 Delaying deliveries 69 MMS hinting 70 Negative validity period 71 Mobile-terminated (MT) message handling 72 Barring based on destination IMSI 72 MT routing 73 MT overload control 75 Failures in delivering short messages 75 Successful delivery 77 Application-terminated (AT) message handling 77 Suffix stripping 78 CIMD2 application overload control (part 2) 78 Status reports 79 Phase 1 and phase 2 status reports 79 Status report for first temporary result 80 A Failure error codes 83 Failure error codes 83 Delivery error codes 83 Submit error codes 86
69
Appendix B List of PIDs 87 B.1 List of PIDs 87
4 (89)
DN03305622 Issue 5-0 en
About this document
About this document

This document describes how Nokia Short Message Service Center (SMS Center) handles the short messages. We also give a basic description about short message handling in the GSM network, but mainly concentrate on the SMS Center internal operations. By message handling we mean the flow of short messages, status reports and internal messages. In addition to the message handling, this document describes the processes of the SMS Center, and lists the commands that applications use to handle the short messages. This document is intended for operator personnel who need information on Nokia SMS Center's internal message handling.
1.1
Date Release
November 2007 SMSC9.0
Summary of changes
Document identifier Issue
dn03305622 5-0 en Updated for SMS Center 9.0. - Added SMS Relaying Guide, dn70402186 to Section References. - Added 'relayed traffic' to the list of traffic types in Chapter Message flow scenarios. - Added information about SMS relaying and added also a reference to SMS Relaying Guide in Chapter Message flow scenarios.
Changes
January 2006 SMSC8.1
dn03305622 4-0 en
Updated for SMS Center 8.1. New section:
Terminating SMS gateway
DN03305622 Issue 5-0 en
5 (89)
Message Handling
Date Release
September 2005 SMSC8.0
Document identifier Issue

dn03305622 3-0 en
Changes
Updated for SMS Center 8.0. New sections:
Subscriber user groups Delivery attributes Message redirection Regional barring Content-based filtering MT routing
Modified sections:
SCTS, PMD, ICA, LIC Fast-forward MT/AT

June 2004 SMSC7.0 dn03305622 2-0 en Updated for SMS Center 7.0. The whole document has been restructured.
1.2
References
Nokia SMS Center documents
Administration Guide, dn03299867 Configuration Files, dn03299531 External Applications Configuration Guide, dn03325626 In Advance Credit Check Interface Guide, dn03315009 Message Collecting Interface Guide, dn0430677 Online Closed User Group Guide, dn03315121 Operating Guide, dn03299879 Privilege Mobile Destination Guide, dn03366909 SMS Relaying Guide, dn70402186 Subscriber User Groups Guide, dn0518061
6 (89)
DN03305622 Issue 5-0 en
About this document
Terminating SMS Gateway Guide, dn7064234 Virtual SMS Center Guide, dn02214675
Other documents 3GPP TS 23.040, Technical realization of the Short Message Service (SMS), Release 6
DN03305622 Issue 5-0 en
7 (89)
Message Handling
8 (89)
DN03305622 Issue 5-0 en
Message handling overview

The point-to-point short message service (SMS) provides means for sending messages of a limited size to and from the mobile stations (MS) and SMS applications. The provision of the SMS makes use of a SMS Center, which acts as a store and forward centre for short messages in the GSM/GPRS/3G network. Short messaging service (SMS) message handling can be divided into two parts:
.
message handling in the network message handling in the SMS Center.
The technical realisation of the point-to-point SMS is defined in 3GPP specification TS 23.040. The following sections present an overview of SMS message handling.
2.1
Message handling in the network

The following figure shows an example of short message routing in the GSM network. Practically the message handling is the same in all types of networks (GSM, GPRS and 3G), so only the example with GSM network is presented here.
DN03305622 Issue 5-0 en
9 (89)
Message Handling
MS a
Air
BSC
ack sr ack
dr
HLR MSC/VLR SMS Center
MS b
dr ack dr
sr
ack dr sr sr
IWMSC GMSC
ack
BTS BSS
short message dr delivery report sr status report ack acknowledgement
dr sr
NSS
BSS - base station subsystem NSS - network subsystem BTS - base station BSC - base station controller
Figure 1.
Example of MO-MT short message routing in a GSM network
The following list describes the short message routing in the GSM network in chronological order: 1. 2. Short messages (SMs) from MSs are routed through the base station subsystem (BSS) to the mobile switching center (MSC). The MSC communicates with the home location register (HLR) and visitor location register (VLR) to receive authentication, routing and other relevant information for SMS. The MSC routes the SM to the SMS Center via interworking MSC (IWMSC), which is physically located either in the MSC or the SMS Center depending on whether the link between the SMS Center and the MSC is implemented with MAP/SS7, MAP/HSL, MAP/SIGTRAN or SMRSE/TCP. (In this example, SMRSE/TCP is used.) When the SM has reached the SMS Center, the SMS Center informs the MS about this by sending it a positive acknowledgement. If an error occurs when submitting the SM to the SMS Center, the MS will receive a negative acknowledgement. The SMS Center also adds the date and time in the service centre time stamp (SCTS) to the SM
3.
4.
10 (89)
DN03305622 Issue 5-0 en
when it receives it. The information is in the form of year, month, day, hours, minutes and seconds and time zone. The time is the local SMS Center time, while the time zone is an offset to Greenwich Mean Time (GMT). 5. The SMS Center further tries to deliver the SM to its destination address. If the SM is destined to an MS, the gateway MSC (GMSC) receives the SM from the SMS Center and requests routing information from the HLR. Once the location information for the destination MS is obtained from the HLR, the GMSC is able to deliver the SM to the visited MSC (VMSC) of the recipient MS. If the delivery fails, the SMS Center tries to resend the SM according to a predefined schedule until the SM's validity period is reached. If the delivery fails because of a temporary error, and the MS becomes reachable again within the validity period time, the network sends an Alert SC notification to the SMS Center to inform that the MS is again able to receive SMs. After a delivery attempt of the SM to its destination, the GSM network always returns a delivery report to the SMS Center informing the SMS Center that the delivery either succeeded or failed. The positive delivery report comes from the MS, and usually the negative delivery reports (also known as a failure reports) are from a network element, but can also be from the MS (for example, memory full). If the originator of the SM has requested a delivery confirmation, the SMS Center will send a status report, which informs whether the delivery of the SM was successfully completed or if it failed, to the originator.
6.
7.
2.2
Message handling in the SMS Center

The main SMS Center subsystems involved in message handling are the following (see also the figure):
DN03305622 Issue 5-0 en
11 (89)
Message Handling
Mobile subscribers
SMS Center database
External application SMs, reports Telecom interface ASE SMs, reports External application External application
Kernel
Figure 2.
Message handling sybsystems in the SMS Center
Telecom interface The telecom interface subsystem receives short messages (SM) and delivery reports from mobile subscribers through the GSM/ GPRS/3G network and forwards them to the kernel subsystem for further processing. The telecom interface subsystem also receives SMs, acknowledgements and status reports from the kernel and forwards them to mobile subscribers through the GSM/GPRS/3G network.
Kernel The kernel subsystem performs most of the basic processing tasks for the SMs, delivery reports and status reports, and sends and receives them to and from the telecom interface and ASE subsystems. The kernel uses the SMS Center database for storing SMs and status reports. The kernel can also use the services of other SMS Center subsystems (so called kernel plug-ins) for the message processing, such as, subscriber user groups (SUG), delivery attributes (DA), lawful trace and archiving (LAWTR), online closed user group (OCUG), regional barring (REBA), in advance credit check interface (IACC), content-based filtering (CBF), message collecting interface (MCI) and fast-forward (FF).
ASE
12 (89)
DN03305622 Issue 5-0 en
Application server (ASE) subsystem is responsible for providing connectivity to the SMS Center for external applications using CIMD2 protocol. The application server (ASE) subsystem receives SMs from any originating application and forwards them to the kernel subsystem for further processing. The ASE also receives SMs and delivery reports from the kernel and forwards them to external applications.
DN03305622 Issue 5-0 en
13 (89)
Message Handling
14 (89)
DN03305622 Issue 5-0 en
Message flow scenarios

The SMS Center handles messages for the following kinds of traffic:
.
mobile-originated (MO) mobile-terminated (MT) application-originated (AO) application-terminated (AT). relayed traffic
In a typical scenario, the short message (SM) is sent from one mobile subscriber to another (MO-MT). The SMS Center also handles SMs that are received from mobile subscribers and destined to external applications (MO-AT), and SMs received from external applications and destined to mobile subscribers (AO-MT). Also, the SMS relaying feature of the SMS Center enables SM routing to a back-end SMSC, for example, in case the first delivery attempt (FDA) does not succeed. Then, instead of storing the SMs to the database, they are forwarded to a backend SMSC to be delivered later. For more information on SMS relaying, see SMS Relaying Guide (PDF).
3.1
Mobile-originated - mobile-terminated SMs

For an MO-MT SM, the following figure provides an illustration of a basic scenario. The SMS Center sends and receives messages through the telecom interface.
DN03305622 Issue 5-0 en
15 (89)
Message Handling
SMS Center database
1 MS a 3 6 Telecom interface 4b MS b 5 Kernel ASE 2 4a
Figure 3.
MO-MT
The scenario has the following stages: 1. 2. The sender (MS a) sends an SM to another mobile station (MS b), and the network routes the SM to the SMS Center. The kernel stores the SM in the database, or if the fast-forward MT (FF-MT) feature is activated, and the message fulfils the FF-MT criteria, the message is not stored to DB but only to the memory. The kernel sends an acknowledgement to the sender (MS a) through the telecom interface, indicating that the SM has been accepted for delivery. a. If the message is not FF-MT type, the kernel fetches the message from the DB. b. The kernel sends the SM to the recipient (MS b) through the telecom interface.
3.
4.
.
5. 6.
The recipient (MS b) sends an acknowledgement to the SMS Center, indicating that the SM has been delivered. If the sender (MS a) requested status report (SR) the kernel sends an SR to the sender through the telecom interface, indicating that the delivery was successful.
16 (89)
DN03305622 Issue 5-0 en
3.2
Mobile-originated - application-terminated SMs

When processing MO-AT messages, the SMS Center receives the SM from a mobile station through the telecom interface and routes it to an external application through the ASE. The following figure describes a basic scenario where the mobile subscriber sends an SM that is destined to an external application rather than to another mobile station.
SMS Center database
1 3 MS a 6 Telecom interface Kernel 2 4a 4b 5 ASE External application
Figure 4.
MO-AT
1. 2.
The sender (MS a) sends an SM to an application, and the network routes the SM to the SMS Center. The kernel stores the SM in the database, or if the fast-forward AT (FF-AT) feature is activated, and the message fulfils the FF-AT criteria, the message is not stored to DB but only to the memory. The kernel sends an acknowledgement to the sender (MS a) through the telecom interface, indicating that the SM has been accepted for delivery. a. If the message is not FF-AT type, the kernel fetches the message from the DB. b. The kernel sends the SM to the ASE which sends it to the application
3.
4.
.
DN03305622 Issue 5-0 en
17 (89)
Message Handling
5. 6.
The ASE sends an acknowledgement to the kernel, indicating that the SM has been delivered to the application. If the sender (MS a) requested status report (SR) the kernel sends an SR to the sender through the telecom interface, indicating that the delivery was successful.
3.3
Application-originated - mobile-terminated SMs

When processing AO-MT messages, the SMS Center receives the SM from an application and send it to mobile station through the telecom interface. The following figure describes a basic scenario where an application sends an SM that is destined to a mobile station.
SMS Center database
4b 5 MS Telecom interface
4a
1 3 External application
Kernel
6 ASE
Figure 5.
AO-MT
1. 2.
The application sends an SM to the SMS Center, through ASE to kernel. The kernel stores the SM in the database, or if the fast-forward MT (FF-MT) feature is activated, and the message fulfils the FF-MT criteria, the message is not stored to DB but only to the memory. The kernel sends an acknowledgement to the application through the ASE, indicating that the SM has been accepted for delivery.
3.
18 (89)
DN03305622 Issue 5-0 en
4.
.
a. If the message is not FF-MT type, the kernel fetches the message from the DB. b. The kernel sends the SM to the recipient (MS) through the telecom interface.
5. 6.
The recipient (MS) sends an acknowledgement to the SMS Center, indicating that the SM has been delivered. If the sender application requested status report (SR) the kernel sends an SR to the application through the ASE, indicating that the delivery was successful.
DN03305622 Issue 5-0 en
19 (89)
Message Handling
20 (89)
DN03305622 Issue 5-0 en
Message processing
Message processing
In the following figures, the message handling inside the SMS Center is divided into five parts:
.
mobile-originated (MO) messages application-originated (AO) messages common for all (MO-MT, MO-AT and AO-MT) messages mobile-terminated (MT) messages application-terminated (AT) messages.
DN03305622 Issue 5-0 en
21 (89)
Message Handling
MO-message MO SMs Telecom interface checkings Terminating SMS gateway Common for MO/AO-MT/AT SMs Message validation MSC direct SM delivery Virtual SMS Center Resolving destination
submit phase
AO-message AO SMs CIMD2 application capacity control PSW routing
Number conversion and barring

MNP based barring Anonymous short message Commands in the message Commands for external applications
CIMD2 application overload control (part 1) Subscriber user groups Delivery attributes Message redirection SCTS, PMD, ICA, LIC Lawful trace and archiving
continues...
22 (89)
DN03305622 Issue 5-0 en
Message processing
Figure 6.
MO-MT/AT or AO-MT message handling (part 1)
Online closed user group Regional barring In advance credit check interface
submit phase
Content-based filtering Message collecting interface Fast-forward MT/AT Database
Scheduling message delivery

delivery phase
MT SMs Barring based on destination IMSI MT routing MT overload control Suffix stripping
AT SMs
CIMD2 application overload control (part 2)
MT-message
AT-message
Figure 7.
MO-MT/AT or AO-MT message handling (part 2)
In the sections below, the different phases of the message handling of each part is described.
DN03305622 Issue 5-0 en
23 (89)
Message Handling
4.1
Mobile-originated (MO) message handling

Mobile-originated (MO) short messages are sent from a mobile station to the SMS Center. They can be sent further from the SMS Center to an application or back to another mobile station through the GSM/GPRS/3G network. When an MO short message is submitted to the SMS Center, it first checks if it is capable of handling the short message. The check includes short message validity, congestion, storage capacity, and so on. If one of these checks fails, the SMS Center sends back a negative acknowledgement to the network to be passed to the originating mobile station. If no problems are found, a positive acknowledgement is returned to mark a successful submission. After analysing, storing the short message to the database and number conversion, the SMS Center sends the short message to the destination mobile station and gets a delivery report back from the destination mobile station. The following sections describe the message processing phases only for MO messages.
4.1.1
Telecom interface checkings

MAP routing The MAP routing feature (licence-controlled application software) provides the means to route MO short messages to the correct SMS Centers when for example certain applications are located on certain SMS Center(s) or when using multiple SMS Centers to reduce the load. The incoming MO short messages are routed to the correct SMS Center(s) according to the PID and the destination address information carried in the short message. In the following figure, an example of MAP routing is given.
24 (89)
DN03305622 Issue 5-0 en
Message processing
Application SMSC 2 Application SMSC 1
MO-MT SMSC 1
MO-MT SMSC 2
MO-MT SMSC 3
3 5
2 4
SS7 1 6
Figure 8.
Example of MAP routing
In the example the mobile station wants to use information located in the application server. The following operations take place: 1. The mobile station sends a short message requesting an application-specific service. The service center (SC) number is the number used for MO-MT traffic, that is, all the SMS Centers have the same MSISDN. The MAP interface notices that the short message is destined to an application and re-routes it to the correct SMS Center. The SMS Center with the application receives the MO request and sends an acknowledgement to the re-routing MAP interface. The MAP interface forwards the MO acknowledgement to the mobile station.
2. 3. 4.
DN03305622 Issue 5-0 en
25 (89)
Message Handling
5. 6.
The SMS Center sends the response to the mobile station short message. The mobile station acknowledges the response to the SMS Center that sent the response.
The SMS Center address displayed by the phone for an MT short message is always the SMS Center address of the sending SMS Center, even if the MO short message has been re-routed.
Note
Note that if MAP routing is activated, the second SMS Center does not get the original VMSC/SGSN address anymore, as the first SMS Center address replaces the VMSC/SGSN address. Features relying on the correct VMSC will thus not work for the re-routed traffic. This includes for example regional barring (REBA) feature.
Note
MAP routing is not needed for routing messages to CIMD2 applications within networked SMS Center.
Note
When using SMRSE link, the same functionality is available with the MSC feature 619.
MAP overload control If the internal interface between the MAP interface and the SMS Center kernel is congested, the MO short messages and alert SC notifications are negatively acknowledged to the network. The total number of concurrent incoming dialogues can be also restricted by the configuration parameter MAX_MO_SMS_COUNT of the MAP interface.
26 (89)
DN03305622 Issue 5-0 en
Message processing
One service center address solution The MAP/SS7, MAP/SIGTRAN and MAP/HSL interfaces support optimised SS7 network configuration where all mobile users can have the same SMS Center address setting in the phone. MO short messages from different MSCs can be routed to different SMS Centers. For example, with four hosts configuration the four SMS Center hosts are physically connected to two gateway or transit MSCs. All other MSCs are routing the MO short messages to one of these SMS Center nodes through gateway or transit MSCs. MSC MO limit for SMRSE/TCP In the SMS Center link configuration, it is possible to set a MO limit for the links. The defined MO limit is sent to the interworking MSC (IWMSC) in the bind request to limit the maximum number of short messages to be submitted to the SMS Center through the link. For instructions, see Configuring links dedicated only for MO or MT traffic in Administration Guide (PDF).
4.1.2
Terminating SMS gateway

With the terminating SMS gateway (TSG) feature (licence-controlled application software), it is possible to configure the SMS Center to receive short messages (SMs) from other operator's network to be delivered to the applications residing in operator's own network. When the TSG feature is used, the SMS Center emulates GSM network towards foreign (other operator's) SMSCs to receive short messages and to forward them to SMS Center applications (applications in operator's own network). TSG functionality comprises two functional components in SMS Center telecom interface, an HLR-responder and an MT-receiver. The HLR-responder responds to incoming HLR enquiries from foreign SMSC by returning the pre-defined visited-MSC address and an IMSI value. The virtual subscribers with their respective application addresses and IMSI numbers are listed in the TSG configuration forming a minimal HLR database. The HLRresponder acknowledges all HLR update requests.
DN03305622 Issue 5-0 en
27 (89)
Message Handling
The MT-receiver converts an incoming MT-short message into an MOshort message and then forwards it to the SMS Center kernel, which should have the required application configured. The IMSI in the incoming MT-forwardSM is checked against the configured values. If a matching value in the TSG configuration is found then the SM is converted and forwarded; the MT-receiver waits for acknowledgement from the SMS Center kernel to acknowledge the received MT-short message. For more information on the TSG functionality, see Terminating SMS gateway functionality in Terminating SMS Gateway Guide (PDF).
4.1.3
Mobile number portability (MNP) based barring

The SMS Center supports three methods for mobile number portability (MNP):
.
Barring based on originator IMSI received from the interworking MSC (IWMSC). Database of exported and imported MSISDNs maintained by the operator and used by the SMS Center. Subscriber user group (SUG) and incoming capacity allocations (ICA) features, used together to handle lists of exported and imported MSISDNs for MNP.
Only one of these methods can be used, except if the virtual SMS Center (VSMSC) feature is in use; then each VSMSC profile can have its own MNP method in use. For more information on virtual SMS Center feature, see Overview of the Virtual SMS Center in Virtual SMS Center Guide (PDF). IMSI based MNP barring It possible to configure the SMS Center to receive the originator's IMSI number from the network, and configure the MNP based barring according the originator's IMSI number. Itself the barring is defined with the same syntax like in the other number conversion and barring rules files. For more information on configuring IMSI based MNP barring, see Configuring IMSI based mobile number portability in Operating Guide (PDF).
28 (89)
DN03305622 Issue 5-0 en
Message processing
MSISDN based MNP barring It is possible for the operator to maintain a list of subscribers' MSISDN numbers that are exported or imported. The messages originating from MSISDN numbers defined in the imported list are accepted, and the messages originating from MSISDN numbers in the exported list are rejected. For more information on configuring MSISDN based MNP barring, see Configuring MSISDN based mobile number portability in Operating Guide (PDF). SUG and ICA used for MNP The licence-controlled features, subscriber user group (SUG) and incoming capacity allocations (ICA), can together be used to handle lists of exported and imported MSISDN for MNP. Using these features, users to be barred are left in the default ICA group, which is configured a maximum submit rate of zero, hence all traffic is barred. Other ICA groups can be used for the MSISDNS which are accepted, possibly setting different limits for different groups of subscribers. For more information on the SUG and ICA, see Subscriber user groups overview in Subscriber User Groups Guide (PDF). Processing of MO message from the MNP point of view When the processing of a MO short message starts, its barring state is unknown. The SMS Center conceptually defines the state of a short message regarding the originator using the steps described below. Once the state is known (other than unknown), the rest of the steps are skipped. Note that these are the steps done just for the originator-based barring. Other barring decisions are done independently of the procedure described here. The figure below presents the MNP process. Different phases are explained in more detail under the figure.
DN03305622 Issue 5-0 en
29 (89)
Message Handling
MO-message
1. Is MNP enabled? Yes 2. Is MSISDN MNP enabled? Yes Reject Yes Accept Yes 3. Is MSISDN in exported file? No 4. Is MSISDN in imported file?
No
No
No
5. Is IMSI MNP enabled? No Reject Yes 6. Is IMSI available? Yes 7. IMSI number conversion rules used. No
Accept
Reject
8. rules_orig_int rules used
9. SUG based MNP
Accept
Reject
Figure 9.
Processing of MO message from the MNP point of view
1. 2.
If the mobile number portability is disabled, the MNP checking is skipped, and the processing continues from step 8. If the MSISDN based MNP is enabled, the processing continues in steps 3, otherwise processing continues from step 5.
30 (89)
DN03305622 Issue 5-0 en
Message processing
3.
If the MSISDN of the originator is included in the exported numbers list (that is a file created for rejected MSISDNs), the message is rejected, and negative acknowledgement is sent to the originator. If the MSISDN of the originator is included in the imported numbers list (that is a file created for accepted MSISDNs), the message is accepted, and the message continues to the next phase of the overall message handling process.
4.
Note
If the MSISDN of the originator is not found either exported or imported numbers list, the message processing continues from step 8. 5. 6. If the IMSI based MNP is enabled, the message processing continue from step 6, otherwise from step 8. If, for some reason, no IMSI was received from the network, the message is rejected, and negative acknowledgement is sent to the originator. If IMSI was received from the network, then the decision of accepting or rejecting the message is made according the rules defined in the IMSI number conversion rules file. If the state of the message is still unknown, then it is defined by the rules in the file defined by the rules_orig_int setting. If SUG based MNP is configured to be used, all traffic accepted according to the steps above will also be marked with the provisioned subscriber group information, after which the ICA feature can bar any restricted traffic.
7.
8. 9.
4.1.4
Anonymous short message

The SMS Center supports anonymous MO-MT messaging. Operators can allow their mobile subscribers to send anonymous short messages by defining the anonymity separately for each message, or certain subscribers can be defined to send all their messages as anonymous. Originator address When there is a delivery attempt of a short message, the SMS Center inspects the message's service description attribute to find out if anonymity is requested for the short message. If the short message's service description value is the same as the value defined in the SMS Center's anonymous message configuration (parameter
DN03305622 Issue 5-0 en
31 (89)
Message Handling
ANO_SERVICE_DESCRIPTION), the SMS Center replaces the originator
address by a pseudo-address pre-defined by the operator. How the original originator address and type are replaced, is defined by parameters ANO_PSEUDO_ADDRESS and ANO_PSEUDO_ADDRESS_TYPE respectively. Replace type PID Replacing of short messages that have changed originator address may result to unintended replacements in the mobile station. If two different originators send anonymous short messages to the same two destinations using the same replace type value, the later message will replace the previous one although the short messages were not originally from the same originator. It just looks like it to the mobile station, as the originator address for both short messages is the pseudo-address set by the SMS Center. To prevent this, if the PID of the short message is one of the replace type values defined in 3GPP TS 23.040, the SMS Center changes the SMSDELIVER.PID to 0. Reply path The anonymous short messages feature of the SMS Center requires special handling with the reply path. If the reply path is used, and the reply is sent to the sending SMS Center, it at least recognises that the destination address is its anonymous pseudoaddress and can for example bar the short message. On the other hand, turning the reply path off may save the SMS Center from replies that cannot be handled. The value of the reply path that the destination sees can be controlled by parameter ANO_REPLY_PATH_SETTING in the xsblibmx.cf file. If the SMS Center feature Reply Path Suppression is active for MO short messages, it overrides parameter ANO_REPLY_PATH_SETTING. For more information on configuring anonymous short messages, see Configuring anonymous short messaging in Operating Guide (PDF).
4.1.5
Commands in the message

The SMS Center support the 'commands in the beginning of user data' feature. A mobile user types in a command to the beginning of the short message text to request that the SMS Center performs some specific actions on a short message that the same mobile users has sent earlier.
32 (89)
DN03305622 Issue 5-0 en
Message processing
The following operations can be performed with the commands:

.
deferred delivery With the deferred delivery function the originator of the message can request that the first delivery attempt for the message will be at some time in the future. For example, if the originator types:
*p 2H30M#Thank you
the SMS Center will perform the first delivery attempt 2 hours 30 minutes after the submit time.
.
status report request With the status report request, the originator of the message can request the status or delivery report for the message he or she is currently sending. For example, if the originator types:
*notification#I will be there at 3 pm.
the SMS Center will deliver a status report to the originator after the message as been sent to the destination.
.
keyword based routing With the keyword based routing, mobile users can define certain protocol identifiers (PIDs) to direct the short messages to certain addresses. The PIDs are defined in the 3GPP TS 23.040. For example, if the originator types:
*FAX#I got the meeting minutes, thank you!
the SMS Center will deliver the message to a fax machine at the destination address.
.
anonymous short message In an anonymous short message, the originating address (MSISDN) is hidden from the recipient of the message. The originator address is replaced with an operator-defined string. For example, if the originator types:
-A-Guess who?
DN03305622 Issue 5-0 en
33 (89)
Message Handling
the SMS Center will deliver the message to the recipient with an operator-configured originator address. When an MO message is submitted to the SMS Center, the commands in the message text are executed after the message has passed the basic syntax checks and the originator and destination are validated. The messages have to be 7-bit coded messages. The command(s) must be in the beginning of the user data (in the SMS-SUBMIT TP-UD field). If the text between the command's begin and end markers does not map to any command, it is treated as a normal text. This implies that the text is not stripped from the user data and the SMS-SUBMIT TP-UD field is not scanned for more commands. For more information on configuring the commands in the beginning of user data, see Configuring commands in the beginning of user data in Operating Guide (PDF).
4.2
Application-originated (AO) message handling

External applications submit short messages to the SMS Center kernel via the application server (ASE). The SMS Center then delivers the short message to the destination mobile station via the GSM/GPRS/3G network. After delivering the short message to the mobile station, the SMS Center can, depending on the application type and the possible status report request, send a status report to the application stating whether the delivery was successful or not. External applications connect to the SMS Center kernel using the CIMD2 protocol. There are three different ASE application types:
.
Send-only A send-only application can only send short messages. If it wants to know the status of a previously submitted short message, it must query for it from the SMS Center.
Querying A querying application can both send and receive short messages, but it has to query for the status and incoming short messages addressed to it.
Receiving
34 (89)
DN03305622 Issue 5-0 en
Message processing
A receiving application can both send and receive short messages. Status reports and incoming short messages are delivered to it automatically. The following sections describe the message processing phases only for AO messages.
4.2.1
CIMD2 application capacity control

By using the CIMD2 application capacity control (CACC) feature, the operator can configure maximum submit rates for groups of ASEsubscribers, or per individual ASE-subscriber account. In addition, the operator can redistribute the message submitting capacity between groups of applications so that busy applications can have temporarily more capacity. The applications are arranged into groups and the submit capacity definitions are allocated to the groups. The number of groups is in principle unlimited as well as is the number of applications in one group. Applications which are not explicitly defined to a group will be implicitly added to the default group, which has its own settings. The capacity allocation to a group is done by defining the allowed number of submits per second. The redistribution of any unused capacity is done by distributing the unused submit capacity of the previous second proportionally according to the configured maximum extra capacity per group. It is possible to apply changes to the CACC setup on-the-fly. This provides the means to continue to run the SMS Center, ASE, PSW, and all CIMD2 connections without interruption when changing the settings; for example, while adding a new application or increasing the allocated capacity for a group. This can also be used to change the distribution at different times of a day, or have different limits for different days of a week. For example, different limits during the nights, or weekends. For instructions on how to configure the CACC feature, see Configuring CIMD2 Application Capacity Control (CACC) in External Applications Configuration Guide (PDF).
DN03305622 Issue 5-0 en
35 (89)
Message Handling
4.2.2
PSW routing
The packet switch (PSW, licence-controlled application software) is responsible for routing short messages to respective SMS Center kernels in networked SMS Centers. The PSW determines the route of a short message according to the protocol identifier (PID) or destination address (daddr) of the message. The PSW routes the short message according to the PID if the message has a non-zero value and is mapped in the routing table. If PID-based routing cannot be done then the routing is based on the destination address of the short message.
Host 1 KERNEL 1 KERNEL 2
Host 2
PSW
Backup PSW
APPLICATION SERVER 1
APPLICATION SERVER 2
Application 1
Application 2
Application 3
Application 4
Figure 10.
PSW and ASE in the networked SMS Center
4.2.3
Commands for external applications

The SMS Center supports some commands that can be used by applications. Each application can only use the commands to affect short messages it has sent itself. The following operations can be performed with the commands:
36 (89)
DN03305622 Issue 5-0 en
Message processing
enquiring a status report The command for a single status report request produces only the current status report from the defined short message independently of the restriction tables set for continuous status report requests.
replacing an earlier submitted message The replacing command can be used to replace an un-sent short message in the SMS Center database. The application must send the new message using the same PID type and SMS Center, and the message must be from the same originator to the same destination as the earlier message. (This command is also supported for MO short messages).
cancelling an earlier submitted message The cancelling command can be used to delete an un-sent short message from the SMS Center database.
4.3
Common message handling for all (MO-MT, MO-AT or AO-MT) messages

The following sections describe the message processing phases common to all MO-MT, MO-AT and AO-MT messages.
4.3.1
Message validation
During the message validation phase, the SMS Center does several checkings for validating the message accuracy, as well as it unpacks the message packet. The validation consists of checking (syntax, invalid characters etc.) for example the following items:
.
UDL - User Data Length DCS - Data Coding Schema UDH - User Data Header UD - User Data
In case any item fails the checking, the message is rejected and negative acknowledgement is sent to the originator.
DN03305622 Issue 5-0 en
37 (89)
Message Handling
4.3.2
MSC direct SM delivery

The SMS Center supports (if enabled) Nokia MSC feature 1633: Direct SM Delivery (implemented in Nokia MSC M12 ED2). The direct SM delivery provides a solution for direct short message (SM) delivery without the involvement of SMS Center, that is, the MSC tries to deliver the MO-MT message straight to the destination subscriber, without sending it to the SMS Center. In case this attempt to send the SM straight to the destination fails with some error, the MSC forwards the MO-SM to the SMS Center, and the SM delivery is carried out in traditional way by the SMS Center. Based on the configuration, the MSC can set the Reserved value of Transport Protocol-Message Type Indication (TP-MTI) field in the SUBMITMO-SM, which indicates to the SMS Center that the direct SM delivery failed. In case the support for MSC direct SM delivery is enabled in the SMS Center, the SMS Center handles these messages differently from other messages. This means that the SMS Center does not start to deliver these SMs immediately, which would probably lead to another delivery failure, but it performs an SM delivery delay. In this way many unsuccessful SM deliveries can be avoided, which further improves the efficiency of the usage of resources. From message handling point of view the procedure for MSC direct SM delivery support in SMS Center is as follows, when support for MSC direct SM delivery is enabled in SMS Center and direct SM delivery feature is activated in MSC.
.
Incoming message with Reserved value in TP-MTI field is converted to a normal submit message and deferred delivery time is set to the value of the parameter defined in kernel message handling configuration. If the destination of the message is mobile subscriber (MO-MT message) then . message is not delivered as fast-forward message, and . delivery attempt counter starts from 2, that is, SMS Center does not do the attempt number one for the message (its done by MSC). If the destination of the message is application (MO-AT message) then the message delivered normally.
38 (89)
DN03305622 Issue 5-0 en
Message processing
Note that, in case the support for MSC direct SM delivery is disabled in SMS Center and direct SM delivery feature is activated in MSC, the procedure is as follows.
.
Incoming message with Reserved value in TP-MTI field is rejected with system failure error cause. Alarm Invalid MTI in SMS-SUBMIT message rejected is set. No event log entry created.
For more information on how to enable the support for MSC direct SM delivery in SMS Center, see Configuring MSC direct SM delivery support in Operating Guide (PDF).
4.3.3
Virtual SMS Center

The virtual SMS Center (VSMSC) feature, allows to set up different configuration profiles associated with a particular SC-ADDRESS parameter for the SMS Center. This feature affects mainly the submitting of short messages. This means that when the SMS Center receives a short message, it checks the SC-ADDRESS, and if a corresponding VSMSC profile is found, the checkings related to the mobile number portability (MNP), anonymous messaging, and number conversion and barring will be made according to the found profile. If no VSMSC profile is found, the default VSMSC profile is used. If the default VSMSC profile is not set, the short message is barred and the 'Virtual SMSC is not found xxxx' alarm is set. For more information on virtual SMS Center feature, see Overview of the Virtual SMS Center in Virtual SMS Center Guide (PDF).
4.3.4
Resolving destination
The SMS Center routing determines the correct destination for SMs. The SMS Center determines the destination of a SM according to the PID (TPPID) or the destination address (TP-DA) included in the SMS-SUBMIT. The destination address is treated as an international number in case typeof-number (TON) is international number and number-plan-indication is ISDN/telephone numbering plan. Decimal value of this combination is 145. For example, typically destination address gets international number value in the mobile station when SM is sent from the mobile station in such way
DN03305622 Issue 5-0 en
39 (89)
Message Handling
that the '+' -sign is inserted to the front of the destination number. In case the '+' -sign is not given in the front of the number, the mobile station creates the SMS-SUBMIT where type-of-number and number-planindication value results to value different from 145. Note that alphanumeric addresses are not supported for MO traffic. The figure below presents the process how the SMS Center analyses the PID and/or the destination addresses. Different phases are explained in more detail under the figure.
40 (89)
DN03305622 Issue 5-0 en
Message processing
AO-message
MO-message
1. PID re-route table checking. Yes
2. Is PID zero? No No 3. Is PID supported? Yes Yes 4. Is there application with the PID? No Other 5. Is destination address in Int. or Other? Int 6. Is shortcut MT routing active? No 7. rules_dest_app_int conversion
Reject
Application
Yes
8. rules_dest_app conversion Application Yes 9. Is there application with the address? No 10. rules_dest_nat or rules_dest_int
MT
Figure 11.
Resolving the destination
Description of the phases:
DN03305622 Issue 5-0 en
41 (89)
Message Handling
1.
If the PID re-routing feature is configured (that is, the PID re-route table is defined), the SMS Center replaces the PID of the message according to the PID re-routing rules. See also PID re-routing in Message Handling (PDF). Note that the AO-messages do not go through this phase.
2.
The SMS Center checks if the PID of the message is set to zero. If it is set to zero, the message handling continues from step 5. Otherwise, the message handling continues from step 3. The SMS Center checks if the PID is supported. If the PID is not supported, the SMS Center rejects the message and sends a negative acknowledge to the mobile station. See also PID routing and Failure error codes in Message Handling (PDF).
3.
4.
The SMS Center checks if any application contains the same PID as the message. If there is an application with the same PID the message is routed to that application, except if the message is AO type then the message is rejected (that is, AO-AT case). If the message does not contain a PID, or the PID of the message is supported but no application containing the same PID exists, the destination address is analysed whether it is in international or some other format. If the destination address is in international format, the message handling continues from step 6. The SMS Center checks whether the shortcut MT routing feature is activated. If it is activated, the message is considered as an MT message and the message handling continues from step 10. If the shortcut MT routing feature is not activated, the message handling continues from step 7. See also Shortcut MT routing in Message Handling (PDF).
5.
6.
7.
If the destination address is in international format, it goes through the rules_dest_app_int conversion. After this, the message handling continues from step 9. See also Number conversion and barring in Message Handling (PDF).
8.
If the destination address is in some other than international format, it goes through the rules_dest_app conversion.
42 (89)
DN03305622 Issue 5-0 en
Message processing
9.
The SMS Center checks if there is an application with the destination address. If there is an application with the address, the message is routed to that application, except if the message is AO type then the message is rejected (that is, AO-AT case). If there was no application with the address, the message is considered as an MT message and the message handling continues from step 10.
10.
If the original destination address is in some other than international format, it goes through the rules_dest_nat conversion, starting with the original address (before rules_dest_app or rules_dest_app_int conversion). If the original destination address is in international format, it goes through the rules_dest_int conversion, starting with the original address (before rules_dest_app or rules_dest_app_int conversion). See also Number conversion and barring in Message Handling (PDF).
Note
The application profile is important for the routing because it is the primary routing information. You can modify it through the SMS Center GUI in the Application data view (under the ASE Subscribers button). For more information, see External Application Configuration Guide (PDF).
In case Virtual SMS Center (VSMSC) feature is used, and a private ASE application for VSMSC profile is assosiated, the message handling is slightly different than presented in above. For more information on VSMSC, see Overview of the Virtual SMS Center in Virtual SMS Center Guide (PDF). 4.3.4.1 PID routing An application-terminated (AT) short message, that is routed by the protocol identifier (PID), can have secondary information passed as a destination address and thus the destination address is not used if the PID is set. The 3GPP TS 23.040 defines the PID list. Using PID values requires that the mobile station supports changing of the PID and that there is a suitable PID standardised for the application. All MO messages with PIDs that are not defined in the 3GPP TS 23.040, (that is, the reserved PIDs) are rejected.
DN03305622 Issue 5-0 en
43 (89)
Message Handling
Besides the PID, Nokia SMS Center also supports an application prefix mechanism. This means that there is a unique prefix defined for every application (for example CIMD2, e-mail) known by the SMS Center kernel. When a subscriber sends an MO short message, he/she gives a destination address that begins with the application prefix. From the prefix the SMS Center kernel knows that this short message must be routed to an application. The advantages of the application prefix mechanism are that all mobile stations support it (if they support MO short messages in the first place) and that there is no need for changing the PID values. In addition, it is possible to configure a fixed address for each ASE application. In this case, no prefix is used, and only exact matches are routed to the application. It is possible to have overlapping application addresses if the shortest one is of fixed length. It is also possible to have overlapping fixed addresses. Both the PID and the application prefix are defined for the application in the application database of the SMS Center. The SMS Center first checks the PID of the incoming short message. The 3GPP TS 23.040 defines two kinds of PIDs, routing PIDs and PIDs for other purposes, for example, replace message type. For list of PIDs, see List of PIDs in Message Handling (PDF). If it is a routing PID other than zero, the SMS Center checks if there is an application for that PID. If there is such an application, the message will be routed to it. Otherwise, the SMS Center will route this message according to its destination address. If it is not a routing PID, the SMS Center checks if there is an application prefix in the beginning of the destination address. If the short message does not contain either a PID or an application prefix, that is, the short message is not destined to application, the system assumes that the short message is destined to a mobile station, and delivers it to the network. 4.3.4.2 PID re-routing With the PID re-routing feature, it is possible to re-route MO messages to go to different PID applications or directions than defined by the original PID. The following figure presents an example of the message flow when the PID re-routing feature is used.
44 (89)
DN03305622 Issue 5-0 en
Message processing
PID re-route table mobile station

PID = 66 PID = 67 ... 65 > 64 66 > 64 67 > 64 ... PID = 64
PID table
... 64 - SM Type 0 65 - Replace SM Type 1 66 - Replace SM Type 2 67 - Replace SM Type 3 ... to MS
PID = 64
Figure 12.
Example of PID re-route table
The PID re-route table is configurable and the PID table is based on the 3GPP TS 23.040. If the PID coming from a mobile station is not found in the PID re-route table, the original PID is checked normally from the PID table. For list of PIDs, see List of PIDs in Message Handling (PDF). 4.3.4.3 Shortcut MT routing If an application on the SMS Center has an application prefix which matches a country code, all messages cannot be sent to the MS in that country even if the destination address is given in international format. The messages are routed to the application instead. This is due to the routing mechanism of the SMS Center as explained in earlier sections. For example, if an application with application prefix 358 (country code of Finland) is defined on the SMS Center, all messages sent to the destination address 358xxxxxxxxxx or +358xxxxxxxxxx are always routed to the application. In this case, it is practically impossible to send messages to the mobile subscribers in Finland through this SMS Center. In this kind of situation, the shortcut MT routing feature provides a possibility to send messages to the mobile subscribers. With shortcut MT routing feature enabled, the SMS Center will always resolve the destination of the MO messages to be MS if the destination address is given in international format. For example, an application with an application prefix 358, is defined in the SMS Center. Sending messages to destination address 358xxxxxxxxx in national and international format gives the following results, see the table below.
DN03305622 Issue 5-0 en
45 (89)
Message Handling
Table 1.
Example of resolving the destination with the shortcut MT Routing feature Destination
Application-terminated (AT) Mobile-terminated (MT)
Destination address
358xxxxxxxxx +358xxxxxxxxx
As a PID has priority in routing over the destination address, the PID of the message is checked before the shortcut MT routing decision is made. If the PID of the message matches the PID of a receiving application, the message is routed to the application, regardless of the destination address and the destination address type. For more information on configuring the shortcut MT routing, see Configuring shortcut MT routing in Operating Guide (PDF).
4.3.5
Number conversion and barring

The main purpose of the SMS Center number conversion facility is to convert the destination addresses of incoming short messages to the international address format or to the national format, depending on whether the message is destined to a mobile station or an application. With barring, it is possible to restrict certain subscribers from sending or receiving short messages. This can be carried out through the conversion rules that are defined in the number conversion and barring rules files. For mobile-terminated messages, the type of the destination address must be international. In addition, in some cases there is a need to define rules for how addresses are converted to some other format. The following tables present the number conversion and barring functions in chronological order in case of MO, AO and MT messages, for both originator and destination addresses, in each case. The MO and AO phases are done in the submit phase, and the MT barring in the delivery phase. In the tables, each conversion is named according to the setting, where the used rule file is defined (in $SC_CONFPATH/xsblibmx.cf configuration file).
46 (89)
DN03305622 Issue 5-0 en
Message processing
If the virtual SMS Center feature is in use, all number conversion and barring rules files can be separately defined for each virtual SMS Center profile. For more information on virtual SMS Center feature, see Overview of the Virtual SMS Center in Virtual SMS Center Guide (PDF).
Table 2. Orde r Conversion
MO message number conversion and barring (in submit phase)
Description
MO message, originator address 1 rules_orig_int or rules_orig_nat 2 MNP_IMSI_CONVE RSION_FILE If the originator address is in international format, the number conversion and barring rules file used is set in rules_orig_int. If the originator address is in some other than international format, the number conversion and barring rules file used is set in rules_orig_nat. If originator IMSI based barring for MNP is enabled, the barring rules file used is defined in the MNP_IMSI_CONVERSION_FILE.
MO message, destination address 1 rules_dest_app_int or rules_dest_app In case of AT message: If the destination address is in international format, the number conversion and barring rules file is set in rules_dest_app_int. If the destination address is in some other than international format, the number conversion and barring rules file is set in rules_dest_app. The result address is checked and if an application with the address is found, the message is sent to that application. If there is no application with the address, the next conversion and barring phase starts with the original address (that is, the address before the rules_dest_app_int or rules_dest_app conversion). 2 rules_dest_int or rules_dest_nat In case of MT message: If the destination address is in international format, the number conversion and barring rules file used is set in rules_dest_int. If the destination address is in some other than international format, the number conversion and barring rules file used is set in rules_dest_nat.
AO message number conversion and barring (in submit phase)
Description
AO message, originator address 1 rules_orig_app The originator address number conversion and barring rules file is set in rules_orig_app.
DN03305622 Issue 5-0 en
47 (89)
Message Handling
Table 3.
AO message number conversion and barring (in submit phase) (cont.)
Orde r
Conversion
Description
AO message, destination address 1 rules_dest_int or rules_dest_nat In case of MT message: If the destination address is in international format, the number conversion and barring rules file used is set in rules_dest_int. If the destination address is in some other than international format, the number conversion and barring rules file used is set in rules_dest_nat. 2 rules_dest_app In case of AT message: If the destination address is in international format, the number conversion and barring rules file is set in rules_dest_app_int. If the destination address is in some other than international format, the number conversion and barring rules file is set in rules_dest_app. The result address is checked and if an application with the address is found, the message is sent to that application. If there is no application with the address, the next conversion and barring phase starts with the original address (that is, the address before the rules_dest_app_int or rules_dest_app conversion).
MT message number barring (in delivery phase)
Description
MT message 1 rules_dest_imsi If destination IMSI based barring is enabled, the barring rules file used is defined in rules_dest_imsi.
For instructions on how to configure the number conversion and barring rules, see Number conversion and barring overview in Operating Guide (PDF).
4.3.6

CIMD2 application terminated overload control (CATOC) is a dynamic control which automatically rejects and accepts messages per application. The CATOC message handling can be divided into two parts.
48 (89)
DN03305622 Issue 5-0 en
Message processing
In part 1, the SMS Center checks whether the CATOC feature is enabled for the destination application and whether it is currently in barring state, and accepts or rejects the message. For full description of the CATOC feature, see CIMD2 application overload control (part 2) in Message Handling (PDF).
4.3.7
Subscriber user groups

The subscriber user groups (SUG, licence-controlled application software) feature is for handling number of configurable attributes and rules that the SMS Center takes into account when handling messages to/from subscribers or applications. From a message handling point of view, the SUG kernel plug-in process (XUG) is the first plug-in in the kernel core, thus handles the messages first, that is, resolves the destination and originator groups of an incoming message. After this, the SMS Center uses the SUG data when further processing the message. With SUG, it is possible to define which rules are applied to the message (according to the originator and destination address) with the delivery attributes (DA), message redirection (MRD), lawful trace and archiving (LAWTR), incoming capacity allocation (ICA), regional barring (REBA) and content based filtering (CBF) features. The SUG uses the operatorprovisioned SUG data to attach the SUG group ID to the message, and then the above mentioned features uses the group ID to handle the messages accordingly. The figure below presents the process how the SMS Center does the SUG message handling.
DN03305622 Issue 5-0 en
49 (89)
Message Handling
MO/AO -message No
1. Is SUG enabled? Yes 2. Finding orig./dest. addr. from SUG data.
3. Messages SUG group ID is set.
4. Message continues in message flow.
Figure 13.
SUG message handling
Description of the SUG message handling: 1. After MO/AO message is received, the SMS Center checks if the SUG feature is enabled. If the SUG is not enabled, the message handling continues without SUG functionality, that is, the message continues in the message flow. 2. 3. The SMS Center checks if the originating and/or destination address matches any of the configured SUG data. The SMS Center attaches found SUG group ID to the message. If the originating and/or destination address was not found from the SUG data, the SMS Center sets the SUG group ID to default value 0. The message continues in the message flow. After this, if the SUG is enabled, when the message reaches any of the activated SUG related features (DA/MRD, LAWTR, ICA, REBA or CBF), the SMS Center uses the SUG data accordingly in those phases. For more information on the SUG functionality, see Subscriber user groups functionality in Subscriber User Groups Guide (PDF).
4.
50 (89)
DN03305622 Issue 5-0 en
Message processing
4.3.8
Delivery attributes
The delivery attributes (DA, licence-controlled application software) feature can be used to determine how short messages to or from the subscribers are handled in the delivery phase. The SMS Center uses the group-specific delivery attributes in combination with subscriber-defined message attributes, system default attributes and some hard coded delivery attribute values to set the final delivery attributes of the message. The operator can define different delivery attributes for each subscriber user group. For messages to or from subscribers that do not belong to any of the groups, the SMS Center applies the system defaults if they are defined, otherwise hard coded values will be used. The delivery attributes are set in the mgratrmx process, but they are applied by all subsequent message handling processes in the SMS Center.
Note
The mgratrmx process is a mandatory part of the SMS Center, because it handles the system default settings that are used also if the delivery attributes feature is not active.
The delivery attributes process sets the following data for the message, based on the originators group ID:
.
Validity period for messages, the default and the maximum values Each user group can have a different length of validity period for its short messages.
Prepaid subscriber identification based on their MSISDNs It is possible to specify prepaid status per any MSISDN. In earlier releases, certain MSISDN number ranges were reserved for prepaid subscribers, but now the prepaid information can be made per MSISDN. This supports the mobile number portability better when changing post-paid and pre-paid subscription types.
Message priority levels The operator can offer different service levels for user groups, for example 'premium service' and 'low-cost service'.
DN03305622 Issue 5-0 en
51 (89)
Message Handling
The delivery attributes process sets the following data for the message, based on the destination group ID:
.
Deferring delivery, the maximum time and whether the subscriber is allowed to request it. Service description field in charging data records. Message redirection (MRD) settings.
For more information on DA functionality, see Delivery attributes functionality in Subscriber User Groups Guide (PDF).
4.3.9
Message redirection
The message redirection (MRD, licence-controlled application software) feature can be used to redirect both MT and AT short messages in case the first destination is not reachable in a defined time- frame. The option for an alternative destination is useful for example if a recipient has two mobile terminals but only one of them is in use, or when a backup person needs to be reached. For more information on MRD functionality, see Message redirection overview in Subscriber User Groups Guide (PDF).
4.3.10
SCTS, PMD, ICA, LIC

SCTS In the time stamping phase, each message is time stamped. This means that each message gets an unique pair of service centre time stamp (SCTS) and destination address. SCTS recalculation The SMS Center has time stamp recalculation (SCTS recalculation) mechanism to handle bursts of MO short messages toward a single destination address in the same second. By default, this feature allows 5 messages per second (set in file kernel.cf with parameter MAX_SCTS_RECALCS). Traffic exceeding this limit is rejected. Note that if the SMS Center receives more than one SM to the same destination for a longer period, the SCTS recalculation feature does not help. Instead, with features prrivilege mobile destination (PMD) and destatination address suffxing (AT) features can be used to overcome this kind of situation (see the sections below).
52 (89)
DN03305622 Issue 5-0 en
Message processing
Privilege mobile destination (PMD) If the traffic amounts towards an MT destination exceed the SCTS recalculation value (previous section), the PMD (licence-controlled application software) feature starts handling the messages as PMD messages. It adds 5 digit suffixes to the destination address, so that it can handle large numbers of messages in the same second. Each privilege mobile destination, once detected, is valid for a limited period of time. The period can be configured in the SMS Center kernel configuration. For more information on the privilege mobile destination, see Privilege mobile destination functionality in Privilege Mobile Destination Guide (PDF). Destination address suffixing (AT) For popular applications, the SCTS recalculation feature alone provides too low capacity of only 1 SM/second continuously. In such cases the destination address suffixing (AT) feature can be used to improve this. Destination address suffixing is performed in order to produce a unique key to identify each short message in the database. The key for the short message consists of the destination address and service center time stamp (SCTS). The SMS Center will suffix a three-digit number to the destination address. Suffixing is activated by ticking the AutoSuffixing box in the ASE subscriber edit window. The application must be defined as type 3 (send & receive) in order to activate the suffixing.
DN03305622 Issue 5-0 en
53 (89)
Message Handling
daddr = 8888 000 daddr = 8888 001 daddr = 8888 002 daddr = 8888 003 daddr = 8888 004 daddr = 8888 005 ... 999 SMS Center
Application daddr = 8888
Figure 14.
Destination address suffixing
Incoming capacity allocation (ICA) The incoming capacity allocation (ICA, licence-controlled application software) feature is used to reserve certain submit capacity per subscriber user group. The ICA feature gives the operator a tool for controlling which messages get rejected in peak-traffic situations. The ICA consists of two modules, called ICA-A and ICA-B, which perform different functions. The operator can configure either one or both of them active. The ICA feature can be used to control the incoming message amounts in the following ways:
.
The operator can divide the licenced capacity of the SMS Center between different user groups, by defining the maximum submit allocation per subscriber user group (ICA-A). The ICA rejects messages exceeding the allowed limit. The operator can define priorities per originating subscriber group and then define a threshold per priority in the SUG capacity allocation settings (ICA-B), to control after what overall traffic rates traffic will be rejected for each group.
The key difference between ICA-A and ICA-B is that ICA-A counts traffic rates per group, while ICA-B counts all traffic together when deciding what traffic to reject.
54 (89)
DN03305622 Issue 5-0 en
Message processing
For detailed description of online ICA functionality, see Incoming capacity allocation functionality in Subscriber User Groups Guide (PDF). Licence check (LIC) The SMS Center software is protected by licence and a capacity licence key is provided to operators in order to supply the purchased capacity and features. The capacity licence key contains information on purchased capacity (messages/second), and limits of using the SMS Center when purchased capacity is exceeding. In addition, the capacity licence key controls of using licence-controlled application software, that is, the licence key contains information on purchased features, and prevents of using any unpurchased features. The capacity licence checking procedure is as follows: 1. When message arrives to kernel, the kernel checks the current situation of used capacity, that is, how many messages per second there is. If the current capacity is under the purchased capacity limit, the message is accepted. If the message exceeds the purchased capacity limit, the message is rejected and negative acknowledgement is sent to the originator.
2. 3.
Note that only valid and accepted messages are counted in to the used capacity. This means the messages that have reached to the licence checking phase, that is, have passed the message validation and the first phase of number conversion and barring. Note also that the capacity checking is the same for MO- and AO-traffic, and the capacity cannot be separately defined between these two traffic types. If needed, AO traffic limits can be configured using the CACC feature, see more in section CIMD2 application capacity control in Message Handling (PDF). If there is no valid capacity key in the SMS Center, or if the key gets corrupted, the default value takes effect. For more information on purchasing or updating capacity licence key, contact Nokia. For instructions for displaying the contents of the capacity licence key, see Viewing capacity licence key contents in Administration Guide (PDF).
DN03305622 Issue 5-0 en
55 (89)
Message Handling
4.3.11
Online closed user group

With the online closed user group (OCUG, licence-controlled application software) feature it is possible to define subscriber and application groups with privileges and restrictions (barring) in sending and receiving short messages. The privileges and restrictions are defined as rules which specify where the group members have access. There can be rules defined for both the incoming and the outgoing directions, since the rules can include both originator and destination addresses. Subscribers and applications are arranged in CUG groups according to their MSISDN, and/or IMSI numbers, and/or protocol identifiers (PIDs). Each group includes a defined set of numbers. Operator can choose which routing information (MSISDN, IMSI, PID) is used in barring or in granting access for messages. In addition, it is possible to set OCUG rules to different traffic directions; MO-MT, MO-AT and AO-MT. For more detailed description of online CUG functionality, see Online CUG overview in Online Closed User Group Guide (PDF).
Note
Note that the OCUG definitions are separate from the subscriber user group (SUG) definitions.
4.3.12
Regional barring
The regional barring (REBA, licence-controlled application software) feature is used for barring incoming short messages based on the visitedMSC or SGSN addresses. That is, with the REBA feature the operator can provide SMS services so that submits only from a specific area, served by a set of visited-MSCs/SGSNs (for example "home location"), are accepted/barred. For detailed description of online REBA functionality, see Regional barring functionality in Online Closed User Group Guide (PDF).
4.3.13
In advance credit check interface

The in advance credit check (IACC, licence-controlled application software) provides the ability to request the credit of a prepaid customer from a prepaid system before delivering a short message. It also provides support for the prepaid system to do real-time charging.
56 (89)
DN03305622 Issue 5-0 en
Message processing
The following steps describe the IACC mechanism shortly. 1. 2. 3. 4. 5. The SMS Center receives a short message. The SMS Center finds out that the subscriber is prepaid based on the MSISDN or IMSI number. The SMS Center checks for credit in the prepaid system. The prepaid system replies 'Ok' or 'NotOk' depending on whether there is credit on the sender's prepaid account or not. Depending on the result of the IACC check, the following two alternatives are possible: . a. If the account has credit, message is sent to the recipient. . b. If the account has no credit, the message is discarded.
In addittion, the IACC interface supports a two-step reserve plus commit or cancel to the prepaid system. The final outcome of the delivery selects if the reservation is committed or cancelled. For more detailed description of IACC functionality, see In advance credit check overview in In Advance Credit Check Guide (PDF).
4.3.14
Content-based filtering
With the content-based filtering (CBF, licence-controlled application software) feature it is possible to disable sending of unsuitable message contents to defined groups of people. The CBF feature can perform the following functions:
.
scanning message contents against operator-defined dictionaries blocking messages (where unsuitable contents found) from reaching their destination letting messages go through without alteration recording selected fields of the messages into files in XML format applying several rules depending on the origin, destination, protocol id or virtual SMS Center sending status reports sending notification messages if allowed to do so.
All the above mentioned functions are configurable.
DN03305622 Issue 5-0 en
57 (89)
Message Handling
For detailed description of CBF functionality, see Content-based filtering functionality in Subscriber User Groups Guide (PDF).
4.3.15
Message collecting interface

With the message collecting interface (MCI, licence-controlled application software) feature, it is possible collect or count short messages that are sent to defined destination addresses. For the MCI configuration, operator needs to define one or more addresses (destination addresses from mobile subscriber point of view) and the period of time for collecting or counting the messages. The messages sent to this/these addresses, during the defined time period, are either counted and the result is written to a file, or the messages are collected and stored to text files. After the file(s) have been written, an external collecting platform is able to fetch the file(s) via FTP for further processing. For more detailed description of MCI functionality, see Message collecting interface functionality in Message Collecting Interface Guide (PDF).
4.3.16
Fast-forward MT/AT
The fast-forward MT (FFMT) and fast-forward AT (FFAT) features allow the SMS Center to deliver mobile-terminated (MT) and application-terminated (AT) messages without storing them in the database (DB). Instead of inserting the message to the DB, the SMS Center tries to deliver the message straight to the network or to the application. The FFMT and FFAT message handling differs slightly from each other, the following sections describe both cases. Fast-forward MT The fast-forward MT feature (FFMT) allows the SMS Center to deliver mobile-terminated (MT) messages without storing them in the database (DB). Instead of inserting the message to the DB, the SMS Center tries to deliver the message straight to the network. If the fast-forward delivery fails, the message is stored to the DB and the SMS Center tries to send it according to the configured retry policy. The FFMT feature can be used for both, MO and AO messages. However, in the following cases, the message is not delivered as fast-forward message:
58 (89)
DN03305622 Issue 5-0 en
Message processing
message is a part of concatenated SM message contains deferred delivery request message contains replace PID request message contains a command (commands in the beginning of user data), except if the command is phase 1 status report request.
In the following the FFMT message handling is described in more detail.

MO/AO-message
1. Is FFMT enabled? Yes 2. Is message MT/supported FF SM? Yes 3. Message sent to network (not stored DB)
No
No
4. Is delivery successful? b) SR sent to originator.
a)
5. Message is not handled as FFMT.
Figure 15.
Fast-forward MT message handling
Description of the FFMT message handling: 1. After MO or AO message is received, the SMS Center checks if the FFMT feature is enabled. If the FFMT is not enabled, the message handling continues without FFMT functionality (step 5).
DN03305622 Issue 5-0 en
59 (89)
Message Handling
2.
The SMS Center checks if the message is mobile-terminated and if it is of supported type for FFMT. If the message is not MT type or the message is one of the following cases, the message handling continues without FFMT functionality (step 5): . message is a part of concatenated SM . message contains deferred delivery request . message contains replace PID request . message contains a command (commands in the beginning of user data), except if the command is phase 1 status report request.
3. 4.
If the message is MT type, the message is sent to the network, that is, to the recipient. After this, the SMS Center waits for the delivery report from the network. a. If the delivery fails with temporary error (negative delivery report is received), the message is inserted to the database and delivery is made according to retry policy. As an option, deferred delivery can be requested for every failed delivery of FFMT message. b. If the delivery succeeds or delivery fails with a permanent error, the event is logged and the SM is removed from the system, without ever being stored in the database. The SMS Center considers the message not a FFMT type of message.
5.
Depending on the delivery outcome, the request for status reports (SRs) from the originator, and the configuration of the SMS Center, the SMS Center creates a SR when needed. The SRs are handled like FFMT for MO-MT and MO-AT SMs, and like FFAT for AO-MT SMs. This means that also SRs can be fast-forwarded, but will also be written to the DB if they can't be delivered immediately. For more information on configuring fast-forward MT, see Configuring fastforward MT in Operating Guide (PDF). Fast-forward AT The fast-forward AT feature (FFAT) allows the SMS Center to deliver application-terminated (AT) messages without storing them into the database (DB). Instead of inserting the message to the DB, the SMS Center tries to deliver the message straight to the application. If the fastforward delivery fails, the message is stored to the DB and the SMS Center tries to send it without fast-foward functionality.
60 (89)
DN03305622 Issue 5-0 en
Message processing
The FFAT feature can be used for all AT messages. However, the following limitations are set:
.
If the destination application is not logged in, and thus is not able to receive messages immediately, messages are not handled as fastforward messages. If the parameter delivery mode is set to 1, in the destination application's user profile file the messages are not handled as fastforward messages. For more information on the parameter, see s2aupsamplemx.cf in Configuration Files (PDF).
All traffic for alias applications is routed to the parent application. If the parent application is logged out, the messages to the parent and child applications are not handled as fast-forward messages. The message contains replace PID request.
In the following the FFAT message handling is described in more detail.
DN03305622 Issue 5-0 en
61 (89)
Message Handling
MO -message
1. Is FFAT enabled? Yes 2. Is application ready to receive message? Yes 3. Message is sent to application.
No
No
4. Is delivery successful? b) SR sent to originator.
a)
5. Message is not handled as FFAT.
Figure 16.
Fast-forward AT message handling
Description of the FFAT message handling: 1. After MO message is received, the SMS Center checks if the FFAT feature is enabled. If the FFAT is not enabled, the message handling continues without FFAT functionality (step 5). 2. The SMS Center checks if the application is ready for receiving messages. If the application is not ready for FFAT message, the message handling continues without FFAT functionality (step 5). 3. The message is sent to the application.
62 (89)
DN03305622 Issue 5-0 en
Message processing
4.
After this, the SMS Center waits for the delivery report from the application. a. If the delivery fails, the message is inserted to the database and delivery is made as usual. b. If the delivery succeeds, status report (if requested) is sent to the originator. The message is not handled as fast-forward message. This means that the SMs are fetched from the DB automatically when the application logs on, or are fetched from the DB on request by the application.
5.
For more information on configuring fast-forward AT, see Configuring fastforward AT in Operating Guide (PDF).
4.3.17
Failures in submitting short messages

If an error occurs when submitting a short message to the SMS Center, the mobile station displays a text about failed short message sending. Errors can be sent from any network element. Also, an error can be sent by the mobile station, if the time limit of the mobile station's internal timer is reached. For more information on error codes, see Failure error codes in Message Handling (PDF).
4.3.18
Scheduling message delivery

Before delivering the short message (if the SM is not delivered as FFMT message, that is, the FFMT is disabled or FFMT delivery fails), the kernel first determines if there are any previously submitted short messages destined for the same mobile station waiting for delivery. If queuing messages exist, the delivery depends on the value for NEW_SM_POLICY (in kernel.cf). If no other queuing messages exist, the kernel proceeds with the delivery. The following functions affect the short message deliveries and are described in the sections below.
.
Prioritising messages Scheduled delivery Rescheduling deliveries
DN03305622 Issue 5-0 en
63 (89)
Message Handling
Deferring deliveries Delaying deliveries MMS hinting Negative validity period
For more information on configuring the message delivery scheduling Configuring basic message delivery settings in Operating Guide (PDF). 4.3.18.1 Prioritising messages You can prioritise short messages in two ways:
.
Affecting the message queue You can decide how the SMS Center handles a message queue waiting to be delivered to the same mobile station.
Affecting the priority of message type You can prioritise short messages according to their type.
Affecting the message queue You can decide how the SMS Center handles queues of short messages destined to the same mobile station by changing the value of the system parameter NEW_SM_POLICY. Note that the NEW_SM_POLICY has no effect if the destination queue is empty.
Table 5. Value
1 2
Message handling with different values of NEW_SM_POLICY
Description
The SMS Center stores the new message and delivers the first message in the queue. If the delivery succeeds, it proceeds with the next message in the queue. The SMS Center stores the new message. If the destination queue contains a previous message or messages from the same originating address as the new one, it delivers the first matching message. If no message with the same originator exists, it delivers the new message. If the delivery succeeds, it proceeds with the next message in the queue. The SMS Center stores the new message and attempts a delivery of the new message. If the delivery succeeds, it proceeds with the first message in the queue. The SMS Center stores the new message. If the destination queue contains a message or messages from the same originating address as the new one, it does not make a delivery attempt but uses the retry table instead. If no message from the same originating address exists, it delivers the new message. If the delivery succeeds, it proceeds with the next message in the queue.
3 4
64 (89)
DN03305622 Issue 5-0 en
Message processing
Table 5. Value
5
Message handling with different values of NEW_SM_POLICY (cont.)
Description
The SMS Center stores the new message. It does not deliver anything but uses the retry table instead.
Table 6. New SM policy

1,5 2,4 3
Chronological order with different values of NEW_SM_POLICY
Chronological order of the messages

Chronological order of delivery is guaranteed. Messages from the same originator are delivered in a chronological order. Chronological order of messages cannot be guaranteed.
The NEW_SM_POLICY affects the total cumulative number of delivery attempts:

.
5 causes least delivery attempts 4 causes some additional attempts 1, 2 and 3 cause most additional delivery attempts.
Affecting the priority of message type You can assign priority classes to the following short message types:
.
MO short messages Status reports (SR) Application-originated (AO) short messages (applications may choose from the allowed types)
Priority classes range from 1 to 9, and 1 is the highest. Short messages with higher priority get to be delivered before short messages with a lower priority class. The following table describes how to assign a priority class for the short messages.
DN03305622 Issue 5-0 en
65 (89)
Message Handling
Table 7. Message
MO messages Status reports AO messages
Assigning priority classes for short messages
Place where to assign the priority class

Kernel parameter PRIORITY_CLASS. Kernel parameter SR_PRIORITY_CLASS. The application's profile file. The application can decide which priority class to use.
Note
Priority class only affects one and the same destination queue. Other destination queues, that is, those of other mobile stations, are not affected. Only the operator can set the priority class for short messages, but there are no priorities between subscribers.
Note
If subscriber user group (SUG) feature is in use, the delivery attributes (DA) settings can also be used to select the priority of SMs based on the user group of the originator. In that case, the parameters in the above table are used as defaults if no group-specific values have been configured in SUG data.
RP-Priority flag RP-priority flag can be set in MT messages. Setting of this flag is configurable by attributes field of RP-errors in xdierrmx.cf configuration file and by RP_FLAG_PRIO_THRESHOLD parameter in section [DISPATCHER] section of kernel.cf configuration file. Attributes field can contain RP-PRIORITY_ALWAYS or RP_PRIORITY_RUNTIME flags. If RP-PRIORITY_ALWAYS flag is set on for an RP-error than all retries happening after this error will have RP-priority flag set on. If RPPRIORITY_RUNTIME flag is set on for an RP-error then all retries happening after this error will have RP-priority flag set on only if message priority is higher or equal to value set in RP_FLAG_PRIO_THRESHOLD parameter. Value 0 for RP_FLAG_PRIO_THRESHOLD parameter is used to disable runtime RP-Priority flag setting.
66 (89)
DN03305622 Issue 5-0 en
Message processing
4.3.18.2
Scheduled delivery Every subscriber that has short messages in a waiting state in the SMS Center, has his or her own queue of short messages in the dispatcher process's memory. However, the first short message in every queue is also arranged according to the time intervals set for delivery queues. The dispatcher process checks these queues for short messages to be delivered. On process level, the procedure is as follows: 1. 2. 3. 4. The submit chain receives the short message from the link process. The submit chain places the short message in the database and gives the key to the dispatcher process. The dispatcher process places the short message in its own queue in the memory based on the retry interval settings. The dispatcher process reads its queues and when a scheduled delivery is going to take place, it gives the key to the delivery process. The delivery process reads the short message from the database based on the key and sends the short message through the get/put process.
5.
4.3.18.3
Rescheduling deliveries Delivery rescheduling for a short message takes place in the following situations:
.
A temporary error is received from the network for a previous delivery attempt. There is congestion in MT traffic, that is, there are too many short messages currently in the network from this SMS Center. There is congestion in the incoming traffic. If the short message queue of the dispatching process has many unprocessed short messages, the handling of scheduled deliveries is paused and the deliveries being processed are rescheduled. An alert is received from a previously attempted message.
The SMS Center will retry the delivery of the short message until one of the following conditions is met:
DN03305622 Issue 5-0 en
67 (89)
Message Handling
the delivery succeeds the validity period of the short message expires the short message is cancelled, deleted or replaced.
The rescheduling of the short messages is done by defining values for system parameter RETRY_INTERVALS. The values for the RETRY_TABLE_x, where x indicates the error code (see section Failure error codes), are taken from the RETRY_INTERVAL parameter values. The error codes are mapped to the retry tables in configuration file xdierrmx.cf. A series of attempts continues till the end of the retry table. If the short message is still waiting to be delivered once the end of the table is reached, the last two intervals will be used until the validity period (VP) expires. Special retry interval index VP (string "VP") can be added to the end of RETRY_TABLE_x. If retry is done using it then the delivery attempt will happen two seconds before the short message's validity period expires. If the reason for the delivery failure changes, the following retries will be made according to the retry table defined for that specific error. The retries always start from the beginning of the table when the error changes. After an alert, the retries start from the beginning of the retry table if the delivery fails again after the alert. A new short message to a subscriber that has also some older nondelivered short messages may cause a delivery attempt. If that delivery attempt fails and the error is the same as in the previous attempt, the next attempt will be scheduled using the same value from the retry table as after the previous failure. In other words, the retry table value does not change if the attempt was made because of a new short message and if the error cause did not change.
Note
The retry policy affects always the first short message in the queue, unless it is a deferred short message. Deferred short messages are simply skipped over, the delivery is attempted at the time defined in the deferred delivery policy. Other short messages in the queue are attempted only if the delivery succeeds. The retry policy does not depend on the length of the validity period.
68 (89)
DN03305622 Issue 5-0 en
Message processing
4.3.18.4
Rescheduling HLR-based SMS forwarding deliveries The SMS Center uses a dedicated retry table for cases where mobile subscribers have forwarded their incoming messages to another subscriber's number (C-subscriber), and the C-subscriber has the mobile station turned off. When a message delivery attempt fails with a temporary error, the SMS Center notices if the message has been forwarded to a C-subscriber who is not reachable, and based on this information the SMS Center applies the dedicated retry table to deliver the message according to the settings of RETRY_TABLE_106.
4.3.18.5
Rescheduling FFMT deliveries In case the FFMT message sending fails (see more about FFMT in section Fast-forward MT/AT), in FFMT configuration, it is possible to set a special deferred delivery time for these messages (configured in $SC_CONFPATH/ kernel.cf). This means that the FFMT message, which was failed to deliver, is rescheduled to be tried to sent after this period of time. If the message sending fails again, or this option in FFMT configuration is not used, the message is sent according to the normal message sending policy.
4.3.18.6
Deferring deliveries Deferred delivery means that an application has requested a delivery time in the future. Deferred delivery is implemented for example for the voice mail application (VMA). Application-originated (AO) short messages may specify a time before which no delivery attempts are allowed. When such a short message is received, it is placed in the list of scheduled deliveries according to internal heuristics that try to minimise the cost of the scheduling operation. This is semantically true for the voice mail notifications where RN_PAUSE is nonzero. RN_PAUSE is interpreted the same way as ALERT_D_INTVL and REPORT_D_INTVL.
4.3.18.7
Delaying deliveries In some cases the short messages cannot be sent to the network immediately. Delaying is needed in the following cases:
DN03305622 Issue 5-0 en
69 (89)
Message Handling
After the short message is sent to the network, the SMS Center starts to wait for a report from the network. The SMS Center is only allowed to have one short message delivery for which a report has not been received to a specific mobile station at a given time. During the time of waiting for the report, the SMS Center kernel can make deliveries to other mobile stations. The maximum time the SMS Center will wait for a report, is controlled by system parameter WAIT_REPORT_TIME. When there are many short messages to be sent at about the same time and it takes a long time to get the reports from the network.
The SMS Center is allowed to have only a certain number of short messages for which a report has not been received. The number of short messages in the network depends both on the network to which the SMS Center is connected and on the connection. The SMS Center limits are set in configuration file $SC_CONFPATH/xsclnkmx.cf. 4.3.18.8 MMS hinting More messages to send (MMS) hinting is a method for speeding up the delivery of messages to the same destination. Normally, when the SMS Center has more than one pending message to a mobile subscriber, the SMS Center sets the MMS flag for the mobile terminated (MT) message. This will tell the network to keep the communication channel, which was opened by the first message, open also for the following messages. The MMS hinting can also be used, by using the so called conditional deferred delivery. The deferred delivery means that the sending of the message is scheduled at some configurable point of time in the future. Conditional means that the message is not deferred or deferring is stopped if any of the following is true:
.
After the message is scheduled for deferred delivery, the SMS Center receives a new message, alert, report or error. When the message is scheduled there is already one or more pending messages for that subscriber. The 'normal' deferred delivery is used. The SMS Center is restarted.
The result is that for the first message in a series of messages, the SMS Center kernel will wait for the second message to come for a configurable maximum time before trying to deliver the first message.
70 (89)
DN03305622 Issue 5-0 en
Message processing
For concatenated messages, it is also possible to configure if the SMS Center, when it receives a concatenated message, should wait for the last message before it triggers a new delivery attempt for the destination. The following events also trigger a new delivery:
.
After the message is scheduled for a deferred delivery, the SMS Center receives a new message, alert, report or error. When the message is scheduled there is already one or more pending message for that subscriber. The 'normal' deferred delivery is used. The SMS Center is restarted.
For more information on configuring the MMS hinting, see Configuring more messages to send hinting in Operating Guide (PDF).
Note
Any event that would normally trigger a new delivery attempt, will also do it even if the MMS hint or last message triggering for concatenated messages is used. Those events are report, alert, scheduled delivery or a new message without MMS or concatenation information.
4.3.18.9
Negative validity period Negative validity period means that the validity period has already expired when the short message arrives in the SMS Center. The delivery of the short message will not be attempted more than once. The attempt is made either immediately or after any queuing short messages triggered by the new short message have been delivered successfully. If the delivery of an older short message fails, the new one will not be attempted at all, because of the validity period expiration. The SMS Center considers SMs with a negative validity period to be valid as long as there are successful deliveries going on to the same destination.
DN03305622 Issue 5-0 en
71 (89)
Message Handling
Note
The negative validity period can only be used by applications by setting the validity period (VP). Mobile stations cannot set negative validity period. The negative validity period can be used by applications by setting the validity period (VP). Mobile stations cannot set a negative validity period, but the subscriber user data (SUG) and delivery attributes (DA) features can be used to configure a negative VP for specific subscriber groups.
4.4
Mobile-terminated (MT) message handling

Mobile-terminated (MT) short messages are destined from the SMS Center to mobile stations. The originator of a short message can be any a short message entity (SME): another mobile phone (MO-MT) or an application (AO-MT). When an SME has successfully submitted a new short message to a SMS Center, the SMS Center orders it to a queue according to the destination address included in the message, and then the SMS Center delivers the short message to the destination mobile station. After the delivery, the GSM/GPRS/3G network returns a delivery report, which is either positive or negative. The positive delivery report comes from the mobile station, the negative delivery reports are from a network element or the mobile station. The following sections describe the message processing phases only for MT messages.
4.4.1
Barring based on destination IMSI

With the barring based on destination IMSI feature, it is possible to restrict MT messages to be sent according to the B-subscriber s IMSI number.
Note
Barring based on destination IMSI can be used only with MAP/SS7, MAP/SIGTRAN and MAP/HSL interfaces.
72 (89)
DN03305622 Issue 5-0 en
Message processing
When sending an MT message, the SMS Center checks the destination IMSI number and compares the number with the barring rules. If the message is allowed to be delivered to the subscriber, the message is normally sent. If the rules deny delivery of the message, the kernel will receive a delivery failed report from the MAP subsystem. For the barred messages, the error code in the event log is 65 MT IMSI barred. The error is permanent and thus the SMS Center will not try to send the message again. The rules for the IMSI-based barring are defined in IMSI barring rules file(s). For each configuration of virtual SMS Center (VSMSC), a different IMSI barring rules file can be defined, so that each VSMSC uses different rules for barring messages. On the other hand, any of the virtual SMS Centers can use the same rules file. For more information on VSMSC, see Overview of the virtual SMS Center in Virtual SMS Center Guide (PDF). For more information on error codes, see Failure error codes in Message Handling (PDF).
4.4.2
MT routing
With the MT routing feature, it is possible to define routing rules for MT messages. When MT routing feature is enabled, the MT messages are sent via certain configured telecom interface links to the network, according to the message's destination address, that is, according to the configured rules with MSISDN prefix(es). Note that MT routing feature provides only preference to use dedicated link(s) but not "must-use" principle, that is, if dedicated link for some reason cannot be used, some other link is used. The following figure shows the message flow when MT routing feature is enabled.
DN03305622 Issue 5-0 en
73 (89)
Message Handling
MT -message
1. Is MT routing enabled? Yes 2. Prefix defined for destination addres? Yes 3. Which links are defined for prefix?
No
No
4. Is suitable link found?
4.b)
4.a) Message is sent via suitable link.
5. SEND_POLICY 2 applied.
Figure 17.
MT routing message handling
Description of the MT routing message handling: 1. When MT message is in delivery phase, the SMS Center checks if the MT routing feature is enabled. If the MT routing is not enabled, the message handling continues without MT routing functionality (step 5). 2. The SMS Center checks (according to the MT routing configuration) if the destination address matches any of the configured prefixes. If there is no matching prefix, the message handling continues without MT routing functionality (step 5). 3. The SMS Center checks (according to the MT routing configuration), which links are dedicated for the found prefix.
74 (89)
DN03305622 Issue 5-0 en
Message processing
4.
The SMS Center checks the status of the dedicated links. a. The SMS Center selects a link from the list of dedicated links using round-robin algorithm. A suitable link must be up, not overloaded and configured for MT messages. If a suitable link from the list of dedicated links is found, the message is sent via that link. b. In case all the links dedicated for the prefix are not suitable for sending the message, the message handling continues without MT routing functionality (step 5). The message handling continues without MT routing functionality, that is, the destination link is selected using round-robin algorithm (SEND_POLICY=2) among all links.
5.
For more information on configuring MT routing, see Configuring MT routing in Administration Guide (PDF).
4.4.3
MT overload control
An overload situation can result from an overload in the telecom interface. When the overload situation occurs, any mobile-terminated (MT) requests from the SMS Center kernel are immediately replied to with a negative acknowledgement. The error code is set to value 61, which indicates gateway MSC (GMSC) congestion. For more information on error codes, see Failure error codes in Message Handling (PDF).
4.4.4
Failures in delivering short messages

If the delivery fails, the network returns a negative delivery report indicating the cause of the failure, that is, the error indication. The error indications are listed in Failure error codes in Message Handling (PDF). Error indications are classified as either permanent or temporary. If the delivery report does not come during the time set by system parameter WAIT_REPORT_TIME, the SMS Center considers it as a temporary error. A temporary error indicates that the mobile station is likely to become attainable within a reasonable period of time, and therefore a later delivery will be attempted according to the settings in the retry tables, see section Scheduling message delivery in Message Handling (PDF). If the SM delivery fails due to a temporary error, the SMS Center retries until:
DN03305622 Issue 5-0 en
75 (89)
Message Handling
the short message is cancelled, deleted or replaced the delivery succeeds the validity period of the short message expires.
A permanent error gives no cause for further attempts, and so the short message is discarded. Alert SC After a temporary error situation is over, for example when the mobile subscriber switches on his or her mobile station again, the network sends the SMS Center an Alert SC notification indicating that the subscriber is again available to receive short messages.
SMSIWMSC
MSC/ SGSN
MS SMS Center
HLR
VLR
Figure 18.
Alert SC
When the SMS Center kernel receives the alert, it schedules a new delivery attempt for the first short message in the queue waiting for delivery. The scheduling is controlled with system parameter ALERT_D_INTVL which defines the delay (a few seconds) after the alert before the first short message will be attempted. The first short message after the alert is not sent right away because the mobile station is not necessarily ready to receive the short messages immediately. The delay in the SMS Center is not needed if the network already delays the sending of the alert.
76 (89)
DN03305622 Issue 5-0 en
Message processing
Note
Alert SC may cause a reachability notification to be sent to the VMS if so configured. Refer to reachability notification parameter RN_PAUSE for the configuration.
See also Scheduling message delivery in Message Handling (PDF).
4.4.5
Successful delivery
A successful delivery is indicated by a successful delivery report returned from the destination mobile station to the SMS Center. After receiving the delivery report, the SMS Center removes the short message from the database. The SMS Center is allowed to have one pending short message delivery (that is, the delivery report has not been received yet) with a specific mobile station at any given time. If one or more short messages to the same destination are waiting for delivery, they cannot be delivered before the network returns a successful delivery report for the previous delivery. In the meantime, deliveries to other mobile stations can, of course, proceed normally. System parameter WAIT_REPORT_TIME defines the time-out for a pending delivery report. If the delivery is successful, the SMS Center proceeds with the next short message in the destination queue. If system parameter REPORT_D_INTVL is not zero, there is a short delay between the deliveries. Also, if REPORT_D_INTVL is set, the more messages to send (MMS) functionality is not working.
4.5
Application-terminated (AT) message handling

Application-terminated (AT) short messages are messages that mobile stations submit to the SMS Center to be further delivered to an application. In accordance with 3GPP TS 23.040, the SMS Center forwards the short messages to a protocol or device associated with the protocol identifier (PID). The SMS Center rejects PIDs associated with external applications that are not implemented by the operator, causing a negative acknowledgement to be returned to the originator.
DN03305622 Issue 5-0 en
77 (89)
Message Handling
Instead of a PID, an application prefix or a fixed application address is used to address the short message to its destination when a standard PID is not defined or when the PID is not supported in the mobile station. The following sections describe the message processing phases only for AT messages.
4.5.1
Suffix stripping
The destination address suffix stripped or removed from the destination address in the ASE before the message is delivered to an application. The stripping is enabled or disabled in the application's user profile file by using the destination address suffix strip parameter. In submit logs, the suffix can be filtered out from the destination address field if the autosuffixing function is active for the destination application. Note that the delivery log still shows the suffix in the destination address field.
4.5.2

CIMD2 application terminated overload control (CATOC) is a dynamic control which automatically rejects and accepts messages per application. It prevents application-terminated messages to fill in the SMS Center database when the applications cannot sufficiently handle their application-terminated traffic and that way also prevents possible capacity drop of the application server (ASE) interface. The feature is implemented so that the application-terminated delivery logic keeps track of how many messages are pending and informs the submit logic when to accept or reject the incoming messages, as described in section CIMD2 application overload control (part 1) in Message Handling (PDF). The CATOC works dynamically and per ASE subscriber account, that is, per application. For every application there is a configurable upper and lower limit for a pile of pending messages in the database. When this upper limit is exceeded, the submits are rejected and accepted when below the lower limit. When the application is not logged in, the submits are rejected. The CATOC feature can be activated or deactivated for subscriber type 3 (send & receive) applications.
78 (89)
DN03305622 Issue 5-0 en
Message processing
4.6
4.6.1
Status reports
Phase 1 and phase 2 status reports
When submitting a short message, the subscriber may request a status report (SR) telling whether or not the short message reached its destination. The SMS Center knows the status of a short message by its log type and the related log success indicator, which are kept in the result database. The combination of log type and log success indicator needs to be mapped to some predefined value depending on whether it is requested by a mobile station or an application. There are two different types of SRs:
.
Phase 1 SR When requesting a SR from a phase 1 mobile station, a string must be inserted in the beginning of the short message text. The string is defined by the kernel parameter SR_AS_SM_REQ_ID. The format of the phase 1 SR is defined in xdbsm_res__mx.cf configuration file.
Phase 2 SR A subscriber with a phase 2 mobile station can request a SR by selecting it from the mobile station's menu.
The validity period of SR is defined with the kernel parameter STATUS_REPORT_VP. If the validity period expires, the SR is discarded.
Note
The SMS Center tries to deliver the SRs like a normal mobileterminated short messages. This means that, for example, the retry policy affects also the SRs. SRs can be delivered even if the final status has not been reached for the short message. In this case the parameter value is also for a SR delivery in pending delivery situations.
Error and success codes that trigger SRs for the mobile stations can be defined in the kernel parameter MO_DEF_STATUS_REPORT. MO_DEF_COM_STATUS_REPORT defines SRs requested by an SMS command.
DN03305622 Issue 5-0 en
79 (89)
Message Handling
Status reports for fast-forward MT/AT messages The following list describes the handling of SRs with fast-forward MT/AT (FFMT and FFAT) messages.
.
In case of a temporary error, and if the SMS Center is configured to send an SR with a temporary error, the SR is sent to the originator. If the delivery of FFMT message succeeds or delivery fails with a permanent error, a status report (if requested) is sent to the originator. In case of MO-MT or MO-AT message, the SMS Center tries to send the SR as an FFMT message. If the delivery of an SR succeeds, the SMS Center writes successful event log. If the SR delivery fails, the SMS Center writes the event log with an error (permanent or temporary). If the error is temporary then the SR is inserted to the database and will be delivered according to retry policy, otherwise if the error is permanent the SR is dropped. In case of AO-MT message, the SR is treated as an FFAT message. If it cannot be delivered via FFAT, it is inserted to the database and delivered to the application.
For more information on configuring the status reports, see Configuring status reports in Operating Guide (PDF).
4.6.2
Status report for first temporary result

The concept 'first temporary result of a message' is hard to define. In some cases there is no delivery attempt for a new message. Immediately after the SMS Center has received a message, its state may be what the SMS Center considers transient for a while. The SMS Center will not send a status report while the message is in transient state. The following explains what the SMS Center considers to be the first result of a message in different cases. Mobile-originated (MO) message For MO messages, the system parameter MO_DEF_STATUS_REPORT in kernel.cf configuration file defines the different events that trigger a status report. See kernel.cf in Configuration Files (PDF). Application-originated (AO) message For application-originated messages the status report request can be set for each submit separately. The srr parameter itself follows the same bit field logic as MO_DEF_STATUS_REPORT.
80 (89)
DN03305622 Issue 5-0 en
Message processing
Mobile-terminated (MT) message For an MT message, there are three different cases. Depending on the setting NEW_SM_POLICY, a new message for a certain mobile destination may trigger: 1. delivery of a different message to the destination in question If the new short message triggers a delivery of a different message, the SMS Center will wait for the outcome of that delivery before deciding what to do. If the delivery fails with a temporary error (next delivery according to retry tables), a status report for the new message is generated indicating that the message has been successfully submitted and is waiting for delivery. This is the typical case when there were other messages already queued for the destination. If the delivery succeeds or fails permanently, no status report is generated immediately for the new message. Instead, the next message for the destination is attempted and the outcome of that attempt is checked in turn. In other words, while there are deliveries going on for the destination, the SMS Center treats the status of the new message as transient and will not generate a status report for it. However, the ongoing delivery attempts will guarantee that the status report for the new message will be delivered when it is its turn in the queue. If, before the new message is attempted, a delivery attempt results in a temporary error, the status report is generated as described in the previous paragraph. 2. delivery of the new message If the new message triggers the delivery of the new message, the status report for the message is generated after the report (or error) from the network is received. 3. no delivery at all If the new message triggers no delivery attempt (NEW_SM_POLICY 5 and also 4 in some cases), the status report is generated immediately after a successful submit. Note that setting NEW_SM_POLICY to 3 ensures that the new message for a destination is always attempted first. Application-terminated (AT) message For an application-terminated message there are two different scenarios related to handling the first temporary status report of a message:
DN03305622 Issue 5-0 en
81 (89)
Message Handling
1. 2.
Application is not logged in Application is logged in
If the application is not logged in, a status report indicating successful submit is generated immediately after the submit. If the application is logged in, the sending of the first temporary status report depends on the number of pending messages to be delivered to the application. If the number of pending messages exceeds a certain limit, the first temporary status report is sent immediately after a new message is submitted. If the number of pending messages is under the limit, no first temporary status report is sent, but only the final status report is sent after the delivery to the application (if configured so). The limits for when these status reports are sent or not sent can be configured in the ASE-subscriber profile file of the application in question. This mechanism uses the same settings as the CIMD2 application terminated capacity overload control (CATOC) feature. The CATOC feature is designed to automatically bar further submits when the number of pending messages gets too high. Even if the CATOC and the first temporary result triggering use the same mechanism and settings, they can be separately enabled. For example, the following settings configure the upper limit of the number of the pending messages, which enables the first temporary result:
delivery cache size = 1000 max cache size which disable delivery = 70
This means that the traffic is switched off (for CATOC), and/or sending of first temporary status report at 70% of 1000 messages pending. The following setting is used by CATOC to enable the traffic flow again:
max cache size which enable delivery = 30
The above setting is not used, in practice, for the first temporary result triggering, as most likely the total cache will overflow as the incoming stream of messages is not reduced as in the CATOC case. If the cache overflows, the packet switch (PSW) will remain in the slower polling mode until all pending messages have been handled. Only after that, the first temporary status reports will be suppressed again. See also Enabling status report for first temporary result for AO and AT traffic in Operating Guide (PDF).
82 (89)
DN03305622 Issue 5-0 en
Failure error codes
Appendix A Failure error codes
A.1
Failure error codes

The following tables list the error codes used when there is a failure in sending a short message (in delivery or in submit phase).
A.1.1
Delivery error codes
Table 8. Error code

1 9 11 13 15 19 20
Delivery error causes Status

P P P T P T T
Error cause
Unknown subscriber Illegal subscriber Teleservice not provisioned Call barred CUG Reject SMS not supported by MS Error in MS
Description
The subscriber is unknown to the PLMN. The mobile station failed authentication. The subscriber has no SMS subscription. The mobile station is barred. Closed user group (CUG) has rejected the message. The mobile station (MS) does not support short messaging. Error occurring within the mobile station at reception of short message, for example, lack of memory in event that Mem_cap_exceed error is not available, or protocol error. No SMS provision in the visited network (VPLMN). No memory capacity available in the mobile station to store the message. Non-reachable subscriber. This error indication is given when reasons for absence are not available in the network (PLMN). Congestion encountered at visited MSC (VMSC) or SGSN. Possible reasons can be that any of the following events are in progress: - short message delivery from another SMS Center - IMSI or GPRS detach - location update or inter-SGSN routing area update - paging - emergency call - call setup
21 22 29
Facility not supported Memory capacity exceeded Absent subscriber
T T T
30
MS busy for MT SMS
DN03305622 Issue 5-0 en
83 (89)
Message Handling
Table 8. Error code

36 44 60 61 63 64 65 66
Delivery error causes (cont.) Status

T P T T T T P P
Error cause
Network/Protocol failure Illegal equipment No paging response GMSC congestion HLR timeout MSC/SGSN_timeout MT IMSI barred SS7 GT translation missing SS7 subsystem congestion SS7 subsystem failure SS7 unequipped user SMRSE/TCP Error MO/AO congestion MT congestion Message not in DB No response GPRS suspended SS7 network failure SS7 network congestion SS7 unqualified VSMSC not found No paging response via MSC
Description
Network protocol error. The IMEI of the mobile station is blacklisted in the equipment identity register (EIR). No paging response. Congestion occurred in the MAP or SMRSE interface. Timer of the MAP operation towards HLR expired in the MAP interface. Timer of the MAP operation towards MSC or SGSN expired in the MAP interface. MT-delivery barred based on the B-subscriber s IMSI. No global title translation configured for destination MSISDN or network element in the SS7 SCCP level configuration. Local or remote subsystem congested. Remote subsystem has no user connected. Notice about an unequipped user from the SS7 network. Error occurred in the SMRSE/TCP interface. SMS Center kernel's internal error: MO/AO message congestion. SMS Center kernel's internal error: MT message congestion. SMS Center kernel's internal error: message not in database. SMS Center kernel's internal error: no response. MS_busy_for_MTSMS and the servicing SGSN indicated that the GPRS connection is suspended. SS7 links are down or other problem exists in the network. SS7 network congested. Unqualified notice from the SS7 network. SMS Center kernel's internal error: virtual SMS Center not found Absent subscriber. No paging response via MSC.
67 68 69 70 71 72 73 74 75 76 77 78 79 80
T T T T T T T T T
84 (89)
DN03305622 Issue 5-0 en
Failure error codes
Table 8. Error code

81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 99 106
Delivery error causes (cont.) Status

T T T T T T T T T T P P T T T T T T
Error cause
IMSI detached Roaming restriction Deregistred in HLR for GSM The MS purged for GSM No paging response via SGSN GPRS detached Deregistred in HLR for GPRS The MS purged for GPRS Unidentified subscriber via MSC Unidentified subscriber via SGSN Data missing in SRI Unexpected data in SRI Data missing in FSM Unexpected data in FSM Msg waiting list full Data missing in RSDM Unexpected data in RSDM Other error Temporary error with HLR based forwarding
Description
Absent subscriber. The IMSI record was marked detached in the servicing MSC/VLR. Absent subscriber. Roaming restricted. Absent subscriber. The HLR does not have an MSC number stored for the destination mobile station. Absent subscriber. The mobile station purged for GSM. Absent subscriber. No paging response via SGSN. Absent subscriber. The IMSI record was marked detached in the SGSN. Absent subscriber. The HLR does not have an SGSN number stored for the mobile station. Absent subscriber. The mobile station purged for GPRS. Absent subscriber. Unidentified subscriber via MSC. Absent subscriber. Unidentified subscriber via SGSN. MAP error 'dataMissing' received as a response to the HLR query. MAP error 'unexpectedDataValue' received as a response to the HLR query. MAP error 'dataMissing' received from VMSC/SGSN. MAP error 'unexpectedDataValue' received from VMSC/ SGSN. The SC address list in the HLR is full. MAP error 'dataMissing' received as a response to the HLR update. MAP error 'unexpectedDataValue' received as a response to the HLR update. No detailed error code is available. Temporary error with HLR-based forwarding.
P T
Error indication has a permanent (P) status. Error indication has a temporary (T) status.
DN03305622 Issue 5-0 en
85 (89)
Message Handling
A.1.2
Submit error codes
Table 9. Error code

1 9 11 15 21 36 44 61
Submit error codes Status

P P P P T T P T
Error indication
Unknown subscriber Illegal subscriber Teleservice not provisioned CUG rejected Facility not supported System failure Illegal equipment GMSC congestion
Description
The network rejects the short message because the HLR lacks information about the subscriber. The mobile station failed authentication. The subscriber has no SMS subscription. Close used group (CUG) has rejected the message. The network does not support SMS. The network rejects the short message due to a network or protocol failure other than those listed above. The IMEI of the mobile station is blacklisted in the equipment identity register (EIR). The SMS Center rejects the short message due to congestion in the SMRSE or MAP interface with the MSC.
P T
Error indication has a permanent (P) status. Error indication has a temporary (T) status.
86 (89)
DN03305622 Issue 5-0 en
List of PIDs
Appendix B List of PIDs
B.1
List of PIDs
The following table lists the PIDs defined in 3GPP specification TS 23.040 Technical realization of the Short Message Service (SMS). Note the following characteristics of the table.
.
PID values are represented in decimal format. Column Standard action in SMS Center describes the default SMS Center action if no re-routing is done. PIDs marked with Y in the Re-routable column can be re-routed with no effect to SMS Center operation, unless they are used as application PIDs. Other PIDs can be routed as well, but it can affect to the operation. For example, routing replace PIDs to 0 will disable the replace function.
Table 10. PID value (dec)

0 1-13 14-15 16-18 19-23 24-31 32 33 34 35 36 37 38 39
List of PIDs Function (TS 23.040)
Standard action Rein the SMS routable Center

Accept Accept Reject Accept Reject Accept Accept Accept Accept Accept Accept Accept Accept Accept N Y Y Y Y Y Y Y Y Y Y Y Y Y
Simple case SME-SME Reserved in SMSC SME-SME Reserved in SMSC SME-SME Implicit - device type is specific to this SC, or can be concluded on the basis of the address. Telex (or teletex reduced to telex format) Group 3 telefax Group 4 telefax Voice telephone (i.e. conversion to speech) ERMES (European Radio Messaging System) National paging system (known to the SC) Videotex (T.100 [20] /T.101 [21])
DN03305622 Issue 5-0 en
87 (89)
Message Handling

40 41 42 43 44 45 46-47 48 49 50 51-54 55 56-62
List of PIDs (cont.) Function (TS 23.040)

Accept Accept Accept Accept Accept Accept Reject Accept Accept Accept Reject Accept Accept Y Y Y Y Y Y N Y Y Y N N Y
Teletex, carrier unspecified Teletex, in PSPDN Teletex, in CSPDN Teletex, in analog PSTN Teletex, in digital ISDN UCI (Universal Computer Interface, ETSI DE/PS 3 013) Reserved A message handling facility (known to the SC) Any public X.400 -based message handling system Internet Electronic Mail Reserved Reserved, SMSC proprietary mapping for SMSCommand Values specific to each SC, usage based on mutual agreement between the SME and the SC (7 combinations available for each SC) A GSM/UMTS mobile station. The SC converts the SM from the received TP-Data-Coding-Scheme to any data coding scheme supported by that MS (e.g. the default). Short Message Type 0 Replace Short Message Type 1 Replace Short Message Type 2 Replace Short Message Type 3 Replace Short Message Type 4 Replace Short Message Type 5 Replace Short Message Type 6 Replace Short Message Type 7 Reserved Enhanced Message Service (Obsolete) Return Call Message Reserved ANSI-136 R-DATA
63
Accept
64 65 66 67 68 69 70 71 72-93 94 95 96-123 124
Accept Accept Accept Accept Accept Accept Accept Accept Reject Reject Accept Reject Reject
N N N N N N N N N N N N N
88 (89)
DN03305622 Issue 5-0 en
List of PIDs

125 126 127 128-191 192-255
List of PIDs (cont.) Function (TS 23.040)

Accept Accept Accept Reject Accept N N N N Y
ME Data download ME De-personalization Short Message (U)SIM Data download Reserved SC specific
DN03305622 Issue 5-0 en
89 (89)

SMS Flow

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SMS Flow

Transféré par

Droits d'auteur :

Formats disponibles

SMSCDOC9000.00 Nokia SMS Center, Rel. SMSC 9.0, Product Documentation, v.

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

Appendix B List of PIDs 87 B.1 List of PIDs 87

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

About this document

About this document

January 2006 SMSC8.1

Updated for SMS Center 8.1. New section:

Terminating SMS gateway

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

Document identifier Issue

Updated for SMS Center 8.0. New sections:

SCTS, PMD, ICA, LIC Fast-forward MT/AT

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

About this document

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

Message handling overview

Message handling overview

message handling in the network message handling in the SMS Center.

Message handling in the network

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

HLR MSC/VLR SMS Center

Example of MO-MT short message routing in a GSM network

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

Message handling overview

Message handling in the SMS Center

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

SMS Center database

Message handling sybsystems in the SMS Center

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

Message handling overview

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

Message flow scenarios

Message flow scenarios

Mobile-originated - mobile-terminated SMs

DN03305622 Issue 5-0 en

# Nokia Siemens Networks

SMS Center database

1 MS a 3 6 Telecom interface 4b MS b 5 Kernel ASE 2 4a

# Nokia Siemens Networks

DN03305622 Issue 5-0 en

Message flow scenarios

Mobile-originated - application-terminated SMs

SMS Center database

1 3 MS a 6 Telecom interface Kernel 2 4a 4b 5 ASE External application

DN03305622 Issue 5-0 en