SMS Flow

Message Handling

DN03305622Issue 5-0 en

# Nokia Siemens Networks 1 (89)

SMSCDOC9000.00Nokia SMS Center, Rel. SMSC 9.0, ProductDocumentation, v.1

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted inany form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given as is and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia 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) # Nokia Siemens Networks DN03305622Issue 5-0 en

Message Handling

Contents

Contents 3

1 About this document 51.1 Summary of changes 51.2 References 6

2 Message handling overview 92.1 Message handling in the network 92.2 Message handling in the SMS Center 11

3 Message flow scenarios 153.1 Mobile-originated - mobile-terminated SMs 153.2 Mobile-originated - application-terminated SMs 173.3 Application-originated - mobile-terminated SMs 18

4 Message processing 214.1 Mobile-originated (MO) message handling 244.1.1 Telecom interface checkings 244.1.2 Terminating SMS gateway 274.1.3 Mobile number portability (MNP) based barring 284.1.4 Anonymous short message 314.1.5 Commands in the message 324.2 Application-originated (AO) message handling 344.2.1 CIMD2 application capacity control 354.2.2 PSW routing 364.2.3 Commands for external applications 364.3 Common message handling for all (MO-MT, MO-AT or AO-MT)

messages 374.3.1 Message validation 374.3.2 MSC direct SM delivery 384.3.3 Virtual SMS Center 394.3.4 Resolving destination 394.3.4.1 PID routing 434.3.4.2 PID re-routing 444.3.4.3 Shortcut MT routing 454.3.5 Number conversion and barring 464.3.6 CIMD2 application overload control (part 1) 484.3.7 Subscriber user groups 494.3.8 Delivery attributes 514.3.9 Message redirection 524.3.10 SCTS, PMD, ICA, LIC 524.3.11 Online closed user group 564.3.12 Regional barring 564.3.13 In advance credit check interface 564.3.14 Content-based filtering 574.3.15 Message collecting interface 584.3.16 Fast-forward MT/AT 584.3.17 Failures in submitting short messages 63



Contents

4.3.18 Scheduling message delivery 634.3.18.1 Prioritising messages 644.3.18.2 Scheduled delivery 674.3.18.3 Rescheduling deliveries 674.3.18.4 Rescheduling HLR-based SMS forwarding deliveries 694.3.18.5 Rescheduling FFMT deliveries 694.3.18.6 Deferring deliveries 694.3.18.7 Delaying deliveries 694.3.18.8 MMS hinting 704.3.18.9 Negative validity period 714.4 Mobile-terminated (MT) message handling 724.4.1 Barring based on destination IMSI 724.4.2 MT routing 734.4.3 MT overload control 754.4.4 Failures in delivering short messages 754.4.5 Successful delivery 774.5 Application-terminated (AT) message handling 774.5.1 Suffix stripping 784.5.2 CIMD2 application overload control (part 2) 784.6 Status reports 794.6.1 Phase 1 and phase 2 status reports 794.6.2 Status report for first temporary result 80

Appendix A Failure error codes 83A.1 Failure error codes 83A.1.1 Delivery error codes 83A.1.2 Submit error codes 86

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


Message Handling

1 About this documentThis document describes how Nokia Short Message Service Center (SMSCenter) handles the short messages. We also give a basic descriptionabout short message handling in the GSM network, but mainly concentrateon the SMS Center internal operations. By message handling we meanthe flow of short messages, status reports and internal messages.

In addition to the message handling, this document describes theprocesses of the SMS Center, and lists the commands that applicationsuse to handle the short messages.

This document is intended for operator personnel who need information onNokia SMS Center's internal message handling.

1.1 Summary of changes

Date

Release

Documentidentifier

Issue

Changes

November2007

SMSC9.0

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 Messageflow scenarios.- Added information about SMS relaying and added also a referenceto SMS Relaying Guide in Chapter Message flow scenarios.

January 2006

SMSC8.1dn03305622

4-0 en

Updated for SMS Center 8.1.New section:

Terminating SMS gateway



About this document

Date

Release

Documentidentifier

Issue

Changes

September2005

SMSC8.0

dn03305622

3-0 en

Updated for SMS Center 8.0.New sections:

Subscriber user groupsDelivery attributesMessage redirectionRegional barringContent-based filteringMT routingModified sections:

SCTS, PMD, ICA, LICFast-forward MT/AT

June 2004

SMSC7.0dn03305622

2-0 en

Updated for SMS Center 7.0.The whole document has been restructured.

1.2 References

Nokia SMS Center documents

Administration Guide, dn03299867

Configuration Files, dn03299531

External Applications Configuration Guide, dn03325626

In Advance Credit Check Interface Guide, dn03315009

Message Collecting Interface Guide, dn0430677

Online Closed User Group Guide, dn03315121

Operating Guide, dn03299879

Privilege Mobile Destination Guide, dn03366909

SMS Relaying Guide, dn70402186

Subscriber User Groups Guide, dn0518061


Message Handling

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



About this document


Message Handling

2 Message handling overviewThe point-to-point short message service (SMS) provides means forsending messages of a limited size to and from the mobile stations (MS)and SMS applications. The provision of the SMS makes use of a SMSCenter, which acts as a store and forward centre for short messages in theGSM/GPRS/3G network.

Short messaging service (SMS) message handling can be divided into twoparts:

. message handling in the network

. message handling in the SMS Center.

The technical realisation of the point-to-point SMS is defined in 3GPPspecification TS 23.040.

The following sections present an overview of SMS message handling.

2.1 Message handling in the network

The following figure shows an example of short message routing in theGSM network. Practically the message handling is the same in all types ofnetworks (GSM, GPRS and 3G), so only the example with GSM network ispresented here.



Message handling overview

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

The following list describes the short message routing in the GSM networkin chronological order:

1. Short messages (SMs) from MSs are routed through the basestation subsystem (BSS) to the mobile switching center (MSC).

2. The MSC communicates with the home location register (HLR) andvisitor location register (VLR) to receive authentication, routing andother relevant information for SMS.

3. The MSC routes the SM to the SMS Center via interworking MSC(IWMSC), which is physically located either in the MSC or the SMSCenter depending on whether the link between the SMS Center andthe MSC is implemented with MAP/SS7, MAP/HSL, MAP/SIGTRANor SMRSE/TCP. (In this example, SMRSE/TCP is used.)

4. When the SM has reached the SMS Center, the SMS Center informsthe MS about this by sending it a positive acknowledgement. If anerror occurs when submitting the SM to the SMS Center, the MS willreceive a negative acknowledgement. The SMS Center also addsthe date and time in the service centre time stamp (SCTS) to the SM

delivery report

status report

acknowledgement

short message

dr

sr

ack

BTS

BSC

MSC/VLR

MS a

GMSC

HLR

IWMSC

BSS NSS

A

SMSCenter

ack

MS b

dr

sr

dr

ackack

ack

dr

ack

sr

BSS - base station subsystemNSS - network subsystemBTS - base stationBSC - base station controller

dr

dr

sr

srsr

Air


Message Handling

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 localSMS Center time, while the time zone is an offset to GreenwichMean Time (GMT).

5. The SMS Center further tries to deliver the SM to its destinationaddress. If the SM is destined to an MS, the gateway MSC (GMSC)receives the SM from the SMS Center and requests routinginformation from the HLR. Once the location information for thedestination MS is obtained from the HLR, the GMSC is able todeliver the SM to the visited MSC (VMSC) of the recipient MS. If thedelivery fails, the SMS Center tries to resend the SM according to apredefined schedule until the SM's validity period is reached. If thedelivery fails because of a temporary error, and the MS becomesreachable again within the validity period time, the network sends anAlert SC notification to the SMS Center to inform that the MS is againable to receive SMs.

6. After a delivery attempt of the SM to its destination, the GSMnetwork always returns a delivery report to the SMS Centerinforming the SMS Center that the delivery either succeeded orfailed. The positive delivery report comes from the MS, and usuallythe negative delivery reports (also known as a failure reports) arefrom a network element, but can also be from the MS (for example,memory full).

7. If the originator of the SM has requested a delivery confirmation, theSMS Center will send a status report, which informs whether thedelivery of the SM was successfully completed or if it failed, to theoriginator.

2.2 Message handling in the SMS Center

The main SMS Center subsystems involved in message handling are thefollowing (see also the figure):




Figure 2. Message handling sybsystems in the SMS Center

. Telecom interface

The telecom interface subsystem receives short messages (SM)and delivery reports from mobile subscribers through the GSM/GPRS/3G network and forwards them to the kernel subsystem forfurther processing.

The telecom interface subsystem also receives SMs,acknowledgements and status reports from the kernel and forwardsthem to mobile subscribers through the GSM/GPRS/3G network.

. Kernel

The kernel subsystem performs most of the basic processing tasksfor the SMs, delivery reports and status reports, and sends andreceives them to and from the telecom interface and ASEsubsystems. The kernel uses the SMS Center database for storingSMs and status reports.

The kernel can also use the services of other SMS Centersubsystems (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

SMS Centerdatabase

Kernel

Mobilesubscribers

Externalapplication

Externalapplication

Externalapplication

SMs,reports

SMs,reportsTelecom

interfaceASE


Message Handling

Application server (ASE) subsystem is responsible for providingconnectivity to the SMS Center for external applications usingCIMD2 protocol.

The application server (ASE) subsystem receives SMs from anyoriginating application and forwards them to the kernel subsystemfor further processing.

The ASE also receives SMs and delivery reports from the kernel andforwards them to external applications.





Message Handling

3 Message flow scenariosThe SMS Center handles messages for the following kinds of traffic:

. mobile-originated (MO)

. mobile-terminated (MT)

. application-originated (AO)

. application-terminated (AT).

. relayed traffic

In a typical scenario, the short message (SM) is sent from one mobilesubscriber to another (MO-MT). The SMS Center also handles SMs thatare received from mobile subscribers and destined to external applications(MO-AT), and SMs received from external applications and destined tomobile subscribers (AO-MT).

Also, the SMS relaying feature of the SMS Center enables SM routing to aback-end SMSC, for example, in case the first delivery attempt (FDA) doesnot succeed. Then, instead of storing the SMs to the database, they areforwarded to a backend SMSC to be delivered later. For more informationon SMS relaying, see SMS Relaying Guide (PDF).

3.1 Mobile-originated - mobile-terminated SMs

For an MO-MT SM, the following figure provides an illustration of a basicscenario. The SMS Center sends and receives messages through thetelecom interface.



Message flow scenarios

Figure 3. MO-MT

The scenario has the following stages:

1. The sender (MS a) sends an SM to another mobile station (MS b),and the network routes the SM to the SMS Center.

2. 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-MTcriteria, the message is not stored to DB but only to the memory.

3. The kernel sends an acknowledgement to the sender (MS a) throughthe telecom interface, indicating that the SM has been accepted fordelivery.

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 b) through the

telecom interface.

5. The recipient (MS b) sends an acknowledgement to the SMS Center,indicating that the SM has been delivered.

6. If the sender (MS a) requested status report (SR) the kernel sendsan SR to the sender through the telecom interface, indicating that thedelivery was successful.

SMS Centerdatabase

2

KernelTelecominterface

ASE

1

3

4b

5

6MS a

MS b

4a


Message Handling

3.2 Mobile-originated - application-terminated SMs

When processing MO-AT messages, the SMS Center receives the SMfrom a mobile station through the telecom interface and routes it to anexternal application through the ASE.

The following figure describes a basic scenario where the mobilesubscriber sends an SM that is destined to an external application ratherthan to another mobile station.

Figure 4. MO-AT

1. The sender (MS a) sends an SM to an application, and the networkroutes the SM to the SMS Center.

2. 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-ATcriteria, the message is not stored to DB but only to the memory.

3. The kernel sends an acknowledgement to the sender (MS a) throughthe telecom interface, indicating that the SM has been accepted fordelivery.

4.. 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

Externalapplication

SMS Centerdatabase

2


ASE

1

3

6MS a 5

4a4b




5. The ASE sends an acknowledgement to the kernel, indicating thatthe SM has been delivered to the application.

6. If the sender (MS a) requested status report (SR) the kernel sendsan SR to the sender through the telecom interface, indicating that thedelivery was successful.

3.3 Application-originated - mobile-terminated SMs

When processing AO-MT messages, the SMS Center receives the SMfrom an application and send it to mobile station through the telecominterface.

The following figure describes a basic scenario where an applicationsends an SM that is destined to a mobile station.

Figure 5. AO-MT

1. The application sends an SM to the SMS Center, through ASE tokernel.

2. 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-MTcriteria, the message is not stored to DB but only to the memory.

3. The kernel sends an acknowledgement to the application throughthe ASE, indicating that the SM has been accepted for delivery.

Externalapplication

SMS Centerdatabase

2


ASE

1

3

4b

MS

5

6

4a


Message Handling

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. The recipient (MS) sends an acknowledgement to the SMS Center,indicating that the SM has been delivered.

6. If the sender application requested status report (SR) the kernelsends an SR to the application through the ASE, indicating that thedelivery was successful.





Message Handling

4 Message processingIn the following figures, the message handling inside the SMS Center isdivided 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.



Message processing

MO-message AO-message

Message validation

Resolving destination

Telecom interface checkings

MNP based barring

Anonymous short message

Virtual SMS Center

Number conversion and barring

CIMD2 application capacity control

PSW routing

SCTS, PMD, ICA, LIC

Commands in the message

MO SMs AO SMs

submitphase

Common for MO/AO-MT/AT SMs

Commands for external applications

Subscriber user groups

Delivery attributes

Lawful trace and archiving

continues...

Message redirection

CIMD2 application overload control (part 1)

Terminating SMS gateway

MSC direct SM delivery


Message Handling

Figure 6. MO-MT/AT or AO-MT message handling (part 1)

Figure 7. MO-MT/AT or AO-MT message handling (part 2)

In the sections below, the different phases of the message handling ofeach part is described.

MT-message AT-message

MT overload control

Scheduling message delivery

CIMD2 application overload control (part 2)

Fast-forward MT/AT

In advance credit check interface

Message collecting interface

MT SMs AT SMs

Barring based on destination IMSI

submitphase

deliveryphase

Database

Suffix stripping

Regional barring

Content-based filtering

MT routing

Online closed user group



Message processing

4.1 Mobile-originated (MO) message handling

Mobile-originated (MO) short messages are sent from a mobile station tothe SMS Center. They can be sent further from the SMS Center to anapplication or back to another mobile station through the GSM/GPRS/3Gnetwork.

When an MO short message is submitted to the SMS Center, it first checksif it is capable of handling the short message. The check includes shortmessage validity, congestion, storage capacity, and so on. If one of thesechecks fails, the SMS Center sends back a negative acknowledgement tothe network to be passed to the originating mobile station. If no problemsare found, a positive acknowledgement is returned to mark a successfulsubmission.

After analysing, storing the short message to the database and numberconversion, the SMS Center sends the short message to the destinationmobile station and gets a delivery report back from the destination mobilestation.

The following sections describe the message processing phases only forMO messages.

4.1.1 Telecom interface checkings

MAP routing

The MAP routing feature (licence-controlled application software) providesthe means to route MO short messages to the correct SMS Centers whenfor example certain applications are located on certain SMS Center(s) orwhen using multiple SMS Centers to reduce the load. The incoming MOshort messages are routed to the correct SMS Center(s) according to thePID and the destination address information carried in the short message.

In the following figure, an example of MAP routing is given.


Message Handling

Figure 8. Example of MAP routing

In the example the mobile station wants to use information located in theapplication server. The following operations take place:

1. The mobile station sends a short message requesting anapplication-specific service. The service center (SC) number is thenumber used for MO-MT traffic, that is, all the SMS Centers have thesame MSISDN.

2. The MAP interface notices that the short message is destined to anapplication and re-routes it to the correct SMS Center.

3. The SMS Center with the application receives the MO request andsends an acknowledgement to the re-routing MAP interface.

4. The MAP interface forwards the MO acknowledgement to the mobilestation.

SS7

35

24

1

6

ApplicationSMSC 1

MO-MTSMSC 1

ApplicationSMSC 2 MO-MT

SMSC 2 MO-MTSMSC 3



Message processing

5. The SMS Center sends the response to the mobile station shortmessage.

6. The mobile station acknowledges the response to the SMS Centerthat sent the response.

The SMS Center address displayed by the phone for an MTshort messageis always the SMS Center address of the sending SMS Center, even if theMO short message has been re-routed.

Note

Note that if MAP routing is activated, the second SMS Center does notget the original VMSC/SGSN address anymore, as the first SMS Centeraddress replaces the VMSC/SGSN address. Features relying on thecorrect VMSC will thus not work for the re-routed traffic. This includesfor example regional barring (REBA) feature.

Note

MAP routing is not needed for routing messages to CIMD2 applicationswithin networked SMS Center.

Note

When using SMRSE link, the same functionality is available with theMSC feature 619.

MAP overload control

If the internal interface between the MAP interface and the SMS Centerkernel is congested, the MO short messages and alert SC notifications arenegatively acknowledged to the network.

The total number of concurrent incoming dialogues can be also restrictedby the configuration parameter MAX_MO_SMS_COUNT of the MAP interface.


Message Handling

One service center address solution

The MAP/SS7, MAP/SIGTRAN and MAP/HSL interfaces supportoptimised SS7 network configuration where all mobile users can have thesame SMS Center address setting in the phone. MO short messages fromdifferent MSCs can be routed to different SMS Centers. For example, withfour hosts configuration the four SMS Center hosts are physicallyconnected to two gateway or transit MSCs. All other MSCs are routing theMO short messages to one of these SMS Center nodes through gatewayor transit MSCs.

MSC MO limit for SMRSE/TCP

In the SMS Center link configuration, it is possible to set a MO limit for thelinks. The defined MO limit is sent to the interworking MSC (IWMSC) in thebind request to limit the maximum number of short messages to besubmitted to the SMS Center through the link.

For instructions, see Configuring links dedicated only for MO or MT trafficin Administration Guide (PDF).

4.1.2 Terminating SMS gateway

With the terminating SMS gateway (TSG) feature (licence-controlledapplication software), it is possible to configure the SMS Center to receiveshort messages (SMs) from other operator's network to be delivered to theapplications residing in operator's own network.

When the TSG feature is used, the SMS Center emulates GSM networktowards foreign (other operator's) SMSCs to receive short messages andto forward them to SMS Center applications (applications in operator's ownnetwork).

TSG functionality comprises two functional components in SMS Centertelecom interface, an HLR-responder and an MT-receiver.

The HLR-responder responds to incoming HLR enquiries from foreignSMSC by returning the pre-defined visited-MSC address and an IMSIvalue. The virtual subscribers with their respective application addressesand IMSI numbers are listed in the TSG configuration forming a minimalHLR database. The HLRresponder acknowledges all HLR updaterequests.



Message processing

The MT-receiver converts an incoming MT-short message into an MO-short message and then forwards it to the SMS Center kernel, whichshould have the required application configured. The IMSI in the incomingMT-forwardSM is checked against the configured values. If a matchingvalue in the TSG configuration is found then the SM is converted andforwarded; the MT-receiver waits for acknowledgement from the SMSCenter kernel to acknowledge the received MT-short message.

For more information on the TSG functionality, see Terminating SMSgateway functionality in Terminating SMS Gateway Guide (PDF).

4.1.3 Mobile number portability (MNP) based barring

The SMS Center supports three methods for mobile number portability(MNP):. Barring based on originator IMSI received from the interworking

MSC (IWMSC).. Database of exported and imported MSISDNs maintained by the

operator and used by the SMS Center.. Subscriber user group (SUG) and incoming capacity allocations

(ICA) features, used together to handle lists of exported andimported 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 ownMNP 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 IMSInumber from the network, and configure the MNP based barring accordingthe originator's IMSI number. Itself the barring is defined with the samesyntax like in the other number conversion and barring rules files.

For more information on configuring IMSI based MNP barring, seeConfiguring IMSI based mobile number portability in Operating Guide(PDF).


Message Handling

MSISDN based MNP barring

It is possible for the operator to maintain a list of subscribers' MSISDNnumbers that are exported or imported. The messages originating fromMSISDN numbers defined in the imported list are accepted, and themessages originating from MSISDN numbers in the exported list arerejected.

For more information on configuring MSISDN based MNP barring, seeConfiguring MSISDN based mobile number portability in Operating Guide(PDF).SUG and ICA used for MNP

The licence-controlled features, subscriber user group (SUG) andincoming capacity allocations (ICA), can together be used to handle lists ofexported and imported MSISDN for MNP. Using these features, users tobe barred are left in the default ICA group, which is configured a maximumsubmit rate of zero, hence all traffic is barred. Other ICA groups can beused for the MSISDNS which are accepted, possibly setting different limitsfor different groups of subscribers.

For more information on the SUG and ICA, see Subscriber user groupsoverview 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 isunknown. The SMS Center conceptually defines the state of a shortmessage regarding the originator using the steps described below. Oncethe 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 proceduredescribed here.

The figure below presents the MNP process. Different phases areexplained in more detail under the figure.



Message processing

Figure 9. Processing of MO message from the MNP point of view

1. If the mobile number portability is disabled, the MNP checking isskipped, and the processing continues from step 8.

2. If the MSISDN based MNP is enabled, the processing continues insteps 3, otherwise processing continues from step 5.

MO-message

2. Is MSISDN MNP enabled?

1. Is MNP enabled?

Yes

No

No

Yes

3. Is MSISDN in exported file?Reject

No

4. Is MSISDN in imported file?

Yes

AcceptYes

5. Is IMSI MNP enabled?

NoYes

6. Is IMSI available?RejectNo

Yes

7. IMSI number conversion rules used.

Accept Reject

8. rules_orig_int rules used

No

9. SUG based MNP

Accept Reject


Message Handling

3. If the MSISDN of the originator is included in the exported numberslist (that is a file created for rejected MSISDNs), the message isrejected, and negative acknowledgement is sent to the originator.

4. If the MSISDN of the originator is included in the imported numberslist (that is a file created for accepted MSISDNs), the message isaccepted, and the message continues to the next phase of theoverall message handling process.

Note

If the MSISDN of the originator is not found either exported or importednumbers list, the message processing continues from step 8.

5. If the IMSI based MNP is enabled, the message processing continuefrom step 6, otherwise from step 8.

6. If, for some reason, no IMSI was received from the network, themessage is rejected, and negative acknowledgement is sent to theoriginator.

7. If IMSI was received from the network, then the decision of acceptingor rejecting the message is made according the rules defined in theIMSI number conversion rules file.

8. If the state of the message is still unknown, then it is defined by therules in the file defined by the rules_orig_int setting.

9. If SUG based MNP is configured to be used, all traffic acceptedaccording to the steps above will also be marked with theprovisioned subscriber group information, after which the ICAfeature can bar any restricted traffic.

4.1.4 Anonymous short message

The SMS Center supports anonymous MO-MT messaging. Operators canallow their mobile subscribers to send anonymous short messages bydefining the anonymity separately for each message, or certainsubscribers can be defined to send all their messages as anonymous.

Originator address

When there is a delivery attempt of a short message, the SMS Centerinspects the message's service description attribute to find out ifanonymity is requested for the short message. If the short message'sservice description value is the same as the value defined in the SMSCenter's anonymous message configuration (parameter



Message processing

ANO_SERVICE_DESCRIPTION), the SMS Center replaces the originatoraddress by a pseudo-address pre-defined by the operator. How theoriginal originator address and type are replaced, is defined by parametersANO_PSEUDO_ADDRESS and ANO_PSEUDO_ADDRESS_TYPE respectively.

Replace type PID

Replacing of short messages that have changed originator address mayresult to unintended replacements in the mobile station. If two differentoriginators send anonymous short messages to the same two destinationsusing the same replace type value, the later message will replace theprevious one although the short messages were not originally from thesame originator. It just looks like it to the mobile station, as the originatoraddress for both short messages is the pseudo-address set by the SMSCenter.

To prevent this, if the PID of the short message is one of the replace typevalues defined in 3GPP TS 23.040, the SMS Center changes the SMS-DELIVER.PID to 0.

Reply path

The anonymous short messages feature of the SMS Center requiresspecial handling with the reply path.

If the reply path is used, and the reply is sent to the sending SMS Center, itat least recognises that the destination address is its anonymous pseudo-address and can for example bar the short message. On the other hand,turning the reply path off may save the SMS Center from replies thatcannot be handled. The value of the reply path that the destination seescan be controlled by parameter ANO_REPLY_PATH_SETTING in thexsblibmx.cf file.

If the SMS Center feature Reply Path Suppression is active for MO shortmessages, it overrides parameter ANO_REPLY_PATH_SETTING.

For more information on configuring anonymous short messages, seeConfiguring anonymous short messaging in Operating Guide (PDF).

4.1.5 Commands in the message

The SMS Center support the 'commands in the beginning of user data'feature. A mobile user types in a command to the beginning of the shortmessage text to request that the SMS Center performs some specificactions on a short message that the same mobile users has sent earlier.


Message Handling

The following operations can be performed with the commands:

. deferred delivery

With the deferred delivery function the originator of the message canrequest that the first delivery attempt for the message will be at sometime in the future.

For example, if the originator types:

*p 2H30M#Thank you

the SMS Center will perform the first delivery attempt 2 hours 30minutes after the submit time.

. status report request

With the status report request, the originator of the message canrequest the status or delivery report for the message he or she iscurrently sending.


*notification#I will be there at 3 pm.

the SMS Center will deliver a status report to the originator after themessage as been sent to the destination.

. keyword based routing

With the keyword based routing, mobile users can define certainprotocol identifiers (PIDs) to direct the short messages to certainaddresses. The PIDs are defined in the 3GPP TS 23.040.


*FAX#I got the meeting minutes, thank you!

the SMS Center will deliver the message to a fax machine at thedestination address.

. anonymous short message

In an anonymous short message, the originating address (MSISDN)is hidden from the recipient of the message. The originator addressis replaced with an operator-defined string.


-A-Guess who?



Message processing

the SMS Center will deliver the message to the recipient with anoperator-configured originator address.

When an MO message is submitted to the SMS Center, the commands inthe message text are executed after the message has passed the basicsyntax checks and the originator and destination are validated.

The messages have to be 7-bit coded messages. The command(s) mustbe in the beginning of the user data (in the SMS-SUBMIT TP-UD field). Ifthe text between the command's begin and end markers does not map toany command, it is treated as a normal text. This implies that the text is notstripped from the user data and the SMS-SUBMIT TP-UD field is notscanned for more commands.

For more information on configuring the commands in the beginning ofuser data, see Configuring commands in the beginning of user data inOperating Guide (PDF).

4.2 Application-originated (AO) message handling

External applications submit short messages to the SMS Center kernel viathe application server (ASE). The SMS Center then delivers the shortmessage to the destination mobile station via the GSM/GPRS/3G network.After delivering the short message to the mobile station, the SMS Centercan, depending on the application type and the possible status reportrequest, send a status report to the application stating whether the deliverywas successful or not.

External applications connect to the SMS Center kernel using the CIMD2protocol.

There are three different ASE application types:

. Send-only

A send-only application can only send short messages. If it wants toknow the status of a previously submitted short message, it mustquery for it from the SMS Center.

. QueryingA querying application can both send and receive short messages,but it has to query for the status and incoming short messagesaddressed to it.

. Receiving


Message Handling

A receiving application can both send and receive short messages.Status reports and incoming short messages are delivered to itautomatically.

The following sections describe the message processing phases only forAO messages.

4.2.1 CIMD2 application capacity control

By using the CIMD2 application capacity control (CACC) feature, theoperator can configure maximum submit rates for groups of ASE-subscribers, or per individual ASE-subscriber account. In addition, theoperator can redistribute the message submitting capacity betweengroups of applications so that busy applications can have temporarily morecapacity.

The applications are arranged into groups and the submit capacitydefinitions are allocated to the groups. The number of groups is in principleunlimited as well as is the number of applications in one group.Applications which are not explicitly defined to a group will be implicitlyadded to the default group, which has its own settings.

The capacity allocation to a group is done by defining the allowed numberof submits per second. The redistribution of any unused capacity is doneby distributing the unused submit capacity of the previous secondproportionally according to the configured maximum extra capacity pergroup.

It is possible to apply changes to the CACC setup on-the-fly. This providesthe means to continue to run the SMS Center, ASE, PSW, and all CIMD2connections without interruption when changing the settings; for example,while adding a new application or increasing the allocated capacity for agroup. This can also be used to change the distribution at different times ofa day, or have different limits for different days of a week. For example,different limits during the nights, or weekends.

For instructions on how to configure the CACC feature, see ConfiguringCIMD2 Application Capacity Control (CACC) in External ApplicationsConfiguration Guide (PDF).



Message processing

4.2.2 PSW routing

The packet switch (PSW, licence-controlled application software) isresponsible for routing short messages to respective SMS Center kernelsin networked SMS Centers. The PSW determines the route of a shortmessage according to the protocol identifier (PID) or destination address(daddr) of the message. The PSW routes the short message according tothe PID if the message has a non-zero value and is mapped in the routingtable. If PID-based routing cannot be done then the routing is based on thedestination address of the short message.

Figure 10. PSW and ASE in the networked SMS Center

4.2.3 Commands for external applications

The SMS Center supports some commands that can be used byapplications. Each application can only use the commands to affect shortmessages it has sent itself. The following operations can be performedwith the commands:

Application1

Application2

APPLICATION SERVER 1

BackupPSW

KERNEL2

KERNEL1

Application3

Application4

APPLICATION SERVER 2

PSW

Host 1 Host 2


Message Handling

. enquiring a status report

The command for a single status report request produces only thecurrent status report from the defined short message independentlyof 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 shortmessage in the SMS Center database. The application must sendthe new message using the same PID type and SMS Center, and themessage must be from the same originator to the same destinationas the earlier message. (This command is also supported for MOshort messages).

. cancelling an earlier submitted message

The cancelling command can be used to delete an un-sent shortmessage from the SMS Center database.

4.3 Common message handling for all (MO-MT, MO-ATor AO-MT) messages

The following sections describe the message processing phases commonto all MO-MT, MO-AT and AO-MT messages.

4.3.1 Message validation

During the message validation phase, the SMS Center does severalcheckings for validating the message accuracy, as well as it unpacks themessage packet. The validation consists of checking (syntax, invalidcharacters 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 negativeacknowledgement is sent to the originator.



Message processing

4.3.2 MSC direct SM delivery

The SMS Center supports (if enabled) Nokia MSC feature 1633: Direct SMDelivery (implemented in Nokia MSC M12 ED2). The direct SM deliveryprovides a solution for direct short message (SM) delivery without theinvolvement of SMS Center, that is, the MSC tries to deliver the MO-MTmessage straight to the destination subscriber, without sending it to theSMS Center.

In case this attempt to send the SM straight to the destination fails withsome error, the MSC forwards the MO-SM to the SMS Center, and the SMdelivery is carried out in traditional way by the SMS Center.

Based on the configuration, the MSC can set the Reserved value ofTransport Protocol-Message Type Indication (TP-MTI) field in the SUBMIT-MO-SM, which indicates to the SMS Center that the direct SM deliveryfailed.

In case the support for MSC direct SM delivery is enabled in the SMSCenter, the SMS Center handles these messages differently from othermessages. This means that the SMS Center does not start to deliver theseSMs immediately, which would probably lead to another delivery failure,but it performs an SM delivery delay. In this way many unsuccessful SMdeliveries can be avoided, which further improves the efficiency of theusage of resources.

From message handling point of view the procedure for MSC direct SMdelivery support in SMS Center is as follows, when support for MSC directSM delivery is enabled in SMS Center and direct SM delivery feature isactivated in MSC.

. Incoming message with Reserved value in TP-MTI field isconverted to a normal submit message and deferred delivery time isset to the value of the parameter defined in kernel message handlingconfiguration.

. If the destination of the message is mobile subscriber (MO-MTmessage) 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 doneby MSC).

. If the destination of the message is application (MO-AT message)then the message delivered normally.


Message Handling

Note that, in case the support for MSC direct SM delivery is disabled inSMS Center and direct SM delivery feature is activated in MSC, theprocedure is as follows.

. Incoming message with Reserved value in TP-MTI field is rejectedwith 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 SMdelivery in SMS Center, see Configuring MSC direct SM delivery support inOperating Guide (PDF).

4.3.3 Virtual SMS Center

The virtual SMS Center (VSMSC) feature, allows to set up differentconfiguration profiles associated with a particular SC-ADDRESSparameter for the SMS Center. This feature affects mainly the submitting ofshort messages.

This means that when the SMS Center receives a short message, itchecks the SC-ADDRESS, and if a corresponding VSMSC profile is found,the checkings related to the mobile number portability (MNP), anonymousmessaging, and number conversion and barring will be made according tothe found profile.

If no VSMSC profile is found, the default VSMSC profile is used. If thedefault VSMSC profile is not set, the short message is barred and the'Virtual SMSC is not found xxxx' alarm is set.

For more information on virtual SMS Center feature, see Overview of theVirtual SMS Center in Virtual SMS Center Guide (PDF).

4.3.4 Resolving destination

The SMS Center routing determines the correct destination for SMs. TheSMS Center determines the destination of a SM according to the PID (TP-PID) or the destination address (TP-DA) included in the SMS-SUBMIT.

The destination address is treated as an international number in case type-of-number (TON) is international number and number-plan-indication isISDN/telephone numbering plan. Decimal value of this combination is 145.For example, typically destination address gets international number valuein the mobile station when SM is sent from the mobile station in such way



Message processing

that the '+' -sign is inserted to the front of the destination number. In casethe '+' -sign is not given in the front of the number, the mobile stationcreates the SMS-SUBMIT where type-of-number and number-plan-indication value results to value different from 145. Note that alphanumericaddresses are not supported for MO traffic.

The figure below presents the process how the SMS Center analyses thePID and/or the destination addresses. Different phases are explained inmore detail under the figure.


Message Handling

Figure 11. Resolving the destination

Description of the phases:

1. PID re-route table checking.

Yes2. Is PID zero?

No

3. Is PID supported?RejectNo

Yes

4. Is there application with the PID?ApplicationYes

No

5. Is destination address in Int. or Other?Other

8. rules_dest_app conversion

9. Is there application with the address?Application

Yes

6. Is shortcut MT routing active?

MO-message

7. rules_dest_app_int conversion

10. rules_dest_nat or rules_dest_int

MT

Int

No

Yes

No

AO-message



Message processing

1. If the PID re-routing feature is configured (that is, the PID re-routetable is defined), the SMS Center replaces the PID of the messageaccording 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 itis set to zero, the message handling continues from step 5.Otherwise, the message handling continues from step 3.

3. The SMS Center checks if the PID is supported.

If the PID is not supported, the SMS Center rejects the message andsends a negative acknowledge to the mobile station.

See also PID routing and Failure error codes in Message Handling(PDF).

4. The SMS Center checks if any application contains the same PID asthe message. If there is an application with the same PID themessage is routed to that application, except if the message is AOtype then the message is rejected (that is, AO-AT case).

5. If the message does not contain a PID, or the PID of the message issupported but no application containing the same PID exists, thedestination address is analysed whether it is in international or someother format. If the destination address is in international format, themessage handling continues from step 6.

6. The SMS Center checks whether the shortcut MT routing feature isactivated. If it is activated, the message is considered as an MTmessage and the message handling continues from step 10.

If the shortcut MT routing feature is not activated, the messagehandling continues from step 7.

See also Shortcut MT routing in Message Handling (PDF).7. If the destination address is in international format, it goes through

the rules_dest_app_int conversion. After this, the messagehandling 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.


Message Handling

9. The SMS Center checks if there is an application with the destinationaddress.

If there is an application with the address, the message is routed tothat application, except if the message is AO type then the messageis rejected (that is, AO-AT case). If there was no application with theaddress, the message is considered as an MT message and themessage handling continues from step 10.

10. If the original destination address is in some other than internationalformat, it goes through the rules_dest_nat conversion, startingwith the original address (before rules_dest_app orrules_dest_app_int conversion).If the original destination address is in international format, it goesthrough the rules_dest_int conversion, starting with the originaladdress (before rules_dest_app or rules_dest_app_intconversion).See also Number conversion and barring in Message Handling(PDF).

Note

The application profile is important for the routing because it is theprimary routing information. You can modify it through the SMS CenterGUI 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 ASEapplication for VSMSC profile is assosiated, the message handling isslightly different than presented in above. For more information onVSMSC, see Overview of the Virtual SMS Center in Virtual SMS CenterGuide (PDF).

4.3.4.1 PID routing

An application-terminated (AT) short message, that is routed by theprotocol identifier (PID), can have secondary information passed as adestination address and thus the destination address is not used if the PIDis set. The 3GPP TS 23.040 defines the PID list. Using PID values requiresthat the mobile station supports changing of the PID and that there is asuitable PID standardised for the application. All MO messages with PIDsthat are not defined in the 3GPP TS 23.040, (that is, the reserved PIDs)are rejected.



Message processing

Besides the PID, Nokia SMS Center also supports an application prefixmechanism. This means that there is a unique prefix defined for everyapplication (for example CIMD2, e-mail) known by the SMS Center kernel.When a subscriber sends an MO short message, he/she gives adestination address that begins with the application prefix. From the prefixthe SMS Center kernel knows that this short message must be routed toan application. The advantages of the application prefix mechanism arethat all mobile stations support it (if they support MO short messages in thefirst place) and that there is no need for changing the PID values.

In addition, it is possible to configure a fixed address for each ASEapplication. In this case, no prefix is used, and only exact matches arerouted to the application. It is possible to have overlapping applicationaddresses if the shortest one is of fixed length. It is also possible to haveoverlapping fixed addresses.

Both the PID and the application prefix are defined for the application inthe application database of the SMS Center.

The SMS Center first checks the PID of the incoming short message. The3GPP TS 23.040 defines two kinds of PIDs, routing PIDs and PIDs forother purposes, for example, replace message type. For list of PIDs, seeList of PIDs in Message Handling (PDF).

If it is a routing PID other than zero, the SMS Center checks if there is anapplication for that PID. If there is such an application, the message will berouted to it. Otherwise, the SMS Center will route this message accordingto its destination address.

If it is not a routing PID, the SMS Center checks if there is an applicationprefix in the beginning of the destination address. If the short messagedoes not contain either a PID or an application prefix, that is, the shortmessage is not destined to application, the system assumes that the shortmessage 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 togo to different PID applications or directions than defined by the originalPID. The following figure presents an example of the message flow whenthe PID re-routing feature is used.


Message Handling

Figure 12. Example of PID re-route table

The PID re-route table is configurable and the PID table is based on the3GPP TS 23.040. If the PID coming from a mobile station is not found inthe PID re-route table, the original PID is checked normally from the PIDtable.

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 whichmatches a country code, all messages cannot be sent to the MS in thatcountry even if the destination address is given in international format. Themessages are routed to the application instead. This is due to the routingmechanism of the SMS Center as explained in earlier sections.

For example, if an application with application prefix 358 (country code ofFinland) is defined on the SMS Center, all messages sent to thedestination address 358xxxxxxxxxx or +358xxxxxxxxxx are always routedto the application. In this case, it is practically impossible to sendmessages to the mobile subscribers in Finland through this SMS Center.

In this kind of situation, the shortcut MT routing feature provides apossibility to send messages to the mobile subscribers. With shortcut MTrouting feature enabled, the SMS Center will always resolve thedestination of the MO messages to be MS if the destination address isgiven in international format.

For example, an application with an application prefix 358, is defined in theSMS Center. Sending messages to destination address 358xxxxxxxxx innational and international format gives the following results, see the tablebelow.

mobilestation

PID = 66

PID re-route table PID table

...65 > 6466 > 6467 > 64...

PID = 64 ...64 - SM Type 065 - Replace SM Type 166 - Replace SM Type 267 - Replace SM Type 3...

to MS

PID = 67

PID = 64



Message processing

Table 1. Example of resolving the destination with the shortcut MT Routingfeature

Destination address Destination

358xxxxxxxxx Application-terminated (AT)+358xxxxxxxxx Mobile-terminated (MT)

As a PID has priority in routing over the destination address, the PID of themessage is checked before the shortcut MT routing decision is made. Ifthe PID of the message matches the PID of a receiving application, themessage is routed to the application, regardless of the destination addressand the destination address type.

For more information on configuring the shortcut MT routing, seeConfiguring shortcut MT routing in Operating Guide (PDF).

4.3.5 Number conversion and barring

The main purpose of the SMS Center number conversion facility is toconvert the destination addresses of incoming short messages to theinternational address format or to the national format, depending onwhether the message is destined to a mobile station or an application.

With barring, it is possible to restrict certain subscribers from sending orreceiving short messages. This can be carried out through the conversionrules that are defined in the number conversion and barring rules files.

For mobile-terminated messages, the type of the destination address mustbe international. In addition, in some cases there is a need to define rulesfor how addresses are converted to some other format.

The following tables present the number conversion and barring functionsin chronological order in case of MO, AO and MT messages, for bothoriginator and destination addresses, in each case. The MO and AOphases are done in the submit phase, and the MT barring in the deliveryphase.

In the tables, each conversion is named according to the setting, wherethe used rule file is defined (in $SC_CONFPATH/xsblibmx.cf configurationfile).


Message Handling

If the virtual SMS Center feature is in use, all number conversion andbarring rules files can be separately defined for each virtual SMS Centerprofile. For more information on virtual SMS Center feature, see Overviewof the Virtual SMS Center in Virtual SMS Center Guide (PDF).

Table 2. MO message number conversion and barring (in submit phase)

Order

Conversion Description

MO message, originator address

1 rules_orig_intor

rules_orig_nat

If the originator address is in international format, the number conversionand barring rules file used is set in rules_orig_int.If the originator address is in some other than international format, thenumber conversion and barring rules file used is set in rules_orig_nat.

2 MNP_IMSI_CONVERSION_FILE

If originator IMSI based barring for MNP is enabled, the barring rules fileused is defined in the MNP_IMSI_CONVERSION_FILE.

MO message, destination address

1 rules_dest_app_intor

rules_dest_app

In case of AT message:

If the destination address is in international format, the number conversionand barring rules file is set in rules_dest_app_int.If the destination address is in some other than international format, thenumber conversion and barring rules file is set in rules_dest_app.The result address is checked and if an application with the address isfound, the message is sent to that application.If there is no application with the address, the next conversion and barringphase starts with the original address (that is, the address before therules_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 conversionand barring rules file used is set in rules_dest_int.If the destination address is in some other than international format, thenumber conversion and barring rules file used is set in rules_dest_nat.

Table 3. AO message number conversion and barring (in submit phase)

Order


AO message, originator address

1 rules_orig_app The originator address number conversion and barring rules file is set inrules_orig_app.



Message processing

Table 3. AO message number conversion and barring (in submit phase)(cont.)

Order


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 conversionand barring rules file used is set in rules_dest_int.If the destination address is in some other than international format, thenumber 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 conversionand barring rules file is set in rules_dest_app_int.If the destination address is in some other than international format, thenumber conversion and barring rules file is set in rules_dest_app.The result address is checked and if an application with the address isfound, the message is sent to that application.If there is no application with the address, the next conversion and barringphase starts with the original address (that is, the address before therules_dest_app_int or rules_dest_app conversion).

Table 4. MT message number barring (in delivery phase)

Order


MT message

1 rules_dest_imsi If destination IMSI based barring is enabled, the barring rules file used isdefined in rules_dest_imsi.

For instructions on how to configure the number conversion and barringrules, see Number conversion and barring overview in Operating Guide(PDF).

4.3.6 CIMD2 application overload control (part 1)

CIMD2 application terminated overload control (CATOC) is a dynamiccontrol which automatically rejects and accepts messages per application.The CATOC message handling can be divided into two parts.


Message Handling

In part 1, the SMS Center checks whether the CATOC feature is enabledfor 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 overloadcontrol (part 2) in Message Handling (PDF).

4.3.7 Subscriber user groups

The subscriber user groups (SUG, licence-controlled application software)feature is for handling number of configurable attributes and rules that theSMS Center takes into account when handling messages to/fromsubscribers or applications.

From a message handling point of view, the SUG kernel plug-in process(XUG) is the first plug-in in the kernel core, thus handles the messagesfirst, that is, resolves the destination and originator groups of an incomingmessage. After this, the SMS Center uses the SUG data when furtherprocessing the message.

With SUG, it is possible to define which rules are applied to the message(according to the originator and destination address) with the deliveryattributes (DA), message redirection (MRD), lawful trace and archiving(LAWTR), incoming capacity allocation (ICA), regional barring (REBA) andcontent based filtering (CBF) features. The SUG uses the operator-provisioned SUG data to attach the SUG group ID to the message, andthen the above mentioned features uses the group ID to handle themessages accordingly.

The figure below presents the process how the SMS Center does the SUGmessage handling.



Message processing

Figure 13. SUG message handling

Description of the SUG message handling:

1. After MO/AO message is received, the SMS Center checks if theSUG feature is enabled.

If the SUG is not enabled, the message handling continues withoutSUG functionality, that is, the message continues in the messageflow.

2. The SMS Center checks if the originating and/or destination addressmatches any of the configured SUG data.

3. The SMS Center attaches found SUG group ID to the message. Ifthe originating and/or destination address was not found from theSUG data, the SMS Center sets the SUG group ID to default value 0.

4. The message continues in the message flow.

After this, if the SUG is enabled, when the message reaches any ofthe activated SUG related features (DA/MRD, LAWTR, ICA, REBAor CBF), the SMS Center uses the SUG data accordingly in thosephases.

For more information on the SUG functionality, see Subscriber user groupsfunctionality in Subscriber User Groups Guide (PDF).

MO/AO -message

2. Finding orig./dest. addr. from SUG data.

1. Is SUG enabled?

Yes

No

3. Messages SUG group ID is set.

4. Message continues in message flow.


Message Handling

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 thesubscribers are handled in the delivery phase.

The SMS Center uses the group-specific delivery attributes in combinationwith subscriber-defined message attributes, system default attributes andsome hard coded delivery attribute values to set the final delivery attributesof the message.

The operator can define different delivery attributes for each subscriberuser group. For messages to or from subscribers that do not belong to anyof the groups, the SMS Center applies the system defaults if they aredefined, otherwise hard coded values will be used.

The delivery attributes are set in the mgratrmx process, but they areapplied by all subsequent message handling processes in the SMSCenter.

Note

The mgratrmx process is a mandatory part of the SMS Center, becauseit handles the system default settings that are used also if the deliveryattributes 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 itsshort messages.

. Prepaid subscriber identification based on their MSISDNs

It is possible to specify prepaid status per any MSISDN. In earlierreleases, certain MSISDN number ranges were reserved for prepaidsubscribers, but now the prepaid information can be made perMSISDN. This supports the mobile number portability better whenchanging post-paid and pre-paid subscription types.

. Message priority levels

The operator can offer different service levels for user groups, forexample 'premium service' and 'low-cost service'.



Message processing

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 isallowed to request it.

. Service description field in charging data records.

. Message redirection (MRD) settings.

For more information on DA functionality, see Delivery attributesfunctionality 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 MTand ATshort messages in case thefirst destination is not reachable in a defined time- frame. The option for analternative destination is useful for example if a recipient has two mobileterminals but only one of them is in use, or when a backup person needs tobe reached.

For more information on MRD functionality, see Message redirectionoverview in Subscriber User Groups Guide (PDF).

4.3.10 SCTS, PMD, ICA, LIC

SCTS

In the time stamping phase, each message is time stamped. This meansthat each message gets an unique pair of service centre time stamp(SCTS) and destination address.SCTS recalculation

The SMS Center has time stamp recalculation (SCTS recalculation)mechanism to handle bursts of MO short messages toward a singledestination address in the same second. By default, this feature allows 5messages per second (set in file kernel.cf with parameterMAX_SCTS_RECALCS). Traffic exceeding this limit is rejected.

Note that if the SMS Center receives more than one SM to the samedestination for a longer period, the SCTS recalculation feature does nothelp. Instead, with features prrivilege mobile destination (PMD) anddestatination address suffxing (AT) features can be used to overcome thiskind of situation (see the sections below).


Message Handling

Privilege mobile destination (PMD)

If the traffic amounts towards an MT destination exceed the SCTSrecalculation value (previous section), the PMD (licence-controlledapplication software) feature starts handling the messages as PMDmessages. It adds 5 digit suffixes to the destination address, so that it canhandle large numbers of messages in the same second.

Each privilege mobile destination, once detected, is valid for a limitedperiod of time. The period can be configured in the SMS Center kernelconfiguration.

For more information on the privilege mobile destination, see Privilegemobile destination functionality in Privilege Mobile Destination Guide(PDF).Destination address suffixing (AT)

For popular applications, the SCTS recalculation feature alone providestoo low capacity of only 1 SM/second continuously. In such cases thedestination address suffixing (AT) feature can be used to improve this.

Destination address suffixing is performed in order to produce a uniquekey to identify each short message in the database. The key for the shortmessage consists of the destination address and service center timestamp (SCTS). The SMS Center will suffix a three-digit number to thedestination address.

Suffixing is activated by ticking the AutoSuffixing box in the ASEsubscriber edit window. The application must be defined as type 3 (send& receive) in order to activate the suffixing.



Message processing

Figure 14. Destination address suffixing

Incoming capacity allocation (ICA)

The incoming capacity allocation (ICA, licence-controlled applicationsoftware) feature is used to reserve certain submit capacity per subscriberuser group. The ICA feature gives the operator a tool for controlling whichmessages get rejected in peak-traffic situations.

The ICA consists of two modules, called ICA-A and ICA-B, which performdifferent functions. The operator can configure either one or both of themactive.

The ICA feature can be used to control the incoming message amounts inthe following ways:

. The operator can divide the licenced capacity of the SMS Centerbetween different user groups, by defining the maximum submitallocation per subscriber user group (ICA-A). The ICA rejectsmessages exceeding the allowed limit.

. The operator can define priorities per originating subscriber groupand then define a threshold per priority in the SUG capacityallocation settings (ICA-B), to control after what overall traffic ratestraffic will be rejected for each group.

The key difference between ICA-A and ICA-B is that ICA-A counts trafficrates per group, while ICA-B counts all traffic together when deciding whattraffic to reject.

SMS Center

daddr = 8888 000daddr = 8888 001

... 999

daddr = 8888 005

daddr = 8888 004

daddr = 8888 003

daddr = 8888 002

Application

daddr = 8888


Message Handling

For detailed description of online ICA functionality, see Incoming capacityallocation functionality in Subscriber User Groups Guide (PDF).Licence check (LIC)

The SMS Center software is protected by licence and a capacity licencekey is provided to operators in order to supply the purchased capacity andfeatures.

The capacity licence key contains information on purchased capacity(messages/second), and limits of using the SMS Center when purchasedcapacity is exceeding.

In addition, the capacity licence key controls of using licence-controlledapplication software, that is, the licence key contains information onpurchased 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 currentsituation of used capacity, that is, how many messages per secondthere is.

2. If the current capacity is under the purchased capacity limit, themessage is accepted.

3. If the message exceeds the purchased capacity limit, the messageis rejected and negative acknowledgement is sent to the originator.

Note that only valid and accepted messages are counted in to the usedcapacity. This means the messages that have reached to the licencechecking phase, that is, have passed the message validation and the firstphase 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 traffictypes. If needed, AO traffic limits can be configured using the CACCfeature, see more in section CIMD2 application capacity control inMessage Handling (PDF).

If there is no valid capacity key in the SMS Center, or if the key getscorrupted, 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, seeViewing capacity licence key contents in Administration Guide (PDF).



Message processing

4.3.11 Online closed user group

With the online closed user group (OCUG, licence-controlled applicationsoftware) feature it is possible to define subscriber and application groupswith privileges and restrictions (barring) in sending and receiving shortmessages. The privileges and restrictions are defined as rules whichspecify where the group members have access. There can be rulesdefined for both the incoming and the outgoing directions, since the rulescan include both originator and destination addresses.

Subscribers and applications are arranged in CUG groups according totheir MSISDN, and/or IMSI numbers, and/or protocol identifiers (PIDs).Each group includes a defined set of numbers. Operator can choose whichrouting information (MSISDN, IMSI, PID) is used in barring or in grantingaccess for messages. In addition, it is possible to set OCUG rules todifferent traffic directions; MO-MT, MO-AT and AO-MT.

For more detailed description of online CUG functionality, see Online CUGoverview in Online Closed User Group Guide (PDF).

Note

Note that the OCUG definitions are separate from the subscriber usergroup (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 visited-MSC or SGSN addresses. That is, with the REBA feature the operator canprovide SMS services so that submits only from a specific area, served bya set of visited-MSCs/SGSNs (for example "home location"), areaccepted/barred.

For detailed description of online REBA functionality, see Regional barringfunctionality in Online Closed User Group Guide (PDF).

4.3.13 In advance credit check interface

The in advance credit check (IACC, licence-controlled applicationsoftware) provides the ability to request the credit of a prepaid customerfrom a prepaid system before delivering a short message. It also providessupport for the prepaid system to do real-time charging.


Message Handling

The following steps describe the IACC mechanism shortly.

1. The SMS Center receives a short message.

2. The SMS Center finds out that the subscriber is prepaid based onthe MSISDN or IMSI number.

3. The SMS Center checks for credit in the prepaid system.

4. The prepaid system replies 'Ok' or 'NotOk' depending on whetherthere is credit on the sender's prepaid account or not.

5. Depending on the result of the IACC check, the following twoalternatives 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 orcancel to the prepaid system. The final outcome of the delivery selects ifthe reservation is committed or cancelled.

For more detailed description of IACC functionality, see In advance creditcheck overview in In Advance Credit Check Guide (PDF).

4.3.14 Content-based filtering

With the content-based filtering (CBF, licence-controlled applicationsoftware) feature it is possible to disable sending of unsuitable messagecontents 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 reachingtheir 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, protocolid or virtual SMS Center

. sending status reports

. sending notification messages if allowed to do so.

All the above mentioned functions are configurable.



Message processing

For detailed description of CBF functionality, see Content-based filteringfunctionality in Subscriber User Groups Guide (PDF).

4.3.15 Message collecting interface

With the message collecting interface (MCI, licence-controlled applicationsoftware) feature, it is possible collect or count short messages that aresent to defined destination addresses.

For the MCI configuration, operator needs to define one or moreaddresses (destination addresses from mobile subscriber point of view)and the period of time for collecting or counting the messages. Themessages sent to this/these addresses, during the defined time period, areeither counted and the result is written to a file, or the messages arecollected and stored to text files. After the file(s) have been written, anexternal collecting platform is able to fetch the file(s) via FTP for furtherprocessing.

For more detailed description of MCI functionality, see Message collectinginterface functionality in Message Collecting Interface Guide (PDF).

4.3.16 Fast-forward MT/AT

The fast-forward MT (FFMT) and fast-forward AT (FFAT) features allow theSMS Center to deliver mobile-terminated (MT) and application-terminated(AT) messages without storing them in the database (DB). Instead ofinserting the message to the DB, the SMS Center tries to deliver themessage straight to the network or to the application.

The FFMTand FFAT message handling differs slightly from each other, thefollowing sections describe both cases.

Fast-forward MT

The fast-forward MT feature (FFMT) allows the SMS Center to delivermobile-terminated (MT) messages without storing them in the database(DB). Instead of inserting the message to the DB, the SMS Center tries todeliver the message straight to the network. If the fast-forward deliveryfails, the message is stored to the DB and the SMS Center tries to send itaccording 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-forwardmessage:


Message Handling

. 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 userdata), except if the command is phase 1 status report request.

In the following the FFMT message handling is described in more detail.

Figure 15. Fast-forward MT message handling

Description of the FFMT message handling:

1. After MO or AO message is received, the SMS Center checks if theFFMT feature is enabled.

If the FFMT is not enabled, the message handling continues withoutFFMT functionality (step 5).

MO/AO-message

2. Is message MT/supported FF SM?

1. Is FFMT enabled?

Yes

No

Yes

3. Message sent to network (not stored DB)

4. Is delivery successful?

SR sent to originator.

a)

5. Message is not handled as FFMT.

No

b)



Message processing

2. The SMS Center checks if the message is mobile-terminated and if itis of supported type for FFMT.

If the message is not MT type or the message is one of the followingcases, 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 reportrequest.

3. If the message is MT type, the message is sent to the network, thatis, to the recipient.

4. After this, the SMS Center waits for the delivery report from thenetwork.a. If the delivery fails with temporary error (negative delivery

report is received), the message is inserted to the databaseand delivery is made according to retry policy. As an option,deferred delivery can be requested for every failed delivery ofFFMT message.

b. If the delivery succeeds or delivery fails with a permanenterror, the event is logged and the SM is removed from thesystem, without ever being stored in the database.

5. The SMS Center considers the message not a FFMT type ofmessage.

Depending on the delivery outcome, the request for status reports (SRs)from the originator, and the configuration of the SMS Center, the SMSCenter creates a SR when needed. The SRs are handled like FFMT forMO-MT and MO-AT SMs, and like FFAT for AO-MT SMs. This means thatalso SRs can be fast-forwarded, but will also be written to the DB if theycan't be delivered immediately.

For more information on configuring fast-forward MT, see Configuring fast-forward MT in Operating Guide (PDF).Fast-forward AT

The fast-forward AT feature (FFAT) allows the SMS Center to deliverapplication-terminated (AT) messages without storing them into thedatabase (DB). Instead of inserting the message to the DB, the SMSCenter tries to deliver the message straight to the application. If the fast-forward delivery fails, the message is stored to the DB and the SMSCenter tries to send it without fast-foward functionality.


Message Handling

The FFAT feature can be used for all AT messages. However, the followinglimitations are set:

. If the destination application is not logged in, and thus is not able toreceive messages immediately, messages are not handled as fast-forward messages.

. If the parameter delivery mode is set to 1, in the destinationapplication's user profile file the messages are not handled as fast-forward messages.

For more information on the parameter, see s2aupsamplemx.cf inConfiguration Files (PDF).

. All traffic for alias applications is routed to the parent application. Ifthe parent application is logged out, the messages to the parent andchild applications are not handled as fast-forward messages.

. The message contains replace PID request.

In the following the FFAT message handling is described in more detail.



Message processing

Figure 16. Fast-forward AT message handling

Description of the FFAT message handling:

1. After MO message is received, the SMS Center checks if the FFATfeature is enabled.

If the FFAT is not enabled, the message handling continues withoutFFAT functionality (step 5).

2. The SMS Center checks if the application is ready for receivingmessages.

If the application is not ready for FFAT message, the messagehandling continues without FFAT functionality (step 5).

3. The message is sent to the application.

MO -message

2. Is application ready to receive message?

1. Is FFAT enabled?

Yes

No

Yes

3. Message is sent to a

SMS Flow

Documents

nokia sms center

nokiasiemens networks

message processing

message handling overview

whichthe document

anonymous short message

message flow scenarios

terminating sms gateway