T2-010470 MM7

1
T2-010470MM7 Use Cases, Goals and Requirements

• Jan Geiger
• MATERNA GmbH
• 3GPP T213 May 14-18, 2001 Pusan, South Korea

2
Overview

• Architecture of an external MMS application
  environment
• Use case and goal analysis for external MMS
  applications
• Requirements for protocols at reference point MM7
• Proposals for Rel-5 drafting

3
Architecture
Location
Local Subscriber Profiles
Presence
VASP Profiles
e.g. Travel Assistant App
Network Operator
e.g. Community Services
Sports
Gateways
Traffic
Application Server
Weather
MMS Relay/Server
MM7
Value AddedService Provider(VASP)
Content / Service Providers
Network Operator
4
Roles

• Content Creator / Service Provider out of scope
• Value Added Service Provider (VASP)
• Provides remote MMS Application Server
• Provides MMS Applications, making use of Services
  (location, presence, content, ...)
• Has commercial agreements with Content Creators
  and Service Providers (such as the Network
  Operator)
• Network Operator -
• Provides access to MMSE via MM7
• Has commercial agreements with VASP
• Message Termination and Routing
• VAS Provisioning and 3rd party billing
• Consumer
• Is customer of the Network Operator
• May subscribe to VASPs services

5
Basic goals

• Application Server needs a dedicated,
  bi-directional interface to MMS Relay/Server
  (MM7)
• If possible, find an appropriate base protocol
  based on existing internet standards
• Minimum feature set -- see Soneras paper
  (T2-010134)
• MM Delivery from MMS R/S to VAS Application
  MM7_delivery
• MM Delivery from VAS Application to MMS R/S
  MM7_submission
• Resulting from commercial relationship between
  VASP and Network Operator
• Enable session authentication between Application
  Server and MMS Relay/Server

6
Sample use cases

• UMS Notifications (Voice/Email/Fax Im Away
  multimedia announcement)
• Push-type information services (location-based
  weather and traffic, sports, jokes, ...)
• Pull-type information services (stock quote
  request, ...)
• Push-reply-type services (opinion polls, quiz
  games, ...)
• List servers (public or private message boards,
  MMS Publisher, chat, ...)
• Instant Messaging gateway
• Make all these available to prepaid subscribers

7
Use Case analysis

• Push-type information services
• Use submit-type operation for sending MM to
  service subscribers
• Multiple recipients per MM7 operation should be
  possible for efficiency reasons
• Delivery reports towards VASP desirable, should
  include reference to original message
• Returning a message ID for original message
  required to evaluate delivery reports
• Application-specific sender address in original
  message would be useful (for collecting replies
  to VAS message)
• Some billing issues see below

8
Use case analysis

• Pull-type information services
• Require an application-specific address compliant
  to MMS addressing, e.g. MSISDN or RFC822
• RFC822 more convenient to use (e.g.
  millionaire_at_mmsgames.operator.net) than MSISDN
  MSISDN would require to send a keyword
  identifying the desired service
• Again, some billing issues see below

9
Use case analysis

• List servers (public or private message boards,
  MMS chat, ...)
• Consumer may subscribe to a list, cancel a list,
  search a list, ... Like we know it from Email
  list servers
• List server should reside on Application server
  rather than be a part of MMS relay/server
• Consumers may be owners, members and/or authors
  of lists
• Again, multiple recipients per MM7 submit-type
  operation should be possible for efficiency
  reasons
• Interesting billing models, e.g. revenue share
  for list owners
• Again, some billing issues

10
Billing - not a trivial task
Content
Content Creator
Cash
MM7
Service /Content Provider
Value Added ServiceProvider
NetworkOperator

• Issues
• Prepaid Billing
• Reply Charging, 3rd party Reverse Charging
• Charge only if service delivered successfully

!
Consumer
11
Billing Aspects

• Use Case Push-type information service
• Reverse charging should be possible to charge the
  recipient for using the service VASP should be
  able to control the charging (using content class
  or VAS codes)
• VASP should be informed if prepaid recipients
  cannot get the information due to insufficient
  credit
• Operator will charge for sucessful message
  delivery only, requires use of delivery status
  notifications, share revenue with VASP

12
Billing Aspects

• Use Case Pull-type information service
• Operator may charge for request msg
• VASP should be able to include charging
  information in response message
• Operator should charge for sucessfully delivered
  responses, reporting back to VAS application,
  share revenue with VASP

13
Billing Aspects

• Use Case List servers
• Pretty much the same as Push-type information
  service
• Control messages (subscribe / cancel / search)
  like pull-type information requests, will be
  charged as such
• Operator should charge for sucessfully delivered
  responses, reporting back to VAS application,
  share revenue with VASP
• Revenue share model for list owners using special
  messages?

14
Billing Aspects

• Use Case Push-reply-type service (e.g. opinion
  polls)
• Typical use case for reply-charging, e.g. VASP
  will be charged for the reply not the replying
  party, i.e. the recipient of the push message

15
Security Aspects

• MM7 operations will have effect on subscribers
  credits as well as on VASPs and network
  operators costs
• MM7 will possibly realized over public networks,
  e.g. VPN tunnels through the Internet, or IP over
  leased lines
• Proper authentication, data encryption, and data
  integrity is required on both sides of the
  interface
• Session-oriented connection is strongly
  recommended
• VASP profiles are required on the MMS
  Relay/Server (or MM7 frontend) side for
  commercial reasons and VASP authentication
• Different VASP agreements could include different
  levels of VASP rights (e.g. reverse charging,
  charging limits, ...)

16
MM7 Requirements summary

• Open session / close session operations for VASP
  authentication
• Security measures to minimize fraud or other
  interception attempts
• RFC822-style addressing for applications
  (application-name_at_server-name.operator-domain.topl
  evel-domain)
• Submit / Deliver operations
• VASP controls basic service charging
• VASP should get individual low-credit or
  no-credit result codes for push messages to
  prepaid subscribers
• Support of reverse charging (part of commercial
  agreement with VASP)
• Support of reply-charging (part of commercial
  agreement with VASP)

17
OSA (Open Services Access)

• -- a proper choice for an MM7 framework?
• OSA would fulfill some security and
  authentication requirements
• For an VAS application, OSA would provide access
  to other network services in parallel to MMS
• Network operators would probably not open their
  OSA environment to everyone
• Generic Messaging not yet defined in Rel-4 OSA
  specifications

18
Recommendations

• Add a description of MMS-based value added
  services and a list of MM7-related requirements
  to TS 22.140 (Liasion to SA)
• Examine available standard IETF protocols for
  their usefulness as a base protocol for MM7
• Evaluate OSA standardisation activities
• Include a list of required/optional MM7
  operations in TS23.140
• Include MM7 billing aspects in other billing
  drafting activities

19
Thank you for listening!
Jan Geiger Head of ResearchBU Communications MATE
RNA GmbH jan.geiger_at_materna.de