T2-010470 MM7 - PowerPoint PPT Presentation

About This Presentation
Title:

T2-010470 MM7

Description:

T2-010470 MM7 Use Cases, Goals and Requirements Jan Geiger MATERNA GmbH 3GPP T2#13 May 14-18, 2001 Pusan, South Korea Overview Architecture of an external MMS ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Slides: 20
Provided by: JanGeige
Learn more at: https://www.3gpp.org
Category:
Tags: mm7 | operations

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com