Transcript T201xxxx MM7 – Use Cases, Goals and Requirements

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 application
environment
Use case and goal analysis for external MMS
applications
Requirements for protocols at reference point MM7
Proposals for Rel-5 drafting
2
Architecture
Location
Presence
Network Operator
Sports
Traffic
Weather
Content /
Service
Providers
User Profiles /
Home Environment
Local Subscriber Profiles
e.g.
Travel Assistant App
VASP Profiles
e.g.
Community Services
Gateways
Application Server
Value Added
Service Provider
(VASP)
MM7
MMS Relay/Server
Network Operator
3
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 VASP‘s services
4
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 Sonera‘s paper (T2010134):
 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
5
Sample use cases
•
•
•
•
•
•
•
UMS Notifications (Voice/Email/Fax; „I‘m 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
6
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
7
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.
[email protected]) than
MSISDN; MSISDN would require to send a
keyword identifying the desired service
• Again, some billing issues – see below
8
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
9
Billing - not a trivial task
Content
Cash
MM7
Content
Creator
Service /
Content
Provider
Value
Added
Service
Provider
Network
Operator
Issues:
- Prepaid Billing
!
Consumer
- Reply Charging, 3rd party Reverse Charging
- Charge only if service delivered successfully
10
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
11
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
12
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?
13
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
14
Security Aspects
•
•
•
•
•
•
MM7 operations will have effect on subscriber‘s credits as
well as on VASP‘s and network operator‘s 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, ...)
15
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 ([email protected])
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)
16
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
17
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
18
Thank you for listening!
Jan Geiger
Head of Research
BU Communications
MATERNA GmbH
[email protected]
19