Dn 01197872

8/12/2019 Dn 01197872

1/69

8/12/2019 Dn 01197872

2/69

2 DN01197872

Issue 10-0

Message Handling

Id:0900d80580862d66

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 whichthe 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 DOCUMENTA-

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, 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 respectiveowners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2012/7/5. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources

of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle

this product and only after having carefully read the safety information applicable to this

product.

The safety information is provided in the Safety Information section in the Legal, Safety

and Environmental Information part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt knnen Gefahren durch Laser, Elektrizitt, Hitzeentwicklung oder

andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch

geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal,

Safety and Environmental Information dieses Dokuments oder dieses Dokumentations-

satzes.

8/12/2019 Dn 01197872

3/69

8/12/2019 Dn 01197872

4/69

4 DN01197872

Issue 10-0

Message Handling

Id:0900d80580862d66

5.1.3.18 Barring based on recipient profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.3.19 Prepaid query for sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.3.20 Autoprovisioning of postpaid and prepaid subscribers . . . . . . . . . . . . . . 43

5.1.3.21 Prepaid query for recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.3.22 Recipient-based forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.3.23 Updating MM-O in database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.3.24 Route to filtering application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3.25 Sending acknowledgement to sender. . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3.26 Traffic load management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3.27 Send notification to recipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3.28 Route MM-O to EAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 MM delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.1 Receiving request for MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.2 Processing request for MM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.2.1 Number conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2.2 Fetching MM-O from database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2.3 Verification of recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2.4 Barring based on terminal type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2.5 Prepaid query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2.6 Content adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.2.7 Routing rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.3 Delivering MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.4 MM expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.5 Legacy phone timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Delivery report processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1 Generating a delivery report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Delivery report processing in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3 Sending a delivery report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7 Read-reply report processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.1 Receiving read-reply reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2 Read-reply report processing in the kernel. . . . . . . . . . . . . . . . . . . . . . . 56

7.3 Sending read-reply reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8 Message exchange with external applications . . . . . . . . . . . . . . . . . . . . 60

8.1 Routing MMs to legacy phone support application . . . . . . . . . . . . . . . . . 60

8.1.1 Routing based on profile information . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.1.2 Routing of unfetched MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.1.3 Routing of expired MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.1.4 Routing based on content adaptation. . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2 Message exchange with Internet mail gateway . . . . . . . . . . . . . . . . . . . 64

8.2.1 Message handling from mobile terminal to mail server. . . . . . . . . . . . . . 65

8.2.2 Message handling from mail server to mobile terminal. . . . . . . . . . . . . . 66

8.3 Message exchange with inter-MMS Center . . . . . . . . . . . . . . . . . . . . . . 67

8.3.1 Inter-MMS Center message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8/12/2019 Dn 01197872

5/69

DN01197872

Issue 10-0

5

Message Handling

Id:0900d80580862d66

List of FiguresFigure 1 MMS message flow in the GPRS and WCDMA networks . . . . . . . . . . . . 9

Figure 2 MMS message flow in the CDMA2000 network. . . . . . . . . . . . . . . . . . . 10

Figure 3 Message handling subsystems in the MMS Center. . . . . . . . . . . . . . . . 11

Figure 4 MM and the multi-part structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 5 MO-MT MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 6 MO-MT with deferred delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 7 MO-MT with a filtering application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 8 MO-AT MMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 9 AO-MT MMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 10 Submitting and delivering MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 11 MM-O processing in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 12 MNP processing for sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 13 Distribution list processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 14 MNP processing for recipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Figure 15 Kernel processing after a request for an MM. . . . . . . . . . . . . . . . . . . . . 46

Figure 16 Receiving and sending delivery reports . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 17 Delivery report processing in kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 18 Receiving and sending read-reply reports . . . . . . . . . . . . . . . . . . . . . . . 56

Figure 19 Read-reply report processing in the kernel . . . . . . . . . . . . . . . . . . . . . . 57

Figure 20 Legacy phone support with subscriber database. . . . . . . . . . . . . . . . . . 61

Figure 21 Legacy phone support with unfetched MMs . . . . . . . . . . . . . . . . . . . . . 62

Figure 22 Legacy phone support with expired MMs . . . . . . . . . . . . . . . . . . . . . . . 63

Figure 23 Legacy phone support with content adaptation . . . . . . . . . . . . . . . . . . . 64

Figure 24 Message handling from a mobile terminal to the mail server. . . . . . . . . 65

Figure 25 Message handling from the mail server to a mobile terminal. . . . . . . . . 66

Figure 26 Inter-MMS Center message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8/12/2019 Dn 01197872

6/69

8/12/2019 Dn 01197872

7/69

8/12/2019 Dn 01197872

8/69

8 DN01197872

Issue 10-0

Message Handling

Id:0900d80580268a4c

About this document

Location Information from WAP Gateway Guide, DN70111059

Mobile Number Portability and Address Resolution Guide, DN0269185

Operating Guide, DN0272867

Parameter Reference Guide, DN0225812

Performance Management Interface Guide, DN02103812

Standard Transcoding Interface Guide, DN05119359

Subscriber Database Interface Guide, DN0261196

Technical Reference, DN0272988

Virtual MMS Center Guide, DN03285424

Other documents:

OMA Multimedia Messaging Service Encapsulation Protocol Version 1.2, OMA-MMS-

ENC-V1_2-20050301-A

OMA Multimedia Messaging Service Client Transactions Version 1.2, OMA-MMS-CTR-

V1_2-20050301-A

OMA Multimedia Messaging Service Conformance Document Version 1.2, OMA-MMS-

CONF-v1_2-20050301-A

8/12/2019 Dn 01197872

9/69

DN01197872

Issue 10-0

9

Message Handling Message handling overview

Id:0900d805803d9bf5

2 Message handling overviewMultimedia messaging service (MMS) message handling can be divided into two parts:

message handling in the network message handling in the MMS Center

The following sections present an overview of MMS message handling.

2.1 Message handling in the network

The MMS Center can be operating in different network environments with the requisite

IP network:

in the general packet radio service (GPRS) network

in the wideband CDMA (WCDMA) network

in the code division multiple access (CDMA) 2000 network

The following figures illustrate how the multimedia messages are handled in the different

networks:

Figure 1 MMS message flow in the GPRS and WCDMA networks

MSC/VLR/HLR

WAP/HTTPPOST

MMS

Center

MMSnotification

(overSMS)

BTS BSC/RNC

SMS

Center

IP

Air

GPRSBB

SGSN

GGSN

BTSBSC/RNC

SGSN

WAP/HTTP

GET

1

2

4

IP

GGSN

WAP/IPgatewayand PPG

3

HTTP

SMTP

e-mail

EA

MMSC

SMTP

8/12/2019 Dn 01197872

10/69

10 DN01197872

Issue 10-0

Message Handling

Id:0900d805803d9bf5

Message handling overview

Figure 2 MMS message flow in the CDMA2000 network

The bearer for the multimedia messages (MMs) can be, for example, circuit switched

data (CSD), GPRS, WCDMA or CDMA2000 provided by the cellular network. The short

message service (SMS) can be used as a bearer for the transmission of notifications,

delivery reports and read-reply reports to subscribers.

The flow of messages through the network usually begins with an MM sent from a mul-

timedia-enabled mobile terminal. There are different message flow scenarios depending

on the network. The numbers below match those given in the previous figures.

1. The MM is routed in a GPRS network via the base transceiver station (BTS) and the

base station controller (BSC), the serving GPRS support node (SGSN) and the

gateway GPRS support node (GGSN) to the GPRS backbone network. The MM is

further routed through the IP network, via the WAP/IP gateway, to the MMS Center.

In the WCDMA network, radio network controller (RNC) is used instead of the BSC.

Otherwise the message is routed through the same network elements.

In the CDMA2000 network, the message is routed via the BTS, the BSC and the

packet data serving node (PDSN) to the IP network and the MMS Center.

When MMs enter the MMS Center, the WAP/IP gateway has already added HTTP

headers to the MMs, containing, for example, the sender's identification information

(the MSISDN/MDN, and possibly also the IMSI and SGSN IP address that acts as

location information).

2. In the GPRS, WCDMA and CDMA2000 networks the MMS Center sends a notifica-

tion about a new mobile-terminated MM to the recipient's mobile terminal through

MSC/VLR/HLR

HTTPPOST

MMSCenter

MMS

notification(overSMS)

BTS BSC/PCF

SMSCenter

IP

Air

IP core networkPDSN

AAA /RADIUS

BTSBSC/PCF

PDSN

HTTPGET

1

2

3

4

IP

GGSN

WAP/IPgatewayand PPG

HTTP

SMTP

e-mail

EA

MMSC

SMTP

8/12/2019 Dn 01197872

11/69

DN01197872

Issue 10-0

11

Message Handling Message handling overview

Id:0900d805803d9bf5

the push proxy gateway (PPG). The PPG can be located in the MMS Center

(optional feature Integrated PPG) or together with the WAP gateway.

The notification sending is done over the SMS bearer and the mobile switching cen-

tre/hlr/visitor location register (msc/hlr/VLR) to the BSC/RNC and BTS.

3. In the case of a mobile-terminated MM, the recipient sends a response to the notifi-

cation or retrieves the MM. The routing is identical to the routing of an MM, described

in step 1.

4. In the case of an application-terminated MM, the MM is routed directly to an external

application after it has been received from the WAP/IP gateway (no notification is

sent).

The MM can be routed, for example, to an e-mail application, or to another opera-

tor's MMS Center through the inter-MMS Center application.

The protocols in network routing include:

wireless application protocol (WAP) for WAP gateway

In the figure, WAP/HTTP POST is used for sending the MM. WAP PUSH is used forsending a notification on top of the SMS bearer via the SMS Center. WAP/HTTP

GET is used to request the MM from the MMS Center database in those cases

where the recipient retrieves the MM.

hypertext transfer protocol (HTTP) and push access protocol (PAP) for the WAP

gateway interface (WAPGWIF) of the MMS Center

short message peer to peer protocol (SMPP) for notifications sent out by the inte-

grated PPG (optional feature)

simple mail transfer protocol (SMTP) for e-mail application

MM7 protocol for external applications

Proprietary EAIF protocol for external applications

MM4 protocol for inter-MMS Center communications

2.2 Message handling in the MMS Center

The main MMS Center subsystems involved in message handling are the following (see

also the figure):

Figure 3 Message handling subsystems in the MMS Center

MMS Centerdatabase

Kernel

Mobilesubscribers

Externalapplication

Externalapplication

Externalapplication

MMs,reports

MMs,reports

WAPGWIF EAIF

8/12/2019 Dn 01197872

12/69

12 DN01197872

Issue 10-0

Message Handling

Id:0900d805803d9bf5

Message handling overview

WAP gateway interface (WAPGWIF)

The WAP gateway interface subsystem receives MMs, MM retrieval requests, read-

reply reports and acknowledgements from mobile terminals via the WAP/IP gateway

and forwards them to the kernel subsystem for further processing.

The WAPGWIF also receives delivery reports, read-reply reports and MM notifica-

tions from the kernel and forwards them to mobile subscribers through the PPG or

directly to the SMS Center using SMPP.

External application interface (EAIF)

The EAIF subsystem receives MMs from any originating application, as well as

delivery reports and read-reply reports from the inter-MMS Center application, and

forwards them to the kernel subsystem for further processing.

The EAIF also receives MMs, delivery reports and read-reply reports from the kernel

and forwards them to external applications.

The EAIF generates delivery reports for AT messages.

Kernel

The kernel subsystem performs most of the basic processing tasks for the MMs,

delivery reports and read-reply reports.

The kernel receives MMs, MM retrieval requests and read-reply reports from the

WAPGWIF and sends MM notifications, delivery reports and read-reply reports to

the WAPGWIF. The kernel receives MMs from any external application and also

delivery reports and read-reply reports from remote MMS Centers through the EAIF.

The kernel also receives delivery reports generated by the EAIF for AT messages

and generates delivery reports for MT messages.

The kernel uses the MMS Center database for updating MMs, as well as for storing

delivery reports and read-reply reports, if necessary.

The kernel can also use the services of other MMS Center subsystems for the message

processing. It can use the mobile number portability interface (MNPIF, optional feature)

to make IMSI or domain requests to external network elements, the subscriber database

interface (SUDBIF, optional feature) to request subscriber profile information or distribu-

tion list members (optional feature) from a subscriber database, the in advance credit

check (IACC) interface (optional feature) to make IACC queries to an external prepaid

system and the multimedia message adaptation engine (MMAE) subsystem (optional

feature) and/or standard transcoding interface (STI, optional feature) to perform content

adaptation on the MM.

Note that domain requests are only possible if the ENUM interface is used, see MNP

and address resolution overview(PDF Mobile Number Portability and Address Resolu-

tion Guide).

For more detailed information on how MMs, delivery reports and read-reply reports are

processed in the MMS Center, see Multimedia message processing(PDF Message

Handling).

For information on the MMS Center subsystems, see MMS Center subsystems

overview(PDFArchitecture).
http://dn0269185.pdf/http://dn0269185.pdf/http://6xarchitecture.pdf/http://6xarchitecture.pdf/http://6xarchitecture.pdf/http://6xarchitecture.pdf/http://dn0269185.pdf/http://dn0269185.pdf/

8/12/2019 Dn 01197872

13/69

DN01197872

Issue 10-0

13

Message Handling Message types and storage

Id:0900d80580350685

3 Message types and storageThe MMS Center handles the processing and storage of the different message types

involved in multimedia messaging:

The MMS Center receives multimedia messages (MMs) from MM senders, pro-

cesses the MMs, and delivers them to the MM recipients.

The MMS Center generates delivery reports, processes them and delivers them to

the MM senders.

The MMS Center receives read-reply reports from MM recipients, processes them

and delivers them to the MM senders.

The MMS Center can also send and receive MMs, delivery reports and read-reply

reports via inter-MMS Center connections.

In the MMS Center, MMs, delivery reports and read-reply reports are processed as indi-

vidual message types. This means that, for example, in configuration parameters and

database fields, the terms 'sender' and 'recipient' refer to the sender and recipient of that

particular message type, and not to the original MM sender or recipient.

The process of transferring the MM from the sender to the recipient involves several

types of protocol data units (PDUs). For detailed information on the PDUs, see OMA

specification Multimedia Messaging Service Encapsulation Protocol Version 1.2.

3.1 Multimedia messages

The MM consists of MMS headers and a message body.

The MMS headers contain MMS-specific information on how to transfer the MM from

the sender's terminal to the recipient's terminal. The message body may contain different types of content, for example, text, image,

or audio.

The MM can contain a presentation part that is used in the multi-part structure. The

presentation part contains instructions on how the multimedia content should be

rendered to the display and speakers of the mobile terminal. Examples of presenta-

tion techniques are Synchronized Multimedia Integration Language (SMIL) and

Wireless Markup Language (WML).

If there are no presentation instructions, the handling of the MM follows the instruc-

tions embedded in the mobile terminal itself. The following figure illustrates the

headers and the multi-part field.

8/12/2019 Dn 01197872

14/69

14 DN01197872

Issue 10-0

Message Handling

Id:0900d80580350685

Message types and storage

Figure 4 MM and the multi-part structure

The MMS Center wraps the MM into a multimedia message object (MM-O). The MM-Ois used in internal processing and stored into the database. The MM-O encapsulates the

actual MM and contains information about the MM to facilitate processing.

For information on the MMS header specifications, see the OMA specification Multime-

dia Messaging Service Encapsulation Protocol Version 1.2.

Information on the MM-O fields can also be found in Multimedia message table (mmo)

(PDF Technical Reference).

3.2 Delivery reports

The MMS Center can generate and send a delivery report to the MM sender to inform

about the MM delivery status. The delivery report can indicate, for example, that the MM

was delivered to the recipient, that the recipient rejected the MM, or that non-delivery

occurred for some other reason. In case the MM was sent to multiple recipients, a

separate delivery report is sent per recipient.

Delivery reports are sent if they are requested by the sender, and if sending them is

allowed in the recipient's mobile terminal settings and in the MMS Center configuration.

The operator can deny sending delivery reports for mobile- and application-originated

messages even if they are requested by the sender, or allow sending them even if they

are denied by the recipient.

When the MM is sent via an inter-MMS Center, the originating MMS Center can be con-

figured to request for a delivery report, even if the sender does not request for one.

These delivery reports will not be sent to the MM sender.

MMS headers

Presentationinstructions

image/jpeg

application/smil

This is a

message...text/plain

audio/amr

Content

WAP/HTTP Multipart
http://dn0272988.pdf/http://dn0272988.pdf/

8/12/2019 Dn 01197872

15/69

DN01197872

Issue 10-0

15

Message Handling Message types and storage

Id:0900d80580350685

The information about whether or not a delivery report is requested can come from the

MM sender's mobile terminal (through the WAPGWIF), or from the inter-MMS Center

application or some other originating application (through the EAIF). The delivery

reports are also sent via the WAPGWIF, the EAIF or via the inter-MMS Center connec-

tions (through the EAIF).

3.3 Read-reply reports

The MM recipient's mobile terminal can send a read-reply report to the MM sender to

inform that the recipient has either read the MM or deleted it without reading. In the case

of multiple recipients, a separate read-reply report is sent per recipient.

Read-reply reports are sent if they are requested by the sender, and if sending them is

allowed in the recipient's mobile terminal settings and the MMS Center configuration.

The operator can deny sending read-reply reports for mobile- and application-originated

messages even if they are requested by the sender.

The information about whether or not a read-reply report is requested can come from

the MM sender's mobile terminal (through the WAPGWIF), or from the inter-MMS

Center or some other originating application (through the EAIF). The read-reply reports

are sent through the WAPGWIF, the EAIF or via the inter-MMS Center connections

(through the EAIF).

3.4 MMS Center message storage

The following message-related information is stored in the MMS Center database:

multimedia messages (MMs) and multimedia message objects (MM-Os)

unsent notifications, delivery reports and read-reply reports delivery reports and read-reply reports routed to EAIF

Unsent messages can occur when message sending fails to the push proxy gateway

(PPG) or to the SMS Center (in case the optional feature integrated PPG is used).

When the MM is destined to multiple recipients, the MM in the database is shared

between the recipients, but each recipient has an own MM-O stored in the database.

The operator can define the maximum storage time for MMs. If MMs are not retrieved

within the configured expiration time interval, they can be removed from the database.

When MMs expire, the MMS Center can send a delivery report to the MM sender, indi-

cating that non-delivery occurred. Expired MMs can also be configured to be routed to

the legacy phone support application.

External applications can also define a validity period for their messages. If the external

application sends a validity period, it overrides the MMS Center's default validity period

setting. Expired MMs can be removed from the database.

All MMS notifications, delivery reports and read-reply reports expire and are deleted

according to the validity period.

For information about database tables, database scriptsand events logged in the data-

base, see PDF Technical Reference.
http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/http://dn0272988.pdf/

8/12/2019 Dn 01197872

16/69

16 DN01197872

Issue 10-0

Message Handling

Id:0900d80580350685


3.5 Protocol data units

Different protocol data units (PDUs) are used at the different stages in the MM handling

process:

submitting the MM

sending a notification to the recipient about a new MM

retrieving the MM from the MMS Center

acknowledging the MM delivery

sending a delivery report to the MM sender (if requested)

sending a read-reply report to the MM sender (if requested)

The PDUs are described in the following table. For further information on the PDUs, see

OMA specification Multimedia Messaging Service Encapsulation Protocol Version 1.2.

PDU type Description

M-Send.req An MM sent to the MMS Center by the sender's mobile terminal or an

external application that uses the EAIF protocol.

M-Send.conf The MMS Center sends this acknowledgement to the MM sender's

mobile terminal (after receiving the M-Send.req).

The acknowledgement indicates the status of the operation, for

example, Message Validation failed, User barred, or Message

accepted.

The operator can configure the texts used in the M-Send.conf

response to the mobile terminal. The default texts are in English.

M-Notification.ind A notification sent by the MMS Center to the MM recipient's mobile ter-

minal, indicating that an MM is waiting.

The notification contains information about the contents of the MM(URI, size, expiry time).

WSP/HTTP GET The MM recipient retrieves the MM with a WSP/HTTP GET request

(the MMS Center receives it as an HTTP request from the WAP/IP

gateway).

The MM can be retrieved either immediately after receiving the M-

Notification.ind, or using deferred delivery (in which case an M-Noti-

fyResp.ind is sent instead of making a WSP/HTTP GET request.

M-Retrieve.conf The retrieved MM or an error message sent by the MMS Center to the

MM recipient.

M-NotifyResp.ind The PDU is used in either one of the following cases:

In the case of immediate MM retrieval, this is the acknowledge-ment of MM delivery (a response to the M-Retrieve.conf), sent by

the MM recipient's mobile terminal.

(In the case of deferred retrieval, the M-Acknowledge.ind is used

as an acknowledgement instead of the M-NotifyResp.ind.)

In the case of deferred delivery or MM rejection, this is the MMrecipient's acknowledgement to the notification received from the

MMS Center (M-Notification.ind). The acknowledgement also

specifies the action to be taken (deferring, rejection).

(If the MM recipient retrieves the MM immediately after receiving the

notification, a WSP/HTTP GET request is used instead of the M-Noti-

fyResp.ind.)

Table 1 PDU types

8/12/2019 Dn 01197872

17/69

8/12/2019 Dn 01197872

18/69

18 DN01197872

Issue 10-0

Message Handling

Id:0900d80580350685


The inter-MMS Center transmitter by default requests a .RES PDU as an acknowledge-

ment for .REQ PDUs sent over the MM4 reference point. The acknowledgement

requests can be disabled in the inter-MMS Center configuration.

MM4_Read_reply_report.REQ A read-reply report routed by the terminating MMS Center to the orig-

inating MMS Center.

The read-reply report contains MMS control information only.

MM4_Read_reply_report.RES The response to the MM4_Read_reply_report.REQ from the originat-

ing MMS Center.

The response indicates the status of the

MM4_Read_reply_report.REQ request (if the sending the status was

requested).

PDU types Description

Table 2 MM4 PDU types (Cont.)

8/12/2019 Dn 01197872

19/69

DN01197872

Issue 10-0

19

Message Handling Message flow scenarios

Id:0900d80580290d7e

4 Message flow scenariosThe MMS Center handles messages for the following kinds of traffic:

mobile-originated (MO) mobile-terminated (MT)

application-originated (AO)

application-terminated (AT)

In a typical scenario, the multimedia message (MM) is sent from one mobile subscriber

to another (MO-MT). The MMS Center also handles MMs that are received from mobile

subscribers and destined to external applications (MO-AT), MMs received from external

applications and destined to mobile subscribers (AO-MT), and MMs received from

external applications and destined to other external applications (AO-AT).

The MMS Center exchanges messages with other operators' MMS Centers through the

inter-MMS Center application. When the MMS Center receives MMs from other opera-

tors networks and sends them to mobile subscribers in the operators own network, the

MMS Center sees this as AO-MT message processing.

Similarly, when the MMS Center receives MMs from mobile subscribers in the operator's

own network and sends them to other operator's MMS Centers, the MMS Center sees

this as MO-AT message processing. For further information, see Message exchange

with inter-MMS Center(PDF Message Handling).

The operator can configure that MMs are routed to a filtering application to be processed

before they are sent to the recipients. This does not, however, imply that the message

is AT, as that is determined by what the MMS Center sees as the final recipient of the

message, either a mobile terminal or an external application.

4.1 Mobile-originated messages

Mobile-originated (MO) MMs originate from a mobile terminal. When an MO MM is sub-

mitted to the MMS Center, the MMS Center checks whether it can handle the message.

This check includes, for example, message validity and congestion in the MMS Center.

If any one of these checks fails, the MMS Center informs the sender that the message

could not be handled. Likewise, if there is no failure with the system checks and the MM

handling, an acknowledgement is sent to the sender.

4.1.1 Mobile-originated - mobile-terminated MMs

For an MO-MT MM, the following figure shows the basic scenario where the sender and

the recipient are served by the same MMS Center. The MMS Center sends and receives

messages through the WAPGWIF.

8/12/2019 Dn 01197872

20/69

20 DN01197872

Issue 10-0

Message Handling

Id:0900d80580290d7e

Message flow scenarios

Figure 5 MO-MT MMs

The scenario has the following stages:

1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF

subsystem wraps the MM into an MM-O (a format used in internal processing), and

forwards the MM-O to the kernel.

2. The MMS Center stores the MM-O in the database.

When the MM is destined to multiple recipients, the kernel stores an own MM-O for

each recipient in the database. Each MM-O contains a reference to the MM, which

is stored in the database only once and is shared between the recipients.

3. The MMS Center sends an acknowledgement (PDU M-Send.conf) to the sender,indicating that the MM has been accepted for delivery.

4. The MMS Center sends a notification (PDU M-Notification.ind) to the recipient(s)

about a new MM.

5. The recipient replies to the notification either by requesting the MM immediately

(PDU WSP/HTTP GET), or by indicating deferred delivery (PDU M-NotifyResp.ind).

See Mobile-originated - mobile-terminated MMs with deferred delivery(PDF

Message Handling).

6. Assuming that the recipient requested the MM immediately, the MM is retrieved from

the MMS Center database and delivered to the recipient (PDU M-Retrieve.conf).

7. The recipient acknowledges the MM delivery (PDU M-NotifyResp.ind).

8. The MMS Center generates and sends a delivery report (PDU M-Delivery.ind) to thesender of the MM (if requested by the sender, and allowed by the recipient and the

MMS Center configuration).

9. The recipient sends a read-reply report (PDU M_Read_Rec.ind) to the MMS Center

(if requested by the sender, and allowed in the recipient's mobile terminal settings

and the MMS Center configuration).

10. The MMS Center forwards the read-reply report (PDU M_Read_Orig.ind) to the

sender of the MM.

Note that when the sender and the recipient belong to different MMS Centers that are

owned by different operators, the message routing is different. For further information,

see Message exchange with inter-MMS Center(PDF Message Handling).

5

6

7

8

MMS Center

database

WAPGWIF Kernel EAIF

1

23

4

9

10

8/12/2019 Dn 01197872

21/69

8/12/2019 Dn 01197872

22/69

22 DN01197872

Issue 10-0

Message Handling

Id:0900d80580290d7e



sender of the MM.

4.1.3 Mobile-originated - mobile-terminated MMs with filtering applicationIn some cases of processing an MO-MT message, an external (filtering) application is

used to process the MM before it is delivered to the recipient(s). For example, delivering

the MM may require adding an advertisement to it. The MMS Center sends and receives

messages through the WAPGWIF, but uses the EAIF to route the MM to the filtering

application and back.

The scenario is illustrated in the following figure.

Figure 7 MO-MT with a filtering application

This scenario is much the same as the one for processing an MO-MT MM, the only dif-

ference is that the MM is processed by a filtering application before it is delivered to the

recipient.






each recipient in the database. Each MM-O contains a reference to the MM, whichis stored in the database only once and is shared between the recipients.

3. The MMS Center sends an acknowledgement (PDU M-Send.conf) to the sender,

indicating that the MM has been accepted for delivery.

4. The MMS Center sends the MM to the external application through the EAIF. The

external application (EA) processes the MM according to its configuration.

5. After processing the MM, the external application returns it to the EAIF, which

updates the MM in the database and sends it to the kernel.

Note that the dotted lines in the figure indicate a possibility of another filtering appli-

cation being used to process the MM before the EAIF sends the MM back to the

kernel.

6. The MMS Center sends a notification (PDU M-Notification.ind) to the recipient(s)about a new MM.

6

7

10

MMS Center

database

WAPGWIF Kernel EAIF

1

23

4External

application

Externalapplication

5

8

9

12

11

8/12/2019 Dn 01197872

23/69

DN01197872

Issue 10-0

23


Id:0900d80580290d7e

7. The recipient replies to the notification by either requesting the MM immediately

(PDU WSP/HTTP GET), or indicating deferred delivery (PDU M-NotifyResp.ind).


the MMS Center database and delivered to the recipient (PDU M-Retrieve.conf).9. The recipient acknowledges the MM delivery (PDU M-NotifyResp.ind).

10. The MMS Center generates and sends a delivery report (PDU M-Delivery.ind) to the

sender of the MM (if requested by the sender, and allowed by the recipient and the

MMS Center configuration).


(if requested by the sender, and allowed in the recipient's mobile terminal settings

and the MMS Center configuration).


sender of the MM.

4.1.4 Mobile-originated - application-terminated MMs

When processing MO-AT messages, the MMS Center receives the MM from a mobile

terminal through the WAPGWIF and routes it to an external application through the

EAIF.

The following figure shows a scenario where the mobile subscriber sends an MM that is

destined to an external application rather than to another mobile terminal.

Figure 8 MO-AT MMs








3. The MMS Center sends an acknowledgement (PDU M-Send.conf) to the sender,

indicating that the MM has been accepted for delivery.

4. The kernel routes the MM to the EAIF, which sends it to the external application.

6

MMS Centerdatabase

WAPGWIF Kernel EAIF

1

23

4External

application

5

8/12/2019 Dn 01197872

24/69

24 DN01197872

Issue 10-0

Message Handling

Id:0900d80580290d7e


5. The EAIF generates a delivery report (PDU M-Delivery.ind, if requested) and sends

it to the kernel.

6. The MMS Center sends the delivery report to the sender of the MM if it is allowed in

the MMS Center configuration.

4.2 Application-originated MMs

When processing AO-MT MMs, the MMS Center receives the MMs from external appli-

cations through the EAIF and routes them to a mobile terminal through the WAPGWIF.

The following figure describes a scenario where the MM originates from an external

application and is destined to a mobile terminal.

Figure 9 AO-MT MMs

1. An external application submits an MM to the MMS Center. The EAIF subsystem

wraps the MM into an MM-O (a format used in internal processing), and forwards the

MM-O to the kernel.





3. The kernel acknowledges receiving the MM, and the EAIF sends the acknowledge-

ment to the external application.

4. The MMS Center sends a notification (PDU M-Notification.ind) to the recipient(s)

about a new MM.

5. The recipient replies to the notification by either requesting the MM immediately

(PDU WSP/HTTP GET), or indicating deferred delivery (PDU M-NotifyResp.ind).


the MMS Center database and delivered to the recipient (PDU M-Retrieve.conf).

7. The recipient acknowledges the MM delivery (PDU M-NotifyResp.ind).

8. The MMS Center generates and sends a delivery report to the external application,

if it was requested and if it is allowed in the MMS Center configuration.


(if requested by the sender, and allowed in the recipient's mobile terminal settingsand the MMS Center configuration).

4

5

WAPGWIF Kernel EAIF

2

1

Externalapplication

3

6

7

8

9

10

MMS Center

database

8/12/2019 Dn 01197872

25/69

DN01197872

Issue 10-0

25


Id:0900d80580290d7e


originating application.

8/12/2019 Dn 01197872

26/69

8/12/2019 Dn 01197872

27/69

DN01197872

Issue 10-0

27

Message Handling Multimedia message processing

Id:0900d8058041dd4a

5.1.1 Receiving new mobile-originated MM

When the WAPGWIF receives an MM from the WAP/IP gateway, it processes the MM

as follows:

The WAPGWIF validates the MM by checking, for example, that the MSISDN/MDN

information in the headers and the MM are in a correct format. If allowed by the con-

figuration, it may also check if the sender IMSI and/or SGSN address are included

in the MM headers and validate them.

The WAPGWIF checks that the allowed message size and allowed number of recip-

ients are not exceeded.

The WAPGWIF checks whether it is overloaded and if so, it rejects the message.

The WAPGWIF wraps the MM into an MM-O and generates a message ID. It also

adds the sender and recipient address (and possibly the sender IMSI and SGSN

address) to the MM-O. The WAP/IP gateway resolves the sender's identification

reliably from the network and provides this information to the MMS Center in the

HTTP headers.

If the MM is a reply to an AO MM, and the recipient of the AO MM was a distribution

list, and, if it has been enabled in the configuration, the WAPGWIF converts the

incoming MM's recipient from an alias address to the actual application address.

If the MM headers contain a request for address hiding, the WAPGWIF includes this

request in the MM-O.

The actual address hiding is not done until the MM is being sent to the recipient by

either the WAPGWIF or the EAIF.

If the MM headers contain requests for delivery reports, the WAPGWIF adds this

information to the MM-O. The kernel and the EAIF use this information later when

determining whether or not delivery reports are sent to the MM sender.

If the MM headers contain requests for read-reply reports, the WAPGWIF adds infor-mation in the MM-O on whether the read-reply report is disabled or enabled. If the

read-reply report is enabled, the receiving mobile terminal sends a read-reply report

to the kernel when the recipient has received and opened the MM.

For information, see Delivery report processingand Read-reply report processing

(PDF Message Handling).

Having processed the MM, the WAPGWIF forwards it to the kernel.

For information on configuring the WAPGWIF, see WAP gateway interface configura-

tions overview(PDF Operating Guide).

5.1.2 Receiving new application-originated MMWhen the EAIF receives an MM from an external application, it processes the MM as

follows:

The EAIF checks whether any connection-related restrictions apply, for example,

that the application-specific server capacity limitation is exceeded and that the

external application is not barred from sending messages through the MMS Center.

The EAIF validates the MM by checking, for example, that the sender and recipient

addresses and the MM are in a correct format, and that the external application is

allowed to send the type of information included in the MM headers. The EAIF can

also decrypt the recipient address. For further information on address encryption
http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/

8/12/2019 Dn 01197872

28/69

28 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a

Multimedia message processing

and decryption, seeAddress encryption with EAIF protocol(PDF External Applica-

tions Developer's Guide).

The order of the first two bullets is different when the MM7 protocol is used. Because

the MM7 receiver process serves several applications and the application ID can be

determined only after message validation, the message has to be validated before

any application-specific parameters can be checked.

When the EAIF protocol is used, each application has its own interface process, and

therefore some application-specific parameters can be checked before validating

the message.

The EAIF checks that the allowed message size and allowed number of recipients

are not exceeded.

The EAIF wraps the MM into an MM-O and generates a message ID.

During the processing, the EAIF adds information to the MM-O to be used in further

processing. The information can be either defined in the application interface con-

figuration (for example, restrictions of profile queries or routing to applications) or

received in the message headers from the external application (for example, a

restriction of content adaptation or validity period).

The EAIF checks if the MM headers contain a request for address hiding. Depending

on the configuration, the EAIF can enable or disable the address hiding request

(written in the MM-O) and continue the processing, or reject the MM.

The actual address hiding is not done until the MM is being sent to the recipient by

either the WAPGWIF or the EAIF.

The EAIF checks if the MM headers contain requests for delivery reports. If such

requests are found, and if the EAIF configuration allows the external application to

receive delivery reports, the EAIF adds this information to the MM-O. The kernel and

the EAIF use the information later when determining whether or not delivery reports

are sent to the application.If the MM headers contain requests for read-reply reports, the EAIF adds information

in the MM-O on whether the read-reply report is disabled or enabled. If the read-

reply report is enabled, the receiving mobile terminal sends a read-reply report to the

kernel when the recipient has received and opened the MM.

For information, see Delivery report processingand Read-reply report processing

(PDF Message Handling).

The EAIF configuration may also specify that even if the recipient denies sending a

delivery report, the denial is overridden. This information is also added to the MM-O

for later kernel processing.

The EAIF adds application-specific charging information to the MM-O (if the config-

uration allows adding the information and the information to be added is available). The EAIF performs number conversion on the sender and recipient addresses

based on configurable EAIF number conversion lists, and then checks the converted

addresses against the EAIF's barring lists to see if the sender or the recipient is

barred. Barring can also be based on the MMS Center load level. For more informa-

tion and configuration instructions, see Configuring PMDS for load monitoring(PDF

Performance Management Interface Guide).

Note that the converted numbers are only used by the EAIF, and not conveyed to

the kernel in the MM-O. The kernel does its own number conversion when it pro-

cesses the MM-O.

Having processed the MM, the EAIF forwards it to the kernel.

For information on configuring the EAIF, see EAIF-related configurations overview(PDFEAIF and External Applications Configuration Guide).
http://dn0284937.pdf/http://dn02103812.pdf/http://dn0267915.pdf/http://dn0267915.pdf/http://dn02103812.pdf/http://dn0284937.pdf/

8/12/2019 Dn 01197872

29/69

DN01197872

Issue 10-0

29


Id:0900d8058041dd4a

5.1.3 MM-O processing in the kernel

The kernel processes the MM-O and determines whether the MM is accepted for

delivery or rejected. The following figure illustrates the phases in MM-O processing in

the order they are gone through in the kernel.

The licence checking is not in the scope of the following figure. The licence key defines

the available capacity of the MMS Center as well as which optional features can be

used.

The grey boxes indicate processing phases after which the kernel may either reject the

MM (and send an error message to the MM sender via the WAPGWIF, indicating

message rejection) or continue with processing to the next phase.

For information about the error message texts, see Error messages to mobile terminals

(PDF Technical Reference). The error message texts are configurable in the MM1 /

Gwrmanmxfragment (see Gwrmanmx, PDF Parameter Reference).

Routing rules based on IMSI/domain

MT AT

Copies for multiple recipients to memory

Profile query for sender (optional)

Barring based on sender profile (optional)

Number conversion for sender and recipient

Delayed delivery time validation

Address hiding validation

Location information from WAP/IPgateway (optional)

Barring based on terminal type

Routing rules based on MSISDN/MDN

Temporary number conversion for MM-Orecipient (multiple-recipient case)

Overload control

Applying MNP and address resolution

(optional) for sender

Distribution list processing (optional)

Applying MNP and address resolution(optional) for recipient

Expiration time validation
http://dn0272988.pdf/http://new_parameter_reference.pdf/http://new_parameter_reference.pdf/http://dn0272988.pdf/

8/12/2019 Dn 01197872

30/69

30 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


Figure 11 MM-O processing in the kernel

5.1.3.1 Number conversion for sender and recipient

The kernel can perform number conversion for both the sender and recipient

MSISDN/MDN numbers in the MM.

The MSISDN/MDN number is converted from a national format to the international

format, for example, the MSISDN/MDN 0707778888 can be converted to

+358707778888.

Number conversion is usually performed at the beginning of MM-O processing in the

kernel. However, if the MM is destined to multiple recipients, number conversion for the

recipients of the MM-O is done at a later stage when copying an MM-O for each recipient

to the database.

For further information, seeAbout number conversion(PDF Operating Guide).

5.1.3.2 Delayed delivery time validation

The kernel checks if the incoming MM contains an indication of the earliest time when

the MM should be delivered (that is, when a notification of the MM should be sent to the

MM recipient). The MMS Center operator can define a maximum value for the delayed

delivery time. If the MM sender requests a longer delayed delivery time than what is

allowed by this maximum value, the kernel either accepts the message and ignores the

request for the delayed delivery time in the MM or rejects the message, depending on

the configurations made by the operator.

If delayed delivery time was indicated in the MM (and did not exceed the definedmaximum value), the kernel continues MM-O processing up until making a prepaid

MT

AT

Legacy phonesupport

Route MM-O to EAIF

Prepaid query for sender (optional)

Store MM-O to database

Autoprovisioning of postpaid andprepaid subscribers

Send acknowledgement to sender

Traffic load management (optional)

Barring based on recipient profile (optional)

Prepaid query for sender (optional)

Autoprovisioning of postpaid andprepaid subscribers

Prepaid query forrecipient (optional)


Route to filtering application

Traffic load management (optional)


Send notification to recipient

Recipient-based forwarding

Profile query for recipient(optional)

Message rejection possible at this stage.

Message processing continues to next stage.

8/12/2019 Dn 01197872

31/69

DN01197872

Issue 10-0

31


Id:0900d8058041dd4a

query for the recipient. After making the query, the kernel saves the MM-O (and possibly

copies of it for multiple recipients) in the database with the status 'delayed', indicating

the delayed delivery time.

By default, the kernel retransmitter polls the MM-Os with the status 'delayed' everyminute. When the delayed delivery time has been reached, the kernel continues pro-

cessing by either making a profile query for the recipient (with an MT message) or by

routing the MM to the EAIF (with an AT message).

Handling delayed delivery time is always done by the sender's MMS Center. This means

that in inter-MMS Center cases, the MM is sent to the recipient's MMS Center (via the

inter-MMS Center) at the time indicated by the delayed delivery time.

In case of delayed delivery, the message expiration time starts counting from the desired

delivery time.

For information on the configurations related to MMs with a delayed delivery time, see

Configuring the handling of MMs with a delayed delivery timeand Configuring the

handling of MMs that have a delayed delivery time later than the maximum desired

delivery time(PDF Operating Guide).

5.1.3.3 Expiration time validation

The MMS Center kernel sets expiration timestamps for MM-Os and DRs. These time-

stamps are calculated based on the following:

the requested expiration time set in the MM-O (optional)

the desired delivery time set in the MM-O (optional)

operator specified maximum allowed expiration time set in the kernel configuration

If no expiration time is present in the arriving MM-O, the default expiration time fromkernel configuration is used. If the message has a desired delivery time set, the expira-

tion time is calculated to start from that instead of the received timestamp. As a last step,

the calculated expiration time is compared against the maximum allowed expiration time

and is truncated if needed. In case of delivery reports the expiration timestamp calcula-

tions are based on the message delivery timestamp instead of the message received

timestamp.

Before a notification is generated for a message, the kernel checks the current time

against the expiration time set in the message. If the current time is past the expiration

time, no notification is sent and the message is deleted from the system.

5.1.3.4 Applying MNP and address resolution for senderThe kernel uses the mobile number portability (MNP) interface to apply MNP and

address resolution for subscribers, as well as to check the barring lists. The processing

is done separately for the sender and recipient as follows:

If the message is mobile-originated (MO), the processing is done to the sender.

If the message is mobile-terminated (MT), the processing is done to the recipient.

If the message is application-originated (AO), the processing is not done to the

sender.

If the message is application-terminated (AT), the processing is done to the recipient

only if the recipient address is an MSISDN/MDN (and not, for example, an e-mail

address or the external application's short number).
http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/

8/12/2019 Dn 01197872

32/69

32 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


The kernel's MNP interface uses plugins (MAP/SIGTRAN, MAP/SS7, XML or ENUM

interface plugin) to make MNP requests to external servers (optional feature). With the

MNP requests, the IMSI or domain (and possibly location information) can be obtained

for the sender and recipient. The IMSI and domain information can then be used for

barring purposes, as well as for routing messages to external applications. For more

information on the optional feature, see MNP and address resolution overview(PDF

Mobile Number Portability and Address Resolution Guide.

Whether or not MNP requests are made depends on the kernel's MNP configuration and

on whether the IMSI and sender's SGSN address have been received from the WAP

gateway. With AO messages, the EAIF can also provide the kernel with information that

making an MNP request for the recipient is denied, in which case no MNP request is

made even if allowed in the kernel configuration. The information is specified either in

the EAIF (per application) or in the inter-MMS Center configuration (per each remote

MMS Center).

The MNP interface can be configured not to make an MNP request for the sender usingthe MAP/SIGTRAN, MAP/SS7 or XML interface plugin, if the sender's IMSI or SGSN

address was received from the WAP/IP gateway in the message headers. If the ENUM

interface plugin is in use, it is possible to make an MNP request to obtain the sender's

domain even if the sender's IMSI was provided by the WAP/IP gateway.

In addition to making the MNP requests, the kernel's MNP interface is responsible for

the following functions which are all part of the MMS Center basic package:

checking the configurable lists of exported and imported numbers (as an option to

the MNP requests).

The entries on the lists act as exceptions to the MSISDN/MDN-based white- and

blacklists. For further information about how the lists are used and configured, see

Mobile number portability with imported and exported numbers lists(PDF OperatingGuide).

mapping the subscriber's MSISDN/MDN or IMSI to a domain name based on con-

figurable lists (as an option to obtaining the domain with MNP requests)

For further information about how the lists are configured, see Configuring domain

mapping lists(PDF Operating Guide).

checking the configurable MSISDN/MDN, IMSI and domain barring lists

For further information about how the lists are configured, seeAbout barring(PDF

Operating Guide).

Using the previous lists depends on whether or not the operator has configured the lists

(and in the case of barring and domain mapping lists, enabled them in the kernel as

well).

Barring lists may be dependable on the MMS Center load level. For more information,

see see Configuring PMDS for load monitoring(PDF Performance Management Inter-

face Guide).

Whenever the MNP interface is able to obtain the subscriber's IMSI or domain (and

possibly location information), it provides the kernel with the information to be used in

further message processing. If the MNP request fails, the MNP configuration determines

if the message is rejected or if message processing continues in the kernel. If the

message is barred by any of the barring lists (MSISDN, IMSI or domain), it is rejected.

The MNP interface sends an error response to the kernel if the message was rejected

during the MNP processing.
http://dn0269185.pdf/http://dn0272867.pdf/http://x%3Dd%3Do%3Dc/s-000006.pdfhttp://x%3Dd%3Do%3Dc/s-000006.pdfhttp://dn0272867.pdf/http://dn02103812.pdf/http://dn02103812.pdf/http://dn0272867.pdf/http://x%3Dd%3Do%3Dc/s-000006.pdfhttp://x%3Dd%3Do%3Dc/s-000006.pdfhttp://dn0272867.pdf/http://dn0269185.pdf/

8/12/2019 Dn 01197872

33/69

DN01197872

Issue 10-0

33


Id:0900d8058041dd4a

MNP, address resolution and barring for sender

The following figure and procedure illustrate how processing is done for the sender.

This is an example that applies to processing a mobile-originated message.

Figure 12 MNP processing for sender

1. The MNP interface checks the sender's MSISDN/MDN against the MSISDN/MDN-

based white- and blacklists to find out if the sender is barred.

The MNP interface can also check the sender's MSISDN/MDN against the entries

on the exported and imported numbers lists, which act as exceptions to the

MSISDN/MDN-based white- and blacklists.

If the sender's MSISDN/MDN is found on the exported numbers list, the sender

is barred from sending messages.

If the sender's MSISDN/MDN is found on the imported numbers list, the sender

is allowed to send messages, unless the number is found on the MSISDN/MDN-

based blacklist.

If the sender is barred, the message is rejected. If the sender is not barred, routing

proceeds to the next step.

2. The MNP interface checks if the WAP/IP gateway provided the sender's IMSI.

If the IMSI is already available, the MNP configuration determines whether an MNP

request should be done or not (that is, if routing proceeds to the next step or to step

5a).

If the IMSI is not available, routing proceeds to the next step.

3. The MNP interface checks which MNP interface plugin to use for making an MNP

request for the sender. Based on the MNP configuration, this can be determined in

two ways:

MNP processing starts for sender

Message rejected Process message further

Plugin found

1. MO MSISDN/MDN barring

No

Barred

Not barred

Request failed

3. Check which plugin to use

2. Check if IMSI is available

5a. IMSI to domain mapping 5b. MSISDN/MDN to domain mapping

Not barred

Not barred

IMSI received

Barred

Barred

Requestfailed

Yes

No plugin found

Domainreceived

4. Request IMSI/domain

7. MO domain barring

6. MO IMSI barring

8/12/2019 Dn 01197872

34/69

34 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


The MNP configuration can specify a default plugin which is used for making all

MNP requests.

The list of MNP countries can specify which plugin is used to make MNP

requests for which country.If no suitable plugin is found, routing proceeds to step 5b. If a suitable plugin is

found, routing proceeds to the next step.

4. The MNP interface makes an MNP request: an IMSI request to the hlr or an MNP

server, or a domain request to an ENUM server.

If the MNP request fails, the MNP configuration determines if the message is

rejected or if routing proceeds to the next procedure (MSISDN-based barring is

checked for the recipient).

If the request is successful, routing proceeds as follows:

If the sender's domain was received, routing proceeds to step 7.

If the sender's IMSI was received, routing proceeds to the next step.

5. The MNP interface does one of the following:a) The sender's IMSI is mapped to a domain based on the IMSI to domain mapping

file. After the mapping, routing proceeds to step 6.

b) The sender's MSISDN/MDN is mapped to a domain based on the MSISDN/MDN

to domain mapping file. After the mapping, routing proceeds to step 6.

6. The MNP interface checks the sender's IMSI against the IMSI-based white- and

blacklists to find out if the sender is barred.

If the sender is barred, the message is rejected. If the sender is not barred, routing

proceeds to the next step.

7. The MNP interface checks the sender's domain against the domain-based white-

and blacklists to find out if the sender is barred.

If the sender is barred, the message is rejected. If the sender is not barred, thekernel continues with the message processing.

5.1.3.5 Location information from WAP/IP gateway (optional)

The WAP/IP gateway can send the sender's SGSN address in the HTTP headers, and

some WAP/IP gateways can also deliver the sender's IMSI.

If the MMS Center has the optional feature location information from WAP gateway

enabled, the kernel can apply the received SGSN address to determine whether the

message was sent by a subscriber in the home network or by a roaming subscriber. The

operator can configure whether the SGSN address from the WAP/IP gateway is applied

in charging.

The kernel resolves the message sender's domain and roaming class as follows:

the kernel checks if the location information from the WAP/IP gateway has been

enabled (an optional feature that delivers the sender's SGSN address)

the kernel checks if the sender's SGSN address is received from the WAP/IP

gateway

the kernel checks if the sender is roaming by comparing the received SGSN address

to the home SGSN address in the xnp_home_sgsn_list.cf configuration file

the kernel maps the SGSN address to the correct roaming class for charging

purposes in the xnp_sgsn_roaming_class_table.cf configuration file

the kernel logs the SGSN address to the event logs, and both the SGSN address

and the roaming class to the charging data records (CDRs).

8/12/2019 Dn 01197872

35/69

8/12/2019 Dn 01197872

36/69

36 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


5.1.3.9 Profile query for sender

If the optional feature subscriber database interface is enabled in the MMS Center, the

kernel can query profile information from a subscriber database for the sender. The sub-

scriber database can be, for example, Nokia Profile Server or an LDAP directory.

The fetched sender profile can contain different kind of user preference information,

such as the terminal capability, virtual operator identification, barring, content adapta-

tion, forwarding, carbon-copying, prepaid indication and address hiding information. The

sender profile may indicate, for example, that carbon copies of all received MMs should

be sent to a specified addresses, or that the recipient address is a distribution list.

With AO MMs, the EAIF configuration can specifically allow (per application) making a

profile query for the sender. If it is not allowed, no profile query is made even if this was

allowed in other MMS Center configurations. For AO MMs the profile query may return

information that the recipient address is a distribution list (optional feature).

For further information, see Subscriber database interface overview(PDF Subscriber

Database Interface Guide).

5.1.3.10 Distribution list

If the MMS Center in the sender profile query receives information from the subscriber

database that the recipient is a distribution list (optional feature), it must expand the

actual recipients based on the distribution list address. The MMS Center fetches the dis-

tribution list members from the subscriber database with a new query, and the sub-

scriber database returns a list of the distribution list members, whose addresses can be

either MSISDN/MDN or e-mail.

The distribution list optional feature requires Profile Server 5.0.

Distribution lists can be used in AO traffic only.

Until the kernel has requested the sender profile from the subscriber database it does

not know that the recipient of the MM is a distribution list. Therefore, the MM-O is pro-

cessed like any other MM-O up to the point when the kernel receives the sender profile

from the subscriber database and notices that the recipient is a distribution list.

The following presents the distribution list processing in the kernel from the sender

profile query onwards.

8/12/2019 Dn 01197872

37/69

DN01197872

Issue 10-0

37


Id:0900d8058041dd4a

Figure 13 Distribution list processing

1. The kernel makes a profile query for the sender.

2. The profile information fetched for the subscriber (sender and/or recipient) may

contain barring information, defined by both the operator and the subscriber. The

originating application may be barred or the recipient (distribution list) may be

barred.

3. The kernel sends an acknowledgement to the external application via the EAIF.

4. The kernel stores the original MM-O in the database.

5. The kernel requests the distribution list members from the subscriber database in

chunks of 10 000 subscribers.

The subscriber database responds to the request by sending a sublist of the distri-

bution list to the kernel.

The response contains, among other things, the addresses of the distribution list

members, information on whether additional recipient profile queries from the sub-

scriber database are to be made, and whether an MNP query is to be made for the

recipients. If an additional recipient profile query is not made, a common profile is

used for the recipients. The common profile contains information on whether the dis-tribution list member is a prepaid subscriber and whether content adaptation may be

performed to the message.

6. Copies of the MM-O in the database are made for all distribution list members.

7. If so configured in the subscriber database, the kernel makes an MNP query for the

recipient.

8. If a common profile is not used, the kernel makes a profile query for the recipient.

9. If so configured in the subscriber database, the kernel makes a prepaid query for the

recipient.

10. If the application associated with distribution list has guaranteed capacity configured

for it, distribution list overload protection is applied when sending out the notifica-

tions. The kernel allows at maximum 10 000 notifications to be buffered for each

Profile query for sender (optional)

MNP query for recipient (optional)

Distribution list query (optional)

Copies for multiple recipients to memory


Barring based on sender profile (optional)


Profile query for recipient (optional)

Prepaid query for sender andrecipient (optional)

Send notification to recipient

Distribution list overload protection Message rejection possibleat this stage.

Message processing continuesto next stage.

8/12/2019 Dn 01197872

38/69

38 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


application that has guaranteed capacity defined. To prevent the distribution lists

from overflowing the buffers, notification sending for a particular application is

paused for a second whenever the amount of buffered notifications for that applica-

tion is greater than 80% of the maximum buffer size. The sending will continue again

when the buffer fullness drops under 80%.

11. The kernel sends a notification about the MM to all recipients that were received in

this sublist.

12. If this was not the last sublist, the kernel repeats steps 5 - 12 until all distribution list

members have been fetched from the subscriber database.

For more information, see Distribution list overview(PDF Distribution List Guide).

5.1.3.11 Barring based on sender profile

The profile information fetched for the sender may contain barring information, defined

by both the operator and the subscriber. For example, the sender profile may indicate

that the sender is barred from sending MMs.

For further information, see Barring(PDF Subscriber Database Interface Guide).

Optionally, the sender profile information may also contain virtual operator information,

which is needed for defining the virtual operator and for computing roaming classes.

After barring is done, roaming classes are computed by mapping roaming information

to an integer value. For more information, see Configuring global roaming class table

(PDF Mobile Number Portability and Address Resolution Guide) and Configuring virtual

operator specific home msc list and roaming class table(PDF Virtual MMS Center

Guide).

5.1.3.12 Copies for multiple recipients to memory

If an MM is targeted to multiple recipients, a copy of the MM-O for each recipient is

stored to the database, and each MM-O has a reference to the original MM.

From this point onwards, processing in the kernel (for example, making an MNP request

to obtain the IMSI or domain, checking the barring lists and querying profile information

from the subscriber database) is done individually for each recipient, except IACC

sender queries, which can optionally be configured so that all recipients are sent to the

IACC server in a single query.

Regarding the handling of multiple recipients in the case of mobile-originated MMs: if

message handling (the time interval between the message submittal to the MMS Center

and the MMS Center response to the submittal) takes longer than configured in the MMSCenter configurations, a mobile terminal may try to resend the MM. This, in turn, may

result in double billing of a mobile subscriber. A solution to this is that a maximum

message handling time (the time interval between the message submittal to the MMS

Center and the MMS Center response to the submittal) can be configured for MMs that

are intended for multiple recipients. In case message handling takes longer than speci-

fied with this maximum message handling time, the MMS Center can be configured

always to accept an MM (and send an acknowledgement PDU M-Send.conf to the

mobile terminal) earlier and continue with message handling. A delivery report is gener-

ated at this stage for failed deliveries.

Regarding the handling of multiple recipients in the case of application-originated MMs

where the recipient is a distribution list: the MMS Center sends a response to the appli-cation before making copies for multiple recipients.
http://x%3Dd%3Do%3Dc/s-000009.pdfhttp://dn0261196.pdf/http://dn0269185.pdf/http://dn03285424.pdf/http://dn03285424.pdf/http://dn03285424.pdf/http://dn03285424.pdf/http://dn0269185.pdf/http://dn0261196.pdf/http://x%3Dd%3Do%3Dc/s-000009.pdf

8/12/2019 Dn 01197872

39/69

DN01197872

Issue 10-0

39


Id:0900d8058041dd4a

For further information on message handling regarding multiple recipients, see Message

flow scenarios(PDF Message Handling). For configuration instructions, see Configuring

the handling of MMs that have multiple recipients(PDF Operating Guide).

5.1.3.13 Temporary number conversion for MM-O recipient in multiple-recip-

ient case

Number conversion is performed for the sender and recipient of the MM and the sender

of the MM-O. If new recipient addresses are added during MM-O processing in the

kernel, for example, because of rules in the sender profile, or because the recipient of

the MM is a distribution list, both defined in the subscriber database, a temporary

number conversion will be performed later for those recipients in the MM-O.

5.1.3.14 Routing rules for applications based on MSISDN/MDN

The kernel reads the MM routing rules at different stages of the MM-O processing todetermine which external applications the MM should be routed to. If matching rules are

found, the kernel checks what type of an application the MM is to be routed to (filtering

or terminating). Based on this information, the kernel determines at this point if the MM

is MT or AT, and adds the applicable application IDs to the MM-O.

After an MM-O is stored in the database, it can be routed to a filtering application. When

the MM has been processed by the filtering application, the EAIF returns it to the kernel

which continues to process it as an MT MM.

The kernel reads the routing rules based on the sender and recipient addresses and

content type (optional feature) both before and after performing MNP and barring for the

recipient. First the routing rules based on the sender address, IMSI and domain, and the

recipient address are read, and if at this point the MM is determined to be AT, no MNP

request for the recipient is made.

With AO MMs, the EAIF configuration can specify (per application) that messages

received from the external application cannot be routed to the inter-MMS Center, to

legacy phone support, or to any terminating application. These restrictions override the

routing rules.

For further information, seeAbout kernel routing rules(PDF Operating Guide).

5.1.3.15 Applying MNP and address resolution for recipient

Mobile number portability (MNP) and address resolution (optional feature) can be

applied to check the domain and location information for the recipient. For more infor-

mation, seeApplying MNP and address resolution for sender(PDF Message Handling).

The following figure and procedure illustrate how processing is done for the recipient.

This is an example that applies to processing a mobile-terminated message.
http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/http://dn0272867.pdf/

8/12/2019 Dn 01197872

40/69

40 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


Figure 14 MNP processing for recipient

1. The MNP interface checks the recipient's MSISDN/MDN against the MSISDN/MDN-based white- and blacklists to find out if the recipient is barred.

The MNP interface can also check the recipient's MSISDN/MDN against the entries

on the exported and imported numbers lists, which act as exceptions to the

MSISDN/MDN-based white- and blacklists.

If the recipient's MSISDN/MDN is found on the exported numbers list, the corre-

sponding network prefix (under which the MSISDN/MDN is listed) is checked

against the MSISDN/MDN-based whitelist. If the network prefix is found, the

recipient is allowed to receive messages, unless the number is found on the

MSISDN/MDN-based blacklist.

If the recipient's MSISDN/MDN number is found on the imported numbers list,

the recipient is allowed to receive messages, unless the number is found on the

MSISDN/MDN-based blacklist.

If the recipient is barred, the message is rejected. If the recipient is not barred,

routing proceeds to the next step.

2. The MNP interface checks which MNP interface plugin to use for making an MNP

request for the recipient. Based on the MNP configuration, this can be determined

in two ways:

The MNP configuration can specify a default plugin which is used for making all

MNP requests.

The list of MNP countries can specify which plugin is used to make MNP

requests for which country.

If no suitable plugin is found, routing proceeds to step 4b. If a suitable plugin is

found, routing proceeds to the next step.

MNP processing starts for recipient

Message rejected Process message further

Plugin found

Barred

Not barred

Request failed

2. Check which plugin to use

3. Request IMSI/domain

4a. IMSI to domain mapping 4b. MSISDN/MDN to domain mapping

Not barred

Not barred

IMSI received

Barred

Barred

Requestfailed

No plugin found

Domainreceived

1. MT MSISDN/MDN barring

5. MT IMSI barring

6. MT domain barring

Temporary error

Request failed

8/12/2019 Dn 01197872

41/69

8/12/2019 Dn 01197872

42/69

42 DN01197872

Issue 10-0

Message Handling

Id:0900d8058041dd4a


If the profile indicates new recipient addresses (for example, in the case of carbon -copy-

ing), the kernel processes these as multiple recipients for the MM, going through number

conversion, copies for multiple recipients, MNP request, barring, and so forth.

When the kernel has queried the recipient profile from the subscriber database, theprofile information may indicate that the recipient does not have an MMS-capable or an

MMS video-capable terminal. In this case, the kernel checks the routing rules again, and

if there is a rule configured for legacy phone support, the kernel routes the MM to the

EAIF, which is then responsible for routing it to the legacy phone support application.

The MM can also be routed to the legacy phone support application if the MM recipient

does not request the MM within a configured time (legacy phone timer) or if the MM

expires in the database. For more information, see Legacy phone timer(PDF Message

Handling).

For further information, see Subscriber database interface overview(PDF Subscriber

Database Interface Guide).

5.1.3.18 Barring based on recipient profile

The profile information fetched for the recipient may contain barring information, defined

by both the operator and the subscriber.

For example, the recipient profile may indicate that the recipient is barred from receiving

any MMs, or that the recipient has barred some specific subscribers from sending MMs

to him/her (for example, to prohibit spam).

For further information, see Barring(PDF Subscriber Database Interface Guide).

Optionally, the recipient profile information may also contain virtual operator information,

which is needed for defining the virtual operator and for computing roaming classes.

After barring is done, roaming classes are computed by mapping roaming information

to an integer value. For more information, see Configuring global roaming class table

(PDF Mobile Number Portability and Address Resolution Guide) and Configuring virtual

operator specific home msc list and roaming class table(PDF Virtual MMS Center

Guide

Documents

Dn 01197872