DN 01197872

Nokia Siemens Networks MMS Center, Rel.6.0 Operating Documentation, PDF v.
Descriptions
Message Handling
DN01197872 Issue 10-0 Approval Date 2010-03
Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components. If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.
Message Handling
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2012/7/5. All rights reserved
Important Notice on Product Safety

This 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:
Wichtiger Hinweis zur Produktsicherheit

Von 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 Sicherheitsanforderungen erfolgen. Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal, Safety and Environmental Information dieses Dokuments oder dieses Dokumentationssatzes.
Id:0900d80580862d66
DN01197872 Issue 10-0
Message Handling
Table of Contents
This document has 69 pages. 1 1.1 1.2 2 2.1 2.2 3 3.1 3.2 3.3 3.4 3.5 4 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 5 5.1 5.1.1 5.1.2 5.1.3 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.5 5.1.3.6 5.1.3.7 5.1.3.8 5.1.3.9 5.1.3.10 5.1.3.11 5.1.3.12 5.1.3.13 5.1.3.14 5.1.3.15 5.1.3.16 5.1.3.17 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Message handling overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Message handling in the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Message handling in the MMS Center. . . . . . . . . . . . . . . . . . . . . . . . . . 11 Message types and storage. . . . . . . Multimedia messages . . . . . . . . . . . Delivery reports . . . . . . . . . . . . . . . . Read-reply reports . . . . . . . . . . . . . . MMS Center message storage . . . . Protocol data units . . . . . . . . . . . . . . ........................... ........................... ........................... ........................... ........................... ........................... 13 13 14 15 15 16 19 19 19 21 22 23 24 26 26 27 27 29 30 30 31 31 34 35 35 35 36 36 38 38 39 39 39 41 41
Message flow scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile-originated messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile-originated - mobile-terminated MMs. . . . . . . . . . . . . . . . . . . . . . Mobile-originated - mobile-terminated MMs with deferred delivery . . . . Mobile-originated - mobile-terminated MMs with filtering application . . Mobile-originated - application-terminated MMs . . . . . . . . . . . . . . . . . . Application-originated MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multimedia message processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MM submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving new mobile-originated MM . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving new application-originated MM . . . . . . . . . . . . . . . . . . . . . . . MM-O processing in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number conversion for sender and recipient . . . . . . . . . . . . . . . . . . . . . Delayed delivery time validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expiration time validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying MNP and address resolution for sender . . . . . . . . . . . . . . . . . Location information from WAP/IP gateway (optional) . . . . . . . . . . . . . Address hiding validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overload control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barring based on terminal type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profile query for sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distribution list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barring based on sender profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copies for multiple recipients to memory. . . . . . . . . . . . . . . . . . . . . . . . Temporary number conversion for MM-O recipient in multiple-recipient case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing rules for applications based on MSISDN/MDN. . . . . . . . . . . . . Applying MNP and address resolution for recipient . . . . . . . . . . . . . . . . Routing rules based on IMSI/domain. . . . . . . . . . . . . . . . . . . . . . . . . . . Profile query for recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DN01197872 Issue 10-0
Id:0900d80580862d66
Message Handling
5.1.3.18 5.1.3.19 5.1.3.20 5.1.3.21 5.1.3.22 5.1.3.23 5.1.3.24 5.1.3.25 5.1.3.26 5.1.3.27 5.1.3.28 5.2 5.2.1 5.2.2 5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4 5.2.2.5 5.2.2.6 5.2.2.7 5.2.3 5.2.4 5.2.5 6 6.1 6.2 6.3 7 7.1 7.2 7.3 8 8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.2 8.2.1 8.2.2 8.3 8.3.1
Barring based on recipient profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Prepaid query for sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Autoprovisioning of postpaid and prepaid subscribers . . . . . . . . . . . . . . 43 Prepaid query for recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Recipient-based forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Updating MM-O in database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Route to filtering application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Sending acknowledgement to sender. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Traffic load management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Send notification to recipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Route MM-O to EAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 MM delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Receiving request for MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Processing request for MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Number conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Fetching MM-O from database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Verification of recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Barring based on terminal type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Prepaid query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Content adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Routing rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Delivering MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 MM expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Legacy phone timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Delivery report processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Generating a delivery report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Delivery report processing in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . 52 Sending a delivery report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Read-reply report processing . . . . . . . . . . . . . . Receiving read-reply reports. . . . . . . . . . . . . . . Read-reply report processing in the kernel . . . . Sending read-reply reports . . . . . . . . . . . . . . . . ....... ....... ....... ....... ...... ...... ...... ...... . . . . . . 55 . . . . . . 56 . . . . . . 56 . . . . . . 59
Message exchange with external applications . . . . . . . . . . . . . . . . . . . . 60 Routing MMs to legacy phone support application . . . . . . . . . . . . . . . . . 60 Routing based on profile information . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Routing of unfetched MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Routing of expired MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Routing based on content adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Message exchange with Internet mail gateway . . . . . . . . . . . . . . . . . . . 64 Message handling from mobile terminal to mail server. . . . . . . . . . . . . . 65 Message handling from mail server to mobile terminal. . . . . . . . . . . . . . 66 Message exchange with inter-MMS Center . . . . . . . . . . . . . . . . . . . . . . 67 Inter-MMS Center message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Id:0900d80580862d66
DN01197872 Issue 10-0
Message Handling
List of Figures
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 MMS message flow in the GPRS and WCDMA networks . . . . . . . . . . . . 9 MMS message flow in the CDMA2000 network. . . . . . . . . . . . . . . . . . . 10 Message handling subsystems in the MMS Center. . . . . . . . . . . . . . . . 11 MM and the multi-part structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 MO-MT MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 MO-MT with deferred delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 MO-MT with a filtering application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 MO-AT MMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 AO-MT MMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Submitting and delivering MMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 MM-O processing in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 MNP processing for sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Distribution list processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 MNP processing for recipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Kernel processing after a request for an MM. . . . . . . . . . . . . . . . . . . . . 46 Receiving and sending delivery reports . . . . . . . . . . . . . . . . . . . . . . . . . 51 Delivery report processing in kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Receiving and sending read-reply reports . . . . . . . . . . . . . . . . . . . . . . . 56 Read-reply report processing in the kernel . . . . . . . . . . . . . . . . . . . . . . 57 Legacy phone support with subscriber database. . . . . . . . . . . . . . . . . . 61 Legacy phone support with unfetched MMs . . . . . . . . . . . . . . . . . . . . . 62 Legacy phone support with expired MMs . . . . . . . . . . . . . . . . . . . . . . . 63 Legacy phone support with content adaptation . . . . . . . . . . . . . . . . . . . 64 Message handling from a mobile terminal to the mail server. . . . . . . . . 65 Message handling from the mail server to a mobile terminal. . . . . . . . . 66 Inter-MMS Center message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
DN01197872 Issue 10-0
Id:0900d80580862d66
Message Handling
List of Tables
Table 1 Table 2 PDU types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 MM4 PDU types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Id:0900d80580862d66
DN01197872 Issue 10-0
Message Handling
About this document
1 About this document

This document provides an introduction to message handling for Nokia Siemens Networks Multimedia Messaging Service Center (MMS Center). This document is intended for operator personnel who are operating and administering the MMS Center.
1.1
Date March 2008 November 2007
Summary of changes
Summary of changes For release MMS Center 5.0 ED01. Section Message exchange with inter-MMS Center updated. For release MMS Center 5.0. Appendix A Error messages to mobile terminals has been moved to Technical Reference. The term service provider has been replaced by virtual operator.
Issue 10-0 en 9-0 en
June 2006
8-0 en
For release MMS Center 4.0. The entire document has been updated. The changes are related to the following features:

June 2005 7-0 en
content adaptation (including standard transcoding interface) distribution list integrated PPG location information from WAP gateway MM7 interface has been renewed single copy of MM stored to database in case of multiple recipients traffic load management
For release MMS Center 3.2. Updated chapters:
References Message processing in the kernel Read-reply report processing in the kernel Error messages to mobile terminals
1.2
References
MMS Center document: Architecture, DN0272949 Content Adaptation Guide, DN0226083 Distribution List Guide, DN7076585 EAIF and External Applications Configuration Guide, DN0267915 External Applications Developers Guide, DN0284937 In Advance Credit Check Guide, DN0277508 Inter-MMS Center Configuration Guide, DN02102346
DN01197872 Issue 10-0
Id:0900d80580268a4c
About this document
Message Handling
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-MMSENC-V1_2-20050301-A OMA Multimedia Messaging Service Client Transactions Version 1.2, OMA-MMS-CTRV1_2-20050301-A OMA Multimedia Messaging Service Conformance Document Version 1.2, OMA-MMSCONF-v1_2-20050301-A
Id:0900d80580268a4c
DN01197872 Issue 10-0
Message Handling
Message handling overview
2 Message handling overview

Multimedia 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:
Air
BTS MSC/VLR/HLR BSC/RNC BSC/RNC BTS
1
WAP/HTTP POST
SMS Center
MMS notification (over SMS)
3
SGSN SGSN
GPRS BB
GGSN
GGSN
WAP/HTTP GET
WAP/IP gateway and PPG
MMS Center
SMTP e-mail HTTP EA SMTP MMSC
4
IP IP
Figure 1
MMS message flow in the GPRS and WCDMA networks
DN01197872 Issue 10-0
Id:0900d805803d9bf5
Message Handling
Air
BTS
MSC/VLR/HLR BSC/PCF BSC/PCF BTS
1
HTTP POST
SMS Center
PDSN PDSN
MMS notification (over SMS)
IP core network
AAA / RADIUS
GGSN
2
WAP/IP gateway and PPG
HTTP GET
MMS Center
SMTP e-mail HTTP EA SMTP MMSC
4
IP IP
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 multimedia-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 notification about a new mobile-terminated MM to the recipient's mobile terminal through
10
Id:0900d805803d9bf5
DN01197872 Issue 10-0
Message Handling
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 centre/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 notification 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 operator'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 for sending 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 integrated 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):
Mobile subscribers
MMS Center database
External application MMs, reports MMs, reports External application External application
Figure 3 Message handling subsystems in the MMS Center
WAPGWIF
Kernel
EAIF
DN01197872 Issue 10-0
Id:0900d805803d9bf5
11
Message Handling
WAP gateway interface (WAPGWIF) The WAP gateway interface subsystem receives MMs, MM retrieval requests, readreply 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 notifications 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 distribution 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 Resolution 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 (PDF Architecture).
12
Id:0900d805803d9bf5
DN01197872 Issue 10-0
Message Handling
Message types and storage
3 Message types and storage

The 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, processes 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 individual 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 presentation 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 instructions embedded in the mobile terminal itself. The following figure illustrates the headers and the multi-part field.
DN01197872 Issue 10-0
Id:0900d80580350685
13
Message Handling
MMS headers
WAP/HTTP Multipart
application/smil
Presentation instructions
text/plain Content image/jpeg
This is a message...
audio/amr
Figure 4
MM and the multi-part structure
The MMS Center wraps the MM into a multimedia message object (MM-O). The MM-O is 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 Multimedia 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 configured 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.
14
Id:0900d80580350685
DN01197872 Issue 10-0
Message Handling
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 connections (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, indicating 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 scripts and events logged in the database, see PDF Technical Reference.
DN01197872 Issue 10-0
Id:0900d80580350685
15
Message Handling
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 M-Send.req M-Send.conf Description An MM sent to the MMS Center by the sender's mobile terminal or an external application that uses the EAIF protocol. 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 terminal, 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 MNotification.ind, or using deferred delivery (in which case an M-NotifyResp.ind is sent instead of making a WSP/HTTP GET request. M-Retrieve.conf M-NotifyResp.ind The retrieved MM or an error message sent by the MMS Center to the MM recipient. The PDU is used in either one of the following cases:
In the case of immediate MM retrieval, this is the acknowledgement 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 MM recipient'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-NotifyResp.ind.)
Table 1
PDU types
16
Id:0900d80580350685
DN01197872 Issue 10-0
Message Handling
PDU type M-Acknowledge.ind
Description In the case of deferred delivery, this is the acknowledgement of the MM delivery (a response to the M-Retrieve.conf), sent by the MM recipient's mobile terminal. (If the MM was fetched immediately, the M-NotifyResp.ind is used as an acknowledgement instead of the M-Acknowledge.ind.)
M-Delivery.ind
A delivery report that the MMS Center can send to the MM sender, indicating the status of the sent MM. The delivery report can include information about MM retrieval, rejection and expiration. A separate delivery report is sent per each MM recipient, and no response message to the delivery report is sent from the mobile terminal.
M_Read_Rec.ind
The MM recipient's mobile terminal can send this indication to the MMS Center about the MM status (read, deleted without being read), if a read-reply report is requested. This PDU is specific to OMA MMS 1.1 and later versions. A read-reply report that the MMS Center can send to the MM sender after receiving the M_Read_Rec.ind. This PDU is specific to OMA MMS 1.1 and later versions.
M_Read_Orig.ind
Table 1
PDU types (Cont.)
The proprietary EAIF protocol is based on a subset of the PDUs listed above. For detailed information on the EAIF protocol PDUs as well as the MM7 protocol PDUs, see EAIF protocol and MM7 PDUs (PDF External Applications Developer's Guide). For more information on the standard message flows, see OMA specification Multimedia Messaging Service Client Transactions Version 1.2. The following table describes the MM4 PDUs (defined by 3GPP TS 23.140) that are used in inter-MMS Center communications when the inter-MMS Center protocol is SMTP:
PDU types MM4_Forward.REQ MM4_Forward.RES Description An MM routed by the originating MMS Center to the terminating MMS Center. The response to the MM4_Forward.REQ from the terminating MMS Center. The response indicates the status of the MM4_Forward.REQ request (if sending the status was requested). MM4_Delivery_report.REQ A delivery report routed by the terminating MMS Center to the originating MMS Center. The delivery report contains MMS control information only. MM4_Delivery_report.RES The response to the MM4_Delivery_report.REQ from the originating MMS Center. The response indicates the status of the MM4_Delivery_report.REQ request (if sending the status was requested).
Table 2
MM4 PDU types
DN01197872 Issue 10-0
Id:0900d80580350685
17
Message Handling
PDU types MM4_Read_reply_report.REQ
Description A read-reply report routed by the terminating MMS Center to the originating MMS Center. The read-reply report contains MMS control information only. The response to the MM4_Read_reply_report.REQ from the originating MMS Center. The response indicates the status of the MM4_Read_reply_report.REQ request (if the sending the status was requested).
MM4_Read_reply_report.RES
Table 2
MM4 PDU types (Cont.) The inter-MMS Center transmitter by default requests a .RES PDU as an acknowledgement for .REQ PDUs sent over the MM4 reference point. The acknowledgement requests can be disabled in the inter-MMS Center configuration.
18
Id:0900d80580350685
DN01197872 Issue 10-0
Message Handling
Message flow scenarios
4 Message flow scenarios

The 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 operators 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 submitted 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.
DN01197872 Issue 10-0
Id:0900d80580290d7e
19
Message Handling
1 3 8 10 WAPGWIF 4 5 6 7 9
Figure 5 MO-MT MMs
MMS Center database
Kernel
EAIF
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 the sender 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).
20
Id:0900d80580290d7e
DN01197872 Issue 10-0
Message Handling
4.1.2
Mobile-originated - mobile-terminated MMs with deferred delivery

When processing an MO-MT MM, the recipient may choose deferred delivery of the MM, meaning that the recipient does not retrieve the message immediately after receiving a notification of it but only later. The following figure shows a scenario when deferred delivery is used. The MMS Center sends and receives messages through the WAPGWIF.
1 3 9 11 WAPGWIF 4 5 6 7 8 10
Figure 6
MMS Center database
Kernel
EAIF
MO-MT with deferred delivery
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 by indicating deferred delivery (PDU M-NotifyResp.ind). 6. Eventually, the recipient sends a request (PDU WSP/HTTP GET) to the MMS Center to retrieve the MM. 7. The MM is retrieved from the MMS Center database and delivered to the recipient (PDU M-Retrieve.conf). 8. The recipient acknowledges the MM delivery (PDU M-Acknowledge.ind). 9. 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). 10. 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).
DN01197872 Issue 10-0
Id:0900d80580290d7e
21
Message Handling
11. The MMS Center forwards the read-reply report (PDU M_Read_Orig.ind) to the sender of the MM.
4.1.3
Mobile-originated - mobile-terminated MMs with filtering application

In 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.
1 3 10 12 WAPGWIF 6 7 8 9 11
Figure 7
MMS Center database
4 5
External application
Kernel
EAIF External application
MO-MT with a filtering application
This scenario is much the same as the one for processing an MO-MT MM, the only difference is that the MM is processed by a filtering application before it is delivered to the recipient. 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 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 application 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.
22
Id:0900d80580290d7e
DN01197872 Issue 10-0
Message Handling
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). 8. 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). 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). 11. 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). 12. The MMS Center forwards the read-reply report (PDU M_Read_Orig.ind) to the 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.
1 3 6
MMS Center database
WAPGWIF
Kernel
EAIF
Figure 8
MO-AT MMs
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 kernel routes the MM to the EAIF, which sends it to the external application.
DN01197872 Issue 10-0
Id:0900d80580290d7e
23
Message Handling
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 applications 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.
MMS Center database
2 WAPGWIF 4 5 6 7 9
Figure 9 AO-MT MMs
Kernel
EAIF 1 3 8 10
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. 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 kernel acknowledges receiving the MM, and the EAIF sends the acknowledgement 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). 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 to the external application, if it was requested and if it is allowed in 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).
24
Id:0900d80580290d7e
DN01197872 Issue 10-0
Message Handling
10. The MMS Center forwards the read-reply report (PDU M_Read_Orig.ind) to the originating application.
DN01197872 Issue 10-0
Id:0900d80580290d7e
25
Multimedia message processing
Message Handling
5 Multimedia message processing

The following sections describe the phases of multimedia message (MM) processing (see the following figure): MM submission The MMS Center receives mobile-originated (MO) MMs through the WAP gateway interface (WAPGWIF) and application-originated (AO) MMs through the external applications interface (EAIF). Both subsystems do some processing on the submitted MMs, wrap them into objects used in internal processing (MM-O:s), before forwarding them to the kernel. The kernel processes the MM and determines whether it is mobile-terminated (MT) or application-terminated (AT). With MT messages, the kernel sends a notification to the mobile recipient through the WAPGWIF and a push proxy gateway (PPG) or the SMS Center, and with AT messages, the kernel delivers the MM to the receiving external application through the external application interface (EAIF). MM delivery The MMS Center delivers MT messages through the WAPGWIF (when the mobile recipient requests the MM after receiving the notification) and AT messages through the EAIF. Both subsystems receive processed messages from the kernel, unwrap the MM-O:s back to MMs, and send the MMs out.
MMS Center database
MM submission (MO)
MM submission (AO)
Originating application
MM sender
WAPGWIF
Kernel
EAIF
MM delivery (MT) MM recipient
MM delivery (AT)
Terminating application
Figure 10
Submitting and delivering MMs
5.1
MM submission
When either a mobile subscriber or an external application has submitted a new MM to the MMS Center, the WAPGWIF and the EAIF validate the message and apply the restrictions specified in each subsystem's configurations. Based on these, the message is either forwarded to the kernel (as an MM-O), or rejected. The kernel processes the MM-O by applying the restrictions specified in its configuration and possibly also by using the services of other MMS Center subsystems and interfaces during the processing. Based on the result of the processing, the kernel can either reject the MM, or continue to send a notification about the MM to a mobile recipient through the WAPGWIF or deliver the MM to an external application through the EAIF.
26
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
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 configuration, 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 recipients 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 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 processing and 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 configurations overview (PDF Operating Guide).
5.1.2
Receiving new application-originated MM

When 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
DN01197872 Issue 10-0
Id:0900d8058041dd4a
27
Message Handling
and decryption, see Address encryption with EAIF protocol (PDF External Applications 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 configuration (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 readreply 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 processing and 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 configuration 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 information 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 processes 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 (PDF EAIF and External Applications Configuration Guide).
28
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
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 / Gwrmanmx fragment (see Gwrmanmx, PDF Parameter Reference).
Number conversion for sender and recipient Delayed delivery time validation Expiration time validation Applying MNP and address resolution (optional) for sender Location information from WAP/IP gateway (optional)
Address hiding validation Overload control Barring based on terminal type Profile query for sender (optional) Barring based on sender profile (optional) Copies for multiple recipients to memory Temporary number conversion for MM-O recipient (multiple-recipient case) Routing rules based on MSISDN/MDN Applying MNP and address resolution (optional) for recipient Routing rules based on IMSI/domain Distribution list processing (optional)
MT
AT
DN01197872 Issue 10-0
Id:0900d8058041dd4a
29
Message Handling
Profile query for recipient (optional) Barring based on recipient profile (optional) Prepaid query for sender (optional) Autoprovisioning of postpaid and prepaid subscribers Prepaid query for recipient (optional)
Legacy phone support
Prepaid query for sender (optional) Autoprovisioning of postpaid and prepaid subscribers Store MM-O to database Send acknowledgement to sender Traffic load management (optional) Route MM-O to EAIF
Recipient-based forwarding Store MM-O to database Route to filtering application Send acknowledgement to sender Traffic load management (optional) Send notification to recipient
AT
Message rejection possible at this stage. Message processing continues to next stage.
MT
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, see About 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 defined maximum value), the kernel continues MM-O processing up until making a prepaid
30
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
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' every minute. When the delayed delivery time has been reached, the kernel continues processing 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 time and 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 timestamps 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 from kernel configuration is used. If the message has a desired delivery time set, the expiration 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 calculations 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 sender

The 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).
DN01197872 Issue 10-0
Id:0900d8058041dd4a
31
Message Handling
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 using the 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 Operating Guide). mapping the subscriber's MSISDN/MDN or IMSI to a domain name based on configurable 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, see About 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 Interface 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.
32
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
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.
MNP processing starts for sender
Barred 1. MO MSISDN/MDN barring Not barred Yes 2. Check if IMSI is available No No plugin found 3. Check which plugin to use Plugin found Request failed 4. Request IMSI/domain Request failed IMSI received 5a. IMSI to domain mapping Domain received 5b. MSISDN/MDN to domain mapping
Barred 6. MO IMSI barring Not barred Barred 7. MO domain barring Not barred Message rejected Process message further
Figure 12
MNP processing for sender
1. The MNP interface checks the sender's MSISDN/MDN against the MSISDN/MDNbased 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/MDNbased 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:
DN01197872 Issue 10-0
Id:0900d8058041dd4a
33
Message Handling
4.
5.
6.
7.
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. 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. 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. 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. The MNP interface checks the sender's domain against the domain-based whiteand blacklists to find out if the sender is barred. If the sender is barred, the message is rejected. If the sender is not barred, the kernel 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).
34
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
If the SGSN address or the IMSI are not received from the WAP/IP gateway, mobile number portability (MNP) and address resolution (optional feature) can be applied to check the domain and location information for the sender. For more information on the optional features, see Location information from WAP gateway overview (PDF Location Information from WAP Gateway Guide) and MNP and address resolution overview (PDF Mobile Number Portability and Address Resolution Guide).
5.1.3.6
Address hiding validation

The MM sender can request that his/her address is not shown to the recipient. The operator can, however, configure whether address hiding is allowed or not. When address hiding is done for MT MMs, the sender's address can either be removed from the MM or replaced with a configurable anonymous address. When address hiding is done for AT MMs, the sender's address is always replaced with a configurable anonymous address. If the sender has requested address hiding but address hiding is not allowed in the MMS Center, the MMS Center can either reject the MM and convey the information about rejection to the sender, or send the MM without hiding the address. Whether or not address hiding is allowed is specified generally for the MMS Center. If the EAIF protocol is used, the EAIF application interface configurations specify whether or not a specific application is allowed to request address hiding, but the general MMS Center configuration can override the EAIF configuration by disabling the request even if the EAIF allowed it. The MM7 protocol does not support address hiding requests. The EAIF can also be configured not to hide the sender address when sending MMs to an external application, even when requested by the sender. If the MM for which the sender requested address hiding is intended for a recipient served by another operator's MMS Center, the MM is routed to the inter-MMS Center without hiding the address and the request for address hiding is included in the MM. The terminating MMS Center's configuration then determines whether or not address hiding is done. For information on how to configure address hiding, see About address hiding (PDF Operating MMS Center).
5.1.3.7
Overload control
The MMS Center deals with system overload by rejecting MMs if the maximum length of the kernel's internal message queue has been reached.
5.1.3.8
Barring based on terminal type

Subscriber terminal type information is received from the WAP gateway interface (WAPGWIF). It is possible to bar a message if the sender's terminal type is not whitelisted. If the terminal type is not supported by the MMS Center, a copy of the MM is sent to the legacy support application and the MM-O is deleted from the database.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
35
Message Handling
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 subscriber 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 adaptation, 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 distribution list members from the subscriber database with a new query, and the subscriber 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 processed 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.
36
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
Profile query for sender (optional) Barring based on sender profile (optional) Send acknowledgement to sender Store MM-O to database Distribution list query (optional) Copies for multiple recipients to memory MNP query for recipient (optional) Profile query for recipient (optional) Prepaid query for sender and recipient (optional)
Distribution list overload protection Send notification to recipient
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 distribution 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 subscriber 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 distribution 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 notifications. The kernel allows at maximum 10 000 notifications to be buffered for each
DN01197872 Issue 10-0
Id:0900d8058041dd4a
37
Message Handling
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 application 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 MMS Center 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 specified 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 generated 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 application before making copies for multiple recipients.
38
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
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-recipient 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 to determine 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, see About 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 information, see Applying 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.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
39
Message Handling
MNP processing starts for recipient
Barred
1. MT MSISDN/MDN barring Not barred No plugin found 2. Check which plugin to use Plugin found 3. Request IMSI/domain IMSI received 4a. IMSI to domain mapping Domain received 4b. MSISDN/MDN to domain mapping
Request failed Request failed Request failed Temporary error
Barred
5. MT IMSI barring Not barred
Barred
6. MT domain barring Not barred
Message rejected
Process message further
Figure 14
MNP processing for recipient
1. The MNP interface checks the recipient's MSISDN/MDN against the MSISDN/MDNbased 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 corresponding 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.
40
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
3. The MNP interface makes an IMSI request to the hlr or an MNP server, or a domain request to an ENUM server. If the request fails, the MNP configuration determines if the message is rejected or if the message is stored in the database for further processing by the MMS Center subsystems. If the MAP/SIGTRAN, MAP/SS7 or XML interface plugin is used and the MNP request fails because of an absent subscriber, the plugin waits for a notification from the hlr or MNP server and sends a new IMSI query when the subscriber is available again. If the request is successful, routing proceeds as follows: If the recipient's domain was received, routing proceeds to step 6. If the recipient's IMSI was received, routing proceeds to the next step. 4. The MNP interface does one of the following: a) The recipient's IMSI is mapped to a domain based on the IMSI to domain mapping file. After the mapping, routing proceeds to step 5. b) The recipient'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. 5. The MNP interface checks the recipient's IMSI against the IMSI-based white- and blacklists to find out if the recipient is barred. If the recipient is barred, the message is rejected. If the recipient is not barred, routing proceeds to the next step. 6. The MNP interface checks the recipient's domain against the domain-based whiteand blacklists to find out if the recipient is barred. If the recipient is barred, the message is rejected. If the recipient is not barred, routing proceeds to the next step. The kernel continues processing the message.
5.1.3.16
Routing rules based on IMSI/domain

When the kernel has performed MNP and barring for the recipient, it can read the routing rules based on the recipient network address and content type (optional feature), and the ones based on the IMSI and domain if these are available (for example, through an MNP request or domain mapping). The routing rules define which external applications the MM should be routed to. For more information, see Routing rules based on MSISDN/MDN (PDF Message Handling).
5.1.3.17
Profile query for recipient

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 recipient. The subscriber database can be, for example, Profile Server or an LDAP directory. If the distribution list optional feature is used and the subscriber database returns a common profile for the distribution list members, no recipient profile query is made. The fetched recipient profile can contain different kind of user preference information, such as the terminal capability, virtual operator identification, barring, content adaptation, forwarding, carbon-copying, prepaid indication and address hiding information.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
41
Message Handling
If the profile indicates new recipient addresses (for example, in the case of carbon -copying), 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, the profile 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).
5.1.3.19
Prepaid query for sender

If the optional feature in advance credit check (IACC) is enabled in the MMS Center, the kernel can make IACC queries to the prepaid system for both the sender and the recipient. The sender IACC query is done after the recipient subscriber database query. This ensures that the MMS Center can provide the correct value of the NUMBER_OF_SUCCESSFUL_RECIPIENTS CDR field for event 128 and for the sender IACC query in case some recipients are rejected in recipient SUDBIF queries. How prepaid queries are made for each subscriber depends on the MMS Center configuration: The kernel can make an IACC query to deduct the money from the subscriber's account in a configurable phase of the message processing. The kernel can make two queries in configurable phases of the message processing: first check the subscriber's credit and later deduct the money from the account.
42
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
The kernel can make two queries in configurable phases of the message processing: first make a money reservation on the account and later either deduct the reserved money from the account or release the money reservation.
The EAIF configuration can contain application-specific restrictions for prepaid queries. For originating applications, the EAIF configuration can define whether or not making prepaid queries for the sender of an AO MM is allowed, and whether or not an originating application is allowed to send MMs to prepaid recipients. For terminating and filtering applications, the EAIF configuration can define whether or not MMs from prepaid senders can be sent to the application. For further information, see IACC overview (PDF In Advance Credit Check Interface Guide).
5.1.3.20
Autoprovisioning of postpaid and prepaid subscribers

Autoprovisioning of postpaid and prepaid subscribers to the subscriber database is only performed once when the first profile request is made for the sender. By default, all subscribers are provisioned to the subscriber database as prepaid subscribers. For more information, see Subscriber database interface functionality (PDF Subscriber Database Interface Guide).
5.1.3.21
Prepaid query for recipient

For more information, see Prepaid query for sender (PDF Message Handling).
5.1.3.22
Recipient-based forwarding
The recipient can define a forwarding address for the MM in the subscriber database. The operator can configure whether the message legs in a forwarded MM should be considered to be one MM or separate message legs. If the forwarded message is considered a separate message leg, it is treated as a new MM, and the kernel reverts to checking routing rules based on MSISDN/MDN, and continues message processing from there. For instructions on defining how the message legs should be treated, see Configuring SUDBIF (PDF Subscriber Database Interface Guide).
5.1.3.23
Updating MM-O in database

During message processing the kernel may update the MM-O in the database. If the message has multiple recipients, the kernel generates as many MM-Os about the message as the message has recipients. The database contains one copy of the actual MM to the MMS Center database, but there can be several MM-Os, depending on the number of recipients. For detailed information about the MM stored in the database (that is, the MM-O fields), see Multimedia message table (mmo) (PDF Technical Reference). After the MT MM is stored in the database, it can be routed to a filtering application depending on the specified routing rules.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
43
Message Handling
5.1.3.24
Route to filtering application

In 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). The kernel uses the EAIF to route the MM to the filtering application. When the MM has been processed by the filtering application, the EAIF may, depending on the routing rules, route it to the next application (which can be a terminating application) or return it to the kernel, which continues to process it as an MT MM. For more information on routing, see Routing rules based on MSISDN/MDN (PDF Message Handling).
5.1.3.25
Sending acknowledgement to sender

Having stored the MM-O to the database, the kernel sends an acknowledgement to the MM sender, indicating that the MM has been accepted for delivery. After this, the sender can get information about the message delivery in a delivery report (if he/she requested one when submitting the MM), and information about what the recipient did with the MM (read it or deleted it without reading) in a read-reply report.
5.1.3.26
Traffic load management

When the optional feature traffic load management is enabled, the operator can share the MMS Center capacity between incoming messages so that a certain throughput can be guaranteed for mobile-originated (MO) traffic and application-originated (AO) traffic. Note, however, that if traffic load management is used, the MM-Os are not necessarily handled in the order they arrive in the kernel; the kernel first handles incoming traffic from the guaranteed capacity groups and then the rest of MO/AO traffic. The messages within the groups are, however, handled on a first-in-first-out basis. The guaranteed capacity can be defined for the following traffic types: general MO traffic in the MM1 interface MO traffic per virtual operator MO traffic from inter-MMS Center (inter-MMS Center defined as a virtual operator) AO traffic from MM7 and EAIF applications (whose message priority has been set as High)
All incoming traffic that comes from other sources than the defined traffic types, is stored to two generic buffers: rest of the MO traffic rest of the AO traffic (for example messages with priority normal or low, or with no priority setting)
All incoming traffic is inserted into the traffic type specific buffers, and the insertion is not restricted in any way by the MMS Center capacity licence or hardware capacity. The traffic load management only restricts the fetching of messages from the buffers. Note that no guaranteed capacity values can be defined for the rest of MO traffic and rest of AO traffic buffers. The MMS Center sends messages from the buffers according to the defined guaranteed capacity every second; it sends messages from the buffers in the same order as the traffic types are listed above. If the defined traffic types do not take up all capacity during the second, the MMS Center sends out messages also from the rest of MO traffic and
44
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
rest of AO traffic buffers. After all guaranteed traffic has been sent during a certain second, messages from all buffers (including the rest of MO traffic and rest of AO traffic) are handled in round-robin fashion. The MMS Center returns to the guaranteed capacity mode in the beginning of every second.
5.1.3.27
Send notification to recipient

After an MT MM has been accepted for delivery in the MMS Center, a notification about the MM is sent to the mobile recipient. The kernel sends the notification to the WAPGWIF which processes the notification by performing, for example, number conversion. The WAPGWIF converts the notification from internal to external format, adds the URL where the recipient can retrieve the MM, and sends the notification to the push proxy gateway (PPG) or directly to the SMS Center using integrated PPG (optional feature). If the PPG or SMS Center is down or there is no capacity available, transmission is postponed until they are operational. When the PPG or SMS Center is up again, the WAPGWIF informs the kernel about this, and the kernel attempts to resend the notification. The MMS Center automatically sets the expiry time for the notification to be the same as the MMs expiry time in the MMS Center. If the MM is destined to a distribution list (optional feature), the WAPGWIF also checks whether the reply to alias -functionality is enabled, that is, whether the MM recipient is later able to reply to the alias displayed in the sender field. If so, the WAPGWIF converts the sender address to the alias address in the notification that is sent. In the case of an AT MM, no notification is sent but the MM is sent directly to the external application through the EAIF.
5.1.3.28
Route MM-O to EAIF

The MM-O is routed to the EAIF, which is then responsible for routing the MM to the destination external application.
5.2
MM delivery
Depending on whether the MM is MT or AT, it is delivered to the recipient either through the WAPGWIF or the EAIF subsystem. In the case of an MT MM, MM delivery includes receiving and processing an MM request from the recipient before the actual delivery of the MM to the recipient's mobile terminal. Instead of requesting the MM, the recipient can also respond to the notification of the MM by sending a message rejection. In this case, the kernel deletes the MM from the database after returning a status response to the recipient. In the case of an AT MM, the MM is simply sent to the external application when the MMS Center has accepted the MM for processing and determined it as AT.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
45
Message Handling
5.2.1
Receiving request for MM

Having received a notification about the MM, the mobile MM recipient can make a request to retrieve the MM from the MMS Center. The request contains, for example, the MM recipients MSISDN/MDN, the terminal type (in the UAHeader or UAProf fields) and possibly the IMSI (if received from the WAP/IP gateway). The WAP/IP gateway resolves the MM recipient's identification and location (SGSN address) reliably from the network and provides this information to the MMS Center in the HTTP headers. When the WAPGWIF receives the request, it processes the request (for example, by converting the request to an internal processing format and adding the MM recipient's MSISDN/MDN and terminal type in it) and forwards the request to the kernel. The recipient's SGSN address can be received from the WAP gateway, but the MNP queries are not supported for the message fetch phase.
5.2.2
Processing request for MM

The following figure illustrates the processing that the kernel does when it has received a request for an MM. The grey boxes indicate processing phases after which the kernel may either reject the request or continue with processing to the next phase.
Number conversion for recipient Fetch MM-O from database Verification of recipient Barring based on terminal type Prepaid query (optional) Content adaptation (optional) Routing rules (optional)
Figure 15
Kernel processing after a request for an MM
The phases of kernel processing are explained in detail in the following sections. In short, the phases are the following: Number conversion for the MM recipient Fetching the MM-O from the database Verifying that the subscriber requesting the MM is the intended recipient Barring based on terminal type Performing a prepaid query Performing content adaptation (optional) Checking the MM routing rules (due to content adaptation)
Having received the notification of an MM, the MM recipient may also decide to reject the MM. In this case, the kernel receives a reject message from the WAPGWIF, applies number conversion and checks that the subscriber sending the MM rejection is the intended recipient, sends a status message to the recipient, and deletes the MM-O from the MMS Center database.
46
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
The kernel can also be configured to perform a prepaid query (optional feature) when a reject message is reached, for example, to cancel an earlier-made reservation.
5.2.2.1
Number conversion
Having received the recipient's request for an MM, the kernel performs number conversion for the MSISDN/MDN number in the request. The MSISDN/MDN number is converted from a national format to the international address format, for example, the MSISDN/MDN 0707778888 can be converted to +358707778888. For further information, see About number conversion (PDF Operating Guide ).
5.2.2.2
Fetching MM-O from database

The kernel fetches the MM-O from the database for processing. If the requested MM-O is not found in the database (for example, it has expired and been deleted, the kernel sends an error message to the recipient. For information about the error message text, see Error messages to mobile terminals (PDF Message Handling).
5.2.2.3
Verification of recipient
The kernel verifies that the subscriber who sent the request for an MM is the intended recipient. This is done by checking the MSISDN/MDN in the request against the recipient MSISDN/MDN in the MM in the database. If the MSISDNs/MDNs match, the kernel proceeds to the next phase of processing. If the MSISDNs/MDNs do not match, the kernel checks the IMSI in the request against the recipient IMSI in the MM in the database. If the IMSIs match, the kernel proceeds to the next phase of processing. If they do not match, the kernel sends an error message to the requesting mobile terminal. For information about the error message text, see Error messages to mobile terminals (PDF Message Handling).
5.2.2.4
Barring based on terminal type

Operators may control which terminal types are allowed in their network. Terminal types are controlled by establishing barring rules for both sending and receiving mobile terminals via a terminal type white list. For configuration instructions, see Configuring barring of messages based on terminal type (PDF Operating Guide).
5.2.2.5
Prepaid query
If the optional feature in advance credit check (IACC) is enabled in the MMS Center, the kernel can make an IACC query to the prepaid system at this point, for example, to commit an earlier-made reservation or to deduct money from the subscriber's account if the credit was checked when the MM was submitted. When the prepaid query is made depends on the MMS Center configuration: The prepaid query can be made when the kernel has verified that the subscriber requesting the MM is the intended recipient.
DN01197872 Issue 10-0
Id:0900d8058041dd4a
47
Message Handling
The prepaid query can be made when the kernel receives an acknowledgement of the MM delivery.
For further information, see IACC overview (PDF In Advance Credit Check Interface Guide).
5.2.2.6
Content adaptation
The optional content adaptation feature enables converting the MM to a format suitable for the MM recipient's mobile terminal. Content adaptation can involve, for example, image conversions or dropping unsupported media content from the MM. It can be configured in EAIF configurations whether or not an application allows content adaptation. For more information, see Application interface configuration parameters (PDF EAIF and External Applications Configuration Guide). For AO messages, the external application may send an indication whether it allows or denies performing content adaptation for specific MMs. This indication overrides the setting made in the EAIF configuration. Either the kernel configuration or profile information fetched from the subscriber database may also specify whether or not content adaptation is performed. This overrides both of the previous settings. When the kernel receives the MM recipient's request for an MM, it checks the information in the MM-O in the database to see whether or not content adaptation needs to be performed. If the MM-O indicates a need for content adaptation, the kernel uses the multimedia message adaptation engine (MMAE) subsystem or the standard transcoding interface (STI, optional feature) to convert the MM to a suitable format. When only internal content adaptation is used (that is, STI is not used), and if terminal capability information for the MM recipient's terminal type is not defined in the MMAE configuration, content adaptation is performed either based on default terminal capability information, or not performed at all (depending on the kernel configuration). In the latter case, the kernel sends the original MM to the recipient. During the process of content adaptation, unsupported content may be dropped from the MM or the content adaptation process may fail. In these cases, the original MM can be sent to a legacy phone support application through the EAIF. If the optional feature content adaptation per terminal type is used, and if an MM has multiple recipients, it is possible to optimise the content adaptation of the MM so that it is performed only once per terminal type per front-end server. If so configured, the adapted message can be stored in a cache and re-used later when another recipient with the same terminal type is retrieving the message from the MMS Center. For further information, see Content adaptation overview (PDF Content Adaptation Guide and Content adaptation per terminal type overview (PDF Content Adaptation Per Terminal Type Guide).
5.2.2.7
Routing rules
When content adaptation is performed, the process may involve dropping some content from the MM. The kernel configuration may define that in this case, the original MM must be routed to a legacy phone support application. If content adaptation has been performed, the kernel reads the MM routing rules, and if an applicable rule is found, it adds the application ID of the legacy phone support appli-
48
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
cation to the MM-O and routes it to the EAIF. The converted MM is still sent to the recipient's mobile terminal. For further information, see About routing rules (PDF Operating Guide).
5.2.3
Delivering MM
Mobile-terminated MM Having processed the mobile recipient's request for an MM, the kernel sends the requested MM to the WAPGWIF. The WAPGWIF processes the MM, for example, by performing address hiding, or by performing PDU downgrading according to the MMS version of the recipient's mobile terminal, and sends the MM to the WAP/IP gateway. Having received the MM, the recipient's mobile terminal sends an acknowledgement of this to the MMS Center through the WAPGWIF. The WAPGWIF forwards the acknowledgement to the kernel which deletes the MM from the MMS Center database (and possibly performs a prepaid query). Application-terminated MM When the kernel has determined an MM to be AT, it routes the MM to the EAIF. The EAIF can, for example, modify the sender address by replacing it with an anonymous address (if address hiding was requested and is enabled) or by encrypting it. The EAIF can also perform PDU downgrading. Having processed the MM, the EAIF sends it to the external application. Having received an acknowledgement from the external application that it received the MM, the EAIF deletes the MM from the database. For further information on sender address encryption, see PDF External Application Developer's Guide.
5.2.4
MM expiry
Both MT and AT MMs can expire in the database: MT MMs expire if the MM recipient does not request the MM within the expiration time. AT MMs expire if the MM cannot be sent to the external application within the expiration time.
Each MM contains an expiry time specified in the MM sender's mobile terminal settings, and the MMS Center has its own configurable expiry time for all MMs. The shorter of these times is used to determine when the MM expires. Expired messages can be configured to be either deleted from the database or routed to an external application, for example, the legacy phone support application. If expired messages are routed to the legacy phone support application, they are not deleted from the database until the message has been delivered to the legacy phone support application. The kernel can also be configured to perform a prepaid query when an MM expires, for example, to cancel an earlier-made reservation. For information on configurations related to expired MMs, see Configuring expiry times for undelivered MMs, delivery reports and read-reply reports and Configuring legacy
DN01197872 Issue 10-0
Id:0900d8058041dd4a
49
Message Handling
phone support for expired MMs (PDF Operating Guide ), and IACCIF configurations overview (PDF In Advance Credit Check Interface Guide).
5.2.5
Legacy phone timer

If the mobile MM recipient does not request the MM within the time configured with the polling rule for legacy phone support, a copy of the MM can be routed to the legacy phone support application. After this, the recipient can still retrieve the MM in the MMS Center until the MM expires. The kernel can also be configured to perform a prepaid query when an MM reaches the time specified in the legacy phone timer, for example, to commit an earlier-made reservation. For information related to the configurations, see Configuring legacy phone support for unfetched MMs (PDF Operating Guide) and IACCIF configurations overview (PDF In Advance Credit Check Interface Guide).
50
Id:0900d8058041dd4a
DN01197872 Issue 10-0
Message Handling
Delivery report processing
6 Delivery report processing

Delivery reports are generated in the MMS Center. In those cases when MMs are routed to recipients in other operators' networks, delivery reports may also be received from the inter-MMS Center through the EAIF (as they were generated in the remote MMS Center). Delivery reports are generated and sent to the MM sender only if the MM sender requests them and the MMS Center configuration allows them. The MMS Center delivery report contains information about the status of the message delivery, which can be either 'retrieved', 'rejected' or 'expired'. If the delivery report is received via the inter-MMS Center, it may indicate other statuses as well as specified in the OMA Multimedia Messaging Service Encapsulation Protocol Version 1.2 document. The MMS Center sends the delivery report as a code number, and the mobile terminal converts it to text format according to the subscriber's language selection. In the MMS Center, a delivery report is processed as an individual message, separate from the MM which it refers to. This means that, for example, in configuration parameters and database fields related to delivery reports, the terms 'sender' and 'recipient' refer to the sender and recipient of the delivery report. In the delivery report database table, the sender ('from'-field) indicates the address of the MM recipient and the recipient ('to'-field) indicates the address of the delivery report recipient.
MMS Center database
Delivery report for MO MM MM sender = Delivery report recipient
Delivery report for AO MM
External application MM sender = Delivery report recipient Inter-MMS Center
WAPGWIF
Kernel
EAIF Delivery report from a remote MMSC
MM recipient
Figure 16
Receiving and sending delivery reports
6.1
Generating a delivery report

How a delivery report is generated in the MMS Center depends on whether the original MM was sent to a mobile terminal or to an external application. The MMS Center kernel checks already when the MM is being processed whether a delivery report is requested for an MM, and whether the MMS Center configurations allow this request. If a delivery report is both requested and allowed, the request is written to the MM-O. At the time a delivery report is about to be generated, the subsystems responsible for the generation read this information in the MM-O and act accordingly.
DN01197872 Issue 10-0
Id:0900d805802cd7ea
51
Message Handling
With MT MMs, the kernel generates the delivery reports. Having received the acknowledgement from the MM recipient through the WAPGWIF, the kernel checks if the MM-O contains a request for a delivery report and generates one if it is requested. The delivery report is generated only if it was requested by the MM sender and if it is allowed in the MMS Center configuration: If the MM sender is a mobile subscriber, the kernel configuration determines whether or not requesting a delivery report is allowed. If the MM sender is an external application, the EAIF configuration specifies whether or not the particular application is allowed to request delivery reports. Furthermore, even if the EAIF configuration allows the delivery report request, the kernel configuration may specify that external applications are not allowed to request delivery reports, in which case no delivery report is generated. The MM recipient's acknowledgement of the received MM may also indicate that the MM recipient denies sending a delivery report to the MM sender. In this case, no delivery report is generated, unless the delivery report denial is overridden by the application-specific EAIF configurations. In the case of MM rejections as well, the kernel can still generate and send a delivery report after receiving the reject message from the MM recipient's mobile terminal. Based on the kernel configuration, MMs can also expire in the MMS Center database, and the kernel can generate delivery reports for the expired MMs. With AT MMs, the EAIF generates the delivery reports. When an external application has received an MM, it sends an acknowledgement to the EAIF. The EAIF checks if the MM-O contains a request for a delivery report, and then generates the delivery report and sends it to the kernel. With AT MMs that were sent to a remote MMS center, the delivery report can also be received via the inter-MMS Center, in which case the EAIF just forwards it to the kernel. If the delivery report is generated for an MO-AT MM that is a reply to an alias address, the WAPGWIF converts the application address to the alias address before sending it to the sender of the MM.
In the case of multiple recipients for AO MMs, the generation of delivery reports is affected by whether or not the partial success code is in use. For further information, see the description for parameter Send partial success response to application in Application interface configuration parameters (PDF EAIF and External Applications Configuration Guide).
6.2
Delivery report processing in the kernel

The following figure illustrates the processing that the kernel does when it has received a delivery report request and generated a delivery report.
52
Id:0900d805802cd7ea
DN01197872 Issue 10-0
Message Handling
DR routing rules MT or AT? MT Location information from WAPGW (optional) or MNP query and address resolution (optional) Domain information mapping (optional) AT Application ID added to routing information in DR
MNP query to messages from inter-MMSC Saving the DR to database as DR-O Routing the DR to EAIF
DR routing rules Routing the DR to WAPGWIF
If sending fails, DR-O saved to database

Figure 17 Delivery report processing in kernel
Removing DR-O from DB
The phases of delivery report processing as the following: 1. The kernel reads the delivery report (DR) routing rules based on the delivery report recipient address, and the ones based on which external application or domain the EAIF received the MM from. The latter two options can be used, for example, in inter-MMS Center routing. 2. Based on the delivery report routing rule information, the kernel determines if the delivery report recipient is a mobile subscriber or an external application. 3. With mobile-terminated DRs, the processing goes as follows: a) The kernel checks if the location information (the recipient's IMSI or SGSN address) has been received from the WAP gateway (when the optional feature location information from WAP gateway is enabled). If not, then the kernel can initiate MNP query and address resolution using the MAP/SIGTRAN, MAP/SS7, XML or ENUM interface plugin (optional features). b) The kernel maps the recipient's MSISDN/MDN (or IMSI, if available) to domain information if domain mapping lists have been configured. c) The kernel reads the delivery report routing rules based on the recipient network address, and the ones based on the IMSI and domain if these are available (for example, through an MNP request or domain mapping). d) The kernel routes the delivery report to the WAPGWIF which in turn sends the delivery report to the recipient. e) If sending the delivery report to the mobile terminal fails (PPG or the SMS Center is down), the delivery report is saved to the MMS Center database as an delivery report object (DR-O). Sending is retried according to the MMS Center configuration. 4. With application-terminated DRs, the processing goes as follows: a) The kernel adds the application ID to the routing information in the delivery report.
DN01197872 Issue 10-0
Id:0900d805802cd7ea
53
Message Handling
b) If the delivery report was received from the inter-MMS Center, an MNP request is done if it is allowed by the EAIF and inter-MMS Center configurations. For further information, see the description for parameter Allow number portability for recipient in Application interface configuration parameters (PDF EAIF and External Applications Configuration Guide). c) The kernel saves the delivery report as an DR-O to the database and to the application message queue (AMQ) tables. d) The kernel routes the DR to the EAIF. The EAIF sends the DR to the appropriate external application or to the Inter-MMS Center. e) After receiving a positive acknowledgement, the EAIF removes the DR-O from the database.
6.3
Sending a delivery report

Sending the delivery report depends on whether the delivery report recipient is a mobile subscriber or an external application: If the delivery report recipient is a mobile subscriber, the kernel sends the delivery report to the WAPGWIF. The WAPGWIF processes the delivery report, for example, by performing number conversion, converts it from internal to external format, and sends the delivery report to the MM sender's mobile terminal through the PPG and the SMS Center, or only through the SMS Center, if the optional feature integrated PPG is used. If the delivery report is destined to a mobile subscriber who has replied to an alias address, the WAPGWIF converts the application address (From field of delivery report) to the alias address before sending it to the sender of the MM. If the delivery report recipient is an external application, the kernel routes the delivery report to the EAIF which adds information to it as extension headers (such as IMSI information, if available) and sends it to the recipient application.
Delivery reports are only stored to the MMS Center database if sending to the mobile terminal fails (PPG is down - or the SMS Center in case integrated PPG is used), or if a delivery report is sent to an external application through the EAIF, in which case the DRO is stored in the application message queue (AMQ) table in the database.
54
Id:0900d805802cd7ea
DN01197872 Issue 10-0
Message Handling
Read-reply report processing
7 Read-reply report processing

A read-reply report can be sent to inform the sender of a multimedia message (MM) that the recipient either read the MM or deleted it without reading. Read-reply reports can be sent to both mobile subscribers and external applications. If the MM sender requested a read-reply report, the MM recipient's mobile terminal may generate a read-reply report which indicates that the recipient either read the MM or deleted the MM without reading it. The MMS Center processes the received read-reply report and sends it to the MM sender (see the following figure). Depending on the mobile terminal type, the read-reply report it generates may also be an MM PDU M-Send.req, instead of the actual read-reply report PDU M_Read_Rec.ind. In this case, the MMS Center processes the received read-reply report as a new MM, see Multimedia message processing (PDF Message Handling). OMA MMS 1.0 does not support PDU M_Read_Rec.ind. The MMS Center checks already when processing the MM whether a read-reply report was requested for the MM, and whether the MMS Center configurations allows this request. Allowing a request for a read-reply report depends on whether the MM sender is a mobile terminal or an external application: If the MM sender is a mobile subscriber, the kernel configuration determines whether or not requesting a read-reply report is allowed. If the MM sender is an external application, the EAIF configuration specifies whether or not the particular application is allowed to request read-reply reports. Furthermore, even if the EAIF configuration allows the read-reply report request, the kernel configuration may specify that external applications are generally not allowed to request read-reply reports, in which case no read-reply report request is delivered to the recipient mobile terminal.
If a read-reply report was requested and allowed, the request is written to the MM-O. When the MM is about to be delivered to the MM recipient, the kernel reads this information in the MM-O and adds a request for a read-reply report in the delivered MM. When the MM recipient receives the MM and either reads or deletes it without reading, the mobile terminal settings determine whether or not the mobile terminal sends a readreply report to the MMS Center. In the MMS Center, a read-reply report is processed as an individual message, separate from the MM which it refers to. This means that, for example, in configuration parameters and database fields related to read-reply reports, the terms 'sender' and 'recipient' refer to the sender and recipient of the read-reply report.
DN01197872 Issue 10-0
Id:0900d8058035c801
55
Message Handling
MMS Center database
Read-reply report for MO MM MM sender = Read-reply report recipient
Read-reply report for AO MM
WAPGWIF
Kernel
EAIF
MM sender = Read-reply report recipient
Read-reply report about MT MM MM recipient = Read-reply report sender
Read-reply report from a remote MMSC
Inter-MMS Center
Figure 18
Receiving and sending read-reply reports
7.1
Receiving read-reply reports

The MMS Center receives read-reply reports via the WAPGWIF and via the EAIF, depending on whether the original MM was sent to a mobile terminal or to a remote MMS Center through the inter-MMS Center. With MT MMs, the kernel receives the read-reply reports from mobile terminals through the WAPGWIF. The WAPGWIF wraps the read-reply report into an RR-O, a format used in internal processing. It also adds the sender and recipient MSISDN/MDN (and possibly the sender IMSI and SGSN address) to the RR-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. In case the MM was destined to a distribution list (optional feature), and the MMS Center receives the read-reply report from a distribution list member, the WAPGWIF maps the alias in the recipient field to the application address of the application that sent the original MM. The RR-O thus contains the application address instead of the alias. With AT MMs that were sent to a remote MMS Center, the kernel can receive readreply reports from the inter-MMS Center through the EAIF. The EAIF processes the received read-reply reports in the same way as MMs, for example, by checking capacity restrictions and validating the message (see Receiving new MM, PDF Message Handling).
7.2
Read-reply report processing in the kernel

The kernel processes the read-reply reports and determines whether they are accepted for delivery or rejected. The following figure illustrates the phases in read-reply report processing in the order they are gone through in the kernel. The grey boxes in the figure indicate processing phases after which the kernel may either reject the read-reply report or continue with processing to the next phase.
56
Id:0900d8058035c801
DN01197872 Issue 10-0
Message Handling
Number conversion for sender and recipient Location information from WAPGW (optional) and barring for sender
MNP (optional) and barring for sender
Profile query for sender (optional) Barring based on sender profile (optional) Routing rules based on MSISDN/MDN MNP (optional) and barring for recipient Routing rules based on IMSI/domain MT read-reply report AT read-reply report
Profile query for recipient (optional) Barring based on recipient profile (optional) Prepaid query for sender (optional) Prepaid query for recipient (optional) Store read-reply report to database
Prepaid query for sender (optional) Store read-reply report to database Route read-reply report to EAIF
Message rejection possible at this stage.
Send read-reply report to WAPGWIF
Message processing continues to next stage.
Figure 19
Read-reply report processing in the kernel
The phases of kernel read-reply report processing are the following: 1. The kernel performs number conversion for the read-reply report sender's and recipient's MSISDN/MDN. 2. The kernel checks if optional feature location information from WAP gateway is enabled, and if an SGSN address is available. If the WAP gateway has provided the SGSN address, the kernel maps it to the appropriate roaming class that is used for charging. If the SGSN address is not available, the kernel check the subscriber barring and domain information using the mobile number portability (MNP) and address resolution (optional feature) as follows: checking the lists of imported and exported numbers mapping the MSISDN/MDN or IMSI to domain information requesting the sender's IMSI using the MAP/SIGTRAN, MAP/SS7 or the XML interface plugin, and requesting the sender's domain using the ENUM interface plugin (optional features) checking the MSISDN/MDN, IMSI and domain barring lists for the sender
DN01197872 Issue 10-0
Id:0900d8058035c801
57
Message Handling
3. The kernel makes a profile query to get the read-reply report sender's profile from the subscriber database. The profile query may return barring and prepaid information. 4. The kernel performs barring based on the read-reply report sender's profile information. Optionally, the sender's profile information may also contain virtual operator information, which is needed for computing roaming classes. After barring is done, roaming classes are computed by mapping roaming information to an integer value. 5. The kernel checks the read-reply report routing rules. Based on the read-reply report routing rule information, the kernel determines if the read-reply report recipient is a mobile subscriber or an external application. The kernel reads the routing rules both before and after performing MNP and barring for the recipient: First, the kernel reads the routing rules based on the read-reply report recipient address. If the read-reply report is determined to be AT, no MNP request for the recipient is made. Having performed MNP and barring for the recipient, the kernel can read the routing rules based on the recipient network address, and the ones based on the IMSI and domain if these are available (for example, through an MNP request or domain mapping). 6. The kernel applies MNP and address resolution and checking barring (optional feature) for the read-reply report recipient as follows: Checking the lists of imported and exported numbers Mapping the MSISDN/MDN or IMSI to domain information Requesting the recipient's IMSI using the MAP/SIGTRAN, MAP/SS7 or the XML interface plugin, and requesting the recipient's domain using the ENUM interface plugin (optional features) Checking the MSISDN/MDN, IMSI and domain barring lists for the recipient 7. The kernel checks the routing rules based on the recipient's IMSI and domain information to find out whether the read-reply report recipient is a mobile subscriber or an external application. 8. The kernel processes mobile-terminated (MT) read-reply reports as follows: a) Querying the read-reply report recipient's profile from the subscriber database The profile query may return barring and prepaid information. b) Barring based on read-reply report recipient's profile information Optionally, the recipient's profile information may also contain virtual operator information, which is needed for computing roaming classes. After barring is done, roaming classes are computed by mapping roaming information to an integer value. c) Performing a prepaid check for the read-reply report sender d) Performing a prepaid check for the read-reply report recipient e) Sending the read-reply report to the recipient via the WAPGWIF f) If sending the read-reply report to the mobile terminal fails (PPG or the SMS Center is down), the kernel saves the read-reply report to the MMS Center database. Sending is retried according to the MMS Center configuration. 9. The kernel processes application-terminated (AT) read-reply reports as follows: a) Performing a prepaid check for the read-reply report sender b) Storing the read-reply report to the database
58
Id:0900d8058035c801
DN01197872 Issue 10-0
Message Handling
c) Routing the read-reply report to the EAIF, which is then responsible for routing it to the recipient application. The phases of read-reply report processing are very similar to those of processing a submitted MM. For information on the MM processing phases, see MM processing in the kernel (PDF Message Handling ).
7.3
Sending read-reply reports

Sending the read-reply report depends on whether the read-reply report recipient is a mobile subscriber or an external application: If the read-reply report recipient is a mobile subscriber, the kernel sends the readreply report to the WAPGWIF. The WAPGWIF processes the read-reply report, for example, by performing number conversion, and sends the read-reply report to the recipient's mobile terminal through the PPG and the SMS Center, or only through the SMS Center, if the optional feature integrated PPG is used. If the read-reply report recipient is an external application, the kernel routes the read-reply report to the EAIF which adds information to it as extension headers (such as IMSI information, if available) and sends it to the recipient application.
Read-reply reports are only stored to the MMS Center database if sending to the mobile terminal fails (PPG is down - or the SMS Center in case integrated PPG is used), or if a read-reply report is sent to an external application through the EAIF, in which case it is stored in the application message queue (AMQ) table in the database.
DN01197872 Issue 10-0
Id:0900d8058035c801
59
Message exchange with external applications
Message Handling
8 Message exchange with external applications

Message exchange with external applications occurs when a multimedia message (MM) is application-originated or application-terminated, or when an MM needs to have additional processing by a filtering application before it is delivered to the recipient. Delivery reports and read-reply reports can be sent to external applications (if requested by an application and allowed in the MMS Center configuration), and received from the inter-MMS Center application. The MMS Center can use either the MM7 protocol specified by 3GPP TS 23.140 or the proprietary EAIF protocol. The following MMS Center functions are implemented as external applications using the EAIF protocol: Routing messages to a legacy phone support application Exchanging messages with the Internet mail gateway Exchanging messages with other operators' MMS Centers
For information on configuring interfaces to external applications, see EAIF-related configurations overview (PDF EAIF and External Applications Configuration Guide ). For information about the supported protocols, see MM7 protocol and EAIF protocol (PDF External Applications Developer's Guide). Service level agreements A service level agreement (SLA) controls external applications' access to the MMS Center. The EAIF checks that an incoming message does not violate any of the restrictions set in the SLA. If it does, the message can be rejected or the violation may be overridden (for example, a delivery report request can be disabled in an MM). For further information on the SLA, see Configuring the interface between MMS Center and an external application (PDF External Applications Developer's Guide).
8.1
Routing MMs to legacy phone support application

The MMS Center legacy phone support enables the delivery of multimedia messages (MMs) to recipients who do not have a multimedia-enabled terminal or whose mobile terminal does not support all types of content included in the MM. If the delivery to a remote MMS Center fails because the message size is too large or the destination cannot be found, the MM can also be routed to another application, for example legacy phone support application. Regarding forwarding, MMs can be configured to be forwarded directly to an alternative destination, such as the legacy phone support application. MMs are routed to a legacy phone support application based on the kernel's MM routing rules. The routing rules cover different situations when subscribers may not be able to access MMs by retrieving them from the MMS Center. For further information about legacy phone support and the configurations related to it, see About legacy phone support (PDF Operating Guide). The operator can deny sending application-originated MMs to the legacy phone support application. The configuration is done per application. For further information, see Appli-
60
Id:0900d805803ab694
DN01197872 Issue 10-0
Message Handling
cation interface configuration parameters (PDF EAIF and External Applications Configuration Guide).
8.1.1
Routing based on profile information

The following figure illustrates the scenario where MM routing to the legacy phone support application happens based on profile information from the subscriber database (optional feature).
1 Sender 4 WAPGWIF 5
MMS Center database
3 6 Kernel 2 EAIF Legacy support
Recipient
Subscriber database
Figure 20
Legacy phone support with subscriber database
The process is the following: 1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF wraps the MM into an MM-O (a format used in internal processing), and forwards the MM-O to the kernel. 2. During the processing, the kernel queries the recipient's profile from the subscriber database, and receives information about the recipient's terminal capabilities ('Unknown', 'MMS video capable', 'MMS capable' or 'Not MMS capable'). 3. The MMS Center stores the MM-O in the database. 4. The MMS Center sends an acknowledgement to the sender, indicating that the MM has been accepted for delivery. From here the processing continues based on the terminal capabilities information in the profile. The kernel's MM routing rules may define that in the following cases, sending a notification to the recipient (step 5) is not done, and the MM must be routed directly to the legacy phone support application (step 6). The profile indicated that the recipient does not have a multimedia-enabled terminal. The MM contains video content and the profile indicated that the recipient's multimedia-enabled terminal does not support it.
DN01197872 Issue 10-0
Id:0900d805803ab694
61
Message Handling
5. Optional: If the recipient's profile indicated that the recipient's terminal capabilities are unknown, the MMS Center sends a notification to the recipient about a new MM, which the recipient can then retrieve from the MMS Center. If the recipient does not retrieve the MM within a configured time (the 'legacy phone timer'), the MM can be routed to the legacy phone support application. For information, see Routing of unfetched MMs (PDF Message Handling ). 6. Based on the terminal capabilities information in the profile, the MMS Center routes the MM to the legacy phone support application. A delivery report is generated and sent to the MM sender (if requested). For further information about legacy phone support based on profile information and the configurations related to it, see Legacy phone support based on profile information (PDF Operating Guide).
8.1.2
Routing of unfetched MMs

The following figure illustrates the scenario where MM routing to the legacy phone support application happens when a MM is not fetched within the configured period of time (the 'legacy phone timer'). If the profile information queried from the subscriber database (optional feature) indicates that the recipient's terminal capability is 'MMS capable', unfetched MMs cannot be routed to the legacy phone support application.
1 Sender 3 WAPGWIF 4 6 Recipient

Figure 21
MMS Center database
2 5 Kernel EAIF Legacy support
Legacy phone support with unfetched MMs
The process is the following: 1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF 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. 3. The MMS Center sends an acknowledgement to the sender, indicating that the MM has been accepted for delivery. 4. The MMS Center sends a notification to the recipient about a new MM. 5. The MM is polled in the database, and if the recipient does not retrieve the MM within a configured time, the MMS Center routes a copy of the MM to the legacy phone support application. No delivery report is sent for the copy of the MM. The original MM remains in the MMS Center database until it expires.
62
Id:0900d805803ab694
DN01197872 Issue 10-0
Message Handling
6. Optional: The recipient may still send a request to the MMS Center to retrieve the MM. This is handled as normal MM retrieval: the MM is sent to the recipient and deleted from the database. For further information about legacy phone support for unfetched MMs and the configurations related to it, see Legacy phone support for unfetched MMs (PDF Operating Guide).
8.1.3
Routing of expired MMs

The following figure illustrates the scenario where MM routing to the legacy phone support application happens when a MM expires.
1 Sender 3 WAPGWIF 4
MMS Center database
2 5 Kernel EAIF Legacy support
Recipient
Figure 22 Legacy phone support with expired MMs
The process is the following: 1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF 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. 3. The MMS Center sends an acknowledgement to the sender, indicating that the MM has been accepted for delivery. 4. The MMS Center sends a notification to the recipient about a new MM. 5. If the recipient does not retrieve the MM before it expires, the kernel's MM routing rules may define that in this case, the MM is routed to the legacy phone support application. If no routing rule for expired MMs is configured, the MM is simply deleted when it expires. Regardless of whether the MM is routed to the legacy phone support application or deleted, a delivery report is always generated and sent to the MM sender, indicating that the MM expired. For further information about legacy phone support for expired MMs and the configurations related to it, see Legacy phone support for expired MMs (PDF Operating Guide).
DN01197872 Issue 10-0
Id:0900d805803ab694
63
Message Handling
8.1.4
Routing based on content adaptation

The following figure illustrates the scenario where routing to the legacy phone support application happens either because the content of the MM was adapted, or because the content adaptation process failed.
MMS Center database
MMAE
STI
2 1 WAPGWIF Recipient 3
Figure 23 Legacy phone support with content adaptation
4 Kernel EAIF
Legacy support
The process is the following: 1. The recipient sends a request to the MMS Center to retrieve an MM. Based on information about the mobile terminal type in the MM headers, the multimedia message adaptation engine (MMAE) subsystem determines that content adaptation needs to be performed for the MM before it can be delivered. 2. When the MMAE or the standard transcoding interface (STI, optional feature) platform performs content adaptation for the MM, unsupported content may be dropped, or the content adaptation process may fail. The kernel's MM routing rules may define that in this case, a copy of the original MM must be routed to the legacy phone support application. 3. The adapted MM (or if content adaptation failed, the original MM) is retrieved from the MMS Center database and delivered to the recipient. 4. A copy of the original MM is routed to the legacy phone support application. No delivery report is sent for the copy of the MM. For further information about legacy phone support when any content adaptation is performed to an MM, when unsupported MM content is dropped, or when the content adaptation fails, see Legacy phone support based on content adaptation (PDF Operating Guide).
8.2
Message exchange with Internet mail gateway

The MMS Center optional feature Internet mail gateway enables transferring MMs to and from e-mail addresses, and performing the necessary conversion from MM to e-mail format and vice versa. The Internet mail gateway application transfers messages between the MMS Center EAIF and an external mail server. It is implemented as an external application with two separate components, the mail gateway transmitter and the mail gateway receiver, both of which have their own application interface configured in the EAIF.
64
Id:0900d805803ab694
DN01197872 Issue 10-0
Message Handling
The mail gateway transmitter is a terminating asynchronous application that receives MMs from the EAIF and sends them as e-mail messages to the external mail server, having first converted them to e-mail format. The mail gateway receiver is an originating synchronous application that receives email messages from the external mail server and sends them to the EAIF, having first converted them to multimedia binary format.
For information on the external application types, see the Overview of developing external applications (PDF External Application Developer's Guide).
8.2.1
Message handling from mobile terminal to mail server

The following figure illustrates the message handling process from a mobile terminal to the mail server.
Sender
1 3 8
MMS Center database
4 5b/c 5 7 Mail gateway transmitter
5a Mail server 6
WAPGWIF
Kernel
EAIF
Figure 24
Message handling from a mobile terminal to the mail server
The process is the following: 1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF 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 kernel stores the MM-O in the database. 3. The MMS Center kernel sends an acknowledgement to the sender through the WAPGWIF, indicating that the MM has been accepted for delivery. 4. The EAIF sends the MM to the mail gateway transmitter. 5. The mail gateway transmitter sends an acknowledgement to the EAIF. Depending on the acknowledgement, the message handling continues in the following manner: a) In the case of an interim OK status, the mail gateway transmitter converts the message to e-mail format and sends it to the mail server. The EAIF starts to wait for a final status from the mail gateway transmitter. b) In the case of a permanent error, the EAIF deletes the MM from the database (and generates a delivery report, if it was requested). c) If the mail gateway transmitter sends a temporary error to the EAIF (for example, if the mail gateway transmitter is overloaded), the EAIF updates the MM status in the database. The kernel then polls the MM in the database and attempts to resend it based on the polling rule configuration. 6. Assuming that the e-mail was sent to the mail server, the mail server sends an acknowledgment to the mail gateway transmitter, indicating that the MM was accepted for processing.
DN01197872 Issue 10-0
Id:0900d805803ab694
65
Message Handling
7. The mail gateway transmitter sends the final status to the EAIF (OK, a permanent error or a temporary error). If the status was OK or a permanent error, the EAIF deletes the MM from the database. If the status was a temporary error, the MM is scheduled to be retransmitted to the mail gateway transmitter. 8. If the final status was OK or a permanent error, and if the MM sender requested for a delivery report, the EAIF generates and sends a delivery report to the MM sender.
8.2.2
Message handling from mail server to mobile terminal

The following figure illustrates the message handling process from the mail server to a mobile terminal.
MMS Center database
3 5
2 6 EAIF Mail gateway receiver
1 7 Mail server
8 9 10 11 Recipient
WAPGWIF
Kernel
Figure 25
Message handling from the mail server to a mobile terminal
The process is the following: 1. The mail server sends an e-mail message to the mail gateway receiver. 2. The mail gateway receiver converts the e-mail message to multimedia binary format and sends it to the MMS Center EAIF. 3. The EAIF wraps the MM into an MM-O (a format used in internal processing), and forwards the MM-O to the kernel. 4. The kernel 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. 5. The kernel sends an acknowledgement to the EAIF, indicating the status of MM processing. 6. The EAIF sends a similar acknowledgement to the mail gateway receiver. 7. The mail gateway receiver sends a similar acknowledgement to the mail server. 8. The MMS Center sends a notification to the recipient(s) about a new MM. 9. The recipient replies to the notification by either requesting the MM immediately or indicating deferred delivery. 10. Assuming that the recipient requested the MM immediately, the MM is retrieved from the MMS Center database and delivered to the recipient. 11. The recipient's mobile terminal acknowledges the MM delivery.
66
Id:0900d805803ab694
DN01197872 Issue 10-0
Message Handling
8.3
Message exchange with inter-MMS Center

The inter-MMS Center connection is used when the sender and the recipient are served by different MMS Centers. Operators may utilise different networks and possibly different network types and may offer different kinds of additional services for their subscribers. Therefore, the sender must send the MM to the MMS Center of his or her own operator, which routes the MM to the MMS Center of the recipient's operator. In this context, the MMS Center of the sender is called the originating MMS Center and the MMS Center of the recipient is called the terminating MMS Center. The inter-MMS Center application enables the transfer of MMs, delivery reports and read-reply reports between different operators. This application is implemented as an external application. The application has two separate components, the inter-MMS Center transmitter and the inter-MMS Center receiver, both of which have their own application interface configured in the EAIF. The inter-MMS Center transmitter is a terminating asynchronous application that sends messages from the originating MMS Center to other terminating MMS Centers according to routing rules. The inter-MMS Center receiver is an originating synchronous application that receives messages that have originated in other MMS Centers.
For information on the external application types, see Overview of developing external applications (PDF External Application Developer's Guide ). The inter-MMS Center supports the SMTP-based protocol compliant with 3GPP TS 23.140 V6.3.0 used either between a Nokia Siemens Networks MMS Center and another vendor's MMSC or between two Nokia Siemens Networks MMS Centers. Before a message is sent to another MMS Center, it is converted from MMS encapsulation protocol data unit format to MIME (multi-purpose Internet mail extensions) format, and it is also converted back to that format when the message is received from another MMS Center. Depending on configuration, the kernel may or may not be able to provide sufficient information (recipient domain name) for routing a message destined to a remote MMS Center. This is why the inter-MMS Center application configuration provides alternative ways of determining to which specific operator the message should be routed: Kernel uses both kernel and Inter-MMSC configuration to determine if the message is possible to route. The kernel routes messages to the inter-MMS Center application based on the kernel routing rules. With the configuration for inter-MMS Center and the number portability information in the lists of exported and imported numbers, kernel can check the barring between virtual operator and terminating network operators. The kernel routes messages to the inter-MMS Center application based on the interMMS Center application configuration routing rules that define how messages are routed to other operators' MMS Centers.
8.3.1
Inter-MMS Center message flow

The following figure illustrates the message flow between the local (originating) MMS Center and the other operator's (terminating) MMS Center at a general level. The figure
DN01197872 Issue 10-0
Id:0900d805803ab694
67
Message Handling
assumes that both MMS Centers involved in MM4 interworking are Nokia Siemens Networks MMS Centers and that the receiving MMS Center terminates the message.
Originating MMS Center
MMS Center database
EA 4 Inter-MMS Inter-MMS Center Center 11 transmitter receiver 5 MTA
1 3 Sender
13 WAPGWIF Kernel EAIF
12
Terminating MMS Center
MMS Center database
MTA 10 7a 6 7b 9 Inter-MMS Center receiver
WAPGWIF Recipient
Kernel
EAIF
Figure 26
Inter-MMS Center message flow
The process for handling MMs is the following: 1. The sender submits an MM (PDU M-Send.req) to the MMS Center. The WAPGWIF 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 to the sender, indicating that the MM has been accepted for delivery. 4. During the processing, the kernel notices that the recipient cannot be found in the originating MMS Center and considers the MM to be inter-MMS Center message. Before sending the MM to the inter-MMS Center transmitter through the EAIF, the kernel checks the following, and if any of the cases are true, the kernel rejects the MM: it cannot find the terminating MMS Center in the inter-MMS Center configuration a virtual operator is not allowed to send the MM to a specific terminating MMS Center
68
Id:0900d805803ab694
DN01197872 Issue 10-0
Message Handling
5.
6. 7.
8. 9. 10.
11.
12. 13.
the size of the MM exceeds a configurable maximum value in the inter-MMSC application configuration However, in the above cases, the kernel can be configured to reroute the message (through EAIF) to another application. The application configuration parameter Secondary routing for inter-MMSC transmitter EAIF specifies the application ID of this application. The inter-MMS Center transmitter sends the MM as an SMTP message to the terminating MMS Center. The message is transferred by a mail transfer agent (MTA) in both the originating and terminating MMS Center end. The inter-MMS Center transmitter can be configured to always request for a delivery report, even if the MM sender has not requested for one. In this case, the delivery report will not be delivered to the MM sender, it is only used internally. The inter-MMS Center transmitter can also send a temporary error (for example, if the inter-MMS Center transmitter is overloaded), in which case the EAIF updates the MM status in the database. The kernel then polls the MM in the database and attempts to resend it based on the polling rule configuration. When the inter-MMS Center receiver of the terminating MMS Center has received the MM, it sends it to the terminating MMS Center's EAIF. The EAIF checks for possible restrictions (for example, the capacity limit) and validates the MM. a) If no restrictions apply, the EAIF sends the MM to the kernel. b) If restrictions apply or the MM is not valid, the EAIF discards the MM and sends a temporary or permanent error status (depending on the error type) to the interMMS Center receiver. The kernel handles the MM in the same way as other application-originated MMs and sends a response back to the EAIF. The EAIF sends a status (OK, temporary error, or permanent error) to the interMMS Center receiver. The inter-MMS Center receiver sends the processing status as a .RES PDU to the originating MMS Center (if it was requested). The message is again transferred by a mail transfer agent in both the terminating and the originating MMS Center end. The originating MMS Center's inter-MMS Center receiver puts the status acknowledgement in a queue where the originating MMS Center's inter-MMS Center transmitter can read the acknowledgement and send it to the EAIF. The inter-MMS Center transmitter sends the final status to the MMS Center's EAIF. The EAIF retrieves the original MM from the database and updates its status, depending on the final status received from the inter-MMS Center transmitter. If the final status was OK or a permanent error, the EAIF deletes the MM from the database (and in case of a permanent error, generates a delivery report if it was requested). If the status was a temporary error, the MM is scheduled to be retransmitted to the inter-MMS Center transmitter.
Delivery reports and read-reply reports are transmitted between different MMS Centers in a similar fashion. The MMS Center kernel has separate routing rules for MMs, delivery reports and read-reply reports.
DN01197872 Issue 10-0
Id:0900d805803ab694
69

DN 01197872

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DN 01197872

Transféré par

Droits d'auteur :

Formats disponibles

Nokia Siemens Networks MMS Center, Rel.6.0 Operating Documentation, PDF v.

Important Notice on Product Safety

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

DN01197872 Issue 10-0

DN01197872 Issue 10-0

DN01197872 Issue 10-0

DN01197872 Issue 10-0

DN01197872 Issue 10-0

About this document

1 About this document

Issue 10-0 en 9-0 en

For release MMS Center 3.2. Updated chapters:

DN01197872 Issue 10-0

About this document

DN01197872 Issue 10-0

Message handling overview

2 Message handling overview

The following sections present an overview of MMS message handling.

Message handling in the network

MMS notification (over SMS)

MMS message flow in the GPRS and WCDMA networks

DN01197872 Issue 10-0

Message handling overview

MSC/VLR/HLR BSC/PCF BSC/PCF BTS

MMS notification (over SMS)

MMS message flow in the CDMA2000 network

DN01197872 Issue 10-0

Message handling overview

Message handling in the MMS Center

MMS Center database

DN01197872 Issue 10-0

Message handling overview

DN01197872 Issue 10-0

Message types and storage

3 Message types and storage

DN01197872 Issue 10-0

Message types and storage

text/plain Content image/jpeg

MM and the multi-part structure

DN01197872 Issue 10-0

Message types and storage

MMS Center message storage

DN01197872 Issue 10-0

Message types and storage

Protocol data units

DN01197872 Issue 10-0

Message types and storage

PDU type M-Acknowledge.ind

PDU types (Cont.)

MM4 PDU types

DN01197872 Issue 10-0

Message types and storage

PDU types MM4_Read_reply_report.REQ

DN01197872 Issue 10-0

Message flow scenarios

4 Message flow scenarios

Mobile-originated - mobile-terminated MMs

DN01197872 Issue 10-0

Message flow scenarios

MMS Center database

DN01197872 Issue 10-0