Message Handling
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)
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
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
4 (89)
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
dn03305622 4-0 en
5 (89)
Message Handling
Date Release
September 2005 SMSC8.0
Changes
Subscriber user groups Delivery attributes Message redirection Regional barring Content-based filtering MT routing
Modified sections:
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)
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
7 (89)
Message Handling
8 (89)
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
9 (89)
Message Handling
MS a
Air
BSC
ack sr ack
dr
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.
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)
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
11 (89)
Message Handling
Mobile subscribers
External application SMs, reports Telecom interface ASE SMs, reports External application External application
Kernel
Figure 2.
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)
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.
13 (89)
Message Handling
14 (89)
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
15 (89)
Message Handling
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)
3.2
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.
.
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
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)
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.
19 (89)
Message Handling
20 (89)
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.
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
CIMD2 application overload control (part 1) Subscriber user groups Delivery attributes Message redirection SCTS, PMD, ICA, LIC Lawful trace and archiving
continues...
22 (89)
Message processing
Figure 6.
Online closed user group Regional barring In advance credit check interface
submit phase
MT SMs Barring based on destination IMSI MT routing MT overload control Suffix stripping
AT SMs
MT-message
AT-message
Figure 7.
In the sections below, the different phases of the message handling of each part is described.
23 (89)
Message Handling
4.1
4.1.1
24 (89)
Message processing
MO-MT SMSC 1
MO-MT SMSC 2
MO-MT SMSC 3
3 5
2 4
SS7 1 6
Figure 8.
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.
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)
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
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
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)
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.
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
Accept
Reject
Figure 9.
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)
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
31 (89)
Message Handling
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
32 (89)
Message processing
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?
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
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)
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
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 2
PSW
Backup PSW
APPLICATION SERVER 1
APPLICATION SERVER 2
Application 1
Application 2
Application 3
Application 4
Figure 10.
4.2.3
36 (89)
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
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.
37 (89)
Message Handling
4.3.2
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)
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
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
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)
Message processing
AO-message
MO-message
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.
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)
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.
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)
Message processing
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.
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.
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
46 (89)
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).
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.
Description
AO message, originator address 1 rules_orig_app The originator address number conversion and barring rules file is set in rules_orig_app.
47 (89)
Message Handling
Table 3.
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).
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
48 (89)
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
49 (89)
Message Handling
MO/AO -message No
Figure 13.
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)
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'.
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
52 (89)
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.
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
Figure 14.
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)
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).
55 (89)
Message Handling
4.3.11
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
56 (89)
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.
57 (89)
Message Handling
For detailed description of CBF functionality, see Content-based filtering functionality in Subscriber User Groups Guide (PDF).
4.3.15
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)
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.
1. Is FFMT enabled? Yes 2. Is message MT/supported FF SM? Yes 3. Message sent to network (not stored DB)
No
No
a)
Figure 15.
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).
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)
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.
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
a)
Figure 16.
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)
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
4.3.18
63 (89)
Message Handling
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
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)
Message processing
Table 5. Value
5
Description
The SMS Center stores the new message. It does not deliver anything but uses the retry table instead.
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.
65 (89)
Message Handling
Table 7. Message
MO messages Status reports AO messages
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)
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:
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)
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:
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)
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.
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
4.4.1
Note
Barring based on destination IMSI can be used only with MAP/SS7, MAP/SIGTRAN and MAP/HSL interfaces.
72 (89)
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.
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.b)
5. SEND_POLICY 2 applied.
Figure 17.
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)
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
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)
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.
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
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
78 (89)
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.
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
80 (89)
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:
81 (89)
Message Handling
1. 2.
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)
A.1
A.1.1
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
T T T
30
83 (89)
Message Handling
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)
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.
85 (89)
Message Handling
A.1.2
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)
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.
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])
87 (89)
Message Handling
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
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)
List of PIDs
ME Data download ME De-personalization Short Message (U)SIM Data download Reserved SC specific
89 (89)