1. 3GPP2 Requirements Development Projects of Interest to OMA 3GPP2 – OMA Requirements Workshop Kansas City, MO, USA March 22, 2004

2. 2 Requirements Status (1/2) BCMCS NAM Network Evolution MEID IP Multimedia Domain System Req. Immediate Messaging Presence MMS Revision A IP Based Location Rev. A Enhanced Call Recovery Protocol Alignment End-to-End QoS Wideband Vocoder Doc.TitleDev.TSG Rev.Pub. 30-A 37 38 48-A 58 61 62 64-A 66-A 67 76 79 80 Document preamble: S.P0[0].. or S.R0[0].. Items in red identify projects of mutual interest

3. 3 Requirements Status (2/2) Packet Data Security BCMCS Security Packet Data Pre-Paid IMS Security Framework WLAN Interworking Network Initiated Data Session LMSD Step 2 Network Performance Measurements Rm Interface Enhancements ISIM on UICC Transcoder-Free Operation WLAN Interworking Security Framework PoC IOTA Network Firewall Config. and Control Doc.TitleDev.TSG Rev.Pub. 82 83 84 86 87 90 92 93 94 95 96 98 100 101 103

4. 4 Broadcast/Multicast BCMCS Requirements Revision A (S.R0030-A) Revision A of Stage 1 was published January 2004 BCMCS physical layer specification work is completed in TSG-C BCMCS is in advanced stages of development in TSG-X BCMCS Security Framework (S.R0083-A) This security document was published in October 2003 Fundamental concept of BCMCS security is a subscription model providing a basis for access to authorized users only This may be extended to include DRM considerations for the content being broadcast/multicast

5. 5 Immediate Messaging and Presence IM and Presence Requirements Revision 0 of Stage 1 Immediate Messaging (S.R0061-0) and Presence (S.R0062-0) were published October 2002 They are based on –RFC 2778 “A Model of Presence and Instant Messaging” and –RFC 2779 “Instant Message/Presence Requirements” IM/Presence Stage 1s should be highly aligned with the equivalent projects in 3GPP, which are also based on the two stated RFCs Discussion IM is one of many potential applications of Presence capability Close coordination on Presence capability will ease interoperability of many such applications Coordination with IETF will ease interoperability with the similar non-wireless services (e.g. Instant Messaging, Chat, etc.)

6. 6 MMS (1/3) MMS Requirements Revision 0 (S.R0064-0) Revision 0 of Stage 1 published October 2002 Conceptually similar with 3GPP equivalent Permits additional protocols for the client-server interface (MM1) – several are defined in MMS specifications –X.S0016-310 MM1 Using OMA/WAP-defined protocol (published April 2003) –X.S0016-311 MM1 Using M-IMAP for Message Submission and retrieval (published May 2003) –SIP-based MM1 in publication process

7. 7 MMS (2/3) MMS Requirements Revision A (S.P0064-A) Currently under development Modifications include –Incorporation of DRM Issues (refers to OMA DRM v1_0) –Supplemental VASP related requirements (note that MM7 specification, defining interface to a VASP is published April 2004 in X.S0016-370) –Short Code addressing option –Suppression of message forwarding loops –Support of Hyperlinks imbedded in message payload (e.g., plain text, HTML, etc.) –Network based message repository option These modifications should keep it in closer alignment with the 3GPP version

8. 8 MMS (3/3) Collaboration with OMA The need for MMS interoperability between various networks (including landline ISPs and corporate intranets) and technologies (CDMA, GSM, WLAN, …) is critical for the uptake of MMS It would be best if the bulk of specifications that are technology neutral are developed in a single place There are few access dependent aspects, which are currently being investigated 3GPP2 is in favor of relying on OMA for maintenance and further development of MMS 3GPP2 has approved submitting its work to OMA for such purpose, pending resolution of IPR alignment issue.

9. 9 Location (1/3) Background Geo-location is a very important capability for many applications in mobile wireless systems 3GPP2 has devoted considerable effort toward development of underlying technology and location based services, a process that is ongoing Published specs: Spec.Subject/TitleStatus C.S0022-APosition Determination ServicePublished 3/04 N.S0030-0Enhanced Wireless 911 Phase 2Published 4/02 X.S0002-0Location Services Using Enhanced 911Published 2/04 S.R0066-0IP Based Location Service RequirementsPublished 4/03

10. 10 Location (2/3) Circuit-Switched Location N.S0030 specifications are complete as of April 2002 Transmission of mobile station location in case of emergency distress, known in the US as E-911 –Circuit switched call to emergency center –Location information is (LAT, LON) is conveyed via messaging X.S0002 specifications are complete as of February 2004 for transmitting mobile station location for commercial (non- emergency) applications –Contains controls for privacy (e.g. mobile subscriber can block access if location privacy is desired)

11. 11 Location (3/3) IP Based Location Requirements document S.R0066-0 published as of April 2003 Based largely on the circuit-switched counterpart in X.S0002 –Same general requirements, but accessible via IP-based interface –Allows reuse of large portions of existing location infrastructure for rapid deployment of services IP Based Location Requirements Revision A (S.P0066-A) Development started in 2003 Not much progress due to desire to first develop specifications and deploy Revision 0 Some newly proposed requirements are still subject to decisions of 3GPP2: –Codeword based security –Diluted precision as way of controlling privacy –Various forms of location reporting triggers (e.g. periodic, distance segment traveled, velocity threshold, etc.)

12. 12 PoC PoC System Requirements Document Revision 0 (S.P0100-0) “System Requirements” is conceptually similar to Stage 1, but there is a difference in emphasis –Stage 1 emphasis is user perception –System Requirement emphasis is development of network capability, based on which service can be defined Currently in early stages of development The intent is to work in concert with OMA PoC requirements and beyond PoC requires close coordination because of high dependence on underlying and radio access and network capabilities

13. 13 IOTA DM IOTA – IP-Based Over-The-Air Device Management (S.P0101-0) IOTA DM Stage 1 is now in the review phase, leading to publication The objective is to increase IOTA capabilities to a broader set of goals, up to and including remote software download The work is expected to be complimentary to OMA work –Exchange of LS is already occurring, e.g. on the issue of remote detection of R-UIM (SIM) insertion 3GPP2 has developed some capabilities to manage wireless devices remotely (over-the-air): Spec.Subject/TitleStatus N.S0011-0OTASP and OTAPAPublished C.S0040-0IOTA HCMPublished 8/03 IOTA DM OTASP OTAPA IOTA HCM Legend IP-Based Over-The-Air Device Management Over-The-Air Service Provisioning Over-The-Air Parameter Administration IOTA Handset Configuration Management

14. 14 NFCC Network Firewall Configuration and Control Stage 1 (S.P0103-0) Draft requirements document under development NFCC may be related to OMA Content Screening Purpose of NFCC Minimize effects of unapproved IP traffic upon network resources Prevent subscriber being billed for unapproved traffic

15. 15 Conclusions Several 3GPP2 and OMA projects may be of mutual interest Further exchange should take place between two organizations to coordinate requirements development and alignment, if necessary www.3GPP2.org web site is openly accessible with wealth of information Published Requirements (Stage 1) documents are in S-series of documents (published by TSG-S) All meeting Contributions are placed on the web site after every meeting Contribution S00- -100, where is meeting date (e.g. 20040315 contains a table with latest status of TSG-S documents under development The latest 3GPP2 Work Plan is attached for further information