T2-010470 MM7 – Use Cases, Goals and Requirements

1. T2-010470MM7 – Use Cases, Goals and Requirements Jan Geiger MATERNA GmbH 3GPP T2#13 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. User Profiles / Home Environment 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 VASP‘s 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 Sonera‘s 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; „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

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@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 MM7 Cash 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 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, ...)

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@server-name.operator-domain.toplevel-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 MATERNA GmbH jan.geiger@materna.de