Notification Protocol in MMS

1
Notification Protocol in MMS

• June 2001

Erez Reinschmidt, Rami Neudorfer
3GPP TSG-T2 SWG37 Braunschweig, Germany 27-29
June, 2001
T2M010070
2
The Problem

• Notification of events is a major feature of MMS
• MMS Relay is connected to external servers
  (Email, Voicemail) and needs to get notifications
  from them in order to pull messages, convert them
  to MMS format, and send notifications to UA
• Currently, there are no standard methods of doing
  so
• Polling is a costly, not timely enough,
  inefficient alternative and creates huge traffic
  loads which, for large number of MMS subscribers
  may be unacceptable

3
The Challenge

• Enable notification of events occurring in
  external servers or VAS applications connected to
  MMS, such as
• A new mail message has arrived from an external
  mail server
• An external application sends a request for an
  online game
• Your pre-paid credit is below some threshold
• But also, enable notification of events occurring
  on a large variety of other systems
• External email accounts (E.g. You have a new
  Hotmail message)
• External voice mail systems (E.g you have a
  voice mail from your son)
• Calendars (E.g. Your meeting starts in 5
  minutes or Your meeting was cancelled)
• Information services stock exchange, news,
  weather reports, changes in web pages, etc.
• Fax servers
• More

4
Status

• The need for a notification protocol as part of
  MM3 (Interface to External servers) was
  recognized in 23.140 (release 4 of MMS stage 2
  document)
• The SNAP protocol presented in this document,
  addresses the need in a timely and well supported
  manner
• We propose to 3GPP T2 to adopt this protocol and
  to submit it to the IETF for a rapid process of
  standardization

5
Roadmap for Solution

• The SNAP protocol for notification is proposed
• The notification protocol is based on Standard
  Internet protocols
• Major E-mail vendors, and Comverse , have already
  implemented this in their products
• The protocol was reviewed and approved by several
  E-Mail vendors, and service providers
• This presentation is intended to encourage
  discussion , enlist support, and trigger
  suggestions for changes and improvements in this
  protocol, and then submit it, to IETF through
  IETF - 3GPP Liaison

6
The concept (The general case not limited to
MMS)

• Centralize the subscribers notification logic in
  a single notification component as part of the
  MMS relay
• A variety of messaging and information services
  are possible sources of events
• The notification component will
• Analyze each event, based on user preferences,
  configuration and personalization and decide
  whether the user needs to be notified.
• Decide where to send the notification
  messageE.g. to the subscribers UA, to an email
  account, etc. (In certain cases several
  destinations may exist simultaneously.)
• Compose the outgoing messageto MMS recipient
• Use a variety of other services to deliver the
  messagewhen needed MMS, SMS, SMTP, Instant
  Messaging, PPG

7
The notification protocol

• The protocol is the means by which the sources
  report events to the notification server
• Requirements
• Using a standard Internet protocol as a basis.
• Easy to understand, easy to use.
• Efficient, scalable.
• Requires minimal development effort from the
  sources.
• Can be easily extended to support future
  requirements.

8
The SNAP Protocol

• SNAP Simple Notification and Alarm Protocol
• Upon a new event, the Source sends a notification
  request using the SNAP
• A notification component , within the MMS
  Relay/Server receives the request and decides
  what to do with it
• The MMS relay/Server sends the notification
  message to one or more notification destinations

9
The SNAP Protocol

• Uses HTTP as the transport protocol.
• Current implementation
• The notification request is a list of standard
  message types, similar to the way requests are
  sent to search engines, etc.
• Handles mostly messaging and mailbox events.
• For example
• POST http//www.sonera.com/Notify ?
  RequestTypeNewMsg ServerNameHotmail.com
  MailboxNamePetri Timonen Fromrami.neudorfer_at_co
  mverse.com ToBigPetri_at_hotmail.com
  SubjectMMSStandardization UrgentYes
  ProtocolVersion1.0.0.0 ApplicationNameHotmail
  ApplicationVersion3.2

10
Current status

• Notification server with notification protocol
  implementation are part of Unified Messaging
  offerings.
• Major E-Mail Vendors have integrated this
  protocol in their products
• Isocor (Critical Path) IMS version 5.1 and up
• Integrated in iPlanet messaging servers
• Implemented by Microsoft SendIt, Cyntegra
• Advanced discussions with OpenWave
• Comverse messaging platform

11
Top Level View